xiaobai-review/config/README.md

Governance Registries

These registries describe the approved product surface of the standalone application.

• pages.config.json: primary page identity, navigation group, access expectation, scrolling, and mobile composition policy.
• features.config.json: feature ownership, backend access class, data scope, and availability.
• api.config.json: current routes generated from the preserved server.py API surface, with one feature owner and backend access class per route. Its dispatcher implementation lives in backend/application.py.
• architecture-inventory.json: generated inventory of current pages, routes, tables, providers, model entry points, CSS layers, and remaining code hotspots.
• data-fields.config.json: canonical data products, provider eligibility, intended use, and known blocked datasets.
• datahub.config.json: official read-only client for xiaobai-datahub. Each dataset has its own read / shadow flag; official reads default on. compose.yaml pins every DATAHUB_READ_* to "1" so a leftover .env =0 cannot silently keep official pages on the old APIs. Environment variables can still override a single DATAHUB_SHADOW_* without a master switch. The old website APIs stay as emergency fallback only.
• data-quality.config.json: freshness, coverage, units, adjustment, point-in-time, and fail-closed rules for every canonical data product.
• jobs.config.json: background schedules, dependencies, lock keys, retry policy, timeouts, and output versions.

The registries are governance contracts, not substitutes for runtime authorization. Backend access in backend/http/routes.py is authoritative; frontend visibility is only a presentation concern and never grants access.

Regenerate the transitional API inventory after a route change:

python tools/build_api_registry.py
python tools/build_api_registry.py --check
python tools/build_architecture_inventory.py
python tools/build_architecture_inventory.py --check