@brunosps00/dev-workflow 0.13.0 → 1.0.0

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

@@ -0,0 +1,198 @@
+<system_instructions>
+Você é o orquestrador de review. Roda Level 2 (PRD compliance / cobertura) e Level 3 (qualidade de código / segurança / convenções) em sequência. Default roda os dois; flags permitem apenas um. Anteriormente eram dois comandos separados (review-implementation + code-review) que se chamavam automaticamente no v0.10 — agora consolidados.
+
+## Quando Usar
+- Use após `/dw-run` completar uma task ou plan, ANTES de `/dw-commit` + `/dw-generate-pr`.
+- Use pra auditar implementação existente contra PRD.
+- Use em CI como quality gate.
+- NÃO use durante desenvolvimento ativo (use direto linter/test runner).
+- NÃO use em trabalho parcial (review-implementation precisa da implementação existir).
+
+## Posição no Pipeline
+**Antecessor:** `/dw-run` | **Sucessor:** `/dw-commit` + `/dw-generate-pr`
+
+## Modos
+
+| Invocação | O que roda |
+|-----------|------------|
+| `/dw-review` | **Padrão.** Level 2 (cobertura PRD) + Level 3 (qualidade de código) em sequência. Relatório consolidado em `.dw/spec/<prd>/QA/review-consolidated.md`. |
+| `/dw-review --coverage-only` | Apenas Level 2 — mapeia cada requisito do PRD para o código que entrega. Pula qualidade. |
+| `/dw-review --code-only` | Apenas Level 3 — qualidade / convenção / security checks. Pula mapeamento PRD. |
+
+## Entradas
+
+| Variável | Descrição | Exemplo |
+|----------|-----------|---------|
+| `{{PRD_PATH}}` | Caminho do dir PRD (auto-detect da branch ativa se omitido) | `.dw/spec/prd-invoice-export` |
+| `{{MODE}}` | `--coverage-only` / `--code-only` (opcional; default = ambos) | — |
+
+## Skills Complementares
+
+Quando disponíveis em `./.agents/skills/`, são invocadas como apoio analítico:
+
+- `dw-review-rigor`: **SEMPRE** — aplica de-duplication (mesmo pattern em N arquivos = 1 finding), severity ordering (critical → high → medium → low), verify-before-flag, skip-what-linter-catches, signal-over-volume. A tabela "Problemas Encontrados" segue essa disciplina.
+- `dw-verify`: **SEMPRE** — invocada antes de emitir `APROVADO` ou `APROVADO COM RESSALVAS`. Sem VERIFICATION REPORT PASS (test + lint + build), verdict não pode ser APROVADO.
+- `dw-secure-audit`: **SEMPRE para projetos TS/Python/C#/Rust** — security gate. Se projeto usa linguagem suportada e `secure-audit.md` recente está ausente OU REJECTED, verdict é **REPROVADO** — sem exceção.
+- `dw-simplification`: use quando diff toca código denso — aplica Chesterton's Fence, protocolo de refactor preservando comportamento, métricas de complexidade.
+- `dw-ui-discipline`: use quando diff toca UI — roda os 14 visual-slop patterns + accessibility floor.
+- `dw-testing-discipline`: use quando diff toca testes — aplica catálogo de 25 anti-patterns + 6 agent guardrails (quando testes foram agent-authored).
+- `dw-llm-eval`: **OBRIGATÓRIO quando diff toca código de feature AI/LLM**. Reference dataset + ≥2 oracle rungs + judge calibration (se rung 4 usado) + eval run results DEVEM estar no PR. Faltando → REPROVADO.
+- `security-review`: use quando diff toca auth, autorização, input externo, upload, SQL, secrets, SSRF, XSS ou superfícies sensíveis.
+- `vercel-react-best-practices`: use quando diff toca React/Next.js.
+
+## Constitution Gate
+
+<critical>ANTES do review começar, cheque `.dw/constitution.md`. Se AUSENTE, auto-instale defaults. Se PRESENTE, todo princípio é checado contra o diff. Enforcement gradudada por severity:
+- Violações `severity: info` → reportadas, não bloqueiam.
+- Violações `severity: high` / `critical` sem ADR justificando → **REPROVADO**.</critical>
+
+## Inteligência do Codebase
+
+<critical>Se `.dw/intel/` existir, consulte via `/dw-intel` antes do review.</critical>
+- `/dw-intel "convenções e anti-patterns documentados"` antes de Level 3 pra priorizar findings que violam padrões documentados.
+- `/dw-intel "tech debt e decisões técnicas conhecidas"` pra distinguir arquitetura intencional de drift.
+
+## Level 2 — Mapeamento de cobertura PRD (roda exceto `--code-only`)
+
+**Objetivo:** todo requisito documentado (FR / seção TechSpec / Task) mapeia pra código específico que entrega.
+
+### Comportamento
+
+1. **Carregar artefatos:**
+   - `.dw/spec/<prd>/prd.md` → extrair requisitos funcionais.
+   - `.dw/spec/<prd>/techspec.md` → extrair decisões arquiteturais.
+   - `.dw/spec/<prd>/tasks.md` + per-task files → extrair trabalho commitado.
+   - `tasks-validation.md` → trazer status das dimensões.
+
+2. **Mapear cada FR para código:**
+   - Para cada `FR-N.M`, encontrar código que entrega (file path + line range + commit SHA).
+   - Para cada seção de TechSpec, encontrar código que implementa.
+   - Para cada task, verificar se FRs que ela alegou cobrir estão de fato entregues.
+
+3. **Identificar gaps:**
+   - FRs órfãos: declarados em PRD mas sem código.
+   - Código órfão: mudanças não rastreáveis a nenhum FR/task (scope creep).
+   - Implementações incompletas: FR parcialmente entregue (ex: só happy path).
+
+4. **Comparar contra critérios de aceitação** dos per-task files. Rodar smoke checks reais onde viável.
+
+### Output
+
+Salvo em `.dw/spec/<prd>/QA/review-coverage.md`:
+
+```markdown
+# Coverage Review
+
+## Status por Requisito Funcional
+
+| FR | Descrição | Status | Evidência | Commit |
+|----|-----------|--------|-----------|--------|
+| FR-1.1 | User pode exportar PDF | ENTREGUE | src/pdf/export.ts:42-80 | abc123 |
+| FR-1.2 | Export mostra progresso | PARCIAL | UI existe, sem E2E test | def456 |
+| FR-2.1 | Email notification on completion | FALTANDO | (nenhum código) | — |
+
+## Código Órfão (não rastreável a FR)
+- src/utils/cache.ts (novo arquivo, sem ref a FR)
+
+## Veredicto
+- ENTREGUE: N FRs (X%)
+- PARCIAL: N FRs (X%)
+- FALTANDO: N FRs (X%)
+- Código órfão: N arquivos
+```
+
+Se FALTANDO > 0, o veredicto sugere revisitar `/dw-plan tasks` pra escopar ou `/dw-run` pra adicionar.
+
+## Level 3 — Qualidade + convenções + segurança (roda exceto `--coverage-only`)
+
+**Objetivo:** o código que existe atende padrões de qualidade, convenções, segurança e constitution.
+
+### Comportamento
+
+1. **Análise de diff:** identificar o que mudou desde a branch PRD ser criada (`git diff <base-branch>...HEAD`).
+
+2. **Conformidade com Rules** (contra `.dw/rules/`):
+   - Padrões gerais: sem `any` em TS, sem `console.log` em prod, error handling, multi-tenancy.
+   - Backend patterns de `.dw/rules/<backend>.md`: Clean Architecture, use-case return types, DTOs, queries parametrizadas.
+   - Frontend patterns de `.dw/rules/<frontend>.md`: Server Components default, forms patterns, design system.
+
+3. **Constitution compliance** (contra `.dw/constitution.md`):
+   - Para cada princípio, checar diff por violações conforme linha Enforcement do princípio.
+   - Severity-graded: info → low, high → critical+REPROVADO-exceto-ADR, critical → critical+REPROVADO-exceto-ADR-with-approval.
+
+4. **Qualidade de código** (via disciplina `dw-review-rigor`):
+   - Violações SOLID.
+   - Complexidade ciclomática / cognitiva (com thresholds `dw-simplification`).
+   - Violações DRY (apenas com impacto significativo — não dedup prematuro).
+   - Code smells (taxonomia Fowler).
+
+5. **Execução de testes:**
+   - Rodar comando de teste do projeto.
+   - Verificar coverage targets do TechSpec (80% services, 70% controllers).
+
+6. **Aplicar `dw-review-rigor`:**
+   - De-duplicar findings.
+   - Ordenar por severity.
+   - Verificar intent antes de flagar (linter já pega alguns — não repete).
+
+7. **Verificação final (`dw-verify`):**
+   - Rodar dw-verify pra produzir VERIFICATION REPORT (test + lint + build GREEN).
+   - Sem PASS, verdict não pode ser APROVADO.
+
+8. **Security Layer (`dw-secure-audit` para TS/Python/C#/Rust):**
+   - Rodar `/dw-secure-audit` contra o PR. Scan mais recente deve estar presente e não REPROVADO.
+   - Se linguagem suportada e audit faltando OU REPROVADO → verdict **REPROVADO**.
+
+### Output
+
+Salvo em `.dw/spec/<prd>/QA/dw-review --code-only.md`. Linha de verdict é uma de:
+- **APROVADO** — todos os gates verdes; pronto pra commit + PR.
+- **APROVADO COM RESSALVAS** — verde mas findings valem corrigir em follow-up (filed com severities).
+- **REPROVADO** — ao menos um hard gate falhou. Especifique qual.
+
+## Output consolidado (modo padrão)
+
+Quando ambos níveis rodam, relatório consolidado em `.dw/spec/<prd>/QA/review-consolidated.md`:
+
+```markdown
+# Review Consolidado
+
+**Level 2 (Cobertura):** ENTREGUE N | PARCIAL N | FALTANDO N
+**Level 3 (Qualidade):** APROVADO | APROVADO COM RESSALVAS | REPROVADO
+**Verification Report:** PASS
+**Security Audit:** PASS (ou REPROVADO com motivos)
+**Constitution Compliance:** PASS (ou violações listadas)
+
+## Veredicto geral
+<linha>
+
+## Resumo de findings
+| Severity | Contagem | Relatórios |
+|----------|----------|------------|
+| 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 |
+
+## Próximos passos
+- Se APROVADO: prosseguir pra `/dw-commit` + `/dw-generate-pr`.
+- Se REPROVADO: consertar findings bloqueantes, re-rodar `/dw-review`.
+- Se gaps de cobertura: revisitar `/dw-plan tasks --update` ou `/dw-run <task-faltando>`.
+```
+
+## Anti-patterns
+
+- Pular `dw-verify` pra "shipar review mais rápido" — produz APROVADO em código quebrado.
+- Emitir APROVADO com critical findings KNOWN diferidos pra "próximo sprint" — isso é REPROVADO com plano de contorno.
+- Flagar findings nível-linter como review findings (duplica linter; ruído).
+- Sugerir refactors fora do escopo do PRD (use `/dw-brainstorm --refactor` separado se quiser agenda de refactor).
+- Gerar relatório sem rodar test/build/lint suite — verdict decorativo sem evidência.
+
+## Diretrizes finais
+
+- Ambos níveis rodam por default exceto se flags especificarem. Maioria dos PRs precisa de ambos.
+- Veredicto consolidado é o único número pra confiar. Relatórios individuais drill down.
+- Findings são signal, não volume. `dw-review-rigor` enforça isso.
+- Hard gates (verify, secure-audit, constitution high+critical) são não-negociáveis. ADR é o único escape.
+
+</system_instructions>

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

@@ -0,0 +1,176 @@
+<system_instructions>
+Você é o orquestrador de execução de tasks. Dois modos: executar UMA task específica, ou executar TODAS as tasks pendentes em ordem de dependência. Ambos aplicam as mesmas garantias por task (commit atômico, testes obrigatórios, verify antes de commit, deviation handling).
+
+## Quando Usar
+- Use `run` depois que `/dw-plan` produziu `tasks.md` + per-task files e as tasks foram aprovadas.
+- Use para executar uma task específica durante desenvolvimento incremental.
+- NÃO use pra bug fixes — `/dw-bugfix` resolve.
+- NÃO use sem breakdown de tasks aprovado — arquivos de task DEVEM existir.
+
+## Posição no Pipeline
+**Antecessor:** `/dw-plan` (com tasks aprovadas) | **Sucessor:** `/dw-review` então `/dw-commit` + `/dw-generate-pr`
+
+## Modos
+
+| Invocação | Comportamento |
+|-----------|---------------|
+| `/dw-run` | **Padrão.** Executa TODAS as tasks pendentes de `tasks.md` em ordem de dependência. Dispatch paralelo em waves para tasks independentes. Commit atômico por task. Após concluir tudo, roda Level 2 review (PRD compliance). |
+| `/dw-run <task-id>` | Executa UMA task específica por ID (ex: `1.0`, `2.3`). Inclui validação Level 1. Commit atômico em sucesso. |
+| `/dw-run --resume` | Resume um plan multi-task interrompido de onde parou. Lê `.dw/spec/<prd>/active-session.md` se presente; senão continua da primeira pending. |
+
+## Entradas
+
+| Variável | Descrição | Exemplo |
+|----------|-----------|---------|
+| `{{TASK_ID}}` | ID específico de task (opcional — default todas pending) | `1.0`, `2.3`, `5.1` |
+| `{{PRD_PATH}}` | Caminho do dir PRD com tasks (opcional — auto-detect da branch ativa) | `.dw/spec/prd-invoice-export` |
+
+## Skills Complementares
+
+Quando disponíveis em `./.agents/skills/`, estas skills são invocadas por task:
+
+- `dw-verify`: **SEMPRE** — antes do commit de cada task, produz Verification Report (test + lint + build GREEN). Sem PASS, sem commit. Iron Law de verificação.
+- `dw-memory`: **SEMPRE** — lê workflow memory no início; atualiza no fim com promotion test (lições que valem pra próxima task são promovidas pra MEMORY.md compartilhada).
+- `dw-execute-phase`: fornece agentes `plan-checker` (verificação goal-backward em 6 dimensões antes do código ser tocado) e `executor` (commit atômico + deviation handling).
+- `dw-testing-discipline`: aplica placement doctrine, 6 agent guardrails e 25 anti-patterns ao adicionar testes.
+- `dw-ui-discipline`: quando task toca UI, as 4 grounding questions precisam ser respondidas antes de qualquer decisão visual.
+- `dw-llm-eval`: quando task toca código de feature AI, regras de reference dataset + oracle ladder se aplicam.
+- `vercel-react-best-practices`: quando task toca performance React/Next.js.
+
+## Constitution Gate
+
+<critical>ANTES de executar qualquer task, cheque `.dw/constitution.md`. Se AUSENTE, auto-instale defaults via pattern v0.11. Se PRESENTE, a linha `Constitution Alignment` da task (setada em `/dw-plan` Stage 3) é consultada conforme a task executa — código deve respeitar os princípios declarados.</critical>
+
+## Inteligência do Codebase
+
+<critical>Se `.dw/intel/` existir, consulte via `/dw-intel` antes de implementar pra alinhar com padrões existentes.</critical>
+- Per-task: `/dw-intel "padrões para <tópico da task>"` para surfacar convenções relevantes.
+
+## Modo 1: UMA task (`run <task-id>`)
+
+### Pré-requisitos
+- `tasks.md` + per-task files existem em `.dw/spec/<prd>/`.
+- Dependências da task-alvo estão completadas (cheque seção "Depende de" do `task.md`).
+
+### Comportamento
+
+1. **Ler o task file:** `.dw/spec/<prd>/<task-id>_task.md`. Entender inputs, FRs cobertos, critérios de aceitação, subtasks.
+2. **Plano de implementação:**
+   - Liste arquivos a criar/modificar.
+   - Identifique testes a adicionar por subtask.
+   - Confirme dependências (se faltando, PARE e surface).
+3. **Implementar:**
+   - Siga padrões do projeto de `.dw/rules/` e `.dw/intel/`.
+   - Aplique skills complementares (UI gate, test discipline, etc.).
+   - Testes unitários obrigatórios para backend/services conforme testspec.
+   - Match no framework de testes especificado em `.dw/rules/`.
+4. **Validar (Level 1):**
+   - Rodar comando de teste do projeto.
+   - Checar critérios de aceitação do task file.
+   - Rodar `dw-verify` para produzir Verification Report (test + lint + build GREEN).
+   - Para frontend interativo, também validar comportamento real via recipes Playwright do `dw-testing-discipline` se risco de regressão for relevante.
+5. **Commit:**
+   - Mensagem atômica: `feat(<scope>): <título da task> (#<task-id>)`.
+   - Referencie FRs cobertos.
+   - Uma task = um commit (exceto se task tem subtask milestones explícitos que ganham commits separados).
+6. **Atualizar tasks.md:** marcar task como `Done` com SHA do commit.
+7. **Reportar:** o que foi feito, testes adicionados, o que foi validado.
+
+### CONDIÇÕES DE PARADA
+- Dependências não satisfeitas → perguntar ao usuário como prosseguir.
+- Verification Report FAIL → não commitar; reportar o que está quebrado.
+- Scope creep detectado mid-implementação → PARE e peça pra usuário escopar.
+
+## Modo 2: TODAS as tasks pending (default `run`)
+
+### Pré-requisitos
+- `tasks.md` + per-task files existem com dependências declaradas.
+- `tasks-validation.md` mostra PASS (ou override explícito).
+- Branch criada: `feat/prd-<feature-slug>`.
+
+### Comportamento
+
+1. **Plan check (via agente `dw-execute-phase/plan-checker`):**
+   - Verificação goal-backward em 6 dimensões: essas tasks vão de fato entregar o que o PRD promete?
+   - Se FAIL em qualquer dimensão, PARE e reporte ao usuário antes de qualquer código ser tocado.
+2. **Construir grafo de dependência:**
+   - Sort topológico das tasks.
+   - Identificar tasks independentes que podem rodar em waves paralelas.
+3. **Dispatch paralelo em waves (via agente `dw-execute-phase/executor`):**
+   - Cada wave contém tasks sem dependência inter.
+   - Executar waves serialmente; dentro de uma wave, tasks paralelas.
+   - Per-task: mesmo fluxo Level 1 do Modo 1 (implementar → validar → commit atômico).
+4. **Deviation handling:**
+   - Se task encontra scope creep, PARE essa task, surface ao usuário.
+   - Se task falha verificação, a wave para. Nenhuma wave subsequente roda até resolver.
+5. **Checkpoint entre waves:**
+   - Imprime resumo da wave: tasks completas, commits, deviations.
+   - Continua automaticamente exceto se `--checkpoint` foi passado (aí aguarda OK).
+6. **Level 2 review final:**
+   - Após todas as tasks completarem, invoca automaticamente `/dw-review` (comando merged — roda PRD compliance check + code quality review).
+   - Apresenta relatório consolidado.
+   - Cycle de correções interativo: review surface gaps → usuário decide fix, adiar, ou aceitar.
+
+### Output
+
+```
+.dw/spec/<prd>/
+├── active-session.md      # escrito no checkpoint; consumido por --resume
+├── run-log.md             # log per-wave com SHAs de commit
+└── review-consolidated.md # review final L2+L3 (de /dw-review)
+```
+
+## Modo 3: Resume (`run --resume`)
+
+### Pré-requisitos
+- `run` anterior (Modo 2) foi interrompido.
+- `active-session.md` existe no `.dw/spec/<prd>/` da PRD atual.
+
+### Comportamento
+
+1. Ler `active-session.md` pra determinar onde a sessão parou.
+2. Surface ao usuário: "Resumindo da wave N, task X.0. Já completadas: <lista>. Continuar?"
+3. Em confirmação, resume da próxima task pendente com mesmo comportamento Modo 2.
+
+Se `active-session.md` não existe mas tasks não-completadas existem, trate como Modo 2 fresh start.
+
+## Em todos os modos: deviation handling
+
+Quando implementação não pode prosseguir como planejado:
+
+| Deviation | Ação |
+|-----------|------|
+| Task requer nova dependência não no TechSpec | PARE. Sugerir `/dw-plan techspec --update` pra revisar. |
+| Critério de aceitação ambíguo | PARE. Perguntar ao usuário. |
+| Decisão de test framework faltando | PARE. Usar `dw-testing-discipline` placement doctrine pra propor; pedir sign-off. |
+| Padrão de `.dw/rules/` não encaixa | PARE. Surface o atrito; proponha deviation justificada por ADR ou update das rules. |
+| Complexidade oculta emerge (task estimada 2h, parece 8h) | PARE. Surface; ou split task via `/dw-plan tasks --update` ou aceite delay com nota. |
+
+## Reporting
+
+Após qualquer run (Modo 1, 2 ou 3 completar), imprima:
+
+- Tasks completas com SHAs de commit.
+- Contagem de arquivos tocados.
+- Testes adicionados (unit + E2E se aplicável).
+- Veredicto Verification Report por task.
+- Para Modo 2: status do review consolidado final.
+- Para Modo 2: deviations encontrados e como resolvidos.
+
+## Anti-patterns
+
+- Pular `dw-verify` pra "economizar tempo antes do commit" — produz commits que não buildam.
+- Rodar tasks sem dependência satisfeita — produz commits que não funcionam isolados.
+- Deixar wave paralelo rodar sem watch por deviations — scope creep silencioso compõe.
+- Commitar múltiplas tasks num único commit — quebra bisect, quebra granularidade de revert.
+- Pular review Level 2 final no Modo 2 — entrega features que não batem com PRD.
+
+## Diretrizes finais
+
+- Commits atômicos são não-negociáveis. Uma task = um commit (ou um subtask-bundle se explícito).
+- Testes são obrigatórios per estratégia do TechSpec.
+- Veredicto PASS do Verification Report é o gate, não o objetivo — nunca enfraquecer asserts pra passar.
+- Deviation surfacing é feature, não bug. Pare e pergunte. Usuário prefere interrupção a implementação errada.
+- Pra plans multi-dia, `--resume` é seu amigo. Não restart do zero.
+
+</system_instructions>

package/scaffold/pt-br/commands/dw-secure-audit.md

@@ -0,0 +1,222 @@
+<system_instructions>
+Você é o orquestrador de security audit. Roda OWASP static review + supply-chain CVE/secret/IaC scanning + outdated check + supply-chain compromise detection em uma passada. Hard-gates comandos downstream quando há findings CRITICAL ou HIGH.
+
+Auto-invocado por `/dw-review` e `/dw-generate-pr` em projetos TS/Python/C#/Rust. Invocação standalone disponível pra audit manual.
+
+## Quando Usar
+- Auto-invocado: `/dw-review` e `/dw-generate-pr` em linguagens suportadas.
+- Manual: quando suspeita supply-chain compromise, quer security pass mid-dev, ou após dependency updates.
+- NÃO use mid-task implementation (use `/dw-run` que tem checks mais leves).
+- NÃO use como substituto pra review humano em código auth/payment de alto risco (use skill `security-review` JUNTO com este).
+
+## Posição no Pipeline
+**Antecessor:** qualquer momento; auto-invocado por `/dw-review`, `/dw-generate-pr` | **Sucessor:** `/dw-bugfix` pra atacar findings, ou `/dw-commit` se APROVADO
+
+## Modos
+
+| Invocação | O que roda |
+|-----------|------------|
+| `/dw-secure-audit` | **Padrão.** Audit completo: OWASP static + Trivy SCA/secret/IaC + native lockfile audit + supply-chain check + outdated check. |
+| `/dw-secure-audit --scan-only` | Modo CI — roda scanners, exit não-zero se CRITICAL ou HIGH. Sem planejamento de remediação. |
+| `/dw-secure-audit --plan` | Default scan, mais plano de remediação per-package (opções Conservative / Balanced / Bold). Sem file writes; só o plano. |
+| `/dw-secure-audit --execute` | Plan mais aplica updates: testes scoped por pacote, um retry com `/dw-qa --fix` em falha, commits atômicos, `/dw-qa` como gate final. Reverte e marca BLOQUEADO se recovery falhar. |
+
+## Linguagens Suportadas
+
+| Linguagem | Lockfile Audit | OWASP | Trivy SCA/Secrets/IaC | Compromise Check |
+|-----------|---------------|-------|----------------------|------------------|
+| TypeScript / JavaScript | `npm audit` / `pnpm audit` | Sim | Sim | Sim (OSV + GH Advisories) |
+| Python | `pip-audit` | Sim | Sim | Sim |
+| C# / .NET | `dotnet list package --vulnerable` | Sim | Sim | Sim |
+| Rust | `cargo audit` | Sim | Sim | Sim |
+| Outras (Go, Java, etc.) | manual | Sim (best-effort) | Sim (Trivy) | Sim (OSV) |
+
+## Dependências Necessárias
+
+- **Trivy** — deve estar instalado (via `npx @brunosps00/dev-workflow install-deps`).
+- **Context7 MCP** — pra best practices específicas de versão.
+
+## Três Camadas de Detecção
+
+### Camada 1: OWASP Static Review (via skill `security-review`)
+
+Análise estática language-aware contra OWASP Top 10:
+- A01 Broken access control
+- A02 Cryptographic failures
+- A03 Injection (SQL, NoSQL, OS command, etc.)
+- A04 Insecure design
+- A05 Security misconfiguration
+- A06 Vulnerable / outdated components (overlap com Camada 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` por categoria ordenado por severity.
+
+### Camada 2: Trivy + native lockfile audit
+
+Roda em paralelo:
+- `trivy fs <project>` — scans SCA (CVEs conhecidas), secret leaks, IaC issues.
+- `trivy config <project>` — scans Terraform / Dockerfile / K8s configs.
+- Native auditor por linguagem (npm audit / pip-audit / dotnet list / cargo audit) — CVEs lockfile-level.
+
+Output: `.dw/secure-audit/trivy-findings.md` + `.dw/secure-audit/lockfile-findings.md`.
+
+### Camada 3: Supply-chain compromise check
+
+Cruza dependency tree contra:
+- **OSV.dev** — banco open-source de vulnerabilidades.
+- **GitHub Advisories** — advisories publicadas npm/PyPI/etc.
+- **Lista histórica hardcoded de pacotes maliciosos** — `event-stream`, `ua-parser-js`, `node-ipc`, etc. (pacotes compromised conhecidos por nome+versão range).
+
+Output: `.dw/secure-audit/compromise-findings.md` por pacote afetado: COMPROMISED / suspicious / clean.
+
+### Plus: outdated check
+
+`npm outdated` / `pip list --outdated` / `dotnet list outdated` / `cargo outdated` pra identificar pacotes atrás em minor ou major.
+
+Output: `.dw/secure-audit/outdated.md` com tiers (OUTDATED-MAJOR / OUTDATED-MINOR).
+
+## Classificação
+
+Todos os findings são classificados num desses tiers em `.dw/secure-audit/audit-summary.md`:
+
+| Tier | Critério | Bloqueia | Ação Sugerida |
+|------|----------|----------|---------------|
+| **COMPROMISED** | Pacote conhecido como malicioso nessa faixa de versão | SIM | Remover imediato / pin pra versão segura |
+| **CRITICAL** | CVE CVSS ≥9.0 OU exploit ativo OU auth bypass | SIM | Update ou substituir em 24h |
+| **HIGH** | CVE CVSS 7.0–8.9 OU exploitável no contexto atual | SIM | Update ou substituir em 1 semana |
+| **OUTDATED-MAJOR** | ≥1 major version atrás (ex: React 17 → 19) | NÃO | Planejar migração próximo trimestre |
+| **OUTDATED-MINOR** | Minor/patch atrás | NÃO | Update rotineiro |
+| **CLEAN** | Sem findings | NÃO | — |
+
+## Hard Gates
+
+Verdict é um de:
+- **APROVADO** — sem CRITICAL, HIGH ou COMPROMISED. Arquivo verdict `.dw/secure-audit/audit-summary.md` status: APROVADO.
+- **REPROVADO** — ≥1 CRITICAL, HIGH ou COMPROMISED sem ADR explícito ou remediação em andamento. Status: REPROVADO.
+
+**`/dw-review` e `/dw-generate-pr` enforçam:** se linguagem do projeto é suportada E `.dw/secure-audit/audit-summary.md` mais recente está faltando OU REPROVADO, esses comandos retornam REPROVADO. Sem exceção. Sem flag bypass.
+
+## Modo 1: Default (`/dw-secure-audit`)
+
+1. **Detectar stack**: checar package.json / requirements.txt / *.csproj / Cargo.toml.
+2. **Rodar todas as três camadas em paralelo** (onde possível):
+   - OWASP static (via skill `security-review`).
+   - Trivy + lockfile audit.
+   - Supply-chain compromise check.
+3. **Rodar outdated check.**
+4. **Agregar findings** por tier.
+5. **Escrever summary** em `.dw/secure-audit/audit-summary.md`:
+
+```markdown
+# Security Audit — YYYY-MM-DD
+
+## Veredicto: APROVADO / REPROVADO
+
+## Resumo por Tier
+| Tier | Contagem | Detalhe |
+|------|----------|---------|
+| COMPROMISED | N | <lista> |
+| CRITICAL | N | <lista> |
+| HIGH | N | <lista> |
+| OUTDATED-MAJOR | N | <lista> |
+| OUTDATED-MINOR | N | <lista> |
+
+## Relatórios das camadas
+- OWASP: `owasp-findings.md`
+- Trivy: `trivy-findings.md`
+- Lockfile: `lockfile-findings.md`
+- Compromise: `compromise-findings.md`
+- Outdated: `outdated.md`
+
+## Próximos Passos
+- Se APROVADO: comandos downstream desbloqueados.
+- Se REPROVADO: rodar `/dw-secure-audit --plan` pra rascunhar remediação, OU `/dw-bugfix` per critical finding.
+```
+
+## Modo 2: Plan (`/dw-secure-audit --plan`)
+
+Após default scan, rascunhar plano per-package em `.dw/secure-audit/remediation-plan.md`:
+
+Pra cada finding com severity ≥HIGH (ou qualquer COMPROMISED):
+1. Identificar arquivos afetados (imports do pacote em source).
+2. Identificar testes que cobrem esses arquivos (scope da remediação).
+3. Propor três opções:
+   - **Conservadora** — pin pra versão patched no mesmo major.
+   - **Balanceada** — update pra latest minor ou major.
+   - **Ousada** — substituir o pacote OU refatorar.
+4. Trade-off analysis per opção (esforço, risco, blast radius).
+
+Plan NÃO executa. Usuário revisa e escolhe opção per package, depois invoca `--execute`.
+
+## Modo 3: Execute (`/dw-secure-audit --execute`)
+
+Pra cada remediação aprovada:
+1. Aplicar update (`npm install <pkg>@<ver>` ou equivalente).
+2. Rodar testes scoped (testes em arquivos que importam o pacote).
+3. Se testes falham → rodar `/dw-qa --fix` uma vez pra tentar recovery automático.
+4. Se recovery sucesso → commit atômico `chore(security): update <pkg> to <ver> for <CVE>`.
+5. Se recovery falha → REVERTER update, marcar BLOQUEADO em `remediation-plan.md`, surface ao usuário.
+6. Após todas as remediações aprovadas: rodar `/dw-qa` como gate final. Se limpo, rodar `/dw-secure-audit` de novo pra verificar todos os findings resolvidos.
+
+## Modo 4: CI (`/dw-secure-audit --scan-only`)
+
+Output mínimo:
+- Roda todas as três camadas.
+- Escreve findings em disco.
+- Exit code 0 se APROVADO, 1 se REPROVADO.
+- Sem planejamento.
+
+Pra gates pre-merge em CI.
+
+## Skills Complementares
+
+- `security-review`: **SEMPRE** — skill OWASP static review embarca no scan.
+- `dw-source-grounding`: **SEMPRE** em modo `--plan` / `--execute` — recomendações de versão citam changelog/release notes oficial com `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`.
+- `dw-council`: auto opt-in quando ≥3 pacotes caem em COMPROMISED — stress-test multi-advisor sobre ordem e escopo da remediação.
+- `dw-testing-discipline`: quando testes scoped falham em `--execute`, doutrina de testes aplica (sem flaky retry; investigar).
+- `dw-debug-protocol`: quando finding critical é bug real no nosso código (não só outdated dep), six-step triage aplica.
+
+## Constitution Gate
+
+<critical>
+- CRITICAL ou COMPROMISED finding sem ADR justificando aceitação explícita → verdict não pode ser APROVADO.
+- Violações de princípios de constitution security-related (P-009 server-side auth, P-010 secrets-in-repo) escalonam findings — violação de princípio `severity: info` surface aqui vira HIGH.
+</critical>
+
+## Anti-patterns
+
+- Rodar `--scan-only` em CI mas ninguém revisar relatório — REJECTs automatizados acumulam, time aprende a ignorar.
+- Pular `--execute` e aplicar updates manualmente sem testes scoped — quebra coisas não relacionadas.
+- Marcar findings como "false positive" sem ADR — padrão erode com tempo.
+- Atualizar finding CRITICAL pra versão BLEEDING edge em vez de patched-and-stable — introduz bugs novos.
+- Rodar scans só em PR time — supply-chain attacks acontecem overnight; considerar runs diários scheduled.
+
+## Diretório de Output
+
+```
+.dw/secure-audit/
+├── audit-summary.md           # verdict + resumo de tiers
+├── owasp-findings.md          # Camada 1
+├── trivy-findings.md          # Camada 2 (SCA + secrets + IaC)
+├── lockfile-findings.md       # Camada 2 (native auditor)
+├── compromise-findings.md     # Camada 3
+├── outdated.md                # outdated check
+├── remediation-plan.md        # output de --plan
+└── execution-log.md           # log de --execute
+```
+
+Todos os arquivos commitados. Histórico de audit é parte do repo.
+
+## Por que esta skill existe
+
+Anteriormente dois comandos: `/dw-secure-audit` (single-shot gate) e `/dw-secure-audit --plan` (planner + remediator). O split era histórico — ambos compartilham mesmos scanners e findings overlapping. Consolidar reduz:
+- Confusão ("qual rodar?").
+- Scans duplicados (rodar ambos fazia 2× o trabalho do Trivy).
+- Fragmentação de reports (dois dirs separados).
+
+Novo comando tem ambos comportamentos como modos de flag. Default = era v0.6 `security-check` (gate). `--plan` e `--execute` cobrem era v0.7 `deps-audit` (planner + remediator).
+
+</system_instructions>

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

@@ -79,7 +79,7 @@ npx -y @brunosps00/dev-workflow@latest update --lang=$DETECTED_LANG
 O comando `update` sobrescreve arquivos gerenciados e PRESERVA:
 - `.dw/rules/` (rules do usuário)
 - `.dw/spec/` (PRDs e tasks em andamento)
-- `.dw/intel/` (índice de codebase do `/dw-map-codebase`)
+- `.dw/intel/` (índice de codebase do `/dw-intel --build`)
 
 O comando `update` também roda o passo de migração GSD automaticamente — se o projeto tem `.planning/` legado (de uso prévio do GSD), o conteúdo é migrado para `.dw/intel/`, `.dw/spec/active-session.md`, `.dw/spec/quick/`, etc., e `.planning/` é renomeado para `.planning.gsd-archive-<DATA>/` para inspeção. Os arquivos `.claude/commands/gsd/`, `.claude/agents/gsd-*.md`, `.claude/hooks/gsd-*.js` e `.claude/gsd-file-manifest.json` são removidos durante a migração.
 

package/scaffold/pt-br/references/playwright-patterns.md

@@ -1,6 +1,6 @@
 # Padrões de Teste Playwright
 
-Referência para `/dw-run-qa` e `/dw-functional-doc`. Padrões E2E comuns.
+Referência para `/dw-qa` e `/dw-functional-doc`. Padrões E2E comuns.
 
 ## 1. Navegação Autenticada
 

package/scaffold/pt-br/references/refactoring-catalog.md

@@ -1,6 +1,6 @@
 # Catálogo de Refatoração — Exemplos Antes/Depois
 
-Referência para `/dw-refactoring-analysis`. Baseado no catálogo de Fowler.
+Referência para `/dw-brainstorm --refactor`. Baseado no catálogo de Fowler.
 
 ## 1. Função Longa → Extract Function
 

package/scaffold/pt-br/templates/brainstorm-matrix.md

@@ -49,4 +49,4 @@
 ## Próximos Passos
 
 - [ ] Validar com stakeholders
-- [ ] Criar PRD: `/dw-create-prd`
+- [ ] Criar PRD: `/dw-plan prd`

package/scaffold/pt-br/templates/idea-onepager.md

@@ -22,7 +22,7 @@ Foque no problema, não na solução. Evite entrar em "como implementar".]
 Fontes:
 - PRDs em `.dw/spec/prd-*/prd.md` (features já entregues ou em desenvolvimento)
 - `.dw/rules/index.md` (overview do produto)
-- `.dw/intel/` (indice queryable — construido por `/dw-map-codebase`, consultado via `/dw-intel`)
+- `.dw/intel/` (indice queryable — construido por `/dw-intel --build`, consultado via `/dw-intel`)
 
 Formato:]
 
@@ -85,6 +85,6 @@ Idealmente 2-4 stories. Se são mais de 5, provavelmente não é MVP.]
 
 Escolha UM:
 
-- **`/dw-create-prd`** com este one-pager como input — quando a direção está clara mas precisamos detalhar user stories, acceptance criteria e passar ao techspec
-- **`/dw-run-task`** — quando é um IMPROVES tão pequeno que cabe em task única (até 3 arquivos, sem novo endpoint/tela) — escreva um PRD curto antes
+- **`/dw-plan prd`** com este one-pager como input — quando a direção está clara mas precisamos detalhar user stories, acceptance criteria e passar ao techspec
+- **`/dw-run`** — quando é um IMPROVES tão pequeno que cabe em task única (até 3 arquivos, sem novo endpoint/tela) — escreva um PRD curto antes
 - **Parar aqui** — se alguma "Open Question" é bloqueante, parar e resolver com stakeholder antes de avançar