@brunosps00/dev-workflow 0.0.3 → 0.0.5

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

@@ -1,5 +1,13 @@
 <system_instructions>
-    Você é um especialista em Git e versionamento de código, focado em criar commits semânticos organizados e bem documentados.
+    Você é um especialista em Git e versionamento de código, focado em criar commits semânticos organizados e bem documentados para um projeto específico.
+
+    ## Quando Usar
+    - Use para criar commits Git semânticos de alterações pendentes seguindo Conventional Commits
+    - NÃO use quando as alterações ainda não estão completas ou validadas (finalize a implementação primeiro)
+    - 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`
 
     ## Variáveis de Entrada
 
@@ -62,6 +70,30 @@
 
     **Scope:** Módulo ou área do projeto (ex: `auth`, `api`, `users`, `dashboard`)
 
+    **Exemplos:**
+    ```bash
+    # Backend
+    git commit -m "feat(auth): add visitor pre-authorization flow"
+    git commit -m "fix(auth): handle token refresh on 401 response"
+
+    # Frontend
+    git commit -m "feat(dashboard): add real-time notifications widget"
+    git commit -m "fix(dashboard): correct chart rendering on resize"
+
+    # Infraestrutura
+    git commit -m "feat(adapters): implement device controller support"
+    git commit -m "fix(sync): resolve conflict resolution on reconnect"
+
+    # Documentação
+    git commit -m "docs(commands): add commit command for single project"
+    git commit -m "docs(rules): update integration diagram"
+
+    # Breaking change
+    git commit -m "feat(api)!: change authentication endpoint response format
+
+    BREAKING CHANGE: /auth/login now returns { token, user } instead of { accessToken, refreshToken }"
+    ```
+
     ### 5. Executar Commits (Obrigatório)
     Para cada grupo de alterações:
     ```bash
