probe.sh silently runs the last-built DLL — build (or refuse) first nf-zr6d ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/380 by tools/beads/import_github.py's reconcile pass.

Captured from a real misdiagnosis today, not a hypothetical.

probe.sh launches Godot against whatever dotnet build last produced. It has no build step and no staleness check — grep -n 'dotnet\|build' probe.sh → nothing. CLAUDE.md already warns about this in bold ("⚠ the probe runs the last-built DLL — dotnet build after any checkout, or the shots silently show the wrong code"), and it still bit.

What it cost, 2026-08-01. While investigating the permanently-red probe_all (#371) I measured two probes as failing with unknown step: {"expect_hint": …} and concluded another session had landed probes ahead of their harness steps. That was wrong — main's harness had the step; my DLL predated a checkout. I reported the wrong root cause, then rebuilt and re-measured before it reached a PR body. The real baseline was 14/5, not 12/7.

The failure is quiet in the worst way: the probe *runs*, prints plausible output, and exits with a status that looks like a verdict about the tree you're looking at. Nothing in the output says "this is code from a different commit". A stale-DLL run and a genuine regression are indistinguishable from the log.

Options

• A (recommended): build first. dotnet build Ninefold.sln --nologo -v q at the top of probe.sh. Incremental and near-free when up to date; correct by construction. Cost is that probe_all.sh would invoke it ~19×, so it should build once itself and pass NINEFOLD_PROBE_SKIP_BUILD=1 to the per-probe calls.
• B: refuse on staleness. Compare the newest *.cs mtime against the built DLL and exit loudly if sources are newer. Cheaper, but mtime comparisons across a git checkout are exactly where this gets subtle — a checkout can leave older mtimes on newer content.
• C: stamp the run. Print the DLL's build time and the current git rev-parse --short HEAD in the [probe] header, so a stale run is at least *visible* in the log and in any pasted output. Weakest on its own, but a good complement to A.

I'd take A + C: A removes the trap, C means any future log carries enough to spot it.

Filed rather than fixed because it touches the probe entry point every UI PR depends on, and the build-once/skip plumbing for probe_all.sh is a design call worth your steer.