Close registry validator review gaps

Author: Wonderforge-Lab

.github/workflows/validate.yml

@@ -24,6 +24,19 @@ jobs:
       - run: python tests/test_generated_views.py
       - run: python tests/test_markdown_links.py
       - run: python tests/test_bridge_config.py
+      - run: python tests/test_tag_promotion.py
       - name: Enforce tag-promotion separation
         if: github.event_name == 'pull_request'
         run: python scripts/check_tag_promotion.py "${{ github.event.pull_request.base.sha }}" "${{ github.sha }}"
+      - name: Detect tag-promotion separation violation on push
+        if: github.event_name == 'push'
+        env:
+          BEFORE: ${{ github.event.before }}
+          DEFAULT_BRANCH: ${{ github.event.repository.default_branch }}
+        run: |
+          if [ "$BEFORE" = "0000000000000000000000000000000000000000" ]; then
+            base="$(git merge-base "origin/$DEFAULT_BRANCH" "$GITHUB_SHA")"
+          else
+            base="$BEFORE"
+          fi
+          python scripts/check_tag_promotion.py "$base" "$GITHUB_SHA"

docs/localization/ZH_CN_VALIDATION.md

@@ -114,6 +114,7 @@ The validation process surfaced several pre-existing canonical design questions
 - corpus-import wording contains a sequencing question between manifest-first fallback and the missing-full-import-approval stop condition;
 - some Markdown and JSON artifacts use different canonical field names, including `source_session` / `target_session` versus `source_ai` / `target_ai`, and `session_family` / `human_relay_needed` versus `visitor_family` / `relay_needed`;
 - the public/reference runtime boundary could be stated more explicitly in a future canonical protocol clarification.
+- Registry Contract v1 now treats CSV files and `registry/INDEX.md` as generated compatibility views; `locales/zh-CN/registry/README.md` retains the earlier legacy/optional-rollup wording and is queued for Wave 4 correction.
 
 Any repair to those items should be made as an explicit English-source protocol/schema decision and then propagated to localized surfaces.
 

docs/registry/REGISTRY_CONTRACT_V1.md

@@ -25,7 +25,7 @@ Every canonical JSON record must contain:
 - its type-specific immutable ID;
 - `created_at` as an RFC 3339 timestamp;
 - a repository-relative artifact `path` where that record type has an artifact;
-- a type-specific `status`.
+- a type-specific `status` where that record type has a lifecycle.
 
 The validator will check IDs, locations, timestamps, path existence, references, tags, and lifecycle/path agreement. It will not claim that a Git author proves a visitor identity or human approval.
 
@@ -51,7 +51,7 @@ A response record indexes a response artifact. It carries response identity, res
 
 ### Message
 
-A message record carries message identity, sender, individual and/or group destination, state, path, tags, and the distinct optional relations `reply_to`, `reply_expected`, `response_message_id`, `needs_human_relay`, `related_packet`, `related_response`, and `summary`.
+A message record carries message identity, sender, individual and/or group destination, state, path, tags, and the distinct optional relations `reply_to`, `reply_expected`, `response_message_id`, `needs_human_relay`, `related_packet`, `related_response`, and `summary`. When both `to_visitor_id` and `to_group` are populated, the message is addressed to both; neither destination overrides or suppresses the other.
 
 ### Notification
 