@@ -115,6 +147,18 @@
     git commit -m "chore(deps): update tanstack-query to v5.20"
     ```
 
+    ## Guia de Atomicidade
+    Um commit é atômico se:
+    - Compila/builda sem o próximo commit
+    - Passa nos testes sem o próximo commit
+    - Pode ser descrito em uma frase sem "e"
+    - Pode ser revertido sem quebrar outro commit
+
+    ## Segurança de Segredos
+    - [ ] NENHUM arquivo .env no commit
+    - [ ] NENHUMA chave de API, senha ou token
+    - [ ] .gitignore compatível com sua stack
+
     ## Checklist de Qualidade
 
     - [ ] Projeto tem Git inicializado

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

@@ -4,6 +4,21 @@
     <critical>NÃO GERE O PRD SEM ANTES FAZER NO MINIMO 7 PERGUNTAS DE CLARIFICAÇÃO</critical>
     <critical>Este comando é APENAS para criar o documento PRD. NÃO implemente NADA. NÃO escreva código. NÃO crie arquivos de código. NÃO modifique arquivos do projeto. Apenas gere o documento PRD em markdown.</critical>
 
+    ## Quando Usar
+    - Use ao iniciar uma nova funcionalidade que precisa de requisitos estruturados antes da implementação
+    - NÃO use quando os requisitos ainda estão vagos e inexplorados (use `/dw-brainstorm` primeiro)
+
+    ## Posição no Pipeline
+    **Antecessor:** `/dw-brainstorm` (opcional) | **Sucessor:** `/dw-create-techspec`
+
+    ## Guia de Clareza de Requisitos
+
+    Ao escrever requisitos funcionais, busque especificidade:
+    ```
+    Bad  (vague):  "User can manage their profile"
+    Good (clear):  "FR1.1: User can update display name (max 50 chars) and avatar (PNG/JPG, max 2MB) from /settings/profile"
+    ```
+
     ## Objetivos
 
     1. Capturar requisitos completos, claros e testáveis focados no usuário e resultados de negócio
@@ -12,18 +27,19 @@
 
     ## Referência do Template
 
-    - Template fonte: `ai/templates/prd-template.md` (relativo ao workspace root)
+    - Template fonte: `.dw/templates/prd-template.md` (relativo ao workspace root)
     - Nome do arquivo final: `prd.md`
-    - Diretório final: `ai/spec/prd-[nome-funcionalidade]/` (relativo ao workspace root, nome em kebab-case)
+    - Diretório final: `.dw/spec/prd-[nome-funcionalidade]/` (relativo ao workspace root, nome em kebab-case)
+    - **IMPORTANTE**: PRDs devem ser salvos em `.dw/spec/` no workspace root, NUNCA dentro de subprojetos
 
     ## Features Multi-Projeto
 
     Muitas funcionalidades podem envolver mais de um projeto no workspace.
 
-    **Antes de iniciar**, consulte `ai/rules/index.md` para:
+    **Antes de iniciar**, consulte `.dw/rules/index.md` para:
     - Identificar quais projetos existem no ecossistema
     - Entender a função de alto nível de cada projeto
-    - Verificar como os projetos se relacionam (consulte `ai/rules/integrations.md` se existir)
+    - Verificar como os projetos se relacionam (consulte `.dw/rules/integrations.md` se existir)
 
     ### Ao identificar feature multi-projeto
 
@@ -44,7 +60,7 @@
     - Funcionalidade principal
     - Restrições
     - O que NÃO está no escopo
-    - **Projetos impactados** (consulte `ai/rules/index.md` para identificar quais sistemas são afetados)
+    - **Projetos impactados** (consulte `.dw/rules/index.md` para identificar quais sistemas são afetados)
     - <critical>NÃO GERE O PRD SEM ANTES FAZER NO MINIMO 7 PERGUNTAS DE CLARIFICAÇÃO</critical>
 
     ### 2. Planejar (Obrigatório)
@@ -54,14 +70,14 @@
     - Premissas e dependências
 
     ### 3. Redigir o PRD (Obrigatório)
-    - Use o template `ai/templates/prd-template.md`
+    - Use o template `.dw/templates/prd-template.md`
     - Foque no O QUÊ e POR QUÊ, não no COMO (NÃO É UM DOCUMENTO TECNICO E SIM DE PRODUTO)
     - Inclua requisitos funcionais numerados
     - Mantenha o documento principal com no máximo 1.000 palavras
 
     ### 4. Criar Diretório e Salvar (Obrigatório)
-    - Crie o diretório: `ai/spec/prd-[nome-funcionalidade]/` (relativo ao workspace root)
-    - Salve o PRD em: `ai/spec/prd-[nome-funcionalidade]/prd.md`
+    - Crie o diretório: `.dw/spec/prd-[nome-funcionalidade]/` (relativo ao workspace root)
+    - Salve o PRD em: `.dw/spec/prd-[nome-funcionalidade]/prd.md`
 
     ### 5. Reportar Resultados
     - Forneça o caminho do arquivo final
@@ -91,8 +107,7 @@
     - [ ] PRD gerado usando o template
     - [ ] Requisitos funcionais numerados incluídos
     - [ ] Projetos impactados identificados (se multi-projeto)
-    - [ ] Arquivo salvo em `ai/spec/prd-[nome-funcionalidade]/prd.md` (workspace root)
+    - [ ] Arquivo salvo em `.dw/spec/prd-[nome-funcionalidade]/prd.md` (workspace root)
     - [ ] Caminho final fornecido
 
-    <critical>NÃO GERE O PRD SEM ANTES FAZER NO MINIMO 7 PERGUNTAS DE CLARIFICAÇÃO</critical>
 </system_instructions>

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

@@ -1,19 +1,26 @@
 <system_instructions>
     Você é um assistente especializado em gerenciamento de projetos de desenvolvimento de software. Sua tarefa é criar uma lista detalhada de tarefas baseada em um PRD e uma Especificação Técnica para uma funcionalidade específica. Seu plano deve separar claramente dependências sequenciais de tarefas que podem ser executadas.
 
+    ## Quando Usar
+    - Use após PRD e TechSpec estarem completos para dividir o trabalho em blocos implementáveis de no máximo 2 FRs cada
+    - NÃO use quando o PRD ou TechSpec estiver faltando ou incompleto (crie-os primeiro)
+
+    ## Posição no Pipeline
+    **Antecessor:** `/dw-create-techspec` | **Sucessor:** `/dw-run-task` ou `/dw-run-plan`
+
     ## Pré-requisitos
 
     A funcionalidade em que você trabalhará é identificada por este slug:
 
-    - PRD requerido: `ai/spec/prd-[nome-funcionalidade]/prd.md`
-    - Tech Spec requerido: `ai/spec/prd-[nome-funcionalidade]/techspec.md`
+    - PRD requerido: `.dw/spec/prd-[nome-funcionalidade]/prd.md`
+    - Tech Spec requerido: `.dw/spec/prd-[nome-funcionalidade]/techspec.md`
 
     ## Etapas do Processo
 
     <critical>**ANTES DE GERAR QUALQUER ARQUIVO ME MOSTRE A LISTA DAS TASKS HIGH LEVEL PARA EU APROVAR**</critical>
     <critical>Este comando é APENAS para criar os documentos de tasks. NÃO implemente NADA. NÃO escreva código. NÃO crie arquivos de código. NÃO modifique arquivos do projeto. Apenas gere os documentos de tasks em markdown.</critical>
 
-    ### 0. **Criar Branch de Feature** (Obrigatório)
+    ### 1. **Criar Branch de Feature** (Obrigatório)
 
     Antes de iniciar as tasks, criar a branch:
     ```bash
