Reported by the docudesk agent, reproducible.
Symptom
The runner stopped after gate-24 and printed:
ABORTED before the summary — GATE COVERAGE IS INCOMPLETE
38 gates never executed.
Root cause, visible in source
gate-25's block ends with set -e and never restores the prior state, so errexit leaks into every subsequent gate. Any later gate whose helper returns non-zero — which for several gates is the normal way to report findings — kills the whole run.
Why this matters more than it looks
It fails loudly, which is genuinely good and is why it was caught. But it is a latent whole-run killer sitting in the middle of a 64-gate sequence, and the gates after 25 are the ones this programme has been relying on all day.
Note also that the runner's exit code is a finding/gate COUNT, not a status — so an abort and a large-but-complete run are not distinguishable from the exit code alone. Anyone reading the status rather than the stdout would see a number either way. (Same lossy channel as #209.)
Suggested fix
Save and restore the shell options around any block that changes them (old=$(set +o); …; eval "$old"), or scope the change to a subshell. Then add a regression test that runs the full sequence with a deliberately non-zero helper after gate-25 and asserts all gates still report.
Related, from the same run
gate-22 is non-deterministic across runs on identical trees — ajv resolution depends on cwd/NODE_PATH, so the same tree yields PASS or "SCHEMA VALIDATION DID NOT HAPPEN" depending on where the runner was invoked. Four agents hit this independently today, and on procest the wiring failure was masking 9 real gate-53 findings. Its "vendored validator missing" message also fired once for a file that was present. Worth resolving ajv deterministically relative to the script dir.
Reported by the docudesk agent, reproducible.
Symptom
The runner stopped after gate-24 and printed:
38 gates never executed.
Root cause, visible in source
gate-25's block ends with
set -eand never restores the prior state, soerrexitleaks into every subsequent gate. Any later gate whose helper returns non-zero — which for several gates is the normal way to report findings — kills the whole run.Why this matters more than it looks
It fails loudly, which is genuinely good and is why it was caught. But it is a latent whole-run killer sitting in the middle of a 64-gate sequence, and the gates after 25 are the ones this programme has been relying on all day.
Note also that the runner's exit code is a finding/gate COUNT, not a status — so an abort and a large-but-complete run are not distinguishable from the exit code alone. Anyone reading the status rather than the stdout would see a number either way. (Same lossy channel as #209.)
Suggested fix
Save and restore the shell options around any block that changes them (
old=$(set +o); …; eval "$old"), or scope the change to a subshell. Then add a regression test that runs the full sequence with a deliberately non-zero helper after gate-25 and asserts all gates still report.Related, from the same run
gate-22 is non-deterministic across runs on identical trees —
ajvresolution depends on cwd/NODE_PATH, so the same tree yields PASS or "SCHEMA VALIDATION DID NOT HAPPEN" depending on where the runner was invoked. Four agents hit this independently today, and on procest the wiring failure was masking 9 real gate-53 findings. Its "vendored validator missing" message also fired once for a file that was present. Worth resolvingajvdeterministically relative to the script dir.