@wemuda/launchrail 1.12.0 → 1.13.0

package/README.md

@@ -34,6 +34,8 @@ This repository is the Launchrail **toolchain**: the CLI, the workflow skills (s
 
 Launchrail structures development as two movements. The **foundation** runs once per project: it turns an idea into hard constraints and recorded decisions. Then the **delivery loop** takes over — once per feature: size the work and plan it only as deeply as it needs (a small change goes straight from a grill to tickets; a larger one adds `launch-wayfinder`, a spec, and design validation first), then hand the tickets to the built-in **Ralph loop** to implement and verify before going around again for the next feature. Every stage leaves a committed artifact behind, and the next stage starts from that artifact, not from chat memory. Two commands cover the rail: **`/launch`** plans — it reads the committed artifacts, detects where the project is, and routes to the stage's owner — and **`/launch-implement`** builds, driving ready tickets to verified merges.
 
+You experience the rail as **six phases** — Intent → Exploration → Decisions → Blueprint → Build → Ship — with a fixed **rail banner** rendered at every transition: where you are, what just finished, what happens now, and the one next command. And planning runs under a hard **interaction contract** ([ADR-0029](https://github.com/wemuda/launchrail/blob/master/docs/adr/0029-planning-interaction-contract.md)): every uncertainty is labeled and only the questions that are genuinely yours reach you — at most three per round, about six decisions per session, with a checkpoint every two rounds (continue / prototype / defer / build). Reversible engineering details become recorded agent defaults instead of questions, approved prototypes are treated as decisions rather than feature inventories to trim, and planning stops when the next slice can be built safely — not when every question is answered.
+
 <p align="center">
   <img src="https://github.com/wemuda/launchrail/raw/master/assets/how-launchrail-works.png" alt="How Launchrail works — the foundation runs once per project (Vision → Visual exploration → Discovery research → Complexity grill → Technical research → Architecture decisions); the delivery loop then repeats once per slice (Specify features into tickets → Ralph loop → Verification) before looping back for the next slice." width="880" />
 </p>

package/assets/skills/launchrail/launch/SKILL.md

@@ -1,11 +1,13 @@
 ---
 name: launch
-description: The planning conductor and single entry point to the Launchrail loop. Detects how far a project has moved from idea toward release — setup, vision, visual exploration, discovery, grill, research, ADRs, spec, design validation, tickets — then runs or routes to the stage that owns the next step, and hands implementation to /launch-implement. Once the foundation exists it also sizes each new feature (large / semi / small) and routes the planning subset that size needs. Use to start or continue the workflow, ask what stage a project is at, size a new feature, or jump straight to a named stage.
+description: The planning conductor and single entry point to the Launchrail loop. Detects how far a project has moved from idea toward release — setup, vision, visual exploration, discovery, grill, research, ADRs, spec, design validation, tickets — then runs or routes to the stage that owns the next step, and hands implementation to /launch-implement. Reports position as six phases with an explicit rail banner at every transition. Once the foundation exists it also sizes each new feature (large / semi / small) and routes the planning subset that size needs. Use to start or continue the workflow, ask what stage or phase a project is at, size a new feature, or jump straight to a named stage.
 ---
 
 # Launch — the loop conductor
 
-One command for the whole rail. You are the **conductor**, not a stage: find where the project sits, then run or hand off to the skill that owns the next step. Every stage has exactly one owner; [`workflow.md`](workflow.md) is the contract for who owns what and for the conductor rules — compose owners by name, gate on committed artifacts, prepare handoffs for user-typed stages, keep detection read-only. Follow those rules; this file only tells you how to route.
+One command for the whole rail. You are the **conductor**, not a stage: find where the project sits, then run or hand off to the skill that owns the next step. Every stage has exactly one owner; [`workflow.md`](workflow.md) is the contract for who owns what, for the phase view and rail banner, for the interaction contract, and for the conductor rules — compose owners by name, gate on committed artifacts, prepare handoffs for user-typed stages, keep detection read-only. Follow those rules; this file only tells you how to route.
+
+**You are also the handrail.** The user sees the rail as **six phases** — Intent (stages 0–1) → Exploration (2–3) → Decisions (4–6) → Blueprint (7–9) → Build (10) → Ship (11–12) — and every time you orient, route, or resume, you render the **rail banner** from `workflow.md`'s phase view: phase m of n, Done / Now / Next / Later, one `➤` next action. Stages are your working vocabulary; phases and the banner are the user's. Never replace the banner with loose prose.
 
 ## The stage map
 
@@ -41,7 +43,7 @@ Once the foundation exists (a real vision, ADRs beyond the template) and the use
 | **Semi** | Self-contained feature, some design surface, a handful of tickets | grill → `launch-spec` → design validation *(optional)* → `launch-tickets` |
 | **Small** | Well-understood change, little or no design surface, one or few tickets | grill → `launch-tickets` |
 
-Judgment calls: the grill here is feature-scoped (same `launch-grill`, narrower brief); discovery earns a place only when the feature opens genuinely new tech territory — a vendor category or storage engine the project hasn't used; design validation is for real UI surface; a genuine architecture decision gets an ADR before tickets. Between two sizes pick the smaller — it's cheaper to add a stage than to over-plan a small change. Every size ends at `/launch-implement`.
+Judgment calls: the grill here is feature-scoped (same `launch-grill`, narrower brief); discovery earns a place only when the feature opens genuinely new tech territory — a vendor category or storage engine the project hasn't used; design validation is for real UI surface; a genuine architecture decision gets an ADR before tickets. Between two sizes pick the smaller — it's cheaper to add a stage than to over-plan a small change. Every size ends at `/launch-implement`. The sized path is also the feature's **banner path**: its phases are counted against that path (a semi feature's grill opens as "Phase 1 of 3: Decisions"), so progress reads against what will actually happen, not the full foundation rail.
 
 A feature that arrives **design-first** — a dropped zip or folder of Claude Design artboards, "here is the prototype of X" — routes through `launch-design-handoff` before sizing: it commits the package under `docs/design/<slug>/` and proposes a size; sizing then consumes its `handoff.md` as the feature brief, the grill takes the doc's open questions as its agenda, the spec cites the package as its UX/UI reference, and design validation usually becomes a recorded skip citing it.
 
@@ -49,15 +51,15 @@ A feature that arrives **design-first** — a dropped zip or folder of Claude De
 
 1. **Did the user name a stage or a feature?** A stage keyword (below): sanity-check its inputs exist, offer the earlier stage if one is missing, but honor the jump if they insist — then invoke or hand off and stop. A new feature on a founded project: size it (above) and run the path.
 2. **Otherwise orient, then find the frontier.** A cheap read-only look first: `git status`, current branch, recent commits — is something already in flight for the stage you're about to start? If the tracker is configured and reachable, read the live discussion on relevant tickets and PRs, not just titles; skip what isn't there (orientation sharpens routing, never gates it). Then close stage-0 gaps yourself without asking (init, commit init output, `sync` — it seeds `docs/agents/` too). Walk stages 1 → 12 and stop at the first whose "done when" fails, skipping only what the vision's non-goals record as deliberately skipped. `origin: existing` with no real vision → route to `launch-project-alignment`, not a blank vision.
-3. **Confirm the read.** Say where you think the project is and why — which artifacts you found and which you didn't. Ambiguous signals (template-only vision, several specs) are questions, not guesses.
+3. **Confirm the read — with the banner.** Render the rail banner for the position you detected, then say why — which artifacts you found and which you didn't. Ambiguous signals (template-only vision, several specs) are questions, not guesses.
 4. **Route.** Invoke the owner by exact name, or prepare the handoff for a user-typed stage (†). For stage 7, name the authoritative inputs in order; if the stack isn't stood up yet, tell it to name its seams but leave harness mechanics to the foundation work. For stage 10, hand over `/launch-implement` — never start it yourself.
-5. **Leave an explained map.** Current stage, the next one with a sentence on what it does and whether it's optional here, then the rest of the arc to the destination — and that any stage is reachable by keyword. A bare stage name reads as a turnstile; explain, don't gate.
+5. **Close every transition with the banner.** When a stage finishes or a handoff is prepared, re-render the banner — the just-closed artifact under Done, the next mover under Now, the `➤` line carrying the one next action (the exact fully-argumented command when the stage is user-typed). Add a sentence on what the next stage does and whether it's optional here, and that any stage is reachable by keyword — a bare stage name reads as a turnstile; explain, don't gate.
 
 ## Stage keywords
 
 Case-insensitive direct jumps:
 
-- `status` / `where` — report the detected stage and stop.
+- `status` / `where` — render the rail banner for the detected position (with the evidence) and stop.
 - `next` — detect the frontier and drive it (the default).
 - `setup` / `init` — 0 · `align` / `adopt` — the existing-project on-ramp · `vision` — 1 · `explore` — 2 · `discovery` / `landscape` — 3 · `grill` — 4 · `research` — 5 · `deep-research` — 3→5 · `adr` / `architecture` — 6 · `spec` — 7 · `design-validation` / `validate` — 8 · `tickets` — 9 · `implement` / `build` / `ralph` / `loop` — hand over `/launch-implement` · `verify` / `smoke` — 11 · `release` — 12 · `handoff` / `design-handoff` — the design→code on-ramp (`launch-design-handoff`).
 - `feature` / `size` — size a described feature (recommend a path; route on request).

package/assets/skills/launchrail/launch/workflow.md

@@ -1,6 +1,6 @@
 # The Launchrail core workflow
 
-How a project moves from idea to verified, released software through committed artifacts. The rail is one complete, self-contained skill set — every stage owner is a Launchrail `launch-*` skill, written to the rail's artifact contract ([ADR-0020](https://github.com/wemuda/launchrail/blob/master/docs/adr/0020-independent-skill-set.md); several absorb methodology from [Matt Pocock's skills](https://github.com/mattpocock/skills), credited in `NOTICE.md`). The stage table below is the contract for which skill owns which stage and what artifact it must leave behind, and the conductor rules further down are the contract for how the `launch` conductor (and any agent working the rail) behaves between stages.
+How a project moves from idea to verified, released software through committed artifacts. The rail is one complete, self-contained skill set — every stage owner is a Launchrail `launch-*` skill, written to the rail's artifact contract ([ADR-0020](https://github.com/wemuda/launchrail/blob/master/docs/adr/0020-independent-skill-set.md); several absorb methodology from [Matt Pocock's skills](https://github.com/mattpocock/skills), credited in `NOTICE.md`). This document carries four contracts: the **phase view** (what the user is shown), the **stage table** (which skill owns which stage and what artifact it must leave behind), the **interaction contract** (how any stage spends the user's attention — ADR-0029), and the **conductor rules** (how the `launch` conductor, and any agent working the rail, behaves between stages).
 
 ## Running it
 
@@ -9,6 +9,45 @@ Two commands cover the whole rail:
 - **`/launch`** — plan. It detects which stage the project has reached from its committed artifacts and runs or routes to that stage's owner; it takes a stage name (`vision`, `discovery`, `design-validation`, …) to jump straight there, and it sizes each new feature once the foundation exists ([ADR-0009](https://github.com/wemuda/launchrail/blob/master/docs/adr/0009-launch-orchestrator-skill.md), [ADR-0018](https://github.com/wemuda/launchrail/blob/master/docs/adr/0018-implement-front-door.md)).
 - **`/launch-implement`** — build. The single entry point for stage 10: it drives ready tickets to verified merges through the project's selected loop — the whole frontier, a spec's tickets, the next N ("max 5"), or one ticket at a time.
 
+## The phase view — what the user is shown
+
+The rail's internal machinery is thirteen stages, and stages, tickets, rounds, frontiers, and fog are all real concepts — but they are *the agent's* working vocabulary, not the user's progress model. "Stage 7 of 12" tells a user nothing about how far they are from using their product. So the rail is **presented as six phases**, each answering one plain question ([ADR-0029](https://github.com/wemuda/launchrail/blob/master/docs/adr/0029-planning-interaction-contract.md)):
+
+| Phase | Name | Answers | Stages inside |
+|---|---|---|---|
+| 1 | **Intent** | What are we building, for whom, and what would prove it? | 0 Setup · 1 Vision |
+| 2 | **Exploration** | What should it feel like, and what options exist? | 2 Visual exploration · 3 Discovery |
+| 3 | **Decisions** | Which risks and choices must be settled before building? | 4 Grill · 5 Research · 6 ADRs |
+| 4 | **Blueprint** | What exactly is the next slice, and is it right on screen? | 7 Spec · 8 Design validation · 9 Tickets |
+| 5 | **Build** | Does it work, end to end? | 10 Implementation |
+| 6 | **Ship** | Is it proven and released? | 11 Verification · 12 Release |
+
+Stages stay the normative contract — ownership, artifacts, and gates are all stage-level, and nothing below changes meaning. Phases are the *legibility layer*: every report of position, every transition, and every session close is phrased in phases first, stages second. A sized feature walks a subset of the rail, so its banner counts the phases **on its own path** (a semi feature's grill → spec → tickets is "Phase 1 of 3: Decisions" for that feature), exactly as the foundation counts all six.
+
+### The rail banner
+
+Every transition on the rail is announced with the same fixed banner — a fenced block, never loose prose — so "where we are" and "where we're going" are legible at a glance. Render it whenever position is reported or changes hands: when the conductor orients or routes, when a stage skill closes, and at the end of any session summary. The banner reflects the frontier **at the moment it renders** — a stage that just closed appears under Done, and Now points at the next mover.
+
+```
+🛤️ <path> — Phase <m> of <n>: <phase name>   ·   stage: <current stage>
+Done:  <phases/artifacts behind you — compact, ✓-marked>
+Now:   <the stage in motion and the artifact it leaves behind>
+Next:  <the stage after that, one clause>
+Later: <the remaining arc, arrows — plus any majors deliberately deferred>
+➤ <the single next action — the exact command when the user types it>
+```
+
+`<path>` is `Foundation` or the feature's name; `<n>` counts the phases on that path. The `➤` line carries exactly one action — a fully-argumented command for a user-typed stage, or what the agent does next. Never bury the banner's content in prose instead of rendering it: the block *is* the handrail.
+
+### Session summaries
+
+A planning session (a grill, a wayfinder ticket, an interview) closes with the banner **plus a summary of exactly four blocks** — nothing else:
+
+- **Locked** — decisions made, one line each with the why.
+- **Provisional** — defaults the agent chose and recorded as changeable (see the interaction contract); revisiting one later is cheap and expected.
+- **Deferred** — questions parked with the trigger that reopens them.
+- **Next command** — the one thing to type (or the one thing the agent does next).
+
 ## Prerequisites
 
 - The repository is initialized (`npx @wemuda/launchrail init`) and healthy (`npx @wemuda/launchrail doctor`). Init writes the workflow skills, the implementation loop's materials, *and* the `docs/agents/` configuration (issue-tracker conventions and domain-doc rules, seeded from the manifest's answers) — there is no separate install or setup step on the golden path.
@@ -35,7 +74,7 @@ Two commands cover the whole rail:
 Stage notes:
 
 - **Stages 3 → 4 → 5 are one arc** (`deep-research`): discovery *diverges* — it maps the real option space for the vision's hard parts (all the auth vendors, not one) and never picks winners; the grill *converges* — it narrows that landscape into constraints; research de-risks what survives. Don't collapse discovery into the grill unless the vision's non-goals record the skip: a grill with no discovery narrows whatever stack was assumed upstream, the exact failure discovery exists to prevent ([ADR-0015](https://github.com/wemuda/launchrail/blob/master/docs/adr/0015-discovery-research-stage.md)).
-- **Stage 4 ends in a committed file, always.** `launch-grill` closes its interview by writing the surviving constraints to `docs/research/` — the conversation alone never closes the stage, and the skill treats the committed doc as part of its own contract.
+- **Stage 4 converges far enough to build, not exhaustively.** The grill's stopping rule is build-safety — the decisions the next slice depends on are locked or safely defaulted — never an empty question tree: product design is generative, and "everything answered before implementation" is not a reachable state ([ADR-0029](https://github.com/wemuda/launchrail/blob/master/docs/adr/0029-planning-interaction-contract.md)). "Nothing silently assumed" still holds, but it means every open question is *labeled and parked*, not answered. And stage 4 ends in a committed file, always: `launch-grill` closes its interview by writing the surviving constraints to `docs/research/` — the conversation alone never closes the stage, and the skill treats the committed doc as part of its own contract.
 - **‡ The stage-7 spec's home follows the tracker** ([ADR-0025](https://github.com/wemuda/launchrail/blob/master/docs/adr/0025-spec-home-follows-tracker.md)), exactly as stage-9 tickets do. On a real tracker (GitHub, GitLab, Linear) the spec **is** a `spec`-labeled issue and no `docs/specs/` file is written; in local mode (`local`, or no tracker) it is a committed `docs/specs/<slug>.md` file. Detection is therefore tracker-aware — read `docs/agents/issue-tracker.md` to know where to look. `ready-for-agent` still marks tickets only; the spec issue wears `spec` so the loop never dispatches prose as work.
 - **Stage 8 scales to the spec's design surface** through a fidelity ladder ([ADR-0016](https://github.com/wemuda/launchrail/blob/master/docs/adr/0016-design-validation-fidelity-ladder.md)): recorded skip, flow diagrams, screen mockups, or Claude Design. The level choice lives inside `design-validation` (recommend, user confirms). It exists to catch "specified but wrong on screen" while the finding still costs a spec edit rather than re-cut tickets — that's why it precedes stage 9 and is not stage 11, which checks the *built* product. Even a skip is recorded through the skill, so the gate stays artifact-based.
 - **Stage 10 is one door.** `/launch-implement` drives the Ralph loop ([ADR-0017](https://github.com/wemuda/launchrail/blob/master/docs/adr/0017-implementation-loop-provider.md) as amended by [ADR-0020](https://github.com/wemuda/launchrail/blob/master/docs/adr/0020-independent-skill-set.md)). Launchrail owns both edges of the loop: `ready-for-agent` tickets with `Blocked by: #n` edges in, `launchrail verify` (+ browser smoke where enabled) gating every merge.
@@ -62,10 +101,24 @@ From there the normal sizing paths apply, with two design-first twists: the hand
 
 When `.launchrail.yml` records `origin: existing`, stage 1 is reached through the Launchrail `project-alignment` skill: it inventories what the codebase already has, infers a draft vision from the code, interviews only the gaps, and detects the existing design system as the baseline for stages 2 and 8, then hands to `vision-creation` to commit ([ADR-0013](https://github.com/wemuda/launchrail/blob/master/docs/adr/0013-existing-project-alignment.md)). Alignment is an on-ramp onto the same rail, not a second workflow.
 
+## The interaction contract
+
+How every stage spends the user's attention ([ADR-0029](https://github.com/wemuda/launchrail/blob/master/docs/adr/0029-planning-interaction-contract.md)). The grill carries the detailed mechanics, but these rules bind *any* stage that interviews, proposes, or checkpoints — the human in the loop must mean meaningful control, not procedural approval of an unmanageable working set.
+
+- **Decision ownership is split.** The user owns product promises, priorities, risk tolerance, and irreversible or costly-to-reverse tradeoffs — data loss, security, tenancy, spend, public contracts. The agent owns reversible implementation details *within* those constraints: it picks a sensible default, records it as **Provisional**, and moves on. A reversible choice escalated as a question is a contract violation, not diligence.
+- **Label every uncertainty; only one label reaches the user.** Every open question is triaged as `decide-now`, `agent-default`, `research`, `prototype`, or `defer` — and only `decide-now` questions are asked. The other four are worked or parked by the agent and surface in the session summary, not as questions.
+- **Rounds are small.** At most **three questions per round** — and a genuinely consequential decision rides alone, with the context it deserves. Working memory holds about four chunks; a round of eleven interdependent questions is delegation pressure, not rigor.
+- **Sessions are budgeted.** About **six user decisions per session**. When the budget is spent, close: write the artifact, summarize Locked / Provisional / Deferred, hand over the next command. Pressing on past the budget converts the decision-maker into an approval machine.
+- **Checkpoint every two rounds.** Offer the explicit choice: **continue** grilling, **prototype** to raise fidelity, **defer** the rest, or **go build**. The user steers the process, not just the answers.
+- **Stop at build-safety.** Planning stops when the next vertical slice can be built safely — not when the frontier is empty. Questions beyond that line get labeled and parked, and the slice's feedback reopens them cheaper than speculation ever could.
+- **Approved prototypes have authority.** Behavior shown in an approved prototype or design package is *presumed in scope*. Proposing to cut it requires a concrete safety, infrastructure, or measured-cost reason — "the spec would be simpler" is not one. A prototype is a decision record, not a feature inventory to re-litigate.
+- **Planning must keep touching ground.** Never more than **two consecutive planning sessions or planning tickets without a runnable or visual checkpoint** — a prototype, a spike, or building the slice that's already safe. Planning that only produces more planning has left the rail.
+
 ## Conductor rules
 
 The contract for `launch`, `/launch-implement`, and any agent driving the rail. The conductors execute these rules; this document owns them.
 
+- **Every transition renders the rail banner.** Orientation, routing, stage close, session summary — position is announced with the banner from the phase view above, never gestured at in prose. The user should never have to ask "where are we, and what happens now?"
 - **One owner per stage, invoked by name.** Every stage has exactly one owning skill. Invoke it by name; do not paraphrase, wrap, re-prompt, or re-derive its work inline — the skill is the only place its stage's behavior lives.
 - **Artifacts gate stages, not chat memory.** A stage is done only when its committed artifact exists; detect by reading the repository, and when a signal is ambiguous (a template-only vision, an abandoned spec draft), ask rather than assume. Detection and sizing are read-only — every write happens inside the stage owner.
 - **User-typed stages get a prepared handoff, never reverse-engineering.** A `disable-model-invocation` refusal is the cue to hand over, not to reproduce the skill's work by hand or grep vendored skill files. A prepared handoff is three moves: confirm the stage's input artifacts are committed; hand the user the exact, fully-argumented command naming those inputs (a bare `/skill` sends it re-deriving what your inputs already settle — arguments that point at committed inputs are parameters, not paraphrase); pick up automatically once the stage's artifact lands.

package/assets/skills/launchrail/launch-design-handoff/SKILL.md

@@ -13,6 +13,7 @@ The rail drives Claude Design in two places — visual exploration (stage 2) and
 - **Read the artboards, don't just file them.** Claude Design artboards are self-contained HTML: real layout, spacing, colors, type, and copy. The handoff doc is written from what the files actually say, cross-checked against what the user said the drop is.
 - **Interview only what documenting needs; leave alignment to the grill.** This skill asks just enough to file the package truthfully — scope, intentional-vs-accidental design-system divergence, load-bearing copy. Everything the prototype is silent on (missing states, behavior rules, edge cases) is *recorded as open questions* that become the feature grill's agenda, not interviewed twice.
 - **Design-system deltas are findings, not fixes.** Where the prototype's tokens diverge from the project's existing design system, ask whether that is an intentional restyle or an accident. Never silently normalize the prototype, and never silently fork the design system.
+- **The committed prototype has authority downstream.** Once the package is committed, the behavior it shows is *presumed in scope* for the planning stages that consume it ([ADR-0029](https://github.com/wemuda/launchrail/blob/master/docs/adr/0029-planning-interaction-contract.md)): the grill and spec treat it as a decision record, and cutting something it shows requires a concrete safety, infrastructure, or measured-cost reason — never a simplification default. Record that presumption in `handoff.md` so it survives the session.
 - **Route, don't build.** The skill ends at a committed package plus a recommended path. Planning stages keep their owners; implementation stays behind the user-typed `/launch-implement`.
 
 ## Process
@@ -31,4 +32,4 @@ The rail drives Claude Design in two places — visual exploration (stage 2) and
    - **New pages / a feature on the existing system** (the common case) → short feature grill *fed this handoff doc, its open questions as the agenda* → `launch-spec`, naming `docs/design/<feature-slug>/` as the design reference the spec cites for UX/UI → `launch-tickets`. Because the spec is written *from* the prototype, design validation usually becomes a recorded skip citing this package — recorded through `launch-design-validation` as always, so the gate stays artifact-based.
    - **Redesign / new surface area** → `launch-wayfinder` and the full large-feature path.
 
-   Then hand to `/launch`, naming the committed `handoff.md` as the input. Never start `/launch-implement` yourself — every path ends there by the user's hand. See [`workflow.md`](../launch/workflow.md) for the stage contract.
+   Then hand to `/launch`, naming the committed `handoff.md` as the input, and close with the rail banner ([`workflow.md`](../launch/workflow.md)'s phase view): the committed package under Done, the recommended path as the feature's phase arc, the `➤` line carrying the sizing command. Never start `/launch-implement` yourself — every path ends there by the user's hand.

package/assets/skills/launchrail/launch-design-validation/SKILL.md

@@ -41,4 +41,4 @@ Every level answers the same question — does the specified behavior survive co
 5. **Harvest findings.** For each flow record: what the design confirmed, what it contradicted in the spec, and what the spec turned out to be silent on. Ambiguities count as findings. Findings at a low level are also a signal — if the diagrams alone surface deep uncertainty, recommend re-running a flow at a higher level before revising.
 6. **Revise the spec.** Apply the accepted findings to the spec in place. If a finding invalidates an ADR, update or supersede that ADR in the same change. Note rejected findings and why in the handoff note, so the question does not resurface every review.
 7. **Write the handoff note** at the end of the spec (section `## Design validation`) with: date, the level that ran, flows validated, links to the artifact pages / design artifacts, accepted changes, rejected findings with reasons, and open questions. This section is the evidence that validation happened — the ticket stage (`launch-tickets`) reads the spec as validated only if it is present.
-8. **Hand off.** Confirm with the user that the revised spec is approved, save it in place — commit the file, or update the spec issue on the tracker — respecting the project's commit conventions, and point them at ticket creation as the next stage. See [`workflow.md`](../launch/workflow.md) for the full stage order.
+8. **Hand off with the rail banner.** Confirm with the user that the revised spec is approved, save it in place — commit the file, or update the spec issue on the tracker — respecting the project's commit conventions. Then close with the banner from [`workflow.md`](../launch/workflow.md)'s phase view: the validated spec under Done, ticket creation (`launch-tickets`) as Now, and the exact command on the `➤` line.

package/assets/skills/launchrail/launch-discovery/SKILL.md

@@ -24,7 +24,7 @@ Diverge here; converge in the grill; de-risk in technical research. This stage o
 3. **For each area, enumerate the real contenders.** List the actual options that fit this stack — libraries, frameworks, hosted services, vendors, and the roll-your-own baseline. For each: what it is, what it buys you, what it costs (integration effort, lock-in, license, operational burden), and where it breaks down for *this* vision. Include the boring and the build-it-yourself options; a landscape that lists only the trendy pick is not a landscape.
 4. **Go deep where it's load-bearing.** For the areas where the choice most shapes the architecture, drive `launch-research` on the specific threads — verify real capabilities against the vision's needs, maintenance and community health, license, and concrete integration cost on this stack. Where research agents aren't available in the session, say so and fall back to a clearly-marked best-effort survey — do not silently skip the depth pass.
 5. **Write the landscape map.** Commit one doc per area (or one grouped doc) under `docs/research/`, named `discovery-<area>.md`. Each area records: the contenders with their trade-offs, what's verified vs. assumed, any options ruled out with the reason, and — most importantly — the **questions this hands to the grill**: the decisions now teed up with real options behind them.
-6. **Hand to the grill.** This stage does not choose. Route to the complexity grill (`launch-grill`, stage 4), which takes the landscape as input and narrows it into surviving constraints. Tell the user what you surveyed, where the docs are, that the grill is next, and that they can jump straight there.
+6. **Hand to the grill — with the rail banner.** This stage does not choose. Route to the complexity grill (`launch-grill`, stage 4), which takes the landscape as input and narrows it into surviving constraints. Close with the banner from [`workflow.md`](../launch/workflow.md)'s phase view: what you surveyed and where the docs are under Done, the grill as Now, and the one next action on the `➤` line.
 
 ## What this stage is not
 

package/assets/skills/launchrail/launch-grill/SKILL.md

@@ -1,26 +1,44 @@
 ---
 name: launch-grill
-description: The grill — a relentless, round-based interview that stress-tests a plan, decision, or idea into surviving constraints, maintains the domain model as terms and decisions crystallise, and always ends by committing the constraints under docs/research/. Runs in two contexts, the foundation's complexity grill (stage 4) and the feature grill that opens every delivery-loop path before speccing and tickets. Use whenever the user wants to be grilled, stress-test thinking, or get aligned before building.
+description: The grill — a budgeted, round-based interview that stress-tests a plan, decision, or idea until the next slice can be built safely, maintains the domain model as terms and decisions crystallise, and always ends by committing what settled under docs/research/. Runs in two contexts, the foundation's complexity grill (stage 4) and the feature grill that opens every delivery-loop path before speccing and tickets. Use whenever the user wants to be grilled, stress-test thinking, or get aligned before building.
 ---
 
 <!-- Contains text derived from Matt Pocock's skills (https://github.com/mattpocock/skills), MIT — see ../NOTICE.md -->
 
 # The grill
 
-Interview the user relentlessly until you reach a shared understanding — then commit what survived. The grill is the rail's *convergent* tool, and it runs anywhere the user needs to get aligned with the agent before work hardens into specs and tickets. A grill that ends in conversation and no committed file has not finished — see [the artifact](#the-artifact-closes-the-grill) below.
+Interview the user until the next move is safe — then commit what settled. The grill is the rail's *convergent* tool, and it runs anywhere the user needs to get aligned with the agent before work hardens into specs and tickets. But convergence has a target: **build-safety, not exhaustion**. Product design is generative — every answer reveals new questions — so a grill that only stops at an empty question tree never stops; it converts the decision-maker into an approval machine and calls the exhaustion rigor. This skill executes the interaction contract in [`workflow.md`](../launch/workflow.md) ([ADR-0029](https://github.com/wemuda/launchrail/blob/master/docs/adr/0029-planning-interaction-contract.md)): the user's attention is the scarcest resource on the rail — spend it only on decisions that are genuinely theirs.
 
 Run every grill with the **domain-modeling discipline** ([domain-modeling.md](./domain-modeling.md)) active: challenge terms against the glossary, sharpen fuzzy language, update `CONTEXT.md` as terms resolve, and offer an ADR (the project's `docs/adr/0000-template.md` format) when a decision meets its three-part bar.
 
+A grill that ends in conversation and no committed file has not finished — see [the artifact](#the-artifact-closes-the-grill) below.
+
 ## Two contexts, one grill
 
-- **The foundation grill (stage 4).** Inputs: the vision, the visual exploration, and the discovery landscape (`docs/research/discovery-*.md`). The job is to narrow the whole product's option space into the constraints everything downstream builds on. When discovery ran, the landscape map is the option space — pick from the real contenders it surfaced; don't re-assume the default that the discovery stage existed to widen past. The surviving constraints become technical research's brief (stage 5).
-- **The feature grill (delivery loop).** Every sizing path — large, semi, small — starts here: when a new feature or idea arrives, grill it *before* `launch-spec` and `launch-tickets`, so the spec synthesizes decisions actually made together rather than assumptions. Same method, narrower brief: inputs are the feature idea plus the founded artifacts it touches (vision, ADRs, existing specs, the code). Hand off to whatever the sizing path says comes next — usually straight to `launch-spec` or `launch-tickets`.
+- **The foundation grill (stage 4).** Inputs: the vision, the visual exploration, and the discovery landscape (`docs/research/discovery-*.md`). Open with the **risk cut**: name the handful of assumptions — about five — that could kill or fundamentally reshape the product (tenancy and isolation, money arithmetic, data durability, the core mechanic, the load-bearing integration). Those are the decide-now agenda; the long tail of product surface — slice counts, control placement, empty-state copy — is real work but not foundation work: default it or defer it to the slice that touches it. When discovery ran, the landscape map is the option space — pick from the real contenders it surfaced; don't re-assume the default that the discovery stage existed to widen past. The surviving constraints become technical research's brief (stage 5).
+- **The feature grill (delivery loop).** Every sizing path — large, semi, small — starts here: when a new feature or idea arrives, grill it *before* `launch-spec` and `launch-tickets`, so the spec synthesizes decisions actually made together rather than assumptions. Same method, narrower brief: inputs are the feature idea plus the founded artifacts it touches (vision, ADRs, existing specs, the code). A feature that arrived design-first brings its handoff package: the prototype has [authority](#approved-prototypes-have-authority), and `handoff.md`'s open questions are the agenda — already triaged fodder, not a reason to re-interview the package. Hand off to whatever the sizing path says comes next — usually straight to `launch-spec` or `launch-tickets`.
+
+## Triage before you ask
+
+Every uncertainty gets exactly one label the moment it surfaces — labeling is *your* job and costs the user nothing:
+
+| Label | It is | Resolved by |
+|---|---|---|
+| `decide-now` | A product promise, priority, risk tolerance, or an irreversible / costly-to-reverse tradeoff **that the next slice depends on** | The user — this is the only label that becomes a question |
+| `agent-default` | A reversible implementation detail with a sensible default | You: pick it, record it as **Provisional**, move on |
+| `research` | A fact the environment or primary sources can answer | A dispatched sub-agent — never the user |
+| `prototype` | Best answered by reacting to something concrete, not by prose | A cheap artifact to react to |
+| `defer` | Doesn't gate the next slice | Parked under **Deferred** with the trigger that reopens it |
+
+`decide-now` is a conjunction of **ownership** and **dependency**: it must be the user's kind of decision *and* the next slice must depend on it. Miss either test and the label is one of the other four. Escalating a reversible choice as a question is not diligence — it is how an interview swells into a hundred questions and the human's control becomes procedural approval. When in doubt whether a decision needs the user, default it, mark it Provisional, and let the built slice arbitrate.
 
 ## The interview
 
-Map the discussion as a **design tree**: every decision branches into the decisions that hang off it. Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled — the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
+Map the discussion as a **design tree**: every decision branches into the decisions that hang off it. The **frontier** is every open question whose prerequisites are already settled. But the frontier is what you *triage*, not what you *ask*. Work in **rounds**:
 
-Each question should be formatted like so:
+1. Recompute the frontier; label everything new on it.
+2. Work the non-user labels: dispatch `research`, pick and record `agent-default`s, park `defer`s, propose a `prototype` when one would collapse several questions at once.
+3. Ask at most **three** `decide-now` questions — the most load-bearing ones on the frontier. A genuinely consequential decision **rides alone**, with the context it deserves. Number each question and give your recommended answer:
 
 ```
 ❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
@@ -28,21 +46,33 @@ Each question should be formatted like so:
 ➡️ <your recommended answer>
 ```
 
-Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
+4. Wait for the answers. Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. A question whose answer depends on another question still open in this round belongs to a *later* round, not this one.
+
+**Checkpoint every two rounds.** Before the third round, and every second round after, stop and offer the explicit choice — **continue** grilling, **prototype** to raise the fidelity, **defer** what's left, or **go build** what's already safe — with your recommendation. The user steers the process, not just the answers.
 
-Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. The _decisions_ are the user's — put each to them and wait.
+**The budget is about six user decisions per session.** When it's spent, don't press on — close: write the artifact, summarize, hand over the next command. A second grill session is always available; a burned-out decision-maker is not.
 
-The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on the decisions until the user confirms you have reached a shared understanding.
+Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — work the rest of the round now. The _decisions_ are the user's — put each to them and wait.
+
+## Stop at build-safety
+
+The session is done when **the next vertical slice can be built safely**: every decision that slice depends on is Locked or safely Provisional, and everything else on the tree carries a label and a parking place. The frontier does *not* need to be empty — it never will be, and chasing emptiness is how planning eats the product. "Nothing silently assumed" still holds in full force, but it means every open question is **labeled and written down**, not answered. Do not act on the decisions until the user confirms you have reached a shared understanding.
+
+## Approved prototypes have authority
+
+When an approved prototype, design package, or working design exists for the thing being grilled, its behavior is **presumed in scope** — it is a decision record, not a feature inventory to re-litigate. Never propose cutting something the prototype shows as a default or a simplification; a cut is a `decide-now` question only when you bring a concrete **safety, infrastructure, or measured-cost** reason, stated with the evidence. Shared structure the prototype demonstrates (a repeated component, a mode, a rail pattern) is a finding to name, not a scope to question.
 
 ## The artifact closes the grill
 
-A grill gates on a committed file, not on the conversation. When the user confirms shared understanding, write the surviving constraints to **`docs/research/grill-<topic>.md`** (feature grills take the feature's slug) and commit it. The doc records:
+A grill gates on a committed file, not on the conversation. When the user confirms shared understanding — or the budget is spent — write what settled to **`docs/research/grill-<topic>.md`** (feature grills take the feature's slug) and commit it. The doc records:
 
-- the decisions made, each with its one-line why;
-- the assumptions attacked, and whether they survived;
-- the options ruled out, with the reason;
-- the open questions handed onward — to technical research after a foundation grill, or into the spec after a feature grill.
+- **Locked** — the decisions made, each with its one-line why.
+- **Provisional** — the agent-defaults chosen, each marked changeable; revisiting one later is cheap and expected.
+- **Deferred** — the questions parked, each with the trigger that reopens it (a slice, a metric, a user signal). After a foundation grill these hand onward to technical research; after a feature grill, into the spec's Out of Scope.
+- **Ruled out** — the options rejected and the assumptions that died under attack, each with the reason.
 
 Everything under `docs/research/` is project-owned; Launchrail tooling never overwrites it.
 
-One exception: when another skill invokes the grill for its own artifact — a `launch-wayfinder` ticket records its resolution on the ticket — that caller's artifact replaces the `docs/research/` doc. Absent such a caller, the committed doc is never optional.
+Close the session with the **rail banner** and the four-block summary — **Locked, Provisional, Deferred, Next command** — as defined in [`workflow.md`](../launch/workflow.md)'s phase view. The summary is drawn from the artifact, and the next command is fully argumented (name the committed doc), so the user always knows where they are and what to type.
+
+One exception: when another skill invokes the grill for its own artifact — a `launch-wayfinder` ticket records its resolution on the ticket — that caller's artifact replaces the `docs/research/` doc, and the caller may hand the grill a tighter budget and a set of already-settled decisions to inherit. Inherited decisions are never re-opened. Absent such a caller, the committed doc is never optional.

package/assets/skills/launchrail/launch-implement/SKILL.md

@@ -46,4 +46,4 @@ If the loop's materials are missing — `modules.ralph` off in the manifest, or
 - **Only the user starts this.** Conductors and other skills hand over the command (`/launch-implement`); they never invoke it. The engines behind it inherit the same rule — reaching them through this door *is* the explicit user start.
 - **Nothing is done until `npx @wemuda/launchrail verify` is green** — per ticket, and once more on the final base when a loop run ends. Where `modules.browser-testing` is enabled and the change is user-facing, a `launch-browser-smoke` journey is part of done.
 - **Report evidence, not assertions:** PR numbers, merge commits, issues closed, the verify outcome — and what was parked or punted, with why.
-- **Every loop run ends with the campaign recap** (the `launch-ralph` close-out): where the work lives — target branch and head SHA — the ticket → PR → merge-commit table, parked and stuck tickets, punted follow-ups in one list, and the single next step. By default that step is *offering* the one release PR `<target> → <default>`, opened only when the user says so; in the opt-in trunk mode it is nothing — every ticket is already live on the default branch.
+- **Every loop run ends with the campaign recap** (the `launch-ralph` close-out): where the work lives — target branch and head SHA — the ticket → PR → merge-commit table, parked and stuck tickets, punted follow-ups in one list, and the single next step. By default that step is *offering* the one release PR `<target> → <default>`, opened only when the user says so; in the opt-in trunk mode it is nothing — every ticket is already live on the default branch. Under the recap, render the rail banner ([`workflow.md`](../launch/workflow.md)'s phase view) — Build done for this scope, verification/release as what remains — so even the build door closes with "where we are and where we're going".

package/assets/skills/launchrail/launch-project-alignment/SKILL.md

@@ -22,11 +22,11 @@ The Launchrail loop is written for a project that starts from an idea. A project
 3. **Align the vision** — the one artifact worth inferring:
    - If `docs/vision.md` exists and is real (not the bare template), read it and note where it's thin or stale. This becomes a revision.
    - If it's missing or template-only, **draft an inferred vision** from the inventory: what the product appears to be, who it seems to serve, what it does today, and the assumptions and non-goals the code implies. Mark clearly what is inferred vs. observed, and list the open questions the code can't resolve (the real target user, the bet, the success signal).
-   - **Interview the user on those gaps only** — a few questions at a time, in their language. Don't re-ask what you inferred with confidence; confirm it.
+   - **Interview the user on those gaps only** — at most three questions per round, in their language, per the interaction contract in [`workflow.md`](../launch/workflow.md). Don't re-ask what you inferred with confidence; confirm it.
    - **Hand the result to `launch-vision-creation`** to finalize and commit as a *revision* — it owns the template, the commit, and the `AGENTS.md` project-purpose sync. The interview is already done; it should confirm and commit, not re-interview from scratch.
 4. **Detect the design system.** Look for an existing one: design tokens, a theme or Tailwind config, a component library, Storybook, a CSS framework, or Figma links in the docs. If a real design system exists, record it as the **baseline** for visual exploration (stage 2) and design validation (stage 8) — link it from the vision — so those stages extend what's there instead of exploring from zero. If none exists, note it as a genuine stage-2 gap.
 5. **Map the remaining artifacts, don't manufacture them.** For ADRs, the MVP spec, tickets, and the verification setup, record present/partial/missing in the alignment map. Do not back-fill them here — each has an owning stage. Where a project already has, say, architecture docs or a test suite, note that the corresponding stage is largely satisfied so `launch` doesn't send the user to redo it.
-6. **Report and hand back.** Present the alignment map: what's already aligned, what you inferred and the user confirmed, and the real gaps in loop order. Then route to `launch` to drive the first real gap. Leave the user a clear picture of where their existing project sits on the rail and what's next.
+6. **Report and hand back — with the rail banner.** Present the alignment map: what's already aligned, what you inferred and the user confirmed, and the real gaps in loop order. Then route to `launch` to drive the first real gap, and close with the banner from [`workflow.md`](../launch/workflow.md)'s phase view — the satisfied phases ✓-marked under Done, the first real gap as Now — so the adopted project sees exactly where it sits on the rail and what one thing comes next.
 
 ## The artifact map
 

package/assets/skills/launchrail/launch-spec/SKILL.md

@@ -8,6 +8,8 @@ disable-model-invocation: true
 
 This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user — just synthesize what you already know: the vision, the grill's surviving constraints, the research notes, and the ADRs are the inputs; a conductor handing off this stage names them.
 
+Synthesis preserves the grill's labels ([ADR-0029](https://github.com/wemuda/launchrail/blob/master/docs/adr/0029-planning-interaction-contract.md)): **Locked** decisions are stated as decisions; **Provisional** agent-defaults stay marked provisional in the spec (changeable without re-planning); **Deferred** questions land in Out of Scope with the trigger that reopens them — never silently dropped, never silently promoted into scope.
+
 ## Process
 
 1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary (`CONTEXT.md`) throughout the spec, and respect any ADRs in the area you're touching.
@@ -23,7 +25,7 @@ This skill takes the current conversation context and codebase understanding and
 
 On a real tracker, also bundle the spec under a **milestone** named for the feature: create the milestone, put the spec issue in it, and set its description to a one-line goal plus a link back to the spec issue. That milestone is the rollup `launch-tickets` hangs every ticket on, so the whole feature reads as one progress bar — a *view*, not the spec's home; the `spec`-labelled issue stays canonical. See `docs/agents/issue-tracker.md` for the exact per-tracker commands; local mode has no milestone (the feature's files are its bundle).
 
-The spec then flows on: design validation (stage 8) revises it in place, and `launch-tickets` (stage 9) breaks it into tickets that reference it.
+The spec then flows on: design validation (stage 8) revises it in place, and `launch-tickets` (stage 9) breaks it into tickets that reference it. Close by rendering the rail banner ([`workflow.md`](../launch/workflow.md)'s phase view) — the published spec under Done, design validation as Now, tickets as Next — with the one next command on the `➤` line.
 
 <spec-template>
 
@@ -45,7 +47,7 @@ A LONG, numbered list of user stories. Each user story should be in the format o
 1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
 </user-story-example>
 
-This list of user stories should be extremely extensive and cover all aspects of the feature.
+This list of user stories should be extremely extensive and cover all aspects of the feature *as decided* — behavior an approved prototype shows is in scope by presumption, while questions the grill deferred belong in Out of Scope, not as invented stories.
 
 ## Implementation Decisions
 
@@ -73,7 +75,7 @@ A list of testing decisions that were made. Include:
 
 ## Out of Scope
 
-A description of the things that are out of scope for this spec.
+A description of the things that are out of scope for this spec — including every question the grill deferred, each with the trigger that reopens it.
 
 ## Further Notes
 

package/assets/skills/launchrail/launch-tickets/SKILL.md

@@ -68,6 +68,10 @@ Work the **frontier**: any ticket whose blockers are all done. For a purely line
 
 Do NOT close or modify any parent issue. Each new ticket is closed later by its own implementing PR (`Closes #n`, per the tracker doc's Issue ↔ PR linkage), not by hand here.
 
+### 6. Close with the rail banner
+
+End by rendering the banner from [`workflow.md`](../launch/workflow.md)'s phase view: the published tickets under Done (count and where they live), Build as Now, and `➤ /launch-implement` — the user-typed door — as the one next command. Never start it yourself.
+
 <local-ticket-template>
 
 # <NN> — <Ticket title>

package/assets/skills/launchrail/launch-vision-creation/SKILL.md

@@ -18,7 +18,7 @@ Produce `docs/vision.md`: a short, honest statement of what this product is, who
 ## Process
 
 1. **Read what exists.** Check for `docs/vision.md`, a README, and any notes the user points at. Do not ask questions the repository already answers.
-2. **Interview the user** — briefly, a few questions at a time, in their language:
+2. **Interview the user** — briefly, in their language, at most three questions per round with your recommended answer where you have one (the interaction contract in [`workflow.md`](../launch/workflow.md) applies here as everywhere):
    - What problem hurts, and for whom? How do those people cope today?
    - Why this, why now — what is the bet that makes this worth building?
    - Who is the first concrete user (a person or team you could name), as opposed to the eventual market?
@@ -30,7 +30,7 @@ Produce `docs/vision.md`: a short, honest statement of what this product is, who
 5. **Present and iterate** until the user approves.
 6. **Sync the agent contract.** If the seeded `AGENTS.md` still carries the TODO under `## Project purpose`, replace it with a one-paragraph distillation of the approved vision — what this is, who it serves, what it is not. Touch only that section: `AGENTS.md` belongs to the project, and the rest of it is not this skill's business.
 7. **Commit** `docs/vision.md` and the `AGENTS.md` update together (respect the project's commit conventions).
-8. **Hand off.** Point the user at the next stages of the loop: visual exploration in Claude Design to make the intent concrete, discovery research (`launch-discovery`) to map the real options for the vision's hard parts, then the complexity grill (`launch-grill`) to attack the assumptions just recorded. See [`workflow.md`](../launch/workflow.md) for the full stage order.
+8. **Hand off with the rail banner.** Close with the banner from [`workflow.md`](../launch/workflow.md)'s phase view — the committed vision under Done, visual exploration (Claude Design, to make the intent concrete) as Now, discovery research (`launch-discovery`, mapping the real options for the vision's hard parts) as Next, and the grill on the Later arc — so the user sees exactly where they are and what one thing comes next.
 
 ## Template
 

package/assets/skills/launchrail/launch-wayfinder/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: launch-wayfinder
-description: Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on the project's issue tracker, and resolve them one at a time until the way to the destination is clear. Stage 7's breakdown half for large features; launch-spec synthesizes once the way is clear.
+description: Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on the project's issue tracker, and resolve them one at a time until the way to the destination is clear. Decisions only — execution stays out of the map and follows the spec. Stage 7's breakdown half for large features; launch-spec synthesizes once the way is clear.
 disable-model-invocation: true
 ---
 
@@ -12,7 +12,12 @@ The destination varies per effort, and naming it is the first act of charting
 
 ## Plan, don't do
 
-Wayfinder is **planning** by default: each ticket resolves a decision, and the map is done when the way is clear — nothing left to decide before someone goes and does the thing. The pull to just do the work is usually the signal you've reached the edge of the map and it's time to hand off. An effort can override this in its **Notes** — carrying execution into the map itself — but absent that, produce decisions, not deliverables.
+Wayfinder is **planning, only**: each ticket resolves a decision, and the map is done when the way is clear — nothing left to decide before someone goes and does the thing. **Execution never enters the map** ([ADR-0029](https://github.com/wemuda/launchrail/blob/master/docs/adr/0029-planning-interaction-contract.md)): a ticket that would *deliver* part of the destination — build the worker, ship the page, migrate the data for real — is implementation wearing a planning label, and it belongs after the spec, in `launch-tickets` and the build loop. The test, applied at creation and again if a ticket balloons: **name the decision this ticket unblocks.** No decision named, no ticket. The pull to just do the work is usually the signal you've reached the edge of the map and it's time to hand off.
+
+Two more bounds keep the map from recursing into itself:
+
+- **One layer of map.** A ticket never spawns its own map, and its grill never re-runs the foundation's. If a single ticket looks big enough to need either, the destination is drawn too far out — redraw this map instead.
+- **Touch ground every two tickets.** Never resolve more than **two planning tickets in a row without a runnable or visual checkpoint** — a prototype ticket, a spike, or pausing the map to build a slice that's already safe. When charting, sequence the frontier so those checkpoints land; when working the map, track the count and force the checkpoint before the third.
 
 ## Refer by name
 
@@ -78,8 +83,8 @@ Every ticket is either **HITL** — human in the loop, worked _with_ a human who
 
 - **Research** (AFK): Reading documentation, third-party APIs, or local resources like knowledge bases to surface a fact a decision waits on. Resolved by a `launch-research` **subagent**. Use when knowledge outside the current working directory is required.
 - **Prototype** (HITL): Raise the fidelity of the discussion by making a cheap, rough, concrete artifact to react to — an outline, a rough take, a stub, or throwaway UI/logic code. Links the prototype as an asset. Use when "how should it look" or "how should it behave" is the key question.
-- **Grilling** (HITL): Conversation. The default case. Always invoke the `launch-grill` skill — the ticket's resolution comment is the artifact, in place of the grill's usual `docs/research/` doc.
-- **Task** (HITL or AFK): Manual work that must happen before a _decision_ can be made — nothing to decide, prototype, or research, but the discussion is blocked until it's done. Signing up for a service so its API can be judged, provisioning access, moving data so its shape can be seen. This is the one type that _does_ rather than decides — and it earns its place by unblocking a decision, not by delivering the destination. The agent drives it alone where it can (AFK); otherwise it hands the human a precise checklist (HITL). Resolved when the work is done; the answer records what was done and any resulting facts (credentials location, new URLs, row counts) later tickets depend on.
+- **Grilling** (HITL): Conversation. The default case. Always invoke the `launch-grill` skill — the ticket's resolution comment is the artifact, in place of the grill's usual `docs/research/` doc. The ticket's question is the grill's **entire scope**, and the map's Decisions-so-far (plus the foundation's constraints) are **inherited, never re-opened** — hand the grill those settled decisions as context and a tight budget (a few decide-now questions, not a fresh session's six). A ticket grill that re-converges what the map already closed is the recursion this rule exists to stop.
+- **Task** (HITL or AFK): Manual work that must happen before a _decision_ can be made — nothing to decide, prototype, or research, but the discussion is blocked until it's done. Signing up for a service so its API can be judged, provisioning access, moving data so its shape can be seen. This is the one type that _does_ rather than decides — and it earns its place **only** by unblocking a decision: its body names that decision (an "Unblocks:" line pointing at the ticket or fog patch that waits on it), and a task that can't name one is implementation mis-filed on the map — delivering the destination belongs after the spec, in `launch-tickets` (see [Plan, don't do](#plan-dont-do)). The agent drives it alone where it can (AFK); otherwise it hands the human a precise checklist (HITL). Resolved when the work is done; the answer records what was done and any resulting facts (credentials location, new URLs, row counts) later tickets depend on.
 
 ## Fog of war
 
@@ -111,7 +116,7 @@ Two modes. Either way, **never resolve more than one ticket per session** — wi
 User invokes with a loose idea.
 
 1. **Name the destination.** Run a `launch-grill` session to pin down what this map is finding its way to — the spec, decision, or change. The destination fixes the scope, so it's settled first.
-2. **Map the frontier.** Grill again, **breadth-first** this time: fan out across the whole space rather than deep on any one thread, surfacing the open decisions and the first steps takeable now. **If this surfaces no fog** — the way to the destination is already clear, the whole journey small enough for one session — you don't need a map. Stop and ask the user how they'd like to proceed.
+2. **Map the frontier.** Grill again, **breadth-first** this time: fan out across the whole space rather than deep on any one thread, surfacing the open decisions and the first steps takeable now. Both charting grills share **one session budget** — breadth-mapping is mostly triage (the agent's job: label, default, park), and the user's questions go to naming the destination and the genuinely consequential forks. **If this surfaces no fog** — the way to the destination is already clear, the whole journey small enough for one session — you don't need a map. Stop and ask the user how they'd like to proceed.
 3. **Create the map** (label `wayfinder:map`): Destination and Notes filled in, Decisions-so-far empty, the fog sketched into **Not yet specified**.
 4. **Create the tickets you can specify now** as child issues of the map — then wire blocking edges in a **second pass** (issues need ids before they can reference each other). Wiring sorts them into the frontier and the blocked; everything you can't yet specify stays in the fog — the **Not yet specified** section.
 5. **Fire the research subagents.** For each `research` ticket you just created, spin up a `launch-research` subagent to resolve it in parallel, capturing its findings on a throwaway `research/<name>` branch with a context pointer from the ticket.
@@ -126,5 +131,6 @@ User invokes with a map (URL or number). A ticket is **optional** — without on
 3. Resolve it — **zoom as needed**: fetch the full body of any related or closed ticket on demand; invoke the skills the `## Notes` block names. If in doubt, use `launch-grill`.
 4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far.
 5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from **Not yet specified** so it lives only as its new ticket. If the answer reveals a ticket — this one or another — sits beyond the destination, **rule it out of scope** rather than resolving it on the route. If the decision invalidates other parts of the map, update or delete those tickets.
+6. **Close legibly.** End the session with the rail banner and the four-block summary — **Locked** (this resolution), **Provisional**, **Deferred**, **Next command** (the next frontier ticket by name, the checkpoint now due, or the handoff once the way is clear) — per [`workflow.md`](../launch/workflow.md)'s phase view. Check the checkpoint count here: if this was the second planning ticket since the last runnable or visual checkpoint, the next move is the checkpoint, not another ticket.
 
 The user may run unblocked tickets in parallel, so expect other sessions to be editing the tracker concurrently.

package/dist/lib/seeds.js

@@ -86,7 +86,7 @@ function claudeGeneratedMd(ctx) {
 
 # Launchrail workflow instructions
 
-- This project follows the Launchrail development loop: vision → design exploration → discovery → grill/research → ADRs → spec → visual validation → tickets → bounded implementation → verification → release.
+- This project follows the Launchrail rail — six phases: Intent → Exploration → Decisions → Blueprint → Build → Ship. Report position with the rail banner at every transition; the stage detail and the interaction contract live in \`.claude/skills/launch/workflow.md\`.
 - Product knowledge (vision, specs, ADRs, designs, tickets, code) is project-owned; Launchrail never overwrites it.
 - \`.launchrail.yml\` is project configuration; \`.launchrail-lock.json\` is machine-managed — do not hand-edit it.
 - The issue-tracker workflow (labels included) and the domain-doc consumer rules live in \`docs/agents/\` — seeded from \`.launchrail.yml\`, yours to edit.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wemuda/launchrail",
-  "version": "1.12.0",
+  "version": "1.13.0",
   "description": "Launchrail — initialize, inspect, update, and validate repositories using the Launchrail development system.",
   "license": "MIT",
   "type": "module",