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.
• Preflight runs once per feature. Every later Preflight or Implement keeps the answers you already gave, whether the earlier attempt was paused, discarded, failed or finished, and whether it was this feature's own run or a module run that included it. If nothing preflight reads has changed, nothing is asked: Implement starts straight away, and Preflight is ready to implement as soon as you open it. If something has (the Gherkin, the validation rules, the database policy or your instructions), preflight checks only that change and asks only what it raises. Often that is nothing. A preflight you stopped part-way picks up where it stopped, with your unsubmitted answers still there.
• To answer every question again from scratch, start Preflight and tick Ask every question again. The option appears only when the feature has earlier answers to set aside.

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, Implement opens the same Implement dialog as everywhere else, now that preflight has told you what the feature involves. Choose the verification (Classic BDD or UAT-first, where your project allows it), the model, and the spend limit, add reference images, and give additional instructions. The instructions preflight ran with stay in place, and anything you add goes to the implementation without running preflight again. The model is locked for the run, so a launch cannot silently change models partway through.

If you tick Start implementation when preflight is done when you start a preflight, nobody presses Implement afterwards, so Start preflight asks for the verification and spend limit then.

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. The fixes, merges and tests that follow have budgets too, set per agent in the project's agent defaults, and an administrator can also limit everything a feature or a project spends. Work a budget stops is kept: reset a run's budget, or raise the feature's, to continue it. See Budgets in the admin portal.

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, repave by 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.

Closing a reopened merged feature again, while nothing has changed, also takes away the working copy its preview or Repave IDE recreated, unless that copy holds work the merged branch does not have or someone has it open in Repave IDE; then it is kept.

Resetting a feature stops its preview and any Repave IDE session on it and removes its working copy. If the working copy cannot be removed, the reset stops and says why, and the feature is left as it was.

Next: Repave IDE.