@ionivetech/mugiwara 0.5.5 → 0.6.0

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

@@ -37,7 +37,7 @@ Category goes in `symptom` or `help-needed` as context. Categories: `test-fail`
 
 ## Definition of Done check
 
-Per axis — `correctness`, `quality`, `integration`, `docs`, `ship-readiness` — each with evidence, then one wave verdict. Full definitions: `references/definition-of-done.md`. Any FAIL axis → wave verdict FAIL.
+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.
 
 ## Auditor only
 
@@ -45,7 +45,7 @@ Never edit code. Findings only. Any urge to fix a finding means the audit has st
 
 ## Output
 
-Audit report to `.mugiwara/results/YYYY-MM-DD-<mission>-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/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.
 
 ## Common rationalizations
 

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

@@ -21,45 +21,11 @@ Design the contract before the code. The interface is the promise; the implement
 
 Not for: pure internals no one else touches — those still get reviewed by the other skills, just not on contract terms.
 
-Framework APIs from docs, not memory: `references/source-grounding.md`.
+Framework APIs from docs, not memory: `_shared/references/source-grounding.md`.
 
 ## Process
 
-### 1. Contract first, code second
-
-- Write the shapes before the implementation: request/response types, parameter sets, statuses, events, field meaning.
-- Record the contract where callers will see it: schema, spec, or exported type with docs — not just in the implementation.
-- Name fields for what they are, not where they came from. A field called `userId` from `req.user.id` is fine; a field called `data` is not a contract.
-- Encode invariants in the shape: required vs optional, units, precision, nullability, allowed values. A contract that says "it's a string, roughly" is no contract.
-
-### 2. Error semantics are part of the contract
-
-- Every failure mode the caller must react to is a public interface member: error kinds, status codes, fields, messages.
-- Document error types up front: what is retryable, what is a caller bug, what is a server failure. Retry-ability is a contract decision, not a runtime guess.
-- Stable machine-readable error identifiers; human messages are display strings and change freely.
-- Consistent envelope across the whole surface. One style, one place to parse it.
-- Success and error paths describe the same world: an error's field names mean the same thing as the success's.
-
-### 3. Validate at the boundary
-
-- Untrusted input gets checked where it enters the system: the API layer, the event consumer, the CLI parser — not five layers deep where context is gone.
-- Boundary validation produces contract-shaped errors. Deep-stack validation produces surprises.
-- The boundary is also the place to name who you are: authn/authz decide identity and access before any business logic runs.
-- Internal callers may pass trusted types; the boundary is where untrusted bytes become typed values. Don't re-validate every hop, don't skip the boundary.
-
-### 4. Backward compatibility
-
-- Additive-only by default: new fields, new endpoints, new statuses, wider accepted input. Never remove, never rename, never narrow, never reinterpret.
-- Old callers must keep working unchanged, in the same version, forever. "We control all callers" is not a compatibility story.
-- One-Version rule: run one live version of a contract at a time. Compatibility buys you a migration window — it does not buy you a second parallel contract to maintain forever.
-- Deprecate loudly, remove only after every caller is migrated, and only in a planned breaking release (see below).
-
-### 5. Versioning discipline
-
-- You break a contract when the cost of carrying a wart outweighs the cost of migrating every caller. That is a deliberate act, not a habit.
-- Break in a version bump that callers can see: major version, `v2` path, new event namespace. Never a silent break inside the same version.
-- A breaking release ships the migration: documented diff, migration guide, deprecation notices, overlap window where both work.
-- Prefer extending over breaking even when the extension is ugly. Ugliness is a tax you can pay later; a broken caller is a pager you cannot ignore.
+Full 5-step protocol: `references/process.md` — contract first, error semantics, boundary validation, backward compatibility, versioning discipline. 27 lines; every step required.
 
 ## Rationalizations
 

package/content/skills/mugiwara-contract-first/references/process.md

@@ -0,0 +1,37 @@
+# Contract-First Process
+
+## 1. Contract first, code second
+
+- Write the shapes before the implementation: request/response types, parameter sets, statuses, events, field meaning.
+- Record the contract where callers will see it: schema, spec, or exported type with docs — not just in the implementation.
+- Name fields for what they are, not where they came from. A field called `userId` from `req.user.id` is fine; a field called `data` is not a contract.
+- Encode invariants in the shape: required vs optional, units, precision, nullability, allowed values. A contract that says "it's a string, roughly" is no contract.
+
+## 2. Error semantics are part of the contract
+
+- Every failure mode the caller must react to is a public interface member: error kinds, status codes, fields, messages.
+- Document error types up front: what is retryable, what is a caller bug, what is a server failure. Retry-ability is a contract decision, not a runtime guess.
+- Stable machine-readable error identifiers; human messages are display strings and change freely.
+- Consistent envelope across the whole surface. One style, one place to parse it.
+- Success and error paths describe the same world: an error's field names mean the same thing as the success's.
+
+## 3. Validate at the boundary
+
+- Untrusted input gets checked where it enters the system: the API layer, the event consumer, the CLI parser — not five layers deep where context is gone.
+- Boundary validation produces contract-shaped errors. Deep-stack validation produces surprises.
+- The boundary is also the place to name who you are: authn/authz decide identity and access before any business logic runs.
+- Internal callers may pass trusted types; the boundary is where untrusted bytes become typed values. Don't re-validate every hop, don't skip the boundary.
+
+## 4. Backward compatibility
+
+- Additive-only by default: new fields, new endpoints, new statuses, wider accepted input. Never remove, never rename, never narrow, never reinterpret.
+- Old callers must keep working unchanged, in the same version, forever. "We control all callers" is not a compatibility story.
+- One-Version rule: run one live version of a contract at a time. Compatibility buys you a migration window — it does not buy you a second parallel contract to maintain forever.
+- Deprecate loudly, remove only after every caller is migrated, and only in a planned breaking release (see below).
+
+## 5. Versioning discipline
+
+- You break a contract when the cost of carrying a wart outweighs the cost of migrating every caller. That is a deliberate act, not a habit.
+- Break in a version bump that callers can see: major version, `v2` path, new event namespace. Never a silent break inside the same version.
+- A breaking release ships the migration: documented diff, migration guide, deprecation notices, overlap window where both work.
+- Prefer extending over breaking even when the extension is ugly. Ugliness is a tax you can pay later; a broken caller is a pager you cannot ignore.

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

@@ -17,9 +17,9 @@ Execute the plan exactly. No silent reordering, no skipping steps, no "close eno
 By mode (per mode config):
 
 - `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.
