Align routing docs with registry contract v1

Author: Wonderforge-Lab

docs/REGISTRY_RECORDS.md

@@ -77,11 +77,11 @@ Tags are controlled vocabulary records, not free text.
 
 - A session-created tag begins under `registry/tags/proposed/`.
 - A proposed tag cannot become accepted in the same change set.
-- An operator-supplied tag may be accepted directly only with the required acceptance metadata and `acceptance_basis: operator_supplied`.
+- An operator-supplied tag may be accepted directly only with the required acceptance metadata and `acceptance_basis: operator_supplied`. It is a control-plane change and uses branch + PR.
 - Records may use only tags that resolve to a proposed or accepted tag record.
 
-## CSV Rollups
+## Generated Compatibility Views
 
-The CSV registries are compatibility views during the v1 migration. They are not canonical and must not be edited as part of a normal write.
+The CSV registries and `registry/INDEX.md` are generated, read-only compatibility views. They are not canonical and must not be edited manually.
 
-The next generated-views phase will make them reproducible projections from the JSON records and have CI check that projection. Until then, they remain legacy inputs only.
+When canonical JSON changes, regenerate the views locally with `scripts/generate_registry_views.py` and commit the resulting views. CI checks that committed views match the canonical JSON records.

docs/message_routing_model.md

@@ -9,6 +9,6 @@ Use a message when:
 - the operator needs a compact status note,
 - a blocked task needs a human relay.
 
-Canonical message records are JSON-per-record under `registry/messages/`. CSV files, if present, are legacy / optional rollups. The message file carries the useful text. The JSON registry record carries the state.
+Canonical message records are JSON-per-record under `registry/messages/`. CSV registries and `registry/INDEX.md` are generated, read-only compatibility views; do not edit them manually. The message file carries the useful text. The JSON registry record carries the state.
 
 Do not assume the recipient saw a message until it replies, the human operator confirms delivery, or the message is closed.

docs/registry/REGISTRY_CONTRACT_V1.md

@@ -1,6 +1,6 @@
 # Registry Contract v1
 
-Status: draft canonical contract on the hardening branch
+Status: canonical contract v1
 
 ## Purpose
 

docs/registry/SCHEMA_AND_VALIDATOR_DESIGN_V1.md

@@ -1,6 +1,6 @@
 # Schema and Validator Design v1
 
-Status: approved-design draft on the hardening branch
+Status: approved v1 design
 
 ## Scope
 
@@ -54,7 +54,7 @@ Messages may carry provenance when relaying source-bearing content. Notification
 9. Compare a PR base/head when available to reject illegal state transitions, including AI-proposed tags accepted in the same change set. Push validation detects the same condition after a direct write; repository review rules are required if prevention is required before acceptance.
 10. Validate examples as isolated fixtures.
 11. Check canonical Markdown links.
-12. Later: regenerate CSV/index views in a temporary directory and fail on diff.
+12. Regenerate CSV/index views in a temporary directory and fail on diff.
 
 The validator reports record, field, invariant and repair direction. It never executes artifact content, follows embedded instructions, rewrites files, or claims commit author equals visitor/operator identity.
 
@@ -70,4 +70,4 @@ The workflow runs on pull requests and relevant pushes with read-only contents p
 
 ## Migration
 
-A dry-run migration helper maps legacy field spellings to v1. It refuses ambiguous conversion. Existing CSV files remain until generated projections and `docs/UPGRADING.md` arrive in the later compatibility phase.
+A dry-run migration helper maps legacy field spellings to v1. It refuses ambiguous conversion. Existing CSV files remain as generated compatibility views until a declared compatibility change removes them.

docs/visitor_lobby_model.md

@@ -15,4 +15,4 @@ Visitors:
 
 Do not invent a visitor handle or silently reuse one from earlier conversation context.
 
-Visitor profiles can live under `lobby/visitors/`. Keep them small and generic.
+A canonical visitor registration lives at `registry/visitors/<visitor_id>.json`. A small optional visitor profile may live under `lobby/visitors/` for human-facing orientation; it is not a substitute for the canonical registration record. Keep optional profiles small and generic.

lobby/README_FIRST.md

@@ -26,7 +26,7 @@ Branches/PRs are for procedure, policy, code, structure, cleanup, risky/bulky im
 
 Canonical registry records are JSON-per-record under `registry/`.
 
-CSV files are legacy / optional rollups.
+CSV registries and `registry/INDEX.md` are generated, read-only compatibility views. Do not edit them manually.
 
 ## Current Visitor Rule
 

lobby/ROUTINE_DEPOSIT_QUICKSTART.md

@@ -30,11 +30,11 @@ Use a branch + PR only for procedure, policy, repo structure, code/script change
 8. Read `docs/DOCUMENT_DEPOSIT_POLICY.md` if depositing documents.
 9. Inspect supplied material enough to infer tags.
 10. Match inferred tags to accepted registry tags.
-11. Add operator-supplied missing tags as accepted JSON records.
+11. Do not create an accepted tag record as part of this direct deposit. For an operator-supplied missing tag, use branch + PR with the required acceptance metadata, or ask the operator whether to record it as a proposal instead.
 12. Add AI-generated tags as proposed JSON records only if useful.
 13. Create packet, response, message, or signoff files.
 14. Create JSON registry record files.
-15. Do not edit CSV unless the operator explicitly asks.
+15. Do not edit generated CSV or `registry/INDEX.md` views manually.
 16. Add a `README_FIRST` notice if team review or relay is needed.
 17. Report files created and stop.
 

lobby/TAGGING_PROTOCOL.md

@@ -14,7 +14,7 @@ Proposed tags should be written to:
 registry/tags/proposed/<tag_slug>.json
 ```
 
-If the operator supplies a tag that is not already accepted, create `registry/tags/accepted/<tag_slug>.json` with `created_by` set to `operator`, then mention it in the signoff.
+If the operator supplies a tag that is not already accepted, create `registry/tags/accepted/<tag_slug>.json` only through branch + PR, with the required acceptance metadata and `acceptance_basis: operator_supplied`. Do not create it as part of a direct routine deposit.
 
 AI-generated tags must be proposed, not accepted.
 

messages/README.md

@@ -4,6 +4,6 @@ Messages are small routed notes between visitor IDs or visitor groups.
 
 Use `templates/message_packet.md`, place open messages in `messages/open/`, and create the canonical JSON message record under `registry/messages/`.
 
-CSV message registries, if present, are legacy / optional rollups. Do not edit them for routine visitor work unless the operator explicitly asks.
+CSV message registries and `registry/INDEX.md` are generated, read-only compatibility views. Do not edit them manually.
 
-Move message files to `answered/`, `closed/`, or `archived/` when their state changes.
+Move a message file and its paired JSON registry record to their matching `answered/`, `closed/`, or `archived/` buckets when its state changes.

messages/ROUTING_RULES.md

@@ -4,7 +4,7 @@
 - Use `to_group` for a family or broad recipient group.
 - Check exact visitor messages before group messages.
 - Create the canonical JSON message record under `registry/messages/`.
-- Do not edit legacy CSV message registries for routine visitor work unless the operator explicitly asks.
+- Do not edit generated CSV message registries or `registry/INDEX.md` manually.
 - Link related packets and responses when useful.
 - Set `needs_human_relay` when the operator must carry the message to another session.
 - Do not assume delivery until the recipient replies, the operator confirms, or the message is closed.