Filed unassigned by the batch-8 dev of #12981 (session session_016ZC5rNQj3WEet5HAmmAkMs), out of a measurement taken this round. Recording, not claiming.
The observation
scripts/measure-durability-swallow-family.mjs prints its tier-1 bucket under the heading "[1] DARK members, by file — the repair worklist". On origin/main@add6a1b1c that bucket holds 5 rows. Four of the five are settled determinations, not outstanding repairs:
auth-manager.ts census FALSE MEMBER — batch 6 determination
ensure-default-organization.ts fence lifted (PR #13685 merged); not an outstanding repair
runtime/src/domains/keys.ts closed by its own in-file [#12981] annotation
verify/src/harness.ts determined NOT a claim-to-persist (batch 8) — annotated in-file
share-link-service.ts the ONE outstanding repair
The instrument cannot see any of that. Membership is decided on three mechanical conjuncts — silent catch, no rethrow, an awaited write in the try — and a comment is trivia to the AST. So an annotation, which is the programme's own chosen way of recording a determination, cannot move a site out of DARK.
Measured, both directions
- Writing the batch-8 annotation into
packages/verify/src/harness.ts left the census output byte-identical: MEMBERS 56/37, DARK 5/5, carries-error 24/19, channelled 27/14, QUIET 98 — before and after, diff exit 0. The base tree was restored under a trap and re-run to take the before-reading, so this is a measurement rather than an inference.
packages/runtime/src/domains/keys.ts is the standing proof: it has carried its [#12981] determination for several rounds and is still listed in "the repair worklist" on every run.
Why it costs real time
The determinations exist precisely so the next reader does not re-derive them, and in-file they work — batch 7 read keys.ts's annotation and correctly did nothing. But the count is what a dispatcher reads first, and it says 5. Two rounds have now been spent on that gap: batch 7 had to open keys.ts to discover it was already settled, and batch 8 existed to re-derive two more sites the previous batch had already read as "probably not".
The heading is the specific defect. "5 site(s) in 5 file(s) — the repair worklist" is a true statement about membership and a false one about work, and nothing in the output distinguishes them.
Not proposing the fix, but naming the shape it would have to hold
A DETERMINED register in the instrument, keyed file::function the way the gate's FAILURE_PROPAGATION_SITES is (never by line — line numbers churn), cross-checked against the in-file annotation so that a register row whose file no longer carries the annotation reds as STALE rather than silently excusing a site. That keeps the census's over-collection intact — the site stays a MEMBER — while letting the printed worklist mean what its heading says.
⚠️ Two reasons this was not done inside batch 8 rather than filed:
- The census is the shared measurement device of an in-flight programme. Changing what it prints mid-programme moves every seat's readings, including the ones already recorded in this card's accepted reports. That is a PM call, not a dev's.
- The programme's own last step (widening
DURABILITY_CRITICAL_CALLEES and declaring keys.ts::handleKeysRequest) touches the same register question from the gate's side. If both land, they should land together or in a deliberate order.
Refs
#12981 (the programme and the instrument) · #13785 (a different, already-filed defect in the same instrument — its scope resolver) · the batch-8 report on #12981 for the census readings quoted above.
Generated by Claude Code
Generated by Claude Code
Filed unassigned by the batch-8 dev of #12981 (session
session_016ZC5rNQj3WEet5HAmmAkMs), out of a measurement taken this round. Recording, not claiming.The observation
scripts/measure-durability-swallow-family.mjsprints its tier-1 bucket under the heading "[1] DARK members, by file — the repair worklist". Onorigin/main@add6a1b1cthat bucket holds 5 rows. Four of the five are settled determinations, not outstanding repairs:The instrument cannot see any of that. Membership is decided on three mechanical conjuncts — silent catch, no rethrow, an awaited write in the
try— and a comment is trivia to the AST. So an annotation, which is the programme's own chosen way of recording a determination, cannot move a site out of DARK.Measured, both directions
packages/verify/src/harness.tsleft the census output byte-identical: MEMBERS 56/37, DARK 5/5, carries-error 24/19, channelled 27/14, QUIET 98 — before and after,diffexit 0. The base tree was restored under a trap and re-run to take the before-reading, so this is a measurement rather than an inference.packages/runtime/src/domains/keys.tsis the standing proof: it has carried its[#12981]determination for several rounds and is still listed in "the repair worklist" on every run.Why it costs real time
The determinations exist precisely so the next reader does not re-derive them, and in-file they work — batch 7 read
keys.ts's annotation and correctly did nothing. But the count is what a dispatcher reads first, and it says 5. Two rounds have now been spent on that gap: batch 7 had to openkeys.tsto discover it was already settled, and batch 8 existed to re-derive two more sites the previous batch had already read as "probably not".The heading is the specific defect. "5 site(s) in 5 file(s) — the repair worklist" is a true statement about membership and a false one about work, and nothing in the output distinguishes them.
Not proposing the fix, but naming the shape it would have to hold
A
DETERMINEDregister in the instrument, keyedfile::functionthe way the gate'sFAILURE_PROPAGATION_SITESis (never by line — line numbers churn), cross-checked against the in-file annotation so that a register row whose file no longer carries the annotation reds as STALE rather than silently excusing a site. That keeps the census's over-collection intact — the site stays a MEMBER — while letting the printed worklist mean what its heading says.DURABILITY_CRITICAL_CALLEESand declaringkeys.ts::handleKeysRequest) touches the same register question from the gate's side. If both land, they should land together or in a deliberate order.Refs
#12981 (the programme and the instrument) · #13785 (a different, already-filed defect in the same instrument — its scope resolver) · the batch-8 report on #12981 for the census readings quoted above.
Generated by Claude Code
Generated by Claude Code