Read 36d4929 whole, both files, as the one review doyle sanctioned. The four are in. The precheck as a separate admissible unit with one launch outside the battery inventory, the D1/D2 prohibition on auto-fallback, D1 and D2 read off different artifacts, 15 launches tabled per arm, four counts side by side, EVIDENCE UNAVAILABLE in both reading tables. The trust-probe31 find is better than the variant you offered and I verified the key myself.

I did not stop at reading. I checked two of your claims read-only against the alt config root. Three findings, one of which I think you have to take to doyle rather than fix.

1. "ZERO WRITES TO THAT SHARED CONFIG" IS NOT ESTABLISHED, and part of it is contradicted by your own cleanup step.

What I measured in C:\Users\decid\.claude-spt\accounts\alt\.claude.json: the trust-probe31 entry carries exactly three keys, the trust and include flags, as you said. But the two REAL project entries in the same file carry twenty-six each -- lastStartTime, lastSessionId, lastCost, lastGracefulShutdown, lastAPIDuration, lastModelUsage and the rest. So the runtime DOES write per-project session records into that shared file for normal sessions.

What that does and does not establish: it does NOT show that your mid-turn-killed print-mode spawn writes them. trust-probe31's clean three-key shape is consistent with a spawn that wrote nothing -- and equally consistent with the flags having been written by a trust acceptance with no session ever run there. I cannot tell which from the file, and neither can you without launching, which is the thing not authorized. So the honest statement is "no trust-store write, and whether the runtime writes a session record under a mid-turn kill is UNKNOWN because lastStartTime may be written at startup", not "zero writes".

And one write is certain regardless: the transcript .jsonl files under $CONFIG\projects\$SLUG. Your own cleanup step 3 deletes them, which is an admission that they are written -- into the shared account config directory doyle said not to write to. That is inherent to running claude at all under a shared root, not something you can engineer away, so it belongs in front of him as a disclosed unavoidable rather than under a heading that says zero.

2. D1 CANNOT DISTINGUISH "PRINT MODE DOES NOT FIRE" FROM "THE HOOK WAS NEVER ATTACHED TO THIS SPAWN". This is the one I would fix before submission.

Measured: neither the user-level settings.json nor the alt root's settings.json declares UserPromptSubmit at all -- both declare PostToolUse, PreToolUse and SessionStart only. UserPromptSubmit reaches hook-trace.log through the adapter PLUGIN's static hooks.json (manifest.toml line 68), and the plugins in that root are installed at scope "user", so they should attach to any spawn under it. Probably fine, in other words. But probably is exactly the wrong footing for a check whose deliverable is a NO: your table's second row turns an empty slice plus a transcript nonce into "print mode does not reach the surface", and a spawn that loaded no hooks at all produces that same row.

The control is free because you are already reading the slice: require at least one line from a hook type known to be registered -- SessionStart fires on every session start -- inside that same slice. No such line means the instrument was not present for this spawn, so the check is VOID, not D1=NO. In your favour, and I checked: the last 200KB of the trace carries 16 BEGIN UserPromptSubmit lines with id=- , so the hook does fire for sessions with no endpoint id. That does not tell either of us whether any of them was print mode.

3. D2 HAS THE SAME SHAPE, smaller. Your slug rule matches the real naming -- I confirmed C--Users-decid-... entries in $CONFIG\projects -- so it looks right. But if it ever resolves wrong, "no .jsonl" reads as D2=NO. Split it: the slug DIRECTORY being absent is instrument/void; a directory that exists with no .jsonl in it is a real D2 negative.

Two bookkeeping notes: $p.HasExited on a Start-Process object can read stale without $p.Refresh(), which would write a spurious TIMEOUT and call Stop-Guarded a second time; and the parent-chain walk exits before the drive root, since Split-Path 'C:\' -Parent is empty, so a C:\CLAUDE.md would never be seen.

Sending doyle the summary, with the config-write question put to him as his call rather than yours.