Key Concepts

step_id

Every plan step has a unique step_id (e.g., S-01, S-02). Step IDs are stable across plan revisions and are used by the executor to track progress.

plan_verify

A no-llm gate node that validates the plan structure using plan_verify_gate.py. It runs 12 checks including:

  1. JSON schema validation (against plan.schema.json)
  2. Topological consistency (acyclic forward graph)
  3. Dependency completeness (no dangling references)
  4. Root/leaf correctness
  5. Test-without-implementation detection
  6. Coverage (all spec requirements traced)

plan_verify is code-enforced: the harness runs it deterministically and binds the result to structural_verdict (PASS or FAIL). A FAIL triggers a bounded back-edge to integrate for repair (1 retry). After one failed repair, neither edge fires and the run refuses to write (fail-closed).

coverage_audit

A coverage check that verifies every requirement in the source spec is traced to at least one plan step.

edge_class

Dependency edges carry an edge_class to distinguish build-order from data-flow:

Class Meaning
implementation-prerequisite Must be built before
runtime-data Produces data consumed at runtime
ordering Execution order constraint