@ionivetech/mugiwara 0.7.0 → 0.8.0

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

@@ -1,6 +1,7 @@
 ---
 name: mugiwara-frontend
 description: Use for frontend component, CSS styling, responsive layout, accessible — matching standards, extraction.
+gate_artifact: flows/01-execution.md — frontend evidence (tokens.css + component evidence)
 ---
 
 # Frontend (Anti-Slop)
@@ -9,41 +10,52 @@ description: Use for frontend component, CSS styling, responsive layout, accessi
 
 - Diff touches no UI code: backend, docs, config, or CLI-only change.
 - No visual change, markup, styling, or frontend behavior in the mission.
-
 Interfaces built under this skill must not look templated.
 
 ## Source-backed code
 
 Framework code from docs, not memory — `_shared/references/source-grounding.md`.
-
+- React Server Actions: `useActionState` for form pending/error state — https://react.dev/reference/react/useActionState
+- Tailwind class scanning: `content` purge paths — https://v3.tailwindcss.com/docs/content-configuration
 ## Existing repo standard first
 
 Match the repo's standard before writing anything new; reuse its components and patterns. Greenfield with no UI: skip to design-system extraction.
 - Component library (MUI/Tailwind/shadcn/etc) — a new button looks like the repo's buttons, not the internet's.
 - File conventions, naming, folder structure, CSS strategy; lint/format/test scripts.
 - Tokens already in the theme/config; existing page patterns — how pages compose sections and state.
-
 ## Redesigns: audit first
 
 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; 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.
 
+Tokens BEFORE markup — no tokens, no markup. Write `tokens.css` (CSS custom properties on `:root`) unless the stack keeps tokens elsewhere:
+- Spacing: 4/8 grid — 4, 8, 12, 16, 24, 32, 48, 64 (`space-xs`…`space-3xl`).
+- Type: 12/14/16/18/24/32/48 scale, 1.5 line-height, 45–75ch measure (`text-sm`…`text-display`).
+- Role palette: `surface-muted`, `text-primary`, `border-default`, `accent` — semantic, not color names.
+- Radii: 2/4/8/12/full; shadows sm–xl; motion: duration + easing (`duration-fast`, `ease-in-out`).
+Semantic names only (`surface-muted`, never `gray-100`). Full rules: `references/design-tokens.md`.
+
+## Primitives (reuse, 100%)
+
+Build `Button`, `Input`, `Card`, `Stack` from tokens; compose every screen from them. A bespoke component is debt on every screen — reuse primitives or justify the exception.
+- Storybook story per primitive as behavior reference, not a build harness — https://storybook.js.org/docs
+- Tailwind: `content: ['./src/**/*.{ts,tsx}']` purge in `tailwind.config.ts`; `prettier-plugin-tailwindcss` for stable class order.
+- Variants over props soup: 3+ boolean props = split the component; children/slots over config flags.
+## Server Actions (React)
+
+`useActionState(fn, initial)` returns `[state, formAction, isPending]`; pass `formAction` to `<form action>`. Progressive enhancement works even before hydration.
+- Disable submit while `isPending` (`useFormStatus` for nested buttons).
+- Render `state.error` into a `role="alert"`/`aria-live` region; every async region gets a `data-testid`.
+- Keyboard path asserted: tab order, focus, Enter/Escape; no focus trap without escape.
 ## Component architecture
 
-Compose, don't inherit. Small, single-purpose components; the tree mirrors the page, not a god-component.
-- Boundaries: one component = one responsibility; extract on reuse; leaves stay presentational (no data fetching).
+Compose, don't inherit. One responsibility per component; extract on reuse; leaves presentational (no data fetching).
 - Composition over configuration: children/slots beat dozens of props.
-- Props: primitives and plain callbacks over object-shaped flags; 3+ boolean props = split the component.
 - Naming by role (`ProductCard`, not `CardA`); variants over copy-paste.
-
 ## State management
 
-Minimal state, local first; lift only what is shared.
-- Server vs client state: never store a per-screen copy of API data; cache/refetch at a data layer; derive on render.
-- Single source of truth per state, no duplicate mirrors; lift only when siblings share — context/store for app-wide state, not one screen.
-- Loading, error, empty, success states designed, not an afterthought.
+Minimal state, local first; lift only what is shared. Server vs client: cache/refetch at a data layer, derive on render; no per-screen copies of API data. Loading/error/empty/success designed, not an afterthought.
 
 ## From Figma / image references
 
