@ionivetech/mugiwara 0.6.5 → 0.7.0

package/content/skills/mugiwara-checkpoint/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: mugiwara-checkpoint
-description: Use after an execution wave to audit results — re-run acceptance criteria, verify commit hygiene, classify failures honestly, issue DoD verdict. Auditor only.
+description: Use after an execution flow stage to audit results — re-run acceptance criteria, verify commit hygiene, classify failures honestly, issue DoD verdict. Auditor only.
 ---
 
 # Checkpoint (Chopper)
 
 ## Skip when
 
-- No execution wave completed this mission — nothing to audit yet.
+- No execution flow stage completed this mission — nothing to audit yet.
 - User explicitly deferred the audit and recorded the reason in the decision log.
 
 Auditor, not fixer. Trust nothing; verify everything. Output is an audit report, not a code change.
@@ -18,26 +18,29 @@ Subagents lie. No evidence = not complete. A "done" claim is a starting point, n
 
 ## Audit protocol
 
-For every task in the completed wave, in order:
+For every task in the completed flow stage, in order:
 
 1. **Per-task audit table.** For each acceptance criterion record `task | criterion | command run | evidence | status`. Evidence is output or a clickable markdown file link (`[path](relative/path)`) — never a paraphrase.
-2. **Dedupe re-runs.** Several criteria often share the same command (a wave of tasks all keyed on `npm test`). Run each UNIQUE check command ONCE per wave, scope it to the files this wave changed, and attach the same evidence row to every criterion it covers. Do not re-run the same suite N times for N tasks.
-3. **Scope by diff.** Before re-running, inspect what actually changed (`git diff --name-only <wave-base>..HEAD`). Criteria whose inputs are untouched are verified by the scoped run, not a fresh full run. A criterion with NO command or file to point at is unverifiable — fail it, never waive it.
-4. **Commit hygiene.** Run `git log --stat <wave-base>..HEAD` ONCE (not `git show --stat` per commit) and check each task commit: it must touch ONLY the files the task declared. Undeclared files added or declared files missing = fail.
-5. **Parallel-conflict check.** Run `git diff --name-only` across parallel task commits: no file may be touched by 2 tasks. A shared file means the parallel claim was false.
-6. **Honest classification.** Classify every failure truthfully as code or env. Never file a code failure as `env`. If you cannot prove it is env (reproduce on a clean checkout), it is code.
+2. **Dedupe re-runs.** Several criteria often share the same command (a flow stage of tasks all keyed on `npm test`). Run each UNIQUE check command ONCE per flow stage, scope it to the files this flow stage changed, and attach the same evidence row to every criterion it covers. Do not re-run the same suite N times for N tasks.
+3. **Scope by diff.** Before re-running, inspect what actually changed (`git diff --name-only <flow-base>..HEAD`). Criteria whose inputs are untouched are verified by the scoped run, not a fresh full run. A criterion with NO command or file to point at is unverifiable — fail it, never waive it.
+4. **Reuse across flow stages.** If the diff is unchanged since the previous wave's report recorded a check result (same `flow-base`, same command), cite that result instead of re-running it. Changed diff → run fresh. This is the one exception to "never reuse a prior run": the prior run must be your own crew's, on-disk, with an identical diff.
+5. **Commit hygiene.** Run `git log --stat <flow-base>..HEAD` ONCE (not `git show --stat` per commit) and check each task commit: it must touch ONLY the files the task declared. Undeclared files added or declared files missing = fail.
+6. **Parallel-conflict check.** Run `git diff --name-only` across parallel task commits: no file may be touched by 2 tasks. A shared file means the parallel claim was false.
+7. **Honest classification.** Classify every failure truthfully as code or env. Never file a code failure as `env`. If you cannot prove it is env (reproduce on a clean checkout), it is code.
 
 ## Failure ledger
 
-Append each failing criterion as one row to `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md`:
+Row schema + worked rows: `references/ledger-format.md`.
 
-`| wave | task | symptom | attempted | help-needed |`
+Append each failing criterion as one row to `.mugiwara/missions/<mission>/blockers.md`:
+
+`| flow stage | task | symptom | attempted | help-needed |`
 
 Category goes in `symptom` or `help-needed` as context. Categories: `test-fail` (test/lint/build command fails), `missing-impl` (criterion unverifiable, artifact absent), `parallel-conflict` (concurrent tasks modified shared state), `env` (environment, proven), `regression` (previously passing check now fails). Reuse the existing blocker ledger; create it only if absent.
 
 ## Definition of Done check
 
-Per axis — `correctness`, `quality`, `integration`, `docs`, `ship-readiness` — each with evidence, then one wave verdict. Full definitions: `_shared/references/definition-of-done.md`. Any FAIL axis → wave verdict FAIL.
+Per axis — `correctness`, `quality`, `integration`, `docs`, `ship-readiness` — each with evidence, then one flow-stage verdict. Full definitions: `_shared/references/definition-of-done.md`. Any FAIL axis → flow-stage verdict FAIL.
 
 ## Auditor only
 
