# 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.