Drew T
1.7 KiB
§402
A tool that resolves an input path in a DIFFERENT working directory sees an empty world and calls it success.
parallel_gate runs its worker as gate_stage ... --drafts <path> with cwd=<git worktree>. It passed
--drafts through verbatim, so a relative path resolved inside the worktree. .run/ is deliberately
not linked into a worktree, and R12 puts ALL project scratch under .run/ — so every plan following the
project's own convention pointed at a directory that does not exist there. gate_stage found 0 drafts,
banked 0, and exited rc=0.
Signature: 35 binaries / 57 drafts, all "banked 0", each in 1-2 seconds, while the same drafts gated in-tree banked 15/16 and 3/6. After the fix the same job takes 100s.
The only tell was the runtime. Every other signal — exit code, per-binary summary line, the absence of any error — said success. A wall-clock far below the cost of the work the tool claims to have done is evidence the work did not happen; a gate that "verifies" a binary faster than a compile is not a fast gate.
Rules. (1) Resolve every caller-supplied path against the REPO before handing it to a subprocess with a
different cwd. (2) Assert the input is non-empty and REFUSE otherwise (R32/R43) — a 0-input job must never
report a 0-yield result, because the two are indistinguishable downstream. (3) When a batch returns all
zeros, exonerate the harness before recording a fact about the subject (R40).
Unaudited blast radius: any earlier wave that pointed parallel_gate at a .run/ drafts dir produced
honest-looking zeros. Backlog rows marked failed from such a run may never have been gated at all.