@@ -45,17 +48,17 @@ Never edit code. Findings only. Any urge to fix a finding means the audit has st
 
 ## Output
 
-Audit report to `.mugiwara/results/<mission>/02-audit.md`: per-task table, commit hygiene, parallel-conflict, honest classification, DoD verdicts, ledger rows. Show the verdict and the key evidence inline in the conversation — PASS → next wave. FAIL → report + ledger to Brook (Wave 8). You never fix a finding yourself; you may spawn check subagents for independent re-runs.
+Audit report to `.mugiwara/missions/<mission>/flows/02-audit.md`: per-task table, commit hygiene, parallel-conflict, honest classification, DoD verdicts, ledger rows. Show the verdict and the key evidence inline in the conversation — PASS → next flow stage. FAIL → report + ledger to Brook (Flow 8). You never fix a finding yourself; you may spawn check subagents for independent re-runs.
 
 ## Common rationalizations
 
-- "The test passed last run." → Re-run it now — once, scoped to what changed this wave. A stale result is not evidence, and a wave of duplicate runs is waste.
+- "The test passed last run." → Re-run it now — once, scoped to what changed this flow stage. A stale result is not evidence, and a flow stage of duplicate runs is waste.
 - "It's just an env issue." → Prove it on a clean checkout; unproven env is code.
 - "One small fix would clear it." → You are the auditor, not the healer. Report it.
 
 ## Iron Law
 
-TRUST NOTHING; VERIFY EVERYTHING. No evidence, no pass — and the evidence must be produced by your own re-run, not borrowed from the executor. Verify once per unique check, scoped to the wave's diff — thorough, not wasteful.
+TRUST NOTHING; VERIFY EVERYTHING. No evidence, no pass — and the evidence must be produced by your own re-run, not borrowed from the executor. Verify once per unique check, scoped to the flow stage's diff — thorough, not wasteful.
 
 ## Red flags
 

package/content/skills/mugiwara-checkpoint/references/ledger-format.md

@@ -1,18 +1,18 @@
 # Ledger Format
 
-Blocker ledger row format used by Chopper (wave-audit) and Brook (healing).
+Blocker ledger row format used by Chopper (flow-audit) and Brook (healing).
 
 ## Row format
 
 ```
-| wave | task | symptom | attempted | help-needed |
+| flow stage | task | symptom | attempted | help-needed |
 ```
 
 ## Fields
 
 | Field | Required | Description |
 |-------|----------|-------------|
-| `wave` | yes | Which wave produced the failure (4, 5, 6, 7, 8) |
+| `flow stage` | yes | Which flow stage produced the failure (4, 5, 6, 7, 8) |
 | `task` | yes | Task identifier from the plan (T3, T5, etc.) |
 | `symptom` | yes | What failed — error message, exit code, missing artifact. Include category: `test-fail`, `missing-impl`, `parallel-conflict`, `env`, `regression` |
 | `attempted` | yes | What was tried — "re-ran npm test -- scope", "checked caller imports" |
@@ -22,7 +22,7 @@ Blocker ledger row format used by Chopper (wave-audit) and Brook (healing).
 
 ```
 | 4 | T3 | test-fail: formatDate returns wrong locale | re-ran with en-US locale explicitly | locale detection differs between Node 18 and 20 |
-| 4 | T5 | missing-impl: no thumbnail endpoint | searched routes/ dir, not found | endpoint was in a different plan wave |
+| 4 | T5 | missing-impl: no thumbnail endpoint | searched routes/ dir, not found | endpoint was in a different plan flow stage |
 | 5 | T2 | env: vitest hangs on CI | re-ran locally, passes | needs --pool=forks flag on CI |
 ```
 
@@ -31,4 +31,4 @@ Blocker ledger row format used by Chopper (wave-audit) and Brook (healing).
 - Every blocker gets one row. Never combine two failures into one row.
 - Category goes in `symptom` or `help-needed` — whichever is more specific.
 - `env` classification must be proven (reproduce on clean checkout). Unproven = `test-fail`.
-- File at `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md`. Create if absent.
+- File at `.mugiwara/missions/<mission>/blockers.md`. Create if absent.

package/content/skills/mugiwara-contract-first/SKILL.md

@@ -27,6 +27,8 @@ Framework APIs from docs, not memory: `_shared/references/source-grounding.md`.
 
 Full 5-step protocol: `references/process.md` — contract first, error semantics, boundary validation, backward compatibility, versioning discipline. 27 lines; every step required.
 
+Versioning + deprecation moves: `references/versioning-playbook.md`.
+
 ## Rationalizations
 
 | Rationalization | Reality |

package/content/skills/mugiwara-execution/SKILL.md

@@ -8,7 +8,7 @@ description: Use when executing an approved plan — todo list first, sequential
 ## Skip when
 
 - No approved plan exists to execute — this is triage, brainstorm, or planning territory.
