@brunosps00/dev-workflow 0.8.0 → 0.9.0

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

@@ -0,0 +1,144 @@
+<system_instructions>
+You are a plan verification orchestrator. Your job is to spawn the `dw-plan-checker` agent (from the `dw-execute-phase` bundled skill) to verify that a phase's `tasks.md` will achieve the PRD goal — BEFORE any code is touched.
+
+This is a standalone manual gate. `/dw-execute-phase` and `/dw-autopilot` invoke the same agent automatically; this command lets you run just the gate to inspect the plan quality without committing to execution.
+
+<critical>This command is read-only. Plan-checker NEVER modifies files.</critical>
+<critical>Output one of three verdicts: PASS, REVISE, BLOCK. No middle ground.</critical>
+
+## When to Use
+
+- Before invoking `/dw-execute-phase` if you want to inspect the plan quality first
+- After a partial execution to verify remaining tasks still make sense
+- After manual edits to `tasks.md` (always re-verify before re-executing)
+- During `/dw-create-tasks` revisions to confirm the planner addressed prior REVISE issues
+- NOT for verifying implementation correctness (use `/dw-run-qa`)
+- NOT for code-quality review (use `/dw-code-review`)
+
+## Pipeline Position
+
+**Predecessor:** `/dw-create-tasks` (or manual edits to `tasks.md`) | **Successor:** `/dw-execute-phase` if PASS; `/dw-create-tasks --revise` if REVISE; manual intervention if BLOCK
+
+## Complementary Skills
+
+| Skill | Trigger |
+|-------|---------|
+| `dw-execute-phase` | **ALWAYS** — source of `dw-plan-checker` agent and `references/plan-verification.md` |
+| `dw-codebase-intel` | Optional — agent reads `.dw/intel/` to verify plan against actual codebase facts |
+
+## Input Variables
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `{{PRD_PATH}}` | Path to the PRD folder containing `tasks.md` | `.dw/spec/prd-checkout-v2` |
+
+## File Locations
+
+- Inputs (read-only): `{{PRD_PATH}}/{prd.md, techspec.md, tasks.md, <NN>_task.md}`, `.dw/rules/*.md`, `.dw/intel/*` (if exists), `./CLAUDE.md`
+- Audit log (append-only): `.dw/audit/plan-checks-<YYYY-MM-DD>.log` (records each verdict for `--skip-check` audit trail)
+
+## Required Behavior
+
+### 1. Load context
+
+Verify the PRD path exists and contains `tasks.md`. Read `prd.md`, `techspec.md`, `tasks.md`, and any `<NN>_task.md` files referenced.
+
+### 2. Spawn the agent
+
+Spawn `dw-plan-checker` agent with:
+
+- `prd_path: {{PRD_PATH}}`
+- `required_reading:` block citing `.agents/skills/dw-execute-phase/SKILL.md` and `.agents/skills/dw-execute-phase/references/plan-verification.md`
+
+The agent runs the 6-dimension verification:
+
+1. **Requirement Coverage** — every RF-XX has a task
+2. **Task Completeness** — files / action / verification / done present
+3. **Dependency Soundness** — no cycles, no broken refs, waves ≤ 8 wide
+4. **Artifact Wiring** — every produced artifact is consumed downstream or referenced in PRD
+5. **Context Budget** — ≤ 12 tasks, ≤ 30 aggregate files
+6. **Constraint Compliance** — no violations of `.dw/rules/`, CONTEXT.md `## Decisions`, CLAUDE.md
+
+### 3. Process verdict
+
+**PASS:**
+
+- Append to `.dw/audit/plan-checks-<YYYY-MM-DD>.log`:
+  ```
+  <ISO-8601>  PASS  {{PRD_PATH}}  <task_count> tasks, <wave_count> waves
+  ```
+- Print: `Plan verification PASS — proceed to /dw-execute-phase {{PRD_PATH}}`
+
+**REVISE:**
+
+- Append to audit log with `REVISE` verdict
+- Print the issues per dimension
+- Suggest: `/dw-create-tasks --revise --issues <generated-issues-file>` OR manual edits
+- Exit status: `PLAN-CHECK-REVISE`
+
+**BLOCK:**
+
+- Append to audit log with `BLOCK` verdict
+- Print the conflicting issues with file:line
+- Suggest: resolve the locked-decision conflict (update CONTEXT.md, OR change the plan to honor it)
+- Exit status: `PLAN-CHECK-BLOCK`
+
+### 4. Output format
+
+```markdown
+# Plan Verification — <prd-slug>
+
+**Verdict:** PASS | REVISE | BLOCK
+**PRD:** {{PRD_PATH}}
+**Tasks file:** {{PRD_PATH}}/tasks.md (<N> tasks across <M> waves)
+**Verified at:** <ISO-8601>
+
+## Dimensions
+
+| # | Dimension | Status | Issues |
+|---|-----------|--------|--------|
+| 1 | Requirement Coverage | ✓ / ✗ | <count> |
+| 2 | Task Completeness | ✓ / ✗ | <count> |
+| 3 | Dependency Soundness | ✓ / ✗ | <count> |
+| 4 | Artifact Wiring | ✓ / ✗ | <count> |
+| 5 | Context Budget | ✓ / ✗ | <count> |
+| 6 | Constraint Compliance | ✓ / ✗ | <count> |
+
+## Issues (REVISE/BLOCK only)
+
+[detailed issues per dimension; cite file:line]
+
+## Recommendation
+
+- PASS → `/dw-execute-phase {{PRD_PATH}}`
+- REVISE → `/dw-create-tasks --revise` and re-run this command
+- BLOCK → resolve [list of locked-decision conflicts] then re-plan
+```
+
+## Critical Rules
+
+- <critical>The agent owns verification logic. NEVER inline checks in this command.</critical>
+- <critical>Read-only. Plan-checker MUST NOT modify any file in the project.</critical>
+- <critical>Audit log is append-only. NEVER edit prior entries.</critical>
+- <critical>BLOCK is reserved for hard conflicts (locked decisions, cycles). REVISE is for fixable issues.</critical>
+- Do NOT auto-trigger `/dw-create-tasks` on REVISE. The user decides whether to re-run.
+
+## Error Handling
+
+- `tasks.md` missing → exit `PLAN-CHECK-FAILED` with hint: "Run `/dw-create-tasks {{PRD_PATH}}` first"
+- `prd.md` missing → exit `PLAN-CHECK-FAILED`: "PRD not found; is the path correct?"
+- Agent times out (>5 min) → exit `PLAN-CHECK-TIMEOUT`: "Plan too large; consider splitting via `/dw-create-tasks --split`"
+- Cycle detected in dependencies → BLOCK with the cycle path; do NOT attempt to break it automatically
+
+## Integration With Other dw-* Commands
+
+- **`/dw-create-tasks`** — predecessor; produces the `tasks.md` this command verifies
+- **`/dw-execute-phase`** — wraps this command as a gate before execution
+- **`/dw-autopilot`** — wraps `/dw-create-tasks` → this command → `/dw-execute-phase` with hard gates between
+- **`/dw-resume`** — when resuming after a checkpoint, this command verifies the remaining tasks still satisfy the goal
+
+## Inspired by
+
+`dw-plan-checker` is dev-workflow-native. The 6-dimension goal-backward verification protocol is adapted from [`get-shit-done-cc`](https://github.com/gsd-build/get-shit-done) (`/gsd-plan-phase`, `gsd-plan-checker`) by gsd-build (MIT license). dev-workflow specifics: verifies `tasks.md` (not GSD's PLAN.md), uses dev-workflow's PRD/TechSpec/Tasks vocabulary, audit log for `--skip-check` trail.
+
+</system_instructions>

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

@@ -38,26 +38,44 @@ You are a quick task executor. This command exists to implement one-off changes
 8. Invoke `dw-verify` and include the VERIFICATION REPORT in the output before committing. Without PASS, DO NOT commit.
 9. Create atomic semantic commit with the change
 
-## GSD Integration
+## Task Tracking
 
-<critical>When GSD is installed, delegation to /gsd-quick is MANDATORY for tracking.</critical>
+<critical>Every `/dw-quick` execution writes a tracking entry to `.dw/spec/quick/<slug>.md` so the change is discoverable later.</critical>
 
-If GSD (get-shit-done-cc) is installed in the project:
-- Delegate to `/gsd-quick` for tracking in `.planning/quick/`
-- The task is registered in history for future lookup via `/dw-intel`
+Tracking format (single file per quick task):
 
-If GSD is NOT installed:
-- Execute directly with Level 1 validation
-- No history tracking (only git log)
+```markdown
+---
+type: quick-task
+schema_version: "1.0"
+status: COMPLETE | PARTIAL | ABORTED
+date: YYYY-MM-DD
+files_touched: [...]
+commit: <SHA>
+---
+
+# Quick Task — <slug>
+
+## Description
+<one-line description from the user's prompt>
+
+## Files
+<list>
+
+## Verification
+<dw-verify report excerpt>
+```
+
+Subsequent `/dw-intel` queries surface these via the file index.
 
 ## Codebase Intelligence
 
-If `.planning/intel/` exists, query before implementing:
-- Internally run: `/gsd-intel "implementation patterns in [target area]"`
+If `.dw/intel/` exists, query before implementing:
+- Internally run: `/dw-intel "implementation patterns in [target area]"`
 - Follow the patterns found
 
-If `.planning/intel/` does NOT exist:
-- Use only `.dw/rules/` as context
+If `.dw/intel/` does NOT exist:
+- Use only `.dw/rules/` as context (or grep directly if `.dw/rules/` is also absent)
 
 ## Response Format
 

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

@@ -64,17 +64,13 @@ Use diagnostic tools based on the project's framework:
 7. **VALIDATE**: capture after-state in BOTH resolutions (mobile and desktop), compare before/after, verify accessibility (WCAG 2.2 via `ui-ux-pro-max`), run react-doctor `--diff` if React. If `webapp-testing` is available, capture screenshots at 375px viewport (mobile) and 1440px viewport (desktop).
 8. **PERSIST CONTRACT**: if the user approved a direction, generate `design-contract.md` in the PRD directory (`.dw/spec/prd-[name]/design-contract.md`) with: approved direction, color palette, typography pairing, layout rules, accessibility rules, and component rules. This contract will be read by `dw-run-task` and `dw-run-plan` to ensure visual consistency.
 
-## GSD Integration
+## Codebase Intelligence
 
-<critical>When GSD is installed, registering the design contract in .planning/ and querying .planning/intel/ are MANDATORY.</critical>
+<critical>If `.dw/intel/` exists, querying it via `/dw-intel` is MANDATORY in the audit phase to surface existing UI patterns.</critical>
 
-If GSD (get-shit-done-cc) is installed in the project:
-- After generating the design contract, register in `.planning/` for cross-session persistence
-- Query `.planning/intel/` in the audit phase for existing UI patterns
-
-If GSD is NOT installed:
-- The design contract works normally (file-based in `.dw/spec/`)
-- Audit uses only `.dw/rules/` for context
+- 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)
+- 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
 

