@wemuda/launchrail 1.12.0 → 1.14.0

package/assets/skills/NOTICE.md

@@ -16,6 +16,10 @@ into `docs/agents/`. Each derived file carries its own derivation note. If
 Launchrail is useful to you, the inspiration credit belongs upstream — see the
 Launchrail README's Credits section.
 
+Upstream is monitored as inspiration, never re-vendored (ADR-0020). The
+derived skills were last reviewed against upstream commit `6654f6b`
+(2026-08-24).
+
 ---
 
 MIT License

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 — the single entry point to the Launchrail loop. Detects the project's stage from its committed artifacts, runs or routes to the stage's owner, sizes each new feature (large / semi / small) once the foundation exists, and hands implementation to /launch-implement — reporting position as six phases with the rail banner at every transition. Use to start or continue the workflow, ask what stage or phase the 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.
-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.
+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 — call the Skill tool with its 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. **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,10 +74,10 @@ 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.
+- **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 --fast` gating every land and the full `launchrail verify` (+ browser smoke where enabled) at the loop's checkpoints and release ([ADR-0032](https://github.com/wemuda/launchrail/blob/master/docs/adr/0032-ralph-lean-local-gate-loop.md)).
 
 ## Sizing the work in the delivery loop
 
@@ -62,11 +101,25 @@ 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.
 
-- **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.
+- **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 calling the Skill tool with the owner's exact name (a user-typed stage gets the prepared handoff instead); 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.
 - **The grill feeds research.** Run the grill before technical research and hand research the grill's surviving constraints as its brief.

package/assets/skills/launchrail/launch-code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: launch-code-review
-description: Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating ticket/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. The self-review gate inside launch-ralph-implement; also for reviewing a branch, a PR, or work-in-progress changes on request.
+description: Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (the repo's documented coding standards) and Spec (what the originating ticket or spec asked for) — in parallel sub-agents, reported side by side. The self-review gate inside launch-ralph-implement; also on request for a branch, a PR, or work in progress.
 ---
 
 <!-- Contains text derived from Matt Pocock's skills (https://github.com/mattpocock/skills), MIT — see ../NOTICE.md -->

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

@@ -1,6 +1,6 @@
 ---
 name: launch-design-handoff
-description: The design→code on-ramp — take a Claude Design prototype dropped into the session (a .zip export, an extracted folder, artboard/HTML files, or a published canvas link) and turn it into a committed handoff package under docs/design/, read against the current codebase and design system, then route it into the delivery loop — normally a short feature grill, a spec that references the designs, and tickets. Use when the user drops design files or a zip from Claude Design and wants them documented or implemented — "here is the prototype of feature X" — or asks to hand designs back from Claude Design into code.
+description: The design→code on-ramp — turn a Claude Design prototype dropped into the session (a .zip export, an extracted folder, artboard/HTML files, or a published canvas link) into a committed handoff package under docs/design/, then route it into the delivery loop. Use when the user drops design files from Claude Design and wants them documented or implemented — "here is the prototype of feature X" — or asks to bring designs back from Claude Design into code.
 ---
 
 # Design handoff — from Claude Design back into the loop
@@ -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

@@ -1,6 +1,6 @@
 ---
 name: launch-design-validation
-description: Validate an approved spec visually before implementation — at a confirmed fidelity level (recorded skip, flow-diagram artifact, screen-mockup artifact, or Claude Design), feed the findings back into a revised spec, and produce a handoff note for ticket creation. Use when a spec is drafted (a spec-labeled issue on the tracker, or a docs/specs/ file in local mode) and the user wants design validation, a visual review, or pre-implementation sign-off.
+description: Validate a drafted spec visually before tickets are cut — at a confirmed fidelity level (recorded skip, flow diagrams, screen mockups, or Claude Design) — and feed the findings back into a revised spec. Use when a spec is drafted and the user wants design validation, a visual review, or pre-implementation sign-off.
 ---
 
 # Design validation
@@ -39,6 +39,6 @@ Every level answers the same question — does the specified behavior survive co
    - **Screen mockups** — build one artifact page mocking the key screens and states per flow, including the empty, loading, and error states the spec claims to handle.
    - **Claude Design** — drive it flow by flow when the session can reach it. When it can't, prepare a fully-argumented handoff — the flows, the states each must show, links to the spec and vision, and any existing design-system baseline (see `project-alignment`) — hand it to the user to run, and resume when the design artifacts land. Never silently downgrade a level-4 choice to mockups; a downgrade is the user's decision.
 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.
+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, mirroring the status change in the registry index (`docs/adr/README.md`). 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

@@ -1,6 +1,6 @@
 ---
 name: launch-discovery
-description: The divergent option-space scan that runs before the complexity grill. Given the vision and the intended stack, it maps the real landscape of libraries, frameworks, vendors, hosted services, and patterns available for the hard parts of the product — enumerating the alternatives with their trade-offs rather than locking onto the first choice — and commits a landscape/options map that becomes the grill's input. Use after the vision (and visual exploration) and before the grill, or when the user asks to explore the tech landscape, survey vendors/libraries, or do discovery research. It composes `launch-research` for depth on any single thread; it does not pick winners — the grill does that.
+description: The divergent option-space scan before the complexity grill — map the real landscape of libraries, frameworks, vendors, and patterns for the hard parts of the product (alternatives with trade-offs, no winners) and commit the landscape map the grill narrows. Use after the vision (and visual exploration) and before the grill, or when the user asks to explore the tech landscape, survey vendors or libraries, or do discovery research. Composes `launch-research` for depth on any single thread.
 ---
 
 # Discovery research — map the option space before you narrow it
@@ -13,7 +13,7 @@ Diverge here; converge in the grill; de-risk in technical research. This stage o
 
 - **Diverge, don't decide.** Your job is to widen, not to pick. For each area, present the real contenders and their trade-offs; do **not** crown a winner or collapse to one option — that is the grill's job (stage 4), fed by what you surface here. A discovery doc that recommends exactly one tool per area has skipped its own stage.
 - **Bounded by the vision and the intended stack.** This is not open-ended reading. The vision says what's being built; the intended stack (and any existing design system) says what it must fit. Explore the landscape *for this product on this stack* — options that can't plug into the stack are noted and set aside, not explored in depth. This boundary is what keeps discovery from wandering into research nobody asked for.
-- **Compose, never duplicate.** Discovery is divergent framing over `launch-research`. Do the framing yourself — carve the product into areas, enumerate contenders — and invoke `launch-research` to go deep on any single thread that needs primary sources (real capabilities, maintenance health, license, integration cost). Don't reimplement research; drive it.
+- **Compose, never duplicate.** Discovery is divergent framing over `launch-research`. Do the framing yourself — carve the product into areas, enumerate contenders — and call the Skill tool with `launch-research` to go deep on any single thread that needs primary sources (real capabilities, maintenance health, license, integration cost). Don't reimplement research; drive it.
 - **Everything here is project-owned.** The landscape map is committed to the project under `docs/research/`; Launchrail tooling never overwrites it.
 - **Evidence over vibes.** A contender listed from memory is a lead, not a finding. Where a choice is load-bearing, confirm the fact — does it actually do X, is it maintained, what's the license — through `launch-research` rather than asserting it.
 
@@ -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,48 +1,84 @@
 ---
 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, keeps the domain model current as terms crystallise, and always commits what settled under docs/research/. Runs as the foundation's complexity grill (stage 4) and as the feature grill opening every delivery-loop path. 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, give your recommended answer, and separate questions with a horizontal rule — format a round like so:
 
 ```
 ❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
 
