Phases

Each story progresses through a sequence of phases from analyze to finalize.

A run does its work as an ordered sequence of phases. Each phase has one clear job and a gate it must pass before the next phase begins. You can watch the current phase in .pipeline/STATE.md (or with pipemason status) and on the dashboard. The phases below are described by what you can observe.

Core phases

Every run walks these phases in order:

analyze

The input — text, a ticket, or a design link — is turned into a frozen specification. Open questions are resolved or recorded before the run proceeds.

contracts

The boundaries between domains are written down and frozen so that parallel work cannot drift into incompatible assumptions. Nothing downstream can change them.

architect

Each active domain decides its approach. This runs in parallel by domain and produces the design decisions the rest of the run builds on.

tdd

Tests are written first, and they are expected to fail — proving they actually exercise behavior that does not exist yet. The run will not advance until there are failing tests for the work.

implement

Code is written to turn the failing tests green, in small atomic commits, until every test from the tdd phase passes and the domain is lint- and typecheck-clean.

UI phases

Runs with a user-interface domain (web, mobile, and the game and XR domains) add three more phases after implement. Runs with no UI domain skip these entirely.

e2e

End-to-end tests are written for user-facing flows and confirmed to fail against the missing UI.

ui

The UI is built until those end-to-end flows pass.

screenshot_diff

Screens are captured and, when an expected image was provided, compared against it perceptually. Any visible mismatch loops back to the ui phase with the diff so the UI can be corrected.

Verification phases

verify

Quality gates run — tests, security, accessibility, and (when enabled) performance and SEO. A failure loops back to implement or ui to be fixed.

runtime_check

The app is actually booted and smoke-checked, confirming it runs rather than just passing tests. A failure loops back to be fixed.

rebase

The branch is rebased onto a fresh base branch so it lands on current work. A conflict is never auto-resolved — the run escalates to you.

verify (post-rebase)

Verification runs again on the rebased branch, since the rebased state may differ.

finalize

The branch is always pushed. A pull request is opened only if you asked for one (via --pr or finalize.create_pr). The run is then marked done.