@brunosps00/dev-workflow 0.15.0 → 1.0.0

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

@@ -0,0 +1,176 @@
+<system_instructions>
+You are the task execution orchestrator. Two modes: execute ONE specific task, or execute ALL pending tasks in dependency order. Both modes apply the same task-level guarantees (atomic commit per task, mandatory tests, verify before commit, deviation handling).
+
+## When to Use
+- Use `run` after `/dw-plan` has produced `tasks.md` + per-task files and the tasks are approved.
+- Use to execute a single targeted task during incremental development.
+- Do NOT use for bug fixes — `/dw-bugfix` handles those.
+- Do NOT use without an approved tasks breakdown — tasks files MUST exist.
+
+## Pipeline Position
+**Predecessor:** `/dw-plan` (with tasks approved) | **Successor:** `/dw-review` then `/dw-commit` + `/dw-generate-pr`
+
+## Modes
+
+| Invocation | Behavior |
+|------------|----------|
+| `/dw-run` | **Default.** Executes ALL pending tasks from `tasks.md` in dependency order. Wave-based parallel dispatch for independent tasks. Atomic commit per task. After all complete, runs Level 2 review (PRD compliance). |
+| `/dw-run <task-id>` | Executes ONE specific task by ID (e.g., `1.0`, `2.3`). Includes Level 1 validation. Atomic commit on success. |
+| `/dw-run --resume` | Resumes an interrupted multi-task plan from where it stopped. Reads `.dw/spec/<prd>/active-session.md` if present; otherwise continues from first pending task. |
+
+## Inputs
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `{{TASK_ID}}` | Specific task identifier (optional — defaults to all pending) | `1.0`, `2.3`, `5.1` |
+| `{{PRD_PATH}}` | Path to PRD directory containing tasks (optional — auto-detect from active branch) | `.dw/spec/prd-invoice-export` |
+
+## Complementary Skills
+
+When available under `./.agents/skills/`, these skills are invoked per task:
+
+- `dw-verify`: **ALWAYS** — before each task's commit, produces a Verification Report (test + lint + build all GREEN). Without PASS, no commit. The Iron Law of verification.
+- `dw-memory`: **ALWAYS** — reads workflow memory at task start; updates at task end with the promotion test (lessons that apply to next task get promoted to shared MEMORY.md).
+- `dw-execute-phase`: provides `plan-checker` (6-dimension goal-backward verification before any code is touched in plan mode) and `executor` (atomic commit + deviation handling) agents.
+- `dw-testing-discipline`: applies the placement doctrine, 6 agent guardrails, and 25 anti-patterns when adding tests during the task.
+- `dw-ui-discipline`: when the task touches UI, the 4 grounding questions must be answered before any visual decision lands.
+- `dw-llm-eval`: when the task touches AI feature code paths, the reference dataset + oracle ladder rules apply.
+- `vercel-react-best-practices`: when the task touches React/Next.js performance.
+
+## Constitution Gate
+
+<critical>BEFORE executing any task, check `.dw/constitution.md`. If MISSING, auto-install defaults via the v0.11 pattern. If PRESENT, the task's `Constitution Alignment` line (set during `/dw-plan` Stage 3) is consulted as the task executes — code must respect the claimed principles.</critical>
+
+## Codebase Intelligence
+
+<critical>If `.dw/intel/` exists, query it via `/dw-intel` before implementation to align with existing patterns.</critical>
+- Per-task: `/dw-intel "patterns for <task topic>"` to surface relevant conventions.
+
+## Mode 1: ONE task (`run <task-id>`)
+
+### Prerequisites
+- `tasks.md` + per-task files exist in `.dw/spec/<prd>/`.
+- The target task's dependencies are completed (check `task.md` "Depends on" section).
+
+### Behavior
+
+1. **Read the task file:** `.dw/spec/<prd>/<task-id>_task.md`. Understand inputs, FRs covered, acceptance criteria, subtasks.
+2. **Plan implementation:**
+   - List files to create/modify.
+   - Identify test additions per subtask.
+   - Confirm dependencies (if missing, STOP and surface).
+3. **Implement:**
+   - Follow project patterns from `.dw/rules/` and `.dw/intel/`.
+   - Apply complementary skills (UI gate, test discipline, etc.).
+   - Mandatory unit tests for backend/services per testspec.
+   - Match the testing framework specified in `.dw/rules/`.
+4. **Validate (Level 1):**
+   - Run the project's test command.
+   - Check acceptance criteria from the task file.
+   - Run `dw-verify` to produce the Verification Report (test + lint + build GREEN).
+   - For interactive frontend, also validate real behavior via `dw-testing-discipline` Playwright recipes if regression risk is meaningful.
+5. **Commit:**
+   - Atomic commit message: `feat(<scope>): <task title> (#<task-id>)`.
+   - Reference the FRs covered.
+   - One task = one commit (unless the task explicitly has subtask milestones that earn separate commits).
+6. **Update tasks.md:** mark this task as `Done` with the commit SHA.
+7. **Report:** what was done, what tests were added, what was validated.
+
+### STOP CONDITIONS
+- Dependencies not satisfied → ask user how to proceed.
+- Verification Report FAIL → do not commit; report what's broken.
+- Task scope creep detected mid-implementation → STOP and ask user to scope.
+
+## Mode 2: ALL pending tasks (default `run`)
+
+### Prerequisites
+- `tasks.md` + per-task files exist with declared dependencies.
+- `tasks-validation.md` shows PASS (or explicit override).
+- The branch is created: `feat/prd-<feature-slug>`.
+
+### Behavior
+
+1. **Plan check (via `dw-execute-phase/plan-checker` agent):**
+   - 6-dimension goal-backward verification: are these tasks actually going to deliver what the PRD promises?
+   - If FAIL on any dimension, STOP and report to user before any code is touched.
+2. **Build dependency graph:**
+   - Topological sort of tasks.
+   - Identify independent tasks that can run in parallel waves.
+3. **Wave-based parallel dispatch (via `dw-execute-phase/executor` agent):**
+   - Each wave contains tasks with no inter-dependencies.
+   - Execute waves serially; within a wave, tasks dispatch in parallel.
+   - Per-task: same Level 1 flow as Mode 1 (implement → validate → atomic commit).
+4. **Deviation handling:**
+   - If a task encounters scope creep, STOP that task, surface to user.
+   - If a task fails verification, the wave halts. No subsequent waves run until resolved.
+5. **Checkpoint between waves:**
+   - Print wave summary: tasks completed, commits, any deviations.
+   - Continue automatically unless `--checkpoint` was passed (then wait for user OK).
+6. **Final Level 2 review:**
+   - After all tasks complete, automatically invoke `/dw-review` (the merged review command — runs both PRD compliance check and code quality review).
+   - Present consolidated review report.
+   - Interactive corrections cycle: review surfaces gaps → user decides to fix, defer, or accept.
+
+### Output
+
+```
+.dw/spec/<prd>/
+├── active-session.md      # written at checkpoint; consumed by --resume
+├── run-log.md             # per-wave execution log with commit SHAs
+└── review-consolidated.md # final L2+L3 review (from /dw-review)
+```
+
+## Mode 3: Resume (`run --resume`)
+
+### Prerequisites
+- Previous `run` (Mode 2) was interrupted.
+- `active-session.md` exists in the current PRD's `.dw/spec/<prd>/` directory.
+
+### Behavior
+
+1. Read `active-session.md` to determine which task/wave the session stopped at.
+2. Surface to user: "Resuming from wave N, task X.0. Previously completed: <list>. Continue?"
+3. On confirmation, resume from the next pending task with the same Mode 2 behavior.
+
+If `active-session.md` doesn't exist but uncompleted tasks remain, treat as Mode 2 fresh start.
+
+## Across all modes: deviation handling
+
+When implementation cannot proceed as planned:
+
+| Deviation | Action |
+|-----------|--------|
+| Task requires new dependency not in TechSpec | STOP. Suggest `/dw-plan techspec --update` to revise. |
+| Acceptance criterion is ambiguous | STOP. Ask user for clarification. |
+| Test framework decision missing | STOP. Use `dw-testing-discipline` placement doctrine to propose; ask for sign-off. |
+| Pattern from `.dw/rules/` doesn't fit cleanly | STOP. Surface the friction; propose either an ADR-justified deviation or a rules update. |
+| Hidden complexity emerges (task estimated 2h, looks like 8h) | STOP. Surface; either split the task via `/dw-plan tasks --update` or accept the delay with note. |
+
+## Reporting
+
+After every run (Mode 1, 2, or 3 completion), print:
+
+- Tasks completed with commit SHAs.
+- Files touched count.
+- Tests added (unit + E2E if applicable).
+- Verification Report verdict per task.
+- For Mode 2: final consolidated review status.
+- For Mode 2: any deviations encountered and how they were resolved.
+
+## Anti-patterns
+
+- Skipping `dw-verify` to "save time before commit" — produces commits that don't build.
+- Running tasks without dependency satisfaction — produces commits that won't work in isolation.
+- Letting wave-based parallel run without watching for deviations — silent scope creep compounds.
+- Committing multiple tasks in one commit — breaks bisect, breaks revert granularity.
+- Skipping the final Level 2 review in Mode 2 — ships features that don't fully match the PRD.
+
+## Final Guidelines
+
+- Atomic commits are non-negotiable. One task = one commit (or one subtask-bundle if explicit).
+- Tests are mandatory per the testing strategy section of the TechSpec.
+- Verification Report PASS is the gate, not the goal — never weaken assertions to make tests pass.
+- Deviation surfacing is a feature, not a bug. Stop and ask. The user prefers an interruption to a wrong implementation.
+- For multi-day plans, `--resume` is your friend. Don't restart from zero.
+
+</system_instructions>