+➡️ <your recommended answer>
+
+---
+
+❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
+
 ➡️ <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.
+
+**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.
 
-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.
+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.
 
-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.
+## 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-grill/domain-modeling.md

@@ -42,4 +42,6 @@ Only offer to create an ADR when all three are true:
 2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
 3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
 
-If any of the three is missing, skip the ADR. ADRs use the **project's own format**: copy `docs/adr/0000-template.md` (seeded by `launchrail init`), scan `docs/adr/` for the highest existing number, and increment by one — `NNNN-short-slug.md`. One format per project; do not introduce a second.
+If any of the three is missing, skip the ADR — an implementation choice that fails the bar lives in the spec or the ticket, not `docs/adr/`. And when the decision refines one an existing ADR already owns, amend that ADR (update its `## Status` line and its registry row) instead of minting a sibling; a corpus of revisions reads worse than a decision with a history.
+
+ADRs use the **project's own format**: copy `docs/adr/0000-template.md` (seeded by `launchrail init`), take the next free number — check both the files in `docs/adr/` and the registry index (`docs/adr/README.md`) — and add the new record's row to the registry index **in the same commit**. One format per project; do not introduce a second.

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

@@ -1,6 +1,6 @@
 ---
 name: launch-implement
-description: Start building — the single entry point for implementation (stage 10). Drives ready tickets to verified merges through the Ralph loop. `/launch-implement` works the whole ready frontier; `/launch-implement 15` builds one ticket end to end in this session; several numbers scope the loop to just those tickets; a count ("the next 5") caps the run; a spec or slice reference ("spec #2's tickets") resolves to its tickets. It repairs its own setup (missing loop materials install via `launchrail sync`) instead of stopping. Only ever started explicitly by the user.
+description: Start building — drive ready tickets to verified merges through the Ralph loop. Bare, it works the whole ready frontier; `/launch-implement 15` builds one ticket end to end; several numbers scope the loop; a count ("the next 5") caps it; a spec reference ("spec #2's tickets") resolves to its tickets. Repairs its own setup instead of stopping.
 disable-model-invocation: true
 ---
 
