Authored demo content for a fictional plant-care app, rendered by the same parsers and held to the same invariants as a real project's dashboard. This is the system in use, three months in.
How we work
Work here happens in phases. A phase is any chunk of work — a feature, a rules change, a sweep of small fixes — and its arc is open → build → review → close. The arc runs as a sequence of kinds — each the shape of one session: what it reads, does and leaves, at what level — the phase's plan riding between them on its board, a doc any chat can pick up (§ The phase pipeline). Every step of opening, orienting and closing is a ritual — built into the phase, run by the session and stopping for you where a step says so, yours to reshape. The mode — product · system · side · queue-shaping — sets a phase's focus: what it reads before editing, and what it may touch. Can't name the mode? Just describe what you're holding — the session names the shape with you (§ Session starters). No phase is ritual-free.
Session starters
Every session starts with someone arriving with something, and your part is two choices the chat cannot make for itself: what you're holding, which picks the shape below — the shape sets the mode, and the mode sets the rituals — and the chat's level, set in your tool before you type. Opening a phase runs high. Arriving at a board already opened, its Levels line names the level for the kind its stage: sits at. Queue-shaping and sweeps take what the work honestly needs — your call. Then say the row's line; the session runs the rituals from there, and when its stretch of the arc ends it commits the board and hands you the next opening line — the next kind's, or at a close, the next phase's. No vocabulary yet? Describing what you're holding is enough.
›A new idea nobody is doing yet→Queue-shapingqueue-shaping
"Shape the queue: watering streaks keeps coming up and there's no row for it."
The queue-shaping phase: capture the idea and its context as a row + seed, for phases of any mode — product builds, sweeps, research alike (§ The queue-shaping phase). It ends at the shaped queue: a queued phase launches in its own session, with fresh eyes on the seed. Can't wait? Skip the queue and open a collapsed board directly; a split phase still opens from its seed, which a fresh open chat picks up next.
›The next queued thing, ready to plan→Phase from the queuefrom its seed
"Open [phase name] from the queue."
The open kind: the seed names the mode — product, system or side — and this session verifies the seed, orients, agrees scope and writes the board, Levels line included; row and seed leave the queue. A board with no Levels line keeps this same chat for the whole arc — the collapsed default. One that declares levels ends here at the committed board, and the next kind arrives fresh.
›A pile of small fixes or tracker items→Sweepside
"Run a side phase, sweep: P07 · P12 · §5."
The side phase, in its sweep kind. Tracker-born: pull the items onto a light board and open directly — no queue row needed. A sweep can also be a verification pass over shipped work.
›Something to understand before anything gets decided→Researchside
"Run a side phase, research: explore §2 before we commit."
The side phase, in its research kind. Lands a doc in strategy/research/ and updates the tracker that asked — understanding is the deliverable, not code.
›Friction with the system itself — docs, rules, dashboard→System phasesystem
"Run a system phase: the close ritual keeps missing X."
The system phase itself, no kind. Name the friction and agree the scope before touching anything; system work is always done with the PO.
›Template changes past your marker→Upgradesystem
"Run a system phase, upgrade."
The system phase, in its upgrade kind, on a collapsed board in one chat: read the template's changelog entries past the marker in docs/upstream.md, adopt, adapt or decline each, and set the marker (§ The upgrade kind).
›An open board from an earlier chat→Continuationthe board's
"Continue the [phase name] board."
Not a new phase — the board's own mode carries on, so its rituals are already set. Commit anything stranded first (the session-end rule), then keep working the board.
›A board waiting at its next kind→Kind chatthe board's
"Build the [phase name] board." · "Survey the [run name] run." · "Deepen the [phase name] board." · "Close the [phase name] board."
The queue row's continuation when the board split the phase (§ The phase pipeline): the chat sets the board active and runs the kind its stage: names, at the level the Levels line declares for it — build or basic layer builds, verifying the board as leads; survey walks the whole run with the PO; deepen makes one surface good; close — always a fresh chat — reads the phase's documents cold and runs the close. Each chat's level is fixed at its open.
›Questions, reading, thinking out loud→Not a phase yet—
"How does the watering model work?"
No mode, no board — reading is never gated. The first edit is the line: at it, name the shape that fits and open its board (see the shared rules).
The modes
Concurrency — one open board per mode.Never two boards of the same mode; the light modes (side, queue-shaping) run alongside the heavy ones freely — a queue-shaping phase edits one row and one seed, never the rules.
The queue-shaping phase
Shapes what's next
An idea forms and nobody is doing it yet: capture it while it's fresh — a row on the queue and the seed behind it, holding the context the eventual phase will open from. The routine way work of any mode enters the queue when no phase's own open or close is doing it: add a row and write its seed, split one row in two, reorder what comes next, drop a row the project outgrew. It ends at the shaped queue — the phase launches in its own session, with fresh eyes on the seed.
Reads firstThe indexes, then depth only where the idea touches. Shaping is a search problem, not a comprehension one: you need to know what already exists and where to look, not to hold the rule-set in context.
Home groundThe queue — its rows in the ROADMAP's What's Next and their seeds in planning/queued/ — plus the tracker rows the idea absorbs.
CarefulThe rest of the trackers, swept for overlap rather than restructured. Rows are proposed, never slipped in — the PO owns what lands on the ROADMAP, which is commitments-tier.
GatedThe rules, strategy content, product behavior, and other phases' boards. Suggestions, never decisions, is what separates a shaper from a gate; a rules defect found while shaping is raised, and a system phase lands it.
›The built-in ritual3 opening + 3 closing · 2 stop for the PO
Opening ritualfires at phase open
1with the POOpen the chat with the friction, not the feature — "I keep hitting X and there's no row for it," "these two rows are really one phase" — and agree the scope with the PO: the queue is the PO's ground, so shaping is done with the PO, never solo.
2Open a board from _queue-shaping-template.md (mode: queue-shaping) — a few lines is the right size, and it never carries a Levels line: this mode runs as one chat, always, at whatever level you set at open — the ordinary working tier for straightforward shaping, higher when the idea is tangled or the queue's order is genuinely in question. Then name the chat — set its title from the convention and record it on the board, asking only when the title is not derivable (§ Rules shared by all modes).
3Orient in two tiers. Tier 1 — scan the index: every heading in decisions.md, every FC and open-question title, every punch row's title, the ROADMAP and its queue, plus § Session starters and the rules shared by all modes. Tier 2 — deep-read only what the idea touches, usually two to four entries; leave the rest at their titles. The scan is trustworthy only while absent from the index means absent — a heading that hides its content (an untitled tracker row, an entry named for its phase instead of its call) is a hole in the index, and it gets fixed where it lives rather than read around.
During
shape, and shape actively — sweep the trackers for items the idea absorbs, check the open boards, the queued rows and the strategy shelf for overlap and conflict, propose the shape, mode and kind beyond what the PO arrived with, and push back when the thing isn't phase-shaped at all. Then the bookkeeping: every row added gets its seed in planning/queued/ in the same edit, and every row dropped takes its seed with it — the match between them is checked at build time, so a half-done edit shows up as a drift alarm. Writing a seed is not doing the work; the phase stays on its board. It never settles product strategy — a strategic question found while shaping goes to Open Questions — and wanting to launch the work immediately is the signal it was never queue work: stop shaping and open the phase directly instead.
Closing ritualfires at phase close
1with the POHand off for verification — present the shaped queue (the rows and their seeds) and the canon diff (§ Rules shared by all modes) for the PO's confirm; the ROADMAP is commitments-tier, so a shaped queue is nearly always a canon diff of one hunk. The board isn't deleted until the PO confirms.
2Log to decisions.md only when the reasoning would surprise someone in six months — the rows themselves speak.
3One mode-pure commit, pushed; board deleted (the rows and seeds are the record).
The product phase
Builds the thing
A thesis, the change the phase sets out to make. Then the build, then a walkthrough you drive point by point. The deepest ritual of the four, because this is where the product ships.
Reads firstThe strategy docs, whole. Then whatever this particular phase answers to.
Home groundProduct code and feature docs.
CarefulStrategy docs and roadmap content. Updated when the work genuinely bears on them, never in passing: a walkthrough decision the PO ratified, or a structured challenge when new work presses on an old commitment.
GatedThe rules themselves. CLAUDE.md, this file, the ROADMAP's structure, the /system code. Not forbidden: suggest the edit and a system phase lands it.
›The built-in ritual4 opening + 4 closing · 2 stop for the PO
Opening ritualfires at phase open
1Open the board from _product-template.md (mode: product) with its thesis stated; fold the phase's seed into the board, and remove row + seed per the shared rule (§ Rules shared by all modes). Declare the Levels line — one level per kind the board will run; the open is the open kind's work, and every later kind arrives at what it declares (§ The phase pipeline). A product phase opens from its seed. Arriving without one, shape the seed first — a fresh open chat opens from it.
2Then name the chat — set its title from the convention and record it on the board, asking only when the title is not derivable (§ Rules shared by all modes).
3Orient — run the Opening Checklist (product-lifecycle.md → 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.
4with the POConfirm thesis + scope with the PO — 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 (product-lifecycle.md → During a Phase). When the build commits, the building kind hosts the walkthrough — the PO walks every O/V point, point by point (product-lifecycle.md → Walkthrough); review is the build chat's last stretch, not the close's first.
Closing ritualfires at phase close
1Confirm the walkthrough passed — the building kind hosted it when the build committed (product-lifecycle.md → Walkthrough); the close does not begin until its O list is empty and every V point holds.
2The Closing Checklist (product-lifecycle.md → 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. Here the close kind takes over: fresh eyes at the declared level (§ The phase pipeline).
4Distill + delete — a compact record replaces the board and walkthrough, and the close lands as its own mode-pure commit, pushed.
The system phase
Tends the rules
The docs, the work model, and the dashboard itself. Always done together, never solo. A project built from the template runs one more kind, upgrade, which takes the template's changes in (§ The upgrade kind).
Reads firstThe rules themselves — the standing sections whole, and the ones marked Read when only if this work fires them. The decisions log by its headings, opened where the work touches it.
Home groundThe docs, the rules, the molds, and the code behind the dashboard.
CarefulPrior entries in decisions.md: amend with a new dated entry, and never rewrite one silently — supersede or merge by the dated forms that file states. And ripples into product-facing docs when a rule changes: repoint the references, leave their content alone.
GatedProduct behavior, seeded content, and the content of strategy docs. The boundary is purpose, not file location: system work may touch production code when that code is the system's own surface, never to add or change product behavior. That surface is lib/system.ts and app/system/, plus the styleguide, the tokens and the shared component patterns wherever they live. It never settles product strategy in passing either: a strategic question that surfaces goes to Open Questions rather than being decided here. Not forbidden: suggest it and a product phase lands it.
›The built-in ritual4 opening + 6 closing · 2 stop for the PO
Opening ritualfires at phase open
1with the POName the friction this phase fixes, and agree the scope with the PO — system work is always done with the PO, 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). Declare the Levels line in the same breath — one level per kind; the open is the open kind's work, and build and close arrive at what it declares (§ The phase pipeline). Declaring levels means this phase opens from a seed; collapsed, it opens direct from the friction.
3Then name the chat — set its title from the convention and record it on the board, asking only when the title is not derivable (§ Rules shared by all modes).
4Orient by trigger, not by list. Read this file whole except the sections carrying a Read when: line — those are read only when their moment fires, and this work's may (§ Frontmatter maintenance). Every other governance doc is read when its own frontmatter read-when matches the work, implementation/system-surface.md included; CLAUDE.md was read at session start, which is its ritual, and is not read twice. Then scan decisions.md by its headings, deep-reading only the entries this work touches, and check the doc tiers — the log is lookup context, not standing context, and reading every settled call cold is not what aligns a phase. Both scans carry the same honest-index caveat as the queue-shaping phase's orient (§ The queue-shaping phase). Reopening a settled call is a structured challenge (§ Doc Tiers), not a silent rewrite.
During
keep it lean — a system pass adds to the rule-set only to close a gap or a contradiction, and names which on its board; otherwise it leaves the rule-set the same size or smaller. Silence and self-contradiction are what prose has to fix; everything else that grows the rules is bloat carrying a rationale. ("Rule-set" = the governance docs: this file and CLAUDE.md.) Log decisions in decisions.mdas they're made (this mode writes there directly). When the build commits, the build kind hosts the walkthrough (product-lifecycle.md → Walkthrough, from _walkthrough-template.md) — standard for system phases: delegated execution needs explicit review, and the sharpest defects come from the review surface.
Closing ritualfires at phase close
1with the POHand 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 canon diff (§ Rules shared by all modes), the surface/build state (/system renders, drift alarms silent), and anything worth a second look. The board isn't deleted until the PO confirms. (The walkthrough reviewed the work during the build; this handoff ratifies the record.)
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, and pushed.
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.
The side phase
Sweeps the small stuff
Small logged fixes, an open question, a research pass. Tracker-born work that runs alongside the other phases, usually several items at once (a sweep) rather than one. Runs as one chat, always — one kind, sweep or research, and never split (§ The phase pipeline). If an item grows a thesis it stops, because that is product work now.
Reads firstThe items it pulled, and the docs for the code they touch.
Home groundThe code it changes, and the tracker items it pulled.
CarefulThe feature docs describing the code it changed. Updated at close, last-reviewed bumped.
GatedThe rules, other boards, strategy, and tracker restructuring (moving your own items is not reformatting the file). Resuming a paused phase is gated too, and the default answer is no: ask first. Not forbidden: surface it and the PO routes it to the right mode.
›The built-in ritual3 opening + 4 closing · 1 stop for the PO
Opening ritualfires at phase open
1Open a light board from _side-template.md (mode: side) listing the tracker items pulled — e.g. "Sweep — P87 · P88 · P92" or "Explore §5". Then name the chat — set its title from the convention and record it on the board, asking only when the title is not derivable (§ Rules shared by all modes). 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 PO 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 PO picks.
Closing ritualfires at phase close
1with the POHand 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 canon diff (§ Rules shared by all modes — "none" is the common case here), 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). Load-bearing calls → decisions.md — a side phase leaves no archive record, so the log is the only place a call it made can survive its board.
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, pushed; 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.
Read whena board carries a Levels line — you're writing one at a phase open, or you're a chat picking up a board at the kind its stage: names.
A phase is a board passing through kinds in order, and a kind is the shape of one session: what it reads, what it does, what it leaves behind, and the level it runs at. Each chat holds one capability level, fixed at open, because switching model or effort mid-chat degrades the work — where the level changes, the chat changes. The change is a seam, and a seam is a kind's close followed by the next kind's open: the outgoing chat commits the board, sets it waiting, advances stage:, pushes, and hands you the next kind's opening line (§ Session starters). Your part is the segmenting; every ritual is built into the kind and runs on its own. Small work skips the seams: a board with no Levels line runs its kinds in one chat, in order — the kinds are still the steps. The mode sets the sequence: product runs open → build → close on its own and open → basic layer → survey → deepen → close inside a run; system runs open → build → close; side runs one kind, sweep or research, in one session; queue-shaping runs one, and shaping a run is its second shape. The six kinds, each at the level the board declares:
Product (on its own)
Open
Build
Close
Product (in a run)
Open
Basic layer
Survey
Deepen
Close
System
Open
Build
Close
Product (on its own · in a run) · SystemOpenhighopens the phase: verifies the seed, orients on the mode's set, agrees scope and thesis with the PO, writes the board — stage, status, run declared, the Levels line sizing every kind downstream and the close's read (which Read when: triggers it is expected to fire) — and on a run board writes Considered: the alternatives and challenges weighed before building — and the run's picture (planning/<run>-picture.md). Sizing is ratified beside "Scope agreed with the PO." Open stays the sizing authority afterwards: raises come back to it, and it amends the board for whatever has not opened yet.
Product (on its own) · SystemBuildstandardbuilds a standalone phase: verifies the board at open the way any session verifies a seed — leads to re-check, licensed to challenge — writes the walkthrough with evidence attached as it builds, and hosts the PO's run-through. It never changes its own level: work too big for the level is a raise.
Product (in a run)Basic layerstandardbuilds the first pass of every surface a run board names, and stops at basic: the surfaces exist, the main flow works end to end on seeded data, the real content is in, the layout is a first draft and stays one. Its walkthrough carries flow- and feature-level O items only; the V items it writes move to the board's Deepening section unwalked. A new idea mid-build goes to Deepening too — never into the current kind. Clear this kind across the run before the survey opens.
Product (in a run)Surveyhighreads every board in the run and walks the whole with the PO as each audience, building nothing: directions, features and alternatives are its O items, and the run board's walkthrough holds its decisions. It drafts the shown/launch/later table on the run board, writes each member board's Deepening section — what makes that surface good, with the deferred V items under it — and may send a board back to basic layer or open a new one into the run.
Product (in a run)Deepenstandardmakes one settled surface good, one board at a time. It reads the board and its Deepening section, the survey's decisions, the feature docs it touches, the Vision, and the decisions log by its headings — the shelf stays a free pull, and a deepen chat that finds itself pressing on strategy raises it rather than editing. Full walkthrough: V items walked, device-tested.
Product (on its own · in a run) · SystemClosehigh, always a fresh chatknows the phase only from its paper — board, walkthrough, decisions entries, the diff. It reads the project context cold, raises misalignments, proposes the distillation, and runs the close; the PO ratifies. A member board closes when its deepen walkthrough passes; the run board closes last, with the compact record for the whole. A phase that cannot be distilled from its documents had an insufficient record, and that is itself a finding. Close may read past its declared triggers when evidence leads there — bands gate pens, not eyes — and reports the divergence, so the sizing miss reaches open as feedback.
The run
many boards, one bound
A run is many small boards moving through the kinds together, inside a stated bound. One product board per chunk, each carrying run: with the run's name and stage: with the kind it sits at; the run board is one more board from the product mold, named after the run — that name is how a surface tells it from the members — holding the thesis of the whole, Considered, the shown/launch/later table and the member list, with no workstreams of its own — and its picture: planning/<run>-picture.md, from _run-picture-template.md, linked from the board's Picture: line and written by the open kind — the loop the run builds, the aspirational site map, and who owns which parts, a reading aid whose every fact has a home elsewhere. The default is to clear a kind across every board before any advances — build the basic layer of everything first, survey once, then deepen — and it is a default, not a gate: a board drops back a kind by editing its stage:, and new work joins as a new board at basic layer.
›A paused member does not block the run, and is not silent either
the next kind's open raises it — the survey already reads every board in the run — and the run advances past it deliberately or not at all. The raise is what makes it deliberate. One board is active per mode at any moment and the rest of the run sits waiting or paused; a session that picks one up sets it active first.
›The run board is the spine of its members, not a competitor for that slot
the slot counts sessions, and the run board hosts one only at its own kinds — its open, its survey and its close. So it sits waiting while any member is being worked, and a run between kinds, with every member waiting too, has none active — a real state, not a gap in the record. Shaping a run — the rows, their seeds, the kinds each will run, the bound — is the queue-shaping phase's work (§ The queue-shaping phase); a run's boards open together in one open chat, or one at a time as the run grows.
›The run's close reconciles the picture before deleting it
the aspirational site map against the derived one (/system/site, read from the routes directory) — what exists in both is done; what only the aspiration holds goes to the queue, to Future Considerations, or is dropped with a note in decisions.md. The loop map is lifted to a durable authored home — the vision, or the feature doc for the flow it draws — never deleted; then the picture doc goes with the run board.
›A collapsed phase that outgrows small splits at the seam
The tell is a decision turning into a build. The collapsed chat has already done open's work — seed verified, orient run, scope agreed, board written — so it raises the change with the PO, amends the board with a Levels line, commits, and hands over the next kind's opening line; the chats from there carry the kind-led titles.
›Every close leaves the pipeline feedback
Three questions shape the next chunk of work rather than the pipeline's fate: does under-sized work sail through unraised · does open's spot-check earn its keep · and, from a collapsed phase, did its arc run without ceremony a split would have needed. The first two are every close's to answer; the third is only a collapsed close's, because a split phase has no evidence about collapsing (decisions.md 2026-08-26).
›Subagents stay inside a chat
A session fans mechanical stretches out to subagents on its own — a build chat's workers, an open or close chat's reading sweeps — and that is the session's call, never a step you take. The boundary: anything the PO must converse with is a chat; a subagent is dispatched and judged by its chat, inherits its bands, and runs at or below its level.
›Escalation is notes up, never self-upgrade
No chat changes its own level. A build chat raises; open rules — amend the board, or continue the kind in a fresh chat at the new level. Every handoff crosses by commit: the board at open's close, the build and walkthrough before review, verdicts on the doc before close runs. Not on the doc = did not happen.
›Review reviews evidence, never narrative
A walkthrough item links its proof — command output, a diff hunk, a verify run, a screenshot — never a claim about it; a coherent story about broken work passes any review that reads only the story. Verdicts are written on the walkthrough, one writer per lane: open rules per item — pass · query · fail · escalate — and on a build chat's challenges — accepted · declined with reason · escalated; close states its findings — defect (back to the building kind, which means the board goes paused at the kind that owes the work — that is how "back to" becomes a state rather than a sentence; a session draining a ## Raised entry owed to a kind the board has already passed reaches the same verdict and sets the same state, which is why that case needed no trigger of its own) · plan error (open + PO) · out-of-scope (a suggested seed — the PO owns rows) · clear. The PO's run-through stays load-bearing throughout.
›Crossing a seam is one sentence
The outgoing chat closes its kind — commits the board, sets it waiting, advances stage:, pushes — and hands you the next kind's opening line, so you never have to spot the seam yourself. Open a fresh chat at the level the board declares for that kind and say the line: "Build the [phase name] board." · "Survey the [run name] run." · "Deepen the [phase name] board." · "Close the [phase name] board." (§ Session starters). The sentence is all you say: the new chat reads the briefing at session start, then the board, sets it active, and runs its kind's ritual from the canon on its own — starting by setting its own title, because a kind chat's title is knowable at its open and at no earlier moment (§ Rules shared by all modes). The rituals are the session's job, not steps you carry in your head, and yours to reshape (§ Adjustments) when they stop fitting.
›Sizing the levels
Open declares them, in the project's tier words, one per kind the board will run: open high · build standard · close high, or for a run open high · basic layer standard · survey high · deepen standard · close high. The judgment-dense kinds — open, survey, close — run high; the building kinds take what the work honestly needs — the ordinary working tier for most builds, the cheap tier only when the stretch is truly mechanical, and mechanical stretches mostly belong to subagents anyway; close runs at or above the kind before it. Unsure? Size up: an under-sized chat can only raise what it notices.
›Levels are named in the project's own tier words, never as models
The mapping from tier to model or effort belongs to the project's briefing file (CLAUDE.md here), because the rituals ship to any harness. Seeds carry an expected-weight note so the PO can size the open chat before starting it.
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 · _queue-shaping-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.
›No canon change lands unratified — the canon diff.
Before a board is deleted, the phase gathers every change it made to bedrock- and commitments-tier docs (CLAUDE.md included) and walks the PO through it, hunk by hunk — the doc-tier analog of the walkthrough. It runs inside the system and side phases' verification handoff, and as its own step before the product phase's distill-and-delete. Most hunks are quick confirms of calls the PO already drove; the step exists to catch what nobody decided. "None" is a valid answer for a phase that touched no tiered doc.
›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 a collapsed board and kick off directly.
›Every phase maintains its own footprint in the queue — nobody maintains anyone else's — and every phase reads the rest.
At open, a phase removes its own row and deletes its seed, whatever its mode: the queue is future-only, and the open board is that phase's pointer, so a row left behind double-counts. Then it scans what's left — the remaining rows and their seed ledes — because what is downstream changes how you build for it, not just what you queue after. A row and its seed are written as the idea forms, mid-phase — the moment the work throws off something committed, phase-sized and not this phase's job — so the close confirms rather than discovers. At close, the phase writes the rows its work created that it has not already written — row and seed together, always, because the match between them is a build-time invariant — and appends a dated note to any existing seed its work bore on. A seed accumulates only when something prompts it; this is the prompt, and without it the queue is written at close and read by nobody. Three guardrails hold mid-phase too: row and seed land in the same edit; writing a seed is not doing the work, and the phase stays on its board; and the PO owns what lands on the ROADMAP, which is commitments-tier, so a row is proposed, never slipped in. Shaping the queue at any other time — adding work nobody is doing, reordering, dropping a row the project outgrew — is a queue-shaping phase (§ The queue-shaping phase). An unowned queue rots; this is who owns it.
›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.
›A change that makes a ROADMAP current-state claim inaccurate fixes it in the same edit, whoever made the change.
Those claims — in Where We Are as much as in What's Next — belong to no board, so nobody else will. Every mode may make this correction, even where the text is otherwise gated ground: repointing a line your own work invalidated is mechanical, and the alternative is a rule nobody is permitted to obey. Never defer it — a note on your board is deleted at your close, and the stale text outlives it. Re-orienting the ROADMAP's direction is not covered and stays where it was. Another board's walkthrough is not yours to edit: raise what you noticed and the PO routes it, and its owner re-reads at close (product-lifecycle.md → Closing a Phase, step 1). (Detail: product-lifecycle.md → During a Phase.)
›Every chat serving a phase names itself, and the board records each title.
A session can set its own title — the harness exposes a rename to the session it runs — so at the moment the title is known, right after the board is created or at a kind's chat open, the session sets it from the convention, records it on the board, and says in one line what it chose. It asks only when the title is not derivable: no phase name yet, a harness with no rename the session can reach, or a title the PO set by hand that the harness will not replace unasked. Then the ask is its own prompt, carrying the proposed title so it can be copied — yes, renamed · no, I named it: [title] · skip — and the session waits for the answer. The title is Phase name · mode for a collapsed board, and kind · Phase name · mode for each chat of a split phase — the kind leads because it is the PO's which-chat-am-I-in cue when several of one phase are open, and the mode trails because it matters most to the agent, which reads it from the board anyway. Whoever set it, the board records the title beside the kind that carried it. Session identity lives in the harness, not in git; the board's lines are the only place the record can say which chats ran the phase.
›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.
›Session end commits the board, and pushes it.
A session that ends mid-phase — deliberately or with the chat force-closed — commits the open board as it stands, code ready or not, and pushes: a committed board nobody can see is still stranded work. A board is a doc: committing it is mode-pure and costs nothing, and it is the difference between a phase that survives its chat and work that strands. A session that finds stranded work commits and pushes the board before anything else.
›Push is the publish trigger.
The deploy rebuilds the record from every push, so pushing is publishing where things stand. The smallest push worth naming is the status push: commit the record alone — board, trackers, ROADMAP — and push. One gesture that puts the state of the work on the record without shipping half-finished code. Session end's board commit is its natural companion.
Boards work the main working tree — parallelism is between phases, not within one. (Spawned side tasks are the exception: they run in worktrees, per the side phase.)
›One phase per session is the default — and no board, no pen.
The pipeline multiplies sessions per phase, never phases per session: a kind chat is still one phase's session. A session that legitimately runs several phases still gives each its own board; succession is fine — close one, open the next. A session that only reads or talks needs no phase at all — but the first edit is the line: before touching code or docs, stop, name the shape that fits (§ Session starters), and open its board. Filing a tracker row stays free — capture between phases is what trackers are for. A fix small enough not to earn a board is a punch item (≤30 min, any mode), swept later.
›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 · committed, phase-sized, not this phase's job → a row and seed on the queue · 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 — and by export or upgrade where the board's Exports or Upgrade line names one, since those tune the mode's rituals.
›The partsthe model is a kit — every part is yours to reshape
This model is built from five parts, and every one of them is yours to reshape. That is the difference between adopting a method and owning a system: a part you can explain is a part you can change. Each part below says what it is and what defines it; what you can do with them — change them included — is § Adjustments, just below.
Phase
The unit of work — any chunk of work run through the rituals, in exactly one mode. Opens as a board, closes by distill + delete.
PropertiesA mode (or a kind within one) · a goal or thesis · an orient set (what it reads at open) · touch bands · an opening and closing ritual · a board template · declared chat levels, when its board carries a Levels line (§ The phase pipeline).
Mode
A phase's flavor — the setting that fixes every property at once. Four ship: the product phase (builds the thing), the system phase (tends the rules), the side phase (sweeps the small stuff), the queue-shaping phase (shapes what's next).
PropertiesPurpose · the touch bands · opening ritual · during-rules · closing ritual · a board template (phases/_*-template.md) · the sequence of kinds its boards pass through — each kind the shape of one session, with its own open, close, reads and level (§ The phase pipeline): product runs open → build → close, or open → basic layer → survey → deepen → close inside a run; system runs open → build → close; side runs sweep or research in one session; queue-shaping runs one, shaping a run included.
Ritual
A named set of steps bound to a trigger. No phase is ritual-free — and rituals are not phase-only: session start and session end run rituals too.
PropertiesA trigger · the steps · what it reads · what it leaves behind (a board, a commit, a handoff).
Trigger
The moment a ritual fires. Six exist here, each naming what it fires: phase open (the mode's opening ritual) · phase close (the mode's closing ritual) · session start (reading CLAUDE.md — that is its ritual) · session end (commit and push the open board — see the shared rules) · push (the publish — see the shared rules) · kickoff (the run-once bootstrap — § The Kickoff).
PropertiesThe event · the ritual bound to it · who runs it — you, the agent, or the build.
Band
The edit permission a phase carries for each doc family: home ground (edit freely) · careful (deliberate, never in passing) · gated (another mode's ground — suggest, don't edit). Bands gate pens, not eyes: reading is never gated.
PropertiesThe three bands · each mode's mapping of docs to bands — the three band lines in its mode section.
›Adjustmentsallowed, never required
None of these are things you should do. They're things the model won't break under, when you want them — each names the moment you'd want it. Make the change deliberately: edit the section that owns it, commit, and check that /system/method renders your version. The standing warning cuts both ways — a rule that no longer fits how you work is drift already; you're just the one obeying it.
You keep opening the same shape of work and it has no namename it as a kind. The test is threefold: it recurs, it differs at open or close (its own opening line or its own deliverable), and it lives inside the mode's rituals — tuning a step for the kind is fine (the research kind landing its deliverable in strategy/research/ is the worked example); needing its own template, badge or band lines is a mode argument, not a kind. Then it's a sentence in the host mode's Purpose and a row in § Session starters.
You want something to happen at a moment nothing firesbind a ritual to a trigger: write the steps where the person acting on them will read them. The session-end rule entered the model exactly this way.
A ritual step keeps getting skipped, or costs more than it catchesedit or delete it in place; the numbered lists render as written. Chronic skipping is data: enforce the step or remove it deliberately, but don't keep obeying a rule you've already abandoned.
A mode's ground doesn't match who actually edits whatre-draw its band lines. The one rule worth keeping whatever you draw: reading is never gated.
The boards don't record what you actually want to rememberedit the molds (phases/_*-template.md); every new board inherits the change.
You want a fourth modethe one change that costs code: a heading in the parsed shape, a board template, and a parser change (getWorkModel in lib/system.ts). Weigh a kind first; it's nearly always enough.
A settled rule has stopped fittingreopen it deliberately: a structured challenge (§ Doc Tiers), logged win or lose. The model applies this to itself.