@brunosps00/dev-workflow 0.15.0 → 1.0.0

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

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

@@ -94,12 +94,12 @@ services: []
 
 ## Escopo MVP
 
-[A primeira feature menor que voce vai entregar. Pensada como user stories — vai dirigir a primeira rodada de /dw-create-prd.]
+[A primeira feature menor que voce vai entregar. Pensada como user stories — vai dirigir a primeira rodada de /dw-plan prd.]
 
 - Como [persona], eu posso [acao] para que [beneficio]
 - Como [persona], eu posso [acao] para que [beneficio]
 
-Se voce ainda nao tem a primeira feature em mente, tudo bem — deixa placeholder e roda o /dw-create-prd quando tiver.
+Se voce ainda nao tem a primeira feature em mente, tudo bem — deixa placeholder e roda o /dw-plan prd quando tiver.
 
 ## Nao Estou Fazendo (explicito)
 
@@ -115,7 +115,7 @@ Se voce ainda nao tem a primeira feature em mente, tudo bem — deixa placeholde
 
 ## Perguntas em Aberto
 
-[O que este one-pager nao consegue responder sozinho. Resolva antes do /dw-create-prd ou escale para um stakeholder.]
+[O que este one-pager nao consegue responder sozinho. Resolva antes do /dw-plan prd ou escale para um stakeholder.]
 
 - [pergunta 1]
 - [pergunta 2]
@@ -124,6 +124,6 @@ Se voce ainda nao tem a primeira feature em mente, tudo bem — deixa placeholde
 
 Escolha UM:
 
-- **`/dw-create-prd`** — quando voce tem a primeira feature em mente e quer rascunhar o PRD em cima deste stack
+- **`/dw-plan prd`** — quando voce tem a primeira feature em mente e quer rascunhar o PRD em cima deste stack
 - **`/dw-analyze-project`** — apos primeiro commit substancial, para enriquecer `.dw/rules/` com convencoes por modulo
-- **`/dw-deps-audit --scan-only`** — para confirmar que nenhuma dep vulneravel veio dos templates `create-*`
+- **`/dw-secure-audit --plan --scan-only`** — para confirmar que nenhuma dep vulneravel veio dos templates `create-*`

package/scaffold/pt-br/templates/tasks-template.md

@@ -34,7 +34,7 @@ feat/prd-[nome-funcionalidade]
 ## Workflow
 
 Cada task segue o fluxo:
-1. `/dw-run-task [N]_task.md` - Implementa a task
+1. `/dw-run [N]_task.md` - Implementa a task
 2. Testes unitários incluídos na implementação
 3. Commit ao final da task (sem push)
 4. Próxima task ou `/dw-generate-pr [branch-alvo]` quando todas concluídas

package/scaffold/skills/api-testing-recipes/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: api-testing-recipes
-description: Validated API-testing snippets (.http, pytest+httpx, supertest, WebApplicationFactory, reqwest) used by /dw-run-qa and /dw-fix-qa when the project has no UI. Default format is .http (REST Client) for IDE portability.
+description: Use for API testing recipes (.http, pytest+httpx, supertest, WebApplicationFactory, reqwest). Invoked by /dw-qa in API mode and when authoring API tests. Default format is .http for IDE portability.
 allowed-tools:
   - Read
   - Write
@@ -10,7 +10,7 @@ allowed-tools:
 
 # api-testing-recipes
 
-Curated library of **API-testing snippets** that `/dw-run-qa` and `/dw-fix-qa` use when a project is API-only (no Playwright). Each recipe is a ready-to-customize block per stack; the default is `.http` (REST Client) for maximum portability across IDEs.
+Curated library of **API-testing snippets** that `/dw-qa` and `/dw-qa --fix` use when a project is API-only (no Playwright). Each recipe is a ready-to-customize block per stack; the default is `.http` (REST Client) for maximum portability across IDEs.
 
 ## Why a skill (not inline)
 
@@ -22,14 +22,14 @@ Curated library of **API-testing snippets** that `/dw-run-qa` and `/dw-fix-qa` u
 
 Read this skill when:
 
-- `/dw-run-qa` detected API mode (no UI deps in the manifest) or was invoked with `--api`.
-- `/dw-fix-qa` is retesting a bug whose `evidence_type` is `api-log`.
+- `/dw-qa` detected API mode (no UI deps in the manifest) or was invoked with `--api`.
+- `/dw-qa --fix` is retesting a bug whose `evidence_type` is `api-log`.
 - Generating a baseline test suite from an OpenAPI spec.
 - Authoring contract checks against a backend.
 
 Do NOT use when:
 