-- Lane 0 direct work (typo, rename, single small fix) with no wave structure.
+- Lane 0 direct work (typo, rename, single small fix) with no flow-stage structure.
 
 Execute the plan exactly. No silent reordering, no skipping steps, no "close enough".
 
@@ -17,7 +17,7 @@ Execute the plan exactly. No silent reordering, no skipping steps, no "close eno
 - `guided`: before touching any code, ASK THE USER — auto branch (dedicated mission branch, recommended, keeps `main` clean) or work on the current branch; auto commit per task or commit at user-controlled checkpoints. With `auto_commit=off`: the branch ask stays, the commit question is skipped — changes stay uncommitted.
 - `semi`: auto-create the mission branch per the config `branch` key; auto-commit per task in the config `commit` style ONLY when `auto_commit=on` (default). Off → leave every task's changes uncommitted; the user commits manually.
 - `auto`: auto-create the branch and auto-commit per task ALWAYS — `auto_commit=off` has no effect in auto mode.
-Record mode + branch + commit style + `auto_commit` in the decision log (`.mugiwara/logs/YYYY-MM-DD-<mission>.md`) and in `.mugiwara/results/<mission>/todos.md` — every mode.
+Record mode + branch + commit style + `auto_commit` in the decision log (`.mugiwara/missions/<mission>/decisions.md`) and in `.mugiwara/missions/<mission>/flows/todos.md` — every mode.
 
 Code to the installed version's docs, not memory: `_shared/references/source-grounding.md`. The plan doc stays clean — never edit it during execution except through Nami. If the user says no auto-commit in `guided`, still run every acceptance check and leave the diff staged or presented for approval. State-mutating consent is NOT covered by this rule — it still applies in every mode. One-task-one-commit, save-points, and atomic-commit rules hold unchanged in every mode.
 
@@ -25,14 +25,14 @@ Code to the installed version's docs, not memory: `_shared/references/source-gro
 
 Before touching code:
 
-1. Create `.mugiwara/results/<mission>/todos.md` — one checkbox per task, derived from the plan.
+1. Create `.mugiwara/missions/<mission>/flows/todos.md` — one checkbox per task, derived from the plan.
 2. Check each box off only when the task completes, WITH its evidence link (`[path](relative/path)`, clickable).
 3. Re-check the whole list after each task and after each batch; unmarked boxes mean the mission is not done.
-4. Mirror EVERY transition into the host's native todo tool (`todowrite` on opencode; `TaskUpdate` on Claude Code; none on tier 2/3 — plan doc only) in the SAME response the task's evidence lands — one transition per call, never batched at wave end. Per-host table: `docs/reference/harness-matrix.md`.
+4. Mirror EVERY transition into the host's native todo tool (`todowrite` on opencode; `TaskUpdate` on Claude Code; none on tier 2/3 — plan doc only) in the SAME response the task's evidence lands — one transition per call, never batched at flow-stage end. Per-host table: `docs/reference/harness-matrix.md`. Every task response opens with `[task N/M] <status>` — progress is visible on every harness, todo tool or not.
 
-## Wave execution
+## Flow-stage execution
 
-Before starting: if `.mugiwara/continue/<mission>/[member].json` exists, resume from its next_action — never re-run completed tasks; verify against todos `[x]` marks. Full protocol: `references/resume-batching.md` — batch-resume, TDD, user-test oracle.
+Before starting: if `.mugiwara/missions/<mission>/continue.json | continue-<member>.json` exists, resume from its next_action — never re-run completed tasks; verify against todos `[x]` marks. Full protocol: `references/resume-batching.md` — batch-resume, TDD, user-test oracle.
 
 1. Read the plan doc fully before touching code.
 2. Build the task graph from `[PARALLEL]`/`[SEQUENTIAL]` markers and depends-on fields.
@@ -44,14 +44,15 @@ Before starting: if `.mugiwara/continue/<mission>/[member].json` exists, resume
 ## Worker dispatch triggers
 
 1. **Independence** — `[PARALLEL]` batches, concurrent, one task per worker.
-2. **Context pressure** — when `tokens_est` exceeds `delegate_threshold`% of
-   `budget` (read from `.mugiwara/config`, default 60) mid-execution, remaining
-   SEQUENTIAL tasks dispatch to workers — one at a time, in plan order. Order is
-   preserved; only the context resets. Announce: `⚠ context 62% — remaining tasks run in fresh workers, plan order unchanged.`
+2. **Context pressure** — when `delegate_due` reads `true` in
+   `.mugiwara/missions/<mission>/state.json | <member>.json` (savepoint computes it as
+   `tokens_est ≥ delegate_threshold% of budget`, config default 60), remaining
+   SEQUENTIAL tasks dispatch to workers — one at a time, in plan order.
+   Announce: `⚠ context — remaining tasks run in fresh workers, plan order unchanged.`
 