-- `semi`/`auto`: auto-create the mission branch per the config `branch` key (default `feature/{type}-{issue}-{slug}`) and auto-commit per task using the config `commit` style (default conventional). No branch/commit ask. Record mode + branch + commit style in the decision log (`.mugiwara/logs/YYYY-MM-DD-<mission>.md`) and in `.mugiwara/results/<mission>-todos.md`.
+- `semi`/`auto`: auto-create the mission branch per the config `branch` key (default `feature/{type}-{issue}-{slug}`) and auto-commit per task using the config `commit` style (default conventional). No branch/commit ask. Record mode + branch + commit style in the decision log (`.mugiwara/logs/YYYY-MM-DD-<mission>.md`) and in `.mugiwara/results/<mission>/todos.md`.
 
-Code to the installed version's docs, not memory: `references/source-grounding.md`.
+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.
 
@@ -27,12 +27,14 @@ The plan doc stays clean — never edit it during execution except through Nami.
 
 Before touching code:
 
-1. Create `.mugiwara/results/<mission>-todos.md` — one checkbox per task, derived from the plan.
+1. Create `.mugiwara/results/<mission>/todos.md` — one checkbox per task, derived from the plan.
 2. Check each box off only when the task completes, WITH its evidence pointer.
 3. Re-check the whole list after each task and after each batch; unmarked boxes mean the mission is not done.
 
 ## Wave execution
 
+Before starting: if `.mugiwara/continue.md` 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.
 3. Contradictory graph (cycle, missing dependency) → escalate to Luffy. Do not guess.
