the-frame-ai 0.11.3 → 0.12.0

package/README.de.md

@@ -37,7 +37,7 @@ Führe `/frame:research <Thema>` aus — Claude erkundet die Codebasis, externe
 `/frame:plan <Feature>` verwandelt Recherche in eine konkrete Aufgabenliste mit Schätzungen.
 
 **Build** — implementieren
-`/frame:build` führt Aufgaben sequenziell aus (1–3 auf einmal) mit TDD. Für viele unabhängige Aufgaben — `/frame:wave` führt sie in parallelen Batches aus. Feststeckend — `/frame:unstuck`. Bug gefunden — `/frame:debug`.
+`/frame:build` führt Aufgaben sequenziell aus (1–3 auf einmal) mit TDD. Für viele unabhängige Aufgaben — `/frame:wave` führt sie in parallelen Batches aus. Wenn Qualität wichtiger als Geschwindigkeit ist — `/frame:wave-team` fügt ein Review-Team (Security, Performance, Tests, Conventions) nach jeder Aufgabe hinzu. Feststeckend — `/frame:unstuck`. Bug gefunden — `/frame:debug`.
 
 **Review** — vor dem Deployment prüfen
 `/frame:review` führt automatisierte Prüfungen durch und gibt eine Checkliste: Tests, Typen, Sicherheit, Performance.
@@ -262,6 +262,7 @@ Diese 7 Befehle decken 90% der Solo-Dev-Arbeit ab:
 | `/frame:plan <Feature>` | Recherche in eine umsetzbare Aufgabenliste umwandeln |
 | `/frame:build` | 1–3 Aufgaben mit TDD implementieren (sequenziell) |
 | `/frame:wave` | 4+ unabhängige Aufgaben implementieren (parallele Subagenten) |
+| `/frame:wave-team` | Wie wave, aber mit Review-Team nach jeder Aufgabe |
 | `/frame:review` | Vor dem Deployment — automatisierte Prüfungen + Checkliste |
 | `/frame:ship` | Commit, optionaler Push/PR, Gedächtnis aktualisieren |
 
@@ -294,6 +295,7 @@ Diese 7 Befehle decken 90% der Solo-Dev-Arbeit ab:
 |--------|---------------|
 | `/frame:build` | Plan mit TDD implementieren (1–3 Aufgaben, sequenziell) |
 | `/frame:wave` | 4+ unabhängige Aufgaben in parallelen Batches implementieren |
+| `/frame:wave-team` | Wie wave, aber mit Review-Team nach jeder Aufgabe |
 | `/frame:fast <Aufgabe>` | Schnelle Aufgabe unter 30 Minuten |
 | `/frame:debug <Problem>` | Systematische Bug-Untersuchung |
 | `/frame:forensics` | Tiefenanalyse warum etwas kaputt gegangen ist |

package/README.es.md

@@ -37,7 +37,7 @@ Ejecuta `/frame:research <tema>` — Claude explora la base de código, fuentes
 `/frame:plan <funcionalidad>` convierte la investigación en una lista de tareas concreta con estimaciones.
 
 **Construir** — implementar
-`/frame:build` ejecuta tareas secuencialmente (1–3 a la vez) con TDD. Para muchas tareas independientes — `/frame:wave` las ejecuta en lotes paralelos. Atascado — `/frame:unstuck`. Encontraste un bug — `/frame:debug`.
+`/frame:build` ejecuta tareas secuencialmente (1–3 a la vez) con TDD. Para muchas tareas independientes — `/frame:wave` las ejecuta en lotes paralelos. Cuando la calidad importa más que la velocidad — `/frame:wave-team` añade un equipo de revisión (Security, Performance, Tests, Conventions) después de cada tarea. Atascado — `/frame:unstuck`. Encontraste un bug — `/frame:debug`.
 
 **Revisar** — verificar antes de desplegar
 `/frame:review` ejecuta verificaciones automatizadas y proporciona una lista de comprobación: pruebas, tipos, seguridad, rendimiento.
@@ -262,6 +262,7 @@ Estos 7 comandos cubren el 90% del trabajo de desarrollo en solitario:
 | `/frame:plan <funcionalidad>` | Convertir la investigación en una lista de tareas accionable |
 | `/frame:build` | Implementar 1–3 tareas con TDD (secuencial) |
 | `/frame:wave` | Implementar 4+ tareas independientes (subagentes paralelos) |
