Context
A maintainer review-stack × Autonomous Miner System (AMS) integration audit (2026-07-09) found that a submitted PR's real AI-review findings (category, path, severity) are never exposed via MCP in structured form — only the predicted-gate's static rule codes are.
Evidence
src/review/finding-category-classify.ts:9-40 — the real finding-category taxonomy (security/correctness/performance/maintainability/tests/style) and inferFindingCategory are computed values, but...src/review/unified-comment-bridge.ts:683-697 — buildFindingCategoryCollapsible only tallies counts per category into a markdown table string for the rendered PR-comment collapsible — never returns per-finding path/severity data structurally.src/mcp/server.ts:2253-2269 — gittensory_finding_taxonomy is confirmed to be a static enum resource (the 6-category list), not scoped to any specific PR.src/mcp/server.ts — every other findings-adjacent MCP tool (gittensory_predict_gate, gittensory_explain_gate_disposition, gittensory_explain_review_risk, gittensory_compare_pr_variants) is explicitly pre-submission / "planned PR" scoped.src/services/ai-review.ts (combineReviews) returns a defect/split/hold trio that can HOLD or block a real, already-submitted PR — with no MCP surface reading any of that back out. Confirmed via audit: none of gittensory_monitor_open_prs, gittensory_pr_outcome, gittensory_get_agent_audit_feed, gittensory_get_repo_outcome_patterns, or gittensory_get_outcome_calibration return AI-review finding category/path/severity either.
Why this matters for the Autonomous Miner System
Once a PR is actually submitted, a dual-AI-review defect finding or a reviewer-disagreement HOLD is the one realistic post-submission rejection mode most likely to actually block a miner's PR — and today that leaves the miner with nothing more actionable than PR-comment prose to parse, unlike the pre-submission static rule set (already machine-readable by rule code via gittensory_explain_gate_disposition). Closing this gap gives a future iterate-loop (#2333/#2334) a real, structured signal to map a post-submission rejection back to an actionable fix.
Deliverables
Surfaced by a maintainer review-stack × AMS integration audit (2026-07-09). Related: #1958 (finding-category taxonomy, closed — its scope was explicitly render-only, which is why this gap remains), part of the Wave-3 Dashboard UI & MCP tracker (#2013).
Context
A maintainer review-stack × Autonomous Miner System (AMS) integration audit (2026-07-09) found that a submitted PR's real AI-review findings (category, path, severity) are never exposed via MCP in structured form — only the predicted-gate's static rule codes are.
Evidence
src/review/finding-category-classify.ts:9-40— the real finding-category taxonomy (security/correctness/performance/maintainability/tests/style) andinferFindingCategoryare computed values, but...src/review/unified-comment-bridge.ts:683-697—buildFindingCategoryCollapsibleonly tallies counts per category into a markdown table string for the rendered PR-comment collapsible — never returns per-finding path/severity data structurally.src/mcp/server.ts:2253-2269—gittensory_finding_taxonomyis confirmed to be a static enum resource (the 6-category list), not scoped to any specific PR.src/mcp/server.ts— every other findings-adjacent MCP tool (gittensory_predict_gate,gittensory_explain_gate_disposition,gittensory_explain_review_risk,gittensory_compare_pr_variants) is explicitly pre-submission / "planned PR" scoped.src/services/ai-review.ts(combineReviews) returns a defect/split/hold trio that can HOLD or block a real, already-submitted PR — with no MCP surface reading any of that back out. Confirmed via audit: none ofgittensory_monitor_open_prs,gittensory_pr_outcome,gittensory_get_agent_audit_feed,gittensory_get_repo_outcome_patterns, orgittensory_get_outcome_calibrationreturn AI-review finding category/path/severity either.Why this matters for the Autonomous Miner System
Once a PR is actually submitted, a dual-AI-review defect finding or a reviewer-disagreement HOLD is the one realistic post-submission rejection mode most likely to actually block a miner's PR — and today that leaves the miner with nothing more actionable than PR-comment prose to parse, unlike the pre-submission static rule set (already machine-readable by rule code via
gittensory_explain_gate_disposition). Closing this gap gives a future iterate-loop (#2333/#2334) a real, structured signal to map a post-submission rejection back to an actionable fix.Deliverables
requireContributorAccess/requireRepoAccess) the same way other contributor-facing MCP tools doSurfaced by a maintainer review-stack × AMS integration audit (2026-07-09). Related: #1958 (finding-category taxonomy, closed — its scope was explicitly render-only, which is why this gap remains), part of the Wave-3 Dashboard UI & MCP tracker (#2013).