codymaster 4.8.0 → 7.0.0

package/skills/cm-continuity/SKILL.md

@@ -1,10 +1,19 @@
 ---
 name: cm-continuity
 description: "Working memory protocol — maintains context across sessions via CONTINUITY.md. Inspired by Loki Mode. Read at turn start, update at turn end. Captures mistakes and learnings to prevent repeating errors."
+token_budget: 1200
+compressed: true
+deprecated: false
 ---
 
 # Continuity — Working Memory Protocol
 
+## TL;DR
+- **Use at** session start (read) and end (update)
+- **File**: .cm/CONTINUITY.md (working memory)
+- **Auto-loads**: recent learnings from .cm/learnings.jsonl
+- **Loki Mode**: prevents repeating past mistakes
+
 > **Context persistence across sessions. Mistakes captured. Learnings applied.**
 > Inspired by Loki Mode's CONTINUITY.md protocol (Autonomi).
 
@@ -52,21 +61,9 @@ cm continuity migrate
 # Export SQLite back to JSON (backup)
 cm continuity export
 
-# ── OpenViking backend (optional) ────────────────────────
-# 1. Install OpenViking server (Python 3.10+)
-pip install openviking --upgrade
-
-# 2. Configure ~/.openviking/ov.conf with embedding provider, then start:
-openviking start          # Runs on localhost:1933 by default
-
-# 3. Switch CodyMaster to use OpenViking in .cm/config.yaml:
-#    storage:
-#      backend: viking
-#      viking:
-#        host: localhost
-#        port: 1933
-#        workspace: codymaster
-#        timeout: 60000
+# ── Legacy config note ────────────────────────────────────
+# CodyMaster's supported default path is SQLite + FTS5.
+# Older configs may still say `storage.backend: viking`; CodyMaster now warns and falls back to SQLite.
 ```
 
 ## The Protocol
@@ -187,12 +184,12 @@ Tier 3: LONG-TERM MEMORY (30+ days, only if reinforced)
       · decisions table + decisions_fts
       · skill_outputs per session/chain
       · indexes table (cached L0/L1 content + staleness hash)
-  → Optional: OpenViking backend (storage.backend: viking in .cm/config.yaml)
+  → Legacy config note: `storage.backend: viking` now falls back to SQLite
       · True vector semantic search — finds "async timeout" even when you query "network delay"
       · L0/L1/L2 auto-generated by engine — no manual cm continuity index needed
       · Session compression + long-term memory extraction built-in
       · Graph relations between memories (link/unlink)
-      · Setup: pip install openviking && openviking start
+      · No separate OpenViking setup remains in the supported runtime
   → Fallback: .cm/memory/learnings.json + decisions.json (kept for compat)
   → L0 indexes: .cm/learnings-index.md (~100 tok), .cm/skeleton-index.md (~500 tok)
       · Auto-regenerated on addLearning() + on demand via cm continuity index
@@ -215,27 +212,38 @@ Tier 5: STRUCTURAL CODE MEMORY (optional — code-heavy projects)
 **context bus        = "what did upstream skills produce in this chain?"**
 **L0 indexes         = "cheapest possible memory load (~600 tokens)"**
 **context.db         = "keyword search across all learnings + decisions"**
-**OpenViking (opt.)  = "semantic vector search + auto L0/L1 + session compression"**
+**Legacy `viking` config = "compatibility fallback to SQLite, not a separate backend"**
 **qmd (optional)     = "find what was written across hundreds of docs"**
 
-### MCP Context Server (Claude Desktop integration)
+### MCP Context Server (Claude Desktop, Goose, and any MCP client)
 
-Seven tools exposed over stdio to Claude Desktop and MCP-compatible clients:
-
-| Tool | Purpose |
-|---|---|
-| `cm_query` | FTS5 keyword search — learnings, decisions, or both |
-| `cm_resolve` | Load any `cm://` URI at L0/L1/L2 depth |
-| `cm_bus_read` | Read live context bus state |
-| `cm_bus_write` | Publish skill output to the bus |
-| `cm_budget_check` | Pre-flight token check by category |
-| `cm_memory_decay` | Archive expired learnings (supports dry_run) |
-| `cm_index_refresh` | Regenerate L0 indexes on demand |
+Fifteen tools exposed over stdio — start with `cm mcp-serve`:
 
 ```bash
-# Get install snippet for Claude Desktop config
-cm continuity mcp
-```
+# Start MCP server (stdio)
+cm mcp-serve --project /path/to/project
+
+# Print config snippet for Claude Desktop or Goose
+cm mcp-serve --print-config
+```
+
+| Tool | Purpose | Since |
+|---|---|---|
+| `cm_query` | FTS5 keyword search — learnings, decisions, or both | v4.5 |
+| `cm_resolve` | Load any `cm://` URI at L0/L1/L2 depth | v4.5 |
+| `cm_bus_read` | Read live context bus state | v4.5 |
+| `cm_bus_write` | Publish skill output to the bus | v4.5 |
+| `cm_budget_check` | Pre-flight token check by category | v4.5 |
+| `cm_memory_decay` | Archive expired learnings (supports dry_run) | v4.5 |
+| `cm_index_refresh` | Regenerate L0 indexes on demand | v4.5 |
+| `cm_plan` | Sprint + pipeline snapshot bridge | v4.8 |
+| `cm_review` | Review artifact hints | v4.8 |
+| `cm_qa` | QA workflow hints | v4.8 |
+| `cm_deploy` | Deploy workflow hints | v4.8 |
+| `cm_search` | Search learnings/decisions (alias) | v4.8 |
+| `cm_memory_query` | Memory search (alias) | v4.8 |
+| `cm_memory_write` | Persist a learning with auto-detected category, scope, TTL | v5.1 |
+| `cm_natural` | NLI router: "remember that…" / "forget…" / "what did we learn…" | v5.1 |
 
 ### cm:// URI Scheme
 

