Implementing a feature
Implementation takes a feature's to-be scenarios and writes the code. You launch it, and then your job is to answer what it asks and judge what comes back.
Preflight: the questions before the work
Implementation does not start by writing code. It starts by asking you what it cannot decide from the specification — a preflight clarification, answered per feature.
- Answers you have not submitted are auto-saved, so a long preflight survives a closed tab.
- An answer can carry per-option detail, or your own answer where none of the options fit.
- Decisions are kept, per feature and per launch, on the Decisions page. A discarded attempt's decisions are reused rather than asked again.
A refused launch is an answer, not a fault. If preflight concludes the feature is not ready, the refusal says so, and the thing to fix is usually upstream in the specification.
Once preflight concludes, you pick the implementation model. That choice is locked for the run, so a launch cannot silently change models partway through.
What the agents do
The work is batched by the Rule: blocks in your Gherkin, so the boundaries are ones you wrote and
reviewed rather than ones a model invented. One agent per role does a whole module's work, in one
worktree on one branch.
Along the way:
- Implementation runs against to-be behaviour only. The legacy code is evidence, not a template.
- The agents that write the code also lint it.
- Where a UI prototype was approved for the feature, the implementation reproduces it.
- The implementation and UI-check agents verify against a live dev stack — a running application, not a static reading of the source.
- A per-run budget stops an implementation before it overspends, rather than after.
Following it
Develop Features shows what is in flight. Agent Logs shows what an agent actually did, step by step, as a single timeline.
Interrupting an implementation pauses it rather than ending it. You can stop a run, look at where it got to, and resume — and there is one resume path for every way an attempt can stop. A job the platform itself stops resumes by itself.
Reading the status
The status vocabulary is precise, and one entry in it is a trap worth knowing:
| Status | What it means |
|---|---|
pending | Discovered, nothing started |
analyzed | The as-is specification exists |
generated | To-be scenarios exist |
in_progress | An implementation is running |
in_review | The implementation finished and is waiting on you |
completed | Implemented on the feature branch — not landed |
merged | On the integration branch, or merged through a pull request |
failed | The run ended without producing an implementation |
partially_implemented | Some scenarios were implemented, others were not |
split | The feature was divided into others |
completed is displayed as "Implemented on Feature Branch" deliberately. The work sits on the
feature's own branch until a merge or a pull request puts it on the integration branch, and reading
completed as "this has landed" is the mistake the wording exists to prevent. merged names the
branch it actually merged into.
A completed feature surfaces its latest job failure whatever the job was, so a feature that looks finished but has a failing job behind it says so.
Getting it onto the integration branch
Two merge modes, set per project:
- DIRECT — the feature branch merges into the project's integration branch,
repaveby default. - PR mode — a pull request is opened against your own base branch, and the Pull Requests view tracks every one Repave opened through to a verified landing. A finished feature spanning several source repositories becomes one pull request per repository.
In either mode the base branch can be merged into a feature branch when it has moved on, a conflicted merge leaves the checkout clean rather than half-applied, and a failed merge job does not mark the feature itself as failed. Several completed features can be tested together before merging, and the merged combination is verified as it would land rather than as it currently stands.
Reopening finished work
Completed and merged features require an explicit reopen before further edits. This is a guard, not an obstacle: it stops an accidental edit to a feature someone has already shipped.
Next: The web IDE.