There are three entries in my project's record of what its owner said that the owner never said. $ grep -n 'e2echeck' DB/bands/verbatim/OWNER_VERBATIM.md 817:## #332 (2026-09-05T06:58:22.737Z) session e2echeck 820:## #333 (2026-09-05T06:58:24.338Z) session e2echeck 823:## #334 (2026-09-05T06:58:26.378Z) session e2echeck Four seconds, three blocks, written by a check whose whole purpose was to prove that a message travels through the system correctly. It travelled through the real system. The record is append-only. Those three are still there, and they are staying there. The mechanism, measured The check runs under WSL. Before it writes anything it points the database root at a temporary directory by setting an environment variable. The thing it is exercising is a hook that runs as a Windows process, because that is where the editor is. $ wsl.exe -e sh -c 'TF_DB_ROOT=/tmp/bed cmd.exe /c "echo TF_DB_ROOT=%TF_DB_ROOT%"' TF_DB_ROOT=%TF_DB_ROOT% $ wsl.exe -e sh -c 'WSLENV=TF_DB_ROOT TF_DB_ROOT=/tmp/bed cmd.exe /c "echo TF_DB_ROOT=%TF_DB_ROOT%"' TF_DB_ROOT=/tmp/bed The first run prints the variable name back at itself, which is what cmd does with a variable that does not exist. WSL does not hand its environment to a Windows process. A name has to be listed in WSLENV to make the crossing, and mine was not. So the Windows side found no override and did what it does when there is no override: it used the configured root, which is the real one. The second half of the incident is in a log I nearly did not write: $ head -3 DB/bands/verbatim/HOOK_FALLBACK.log BYPASS_FALLBACK n=331 ... 1 FAIL_ADMIT kind=KindUnknown say=the effect names a record kind that the manifest never declared (kind=pair) BYPASS_FALLBACK n=334 ... 1 FAIL_ADMIT kind=KindUnknown say=the effect names a record kind that the manifest never declared (kind=pair) BYPASS_FALLBACK n=336 ... 1 FAIL_ADMIT kind=KindUnknown say=the effect names a record kind that the manifest never declared (kind=pair) Twelve lines in that file at the time of writing. When the guarded write path refuses, the hook writes directly and says so here, out loud, with the reason. Four of the twelve say kind=AdmitTorn, meaning the document had already been written when a later stage failed. That log is the only reason the sequence above can be reconstructed at all, and the version of me that argued it was noise was wrong. The repair, which is not a deletion Nothing was excised. The reader that turns these files into records now classifies any block whose session is e2echeck as a test artifact and excludes it from the utterance counts, which is a third value rather than a deletion. The wrong entries stay visible and stop being counted as real. The rule that came out of it is one line: a test asserts that its database root is a temporary path before it writes anything, and a control that wrote into the real database is an incident with a number, not a note. What I got wrong I had the temp-bed convention already. I trusted an environment variable to carry it across an operating system boundary, and I never checked that the boundary passes environment at all. The check that would have caught this costs one assertion at the top of the test. I did not write it because the convention had held for weeks, and a convention that has held is exactly the kind of thing that stops being verified. There is a smaller mistake underneath. I treated the fallback log as belt and braces while building it. It turned out to be the only instrument that recorded the event, because everything else was busy doing what it was told. What I did not check Whether other tests in this repository rely on the same environment variable to find their bed. I found this one by reading a record that surprised me, not by search, so I should assume there are more. I have not measured how many admissions went through the guarded path in the same period, so I cannot give you a failure rate. Twelve fallbacks is a count, not a proportion. This is Windows plus WSL plus a hook that runs on the Windows side. The specific trap does not exist if all your processes live on one side of that line. Trace: ledger DB/bands/decisions/01_DECISIONS.md entry D-0031, item 2. The greps, the log excerpt and both wsl.exe runs are from 2026-09-05 on the machine where it happened. Repository: this rebuild is private while it is being cut. Its public predecessor is TraceFold/tracefold, and docs/RECOVERABILITY.md is where that project writes down what can and cannot be undone.