ForgeLoopThe delivery loop
One issue. A traceable path to a pull request.
Every stage should have a clear input, a bounded action, and a result the next stage can trust.
Turn the specification into a plan
ForgeLoop organizes the requested change into tasks with dependencies and file ownership boundaries. This gives agents a defined area of work and tells the system which tasks must finish before others can proceed.
- Independent tasks can proceed when their dependencies permit.
- The plan connects implementation work to the acceptance criteria.
- A vague specification still needs clarification; orchestration cannot supply missing product decisions.
Execute on your runner
An enrolled runner claims available work through a lease and prepares an isolated Git worktree. Agents use repository context, configured tools, and the selected provider to make changes on your infrastructure.
- The web control plane records and coordinates delivery. The runner executes repository commands.
- Provider keys are configured locally. Model requests can send repository context to the selected provider.
- Worktrees separate checkout changes; they are not a security sandbox for arbitrary commands.
Integrate and verify the change
The proposed changes must pass the configured verification gates. Tests, builds, and other commands produce evidence for the commit being evaluated. Browser screenshots are available when a configured browser gate produces them.
- Inspect command output and artifacts, rather than relying only on an agent’s summary.
- Acceptance coverage helps connect the specification to what was checked.
- The quality of the result depends on the quality of your verification commands and criteria.
Repair failures within limits
When verification fails, the failure context can feed a bounded repair loop. The aim is to correct the failing change and verify it again. Limits keep unsuccessful work from continuing indefinitely.
- Review failed gates and repair attempts in the run details.
- A task that exhausts its limits needs attention; failure is not converted into a successful delivery.
- Use clear error reports and focused acceptance criteria to make repair attempts more useful.
Review and deliver a pull request
The final diff, review, and verification evidence support a pull request in your repository. Human approval and optional auto-merge follow the configured policy. Delivery is checked against the expected commit, so a changed branch cannot simply inherit an earlier passing result.
- Human review: inspect the diff, test results, and unresolved questions.
- Optional auto-merge: explicitly enable it and satisfy its delivery checks.
- After merge: deploy and validate the application through your own release process.
Ready for your first run?
Connect a repository, set up your runner, and start with a small change you can review.