Implement Workflow¶

implement writes the code, and - since the #521 lifecycle redesign folded the old clarify agent kind into it - it also conducts the approval conversation and judges the approval grammar, in whichever turn or pod the conversation actually happens in. It is both an agent kind (Task.status.agentKind) and, since #521, an origin kind (Task.spec.kind: implement): it is SweepIssueKind, the same value MintIssueTask stamps on any Task minted from a new issue - webhook-delivered or backlog-sweep-discovered - which is exactly the role clarify used to play as an origin. It is also the agent every other triaged origin (brainstorm, incident, refine, takeover) passes through on its way to code, driven entirely by the operator, never self-initiated.

1. Trigger¶

Any of:

1. (create) -> new -> refined: a new issue arrives (webhook-delivered or backlog-sweep-discovered) and is minted directly with spec.kind: implement - implement is its own origin here, starting at the approval gate, not at code.
2. new -> refined: triage passed and routed a different origin kind (brainstorm, incident, refine, takeover) to the implement agent, same starting point.
3. Any comment on an existing issue that is part of a live Task's umbrella, while the Task sits at refined or under-implementation.
4. awaiting-review -> under-implementation: a review pod submitted verdict=request_changes on a non-review-kind Task (i.e. the platform's own MR). No longer bounded by maxReviewRounds - that cap is deprecated with zero effect; the 24h residency cap is the backstop instead.

2. The conversation phase: refined¶

On a new issue, implement digests the human's issue body and asks clarifying questions via the normal issue-comment channel - the technical conversation happens on the issue thread, the same SCM-native mechanism the platform has always used. On a comment, it reads the existing Task CR and either answers back and waits, or submits action=approved and, once the operator's independent verification passes, continues straight into writing code.

Live polling pod. Once it posts a question or a partial plan, the operator keeps the pod alive for up to 1 hour wall-clock, delivering new comments to the running session rather than tearing it down and re-spawning on every reply. If the hour elapses with no reply, the operator stops the pod - the issue is left exactly where the conversation stopped, resumable by a future comment (which re-spawns a fresh implement pod against the same Task). This is bounded by the refined state's own idle budget (ConversationIdleDefault, 60m by default): past that, the Task parks at parked(awaiting-human) regardless of how many short polling windows it has been through.

The approval gate: implement proposes, the operator verifies¶

The pod's path forward at refined is submit_outcome:

{"action":"approved","reason":"szymonrychu approved on tatara-operator#291",
 "plan_note_id":"n-05fa7cd2b344cec2",
 "approving_maintainer":"szymonrychu",
 "approval_citations":[{"id":"c-291-4","quote":"go ahead, ship it"}]}

submit_outcome(action=approved) answers with granted: true, a guidance string, and the Task itself under a task key, or granted: false with reason, declared, and guidance. Both shapes carry guidance now; before this the grant returned a bare Task DTO with no granted key to check at all.

A Task parked at identity-unverified is not stuck forever: the next non-bot comment on the thread makes the operator re-sync that Issue's comments from the forge and un-park the Task, spawning a fresh implement pod against the refreshed thread. The webhook path itself never grants approval - it only gets a live agent back in front of the human who just commented. That pod reads the new comment, forms its own judgment, and submits action=approved with a fresh citation through the same single gate (restapi.verifyApprovalScope) every other pod goes through. Nothing is posted to the thread when the park happens - the refusal is recorded only in Task.status.notes, a log line, and a metric - so a genuinely new human comment is what un-parks it, not a reaction to any prompt from the operator.

See Approval Gates for the full grammar, why the operator re-derives who posted the cited comment and that the quote is really there instead of trusting the agent's read, and why labels play no part in it at all - issue_write has no labels parameter and no status parameter, so nothing gives implement a path to self-approve by any tool call.

3. The code phase: under-implementation¶

Once action=approved grants, the pod - the same one, or its next turn on this Task - picks up the whole Task CR: every linked Issue and MergeRequest and their conversation, across every repo in scope, not just the one issue that triggered it. It works with all repos under the Task and opens PRs across every affected one, all under the same project-scoped Task (see the context bundle). Implement may check out branches or existing MRs directly rather than always starting from a fresh clone.

The ship gate is enforced, not advisory. Both mr_write(action=open) and submit_outcome(action=submitted) refuse with 409 {reason: "approval-required"} while any live Issue the Task owns carries no approval evidence, one entry per blocking issue carrying repo, number, a detail (needs-maintainer-comment | needs-approval-tool | over-auto-approve-ceiling), and a guidance sentence. Code written before the gate grants is lost: no merge request can carry it forward. A Task that owns zero live Issues - a takeover, an adopted upgrade - is ungated. See The ship gate: no merge request can carry unapproved work.

Subagent tiering¶

Implement's own agent surface (opus) is a tiering point, not a single flat context. The rigid implement skill mandates dispatching work through typed .claude/agents/*.md files shipped by tatara-agent-skills, each with baked model: frontmatter:

The dispatch table (task-shape -> named agent) is structural, resolved via frontmatter (param > frontmatter > parent) rather than the CLAUDE_CODE_SUBAGENT_MODEL environment override, which the design explicitly avoids as a silent-clobber footgun. This is the same context-boundary fan-out principle as brainstorm/incident (split by repo, split by concern, keep each subagent's context lean, report back a compact result) - implement is simply the kind that tiers its own subagents by model as well as by boundary. No Workflow tool, no ultracode effort tier, anywhere in this dispatch.

Output¶

1. Clones (or checks out an existing branch/MR for) every repo in scope.
2. Writes code, commits, pushes to the deterministic task branch.
3. Opens (or updates) an MR per affected repo, referencing the issue(s) it closes.
4. Calls submit_outcome:

{"action":"submitted","title":"...","body":"...",
 "change_significance":"major|minor|patch",
 "merge_order":["tatara-operator","tatara-cli"]}

Since tatara-operator#623, title and body are not just an internal record: on success the operator edits every owned merge request that is not externally-owned (MergeRequest.status.ownership != "external") to match, clamped to the forge's title length limit. Before #623 they went nowhere - a reviewer asking for a corrected MR title had no way to get one, because mr_write exposes open/comment/reply only, and submit_outcome's own title/body silently stopped at an internal Task note. The edit is best-effort and runs after the stage transition has already committed: a forge failure here does not fail the submit.

change_significance is required on submitted and is implement-owned: a reviewer may only raise it, never lower it - see semver push-CD. merge_order is required whenever the Task's MRs span more than one repo, and there is no lexical default - lexical order over this platform's own repos merges cli before operator, which is precisely the fleet outage this field exists to prevent.

The call itself can be refused. Since tatara-operator#594, if any MR the Task already owns is open with red CI, a real base conflict, or an unanswered request_changes, submit_outcome returns a structured 409 and writes nothing - no claim, no note, no transition. The agent's own prompt tells it to loop and wait for its own pipeline (bounded roughly 20 minutes) before resubmitting; submitting while CI is still running is explicitly correct. See CI readiness gate.

On success, under-implementation -> awaiting-review (at least one owned MR must be open). Implement never merges its own PR and never approves its own diff - that is review's job, in a separate pod, on a separate turn, and no MCP tool exposes a merge action to any agent kind.

{"action":"declined","decline_reason":"..."}

decline_reason is required and non-empty. This parks the Task at parked(implement-declined), which normally ages out at ParkRetention and is reaped. The one exception: if the decline was forced by the platform rather than the change - submit_outcome refused with a live 409 ci-red and the Task's own tatara-owned merge request has since gone green at that exact head SHA - a separate driver re-arms the Task back into under-implementation (at most 3 times, never for kind=takeover). See Task State Machine.

The maxTurnsPerPod exemption¶

implement is the one agent kind exempt from Project.spec.agent.maxTurnsPerPod (default 40, which caps every other kind's single pod run). A long healthy coding run must not be cut off mid-implementation. Task.spec.maxTurnsPerTask / Project.spec.agent.maxTurnsPerTask used to be the lifetime turn cap that bounded this exemption; it is now deprecated with zero effect (a turn count measures how much an agent has done, not whether it is stuck). What actually bounds a runaway implement Task today:

• The idle/work budget on refined and under-implementation - on elapse, parked(awaiting-human) or parked(stage-deadline) respectively.
• The probe/interrupt stall escalation on a turn that goes quiet mid-work - see Stall detection.
• The 24h residency cap, a hardcoded dead-man switch for whatever the first two clocks cannot reach.