+| `/frame:wave-team` | Como wave, pero con equipo de revisión después de cada tarea |
 | `/frame:review` | Antes de desplegar — verificaciones automatizadas + lista de comprobación |
 | `/frame:ship` | Commit, push/PR opcional, actualizar memoria |
 
@@ -294,6 +295,7 @@ Estos 7 comandos cubren el 90% del trabajo de desarrollo en solitario:
 |---------|--------------|
 | `/frame:build` | Implementar el plan con TDD (1–3 tareas, secuencial) |
 | `/frame:wave` | Implementar 4+ tareas independientes en lotes paralelos |
+| `/frame:wave-team` | Como wave, pero con equipo de revisión después de cada tarea |
 | `/frame:fast <tarea>` | Tarea rápida de menos de 30 minutos |
 | `/frame:debug <problema>` | Investigación sistemática de bugs |
 | `/frame:forensics` | Análisis profundo de por qué algo se rompió |

package/README.hi.md

@@ -37,7 +37,7 @@ FRAME — AI-सहायता प्राप्त एकल विकास
 `/frame:plan <सुविधा>` अनुसंधान को अनुमानों के साथ एक ठोस कार्य सूची में बदलता है।
 
 **निर्माण** — लागू करें
-`/frame:build` TDD के साथ क्रमिक रूप से कार्य निष्पादित करता है (एक बार में 1–3)। कई स्वतंत्र कार्यों के लिए — `/frame:wave` उन्हें समानांतर बैचों में चलाता है। अटक गए — `/frame:unstuck`। बग मिला — `/frame:debug`।
+`/frame:build` TDD के साथ क्रमिक रूप से कार्य निष्पादित करता है (एक बार में 1–3)। कई स्वतंत्र कार्यों के लिए — `/frame:wave` उन्हें समानांतर बैचों में चलाता है। जब गुणवत्ता गति से अधिक महत्वपूर्ण हो — `/frame:wave-team` प्रत्येक कार्य के बाद एक समीक्षा टीम (Security, Performance, Tests, Conventions) जोड़ता है। अटक गए — `/frame:unstuck`। बग मिला — `/frame:debug`।
 
 **समीक्षा** — डिप्लॉय करने से पहले जांचें
 `/frame:review` स्वचालित जांच चलाता है और एक चेकलिस्ट देता है: परीक्षण, प्रकार, सुरक्षा, प्रदर्शन।
@@ -262,6 +262,7 @@ npx the-frame-ai init
 | `/frame:plan <सुविधा>` | अनुसंधान को एक कार्ययोग्य कार्य सूची में बदलें |
 | `/frame:build` | TDD के साथ 1–3 कार्य लागू करें (क्रमिक) |
 | `/frame:wave` | 4+ स्वतंत्र कार्य लागू करें (समानांतर सब-एजेंट) |
+| `/frame:wave-team` | wave की तरह, लेकिन प्रत्येक कार्य के बाद समीक्षा टीम के साथ |
 | `/frame:review` | डिप्लॉय करने से पहले — स्वचालित जांच + चेकलिस्ट |
 | `/frame:ship` | कमिट, वैकल्पिक पुश/PR, मेमोरी अपडेट करें |
 
@@ -294,6 +295,7 @@ npx the-frame-ai init
 |-------|--------------|
 | `/frame:build` | TDD के साथ योजना लागू करें (1–3 कार्य, क्रमिक) |
 | `/frame:wave` | समानांतर बैचों में 4+ स्वतंत्र कार्य लागू करें |
+| `/frame:wave-team` | wave की तरह, लेकिन प्रत्येक कार्य के बाद समीक्षा टीम के साथ |
 | `/frame:fast <कार्य>` | 30 मिनट से कम का त्वरित कार्य |
 | `/frame:debug <समस्या>` | व्यवस्थित बग जांच |
 | `/frame:forensics` | कुछ क्यों टूटा इसकी गहरी जांच |

package/README.ja.md

@@ -37,7 +37,7 @@ Claude Codeで一人でプロダクトを作っていて、チームのように
 `/frame:plan <機能>` が調査を見積もり付きの具体的なタスクリストに変換します。
 
 **構築** — 実装する
