@brunosps00/dev-workflow 0.0.3 → 0.0.6

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 (dw-create-prd, dw-create-techspec, dw-run-task, code-review, etc.).
+
+## Variáveis de Entrada
 
-Estes arquivos serão utilizados por todos os outros comandos do workflow (criar-prd, criar-techspec, executar-task, code-review, etc.).
+- `{{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,14 +438,14 @@ 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.
 
 ```markdown
 # Integrações — [Nome do Workspace]
 
-> Auto-gerado por /analisar-projeto em [data]
+> Auto-gerado por /dw-analyze-project em [data]
 
 ## Grafo de Dependências
 
@@ -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)
@@ -613,7 +663,7 @@ Após o usuário responder, prossiga com a análise completa.
 ## Exemplo de Uso
 
 ```
-/analisar-projeto
+/dw-analyze-project
 ```
 
 Isso escaneará o repositório atual e gerará os arquivos de rules automaticamente.

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`
-    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]`
+    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]`
 
     ## 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/dw-create-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,12 +229,12 @@
     </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.
+    `/dw-create-techspec` e `/dw-create-tasks` funcionem sem modificação.
 
     ## Tipos de Tarefa (permitidos em bugfix)
 
@@ -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,12 +295,12 @@
     - [ ] 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>
     PRIMEIRO: Avalie se é bug ou feature (Passo 0).
-    Se for feature: Redirecione para criar-prd.md.
+    Se for feature: Redirecione para dw-create-prd.md.
     NUNCA pule as 3 perguntas.
     NUNCA execute tarefas sem aprovação.
     SEMPRE numere as tarefas sequencialmente (1, 2, 3...).