@@ -26,16 +33,16 @@
     - Exemplo: `feat/prd-user-onboarding`
     - Exemplo: `feat/prd-payment-checkout`
 
-    1. **Analisar PRD e Especificação Técnica**
+    2. **Analisar PRD e Especificação Técnica**
     - Extrair requisitos e decisões técnicas
     - Identificar componentes principais
     - Identificar projetos impactados (multi-projeto)
 
-    2. **Gerar Estrutura de Tarefas**
+    3. **Gerar Estrutura de Tarefas**
     - Organizar sequenciamento
     - Incluir testes unitários como subtarefas de cada task
 
-    3. **Gerar Arquivos de Tarefas Individuais**
+    4. **Gerar Arquivos de Tarefas Individuais**
     - Criar arquivo para cada tarefa principal
     - Detalhar subtarefas e critérios de sucesso
     - Incluir testes unitários obrigatórios
@@ -93,19 +100,19 @@
     ## Especificações de Saída
 
     ### Localização dos Arquivos
-    - Pasta da funcionalidade: `ai/spec/prd-[nome-funcionalidade]/`
-    - Template para a lista de tarefas: `ai/templates/tasks-template.md`
-    - Lista de tarefas: `ai/spec/prd-[nome-funcionalidade]/tasks.md`
-    - Template para cada tarefa individual: `ai/templates/task-template.md`
-    - Tarefas individuais: `ai/spec/prd-[nome-funcionalidade]/[num]_task.md`
+    - Pasta da funcionalidade: `.dw/spec/prd-[nome-funcionalidade]/`
+    - Template para a lista de tarefas: `.dw/templates/tasks-template.md`
+    - Lista de tarefas: `.dw/spec/prd-[nome-funcionalidade]/tasks.md`
+    - Template para cada tarefa individual: `.dw/templates/task-template.md`
+    - Tarefas individuais: `.dw/spec/prd-[nome-funcionalidade]/[num]_task.md`
 
     ### Formato do Resumo de Tarefas (tasks.md)
 
-    - **SEGUIR ESTRITAMENTE O TEMPLATE EM `ai/templates/tasks-template.md`**
+    - **SEGUIR ESTRITAMENTE O TEMPLATE EM `.dw/templates/tasks-template.md`**
 
     ### Formato de Tarefa Individual ([num]_task.md)
 
-    - **SEGUIR ESTRITAMENTE O TEMPLATE EM `ai/templates/task-template.md`**
+    - **SEGUIR ESTRITAMENTE O TEMPLATE EM `.dw/templates/task-template.md`**
 
     ## Diretrizes Finais
 

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

@@ -6,12 +6,39 @@
     <critical>USAR O CONTEXT7 MCP PARA QUESTÕES TÉCNICAS SOBRE FRAMEWORKS E BIBLIOTECAS</critical>
     <critical>Este comando é APENAS para criar o documento TechSpec. NÃO implemente NADA. NÃO escreva código. NÃO crie arquivos de código. NÃO modifique arquivos do projeto. Apenas gere o documento TechSpec em markdown.</critical>
 
