Mission dispatcher can deadlock on stale reviewer assignment while real work continues elsewhere

[jeremyplichta]

Summary

In mission mode, the dispatcher can get stuck on a stale reviewer-assignment state even though the actual implementation work is still progressing on a worker task.

Observed behavior

• A mission work item was initially assigned to the wrong lane.
• A later conductor correction reassigned the real ownership conceptually, but the mission bookkeeping kept the old reviewer-blocked state.
• The mission status continued to report that the work item was blocked waiting on reviewer approval, even after the reviewer had no current task and the worker had the live task.
• Dispatcher "help" events continued to point at the stale blocked state instead of converging on the live owner/task.
• Informational conductor nudges to the live worker were auto-consumed and did not materially move the mission state.
• The worker and sidecars could idle out while the mission still appeared active and blocked on the stale assignment.

Why this is harmful

• The operator/conductor loses trust in mission status because the displayed blocker is no longer the real blocker.
• Reviewers can be shown as the assigned gate even when they have no current task.
• A conductor may keep nudging the correct worker, but the mission state never reflects that correction.
• The run can end up in a limbo where code exists locally, but mission-mode orchestration never reaches PR submission.

Expected behavior

• A conductor correction should be able to supersede a stale reviewer-blocked mission state.
• If the live current task belongs to a worker and the reviewer has no current task, the mission should stop presenting the reviewer as the active blocker.
• Informational/query messages that materially change execution should be surfaced in mission state rather than silently disappearing into an idle loop.
• The dispatcher should converge on the live owner/task pair, not keep re-emitting stale blocked reasons.

Reproduction shape

This does not require any project-specific task details. The generic pattern is:

1. Mission work item is assigned to the wrong lane.
2. Conductor creates a new worker-owned task and sends a correction note.
3. Reviewer lane no longer has a real current task.
4. Mission status still claims the work item is blocked on reviewer approval.
5. Worker continues or idles independently, but mission bookkeeping never catches up.

Requested fix ideas

• Treat conductor correction notes as first-class state transitions for mission ownership.
• Reconcile mission blocked reasons against actual task current ownership for the agents involved.
• Detect and clear reviewer-blocked states when the reviewer no longer has a current task.
• Distinguish FYI auto-consumption from actionable state transitions in the dispatcher.
• Add a recovery path that rebinds the mission work item to the live worker task when they diverge.

[jeremyplichta]

Additional field report from a later mission run: this looks broader than just stale reviewer assignment.

Observed behavior:

• the dispatcher assigned the primary mission work item to the wrong agent lane
• the conductor redirected real implementation work to a different agent with direct tasking
• real repo progress continued under that redirected owner
• mission status remained pinned to the original stale work-item assignment
• the dispatcher kept sending repeated "mission appears stuck" help queries to the conductor, keyed to the stale task timestamp
• stopping / pausing / killing the wrongly assigned agent and reclaiming its orphaned task was not enough to make mission status converge back to reality
• a dispatcher tick still left the mission view showing the old assignee and stale stuck state

So the failure mode seems to be:

• mission dispatcher can deadlock on stale assignment state, not only stale reviewer assignment
• once the canonical work item is attached to the wrong agent, conductor-side manual rerouting can keep the real work moving, but mission bookkeeping may never recover
• that leaves the conductor inbox accumulating help requests even while the branch is actively advancing elsewhere

This suggests the fix may need to be more general than reviewer handling:

• if a work item assignee becomes terminal, or the conductor explicitly redirects ownership, mission state should be able to rebind the canonical work item
• dispatcher stuck detection should account for conductor-rerouted progress on replacement tasks
• reclaiming or requeuing an orphaned mission task should actually clear or rewrite the mission's assignee/stuck pointer instead of preserving the dead reference

[jeremyplichta]

Additional datapoint from another mission run: this is broader than stale reviewer bookkeeping. After a fresh mission start and explicit conductor correction, the scheduler kept the primary mission work item attached to the wrong lane (tester) and continued to treat that stale assignment as authoritative, leaving the mission marked blocked while real implementation work progressed elsewhere. We also saw signs of stale prior-mission context leaking into a fresh mission: at least one agent appeared to pick up task context from the previous mission instead of the new objective. Net effect: the conductor has to route around both stale assignment state and possible stale mission-context contamination, not just stale reviewer state.

[jeremyplichta]

Closing this out based on merged PR #88, which shipped the dispatcher/scheduler reconciliation and redirect handling this issue called for.