surface-registry-alignment

# surface-registry-alignment Keep stable surfaces registry-backed and inspectable. ## Procedure 1. Read the surface registry ADR, interface matrix, decision map, and relevant generated manifest. 2. Identify every new or changed stable surface: CLI command, API route, event, schema, ID prefix, storage path, preference key, database table, or UI capability. 3. Register it through the typed registry or the project-approved manifest path. 4. Add `surfaceNarrative` for every new registered surface: concept, authorizing decision, completing human/programmatic surface, and non-inference boundary. 5. Add `resourceContract` for every new runtime, UI, storage, stream, cache, API, CLI, permission, or feature-flag surface: startup, idle, memory, streaming, storage, hot path, scale, and validation. 6. Ensure `claw inspect` or the equivalent inspection surface can explain the surface and expose the narrative and resource contract. 7. Classify human and programmatic surfaces as `stable`, `local-only`, `blocked`, `not applicable`, or another accepted status. 8. Add tests or guards that reject manual lists drifting away from registry truth. ## Constraints - Manual docs are allowed as generated output or explanations, not as the registry source. - UI-only capabilities are incomplete unless a programmatic surface exists or the gap is classified. - A technically valid surface without `surfaceNarrative` is incomplete; do not add it to the baseline unless it is pre-existing bounded debt. - A technically valid surface without `resourceContract` is incomplete; do not add it to the baseline unless it is pre-existing bounded debt. - Do not copy whole provider schemas into Claw-owned registries.