Repository navigation
bug(frontend): 32 baselined API calls point at renamed endpoints — dead buttons the wiring gate cannot see #12894
Description
Activity
Correcting this issue's premise before it drives any more rewiring — PR #12941.
The headline claim here ("32 of the 35 baseline entries are renamed endpoints, not unimplemented ones") came from the
REMOVED-ENDPOINT DRIFTlabel, and that label was over-claiming.rematchclassified a baselined call as drift whenever any candidate route shared one concrete segment and clearedSUGGESTION_FLOOR. Since_similaritydeliberately weights leading-segment agreement, every sibling in a surviving namespace clears that bar — so an endpoint nobody ever built, sitting beside endpoints that were, is indistinguishable from a genuine rename.Checked against a route table built from current source (2161 paths), the namespaces confirm the original #12378 classification was right:
baselined actually in that namespace verdict 8 × /api/dev-speedup/*analyze,dead-code,duplicates,imports,patterns,quality,refactoring,templates, …none of the 8 exist under any name — not renames 3 × /api/system/backup/*only /api/system/backup/statusnot renames /api/system/restart,/shutdownhealth,info,metricsnot renames /api/browser/executesuggestions were /api/workflow/,/api/sandbox/,/api/terminal/cross-namespace — not a rename /api/multimodal/health,/api/service-monitor/resources,/api/knowledge_base/documents/{p}absent not renames Two entries needed reading the caller rather than the path:
/api/knowledge/verification/approveis not the same capability as the real/api/knowledge_base/verification/{fact_id}/approve.acceptSourceinKnowledgeResearchPanel.vueposts{source_url, title}with nofact_id— it approves a research source; the backend route approves a pending fact. Correctly baselined; the reason is now recorded in the baseline file./api/knowledge_base/category/{p}is the one real rename, and even it was not the suggested target./categories/{id}returns{status, category}, whilefetchCategoryis typedCategoryResponse(carryingfacts[]) and its test is titled "should fetch facts for a specific category". The right endpoint is/categories/{category_id}/facts. Note it has no UI caller — reached only via theuseKnowledgeBasere-export — so it was never a "dead button" either.
So: 1 real rename, not 32, and no dead buttons of the kind described.
PR #12941 fixes the classifier rather than the callers: a rename must preserve the resource within the same namespace, and everything else now reports as
NAMESPACE ALIVE, NO MATCHING ROUTEwith its neighbours explicitly marked~ nearest, NOT a rename. Output goes from29 rematchto0 renamed, 28 namespace-only— matching the manual per-namespace review independently.Precision over recall is deliberate: a fuzzy resource match would readmit false positives like
/api/code-intelligence/analysis/{id}→/analyze, which are different operations (fetch a stored analysis vs run one).The 28 namespace-only entries stay tracked under #12378/#12364 as what they always were — unbuilt endpoints awaiting a build-or-remove decision.
- added a commit that references this issue
on Jul 29, 2026 Closed by PR #12941, squash-merged to
Dev_new_guias4e14d0155.Resolved by correcting the classifier rather than the 29 callers this issue named — the premise did not hold (full evidence in the comment above). A baselined call is now reported as renamed only when a surviving route preserves its resource within the same namespace; everything else reports as
NAMESPACE ALIVE, NO MATCHING ROUTEwith neighbours explicitly marked~ nearest, NOT a rename.before: == BASELINE HEALTH: 29 rematch, 0 resolved, 0 no-longer-called == after: == BASELINE HEALTH: 0 renamed, 28 namespace-only, 0 resolved, 0 no-longer-called ==The one genuine rename found —
/api/knowledge_base/category/{p}— is fixed:fetchCategorynow calls/categories/{id}/facts, matching itsfacts[]-carrying return type, and its baseline entry is pruned.Verification: 30 passed (
audit_api_wiring_suggestions_test.py+audit_api_wiring_test.py), 17 passed (useKnowledgeCategories.test.ts), flake8 clean. Gate findings unchanged atUNWIRED FRONTEND CALLS: 5before and after, so gating behaviour is untouched.The 28 namespace-only entries remain tracked under #12378/#12364 as unbuilt endpoints awaiting a build-or-remove decision — not as drift.
Summary
#12738 added closest-route suggestions and a baseline-health classifier to
scripts/audit_api_wiring.py(PR #12893). Running it in authoritative mode against a route table built from current source (2161 paths) shows that 32 of the 35 entries inscripts/api_wiring_baseline.txtare renamed endpoints, not unimplemented ones — the caller is live, the endpoint moved, and the baseline has been suppressing the gate ever since.These are dead buttons in the GUI. The gate is green because each call is baselined.
The clearest cluster: browser endpoints moved under
/mcp/Four of the seven have a same-namespace replacement and are near-mechanical. Three do not, and need a decision about whether the capability still exists at all.
Full rematch list (32)
Reproduce with the suggestions for each:
and read the
BASELINE HEALTHsection.Why this is its own issue
#12738 delivered the detection and the guidance. Acting on it is a different risk profile: 32 frontend call sites across composables and repositories, where a suggestion is a candidate and not proof. Several suggestions are cross-namespace (
/api/browser/execute→/api/workflow/execute) and would be wrong to apply mechanically — those need confirming that the capability still exists, or an issue saying it does not.Done when
BASELINE HEALTHreports 0 rematch on an authoritative run.--fail-on-unwiredgate stays green throughout (rewiring removes entries from the baseline as their calls start matching).Related: #12738 (the tooling), #12381 (baseline introduced), #12756 (browser unification — the
/mcp/cluster likely belongs to that epic).