xiaobaifupan/docs/governance/stage-11-http-governance.md

Stage 11: HTTP Route, Access, and Error Governance

Date: 2026-07-29

Result

• Promoted config/api.config.json from a transitional inventory to the runtime route and access registry.
• Added deterministic exact and regex route resolution with duplicate and regex validation.
• Replaced hand-maintained member/admin path sets with the registered access contract.
• Rejected unregistered API routes before business dispatch.
• Added safe request correlation IDs to JSON responses and X-Request-ID headers.
• Extended every legacy JSON error with stable code, message, and request_id fields while preserving the existing error field used by the browser.
• Kept the current request handler and all route response bodies compatible while feature route modules are migrated incrementally.

Runtime Authority

Changing or adding an API now requires one coherent change to the handler and API registry. The generated source inventory test prevents either side from drifting. Backend access remains authoritative; frontend visibility cannot grant a route.

Residual Migration

Individual dispatch branches still live in the compatibility request handler. Feature-owned controllers will move behind the same registry in later stages without changing route identity, authorization, or error serialization.