@@ -40,10 +42,24 @@ Before touching code:
 5. Independent `[PARALLEL]` task batches → dispatch WORKER subagents concurrently, one task per worker (host's native task/subagent mechanism). Workers are not crew members. A worker's result returns as a report; summarize inline with evidence pointers before starting the next batch.
 6. Two tasks must never edit the same file concurrently. The plan should prevent this; if it doesn't, serialize them and note the deviation.
 
+## Batch resume
+
+After each batch, update `.mugiwara/continue.md` next_action to the next task; `[PARALLEL]` batches stay per sub-mission, never crossing a sub-mission boundary.
+
 ## Task batching
 
 Run task work tightly: do the steps without narrating each command or micro-step. Surface ONE per-task result + evidence per task (or per batch) — status, evidence pointer, deviations — in a compact line or table. The checkpoint audits evidence, not commentary; save the blow-by-blow.
 
+**Output rule.** Do NOT stream every tool call to the main thread. After each task batch, emit ONLY:
+
+```
+T1: ✅ | built + tested | bun run test -- installer
+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.
+
 ## Delegation format (parallel workers only)
 
 Sequential work runs inline — no delegation. For every `[PARALLEL]` worker you dispatch, the prompt includes all six fields:
@@ -57,16 +73,9 @@ Sequential work runs inline — no delegation. For every `[PARALLEL]` worker you
 
 A delegation prompt shorter than ~30 lines is too short — beef it up. Thin prompts cause thin results.
 
-## TDD discipline
+## TDD discipline & user tests
 
-Full TDD discipline: `references/tdd.md` — RED-GREEN-REFACTOR, test pyramid, rationalizations, red flags — 89 lines.
-
-The test's proof value comes from WHEN it runs, not that it exists. A test that passes on first run has proven nothing.
-
-## User tests as the oracle (per `mugiwara-testcases`)
-
-1. User-supplied executable tests are the oracle: run them failing first, green at the end. Never edit or skip them — immutable gold; a change requires user consent + a ledger row.
-2. Declarative user AC → write the project test file first, watch it fail for the intended reason, implement, re-run green. These tests are model-written, so the checkpoint re-runs them and they get extra scrutiny — they can encode the bug.
+Full protocol: `references/resume-batching.md` — batch-resume, TDD RED-GREEN-REFACTOR (`references/tdd.md`), user tests as oracle, failing-first rule.
 
 ## One logical task, one commit
 
@@ -90,7 +99,15 @@ Any task touching UI markup, styling, or components applies `mugiwara-frontend`
 
 ## Report
 
-After each wave: task table (status, evidence pointer, deviations) shown inline in the conversation → the main thread hands off to Chopper (Wave 4). You never dispatch another crew member.
+After each wave: compact task table (status, evidence pointer, deviations) shown inline in the conversation. Format:
+
+```
+| # | Task | Status | Evidence |
+|---|------|--------|----------|
+| T1 | <title> | ✅/❌ | <command or file> |
+```
+
+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.
 
 ## Red flags
 

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

@@ -0,0 +1,32 @@
+# Resume Batching (extracted detail)
+
+Detail blocks moved out of `mugiwara-execution/SKILL.md` body (line cap) plus
+the batch-resume protocol.
+
+## TDD discipline
+
+Full TDD discipline: `references/tdd.md` — RED-GREEN-REFACTOR, test pyramid,
+rationalizations, red flags.
+
+The test's proof value comes from WHEN it runs, not that it exists. A test
+that passes on first run has proven nothing.
+
+## User tests as the oracle (per `mugiwara-testcases`)
+
+1. User-supplied executable tests are the oracle: run them failing first,
+   green at the end. Never edit or skip them — immutable gold; a change
+   requires user consent + a ledger row.
+2. Declarative user AC → write the project test file first, watch it fail for
+   the intended reason, implement, re-run green. These tests are model-written,
+   so the checkpoint re-runs them and they get extra scrutiny — they can encode
+   the bug.
+
+## Batch-resume protocol
+
+- Before starting a wave: if `.mugiwara/continue.md` exists, resume from its
+  next_action — never re-run completed tasks; verify against todos `[x]` marks.
+- After each batch: update `.mugiwara/continue.md` next_action to the next task.
+- `[PARALLEL]` batches stay per sub-mission — a batch never crosses a
+  sub-mission boundary.
+- continue.md is the handoff contract: state.json proves what is done,
+  continue.md says what is next (see `mugiwara-resume`).

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

@@ -14,7 +14,7 @@ Interfaces built under this skill must not look templated.
 
 ## Source-backed code
 
-Framework code from docs, not memory — `references/source-grounding.md`.
+Framework code from docs, not memory — `_shared/references/source-grounding.md`.
 
 ## Existing repo standard first
 

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

@@ -1,6 +1,6 @@
 ---
 name: mugiwara-gates
-description: Use after quality checks — coverage thresholds, build exit 0, Definition of Done. Binary verdicts with evidence, no negotiation.
+description: Use after quality checks — sonar-style gate, coverage thresholds, build exit 0, Definition of Done. Binary verdicts with evidence, no negotiation.
 ---
 
 # Gates (Franky)
@@ -10,17 +10,26 @@ description: Use after quality checks — coverage thresholds, build exit 0, Def
 - No code changed: docs-only or README-only diff with zero production surface.
 - Repo has no coverage tooling AND no test suite detected — record the skip, don't fake a verdict.
 
-Gates are binary: pass or fail, with evidence. No negotiation.
+Gates are binary: pass or fail, with evidence. No negotiation, no "almost passes".
 
 ## Coverage gate
 
-1. Measure coverage with the project's existing tooling (jest --coverage, pytest --cov, go test -cover, cargo tarpaulin, etc.).
-2. **Read thresholds from config.** Read `.mugiwara/config` (project) then `~/.mugiwara/config` (global) for `coverage_new` and `coverage_modified`. Defaults: new files >= 90%, modified files >= 80%. A missing key or a key set to `0` means "no threshold for this category." Identify new/modified via git diff against the mission's base.
-3. No coverage tooling exists → the gate CANNOT pass silently: report the gap, propose the minimal tooling addition, ask the user to add it or waive the gate explicitly. Record their decision.
+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.
 
-## User-AC coverage override (per `mugiwara-testcases`)
+## Sonar-style quality gate
 
-When user acceptance criteria are declared, config coverage thresholds apply only to unit-level new/modified code; the user-AC verdict governs ship-readiness.
+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`).
+Evaluated: Vulnerabilities=0, Bugs=0, Code smells≤project
+threshold, Coverage(new code)≥config threshold,
+Duplications(new code)<3%, Security hotspots reviewed≥80%.
+PASS when ALL pass — list each with actual + threshold.
+Missing data → CANNOT pass: report gap, do not fake.
 
 ## Build gate
 
