# API Contract-Coverage Audit (#528) — Hot-Swap Readiness

## Coverage (against the 6 hot-swap criteria)
- **Backend surface (denominator):** 32 workers, ~1,176 route registrations; ~400 contract-candidate admin/studio operations after excluding non-candidates.
- **Fully READY (all 6 criteria):** 7 operations — events (list/get/create/update/delete) + locations (list/get).
- **Coverage ≈ 1.75% of ~400** (≈2.75% of registry-defined ops). The only "started" domains are **events + locations**, which are ~**64%** ready on their own:
  - events ~33% → 100% after 4 missing client methods are added;
  - locations gap is "writes missing a typed client method" (~36%).
- **Every other domain is 0%:** catalog, booking, integrations (~8%), notifications, payments, availability, staff-feed, reporting, queue/coord, identity, auth.

## Roadmap — dependency-ordered, hub-collision-safe (the key to "aggressively parallel")
- **STEP 0 (prerequisite, single line, blocks all — touches all 3 hubs):** de-monolith `packages/api-contracts/src/operations.ts` into per-domain modules so domains stop colliding on the shared registry. This is what *enables* safe parallel fan-out (per the hub-collision lesson).
- **BATCH A** (quick-wins, read-only GETs — run concurrently after Step 0): catalog GETs, availability, etc.
- **BATCH B** (medium, stateful writes): catalog services CRUD, availability rules CRUD, queue, etc.
- **BATCH C** (heavy-lifts: statefulness + filter/pagination + fan-out): events-guests/tickets, etc.

## Notes / caveats
- One sub-agent (real-backend route enumeration for events/booking/queue — the heaviest) hit an "Overloaded" API error, so the real-route conformance numbers for those domains are partially estimated.
- Demand-driven priority: prioritize the domains a live screen actually calls (per the CD-owns-mocks+changelog model). Detailed per-operation client/contract/mock/backend tables are in the audit transcript.