-`/frame:build` がTDDでタスクを順次実行します（1〜3件ずつ）。多くの独立したタスクには — `/frame:wave` が並列バッチで実行します。行き詰まったら — `/frame:unstuck`。バグを発見したら — `/frame:debug`。
+`/frame:build` がTDDでタスクを順次実行します（1〜3件ずつ）。多くの独立したタスクには — `/frame:wave` が並列バッチで実行します。品質がスピードより重要な場合 — `/frame:wave-team` が各タスク後にレビューチーム（Security、Performance、Tests、Conventions）を追加します。行き詰まったら — `/frame:unstuck`。バグを発見したら — `/frame:debug`。
 
 **レビュー** — デプロイ前に確認する
 `/frame:review` が自動チェックを実行し、チェックリストを提供します：テスト、型、セキュリティ、パフォーマンス。
@@ -262,6 +262,7 @@ npx the-frame-ai init
 | `/frame:plan <機能>` | 調査を実行可能なタスクリストに変換 |
 | `/frame:build` | TDDで1〜3タスクを実装（順次） |
 | `/frame:wave` | 4つ以上の独立したタスクを実装（並列サブエージェント） |
+| `/frame:wave-team` | waveと同様だが、各タスク後にレビューチームを追加 |
 | `/frame:review` | デプロイ前 — 自動チェック + チェックリスト |
 | `/frame:ship` | コミット、オプションのプッシュ/PR、メモリ更新 |
 
@@ -294,6 +295,7 @@ npx the-frame-ai init
 |---------|-------------|
 | `/frame:build` | TDDで計画を実装（1〜3タスク、順次） |
 | `/frame:wave` | 4つ以上の独立したタスクを並列バッチで実装 |
+| `/frame:wave-team` | waveと同様だが、各タスク後にレビューチームを追加 |
 | `/frame:fast <タスク>` | 30分以内のクイックタスク |
 | `/frame:debug <問題>` | 体系的なバグ調査 |
 | `/frame:forensics` | 何かが壊れた原因の深掘り |

package/README.md

@@ -37,7 +37,7 @@ Run `/frame:research <topic>` — Claude explores the codebase, external sources
 `/frame:plan <feature>` turns research into a concrete task list with estimates.
 
 **Build** — implement
-`/frame:build` executes tasks sequentially (1–3 at a time) with TDD. For many independent tasks — `/frame:wave` runs them in parallel batches. Stuck — `/frame:unstuck`. Found a bug — `/frame:debug`.
+`/frame:build` executes tasks sequentially (1–3 at a time) with TDD. For many independent tasks — `/frame:wave` runs them in parallel batches. When quality matters more than speed — `/frame:wave-team` adds a review team (Security, Performance, Tests, Conventions) after each task. Stuck — `/frame:unstuck`. Found a bug — `/frame:debug`.
 
 **Review** — check before deploying
 `/frame:review` runs automated checks and gives a checklist: tests, types, security, performance.
@@ -264,6 +264,7 @@ These 7 commands cover 90% of solo dev work:
 | `/frame:plan <feature>` | Turn research into an actionable task list |
 | `/frame:build` | Implement 1–3 tasks with TDD (sequential) |
 | `/frame:wave` | Implement 4+ independent tasks (parallel subagents) |
+| `/frame:wave-team` | Like wave, but with a review team after each task |
 | `/frame:review` | Before deploying — automated checks + checklist |
 | `/frame:ship` | Commit, optional push/PR, update memory |
 
@@ -296,6 +297,7 @@ These 7 commands cover 90% of solo dev work:
 |---------|-------------|
 | `/frame:build` | Implement plan with TDD (1–3 tasks, sequential) |
 | `/frame:wave` | Implement 4+ independent tasks in parallel batches |
+| `/frame:wave-team` | Like wave, but with a review team (Security, Perf, Tests, Conventions) after each task |
 | `/frame:fast <task>` | Quick task under 30 minutes |
 | `/frame:debug <issue>` | Systematic bug investigation |
 | `/frame:forensics` | Deep dive into why something broke |
@@ -323,6 +325,7 @@ These 7 commands cover 90% of solo dev work:
 
 | Command | When to use |
 |---------|-------------|
