fix(workplan): rescope CUST-WP-0068-T07 — the orphan count rests on a broken field
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

backing_filename is written only by the bindings sync, which fix-consistency
runs before the registrar mints the UUID. Newly registered workplans therefore
record no backing file. Reproduced on CUST-WP-0068 itself.

278 of 800 workplans on central record no backing file, which is what ADR-010
predicted as the "broken links" class. The 23 cache-only orphans were counted
with the same field, so that number is an investigation starting point rather
than a work list.

T07 now repairs the ordering and re-measures before dispositioning anything.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
codex 2026-08-25 15:24:14 +02:00
parent b436c44653
commit 262ac4a6bb

View file

@ -191,26 +191,49 @@ that disposition beats migration.
Acceptance: a ruling recorded as a decision, with the chosen path executed or
explicitly deferred.
## Disposition the 23 orphans
## Repair the binding gap before counting any orphans
```task
id: CUST-WP-0068-T07
status: todo
priority: medium
priority: high
state_hub_task_id: "f44537f2-a738-5f39-b4c1-3711de06632e"
```
Twenty-three records have no backing file, spread thinly across sixteen
repositories — `ground-game` and `reuse-surface` (3 each), `rapp-core-hub`,
`binky-control` and `railiance-fabric` (2 each), then one apiece.
**The orphan count is not trustworthy and must be re-measured first.**
`ADR-010`'s orphan rules apply: broken links where a file exists but was never
recorded are metadata repairs; open hub-first records are `ADR-001` violations
needing a file written or an explicit drop; closed hub-first records may be
retained as provenance where cheap. Do not preserve open records that nothing
can re-derive.
`backing_filename` is written only by `PUT /workplans/index/bindings`, which
`fix-consistency` calls for workplans that already carry a UUID. The documented
registration flow mints the UUID *after* that sync — `fix-consistency` runs,
C-06 skips because the workstation is not the registrar, then
`registrar-reconcile` mints — so a newly registered workplan is left with no
backing file recorded. Reproduced on `CUST-WP-0068` itself: it registered with
`backing_filename: None`, and a second `fix-consistency` run populated it.
Acceptance: every orphan is repaired, given a file, or dropped in writing.
Consequence: **278 of 800 workplans on central (35%) record no backing file**,
including 8 `proposed`, 4 `ready` and 4 `active`. By the read model's own
definition those are hub-only records, and `ADR-010` predicted exactly this as
"broken links — a file exists but `backing_filename` was never recorded …
likely the largest class". The 23 cache-only records classified as orphans were
counted with the same unreliable field, so that number is a starting point for
investigation, not a work list.
Order of work:
1. Fix the ordering so registration binds in one pass — either the registrar
syncs bindings after minting, or the session protocol requires the second
`fix-consistency` run explicitly. The former is preferable; a protocol step
everyone must remember is how this gap opened.
2. Re-sync bindings fleet-wide and re-measure. Also explain
`bindings: synced 63/73` — ten workplans did not bind and the reason is
unknown.
3. 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
explicit drop; closed ones may be retained as provenance where cheap.
Acceptance: registration records a backing file in one pass; the fleet-wide
count of file-less workplans is re-measured and explained; every remaining true
orphan is repaired, given a file, or dropped in writing.
## Converge and retire the cache database