When an AI agent works on code and the result is meant to be a GitHub Pull Request, a question arises: which tasks should generate a PR and which shouldn’t? Until now, Orca handled PR workflow at the project level or globally. Now each task can have its own setting.
Why per-task PR
In practice, not every task in a mission warrants the same workflow. Some are internal prep — refactoring, adding tests, config adjustments — and a PR would just be noise. Others require review and merging. A single toggle for the whole project isn’t enough.
The solution: a tri-state switch (Default / On / Off) directly in the new task form. Default inherits from the project setting, On/Off overrides it.
How it works under the hood
When the user picks on or off, the value is written as a label on the epic (pr:on / pr:off). When a mission starts, the orchestrator resolves priority: task label → project setting → global default. The most specific choice wins.
This means within a single mission, one task can have auto-PR, another manual, and a third none — without toggling project settings.
Fixed bug: partial PRs
A live run exposed that the “Open PR” button was usable while the mission was still in progress. The result: a partial PR with incomplete changes.
The fix: the manual “Open PR” affordance now appears only after the mission has been verified and is in a persisted ready state. The endpoint refuses unfinished missions (HTTP 409). Likewise, the POST /mission/:id/pr endpoint rejects missions that aren’t in ready or open state.
Previously, clicking “Open PR” after the first phase completed gave you a PR with half the mission. Now you have to wait until the orchestrator signals completion.
Agent name deduplication
The second bug found during live use: the planner could assign the same agent name to multiple phases. Those then collided on tmux session names and the mission stalled. The fix: phase names are deduplicated when a plan is persisted, so each phase gets a unique session.
What this means in practice
Per-task PR is a small UI change but a big step in controllability. Instead of a binary “PR workflow on or off,” you get granular control over when and how an AI agent’s work surfaces in Git. Less noise in history, cleaner reviews, less manual toggling.
Automation works best when it can be adapted to context — not when you have to adapt to it.