@brunosps00/dev-workflow 0.13.0 → 1.0.0

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)

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

@@ -15,18 +15,18 @@ Uma etapa que invoca um comando `/dw-xxx` SO e considerada completa quando os ar
 | Pensamento | Realidade |
 |------------|-----------|
 | "Ja rodei os testes manualmente" | O comando produz artefatos estruturados. Rode o comando. |
-| "Validei via Playwright ad-hoc" | `/dw-run-qa` exige matriz por RF, bugs.md, screenshots, scripts, logs, checklist. Rode o comando. |
-| "A implementacao esta obviamente correta" | `/dw-review-implementation` exige matriz de compliance por RF/endpoint/task. Rode o comando. |
+| "Validei via Playwright ad-hoc" | `/dw-qa` exige matriz por RF, bugs.md, screenshots, scripts, logs, checklist. Rode o comando. |
+| "A implementacao esta obviamente correta" | `/dw-review --coverage-only` exige matriz de compliance por RF/endpoint/task. Rode o comando. |
 | "Validacao manual forte ja basta" | NAO. Equivalencia tecnica NAO substitui a execucao formal. |
 | "Ja conferi build e lint, e suficiente" | Build/lint NAO substituem review nem QA. Rode os comandos. |
-| "Gerei um qa-report.md resumido a mao" | Um arquivo solto NAO e execucao de `/dw-run-qa`. A arvore `QA/` completa e obrigatoria. |
+| "Gerei um qa-report.md resumido a mao" | Um arquivo solto NAO e execucao de `/dw-qa`. A arvore `QA/` completa e obrigatoria. |
 | "O autopilot ja avancou, nao preciso voltar" | Se o artefato nao existe, a etapa nao rodou. Volte e execute. |
-| "Corrigi bugs no caminho, entao o QA ja esta ok" | Corrigir bugs nao substitui rodar o QA formal. Rode `/dw-run-qa`. |</critical>
+| "Corrigi bugs no caminho, entao o QA ja esta ok" | Corrigir bugs nao substitui rodar o QA formal. Rode `/dw-qa`. |</critical>
 
 ## Quando Usar
 - Use quando quiser ir de uma ideia ate um PR com minima intervencao manual
 - Use para features completas que passam por todo o pipeline (pesquisa, planejamento, execucao, qualidade)
-- NAO use para tasks pequenas e bem-escopadas — use `/dw-run-task` direto com um PRD curto
+- NAO use para tasks pequenas e bem-escopadas — use `/dw-run` direto com um PRD curto
 - NAO use para corrigir bugs (use `/dw-bugfix`)
 - NAO use quando quiser controle manual entre cada fase (use os comandos individuais)
 
@@ -72,12 +72,12 @@ Se este comando for re-invocado no mesmo PRD apos interrupcao:
 
 - Consulte `.dw/intel/` via `/dw-intel` para entender o contexto do projeto
 - Identifique: stack tecnologica, padroes existentes, features relacionadas
-- Se `.dw/intel/` esta ausente, sugira rodar `/dw-map-codebase` primeiro para contexto downstream mais rico
+- Se `.dw/intel/` esta ausente, sugira rodar `/dw-intel --build` primeiro para contexto downstream mais rico
 
 ### Etapa 2: Pesquisa (Condicional)
 
 Avalie se o topico necessita de pesquisa profunda:
-- **SIM** (execute `/dw-deep-research`): tecnologia nova para o projeto, dominio desconhecido, integracoes com APIs externas, decisoes arquiteturais criticas
+- **SIM** (execute `/dw-brainstorm --research`): tecnologia nova para o projeto, dominio desconhecido, integracoes com APIs externas, decisoes arquiteturais criticas
 - **NAO** (pule para etapa 3): feature simples no dominio ja mapeado, refatoracao de algo existente, CRUD basico
   - Se pular, DOCUMENTE o motivo no bloco de progresso. Ex: "Pesquisa pulada — dominio ja mapeado em .dw/rules/[arquivo].md". O usuario deve ver a justificativa.
 