@@ -18,25 +18,25 @@ From `.launchrail.yml`: `issueTracker` and the `testing` commands. From the argu
 - **a count** — "the next 5", "max 5" → the loop with a merge cap. Don't hand-pick which five: the cap is a stop condition, and the frontier decides the order — the loop stops after that many *verified merges* and leaves the rest ready;
 - **a spec, slice, or epic reference** — "spec #2's tickets", "the rest of slice 1" → resolve it to explicit numbers against the live tracker: the open tickets that belong to it (a "Part of: #n" line, the spec issue's ticket list, or a label), plus any open in-set blockers so the scope stays dependency-closed. Combinations compose: "the next 5 of spec #2" → that spec's tickets *and* a cap of 5.
 
-**Resolve the integration target with the scope.** Every multi-ticket run **consolidates by default** (ADR-0022, ADR-0026): its per-ticket PRs collect onto one integration branch, the default branch stays untouched, and the run ends by *offering* one release PR `<target> → <default>` for the user to review and merge — never merging to the default branch on its own. You name that branch before anything launches, scope-native: the branch the user named if they gave one ("collect spec #44 on `spec/44-mvp`"); else **the session's designated working branch** when the environment pinned one at start — a hosted session's `claude/...` branch exists to receive exactly this run, so use it rather than minting a `spec/*` twin beside it (ADR-0028); else the scope's own name when it maps to a spec, epic, or slice (`spec/<n>-<slug>`); else a generated fallback for an ad-hoc frontier (`launch/frontier-<today>`, or `launch/tickets-<n>-<m>` for a handful of loose numbers). A named target the remote lacks is created from the default branch's tip by the run's preflight. **Trunk** — each ticket merged straight to the default branch, live the moment it lands — is now the explicit opt-in: choose it only when the user asks in so many words ("land each ticket on master as it goes"), and never when the environment forbids pushing to the default branch. A pinned-branch environment ("develop on this branch; no unprompted PRs") constrains the *deliverable*, which consolidation already honors — the default branch stays untouched, the release PR stays offered-only. It never constrains the *engine*: the user typing `/launch-implement` is the explicit go-ahead for the loop's own mechanics — per-ticket `ralph/*` branches and their PRs, every one landing on the target — and is never a reason to drop to sequential in-session building. Whichever target, restate it in the echo — a choice the user should recognize, never silent.
+**Resolve the integration target with the scope.** Every multi-ticket run **consolidates by default** (ADR-0022, ADR-0026): its per-ticket branches are landed onto one integration branch by the loop's own local gate, the default branch stays untouched, and the run ends by *offering* one release PR `<target> → <default>` for the user to review and merge — the one place cloud CI runs — never merging to the default branch on its own. You name that branch before anything launches, scope-native: the branch the user named if they gave one ("collect spec #44 on `spec/44-mvp`"); else **the session's designated working branch** when the environment pinned one at start — a hosted session's `claude/...` branch exists to receive exactly this run, so use it rather than minting a `spec/*` twin beside it (ADR-0028); else the scope's own name when it maps to a spec, epic, or slice (`spec/<n>-<slug>`); else a generated fallback for an ad-hoc frontier (`launch/frontier-<today>`, or `launch/tickets-<n>-<m>` for a handful of loose numbers). A named target the remote lacks is created from the default branch's tip by the run's preflight. **Trunk** — each ticket merged straight to the default branch, live the moment it lands — is now the explicit opt-in: choose it only when the user asks in so many words ("land each ticket on master as it goes"), and never when the environment forbids pushing to the default branch. A pinned-branch environment ("develop on this branch; no unprompted PRs") constrains the *deliverable*, which consolidation already honors — the default branch stays untouched, the release PR stays offered-only. It never constrains the *engine*: the user typing `/launch-implement` is the explicit go-ahead for the loop's own mechanics — per-ticket `ralph/*` branches, pushed as they grow and landed on the target by the loop, no PR among them — and is never a reason to drop to sequential in-session building. Whichever target, restate it in the echo — a choice the user should recognize, never silent.
 
 **Resolve prose to data before anything launches.** The loop's inputs are ticket numbers and policy values (`only`, `max`, `width`, `target`) — the workflow takes them as JSON args and refuses a natural-language string by design. Translating the user's words into that scope, against live tracker state, is *your* job, and it ends with an echo before any dispatch: "Scope: #14, #15, #19 — the remaining slice-1 tickets; #19 builds after #14. Cap: none. Target: consolidate on `spec/2-checkout` (`master` untouched; one release PR offered at the end). Engine: the `ralph` workflow." A misread scope corrected here costs a sentence; corrected after launch it costs a run. That echo is your one pre-launch report — resolve the scope, repair setup (Step 2), and route (Step 3) without narrating the checks in between; surface a step only when it fails or changes the scope.
 
 ## Step 2 — Repair setup, don't gatekeep
 
-If the loop's materials are missing — `modules.ralph` off in the manifest, or `.claude/workflows/ralph.js` absent — run `npx @wemuda/launchrail sync` (additive and idempotent; its migration installs them) and say what it did. Never answer the user's "build this" with "first go run a command" for anything this skill can run itself. What you cannot repair, report precisely: no tracker configured (`issueTracker: none`), or an empty verification contract (no `testing` commands — `verify` fails on an empty contract and the loop refuses a start it cannot gate).
+If the loop's materials are missing — `modules.ralph` off in the manifest, or `.claude/workflows/ralph.js` absent — run `npx @wemuda/launchrail sync` (additive and idempotent; its migration installs them) and say what it did. Never answer the user's "build this" with "first go run a command" for anything this skill can run itself. What you cannot repair, report precisely: no tracker configured (`issueTracker: none`), or an empty verification contract (no `testing` commands — `verify` fails on an empty contract and the loop refuses a start it cannot gate). An unset `testing.checkCommand` is not a gap — the fast gate falls back to the unit command — but say once that naming a quicker lint/typecheck/unit gate there makes every land cheaper.
 
 ## Step 3 — Route by scope
 
-**The frontier (or any multi-ticket scope):** the engine is the `ralph` workflow (`.claude/workflows/ralph.js`) — launch it with the resolved scope and target as JSON args, e.g. `{ only: [14, 15, 19], max: 5, target: 'spec/2-checkout' }` (`canary: true` on a project's first run), then supervise it per the `launch-ralph` skill, which owns the policies (width, attempts, cap, deferrals, the merge gate, remote-verified merges) and the supervisor's contract. Orchestrating dispatches by hand under that skill instead is the exception, chosen out loud in the echo: the user asked to watch each dispatch, the Workflow tool is unavailable here, or the run is a targeted intervention (one parked ticket). One engine, one shape — a session that invents its own fan-out is not running the loop.
+**The frontier (or any multi-ticket scope):** the engine is the `ralph` workflow (`.claude/workflows/ralph.js`) — launch it with the resolved scope and target as JSON args, e.g. `{ only: [14, 15, 19], max: 5, target: 'spec/2-checkout' }` (`canary: true` on a project's first run), then supervise it per the `launch-ralph` skill, which owns the policies (width and the work pool, attempts, re-syncs, cap, deferrals, the local landing gate, checkpoints, remote-verified lands) and the supervisor's contract. Relaunching after a lost container passes `knownGreen: '<sha>'` so preflight skips re-proving a base a previous run verified; pushed `ralph/*` branches are adopted, never rebuilt. Orchestrating dispatches by hand under that skill instead is the exception, chosen out loud in the echo: the user asked to watch each dispatch, the Workflow tool is unavailable here, or the run is a targeted intervention (one parked ticket). One engine, one shape — a session that invents its own fan-out is not running the loop.
 
-**One ticket:** build it here, watchable, under the same contract a Ralph dispatch carries (kept textually parallel with `launch-ralph` — change one, change both). A single ticket has nothing to consolidate, so its base is the **default branch** and its one CI-gated PR merges there — consolidation-by-default is a multi-ticket policy (use a different base only if the user names one, or the session pins a designated branch — then that is the base). One deliberate divergence: you are the session, not a subagent, so you also run the merge gate yourself — waiting on CI here is fine:
+**One ticket:** build it here, watchable, under the same contract a Ralph dispatch carries (kept textually parallel with `launch-ralph` — change one, change both). A single ticket has nothing to consolidate, so its base is the **default branch** and its one CI-gated PR merges there — consolidation-by-default is a multi-ticket policy (use a different base only if the user names one, or the session pins a designated branch — then that is the base). Two deliberate divergences from a loop dispatch: a single ticket's PR *is* the review checkpoint, so it keeps the PR and its cloud CI, and you are the session, not a subagent, so you run that merge gate yourself — waiting on CI here is fine:
 
 1. **Dependency gate:** every ticket on the `Blocked by:` line is closed with its work merged. An open blocker stops you before any code — name it and offer to build it first.
 2. Read the ticket and everything it links (spec sections, ADRs, journeys), plus `AGENTS.md`/`CLAUDE.md`.
 3. Label the ticket `ralph:building`; branch `ralph/<n>-<short-slug>` from a fresh sync of the base resolved above.
-4. Implement by the **`launch-ralph-implement`** contract — TDD, the `verify` gate, browser smoke for user-facing changes, self-review, commit conventions. Name the skill; don't paraphrase it.
-5. Pre-PR sync: merge the latest base; resolve conflicts with `launch-resolving-merge-conflicts`; re-run the gate if anything changed.
+4. Implement by calling the Skill tool with **`launch-ralph-implement`** — it owns TDD, the push cadence, the gates (the full `verify` before a PR of your own), browser smoke for user-facing changes, self-review, and commit conventions. Never paraphrase it inline.
+5. Pre-PR sync: merge the latest base; resolve conflicts by calling the Skill tool with `launch-resolving-merge-conflicts`; re-run the gate if anything changed.
 6. Open a PR titled from the ticket with `Closes #<n>`; adopt an existing `ralph/<n>-*` branch or PR rather than opening a second.
 7. Wait for CI (Monitor or a background sleep, never a foreground busy-wait); fix what the branch broke; merge; confirm on the remote that the PR merged and the issue closed — close it explicitly if squash-merge didn't. Remove `ralph:building`.
 8. **Integrity:** no placeholders, no stubs, never delete or weaken a test to get green, never claim verification you didn't run.
@@ -44,6 +44,6 @@ If the loop's materials are missing — `modules.ralph` off in the manifest, or
 ## Ground rules
 
 - **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.
+- **Nothing is done until the gates are green** — `npx @wemuda/launchrail verify --fast` on every land, the full `npx @wemuda/launchrail verify` at the loop's checkpoints and once more on the final base when a run ends (and before a single ticket's PR). 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:** landing commits (PR numbers in single-ticket mode), issues closed, checkpoint and verify outcomes — and what was held, 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 → landing-commit table, held, 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>` (where cloud CI runs, once), 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

@@ -1,6 +1,6 @@
 ---
 name: launch-project-alignment
-description: The on-ramp for adopting an existing, mid-development codebase into the Launchrail loop. Instead of starting from a blank vision, it inventories what the project already has, infers a draft vision from the code, interviews only about the gaps, and detects an existing design system — then routes the real gaps back into the normal workflow. Use when initializing Launchrail on a project that already has code (`origin: existing` in `.launchrail.yml`), when the user asks to adopt, align, or onboard an existing project, or when `launch` sends an existing project to stage 1.
+description: "The on-ramp for adopting an existing, mid-development codebase: inventory what the project already has, infer a draft vision from the code, interview only the gaps, detect the existing design system — then route back into the normal workflow. Use when initializing Launchrail on a project that already has code (origin: existing in .launchrail.yml), when the user asks to adopt, align, or onboard an existing project, or when launch sends one to stage 1."
 ---
 
 # Project alignment — adopting an existing project
@@ -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