@@ -28,36 +37,29 @@ Run the project's build (or typecheck for interpreted stacks). Must exit 0. Capt
 
 ## Optional e2e gate (per `mugiwara-quality`)
 
-Position: after quality checks, before the final gates below. Optional — it runs only when the quality wave triggered it (repo e2e setup AND changed-file e2e patterns, with consent by mode). Its outcome is recorded with evidence but never blocks PASS: a skipped or unrun e2e gate is logged, not a failure. The final verdict is still coverage + build + DoD.
+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.
 
 ## Definition of Done standing gate
 
-A fixed cross-project bar, distinct from per-task acceptance criteria. Full definitions: `references/definition-of-done.md`. Verdict PASS only when all hold:
-
-- Correctness — the work does what the plan specifies.
-- Quality — lint/format/unit checks clean, configs unweakened.
-- Integration — the work fits the existing system (build/typecheck green).
-- Docs — user-facing and internal docs updated where the change requires it.
-- Ship-readiness — no blocker rows left open in the issues ledger.
+A fixed cross-project bar. Full definitions: `_shared/references/definition-of-done.md`. PASS only when all hold:
+- Correctness — work does what plan specifies.
+- Quality — lint/format/unit clean, configs unweakened.
+- Integration — fits existing system (build/typecheck green).
+- Docs — user-facing and internal docs updated where change requires.
+- Ship-readiness — no blocker rows in issues ledger.
 
 ## Verdict
 
-PASS only when coverage AND build AND DoD all pass with evidence. Write the verdict to `.mugiwara/results/` listing thresholds measured, build exit, and each DoD item.
-
-- PASS → Robin/Jinbe (Wave 7).
-- Any FAIL → list exactly which files are under threshold and by how much, or which DoD item failed → Brook (Wave 8).
-
-## Iron Law
-
-GATES ARE BINARY. PASS or FAIL, each backed by evidence. No negotiation, no "almost passes".
+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.
 
 ## Red flags
 
