# Two invalidated control runs — 2026-09-13, hertz

doyle's instruction (01:18Z): preserve the contaminated runs as invalidated attempts, with the
surviving process identity and the observed interference recorded.

**Stated first, because it is the part that limits this record: the RAW ARTIFACTS of both attempts
no longer exist.** I deleted them myself — `rm -rf d2/rig-d2/work` and an overwrite of
`all-run.txt` — while restarting, BEFORE the instruction to preserve them arrived. What follows is
what I observed and recorded at the time, not a set of files anyone can re-read. Treat it as
testimony with named identities, not as evidence.

## What happened

| attempt | started | how it ended |
| --- | --- | --- |
| 1 | 18:07:42 local | stopped with `TaskStop` after case C, to apply fixes |
| 2 | 18:12:23 local | stopped with `TaskStop` mid-run, to apply doyle's cleanup ruling |
| 3 (clean) | after both trees were reaped by pid and the post-state asserted | the run the receipt reports |

**`TaskStop` returned success for attempt 1, and attempt 1's bash tree kept running.** That is the
whole mechanism. The surviving runner continued its own case loop, and each case begins with
`rm -rf "$RIG/work/$c"` — so it deleted the per-case directories of the run that had started after
it, while both wrote to the same `all-run.txt`.

## What that produced, and how it read

- `all-run.txt` became a **binary file** to grep: interleaved writes at two independent file offsets
  left a block of NUL bytes, so `grep` reported "Binary file matches" and the case tallies for A–D
  were simply absent from a file that was still being appended to.
- `ls work/` showed **A, F, G** while the live run was on case F: B, C, D and E had been removed
  underneath it.
- Case E therefore reported `NO FINDINGS FILE — the driver produced no evidence dir` and four
  assertion FAILs. **Those four failures are not findings about the driver.** The driver exited 7 as
  designed; its evidence directory had been deleted by another process before the assertions read
  it. Read as driver results they would have been fabricated reds.

## The identities

msys `ps` shows no argv, so the trees were identified by **start time and parent chain**, and each
kill's post-state was asserted rather than announced:

| attempt | pids reaped | evidence they were the right ones |
| --- | --- | --- |
| 1 | `50498` (runner), `55773` (child) | `STIME 18:07:42` and `18:13:09`, parent `50497`; both predate attempt 2's tree |
| 2 | `54910`, `54912` | `STIME 18:12:23/24`, the tree of the second background task |
| 3's own stop | `57385` (`timeout`), `57386`, `57459` | `STIME 18:14:33-39`, the third task's tree |

After each kill: `ps` re-read and the pids confirmed **gone** before the next run started. No
machine-wide kill, no image-name kill, nothing outside the trees I started.

## What changed because of it

1. **Per-run control directories.** The rig now works under a unique per-run directory, so an
   earlier control cannot delete a later run's evidence even if it survives its stop.
2. **`TaskStop` returning is not proof of process-tree termination** (doyle). A stop is followed by
   a `ps` read and, where needed, an explicit pid reap with the post-state asserted — the same rule
   the rigs already carry for the product's own processes
   (memory `watchdog-reports-a-kill-it-never-made`).
3. Neither attempt's numbers appear anywhere in the receipt. The receipted run is attempt 3, run
   after both trees were confirmed gone.

## VOID: L on the successor, attempt of 2026-09-13T03:33Z (RUNSTAMP 20260913T033314Z-16767)

Artifact: `rig-d2/L-VOID-edited-in-flight.txt`. Kept, not deleted.

WHY IT IS VOID, and it is my own defect, not the driver's: I edited `rig-d2/run-d2.sh`
WHILE this run was executing it. Bash reads a running script incrementally, so the runner
read a byte offset into text that had moved underneath it. The artifact carries the proof
in-band — a syntax error naming a fragment of the assertion block

    run-d2.sh: line 556: $'LE 1\n      has   "CLEANUP=PENDING" ...': command not found

and then a SECOND `=== CASE L — driver starting` line inside a run that had already printed
its tally. A tally printed by a runner that was re-entered mid-file is not a measurement of
the subject; the 11/0 it shows is DISCARDED, not carried forward.

Its process tree survived the runner (pids 16762/16767 + children, measured alive after the
output stopped) and was reaped by pid, ancestry checked, before any clean run started — a
survivor here deletes a later run's evidence underneath it.

The rig defect this attempt DID surface is real and was fixed before the clean run: the
step-5 reader matched `write_the_exit_preserved_in_step_3_to:` without its `5. ` prefix, so
it found no path and the leg wrote no `setup.exit`. THE DRIVER'S BEHAVIOUR ON THAT GAP WAS
CORRECT — it reported `SETUP_EXIT_PRESERVED=ABSENT` and said what that costs, rather than
inventing a value — which is the behaviour the successor exists to have.

## VOID BY INSTRUMENT: X, generated-handoff exercise, attempt 1 (RUNSTAMP 20260913T033715Z-19972)

Artifact: `rig-d2/X-VOID-instrument-defect.txt`. Kept. Tally 13 pass / 3 fail.

THE THREE FAILURES ARE MINE, NOT THE DRIVER'S. The harmless stand-in for the elevated setup
command was `cmd /c exit 3`, and msys rewrote the bare `/c` argument into a filesystem path
(`C:/`), so cmd never saw a switch, ignored the rest and returned 0. Both exits then came
back 0, which is precisely the shape the exercise exists to rule out: with equal codes,
preservation cannot be told from coincidence, so the unequal-exit requirement was NOT met
and the three exit arms are UNMEASURED rather than failed-as-found.

WHAT THE ATTEMPT DID ESTABLISH, and it is not discarded — these arms read the real generated
request under real powershell.exe and are unaffected by the stand-in's exit:
  TIMESTAMP_ORDER=OK over six real stamps, with no VIOLATED and no UNMEASURED;
  -RuleName bound as TWO elements, both names correct, by the REAL binder;
  the capture received the setup interval read out of the leg's own two files;
  the request spells the stamp command literally;
  step 7 wrote its own exit file.
They are re-measured on attempt 2 anyway, since the stand-in change re-pins the rig.

Fix: the setup stand-in becomes `powershell.exe -NoLogo -NoProfile -NonInteractive -Command
"exit 3"` — a real tool, invoked in the same form the request names, with no bare-slash
argument for msys to rewrite. The operator line also stopped calling the two codes
"different" unconditionally; it now prints both and says so when they are equal.