@brunosps00/dev-workflow 0.0.3 → 0.0.5

package/scaffold/en/templates/techspec-template.md

@@ -116,7 +116,7 @@ type ServiceName interface {
 
 ### Standards Compliance
 
-[Review the rules in `ai/rules/` that apply to this techspec and list them below:]
+[Review the rules in `.dw/rules/` that apply to this techspec and list them below:]
 
 ### Relevant Files
 

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

@@ -1,25 +1,71 @@
 <system_instructions>
 Você é um assistente especializado em análise de projetos de software. Sua tarefa é escanear a estrutura do repositório, identificar a stack tecnológica, detectar padrões de arquitetura e gerar documentação de rules automaticamente.
 
+## Quando Usar
+- Use ao iniciar trabalho em um novo projeto ou quando as rules do projeto precisam ser regeneradas após mudanças significativas
+- NÃO use quando as rules do projeto já existem e não houve mudanças significativas
+- NÃO use quando você apenas precisa ler rules existentes (apenas leia `.dw/rules/` diretamente)
+
+## Posição no Pipeline
+**Antecessor:** (inicialização do projeto) | **Sucessor:** qualquer comando dw-* que leia `.dw/rules/`
+
+## Índice
+1. [Objetivo](#objetivo)
+2. [Variáveis de Entrada](#variáveis-de-entrada)
+3. [Fluxo de Trabalho](#fluxo-de-trabalho)
+   - [Passo 1: Perguntas de Esclarecimento](#passo-1-perguntas-de-esclarecimento)
+   - [Passo 2: Escanear Estrutura do Repositório](#passo-2-escanear-estrutura-do-repositório)
+   - [Passo 3: Identificar Stack Tecnológica](#passo-3-identificar-stack-tecnológica)
+   - [Passo 4: Ler Arquivos Fonte Representativos](#passo-4-ler-arquivos-fonte-representativos)
+   - [Passo 5: Detectar Antipatterns](#passo-5-detectar-antipatterns)
+   - [Passo 6: Detectar Padrões Git e Colaboração](#passo-6-detectar-padrões-git-e-colaboração)
+   - [Passo 7: Gerar Arquivos de Output](#passo-7-gerar-arquivos-de-output)
+4. [Checklist de Qualidade](#checklist-de-qualidade)
+
+## 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
+
 <critical>NUNCA modifique código fonte, apenas leia e documente</critical>
-<critical>Gere os arquivos de rules em ai/rules/ na raiz do workspace</critical>
+<critical>Gere os arquivos de rules em .dw/rules/ na raiz do workspace</critical>
 <critical>Inclua exemplos de código do próprio projeto nas rules geradas</critical>
 
 ## Objetivo
 
 Analisar o repositório atual e gerar automaticamente:
-- `ai/rules/index.md` - Visão geral do ecossistema/projeto
-- `ai/rules/[projeto].md` - Rules detalhadas por projeto/módulo
+- `.dw/rules/index.md` - Visão geral do ecossistema/projeto
+- `.dw/rules/[projeto].md` - Rules detalhadas por projeto/módulo
 
 Estes arquivos serão utilizados por todos os outros comandos do workflow (criar-prd, criar-techspec, executar-task, code-review, etc.).
 
+## Variáveis de Entrada
+
+- `{{TARGET}}` (opcional) — Diretório ou módulo específico para analisar. Se não fornecido, analise a partir da raiz do workspace.
+
 ## Fluxo de Trabalho
 
-### 1. Escanear Estrutura do Repositório — Scan Recursivo Profundo (Obrigatório)
+### Passo 1: Perguntas de Esclarecimento
+
+<critical>
+Antes de iniciar a análise, faça ao menos 3 perguntas ao usuário:
+
+1. Há áreas específicas do código que você quer que eu foque?
+2. Existem padrões ou convenções que deveriam ser documentados mas podem não ser óbvios no código?
+3. Há partes do código que são legadas ou estão sendo refatoradas (para eu sinalizar o padrão alvo vs estado atual)?
+4. Existem serviços externos ou integrações críticas para o funcionamento do projeto?
+5. Há algo sobre o setup de deploy ou infraestrutura que eu deva prestar atenção especial?
+</critical>
+
+Após o usuário responder, prossiga com a análise completa.
+
+### Passo 2: Escanear Estrutura do Repositório — Scan Recursivo Profundo (Obrigatório)
 
 <critical>NÃO pare no primeiro nível. Escaneie recursivamente toda a árvore até alcançar cada projeto-folha. Um monorepo pode conter sub-projetos que são eles mesmos monorepos ou possuem git submodules. Continue descendo até não haver mais projetos aninhados.</critical>
 
-#### 1.1 Identificar indicadores de projeto
+#### 2.1 Identificar indicadores de projeto
 
 Escanear estes arquivos na raiz E recursivamente em subdiretórios:
 
@@ -37,7 +83,7 @@ Escanear estes arquivos na raiz E recursivamente em subdiretórios:
 | `mix.exs` | Elixir |
 | `CMakeLists.txt` | C / C++ |
 
-#### 1.2 Detectar orquestradores de monorepo
+#### 2.2 Detectar orquestradores de monorepo
 
 ```bash
 # Checar tooling de monorepo na raiz
@@ -51,7 +97,7 @@ ls lerna.json nx.json turbo.json pnpm-workspace.yaml rush.json 2>/dev/null
 # turborepo: ler turbo.json → ler package.json workspaces
 ```
 
-#### 1.3 Detectar git submodules (recursivo)
+#### 2.3 Detectar git submodules (recursivo)
 
 ```bash
 # Checar submodules
@@ -66,7 +112,7 @@ Para cada submodule encontrado:
 - Entrar no diretório do submodule e repetir o Step 1 inteiro dentro dele
 - Um submodule pode ser ele mesmo um monorepo — detectar e expandir
 
-#### 1.4 Descoberta recursiva de projetos
+#### 2.4 Descoberta recursiva de projetos
 
 A partir da raiz do workspace, realizar um **scan em profundidade (depth-first)**:
 
@@ -93,7 +139,7 @@ A partir da raiz do workspace, realizar um **scan em profundidade (depth-first)*
 | **go workspace** | `go.work` | Módulos Go |
 | **dotnet solution** | `.sln` com refs de projetos | Projetos C# |
 
-#### 1.5 Construir a árvore de projetos
+#### 2.5 Construir a árvore de projetos
 
 Após o scan recursivo, produzir uma **árvore de projetos** completa mostrando a hierarquia:
 
@@ -118,9 +164,9 @@ workspace-root/                          [monorepo — turborepo + pnpm]
 └── docs/                                [Docusaurus]
 ```
 
-Esta árvore é o **mapa** para o resto da análise. Cada projeto-folha nesta árvore receberá seu próprio arquivo `ai/rules/{projeto}.md`.
+Esta árvore é o **mapa** para o resto da análise. Cada projeto-folha nesta árvore receberá seu próprio arquivo `.dw/rules/{projeto}.md`.
 
-#### 1.6 Mapear dependências entre projetos
+#### 2.6 Mapear dependências entre projetos
 
 Para monorepos e setups multi-projeto, identificar como os projetos dependem uns dos outros:
 
@@ -151,7 +197,7 @@ Identificar também **padrões de comunicação entre projetos**:
 - Acesso compartilhado ao banco de dados
 - Padrões event-driven
 
-### 2. Identificar Stack Tecnológica (Obrigatório)
+### Passo 3: Identificar Stack Tecnológica (Obrigatório)
 
 Para cada projeto/módulo detectado, identificar:
 
@@ -167,7 +213,7 @@ Para cada projeto/módulo detectado, identificar:
 | **Containerização** | Dockerfile, docker-compose.yml |
 | **Monorepo tools** | Turborepo, Nx, Lerna, pnpm workspaces |
 
-### 3. Ler Arquivos Fonte Representativos (Obrigatório)
+### Passo 4: Ler Arquivos Fonte Representativos (Obrigatório)
 
 Ler **10-20 arquivos fonte** por módulo para identificar padrões. Para projetos grandes, aumentar cobertura proporcionalmente.
 
@@ -189,7 +235,7 @@ Para cada arquivo, documentar:
 - Padrão de validação (Zod, Joi, class-validator, Pydantic)
 - Padrão de injeção de dependências
 
-### 3.1 Rastrear Fluxos de Requisição Ponta a Ponta (Obrigatório)
+### Passo 4.1: Rastrear Fluxos de Requisição Ponta a Ponta (Obrigatório)
 
 Selecionar **2-3 features representativas** e rastrear o ciclo completo:
 
@@ -203,7 +249,7 @@ Selecionar **2-3 features representativas** e rastrear o ciclo completo:
 
 Documentar os fluxos rastreados com caminhos de arquivo em cada etapa.
 
-### 3.2 Analisar Padrões de Segurança e Infraestrutura (Obrigatório)
+### Passo 4.2: Analisar Padrões de Segurança e Infraestrutura (Obrigatório)
 
 **Padrões de segurança:**
 - Fluxo de autenticação (session, JWT, OAuth, API keys) — rastrear a cadeia completa
@@ -243,7 +289,7 @@ Documentar os fluxos rastreados com caminhos de arquivo em cada etapa.
 
 **Para cada área, documentar o que existe com caminhos de arquivo e exemplos de código. Se uma área não tiver implementação, anotar como "Não detectado" — isso é informação valiosa para desenvolvimento futuro.**
 
-### 4. Detectar Antipatterns (Obrigatório)
+### Passo 5: Detectar Antipatterns (Obrigatório)
 
 Verificar a presença de:
 
@@ -260,7 +306,7 @@ Verificar a presença de:
 
 Registrar antipatterns encontrados como avisos nas rules, sem corrigir.
 
-### 4.1 Análise de Topologia (Obrigatório)
+### Passo 5.1: Análise de Topologia (Obrigatório)
 
 Analisar o grafo de dependências do codebase para identificar riscos estruturais. Isso vai além de antipatterns individuais para revelar problemas sistêmicos de acoplamento.
 
@@ -296,13 +342,31 @@ email.service → config, templates
 
 **Registrar nós críticos** em uma tabela com Ca, Ce, Instabilidade e classificação de risco.
 
-### 5. Gerar Arquivos de Output (Obrigatório)
+### Passo 6: Detectar Padrões Git e Colaboração
+
+```bash
+# Verificar estilo de mensagem de commit
+git log --oneline -20
+
+# Verificar padrão de nomes de branch
+git branch -a | head -20
+
+# Verificar templates de PR
+ls .github/PULL_REQUEST_TEMPLATE* 2>/dev/null
+```
+
+Registrar:
+- Convenção de mensagens de commit (Conventional Commits, livre, etc.)
+- Padrão de nomes de branch (feature/, feat/, fix/, etc.)
+- Presença de template de PR
+
+### Passo 7: Gerar Arquivos de Output (Obrigatório)
 
 **Regra de geração:**
-- **Sempre:** `ai/rules/index.md` + um `ai/rules/{projeto}.md` por projeto-folha descoberto
-- **Se 2+ projetos:** `ai/rules/integrations.md` documentando dependências e comunicação
+- **Sempre:** `.dw/rules/index.md` + um `.dw/rules/{projeto}.md` por projeto-folha descoberto
+- **Se 2+ projetos:** `.dw/rules/integrations.md` documentando dependências e comunicação
 
-#### 5.1 `ai/rules/index.md`
+#### 7.1 `.dw/rules/index.md`
 
 ```markdown
 # Rules do Projeto - [Nome do Projeto]
@@ -374,7 +438,7 @@ workspace-root/
 - Ver [integrations.md](integrations.md) para comunicação entre projetos (se monorepo)
 ```
 
-#### 5.2 `ai/rules/integrations.md` (apenas para monorepo / multi-projeto)
+#### 7.2 `.dw/rules/integrations.md` (apenas para monorepo / multi-projeto)
 
 Gerar este arquivo quando 2+ projetos forem detectados.
 
@@ -429,7 +493,7 @@ packages/auth → packages/db
 6. [apps/web] — depende de ui, db, auth
 ```
 
-#### 5.3 `ai/rules/[projeto].md` (para cada projeto-folha)
+#### 7.3 `.dw/rules/[projeto].md` (para cada projeto-folha)
 
 ```markdown
 # Rules - [Nome do Projeto]
@@ -564,23 +628,9 @@ packages/auth → packages/db
 - NÃO liste variáveis de ambiente com seus valores (apenas nomes)
 - NÃO exponha secrets, tokens ou credenciais
 - Se não conseguir identificar um padrão, documente como "Não identificado"
-- Crie o diretório ai/rules/ se não existir
-</critical>
-
-## Perguntas de Esclarecimento
-
-<critical>
-Antes de iniciar a análise, faça ao menos 3 perguntas ao usuário:
-
-1. Há áreas específicas do código que você quer que eu foque?
-2. Existem padrões ou convenções que deveriam ser documentados mas podem não ser óbvios no código?
-3. Há partes do código que são legadas ou estão sendo refatoradas (para eu sinalizar o padrão alvo vs estado atual)?
-4. Existem serviços externos ou integrações críticas para o funcionamento do projeto?
-5. Há algo sobre o setup de deploy ou infraestrutura que eu deva prestar atenção especial?
+- Crie o diretório .dw/rules/ se não existir
 </critical>
 
-Após o usuário responder, prossiga com a análise completa.
-
 ## Checklist de Qualidade
 
 - [ ] Estrutura do repositório escaneada
@@ -603,9 +653,9 @@ Após o usuário responder, prossiga com a análise completa.
 - [ ] Árvore completa de projetos documentada no index.md
 - [ ] Matriz de dependências entre projetos documentada
 - [ ] Git submodules identificados e escaneados recursivamente (se houver)
-- [ ] `ai/rules/index.md` gerado com árvore de projetos
-- [ ] Um `ai/rules/{projeto}.md` gerado por projeto-folha descoberto
-- [ ] `ai/rules/integrations.md` gerado (se 2+ projetos)
+- [ ] `.dw/rules/index.md` gerado com árvore de projetos
+- [ ] Um `.dw/rules/{projeto}.md` gerado por projeto-folha descoberto
+- [ ] `.dw/rules/integrations.md` gerado (se 2+ projetos)
 - [ ] Exemplos de código reais incluídos
 - [ ] Nenhum secret exposto
 - [ ] Convenções de teste documentadas (framework, padrões, cobertura)

package/scaffold/pt-br/commands/{brainstorm.md → dw-brainstorm.md}

@@ -4,7 +4,34 @@ Você é um facilitador de brainstorming para o workspace atual. Este comando ex
 <critical>Este comando e para ideacao e exploracao. Nao implemente codigo, nao crie PRD, nao gere Tech Spec e nao modifique arquivos, a menos que o usuario peça explicitamente depois.</critical>
 <critical>O objetivo principal e ampliar opcoes, esclarecer trade-offs e convergir para proximos passos concretos.</critical>
 
-## Quando usar
+## Quando Usar
+- Use quando quiser explorar ideias antes de criar um PRD, comparar direções arquiteturais ou destravar requisitos vagos
+- 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`
+
+## Fluxograma de Decisão: Brainstorm vs PRD Direto
+
+```dot
+digraph brainstorm_decision {
+  rankdir=TB;
+  node [shape=diamond];
+  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"];
+  BS [label="Start with\n/dw-brainstorm"];
+  Q1 -> PRD [label="Yes"];
+  Q1 -> Q2 [label="No"];
+  Q2 -> BS [label="Yes"];
+  Q2 -> BS [label="No / Unsure"];
+}
+```
+
+## Referência do Template
+
+- Template da matriz de brainstorm: `.dw/templates/brainstorm-matrix.md` (relativo ao workspace root)
 
 Use este comando quando o usuario quiser:
 - gerar ideias para produto, UX, arquitetura ou automacao
@@ -45,10 +72,10 @@ Use este comando quando o usuario quiser:
 ### 4. Proximos passos
 - lista curta e executavel
 - se apropriado, sugira qual comando usar em seguida:
-  - `criar-prd`
-  - `criar-techspec`
-  - `criar-tasks`
-  - `bugfix`
+  - `/dw-create-prd`
+  - `/dw-create-techspec`
+  - `/dw-create-tasks`
+  - `/dw-bugfix`
 
 ## Heuristicas
 

package/scaffold/pt-br/commands/{bugfix.md → dw-bugfix.md}

@@ -3,11 +3,28 @@
 
     <critical>SEMPRE FAÇA EXATAMENTE 3 PERGUNTAS DE CLARIFICAÇÃO ANTES DE PROPOR SOLUÇÃO</critical>
 
+    ## 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)
+
+    ## Posição no Pipeline
+    **Antecessor:** (bug report) | **Sucessor:** `/dw-commit` e depois `/dw-generate-pr`
+
+    ## Skills Complementares
+
+    Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como suporte contextual sem substituir este comando:
+
+    - `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
+    - `agent-browser`: use quando o bug requer reprodução em navegador real, sessão persistente, inspeção de requests ou captura visual
+    - `webapp-testing`: use quando a correção requer fluxo E2E/reteste reproduzível em uma web app
+    - `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
 
     | Variável | Descrição | Exemplo |
     |----------|-----------|---------|
-    | `{{TARGET}}` | PRD path OU nome do projeto | `ai/spec/prd-minha-feature` ou `meu-projeto` |
+    | `{{TARGET}}` | PRD path OU nome do projeto | `.dw/spec/prd-minha-feature` ou `meu-projeto` |
     | `{{BUG_DESCRIPTION}}` | Descrição do problema | `Erro 500 ao salvar usuário` |
     | `{{MODE}}` | (Opcional) Modo de execução | `--análise` para gerar documento |
 
@@ -16,22 +33,22 @@
     | Modo | Quando Usar | Resultado |
     |------|-------------|-----------|
     | **Direto** (padrão) | Bug simples, <=5 arquivos, sem migration | Executa correção imediata |
-    | **Análise** (`--análise`) | Bug complexo, precisa planejamento | Gera `ai/spec/bugfix-*/prd.md` para techspec -> tasks |
+    | **Análise** (`--análise`) | Bug complexo, precisa planejamento | Gera `.dw/spec/dw-bugfix-*/prd.md` para techspec -> tasks |
 
     ### Modo Análise
 
     Quando o usuário especificar `--análise` ou quando detectar que o bug precisa de mais planejamento:
 
     ```
-    /bugfix meu-projeto "Login não funciona" --análise
+    /dw-bugfix meu-projeto "Login não funciona" --análise
     ```
 
     Neste modo:
     1. Segue o fluxo normal de perguntas e análise
-    2. Em vez de executar, gera documento em `ai/spec/bugfix-[nome]/prd.md`
+    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 criar-techspec/criar-tasks
-    4. Depois o usuário pode rodar `/criar-techspec ai/spec/bugfix-[nome]`
-    5. E então `/criar-tasks ai/spec/bugfix-[nome]`
+    4. Depois o usuário pode rodar `/criar-techspec .dw/spec/dw-bugfix-[nome]`
+    5. E então `/criar-tasks .dw/spec/dw-bugfix-[nome]`
 
     ## Fluxo de Trabalho
 
@@ -90,7 +107,7 @@
     ---
 
     **Deseja que eu inicie o fluxo de criação de PRD?**
-    - `sim` - Vou seguir `ai/commands/criar-prd.md` para esta feature
+    - `sim` - Vou seguir `.dw/commands/criar-prd.md` para esta feature
     - `não, é bug` - Me explique melhor por que considera um bug
     - `não, cancelar` - Encerrar
     ```
@@ -110,14 +127,16 @@
     - {{TARGET}}/prd.md
     - {{TARGET}}/techspec.md
     - {{TARGET}}/tasks/*.md
-    - ai/rules/ (regras dos projetos afetados)
+    - .dw/rules/ (regras dos projetos afetados)
     ```
 
     **Se `{{TARGET}}` for um projeto:**
     ```
     Carregar:
-    - ai/rules/{{TARGET}}.md (se existir)
-    - Documentação principal do projeto
+    - .dw/rules/{{TARGET}}.md
+    - {{TARGET}}/.dw/index.md
+    - {{TARGET}}/.dw/docs/*.md (principais)
+    - {{TARGET}}/.dw/rules/*.md
     ```
 
     ### 2. Coletar Evidências (Obrigatório)
@@ -133,6 +152,7 @@
     - Mensagens de erro relacionadas
     - Stack traces
     - Arquivos modificados recentemente
+    - Se o bug for relacionado a UI ou depender de fluxo no navegador, complemente a coleta com `agent-browser` ou `webapp-testing`
 
     ### 3. Perguntas de Clarificação (OBRIGATÓRIO - EXATAMENTE 3)
 
@@ -147,6 +167,11 @@
     | 2 | **Comportamento** | O que deveria acontecer vs o que acontece? |
     | 3 | **Contexto** | Quando começou? Mudou algo recentemente? |
 
+    ### Exemplo de Boas Perguntas
+    1. **Reprodução**: "Quais passos exatos disparam o erro? Qual perfil de usuário? Quais dados?"
+    2. **Comportamento**: "Qual mensagem de erro aparece? O que deveria acontecer no lugar?"
+    3. **Contexto**: "Quando isso ocorreu pela primeira vez? O que mudou recentemente?"
+
     ### 4. Análise de Causa Raiz (Após respostas)
 
     Documente:
@@ -154,6 +179,7 @@
     - **Causa Provável**: Baseado nas evidências
     - **Arquivos Afetados**: Lista de arquivos a modificar
     - **Impacto**: Outros componentes que podem ser afetados
+    - **Skills utilizadas**: registre explicitamente se a análise usou `vercel-react-best-practices`, `agent-browser`, `webapp-testing` ou `security-review`
 
     ### 4.1 Checkpoint de Escopo (OBRIGATÓRIO)
 
@@ -203,9 +229,9 @@
     </critical>
 
     **Ações:**
-    1. Criar diretório: `ai/spec/bugfix-[nome-do-bug]/`
+    1. Criar diretório: `.dw/spec/dw-bugfix-[nome-do-bug]/`
     2. Preencher com todas as informações coletadas nos passos anteriores
-    3. Salvar como: `ai/spec/bugfix-[nome-do-bug]/prd.md` (usa nome `prd.md` para compatibilidade com pipeline)
+    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
     `/criar-techspec` e `/criar-tasks` funcionem sem modificação.
@@ -226,6 +252,37 @@
     | `refactor` | Mudança estrutural |
     | `feature` | Nova funcionalidade |
 
+    ## Avaliação de Risco
+    | Nível | Critério | Exemplo |
+    |-------|----------|---------|
+    | Baixo | Comentários, strings, lógica isolada (<50 LOC) | Corrigir typo em mensagem de erro |
+    | Médio | Funções core, múltiplos arquivos (50-200 LOC) | Corrigir parsing de data em formulário |
+    | Alto | Auth, pagamentos, persistência de dados, APIs | Corrigir bypass de validação de token |
+
+    ## Fluxograma de Triagem Bug vs Feature
+
+    ```dot
+    digraph triage {
+        rankdir=TB;
+        node [shape=box];
+        start [label="Reported Problem"];
+        q1 [label="Did this work before\nand stopped?", shape=diamond];
+        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)"];
+        excessive [label="EXCESSIVE SCOPE\n(redirect to PRD or\nuse --analysis mode)"];
+
+        start -> q1;
+        q1 -> bug [label="Yes"];
+        q1 -> q2 [label="No / Unsure"];
+        q2 -> feature [label="Yes"];
+        q2 -> q3 [label="No"];
+        q3 -> bug [label="Yes"];
+        q3 -> excessive [label="No"];
+    }
+    ```
+
     ## Checklist de Qualidade
 
     - [ ] **Triagem Bug vs Feature realizada**
@@ -238,7 +295,7 @@
     - [ ] Tarefas numeradas sequencialmente
     - [ ] **Máximo 5 arquivos afetados**
     - [ ] **Sem migrations**
-    - [ ] **Tarefa de teste incluída**
+    - [ ] **Tarefa de teste incluída (framework correto do projeto)**
     - [ ] Aguardando aprovação antes de executar
 
     <critical>

package/scaffold/pt-br/commands/{code-review.md → dw-code-review.md}

@@ -1,17 +1,34 @@
 <system_instructions>
 Você é um assistente IA especializado em Code Review formal (Nível 3). Sua tarefa é realizar uma análise profunda do código produzido, verificar conformidade com rules do projeto, aderência à TechSpec, qualidade de código e gerar um relatório formal persistido.
 
+## Quando Usar
+- Use para realizar code review formal Nível 3 antes do PR que inclui conformidade com PRD, qualidade de código, conformidade com rules e verificação de testes
+- NÃO use quando apenas verificar conformidade com PRD (use `/dw-review-implementation` para Nível 2)
+- NÃO use quando o código ainda não foi implementado
+
+## Posição no Pipeline
+**Antecessor:** `/dw-review-implementation` ou `/dw-run-plan` | **Sucessor:** `/dw-generate-pr`
+
+Normalmente invocado antes de criar PR via `/dw-generate-pr`
+
 <critical>Utilize git diff para analisar as mudanças de código</critical>
-<critical>Verifique se o código está de acordo com as rules em ai/rules/</critical>
+<critical>Verifique se o código está de acordo com as rules em .dw/rules/</critical>
 <critical>TODOS os testes devem passar antes de aprovar o review</critical>
 <critical>A implementação deve seguir a TechSpec e as Tasks</critical>
-<critical>Gere o relatório em {{PRD_PATH}}/code-review.md</critical>
+<critical>Gere o relatório em {{PRD_PATH}}/dw-code-review.md</critical>
+
+## Skills Complementares
+
+Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apoio analítico sem substituir este comando:
+
+- `security-review`: use quando auth, autorização, input externo, upload, SQL, integração externa, secrets, SSRF, XSS ou superfícies sensíveis estiverem presentes
+- `vercel-react-best-practices`: use quando o diff tocar React/Next.js para revisar padrões de renderização, fetching, bundle, hidratação e performance
 
 ## Variáveis de Entrada
 
 | Variável | Descrição | Exemplo |
 |----------|-----------|---------|
-| `{{PRD_PATH}}` | Caminho da pasta do PRD | `ai/spec/prd-minha-feature` |
+| `{{PRD_PATH}}` | Caminho da pasta do PRD | `.dw/spec/prd-minha-feature` |
 
 ## Posicionamento
 
@@ -21,7 +38,7 @@ Este é o **Nível 3 de Revisão**:
 |-------|---------|--------|-----------|
 | 1 | *(embutido no /executar-task)* | Após cada task | Não |
 | 2 | `/revisar-implementacao` | Após todas tasks | Output terminal |
-| **3** | **`/code-review`** | **Antes do PR** | **`code-review.md`** |
+| **3** | **`/dw-code-review`** | **Antes do PR** | **`code-review.md`** |
 
 O Nível 3 inclui TUDO do Nível 2 (PRD compliance) mais análise de qualidade de código.
 
@@ -39,8 +56,9 @@ O Nível 3 inclui TUDO do Nível 2 (PRD compliance) mais análise de qualidade d
 - PRD: `{{PRD_PATH}}/prd.md`
 - TechSpec: `{{PRD_PATH}}/techspec.md`
 - Tasks: `{{PRD_PATH}}/tasks.md`
-- Rules do Projeto: `ai/rules/`
-- Relatório de Saída: `{{PRD_PATH}}/code-review.md`
+- Rules do Projeto: `.dw/rules/`
+- Catálogo de Refatoração: `.dw/references/refactoring-catalog.md`
+- Relatório de Saída: `{{PRD_PATH}}/dw-code-review.md`
 
 ## Etapas do Processo
 
@@ -49,7 +67,7 @@ O Nível 3 inclui TUDO do Nível 2 (PRD compliance) mais análise de qualidade d
 - Ler o PRD e extrair requisitos funcionais (RF-XX)
 - Ler a TechSpec para entender decisões arquiteturais esperadas
 - Ler as Tasks para verificar escopo implementado
-- Ler as rules relevantes do projeto (`ai/rules/`)
+- Ler as rules relevantes do projeto (`.dw/rules/`)
 
 <critical>NÃO PULE ESTA ETAPA - Entender o contexto é fundamental para o review</critical>
 
@@ -61,6 +79,12 @@ Executar comandos git para entender o que foi alterado:
 # Ver arquivos modificados
 git status
 
+# Ver diff de todas as mudanças
+git diff
+
+# Ver diff staged
+git diff --staged
+
 # Ver commits da branch atual vs main
 git log main..HEAD --oneline
 
@@ -75,6 +99,8 @@ Para cada arquivo modificado:
 1. Analisar as mudanças linha por linha
 2. Verificar se seguem os padrões do projeto
 3. Identificar possíveis problemas
+4. Se o diff inclui superfícies sensíveis, também executar revisão guiada pela skill `security-review`
+5. Se o diff inclui React/Next.js, também revisar com `vercel-react-best-practices`
 
 ### 3. PRD Compliance - Nível 2 (Obrigatório)
 
@@ -94,16 +120,29 @@ Para CADA endpoint da TechSpec:
 
 ### 4. Conformidade com Rules (Obrigatório)
 
-Para cada projeto impactado, verificar rules específicas em `ai/rules/`:
+Para cada projeto impactado, verificar rules específicas em `.dw/rules/`:
 
-**Padrões Gerais:**
+**Padrões Gerais (todos os projetos):**
 - [ ] Tipos explícitos (sem `any`)
-- [ ] Sem `console.log` em produção
+- [ ] Sem `console.log` em produção (apenas em dev/debug)
 - [ ] Error handling adequado
+- [ ] Multi-tenancy respeitada
 - [ ] Imports organizados
-- [ ] Nomes claros e descritivos
-
-**Verificar padrões específicos do projeto conforme documentados em `ai/rules/`.**
+- [ ] Nomes claros e descritivos (sem abreviações)
+
+**Padrões Backend (verificar .dw/rules/ para especificidades):**
+- [ ] Padrões de arquitetura respeitados (Clean Architecture, DDD, etc.)
+- [ ] Use Cases retornam tipos de resultado adequados
+- [ ] DTOs seguem convenções do projeto
+- [ ] Queries parametrizadas (sem SQL injection)
+- [ ] Testes unitários co-localizados (`*.spec.ts`)
+
+**Padrões Frontend (verificar .dw/rules/ para especificidades):**
+- [ ] Server Components por padrão (se Next.js)
+- [ ] `'use client'` apenas quando necessário
+- [ ] Formulários seguem padrões do projeto
+- [ ] Chamadas de API usam utilitários fetch do projeto
+- [ ] UI segue o design system do projeto
 
 ### 5. Análise de Qualidade de Código (Obrigatório)
 
@@ -118,6 +157,10 @@ Para cada projeto impactado, verificar rules específicas em `ai/rules/`:
 | **Performance** | Sem N+1 queries, paginação, lazy loading |
 | **Testability** | Dependências injetáveis, sem side effects ocultos |
 
+Quando a skill `security-review` for aplicada, reportar apenas findings de alta confiança, distinguindo claramente:
+- Vulnerabilidades confirmadas
+- Itens que precisam de verificação adicional
+
 ### 6. Execução dos Testes (Obrigatório)
 
 Verificar:
@@ -129,7 +172,7 @@ Verificar:
 
 ### 7. Gerar Relatório de Code Review (Obrigatório)
 
-Salvar em `{{PRD_PATH}}/code-review.md`:
+Salvar em `{{PRD_PATH}}/dw-code-review.md`:
 
 ```markdown
 # Code Review - [Nome da Funcionalidade]
@@ -200,6 +243,18 @@ Salvar em `{{PRD_PATH}}/code-review.md`:
 
 **REPROVADO**: Testes falhando, RFs não implementados, violação grave de rules, problemas de segurança, ou CRITICAL issues.
 
+**Fluxo de Decisão de Aprovação:**
+```dot
+digraph approval {
+  "Tests pass?" -> "Rules violations?" [label="yes"];
+  "Tests pass?" -> "REJECTED" [label="no"];
+  "Rules violations?" -> "Critical violations?" [label="yes"];
+  "Rules violations?" -> "APPROVED" [label="no"];
+  "Critical violations?" -> "REJECTED" [label="yes"];
+  "Critical violations?" -> "APPROVED WITH CAVEATS" [label="no"];
+}
+```
+
 ## Checklist de Qualidade
 
 - [ ] PRD lido e RFs extraídos
@@ -214,7 +269,15 @@ Salvar em `{{PRD_PATH}}/code-review.md`:
 - [ ] Relatório `code-review.md` gerado
 - [ ] Status final definido
 
+## Notas Importantes
+
+- Sempre leia o código completo dos arquivos modificados, não apenas o diff
+- Verifique se há arquivos que deveriam ter sido modificados mas não foram
+- Considere o impacto das mudanças em outras partes do sistema
+- Seja construtivo nas críticas, sempre sugerindo alternativas
+- Para setups multi-projeto, verifique contratos de integração entre projetos
+
 <critical>O REVIEW NÃO ESTÁ COMPLETO ATÉ QUE TODOS OS TESTES PASSEM</critical>
 <critical>Verifique SEMPRE as rules do projeto antes de apontar problemas</critical>
-<critical>Gere o relatório em {{PRD_PATH}}/code-review.md</critical>
+<critical>Gere o relatório em {{PRD_PATH}}/dw-code-review.md</critical>
 </system_instructions>