Build Loop

The Answer

Build Loop runs significant code changes through eight ordered phases with scoring criteria and a fact-check pass, so “done” means “verified” instead of “the model stopped typing.”

The Problem It Solves

Multi-step builds drift. The model writes code, declares success, and leaves silent failures: placeholder data that looks real, test stubs that never ran, scope creep past the original goal. Without a structured loop there is no place for the plan, no common rubric, and no separation between implementation and critique.

How It Works

#	Phase	Purpose
1	Assess	Read project type, architecture, tools, prior state
2	Define	Pin a goal plus 3 to 5 pass/fail criteria
3	Plan	Decompose into parallel-safe chunks with dependency order
4	Execute	Dispatch subagents (Sonnet for write, Opus for plan/review)
5	Validate	Run evals against the criteria, code-based plus LLM-as-judge
6	Iterate	Fix failures, re-validate, 5-iteration cap
7	Fact Check	Trace rendered data to sources, scan for mock data
8	Report	Scorecard split into verified, unknown, unfixed

What Makes It Different

The orchestrator pins Opus 4.7 for plan and review boundaries while Sonnet handles execution, cutting cost roughly 4x versus single-pass Opus. Bridges connect NavGator for blast-radius analysis, claude-code-debugger for prior-incident recall, and logging-tracer for runtime visibility, with standalone fallbacks when those plugins are not installed. An optional Phase 6 Learn step scans recent runs for recurring patterns and auto-drafts experimental skills.