@@ -94,7 +94,7 @@ Execute `/dw-brainstorm` com o contexto acumulado (intel + pesquisa).
 
 <critical>O PRD DEVE incluir entrevista interativa com o usuario. Faca NO MINIMO 7 perguntas de esclarecimento ANTES de redigir o PRD. NAO responda as perguntas automaticamente com base no contexto — o usuario DEVE responder.</critical>
 
-Execute `/dw-create-prd` usando os findings do brainstorm.
+Execute `/dw-plan prd` usando os findings do brainstorm.
 - Siga TODAS as instrucoes do comando, especialmente a secao de perguntas de esclarecimento
 - Faca pelo menos 7 perguntas ao usuario sobre: problema, usuarios-alvo, funcionalidades criticas, escopo, restricoes, design, integracao
 - Em cada pergunta, apresente uma recomendacao embasada nos findings do brainstorm e do deep-research (se executado). Ex: "Com base na pesquisa, recomendo X porque [evidencia]. Concorda ou prefere outra direcao?"
@@ -115,7 +115,7 @@ Apresente ao usuario:
 
 <critical>O TechSpec DEVE incluir entrevista interativa com o usuario. Faca NO MINIMO 7 perguntas de esclarecimento tecnico ANTES de redigir o TechSpec. NAO responda as perguntas automaticamente — o usuario DEVE responder.</critical>
 
-Execute `/dw-create-techspec` a partir do PRD aprovado.
+Execute `/dw-plan techspec` a partir do PRD aprovado.
 - Siga TODAS as instrucoes do comando, especialmente a secao de perguntas de esclarecimento
 - Faca pelo menos 7 perguntas ao usuario sobre: arquitetura preferida, libs existentes vs novas, estrategia de testes, integracao com sistemas existentes, restricoes de infraestrutura, performance, seguranca
 - Em cada pergunta, apresente uma recomendacao tecnica embasada nos findings do brainstorm, deep-research e PRD aprovado. Ex: "A pesquisa indicou que a lib X tem melhor performance para este caso [fonte]. Quer usar X ou tem outra preferencia?"
@@ -125,7 +125,7 @@ Execute `/dw-create-techspec` a partir do PRD aprovado.
 
 ### Etapa 6: Tasks
 
-Execute `/dw-create-tasks` a partir do PRD + TechSpec.
+Execute `/dw-plan tasks` a partir do PRD + TechSpec.
 - Siga todas as instrucoes do comando
 - Gere tasks individuais em `.dw/spec/prd-[nome]/`
 
@@ -148,9 +148,9 @@ Avalie se as tasks envolvem frontend:
 
 ### Etapa 8: Execucao
 
-Execute `/dw-run-plan` com o path do PRD.
+Execute `/dw-run` com o path do PRD.
 - Siga TODAS as instrucoes do comando, incluindo o gate nativo do plan-checker (PASS obrigatorio) e execucao paralela em waves via os agentes da skill bundled `dw-execute-phase`
-- Cada task segue `/dw-run-task` com validacao Level 1
+- Cada task segue `/dw-run` com validacao Level 1
 
 ### Etapa 9: Review de Implementacao (Loop)
 
@@ -164,7 +164,7 @@ Execute build e lint do projeto:
 5. Repita ate que build E lint passem sem erros
 6. So entao prossiga para o review
 
-Execute `/dw-review-implementation` para verificar PRD compliance (Level 2).
+Execute `/dw-review --coverage-only` para verificar PRD compliance (Level 2).
 - Se encontrar gaps: corrija automaticamente e re-execute o review
 - Maximo 3 ciclos de correcao
 - NAO avance para QA ate que o review passe
@@ -177,7 +177,7 @@ Um review textual curto, um "parece ok" ou conclusao "implementacao correta" SEM
 
 ### Etapa 10: QA Visual
 
-Execute `/dw-run-qa` com Playwright MCP.
+Execute `/dw-qa` com Playwright MCP.
 - Teste happy paths, edge cases, fluxos negativos, acessibilidade
 - Documente bugs com screenshots
 
@@ -188,12 +188,12 @@ Execute `/dw-run-qa` com Playwright MCP.
 - `{{PRD_PATH}}/QA/screenshots/` — diretorio existe e contem pelo menos 1 PNG por RF testado (formato `RF-XX-[slug]-PASS.png` ou `-FAIL.png`)
 - `{{PRD_PATH}}/QA/scripts/` — diretorio existe e contem scripts Playwright `.spec.ts`/`.spec.js` por RF
 - `{{PRD_PATH}}/QA/logs/` — diretorio existe com logs de console/rede capturados
