@brunosps00/dev-workflow 0.0.7 → 0.1.1

package/scaffold/pt-br/commands/dw-review-implementation.md

@@ -7,7 +7,7 @@
     - NÃO use quando os requisitos ainda não foram finalizados
 
     ## Posição no Pipeline
-    **Antecessor:** `/dw-run-plan` (auto) ou `/dw-run-task` (manual) | **Sucessor:** `/dw-code-review`
+    **Antecessor:** `/dw-run-plan` (auto) ou `/dw-run-task` (manual) | **Sucessor:** `/dw-code-review` (auto-fixes gaps before completing)
 
     Chamado por: `/dw-run-plan` ao final de todas as tasks
 
@@ -170,31 +170,82 @@
     2. [ação secundária]
     ```
 
-    ### 8. Decisão Pós-Relatório (Obrigatório)
+    ### 8. Loop de Resolução de Gaps (Obrigatório)
 
-    **Se NÃO há gaps (0 pendentes, 0 parciais, 100% implementado):**
-    - Apresente o relatório ao usuário
-    - **NÃO entre em modo de planejamento**
-    - **NÃO crie tasks adicionais**
-    - **NÃO proponha implementar nada**
-    - Simplesmente conclua com: "Implementação 100% conforme. Nenhuma ação necessária."
-    - ENCERRE a revisão imediatamente
+    <critical>A revisão NÃO termina no primeiro relatório. Se gaps forem encontrados, entre em um loop automático de fix-review até 100% de conformidade ou BLOCK explícito.</critical>
 
-    **Se HÁ gaps (pendentes > 0 OU parciais > 0):**
-    - Apresente o relatório com gaps e recomendações
-    - Liste ações necessárias para resolver cada gap
-    - Aguarde instruções do usuário sobre como proceder
-    - **NÃO execute correções sem instrução explícita do usuário**
+    Após gerar o relatório, avalie:
 
-    **Fluxo de Decisão de Verificação de Conformidade:**
     ```dot