-The threshold stays relative, never absolute: `tokens_est > delegate_threshold%
-× budget` (read from `.mugiwara/config`, default 60), never `tokens_est >
-80,000` (obsolete in six months). A bigger window raises the threshold; it does not remove it.
+Computed, never manual: savepoint emits `delegate_due` (relative
+`tokens_est ≥ delegate_threshold% × budget`, default 60), never an absolute
+`tokens_est > 80,000` (obsolete in six months). A bigger budget raises the bar; it does not remove it.
 
 ## Tier gating & fallback
 
@@ -59,14 +60,14 @@ Real worker dispatch exists only where the harness has subagents — tier 1
 (Claude Code, opencode) plus Copilot. Gate the context-pressure trigger on
 that capability: if the harness cannot dispatch, do not promise fresh workers.
 
-Where workers are unavailable and context pressure crosses the threshold:
+Where workers are unavailable and `delegate_due` is true:
 write a savepoint, run the checkpoint, and suggest a fresh session via
-`resume`. Announce: `⚠ context 62% — no worker dispatch on this harness;
+`resume`. Announce: `⚠ context — no worker dispatch on this harness;
 savepoint written, resume in a fresh session (plan order unchanged).`
 
 ## Batch resume
 
-After each batch, update `.mugiwara/continue/<mission>/[member].json` next_action to the next task; `[PARALLEL]` batches stay per sub-mission, never crossing a sub-mission boundary.
+After each batch, update `.mugiwara/missions/<mission>/continue.json | continue-<member>.json` next_action to the next task; `[PARALLEL]` batches stay per sub-mission, never crossing a sub-mission boundary.
 
 ## Task batching & delegation format (parallel workers only)
 
@@ -76,14 +77,13 @@ six-field worker prompt. Thin prompts cause thin results.
 ## Surfacing rule
 
 > **Delegated work is not hidden work.** A worker may run out of view; its
-> result may not. Every worker returns a wave banner, a one-line verdict, and an
+> result may not. Every worker returns a flow stage banner, a one-line verdict, and an
 > evidence link into the main thread. The user never clicks into a subagent to
 > know what happened.
 > Isolation is for context and permission, never for autonomy.
 
 ## TDD discipline & user tests
-
-Full protocol: `references/resume-batching.md` — batch-resume, TDD RED-GREEN-REFACTOR (`references/tdd.md`), user tests as oracle, failing-first rule.
+Full protocol: `references/resume-batching.md` — batch-resume, TDD RED-GREEN-REFACTOR (`references/tdd.md`), user tests as oracle, failing-first rule. One task end to end, RED through commit: `references/worked-example.md`.
 
 ## One logical task, one commit
 
@@ -91,7 +91,7 @@ Commit per LOGICAL task — a feature, fix, or refactor, not a micro-step; verif
 
 ## Blockers → issues ledger
 
-Blocked → one row `| wave | task | symptom | attempted | help-needed |` to `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md`, then escalate to Luffy. Never work around a blocker silently.
+Blocked → one row `| flow stage | task | symptom | attempted | help-needed |` to `.mugiwara/missions/<mission>/blockers.md`, then escalate to Luffy. Never work around a blocker silently.
 
 ## Frontend tasks
 
@@ -99,11 +99,11 @@ Any task touching UI markup, styling, or components applies `mugiwara-frontend`
 
 ## Report
 
-After each wave: compact task table (status, evidence link, deviations) shown inline in the conversation. Format: `references/dispatch.md` — report table. Then return to Luffy, who routes to Chopper (Wave 4). Write detailed execution log to `.mugiwara/results/<mission>/01-execution.md`. Never dispatch another crew member.
+After each flow stage: compact task table (status, evidence link, deviations) shown inline in the conversation. Format: `references/dispatch.md` — report table. Then return to Luffy, who routes to Chopper (Flow 4). Write detailed execution log to `.mugiwara/missions/<mission>/flows/01-execution.md`. Never dispatch another crew member.
 
 ## Step budget
 
-Tool calls are finite — harnesses cap them per session; a 9-wave mission that wastes them stalls before closure. Combine evidence runs (`evidence.sh <m> quality -- bash -c "lint && test"` — one call, not two); write wave artifacts once at wave end, not incrementally; never re-read what you just wrote; batch reads (one glob beats five reads); open a reference only when its pointer condition triggers.
+Tool calls are finite — harnesses cap them per session; a 9-flow-stage mission that wastes them stalls before closure. Combine evidence runs (`bash -c "lint && test"` — one call, not two); write flow stage artifacts once at flow-stage end, not incrementally; never re-read what you just wrote; batch reads (one glob beats five reads); open a reference only when its pointer condition triggers.
 
 Budget guide: Lane 1 ≤15 calls · Lane 2 ≤35 · Lane 3 ≤60. Crossing it is not a failure; announce it and check the context-pressure trigger.
 
@@ -117,8 +117,8 @@ Budget guide: Lane 1 ≤15 calls · Lane 2 ≤35 · Lane 3 ≤60. Crossing it is
 - Echoing raw output when `verbosity=normal` — summarize and cite the evidence path.
 - The task's TDD order inverted (implementation before the failing test).
 - A test passing immediately without having failed first (wrong test or testing existing behavior).
-- A commit containing files beyond its declared task, or a wave of micro-commits with no logical grouping.
+- A commit containing files beyond its declared task, or a flow stage of micro-commits with no logical grouping.
 - Dispatching a worker whose result is not summarized inline with an evidence link.
-- Host todo UI lags the plan doc — task done but unchecked, or list never seeded at Wave 2.
+- Host todo UI lags the plan doc — task done but unchecked, or list never seeded at Flow 2.
 
 All mean: stop, realign to the plan, or escalate to Luffy.

package/content/skills/mugiwara-execution/references/dispatch.md

@@ -1,7 +1,7 @@
 # Dispatch & batching detail
 
 Full detail behind `content/skills/mugiwara-execution/SKILL.md` — the output
-rule, the worker prompt format, and the per-wave report table.
+rule, the worker prompt format, and the per-flow stage report table.
 
 ## Task batching
 
@@ -15,7 +15,7 @@ T2: ✅ | 7 pointers rewritten | grep refs/ → clean
 T3: ✅ | 38/38 tests | bun run test
 ```
 