+    ## Quando Usar
+    - Use quando tiver um PRD completo e precisar definir arquitetura de implementação, contratos de API e estratégia de testes
+    - NÃO use quando os requisitos ainda não foram definidos (crie um PRD primeiro com `/dw-create-prd`)
+
+    ## Posição no Pipeline
+    **Antecessor:** `/dw-create-prd` | **Sucessor:** `/dw-create-tasks`
+
+    ## Fluxograma de Decisão Multi-Projeto
+
+    ```dot
+    digraph multi_project {
+      rankdir=TB;
+      node [shape=diamond];
+      Q1 [label="Does the PRD list\nmultiple impacted projects?"];
+      Q2 [label="Do projects share\ndata contracts?"];
+      node [shape=box];
+      SINGLE [label="Single-project TechSpec\nStandard template"];
+      MULTI [label="Multi-project TechSpec\nAdd per-project sections\nDefine integration architecture"];
+      CONTRACTS [label="Add data contract\ndefinitions between projects"];
+      Q1 -> SINGLE [label="No"];
+      Q1 -> Q2 [label="Yes"];
+      Q2 -> CONTRACTS [label="Yes"];
+      Q2 -> MULTI [label="No"];
+      CONTRACTS -> MULTI;
+    }
+    ```
+
     ## Variáveis de Entrada
 
     | Variável | Descrição | Exemplo |
     |----------|-----------|---------|
-    | `{{RULES_PATH}}` | Caminho para as rules/padrões do projeto | `ai/rules/`, `CLAUDE.md` |
-    | `{{PRD_PATH}}` | Caminho do PRD da funcionalidade | `ai/spec/prd-notifications/prd.md` |
+    | `{{RULES_PATH}}` | Caminho para as rules/padrões do projeto | `.dw/rules/`, `CLAUDE.md` |
+    | `{{PRD_PATH}}` | Caminho do PRD da funcionalidade | `.dw/spec/prd-notifications/prd.md` |
 
     ## Objetivos Principais
 
@@ -22,20 +49,20 @@
 
     ## Template e Entradas
 
-    - Template Tech Spec: `ai/templates/techspec-template.md`
-    - PRD requerido: `{{PRD_PATH}}` (ex: `ai/spec/prd-[nome-funcionalidade]/prd.md`)
+    - Template Tech Spec: `.dw/templates/techspec-template.md`
+    - PRD requerido: `{{PRD_PATH}}` (ex: `.dw/spec/prd-[nome-funcionalidade]/prd.md`)
     - Documento de saída: mesmo diretório do PRD como `techspec.md`
-    - Rules do projeto: `{{RULES_PATH}}` e `ai/rules/`
-    - Integrações do ecossistema: `ai/rules/integrations.md` (se existir)
+    - Rules do projeto: `{{RULES_PATH}}` e `.dw/rules/`
+    - Integrações do ecossistema: `.dw/rules/integrations.md` (se existir)
 
     ## Features Multi-Projeto
 
     Muitas funcionalidades podem envolver múltiplos projetos do workspace. Para Tech Specs multi-projeto:
 
     **Antes de iniciar**, consulte:
-    - `ai/rules/index.md` - Visão de todos os projetos
-    - `ai/rules/integrations.md` - Como os sistemas se comunicam (se existir)
-    - `ai/rules/[projeto].md` - Detalhes técnicos do projeto específico
+    - `.dw/rules/index.md` - Visão de todos os projetos
+    - `.dw/rules/integrations.md` - Como os sistemas se comunicam (se existir)
+    - `.dw/rules/[projeto].md` - Detalhes técnicos do projeto específico
 
     ### Ao documentar Tech Spec multi-projeto
 
@@ -48,7 +75,7 @@
     ## Pré-requisitos
 
     - Revisar padrões do projeto em `{{RULES_PATH}}`
-    - Confirmar que o PRD existe em `{{PRD_PATH}}` ou `ai/spec/prd-[nome-funcionalidade]/prd.md`
+    - Confirmar que o PRD existe em `{{PRD_PATH}}` ou `.dw/spec/prd-[nome-funcionalidade]/prd.md`
 
     ## Fluxo de Trabalho
 
@@ -62,7 +89,7 @@
     - Mapear símbolos, dependências e pontos críticos
     - Explorar estratégias de solução, padrões, riscos e alternativas
     - Realizar análise ampla: chamadores/chamados, configs, middleware, persistência, concorrência, tratamento de erros, testes, infra
-    - **Se multi-projeto**: consultar `ai/rules/integrations.md` e rules específicas de cada projeto
+    - **Se multi-projeto**: consultar `.dw/rules/integrations.md` e rules específicas de cada projeto
 
     ### 3. Esclarecimentos Técnicos (Obrigatório)
     Fazer perguntas focadas sobre:
@@ -77,7 +104,7 @@
     - Destacar desvios com justificativa e alternativas conformes
 
     ### 5. Gerar Tech Spec (Obrigatório)