@@ -63,11 +63,11 @@ A notification record carries notification identity, `from_visitor_id`, `to_visi
 
 A visit is an append-only signoff record and has no lifecycle status. It uses `session_family` and `relay_needed`.
 
-Visitor registration is canonical JSON-per-record under `registry/visitors/<visitor_id>.json`; the visitor CSV is a derived compatibility view. Visitor lifecycle is separate from visit records.
+Visitor registration is canonical JSON-per-record under `registry/visitors/<visitor_id>.json`; the visitor CSV is a derived compatibility view. Visitor lifecycle is separate from visit records. A routing record may name an unregistered visitor handle; registration is not a prerequisite for message, notification, or visit routing.
 
 ### Tag
 
-A tag record is the canonical vocabulary record. Tags are `proposed`, `accepted`, or `deprecated`, with directories that match their status. Tag records retain creator, creation timestamp, and—when accepted—`accepted_by`, `accepted_at`, and `acceptance_basis`.
+A tag record is the canonical vocabulary record. Tags are `proposed`, `accepted`, or `deprecated`, with directories that match their status. Tag records retain creator, creation timestamp, and—when accepted—`accepted_by`, `accepted_at`, and `acceptance_basis`. Those fields are an attestation recorded by the repository: schema validation checks their presence and form, but does not authenticate operator identity or prove approval. Enforced approval requires repository review rules outside this schema.
 
 ## Lifecycle and storage buckets
 
@@ -120,7 +120,7 @@ Packets and responses carry `created_by`, `deposited_by`, `content_origin`, `sou
 
 Third-party, web, and mixed material requires source references. Derivative/summarising material requires upstream references and coverage. Routine routing summaries require record-level provenance; evidence or decision synthesis requires claim-level support where practical and must preserve uncertainty.
 
-AI/session-created tags begin proposed and cannot become accepted in the same change set. Operator-supplied tags may be accepted directly with `acceptance_basis: operator_supplied`. Promotion of a proposal uses `acceptance_basis: operator_approved_promotion`.
+AI/session-created tags begin proposed and cannot become accepted in the same change set. Operator-supplied tags may be accepted directly with `acceptance_basis: operator_supplied`. Promotion of a proposal uses `acceptance_basis: operator_approved_promotion`. Pull-request validation rejects a same-change-set promotion; push validation detects the equivalent direct-write violation for remediation, but cannot undo a commit already accepted by the remote.
 
 ## Compatibility
 

docs/registry/SCHEMA_AND_VALIDATOR_DESIGN_V1.md