-Full logs go to `.mugiwara/results/<mission>/01-execution.md`. The main thread shows the summary table only. Tool calls visible below the banner are noise — batch them, squash the output.
+Full logs go to `.mugiwara/missions/<mission>/flows/01-execution.md`. The main thread shows the summary table only. Tool calls visible below the banner are noise — batch them, squash the output.
 
 ## Delegation format (parallel workers only)
 
@@ -32,7 +32,7 @@ A delegation prompt shorter than ~30 lines is too short — beef it up. Thin pro
 
 ## Report table
 
-After each wave: compact task table (status, evidence pointer, deviations) shown inline in the conversation. Format:
+After each flow stage: compact task table (status, evidence pointer, deviations) shown inline in the conversation. Format:
 
 ```
 | # | Task | Status | Evidence link |

package/content/skills/mugiwara-execution/references/resume-batching.md

@@ -23,9 +23,9 @@ that passes on first run has proven nothing.
 
 ## Batch-resume protocol
 
-- Before starting a wave: if `.mugiwara/continue/<mission>/[member].json` exists, resume from its
+- Before starting a flow stage: if `.mugiwara/missions/<mission>/continue.json | continue-<member>.json` exists, resume from its
   next_action — never re-run completed tasks; verify against todos `[x]` marks.
-- After each batch: update `.mugiwara/continue/<mission>/[member].json` next_action to the next task.
+- After each batch: update `.mugiwara/missions/<mission>/continue.json | continue-<member>.json` next_action to the next task.
 - `[PARALLEL]` batches stay per sub-mission — a batch never crosses a
   sub-mission boundary.
 - continue is the handoff contract: state proves what is done,

package/content/skills/mugiwara-frontend/SKILL.md

@@ -28,8 +28,7 @@ Match the repo's standard before writing anything new; reuse its components and
 Capture current layout, spacing/type scales, palette, and component inventory before changing existing UI. Fix real problems; do not restyle what works.
 
 ## Design-system extraction (before markup)
-
-Extract tokens from the stack's design system BEFORE markup — spacing scale, type scale, role-based palette, radii, shadows, motion language. Name them semantically (`surface-muted`, not `c3`); store where the stack keeps tokens. No tokens extracted, no markup written. Then turn tokens into a small primitive set (button, input, card, icon, layout helpers) before composing screens — reuse primitives everywhere; every bespoke component is debt on every screen.
+Extract tokens from the stack's design system BEFORE markup — spacing scale, type scale, role-based palette, radii, shadows, motion language. Name them semantically (`surface-muted`, not `c3`); store where the stack keeps tokens. No tokens extracted, no markup written; token set and naming: `references/design-tokens.md`. Then turn tokens into a small primitive set (button, input, card, icon, layout helpers) before composing screens — reuse primitives everywhere; every bespoke component is debt on every screen.
 
 ## Component architecture
 
@@ -66,14 +65,13 @@ Extract tokens first, then reproduce structure faithfully: hierarchy, alignment,
 Mobile-first: start at the smallest screen, add breakpoints as layout needs them. Default full-width stacked; columns only when there is room. Use the stack's breakpoints, not a parallel scale; fluid containers, type, and spacing. Verify at every breakpoint, including between them — 3 widths checked is not 12 checked.
 
 ## Banned AI-default patterns (the slop list)
-
 - Centered hero trio: headline + subtitle + two buttons, dead center, gradient text.
 - Row of 3-4 identical feature cards with icon-circle + title + two lines.
 - Purple/indigo gradient everything; glassmorphism everywhere; emoji as icons.
 - Placeholder content where real product copy exists.
 - Stock hero illustrations when the design specifies otherwise.
 
-If the brief genuinely calls for one of these, execute it well — but the default is: don't.
+Full catalog with the tell for each: `references/slop-catalog.md`. If the brief genuinely calls for one of these, execute it well — but the default is: don't.
 
 ## WCAG 2.1 AA accessibility
 
@@ -87,14 +85,15 @@ Non-negotiable baseline. Full checklist: `references/checklist.md`.
 
 ## Testability and verification
 
-Add stable `data-testid` to interactive elements per the repo's testing convention. Never test by CSS class or by text that changes. Then compare the result against the reference side by side; list remaining deltas before calling it done.
+Add stable `data-testid` to every interactive element per the repo's testing convention; async states (loading/error/empty) get testids too. Never test by CSS class or by text that changes. Prefer role/label queries (`getByRole`) in tests — an accessible name doubles as an accessibility assertion. Keyboard paths for non-trivial interactions (menu, modal, form) are asserted, not assumed. Then compare the result against the reference side by side; list remaining deltas before calling it done.
 
 ## Performance
 
+- Core Web Vitals are the bar: LCP <2.5s, CLS <0.1, INP <200ms. Images carry width/height or aspect-ratio (CLS); the LCP asset is preloaded and fonts ship `font-display` (LCP); input handlers stay off the main thread (INP).
 - No layout thrash: batch DOM reads/writes; heavy work off the scroll path; animate only transform/opacity.
 - Assets: no giant images/font payloads; lazy-load below the fold; no whole icon library for two icons.
 - No re-render storms: memoize heavy computation, stable keys, no work in render.
-- Measure before optimizing; do not guess the bottleneck.
+- Repo has Lighthouse or lighthouse-ci? Run it — performance and accessibility scores meet the repo's budgets, deltas explained. Measure before optimizing; do not guess the bottleneck.
 
 ## Frontend security
 

package/content/skills/mugiwara-frontend/references/checklist.md

@@ -35,3 +35,17 @@ Run before calling a view done. Every box must check; unchecked boxes are not do
 - [ ] Dynamic updates announced via `aria-live` with appropriate `polite`/`assertive`.
 - [ ] `prefers-reduced-motion` respected; motion scales, never disables content.
 - [ ] No interaction reachable only by mouse; nothing requires drag to operate.
+
+## Testability
+
+- [ ] Stable `data-testid` on every interactive element and on each async state (loading/error/empty).
+- [ ] Tests query by role/label, never by CSS class or mutable text.
+- [ ] Keyboard paths asserted in tests for non-trivial interactions (menu, modal, form submit).
+
+## Performance (Core Web Vitals)
+
+- [ ] Every image has width/height or aspect-ratio — no layout shift on load.
+- [ ] LCP asset preloaded; fonts use `font-display: swap`; nothing above the fold lazy-loaded.
+- [ ] Below-fold media and routes lazy-loaded; no whole icon/font library imported for a few glyphs.
+- [ ] Input handlers free of long tasks; heavy work deferred or chunked (INP).
+- [ ] Lighthouse/lighthouse-ci run when the repo has it: performance and accessibility at/above budget, deltas listed.

package/content/skills/mugiwara-gates/SKILL.md

@@ -16,28 +16,32 @@ Gates are binary: pass or fail, with evidence. No negotiation, no "almost passes
 
 1. Measure coverage with the project's existing tooling.
 2. Read thresholds from `.mugiwara/config` then `~/.mugiwara/config` for `coverage_new` and `coverage_modified`. Defaults: new ≥ 90%, modified ≥ 80%. Missing key or 0 = no threshold. Identify new/modified via git diff.
-3. No coverage tooling → report the gap, propose minimal tooling, ask user to add or waive.
-4. User-AC declared (per `mugiwara-testcases`): config thresholds apply to unit-level code only; user-AC verdict governs ship-readiness.
+3. No coverage tooling or no test suite → record a SKIP with its reason. Never a fake pass; propose minimal tooling, ask user to add or waive.
+4. In this repo the gate is executable: `bun run coverage-gate` (`scripts/coverage-gate.ts`) does all three against the mission's `base_sha`, and runs as the last step of `bun run gate`. Never lower a threshold or exclude a file to make it green — add the missing tests.
+5. User-AC declared (per `mugiwara-testcases`): config thresholds apply to unit-level code only; user-AC verdict governs ship-readiness.
 
 ## Sonar-style quality gate
 
-Franky reads evidence from prior wave reports (never re-runs
-checks): Jinbe (`.mugiwara/review/<mission>-security.md`),
-Robin (`.mugiwara/review/<mission>-review.md`), Sanji
-(`.mugiwara/results/<mission>/03-quality.md`).
+Franky reads evidence from prior flow-stage reports (never re-runs
+checks): Jinbe (`.mugiwara/missions/<mission>/security.md`),
+Robin (`.mugiwara/missions/<mission>/review.md`), Sanji
+(`.mugiwara/missions/<mission>/flows/03-quality.md`).
 Evaluated: Vulnerabilities=0, Bugs=0, Code smells≤project
 threshold, Coverage(new code)≥config threshold,
 Duplications(new code)<3%, Security hotspots reviewed≥80%.
+These mirror Sonar's default gate on new code; its AI-Code variant adds
+security rating A and reliability rating C on new code with hotspots 100%
+reviewed — adopt when the team asks for it.
 PASS when ALL pass — list each with actual + threshold.
 Missing data → CANNOT pass: report gap, do not fake.
 
 ## Build gate
 
-Run the project's build (or typecheck for interpreted stacks). Must exit 0. Capture the tail of output.
+Run the project's build (or typecheck for interpreted stacks). Must exit 0. Capture the tail of output. Skip when `flows/03-quality.md` already recorded an exit-0 build on an unchanged diff.
 
 ## Optional e2e gate (per `mugiwara-quality`)
 
-Runs only when quality wave triggered it (repo e2e setup + changed-file e2e patterns, user consent). Skipped/unrun is logged, never blocks PASS. Final verdict: coverage + sonar + build + DoD.
+Runs only when quality flow stage triggered it (repo e2e setup + changed-file e2e patterns, user consent). Skipped/unrun is logged, never blocks PASS. Final verdict: coverage + sonar + build + DoD.
 
 ## Definition of Done standing gate
 
@@ -50,8 +54,8 @@ A fixed cross-project bar. Full definitions: `_shared/references/definition-of-d
 
 ## Verdict
 
