Symptom
When the director dispatches a worker (a Claude session in a worktree) to do a task, the worker reliably implements the code correctly and then ends its turn before completing the git finish — no commit, no push, no PR, no status report. Observed across four consecutive workers during the Smart Orcastrators work. Each left correct, uncommitted changes on disk and went idle.
Impact
- The director has to take over the finish (commit / push / PR), which directly pushes it into violating the no-code / no-build director rule (see the capability-settings issue).
- Wasted cycles re-nudging or spawning fresh "finish-only" workers.
Hypotheses (unconfirmed)
- The worker treats "code written" as the natural end of its response and stops, rather than continuing to commit/push/PR.
- The worker hits a permission/trust prompt on
git push / gh and waits — appearing "idle" — but the prompt isn't answerable via terminal send text.
- The Claude TUI uses an alternate-screen buffer that is not captured in terminal scrollback (
terminal read returns ~1 line), so the director is blind to whether the worker is idle-by-choice or blocked on a prompt. This blindness is itself a core problem — the director can't observe worker state reliably.
Possible directions
- A coordinator-owned finish step: after a worker signals "implementation done", the coordinator (deterministically) runs checks + commit + push + opens the PR, instead of relying on the worker to do it.
- A dispatch contract that the worker must satisfy before its task is considered complete (PR URL reported), with the coordinator retrying/escalating if not met.
- Pre-grant the worker the permissions it needs (git/gh) so it never blocks on a prompt.
- Make worker TUI state observable to the director (a readable status channel) so stalls are detectable, not inferred.
Repro
Dispatch any non-trivial implementation task to a worker via orca terminal create --command claude + a prompt; observe that it implements but commonly does not commit/push/PR without repeated nudging.
Symptom
When the director dispatches a worker (a Claude session in a worktree) to do a task, the worker reliably implements the code correctly and then ends its turn before completing the git finish — no commit, no push, no PR, no status report. Observed across four consecutive workers during the Smart Orcastrators work. Each left correct, uncommitted changes on disk and went idle.
Impact
Hypotheses (unconfirmed)
git push/ghand waits — appearing "idle" — but the prompt isn't answerable viaterminal sendtext.terminal readreturns ~1 line), so the director is blind to whether the worker is idle-by-choice or blocked on a prompt. This blindness is itself a core problem — the director can't observe worker state reliably.Possible directions
Repro
Dispatch any non-trivial implementation task to a worker via
orca terminal create --command claude+ a prompt; observe that it implements but commonly does not commit/push/PR without repeated nudging.