@brunosps00/dev-workflow 0.15.0 → 1.0.0

package/scaffold/en/commands/dw-new-project.md

@@ -13,11 +13,11 @@ You are a workspace bootstrap lead for the dev-workflow ecosystem. Your job is t
 - Spinning up a learning sandbox where you want a realistic stack (db + cache + email + observability) without 30 minutes of YAML
 - NOT for adding services to an existing project — use `/dw-dockerize --audit` for that
 - NOT for adding a new app inside an existing monorepo — that needs a different command (planned for a future release)
-- NOT a replacement for `/dw-create-prd` — this generates the workspace, not the product spec
+- NOT a replacement for `/dw-plan prd` — this generates the workspace, not the product spec
 
 ## Pipeline Position
 
-**Predecessor:** `npx dev-workflow init` (ran from inside the target directory) | **Successor:** `/dw-create-prd` for the first feature, or `/dw-analyze-project` after the first substantial commit to enrich `.dw/rules/`
+**Predecessor:** `npx dev-workflow init` (ran from inside the target directory) | **Successor:** `/dw-plan prd` for the first feature, or `/dw-analyze-project` after the first substantial commit to enrich `.dw/rules/`
 
 ## Complementary Skills
 
@@ -242,7 +242,7 @@ Generate a starter README with:
 - Local Dev (port table for selected services + UI URLs + default credentials)
 - Architecture diagram (ASCII from the one-pager)
 - Project layout (tree of top-level dirs)
-- Dev-workflow integration (mentions `/dw-create-prd`, `/dw-run-task`, `/dw-run-qa`, `/dw-deps-audit`, `/dw-security-check`)
+- Dev-workflow integration (mentions `/dw-plan prd`, `/dw-run`, `/dw-qa`, `/dw-secure-audit --plan`, `/dw-secure-audit`)
 
 If `create-*` already generated a README, **append** to it under "## Local Dev"; do not overwrite.
 
@@ -303,7 +303,7 @@ monorepo: <pnpm-workspaces|turborepo|nx|none>
 2. `pnpm install` (or your chosen package manager).
 3. `pnpm dev:up` to bring up all services. Wait for healthchecks.
 4. Open MailHog UI at http://localhost:8025 to confirm email capture is wired.