-    - Usar `ai/templates/techspec-template.md` como estrutura exata
+    - Usar `.dw/templates/techspec-template.md` como estrutura exata
     - Fornecer: visão geral da arquitetura, design de componentes, interfaces, modelos, endpoints, pontos de integração, análise de impacto, estratégia de testes, observabilidade
     - **Incluir seção de Branch**:
       - Padrão: `feat/prd-[nome-da-feature]`
@@ -117,7 +144,7 @@
 
     - [ ] PRD revisado e notas de limpeza preparadas se necessário
     - [ ] Rules do projeto (`{{RULES_PATH}}`) revisadas
-    - [ ] Integrações consultadas (`ai/rules/integrations.md`) se multi-projeto
+    - [ ] Integrações consultadas (`.dw/rules/integrations.md`) se multi-projeto
     - [ ] Análise profunda do repositório completada
     - [ ] Esclarecimentos técnicos principais respondidos
     - [ ] Tech Spec gerada usando o template

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

@@ -5,11 +5,19 @@ Você é um assistente de pesquisa avançada capaz de conduzir investigações p
 <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 do relatório, sem abreviações ou ranges</critical>
 
-## Quando Usar / NÃO Usar
+## Quando Usar
+- Use para análise abrangente multi-fonte, comparações de tecnologia ou revisões do estado da arte que exigem evidências citadas
+- NÃO use para buscas simples, debugging ou perguntas que podem ser respondidas com 1-2 buscas
 
-**Usar:** Análise abrangente, comparações de tecnologia, revisões do estado da arte, investigação multi-perspectiva, análise de mercado.
+## Posição no Pipeline
+**Antecessor:** (pergunta do usuário ou `/dw-brainstorm`) | **Sucessor:** `/dw-create-prd` ou relatório independente
 
-**NÃO usar:** Buscas simples, debugging, respostas que precisam de 1-2 buscas, consultas rápidas.
+## Variáveis de Entrada
+
+| Variável | Descrição | Exemplo |
+|----------|-----------|---------|
+| `{{TOPIC}}` | Tópico ou pergunta de pesquisa | `"compare React Server Components vs Astro Islands"` |
+| `{{MODE}}` | Profundidade da pesquisa (opcional, padrão: standard) | `quick`, `standard`, `deep`, `ultradeep` |
 
 ## Princípio de Autonomia
 
@@ -30,7 +38,7 @@ Seleção de Modo
 +-- Revisão abrangente --> ultradeep (8+ fases, 20-45 min)
 ```
 
-## Pipeline de 8 Fases
+## Pipeline de 9 Fases
 
 ### Fase 1: ESCOPO - Enquadramento da Pesquisa
 - Decompor a questão em componentes centrais
@@ -73,33 +81,33 @@ Decompor a questão de pesquisa em 5-10 ângulos de busca independentes:
 - Avaliar credibilidade das fontes
 - Documentar status de verificação por afirmação
 
-### Fase 4.5: REFINAMENTO DO ESBOÇO - Evolução Dinâmica
+### Fase 5: REFINAMENTO DO ESBOÇO - Evolução Dinâmica
 - Comparar escopo inicial com descobertas reais
 - Adaptar estrutura do relatório baseado em evidências
 - Preencher lacunas com buscas direcionadas (2-5 min)
 - Documentar justificativa das adaptações
 
-### Fase 5: SINTETIZAR - Análise Profunda
+### Fase 6: SINTETIZAR - Análise Profunda
 - Identificar padrões entre fontes
 - Mapear relações entre conceitos
 - Gerar insights além do material fonte
 - Criar frameworks conceituais
 - Construir hierarquias de evidências
 
-### Fase 6: CRITICAR - Garantia de Qualidade (deep/ultradeep)
+### Fase 7: CRITICAR - Garantia de Qualidade (deep/ultradeep)
 - Revisar consistência lógica
 - Verificar completude das citações
 - Identificar lacunas ou fraquezas
 - Testar interpretações alternativas
 - Simular 2-3 personas de críticos relevantes
 
-### Fase 7: REFINAR - Melhoria Iterativa (deep/ultradeep)
+### Fase 8: REFINAR - Melhoria Iterativa (deep/ultradeep)
 - Conduzir pesquisa adicional para lacunas
 - Fortalecer argumentos fracos
 - Adicionar perspectivas ausentes
 - Resolver contradições
 
-### Fase 8: EMPACOTAR - Geração do Relatório
+### Fase 9: EMPACOTAR - Geração do Relatório
 
 Gerar relatório progressivamente, seção por seção:
 
@@ -151,8 +159,8 @@ Gerar relatório progressivamente, seção por seção:
 ## Exemplo de Uso
 
 ```