package/scaffold/en/commands/dw-refactoring-analysis.md

@@ -31,13 +31,14 @@ For Angular projects, use `ng lint` as an analytical complement.
 
 ## Codebase Intelligence
 
-<critical>If `.planning/intel/` exists, querying it is MANDATORY before writing requirements. Do NOT skip this step.</critical>
-- Internally run: `/gsd-intel "tech debt, decision spaces, and known technical debt"`
-- Contextualize findings with already documented decisions
+<critical>If `.dw/intel/` exists, querying it via `/dw-intel` is MANDATORY before flagging refactoring opportunities. Do NOT skip this step.</critical>
+- Internally run: `/dw-intel "tech debt and known technical decisions"`
+- Contextualize findings with documented decisions in `.dw/rules/`
 - Avoid flagging as a smell something that is an intentional recorded decision
 
-If `.planning/intel/` does NOT exist:
-- Use `.dw/rules/` as context (current behavior)
+If `.dw/intel/` does NOT exist:
+- Use `.dw/rules/` as context, falling back to grep
+- Suggest running `/dw-map-codebase` to enrich downstream context
 
 ## Input Variables
 

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

@@ -40,17 +40,19 @@ You are a session continuity assistant. This command exists to restore context f
 6. Present the summary in the format below (including a "From where we left off" bullet list based on memory)
 7. Suggest the next command to execute
 
