Build & Repair Engine

Understand how FORGE validates generated software, interprets failures, and performs targeted repair attempts.

Build & repair engine

The Build/Repair Engine exists because generating code and producing a valid project are different things.

FORGE treats validation failures as structured feedback that can drive another targeted pass.

Repair loop

Generate or modify files
        ↓
Run validator
        ↓
Success? ── yes ──→ continue to packaging
   │
   no
   ↓
Capture failure
   ↓
Map failure to project context
   ↓
Plan focused repair
   ↓
Modify affected files
   ↓
Validate again

What a useful failure contains

The repair loop is strongest when it has evidence such as:

• failing command or validator
• exit status
• error output
• affected path
• line/column when available
• project configuration
• previous repair attempts

Targeted repair

A repair should change the smallest reasonable surface needed to address the failure. Rewriting large parts of a project for a local type error can introduce more problems than it solves.

Repair budgets

Repair cannot continue forever. FORGE can apply limits such as maximum attempts, runtime, credits, or validation cycles. If the build cannot be repaired within the active limits, the failure should remain visible.

Unsupported validation

Some project types may not have a complete validator in the current FORGE environment. In that case, Starfire should distinguish generated from validated rather than claim a successful build it could not actually check.

A successful automated validation does not prove a project is secure, production-ready, or correct for every real-world environment. FORGE validation is one layer of software verification, not a replacement for testing and review appropriate to the project.

Administrator controls

Control Center can expose build limits, tool availability, timeouts, queue state, and operational failures so FORGE can be managed as a platform service rather than a hidden background process.