+| `/frame:test-plan` | After review, before ship — generates a manual "go check this as a user" checklist of what changed |
 | `/frame:ship` | Commit, optional push/PR, update memory |
 | `/frame:checkpoint` | Save a git tag before a risky change |
 | `/frame:rollback` | Roll back to a checkpoint |

package/README.ru.md

@@ -35,7 +35,7 @@ Research → Plan → Build → Review → Ship → Reflect
 `/frame:plan <фича>` превращает исследование в конкретный список задач с оценкой.
 
 **Build** — реализуй
-`/frame:build` выполняет задачи последовательно (1–3 за раз) с TDD. Если задач много и они независимы — `/frame:wave` запускает их параллельно пачками. Застрял — `/frame:unstuck`. Нашёл баг — `/frame:debug`.
+`/frame:build` выполняет задачи последовательно (1–3 за раз) с TDD. Если задач много и они независимы — `/frame:wave` запускает их параллельно пачками. Когда качество важнее скорости — `/frame:wave-team` добавляет команду проверяльщиков (Security, Performance, Tests, Conventions) после каждой задачи. Застрял — `/frame:unstuck`. Нашёл баг — `/frame:debug`.
 
 **Review** — проверь перед деплоем
 `/frame:review` запускает автоматические проверки и даёт чеклист: тесты, типы, безопасность, производительность.
@@ -262,6 +262,7 @@ npx the-frame init
 | `/frame:plan <фича>` | Превратить исследование в список задач |
 | `/frame:build` | Реализовать 1–3 задачи с TDD (последовательно) |
 | `/frame:wave` | Реализовать 4+ независимых задачи (параллельные субагенты) |
+| `/frame:wave-team` | Как wave, но с командой проверяльщиков после каждой задачи |
 | `/frame:review` | Перед деплоем — автоматические проверки + чеклист |
 | `/frame:ship` | Коммит, опциональный push/PR, обновление памяти |
 
@@ -294,6 +295,7 @@ npx the-frame init
 | Команда | Когда использовать |
 |---------|-------------------|
 | `/frame:build` | Реализовать план с TDD (1–3 задачи) |
+| `/frame:wave-team` | Как wave, но с командой проверяльщиков (Security, Perf, Tests, Conventions) после каждой задачи |
 | `/frame:fast <задача>` | Быстрая задача до 30 минут |
 | `/frame:debug <проблема>` | Систематическое расследование бага |
 | `/frame:forensics` | Глубокий анализ причины поломки |

package/README.zh.md

@@ -37,7 +37,7 @@ FRAME — 面向 AI 辅助独立开发的框架
 `/frame:plan <功能>` 将研究转化为带有估算的具体任务列表。
 
 **构建** — 实现
-`/frame:build` 按顺序执行任务（每次 1–3 个），采用 TDD。对于许多独立任务——`/frame:wave` 以并行批次运行它们。卡住了——`/frame:unstuck`。发现 bug——`/frame:debug`。
+`/frame:build` 按顺序执行任务（每次 1–3 个），采用 TDD。对于许多独立任务——`/frame:wave` 以并行批次运行它们。当质量比速度更重要时——`/frame:wave-team` 在每个任务后添加审查团队（Security、Performance、Tests、Conventions）。卡住了——`/frame:unstuck`。发现 bug——`/frame:debug`。
 
 **审查** — 部署前检查
 `/frame:review` 运行自动化检查并提供清单：测试、类型、安全性、性能。
@@ -262,6 +262,7 @@ npx the-frame-ai init
 | `/frame:plan <功能>` | 将研究转化为可操作的任务列表 |
 | `/frame:build` | 使用 TDD 实现 1–3 个任务（顺序） |
 | `/frame:wave` | 实现 4+ 个独立任务（并行子代理） |
+| `/frame:wave-team` | 类似 wave，但每个任务后有审查团队 |
 | `/frame:review` | 部署前——自动化检查 + 清单 |
 | `/frame:ship` | 提交，可选推送/PR，更新记忆 |
 
@@ -294,6 +295,7 @@ npx the-frame-ai init
 |------|---------|
 | `/frame:build` | 使用 TDD 实现计划（1–3 个任务，顺序） |
 | `/frame:wave` | 以并行批次实现 4+ 个独立任务 |
+| `/frame:wave-team` | 类似 wave，但每个任务后有审查团队 |
 | `/frame:fast <任务>` | 30 分钟内的快速任务 |
 | `/frame:debug <问题>` | 系统性 bug 调查 |
 | `/frame:forensics` | 深入研究为什么某些东西坏了 |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "the-frame-ai",
