Found while widening measure-self-test-floor's DISPATCH criterion for #15421, out of that card's scope. Filed unassigned.
The reading
probeEarlyReturn writes its mutated copy beside the original, inside scripts/:
const probePath = join(dirname(absFile), `.self-test-floor-probe-${basename(absFile)}`);
The comment above it states why — relative imports and repo-root resolution must still answer the same. But any gate whose own work is to walk that tree now reads one extra file: a near-duplicate of itself, with a return; injected. For a gate that counts occurrences or asserts "the checked-in tree is clean", that copy is a finding, so the gate exits non-zero — and the probe reads that as the baseline precondition (#15391) and records NOT MEASURED for a self-test that is perfectly green when run alone.
Measured
On b907c9f42 (branch claude/issue-15421-instrument-dispatch-criterion, where the widened criterion makes this file a census member), in an installed worktree:
node scripts/check-pnpm-filter-targets.mjs --self-test
# exit 0 — "40 assertions ... 181 live occurrence(s) swept"
cp scripts/check-pnpm-filter-targets.mjs scripts/.self-test-floor-probe-check-pnpm-filter-targets.mjs
node scripts/check-pnpm-filter-targets.mjs --self-test
# exit 1 — "and the checked-in tree is clean (dead: @objectstack/adapter-hono, @objectstack/nope, ...)"
rm scripts/.self-test-floor-probe-check-pnpm-filter-targets.mjs
and the probe over that same file:
NOT MEASURED scripts/check-pnpm-filter-targets.mjs entry=selfTest baseline run failed (exit 1)
The copy is removed in a finally, so the perturbation is transient and leaves no trace afterwards — which is exactly why the row reads as a property of the FILE ("this tree cannot run it") rather than of the instrument.
The direction of the error, and why it still matters
It is the safe direction: NOT MEASURED, never a false HELD. But it lands on precisely the class of gates that scan scripts/**, and it lands there for a reason belonging to the instrument, so a reader diagnosing that row does what the precondition's docblock tells them to do (baselineHead "is usually the whole diagnosis — run pnpm install") and finds nothing wrong with the tree.
How many rows this silences was NOT swept here; one carrier is measured above.
Boundary — what this is NOT
Options, not chosen here
Whether the repair is to place the copy outside the scanned tree (and pay the resolution problem the current comment names), to name the copy so the scanning gates ignore it, to record the affected rows by hand, or to leave it and teach the row to say which side the redness came from, is the instrument's own question — the same standing question as #15391 / #15371 / #14963.
Filed from #15421.
Generated by Claude Code
Found while widening
measure-self-test-floor's DISPATCH criterion for #15421, out of that card's scope. Filed unassigned.The reading
probeEarlyReturnwrites its mutated copy beside the original, insidescripts/:The comment above it states why — relative imports and repo-root resolution must still answer the same. But any gate whose own work is to walk that tree now reads one extra file: a near-duplicate of itself, with a
return;injected. For a gate that counts occurrences or asserts "the checked-in tree is clean", that copy is a finding, so the gate exits non-zero — and the probe reads that as the baseline precondition (#15391) and records NOT MEASURED for a self-test that is perfectly green when run alone.Measured
On
b907c9f42(branchclaude/issue-15421-instrument-dispatch-criterion, where the widened criterion makes this file a census member), in an installed worktree:and the probe over that same file:
The copy is removed in a
finally, so the perturbation is transient and leaves no trace afterwards — which is exactly why the row reads as a property of the FILE ("this tree cannot run it") rather than of the instrument.The direction of the error, and why it still matters
It is the safe direction: NOT MEASURED, never a false HELD. But it lands on precisely the class of gates that scan
scripts/**, and it lands there for a reason belonging to the instrument, so a reader diagnosing that row does what the precondition's docblock tells them to do (baselineHead"is usually the whole diagnosis — run pnpm install") and finds nothing wrong with the tree.How many rows this silences was NOT swept here; one carrier is measured above.
Boundary — what this is NOT
check-pnpm-filter-targets: refusing over a stray near-duplicate underscripts/is that gate working.Options, not chosen here
Whether the repair is to place the copy outside the scanned tree (and pay the resolution problem the current comment names), to name the copy so the scanning gates ignore it, to record the affected rows by hand, or to leave it and teach the row to say which side the redness came from, is the instrument's own question — the same standing question as #15391 / #15371 / #14963.
Filed from #15421.
Generated by Claude Code