@@ -53,61 +65,48 @@ Extract tokens first, then reproduce structure faithfully: hierarchy, alignment,
 
 - Hierarchy and rhythm: one primary action per view, one focal point, consistent spacing.
 - Restraint: fewer, more considered elements; whitespace is a tool.
-- Typography: 1-2 typefaces, deliberate scale, weight for emphasis not decoration, 45-75ch lines.
-- Color: role-based palette, contrast AA minimum, never pure-black-on-pure-white for text-heavy surfaces.
-- Consistency: the same thing looks the same everywhere; no three ways to render a button.
+- Typography: 1-2 typefaces, deliberate scale, weight for emphasis, 45-75ch lines.
+- Color: role-based palette, contrast AA minimum, never pure-black-on-pure-white for text.
+- Consistency: the same thing looks the same everywhere.
 - Intentionality: every element earns its place; if you cannot say why, remove it.
-- State design: hover, focus, active, disabled, loading, error, empty — designed, not forgotten.
-- Craft: deliberate spacing grids; subtle motion respecting `prefers-reduced-motion`; verified at all breakpoints.
-
+- State design: hover, focus, active, disabled, loading, error, empty — designed.
+- Craft: spacing grids; motion respecting `prefers-reduced-motion`; verified at breakpoints.
 ## Responsive behavior
 
-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.
+Mobile-first; 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.
+## Performance budgets
 
-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.
+- LCP <2.5s, CLS <0.1, INP <200ms. Images carry width/height or aspect-ratio; LCP asset preloaded; fonts `font-display`; input handlers off the main thread.
+- No layout thrash; animate only transform/opacity; lazy-load below the fold; no whole icon library for two icons; no re-render storms (stable keys, no work in render).
+- Lighthouse/lighthouse-ci in repo? Run it; scores meet budgets, deltas explained. Measure before optimizing.
+## Banned AI-default patterns (the slop list)
 
+- Centered hero trio; row of 3-4 identical feature cards; purple/indigo gradient everything; glassmorphism; emoji as icons; placeholder copy; stock hero illustrations.
+- Full catalog with the tell for each: `references/slop-catalog.md`. Brief genuinely calls for one? Execute it well — but default is don't.
 ## WCAG 2.1 AA accessibility
 
-Non-negotiable baseline. Full checklist: `references/checklist.md`.
-
-- Keyboard: every interaction operable by keyboard alone; logical tab order; visible focus; no focus trap without escape.
-- Semantics: native elements over ARIA; landmarks; logical heading order; buttons for actions, links for navigation.
+Full checklist: `references/checklist.md`.
+- Keyboard: operable alone; logical tab order; visible focus; no trap without escape.
+- Semantics: native elements over ARIA; landmarks; logical heading order.
 - Contrast: 4.5:1 text, 3:1 large text/UI; never color-only meaning.
-- Forms: every input labeled (placeholder is not a label); errors/success announced; `aria-describedby` help.
-- Dynamic content: `aria-live` for changes; reduced-motion respected.
-
+- Forms: every input labeled (placeholder is not a label); `aria-describedby` help.
+- Dynamic content: `aria-live`; reduced-motion respected.
 ## Testability and verification
 
-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.
-- 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.
+Stable `data-testid` on every interactive element and every async state (loading/error/empty). Never test by CSS class or by text that changes. Prefer `getByRole` — accessible name doubles as an a11y assertion. Keyboard paths asserted for menu/modal/form. Compare result against reference; list remaining deltas before done.
 
 ## Frontend security
 
 - Never render user content via `dangerouslySetInnerHTML`/`v-html` unless sanitized.
 - Escape user input in every template; no secrets in client code; validate URL params/storage/API input.
 - `rel="noopener"` on `target="_blank"`; validate URLs before navigating.
-
 ## Red flags
 
 - "Optimize when it's slow" — perf regressions ship measured later, rarely.
 - "It's client-side, so no security review" — client is public by definition.
 - "New screen, new components" — primitives are default; bespoke is exception.
 - "Global store for everything" — local state first; lift only what's shared.
-
 ## Common Rationalizations
 
 | Excuse | Reality |
@@ -120,3 +119,4 @@ Add stable `data-testid` to every interactive element per the repo's testing con
 | "Our repo is messy, I'll use my own style." | Match the repo standard first, then propose raising it. |
 
 If a rationalization wins, name it in the report as a known delta — not as silence.
+

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

@@ -1,6 +1,7 @@
 ---
 name: mugiwara-gates
 description: Use after quality checks — sonar-style gate, coverage thresholds, build exit 0, Definition of Done. Binary verdicts with evidence, no negotiation.
