No task in phase N+1 spawns until every task in phase N reports STATUS: PASS — so bugs are caught at the layer where they were made, not four layers downstream.

Pattern

Phase Gate

The shape

Phase → gate → phase. The gate decides whether the next phase spawns.

Phase 1

Schema / Contract

✓P1-T1

✓P1-T2

✓

Gate 1

all PASS?

Phase 2

Service / Route

✓P2-T1

✓P2-T2

✓

Gate 2

all PASS?

Phase 3

Hook / Component

✓P3-T1

✓P3-T2

YESspawn next phase

NOstop. fix current phase.

Tasks within a phase run in parallel. Tasks across phases are always sequential — the gate is what makes that true.

Why the gate exists

A schema bug costs one fix at Phase 1 — or four fixes at Phase 4.

No gate — parallel spawn4 layers of rework

Bug in schema, discovered when UI fails

schemaROOT BUG

serviceBUILT ON

routeBUILT ON

componentFAILS HERE

Fix cost: schema + service + route + component — four layers of code assumed the broken foundation was correct.

With gate — sequential1 layer of rework

Bug in schema, caught at Gate 1

schemaCAUGHT

service— not built —

route— not built —

component— not built —

Fix cost: schema — no downstream code exists to redo.

If downstream phases run in parallel, the first broken layer poisons every layer above it — and you pay for the correction in layer-count, not bug-count.

The default phase order

Five phases, mapped to architectural dependency.

1

Schema, Contractshape of data, interface boundaries

NONE — first

2

Service, Routebehavior on top of schema

Phase 1 — schema exists

3

Hook, ComponentUI bound to services and routes

Phase 2 — services callable

4

Testexercises the full stack

Phase 3 — everything testable

5

Finalizationplan-finalizer regression check

Phase 4 — tests pass

Tasks within one phase run in parallel (schema + contract are independent). Tasks across phases are sequential because the architecture is sequential — the gate just enforces what's already true.

What the gate actually checks

PASS = three independent signals all agreeing.

A task doesn't PASS because the builder said so. It passes when three separate witnesses agree.

1

Stop hook exits 0

filesExpected satisfied on disk

2

report.md says PASS

validator agrees, independently

3

No blocking issue

companion agent didn't flag it

— ALL THREE —

→STATUS: PASS

The orchestrator queries via task_list.py --plan {name} — never via agent self-report. Disk state decides, not trust.

If one signal disagrees, the gate is closed. No quorum, no majority — unanimous or blocked.

The anti-pattern

Spawn all phases in parallel. Discover the schema bug from the UI.

Anti-patternNo gate — everything at once

You spawn every phase simultaneously to "save time." A schema decision turns out wrong. Service was built on it. Route calls the service. Component calls the route. The UI fails a week later — and debugging traces back through four layers to land on a schema bug that Phase 1 would have caught in minutes.

SCHEMA

root bug

SERVICE

assumed correct

ROUTE

assumed correct

COMPONENT

fails here

Parallelism is cheap. Unguarded parallelism is not — you pay for it in rework proportional to how deep the bug propagated before it was caught.

The discipline

Catch the bug at the layer where it was made — not four layers downstream.

Phase ordering is only meaningful if enforced. The gate is the mechanism: every task in phase N must reach STATUS: PASS on disk before phase N+1 exists. No self-report, no trust, no exceptions.