Developer workflow

Architecture

The Developer workflow takes a scoped engineering task from a connected project-management system, prepares an isolated execution environment, lets a coding agent implement and validate the change, and records delivery evidence.

DEVELOPER DELIVERY PATH

A scoped brief becomes a reviewed pull request

1. 01

   Define

   Resolve the brief, repository, agent, and access.

2. 02

   Build

   Plan, implement, and self-review in isolation.

3. 03

   Verify

   Run validation, reviews, and eligible repair loops.

4. 04

   Deliver

   Push the branch, open the PR, and follow CI.

Durable orchestration owns phase transitions and waits. Repository access, runner lifecycle, issue updates, and pull-request delivery are recorded as phase events in the run history.

Input contract

At minimum, a launch resolves:

Input	Purpose
Organization and venture	Authorization boundary.
Repository and base branch	Source repository and integration target.
Task or brief	Implementation goal and acceptance context.
Developer agent	Coding-agent identity and tool policy.
Validation requirements	Repository-specific commands or evidence expectations.
project-management reference	Optional source ticket and status-update target.
Approved resources	Credentials/resources available to the run.
LLM override	Optional per-launch model settings, merged over venture defaults.

A repository connection alone is insufficient. The workflow also needs a credential with the required source-control permissions and available execution capacity.

Phase model

The exact path is conditional, but the run groups execution into:

1. Initialize: resolve the task, generate a title, create the run record, fetch authorized context, and spawn a runner.
2. Define: scope, brainstorm, gather missing answers, create/link the task, and wait for any configured approval.
3. Plan: produce plan candidates and wait for plan selection when human review is enabled.
4. Execute: implement, self-review, validate, and loop through issue fixes.
5. Review: run engineering, design, acceptance, and cleanup reviews when applicable.
6. Deliver: await completion approval, push changes, create the PR, wait for CI, fix eligible CI failures, rebase when required, notify, and update the issue.
7. Finalize: record terminal evidence and release the execution environment.

LLM phases and deterministic phases are deliberately distinct. Waiting, notification, record creation, and most infrastructure operations do not need a model call; scoping, planning, implementation, reviews, and eligible repairs do.

Requirements

• a connected repository;
• a supported source-control credential;
• a connected work item when task-driven;
• an enabled developer agent and model;
• available execution capacity.

GitHub, GitLab, and platform-hosted repositories (Beta) are the supported source-control paths, and Linear is the only supported tracker. Use the providers offered in the repository selector as the source of truth — a provider that is not offered there is not supported.

Outputs and evidence

A successful run can produce:

• a pushed source-control branch and commit SHA;
• a pull request URL and external identifier;
• validation and CI results;
• phase outputs and review findings;
• issue status/comments in the connected project-management system;
• model token usage and cost attribution;
• a complete application event timeline.

The artifact is not considered delivered merely because code exists in the runner. Confirm the push, PR, and final notification/update phases.

Models, tokens, and compute

Every LLM-using phase resolves a provider/model from the run snapshot. A phase can use several model calls, and the detail view can report input, output, prompt-cache, per-model, and estimated-cost data. Live counters are provisional; completed phase metadata drives final workflow aggregation.

Runner compute is tracked separately from model tokens. It is estimated after completion from the recorded workload tier, capacity type, and wall-clock duration, then appears after the hourly attribution refresh.

Developer sessions can be resumed or forked across phases. Keeping the same provider/model preserves cache reuse; a hard phase override can intentionally change it but may create a full cache miss or an unsupported cross-provider resume.

See Compute, tokens, and model selection for selection precedence, formulas, and cost controls.

Review and recovery

Open the run detail to inspect stages, logs, cost, pull-request links, errors, and recovery state.

Use the phase to choose the recovery path:

Failure location	Check first	Safe recovery
Fetching task/context	External ID, credential scope, tenant ownership	Correct reference or credential, then retry.
Starting execution	Capacity and current run status	Wait for recovery to settle; retry only when the state allows it.
Waiting phase	Pending question or approval	Submit the requested action; do not create a duplicate run.
Implementing/reviewing	Model availability, context window, tool error	Inspect the last phase output; retry if marked eligible.
Validating	Exact command, exit code, repository instructions	Fix the reported failure or refine validation requirements.
Push/PR	Branch protection, token scope, remote conflict	Restore access or rebase; never force-push unless policy permits it.
Waiting for CI	Check provider build and callback/poll state	Fix CI or refresh synchronization; avoid duplicate PRs.

What to expect

• Linear is the primary task-driven project-management integration. Use the providers shown in the launch form as the supported set.
• Repository export or recovery actions that are not shown require help from your Organ administrator.
• Older development records can have less phase and cost detail than current runs.