+gate_artifact: flows/04-gates.md verdict — coverage + build + DoD evidence
 ---
 
 # Gates (Franky)
@@ -15,37 +16,42 @@ Gates are binary: pass or fail, with evidence. No negotiation, no "almost passes
 ## Coverage gate
 
 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.
+2. Read thresholds from `.mugiwara/config` then `~/.mugiwara/config` for `coverage_new` and `coverage_modified`. Defaults: new ≥ 85%, modified ≥ 90%. Policy may raise, never lower. Missing key or 0 = no threshold. Identify new/modified via git diff.
 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 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.
+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`).
+
+Grounding (quality gate = conditions measured against new code during analysis): https://docs.sonarsource.com/sonarqube-server/quality-standards-administration/managing-quality-gates/introduction-to-quality-gates.md — Sonar way: no new issues, all new hotspots reviewed, coverage ≥ 80%, duplication ≤ 3%. Agentic-AI variant thresholds: https://docs.sonarsource.com/sonarqube-cloud/standards/ai-code-assurance/quality-gate-for-agentic-ai.md
+
+Evaluated against these fixed numbers (policy may raise, never lower):
+- Vulnerabilities (new) = 0
+- Bugs (new) = 0
+- Code smells (new) ≤ project threshold
+- Coverage (new code) ≥ config threshold (default 90%)
+- Duplications (new code) < 3%
+- Security hotspots reviewed ≥ 80%
+
+PASS only when ALL pass — list each with actual + threshold. Missing data → CANNOT pass: report the gap, do not fake.
 
 ## Build gate
 
 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.
 
+## Diff size gate (reviewability)
+
+The change diff against `base_sha` must be ≤ 400 LOC (via `git diff --numstat`). Larger → FAIL with the count; split into smaller changes before re-checking. An oversized diff is not reviewable regardless of other green gates.
+
 ## Optional e2e gate (per `mugiwara-quality`)
 
 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
 
-A fixed cross-project bar. Full definitions: `_shared/references/definition-of-done.md`. PASS only when all hold:
+A fixed cross-project bar. Full definitions: `_shared/references/definition-of-done.md`. PASS only when all five axes hold:
 - Correctness — work does what plan specifies.
 - Quality — lint/format/unit clean, configs unweakened.
 - Integration — fits existing system (build/typecheck green).
@@ -54,8 +60,7 @@ 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/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.
+PASS only when coverage AND sonar AND build AND diff-size AND DoD all pass with evidence. Write verdict to `.mugiwara/missions/<mission>/flows/04-gates.md` — each criterion with actual + threshold (see `gate_artifact`). 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
 
@@ -66,5 +71,6 @@ PASS → return to Luffy (routes to Robin/Jinbe). FAIL → list files under thre
 - Gate waived without explicit user decision.
 - PASS on coverage/build while DoD fails.
 - Sonar PASS with unverified or faked data.
+- Diff > 400 LOC passed without split.
 - Echoing raw output when `verbosity=normal` — summarize and cite the evidence path.
 All mean: the gate has not actually run. Report the gap or the fail, honestly.

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

@@ -1,6 +1,7 @@
 ---
 name: mugiwara-healing
 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.
+gate_artifact: flows/05-healing.md — root-cause + guard test evidence
 ---
 
 # Healing (Brook)
@@ -9,37 +10,39 @@ description: Use when an execution flow stage failed, earlier flow stages produc
 
 - No failures recorded: blocker ledger empty, all gates and reviews passed.
 - User explicitly accepts a failure as-is and recorded the decision.
+- Failure reproduces only outside a clean checkout — proven `env`, not code.
 
-Fix what failed, minimally, and prove it. One clean retry per cycle.
+Fix what failed, minimally, and prove it. One clean retry per cycle; `heal_halt` at 3.
 
 ## Read the ledger first
 
-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.
+Inputs: `.mugiwara/missions/<mission>/blockers.md` rows + quality report, gate verdict, review findings, security report. Every row is one healing unit; rows are appended by any agent that hit a blocker — never skip a row. Row fields: flow stage, task, symptom, attempted, help-needed. Full taxonomy: `references/failure-taxonomy.md`.
 
-## Stop-the-Line triage (per failure)
+## Stop-the-line triage (per failure)
 
-1. PRESERVE evidence: save the failing output/state before touching anything.
-2. Reproduce: re-run the failure, confirm it is real and current.
-3. Localize: layer map of where it sits (config/test/code/env); use `git bisect` when a regression window is unclear.
-4. Reduce: shrink to the minimal case that still fails.
-5. Diagnose before you touch code. Read the error in full (line, file, code), ask what changed recently (`git diff`, new deps, config), and chase the bad value upstream to its origin. Grep every caller before patching — a fix aimed only at the visible symptom leaves its siblings broken.
-6. Test one theory at a time. State it, try the smallest change that could confirm it, and check. A failed theory → a new one; never pile a second fix on top of the first.
-7. Guard with a regression test that fails without the fix.
-8. Verify end-to-end: run the failed check, capture output.
+1. PRESERVE evidence — save the failing output/state verbatim before touching anything.
+2. Reproduce — re-run the failure; confirm it is real and current.
+3. Localize — layer map (config/test/code/env); `git bisect` when the regression window is unclear.
+4. Reduce — shrink to the minimal case that still fails.
+5. Diagnose before touching code — read the full error (line, file, code), ask what changed recently (`git diff`, new deps, config), chase the bad value upstream to its origin. Grep every caller before patching — a fix aimed only at the visible symptom leaves its siblings broken.
 
-Never push past a failing test — a red test stops the line until it is green or escalated.
+Never push past a failing test — a red test stops the line until green or escalated.
 
-## When fixes keep failing → question the foundation
+## Root-cause, not symptom
 
-Two or three different fixes that each uncover a fresh dependency somewhere else are a signal you're patching a symptom. The foundation, not the failure, is wrong. Stop, lay out the pattern to Luffy and the human, and argue about the architecture before attempting another fix.
+Fix at the shared function, not the caller that surfaced. One fix = smallest diff resolving the finding. No drive-by refactors. Test one theory at a time: state it, try the smallest change that could confirm it, check. A failed theory → a new one; never pile a second fix on top of the first.
 
-## Prove-It pattern
+## Prove-It (red → green)
 
-Before fixing a bug: write the failing test that reproduces it, watch it fail, then fix until green. Red → code → green, in that order. A fix with no reproducing test is unproven.
+Before fixing a bug: write the failing test that reproduces it, watch it fail, then fix until green. Red → code → green, in that order. A fix with no reproducing test is unproven. Every code fix ships with the failed check now passing — run it, capture output.
+
+## Two-or-three-signal foundation check
+
+Two or three different fixes that each uncover a fresh dependency elsewhere = symptom-patching. Stop, lay out the pattern to Luffy and the human, argue about the architecture before attempting another fix.
 
 ## Triage matrix
 
-Full taxonomy behind the matrix: `references/failure-taxonomy.md`.
+Full taxonomy: `references/failure-taxonomy.md`.
 
 | Failure | Action |
 |---------|--------|
@@ -49,13 +52,11 @@ Full taxonomy behind the matrix: `references/failure-taxonomy.md`.
 | blocker security/review finding | smallest safe diff; add or extend the test that catches it |
 | architectural finding / high-risk change | DO NOT auto-fix — prepare fix/rollback plan, escalate to Luffy → human |
 
-## Rules
+Env rule: `env` must reproduce on a clean checkout in the same environment, or fail only on one OS/CI. "Probably env" is not proof — it stays a code failure until proven otherwise.
+
+## Cycle counter (`heal_halt`)
 
-1. One fix = smallest diff resolving the finding. No drive-by refactors.
-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_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`.
+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, 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
 
