Build

Build produces one integrated candidate and includes independent Review. You can invoke it directly from an accepted task, and a direct Build stops after its Review result without claiming Acceptance or Ship.

Who owns itCopy Anchor Link

One Engineer owns the whole accepted outcome: the tactical plan, any Worker delegation, integration, behavior-preserving simplification, internal review, evidence, and coherent repair. That Engineer reads the accepted Spec or ticket, the Plan, the decisions, the applicable repository harness, the current candidate and base, the shared seams, and the proof contract.

A clear current request can be the ready Issue. If product intent is missing, PM completes it before Engineer assessment and Build, even at Quick depth. That doesn't require a Project Spec. Asking for implementation doesn't bypass Launch, new intent, or consequential strategy gates.

Before entering a new subtree, framework boundary, or standards domain, Forge resolves the harness that applies there and loads only the newly relevant rules and exemplars. Those rules travel in every delegated packet, because neither a familiar pattern nor a persona overrides the target repository's authority.

What it producesCopy Anchor Link

One integrated candidate, plus build/log.md recording the Build, the Review rounds, findings, dispositions, repairs, the exact candidate, and the preservation scope. Acceptance evidence lives separately under verify/.

The work itself traces the current flow, reuses sound existing machinery, and builds the smallest complete path across every layer it actually needs. For bugs, Forge loads its diagnosis guidance, establishes a red-capable signal, tests hypotheses, fixes the root cause, and keeps the original reproduction. For general work, it picks the appropriate creator and proof instead of forcing software files and tests onto a document.

For UI work it applies Forge's design direction and craft guidance inside the accepted design, unless your repository selects a replacement. That doesn't require a new design study for a patch that's already specified.

DelegationCopy Anchor Link

Workers get dispatched under the staffing triggers, with ownership and sequencing shown first. Each Worker receives accepted constraints, seams, source anchors, owned paths, proof, stop conditions, and a return contract. One writer owns a hot seam, and the Builder integrates and tests the combined result. A Worker return or a local green check is not a candidate verdict.

Simplify firstCopy Anchor Link

Before independent Review, the Builder removes accidental duplication, unused layers, speculative compatibility, unnecessary configuration, and scaffolding that only exists because somebody expected a review. Accepted behavior and proof are preserved. Clean focused work records a justified no-op rather than inventing churn. Forge simplify performs this same bounded operation on its own, without becoming a lifecycle phase, and any semantic change goes back to accepted intent instead of sneaking in through cleanup.

Independent ReviewCopy Anchor Link

The Builder pins the exact candidate and base, then hands them to a separate Reviewer who stays read-only. The Reviewer covers the applicable dimensions, owns one integrated verdict, and never edits, delegates repairs, creates requirements, or turns findings into Plan Issues. Direct Forge review stops at that report.

Five dimensions:

Small work narrows the scope and the report size, not the required coverage. A CSS-only change activates both Code Review and Design, because source correctness and rendered fidelity are different questions. Accompanying software docs, plans, and loop records don't routinely activate Quality; the Reviewer checks their managed-artifact contract during integration instead.

Staffing follows the workflow triggers. Without an expanded-Review trigger, one Reviewer covers every applicable dimension directly in one compact report. When a trigger fires, the Reviewer dispatches clean-context, read-only Judges for the required dimensions and directly covers the rest. A Full candidate with multiple implementation outcomes, or a separately authored design or contract it must satisfy, gets one Judge per applicable dimension. A narrower public-contract or trust-boundary change gets Code Review and Spec Judges. The Reviewer integrates their original reports and resolves conflicts from evidence rather than votes.

You can replace a dimension's source or disable it, and your repository's harness can too, in plain prose rather than configuration. A replacement inherits the same boundary, authority, read-only contract, evidence bar, and report schema. Disabled coverage is reported as DISABLED, which is distinct from NOT_APPLICABLE and from a verdict; only an explicit scoped human waiver lets an integrated PASS exclude a dimension, and that PASS is labeled with what it excluded.

AdmissionCopy Anchor Link

Every admitted finding needs controlling authority, a reachable current trigger, observed evidence or a concrete causal trace, and a material consequence. There's no finding quota, and a clean candidate earns a clean report. Manufactured nits, personal taste, speculative scale, hypothetical inputs outside the accepted surface, and unrelated debt don't make the cut. An explicit material rule violation isn't dismissed as preference, and a required proof gap stays a gap instead of becoming an invented runtime failure.

• P0: a demonstrated accepted-Spec or decision violation, or a critical trust, correctness, security, privacy, data-loss, public-contract, or build-boundary failure.
• Pragmatic P1: a current reachable trigger, a material consequence, and a scope-aligned correction, all supported.
• P2: useful nonblocking advice, which never extends the loop.

The verdict is PASS, REVISE, RETHINK, READY_FOR_USER, or BLOCKED. PASS requires no unresolved P0 or pragmatic P1 and sufficient current evidence for every required claim; missing evidence or missing independence blocks it.

Repair, and when it stopsCopy Anchor Link

Admitted P0s and pragmatic P1s return the whole accepted packet to the Builder, not a patch list. Symptoms get grouped by state owner, lifecycle, or contract, and the shared cause gets repaired. A changed candidate needs a new independent verdict, and the Reviewer re-reads the complete packet rather than narrowing to the diff.

After three substantive Review or Acceptance-to-repair cycles for the packet, or three substantive repairs within one cycle, Forge stops editing and records a rethink: the failed invariant, the common cause, why the prior repairs failed, a simpler approach, the preserved scope, and the discriminating proof. An independent Engineer challenges it. If no supported approach comes out, or the same failure recurs after the rethink, Forge returns BLOCKED with the evidence and the decision or input it needs. Accepted intent never gets relaxed to make the loop close, and the candidate never gets renamed to reset the count.

Where it stopsCopy Anchor Link

Build returns the candidate and base identity, the built behavior or deliverable, the actual commands and observations, the independent Review verdict, the unresolved gaps, and the direct-Build boundary.

What it doesn't authorizeCopy Anchor Link

Review PASS establishes engineering judgment at that candidate, and nothing about runtime behavior. Build never claims Acceptance and never authorizes Ship.