package/scaffold/en/commands/dw-secure-audit.md

@@ -0,0 +1,222 @@
+<system_instructions>
+You are the security audit orchestrator. Runs OWASP static review + supply-chain CVE/secret/IaC scanning + dependency outdated check + supply-chain compromise detection in one pass. Hard-gates downstream commands when CRITICAL or HIGH findings exist.
+
+Auto-invoked by `/dw-review` and `/dw-generate-pr` for TS/Python/C#/Rust projects. Standalone invocation available for manual audit.
+
+## When to Use
+- Auto-invoked: `/dw-review` and `/dw-generate-pr` for supported languages.
+- Manual: when you suspect supply-chain compromise, want a security pass mid-development, or after dependency updates.
+- Do NOT use mid-task implementation (use `/dw-run` which has lighter checks).
+- Do NOT use as a substitute for human security review on high-stakes auth/payment code (use `security-review` skill PLUS this).
+
+## Pipeline Position
+**Predecessor:** any time; auto-invoked by `/dw-review`, `/dw-generate-pr` | **Successor:** `/dw-bugfix` to address findings, or `/dw-commit` if APPROVED
+
+## Modes
+
+| Invocation | What runs |
+|------------|-----------|
+| `/dw-secure-audit` | **Default.** Full audit: OWASP static review + Trivy SCA/secret/IaC + native lockfile audit + supply-chain check + outdated check. |
+| `/dw-secure-audit --scan-only` | CI mode — runs scanners, exits with non-zero if CRITICAL or HIGH findings. No remediation planning. |
+| `/dw-secure-audit --plan` | Default scan, plus per-package remediation plan (Conservative / Balanced / Bold options). No file writes; just the plan. |
+| `/dw-secure-audit --execute` | Plan plus apply updates: scoped tests per package, one `/dw-qa --fix` retry on failure, atomic commits, `/dw-qa` as final gate. Reverts and marks BLOCKED if recovery fails. |
+
+## Supported Languages
+
+| Language | Lockfile Audit | OWASP Pattern | Trivy SCA/Secrets/IaC | Compromise Check |
+|----------|---------------|---------------|----------------------|------------------|
+| TypeScript / JavaScript | `npm audit` / `pnpm audit` | Yes | Yes | Yes (OSV + GH Advisories) |
+| Python | `pip-audit` | Yes | Yes | Yes |
+| C# / .NET | `dotnet list package --vulnerable` | Yes | Yes | Yes |
+| Rust | `cargo audit` | Yes | Yes | Yes |
+| Other (Go, Java, etc.) | manual | Yes (best-effort) | Yes (Trivy) | Yes (OSV) |
+
+## Required Dependencies
+
+- **Trivy** — must be installed (via `npx @brunosps00/dev-workflow install-deps`).
+- **Context7 MCP** — for framework-version-specific security best practices.
+
+## Three Detection Layers
+
+### Layer 1: OWASP Static Review (via `security-review` skill)
+
+Language-aware static analysis against OWASP Top 10 categories:
+- A01 Broken access control
+- A02 Cryptographic failures
+- A03 Injection (SQL, NoSQL, OS command, etc.)
+- A04 Insecure design
+- A05 Security misconfiguration
+- A06 Vulnerable / outdated components (overlaps with Layer 2)
+- A07 Identification + authentication failures
+- A08 Software / data integrity failures
+- A09 Security logging + monitoring failures
+- A10 Server-side request forgery (SSRF)
+
+Output: `.dw/secure-audit/owasp-findings.md` with per-category findings ordered by severity.
+
+### Layer 2: Trivy + native lockfile audit
+
+Runs in parallel:
+- `trivy fs <project>` — scans for SCA (known CVEs), secret leaks, IaC issues.
+- `trivy config <project>` — scans Terraform / Dockerfile / K8s configs.
+- Native auditor per language (npm audit / pip-audit / dotnet list / cargo audit) — lockfile-level CVEs.
+
+Output: `.dw/secure-audit/trivy-findings.md` + `.dw/secure-audit/lockfile-findings.md`.
+
+### Layer 3: Supply-chain compromise check
+
+Cross-references the dependency tree against:
+- **OSV.dev** — open-source vulnerabilities database.
+- **GitHub Advisories** — npm/PyPI/etc. published advisories.
+- **Hardcoded historical malicious-package list** — `event-stream`, `ua-parser-js`, `node-ipc`, etc. (known compromised packages by name+version range).
+
+Output: `.dw/secure-audit/compromise-findings.md` per affected package: COMPROMISED / suspicious / clean.
+
+### Plus: outdated check
+
+`npm outdated` / `pip list --outdated` / `dotnet list outdated` / `cargo outdated` to identify packages behind by minor or major versions.
+
+Output: `.dw/secure-audit/outdated.md` with severity tiers (OUTDATED-MAJOR / OUTDATED-MINOR).
+
+## Classification
+
+All findings are classified into one of these tiers in `.dw/secure-audit/audit-summary.md`:
+
+| Tier | Criteria | Block | Suggested Action |
+|------|----------|-------|------------------|
+| **COMPROMISED** | Package known to be malicious in this version range | YES | Immediate remove / pin to safe version |
+| **CRITICAL** | CVE CVSS ≥9.0 OR exploits in the wild OR auth bypass | YES | Update or replace within 24h |
+| **HIGH** | CVE CVSS 7.0–8.9 OR exploitable in current context | YES | Update or replace within 1 week |
+| **OUTDATED-MAJOR** | ≥1 major version behind (e.g., React 17 → 19) | NO | Plan migration in next quarter |
+| **OUTDATED-MINOR** | Minor/patch behind | NO | Update routinely |
+| **CLEAN** | No findings | NO | — |
+
+## Hard Gates
+
+The verdict is one of:
+- **APPROVED** — no CRITICAL or HIGH or COMPROMISED findings. Verdict file `.dw/secure-audit/audit-summary.md` status: APPROVED.
+- **REJECTED** — ≥1 CRITICAL, HIGH, or COMPROMISED finding without explicit ADR or remediation in flight. Verdict file status: REJECTED.
+
+**`/dw-review` and `/dw-generate-pr` enforce:** if the project's language is supported AND the most recent `.dw/secure-audit/audit-summary.md` is missing OR REJECTED, those commands themselves return REJECTED. No exception. No bypass flag.
+
+## Mode 1: Default (`/dw-secure-audit`)
+
+1. **Detect stack**: check for package.json / requirements.txt / *.csproj / Cargo.toml.
+2. **Run all three layers in parallel** (where possible):
+   - OWASP static (via `security-review` skill).
+   - Trivy + lockfile audit.
+   - Supply-chain compromise check.
+3. **Run outdated check.**
+4. **Aggregate findings** per classification tier.
+5. **Write summary** at `.dw/secure-audit/audit-summary.md`:
+
+```markdown
+# Security Audit — YYYY-MM-DD
+
+## Verdict: APPROVED / REJECTED
+
+## Tier Summary
+| Tier | Count | Detail |
+|------|-------|--------|
+| COMPROMISED | N | <list> |
+| CRITICAL | N | <list> |
+| HIGH | N | <list> |
+| OUTDATED-MAJOR | N | <list> |
+| OUTDATED-MINOR | N | <list> |
+
+## Layer reports
+- OWASP findings: `owasp-findings.md`
+- Trivy findings: `trivy-findings.md`
+- Lockfile findings: `lockfile-findings.md`
+- Compromise findings: `compromise-findings.md`
+- Outdated: `outdated.md`
+
+## Next Steps
+- If APPROVED: downstream commands unblocked.
+- If REJECTED: run `/dw-secure-audit --plan` to draft remediation, OR `/dw-bugfix` per critical finding.
+```
+
+## Mode 2: Plan mode (`/dw-secure-audit --plan`)
+
+After the default scan, draft a per-package remediation plan in `.dw/secure-audit/remediation-plan.md`:
+
+For each finding with severity ≥HIGH (or any COMPROMISED):
+1. Identify affected files (imports of the package in source).
+2. Identify tests that cover those files (impact scope for the remediation).
+3. Propose three options:
+   - **Conservative** — pin to a patched version within the same major.
+   - **Balanced** — update to the latest minor or major.
+   - **Bold** — replace the package OR refactor away from it.
+4. Trade-off analysis per option (effort, risk, blast radius).
+
+Plan does NOT execute. User reviews and chooses an option per package, then invokes `--execute`.
+
+## Mode 3: Execute (`/dw-secure-audit --execute`)
+
+For each user-approved remediation:
+1. Apply the update (`npm install <pkg>@<ver>` or equivalent).
+2. Run scoped tests (tests in files that import the package).
+3. If tests fail → run `/dw-qa --fix` once to attempt automatic recovery.
+4. If recovery succeeds → atomic commit `chore(security): update <pkg> to <ver> for <CVE>`.
+5. If recovery fails → REVERT the update, mark BLOCKED in `remediation-plan.md`, surface to user.
+6. After all approved remediations: run `/dw-qa` as final gate. If clean, run `/dw-secure-audit` again to verify all findings resolved.
+
+## Mode 4: CI mode (`/dw-secure-audit --scan-only`)
+
+Minimal output:
+- Runs all three layers.
+- Writes findings to disk.
+- Exits with code 0 if APPROVED, 1 if REJECTED.
+- No remediation planning.
+
+For pre-merge CI gates.
+
+## Complementary Skills
+
+- `security-review`: **ALWAYS** — OWASP static review skill ships with the scan.
+- `dw-source-grounding`: **ALWAYS** in `--plan` / `--execute` mode — version recommendations cite official changelog/release notes with `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`.
+- `dw-council`: auto opt-in when ≥3 packages land in COMPROMISED tier — multi-advisor stress-test on remediation order and scope.
+- `dw-testing-discipline`: when scoped tests fail in `--execute`, the testing doctrine applies (no flaky retry; investigate).
+- `dw-debug-protocol`: when a critical finding turns out to be a real bug in our own code (not just an outdated dep), the six-step triage applies.
+
+## Constitution Gate
+
+<critical>
+- A CRITICAL or COMPROMISED finding without an ADR justifying explicit acceptance → verdict cannot be APPROVED.
+- Constitution principle violations (security-related principles like P-009 server-side auth, P-010 secrets-in-repo) escalate findings — a `severity: info` principle violation surfaced here becomes a HIGH classification.
+</critical>
+
+## Anti-patterns
+
+- Running `--scan-only` in CI but no one reviews the report — automated REJECTs accumulate, team learns to ignore.
+- Skipping `--execute` and applying updates manually without scoped tests — breaks unrelated things.
+- Marking findings as "false positive" without ADR — pattern erodes over time.
+- Updating a CRITICAL finding to the BLEEDING edge version instead of the patched-and-stable version — introduces new bugs.
+- Running scans only at PR time — supply-chain attacks hit overnight; consider scheduled daily runs.
+
+## Output Directory
+
+```
+.dw/secure-audit/
+├── audit-summary.md           # verdict + tier summary
+├── owasp-findings.md          # Layer 1
+├── trivy-findings.md          # Layer 2 (SCA + secrets + IaC)
+├── lockfile-findings.md       # Layer 2 (native auditor)
+├── compromise-findings.md     # Layer 3
+├── outdated.md                # outdated check
+├── remediation-plan.md        # --plan output
+└── execution-log.md           # --execute log
+```
+
+All files committed. Audit history is part of the repo.
+
+## Why this skill exists
+
+Previously two commands: `/dw-secure-audit` (single-shot gate) and `/dw-secure-audit --plan` (planner + remediator). The split was historical — both share the same scanners and overlapping findings. Consolidating reduces:
+- Confusion ("which one do I run?").
+- Duplicate scans (running both did 2× the Trivy work).
+- Reporting fragmentation (two separate output dirs).
+
+The new command has both behaviors as flag modes. Default = the v0.6-era `security-check` (gate). `--plan` and `--execute` cover the v0.7-era `deps-audit` (planner + remediator).
+
+</system_instructions>

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

