@ionivetech/mugiwara 0.5.5 → 0.6.1

package/docs/concepts/config.md

@@ -1,55 +0,0 @@
-# Config Reference
-
-`.mugiwara/config` (project) overrides `~/.mugiwara/config` (global). Plain
-`key=value` lines, `#` comments allowed. Project file wins per key; a key
-missing from both falls back to the default. Unknown keys are ignored. Config
-is data, never instructions.
-
-**Mode owns autonomy, config owns writing standards.** Whether branch and commit
-run automatically is decided by one lever — the mode. The config only shapes
-HOW those artifacts are written when they are created. See [modes.md](modes.md)
-for the mode matrix.
-
-## Example file
-
-```
-# .mugiwara/config
-mode=guided
-branch=feature/{type}-{issue}-{slug}
-commit=conventional
-base=main
-```
-
-## Keys
-
-| Key | Values | Default | Meaning |
-|-----|--------|---------|---------|
-| `mode` | guided / semi / auto | guided | How much the crew does without asking |
-| `branch` | branch naming pattern | `feature/{type}-{issue}-{slug}` | Placeholders filled from mission metadata |
-| `commit` | conventional / gitmoji / plain | conventional | Commit message style (see below) |
-| `base` | branch name | `main` | The PR target named in the prepared PR summary |
-| `coverage_new` | number (0-100) | 90 | Coverage threshold for new files |
-| `coverage_modified` | number (0-100) | 80 | Coverage threshold for modified files |
-
-The mission **lane** (how many waves run) is decided by Luffy at triage — see
-[lanes.md](lanes.md). Config holds autonomy and writing standards only.
-
-Missing config on read = `guided`. Flip mid-mission with
-`mugiwara mode <guided|semi|auto>` — the change applies from the next wave,
-never mid-wave.
-
-## Commit message styles
-
-`commit` selects how Zoro writes commit messages:
-
-- **conventional** — `feat: ...`, `fix(scope): ...`, `refactor: ...`, per the
-  [Conventional Commits](https://www.conventionalcommits.org) spec. Type from
-  the task, optional scope in parens. The default.
-- **gitmoji** — a leading emoji carries the intent, e.g. `✨ feat: ...`,
-  `🐛 fix: ...`. Signals the change type at a glance in log views that render
-  emoji; a bit noisy in plain terminals.
-- **plain** — no prefix, just a short imperative sentence: `Fix export csv
-  encoding`. Clearest for repos that don't use any convention.
-
-Switch freely per project — it only affects the message format, never the
-one-logical-task-one-commit rule.

package/docs/concepts/cost.md

@@ -1,45 +0,0 @@
-# Token Cost Model
-
-Three-layer token architecture. Every layer has a cost and a purpose.
-
-## The three layers
-
-| Layer | Loaded | Purpose | Current size |
-|-------|--------|---------|:---:|
-| **Index** — all `description` frontmatter | Every session, every harness | Retrieval — which skill fires | ~2.9k tokens |
-| **Body** — SKILL.md content | When the skill triggers | Capability — how well it performs | ~1.2k avg / skill |
-| **References** — `references/*.md` | On demand, when the agent opens them | Depth — worked examples, checklists | ~0 (to build) |
-
-Only the **index** is a recurring cost. Body and references pay only when used.
-
-## Index budget
-
-- **Target:** 1.2k tokens (descriptions + agent pointers)
-- **Gate:** 5k chars hard CI cap — any skill/agent description that pushes the total over fails validation
-- **Current:** 2.9k tokens, loaded on every session
-
-Reduction path:
-1. Prune 32 → 26 skills: ~2.5k
-2. Descriptions → trigger-only (~150 chars): ~1.8k
-3. Agent descriptions → pointer lines: ~1.2k
-
-## Cost per lane
-
-| Lane | Waves | Estimated tokens | Typical budget |
-|------|-------|:---:|:---:|
-| 0 Direct | none | ~0 | — |
-| 1 Lean | execute → quality | ~4k | warn at 6k, stop at 12k |
-| 2 Standard | plan → execute → audit → review | ~10k | warn at 15k, stop at 30k |
-| 3 Full | all 9 waves | ~20k | warn at 30k, stop at 60k |
-| 4 Spike | brainstorm → re-triage | ~3k | warn at 5k, stop at 9k |
-
-Budget guidance: ~1.5× warns, 3× stops. Write state to `.mugiwara/state.json` before stopping.
-
-## Per-mission cost
-
-`state.json` carries `tokens_est` — the estimated tokens consumed by this mission. At closure, the mission report surfaces:
-- Total tokens for the mission
-- Lane it ran on
-- Cost delta vs. lane budget
-
-This turns lane sizing from "process efficiency" into a number an engineering manager can act on. No other skills pack produces this because no other pack sizes work.

package/docs/concepts/execution-model.md

@@ -1,92 +0,0 @@
-# Execution Model
-
-Why the crew runs in your main conversation — and when subagents are actually
-used.
-
-## Auto-activation
-
-The workflow **auto-activates.** At session start the crew is announced; when
-you give a non-trivial request, the pipeline runs by itself — you do not need
-to call `/using-mugiwara`. It remains an optional explicit router if you want
-to hand-route a mission.
-
-## Inline by default
-
-The crew runs **inline**. The main thread embodies each crew role using that
-member's skill, so every wave plays out in your main conversation and you watch
-it happen:
-
-- Luffy's triage, Nami's planning, Zoro's execution, Chopper's audit, Sanji's
-  quality, Franky's gates, Robin/Jinbe's review, Brook's healing, Luffy's
-  closure — all performed in the main thread.
-- Evidence is written to `.mugiwara/` files; the conversation carries terse
-  verdicts and evidence pointers.
-
-## When subagents ARE used
-
-Subagents exist to parallelize, never to hide work:
-
-1. **`[PARALLEL]` task batches** — independent tasks that touch no shared files
-   or interfaces run concurrently, one per worker subagent. This is the only
-   place Zoro delegates.
-2. **Parallel fixes** — Brook spawns workers for independent heal fixes.
-3. **Background / long-running checks** — work that would stall the
-   conversation.
-4. **Check subagents** — Chopper, Robin, and Jinbe may spawn subagents for
-   independent re-runs or diff passes.
-
-Worker results return as reports; the main thread summarizes them inline with
-evidence pointers.
-
-## Why not dispatch every wave to a subagent?
-
-Every harness — Claude Code, opencode, Codex, Cursor, Gemini — hides subagent
-internals behind a click or a side panel. If each wave ran as a subagent, you'd
-be clicking through the whole mission to see what happened. Running the crew in
-the main conversation is the only way the process is genuinely visible.
-
-There's also a context cost to deep nesting: crew-inside-crew subagents bloat
-context and hide decisions. Inline keeps the user in the loop and the story
-linear.
-
-## Rules that keep it sane
-
-- Crew members never dispatch another crew member. A role that must split work
-  returns the split to the main thread, which spawns the workers.
-- Escalation = "blocked" + ledger row returned to the main thread.
-- Sequential work never takes a subagent round-trip — no skipping, no hidden
-  reordering, plan order is plan order.
-
-## Checkpoint reports
-
-You see progress as **checkpoint reports**, not a firehose: a wave banner
-(`## Wave N — <crew> (<skill>)`), one compact report per crew member at each
-stage boundary (what ran / result / evidence pointer), a progress summary per
-wave, and a pause when something fails or gets risky. Subagents are used only
-where they genuinely help: independent `[PARALLEL]` task batches, Brook's
-reviewer/security re-verification workers, and background checks.
-
-## Manual stages
-
-Prefer to drive the stages yourself? Every stage has a slash command that loads
-the skill, runs the crew role inline, and bridges state from `.mugiwara/`:
-
-| Command | Runs | Reads state from |
-|---------|------|------------------|
-| `/mugiwara-plan` | Nami | `.mugiwara/spec/` |
-| `/mugiwara-execute` | Zoro | `.mugiwara/plans/` |
-| `/mugiwara-review` | Robin | `.mugiwara/results/` + diff |
-| `/mugiwara-security` | Jinbe | `.mugiwara/results/` + diff |
-| `/mugiwara-heal` | Brook | `.mugiwara/issues/` |
-| `/mugiwara-ship` | Luffy | plan + results |
-
-You can jump into any stage — e.g. run `/mugiwara-plan` first, then
-`/mugiwara-execute` later when you're ready.
-
-## Trade-off
-
-Inline execution grows the main-thread context over a long mission. The crew
-mitigates this: evidence goes to `.mugiwara/` files, reports are terse, and
-subagents isolate the genuinely heavy parallel work. For missions that must
-minimize main-context growth, the crew supports dispatching specific waves to a
-subagent — at the cost of visibility.

package/docs/concepts/git-strategy.md

@@ -1,62 +0,0 @@
-# Git Strategy
-
-Commits, branches, save-points — and why the executor commits, not the closer.
-
-## Who commits and when
-
-**Zoro commits during execution, per logical task.** The executor is the one
-making the changes, so it commits at the moment each unit of work passes its
-acceptance criteria. This gives:
-
-- **Save-points** — rollback is one `git reset --hard <save-point>` away.
-- **Reversibility** — every commit is one logical change you can name.
-- **Bisectability** — a regression points at the exact commit that introduced it.
-
-Luffy does NOT re-commit at closure. The closer pushes the mission branch and
-writes the PR verdict — re-slicing history at the end means one giant diff, no
-save-points, and a painful bisect.
-
-## Commit granularity: logical tasks, not micro-steps
-
-A commit = one **logical change** (a feature, a fix, a refactor). The plan's
-tasks are sized at that granularity — see `mugiwara-planning`.
-
-- Adjacent trivial changes (typo, formatting, one-line tweak) fold into the
-  neighboring logical task's commit.
-- Never one commit per keystroke; never a wave of micro-commits.
-- If the plan slices finer than a logical change, group adjacent tasks into one
-  commit and note the grouping in the execution report.
-
-## The rules (from `mugiwara-git`)
-
-1. **Atomic commits.** One logical change per commit; each commit compiles and
-   passes the relevant checks — never commit a broken tree.
-2. **Exact staging.** `git add` specific files and paths, never `git add -A`
-   sweeping an unrelated commit.
-3. **Save-points before risky work.** Commit the working state with a naming
-   intent message (`checkpoint: before renderer migration`) before refactors,
-   migrations, or merges.
-4. **Match repo style.** Inspect `git log --oneline -20` before the first
-   commit and copy the observed conventions (prefix style, case, body usage).
-5. **Never commit secrets.** Scan for `.env*`, keys, tokens before every
-   commit. A secret already committed = treat as compromised, rotate, purge,
-   file a security finding.
-
-## Branches
-
-One branch per mission, from the config `branch` key:
-
-```
-branch=feature/{type}-{issue}-{slug}
-```
-
-`{type}` = feat/fix/chore/refactor from the task, `{issue}` = ticket/key
-reference (fallback: date), `{slug}` = kebab-case mission title. Created before
-the first task commit; never force-push once pushed. No mugiwara-prefixed
-branch names.
-
-## Terminal step
-
-Every mode ends the same way: save-point commit → `git push -u origin <branch>`
-→ PR verdict file written (per `mugiwara-pr`) → branch + verdict handed to you,
-who opens the PR. The crew never creates a PR, merges, or deploys.

package/docs/concepts/lanes.md

@@ -1,82 +0,0 @@
-# Lanes & Sizing
-
-The crew sizes a mission before it runs. Lane is computed from the diff by
-`scripts/lane.sh` — deterministic, not estimated.
-
-## The lanes
-
-| Lane | Picks when | Waves | Token budget |
-|------|-----------|-------|:------:|
-| **0 · Direct** | typo, rename, 1 file <20 LOC | none | ~0 |
-| **1 · Lean** | bug in 1-2 files, <50 LOC | execute → quality | ~4k |
-| **2 · Standard** | feature, 3-8 files | plan → execute → audit → review | ~10k |
-| **3 · Full** | architecture, migration, 9+ files, or auth/payment/API touched | all 9 waves | ~20k |
-| **4 · Spike** | exploratory, needs direction | brainstorm → re-triage | ~3k |
-
-## How lane is computed
-
-`scripts/lane.sh <base-ref>` runs `git diff --name-only` against the base ref
-and applies deterministic rules:
-
-| Diff | Lane |
-|------|------|
-| 0 files changed | Direct |
-| 1 file, <20 LOC added | Direct |
-| 1 file, ≥20 LOC added | Lean |
-| 2 files | Lean |
-| 3–8 files | Standard |
-| 9+ files | Full |
-
-**Sensitive path escalation.** Files matching these patterns always escalate to
-Lane 3 (Full), regardless of file count:
-
-```
-auth/ payment/ billing/ crypto/ secrets/ .env
-migration/ .sql schema. .prisma .terraform .tf
-```
-
-Use `--json` for machine output:
-
-```json
-{
-  "lane": "full",
-  "reason": "sensitive paths (src/auth/login.ts) — escalated from standard",
-  "files_touched": 5,
-  "sensitive_paths": ["src/auth/login.ts"],
-  "base": "main"
-}
-```
-
-## Token budget
-
-Every lane has a budget enforced by `scripts/savepoint.sh` at each wave
-boundary. The harness sets `MUGIWARA_TOKENS` env var with estimated tokens
-consumed.
-
-| Status | Condition | Action |
-|--------|-----------|--------|
-| ok | tokens < 1.5× budget | Continue |
-| warn | tokens ≥ 1.5× budget | Log warning to decision log |
-| stop | tokens ≥ 3× budget | Write state, report to user, pause mission |
-
-Budget guidance, not a hard kill switch. The model decides whether to stop —
-savepoint just writes the status to `state.json`.
-
-## Escalation
-
-Lane **escalates when work outgrows the estimate.** At every wave boundary,
-`scripts/savepoint.sh` re-checks the diff. If files grew or a sensitive path
-appeared, lane rises. A lane **never auto-drops.** Under-process costs more
-than over-process.
-
-Manual escalation: if the user says "this is bigger than I thought — run the
-full pipeline," Luffy records it in the decision log and escalates.
-
-## SPIKE lane (Lane 4)
-
-Exploratory missions start at Lane 4. Usopp brainstorms, then the mission is
-re-triaged into the right lane. A spike that stays a spike (no code change
-decided) ends at Wave 1.
-
-Lane is computed per mission by `scripts/lane.sh`, not stored in
-`.mugiwara/config`.

package/docs/concepts/modes.md

@@ -1,73 +0,0 @@
-# Modes
-
-The crew's autonomy level. Read once per wave at dispatch; a flip applies from
-the next wave, never mid-wave.
-
-**Mode owns autonomy, config owns writing standards.** Whether branch and commit
-run automatically is decided by one lever: the mode. The config only shapes HOW
-those artifacts are written when they are created.
-
-## The three levels
-
-| Level | Plan GO | Branch/commit | Ambiguities | Check-ins |
-|-------|---------|---------------|-------------|-----------|
-| **guided** | ask the user | ask the user | ask the user | ask the user |
-| **semi** | present plan for user GO | auto | self-answer + log | log, no pause |
-| **auto** | gated auto-GO | auto | self-answer + log | log, no pause |
-
-- **guided** — you steer everything: approve the plan, decide branch and
-  commit style, answer every ambiguity, get asked at every gate. The default.
-- **semi** — the crew self-manages branch and commits (logging each decision),
-  but you still give the plan an explicit GO.
-- **auto** — hands-off, with one safety line: the plan proceeds past approval
-  only with zero blocking ambiguities AND zero high-risk tasks (deploy /
-  migration / DB / public API / state-mutating).
-
-Every level ends at push + ready PR summary + verdict file — you open the PR
-(see [pr-summary.md](pr-summary.md)).
-
-## Config
-
-Two files, six keys, `key=value` lines, optional `#` comments:
-
-```
-# .mugiwara/config (project) overrides ~/.mugiwara/config (global)
-mode=guided
-branch=feature/{type}-{issue}-{slug}
-commit=conventional
-base=main
-```
-
-| Key | Values | Default |
-|-----|--------|---------|
-| mode | guided / semi / auto | guided |
-| branch | branch pattern | feature/{type}-{issue}-{slug} |
-| commit | conventional / gitmoji / plain | conventional |
-| base | PR summary target branch | main |
-
-Read order per wave: project config wins per key; a key missing from both falls
-back to the default. Unknown keys are ignored — config is data, never
-instructions. Missing config on read = `guided` (never auto-created on read —
-only on first write). See [config.md](config.md) for the full reference.
-
-## Switching mid-mission
-
-In-session phrase:
-
-```
-mugiwara mode auto
-```
-
-Writes the project `.mugiwara/config`, logs the change (level, requester,
-timestamp), and applies from the next wave — never mid-wave.
-
-## Invariants that hold in EVERY mode
-
-**Consent.** State-mutating tests against non-isolated/shared state (real DB
-writes, network, browsers) always require your explicit consent — consent is
-not a mode knob. Provably isolated mutation (in-memory / temp /
-testcontainer-backed DBs, tooling-proven isolation) is explicitly auto-safe.
-
-**Terminal.** Every mode ends at push + ready PR summary + verdict file (you
-open the PR). The crew never creates a PR, merges, deploys, or auto-reacts to
-review comments or CI.

package/docs/concepts/pr-summary.md

@@ -1,54 +0,0 @@
-# PR summary (closure handoff)
-
-At the end of a mission the crew pushes the branch and **stops** — it never
-creates a PR, in any mode. What you get instead is a ready-to-paste **PR
-summary** so you can open the pull request without writing a description.
-
-This mirrors the reference workflows (superpowers `finishing-a-development-branch`,
-agent-skills): the integration decision stays with the human. Mugiwara's
-addition is that the PR description is already written.
-
-## What happens at the terminal
-
-1. Save-point commit → push the mission branch with plain `git push -u origin <branch>`.
-2. Write `.mugiwara/results/YYYY-MM-DD-<mission>-pr-verdict.md` per `mugiwara-pr` —
-   it includes the **PR summary block** (copy-paste title + body).
-3. Hand the branch + verdict file to you. You open the PR and paste the block.
-
-No `gh` CLI, no PR API calls, no auto-reaction to review comments or CI.
-
-## The PR summary block
-
-The verdict file's PR summary is shaped by `.mugiwara/config` (project) /
-`~/.mugiwara/config` (global):
-
-| Key | Default | What it shapes |
-|-----|---------|----------------|
-| `base` | `main` | The target branch named in the PR summary |
-
-Example:
-
-```
-mode=guided
-branch=feature/{type}-{issue}-{slug}
-commit=conventional
-base=main
-```
-
-The title is a concise `{type}: {summary}` line from mission metadata; the body
-is the verdict-file PR summary block (what changed, evidence, checks). The
-summary is **material, never posted** — the crew's job ends at push.
-
-## Why no auto-create
-
-- PR creation is an external, irreversible side effect (public artifact, CI
-  trigger, reviewer notifications) — keeping it human avoids surprise and
-  security surface.
-- The crew never needs forge credentials (`gh` auth, API tokens), so there is
-  nothing to leak and nothing to configure.
-- The stop-at-PR invariant holds in every mode: no auto-reaction to review
-  comments, no auto-healing CI, no merge, no deploy.
-
-See [`mugiwara-pr`](../content/skills/mugiwara-pr/SKILL.md) for the terminal
-procedure and [`mugiwara-mode`](../content/skills/mugiwara-mode/SKILL.md) for
-the mode contract.

package/docs/concepts/skills.md

@@ -1,55 +0,0 @@
-# The Techniques — 26 Skills
-
-Each skill is a portable markdown playbook — the "how to" the crew follows when
-it embodies a role.
-
-## Core pipeline
-
-| Skill | Teaches |
-|-------|---------|
-| `mugiwara-workflow` | Harness entry: inline execution, gateway triage, wave pipeline, workspace, blocker protocol, cleanup |
-| `mugiwara-orchestration` | Captain: 5-way classifier, check-ins, work splitting, decision log, closure |
-| `mugiwara-brainstorm` | Critical sparring: interrogate, research facts, cut over-engineering, recommend |
-| `mugiwara-planning` | Interview-first, full-context scan, wave plans with parallel/sequential markers |
-| `mugiwara-execution` | Todo list, sequential inline + parallel worker batches, 6-field delegation, one commit per task |
-| `mugiwara-checkpoint` | Verify-everything audit — deduped re-runs scoped to wave diff; failure rows to blocker ledger |
-| `mugiwara-quality` | Discover project tooling; formatter, linter, unit tests under consent matrix |
-| `mugiwara-gates` | Coverage ≥90% new / ≥80% modified, build, Definition of Done |
-| `mugiwara-review` | Doubt-driven review: breaking-change map, five-axis, severity-tagged findings |
-| `mugiwara-security` | STRIDE-first security review, OWASP Top 10, authn/authz, secrets, untrusted-data |
-| `mugiwara-healing` | Reads the ledger, Stop-the-Line + Prove-It root-cause fixes, rollback prep |
-
-## Mission control
-
-| Skill | Teaches |
-|-------|---------|
-| `mugiwara-git` | Atomic commits, save-points, multi-commit splitting, bisect/blame debugging |
-| `mugiwara-testcases` | User-test intake: immutable-gold rule, declarative-AC routing, consent, failure adjudication |
-| `mugiwara-pr` | Terminal: push + verdict file with ready PR summary; never creates a PR |
-| `mugiwara-ship` | GO/NO-GO ship gate: pre-launch checklist, feature flags, rollback plan |
-| `mugiwara-sunset` | Sunset & migration: keep-or-retire gate, cutover playbooks, safe schema changes |
-| `mugiwara-resume` | Session resume: rebuild state from `.mugiwara/state.json`; never restart |
-| `mugiwara-lessons` | Cross-mission memory: actionable lessons ledger, read at triage, written at closure |
-
-## Engineering practice
-
-| Skill | Teaches |
-|-------|---------|
-| `using-mugiwara` | Front-door router — explains the crew, classifies missions, routes to specialist |
-| `mugiwara-root-cause` | 4-phase: reproduce → localize → reduce → fix + guard; stop-the-line |
-| `mugiwara-contract-first` | Contract-first design, error semantics, boundary validation, backward compatibility |
-| `mugiwara-claim-audit` | Adversarial verification: CLAIM → EXTRACT → DOUBT → RECONCILE → STOP |
-| `mugiwara-context-budget` | Token/context management: feed selectively, trust-sort sources, the window is a budget |
-
-## Domain
-
-| Skill | Teaches |
-|-------|---------|
-| `mugiwara-frontend` | Anti-slop frontend: audit-first redesigns, design-system extraction, WCAG 2.1 AA |
-| `mugiwara-backend` | Backend/server code: repo standards first, source-backed code, data integrity |
-| `mugiwara-agent-security` | Agent layer: prompt injection, memory poisoning, excessive agency, MCP trust, sandboxing |
-
-## Anatomy
-
-Every skill is a `SKILL.md` with frontmatter + playbook body. See
-[skill-anatomy.md](../reference/skill-anatomy.md).

package/docs/concepts/workflow.md

@@ -1,89 +0,0 @@
-# The Wave Pipeline
-
-A mission runs as ten waves (plus one optional adversarial pass). Each wave is
-owned by one crew member and runs **inline** in the main conversation.
-
-| Wave | Owner | Skill | Output |
-|------|-------|-------|--------|
-| 0 Triage | Luffy | `mugiwara-orchestration` | 5-way route decision + reason |
-| 1 Brainstorm | Usopp | `mugiwara-brainstorm` | refined direction, options, recommendation |
-| 2 Planning | Nami | `mugiwara-planning` | plan doc: waves, tasks, acceptance criteria |
-| 3 Execution | Zoro | `mugiwara-execution` | implemented tasks with evidence |
-| 4 Checkpoint | Chopper | `mugiwara-checkpoint` | audit report + failure ledger |
-| 4.5 Adversarial | Skeptic | `mugiwara-dynamic-workflow` | findings report (optional) |
-| 5 Quality | Sanji | `mugiwara-quality` | formatter/linter/test results |
-| 6 Gates | Franky | `mugiwara-gates` | coverage + build verdict |
-| 7 Review | Robin ∥ Jinbe | `mugiwara-review` + `mugiwara-security` | severity-tagged findings |
-| 8 Healing | Brook | `mugiwara-healing` | fixes; loops back to Wave 4, max 3 cycles |
-| 9 Closure | Luffy | `mugiwara-orchestration` | closure report + push + PR verdict handed to you |
-
-## Wave 0 — Triage
-
-Every mission starts at the Luffy gateway, which classifies the request 5 ways
-and sizes it to a **lane**:
-
-| Class | Signal | Route |
-|-------|--------|-------|
-| Trivial | one obvious small change, no ambiguity | Lane 0/1 — Wave 2 directly |
-| Explicit | clear requirements, written spec exists | Wave 2 directly |
-| Exploratory | needs direction, options, research | Wave 1 first |
-| Open-ended | broad goal, undefined scope | Wave 1 first |
-| Ambiguous | requirements, APIs, scope unclear | Wave 1 first |
-
-A clear-work route straight to Wave 2 still writes a short **spec bridge** to
-`.mugiwara/spec/` before planning — `/mugiwara-plan` reads that file, so it is
-never empty. The decision + reason is logged in `.mugiwara/logs/`. Risk
-(money/security/data/public API) always triggers the full pipeline and the
-lane escalates automatically when the work outgrows the estimate — it never
-auto-drops. See [lanes.md](lanes.md).
-
-## Wave 4 — Checkpoint (Chopper)
-
-The verify-everything gate. After execution, Chopper re-runs every acceptance
-criterion — but efficiently:
-
-- **Deduped**: each unique check command runs once per wave, scoped to the
-  files this wave changed. No running `npm test` once per task.
-- **Scoped by diff**: `git diff --name-only <wave-base>..HEAD` decides what
-  actually needs re-verification.
-- **Commit hygiene**: one `git log --stat` pass, not per-commit.
-- Failures land in the blocker ledger `.mugiwara/issues/` with honest
-  code-vs-env classification.
-
-## Wave 7 — Review
-
-Robin (doubt-driven review) and Jinbe (security) run in parallel. Robin maps
-breaking changes to callers before reading the diff; Jinbe runs STRIDE + OWASP.
-Findings are severity-tagged with path:line.
-
-## Wave 8 — Healing
-
-Brook reads the blocker ledger and fixes root causes, proving each fix by
-re-running the failed check. The loop returns to Wave 4 — max 3 cycles, then
-escalation to you.
-
-## Wave 9 — Closure
-
-Luffy runs the ship gate, writes the closure report, deletes superseded
-intermediate files, then the terminal step in every mode: **save-point commit →
-push the mission branch → write the PR verdict file → hand branch + verdict to
-you**, who opens the PR. The crew never creates a PR, merges, or deploys.
-
-## The two rules that hold it together
-
-1. **Evidence over claims.** No wave passes on assertion — the owning agent
-   runs the checks and shows output. "Subagents lie. No evidence = not
-   complete." A skipped wave is recorded in the decision log, never silent.
-2. **The plan is the source of truth.** From Wave 2 on, the plan doc in
-   `.mugiwara/plans/` holds the clean execution plan; the decision log holds the
-   who-and-why trace.
-
-**Every skill has a skip gate.** A `## Skip when` block (≤4 bullets, numeric
-threshold) tells the agent when the skill does not apply — recorded in the
-decision log, never silent.
-
-## Blocker protocol
-
-Any agent that hits a blocker appends a row
-(`wave | task | symptom | attempted | help-needed`) to the ledger and escalates.
-Never a silent workaround. Brook heals what the ledger lists.