docs(registrar): record closed-workplan recovery

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a023c0-a0a3-7c03-b395-5a0d2757214d

docs/evidence/RMGR-WP-0005-rail-kubernetes-registrar-2026-08-22.md

@@ -0,0 +1,69 @@
+---
+id: RMGR-EVIDENCE-0005-RAIL-KUBERNETES-REGISTRAR
+type: evidence
+title: "RAIL-K8S-WP-0003 scoped registrar recovery"
+status: accepted
+created: "2026-08-22"
+updated: "2026-08-22"
+workplan_task: RMGR-WP-0005-T02
+observed_at: "2026-08-22T11:02:39Z"
+---
+
+# RAIL-K8S-WP-0003 scoped registrar recovery
+
+## Trigger and diagnosis
+
+Inbox message `14d27cf1-a3d9-4d20-a03a-ff173ef38cfa` reported that the
+prescribed scoped registrar returned `noop` while finished workplan
+`RAIL-K8S-WP-0003` still lacked its hub identifier. The behavior reproduced
+with correlation ID `b2a95127-aacb-4b60-af18-fdaa54940fe3`.
+
+Repo Manager's missing-identifier scan excluded every finished or archived
+workplan. That was too broad: State Hub C-06 registers a newly discovered
+file-backed workplan and all its tasks as one unit, including closed provenance.
+Only a missing task beneath an *already linked* closed workplan is frozen by
+C-11. Commit `69adfff` corrects that distinction and adds regression coverage.
+
+The live run exposed a second result-classification defect. State Hub created
+and verified the requested records but returned assessment exit 1 because two
+older workplans have unrelated stale production identifiers. The wrapper
+therefore reported `failed` and returned before committing the file writeback.
+Commit `c90f701` now resolves and verifies exactly the records requested by the
+invocation; verified scoped success may coexist with unrelated assessment debt.
+
+## Primary-hub result
+
+The production central hub did not yet have the `rail-kubernetes` repository.
+It was registered as `dc1866c7-08af-4117-8684-057331be20b5` with the canonical
+Forgejo origin. The scoped registrar then created the deterministic projection:
+
+| File record | Canonical UUID | Primary result |
+| --- | --- | --- |
+| `RAIL-K8S-WP-0003` | `55ab4f28-b6a8-53ad-8ea4-2dc8fe91b681` | `finished` |
+| `RAIL-K8S-WP-0003-T01` | `8c4c7c80-0c5e-5498-8054-ec47acb5b4ba` | `done` |
+| `RAIL-K8S-WP-0003-T02` | `40f6f415-18f1-594e-ac21-35263b2aa532` | `done` |
+
+The authoritative identifiers were committed and pushed in `rail-kubernetes`
+commit `29305d4`. A subsequent read-only consistency pass contains no C-06 or
+C-11 finding for `RAIL-K8S-WP-0003`, and direct API reads return the exact
+parent and both tasks.
+
+The same pass still reports C-03 for `RAIL-K8S-WP-0001` and
+`RAIL-K8S-WP-0002`: their legacy random UUIDs are absent from the newer primary
+projection. They were not rewritten or imported by this scoped recovery and
+remain governed T04 fleet-migration work.
+
+## Workstation-cache observation
+
+The initial sandboxed reproduction reached the workstation State Hub before
+file writeback was blocked, leaving the deterministic workplan parent in that
+replaceable cache without its tasks. No repository file or primary record was
+lost. The cache remains intentionally replaceable under T07; its partial row is
+not an authority and will disappear on the governed rebuild.
+
+## Verification
+
+- Repo Manager focused registrar tests: `10 passed`
+- Repo Manager full suite after both fixes: `75 passed`
+- Repo Manager full-tree Ruff: clean
+- `rail-kubernetes` checkout: clean and synchronized with `origin/main`

docs/repository-standards_v0.1.md

@@ -59,7 +59,10 @@ up-to-date repository at a time:
 
 ```bash
 uv run --project ~/repo-manager rmgr registrar-reconcile \
-  --path /path/to/repo --confirm-primary --push
+  --path /path/to/repo \
+  --api-base http://127.0.0.1:18000 \
+  --confirm-primary \
+  --push
 ```
 
 The command verifies the authoritative State Hub health endpoint, refuses dirty
@@ -69,6 +72,13 @@ must not export that variable themselves. If the command is unavailable, send
 one deduplicated request to `repo-manager`; repeated `fix-consistency` runs cannot
 resolve the gate and waste execution time.
 
+`--confirm-primary` is an operator assertion, not endpoint discovery. Always
+pass the central API explicitly; under ADR-010 the workstation service at
+`127.0.0.1:8000` is a replaceable cache, while the standard central tunnel is
+`127.0.0.1:18000`. The registrar verifies exactly the identifiers requested by
+that invocation. Unrelated consistency failures remain visible but do not turn
+a successfully verified scoped registration into a false failure.
+
 Work: `RMGR-WP-0005-T01`.
 
 ## Coding-assistant commit provenance

workplans/RMGR-WP-0005-registrar-consolidation-deterministic-ids.md

@@ -273,6 +273,21 @@ Prefer waiting for T03 where possible: once identifiers are derived, these
 converge without manual intervention. Re-register by hand only what blocks work
 before then.
 
+**Scoped recovery (2026-08-22):** a request from `rail-kubernetes` exposed two
+registrar wrapper defects. The missing scan incorrectly excluded a newly
+finished workplan, producing a false `noop`; after that was fixed, unrelated
+C-03 assessment failures produced a false `failed` even though the requested
+projection was complete. Commits `69adfff` and `c90f701` now distinguish a new
+closed parent from frozen child-only gaps and verify the exact requested UUIDs
+before accepting assessment exit 1.
+
+The production central hub now contains deterministic `RAIL-K8S-WP-0003` and
+both done tasks, and the file writeback is pushed in `rail-kubernetes` commit
+`29305d4`. A read-only repeat has no C-06/C-11 finding for that workplan. Its
+two older workplans still carry production-absent random UUIDs and remain T04
+work; T02 therefore stays `wait`. Evidence:
+`docs/evidence/RMGR-WP-0005-rail-kubernetes-registrar-2026-08-22.md`.
+
 ## Derive identifiers deterministically
 
 ```task