@@ -78,7 +78,7 @@ 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)
-- `.dw/intel/` (codebase index from `/dw-map-codebase`)
+- `.dw/intel/` (codebase index from `/dw-intel --build`)
 
 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.
 

package/scaffold/en/references/playwright-patterns.md

@@ -1,6 +1,6 @@
 # Playwright Test Patterns
 
-Reference for `/dw-run-qa` and `/dw-functional-doc`. Common E2E patterns.
+Reference for `/dw-qa` and `/dw-functional-doc`. Common E2E patterns.
 
 ## 1. Authenticated Navigation
 

package/scaffold/en/references/refactoring-catalog.md

@@ -1,6 +1,6 @@
 # Refactoring Catalog — Before/After Examples
 
-Reference for `/dw-refactoring-analysis`. Based on Fowler's refactoring catalog.
+Reference for `/dw-brainstorm --refactor`. Based on Fowler's refactoring catalog.
 
 ## 1. Long Function → Extract Function
 

package/scaffold/en/templates/brainstorm-matrix.md

@@ -49,4 +49,4 @@
 ## Next Steps
 
 - [ ] Validate with stakeholders
-- [ ] Create PRD: `/dw-create-prd`
+- [ ] Create PRD: `/dw-plan prd`

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)
-- `.dw/intel/` (queryable index — built by `/dw-map-codebase`, queried via `/dw-intel`)
+- `.dw/intel/` (queryable index — built by `/dw-intel --build`, queried via `/dw-intel`)
 
 Format:]
 