-PASS only when coverage AND sonar AND build AND DoD all pass with evidence. Write verdict to `.mugiwara/results/<mission>/04-gates.md`.
-PASS → return to Luffy (routes to Robin/Jinbe). FAIL → list files under threshold + by how much → return to Luffy (routes to Brook). Never dispatch next wave yourself.
+PASS only when coverage AND sonar AND build AND DoD all pass with evidence. Write verdict to `.mugiwara/missions/<mission>/flows/04-gates.md`.
+PASS → return to Luffy (routes to Robin/Jinbe). FAIL → list files under threshold + by how much → return to Luffy (routes to Brook). Never dispatch the next flow stage yourself.
 
 ## Red flags
 

package/content/skills/mugiwara-git/SKILL.md

@@ -7,7 +7,7 @@ description: Use for commits, splitting, or git history debugging — atomic com
 
 ## Skip when
 
-- No commits to make this wave — nothing staged, nothing to split or amend.
+- No commits to make this flow stage — nothing staged, nothing to split or amend.
 - User handles version control manually for this mission.
 
 Git hygiene keeps the mission reversible: one logical change per commit, a save-point before risky work, and history you can bisect.
@@ -29,7 +29,7 @@ Git hygiene keeps the mission reversible: one logical change per commit, a save-
 
 1. A large task becomes multiple commits, one per logical step in the plan.
 2. Split boundaries follow the plan's tasks: no commit spans two plan tasks, no plan task is left partially committed.