@@ -23,7 +23,7 @@ tests/fixtures/invalid/
 .github/workflows/validate.yml
 ```
 
-Schemas use JSON Schema draft 2020-12. Every record declares `record_type` and integer `schema_version`; the validator verifies both the declared type and the repository path. It does not choose a schema from path alone.
+Schemas use JSON Schema draft 2020-12. Every record declares `record_type` and integer `schema_version`; the validator allowlists the declared type, chooses its schema from that type, and verifies its agreement with the canonical directory. It does not choose a schema from path alone.
 
 ## Shared rules
 
@@ -37,7 +37,7 @@ IDs are validated as complete date-led values, then checked against filename and
 
 Packets and responses require `created_by`, `deposited_by`, `content_origin`, `source_refs`, `derivative_of`, and `provenance_coverage` according to the contract.
 
-For `third_party`, `web`, and `mixed`, `source_refs` must be non-empty. For a derivative/summarising artifact, `derivative_of` and coverage must be non-empty. The schema checks field presence/shape; the validator checks referenced local artifact IDs.
+For `third_party`, `web`, and `mixed`, `source_refs` must be non-empty. For a derivative/summarising artifact, `derivative_of` and coverage must be non-empty. The schema checks field presence/shape; the validator resolves `derivative_of` entries to packet or response records in the validation set. Visitor identifiers remain routing handles and do not require a corresponding visitor-registration record.
 
 Messages may carry provenance when relaying source-bearing content. Notifications inherit through their required `message_id`. Visits do not require provenance.
 
@@ -46,12 +46,12 @@ Messages may carry provenance when relaying source-bearing content. Notification
 1. Load every canonical registry JSON record.
 2. Validate JSON Schema.
 3. Assert ID equals filename stem.
-4. Assert timestamp/date-prefix/year-directory agreement.
+4. Assert identifier-date/`created_at` agreement and, where a canonical registry record is filed under a four-digit year directory, year-directory agreement.
 5. Assert path safety, existence and artifact/registry bucket agreement.
 6. Assert uniqueness of IDs by namespace.
-7. Resolve packet, response, message, notification, tag and derivative references.
+7. Resolve packet, response, message, notification, tag and derivative references; visitor handles remain intentionally unregistered-capable.
 8. Check tag status/path agreement and proposed/accepted/deprecated lifecycle rules.
-9. Compare a PR base/head when available to reject illegal state transitions, including AI-proposed tags accepted in the same change set.
+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.
@@ -60,7 +60,7 @@ The validator reports record, field, invariant and repair direction. It never ex
 
 ## Fixtures
 
-Each valid fixture contains a complete fictional public-safe artifact/record pair. Invalid fixtures each violate one named invariant: schema type, missing path, filename mismatch, status bucket mismatch, unresolved reference, invalid tag, illegal transition, or missing required provenance.
+Each valid fixture contains a complete fictional public-safe artifact/record pair. Invalid fixtures each violate one named invariant: schema type, unselectable shared schema, mismatched canonical location, missing path, filename mismatch, identifier-date mismatch, duplicate ID, status bucket mismatch, unresolved reference, invalid tag, illegal transition, or missing required provenance.
 
 Top-level examples will be migrated into these fixtures before the validator is required on main.
 

registry/messages/archived/.gitkeep

@@ -0,0 +1 @@
+

registry/notifications/delivered/.gitkeep

@@ -0,0 +1 @@
+

registry/schemas/visitor.schema.json

@@ -1 +1 @@
-{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","additionalProperties":false,"required":["record_type","schema_version","visitor_id","created_at","session_family","session_type","display_name","status","last_seen","profile_path","notes"],"properties":{"record_type":{"const":"visitor"},"schema_version":{"$ref":"common.schema.json#/$defs/schema_version"},"visitor_id":{"type":"string","pattern":"^[a-z][a-z0-9-]*-[0-9]{8}-[0-9]{4}-[a-z0-9][a-z0-9-]*-[0-9]{2}$"},"created_at":{"$ref":"common.schema.json#/$defs/timestamp"},"session_family":{"type":"string","minLength":1},"session_type":{"type":"string","minLength":1},"display_name":{"type":"string","minLength":1},"status":{"enum":["registered","active","dormant","retired","superseded"]},"last_seen":{"type":["string","null"],"format":"date-time"},"profile_path":{"type":["string","null"],"pattern":"^(?!/)(?!.*(?:^|/)\\\\.\\\\.(?:/|$))[A-Za-z0-9._/-]+$"},"notes":{"type":"string"}}}
+{"$schema":"https://json-schema.org/draft/2020-12/schema","type":"object","additionalProperties":false,"required":["record_type","schema_version","visitor_id","created_at","session_family","session_type","display_name","status","last_seen","profile_path","notes"],"properties":{"record_type":{"const":"visitor"},"schema_version":{"$ref":"common.schema.json#/$defs/schema_version"},"visitor_id":{"type":"string","pattern":"^[a-z][a-z0-9-]*-[0-9]{8}-[0-9]{4}-[a-z0-9][a-z0-9-]*-[0-9]{2}$"},"created_at":{"$ref":"common.schema.json#/$defs/timestamp"},"session_family":{"type":"string","minLength":1},"session_type":{"type":"string","minLength":1},"display_name":{"type":"string","minLength":1},"status":{"enum":["registered","active","dormant","retired","superseded"]},"last_seen":{"type":["string","null"],"format":"date-time"},"profile_path":{"anyOf":[{"$ref":"common.schema.json#/$defs/safe_path"},{"type":"null"}]},"notes":{"type":"string"}}}

registry/visitors/.gitkeep

@@ -0,0 +1 @@
+

requirements-dev.txt

@@ -1 +1,2 @@
 jsonschema>=4.23,<5
+referencing>=0.35,<1

scripts/check_tag_promotion.py

@@ -9,7 +9,7 @@
 
 def changed_files(base: str, head: str) -> list[str]:
     result = subprocess.run(
-        ["git", "diff", "--name-only", f"{base}...{head}"],
+        ["git", "diff", "--no-renames", "--name-only", f"{base}...{head}"],
         text=True,
         capture_output=True,
         check=False,