package/skills/cm-dashboard/SKILL.archive.md

@@ -0,0 +1,15 @@
+---
+name: cm-dashboard
+description: Open visual Dashboard to track work status (Simulated Kanban board)
+---
+
+# Command: `/cm-dashboard`
+
+When this command is called, the AI Assistant should:
+
+1. **Check status:** Find and read the OpenSpec `openspec/changes/[init]/tasks.md` (and synced `cm-tasks.json`) file in the current project directory (or artifacts directory).
+2. **Visual display:** Aggregate tasks and render them as a Kanban board (Markdown table) with 3 columns:
+   - **🔴 TO DO** (Not started)
+   - **🟡 IN PROGRESS** (In progress)
+   - **🟢 DONE** (Completed)
+3. **Flow report:** Briefly summarize which Mode the Agent is in (PLANNING, EXECUTION, or VERIFICATION) and what the Next Step is.

package/skills/cm-dashboard/SKILL.md

@@ -1,15 +1,26 @@
 ---
 name: cm-dashboard
-description: Open visual Dashboard to track work status (Simulated Kanban board)
+description: "[Deprecated] both visualize project state. Use `cm-status` instead."
+deprecated: true
+merged_into: cm-status
 ---
 
-# Command: `/cm-dashboard`
+# cm-dashboard — Deprecated
 
-When this command is called, the AI Assistant should:
+> ⚠️ This skill is deprecated as of CodyMaster v6.0.0 and will be removed in v6.1.0.
+>
+> **Use `cm-status` instead.** both visualize project state.
+>
+> See [docs/migration-v2.md](../../docs/migration-v2.md) for the full mapping.
 
