What happened
On 2026-09-27 the criterion-check run's implementer for task 06-e2e-criterion-check failed twice, at 06:15 UTC. The run escalated, and the only record of why is:
metered implementer $0.98 FAILED (Command failed (exit 1): claude -p Use the implementer subagent … --output-format json --permission-mode bypassPermissions)
metered implementer $0.00 FAILED (Command failed (exit 1): claude -p Use the implementer subagent … --output-format json --permission-mode bypassPermissions)
The engine log (~/Library/Logs/gateline/up-<date>.log), the ledger and the state commits all hold the same text. Nothing says what went wrong. A claude -p probe some hours later exited 0, so the cause was probably transient, but that is a guess.
Cause
runProcess in packages/orchestrator/src/seam.ts (the close handler, around line 320) builds the error from the exit code, the command line and stderr. Both failures had an empty stderr. In print mode with --output-format json the runner reports its outcome on stdout as one JSON document. The engine does read that stdout (the first failure was metered at $0.98 from it), but the error message never includes it.
Expected
A failed dispatch's record says why it failed. When stdout parses as the runner's JSON result, the error carries its error fields (for this runner, is_error, subtype and the result text), trimmed to a line or two. When it does not parse, the tail of stdout is included the way stderr is.
Also
The logged command line runs to hundreds of characters of prompt before any cause would appear. Putting the cause first would make the one-line summaries in commit subjects and the inbox useful.
What happened
On 2026-09-27 the
criterion-checkrun's implementer for task06-e2e-criterion-checkfailed twice, at 06:15 UTC. The run escalated, and the only record of why is:The engine log (
~/Library/Logs/gateline/up-<date>.log), the ledger and the state commits all hold the same text. Nothing says what went wrong. Aclaude -pprobe some hours later exited 0, so the cause was probably transient, but that is a guess.Cause
runProcessinpackages/orchestrator/src/seam.ts(theclosehandler, around line 320) builds the error from the exit code, the command line and stderr. Both failures had an empty stderr. In print mode with--output-format jsonthe runner reports its outcome on stdout as one JSON document. The engine does read that stdout (the first failure was metered at $0.98 from it), but the error message never includes it.Expected
A failed dispatch's record says why it failed. When stdout parses as the runner's JSON result, the error carries its error fields (for this runner,
is_error,subtypeand theresulttext), trimmed to a line or two. When it does not parse, the tail of stdout is included the way stderr is.Also
The logged command line runs to hundreds of characters of prompt before any cause would appear. Putting the cause first would make the one-line summaries in commit subjects and the inbox useful.