A phase is any chunk of work run through the rituals; its mode — product · system · side — sets the ritual's weight and focus. A phase lives as a board while open, and one phase per session (chat) is the strong default, not a law — a phase survives a force-ended chat. The mode answers three questions: where the work comes from, what it reads to orient, and what it's comfortable editing. Can't name the mode? Stop and decide before touching anything — no phase is ritual-free.
OpenDeclare the mode. Open its board. Orient — read, then align or challenge.
WorkStay in scope — the touch bands gate pens, not eyes.
CloseRun the closing ritual: distill, propagate, delete the board.
The three modes
1
Product
building the product
Chunked product work toward the app's goals, carrying a thesis (the structural change it delivers). Usually born from the queue; may open directly when something serious earns it. The product ships through this mode, so its rituals are the deepest.
Home groundproduct code, feature docs.
Carefulstrategy docs and ROADMAP content — updated deliberately when the work bears on them (a ratified walkthrough decision, or a structured challenge when new work presses on an old commitment), never in passing.
Gatedthe governance docs — CLAUDE.md, this file, ROADMAP structure, the /system code. Not forbidden: suggest the edit, and it lands through a system phase.
›The ritual3 steps to open · 3 to close
Opening ritual
1Open the board from _product-template.md (mode: product) with its thesis stated; fold the phase's seed (planning/queued/) into the board and delete it, and remove the phase's row from the ROADMAP in the same step — the queue is future-only, and the active board at /system is the open phase's pointer (a row left behind double-counts in the queued list). Update the ROADMAP's Where-We-Are current-phase line instead.
2Orient — run the Opening Checklist (§ Opening a Product Phase): Ring 1 reads the strategy shelf whole, Ring 2 actively aligns to the docs this phase answers to; align or challenge.
3Confirm thesis + scope with the user — no task moves to in-progress before this.
During
work only from the board; decide-and-flag; keep the walkthrough doc current as you build (§ During a Phase).
Closing ritual
1The collaborative Walkthrough — every O/V point passed with the PO, point by point (§ Walkthrough).
2The Closing Checklist (§ Closing a Phase) — decisions propagated to home docs and the load-bearing ones lifted to decisions.md, feature docs updated, trackers pruned, ROADMAP re-oriented.
3Distill + delete — a compact record replaces the board and walkthrough.
2
System
tending the system
Meta-work on the docs, workflow, and /system surface themselves — restructuring a tracker, rewriting these rules, reorganizing the doc tree, dashboard changes, a styleguide pass. Product-agnostic by definition, and the inverse of a side phase: the governance docs are its home ground. It must never settle product strategy in passing — if a strategic question surfaces mid-phase, it goes to Open Questions, not decided.
Home groundthe governance docs (CLAUDE.md, this file, ROADMAP structure, the trackers' formats, the templates, the doc tree) and production code that is the system's own surface — lib/system.ts, app/system/, and the shared conventions the system defines (styleguide, design tokens, shared component patterns) wherever those live.
Carefuldecisions.md's prior entries (amend with a new dated entry, never rewrite history), and mechanical ripples into product-facing docs when a governance change lands (repoint the refs; don't touch their content).
Gatedproduct behavior — features, flows, product copy, seeded content, strategy doc content. The band is purpose, not file location: production code is home ground while the edit serves the system's own surface, and gated the moment it adds or changes what the product does for its users. Not forbidden: suggest it, and it lands through a product phase.
›The ritual3 steps to open · 6 to close
Opening ritual
1Name the friction this phase fixes, and agree the scope with the user — system work is always done with the user, never solo.
2Open a board from _system-template.md (mode: system) sized to the friction — a few lines for a small fix, workstreams for a build. Max one open; may run alongside a product phase, but never opens mid-walkthrough (doc churn collides with phase edits).
3Orient: read the governance docs whole (CLAUDE.md, this file, implementation/system-surface.md), then check decisions.md and the doc tiers for prior settled calls the work touches — reopening one is a structured challenge (§ Doc Tiers), not a silent rewrite.
During
keep it lean — a system pass should leave the rule-set the same size or smaller, not bigger. Log decisions in decisions.mdas they're made (this mode writes there directly; there's no walkthrough to lift from).
Closing ritual
1Hand off for verification. Before deleting anything, present the phase's durable output for the PO's final read — the artifact that outlives the board: the decisions.md entries, the surface/build state (/system renders, drift alarms silent), and anything worth a second look. The board isn't deleted until the PO confirms. (System work has no walkthrough — this light in-chat handoff is its verification moment, the analog of a product phase's Closing-Checklist gate.)
2Every non-obvious call landed in decisions.md (challenges logged win or lose).
3implementation/system-surface.md and/or this file updated in the same change, if the system's behavior changed.
4last-reviewed bumped on every doc reviewed — not the ones only mechanically touched (§ Doc Tiers → Stamping last-reviewed).
5Lands as its own commit (or PR), described as system work — mode-pure.
6Board deleted (git is the record; decisions.md carries the calls). A build-scale system phase that shipped something durable leaves a compact record in archive/phases/, like a product phase.
3
Side
working the trackers
Tracker-born work that runs alongside other phases — sweeping punch items, exploring an open question, research (a side-phase kind, not a fourth mode), or a verification pass. A side phase usually pulls several tracker items (a sweep), not one — single ≤30-min items wait in the punch list until a sweep collects them. Its board is light: the pulled items, checked off as they land.
Home groundthe code it changes, and its own tracker rows (moving them is the close).
Carefulthe feature docs describing the code it changed — updated at close, last-reviewed bumped.
Gatedgovernance docs, other boards, strategy, tracker restructuring (moving your own rows ≠ reformatting the file), and resuming a paused phase (default answer: no — ask first). Not forbidden: surface it, and the user routes it to the right mode.
›The ritual3 steps to open · 4 to close
Opening ritual
1Open a light board from _side-template.md (mode: side) listing the tracker items pulled — e.g. "Sweep — P87 · P88 · P92" or "Explore §5". Orient: read each pulled item's refs and the feature docs of what it touches before acting.
2Check file-level overlap with the active phases' in-flight edits. If they collide: defer the item, let the other phase settle those files first, or brief the session on the concurrent changes. (A side sweep and an open product phase editing the same file is the failure mode this prevents.)
3Spawned tasks only: declare the files it expects to touch in the spawn prompt (Files: list) so the user can spot overlap before spawning.
During
stay on the pulled items. Meaningful new scope → surface it, don't expand silently. If an item grows a thesis or cross-surface coupling → stop; it's product-shaped — propose resuming a paused phase, opening a new one, or deferring the rest; the user picks.
Closing ritual
1Hand off for verification(in-session closes; spawned/worktree tasks use the PR as the gate). Before deleting anything, present the phase's durable output for the PO's check, shaped to what it produced: code / UI work → each changed surface as a pointer, who's looking → /url → what to expect; research → the doc's summary: + its load-bearing findings to sanity-check, and the tracker/question it answers. Plus the tracker rows being moved, and anything flagged. The board isn't deleted until the PO confirms. (No walkthrough doc — side work is quick; this is its in-chat verification moment.)
2Feature docs whose described behavior changed → updated; last-reviewed bumped on those (§ Doc Tiers → Stamping last-reviewed).
3Its tracker rows moved in the same PR — punch rows removed, §N markers updated, FCs promoted/removed; research lands its doc in strategy/research/ (frontmatter + summary:) and updates the spawning marker. Nothing ends without its trackers moving.
4One focused, mode-pure commit; board deleted (the moved rows + the commit are the record). Spawned/worktree tasks additionally: rebase onto current main before completing (conflicts are the side phase's problem, not the merger's — stale-vs-main work doesn't land), push a remote branch, open a PR as the merge surface.
Rules shared by all modes
·Phase = board while open. A phase opens its board from its mode's template (_product-template.md · _system-template.md · _side-template.md) and closes it in the same arc — usually the same sitting. Boards are always tier: working while open; at close they are distilled and deleted — extraction first (decisions → decisions.md, behavior → feature docs, tracker rows moved), then the file goes; git history is the deep record. Product phases additionally leave a compact record for the timeline.
·The queue is the ROADMAP's What's Next — upcoming planned work of any mode, one mode-tagged list. Every queued row carries a seed (planning/queued/, badged by its mode:) accumulating context until the phase opens. The queue is a staging area, never a gate: something serious can skip it — write the board and kick off directly.
·Trackers hold candidates, not queued work. A tracker note that bloats, or a cluster of connected notes, promotes into a phase — the rows leave the trackers and the board gets a cohesive chunk. Tracker work needed sooner than later gets a seed and/or a board, depending on how soon it'll be picked up.
·Reading is never gated — the touch bands gate pens, not eyes. Every opening ritual has a bounded orient step (read the mode's core set whole; actively align to the emphasized set), and any doc may be pulled freely mid-build. Orientation is align or challenge: new work pressing on an old commitment isn't drift to suppress — it's a structured challenge to raise (§ Doc Tiers), and sometimes the challenge should win. That pressure is how new directions, features, and strategy are born.
·Concurrency — one open board per mode. One product and (when needed) one system board may be open simultaneously; never two boards of the same mode. Side phases run alongside either.
·A change that makes an open walkthrough item inaccurate fixes that item in the same edit — whoever made the change. The rule binds the phase making the change, not the phase that owns the walkthrough, so it reaches across concurrent boards and across modes. Never defer it to the owning phase: a note on your board is deleted at your close, and the stale item outlives it. (Detail: § During a Phase.)
·A phase belongs to one project — the repo its board lives in. The board names that repo at open, and everything outside it is out of bounds for every mode: no edits, no commits, no "while I'm here." A sibling project's problem gets written down and handed to a session running in that project; re-scoping takes a new session there, not a note here.
·One phase per session is the default; a session that legitimately runs several still gives each its own board. Succession is fine — close one, open the next. What isn't fine is reactive work with no board at all. A fix small enough not to earn a board is a punch item (≤30 min, any mode), swept later.
·Commits are mode-pure. A commit serves exactly one board and names it in the message. Never mix product and system changes in one commit.
·Boards work the main working tree — parallelism is between phases, not within one. (Spawned side tasks are the exception: they run in worktrees, per Mode 3.)
·Routing ("where does this go?"): ≤30 min isolated fix → punch list, swept later · focused work, no strategy → side phase · structural thesis or cross-surface coupling → product phase · workflow/doc/dashboard work → system phase · strategic and unresolved → Open Questions · known direction, no trigger yet → Future Considerations.
·The active board(s) render live at /system (Work → Active board), badged by mode.