docs: mark anomaly openapi review item resolved

Author: flyingrobots

docs/audits/code-reviews/PR3/e35da518e543d331abf0b57fa939d682d39f5a88.md.chunk_008.md

@@ -732,9 +732,9 @@ valid range so readers and JSON consumers have clear expectations.
 
 ### docs/api/anomaly-radar-slo-budget.md:124
 
-- [ ] Fixed
+- [x] Fixed
 - [ ] Test Written
-- [x] Suggestion Ignored
+- [ ] Suggestion Ignored
 
 ```text
 In docs/api/anomaly-radar-slo-budget.md around line 124, there is no
@@ -747,30 +747,26 @@ and generates client SDKs (specify targets, output directory, and caching) on
 merge so clients are produced automatically.
 ```
 
-> [!CAUTION]- **Rejected**
+> [!note]- **Accepted**
 > | Confidence | Remarks |
 > |------------|---------|
-> | 5 | Producing a full OpenAPI 3.1 spec + CI pipeline is out-of-scope for this review chunk. |
->
-> ## Rejection Rationale
->
-> We lack consensus on the final endpoint surface and don’t have automated validation wired up; generating an incomplete spec would be misleading.
+> | 8 | Added a draft OpenAPI spec plus validation workflow and linked it from the docs. |
 >
-> ## What you did instead
+> ## Lesson Learned
 >
-> Documented the endpoints comprehensively in markdown and continued referencing the existing admin API OpenAPI documents for guidance.
+> Treat the YAML spec as the source of truth and keep CI guarding it.
 >
-> ## Tradeoffs considered
+> ## What did you do to address this feedback?
 >
-> Building the spec now would take significant time and risk drift; deferring keeps focus on stabilising the API first.
+> Created `docs/api/anomaly-radar-openapi.yaml`, referenced it in the doc’s overview, and added `.github/workflows/anomaly-radar-openapi.yml` to validate the spec and dry-run TypeScript client generation on every change.
 >
-> ## What would make you change your mind
+> ## Regression Avoidance Strategy
 >
-> Once the anomaly radar API is stabilised and we can commit to long-term support, we can add the OpenAPI spec and CI job.
+> CI validation prevents drift; future doc edits can point to the shared spec.
 >
-> ## Future Plans
+> ## Notes
 >
-> Track the “API formalisation” epic; when prioritised we’ll emit the spec and wire the generator pipeline requested here.
+> Spec remains marked draft until the endpoints ship, but tooling is now in place.
 
 ### docs/api/anomaly-radar-slo-budget.md:176