-3. Commit each step the moment it is green; never batch a whole wave into one commit.
+3. Commit each step the moment it is green; never batch a whole flow stage into one commit.
 
 ## Commit message conventions
 
@@ -37,12 +37,17 @@ Git hygiene keeps the mission reversible: one logical change per commit, a save-
 2. Scoped subject when scope is not obvious: `feat(auth): enforce session TTL`.
 3. Body (after a blank line) explains WHY, not what. What is visible in the diff; why is not.
 4. Match the repo's existing style — detect it before writing messages (below).
+5. Config `commit` may be a template: any value containing `{` is a template with
+   placeholders `{type}` `{issue}` `{title}` (e.g. `{issue}: {title}` → `CR-5432: Testing
+   button`). Fill placeholders from mission metadata; `{issue}` falls back to the date.
+   Style names (conventional/gitmoji/plain) keep their normal rules.
 
 ## Style detection
 
 1. Inspect existing history before the first commit: `git log --oneline -20`.
 2. Copy the observed conventions: prefix style (`feat:`/`fix:` vs plain), subject case, body usage, subject length.
 3. No commits in the repo yet → adopt conventional commits and note it in the plan.
+4. A config `commit` template overrides history detection — the user's format wins.
 
 ## Branch naming
 

package/content/skills/mugiwara-healing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mugiwara-healing
-description: Use when an execution wave failed, earlier waves produced failures, broken things to fix — reads blocker ledger, stop-the-line triage, root-cause fixes, prove-it before fixing. Max 3 cycles.
+description: Use when an execution flow stage failed, earlier flow stages produced failures, broken things to fix — reads blocker ledger, stop-the-line triage, root-cause fixes, prove-it before fixing. Max 3 cycles.
 ---
 
 # Healing (Brook)
@@ -14,7 +14,7 @@ Fix what failed, minimally, and prove it. One clean retry per cycle.
 
 ## Read the ledger first
 
