coulomb/repo-manager
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
repo-manager/docs/evidence/RMGR-WP-0005-rail-kubernetes-registrar-2026-08-22.md
tegwick fa1f272ea4 docs(registrar): record closed-workplan recovery 
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a023c0-a0a3-7c03-b395-5a0d2757214d
2026-08-22 13:03:33 +02:00

3.1 KiB
Raw Blame History

id type title status created updated workplan_task observed_at
RMGR-EVIDENCE-0005-RAIL-KUBERNETES-REGISTRAR evidence RAIL-K8S-WP-0003 scoped registrar recovery accepted 2026-08-22 2026-08-22 RMGR-WP-0005-T02 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