REST mirror for the finding-taxonomy and enrichment-analyzers MCP resources

[JSONbored]

Context

src/review/finding-taxonomy.ts and src/review/enrichment-analyzers-taxonomy.ts each build a small, static, read-only JSON document:

• buildFindingTaxonomyDocument() (src/review/finding-taxonomy.ts:13) returns the canonical AI-review finding categories + severities ladder, keyed to FINDING_TAXONOMY_URI = "loopover://finding-taxonomy" (src/review/finding-taxonomy.ts:5).
• buildEnrichmentAnalyzersTaxonomyDocument() (src/review/enrichment-analyzers-taxonomy.ts:29) returns the REES enrichment analyzer taxonomy (name/category/cost class/profiles), keyed to ENRICHMENT_ANALYZERS_URI = "gittensory://enrichment-analyzers" (src/review/enrichment-analyzers-taxonomy.ts:4).

Both are registered as MCP resources in src/mcp/server.ts (server.registerResource("loopover_finding_taxonomy", FINDING_TAXONOMY_URI, ...) and server.registerResource("loopover_enrichment_analyzers", ENRICHMENT_ANALYZERS_URI, ...), around lines 2816-2854) — but neither has a REST mirror in src/api/routes.ts (a 6000+ line file that otherwise exposes essentially every other piece of review/registry/scoring data over /v1/*, e.g. /v1/registry/snapshot, /v1/scoring/model, /v1/upstream/ruleset). A caller without MCP access (a plain HTTP client, a dashboard, a non-MCP integration) currently has no way to fetch either taxonomy.

Both builder functions are pure, take no arguments, require no auth beyond what every other public /v1/* read route already requires, and return no PR/user/private data — they are static discovery documents (categories, severities, analyzer metadata), the same class of data as the already-public /v1/registry/snapshot and /v1/upstream/ruleset routes.

Requirements

1. Add GET /v1/finding-taxonomy to src/api/routes.ts that returns buildFindingTaxonomyDocument() (imported from src/review/finding-taxonomy.ts) as JSON, following the exact same handler shape as the existing app.get("/v1/scoring/model", async (c) => c.json(await getOrCreateScoringModelSnapshot(c.env))); route (no request body, no params, plain c.json(...)).
2. Add GET /v1/enrichment-analyzers to src/api/routes.ts that returns buildEnrichmentAnalyzersTaxonomyDocument() (imported from src/review/enrichment-analyzers-taxonomy.ts) as JSON, same handler shape.
3. Both new routes MUST be registered in src/openapi/spec.ts so spec.paths["/v1/finding-taxonomy"] and spec.paths["/v1/enrichment-analyzers"] are defined — test/unit/openapi.test.ts asserts specific paths exist in buildOpenApiSpec(), and npm run ui:openapi:check / npm run ui:openapi:settings-parity gate on the spec staying in sync with apps/loopover-ui/public/openapi.json. Do not add a route without a matching OpenAPI path entry.
4. Do NOT change the existing MCP resource registrations in src/mcp/server.ts — this is an additive REST mirror, not a replacement. FINDING_TAXONOMY_URI and ENRICHMENT_ANALYZERS_URI stay MCP-only identifiers; the new REST routes are plain /v1/... paths, not those URIs.
5. Both new routes must be unauthenticated GET routes consistent with the other public static-data routes in the same file (/v1/registry/snapshot, /v1/upstream/ruleset, /v1/scoring/model) — do not add new auth middleware for these two routes.

Deliverables

• app.get("/v1/finding-taxonomy", ...) added to src/api/routes.ts, returning buildFindingTaxonomyDocument().
• app.get("/v1/enrichment-analyzers", ...) added to src/api/routes.ts, returning buildEnrichmentAnalyzersTaxonomyDocument().
• src/openapi/spec.ts updated with path entries for both new routes.
• Test coverage (see below) for both new routes.

Test Coverage Requirements

This repo's Codecov patch gate is 99%+, hard, for src/**/packages/**. Both touched files (src/api/routes.ts, src/openapi/spec.ts) are under src/, so the gate applies in full. Add:

• A test (in the existing routes/API test suite, e.g. alongside other /v1/* route tests) asserting GET /v1/finding-taxonomy returns 200 with a body matching buildFindingTaxonomyDocument()'s shape (categories, severities arrays).
• A test asserting GET /v1/enrichment-analyzers returns 200 with a body matching buildEnrichmentAnalyzersTaxonomyDocument()'s shape (defaultProfile, analyzers array).
• Extend test/unit/openapi.test.ts's existing spec.paths[...] assertion list with the two new paths (mirroring how every other route in that file is asserted).

Expected Outcome

GET /v1/finding-taxonomy and GET /v1/enrichment-analyzers return the same JSON documents already available via the loopover://finding-taxonomy and gittensory://enrichment-analyzers MCP resources, so any plain HTTP client (not just MCP-capable ones) can discover the review finding taxonomy and REES analyzer metadata. The OpenAPI spec and its parity checks stay green.

Links & Resources

• src/review/finding-taxonomy.ts, src/review/enrichment-analyzers-taxonomy.ts (the existing pure builders)
• src/mcp/server.ts (existing MCP resource registrations, ~lines 2816-2854)
• src/api/routes.ts (target file for the new routes; see /v1/registry/snapshot and /v1/scoring/model for the pattern to follow)
• src/openapi/spec.ts, test/unit/openapi.test.ts (OpenAPI parity requirement)
• Precedent: feat(mcp): register a gittensory://finding-taxonomy resource enumerating review finding categories #2225 (registered the loopover_finding_taxonomy MCP resource), feat(mcp): register a gittensory://enrichment-analyzers resource from REES analyzer metadata #2226 (registered the loopover_enrichment_analyzers MCP resource) — both MCP-only, never given a REST counterpart.

[linear-code]

JSO-4477