Build and review

Once the plan is approved, Forginate builds it. This page covers the build phase, the integration/audit loop, and how the work reaches your repository.

From plan to tasks

The approved planning documents are decomposed into build tasks — discrete, ordered units of implementation work. Each task is executed by a build agent in its own isolated run:

• The agent works in a sandboxed environment with the project's repository and the relevant approved documents in context.
• Code lands in the project's Git repository as the agent works.
• Progress is visible live: the request detail page shows tasks moving from pending through in-progress to done, and the Pipeline board shows the request in the Build column.

Watching a build

For each run you can see:

• Live status and event stream — what the agent is doing right now.
• Live cost — token usage and dollar cost, updated as the run executes.
• Artifacts — the run's outputs once it completes.

Runs that stall on the provider don't fail

If the model provider is overloaded, rate-limiting, or out of capacity, the run doesn't die — it holds its full working state and retries the same call periodically, for up to 24 hours if needed. The UI shows a "delayed" badge with a countdown. When the provider recovers, the run resumes exactly where it stopped, with no re-spend.

Budget caps

Every run has a cost cap. A run that reaches its cap stops instead of spending indefinitely. During the integration phase there is additionally a budget envelope for the audit-and-fix loop; if it's exhausted before the audit comes back clean, the request escalates to you rather than silently burning money. You can raise the live budget mid-grind to let the loop continue.

Integration: assemble, audit, close gaps

When build tasks complete, the request moves to Integrate — "assembling · auditing · gap-closing":

1. The completed work is assembled into a coherent whole.
2. An auditor agent examines it against the plan and issues a verdict: green (clean), yellow (findings), or red (serious problems).
3. Findings become targeted gap-closing tasks, which build agents execute.
4. A re-audit runs. The request detail page shows the full re-audit history — one chip per round with its verdict and cost — so a yellow→yellow→green progression is visible, not hidden.

This loop runs autonomously inside its budget envelope. If it escalates (budget exhausted, or repeated non-green verdicts), you can:

• Raise the budget and re-arm the loop with a fresh envelope and a new audit.
• Intervene — review the findings and adjust the plan or scope.

Stall handling

If a build stalls — a task stuck without progress — the system detects it and surfaces the state on the request rather than leaving it in limbo. Check the request detail page for the stalled task and its last events.

Delivery

With a green audit (and QA passing), the request enters Deliver — "awaiting approval · delivering". This is your final gate:

• Review the assembled result and the audit trail.
• Approve, and the work lands on the project's main branch. The request moves to Improving: merged, live, and open to improvement requests.

Where the code lives

Forginate provisions and works against a Git repository for your project via its GitHub integration. Phase milestones are tagged in the repo, which is what makes phase reverts possible: reverting resets the repo to the phase tag and discards later documents and runs.

Cost accounting

The request's cost story is broken down by stage — planning, build, audit rounds, gap-closing — so when a request cost more than expected you can see exactly which loop consumed it. Per-run costs are also listed individually.

Next

• QA — the acceptance-criteria harness.
• Deployments — shipping the delivered build.