Autonomous Relay

Autonomous Relay

The run takes a ticket and returns a branch that is committed, green, reviewed, and carries a release plan. It does not deploy, does not push, and does not decide what the product should do.

The value is not speed. It is that the human reads one report instead of answering nine questions, and that every place the run supplied intent nobody gave it is written down.

Before you start

The run needs a ticket. Fetch it by issue key where a tracker connector is available; otherwise treat the argument as the ticket body.

Neither available is a stop, before any stage runs. Say which input was missing. Do not invent a ticket from the repository state — a run with no ticket has no goal, and a goal inferred from a codebase is the codebase's opinion of itself.

The relay

Six stages. Each names its role, its workflow, and the artifact the next stage consumes.

1. Requirements — product-manager with requirements-interview and spec-writing, into docs/specs/<date>-<topic>.md.

   This stage carries the one override in the whole run. requirements-interview asks one question per message; unattended, there is nobody to ask, so state an assumption instead and tag it. Acceptance criteria derived from the ticket body or from the repository are tagged, per the assumption ledger in references/autonomous-run.md. A criterion the ticket actually stated is not an assumption and is not tagged.

2. Plan — tech-lead with work-breakdown, into docs/plans/<date>-<topic>.md.

   Every task gets a tier and a definition of done that is a runnable command. A task whose definition of done cannot be expressed as a command is a task that cannot be verified unattended; split it or escalate it.

3. Build — the tier each task was assigned, with tdd-loop inside incremental-delivery. One task at a time, red before green, whole suite green before the commit.

4. Review — the panel from code-review-pass: code-reviewer and test-engineer always, plus security-auditor, performance-engineer, data-quality, or ux-reviewer when the diff earns them. Reviewers do not see each other's findings first; shared context produces agreement rather than coverage.

5. Release plan — sre with release-and-rollback. A document, not a deployment. If the rollback question has no answer, that is a design problem and escalates rather than being written around.

6. Report — the run report block in references/autonomous-run.md.

Escalation while unattended

A ceiling is still a ceiling. Nobody watching changes who receives the packet, not whether one is owed.

Emit the same handoff packet defined in references/escalation-ladder.md and route it per the redirect table in references/autonomous-run.md. The recipient is terminal and must decide. Record every such decision, with its trigger, in the run report.

Do not restate the trigger table here or in the report. Two copies drift, and the copy an agent happens to read will be the stale one.

Abort

One condition: an open Critical finding from the review panel stops the run.

There is no task ceiling, no consult ceiling, and no wall-clock ceiling. The plan's task list is the practical bound. The run report prints the task count and the consult count so a ceiling can be set later from evidence rather than from guesswork.

An abort is not a failure to report. Emit the run report with Outcome: aborted, the findings that caused it, and the branch left in place.

Git

Branch from the default branch:

adt/<ticket-id>-<topic>

One commit per task. Structural and behavioural changes never share a commit. Nothing is pushed and no pull request is opened — both are outward-facing, which is the first escalation trigger, and the branch is the deliverable.

A run that aborts or pauses leaves the branch exactly where it stopped. Do not clean up after yourself; the partial state is evidence.

Report

Emit the run report block from references/autonomous-run.md verbatim, including on an abort and on a pause.

The report is the only artifact anyone is guaranteed to read. Two fields carry most of its weight: Assumptions, which is every place the run supplied intent nobody gave it, and Not done, which is every place the run fell short. A report that is honest about both is useful even when the run went badly. A report that is not is worse than no run at all.

Red flags