A cron wrapper change would have logged real failures as success. Three reviews flagged the same line, line 43 of close_gaps_daily.ps1.
The wrapper recorded any exit 1 without a Python traceback as the expected “gaps found” verdict.
The verdict that looked like a failure
PreReleaseScan and CloseGaps both use rc=1 as a verdict, and the cron health view was recording that verdict as a failed run. The commit normalised it: a verdict rc=1 is no longer recorded as a failed run, and a Traceback keeps its rc. The commit’s test run reported 89 passing.
The heuristic assumed that an exit 1 with no traceback was the verdict. The wrapper looked for the literal Python traceback header, and if it was absent, the run was recorded as a success.
Three reviews, one finding
The first review was Manus (standard, 171cr, 231.39s) at 1:02 am, flagged high. It said the new rc=1 normalization “treats every non-traceback exit as an expected ‘gaps found’ verdict.”
Codex (high, 243.67s) came in at 1:06 am, also high: “The traceback heuristic converts genuine failures into success.” It cited _client().
A second Codex pass (high, 195.93s) at 1:20 am, medium this time, said it again: “Every exit-1 result lacking the literal Python traceback header is recorded as success.”
What the commit actually quieted was every exit 1 that didn’t print a traceback.
Giving failures their own exit code
The review-fix commit made missing tracker credentials and a missing sprint exit rc 2, so the rc=1 normalisation can no longer hide a failed scan. rc=1 stays the verdict.
Two related changes went in with it:
daemon_health now treats a failed task enumeration as unknown, and a same-name enabled task as not parked.
A tautology assertion in the tests was fixed.
The tests run for the fix covered daemon_health, the cron exit codes, close_gaps and prerelease, and 104 pass.
A failed scan now exits rc 2, so it never lands on the rc=1 path the wrapper treats as “gaps found.”
AI Skills
Use this lesson with the AI assistant you already use
A change to a nightly cron wrapper recorded every exit 1 without a Python traceback as the expected "gaps found" verdict. Three separate review passes flagged the same line even though the tests reported 89 passing.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
The prompt works in any AI assistant as it is. We are also building a /dxdev skill for visual reports and saved memory.
It is not released yet: see what you can use today.
dxdev LESSON · paste into your AI coding agent
LESSON: Give Real Failures Their Own Exit Code So A Verdict Exit Code Can Be Safely Normalised
SOURCE: dxdev.com/blog/exit-code-one-overloaded-verdict-hid-failures
WHAT HAPPENED: PreReleaseScan and CloseGaps both use rc=1 to mean "gaps found," and the cron health view was showing that verdict as a failed run. The fix stopped recording a verdict rc=1 as a failure and kept the rc when a Traceback appeared. The wrapper decided what counted as the verdict by looking for the literal Python traceback header, so any exit 1 without one was recorded as a success. Manus and two Codex passes each flagged this in turn, noting that genuine failures such as missing credentials would be converted into success. The review-fix commit gave missing tracker credentials and a missing sprint their own rc 2. rc=1 stayed the verdict, so the normalisation could no longer hide a failed scan.
THE RULE: When an exit code doubles as a legitimate verdict, do not infer the verdict from the absence of a crash signal. Give every real failure a distinct exit code so that normalising the verdict code cannot swallow failures.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. List every non-zero exit code your scripts return and confirm each one means exactly one thing, with the verdict code separate from the failure codes.
2. Check that any logic downgrading a failure to success matches a positive signal for the expected verdict, not the absence of a traceback or error text.
3. Trigger each known failure path, such as missing credentials or a missing sprint, and confirm the health view records it as a failure and not as the expected verdict.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