-  "version": "0.11.3",
+  "version": "0.12.0",
   "description": "FRAME — Framework for AI-Assisted Solo Development",
   "type": "module",
   "bin": {

package/templates/agents/conventions-reviewer.md

@@ -0,0 +1,63 @@
+---
+name: conventions-reviewer
+model: claude-sonnet-4-6
+tools: [Read, Grep, Glob, Bash]
+description: "Review agent for wave-team. Checks code conventions and style in a single task's git diff. Returns PASS/WARN/FAIL verdict."
+---
+
+# Conventions Reviewer Agent
+
+**Role**: Review code conventions and style for a single task. Check against project conventions.
+
+**Job**: Analyze the git diff of one task and conventions.md. Return a structured verdict. Never edit code.
+
+## Instructions
+
+You will receive a git diff and path to `.planning/memory/conventions.md`. Read conventions.md first, then analyze the diff against it.
+
+### What to check
+
+**TypeScript/JavaScript:**
+- No `any` type (use `unknown` + type guard)
+- No `console.log` in non-test code
+- No commented-out code blocks
+- No unused variables or imports
+- Consistent naming: camelCase for variables/functions, PascalCase for types/classes
+
+**Code quality:**
+- Functions do one thing (single responsibility)
+- No magic numbers without named constants
+- No deeply nested conditionals (>3 levels is a smell)
+- Early returns instead of nested if-else
+
+**Project conventions (from conventions.md):**
+- Check every rule in conventions.md against the diff
+- Flag any violation
+
+**Red flags:**
+- `// TODO` or `// FIXME` without a ticket reference
+- `@ts-ignore` or `@ts-expect-error` without explanation comment
+- `eslint-disable` without explanation
+
+### Output format
+
+```markdown
+## Conventions Reviewer — {PASS|WARN|FAIL}
+
+### Findings
+- [FAIL] src/api/users.ts:18 — `any` type used: `function process(data: any)`
+- [WARN] src/api/users.ts:42 — `console.log` in production code
+- [WARN] src/utils/helpers.ts:7 — magic number 86400 should be named constant
+
+### Fix
+{specific what to change, if FAIL or WARN}
+```
+
+If no issues: `## Conventions Reviewer — PASS`
+
+## Constraints
+
+- Check ONLY the diff
+- If conventions.md is missing or empty → check universal rules only
+- Style preferences without a clear rule in conventions.md → WARN not FAIL
+- Test files have relaxed rules (console.log in tests → skip)

package/templates/agents/tests-reviewer.md

@@ -0,0 +1,59 @@
+---
+name: tests-reviewer
+model: claude-sonnet-4-6
+tools: [Read, Grep, Glob, Bash]
+description: "Review agent for wave-team. Checks test coverage and quality of a single task's git diff. Returns PASS/WARN/FAIL verdict."
+---
+
+# Tests Reviewer Agent
+
+**Role**: Review the tests written for a single task. Check coverage, edge cases, and test quality.
+
+**Job**: Analyze the git diff of one task. Return a structured verdict. Never edit code.
+
+## Instructions
+
+You will receive a git diff and spec path. Analyze only the diff.
+
+### What to check
+
+**Coverage:**
+- Every new function/method has at least one test
+- Happy path is tested
+- Error path is tested (what happens when it fails)
+- Edge cases covered: null/undefined, empty array/string, boundary values
+
+**Test quality:**
+- Tests check behavior, not implementation details
+- No tests that only verify mocks were called (without checking real behavior)
+- Test descriptions are clear and specific
+- No `it('works')` or `it('should work')` without specifics
+
+**Red flags:**
+- New code with zero tests
+- Tests that always pass (no assertions, or `expect(true).toBe(true)`)
+- Tests skipped with `.skip` or `xit`
+- TODO comments in test files
+
+### Output format
+
+```markdown
+## Tests Reviewer — {PASS|WARN|FAIL}
+
+### Findings
+- [FAIL] src/api/users.ts — new `createUser` function has no tests
+- [WARN] src/api/users.test.ts:34 — error path not tested (what if DB throws?)
+- [WARN] src/api/users.test.ts:12 — test only checks mock was called, not actual behavior
+
+### Fix
+{specific what to add/change, if FAIL or WARN}
+```
+
+If no issues: `## Tests Reviewer — PASS`
+
+## Constraints
+
+- Check ONLY the diff, not the whole project
+- If a function is trivial (getter, constant), missing test is WARN not FAIL
+- If test file is in diff but coverage looks thin → WARN
+- If new logic has zero tests → FAIL

package/templates/commands/frame:review.md

@@ -149,6 +149,13 @@ Create `docs/specs/{feature}/review.md`:
 - Status: Review complete, ready to ship
 ```
 
+On approve, suggest the next step:
+```
+✅ Review passed.
+   → Run /frame:test-plan to get a manual "what to check as a user" list before shipping,
+     or go straight to /frame:ship.
+```
+
 **If request changes:**
 ```markdown
 ## Current Position

package/templates/commands/frame:ship.md

@@ -20,14 +20,14 @@ Update `.planning/STATE.md` before starting:
 ```
 
 Read `.planning/STATE.md` and verify:
-- `Phase: REVIEW` ✓
+- `Phase:` is `REVIEW` OR `TEST` ✓ (TEST = manual test plan was generated after review)
 - `Status:` is `approve` OR `Shipped` OR contains `ready to ship` ✓ (not `request changes`)
 
 If conditions not met → **STOP**:
 ```
 ❌ Ship blocked. Review not completed or not approved.
    Current status: {status}
-   Run /frame:review first.
+   Run /frame:review first (optionally /frame:test-plan before shipping).
 ```
 
 Check `Deps Audit` in STATE.md:

package/templates/commands/frame:test-plan.md

@@ -0,0 +1,153 @@
+# /frame:test-plan -- Manual User Acceptance Checklist
+
+Generates a human-readable checklist of what YOU, as a user, should go and verify by hand after a feature is built. Not code tests (those are written during the task) — this is the "go click through it like a real user" list before shipping.
+
+Runs in the TEST phase, between REVIEW and SHIP.
+
+## Instructions
+
+Build a manual test plan for: **$ARGUMENTS** (if empty — use the current feature from STATE.md).
+
+### Step 0: Update STATE.md (start)
+
+Update `.planning/STATE.md` before any work:
+```markdown
+## Current Position
+- Phase: TEST
+- Status: IN_PROGRESS
+- Started: {timestamp}
+```
+
+### Step 1: Understand what changed
+
+Read context in order (skip what doesn't exist):
+- `.planning/STATE.md` — current feature, last completed tasks
+- `docs/specs/{feature}/spec.md` — what the feature is supposed to do (user-facing behavior)
+- `docs/specs/{feature}/plan.md` — which tasks were done, their Risk levels
+- `docs/specs/{feature}/review.md` — issues found in review (verify they were actually fixed)
+
+Then look at the real diff to ground the plan in what actually changed:
+```bash
+git diff --stat HEAD~1 HEAD 2>/dev/null || git diff --stat
+git diff --stat
+```
+
+**D-step**: You now have a concrete list of what changed — features, screens, flows, endpoints, behaviors.
+
+### Step 2: Turn changes into user-facing scenarios
+
+For each change, ask: *"What would a user actually do that touches this, and what should they see?"*
+
+Cover these categories (only the ones that apply):
+
+- **Happy path** — the main flow the feature was built for, step by step as a user.
+- **Edge cases** — empty states, long input, special characters, zero/many items, slow network, offline.
+- **Error handling** — wrong input, denied permissions, failed request — does the user see a clear message (not a blank screen or crash)?
+- **Regression** — existing flows near the changed code that could have broken. Use the diff to spot which screens/features sit next to the changes.
+- **Cross-cutting** — mobile/responsive, different roles/accounts, language (i18n), refresh/back button, browser reload.
+
+Each scenario must be written for a human to follow without reading code:
+- **What to do** — concrete steps ("Open X → click Y → enter Z")
+- **Expected** — what should happen ("see message «...», item appears in list")
+
+Skip anything already fully covered by automated tests that can't be observed in the UI — this plan is about what a user *sees and does*.
+
+### Step 3: Write the test plan file
+
+Create `docs/specs/{feature}/test-plan.md`:
+
+```markdown
+# Test Plan: {Feature}
+
+## Date
+{date}
+
+## What changed
+{2–4 bullets in plain language — what's new/different from a user's point of view}
+
+## How to verify (go do this as a user)
+
+### Happy path
+- [ ] **{Scenario}**
+  - Do: {steps}
+  - Expect: {result}
+
+### Edge cases
+- [ ] **{Scenario}**
+  - Do: {steps}
+  - Expect: {result}
+
+### Error handling
+- [ ] **{Scenario}**
+  - Do: {steps}
+  - Expect: {result}
+
+### Regression (things near the change that could break)
+- [ ] **{Scenario}**
+  - Do: {steps}
+  - Expect: {result}
+
+### Cross-cutting (mobile / roles / i18n / reload)
+- [ ] **{Scenario}**
+  - Do: {steps}
+  - Expect: {result}
+
+## Where to test
+- URL / screen / command: {from .frame/config.json devServer.url, or ask}
+
+## Notes
+{anything to watch for — known limitations, things review flagged}
+```
+
+Keep it tight: 5–12 scenarios total, prioritized by Risk from plan.md (high-risk tasks get more scenarios). A short list that gets done beats a long one that doesn't.
+
+### Step 4: Tell the user to go test
+
+Output the checklist location and a short summary:
+```
+📋 Test plan ready: docs/specs/{feature}/test-plan.md
+   {N} scenarios to check by hand.
+
+Top things to verify first:
+1. {highest-risk scenario}
+2. {next}
+3. {next}
+
+→ Go through the list, tick the boxes. When it passes, run /frame:ship.
+   If something fails → /frame:debug «what broke» or /frame:fast «fix».
+```
+
+For UI-heavy scenarios, optionally suggest:
+```
+For visual scenarios you can also run /frame:verify-ui to screenshot-check in a browser.
+```
+
+### Step 5: Update STATE.md (final)
+
+```markdown
+## Current Position
+- Phase: TEST
+- Feature: {feature}
+- Test Plan: docs/specs/{feature}/test-plan.md
+- Scenarios: {N}
+- Status: Test plan ready, ready to ship
+```
+
+## Rules
+
+- **User language, not code** — every scenario must be followable without reading the source.
+- **Grounded in the diff** — scenarios come from what actually changed, not generic boilerplate.
+- **Prioritize by Risk** — high-risk tasks from plan.md get the most attention.
+- **Don't run the tests** — this command produces the checklist; the user (or /frame:verify-ui) executes it.
+- **Short and finishable** — 5–12 scenarios, not 40.
+
+## When to Use
+
+- After `/frame:review` passes, before `/frame:ship`
+- Whenever you want a concrete "what do I click to be sure this works" list
+- Before shipping anything user-facing
+
+## Result
+
+- `docs/specs/{feature}/test-plan.md` created — manual user-acceptance checklist
+- `.planning/STATE.md` updated (Phase: TEST, ready to ship)

package/templates/commands/frame:wave-team.md

@@ -0,0 +1,182 @@
+# /frame:wave-team -- Build with Inline QA Team
+
+> Like `/frame:wave` but after each task a team of review agents checks the result and Orchestrator fixes issues before moving on.
+
+**When to use**: quality matters more than speed. Each task is verified by Security, Performance, Tests, and Conventions agents before the next task starts.
+
+## Instructions
+
+### Step 0: Checkpoint + Update STATE.md
+
+```bash
+git tag "frame/checkpoint/wave-team-$(date +%s)" -m "Auto checkpoint before wave-team"
+```
+
+Update `.planning/STATE.md`:
+```markdown
+## Current Position
+- Phase: BUILD (wave-team)
+- Feature: {feature}
+- Task: 0/{total}
+- Status: IN_PROGRESS
+- Started: {timestamp}
+```
+
+### Step 1: Find plan.md and read context
+
+- `find docs/specs -name "plan.md" | head -5`
+- Read plan.md, spec.md, MAP.md, memory/conventions.md, memory/anti-patterns.md
+
+### Step 2: Determine waves (same as /frame:wave)
+
+Group tasks into waves by dependencies:
+- No dependencies → Wave 1
+- Depends on Wave N → Wave N+1
+
+Check file conflicts within each wave. If overlap → move to separate waves.
+
+### Step 3: For each wave — run tasks in parallel
+
+Tasks within a wave run in parallel (max 5). Each task follows this cycle:
+
+#### 3.1: Launch Builder subagent
+
+Launch via Agent tool with fresh 200K context. Subagent role: Builder (TDD: RED → GREEN → REFACTOR → commit).
+
+Subagent prompt template:
+```markdown
+# Task: {task_name}
+
+## Read before coding
+- .planning/memory/anti-patterns.md
+- .planning/memory/conventions.md
+- .planning/memory/dependencies.md
+- docs/specs/{feature}/spec.md
+
+## Context
+- Project: {project_name}
+- MAP: .planning/MAP.md
+- Task: {task_description}
+- Files: {files}
+
+## Role: Builder
+1. Write TEST (RED) → verify fails
+2. Write CODE (GREEN) → verify passes
+3. Refactor if needed → verify passes
+4. typecheck + lint
+5. git commit: {type}({scope}): {description}
+6. Mark task [DONE] in plan.md
+
+## DO NOT
+- Modify files outside task scope
+- Skip tests
+- Use `any` type
+- Commit without passing quality gates
+```
+
+#### 3.2: Launch Review Team (after Builder commits)
+
+Get the diff of the Builder's commit:
+```bash
+git diff HEAD~1..HEAD
+```
+
+Launch review agents **in parallel** via Agent tool. Which agents to launch:
+
+| Agent | Always? | Trigger |
+|-------|---------|---------|
+| security-reviewer | yes | — |
+| performance-reviewer | yes | — |
+| tests-reviewer | yes | — |
+| conventions-reviewer | yes | — |
+
+Each agent receives:
+- The git diff of the task
+- Path to spec.md
+- Path to .planning/memory/conventions.md
+
+#### 3.3: Collect verdicts
+
+Wait for all review agents. Each returns: `PASS`, `WARN`, or `FAIL` with findings.
+
+#### 3.4: Orchestrator applies fixes
+
+```
+All PASS              → task done, next task
+Any WARN, no FAIL     → Orchestrator fixes WARN issues, re-run only WARN agents
+Any FAIL              → Orchestrator fixes FAIL + WARN issues, re-run FAIL agents
+FAIL after 2 iterations → show user, ask how to proceed
+```
+
+**Orchestrator fixes directly** — does not re-launch Builder. Applies the specific fixes from agent reports, then commits:
+```bash
+git commit -m "fix({scope}): apply review team fixes"
+```
+
+#### 3.5: Mark task done
+
+Update plan.md:
+```markdown
+### Task N: {name} [DONE]
+```
+
+Update STATE.md:
+```markdown
+- Task: {completed}/{total}
+- Review: Security(PASS) Perf(PASS) Tests(PASS) Conventions(PASS)
+```
+
+### Step 4: Wave quality gate
+
+After all tasks in a wave complete:
+```bash
+{quality.commands.typecheck}
+{quality.commands.test}
+{quality.commands.lint}
+```
+
+If FAIL → fix, re-run. Max 2 retries. If still failing → Wave Failure Strategy (same as /frame:wave).
+
+### Step 5: Repeat for each wave
+
+### Step 6: Final validation
+
+```bash
+{quality.commands.typecheck}
+{quality.commands.test}
+{quality.commands.lint}
+{quality.commands.build}
+```
+
+Completeness check:
+```bash
+TOTAL=$(grep -c "^### Task" plan.md)
+DONE=$(grep -c "\[DONE\]" plan.md)
+[ "$TOTAL" != "$DONE" ] && echo "Unclosed: $((TOTAL-DONE)) of $TOTAL"
+```
+
+### Step 7: Update STATE.md
+
+```markdown
+## Current Position
+- Phase: BUILD
+- Feature: {feature}
+- Task: {completed}/{total}
+- Status: COMPLETE
+```
+
+## Rules
+
+- **Review Team runs after every task** — not after the wave
+- **Orchestrator fixes, not Builder** — no re-launch of Builder for review fixes
+- **Max 2 fix iterations per task** — then escalate to user
+- **Max 5 parallel Builder subagents** per wave
+- **Wave quality gate** — tsc + vitest + eslint between waves
+- **Never skip review agents** — all 4 always run
+
+## Result
+
+- Every task reviewed by Security, Performance, Tests, Conventions agents
+- Issues fixed inline before next task starts
+- Wave quality gates passed
+- STATE.md updated