-Rodar Playwright ad-hoc, tirar algumas screenshots soltas ou escrever um qa-report.md curto a mao NAO substitui esta estrutura. Se qualquer artefato estiver ausente ou incompleto, o comando NAO rodou — invoque `/dw-run-qa` formalmente e siga o fluxo dele ate o fim.</critical>
+Rodar Playwright ad-hoc, tirar algumas screenshots soltas ou escrever um qa-report.md curto a mao NAO substitui esta estrutura. Se qualquer artefato estiver ausente ou incompleto, o comando NAO rodou — invoque `/dw-qa` formalmente e siga o fluxo dele ate o fim.</critical>
 
 ### Etapa 11: Fix QA (Condicional)
 
 Se o QA encontrou bugs:
-- Execute `/dw-fix-qa` para corrigir e retestar
+- Execute `/dw-qa --fix` para corrigir e retestar
 - Loop ate estabilizar (maximo 5 ciclos). Apos 5 ciclos, PARE e pergunte ao usuario como deseja prosseguir.
 
 ### Etapa 12: Review de Implementacao (Pos-QA)
@@ -205,7 +205,7 @@ Execute build e lint do projeto (mesma sequencia da Etapa 9):
 2. Build
 3. Se falhar: corrija e re-execute ate passar
 
-Execute `/dw-review-implementation` novamente para confirmar que as correcoes do QA nao quebraram PRD compliance.
+Execute `/dw-review --coverage-only` novamente para confirmar que as correcoes do QA nao quebraram PRD compliance.
 - Se encontrar gaps: corrija e re-execute
 - Maximo 3 ciclos
 
@@ -213,7 +213,7 @@ Execute `/dw-review-implementation` novamente para confirmar que as correcoes do
 
 ### Etapa 13: Code Review
 
-Execute `/dw-code-review` (Level 3) para review formal.
+Execute `/dw-review --code-only` (Level 3) para review formal.
 - Gere relatorio persistido
 
 ### Etapa 14: Commit
@@ -227,7 +227,7 @@ Rode `ls` em cada caminho abaixo e confirme existencia. Se QUALQUER um faltar, N
 - `{{PRD_PATH}}/QA/screenshots/` (nao vazio)
 - `{{PRD_PATH}}/QA/scripts/` (nao vazio com arquivos `.spec.*`)
 - `{{PRD_PATH}}/QA/logs/`
-- Evidencia do ultimo `/dw-review-implementation` com matriz RF-by-RF (output da sessao ou referencia em `autopilot-state.json`)
+- Evidencia do ultimo `/dw-review --coverage-only` com matriz RF-by-RF (output da sessao ou referencia em `autopilot-state.json`)
 
 Verifique tambem `autopilot-state.json`:
 - Toda etapa de 1 a 13 que NAO esta em `skipped_steps` deve estar em `completed_steps`
@@ -250,7 +250,7 @@ Pergunte ao usuario: **"Commits realizados. Deseja gerar o Pull Request?"**
 
 ## Engine Nativo
 
-O autopilot depende de infraestrutura dev-workflow-native para inteligencia de codebase (`/dw-map-codebase` + `/dw-intel`) e dos agentes bundled de execucao de fase (plan-checker + executor em `.agents/skills/dw-execute-phase/agents/`). Tudo bundled, sem dependencias externas. Veja as skills bundled `dw-codebase-intel` e `dw-execute-phase` em `.agents/skills/` para detalhes.
+O autopilot depende de infraestrutura dev-workflow-native para inteligencia de codebase (`/dw-intel --build` + `/dw-intel`) e dos agentes bundled de execucao de fase (plan-checker + executor em `.agents/skills/dw-execute-phase/agents/`). Tudo bundled, sem dependencias externas. Veja as skills bundled `dw-codebase-intel` e `dw-execute-phase` em `.agents/skills/` para detalhes.
 
 ## Persistencia de Estado
 

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

