The editor keeps project files, agent interaction and a live preview in the same workspace.
ENGINEERING DOSSIER / FORGEAI
The decisions behind the system.
A coding agent is useful only when its authority, work, checks, and handoff can be inspected.
OWNERSHIP
Platform architecture and hands-on implementation. The system keeps the task, execution, evidence, and merge decision under separate owners.
VERIFIED DEVELOPMENT CHECKPOINTA synthetic Kubernetes task completed its check and reached Review in the August 2026 development validation.
Execution remained disabled between tests. The validation does not establish general production operation or autonomous deployment.
ARCHITECTURE / DECISION RECORDS01
A task contract before an agent runs
CONTEXT
Backlog text can be ambiguous and must never become unrestricted instructions to a worker.
CHOICE
The controller accepts named scope and acceptance fields, fixes repository and revision, then resolves the check command from a controlled key.
CONSEQUENCE
The worker can act on a bounded task. Missing or conflicting inputs block the run before execution.
02
Separate execution from publication
CONTEXT
A worker that can both change code and publish it has too much authority.
CHOICE
A per-task worktree contains the code work. The agent does not receive push, Plane, or deployment credentials; publication and review happen outside that boundary.
CONSEQUENCE
A passing check creates reviewable evidence, while a person retains the merge decision.
03
Make an attempt reconstructable
CONTEXT
A single success flag cannot explain retries, interrupted Jobs, or the origin of a change.
CHOICE
TaskRun ties the task, worker attempt, check, and handoff to one immutable run ID with append-only events.
CONSEQUENCE
Operators can inspect the sequence. Multi-node evidence storage remains a documented scaling step, not a completed claim.
EVIDENCE & LIMITS
Private code and run artifacts are not published. The diagram explains the documented control boundaries; it is not a live cluster view.
SourceForgeAI README and TaskRun architecture contract.
ValidationKubernetes development runbook dated 22–23 August 2026; synthetic smoke task reached Review.
Open workSafe parallelism document records disabled scheduling and the remaining multi-node storage work.
SYSTEM MODELSELECT A COMPONENT TO EXPLORE →
SELECTED COMPONENTPlane backlog
Source of truth for task state, acceptance criteria, and role labels.
01 / THE PROBLEM
Agent output can't enter production on trust.
Coding agents can write useful changes, but a team can't merge work it can't trace. Before agent output enters a real workflow, it needs a clear task contract, an isolated place to run and a record someone can review.
02 / THE APPROACH
One bounded task, one isolated worker, one record.
Plane holds the backlog. Ralph, the controller, leases one bounded task, creates an isolated branch and worktree, routes it to a worker and runs only the check registered for that task. The result reaches GitHub as a pull request with its evidence attached, for a person to review.
03 / THE DECISION
A green check is evidence, not permission.
I kept the worker away from deployment credentials and push access. It can change code inside its worktree, but publishing and merging happen outside that boundary. A passing check becomes evidence for the reviewer, never permission to merge.
04 / THE OUTCOME
The full path works. Production is the next test.
In the August 2026 development validation, a synthetic task ran on Kubernetes, passed its check and reached Review. The Kubernetes executor stays disabled between tests, so this shows the path works end to end. It is not a production throughput result.
SOURCES
ForgeAI's README, architecture documents and Kubernetes runbooks. Code and internal links stay private. This page summarizes what those documents show.