-## GSD Integration
+## Cross-Session State
 
-<critical>When GSD is installed, delegation to /gsd-resume-work is MANDATORY, not optional.</critical>
+<critical>If `.dw/spec/active-session.md` exists (written by `/dw-execute-phase` at checkpoint), reading it is MANDATORY to restore the last-known position.</critical>
 
-If GSD (get-shit-done-cc) is installed in the project:
-- Delegate to `/gsd-resume-work` for cross-session state restoration from `.planning/STATE.md`
-- Incorporate additional context: persistent threads, backlog, notes
+Read order for cross-session context:
 
-If GSD is NOT installed:
-- Use only `.dw/spec/` and git log as context sources
-- Full functionality, just without advanced cross-session persistence
+1. `.dw/spec/active-session.md` — last completed task, next task, blockers, open deviations (written by `/dw-execute-phase` when it checkpoints at 70% context budget OR when the user signals stop)
+2. `.dw/spec/prd-*/SUMMARY.md` — completed phase summaries (most recent ones)
+3. Latest commits via `git log --oneline -20` — what landed on the current branch
+4. Open deviations via `.dw/spec/prd-*/deviations.md` — any unresolved Rule 1/2/3 entries
+5. Active PRD detection — the directory under `.dw/spec/` whose `tasks.md` has the most recent uncompleted task
+
+If `.dw/spec/active-session.md` is absent (no checkpoint was written; clean session boundary), fall back to git log + `tasks.md` state across active PRDs.
 
 ## Response Format
 

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