@@ -63,7 +64,7 @@ Brook runs inline for triage + ledger reading; parallel fixes use disposable WOR
 
 ## Output
 
-Fixed list (finding → commit → evidence), escalated list (finding → plan → owner), updated ledger → back to Flow 4 (Chopper).
+Write `.mugiwara/missions/<mission>/flows/05-healing.md`: fixed list (finding → commit → evidence), escalated list (finding → plan → owner), updated ledger. After healing: update the ledger — mark each healed row with evidence; keep unfixed rows for escalation. Then back to Flow 4 (Chopper) for re-audit.
 
 ## Red flags
 
@@ -71,7 +72,7 @@ Fixed list (finding → commit → evidence), escalated list (finding → plan
 - A fix shipped without a reproducing test (Prove-It skipped).
 - A test or config deleted or weakened to silence a failure.
 - A drive-by refactor riding along with a fix.
-- A code failure marked `env` to close the ledger.
+- A code failure marked `env` without clean-checkout proof.
 - A ledger row processed with no evidence recorded.
 - The same failure healing past 3 cycles without escalation.
 - Several failed fixes on one failure without taking the architecture question to Luffy.

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

@@ -22,6 +22,10 @@ Every flow stage returns to Luffy — no crew member hands off directly to anoth
 - Franky → return gates → Luffy routes pass/fail
 - Robin/Jinbe → return findings → Luffy routes to Brook/Zoro/defer
 
+**Control commands (pre-flow):** `mugiwara continue`/`status` are read-only,
+pre-flow — never create config, never start a flow stage; exit 2 = user selects.
+Full: `references/control-commands.md`.
+
 ## Coordination files
 
 Team repos — per-(mission, member) isolation, no collisions: `_shared/references/multi-actor.md`.
@@ -45,7 +49,7 @@ Classify every incoming request. 5-way table (Trivial/Explicit/Exploratory/Open-
 
 ## Lane routing + precedence (Flow 0, size before process)
 
-Alongside the class, size the mission and pick a lane (0 Direct / 1 Lean / 2 Standard / 3 Full / 4 Spike). **Precedence: class decides whether there is work; lane decides how much process — class first, lane second, record both.** A pasted Explicit spec still sizes the lane from its file list before Flow 2 (40-file spec → Lane 3). Escalation only: a lane may rise mid-mission, never drop. Full table: `references/triage-escalation.md`. Small tasks: read-only investigation → host `explore` agent or inline read — NOT a Luffy subagent (~5k inline vs ~132k measured per dispatch); explicit implement → Lane 1 Zoro inline. Review only when risky — full pipeline.
+Alongside the class, size the mission and pick a lane (0 Direct / 1 Lean / 2 Standard / 3 Full / 4 Spike). **Precedence: class decides whether there is work; lane decides how much process — class first, lane second, record both.** Record the initial execution posture + rationale (default `inline-sequential`) per `_shared/references/posture-routing.md`. A pasted Explicit spec still sizes the lane from its file list before Flow 2 (40-file spec → Lane 3). Escalation only: a lane may rise mid-mission, never drop. Full table: `references/triage-escalation.md`. Small tasks: read-only investigation → host `explore` agent or inline read — NOT a Luffy subagent (~5k inline vs ~132k measured per dispatch); explicit implement → Lane 1 Zoro inline. Review only when risky — full pipeline.
 
 ## Spec bridge (Flow 0 → Flow 2)
 
@@ -91,17 +95,13 @@ Rendered examples: `references/output-contract.md` — match the shape.
 
 When a flow stage has many independent tasks, instruct Zoro to parallelize — one task per WORKER subagent — and may split the mission into parallel tracks. Only `[PARALLEL]` sets are dispatched; sequential work stays inline. Never run more parallelism than the plan proves safe (check the dependency graph, no shared files). A `[PARALLEL]` task set with a hidden dependency edge is a red flag.
 
-## Q&A hub
-
-Any agent routes a question to Luffy (via the main thread). Answer with: decision + reason + impact on the plan. Log every decision to `.mugiwara/missions/<mission>/decisions.md`; do NOT touch the plan doc.
-
 ## Override (in-session)
 
 Recognize the in-session phrase `mugiwara mode <guided|semi|auto>`: write the project `.mugiwara/config`, append a decision-log row (level, requester, timestamp), and apply from the next flow stage. No CLI flag. The mode is read once per flow stage — a flip never applies mid-flow-stage.
 
 ## Closure (Flow 9)
 
-Gate — every task's acceptance criteria verified, every gate passed, findings resolved or deferred with an owner, blocker ledger reviewed. Write the closure summary to `.mugiwara/missions/<mission>/report.md` (seeded from `flows/06-closure.md`); report and summary prose follow `_shared/references/prose-style.md`. Run `mugiwara savepoint <mission>` for final state, then `mugiwara archive <mission>` — waves, review, security, blockers, decisions fold into report.md; plan.md stays. The mission dir ends as two files: plan.md + report.md. Full detail: `references/closure.md`. With `auto_commit=off` (guided/semi): skip the save-point commit and push — hand the uncommitted tree + verdict to the user; auto always pushes.
+Gate — every task's acceptance criteria verified, every gate passed, findings resolved or deferred with an owner, blocker ledger reviewed. Write the closure summary to `.mugiwara/missions/<mission>/report.md` (seeded from `flows/06-closure.md`); report and summary prose follow `_shared/references/prose-style.md`. Run `mugiwara savepoint <mission>` for final state, then `mugiwara archive <mission>` — waves, review, security, blockers, decisions fold into report.md; plan.md stays; the PR material (`flows/07-pr-verdict.md`) survives as `pr-verdict.md` at the mission root. The mission dir ends as plan.md + report.md + pr-verdict.md. Full detail: `references/closure.md`. With `auto_commit=off` (guided/semi): skip the save-point commit and push — hand the uncommitted tree + verdict to the user; auto always pushes.
 
 ## Spirit vs letter
 

package/content/skills/mugiwara-orchestration/references/control-commands.md

@@ -0,0 +1,14 @@
+# Control Commands (pre-flow)
+
+`mugiwara continue` / `mugiwara status` are read-only control commands, not flow
+work. They:
+
+- Dispatch before Flow 0 and crew dispatch — the CLI is the deterministic half
+  of resume (directory scan + solo-vs-team rule), no reasoning turn needed.
+- Never create `.mugiwara/config` and never print setup chatter — a fresh
+  project stays clean.
+- Never start a flow stage.
+
+Exit codes: 0 = a single resume point printed; 2 = ambiguous/absent — stop and
+let the user select. Only after the CLI resolves the resume point does Flow 0
+re-entry (or plan verification) begin.

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

@@ -1,16 +1,17 @@
 ---
 name: mugiwara-planning
 description: Use for turning an approved spec into an implementation plan — interview-first, full context scan, scaled Quick/Standard/Full plans, parallel-proof waves.
+gate_artifact: plan.md Waves/Task index — planning evidence
 ---
 
-# Planning (Nami)
+# Planning
 
 ## Skip when
 
 - Lane 0 direct work: no plan needed for a typo or single-file fix.
 - A plan already exists and is approved — execute, don't re-plan.
 
-Classify the mission by size first — after Luffy's route — then write the plan at the matching level. Quality bar: a zero-context senior engineer executes every task without asking one question.
+Classify the mission by size first — after the route decision — then write the plan at the matching level. Quality bar: a zero-context senior engineer executes every task without asking one question. Rule: never plan above or below the measured size (file count + days from the spec) — a 40-file spec is never Quick.
 
 ## Classify mission size
 
@@ -27,17 +28,23 @@ Batch blocking ambiguities into ONE question round; never assume silently. Mode
 
 ## Full context scan
 
-Scan the whole codebase the mission touches before writing: structure, entry points, existing patterns, tests, tooling. If the mission needs it, scan everything — a plan written without the real code is fiction. Ground every file path and step in what exists; confirm tooling, do not assume. Trust-sort sources (high/medium/low): `references/plan-template.md`.
-
-**User AC mapping (per `mugiwara-testcases`).** In the context scan, read the declared test source (none = no user tests) and map each user AC to ≥1 per-task criterion: executable user test → the project test command scoped to that file; declarative AC → "translate to a project test file + run" or a literal command check. Cross-cutting user ACs (an e2e flow spanning tasks) become plan-level criteria re-run at the checkpoint against the whole diff; never invent an integration test as a criterion — user tests are the only integration-class criteria.
+Scan the whole codebase the mission touches before writing: structure, entry points, existing patterns, tests, tooling. Ground every file path in what exists; confirm tooling, do not assume. Trust-sort sources: `references/plan-template.md`. Rule: every file path must be verified — unverified path fails.
 
 ## Zero-question standard
 
-A senior principal's plan leaves nothing to the executor's judgment. Every task specifies: exact file paths (never "the component"), the exact commands to run (TDD steps with the test command), an acceptance criterion that is a literal command or file check ("works correctly" is banned), and the dependency edge. If you cannot write it that specifically, scan again before the task goes in.
+A senior principal's plan leaves nothing to the executor's judgment. Every task specifies: exact file paths (never "the component"), the exact commands to run (TDD steps with the test command), an acceptance criterion that is a literal command or file check ("works correctly" is banned), and the dependency edge. If you cannot write it that specifically, scan again before the task goes in. Rule: a stranger must read each task once and run the acceptance verbatim.
+
+## CODEOWNERS per area
+
+Map every task to a codebase area before parallelizing. Each area (e.g. `src/auth/`, `api/`, `docs/`) lists the task(s) that own it; two tasks in the SAME area are never `[PARALLEL]`, disjoint areas are the only parallel proof. Route review per area from the same table. Rule: every task in the task index appears in exactly one area row of its wave — an unowned file is a planning defect.
+
+| Area | Owner task(s) |
+|------|---------------|
+| <path prefix> | T1, T2 |
 
 ## Plan tables (wave + task index)
 
-Before the detail blocks, add two markdown tables so Zoro can read the shape at a glance and parallelize safely:
+Before the detail blocks, add two markdown tables so the executor can read the shape at a glance and parallelize safely:
 
 | Wave | Focus | Tasks | Gate |
 |------|-------|-------|------|
@@ -60,10 +67,13 @@ Before the detail blocks, add two markdown tables so Zoro can read the shape at
 - Risk: none | <rollback plan>
 ```
 
-**Task size = commit granularity.** Zoro commits per LOGICAL task, not per micro-step. Size tasks as meaningful units of work (a feature, a fix, a refactor), not keystrokes — a "fix typo" or "rename variable" task should be folded into its neighboring logical task, never standalone. If the plan is full of XS tasks, merge them up before writing: a plan sliced into a dozen one-line commits is a plan that will litter the history. Few, well-sized tasks → few, meaningful commits.
+**Task size = commit granularity.** The executor commits per LOGICAL task, not per micro-step. Size tasks as meaningful units of work (a feature, a fix, a refactor), not keystrokes — a "fix typo" or "rename variable" task folds into its neighboring logical task, never standalone. A plan full of XS tasks is a history-littering plan; merge them up before writing. Rule: one task = one commit, no exceptions.
 
 ## Waves
-Group tasks into waves; each wave ends in a verified, reviewable state. `[PARALLEL]` ONLY when tasks share no file AND no interface dependency (state the proof); otherwise `[SEQUENTIAL, depends-on: Task M (file: <path>)].` Never mark parallel on assumption. Per-wave gate: acceptance checks run with evidence; a wave starts only when its dependencies are proven done.
+
+Group tasks into waves; each wave ends in a verified, reviewable state. `[PARALLEL]` ONLY when tasks share no file AND no interface dependency AND no shared CODEOWNERS area (state the proof); otherwise `[SEQUENTIAL, depends-on: Task M (file: <path>)].` Never mark parallel on assumption. Per-wave gate: acceptance checks run with evidence; a wave starts only when its dependencies are proven done.
+
+**Rollback per wave.** Every wave names its rollback point — a tag at the last proven-good commit — in the wave table. Rule: wave N starts only when wave N-1's rollback point is recorded; a failed wave gate means revert (`git revert <wave-N-tag>`), fix, re-run the gate. A wave with no named rollback point is a planning defect.
 
 ## Implementation graph
 
@@ -88,20 +98,22 @@ Any anti-pattern fails the quality bar — fix the plan before handoff. Never sh
 
 ## Full-level skeleton
 
-Full plan at `.mugiwara/missions/<mission>/plan.md`: `# <mission>`, `## Key decisions`, `## Architecture overview`, `## Project structure`, `## Waves`, `## Implementation graph`, `## Task index`, `## Detail tasks`, `## Risk & rollback`, `## Mission split`. Route reasons, check-ins, closure go to `logs/`/`results/`.
+Full plan at `.mugiwara/missions/<mission>/plan.md`: `# <mission>`, `## Key decisions`, `## Architecture overview`, `## Project structure`, `## Waves`, `## CODEOWNERS`, `## Implementation graph`, `## Task index`, `## Detail tasks`, `## Risk & rollback`, `## Mission split`. Route reasons, check-ins, closure go to `logs/`/`results/`.
 
 ## Mission split (very large) — Lane 3
 
-Very-large missions (>2 days, multi-PR) split into sub-missions, never one giant plan. Each sub-mission: own PR, done-criteria, continuation pointer, and its own wave table; every sub-mission ends mergeable. Continuation flows through `.mugiwara/missions/<mission>/continue.json | continue-<member>.json` — next sub-mission resumes from the pointer, never restarts. Nami writes the split before any task detail.
+Very-large missions (>2 days, multi-PR) split into sub-missions, never one giant plan. Each sub-mission: own PR, done-criteria, continuation pointer, and its own wave table; every sub-mission ends mergeable. Continuation flows through `.mugiwara/missions/<mission>/continue.json | continue-<member>.json` — next sub-mission resumes from the pointer, never restarts. The planner writes the split before any task detail.
 
+## Large campaign — sub-plan
+Full checklist: `references/large-campaign-subplan.md` — 6 items; trigger `>3 phases` or `>1500 lines`, `sub-plan/NN-phaseNN-<slug>.md`, master index pattern.
 ## Handoff
 
-STOP after writing. The plan is written to `.mugiwara/missions/<mission>/plan.md` and it is clean — no agent names, no coordination log, no closure (that lives in `logs/` and `results/`). **Return to Luffy.** Present a 2-3 line summary (waves, task count, key risks) and hand off to Luffy for the GO decision. Luffy decides: approve → Zoro, revise → back to you, or escalate.
+STOP after writing. The plan is written to `.mugiwara/missions/<mission>/plan.md` and it is clean — no agent names, no coordination log, no closure (that lives in `logs/` and `results/`). **Return to the orchestrator.** Present a 2-3 line summary (waves, task count, key risks) and hand off for the GO decision. The orchestrator decides: approve → executor, revise → back to you, or escalate.
 
-Never hand to Zoro without Luffy's GO. In `guided` mode, Luffy asks the user before delegating to Zoro. In `semi`/`auto`, Luffy may auto-go unless the task carries high risk (deploy, migration, DB, public API). You do not decide — you present, Luffy routes.
+Never hand to the executor without a GO. In `guided` mode, the orchestrator asks the user before delegating. In `semi`/`auto`, the orchestrator may auto-go unless the task carries high risk (deploy, migration, DB, public API). You do not decide — you present, the orchestrator routes.
 
 ## Red flags
 - Shipping a plan with a known anti-pattern (TBD, "works correctly", assumed tooling).
 - Marking [PARALLEL] without file- AND interface-disjoint proof.
 - Missing file-level dependency edges or a Break point on an 8+ file task.
-- Handing the plan to Zoro without Luffy's GO.
+- Handing the plan to the executor without a GO.

package/content/skills/mugiwara-planning/references/large-campaign-subplan.md

@@ -0,0 +1,41 @@
+# Large Campaign — Sub-Plan Governance (Planning)
+
+Trigger: `phase count >3` or `plan.md >1500 lines` (`wc -l`). When triggered, Nami auto-splits.
+
+## Naming
+
+- `sub-plan/NN-phaseNN-<slug>.md` (zero-padded, slug from `Phase N: Title` lowercased, `[^a-z0-9]+` → `-`)
+- Master `plan.md` holds Mission split table (index) + DoD + how-to-start; detail lives in `sub-plan/`
+- Example: `sub-plan/01-phase01-cost-governor-foundation.md`
+
+## Master index
+
+Master `plan.md` never exceeds 1500 lines — detail lives in sub-plan slices.
+
+## Phase isolation vs true sub-mission
+
+Two distinct decisions — do not conflate:
+
+- **Phase isolation** (sub-plan) = ONE mission, one plan. `sub-plan/NN-phaseNN-*.md`
+  slices detail; `flows/phase-NN/` owns evidence; archive folds the
+  trail. Phase-local posture lives in the slice.
+- **True sub-mission** = a SEPARATE, independently mergeable unit: own branch,
+  done-criteria, continuation pointer, and mergeable end state. Only Nami
+  creates it explicitly.
+
+## Dependency / write conflicts
+
+Each slice's task index makes write-conflict groups explicit: tasks that write
+the same file/area are never parallel. `[PARALLEL]` requires file- AND
+interface-disjoint proof (shared CODEOWNERS area is a conflict). Speculative
+parallelization is prohibited — every parallel set traces to an evidence-backed
+dependency map.
+
+## Skill body rule
+
+If body would exceed 120 lines, move checklist here; SKILL.md keeps one-line pointer.
+
+## Acceptance
+
+- `grep -c "sub-plan" content/skills/mugiwara-planning/SKILL.md` ≥1
+- `validate-content --check-manifest --check-docs` 0

package/content/skills/mugiwara-planning/references/plan-template.md

@@ -46,6 +46,28 @@ Multi-PR scope (>2 days). Split into sub-missions — never one giant plan:
 - Continuation via `.mugiwara/missions/<mission>/continue.json | continue-<member>.json` — next sub-mission resumes from the pointer, never restarts.
 - Each sub-mission needs its own wave table.
 
+## Execution posture (Standard+, proportional smaller on Quick/Lane 0-1)
+
+Expose the adaptive contract before execution without turning plan.md into a
+decision log:
+
+```markdown
+## Execution posture
+Control mode: semi
+Initial model: inline-sequential
+Re-evaluate at: before Flow 3; after each execution batch; Flow 4/6/7
+
+## Dependency and ownership map
+| Task | Depends on | Writes | Member | Parallel eligible | Evidence |
+
+## Cost-aware operating assumptions
+| Decision | Governor evidence | Constraint | Fallback |
+```
+
+Large campaigns index these sections in the master plan; each `sub-plan/` slice
+owns its local detail. Parallel eligibility requires file- AND interface-disjoint
+proof.
+
 ## Interview-first & mode (prose detail)
 
 Batch ALL blocking ambiguities into ONE question round before writing. If a