@@ -85,6 +85,6 @@ Ideally 2-4 stories. If it's more than 5, it's probably not MVP.]
 
 Pick ONE:
 
-- **`/dw-create-prd`** using this one-pager as input — when the direction is clear but we need to detail user stories, acceptance criteria, and hand off to techspec
-- **`/dw-run-task`** — when it's an IMPROVES so small that it fits in a single task (up to 3 files, no new endpoint/screen) — write a quick PRD first
+- **`/dw-plan prd`** using this one-pager as input — when the direction is clear but we need to detail user stories, acceptance criteria, and hand off to techspec
+- **`/dw-run`** — when it's an IMPROVES so small that it fits in a single task (up to 3 files, no new endpoint/screen) — write a quick PRD first
 - **Stop here** — if any "Open Question" is blocking, stop and resolve with the stakeholder before advancing

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

@@ -94,12 +94,12 @@ services: []
 
 ## MVP Scope
 
-[The smallest first feature you'll ship. Thought as user stories — this should drive the first /dw-create-prd run.]
+[The smallest first feature you'll ship. Thought as user stories — this should drive the first /dw-plan prd run.]
 
 - As a [persona], I can [action] so that [benefit]
 - As a [persona], I can [action] so that [benefit]
 
-If you don't have a first feature in mind yet, that's OK — leave a placeholder and run /dw-create-prd when ready.
+If you don't have a first feature in mind yet, that's OK — leave a placeholder and run /dw-plan prd when ready.
 
 ## Not Doing (explicit)
 
@@ -115,7 +115,7 @@ If you don't have a first feature in mind yet, that's OK — leave a placeholder
 
 ## Open Questions
 
-[Things this one-pager cannot answer alone. Resolve before /dw-create-prd or escalate to a stakeholder.]
+[Things this one-pager cannot answer alone. Resolve before /dw-plan prd or escalate to a stakeholder.]
 
 - [question 1]
 - [question 2]
@@ -124,6 +124,6 @@ If you don't have a first feature in mind yet, that's OK — leave a placeholder
 
 Pick ONE:
 
-- **`/dw-create-prd`** — when you have a first feature in mind and want to draft the PRD on top of this stack
+- **`/dw-plan prd`** — when you have a first feature in mind and want to draft the PRD on top of this stack
 - **`/dw-analyze-project`** — after the first substantial commit, to enrich `.dw/rules/` with module-level conventions
-- **`/dw-deps-audit --scan-only`** — to confirm no vulnerable deps shipped from the `create-*` templates
+- **`/dw-secure-audit --plan --scan-only`** — to confirm no vulnerable deps shipped from the `create-*` templates

package/scaffold/pt-br/agent-instructions.md

@@ -11,28 +11,42 @@ Este projeto usa [`@brunosps00/dev-workflow`](https://www.npmjs.com/package/@bru
 |------------------------------------------------|--------------|
 | "Implementa X" / "Cria Y" / "Adiciona feature Z" / "Preciso de..." | `/dw-autopilot "X"` |
 | Erro colado / "X está quebrado" / "Bug em Y" / screenshot de teste falhando | `/dw-bugfix "X"` |
-| "Roda essa task" (com ID da task) | `/dw-run-task <ID>` |
-| "Roda todas as tasks pendentes" / "Executa o plano" | `/dw-run-plan` |
-| "Revisa meu PR" / "Checa qualidade do código" / "Tá pronto pra subir?" | `/dw-code-review` |
+| "Planeja essa feature" / "Escreve PRD + techspec + tasks" | `/dw-plan "X"` |
+| "Escreve PRD pra X" / "Especifica Y" | `/dw-plan prd "X"` |
+| "Desenha a arquitetura" / "Faz o techspec" | `/dw-plan techspec` |
+| "Quebra em tasks" | `/dw-plan tasks` |
+| "Roda essa task" (com ID da task) | `/dw-run <ID>` |
+| "Roda todas as tasks pendentes" / "Executa o plano" | `/dw-run` |
+| "Continue de onde parei" | `/dw-run --resume` |
+| "QA dessa feature" / "Roda o test plan" | `/dw-qa` |
+| "Corrige os bugs do QA" | `/dw-qa --fix` |
+| "Avalia a feature AI" / "Testa o RAG / classifier" | `/dw-qa --ai` |
+| "Revisa meu PR" / "Checa qualidade" / "Tá pronto pra subir?" | `/dw-review` |
+| "Só checagem de cobertura PRD" | `/dw-review --coverage-only` |
+| "Só code review qualidade" | `/dw-review --code-only` |
 | "Hora de commitar" / mudanças validadas e prontas | `/dw-commit` |
 | "Abre um PR" / "Sobe isso" | `/dw-generate-pr` |
-| "Escreve PRD pra X" / "Especifica Y" | `/dw-create-prd` |
-| "Desenha a arquitetura" / "Faz o techspec" | `/dw-create-techspec` |
-| "Quebra em tasks" | `/dw-create-tasks` |
+| "Brainstorm X" / "Explora ideias" | `/dw-brainstorm "X"` |
+| "Research X" / "Compara A vs B com citações" | `/dw-brainstorm --research "X"` |
+| "Auditoria de saúde do código" / "Tech debt" / "Oportunidades de refactor" | `/dw-brainstorm --refactor` |
 | "Onde está X?" / "O que usa Y?" / "Como Z é estruturado?" | `/dw-intel "<pergunta>"` |
-| "Audita nossas dependências" / "Estamos atrasados em pacotes?" | `/dw-deps-audit` |
-| "Scan de vulnerabilidades" / "Check de segurança" | `/dw-security-check` |
-| "QA dessa feature" / "Roda o test plan" | `/dw-run-qa` |
-| "Corrige os bugs do QA" | `/dw-fix-qa` |
+| "Reconstrói o índice" / "Refresh do intel" | `/dw-intel --build` |
+| "Redesign dessa UI" / "Audita e entrega novo design" | `/dw-redesign-ui "<target>"` |
+| "Audita dependências" / "Estamos atrasados em pacotes?" | `/dw-secure-audit --plan` |
+| "Scan de vulnerabilidades" / "Check de segurança" | `/dw-secure-audit` |
+| "Analisa esse projeto" / "Gera rules" | `/dw-analyze-project` |
+| "Abre um novo projeto" / "Bootstrap de stack" | `/dw-new-project` |
+| "Dockeriza isso" / "Adiciona docker-compose" | `/dw-dockerize` |
+| "Functional doc" / "Mapeia screens e flows" | `/dw-functional-doc` |
 
 **Prioridade:** na dúvida entre dois comandos, `/dw-autopilot` é o default mais seguro pra qualquer pedido de feature não-trivial — ele compõe os demais.
 
 ## Hard Gates (os comandos enforçam — não burle)
 
 - **`.dw/constitution.md`**: princípios com `severity: high` ou `critical` bloqueiam PRs / techspecs sem um ADR justificando o desvio. Constitution ausente? Os comandos auto-instalam defaults em `severity: info` (não-bloqueante) e seguem — ausência nunca bloqueia.
-- **`.dw/spec/<prd>/tasks-validation.md`**: auto-gerado no fim do `/dw-create-tasks`. Qualquer dimensão FAIL bloqueia approval do usuário até resolver ou override explícito.
+- **`.dw/spec/<prd>/tasks-validation.md`**: auto-gerado no fim do `/dw-plan tasks`. Qualquer dimensão FAIL bloqueia approval do usuário até resolver ou override explícito.
 - **Verification**: `/dw-generate-pr` exige `dw-verify` PASS fresco (testes + lint + build) depois do último edit.
-- **Segurança**: projetos TS / Python / C# / Rust precisam passar `/dw-security-check` (Trivy + OWASP + lockfile audit) antes do PR abrir.
+- **Segurança**: projetos TS / Python / C# / Rust precisam passar `/dw-secure-audit` (Trivy + OWASP + lockfile audit) antes do PR abrir.
 
 ## Escape Hatches — NÃO auto-trigger
 
@@ -52,10 +66,7 @@ Quando qualquer destes se aplica, responda direto e **não** invoque comando `dw
 
   --- OU passo a passo ---
 
-/dw-brainstorm ─► /dw-create-prd ─► /dw-create-techspec ─► /dw-create-tasks
-                                                              │
-                                                              ▼
-/dw-commit + /dw-generate-pr ◄──── /dw-code-review ◄──── /dw-run-plan
+/dw-brainstorm ─► /dw-plan ─► /dw-run ─► /dw-qa ─► /dw-review ─► /dw-commit ─► /dw-generate-pr
 ```
 
 Lista completa e ajuda contextual: `/dw-help`.

package/scaffold/pt-br/commands/dw-adr.md

@@ -3,12 +3,12 @@ Você é um registrador de decisões arquiteturais. Sua função é criar um **A
 
 ## Quando Usar
 - Use quando uma decisão arquitetural ou de design foi tomada e precisa ser registrada para referência futura (escolha de biblioteca, padrão de comunicação, tradeoff de performance, restrição imposta por compliance, etc.)
-- Use durante `/dw-create-techspec` ou `/dw-run-task` quando a justificativa da decisão não cabe no techspec nem no task file
+- Use durante `/dw-plan techspec` ou `/dw-run` quando a justificativa da decisão não cabe no techspec nem no task file
 - NÃO use para decisões triviais ou reversíveis sem custo (escolha de nome de variável, ordem de import)
 - NÃO use para registrar bugs ou incidents (use `/dw-bugfix` ou notas operacionais)
 
 ## Posição no Pipeline
-**Antecessor:** qualquer ponto do pipeline após `/dw-create-prd` | **Sucessor:** continua o fluxo anterior (techspec, task, review)
+**Antecessor:** qualquer ponto do pipeline após `/dw-plan prd` | **Sucessor:** continua o fluxo anterior (techspec, task, review)
 
 O ADR é **aditivo**: ele não substitui nenhuma etapa do pipeline. Qualquer command existente pode invocar `/dw-adr` quando uma decisão não-trivial precisar de registro permanente.
 

package/scaffold/pt-br/commands/dw-analyze-project.md

@@ -24,10 +24,10 @@ Você é um assistente especializado em análise de projetos de software. Sua ta
 
 ## Consumidores da Saída
 As rules geradas por este comando são consumidas por:
-- `/dw-run-task` -- lê rules para padrões de implementação
-- `/dw-code-review` -- lê rules para verificações de conformidade
-- `/dw-refactoring-analysis` -- lê rules para contexto do projeto
-- `/dw-create-techspec` -- lê rules para decisões de arquitetura
+- `/dw-run` -- lê rules para padrões de implementação
+- `/dw-review --code-only` -- lê rules para verificações de conformidade
+- `/dw-brainstorm --refactor` -- lê rules para contexto do projeto
+- `/dw-plan techspec` -- lê rules para decisões de arquitetura
 
 <critical>NUNCA modifique código fonte, apenas leia e documente</critical>
 <critical>Gere os arquivos de rules em .dw/rules/ na raiz do workspace</critical>
@@ -218,13 +218,13 @@ Para cada projeto/módulo detectado, identificar:
 Quando React for detectado, execute `npx react-doctor@latest --verbose` e inclua o health score nas rules geradas como métrica baseline.
 Para projetos Angular, execute `ng lint` e documente warnings como baseline.
 
-<critical>A execução do /dw-map-codebase para gerar o índice queryable em .dw/intel/ é OBRIGATÓRIA. O comando NÃO pode ser considerado completo sem ela.</critical>
+<critical>A execução do /dw-intel --build para gerar o índice queryable em .dw/intel/ é OBRIGATÓRIA. O comando NÃO pode ser considerado completo sem ela.</critical>
 
 #### Inteligência do Codebase (nativo)
 
-Após gerar as rules em `.dw/rules/`, delegue para `/dw-map-codebase` para criar o índice queryable em `.dw/intel/`:
+Após gerar as rules em `.dw/rules/`, delegue para `/dw-intel --build` para criar o índice queryable em `.dw/intel/`:
 - O índice inclui: stack (`stack.json`), grafo de arquivos (`files.json`), superfície de API (`apis.json`), dependências (`deps.json`), overview de arquitetura (`arch.md`)
-- O índice é incremental — `/dw-map-codebase --files <list>` atualiza só os entries tocados; full scan só quando preciso
+- O índice é incremental — `/dw-intel --build --files <list>` atualiza só os entries tocados; full scan só quando preciso
 - Outros comandos dw-* consultam o índice via `/dw-intel` (veja a skill bundled `dw-codebase-intel` para schemas)
 
 ### Passo 4: Ler Arquivos Fonte Representativos (Obrigatório)