-Brook's inputs: `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md` rows + quality report (Sanji), gate verdict (Franky), review findings (Robin), security report (Jinbe). Process each ledger row — every row is one healing unit. Rows are appended by any agent that hit a blocker; never skip a row.
+Brook's inputs: `.mugiwara/missions/<mission>/blockers.md` rows + quality report (Sanji), gate verdict (Franky), review findings (Robin), security report (Jinbe). Process each ledger row — every row is one healing unit. Rows are appended by any agent that hit a blocker; never skip a row.
 
 ## Stop-the-Line triage (per failure)
 
@@ -39,6 +39,8 @@ Before fixing a bug: write the failing test that reproduces it, watch it fail, t
 
 ## Triage matrix
 
+Full taxonomy behind the matrix: `references/failure-taxonomy.md`.
+
 | Failure | Action |
 |---------|--------|
 | lint/format error | auto-fix (formatter when supported), re-run |
@@ -53,15 +55,15 @@ Before fixing a bug: write the failing test that reproduces it, watch it fail, t
 2. Every code fix ships with the failed check now passing (run it, capture output).
 3. Never delete or weaken tests/configs to make a failure disappear.
 4. After healing: update the ledger — mark each healed row with evidence; keep unfixed rows for escalation.
-5. Cycle counter: read `heal_cycle` from `.mugiwara/state/<mission>/[member].json` (savepoint writes it). After this wave the flow returns to Wave 4 (Chopper) for re-audit. **At 3, STOP and escalate to the user with full history — a halt, not a red flag.** Red flags are prose; the counter is state. Never re-run past 3.
+5. Cycle counter: read `heal_halt` from `.mugiwara/missions/<mission>/state.json | <member>.json` (savepoint writes it as `heal_cycle ≥ heal_max_cycles`, config default 3). After this flow stage the flow returns to Flow 4 (Chopper) for re-audit. **When `heal_halt` reads `true`, STOP and escalate to the user with full history — a halt, not a red flag.** Red flags are prose; the counter is state. Never re-run past `heal_max_cycles`.
 
 ## Worker subagents
 
-Brook runs inline for triage + ledger reading; parallel fixes use disposable WORKER subagents. Full protocol: `references/workers.md` — heal-worker grouping (independent rows in parallel), 5-field worker prompt, validation workers (reviewer/security/re-run), then back to Wave 4. Workers are NOT crew members.
+Brook runs inline for triage + ledger reading; parallel fixes use disposable WORKER subagents. Full protocol: `references/workers.md` — heal-worker grouping (independent rows in parallel), 5-field worker prompt, validation workers (reviewer/security/re-run), then back to Flow 4. Workers are NOT crew members.
 
 ## Output
 
-Fixed list (finding → commit → evidence), escalated list (finding → plan → owner), updated ledger → back to Wave 4 (Chopper).
+Fixed list (finding → commit → evidence), escalated list (finding → plan → owner), updated ledger → back to Flow 4 (Chopper).
 
 ## Red flags
 

package/content/skills/mugiwara-healing/references/workers.md

@@ -20,7 +20,7 @@ Group 2 [SEQUENTIAL]: Row 3 (rbac.ts)
 ```
 
 Each heal worker receives a prompt with 5 fields:
-- **FAILURE** — ledger row verbatim (wave, task, symptom, attempted)
+- **FAILURE** — ledger row verbatim (flow stage, task, symptom, attempted)
 - **ROOT CAUSE** — Brook's triage result: where the bug is, why it happened
 - **FIX** — what to change, which file, which function
 - **MUST DO** — Prove-It: write regression test, watch it fail, implement fix, watch it pass, commit
@@ -33,6 +33,6 @@ After all heal workers complete, dispatch validation workers in parallel:
 - **security-worker** — security pass over fixes (per `mugiwara-security`)
 - **re-run-check worker** — independently re-runs failed checks, returns raw evidence
 
-Flow: Brook triage + grouping → dispatch heal workers parallel → aggregate results → dispatch validation workers → update ledger → back to Wave 4.
+Flow: Brook triage + grouping → dispatch heal workers parallel → aggregate results → dispatch validation workers → update ledger → back to Flow 4.
 
 Workers are NOT crew members — disposable subagents, one narrow job per worker. Crew runs inline in main thread.

package/content/skills/mugiwara-lessons/SKILL.md

@@ -14,7 +14,7 @@ The crew's institutional memory. Every mission writes what it learned so the nex
 
 ## The ledger
 
-`.mugiwara/logs/lessons.md` — append-only, shared across all missions in this repo.
+`.mugiwara/lessons.md` — append-only, shared across all missions in this repo.
 
 ```
 | YYYY-MM-DD | mission | area | lesson |
@@ -47,7 +47,7 @@ A lesson that can't change future behavior is noise. Skip it.
 
 ## Memory hygiene
 
-Lessons are cross-mission but per-repo. The ledger lives in `.mugiwara/logs/` so it never pollutes the codebase. Read the whole file, apply only the rows touching this mission's area.
+Lessons are cross-mission but per-repo. The ledger lives at `.mugiwara/lessons.md` so it never pollutes the codebase. Read the whole file, apply only the rows touching this mission's area.
 
 ## Common rationalizations