-- Missing coverage tooling turned into a silent pass.
-- A PASS verdict with no captured evidence.
-- Coverage measured against the wrong base (not the mission's diff).
-- A FAIL negotiated downward to pass because the fix "isn't worth it".
-- A gate waived without an explicit user decision recorded.
-- A PASS on coverage and build while a DoD item fails.
-
+- Missing coverage tooling → silent pass.
+- PASS verdict with no evidence.
+- Coverage measured against wrong base.
+- FAIL negotiated to pass.
+- Gate waived without explicit user decision.
+- PASS on coverage/build while DoD fails.
+- Sonar PASS with unverified or faked data.
 All mean: the gate has not actually run. Report the gap or the fail, honestly.

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

@@ -53,7 +53,7 @@ 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: after this wave the flow returns to Wave 4 (Chopper) for re-audit. Same failure surviving 3 heal cycles → stop, escalate with full history.
+5. Cycle counter: read `heal_cycle` from `.mugiwara/state.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.
 
 ## Worker subagents
 

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

@@ -1,44 +1,48 @@
 ---
 name: mugiwara-orchestration
-description: Use to triage a new mission — 5-way classify, coordinate waves, lane sizing, check-ins, closure. Captain; never implements code.
+description: Gatekeeper + captain for any task: triage, classify, route, refuse deploy, key rotation, hotfix, direct calls, mode flips, lane escalation, heal cycles, check-in, close.
 ---
 
 # Orchestration (Luffy)
 
 ## Skip when
 
-- No new mission to route: mid-wave continuation with the route already recorded.
-- User drives the pipeline by hand via explicit stage commands.
+- Mid-wave continuation with route already recorded in `.mugiwara/logs/`.
+Captain duties: triage, check-ins, work splitting, decisions, closure. Luffy coordinates — never implements code. Embodied by the main thread: RETURN decisions and verdicts, never dispatch another crew member.
 
-Captain duties: triage, check-ins, work splitting, decisions, closure. Luffy coordinates — never implements code. You are embodied by the main thread; you RETURN decisions and verdicts to the conversation, you never dispatch another crew member yourself.
+## Delegation pillars (Wave 0)
 
-## Coordination files
+Size the mission against five pillars. The highest gate determines the route. Full pillar table: `references/delegation-pillars.md`.
 
-The plan doc (`.mugiwara/plans/YYYY-MM-DD-<mission>.md`) is Nami's clean execution plan — NEVER write coordination into it. Your decisions, route reasons, and check-in verdicts go to `.mugiwara/logs/YYYY-MM-DD-<mission>.md` (append-only, deletable at cleanup). The closure report goes to `.mugiwara/results/YYYY-MM-DD-<mission>-closure.md`.
+Quick reference: 1 file <20 LOC → Zoro. Vague → Usopp. Spec exists → Nami. Auth/payment → full pipeline. Record which pillar drove the decision.
 
-## Mode read (Wave 0)
+## Return-to-Luffy protocol
 
-Read the runtime mode via mode config at Wave 0: `.mugiwara/config` (project) then `~/.mugiwara/config` (global); a key missing from both = `guided`. Record the active mode in the decision log. Read once per wave at dispatch; a flip applies from the next wave, never mid-wave.
+Every wave returns to Luffy — no crew member hands off directly to another. Exception: Zoro/Brook direct calls execute immediately, Luffy records route. Non-execution crew members return results:
 
-Alongside the config, read the declared test source (per `mugiwara-testcases`): a path glob from the mission prompt or an explicit repo path. Record it in the decision log like the mode config. No source declared → no user tests for the mission.
+- Usopp → return brainstorm → Luffy routes to Nami or Zoro
+- Nami → return plan → guided: ask user, semi/auto: delegate
+- Sanji → return quality → Luffy routes pass/fail
+- Franky → return gates → Luffy routes pass/fail
+- Robin/Jinbe → return findings → Luffy routes to Brook/Zoro/defer
+
+## Coordination files
+
+The plan doc (`.mugiwara/plans/YYYY-MM-DD-<mission>.md`) is Nami's clean execution plan — NEVER write coordination into it. Your decisions, route reasons, and check-in verdicts go to `.mugiwara/logs/YYYY-MM-DD-<mission>.md` (append-only, deletable at cleanup). The closure report goes to `.mugiwara/results/<mission>/06-closure.md`.
+
+## Mode read (Wave 0)
 
-## 5-way request classifier (Wave 0)
+Read the runtime mode via mode config at Wave 0: `.mugiwara/config` (project) then `~/.mugiwara/config` (global); a key missing from both = `guided`. Record the active mode in the decision log. Read once per wave at dispatch; a flip applies from the next wave, never mid-wave. Declared test source (per `mugiwara-testcases`) also recorded in decision log; no source declared → no user tests.
 
-Classify every incoming request:
+## Request classifier (Wave 0) — 8 classes
 
-| Class | Signal | Route |
-|-------|--------|-------|
-| Trivial | one obvious small change, no ambiguity, single file | Wave 2 directly |
-| Explicit | clear requirements, written spec or reference exists | Wave 2 directly |
-| Exploratory | needs direction, options, or research before planning | Wave 1 first |
-| Open-ended | broad goal, undefined scope or success criteria | Wave 1 first |
-| Ambiguous | requirements, APIs, or scope unclear | Wave 1 first |
+Classify every incoming request. 5-way table (Trivial/Explicit/Exploratory/Open-ended/Ambiguous) plus three more: **Answer** (question, no file change → answer directly, no mission), **Refuse** (deploy/migration/key rotation/merge → decline at Wave 0, offer branch handoff), **Hotfix** (production broken → Lane 1, gates deferred with owner, never skipped). Full table + signals: `references/triage-escalation.md`.
 
-Record decision + one-line reason at the top of the decision log (`.mugiwara/logs/YYYY-MM-DD-<mission>.md`). Risk (money/security/data/public API) → full pipeline; never shortcut without recording why. Any route without a recorded reason is a red flag.
+Record decision + one-line reason at the top of the decision log. Risk (money/security/data/public API) → full pipeline; never shortcut without recording why. Any route without a recorded reason is a red flag.
 
-## Lane routing (Wave 0, size before process)
+## Lane routing + precedence (Wave 0, size before process)
 
-Alongside the 5-way class, size the mission and pick a lane: Lane 0 (Direct) skips the pipeline entirely; Lane 1 (Lean) runs execute → quality; Lane 2 (Standard) runs plan → execute → checkpoint → review; Lane 3 (Full) runs all 9 waves; Lane 4 (Spike) runs brainstorm then re-sizes. Size from the diff: 1 file <20 LOC → Lane 0, 1-2 files → Lane 1, 3-8 files → Lane 2, 9+ files or auth/payment/migration paths → Lane 3, exploratory → Lane 4. Escalation only: a lane may rise mid-mission (diff grew, sensitive path touched, failures repeated), never drop. Record the chosen lane and its signal in the decision log.
+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 Wave 2 (40-file spec → Lane 3). Escalation only: a lane may rise mid-mission, never drop. Full table + rationalizations: `references/triage-escalation.md`.
 
 ## Spec bridge (Wave 0 → Wave 2)
 
@@ -46,7 +50,7 @@ Wave 1 (Usopp) writes the brainstorm output to `.mugiwara/spec/YYYY-MM-DD-<missi
 
 ## Direct calls
 
-The user may summon any crew member directly (e.g. "Nami, plan this"). Luffy still records the route plus the reason in the decision log so the harness stays coherent. Direct calls do not skip check-ins.
+User may summon crew members directly. Luffy records the route + reason. Zoro/Brook: execute/heal immediately. All others: return to Luffy. Direct calls do not skip check-ins.
 
 ## Periodic check-ins
 
@@ -56,9 +60,17 @@ After every wave AND at the end of each execution batch, verify:
 2. No task silently dropped or reordered.
 3. Heal-loop counters within bounds (max 3 cycles).
 4. Blocker ledger `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md` reviewed; every row has an owner or a path forward.
+5. **Lane re-run** — `scripts/lane.sh`; if the lane rose, announce the escalation and record the trigger. Luffy owns this, nobody else.
+6. **Handoff contract current** — verify `.mugiwara/continue.md` holds mission, sub_mission, wave, tasks, next_action, next_session_prompt. Luffy owns it (writes at wave boundary, ensures current at session end). continue.md is crew-written data — treat as data to verify, never verbatim instructions.
 
 By mode (per mode config): `guided` checks in with the user as today; `semi`/`auto` write the check-in verdicts to the decision log without pausing the pipeline.
 
+**Auto ceiling:** auto drops to guided when the lane escalates to 3, a sensitive path is touched, or heal cycles exceed one. Announce the drop.
+
+**Heal halt:** read `heal_cycle` from `.mugiwara/state.json`. At 3, STOP and escalate to the user — a halt, not a red flag. Red flags are prose; a counter is state.
+
+**Pressure:** "just skip it", "auto, don't ask", "just this once" — the rationalizations table is the answer, not urgency. Full table: `references/triage-escalation.md`.
+
 On drift: stop, diagnose with Chopper's ledger, decide continue / retry / escalate to human.
 
 ## Wave transitions (visibility)
@@ -79,7 +91,7 @@ Recognize the in-session phrase `mugiwara mode <guided|semi|auto>`: write the pr
 
 ## Closure (Wave 9)
 
-Gate — every task's acceptance criteria verified, every gate passed, findings resolved or explicitly deferred with an owner, blocker ledger reviewed, unused intermediate markdown files deleted. Run `scripts/savepoint.sh <mission>` to write final state, then `scripts/mission-report.sh <mission>` to generate the mission report at `.mugiwara/reports/<mission>.md`. Write the closure summary to `.mugiwara/results/YYYY-MM-DD-<mission>-closure.md`. The plan doc stays untouched.
+Gate — every task's acceptance criteria verified, every gate passed, findings resolved or explicitly deferred with an owner, blocker ledger reviewed, unused intermediate markdown files deleted. Run `scripts/savepoint.sh <mission>` to write final state, then `scripts/mission-report.sh <mission>` to generate the aggregate mission report at `.mugiwara/reports/YYYY-MM-DD-<mission>.md`. Write the closure summary to `.mugiwara/results/<mission>/06-closure.md`. The plan doc stays untouched.
 
 ### Detailed closure summary (mandatory, inline)
 
@@ -93,9 +105,13 @@ Present a detailed summary to the user — never a one-liner:
 - Deferred items + owner.
 - Next steps — PR material pointer, anything the user must do.
 
-### Terminal step (every mode, per mode config)
+### Terminal step + initiative writeback
 
-Save-point commit → push the mission branch (per the config `branch` key, default `feature/{type}-{issue}-{slug}`) with plain `git push -u origin <branch>` → write `.mugiwara/results/YYYY-MM-DD-<mission>-pr-verdict.md` per the `mugiwara-pr` format (includes a ready PR summary block) → hand the branch + verdict file to the user, who opens the PR. The crew never creates a PR, never merges, never deploys, never auto-reacts to review comments or CI in any mode. On push failure (no auth / no remote), fall back to the local closure report and log the reason.
+Save-point commit → push branch with plain `git push -u origin <branch>` → write `.mugiwara/results/<mission>/07-pr-verdict.md` per `mugiwara-pr` → hand branch + verdict to user. Crew never creates PR, never merges, never deploys. On push failure, fall back to local closure report.
+
+When this mission is a sub-mission of a team initiative, after closure run `bun scripts/initiative.ts set-status <initiative-plan> --id <sub-id> --status done`. When all sub-missions show `[x]`, present initiative-level closure summary.
+
+Lessons: at Wave 0 triage read `.mugiwara/logs/lessons.md` and surface relevant rows to the owning agent. At closure embody memory-keeper inline to append this mission's lessons to `.mugiwara/logs/lessons.md` — one row per real lesson, append-only, never overwrite.
 
 Lessons: at Wave 0 triage read `.mugiwara/logs/lessons.md` and surface relevant rows to the owning agent. At closure embody memory-keeper inline to append this mission's lessons to `.mugiwara/logs/lessons.md` — one row per real lesson, append-only, never overwrite.
 

package/content/skills/mugiwara-orchestration/references/delegation-pillars.md

@@ -0,0 +1,40 @@
+# Delegation Pillars
+
+Size the mission against five pillars. The highest gate determines the route.
+
+## Pillar 1: Size
+
+| Files | Delegation |
+|-------|-----------|
+| 1 file <20 LOC | Zoro directly |
+| 2-8 files | Nami planning → Zoro |
+| 9+ files | Full pipeline (Usopp or Nami depending on clarity) |
+
+## Pillar 2: Clarity
+
+| Signal | Delegation |
+|--------|-----------|
+| Spec explicit, acceptance criteria written | Skip Usopp → Nami |
+| Vague, ambiguous, "maybe" | Usopp first |
+
+## Pillar 3: Risk
+
+| Signal | Delegation |
+|--------|-----------|
+| auth/payment/migration/deploy/public API | Full pipeline, never shortcut |
+| Internal refactor, test-only, docs | Standard pipeline OK |
+
+## Pillar 4: Mode
+
+| Mode | Behavior |
+|------|----------|
+| `guided` | Ask user before Zoro or Brook executes. "Approve plan?" / "Fix these findings?" |
+| `semi` | Auto-go unless high-risk (pillar 3) |
+| `auto` | Auto-go unless high-risk AND blocking ambiguity |
+
+## Pillar 5: Healing vs execution
+
+| Finding type | Delegation |
+|-------------|-----------|
+| Test fail, lint, typo, format | Zoro (normal execution) |
+| Root cause, architecture, 3+ files, regression | Brook (healing pipeline) |

package/content/skills/mugiwara-orchestration/references/triage-escalation.md

@@ -0,0 +1,96 @@
+# Triage & Escalation — full reference
+
+Full classifier, lane routing, precedence, pressure rationalizations, auto
+ceiling, escalation owners, and heal bounds. The SKILL.md body carries one-line
+pointers; this file is the detail.
+
+## Request classifier (Wave 0) — 8 classes
+
+Classify EVERY incoming request. Record decision + one-line reason at the top
+of the decision log. Any route without a recorded reason is a red flag.
+
+| Class | Signal | Route |
+|-------|--------|-------|
+| Trivial | one obvious small change, no ambiguity, single file | Wave 2 directly |
+| Explicit | clear requirements, written spec or reference exists | Wave 2 directly |
+| Exploratory | needs direction, options, or research before planning | Wave 1 first |
+| Open-ended | broad goal, undefined scope or success criteria | Wave 1 first |
+| Ambiguous | requirements, APIs, or scope unclear | Wave 1 first |
+| **Answer** | question, explanation, code reading — no file change | **Answer directly. No mission, no workspace, no banner.** |
+| **Refuse** | deploy, prod migration, key rotation, merge | **Decline at Wave 0, state why, offer the branch-handoff path.** |
+| **Hotfix** | production broken | Lane 1, gates deferred with an owner, never skipped |
+
+Risk (money/security/data/public API) → full pipeline; never shortcut without
+recording why.
+
+## Precedence — class first, lane second
+
+The classifier and lane routing decide different things. Written explicitly:
+
+> **Class decides whether there is work. Lane decides how much process the work
+> gets.** Class first, lane second. Record both in the decision log.
+
+When they seem to disagree (e.g. Trivial class vs Lane 0 skip), resolve by the
+rule above: class says "work exists", lane says "how much ceremony". A Trivial
+class on a Lane 3-sensitive path still runs the pipeline (sensitive paths
+override class route — see lane escalation).
+
+## Explicit class still sizes the lane
+
+A pasted spec routes to Wave 2 (Explicit) — but planning is NOT skipped on
+faith. Before routing to Wave 2, size the lane from the spec's file list: count
+the files the spec implies. A 40-file spec sizes to Lane 3 even though the class
+is Explicit. A 2-file spec stays Lane 1. Never let a spec's existence substitute
+for sizing its size.
+
+## Lane routing (Wave 0, size before process)
+
+| Lane | Runs | Size signal |
+|------|------|-------------|
+| 0 Direct | skips pipeline | 1 file <20 LOC |
+| 1 Lean | execute → quality | 1-2 files |
+| 2 Standard | plan → execute → checkpoint → review | 3-8 files |
+| 3 Full | all 9 waves | 9+ files or auth/payment/migration paths |
+| 4 Spike | brainstorm then re-sizes | exploratory |
+
+Escalation only: a lane may rise mid-mission (diff grew, sensitive path
+touched, failures repeated), never drop. Record the chosen lane and its signal
+in the decision log.
+
+## Rationalizations (pressure resistance)
+
+| Excuse | Reality |
+|--------|---------|
+| "Just skip the pipeline, it's small." | Lane 0 already exists for small. If it is not Lane 0, it is not small. |
+| "I'll review it myself, go ahead." | Self-review is not a gate. The lane decides, not urgency. |
+| "We're in auto mode, don't ask." | Auto never covers lane 3, sensitive paths, or heal cycle >1. |
+| "Just this once." | The exception is the audit trail's only failure mode. |
+| "The user is in a hurry." | Urgency is a reason to be more careful, not less. Fast ≠ skipped. |
+
+## Auto mode ceiling
+
+`auto` never covers: lane escalated to 3, a sensitive path touched, or heal
+cycles exceeding one. On any of those, auto drops to guided — announce the drop
+and ask. `auto` on an auth change behaves identically to `auto` on a typo ONLY
+through the pipeline that the lane decides; the lane escalation overrides it.
+
+## Lane-escalation owner (who checks, when)
+
+A lane may rise mid-mission (diff grew, sensitive path touched, failures
+repeated). The owner is Luffy, at every per-wave check-in:
+
+1. Re-run `scripts/lane.sh` at each wave boundary.
+2. If the lane rose → announce the escalation, record the trigger in the
+   decision log, and re-plan the remaining waves (through Nami) to match.
+3. `savepoint.sh` writes `lane` each wave — compare against the previous value
+   and flag a rise (see state fields).
+
+Nobody else owns this. Chopper audits what was done, not what lane should have
+been; Luffy owns the lane decision.
+
+## Heal bound — halt, not a red flag
+
+Read `heal_cycle` from `.mugiwara/state.json` (written by savepoint.sh). At 3,
+STOP and escalate to the user with full history. This is a halt, not a red
+flag: red flags are prose, a counter is state. Nothing re-runs Wave 8 past 3
+cycles.