@@ -9,14 +9,16 @@ Você é um facilitador de brainstorming para o workspace atual. Este comando ex
 - NÃO use quando já tiver requisitos claros prontos para um PRD, ou quando precisar implementar código
 
 ## Posição no Pipeline
-**Antecessor:** (ideia do usuário) | **Sucessor:** `/dw-create-prd`
+**Antecessor:** (ideia do usuário) | **Sucessor:** `/dw-plan prd`
 
 ## Flags
 
 - **(padrão)**: brainstorm normal com 3-7 opções (conservadora, equilibrada, ousada) e trade-offs. Se o produto tem PRDs ou rules, **Product Inventory** é produzido automaticamente e cada opção recebe tag de classificação.
-- **`--onepager`**: ao final do brainstorm, gera um one-pager durável em `.dw/spec/ideas/<slug>.md` (usando `.dw/templates/idea-onepager.md`) com Feature Inventory + Classification & Rationale + MVP Scope + Not Doing + Assumptions. Use quando quiser um artefato de produto persistido antes de seguir para `/dw-create-prd`.
+- **`--onepager`**: ao final do brainstorm, gera one-pager durável em `.dw/spec/ideas/<slug>.md` (usando `.dw/templates/idea-onepager.md`) com Feature Inventory + Classification & Rationale + MVP Scope + Not Doing + Assumptions. Use quando quiser artefato persistido antes de seguir para `/dw-plan prd`.
 - **`--council`**: após o brainstorm normal, invoca a skill `dw-council` para stress-test das top 2-3 opções através de 3-5 archetypes (pragmatic-engineer, architect-advisor, security-advocate, product-mind, devils-advocate). Útil quando a escolha é de alto impacto e há genuine dissent entre caminhos.
-- Flags são combináveis: `--onepager --council` produz one-pager após debate do council.
+- **`--research`**: modo de research multi-source. Pipeline: scope → plan → retrieve (sources paralelos) → triangulate → outline-refine → synthesize → critique → refine → report. Output: documento citado. Use pra state-of-the-art reviews, comparações de tech, regulatory landscape mapping. Sub-modos: `quick` (3 fases, 2-5min), `standard` (default, 6 fases, 5-10min), `deep` (8 fases, 10-20min), `ultradeep` (8+ fases, 20-45min).
+- **`--refactor`**: modo catálogo de code smells. Audita um diretório-alvo ou escopo de PRD por smells usando taxonomia de Martin Fowler (bloaters, change preventers, dispensables, couplers, complexidade condicional, violações DRY). Mapeia cada smell pra técnica de refactoring com sketches before/after. Plano severity-ordered P0-P3. Output: documento de oportunidades de refactor.
+- Flags combináveis onde faz sentido: `--onepager --council` produz one-pager após debate. `--research --onepager` salva research como one-pager durável. `--refactor --onepager` salva plano de refactor como one-pager. `--research --refactor` NÃO suportado (escolha um — surfaces de ideação diferentes).
 
 ## Fluxograma de Decisão: Brainstorm vs PRD Direto
 