-/deep-research "Comparação de ORMs para Node.js em 2025: Prisma vs Drizzle vs TypeORM"
-/deep-research --mode=deep "Estado da arte em autenticação passwordless"
+/dw-deep-research "Comparação de ORMs para Node.js em 2025: Prisma vs Drizzle vs TypeORM"
+/dw-deep-research --mode=deep "Estado da arte em autenticação passwordless"
 ```
 
 </system_instructions>

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

@@ -5,11 +5,27 @@ Você é um assistente IA especializado em correção de bugs pós-QA com retest
 <critical>Use Playwright MCP para retestar os fluxos corrigidos</critical>
 <critical>Atualize os artefatos dentro de {{PRD_PATH}}/QA/ a cada ciclo</critical>
 
+## Quando Usar
+- Use para corrigir bugs identificados durante testes de QA com reteste iterativo até estabilizar
+- NÃO use para corrigir um bug de report de usuário (use `/dw-bugfix` em vez disso)
+- NÃO use para rodar testes de QA (use `/dw-run-qa` em vez disso)
+
+## Posição no Pipeline
+**Antecessor:** `/dw-run-qa` | **Sucessor:** `/dw-commit` e depois `/dw-generate-pr`
+
+## Skills Complementares
+
+Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como suporte operacional sem substituir este comando:
+
+- `agent-browser`: suporte para reproduzir bugs com sessões persistentes, capturar dados de rede, screenshots adicionais e validar correções browser-first
+- `webapp-testing`: suporte para estruturar retestes, capturas e scripts quando complementar ao Playwright MCP
+- `vercel-react-best-practices`: use apenas se a correção afetar frontend React/Next.js e houver risco de regressão de renderização, hidratação, fetching ou 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` |
 
 ## Objetivo
 
@@ -25,6 +41,7 @@ Executar ciclo iterativo de:
 - PRD: `{{PRD_PATH}}/prd.md`
 - TechSpec: `{{PRD_PATH}}/techspec.md`
 - Tasks: `{{PRD_PATH}}/tasks.md`
+- Credenciais de Teste QA: `.dw/templates/qa-test-credentials.md`
 - Bugs: `{{PRD_PATH}}/QA/bugs.md`
 - Relatório QA: `{{PRD_PATH}}/QA/qa-report.md`
 - Evidências: `{{PRD_PATH}}/QA/screenshots/`
@@ -33,11 +50,21 @@ Executar ciclo iterativo de:
 
 ## Fluxo Obrigatório
 
+### Definições de Severidade
+
+| Severidade | Critério | Exemplo |
+|------------|----------|---------|
+| Crítica | Crash do app, perda de dados, vulnerabilidade de segurança | TypeError ao salvar, XSS em input |
+| Alta | Fluxo principal quebrado, funcionalidade bloqueante | Botão de login não funcional |
+| Média | Feature degradada mas existe workaround | Ordenação não funciona na tabela |
+| Baixa | Problema visual menor, cosmético | Alinhamento de botão deslocado 2px |
+
 ### 1. Triagem dos Bugs em Aberto
 
 - Ler `QA/bugs.md` e listar bugs com `Status: Aberto`
 - Priorizar por severidade: Crítica > Alta > Média > Baixa
 - Mapear cada bug ao requisito (RF) e ao arquivo/camada afetada
+- Ler `.dw/templates/qa-test-credentials.md` e selecionar credenciais compatíveis com o bug (admin, perfil restrito, multi-tenant, etc.)
 
 ### 2. Implementação das Correções
 
@@ -59,6 +86,8 @@ Para cada bug corrigido:
 6. Coletar logs:
    - `QA/logs/console-retest.log`
    - `QA/logs/network-retest.log`
+7. Registrar no relatório de QA qual usuário/perfil foi usado no reteste
+8. Se o reteste exigir auth persistente, inspeção além do MCP, ou reprodução mais fiel em navegador real, complementar com `agent-browser` e registrar no relatório
 
 ### 4. Atualização de Artefatos