ledger(CCV1-023/-009): attribute the post-reap refusal to the ADAPTER fence, and pin it (c0e) - #87
Conversation
1e2bb57 to
f6f2116
Compare
Manager status — rebased and partially verified; held draft on one unresolved gate.Rebased cleanly onto current Verified:
Not verified, and the reason I am not merging: on my scratch clone the Everything I actually measured is green, and the lane's own run says the module tier passed. But "probably environmental" is not a gate, and this PR touches that exact fixture — so it waits for a clean answer rather than a plausible one. To land it: re-run Context on how this PR came to existThis is recovered work, not a fresh lane. What it settles is worth keeping: PR #71 removed CCV1-023's measurably-false note ("passes via the session latch") without replacing it, leaving the ledger silent on why its own flagship custody fixture passes. This attributes it to the adapter fence and pins it with a test. |
f6f2116 to
8d777c2
Compare
… fence, and pin it CCV1-023's seeded note said the fixture that model_performance-c0e was filed for 'asserts the TOOL-layer refusal (which passes via the session latch)'. That sentence was removed wholesale by PR #71 when the row flipped CONFORMS, but was never replaced by the right answer -- so the ledger has been silent on WHY its own flagship custody fixture passes. Measured, one mechanism at a time, against real bd + an isolated dolt server: * delete the adapter's custody-identity fence (PR #68, b3fac1e) and test_explicit_resolve_refusal_after_reap_clears_held_and_allows_new_claim fails at 'assert resolved.success is False' -- the close LANDS. The session latch is what lets it through. * delete the tool layer's 'except A.FencedError' latch-clearing (PR #3, 69b717e) and the refusal still happens, but the fixture fails at 'assert session._held is None'. So two mechanisms at two layers, and the session latch is neither. Pinned executably rather than left as prose: test_post_reap_refusal_originates_below_the_session_latch asserts the latch still names the item at the moment of the refused call, that the ADAPTER refuses with no session in the picture, that the surfaced wording is the fence's and not the latch's, and that an integrator's close of the same unheld item still succeeds. Its own discrimination measured three ways (fence removed -> DID NOT RAISE; refusal re-sourced to the latch -> wording red; fence re-keyed on 'unheld' instead of identity -> integrator half red). test_row_ccv1_009 gained a part 4 so the ledger notices if that pin is deleted. CCV1-009 re-assessed: stays CONFORMS, both halves RUN this time rather than probed for existence. assertion.kind deliberately unchanged. STALE-NOTE AUDIT of every CCV1 row (the item asked for it explicitly) found four more, all corrected here, none a disposition change: * CCV1-002 said reclaim_eligible has 'exactly two routes'; PR #76 added a third, and the source docstring has said 'three, and only three' since. Two path-2 cites added so the row covers the mechanism it describes. * CCV1-003, CCV1-004, CCV1-010 each defer their indexed upgrade on 'that suite runs in nothing (CCV1-022)'. CCV1-022 went green in PR #68. * CCV1-017 said Fixture 4 'does not exist in ANY suite'; CCV1-023 flipped CONFORMS on the file that contains it. ledger/reconcile-report.md carries the same claims and is deliberately NOT touched: it is a dated, self-declared superseded snapshot.
Recovered by the manager after the lane was killed mid-flight by an external tmux-server restart (model_performance-ye80). The lane had already finished: tiers-summary.txt records cli rc=0, ledger rc=0, module rc=0, ALLDONE. Only the push and the DONE.json marker were lost.
8d777c2 to
130e419
Compare
1 participant
Lane
c0e-ccv1-023-ledger-note, $0.Recovered by the manager after an external kill. The lane was terminated mid-flight when the shared tmux server on socket
hwwas restarted (model_performance-ye80), taking down three lanes and the watchdog at once. It had already finished the work:tiers-summary.txtrecords cli rc=0, ledger rc=0, module rc=0, ALLDONE. Only the push and the DONE.json marker were lost, so this is its work published, not re-run.What it settles
model_performance-c0ewas filed for a failing fixture. The manager measured that the code half was already fixed by PR #68 — the named test passes on main both before (9d61e42) and after (46d7da4) oy4's #76 — so the item was narrowed to its untouched second half: the ledger note that misattributes WHY the fixture passes.CCV1-023's seeded note claimed the fixture "asserts the TOOL-layer refusal (which passes via the session latch)". That was measurably false when filed — the session latch was what let the call through. PR #71 then removed the sentence wholesale when the row flipped CONFORMS, but never replaced it with the right answer — so the ledger has been silent on why its own flagship custody fixture passes.
This attributes it to the adapter fence and pins it.
Why it matters
A conformance ledger that cannot say why its own fixture passes is worse than one that says nothing: the next reader trusts the note and reasons from a mechanism that was never the one operating.
Draft pending manager verification.