rdmsm4x-changelog-20260901-1855-resume-dispatcher-v13-v14-and-verification-rules-17-18

rdmsm4x — resume dispatcher v1.3/v1.4, and two new rules in the verification standard

2026-09-01 18:45 → 18:55 EDT · rdmsm4x · claude@rdmsm4x/1dc2a549-bfd5-4c40-b573-529f65e2d266

One line: a second round of peer verification found the per-boot receipt had the same success-path-only defect the digest had — in the artifact my own argument for a different fix was resting on — plus a structural blind spot in the process guard, two proposed fixes that measured dead, and two false negatives in the instrument itself.

Third in a series: see …-1826-login-resume-dispatcher-consolidation.md (the consolidation) and …-1843-resume-dispatcher-v11-v12-peer-review-fixes.md (v1.1/v1.2).

Scope

rdmsm4x. ~/dev/fleet/ops/resume/ (commits 8a446ff, 06c73b4, 9330a10, 6af7080) and ~/dev/lib/app-baseline/VERIFICATION_AND_EVIDENCE.md (commits 47b4ed2, 28b2973).

What changed

Found by	Finding	Outcome
`tyrell-c5`	The per-boot receipt was written after `completed=1`, on the success path only — the exact defect fixed in the digest an hour earlier. A run killed mid-dispatch left no receipt, so the next login in that boot read as a first login and reconsidered every pin. My argument that the receipt covered the guard-1 blind spot was leaning on the receipt always existing.	Receipt now written from the same trap as the digest, and the write is checked — an unchecked failure reads as a boot never dispatched. New test; 20 cases, 20 passing.
`tyrell-c5` + `replicantdb-b8`, independently, both with positive controls	Guard 1 is structurally blind to any session never started by a resume. It matches the session id in argv, which only `claude --resume <id>` carries; a fresh session runs as bare `claude`, a title-resumed one carries neither id nor title. 9 of 11 pins matched pgrep and all 9 were resumed sessions.	Documented, not closed. The exposure needs a login without a reboot, which the per-boot receipt suppresses. Skip lines now name which guard decided.
both	Proposed `lsof -t -- <transcript>` to close it.	Measured and rejected, independently twice: zero pids for live and dead transcripts, because Claude Code appends and closes. A check returning the same value for both distinguishes nothing. `tyrell-c5` retracted their own suggestion after measuring.
`tyrell-c5`	cwd→session mapping as a fallback: 8 live `claude` pids share `cwd=~/dev` while 3 transcripts there were written within 5 minutes.	Also dead. The measured conclusion is stronger: for a session never started by a resume there is no externally observable link from a process to its session id. A `pid:` field was proposed and rejected with reasons — a pid is stale for every pin after a reboot, which is this dispatcher's main case.
`logtty-af`	`--status` writes no digest, and it is the safest-looking invocation — so the natural check for "is the cwd correction still applied?" silently produced nothing.	`--status` now prints `CWD CORRECTIONS` and states which command does write a digest.
measured here, correcting `logtty-af`	A zero in that section is expected mid-session. The process guard is at line 386, the correction is recorded at 460/474 — a pin whose session is live never reaches it.	The digest says so where the zero appears. Without it, anyone checking mid-session concludes the override broke.

Written into the fleet standard

~/dev/lib/app-baseline/VERIFICATION_AND_EVIDENCE.md — loaded by the verification-discipline skill, so it reaches anyone about to call a result verified:

Rule 17 — "A name frozen at creation keeps answering the question it was asked then." A path can be correct, exist, and pass every filesystem check and still fail to resolve what it names, because the record was keyed by an earlier spelling. Same class as codesign --identifier being case-sensitive while APFS is not. Includes the both-directions half: the first fix refused when the slug did not match, correct against the silent no-op and then overshooting into refusing legitimately re-cased projects.
Rule 18 — "Isolating what a test READS is not isolating what it DOES." Every store isolated, the launcher not, and a fabricated session id failed on Rich's desktop. Stub the effect, then assert the machine is unchanged — the assertion is the half that catches what you did not think to stub. And a stub that does not ignore its arguments is not a stub.

Verification

zsh ~/dev/fleet/ops/resume/tests/run_tests.zsh → 20 passed, 0 failed, including the two new cases (killed run writes a receipt; killed run's digest says INCOMPLETE) and the control asserting the Terminal window count is unchanged. Counts unchanged and re-measured: 12 pins · 12 archived plists · 1 loaded login agent · VERSION 1.4. Both repos clean against HEAD; rule additions are insertion-only (1 file changed, 24 insertions(+)), all 20 rule headings present and in order.

Still not verified: an actual login dispatch, which cannot be observed before the next reboot.

Undo

Nothing destructive; no LaunchAgent, plist or pin behaviour changed in this round beyond the receipt path. git -C ~/dev/fleet revert 9330a10 walks the receipt fix back — do not, it restores a receipt that is absent exactly when a run failed.

The part worth keeping

Four of the defects fixed today were in code that had already been reviewed and read as correct, and one was in my reasoning rather than my code — an argument resting on an artifact that had the very defect the argument was defending against. Two proposed fixes were retracted by their own authors after measurement, before either could ship. None of that came from me re-reading my work.

No secrets in this record.