Gate: phase-ordered

The plan’s phases do not depend on what comes after them.

Property	Value
Checker	phase-ordered
Confronts	plan
Blocking by default — new project	yes
Blocking by default — existing project	no — informs
Duplicates	a declaration it controls repeated in one file fails it; duplicates: false switches this off

How it measures

Confronts internal plan phase ordering and cross-artifact phase dependencies: phases within a plan must follow consistent non-cyclic order, and specifications citing phase prerequisites must target existing phases.

The needs: declaration previously resolved execution order between separate plans, but ordering within a single plan lived purely as informal prose (such as ### Fase 2 — a régua mecânica (depende da Fase 1)). Natural language prose cannot be mechanically verified. When task identification pipelines generate work cards for each specification in a plan, all cards are born into the backlog indistinguishably, and automated claim pipelines deliver any card without respecting prerequisite readiness.

Measured in the very first real-world usage: an automated agent was assigned the specification for a test harness (Phase 3) while Phase 1 and Phase 2 remained completely open. Without even a package.json created in the repository, there was nowhere to configure tooling. The assignment only avoided becoming lost work because a human intervened to read the narrative plan; an agent trusting the task card would have attempted execution and failed.

Phases are therefore promoted to catalogued items with identity codes derived from the plan (such as <PLAN>-W01). A seeded specification declares needs: <PLAN>-W01 in its header, adopting the exact ordering keyword at phase scope. Identity codes remain immutable even when authors revise descriptive phase titles, transforming “can this specification be worked on now?” into an objective mechanical query.

This gate confronts three complementary structural ordering contracts:

1. Phase order within plans (phase-ordered): Phases cannot depend on future phases, duplicate codes, or themselves. Plans with phase-like sections lacking catalogued codes return Pending.
2. Phase references in specifications (phase-exists): A specification declaring needs: must target catalogued phases that exist in project plans, avoiding permanent task blockages.
3. Parent hierarchy integrity (parent-valid): Artifacts declaring a parent: must target real entities (artifacts or phases) without dangling references or circular parent chains.

Declaring it

gates:
  - name: phase-ordered
    on: [plan]
    check: phase-ordered

Source: checker · its spec