-1. **Check status:** Find and read the OpenSpec `openspec/changes/[init]/tasks.md` (and synced `cm-tasks.json`) file in the current project directory (or artifacts directory).
-2. **Visual display:** Aggregate tasks and render them as a Kanban board (Markdown table) with 3 columns:
-   - **🔴 TO DO** (Not started)
-   - **🟡 IN PROGRESS** (In progress)
-   - **🟢 DONE** (Completed)
-3. **Flow report:** Briefly summarize which Mode the Agent is in (PLANNING, EXECUTION, or VERIFICATION) and what the Next Step is.
+The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
+
+## Migration
+
+```bash
+# Old:           cm <use this skill>
+# New (v6.0+):   cm status <equivalent action>
+```
+
+If you depend on a capability that didn't carry over, please file an issue:
+https://github.com/tody-agent/codymaster/issues

package/skills/cm-dashboard/ui/app.js

@@ -926,7 +926,15 @@
   }
 
   // ── Utilities ──────────────────────────────
-  function esc(str) { const d = document.createElement('div'); d.textContent = str; return d.innerHTML; }
+  function esc(str) {
+    if (str == null) return '';
+    return String(str)
+      .replace(/&/g, '&')
+      .replace(/</g, '&lt;')
+      .replace(/>/g, '&gt;')
+      .replace(/"/g, '&quot;')
+      .replace(/'/g, '&#39;');
+  }
   function formatTimeAgo(dateStr) {
     const ms = Date.now() - new Date(dateStr).getTime();
     const m = Math.floor(ms / 60000), h = Math.floor(ms / 3600000), d = Math.floor(ms / 86400000);

package/skills/cm-debugging/SKILL.md

@@ -1,10 +1,19 @@
 ---
 name: cm-debugging
 description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
+token_budget: 1500
+compressed: true
+deprecated: false
 ---
 
 # Systematic Debugging
 
+## TL;DR
+- **Use when** any bug, test failure, or unexpected behavior surfaces
+- **Process**: reproduce → isolate → diagnose root cause → fix
+- **Defense in depth**: also add a test that locks the bug
+- **Next**: cm-tdd → cm-quality-gate
+
 ## Overview
 
 Random fixes waste time and create new bugs. Quick patches mask underlying issues.

package/skills/cm-design-studio/SKILL.archive.md

@@ -0,0 +1,34 @@
+---
+name: cm-design-studio
+description: "Use when you need to create 2-3 UI/UX design variants and document a repeatable handoff before coding."
+---
+# cm-design-studio
+
+> Local design-variant workspace: checklist, named variants, and a handoff stub—no external MCP required.
+
+## When to use
+
+- You want **2–3 UI/UX variants** documented before coding.
+- You need a **repeatable handoff** from design choice to implementation agents.
+- You prefer **files under `.cm/`** over ad-hoc chat-only decisions.
+
+## Steps
+
+1. From the repo root: `cm design-studio init`
+2. Edit `.cm/design-studio/CHECKLIST.md` and `VARIANTS.md` (name options A/B/C).
+3. Pick a variant; complete `.cm/design-studio/HANDOFF.md` (screens, tokens, prompt stub).
+4. Run implementation skills (e.g. `cm-execution`, `cm-tdd`) **using the HANDOFF prompt stub** as the single source of truth.
+
+Optional: `cm design-studio status` — list artifact files.
+
+## Output
+
+- `.cm/design-studio/README.md` — happy path
+- `.cm/design-studio/CHECKLIST.md`
+- `.cm/design-studio/VARIANTS.md`
+- `.cm/design-studio/HANDOFF.md`
+
+## Related
+
+- ADR 003 (`docs/adr/003-skill-distro-and-meta.md`) for pack layout when publishing skills.
+- `cm suggest` may recommend other skills based on git + sprint state.

package/skills/cm-design-studio/SKILL.md

@@ -1,30 +1,26 @@
-# cm-design-studio
+---
+name: cm-design-studio
+description: "[Deprecated] design pipeline merged. Use `cm-design-system` instead."
+deprecated: true
+merged_into: cm-design-system
+---
 
-> Local design-variant workspace: checklist, named variants, and a handoff stub—no external MCP required.
+# cm-design-studio — Deprecated
 
-## When to use
+> ⚠️ This skill is deprecated as of CodyMaster v6.0.0 and will be removed in v6.1.0.
+>
+> **Use `cm-design-system` instead.** design pipeline merged.
+>
+> See [docs/migration-v2.md](../../docs/migration-v2.md) for the full mapping.
 
-- You want **2–3 UI/UX variants** documented before coding.
-- You need a **repeatable handoff** from design choice to implementation agents.
-- You prefer **files under `.cm/`** over ad-hoc chat-only decisions.
+The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
 
-## Steps
+## Migration
 
-1. From the repo root: `cm design-studio init`
-2. Edit `.cm/design-studio/CHECKLIST.md` and `VARIANTS.md` (name options A/B/C).
-3. Pick a variant; complete `.cm/design-studio/HANDOFF.md` (screens, tokens, prompt stub).
-4. Run implementation skills (e.g. `cm-execution`, `cm-tdd`) **using the HANDOFF prompt stub** as the single source of truth.
+```bash
+# Old:           cm <use this skill>
+# New (v6.0+):   cm design-system <equivalent action>
+```
 
-Optional: `cm design-studio status` — list artifact files.
-
-## Output
-
-- `.cm/design-studio/README.md` — happy path
-- `.cm/design-studio/CHECKLIST.md`
-- `.cm/design-studio/VARIANTS.md`
-- `.cm/design-studio/HANDOFF.md`
-
-## Related
-
-- ADR 003 (`docs/adr/003-skill-distro-and-meta.md`) for pack layout when publishing skills.
-- `cm suggest` may recommend other skills based on git + sprint state.
+If you depend on a capability that didn't carry over, please file an issue:
+https://github.com/tody-agent/codymaster/issues

package/skills/cm-design-system/SKILL.md

@@ -10,6 +10,7 @@ description: |
 Establish a robust, stable, and consistent UI Design System by either extracting tokens from an existing source (Harvester mode) or scaffolding a fresh system based on premium Kits (Shadcn, Halo, Lunaris, Nitro). Output a strictly formatted `DESIGN.md` artifact ready for UI generation.
 
 # Instructions
+0. **Load Design Taste** (if `.cm/design-taste.json` exists): Before proposing tokens, call `topTaste(cwd, 'color')`, `topTaste(cwd, 'font')`, `topTaste(cwd, 'layout')` from `src/utils/design-taste.ts`. Bias selections toward `approved` entries; avoid `rejected`. Decay is 5 %/week so stale taste fades — trust live weights. After the user accepts or rejects a palette, call `recordTaste(cwd, { dimension, value, verdict })` so future runs improve.
 1. **Clarify Intent**: Determine if the user wants to *extract* an existing design from a URL/Image or *create* a new system from a specific UI Kit.
 2. **Harvester Extraction (If applicable)**: 
    - Analyze the target visual source.

package/skills/cm-ecosystem-roadmap/SKILL.md

@@ -1,3 +1,7 @@
+---
+name: cm-ecosystem-roadmap
+description: "Use when exploring the CodyMaster skill ecosystem roadmap, marketplace, or distro validation."
+---
 # cm-ecosystem-roadmap — marketplace & distros
 
 **In CLI today:** `cm distro validate <dir>` checks skill folder layout; see **ADR 003** (`docs/adr/003-skill-distro-and-meta.md`) for `meta.json` + tmpl rules.

package/skills/cm-engineering-meta/SKILL.archive.md

@@ -0,0 +1,73 @@
+---
+name: cm-engineering-meta
+description: "Use when looking up quick wins, access patterns, or voice map for the engineering meta layer."
+---
+# cm-engineering-meta — quick wins + access + voice map
+
+## Search before building
+
+Before adding infrastructure, search in three layers:
+
+1. **Tried-and-true** — patterns already in this repo / sibling services.
+2. **New-and-popular** — current docs for your stack version.
+3. **First-principles** — only when 1–2 don’t apply.
+
+## AskUserQuestion format
+
+When asking the human to choose:
+
+- Short **context** (what you already know).
+- Clear **question**.
+- **RECOMMENDATION** (one option you’d pick and why).
+- Lettered options **A / B / C** (not vague yes/no).
+
+## Review readiness dashboard (ASCII)
+
+Before ship, print a table:
+
+```
+| Gate        | Status | Notes |
+|-------------|--------|-------|
+| Tests       | ?      |       |
+| Lint/Type   | ?      |       |
+| Secrets     | ?      |       |
+| Manual QA   | ?      |       |
+```
+
+## Completeness gap (code review)
+
+Flag when an **80% solution** is chosen but the **100%** path costs **< 30 minutes** (tests, edge case, docs).
+
+## Investigate Iron Law
+
+- Do **not** patch without a **root cause** hypothesis.
+- After **three** failed fix attempts, stop and question architecture or gather more data.
+
+## Access controls (Goose-style)
+
+- Maintain lists: **autonomous_ok** vs **confirm_required** skill groups (see `.cm/config.example.yaml`).
+- Respect “stop suggesting skill X” in session notes.
+
+## Provider abstraction
+
+Prefer interfaces for LLM calls so **cm-second-opinion** can swap `OPENAI_API_KEY` / future providers without rewriting skills.
+
+## Proactive skill suggestion
+
+Infer stage from files touched and git state:
+
+- Many `test/` edits → suggest **cm-test-gate**.
+- `Dockerfile` / deploy scripts → **cm-safe-deploy** + **cm canary**.
+- `rm` / migration scripts → **cm-guardian** + **cm-secret-shield**.
+
+## Voice-friendly triggers (examples)
+
+| Phrase (approx.) | Skill / command |
+|------------------|-----------------|
+| “Run a security check” | cm-secret-shield / cm-security-gate |
+| “Test the website” | cm browse + cm qa-visual |
+| “Code review this” | cm-code-review |
+| “Deploy safely” | cm-safe-deploy |
+| “Log what went wrong” | `cm retro --note "…"` |
+
+Use Whisper / AquaVoice → paste transcript; map keywords to the table above.

package/skills/cm-engineering-meta/SKILL.md

@@ -1,69 +1,26 @@
-# cm-engineering-meta — quick wins + access + voice map
+---
+name: cm-engineering-meta
+description: "[Deprecated] engineering bridge merged. Use `cm-mcp-engineering` instead."
+deprecated: true
+merged_into: cm-mcp-engineering
+---
 
-## Search before building
+# cm-engineering-meta — Deprecated
 
-Before adding infrastructure, search in three layers:
+> ⚠️ This skill is deprecated as of CodyMaster v6.0.0 and will be removed in v6.1.0.
+>
+> **Use `cm-mcp-engineering` instead.** engineering bridge merged.
+>
+> See [docs/migration-v2.md](../../docs/migration-v2.md) for the full mapping.
 
-1. **Tried-and-true** — patterns already in this repo / sibling services.
-2. **New-and-popular** — current docs for your stack version.
-3. **First-principles** — only when 1–2 don’t apply.
+The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
 
-## AskUserQuestion format
+## Migration
 
-When asking the human to choose:
-
-- Short **context** (what you already know).
-- Clear **question**.
-- **RECOMMENDATION** (one option you’d pick and why).
-- Lettered options **A / B / C** (not vague yes/no).
-
-## Review readiness dashboard (ASCII)
-
-Before ship, print a table:
-
-```
-| Gate        | Status | Notes |
-|-------------|--------|-------|
-| Tests       | ?      |       |
-| Lint/Type   | ?      |       |
-| Secrets     | ?      |       |
-| Manual QA   | ?      |       |
+```bash
+# Old:           cm <use this skill>
+# New (v6.0+):   cm mcp-engineering <equivalent action>
 ```
 
-## Completeness gap (code review)
-
-Flag when an **80% solution** is chosen but the **100%** path costs **< 30 minutes** (tests, edge case, docs).
-
-## Investigate Iron Law
-
-- Do **not** patch without a **root cause** hypothesis.
-- After **three** failed fix attempts, stop and question architecture or gather more data.
-
-## Access controls (Goose-style)
-
-- Maintain lists: **autonomous_ok** vs **confirm_required** skill groups (see `.cm/config.example.yaml`).
-- Respect “stop suggesting skill X” in session notes.
-
-## Provider abstraction
-
-Prefer interfaces for LLM calls so **cm-second-opinion** can swap `OPENAI_API_KEY` / future providers without rewriting skills.
-
-## Proactive skill suggestion
-
-Infer stage from files touched and git state:
-
-- Many `test/` edits → suggest **cm-test-gate**.
-- `Dockerfile` / deploy scripts → **cm-safe-deploy** + **cm canary**.
-- `rm` / migration scripts → **cm-guardian** + **cm-secret-shield**.
-
-## Voice-friendly triggers (examples)
-
-| Phrase (approx.) | Skill / command |
-|------------------|-----------------|
-| “Run a security check” | cm-secret-shield / cm-security-gate |
-| “Test the website” | cm browse + cm qa-visual |
-| “Code review this” | cm-code-review |
-| “Deploy safely” | cm-safe-deploy |
-| “Log what went wrong” | `cm retro --note "…"` |
-
-Use Whisper / AquaVoice → paste transcript; map keywords to the table above.
+If you depend on a capability that didn't carry over, please file an issue:
+https://github.com/tody-agent/codymaster/issues

package/skills/cm-execution/SKILL.md

@@ -1,14 +1,38 @@
 ---
 name: cm-execution
 description: "Use when executing implementation plans — choose mode: batch execution with checkpoints, subagent-per-task, or parallel dispatch for independent problems."
+token_budget: 1800
+compressed: true
+deprecated: false
 ---
 
 # Execution — Execute Plans at Scale
 
+## TL;DR
+- **Use when** running an approved plan from cm-planning
+- **Modes**: A=batch, B=subagent-per-task, C=parallel, D=RARV, E=TRIZ-parallel
+- **Reads**: handoff/plan.json — **Writes**: handoff/exec.json
+- **Always**: tests pass before reporting done
+- **Next**: cm-code-review
+
 > **Role: Lead Developer** — You execute implementation plans systematically with quality gates at every checkpoint.
 
 > **Three modes, one skill.** Choose based on task structure.
 
+## Persona Dispatch (Phase 2)
+
+In Mode B (subagent-per-task) and Mode E (TRIZ-parallel), dispatch the right persona from `agents/` based on the task type:
+
+| Task signal | Persona | File |
+|-------------|---------|------|
+| "design", "architecture", "trade-off" | architect | `agents/architect.md` |
+| "implement", "fix", "refactor" | engineer | `agents/engineer.md` |
+| "review", "audit", "verify" | reviewer | `agents/reviewer.md` |
+| "secret", "auth", "input validation", "deploy" | security | `agents/security.md` |
+| "scope", "intent", "user story" | pm | `agents/pm.md` |
+
+When dispatching a subagent, pass `subagent_type: <persona>` (Claude Code agents) or load the persona file as the system prompt for the inner call.
+
 ## Step 0: Load Working Memory (MANDATORY)
 
 Per `_shared/helpers.md#Load-Working-Memory`
@@ -55,6 +79,7 @@ Have a plan with independent tasks?
 | **B: Subagent** | Plan with independent tasks, same session | Fresh subagent per task + 2-stage review |
 | **C: Parallel** | 2+ independent problems | One agent per problem domain |
 | **E: TRIZ-Parallel** ⚡ | 3+ independent tasks, need speed + quality | Dependency-aware parallel dispatch with per-agent quality gates |
+| **F: Party** | One non-trivial task, want multi-perspective without subagent cost | Single agent rotates Architect → Engineer → Reviewer (→ Security), append-only `.cm/handoff/party.json` |
 
 ---
 
@@ -252,6 +277,69 @@ After EVERY phase, you MUST:
 
 ---
 
+## Mode F: Party (Persona Rotation, single agent)
+
+> **One agent, three voices.** Cheaper than Mode B, deeper than Mode A.
+
+### When
+- Task is non-trivial but small enough for one session
+- You want multi-perspective scrutiny without paying for N subagents
+- Quality matters more than raw speed
+
+### Process
+
+```
+1. ARCHITECT  → Load agents/architect.md as voice → propose design / approach
+                → Append round to .cm/handoff/party.json
+2. ENGINEER   → Load agents/engineer.md as voice → implement against the design
+                → Append round
+3. REVIEWER   → Load agents/reviewer.md as voice → critique implementation
+                → verdict: "pass" | "revise" | "block"
+                → Append round
+4. (optional) SECURITY → Load agents/security.md when task touches auth/files/subprocess
+                → Append round
+5. SYNTHESIZE → Write `final` summary; mark handoff emitted_at
+```
+
+### Stop Conditions
+- Reviewer verdict `pass` → done, write `final`
+- Reviewer verdict `revise` → loop back to ENGINEER (max 2 revisions)
+- Reviewer verdict `block` or 3rd revision → escalate to user, do not ship
+
+### Output Contract
+
+Writes to `.cm/handoff/party.json` matching `PartyHandoff` from `src/handoff/contracts.ts`:
+
+```json
+{
+  "schema": "party@1",
+  "emitted_at": "<ISO>",
+  "emitted_by": "cm-execution",
+  "data": {
+    "topic": "<task title>",
+    "rounds": [
+      {"persona":"architect","output":"...","ts":"<ISO>"},
+      {"persona":"engineer","output":"...","ts":"<ISO>"},
+      {"persona":"reviewer","output":"...","verdict":"pass","ts":"<ISO>"}
+    ],
+    "final": "<one-paragraph synthesis>"
+  }
+}
+```
+
+### Rules
+- **Never skip the reviewer round** — that defeats the point of party mode
+- **Never edit a previous round** — append-only, like a journal
+- **One agent the whole way** — do NOT dispatch subagents inside party mode (use Mode B for that)
+- **Persona files are the source of truth** — load them as system context, don't paraphrase
+
+### Common Mistakes
+- ❌ Running architect + engineer in same voice → missed trade-offs
+- ❌ Skipping security persona on auth/file-touching tasks → see Security Rules below
+- ❌ Letting reviewer revise > 2× → that's a planning problem, escalate
+
+---
+
 ## Security Rules (Learned: March 2026)
 
 > **Code that touches files, subprocesses, or the DOM MUST follow these rules. No exceptions.**
@@ -308,6 +396,16 @@ After EVERY phase, you MUST:
 | `/cm-status` | Quick terminal progress summary |
 | `/cm-dashboard` | Open browser dashboard |
 
+## Karpathy Discipline — Surgical Changes
+
+Every executor (single agent or subagent fleet) must follow:
+- **Touch only what the task requires.** No "while I'm here" formatting, renames, or refactors.
+- **Match existing style** even if you'd write it differently. Consistency > taste.
+- **Notice unrelated dead code? Mention it, don't delete.** Out-of-scope cleanup → spawn a separate task.
+- **Clean only your own orphans.** If your edit makes an import/var unused, remove it. Pre-existing dead code stays unless explicitly asked.
+
+**Diff test:** Every changed line should trace to the task. If a reviewer asks "why this line?", you must point at the task — not "felt cleaner".
+
 ## The Bottom Line
 
 **Choose your mode. Execute systematically. Review at every checkpoint.**