-5. `/dw-create-prd` to draft the first feature.
+5. `/dw-plan prd` to draft the first feature.
 6. After your first substantial commit, run `/dw-analyze-project` to enrich `.dw/rules/`.
 ```
 
@@ -336,15 +336,15 @@ monorepo: <pnpm-workspaces|turborepo|nx|none>
 
 ## Integration With Other dw-* Commands
 
-- **`npx dev-workflow init`** is a hard predecessor. Run order: `init` → `/dw-new-project` → `/dw-create-prd`.
-- **`/dw-create-prd`** is the suggested next step after a successful bootstrap.
+- **`npx dev-workflow init`** is a hard predecessor. Run order: `init` → `/dw-new-project` → `/dw-plan prd`.
+- **`/dw-plan prd`** is the suggested next step after a successful bootstrap.
 - **`/dw-analyze-project`** should run after the first substantial commit to enrich `.dw/rules/` — the bootstrap leaves a minimal seed.
-- **`/dw-deps-audit --scan-only`** can run immediately after bootstrap to confirm no vulnerable deps shipped from the `create-*` templates.
-- **`/dw-security-check`** runs as part of the standard PRD pipeline after the first feature lands.
+- **`/dw-secure-audit --plan --scan-only`** can run immediately after bootstrap to confirm no vulnerable deps shipped from the `create-*` templates.
+- **`/dw-secure-audit`** runs as part of the standard PRD pipeline after the first feature lands.
 - **`/dw-dockerize`** is the sister command for retrofitting Docker into an existing project that didn't start with this command.
 
 ## Inspired by
 
-`dw-new-project` is dev-workflow-native. The interview pattern borrows from `/dw-create-prd` (Socratic clarification, conditional branching by prior artifact). The execution discipline (per-phase verification, atomic gate before mutation) borrows from `/dw-deps-audit` and `/dw-security-check`. The compose-composition logic is delegated to the `docker-compose-recipes` bundled skill. The wrap-the-official-tool philosophy was confirmed via `/dw-find-skills` against the `npx skills` ecosystem on 2026-04-28 — no skill there matched the "interview + multi-stack scaffold + dev compose" combination at sufficient quality.
+`dw-new-project` is dev-workflow-native. The interview pattern borrows from `/dw-plan prd` (Socratic clarification, conditional branching by prior artifact). The execution discipline (per-phase verification, atomic gate before mutation) borrows from `/dw-secure-audit --plan` and `/dw-secure-audit`. The compose-composition logic is delegated to the `docker-compose-recipes` bundled skill. The wrap-the-official-tool philosophy was confirmed via `/dw-find-skills` against the `npx skills` ecosystem on 2026-04-28 — no skill there matched the "interview + multi-stack scaffold + dev compose" combination at sufficient quality.
 
 </system_instructions>

package/scaffold/en/commands/dw-plan.md

@@ -0,0 +1,175 @@
+<system_instructions>
+You are a planning orchestrator that takes an idea through the full PRD → TechSpec → Tasks pipeline with checkpoints between each stage. Default mode runs all three sequentially; flags allow entering or exiting mid-pipeline.
+
+## When to Use
+- Use when you have an idea and need to produce all three planning artifacts (PRD + TechSpec + Tasks) so `/dw-run` can execute.
+- Use when you want to update one specific stage (e.g., re-run tasks after editing the techspec).
+- Do NOT use for a simple bug fix — `/dw-bugfix` handles that.
+- Do NOT use mid-implementation — once `/dw-run` is in flight, edits go through `/dw-bugfix` or back to `plan techspec --update`.
+
+## Pipeline Position
+**Predecessor:** `/dw-brainstorm` (optional, for ideation) | **Successor:** `/dw-run`
+
+## Modes
+
+| Invocation | What runs |
+|------------|-----------|
+| `/dw-plan "<idea>"` | **Default.** PRD → TechSpec → Tasks sequentially, with an explicit user-approval checkpoint between each stage. |
+| `/dw-plan prd "<idea>"` | Only generates the PRD. Stops after user approval. |
+| `/dw-plan techspec` | Assumes a PRD exists at `.dw/spec/prd-<feature>/prd.md`. Generates only the TechSpec. |
+| `/dw-plan tasks` | Assumes PRD + TechSpec exist. Generates only the tasks breakdown. |
+| `/dw-plan --from techspec "<idea>"` | Skips PRD generation (assumes it exists), starts at TechSpec. |
+| `/dw-plan --council "<idea>"` | Default flow plus multi-advisor debate during the TechSpec stage for high-impact architectural decisions. |
+
+## Inputs
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `{{IDEA}}` | The feature idea or PRD slug being planned | `"users can export invoices to PDF"` or `prd-invoice-export` |
+| `{{MODE}}` | Stage flag (optional) | `prd` / `techspec` / `tasks` / `--from techspec` / `--council` |
+
+## Complementary Skills
+
+When available under `./.agents/skills/`, use these as planning support:
+
+- `dw-source-grounding`: **ALWAYS** in TechSpec stage — every framework/library decision must cite official docs with version + retrieval date.
+- `dw-ui-discipline`: **REQUIRED** when the PRD has UI surfaces — runs the 4 grounding questions before any visual design lands in the TechSpec.
+- `dw-llm-eval`: **REQUIRED** when the PRD describes an AI feature — an eval-plan subtask is mandatory in the tasks breakdown.
+- `dw-testing-discipline`: applied during the tasks stage — every test-adding task names its invariant per the placement doctrine.
+- `dw-council` (opt-in via `--council`): multi-advisor stress-test on the major architectural decision during TechSpec stage.
+- `dw-codebase-intel`: consulted for API conventions, architecture patterns, naming when designing the TechSpec.
+
+## Constitution Gate
+
+<critical>BEFORE any stage, check `.dw/constitution.md`. If MISSING, copy `templates/constitution-template.md` to `.dw/constitution.md` (severity=info defaults), notify the user in chat, and continue. If PRESENT, every FR (PRD), every architectural decision (TechSpec), and every task (Tasks) carries Constitution Alignment metadata mapping to relevant principles or declaring deviation.</critical>
+
+## Codebase Intelligence
+
+<critical>If `.dw/intel/` exists, query it via `/dw-intel` before each stage. MANDATORY for TechSpec stage.</critical>
+- PRD stage: `/dw-intel "existing features in the <topic> domain"` to avoid duplicate functionality.
+- TechSpec stage: `/dw-intel "architectural patterns, API conventions, technical decisions"` to align with existing project shape.
+- Tasks stage: `/dw-intel "test patterns, build pipeline, deployment cadence"` for accurate task sizing.
+
+If `.dw/intel/` doesn't exist, fall back to `.dw/rules/` and direct grep. Suggest `/dw-intel --build` to populate intel for richer downstream context.
+
+## Stage 1 — PRD generation
+
+Runs when default mode OR `plan prd`.
+
+### Prerequisites for this stage
+- Idea or topic from the user.
+- (Optional) brainstorm one-pager from `/dw-brainstorm --onepager` at `.dw/spec/ideas/<slug>.md`.
+
+### Required behavior
+
+1. **Clarification questions (MINIMUM 7).** Before writing anything, ask 7+ focused questions covering: goals, target users, scope boundaries, success metrics, rollout strategy, integration points, edge cases.
+2. **Web search MINIMUM 3 queries** for market patterns, regulatory context, competitor approaches when relevant.
+3. **Constitution alignment.** Each functional requirement (FR-N.M) includes a `Constitution Alignment: respects P-NNN, P-MMM` line OR `no applicable principle: <reason>`.
+4. **Multi-project awareness.** If the feature spans multiple projects in the workspace, consult `.dw/rules/integrations.md` and document scope in the PRD's "Impacted Projects" section.
+5. **Output location:** `.dw/spec/prd-<feature-slug>/prd.md`.
+
+### Checkpoint
+After PRD is drafted, present a summary to the user (1-page TLDR + open questions). Wait for explicit approval before proceeding to Stage 2.
+
+**STOP CONDITIONS:**
+- PRD has unresolved "Open Questions" section → cannot proceed.
+- User wants edits → loop back, regenerate.
+- User declines TechSpec stage → exit (saved PRD remains).
+
+## Stage 2 — TechSpec generation
+
+Runs when default mode (after PRD approval) OR `plan techspec` OR `plan --from techspec`.
+
+### Prerequisites for this stage
+- PRD exists at `.dw/spec/prd-<feature-slug>/prd.md` with NO unresolved open questions.
+
+### Required behavior
+
+1. **Hard gate: PRD open questions.** If `.dw/spec/prd-<feature>/prd.md` has an "Open Questions" section with unresolved items, STOP and ask the user to resolve them first.
+2. **Clarification questions (MINIMUM 7).** Technical questions covering: domain placement, data flow, dependencies, core interfaces, test strategy, reuse-vs-build, multi-project integration if applicable.
+3. **Web search MINIMUM 3 queries** for technical patterns + Context7 MCP for framework/library specifics.
+4. **Source grounding (`dw-source-grounding`).** Every framework/library decision ships with `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`.
+5. **Constitution gate.** Each architectural decision lists `Respects: P-NNN` or `Deviates: P-NNN — justification: <ADR slug or rationale>`. Deviations from `severity: high/critical` principles without ADR → STOP.
+6. **API design discipline.** When defining endpoints, consult `dw-codebase-intel/references/api-design-discipline.md` for Hyrum's Law, error semantics, versioning.
+7. **UI sections** (when feature has UI): the 4 grounding questions from `dw-ui-discipline` must be answered in the techspec; state matrix + scene sentence required.
+8. **Branch name section:** `feat/prd-<feature-slug>`.
+9. **Testing strategy section:** explicit tests-per-method, mock setup, coverage targets (80% services, 70% controllers), E2E flows.
+10. **Output location:** `.dw/spec/prd-<feature-slug>/techspec.md` (same dir as PRD).
+
+### Optional: `--council` flag
+
+When `--council` is passed, after the user signals the techspec is near-final BUT before finalizing the major architectural decision, invoke the `dw-council` skill for multi-advisor stress-test (3-5 archetypes with steel-manning). Output appended as "Architectural Debate" section. Decisions hardening from the council become ADRs via `/dw-adr`.
+
+### Checkpoint
+Present TechSpec summary (chosen architecture + key decisions + test strategy + integration points) to user. Wait for explicit approval before Stage 3.
+
+## Stage 3 — Tasks breakdown
+
+Runs when default mode (after TechSpec approval) OR `plan tasks`.
+
+### Prerequisites for this stage
+- PRD + TechSpec exist at `.dw/spec/prd-<feature-slug>/`.
+
+### Required behavior
+
+1. **Feature branch instruction:** include the `feat/prd-<feature-slug>` branch creation in the tasks summary.
+2. **Decompose** PRD + TechSpec into tasks. Target ~6 tasks per feature. **NEVER exceed 2 FRs per task.**
+3. **End-to-end coverage:** every user-facing flow has backend + frontend + functional UI subtasks if applicable.
+4. **Test placement (`dw-testing-discipline`):** every test-adding subtask names its invariant per the placement doctrine. Owning layer specified.
+5. **Constitution alignment:** every task lists `Constitution: respects P-NNN` or `Constitution: deviates P-NNN — ADR planned: <slug>` or `Constitution: n/a — reason: <one-liner>`.
+6. **LLM-eval subtask (when applicable):** if the PRD has an AI feature, one task must include an Eval Plan subtask (reference dataset path, oracle rungs, judge calibration, target metrics).
+7. **Dependency declaration:** each task explicitly lists which previous tasks it depends on. Validation rejects cycles.
+8. **Output locations:**
+   - Summary: `.dw/spec/prd-<feature-slug>/tasks.md`
+   - Per-task files: `.dw/spec/prd-<feature-slug>/<N>_task.md`
+
+### Final Consistency Check (auto-invoked before user approval)
+
+Run 5-dimension check, write `.dw/spec/prd-<feature-slug>/tasks-validation.md`:
+
+1. **FR coverage:** every numbered FR maps to ≥1 task.
+2. **Task grounding:** every task references ≥1 FR.
+3. **Test coverage:** every user-facing FR has ≥1 test-adding task.
+4. **Dependency graph:** topological order valid, no cycles.
+5. **Constitution alignment:** every task has the alignment line (only if `.dw/constitution.md` exists).
+
+Any FAIL → STOP. Show the dimension table in chat. Three options: auto-fix (regenerate affected tasks), manual edit, explicit override with reason.
+
+### Checkpoint
+Present tasks.md summary + per-task list. User approves to allow `/dw-run` execution.
+
+## Output Files Summary
+
+After full plan run, the PRD directory contains:
+
+```
+.dw/spec/prd-<feature-slug>/
+├── prd.md                 # Stage 1 output
+├── techspec.md            # Stage 2 output
+├── tasks.md               # Stage 3 summary
+├── 1_task.md, 2_task.md...# Stage 3 per-task files
+├── tasks-validation.md    # Stage 3 consistency check
+└── adrs/                  # ADRs created via --council or during stages
+```
+
+## Anti-patterns
+
+- Skipping clarification questions to "save time" — every saved minute upstream costs hours during implementation.
+- Generating TechSpec from a PRD with open questions → 90% chance of techspec rewrites.
+- Generating tasks before techspec is approved → tasks miss architecture context.
+- Skipping the consistency check because tasks "look fine" → FR drift, missing tests caught later.
+- Multiple PRDs for related work in separate dirs → merge into one PRD with multiple FRs if they share users/journey.
+
+## Override / advanced
+
+- `--no-checkpoint` (default mode): skip user-approval gates between stages. Use ONLY for non-interactive automation (CI generating starter specs). Risk: low-quality output goes through unchallenged.
+- `--regenerate <stage>`: rerun only one stage on existing artifacts. Useful when you edit the PRD and want techspec regenerated.
+
+## Final Guidelines
+
+- Each stage has its own clarification question quota — don't recycle. Different stages need different framing.
+- Web search is mandatory; Context7 MCP for libraries. No skipping for "I think I know the latest version."
+- Constitution gate runs at every stage entry; defaults are auto-installed when missing (never blocks).
+- All three stages produce committed Markdown — these are the canonical planning artifacts. They evolve with the feature.
+
+</system_instructions>

package/scaffold/en/commands/dw-qa.md

@@ -0,0 +1,166 @@
+<system_instructions>
+You are the QA orchestrator. Two modes: run QA against the implementation (UI or API), or enter the QA + fix-retest loop until bugs are clear. Both modes apply the same testing-discipline gates.
+
+## When to Use
+- Use after `/dw-run` finishes and the implementation is verified (lint+test+build green via `dw-verify`).
+- Use before `/dw-review` to gather behavioral evidence beyond unit tests.
+- Use after every PRD-significant change to confirm production-equivalent behavior.
+- Do NOT use during active task implementation (use `/dw-run` which has its own Level 1 validation).
+- Do NOT use for unit-test runs (use the project's test command directly).
+
+## Pipeline Position
+**Predecessor:** `/dw-run` (implementation complete) | **Successor:** `/dw-review` then `/dw-commit` + `/dw-generate-pr`
+
+## Modes
+
+| Invocation | What runs |
+|------------|-----------|
+| `/dw-qa` | **Default.** Mode-aware QA pass (UI or API auto-detected). Generates evidence (screenshots/JSONL logs), writes `QA/qa-report.md` + `QA/bugs.md`. Does NOT fix bugs. |
+| `/dw-qa --fix` | QA pass followed by an iterative fix+retest loop. Each detected bug → root-cause → fix → retest with evidence → mark resolved. Continues until all bugs marked Closed or user accepts a deferred list. |
+| `/dw-qa --api` | Forces API-only mode (skips UI even when frontend dependencies are present). Useful for backend-only sub-features in fullstack repos. |
+| `/dw-qa --ai` | Adds AI feature evaluation against the reference dataset at `.dw/eval/datasets/<feature>/`. Computes precision@k / faithfulness / outcome accuracy per the feature type. Logs JSONL to `QA/logs/ai/`. |
+
+## Mode auto-detection
+
+The default `/dw-qa` inspects the project to choose UI vs API:
+
+- **UI mode** if package.json has `playwright`, `next`, `react`, `vue`, or similar frontend dependencies AND a server can be started.
+- **API mode** if no frontend deps are detected OR forced via `--api`.
+- **AI mode** adds on top of UI or API via `--ai` flag — runs alongside the chosen interaction mode.
+
+## Inputs
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `{{PRD_PATH}}` | Path to PRD directory containing tasks (auto-detect from active branch if omitted) | `.dw/spec/prd-invoice-export` |
+| `{{MODE}}` | `--fix` / `--api` / `--ai` (optional; default = auto-detect) | — |
+
+## Complementary Skills
+
+When available under `./.agents/skills/`, these are invoked operationally:
+
+- `dw-testing-discipline`: **(UI mode — ALWAYS)** — core rules and 25 anti-patterns apply to every QA test authored. `references/playwright-recipes.md` for tactical patterns. `references/three-workflow-patterns.md` to pick the right verification mode (UI / network / perf). `references/security-boundary.md` for any flow that crosses an auth boundary.
+- `api-testing-recipes`: **(API mode — ALWAYS)** — validated snippets for `.http`, pytest+httpx, supertest, WebApplicationFactory, reqwest. Composes per-FR test files in `QA/scripts/api/` and JSONL logs in `QA/logs/api/`.
+- `dw-llm-eval`: **(AI mode — when invoked with `--ai`)** — runs reference dataset against current implementation. Computes precision@k / faithfulness / outcome accuracy. Logs JSONL to `QA/logs/ai/<feature>-<date>.jsonl`. Alerts on >10% metric regression vs prior run.
+- `dw-debug-protocol`: **(in `--fix` mode — ALWAYS)** — six-step triage (Reproduce → Localize → Reduce → Fix Root Cause → Guard → Verify End-to-End) for each detected bug. Stop-the-line discipline; root-cause over symptom; regression test in same atomic commit.
+- `vercel-react-best-practices`: (UI mode) when React/Next.js regression risk is suspected.
+- `dw-ui-discipline`: (UI mode) when validating design consistency — anti-slop catalog + WCAG accessibility floor check.
+- `dw-verify`: **(in `--fix` mode — ALWAYS)** — before marking any bug `Fixed` or `Closed`, requires VERIFICATION REPORT PASS (test + lint + build) AND retest evidence (screenshot in UI mode, JSONL log in API mode, eval-run delta in AI mode).
+
+## Output Structure
+
+```
+.dw/spec/<prd>/QA/
+├── qa-report.md                  # Test plan + execution summary
+├── bugs.md                       # Bug catalog with status
+├── scripts/
+│   ├── ui/<RF>-<slug>.spec.ts    # Playwright scripts (UI mode)
+│   ├── api/<RF>-<slug>.http      # API test files
+│   └── ai/<feature>-eval.ts      # AI eval scripts (--ai mode)
+├── evidence/
+│   ├── ui/                       # Screenshots per RF + retests
+│   └── ...
+└── logs/
+    ├── api/<RF>-<slug>.log       # JSONL request/response per call
+    └── ai/<feature>-<date>.jsonl # AI eval results
+```
+
+## Mode 1: Default (`/dw-qa`)
+
+### Behavior — UI mode
+
+1. **Pre-flight**: confirm the project dev server can run. Confirm `.dw/spec/<prd>/` has the PRD + TechSpec + tasks.
+2. **Map FRs to test plan**: for each FR, identify the user-facing flow that exercises it.
+3. **Drive Playwright MCP** (or fallback to local Playwright per `dw-testing-discipline/references/playwright-recipes.md`):
+   - Happy paths for each FR.
+   - Edge cases (boundary inputs, network failure, validation errors).
+   - Negative flows (unauthorized actions, malformed input).
+   - Regressions (smoke check on adjacent surfaces).
+   - WCAG 2.2 accessibility check per `dw-ui-discipline/references/accessibility-floor.md`.
+4. **Capture evidence**: screenshots at 375px mobile + 1440px desktop, console logs, network HARs.
+5. **Detect stub/placeholder pages**: any page that looks "TODO" or has obvious dummy content → flag as a bug.
+6. **Write `qa-report.md`**: test plan, execution log, evidence references, bug count by severity.
+7. **Write `bugs.md`**: one entry per bug found, with severity, repro steps, evidence link, status (`Open`).
+
+### Behavior — API mode
+
+1. **Pre-flight**: confirm API server can run. Confirm OpenAPI spec exists or design from PRD endpoints.
+2. **Compose test files per FR** via `api-testing-recipes`:
+   - Detect stack (TS/Python/C#/Rust) → pick the matching recipe.
+   - Generate `.http` file or pytest+httpx / supertest / WebApplicationFactory / reqwest script.
+   - Test matrix per FR: {200 happy / 4xx validation / 4xx auth / 4xx authz / 4xx not-found / 4xx conflict / 5xx / contract drift / cross-tenant denial}.
+3. **Optional `--from-openapi`**: derive baseline from project's OpenAPI spec.
+4. **Execute scripts**: run each test; capture JSONL request/response to `QA/logs/api/<RF>-<slug>.log`.
+5. **Detect unmapped endpoints**: endpoints in spec that no test exercises → flag.
+6. **Write `qa-report.md` + `bugs.md`** with API-mode evidence.
+
+### Behavior — AI mode (additive via `--ai`)
+
+1. Locate `.dw/eval/datasets/<feature>/cases.jsonl`. If missing → STOP and ask user to define the dataset via `dw-llm-eval`.
+2. Run the dataset against the current implementation per the feature type:
+   - RAG: precision@k + faithfulness + context utilization.
+   - Agent: outcome assertion + trajectory match (per `--ai-mode` parameter or feature config).
+   - Classification: exact match accuracy.
+3. Log JSONL to `QA/logs/ai/<feature>-<date>.jsonl`.
+4. Compare to prior run's JSONL — alert on >10% regression in any metric.
+5. Append AI-mode section to `qa-report.md`.
+
+## Mode 2: Fix loop (`/dw-qa --fix`)
+
+### Behavior
+
+After the default QA pass produces `bugs.md`, enter an iterative loop:
+
+1. **For each Open bug, in severity order (critical → high → medium → low):**
+   - Apply `dw-debug-protocol` six-step triage.
+   - Reproduce → Localize → Reduce → Fix → Guard (regression test) → Verify E2E.
+   - Implementation lives in the appropriate task's file; commit message references the bug ID.
+   - `dw-verify` runs before commit (test + lint + build PASS required).
+2. **Retest** with mode-aware evidence:
+   - UI mode: re-run the Playwright flow; capture retest screenshot to `QA/evidence/ui/`.
+   - API mode: re-run the `.http`/recipe script; append `verdict: PASS|FAIL` JSONL line to `QA/logs/api/BUG-NN-retest.log`.
+   - AI mode: re-run the eval dataset; verify metric is back in range.
+3. **Update `bugs.md`** with status: `Fixed` (retest PASS + verify PASS) or `Reopened` (retest FAIL).
+4. **Continue until `bugs.md` shows all bugs `Fixed` OR `Closed`** OR user accepts a deferred list of remaining bugs.
+
+## Constitution + verification gates
+
+<critical>
+- `dw-verify` PASS required before any bug status flips to `Fixed`/`Closed`.
+- Constitution principles with `severity: high/critical` apply: if a fix violates an existing principle without an ADR, the fix is REJECTED and the bug returns to `Open`.
+- For `--ai` mode: a metric regression > 20% blocks the QA verdict until the regression is investigated (don't just lower the bar).
+</critical>
+
+## Reporting
+
+`qa-report.md` final section:
+
+```markdown
+## Verdict
+
+- Mode(s): UI / API / AI
+- FRs tested: N / M
+- Bugs found: critical X | high X | medium X | low X
+- Bugs fixed (in --fix mode): N / M
+- Bugs Open: N (deferred per user)
+- Verify status: PASS / FAIL
+- Constitution compliance: PASS / VIOLATIONS LISTED
+- Final QA verdict: APPROVED / APPROVED WITH DEFERRED BUGS / REJECTED
+```
+
+## Anti-patterns
+
+- Skipping evidence capture because "the test passed visually" — without screenshots/logs, retest later is guesswork.
+- Marking bugs `Fixed` without re-running the QA flow that originally caught them.
+- Lowering the bar in `--ai` mode when metrics regress — investigate, don't accept silent quality drop.
+- Auto-retrying flaky tests until green — applies `dw-testing-discipline/flaky-discipline.md` quarantine instead.
+- Running `/dw-qa --fix` without `/dw-qa` first — produces fixes for bugs that weren't reproduced cleanly.
+
+## Final Guidelines
+
+- QA is mode-aware. Trust the auto-detection; override only when explicitly needed (`--api`, `--ai`).
+- Evidence is non-negotiable: screenshots, JSONL logs, or eval-run deltas per mode.
+- `--fix` mode is the loop. Run it as many cycles as needed until bugs.md is clean.
+- Reference datasets for `--ai` mode evolve with the feature — add cases from real failures observed during QA.
+
+</system_instructions>

package/scaffold/en/commands/dw-redesign-ui.md

@@ -3,19 +3,19 @@ You are a frontend redesign specialist for the current workspace. This command e
 
 <critical>Do NOT redesign without first auditing the current implementation. Always read the code and capture the visual state before proposing changes.</critical>
 <critical>ALWAYS propose design directions and wait for user approval before implementing any changes.</critical>
-<critical>Preserve existing functionality. Redesign is visual/UX, not behavioral. If the change alters behavior, redirect to `/dw-create-prd`.</critical>
+<critical>Preserve existing functionality. Redesign is visual/UX, not behavioral. If the change alters behavior, redirect to `/dw-plan prd`.</critical>
 <critical>MOBILE FIRST is MANDATORY. Every design proposal MUST include both mobile AND desktop versions. Implementation MUST start with mobile and then adapt for desktop. Do NOT present only the desktop layout — if the proposal does not show how it looks on mobile, it is incomplete.</critical>
 
 ## When to Use
 - Use for rebuild/modernization of existing pages or components
 - Use for design refresh, design system migration, or style overhaul
-- Do NOT use for new features (use `/dw-create-prd`)
+- Do NOT use for new features (use `/dw-plan prd`)
 - Do NOT use for bug fixes (use `/dw-bugfix`)
 - Do NOT use for open-ended idea exploration (use `/dw-brainstorm`)
 
 ## Pipeline Position
 **Predecessor:** `/dw-brainstorm` (optional) | `/dw-analyze-project` (recommended)
-**Successor:** `/dw-run-qa` | `/dw-code-review`
+**Successor:** `/dw-qa` | `/dw-review --code-only`
 
 ## Decision Flowchart
 
@@ -27,7 +27,7 @@ digraph redesign_decision {
   Q2 [label="Is there a specific\ntarget page or component?"];
   node [shape=box];
   REDESIGN [label="Use\n/dw-redesign-ui"];
-  PRD [label="Use\n/dw-create-prd"];
+  PRD [label="Use\n/dw-plan prd"];
   BRAINSTORM [label="Start with\n/dw-brainstorm"];
   Q1 -> PRD [label="No (changes behavior)"];
   Q1 -> Q2 [label="Yes"];
@@ -69,7 +69,7 @@ Use diagnostic tools based on the project's framework:
 <critical>If `.dw/intel/` exists, querying it via `/dw-intel` is MANDATORY in the audit phase to surface existing UI patterns.</critical>
 
 - Audit phase: internally run `/dw-intel "UI components, design patterns, layout conventions"` before proposing redesign directions
-- The design contract (`.dw/spec/prd-[name]/design-contract.md`) is the single source of truth for visual consistency — it's read by `/dw-run-task` and `/dw-run-plan` and persists across sessions naturally (no separate registration needed)
+- The design contract (`.dw/spec/prd-[name]/design-contract.md`) is the single source of truth for visual consistency — it's read by `/dw-run` and `/dw-run` and persists across sessions naturally (no separate registration needed)
 - If `.dw/intel/` does NOT exist, fall back to `.dw/rules/` and direct grep over `apps/web/src/` (or equivalent frontend root)
 
 ## Preferred Response Format
@@ -124,6 +124,6 @@ Depending on the request, this command may produce:
 At the end, always leave the user in one of these situations:
 - With a completed redesign + validation evidence
 - With a design proposal awaiting approval
-- With a next workspace command to follow (`/dw-run-qa`, `/dw-code-review`, `/dw-commit`)
+- With a next workspace command to follow (`/dw-qa`, `/dw-review --code-only`, `/dw-commit`)
 
 </system_instructions>

package/scaffold/en/commands/dw-review.md

@@ -0,0 +1,198 @@
+<system_instructions>
+You are the review orchestrator. Runs both Level 2 (PRD compliance / coverage) and Level 3 (code quality / security / conventions) reviews in sequence. Default runs both; flags allow either alone. This was previously two separate commands (review-implementation + code-review) that chained automatically in v0.10 — now consolidated for clarity.
+
+## When to Use
+- Use after `/dw-run` completes a task or plan, BEFORE `/dw-commit` + `/dw-generate-pr`.
+- Use to audit existing implementation against PRD.
+- Use in CI as a quality gate.
+- Do NOT use during active development (use directly with the linter/test runner).
+- Do NOT use on partial work (review-implementation needs the implementation to actually exist).
+
+## Pipeline Position
+**Predecessor:** `/dw-run` | **Successor:** `/dw-commit` + `/dw-generate-pr`
+
+## Modes
+
+| Invocation | What runs |
+|------------|-----------|
+| `/dw-review` | **Default.** Level 2 (PRD coverage) + Level 3 (code quality) in sequence. Consolidated report saved to `.dw/spec/<prd>/QA/review-consolidated.md`. |
+| `/dw-review --coverage-only` | Only Level 2 — maps every PRD requirement to the code that delivers it. Skips code quality. |
+| `/dw-review --code-only` | Only Level 3 — code quality / convention / security checks. Skips PRD mapping. |
+
+## Inputs
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `{{PRD_PATH}}` | Path to PRD directory (auto-detect from active branch if omitted) | `.dw/spec/prd-invoice-export` |
+| `{{MODE}}` | `--coverage-only` / `--code-only` (optional; default = both) | — |
+
+## Complementary Skills
+
+When available under `./.agents/skills/`, these are invoked as analytical support:
+
+- `dw-review-rigor`: **ALWAYS** — applies de-duplication (same pattern in N files = 1 finding), severity ordering (critical → high → medium → low), verify-before-flag, skip-what-linter-catches, and signal-over-volume. The "Issues Found" table follows this discipline.
+- `dw-verify`: **ALWAYS** — invoked before emitting `APPROVED` or `APPROVED WITH CAVEATS`. Without a VERIFICATION REPORT PASS (test + lint + build), verdict cannot be APPROVED.
+- `dw-secure-audit`: **ALWAYS for TS/Python/C#/Rust projects** — security gate. If the project uses a supported language and a recent `secure-audit.md` is missing OR has REJECTED status, the verdict is **REJECTED** — no exception.
+- `dw-simplification`: use when the diff touches dense or twisty code — applies Chesterton's Fence, behavior-preserving refactor protocol, complexity metrics.
+- `dw-ui-discipline`: use when the diff touches UI — runs the 14 visual-slop patterns + accessibility floor checks.
+- `dw-testing-discipline`: use when the diff touches tests — applies the 25 anti-patterns catalog + 6 agent guardrails (when tests were agent-authored).
+- `dw-llm-eval`: **REQUIRED when the diff touches AI/LLM feature code paths**. Reference dataset + ≥2 oracle rungs + judge calibration (if rung 4 used) + eval run results MUST be in the PR. Missing → REJECTED.
+- `security-review`: use when the diff touches auth, authorization, external input, upload, SQL, secrets, SSRF, XSS, or sensitive surfaces.
+- `vercel-react-best-practices`: use when the diff touches React/Next.js.
+
+## Constitution Gate
+
+<critical>BEFORE the review starts, check `.dw/constitution.md`. If MISSING, auto-install defaults. If PRESENT, every principle is checked against the diff. Severity-graded enforcement:
+- `severity: info` violations → reported, no block.
+- `severity: high` / `critical` violations without ADR justifying → **REJECTED**.</critical>
+
+## Codebase Intelligence
+
+<critical>If `.dw/intel/` exists, query via `/dw-intel` before reviewing.</critical>
+- `/dw-intel "documented conventions and anti-patterns"` before Level 3 to prioritize findings that violate documented patterns.
+- `/dw-intel "tech debt and known technical decisions"` to distinguish intentional architecture from drift.
+
+## Level 2 — PRD coverage mapping (runs unless `--code-only`)
+
+**Goal:** every documented requirement (FR / TechSpec section / Task) maps to specific code that delivers it.
+
+### Behavior
+
+1. **Load artifacts:**
+   - `.dw/spec/<prd>/prd.md` → extract functional requirements.
+   - `.dw/spec/<prd>/techspec.md` → extract architectural decisions.
+   - `.dw/spec/<prd>/tasks.md` + per-task files → extract committed work.
+   - `tasks-validation.md` → carry forward dimension status.
+
+2. **Map each FR to code:**
+   - For each `FR-N.M`, find code that delivers it (file path + line range + commit SHA).
+   - For each TechSpec section, find code that implements it.
+   - For each task, verify the FRs it claimed to cover are actually delivered.
+
+3. **Identify gaps:**
+   - Orphan FRs: declared in PRD but no code implements them.
+   - Orphan code: code changes not traceable to any FR/task (scope creep).
+   - Incomplete implementations: FR partially delivered (e.g., happy path only).
+
+4. **Compare against acceptance criteria** from per-task files. Run actual smoke checks where feasible.
+
+### Output
+
+Saved to `.dw/spec/<prd>/QA/review-coverage.md`:
+
+```markdown
+# Coverage Review
+
+## Status by Functional Requirement
+
+| FR | Description | Status | Evidence | Commit |
+|----|-------------|--------|----------|--------|
+| FR-1.1 | User can export PDF | DELIVERED | src/pdf/export.ts:42-80 | abc123 |
+| FR-1.2 | Export shows progress | PARTIAL | UI exists, no E2E test | def456 |
+| FR-2.1 | Email notification on completion | MISSING | (no code found) | — |
+
+## Orphan Code (not traceable to any FR)
+- src/utils/cache.ts (new file, no FR reference)
+
+## Verdict
+- DELIVERED: N FRs (X%)
+- PARTIAL: N FRs (X%)
+- MISSING: N FRs (X%)
+- Orphan code: N files
+```
+
+If MISSING > 0, the verdict suggests revisiting `/dw-plan tasks` to scope or `/dw-run` to add the missing implementations.
+
+## Level 3 — Code quality + conventions + security (runs unless `--coverage-only`)
+
+**Goal:** the code that exists meets quality, conventions, security, and constitution standards.
+
+### Behavior
+
+1. **Diff analysis:** identify what changed since the PRD branch was created (`git diff <base-branch>...HEAD`).
+
+2. **Rules conformance** (against `.dw/rules/`):
+   - General patterns: no `any` types in TS, no `console.log` in prod, error handling, multi-tenancy.
+   - Backend patterns from `.dw/rules/<backend>.md`: Clean Architecture, use-case return types, DTOs, parameterized queries.
+   - Frontend patterns from `.dw/rules/<frontend>.md`: Server Components default, forms patterns, design system.
+
+3. **Constitution compliance** (against `.dw/constitution.md`):
+   - For each principle, check diff for violations per the principle's Enforcement line.
+   - Severity-graded: info → low, high → critical+REJECTED-unless-ADR, critical → critical+REJECTED-unless-ADR-with-approval.
+
+4. **Code quality** (via `dw-review-rigor` discipline):
+   - SOLID violations.
+   - Cyclomatic / cognitive complexity (with `dw-simplification` thresholds).
+   - DRY violations (only when impact is meaningful — not premature deduplication).
+   - Code smells (Fowler taxonomy).
+
+5. **Test execution:**
+   - Run the project's test command.
+   - Verify coverage targets per TechSpec (80% services, 70% controllers).
+
+6. **Apply `dw-review-rigor`:**
+   - De-duplicate findings.
+   - Sort by severity.
+   - Verify intent before flagging (the linter already catches some — those don't repeat).
+
+7. **Final verification (`dw-verify`):**
+   - Run dw-verify to produce a VERIFICATION REPORT (test + lint + build all GREEN).
+   - Without PASS, verdict cannot be APPROVED.
+
+8. **Security Layer (`dw-secure-audit` for TS/Python/C#/Rust):**
+   - Run `/dw-secure-audit` against the PR. Latest scan must be present and not REJECTED.
+   - If language is supported and audit is missing OR REJECTED → verdict **REJECTED**.
+
+### Output
+
+Saved to `.dw/spec/<prd>/QA/dw-review --code-only.md`. The verdict line is one of:
+- **APPROVED** — all gates green; ready for commit + PR.
+- **APPROVED WITH CAVEATS** — green but findings worth fixing in follow-up (filed with severities).
+- **REJECTED** — at least one hard gate failed. Specify which.
+
+## Consolidated output (default mode)
+
+When both levels run, a consolidated report at `.dw/spec/<prd>/QA/review-consolidated.md`:
+
+```markdown
+# Consolidated Review
+
+**Level 2 (Coverage):** DELIVERED N | PARTIAL N | MISSING N
+**Level 3 (Quality):** APPROVED | APPROVED WITH CAVEATS | REJECTED
+**Verification Report:** PASS
+**Security Audit:** PASS (or REJECTED with reasons)
+**Constitution Compliance:** PASS (or violations listed)
+
+## Overall Verdict
+<line>
+
+## Findings Summary
+| Severity | Count | Reports |
+|----------|-------|---------|
+| critical | N | review-coverage.md, dw-code-review.md |
+| high | N | dw-code-review.md |
+| medium | N | dw-code-review.md |
+| low | N | review-coverage.md, dw-code-review.md |
+
+## Next Steps
+- If APPROVED: proceed to `/dw-commit` + `/dw-generate-pr`.
+- If REJECTED: fix the blocking findings, re-run `/dw-review`.
+- If gaps in coverage: revisit `/dw-plan tasks --update` or `/dw-run <missing-task>`.
+```
+
+## Anti-patterns
+
+- Skipping `dw-verify` to "ship the review faster" — produces APPROVED verdicts on broken code.
+- Issuing APPROVED with KNOWN critical findings deferred to "next sprint" — that's REJECTED with a workaround plan.
+- Flagging linter-level findings as review findings (duplicates the linter; noise).
+- Suggesting refactors that aren't in scope of the PRD (use `/dw-brainstorm --refactor` separately if you want a refactor agenda).
+- Generating the report without actually running the test/build/lint suite — verdict is decorative without evidence.
+
+## Final Guidelines
+
+- Both levels run by default unless flags specify otherwise. Most PRs need both.
+- The consolidated verdict is the single number to trust. Individual level reports drill down.
+- Findings are signal, not volume. `dw-review-rigor` enforces this.
+- Hard gates (verify, secure-audit, constitution high+critical) are non-negotiable. ADR is the only escape.
+
+</system_instructions>