The six phases.

Delivery is a sequence of six gated milestones, each crossed on evidence rather than on an assertion.

How the gate reads a mission

Finding the mission

A mission lives in a runward/ directory. runward check finds it by walking up from the current directory looking for runward/framing.md — a directory merely named runward (like the tool's own repo) does not count.

Deliverable states

The phases and their required deliverables are declared as data (the PHASES array). For each deliverable the gate computes an ArtifactState — missing, untouched, in-progress, or filled:

• missing — the file does not exist.
• untouched — the file is byte-identical to the shipped template (content.trim() === template.trim()).
• in-progress — three or more bracketed prose placeholders like [the real process as observed…] still remain, or the edit added fewer than 3 new lines / fewer than 20 new words beyond the template.
• filled — it departs meaningfully from the scaffold. This "divergence guard" exists because templates with few placeholders (e.g. the decision matrix) could otherwise be passed by a one-byte edit; it is calibrated against the shipped reference mission, whose lightest fill adds 5 lines / 215 words.

When a phase is complete

A phase is complete only when every one of its artifacts is filled. The "current gate" is the first incomplete phase.

Exit codes

• 0 = clean
• 1 = gaps
• 2 = no mission found

One caveat on 0: the gate counts unfilled deliverables across all six phases, not just the current frontier. So 0 means the whole chain is filled (and, under --strict, every mapped rule accounted for and every hook green), while a fresh mission returns 1 until then.

An agent should drive on the exit code, or on runward check --json, which emits a stable machine object with verdict, currentGate, per-deliverable states and conformance gaps. The exit-code contract is unchanged in JSON mode.

Flags

• --strict — verify rule-conformance manifests
• --freeze — seal a green strict gate, implies --strict
• --hooks — run operator hooks around the audit
• --coverage — advisory ratios, never gates
• --json — machine output

A note on "six phases" vs. what the gate enforces

All six phases are real and sequenced by the method workflow, which lists them explicitly: Frame, Architect, Floor, Iterate, Govern, Handover. But they are not enforced identically, and this is deliberate:

• Five phases carry a gated deliverable. The gap-analysis PHASES array labels them 1 · Frame, 2 · Architect, 3 · Floor, 5 · Govern (day zero), 6 · Hand over. A reader counting the labels sees 1, 2, 3, 5, 6 — a gap where iterate would be.
• Iterate (phase 4) has no fixed deliverable file, so it is intentionally absent from the gap-analysis gate. Iterate is gated by discipline, not by a file: "one ADR per switch". You cannot have a single "iterate.md" because iteration is open-ended — each evolution produces its own ADR and, if it moves a port's placement, reopens execution-topology.md.
• --strict rule-conformance runs against a slightly different list, GATED_DELIVERABLES: architect → architecture.md, topology → execution-topology.md, floor → floor.md, govern → governance/threat-model.md, handover → handover.md. Note topology is a separate strict scope even though the gap-analysis display groups the topology note visually under the Architect phase (it is one of Architect's five artifacts). The human display and the strict-scope list do not line up one-to-one. Frame has no strict scope — the framing note carries no rule-conformance manifest.

So: six phases in the method, five with a presence gate, four-plus-topology (five scopes) with a strict rule gate, and iterate gated by ADR discipline. The sections below cover each.

Continue in this section

• The six phases in detail
• Sealing, rules, and the method