@@ -27,7 +29,7 @@ digraph brainstorm_decision {
   Q1 [label="Are requirements\nclear and specific?"];
   Q2 [label="Are there multiple\nviable approaches?"];
   node [shape=box];
-  PRD [label="Go directly to\n/dw-create-prd"];
+  PRD [label="Go directly to\n/dw-plan prd"];
   BS [label="Start with\n/dw-brainstorm"];
   Q1 -> PRD [label="Yes"];
   Q1 -> Q2 [label="No"];
@@ -108,10 +110,10 @@ Use este comando quando o usuario quiser:
 ### 7. Próximos passos
 - lista curta e executavel
 - se apropriado, sugira qual comando usar em seguida:
-  - `/dw-create-prd` (principal sucessor; aceita one-pager como input reduzindo perguntas de clarificação)
-  - `/dw-run-task` (se é IMPROVES pequeno que cabe em task única com um PRD curto)
-  - `/dw-create-techspec`
-  - `/dw-create-tasks`
+  - `/dw-plan prd` (principal sucessor; aceita one-pager como input reduzindo perguntas de clarificação)
+  - `/dw-run` (se é IMPROVES pequeno que cabe em task única com um PRD curto)
+  - `/dw-plan techspec`
+  - `/dw-plan tasks`
   - `/dw-bugfix`
 
 ## Heuristicas
@@ -140,6 +142,155 @@ Ao final, sempre deixe o usuario em uma destas situacoes:
 - com perguntas melhores para decidir
 - com um proximo comando do workspace para seguir
 - com o one-pager em `.dw/spec/ideas/<slug>.md` (se `--onepager` foi usado)
+- com o relatório de research em `~/Documents/<Tópico>_Research_<data>/` (se `--research`)
+- com o plano de refactor em `<target>/refactor-plan.md` (se `--refactor`)
+
+## Modo: `--research` (research multi-fonte)
+
+Ativado pela flag `--research`. Substitui o brainstorm padrão por um pipeline estruturado de research que produz documento citado com claims verificados.
+
+<critical>Cada afirmação factual DEVE ser citada imediatamente com [N] na mesma frase</critical>
+<critical>NUNCA fabrique citações — se não encontrar fonte, diga explicitamente</critical>
+<critical>A bibliografia DEVE conter TODAS as citações usadas no corpo, sem abreviações ou ranges</critical>
+
+### Quando usar modo research
+- Comparações multi-fonte (ex: "compare React Server Components vs Astro Islands").
+- State-of-the-art reviews de um tópico.
+- Mapeamento de contexto regulatório ou industrial.
+- Decisões precisando de evidência citada (não opinião).
+- NÃO use research mode pra lookups simples, debugging ou perguntas respondíveis em 1-2 web searches.
+
+### Sub-modos (research depth)
+
+```
+Seleção
+├── Exploração inicial → quick (3 fases, 2-5 min)
+├── Research padrão → standard (6 fases, 5-10 min) [DEFAULT pra --research]
+├── Decisão crítica → deep (8 fases, 10-20 min)
+└── Review abrangente → ultradeep (8+ fases, 20-45 min)
+```
+
+### Required reading
+
+Skill complementar **`dw-source-grounding`**: **SEMPRE** — aplica protocolo Detect → Fetch → Implement → Cite com hierarquia estrita (docs oficiais versionados > changelogs > web standards > compat tables; Stack Overflow / blogs / training data são só discovery). Cada finding termina com `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`; bibliografia construída dessas citações.
+
+### Fases do pipeline
+
+**Fase 1 — SCOPE** | Enquadrar a questão. Decompor em componentes. Identificar perspectivas de stakeholders. Definir limites. Listar assumptions a validar.
+
+**Fase 2 — PLAN** | Identificar fontes primárias + secundárias. Mapear dependências de conhecimento. Estratégia de busca com variantes. Plano de triangulação. Quality gates.
+
+**Fase 3 — RETRIEVE** | Coleta paralela. Decompor em 5-10 ângulos independentes (semantic, keyword, date-filtered, academic, alternative perspectives, statistics, industry analysis, critical analysis). Executar TODAS as buscas em paralelo via múltiplas tool calls numa mensagem. First Finish Search: prosseguir quando primeiro threshold atingido (quick: 10+ sources avg credibilidade >60/100; standard: 15+ >60; deep: 25+ >70; ultradeep: 30+ >75).
+
+**Fase 4 — TRIANGULATE** | Identificar claims que requerem verificação. Cross-check em 3+ fontes independentes. Flagar contradições. Documentar status de verificação por claim.
+
+**Fase 5 — REFINAMENTO DO OUTLINE** | Comparar escopo inicial com findings reais. Adaptar estrutura baseada em evidência. Buscas direcionadas pra preencher gaps.
+
+**Fase 6 — SYNTHESIZE** | Identificar patterns cross-source. Mapear relações de conceitos. Gerar insights além do material fonte. Construir hierarquias de evidência.
+
+**Fase 7 — CRITIQUE** (só deep/ultradeep) | Review de consistência lógica. Verificar completude de citações. Identificar gaps ou fraquezas. Simular 2-3 personas críticas.
+
+**Fase 8 — REFINE** (deep/ultradeep) | Fortalecer argumentos fracos. Adicionar perspectivas ausentes. Resolver contradições.
+
+**Fase 9 — PACKAGE** | Gerar relatório progressivamente, seção por seção.
+
+### Output
+
+Salvo em `~/Documents/<Tópico>_Research_<YYYYMMDD>/`. Seções obrigatórias:
+1. Sumário Executivo (200-400 palavras)
+2. Introdução (escopo, metodologia, premissas)
+3. Análise Principal (4-8 achados, 600-2000 palavras cada, todos citados)
+4. Síntese e Insights
+5. Limitações e Ressalvas
+6. Recomendações
+7. Bibliografia (COMPLETA — toda citação, sem placeholders)
+8. Apêndice Metodológico
+
+Tamanhos-alvo: quick 2-4k palavras; standard 4-8k; deep 8-15k; ultradeep 15-20k+.
+
+### Padrões de qualidade
+- Narrativo: prosa fluida, com início/meio/fim. Min 80% prosa, max 20% bullets.
+- Cada afirmação factual citada imediatamente com [N].
+- Distinguir fato de síntese.
+- Sem atribuições vagas ("estudos mostram...", "especialistas acreditam..." sem citação).
+- Rotular especulação explicitamente.
+- Admitir incerteza: "Sem fontes encontradas para X."
+
+## Modo: `--refactor` (catálogo de code smells)
+
+Ativado pela flag `--refactor`. Audita uma área-alvo do codebase por oportunidades de refactoring usando taxonomia de smells de Martin Fowler.
+
+<critical>FAÇA EXATAMENTE 3 PERGUNTAS DE CLARIFICAÇÃO ANTES DE INICIAR ANÁLISE</critical>
+
+### Quando usar modo refactor
+- Audit pre-implementação de tech debt na área que vai mexer.
+- Code-health review trimestral.
+- Scoping pre-migration (ex: antes de upgrade de framework).
+- NÃO use refactor mode se `/dw-review` já flagou a mesma área (evita findings duplicados).
+
+### Required reading
+
+Skills complementares:
+- **`dw-review-rigor`**: **SEMPRE** — aplica de-duplication (mesmo smell em N arquivos = 1 entrada com affected list), severity ordering P0-P3, signal-over-volume (max ~20 findings; manter críticos, podar marginais). Smells com ADR justificatório caem para `low` no máximo.
+- **`dw-simplification`**: **SEMPRE** — todo smell flagueado passa pelo filtro Chesterton's Fence (o que o construto FAZ, por que foi adicionado, o que quebra se removido). Smells sem resposta clara para "por que isso está aqui" caem para `info` com nota de investigação. Métricas de complexidade (complexidade cognitiva ≥16 ou nesting depth ≥4 = candidato `high`; <10 = `low` no máximo) ancoram severity.
+- **`security-review`**: delegue preocupações de segurança para este skill — não duplique.
+- **`vercel-react-best-practices`** + seu `perf-discipline.md`: delegue padrões de performance React/Next.js para este skill.
+
+### Pipeline
+
+1. Três perguntas de clarificação (escopo, prioridades, restrições).
+2. Identificar área-alvo (diretório PRD-scoped, módulo específico, ou codebase inteiro).
+3. Scan por smells usando taxonomia Fowler:
+   - **Bloaters** — Long Method, Large Class, Long Parameter List, Data Clumps, Primitive Obsession.
+   - **Object-Orientation Abusers** — Switch Statements, Refused Bequest, Alternative Classes with Different Interfaces, Temporary Field.
+   - **Change Preventers** — Divergent Change, Shotgun Surgery, Parallel Inheritance Hierarchies.
+   - **Dispensables** — Comments, Duplicate Code, Lazy Class, Data Class, Dead Code, Speculative Generality.
+   - **Couplers** — Feature Envy, Inappropriate Intimacy, Message Chains, Middle Man.
+   - **Conditional complexity** — alta cyclomatic/cognitive, nesting profundo.
+4. Aplicar de-duplication `dw-review-rigor` + filtro Chesterton `dw-simplification`.
+5. Pra cada smell sobrevivente, mapear pra técnica de refactoring com sketches before/after.
+6. Severity-order P0-P3 (impacto × likelihood × custo de manutenção).
+7. Mais: coupling/cohesion metrics, análise SOLID.
+
+### Output
+
+Salvo em `<target>/refactor-plan.md`:
+
+```markdown
+# Oportunidades de Refactoring — <target>
+
+## Resumo
+- Smells encontrados: N (após de-dup)
+- P0 (fazer neste sprint): N
+- P1 (este trimestre): N
+- P2 (quando conveniente): N
+- P3 (informacional): N
+
+## Findings (severity-ordered)
+
+### P0 — <smell name>
+**Arquivos:** <lista> (de-duplicados)
+**Sintoma:** <descrição>
+**Por que corrigir:** <análise de impacto>
+**Refactor sugerido:** <técnica Fowler>
+**Before:** <code sketch>
+**After:** <code sketch>
+**Esforço:** S / M / L
+**Risco:** Baixo / Médio / Alto
+**Testes necessários:** <lista>
+
+...
+```
+
+### Ferramentas de análise
+- Projetos React: `npx react-doctor@latest --verbose` pra health score.
+- Projetos Angular: `ng lint` pra issues estáticos.
+
+### Anti-patterns
+- Listar todo hit de complexidade ciclomática > threshold sem contexto → ruído.
+- Sugerir "extract method" em toda função maior que N linhas → mecânico, não insight.
+- Propor refactors sem teste ou não-testáveis → alto risco, não shippa.
+- Ignorar decisões arquiteturais documentadas em `.dw/rules/` → flagar design intencional como smell.
 
 ## Inspired by
 
@@ -148,7 +299,7 @@ O padrão de codebase-grounded idea refinement é inspirado em [`addyosmani/agen
 - **Nível de produto, não de código**: enquanto `idea-refine` usa Glob/Grep/Read em `src/*`, aqui lemos **PRDs + rules + intel** para mapear o **inventário de features** do produto. O brainstorm continua sendo produtual.
 - **Classificação explícita** (IMPROVES / CONSOLIDATES / NEW) como disciplina dev-workflow-nativa — força o time a decidir se a ideia é feature nova, consolidação ou melhoria de algo existente, antes de abrir um PRD.
 - Output em `.dw/spec/ideas/<slug>.md` (irmão de `prd-<slug>/`) em vez de `docs/ideas/` — mantém a convenção de paths do dev-workflow.
-- Integração com o pipeline existente: `/dw-create-prd` aceita o one-pager como input, reduzindo perguntas de clarificação.
+- Integração com o pipeline existente: `/dw-plan prd` aceita o one-pager como input, reduzindo perguntas de clarificação.
 
 Crédito: Addy Osmani e o padrão `idea-refine`.
 

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

@@ -5,8 +5,8 @@
 
     ## Quando Usar
     - Use para corrigir um bug reportado com triagem automática para distinguir bug vs feature vs escopo excessivo
-    - NÃO use para implementar uma nova funcionalidade (use `/dw-create-prd` em vez disso)
-    - NÃO use para corrigir bugs encontrados durante testes de QA (use `/dw-fix-qa` em vez disso)
+    - NÃO use para implementar uma nova funcionalidade (use `/dw-plan prd` em vez disso)
+    - NÃO use para corrigir bugs encontrados durante testes de QA (use `/dw-qa --fix` em vez disso)
 
     ## Posição no Pipeline
     **Antecessor:** (bug report) | **Sucessor:** `/dw-commit` e depois `/dw-generate-pr`
@@ -18,7 +18,8 @@
     - `dw-debug-protocol`: **SEMPRE** — conduz o bug pelo six-step triage (Reproduzir → Localizar → Reduzir → Fix Root Cause → Guardar → Verificar End-to-End). Stop-the-line discipline; root-cause sobre symptom; regression test commitado no mesmo commit atômico. Bugs não-reprodutíveis seguem o sub-protocolo instrument-first — sem fix por palpite a não ser com acknowledgement explícito.
     - `dw-verify`: **SEMPRE** — em modo Direto, invocada antes do commit da correção. O VERIFICATION REPORT deve mostrar que o sintoma original do bug não se reproduz mais (não apenas que os testes passam).
     - `vercel-react-best-practices`: use quando o bug afeta React/Next.js e há suspeita de problemas de render, hidratação, fetching, waterfall, bundle ou re-render
-    - `dw-testing-discipline`: use quando a correção requer fluxo E2E/reteste reproduzível em web app — `references/playwright-recipes.md` pra recipes, Iron Laws + 7 AI Gates pra qualquer teste que o fix adicione, flaky-discipline se o bug aparece de forma intermitente.
+    - `dw-testing-discipline`: use quando a correção requer fluxo E2E/reteste reproduzível em web app — `references/playwright-recipes.md` pra recipes, core rules + 6 agent guardrails pra qualquer teste que o fix adicione, flaky-discipline se o bug aparece de forma intermitente.
+    - `dw-incident-response`: use quando o bug tem severidade `critical` E afeta produção E foi detectado por alerta/user-report (ou seja, o bug É um incident, não item de backlog). Dispara o workflow de 5 fases (triage → investigation → resolution → communication → postmortem) com saída estruturada em `.dw/incidents/`. As correções rodam via `/dw-bugfix` durante a fase de resolution.
     - `security-review`: use quando a causa raiz toca auth, autorização, input externo, upload, secrets, SQL, XSS, SSRF ou outras superfícies sensíveis
 
     ## Variáveis de Entrada
@@ -47,9 +48,9 @@
     Neste modo:
     1. Segue o fluxo normal de perguntas e análise
     2. Em vez de executar, gera documento em `.dw/spec/dw-bugfix-[nome]/prd.md`
-    3. O arquivo é nomeado `prd.md` para manter compatibilidade com o pipeline dw-create-techspec/dw-create-tasks
-    4. Depois o usuário pode rodar `/dw-create-techspec .dw/spec/dw-bugfix-[nome]`
-    5. E então `/dw-create-tasks .dw/spec/dw-bugfix-[nome]`
+    3. O arquivo é nomeado `prd.md` para manter compatibilidade com o pipeline dw-create-techspec/dw-plan tasks
+    4. Depois o usuário pode rodar `/dw-plan techspec .dw/spec/dw-bugfix-[nome]`
+    5. E então `/dw-plan tasks .dw/spec/dw-bugfix-[nome]`
 
     ## Fluxo de Trabalho
 
@@ -108,7 +109,7 @@
     ---
 
     **Deseja que eu inicie o fluxo de criação de PRD?**
-    - `sim` - Vou seguir `.dw/commands/dw-create-prd.md` para esta feature
+    - `sim` - Vou seguir `.dw/commands/dw-plan prd.md` para esta feature
     - `não, é bug` - Me explique melhor por que considera um bug
     - `não, cancelar` - Encerrar
     ```
@@ -243,7 +244,7 @@
     3. Salvar como: `.dw/spec/dw-bugfix-[nome-do-bug]/prd.md` (usa nome `prd.md` para compatibilidade com pipeline)
 
     **IMPORTANTE:** O arquivo deve ser nomeado `prd.md` para que os comandos
-    `/dw-create-techspec` e `/dw-create-tasks` funcionem sem modificação.
+    `/dw-plan techspec` e `/dw-plan tasks` funcionem sem modificação.
 
     ## Tipos de Tarefa (permitidos em bugfix)
 
@@ -279,7 +280,7 @@
         q2 [label="Does it require\nnew functionality?", shape=diamond];
         q3 [label="Scope <= 5 files\nand no migration?", shape=diamond];
         bug [label="BUG\n(continue bugfix flow)"];
-        feature [label="FEATURE\n(redirect to /dw-create-prd)"];
+        feature [label="FEATURE\n(redirect to /dw-plan prd)"];
         excessive [label="EXCESSIVE SCOPE\n(redirect to PRD or\nuse --analysis mode)"];
 
         start -> q1;

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

@@ -7,7 +7,7 @@
     - NÃO use para criar uma PR (use `/dw-generate-pr` em vez disso)
 
     ## Posição no Pipeline
-    **Antecessor:** `/dw-run-task` ou `/dw-bugfix` | **Sucessor:** `/dw-generate-pr`
+    **Antecessor:** `/dw-run` ou `/dw-bugfix` | **Sucessor:** `/dw-generate-pr`
 
     ## Skills Complementares