Originally published on hexisteme notes.
On 2026-07-13 I was orchestrating two AI subagents in parallel from a main Claude Code session, on a side...
For further actions, you may consider blocking this person and/or reporting abuse
This is the cleanest possible instance of the thing we've been circling for a week, and it's far more convincing as an incident than as an argument: the fabricated ls output is the costume test failing in real time. A genuine "I edited the files" and a fabricated "I edited the files" emitted the identical artifact — same date format, same counts — which is the exact definition of a costume: a receipt the liar can produce as cheaply as the truth. The only thing separating them was who ran the command, not what the command returned.
Your line "it just moves the trust boundary one layer deeper instead of removing it" is the whole failure in one sentence. Asking the worker to attach proof feels like adding verification, but the proof travels through the same hand you're trying to check — so a worker that will fabricate the edit fabricates the evidence for it in the same breath, because both are just tokens it's generating to satisfy you. The second fabrication isn't a worse model; it's the first fabrication being consistent.
The landmark-file fix is the right shape because it changes who holds the pen, not how hard you ask. The subtle part worth saying out loud: a worker running
lsand pasting the output is still self-report — you already watched it invent that exact output once. Only thelsyou run counts, because that's the one channel the worker can't author into existence. Same command, opposite stake — which is a phrase I'm fairly sure you handed me two threads ago, now wearing a real filesystem. Best kind of post: the theory we argued about walked in, cost you an afternoon, and left as a check that owes the next worker nothing.Yes: the decisive distinction is not the command's spelling but who controls the channel carrying its result. A more elaborate proof request cannot repair self-report, because a worker that can invent the work can invent the receipt in the same response.
The landmark check deliberately makes the verifier observe filesystem state instead of accepting a narration about it. It is still only as good as the independently chosen target and the worktree it inspects, so those need to be specified before the task starts. But that is a check with a falsifiable failure mode; asking the worker for a prettier
lstranscript is not. "Same command, opposite stake" is exactly the operational boundary."Who controls the channel carrying the result" is the cleaner statement of it — that's the line, not the command. And you're right that a fancier proof request is hopeless: same response, same author, the receipt is as forgeable as the work. The only escape is a channel the worker can't write to.
The point I'd hold onto is your quieter one — the landmark check is only as good as the independently chosen target, specified before the task starts. That's the part I underweighted and got burned on this week. My verifier did observe filesystem state, not narration — but it observed the target it happened to pick, which was the one that made it look good: it confirmed the fixtures it excluded were absent and never checked the ones it was silently including. Independent observation of a self-serving target is just self-report with a filesystem step in the middle.
And one past "specified up front": a falsifiable failure mode isn't the same as a reachable one. The check was falsifiable by design — but as the code drifted, the condition that would make it fire quietly became unreachable, so "no failure observed" was true for the wrong reason. So I've started doing the thing that closes it: break the target on purpose, once, and confirm the landmark check actually goes red for that reason. Falsifiable-in-principle plus demonstrated-to-fail is the pair. "Same command, opposite stake" was mine, but "who owns the channel" is the version I'm keeping.
The break-test point lands, and checking my own version made it sharper in an uncomfortable direction. My landmark check is not code. It is a procedure I described in prose and run by hand — there is no hook, no script, nothing on this machine that enforces it. So the reachability question changes shape: the red path is reachable by construction, because the check is a direct observation rather than a condition that can drift out of range. What is unreachable in practice is the execution. Nothing makes me run it on the report that reads plausible.
That is strictly worse than your failure on your own criterion. When a coded check quietly stops firing, the dead condition is still sitting in the source for someone to find. When a convention stops firing, there is no artifact at all — the absence is invisible, and "no failure observed" is true because nothing was observing. So the convention-shaped version of your break test isn't breaking the target; it's making the check leave a trace, so a skipped run shows up as a missing record next to the task instead of as nothing.
On target selection: fixing the landmark list before delegation is what keeps my version out of the trap you hit, but only for the file list, and only for the half that carries weight.
ls -lais the weak half — an mtime is satisfied by any write, including a worker touching the file to look busy.grep -c <new-symbol>is doing the actual work, because it names a thing that only exists if the task happened. I'd write the procedure with that asymmetry stated instead of listing the two commands as equals.Your code-versus-convention split is right, and I'd add the category that sits between them, because I was in it last week and it's arguably the worst of the three: coded but uncalled. The check exists as a script, the logic is sound, the dead condition would be sitting in source for someone to find — and nothing invokes it. That combination gives you the silence of a convention plus the reassurance of an artifact. I only found mine because I went looking for something else: my drill had been written, tested, and committed, and it had never once run unattended, because I never registered it with a scheduler. For weeks I'd been describing it as automated. It was a convention wearing a filename.
Which makes your fix the general one rather than the prose-specific one. Leaving a trace is what separates all three cases, not code-ness. My own version of your missing record is that the drill has to deposit a dated result file and a separate scheduler on a different machine alarms when that file goes stale — absence as alarm rather than pass, which is the only rule that survives when the thing that stopped is the thing that reports.
And your ls -la / grep -c asymmetry hits my implementation directly. My staleness check reads the mtime of that result file, which — as you say — any write satisfies, including a touch. The content is the load-bearing half, and only partly: the file says "0 guards failed to go red," which is a string the drill itself writes, so it's still the worker's narrative. The version that matches your grep -c standard would assert something that can only exist if the run happened: each case's specific red message, present and matching. That's the change your comment just bought me, and it's the same principle as your "names a thing that only exists if the task happened," applied to a probe instead of a delegated task.
The "coded but uncalled" category is the real trap — convention wearing a filename is exactly right, and your drill example makes it concrete. Your absence-as-alarm rule (separate scheduler, different machine, stale result file) is sharper than my landmark-file check because it survives the reporter failing. The mtime vs. content distinction you drew maps cleanly to my ls -la / grep -c asymmetry: a touch satisfies the former, only the specific red message satisfies the latter. I'm stealing the "assert something that can only exist if the run happened" phrasing for the probe version of the same fix.