I ran orchestrate on a 9-WP mission. Seven WPs went through implement → review → merge cleanly. Then WP07's implementation agent ran, exited 0, but committed nothing — and the whole run died with exit 1:
Orchestration stalled: no schedulable or resumable work packages and nothing in flight.
Stuck WPs: WP07(lane=in_progress, last_error=implementation produced no committable changes), WP09(lane=planned)
WP09 was independent of WP07 and never got a chance to run. One empty WP took the whole mission down.
Looking at it, the "agent exited 0 but committed nothing" path seems to be a dead end: it logs "not advancing to review," records the error, and returns — but leaves the WP in_progress. Every other failure mode retries and eventually gets marked blocked/failed so the run keeps going; this one does neither, so the WP wedges in_progress and the scheduler then reports a stall for the entire mission.
Proposed fix: treat "exited 0 but no committable changes" like any other implementation failure — retry it (up to max_retries), and if it still produces nothing, mark it blocked/failed (the "all agents exhausted" path already transitions to blocked). Then the scheduler can carry on with independent WPs and just report the blocked one. A single no-op WP shouldn't halt unrelated work.
Also, observability: when an implementation produces no commit, include the agent's final message (or a tail of its captured log) in the warning. In my case the agent had actually printed a clear "I'm blocked on X, waiting for direction" explanation — but I only found that by hand-reading the log file. Surfacing it would make this diagnosable at a glance instead of log-spelunking.
I ran
orchestrateon a 9-WP mission. Seven WPs went through implement → review → merge cleanly. Then WP07's implementation agent ran, exited 0, but committed nothing — and the whole run died with exit 1:WP09 was independent of WP07 and never got a chance to run. One empty WP took the whole mission down.
Looking at it, the "agent exited 0 but committed nothing" path seems to be a dead end: it logs "not advancing to review," records the error, and returns — but leaves the WP
in_progress. Every other failure mode retries and eventually gets marked blocked/failed so the run keeps going; this one does neither, so the WP wedgesin_progressand the scheduler then reports a stall for the entire mission.Proposed fix: treat "exited 0 but no committable changes" like any other implementation failure — retry it (up to
max_retries), and if it still produces nothing, mark it blocked/failed (the "all agents exhausted" path already transitions toblocked). Then the scheduler can carry on with independent WPs and just report the blocked one. A single no-op WP shouldn't halt unrelated work.Also, observability: when an implementation produces no commit, include the agent's final message (or a tail of its captured log) in the warning. In my case the agent had actually printed a clear "I'm blocked on X, waiting for direction" explanation — but I only found that by hand-reading the log file. Surfacing it would make this diagnosable at a glance instead of log-spelunking.