Delivery workflow

Ship an issue as a validated pull request

A practical first evaluation: take a well-specified issue, agree what done means, let a run implement and prove it, and approve the pull request with the evidence in front of you.

Cloud is a future offering outside the initial self-hosted release. Registering interest creates no service or launch commitment.

What does this delivery workflow workflow cover?

A practical first evaluation: take a well-specified issue, agree what done means, let a run implement and prove it, and approve the pull request with the evidence in front of you.

What should an evaluator inspect?

Inspect the stated requirements, workspace boundary, validation evidence, approval points, and stated deployment scope rather than inferring results from an example workflow.

Is this customer proof?

No. Workflow pages describe an evaluation model and may use fictional product artifacts. They do not assert customer adoption, outcome, or availability evidence.

Can we run this workflow today?

A released self-managed artifact and tested quickstart are not published. Review the self-hosted requirements or register interest in future Cloud or Enterprise offerings.

What is the next step?

Use the ungated sample run and pilot scorecard to frame the evaluation, then choose a request path only if the operating model fits.

The problem

A queue of well-understood issues sits behind more urgent work. An agent could do most of them, but nobody trusts an unattended change to a payments-adjacent service. So the issues wait, or a senior engineer spends an afternoon babysitting a chat window and pasting diffs into a review tool.

The current workflow

1Copy the issue into an agent chat, re-explain the codebase

2Let it edit a local checkout, hope nothing else is running

3Run tests by hand, read the agent's summary, trust it or not

4Open a pull request with no record of what was verified

5Lose the reasoning and the environment when the session closes

The BranchRunner workflow

01
Import and agree the scope
The issue becomes a task. The planner proposes numbered requirements and states its assumptions; you correct them before any code is written.
02
Provision and implement
A run reserves a worker, creates the worktree and Docker environment, and the implementer works there — not on anyone's laptop.
03
Validate against the ledger
Tests, type checks and a preview smoke test run in the workspace, and each result attaches to the requirement it satisfies.
04
Independent review
A reviewing session with no shared context reads the diff against the requirements and records findings, not compliments.
05
Approve and deliver
You approve the handoff with the evidence in view. BranchRunner opens the draft pull request and keeps the audit record.

In the product

The same run shown three ways: the agreed requirements, the change and its checks, and the approval record that ships with the pull request.

RequirementsAgreed before implementation

R1Backoff is exponential with jitterSatisfied

R2Retries stop after five attemptsSatisfied

R3Alert fires on final failureSatisfied

R4Checkout flow unaffected in previewSatisfied

R5Queue schema unchangedVerified

Run context

Assumption raised by the planner and confirmed by a person: alerting uses the existing channel.

src/workers/webhook.ts+41 −7

@@ -39,7 +41,9 @@ export async function deliver(job) {

3941 if (!response.ok) {

40− return requeue(job, 1000);

42+ const base = jitter(250);

43+ const delay = base * 2 ** job.attempt;

44+ return requeue(job, delay);

PassedUnit tests · 212 passed48s

PassedType check · no new errors21s

PassedPreview smoke test · checkout healthy1m 20s

Approval recordHuman-approved

Approved by

Example reviewer

Decision

Approve for pull request

Evidence

5 requirements, 3 checks, 1 review

Pull request

#1284 · draft

Branch

runs/br-482 → main

Duration

31m 18s · $4.20

Run context

One declined approval during the run: a destructive command was refused and the session took a different next action.

Interface built from the product model. Repository, task and identities are examples.

Where a person stays in control

Before implementation

Requirements and assumptions are confirmed. A run cannot start on a scope nobody agreed.

During the run

Reply in the task to redirect, pause the run, or refuse a tool call. Budgets stop it without you watching.

At handoff

Approval to move from implementation to review is explicit, and shows what has actually been validated.

Before delivery

The pull request opens only after a named person approves. It opens as a draft, so your normal review still applies.

What to expect

·Well-specified issues can run unattended up to the approval point

·Review time goes into the diff, not into reconstructing what happened

·Failed attempts leave a reproducible environment instead of a lost session

·Cost per issue is visible before it becomes a surprise

We do not publish percentage productivity claims. When design partners approve measured results, they will appear here with the workflow that produced them.

Integrations used

Linear or GitHub Issues · work-item importAvailable

GitHub · branch and pull-request deliveryAvailable

Any supported coding agent · planner, implementer, reviewerAvailable

Docker Compose · workspace and previewAvailable

Slack · attention requests and approvalsBeta

Deployment considerations

Capacity

One worker slot per concurrent run, held until approval

Environment

A Compose definition that starts the services the checks need

Credentials

Git token for delivery, model keys per role

Retention

Keep failed workspaces long enough to diagnose them

Which edition for this workflow

One team, one or two repositories: Cloud, or Community if you would rather run it. Many teams sharing rules and capacity: Enterprise.

Cloud is a future offering outside the initial self-hosted release. Registering interest creates no service or launch commitment.