@@ -159,36 +159,30 @@ If a task FAILS during execution:
 4. Wait for manual intervention from the user
 5. **DO NOT** automatically continue to the next task
 
-## GSD Integration
+## Plan Verification + Parallel Execution
 
-<critical>When GSD is installed, plan verification and parallel execution are MANDATORY, not optional. The command MUST NOT skip these steps.</critical>
+<critical>Plan verification and wave-based parallel execution are MANDATORY, not optional. Both are now native to dev-workflow via the `dw-execute-phase` bundled skill.</critical>
 
 ### Plan Verification (Pre-Execution)
 
-If GSD (get-shit-done-cc) is installed in the project:
-- Before starting execution, delegate to GSD's plan-checker agent
-- The verifier analyzes: cyclic dependencies, task viability, risks, PRD requirements coverage
-- If FAIL: present issues found and suggest fixes. Maximum 3 correction cycles
+Before starting execution, delegate to `/dw-plan-checker {{PRD_PATH}}`:
+- The plan-checker agent verifies the 6 dimensions (requirement coverage, task completeness, dependency soundness, artifact wiring, context budget, constraint compliance)
+- If REVISE: present issues found and suggest fixes. Maximum 3 correction cycles via `/dw-create-tasks --revise`
+- If BLOCK: surface conflict to user, do NOT auto-replan
 - If PASS: proceed to execution
 
-If GSD is NOT installed:
-- Skip verification and execute directly (current behavior)
-
 ### Parallel Execution (Wave-Based)
 
-If GSD (get-shit-done-cc) is installed in the project:
-- Analyze each task's `blockedBy` field to build the dependency graph
-- Group tasks into waves:
-  - Wave 1: tasks with no dependencies (can run in parallel)
+After plan-checker PASS, delegate to `/dw-execute-phase {{PRD_PATH}}`:
+- The executor agent analyzes each task's `Depends on:` field to build the dependency graph
+- Groups tasks into waves:
+  - Wave 1: tasks with no dependencies (run in parallel)
   - Wave 2: tasks that depend on Wave 1 tasks
   - Wave N: and so on
-- Delegate each wave to GSD's parallel execution engine (`/gsd-execute-phase`)
-- Each task runs in an isolated worktree with fresh context
-- Results are merged after the wave completes
-- If any task in a wave fails: pause the wave, report, await user decision
-
-If GSD is NOT installed:
-- Execute sequentially as today (current behavior)
+- Each wave dispatches subagents in parallel (one per task)
+- Results merged after the wave completes
+- If any task in a wave fails permanently (Rule 3 deviation): pause the wave, report, await user decision
+- The executor commits atomically per task and writes `SUMMARY.md` after the final wave
 
 ### Design Contracts
 

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

@@ -9,7 +9,7 @@ You are an AI assistant specialized in Quality Assurance. Your task is to valida
 ## Pipeline Position
 **Predecessor:** `/dw-run-plan` or `/dw-run-task` | **Successor:** `/dw-code-review` (auto-fixes bugs internally before completing)
 
-<critical>Use the Playwright MCP to execute all E2E tests</critical>
+<critical>In UI mode, use the Playwright MCP for all E2E tests. In API mode (no UI in the project, OR `--api` flag), use the bundled `api-testing-recipes` skill to generate `.http` / pytest+httpx / supertest / WebApplicationFactory / reqwest scripts and capture request/response logs as evidence.</critical>
 <critical>Verify ALL requirements from the PRD and TechSpec before approving</critical>
 <critical>QA is NOT complete until ALL checks pass</critical>
 <critical>Document ALL bugs found with screenshot evidence</critical>
@@ -20,9 +20,10 @@ You are an AI assistant specialized in Quality Assurance. Your task is to valida
 
 When available in the project under `./.agents/skills/`, use these skills as operational support without replacing this command:
 
