Key Concepts
The COMPILE model
The executor compiles each plan step into a harness node with four binding contract field-groups:
| Group | What it covers |
|---|---|
| Lifecycle | Step state (pending, executing, verifying, complete, failed) |
| DoD (Definition of Done) | Acceptance criteria, integration checks, outputs |
| Effect | Classification (pure, reversible, irreversible), pre-commit gates |
| Traces | Which spec requirements this step satisfies |
DoD (Definition of Done)
Every step has a DoD derived from its acceptance criteria, integration checks, and declared outputs. The executor verifies DoD in a role-separated verifier lens: it re-derives each criterion from recorded evidence, never from the build narration.
- Empty
acceptance_criteria=> BLOCKED (never auto-passed). - A criterion that cannot be grounded in evidence => FAILED (never silent PASS).
effect_class
Effects are classified before acting:
| Class | Gate |
|---|---|
pure |
No gate --- safe to execute |
reversible |
Checkpoint before executing |
irreversible |
Human confirm required --- pre-commit checkpoint + HITL gate |
Role separation
The executor enforces role separation between building (execute_step) and verifying (verify_dod). When driving the graph, these are separate nodes with separate contexts. This separation is lost the moment you hand-emulate the loop instead of driving it.