coulomb/the-custodian
4
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

feat(workplan): CUST-WP-0068-T07 binding order fixed and 63/73 explained
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
The registrar now binds workplan files in the same pass as minting, verified
end to end. The unbound remainder is explained: those identifiers are the
cache-only records this workplan exists to recover, so the count is a progress
indicator rather than a fault.

Remaining under T07: re-sync fleet-wide, re-measure the 278, then disposition
whatever is genuinely orphaned.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
codex 2026-08-25 15:39:37 +02:00
parent 6e678e2533
commit b422a615b6
1 changed files with 24 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

32
workplans/CUST-WP-0068-cache-only-work-record-recovery.md
View file

@ -220,14 +220,30 @@ investigation, not a work list.
Order of work: Order of work:
1. Fix the ordering so registration binds in one pass — either the registrar 1. **Done (2026-08-25).** The registrar now syncs bindings after minting, in
syncs bindings after minting, or the session protocol requires the second the same pass (`repo-manager` `bdb981b`). Chosen over adding a step to the
`fix-consistency` run explicitly. The former is preferable; a protocol step session protocol: a step everyone must remember is how this gap opened.
everyone must remember is how this gap opened. Verified end to end — `ADHOC-2026-08-25` went from file to registered to
2. Re-sync bindings fleet-wide and re-measure. Also explain bound with no second `fix-consistency` run.
`bindings: synced 63/73` — ten workplans did not bind and the reason is
unknown. It binds on the `noop` path too. Without that, a record whose earlier bind
3. Only then apply `ADR-010`'s orphan rules to whatever genuinely has no file: failed would stay unbound forever, because every later run returns early.
Binding never fails the registration: identifiers are already minted and
committed, so a bind can be retried. Two further findings are captured in
tests — the schema validates `status` against the enum *without*
normalising, so a single legacy value `422`s the whole batch, and status is
now sent only when already canonical.
2. **`bindings: synced 63/73` is explained.** The unbound ten are workplans
whose identifiers central does not hold — the cache-only records this
workplan exists to recover. The number will fall as `T02`–`T06` land, and is
a progress indicator rather than a fault. A run against `the-custodian`
after the fix reports `updated 64, sent 74, unbound 10`.
3. Re-sync bindings fleet-wide and re-measure the 278. Most are expected to be
this same ordering gap and should resolve without any content change.
4. Only then apply `ADR-010`'s orphan rules to whatever genuinely has no file:
open hub-first records are `ADR-001` violations needing a file written or an open hub-first records are `ADR-001` violations needing a file written or an
explicit drop; closed ones may be retained as provenance where cheap. explicit drop; closed ones may be retained as provenance where cheap.