-- The project has a UI and `/dw-run-qa` is in UI mode → use Playwright MCP instead.
+- The project has a UI and `/dw-qa` is in UI mode → use Playwright MCP instead.
 - The user wants browser-level acceptance (forms, navigation, accessibility) — that's Playwright territory.
 
 ## Available Recipes
@@ -49,7 +49,7 @@ Picking order:
 
 ## How to Compose
 
-The composing command (`/dw-run-qa` API mode) follows this loop:
+The composing command (`/dw-qa` API mode) follows this loop:
 
 1. **Pick the recipe** based on the rules above.
 2. **Read the recipe file** (`recipes/<name>.md`) for the variable conventions, test-matrix shape, and an example block.

package/scaffold/skills/api-testing-recipes/references/auth-patterns.md

@@ -135,4 +135,4 @@ Add one env var per role; the recipe reads them as needed. Tests that don't need
 
 ## What `dw-run-qa` does
 
-In API mode, `/dw-run-qa` reads `QA/test-credentials.md` (or `.env`) for the env var names, picks the recipe, and substitutes variables at test-generation time. The script files reference `@variable` references only — never raw tokens.
+In API mode, `/dw-qa` reads `QA/test-credentials.md` (or `.env`) for the env var names, picks the recipe, and substitutes variables at test-generation time. The script files reference `@variable` references only — never raw tokens.

package/scaffold/skills/api-testing-recipes/references/matrix-conventions.md

@@ -65,4 +65,4 @@ That's 9 test cases for one RF — the floor for a real API surface, not the cei
 
 ## How `dw-run-qa` uses this
 
-When in API mode, `/dw-run-qa` walks each `RF-XX` in the PRD, runs through this matrix, and emits PASS/FAIL per RF — not per test case. A single FAIL in any tier marks the RF as FAIL and lands a `BUG-NN` entry pointing to the failing log line.
+When in API mode, `/dw-qa` walks each `RF-XX` in the PRD, runs through this matrix, and emits PASS/FAIL per RF — not per test case. A single FAIL in any tier marks the RF as FAIL and lands a `BUG-NN` entry pointing to the failing log line.

package/scaffold/skills/api-testing-recipes/references/openapi-driven.md

@@ -1,6 +1,6 @@
 # OpenAPI-driven mode — generating tests from a spec
 
-When the project exposes an OpenAPI spec (static `openapi.yaml`/`openapi.json`, or dynamic `/openapi.json` for FastAPI), `/dw-run-qa` can derive a baseline test suite directly from it. This catches contract drift between code and spec for free.
+When the project exposes an OpenAPI spec (static `openapi.yaml`/`openapi.json`, or dynamic `/openapi.json` for FastAPI), `/dw-qa` can derive a baseline test suite directly from it. This catches contract drift between code and spec for free.
 
 ## When to use this mode
 
@@ -20,13 +20,13 @@ The generated tests live alongside hand-written ones in `{{PRD_PATH}}/QA/scripts
 
 ## How to run it
 
-`/dw-run-qa --from-openapi <spec-path-or-url>` — explicit. The `<spec-path-or-url>` can be:
+`/dw-qa --from-openapi <spec-path-or-url>` — explicit. The `<spec-path-or-url>` can be:
 
 - `./openapi.yaml`
 - `http://localhost:3000/openapi.json` (FastAPI default)
 - `http://localhost:3000/swagger/v1/swagger.json` (ASP.NET Core default)
 
-Without the flag, `/dw-run-qa` auto-detects:
+Without the flag, `/dw-qa` auto-detects:
 
 - File at repo root: `openapi.yaml`, `openapi.json`, `swagger.yaml`, `swagger.json`.
 - Project running locally: `GET /openapi.json`, `GET /swagger/v1/swagger.json`, `GET /api-docs`.

package/scaffold/skills/docker-compose-recipes/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: docker-compose-recipes
-description: Validated docker-compose service blocks (postgres, redis, mailhog, minio, meilisearch, jaeger, traefik, etc.) for dev and prod, composed by /dw-new-project and /dw-dockerize. Each service is a standalone YAML with healthcheck, named volume, and env conventions.
+description: Use for docker-compose service blocks (postgres, redis, mailhog, minio, meilisearch, jaeger, traefik). Invoked by /dw-new-project, /dw-dockerize, or when composing dev/prod compose files.
 allowed-tools:
   - Read
   - Write