@wemuda/launchrail 1.13.0 → 1.15.0

package/README.md

@@ -60,9 +60,10 @@ From there, the day-to-day driver is not the CLI — it's the **`launch` skill**
 - **`launch-design-handoff`** — the design→code on-ramp: drop a Claude Design export (a zip, a folder, artboards) and it becomes a committed handoff package under `docs/design/` — read against the code and design system, gaps recorded as the grill's agenda — then sized into the loop ([ADR-0024](https://github.com/wemuda/launchrail/blob/master/docs/adr/0024-design-handoff-onramp.md))
 - **`launch-vision-creation`**, **`launch-discovery`**, **`launch-grill`**, **`launch-research`** — vision, then the divergent landscape scan, the grill (the convergent interview that runs both as the foundation's complexity grill and per-feature before speccing, keeping the glossary and ADRs honest as it goes), and primary-source research
 - **`launch-wayfinder`**, **`launch-spec`**, **`launch-tickets`**, **`launch-design-validation`** — break big work into decision maps, synthesize the spec, validate it visually, and cut tracer-bullet tickets with blocking edges
-- **`launch-browser-smoke`** — drives a real browser journey and leaves a traceable evidence bundle (with the browser-testing module)
+- **`launch-browser-smoke`** — drives the running app in a real browser to see a just-built change working — one-off, from the shell with `agent-browser`, no test suite and no evidence bundle ([ADR-0034](https://github.com/wemuda/launchrail/blob/master/docs/adr/0034-browser-smoke-one-off-driving.md); with the browser-testing module)
 - **`launch-implement`** — the one door to building: `/launch-implement` drives ready tickets to verified merges through the Ralph loop (a ticket number builds just that one; "the next 5 of spec #2" scopes and caps a run)
 - **`launch-ralph`**, **`launch-ralph-implement`**, **`launch-code-review`**, **`launch-resolving-merge-conflicts`** — the verification-gated loop engine behind that door, installed by `init`
+- **`launch-loop-readiness`** — checks and tunes a repo for the loop: measures the gates, sets the fast per-land gate, parallelizes the e2e specs, shares caches for parallel builders, narrows CI triggers, creates the tracker labels, adds hosted-session setup ([ADR-0033](https://github.com/wemuda/launchrail/blob/master/docs/adr/0033-loop-readiness.md)); `doctor` shows the same findings as warn-only readiness lines
 
 The CLI is the maintenance surface you return to between sessions:
 
@@ -73,7 +74,6 @@ npx @wemuda/launchrail sync                  # apply managed updates + run migra
 npx @wemuda/launchrail add browser-testing   # enable a module
 npx @wemuda/launchrail doctor                # repository and environment checks
 npx @wemuda/launchrail verify                # deterministic verification gate
-npx @wemuda/launchrail smoke                 # scaffold a browser-smoke evidence bundle
 npx @wemuda/launchrail eject <module|file>   # opt out of management (vendor mode: --all)
 ```
 
@@ -147,7 +147,7 @@ The toolchain is stable and versioned. The full surface — `init`/`doctor`, the
 See [CONTRIBUTING.md](https://github.com/wemuda/launchrail/blob/master/CONTRIBUTING.md). The short version:
 
 - Commits follow [Conventional Commits](https://www.conventionalcommits.org/) (`type(scope): summary`); see [ADR-0002](https://github.com/wemuda/launchrail/blob/master/docs/adr/0002-conventional-commits.md). Releases and the changelog are generated from them ([docs/releasing.md](https://github.com/wemuda/launchrail/blob/master/docs/releasing.md)).
-- Meaningful decisions are recorded as ADRs in [docs/adr/](https://github.com/wemuda/launchrail/tree/master/docs/adr/).
+- Meaningful decisions are recorded as ADRs in [docs/adr/](https://github.com/wemuda/launchrail/tree/master/docs/adr/); the registry index [docs/adr/README.md](https://github.com/wemuda/launchrail/blob/master/docs/adr/README.md) says which are live.
 - The agent operating contract lives in [AGENTS.md](https://github.com/wemuda/launchrail/blob/master/AGENTS.md).
 - Security issues go through [SECURITY.md](https://github.com/wemuda/launchrail/blob/master/SECURITY.md), not public issues.
 

package/assets/agents-docs/domain.md

@@ -11,7 +11,7 @@ How the workflow skills should consume this repo's domain documentation when exp
 
 - **`CONTEXT.md`** at the repo root, or
 - **`CONTEXT-MAP.md`** at the repo root if it exists — it points at one `CONTEXT.md` per context. Read each one relevant to the topic.
-- **`docs/adr/`** — read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
+- **`docs/adr/README.md`** — the decision registry. Read its index first, then open only the ADRs that touch the area you're about to work in. An ADR records a decision, not the current system — never take one as evidence that a component exists or still works as described; verify against the code. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
 
 If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `launch-grill` skill's domain-modeling discipline creates them lazily when terms or decisions actually get resolved.
 
@@ -44,7 +44,7 @@ Multi-context repo (presence of `CONTEXT-MAP.md` at the root):
         └── docs/adr/
 ```
 
-ADRs use the project's own format — copy `docs/adr/0000-template.md` and number sequentially (`NNNN-short-slug.md`).
+ADRs use the project's own format — copy `docs/adr/0000-template.md`, take the next free number (`NNNN-short-slug.md`), and add the record's row to the registry index (`docs/adr/README.md`) in the same commit.
 
 ## Use the glossary's vocabulary
 

package/assets/agents-docs/issue-tracker-github.md

@@ -28,7 +28,7 @@ The Launchrail workflow's label vocabulary — the skills quote these exact stri
 - **`ready-for-agent`** — an implementable ticket the implementation loop may pick up. Only tickets wear it; the loop's frontier is computed from this label alone and cannot tell prose from work.
 - **`needs-info`** — a parked ticket, carrying its failure history; a human unblocks it.
 - **`spec`** — a spec or research note published to the tracker. Never `ready-for-agent`.
-- **`ralph:building`** — claimed by an implementer; removed when its PR merges.
+- **`ralph:building`** — claimed by an implementer; removed when the loop lands it.
 - **`wayfinder:map`** / **`wayfinder:<type>`** — a wayfinder map and its decision tickets (see below).
 
 ## Relationships — native, not prose

package/assets/agents-docs/issue-tracker-linear.md

@@ -29,7 +29,7 @@ The Launchrail workflow's label vocabulary — the skills quote these exact stri
 - **`ready-for-agent`** — an implementable ticket the implementation loop may pick up. Only tickets wear it; the loop's frontier is computed from this label alone and cannot tell prose from work.
 - **`needs-info`** — a parked ticket, carrying its failure history; a human unblocks it.
 - **`spec`** — a spec or research note published to the tracker. Never `ready-for-agent`.
-- **`ralph:building`** — claimed by an implementer; removed when its PR merges.
+- **`ralph:building`** — claimed by an implementer; removed when the loop lands it.
 - **`wayfinder:map`** / **`wayfinder:<type>`** — a wayfinder map and its decision tickets (see below).
 
 ## When a skill says "publish to the issue tracker"