-    digraph compliance {
-      "Analysis Complete" -> "0 gaps AND 0 partial?";
-      "0 gaps AND 0 partial?" -> "Report + EXIT" [label="yes"];
-      "0 gaps AND 0 partial?" -> "Report + List Actions\nWAIT for user" [label="no"];
+    digraph review_loop {
+      rankdir=TB;
+      "Generate Review Report" -> "Gaps found?";
+      "Gaps found?" -> "100% Compliant\nExit" [label="no"];
+      "Gaps found?" -> "Fix gaps\n(implement missing code)" [label="yes"];
+      "Fix gaps\n(implement missing code)" -> "Re-review\nimplementation";
+      "Re-review\nimplementation" -> "Still gaps?";
+      "Still gaps?" -> "100% Compliant\nExit" [label="no"];
+      "Still gaps?" -> "Max cycles\nreached?" [label="yes"];
+      "Max cycles\nreached?" -> "Fix gaps\n(implement missing code)" [label="no"];
+      "Max cycles\nreached?" -> "BLOCKED\nReport residual gaps" [label="yes (3 cycles)"];
     }
     ```
 
+    **Regras do loop:**
+    1. Após o relatório inicial, se houver gaps (❌ não implementado ou ⚠️ parcial), entre no loop automaticamente
+    2. Para cada ciclo:
+       a. Corrija todos os gaps identificados: implemente código faltante, complete implementações parciais
+       b. Siga os padrões do projeto em `.dw/rules/` durante as correções
+       c. Execute testes após as correções (`pnpm test` ou equivalente)
+       d. Releia os arquivos alterados e recompare com os requisitos do PRD
+       e. Atualize o relatório de revisão com os resultados do ciclo
+       f. Se 100% conforme → saia do loop, apresente o relatório final
+       g. Se gaps permanecerem → continue para o próximo ciclo
+    3. **Máximo de 3 ciclos de fix-review.** Após 3 ciclos, marque a revisão como **BLOCKED** com gaps residuais documentados
+    4. Cada ciclo deve adicionar uma seção ao relatório mostrando o que foi corrigido e o novo status de conformidade
+    5. Commite correções após cada ciclo: `fix(review): implement [requirement] from PRD`
+
+    **O que corrigir automaticamente:**
+    - ❌ Requisitos não implementados → implemente-os
+    - ⚠️ Requisitos parcialmente implementados → complete-os
+    - 📝 Tasks marcadas como concluídas mas incompletas → finalize-as
+
+    **O que NÃO corrigir (parar e perguntar ao usuário):**
+    - Requisitos que contradizem uns aos outros no PRD
+    - Requisitos que precisam de decisões arquiteturais não cobertas na TechSpec
+    - Requisitos que dependem de serviços externos não disponíveis
+    - Se uma correção ultrapassar o escopo de uma única task
+
+    **Formato do relatório por ciclo (adicionar ao relatório de revisão):**
+    ```markdown
+    ## Fix Cycle [N] — [YYYY-MM-DD]
+
+    ### Gaps Resolved
+    | RF | Description | Action Taken | Status |
+    |----|-------------|-------------|--------|
+    | RF-XX | [requirement] | [what was implemented] | ✅ |
+
+    ### Tests
+    - `pnpm test`: PASS/FAIL
+    - Files changed: [list]
+
+    ### Remaining Gaps
+    - [list or "None"]
+
+    ### Cycle Result: CONTINUE / COMPLIANT / BLOCKED
+    ```
+
+    **Se 100% conforme após qualquer ciclo:**
+    - Apresente o relatório final
+    - **NÃO entre em modo de planejamento (EnterPlanMode)**
+    - **NÃO crie tasks (TaskCreate)**
+    - Conclua com: "Implementação 100% conforme após [N] ciclos de fix. Nenhuma ação adicional necessária."
+
+    **Se BLOCKED após 3 ciclos:**
+    - Apresente o relatório com gaps residuais
+    - Liste o que não pôde ser resolvido e por quê
+    - Aguarde instruções do usuário
+
     ## Níveis de Status
 
     | Ícone | Significado |
@@ -246,4 +297,5 @@
     <critical>NÃO APROVE requisitos sem evidência concreta no código</critical>
     <critical>ANALISE o código real, não confie apenas nos checkboxes do tasks.md</critical>
     <critical>Se 100% dos requisitos foram implementados e NÃO há gaps: NÃO entre em plan mode, NÃO crie tasks. Apenas apresente o relatório e ENCERRE.</critical>
+    <critical>Se gaps forem encontrados, entre no loop de fix-review automaticamente. NÃO aguarde instruções do usuário para corrigir gaps. Máximo de 3 ciclos antes de marcar como BLOCKED.</critical>
 </system_instructions>

package/scaffold/pt-br/commands/dw-run-qa.md

@@ -7,7 +7,7 @@ Você é um assistente IA especializado em Quality Assurance. Sua tarefa é vali
 - NÃO use quando os requisitos ainda não foram definidos (crie o PRD primeiro)
 
 ## Posição no Pipeline
-**Antecessor:** `/dw-run-plan` ou `/dw-run-task` | **Sucessor:** `/dw-fix-qa` (se bugs) ou `/dw-code-review`
+**Antecessor:** `/dw-run-plan` ou `/dw-run-task` | **Sucessor:** `/dw-code-review` (auto-fixes bugs internally before completing)
 
 <critical>Utilize o Playwright MCP para executar todos os testes E2E</critical>
 <critical>Verifique TODOS os requisitos do PRD e TechSpec antes de aprovar</critical>
@@ -20,7 +20,6 @@ Você é um assistente IA especializado em Quality Assurance. Sua tarefa é vali
 
 Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como apoio operacional sem substituir este comando:
 
-- `agent-browser`: apoio para navegação operacional, auth persistente, screenshots adicionais, inspeção de requests e debugging de sessão
 - `webapp-testing`: apoio para estruturar fluxos de teste, retestes, screenshots e logs quando complementar ao Playwright MCP
 - `vercel-react-best-practices`: use apenas se o frontend sob teste for React/Next.js e houver indicação de regressão relacionada a renderização, fetching, hidratação ou performance percebida
 
@@ -96,7 +95,7 @@ Consulte `.dw/rules/` para URLs e frameworks específicos do projeto.
 - Verificar se a aplicação está rodando em localhost
 - Usar `browser_navigate` do Playwright MCP para acessar a aplicação
 - Confirmar que a página carregou corretamente com `browser_snapshot`
-- Se sessão persistente, import de auth, inspeção de rede além do MCP ou reprodução browser-first forem necessários, complementar com `agent-browser`
+- Se sessão persistente, import de auth, inspeção de rede além do MCP ou reprodução browser-first forem necessários, complementar com `webapp-testing`
 
 ### 3. Verificação de Páginas do Menu (Obrigatório — Executar ANTES dos testes de RF)
 
@@ -163,7 +162,7 @@ Para cada requisito funcional do PRD:
 8. Marcar como PASSOU ou FALHOU
 9. Salvar o script Playwright do fluxo em `{{PRD_PATH}}/QA/scripts/` com nome padronizado: `RF-XX-[slug].spec.ts` (ou `.js`)
 10. Registrar no relatório quais credenciais (usuário/perfil) foram usadas em cada fluxo sensível a permissões
-11. Quando o fluxo MCP ficar instável ou insuficiente para evidência operacional, complementar com `agent-browser` ou `webapp-testing`, registrando isso explicitamente no relatório
+11. Quando o fluxo MCP ficar instável ou insuficiente para evidência operacional, complementar com `webapp-testing`, registrando isso explicitamente no relatório
 
 <critical>Não basta validar apenas o caminho feliz. Cada requisito deve ser exercitado contra seus estados de borda e suas regressões mais prováveis</critical>
 <critical>Se um requisito não puder ser completamente validado via E2E, o QA deve ser marcado como REJEITADO ou BLOQUEADO, nunca APROVADO</critical>
@@ -270,6 +269,62 @@ Gerar relatório em `{{PRD_PATH}}/QA/qa-report.md`:
 [Parecer final do QA]
 ```
 
+### 9. Loop QA Fix-Retest (Automático)
+
+<critical>O QA NÃO termina no primeiro relatório. Se bugs forem encontrados, entre em um loop automático de fix-retest até que o QA seja APROVADO ou explicitamente BLOQUEADO.</critical>
+
+Após gerar o relatório inicial de QA:
+
+```dot
+digraph qa_loop {
+  rankdir=TB;
+  "Generate QA Report" -> "Bugs found?";
+  "Bugs found?" -> "QA APPROVED\nExit" [label="no"];
+  "Bugs found?" -> "Fix bugs\n(follow dw-fix-qa rules)" [label="yes"];
+  "Fix bugs\n(follow dw-fix-qa rules)" -> "Retest ALL\nfixed bugs";
+  "Retest ALL\nfixed bugs" -> "New/reopened\nbugs?";
+  "New/reopened\nbugs?" -> "QA APPROVED\nExit" [label="no"];
+  "New/reopened\nbugs?" -> "Max cycles\nreached?" [label="yes"];
+  "Max cycles\nreached?" -> "Fix bugs\n(follow dw-fix-qa rules)" [label="no"];
+  "Max cycles\nreached?" -> "QA BLOCKED\nReport residual bugs" [label="yes (5 cycles)"];
+}
+```
+
+**Regras do loop:**
+1. Após o relatório inicial, se `QA/bugs.md` tiver bugs com `Status: Open`, entre no loop automaticamente
+2. Para cada ciclo:
+   a. Corrija todos os bugs abertos cirurgicamente (mesmas regras do `/dw-fix-qa`: sem scope creep, impacto mínimo)
+   b. Reteste TODOS os bugs corrigidos via Playwright MCP com captura de evidências
+   c. Verifique regressões introduzidas pelas correções
+   d. Atualize `QA/bugs.md` e `QA/qa-report.md` com os resultados do ciclo
+   e. Se todos os bugs críticos/altos estiverem fechados → **QA APPROVED**, saia do loop
+   f. Se novos bugs apareceram ou correções falharam → continue para o próximo ciclo
+3. **Máximo de 5 ciclos de fix-retest.** Após 5 ciclos, marque o QA como **BLOCKED** com bugs residuais documentados
+4. Cada ciclo deve atualizar o relatório de QA com uma seção "Cycle N" mostrando o que foi corrigido, retestado e o resultado
+5. Faça commit das correções após cada ciclo bem-sucedido: `fix(qa): resolve BUG-NN [description]`
+
+**Formato do relatório por ciclo (adicionar ao qa-report.md):**
+```markdown
+## Fix-Retest Cycle [N] — [YYYY-MM-DD]
+
+### Bugs Fixed
+| Bug | Fix Description | Retest | Evidence |
+|-----|----------------|--------|----------|
+| BUG-01 | [what was changed] | PASS/FAIL | `QA/screenshots/BUG-01-cycle-N.png` |
+
+### Regressions Checked
+- [list of related flows retested]
+
+### Cycle Result
+- **Bugs remaining:** [count]
+- **Status:** CONTINUE / APPROVED / BLOCKED
+```
+
+**Red flags — PARE o loop:**
+- Correção requer uma nova feature (não é bug) → pare, recomende `/dw-create-prd`
+- Correção requer refatoração significativa → pare, recomende `/dw-refactoring-analysis`
+- Mesmo bug reaparece após 2+ tentativas de correção → marque como BLOCKED com análise de causa raiz
+
 ## Checklist de Qualidade
 
 - [ ] PRD analisado e requisitos extraídos

package/scaffold/pt-br/commands/dw-run-task.md

@@ -20,7 +20,6 @@ Quando disponíveis no projeto em `./.agents/skills/`, use estas skills como sup
 |-------|---------|
 | `vercel-react-best-practices` | Task envolve renderização React, hidratação, data fetching, bundle, cache ou performance |
 | `webapp-testing` | Task tem frontend interativo que necessita validação E2E em navegador real |
-| `agent-browser` | Validação de UI requer sessão persistente, inspeção de navegação operacional ou evidência visual complementar |
 
 ## Localização dos Arquivos
 
@@ -78,7 +77,7 @@ Após fornecer o resumo e abordagem, **comece imediatamente** a implementar a ta
 - Seguir padrões estabelecidos do projeto
 - Garantir que todos os requisitos sejam atendidos
 - **Rodar testes**: use o comando de teste do projeto
-- Se houver frontend interativo, valide também o comportamento real com `webapp-testing` ou `agent-browser` quando isso reduzir o risco de regressão invisível nos testes unitários
+- Se houver frontend interativo, valide também o comportamento real com `webapp-testing` quando isso reduzir o risco de regressão invisível nos testes unitários
 
 **VOCÊ DEVE** iniciar a implementação logo após o processo acima.