ForgeLoop is a distributed software-engineering harness for autonomous coding agents. It decomposes feature specifications into parallel units of work, executes agents in isolated environments, and uses builds, tests, containers, browser automation, and independent review to close the loop between generated code and verified software.
翻译准备中
取自仓库 README
正在加载完整 README。
查看完整 README ↗A live software-delivery product—and a case study in making coding agents accountable for verified work.
Watch the demo run · Explore the hosted product · View the source
ForgeLoop takes GitHub issues or feature specifications through planning, bounded agent work, integration, verification, and human review. Its central design principle is simple: an agent saying “done” is not evidence. A run becomes reviewable only when its configured checks and acceptance criteria have supporting results.
This repository is presented as a technical portfolio case study, not a self-hosting or local-install guide. The hosted site is the product demo; GitHub sign-in is required to use the console. The runner is a separate execution component in the product architecture.
Coding agents can produce patches, but reliable software delivery also needs safe coordination, repository access, isolated execution, bounded spend, recovery from failure, and proof that a change meets its requirements. ForgeLoop explores how to make those concerns explicit in a working product rather than hiding them behind a chat interface.
Administrators can also manually ask a runner to scan a repository snapshot for evidence-backed issue proposals. Scans are read-only, may incur provider charges, and never create GitHub issues without an explicit review action.
| Component | Responsibility |
|---|---|
| Hosted web app | Public product pages and the GitHub-authenticated operator console for runs, repositories, policies, usage, support, and evidence. |
| Control plane | Java and Spring Boot GraphQL API; organization-scoped state, policy, issue intake, task scheduling, runner leases, audit records, and GitHub coordination. |
| PostgreSQL and artifact storage | Flyway-managed durable workflow state plus redacted, checksummed evidence in filesystem or S3-compatible storage. |
| ForgeLoop runner | Java desktop/CLI process near the repository; uses Git worktrees and Docker for execution, MCP for approved context/tools, and runner-local provider credentials. |
| External services | GitHub App and OAuth for identity/repository events; configured hosted or local model providers for agent work. |
The control plane coordinates work; the runner handles checkout, execution, and model calls. The hosted service stores workflow records, issue text, findings, usage, and verification evidence. Optional detailed run records can also upload prompts, provider responses, and repository context as artifacts. Local execution is not an offline-only or zero-data-transfer promise; provider data handling still applies.
| Challenge | Design response |
|---|---|
| Parallel agents can overwrite or depend on one another’s changes. | Validate task graphs, capabilities, dependencies, and owned paths; issue expiring single-owner leases; use isolated worktrees; integrate declared commits deterministically. |
| Model output can be incomplete, malformed, or overconfident. | Require structured outputs, validate paths and schemas, run versioned verification gates, track criterion-level evidence, and use bounded repair and review stages. |
| Repository execution and credentials are sensitive. | Keep checkout/provider work on the runner; use short-lived GitHub installation grants, hashed runner credentials, organization membership checks, redaction, and audited operator actions. |
| Services and workers can fail mid-run. | Persist workflow transitions, publish runner heartbeats, expire and recover leases, retain checksummed artifacts, and expose progress and failure evidence to operators. |
| Agent usage has real cost and needs a human boundary. | Track provider/model/token and estimated-cost data, enforce budgets and retry limits, require configured approval, and keep automatic merge disabled unless an administrator opts in. |
The hosted product is live and the repository contains the implementation and automated checks. Current CI covers the control plane, runner, web app, MCP gateway, Windows installer setup, and a disposable Compose end-to-end environment that exercises database restore, runner pairing, package enrollment, and browser tests.
A live issue-to-verified-PR path has been demonstrated against a demo repository. A second-repository unattended issue-to-merge run was also validated on October 9, 2026. Remaining checks include off-host backup/restore, a physical reboot/server validation, staging burn-in, and a production go/no-go review. Desktop installers are unsigned development previews and macOS packages are not notarized. The website and desktop downloads label this limitation.
This is an evolving portfolio product, not a claim that every production launch gate is closed. The open items are listed at the bottom so implementation and operational evidence remain distinct.
Checklist reviewed October 15, 2026. Checked items are implemented or have the specific evidence stated; they do not imply every production validation is complete.
Run history now uses tenant-scoped database pagination, with direct issue-source lookups and complete paginated usage reporting. The guarded multi-turn writing worker is connected behind a default-off runner switch and repository policy opt-in. Lease renewal, spend reservations, cancellation, and verification boundaries are described in agent-loop activation. Security updates, immutable CI action pins, code separation, bounded load scenarios, and local validation are recorded in the hardening report. Operational launch gates remain separate and unchanged.