-- `webapp-testing`: support for structuring test flows, retests, screenshots, and logs when complementary to Playwright MCP
-- `vercel-react-best-practices`: use only if the frontend under test is React/Next.js and there is indication of regression related to rendering, fetching, hydration, or perceived performance
-- `ui-ux-pro-max`: use when validating design consistency, color palettes, typography, spacing, and visual hierarchy against industry standards
+- `webapp-testing`: (UI mode) support for structuring test flows, retests, screenshots, and logs when complementary to Playwright MCP
+- `vercel-react-best-practices`: (UI mode) use only if the frontend under test is React/Next.js and there is indication of regression related to rendering, fetching, hydration, or perceived performance
+- `ui-ux-pro-max`: (UI mode) use when validating design consistency, color palettes, typography, spacing, and visual hierarchy against industry standards
+- `api-testing-recipes`: **(API mode — ALWAYS)** validated snippets for `.http`, pytest+httpx, supertest, WebApplicationFactory, reqwest. Composes per-RF test files in `QA/scripts/api/` and JSONL logs in `QA/logs/api/` per its references
 
 ## Analysis Tools
 
@@ -38,12 +39,13 @@ When available in the project under `./.agents/skills/`, use these skills as ope
 ## Objectives
 
 1. Validate implementation against PRD, TechSpec, and Tasks
-2. Execute E2E tests with Playwright MCP
-3. Cover positive, negative, boundary, and relevant regression scenarios
-4. Verify accessibility (WCAG 2.2)
-5. Perform visual checks
-6. Document bugs found
-7. Generate final QA report
+2. **Detect mode** (UI vs API-only) and pick the right execution path
+3. Execute E2E tests via Playwright MCP (UI mode) OR via the `api-testing-recipes` skill (API mode)
+4. Cover positive, negative, boundary, and relevant regression scenarios
+5. Verify accessibility (UI mode = WCAG 2.2; API mode = error-shape and surface contracts)
+6. Perform visual checks (UI mode only — skipped in API mode)
+7. Document bugs found
+8. Generate final QA report
 
 ## File Locations
 
@@ -56,10 +58,13 @@ When available in the project under `./.agents/skills/`, use these skills as ope
 - Evidence folder (required): `{{PRD_PATH}}/QA/`
 - Output Report: `{{PRD_PATH}}/QA/qa-report.md`
 - Bugs found: `{{PRD_PATH}}/QA/bugs.md`
-- Screenshots: `{{PRD_PATH}}/QA/screenshots/`
-- Logs (console/network): `{{PRD_PATH}}/QA/logs/`
-- Playwright test scripts: `{{PRD_PATH}}/QA/scripts/`
+- Screenshots (UI mode): `{{PRD_PATH}}/QA/screenshots/`
+- Logs — UI (console/network): `{{PRD_PATH}}/QA/logs/`
+- Logs — API (JSONL request/response): `{{PRD_PATH}}/QA/logs/api/`
+- Playwright test scripts (UI mode): `{{PRD_PATH}}/QA/scripts/`
+- API test scripts (API mode — `.http` / pytest+httpx / supertest / etc.): `{{PRD_PATH}}/QA/scripts/api/`
 - Consolidated checklist: `{{PRD_PATH}}/QA/checklist.md`
+- API-testing recipes (skill): `.agents/skills/api-testing-recipes/`
 
 ## Multi-Project Context
 
@@ -74,6 +79,43 @@ Refer to `.dw/rules/` for project-specific URLs and frameworks.
 
 ## Process Steps
 
+### 0. Mode Detection (UI vs API) -- Required FIRST
+
+Decide whether the project has a testable UI or is API-only before any browser/API setup. The chosen mode drives every subsequent step.
+
+**Auto-detection (same matrix used by `/dw-dockerize`):**
+
+| Signal | UI mode | API mode |
+|--------|---------|----------|
+| `package.json` deps | `next`, `vite`, `react`, `vue`, `svelte`, `@angular/*`, `nuxt`, `astro`, `solid-js`, `remix` | none of the above |
+| `pyproject.toml` / `requirements*.txt` | `jinja2`, `django` (full), `flask` + `flask_login`/`render_template` | `fastapi`, `flask` (JSON only), `starlette`, `litestar` |
+| `*.csproj` | `Microsoft.AspNetCore.Mvc`, Razor, Blazor | `Microsoft.AspNetCore.Mvc.Core` only, minimal API templates |
+| `Cargo.toml` | `yew`, `leptos`, `dioxus`, `sycamore` | `axum`, `actix-web`, `rocket`, `warp` (no template engine) |
+
+If NO UI signals match → **API mode**. If at least one matches → **UI mode** (default).
+
+**Manual override (flags):**
+
+- `--api` forces API mode (useful when running headless API tests inside a fullstack project where the UI is irrelevant for this run).
+- `--ui` forces UI mode (raises a clear error if no UI dep is detected — this prevents accidentally running browser tests against a backend-only repo).
+- `--from-openapi <path-or-url>` adds an OpenAPI baseline on top of API mode (see `.agents/skills/api-testing-recipes/references/openapi-driven.md`).
+
+**Effect on subsequent steps:**
+
+| Step | UI mode | API mode |
+|------|---------|----------|
+| 2 — Environment Preparation | full Playwright + browser setup | API client setup, no browser; create `QA/scripts/api/` and `QA/logs/api/` |
+| 3 — Menu Page Verification | required, blocking | **skipped** |
+| 4 — E2E Tests | Playwright MCP | `api-testing-recipes` skill (recipe per stack) |
+| 5 — Accessibility | WCAG 2.2 with browser tools | API-surface checks (error shape, status semantics, leak detection) |
+| 6 — Visual Checks | required (mobile + desktop) | **skipped** |
+| 7-8 — Bug Documentation + Report | screenshots as evidence | JSONL logs as evidence (`evidence_type: api-log`) |
+| 9 — Fix-Retest Loop | unchanged shape; replays Playwright | unchanged shape; replays the recipe and writes new log line |
+
+Record the chosen mode in the QA report frontmatter (`mode: ui | api | mixed`). When in doubt, ask the user before proceeding — never silently fall back.
+
+<critical>If neither UI nor API signal is detectable (e.g., empty repo), abort with: "Cannot determine QA mode. Run `/dw-analyze-project` first OR pass `--ui` or `--api` explicitly."</critical>
+
 ### 1. Documentation Analysis (Required)
 
 - Read the PRD and extract ALL numbered functional requirements (RF-XX)
