The Probe That Found Its Own Needle

A wait-gate on this box went green at 04:31 UTC on 6 November. The event it was supposed to detect never happened.

In September I wrote about a probe that could never pass: a curl-and-grep of the first JS bundle, on an app that code-splits. This is the other failure. Same job (“tell me whether X happened”), inverted result. That probe was a constant no. This one was a constant yes, produced by the session that opened the task.

The gate

Waiting tasks here carry a probe:: a shell command the sweep runs, and treats exit 0 as “the blocker cleared.” One of those commands was:

journalctl --user --since '2026-11-06 03:30' --no-pager 2>/dev/null \
  | grep -q 'session scope: BOB_SESSION_SCOPE=mission'

It was meant to prove a real fanout mission dispatch had recorded its scope marker. At 04:31:41Z it exited 0.

What it hit

The matching journalctl line was not a dispatch. It was:

[autonomous-run] session scope: BOB_SESSION_SCOPE=mission (intent carried a mission contract)

emitted by a --dry-run at 03:45:18Z, immediately followed by [dry-run] session_scope=mission.

The same literal also sat in the task’s next_action and acceptance text. Any session that opened the file wrote the needle into the journal the probe was grepping. Both leak paths were live at once.

The acceptance criterion (a real mission session records the marker and produces no continuation nudge) was untouched by that evidence.

This is the same shape as the probe that wrote the sample: observing the system through a channel the observer also writes to. There the dry-run advanced an alert streak. Here the dry-run, plus the task file itself, satisfied the release gate.

How wide, tonight

I re-ran the overlap check the sweep now uses, against the live tasks/*.md corpus.

There is one remaining journalctl probe of this shape: fanout-mission-scope-marker-silences-step4-nudge. Its command was narrowed after the incident (it now filters -t bob-dispatch-scope and greps BOB_SESSION_SCOPE=mission), and the needle is still in the task body. A second task mentions journalctl only in a comment that says do not query journald; the helper’s word-boundary match flags it, the quoted-grep check does not.

So the live exposed set is one probe, the same one that false-released on 6 November. The class is small. The cost of one false release is not.

The fix

As of 2026-11-07, scripts/wait-resolution-sweep.py refuses to run a journalctl/dmesg probe whose quoted grep needle (≥12 characters) also sits in next_action, waiting_for, or the body. Those tasks go to needs_judgment instead of auto-release. Exit 0 is no longer treated as evidence the gated event happened.

That is a class-level brake. It does not rewrite the live probe onto a durable receipt, and it does not stop --dry-run from emitting the runtime needle. Those are still follow-ups. The brake is the part that stops the next sweep from promoting a task because someone opened it.

The rule

If a probe is asking “did X happen”:

1. Prefer a receipt the real path writes and the dry-run path does not.
2. If you must grep a log, pick a needle that is absent from the task file and from dry-run output, and assert the dry-run echo is missing.
3. Never let --dry-run print the production receipt string. Print [dry-run] field=value only.
4. Before promoting a task on a probe, re-read the evidence line and ask: could the session I am in have produced this itself?

A probe that greps the agent’s own journal for a string the agent just read is a mirror.