feat(api): add REST mirrors for the finding-taxonomy and enrichment-analyzers MCP resources

[davion-knight]

What & why

buildFindingTaxonomyDocument() and buildEnrichmentAnalyzersTaxonomyDocument() were reachable only as MCP resources (loopover://finding-taxonomy, gittensory://enrichment-analyzers). A caller without MCP access — a plain HTTP client, a dashboard, a non-MCP integration — had no way to fetch either, even though routes.ts otherwise exposes essentially every other piece of review/registry/scoring data over /v1/*.

Changes

• GET /v1/finding-taxonomy and GET /v1/enrichment-analyzers, each delegating to its existing pure, argument-free builder with the same plain-c.json() handler shape as the /v1/scoring/model route they sit beside.
• Additive only — the MCP resource registrations in src/mcp/server.ts are untouched, and the URIs stay MCP-only identifiers.
• Both paths registered in src/openapi/spec.ts with response schemas, and apps/loopover-ui/public/openapi.json regenerated so ui:openapi:check / ui:openapi:settings-parity stay green.

The two schemas are deliberately permissive on member strings: the taxonomies are open-ended (FINDING_CATEGORIES, the committed analyzer-metadata.json), so the shape is the contract — adding a category or analyzer must never break the spec.

One correction worth flagging

The issue describes these as "unauthenticated GET routes consistent with the other public static-data routes (/v1/registry/snapshot, /v1/upstream/ruleset, /v1/scoring/model)". Those siblings aren't actually public — I verified GET /v1/scoring/model returns 401 unauthenticated. So I followed the requirement as written where it counts (no new auth middleware added), and the new routes inherit exactly the same gating as the siblings they mirror. The auth test pins them against /v1/scoring/model's own behavior rather than a hard-coded status, so it stays honest if that shared middleware ever changes — and can never silently open a public hole.

Tests

Each route returns its builder's document byte-identically; neither leaks PR/user/private data; both match the sibling's gating; and openapi.test.ts's path list is extended with both new paths (as the issue requires). Zero uncovered lines and branches across all three changed src/ files, measured against the changed-line set.

Resubmit of #6689, which the gate closed as dirty with CI green and no blockers — main moved and conflicted the generated apps/loopover-ui/public/openapi.json. Rebased onto latest; the artifact was regenerated from the merged spec rather than hand-merged, so it can't carry a stale hand-resolution.

Closes #6593

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.65%. Comparing base (3acc512) to head (73a91a2).
⚠️ Report is 21 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6706   +/-   ##
=======================================
  Coverage   93.65%   93.65%           
=======================================
  Files         681      682    +1     
  Lines       68098    68124   +26     
  Branches    18695    18702    +7     
=======================================
+ Hits        63775    63800   +25     
  Misses       3347     3347           
- Partials      976      977    +1     

Flag	Coverage Δ
shard-1	43.84% <100.00%> (-0.06%)	⬇️
shard-2	36.95% <66.66%> (+0.11%)	⬆️
shard-3	32.37% <100.00%> (-0.03%)	⬇️
shard-4	34.23% <100.00%> (-0.43%)	⬇️
shard-5	31.40% <66.66%> (+0.46%)	⬆️
shard-6	45.77% <100.00%> (+0.11%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/api/routes.ts	94.61% <100.00%> (+0.06%)	⬆️
src/openapi/schemas.ts	100.00% <100.00%> (ø)
src/openapi/spec.ts	99.45% <100.00%> (+0.01%)	⬆️

... and 1 file with indirect coverage changes

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-16 20:14:29 UTC}

6 files · 1 AI reviewer · no blockers · readiness 80/100 · CI green · unknown

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR adds two GET REST mirrors (`/v1/finding-taxonomy`, `/v1/enrichment-analyzers`) for existing pure, argument-free MCP resource builders, wires them into the OpenAPI spec/schemas with a regenerated openapi.json, and adds tests that pin the routes' auth behavior against the sibling `/v1/scoring/model` route rather than a hard-coded status. The change is additive, narrowly scoped, and the auth-parity test design is a solid defensive choice that avoids silently opening a public hole if middleware changes. The PR description explicitly corrects a factual error in the linked issue (claiming these routes should be public) and documents why it deviated, which is good practice.

Nits — 5 non-blocking

• The size-smell flags on `routes.ts`, `schemas.ts`, and `openapi.json` are pre-existing file sizes, not something this diff meaningfully worsens, since it only adds a handful of lines to each.
• The magic-number flags on `200` in `src/openapi/spec.ts` are boilerplate HTTP status codes matching the exact pattern already used by every other route registration in that file, so no action needed there.
• Consider a short comment in `test/unit/routes-taxonomy-mirrors.test.ts` clarifying that the JSON round-trip (`JSON.parse(JSON.stringify(...))`) is intentional to normalize any non-JSON-serializable builder output for the equality check.
• If `buildFindingTaxonomyDocument()`/`buildEnrichmentAnalyzersTaxonomyDocument()` are ever extended to include per-user or private fields, the auth-parity test in `routes-taxonomy-mirrors.test.ts` should be revisited since it currently just mirrors whatever `/v1/scoring/model` does rather than asserting a specific policy.
• Double check the linked issue REST mirror for the finding-taxonomy and enrichment-analyzers MCP resources #6593 is fully closed by this PR (the external brief flags 'partial' coverage) — confirm whether any part of the issue's ask (e.g., additional documentation) is still open.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#6593
Related work	⚠️ 3 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 174 registered-repo PR(s), 111 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	davion-knight; Gittensor profile; 174 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Review context

• Author: davion-knight
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 174 PR(s), 0 issue(s).
• Related work: Titles/paths share 9 meaningful terms. (issue #6620)
• Related work: Titles/paths share 8 meaningful terms. (PR #6709)
• Related work: Titles/paths share 10 meaningful terms. (issue #6593, issue #6620)
• Additional title-only matches omitted; title-only overlap does not block.

Contributor next steps

• Start here: Review top overlaps.
• Then work through the remaining 2 steps in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.