@@ -109,9 +151,11 @@ If NO credentials are found, STOP and ask the user before continuing. Do NOT gue
 - Confirm the page loaded correctly with `browser_snapshot`
 - If persistent session, auth import, or network inspection beyond MCP is needed, complement with `webapp-testing`
 
-### 3. Menu Page Verification (Required -- Execute BEFORE RF tests)
+### 3. Menu Page Verification (UI mode only -- Required, Execute BEFORE RF tests)
 
-<critical>BEFORE testing individual RFs, verify that EACH menu item in the module leads to a FUNCTIONAL and UNIQUE page. This verification is blocking -- if it fails, QA CANNOT be approved.</critical>
+**In API mode, this step is SKIPPED.** API surfaces have no menus; the equivalent check (every advertised endpoint exists and answers) is folded into Step 4-API.
+
+<critical>(UI mode) BEFORE testing individual RFs, verify that EACH menu item in the module leads to a FUNCTIONAL and UNIQUE page. This verification is blocking -- if it fails, QA CANNOT be approved.</critical>
 
 For each menu item in the module:
 1. Navigate to the page via `browser_navigate`
@@ -146,7 +190,11 @@ digraph menu_check {
 }
 ```
 
-### 4. E2E Tests with Playwright MCP (Required)
+### 4. E2E Tests (Required, mode-aware)
+
+This step has two branches; pick the one matching the mode chosen in Step 0.
+
+#### 4-UI (UI mode) -- Playwright MCP
 
 Use Playwright MCP tools to test each flow:
 
@@ -179,6 +227,39 @@ For each functional requirement from the PRD:
 <critical>It is not enough to validate only the happy path. Each requirement must be exercised against its boundary states and most likely regressions</critical>
 <critical>If a requirement cannot be fully validated via E2E, QA must be marked as REJECTED or BLOCKED, never APPROVED</critical>
 
+#### 4-API (API mode) -- `api-testing-recipes` skill
+
+Use the bundled `api-testing-recipes` skill to compose tests. The skill picks the right recipe per stack (default `.http` / REST Client; `pytest+httpx`, `supertest`, `WebApplicationFactory`, `reqwest` per language) and writes scripts and JSONL logs as evidence.
+
+Process:
+
+1. **Read** `.agents/skills/api-testing-recipes/SKILL.md` and select the recipe that matches the project's primary backend stack. Default to `recipes/http-rest-client.md` unless the project already runs `pytest`/`vitest`/`dotnet test`/`cargo test`, in which case prefer the matching stack-specific recipe so QA tests live alongside unit tests.
+2. **For each functional requirement (RF-XX) in the PRD**, derive the matrix per `.agents/skills/api-testing-recipes/references/matrix-conventions.md`:
+   - 200 happy path
+   - 4xx -- validation (missing field, wrong type, out of range)
+   - 4xx -- auth (no token, expired, malformed)
+   - 4xx -- authorization (valid token, wrong role)
+   - 4xx -- not found
+   - 4xx -- conflict
+   - 5xx -- server error (only if synthetically reproducible)
+   - **Contract drift** (response shape vs OpenAPI / TS types) -- mandatory
+   - **Authorization cross-tenant** (token from another org) -- mandatory if multi-tenant
+3. **Generate one file per RF** at `{{PRD_PATH}}/QA/scripts/api/RF-XX-[slug].<ext>` using the recipe's structure. Wire credentials via the patterns in `.agents/skills/api-testing-recipes/references/auth-patterns.md` (NEVER hardcode tokens).
+4. **Execute** each request (`curl` for `.http`; the project's runner for stack-specific). For EACH request, append a JSONL line to `{{PRD_PATH}}/QA/logs/api/RF-XX-[slug].log` per `references/log-conventions.md`. Redact `Authorization`/`Cookie`/`X-API-Key` headers and any response field matching `password*`/`secret*`/`*_hash`/`token*`.
+5. **Assert** per matrix expectation:
+   - Status code matches expected
+   - Response body matches schema (use `jq` for `.http` mode, framework matchers per stack)
+   - Required headers present (e.g., `Content-Type: application/json`)
+   - No leaked internal fields
+6. **Mark the requirement** as PASSED or FAILED with a one-line summary citing the log file path and (if FAILED) the failing JSONL line number.
+7. **Optional**: if the project exposes an OpenAPI spec (`openapi.yaml`, `openapi.json`, runtime `/openapi.json`), follow `references/openapi-driven.md` to generate a baseline. Add the `--from-openapi <path-or-url>` flag to make this explicit.
+
+OpenAPI baseline note: if `--from-openapi` is used, the generated tests live alongside hand-derived ones with filename pattern `openapi-RF-XX-[path-slug].<ext>`. Tag any unmapped spec endpoint as a documentation gap in the QA report (`openapi-no-rf-*`).
+
+<critical>(API mode) Every endpoint that mutates or reads tenant-scoped data MUST have a cross-tenant denial test. Skipping is allowed only for explicitly single-tenant systems and must be recorded as a `pytest.skip`/`it.skip`/equivalent with a reason.</critical>
+<critical>(API mode) Logs are evidence. Every PASS or FAIL claim in the QA report must cite a JSONL line under `QA/logs/api/`. No log = no evidence = QA cannot be APPROVED.</critical>
+<critical>(API mode) NEVER hardcode tokens or credentials in committed scripts. Use `@variable`/env-var references.</critical>
+
 ### 4.1. Required Minimum Matrix per Requirement
 
 For each RF, QA must explicitly answer:
@@ -201,9 +282,9 @@ Examples of edge cases that must be considered whenever relevant:
 - re-entrance/repeated actions
 - API failures, loading, and intermediate states
 
-### 5. Accessibility Checks (Required)
+### 5. Accessibility / API-Surface Checks (Required, mode-aware)
 
-Verify for each screen/component (WCAG 2.2):
+In **UI mode**, verify each screen/component against WCAG 2.2:
 
 - [ ] Keyboard navigation works (Tab, Enter, Escape)
 - [ ] Interactive elements have descriptive labels
@@ -217,13 +298,26 @@ Verify for each screen/component (WCAG 2.2):
 Use `browser_press_key` to test keyboard navigation.
 Use `browser_snapshot` to verify labels and semantic structure.
 
-### 6. Visual Checks (Required)
+**In API mode**, the WCAG checklist above is REPLACED by API-surface checks:
+
+- [ ] Every endpoint returns the correct `Content-Type` header
+- [ ] Errors follow a consistent shape (e.g., `{ "error": { "code": "...", "message": "..." } }`)
+- [ ] `401` (auth missing/invalid) is distinct from `403` (auth present but unauthorized)
+- [ ] Error responses do NOT leak stack traces, internal IDs, SQL fragments, or environment hints
+- [ ] Sensitive fields (`password*`, `*_hash`, `secret*`, `token*`) NEVER appear in any response body
+- [ ] Rate-limited endpoints return `429` with a `Retry-After` header (when applicable)
+
+Each check FAILED becomes a HIGH severity bug in `QA/bugs.md` with `evidence_type: api-log` pointing to the failing JSONL line.
+
+### 6. Visual Checks (UI mode only -- Required)
+
+**In API mode, this step is SKIPPED.** The QA report omits the "Visual" section entirely.
 
 - Capture screenshots of main screens with `browser_take_screenshot` and save to `{{PRD_PATH}}/QA/screenshots/`
 - Check layouts in different states (empty, with data, error, loading)
 - Document visual inconsistencies found
 
-### 6.1. Mobile Validation (Required)
+### 6.1. Mobile Validation (UI mode only -- Required)
 
 <critical>ALL visual checks MUST include tests at mobile viewport (375px) IN ADDITION to desktop (1440px). QA approval REQUIRES that BOTH resolutions are functional and visually acceptable. If the mobile layout is broken, unusable, or visually degraded, QA CANNOT be approved.</critical>
 
@@ -246,13 +340,15 @@ For each bug found, create an entry in `{{PRD_PATH}}/QA/bugs.md`:
 
 - **Severity:** High/Medium/Low
 - **Affected RF:** RF-XX
-- **Component:** [component/page]
+- **Component:** [component/page or endpoint path]
+- **Mode:** ui | api
 - **Steps to Reproduce:**
   1. [step 1]
   2. [step 2]
 - **Expected Result:** [what should happen]
 - **Actual Result:** [what happens]
-- **Screenshot:** `QA/screenshots/[file].png`
+- **Evidence type:** screenshot | api-log
+- **Evidence path:** `QA/screenshots/[file].png` (UI mode) OR `QA/logs/api/RF-XX-[slug].log#L<line>` (API mode)
 - **Status:** Open
 ```
 
@@ -296,10 +392,15 @@ Generate report in `{{PRD_PATH}}/QA/qa-report.md`:
 [Final QA assessment]
 ```
 
-### 9. QA Fix-Retest Loop (Automatic)
+### 9. QA Fix-Retest Loop (Automatic, mode-aware)
 
 <critical>QA does NOT end at the first report. If bugs are found, enter an automatic fix-retest loop until QA is APPROVED or explicitly BLOCKED.</critical>
 
+**Mode-aware behavior:** the loop's structure (max 5 cycles, atomic commit per fix, regression checks, exit criteria) is identical in both modes. What changes is the EVIDENCE replayed:
+
+- UI mode: re-run the Playwright flow, capture new `BUG-NN-retest.png` screenshot.
+- API mode: re-run the same `.http`/recipe via the recipe's runner, append a new line to `QA/logs/api/BUG-NN-retest.log` with `verdict: "PASS"` (closes the bug) or `verdict: "FAIL"` (keeps the cycle going).
+
 After generating the initial QA report:
 
 ```dot

package/scaffold/en/commands/dw-run-task.md

@@ -25,15 +25,16 @@ When available in the project at `./.agents/skills/`, use these skills as specia
 
 ## Codebase Intelligence
 
-<critical>If `.planning/intel/` exists, querying it is MANDATORY before writing requirements. Do NOT skip this step.</critical>
-- Internally run: `/gsd-intel "implementation patterns in [task target area]"`
+<critical>If `.dw/intel/` exists, querying it via `/dw-intel` is MANDATORY before writing code. Do NOT skip this step.</critical>
+- Internally run: `/dw-intel "implementation patterns in [task target area]"`
 - Follow conventions found for file structure, naming, and error handling
 
 If `design-contract.md` exists in the PRD directory:
 - Read the contract and ensure all frontend implementation follows the approved design rules
 
-If `.planning/intel/` does NOT exist:
-- Use `.dw/rules/` as context (current behavior)
+If `.dw/intel/` does NOT exist:
+- Use `.dw/rules/` as context, falling back to direct grep
+- Suggest running `/dw-map-codebase` after the task to enrich downstream context
 
 ## File Locations
 

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

@@ -78,7 +78,9 @@ npx -y @brunosps00/dev-workflow@latest update --lang=$DETECTED_LANG
 The `update` command overwrites managed files and PRESERVES:
 - `.dw/rules/` (user rules)
 - `.dw/spec/` (in-progress PRDs and tasks)
-- `.planning/` (user data)
+- `.dw/intel/` (codebase index from `/dw-map-codebase`)
+
+The `update` command also runs the GSD migration step automatically — if a project has legacy `.planning/` (from prior GSD usage), the contents are migrated to `.dw/intel/`, `.dw/spec/active-session.md`, `.dw/spec/quick/`, etc., and `.planning/` is renamed to `.planning.gsd-archive-<DATE>/` for inspection. The `.claude/commands/gsd/`, `.claude/agents/gsd-*.md`, `.claude/hooks/gsd-*.js`, and `.claude/gsd-file-manifest.json` files are removed during the migration.
 
 If the update fails (network error, permission, package unavailable): report the error to the user and STOP. Do NOT attempt manual workarounds like copying files by hand.
 

package/scaffold/en/templates/idea-onepager.md

@@ -22,7 +22,7 @@ Focus on the problem, not the solution. Avoid jumping into "how to implement".]
 Sources:
 - PRDs in `.dw/spec/prd-*/prd.md` (features already delivered or in development)
 - `.dw/rules/index.md` (product overview)
-- `.planning/intel/` if GSD is installed
+- `.dw/intel/` (queryable index — built by `/dw-map-codebase`, queried via `/dw-intel`)
 
 Format:]