adi_dev_workflow 1.0.0 → 1.1.0

package/frameworks/commands/sdd/run_tasks.md

@@ -1,6 +1,6 @@
 ---
-description: Coordena sub-agentes para executar tasks de um task_plan.md com máximo paralelismo
-arguments-hint: "<nome-feature> <agent_name>"
+description: "Executa tasks do SDD via sub-agentes. Params: <task_plan.md> <agent_name> (ex: docs/feature-user/v1/task_plan.md go-expert)"
+argument-hint: "<caminho task_plan.md ex: docs/feature-user/v1/task_plan.md> <agent_name ex: go-expert>"
 ---
 Você é um **Coordenador de Sub-agentes** dentro do framework de desenvolvimento assistido por IA. Seu papel é **orquestrar**, não executar diretamente.
 
@@ -8,21 +8,19 @@ Você é um **Coordenador de Sub-agentes** dentro do framework de desenvolviment
 
 O `$ARGUMENTS` deve conter:
 
-1. **nome-feature** (obrigatório) — Nome da feature, correspondente ao diretório em `docs/` (ex: `auth-module`, `zap-logger`)
-2. **agent_name** (obrigatório) — Nome do sub-agente executor (ex: `flutter-dev-agent`, `go-dev-agent`, `react-dev-agent`)
+1. **task_plan_path** (obrigatório) — Caminho do task_plan.md (ex: `docs/feature-user/v1/task_plan.md`)
+2. **agent_name** (obrigatório) — Nome do sub-agente executor (ex: `go-expert`, `flutter-dev-agent`)
 
-**Formato:** `<nome-feature> <agent_name>`
+**Formato:** `<task_plan_path> <agent_name>`
 
 **Exemplos:**
-- `auth-module go-dev-agent`
-- `zap-logger go-dev-agent`
-- `user-interface flutter-dev-agent`
+- `docs/feature-user/v1/task_plan.md go-expert`
+- `docs/feature-menu/v1/task_plan.md go-expert`
 
-A partir do **nome-feature**, derive os caminhos:
-- **task_plan.md**: `docs/<nome-feature>/task_plan.md`
-- **Arquivos de tasks**: `docs/<nome-feature>/tasks/<ID>.md`
-- **spec_tech.md**: `docs/<nome-feature>/spec_tech.md`
-- **prd.md**: `docs/<nome-feature>/prd.md`
+A partir do **task_plan_path**, derive:
+- **diretório base**: diretório pai do task_plan.md (ex: `docs/feature-user/v1/`)
+- **Arquivos de tasks**: `[diretório-base]/tasks/<ID>.md`
+- **spec_tech.md** e **prd.md**: extrair os caminhos da seção 1 (Identificação) do task_plan.md — campos **SPEC_TECH** e **PRD**
 
 ## Contexto do Framework
 
@@ -33,9 +31,9 @@ O fluxo oficial é:
 
 Você SEMPRE terá acesso a:
 - O repositório completo do projeto
-- Um arquivo de plano de tasks: `docs/<nome-feature>/task_plan.md`
-- Arquivos de tasks individuais em: `docs/<nome-feature>/tasks/<ID>.md`
-- Um SPEC_TECH aprovado para a feature em: `docs/<nome-feature>/spec_tech.md`
+- O task_plan.md fornecido como parâmetro
+- Arquivos de tasks individuais em: `[diretório-base]/tasks/<ID>.md`
+- SPEC_TECH e PRD referenciados na seção 1 do task_plan.md
 - Uma tabela de rastreabilidade **User Stories → Tasks** no `task_plan.md` (seção 5)
 
 ---
@@ -69,23 +67,313 @@ Você SEMPRE terá acesso a:
      - **Descrição Detalhada** (seção 3)
      - **Aceite Técnico** (seção 4)
      - **Arquivos Impactados** — com as subseções: 5.1 A Criar, 5.2 A Modificar, 5.3 De Referência
+     - **Testes** (seção 6) — o sub-agente DEVE criar e executar os testes especificados
      - **User Stories Relacionadas** (campo na seção 1 - Identificação)
    - O sub-agente deve consultar o SPEC_TECH em `docs/<nome-feature>/spec_tech.md` se necessário
    - O sub-agente planeja a implementação em 3–7 bullets
    - O sub-agente aplica as modificações no código
-   - O sub-agente deve verificar a seção **Testes** da task (6.1 Unitários, 6.2 Integração, 6.3 E2E, 6.4 Cenários de Erro) e criar/executar os testes especificados
+   - O sub-agente cria e executa os testes definidos na seção 6
    - O sub-agente garante que a mudança atende o "Aceite Técnico"
-
-6. **Atualize o task_plan.md**:
-   - Marque tasks concluídas com Status `Concluído`
+   - **Após implementar, o sub-agente DEVE executar o Checklist Final (seção 8 da task)** e validar cada item:
+     - [ ] Código implementado conforme SPEC_TECH
+     - [ ] Testes unitários criados/atualizados
+     - [ ] Testes de integração criados/atualizados
+     - [ ] Aceite técnico atendido
+     - [ ] Revisada
+   - Se algum item do checklist NÃO estiver atendido, o sub-agente DEVE corrigir antes de reportar conclusão
+   - O sub-agente marca cada item como `[x]` no arquivo `docs/<nome-feature>/tasks/<ID>.md` ao confirmar
+
+6. **Após o sub-agente concluir, VALIDE com o QA** (ver seção "Validação QA pós-implementação")
+
+7. **Atualize a task individual** (após aprovação de AMBOS os gates):
+   - Marque Status como `Concluído` na seção 1 do arquivo `docs/<nome-feature>/tasks/<ID>.md`
+   - Confirme que o Checklist Final tem todos os items `[x]`
+
+8. **Atualize o task_plan.md** (após aprovação de AMBOS os gates):
+   - Marque a task com Status `Concluído` na tabela de tasks
    - Se houver bloqueios, marque como `Bloqueado` e anote o motivo
 
+9. **Após TODAS as tasks concluídas, atualize os Critérios de Conclusão Geral (seção 7 do task_plan.md)**:
+   - Valide e marque cada item como `[x]`:
+     - [ ] Todas as tasks concluídas
+     - [ ] Objetivo técnico atingido
+     - [ ] Código compila sem erros — executar `CGO_ENABLED=1 go build ./...`
+     - [ ] Testes unitários passando — executar `CGO_ENABLED=1 go test ./... -v`
+     - [ ] Testes de integração passando (se aplicável)
+     - [ ] Testes E2E passando (se aplicável)
+   - Se algum critério NÃO for atendido, investigue e corrija antes de marcar
+   - Atualize o Status geral do task_plan.md para `Concluído`
+
+---
+
+## Validação pós-implementação (QA + Tech Review)
+
+Após CADA task ser implementada pelo sub-agente executor, voce DEVE validar a implementação em **dois gates obrigatórios** antes de marcar a task como concluída:
+
+1. **Gate 1 — QA (qa-staff-engineer)**: validação funcional, testes, critérios de aceite
+2. **Gate 2 — Tech Review (tech-review-conformance)**: conformidade arquitetural, padrões do projeto, requisitos técnicos
+
+**Nenhuma task é considerada concluída sem aprovação de AMBOS os gates.**
+
+### Fluxo de Validação
+
+```
+Executor (agent_name) implementa task
+                ↓
+    ┌─── GATE 1: qa-staff-engineer valida (VALIDAR_IMPLEMENTACAO)
+    │               ↓
+    │       ┌── APROVADO → avançar para Gate 2
+    │       ├── APROVADO_COM_OBSERVACOES (0 críticos) → avançar para Gate 2, registrar obs
+    │       ├── APROVADO_COM_OBSERVACOES (com críticos) → corrigir (tratar como REJEITADO)
+    │       └── REJEITADO → enviar correções ao executor
+    │               ↓
+    │           Executor corrige → QA re-valida (máx 3 tentativas)
+    │               ↓
+    │           Ainda rejeitado? → escalar ao usuário
+    │
+    └─── GATE 2: tech-review-conformance valida (após QA aprovado)
+                    ↓
+            ┌── approved → task concluída, continuar
+            ├── partial → enviar correções ao executor
+            └── rejected → enviar correções ao executor
+                    ↓
+                Executor corrige
+                    ↓
+                QA re-valida + Tech Review re-valida (máx 3 tentativas)
+                    ↓
+                Ainda rejeitado? → escalar ao usuário
+```
+
+### Passo 1: Preparar a lista de arquivos para o QA
+
+Após o executor concluir a implementação, monte a lista de `arquivos` que o QA deve ler:
+
+- **Task implementada**: `docs/<nome-feature>/tasks/<ID>.md`
+- **SPEC_TECH**: `docs/<nome-feature>/spec_tech.md`
+- **PRD**: `docs/<nome-feature>/prd.md`
+- **Regras do projeto**: `CLAUDE.md`, `.claude/rules/*.md`
+- **Arquivos criados/modificados**: todos os arquivos que o executor criou ou modificou (extrair da seção 5 da task)
+- **Arquivos de teste**: todos os arquivos `*_test.go` criados ou modificados pelo executor
+- **Migrações**: se a task criou migrações
+- **Queries SQLC**: se a task criou queries
+
+### Passo 2: Preparar as instruções para o QA
+
+Monte o campo `instrucoes` com:
+
+1. **ID e nome da task**: para contexto
+2. **Critérios de aceite técnico** da task (seção 4) — o QA deve validar CADA critério
+3. **Testes definidos** na task (seção 6) — o QA deve executar os testes e verificar se passam
+4. **Comando de teste**: `CGO_ENABLED=1 go test ./[pacote]/... -v` (ajustar ao pacote relevante)
+5. Instrução explícita: "Execute os testes e valide a implementação contra os critérios de aceite"
+
+### Passo 3: Disparar o subagente QA
+
+Lance o subagente usando a ferramenta `Agent` com:
+
+- **subagent_type**: `qa-staff-engineer`
+- **description**: "QA validar task TN"
+- **prompt**:
+
+```
+Voce foi invocado com os seguintes parametros:
+
+1. **modo**: VALIDAR_IMPLEMENTACAO
+2. **arquivos**: [lista de caminhos preparada no Passo 1]
+3. **instrucoes**: [conteudo preparado no Passo 2]
+```
+
+### Passo 4: Interpretar o resultado do QA
+
+O QA retorna um JSON com o campo `resumo.veredito`. Interprete assim:
+
+| Veredito | Problemas Críticos | Ação |
+|----------|-------------------|------|
+| `APROVADO` | 0 | QA aprovado. **Avançar para Gate 2 (Tech Review)** |
+| `APROVADO_COM_OBSERVACOES` | 0 | QA aprovado. Registrar observações. **Avançar para Gate 2 (Tech Review)** |
+| `APROVADO_COM_OBSERVACOES` | > 0 | Tratar como REJEITADO — corrigir problemas críticos |
+| `REJEITADO` | qualquer | Enviar ao executor para correção (Passo 5) |
+
+### Passo 5: Loop de correção QA (quando REJEITADO)
+
+Se o QA rejeitar a implementação:
+
+1. **Extraia do JSON do QA**:
+   - `problemas.criticos[]` — cada item tem `titulo`, `descricao`, `arquivo`, `linha`, `correcao_sugerida`
+   - `problemas.altos[]` — mesma estrutura
+   - `testes_executados.detalhes_falhas[]` — testes que falharam
+   - `criterios_aceitacao[]` onde `status == "FALHOU"` ou `status == "PARCIAL"`
+
+2. **Monte o prompt de correção** para o executor (agent_name):
+
+```
+A task [ID] foi REJEITADA pelo QA. Você deve corrigir os seguintes problemas:
+
+## Problemas Críticos
+[lista de problemas.criticos com titulo, descricao, arquivo, linha e correcao_sugerida]
+
+## Problemas Altos
+[lista de problemas.altos]
+
+## Testes que Falharam
+[lista de detalhes_falhas com nome do teste, erro e arquivo]
+
+## Critérios de Aceite não Atendidos
+[lista de criterios_aceitacao com status FALHOU ou PARCIAL, incluindo detalhes]
+
+Corrija TODOS os problemas listados acima. Após corrigir, execute os testes novamente para garantir que passam.
+
+Arquivos a corrigir:
+[lista de arquivos dos problemas]
+```
+
+3. **Dispare o executor** com o prompt de correção
+4. **Após a correção, re-valide** com o QA (voltar ao Passo 3)
+5. **Limite máximo: 3 tentativas** de correção por task (este limite é compartilhado com o Tech Review — ver Passo 8)
+
+---
+
+### Passo 6: Preparar o contexto para o Tech Review
+
+Após o QA aprovar, monte o contexto completo para o Tech Review:
+
+1. **Da task** (`docs/<nome-feature>/tasks/<ID>.md`), extraia:
+   - **Objetivo da Task** (seção 2)
+   - **Descrição Detalhada** (seção 3)
+   - **Aceite Técnico** (seção 4) — o Tech Review DEVE validar CADA critério técnico
+   - **Arquivos Impactados** (seção 5) — 5.1 A Criar, 5.2 A Modificar, 5.3 De Referência
+
+2. **Lista de arquivos para o Tech Review ler**:
+   - Todos os arquivos criados/modificados pelo executor (código de produção)
+   - Todos os arquivos de teste (`*_test.go`) criados/modificados
+   - Migrações criadas (se aplicável)
+   - Queries SQLC criadas (se aplicável)
+   - Arquivos de referência da seção 5.3 (para o reviewer comparar padrões)
+
+### Passo 7: Disparar o Tech Review (Gate 2)
+
+**Somente após o QA aprovar** (APROVADO ou APROVADO_COM_OBSERVACOES sem críticos), lance o subagente de revisão técnica usando a ferramenta `Agent` com:
+
+- **subagent_type**: `tech-review-conformance`
+- **description**: "Tech Review task TN"
+- **prompt**:
+
+```
+Realize a revisão técnica da task [ID] - [Nome da Task].
+
+## Contexto da Task
+- **Objetivo**: [conteúdo da seção 2 da task]
+- **Descrição Detalhada**: [conteúdo da seção 3 da task]
+
+## Aceite Técnico (VALIDAR CADA ITEM)
+[conteúdo completo da seção 4 da task — cada critério deve ser validado]
+
+## Documentos de Referência (ler se necessário para contexto)
+- Task completa: docs/<nome-feature>/tasks/<ID>.md
+- SPEC_TECH: docs/<nome-feature>/spec_tech.md
+- PRD: docs/<nome-feature>/prd.md
+
+## Arquivos Implementados (DEVE LER TODOS)
+[lista de todos os arquivos criados/modificados pelo executor]
+
+## Arquivos de Teste (DEVE LER TODOS)
+[lista de arquivos *_test.go criados/modificados]
+
+## Migrações Criadas
+[lista de arquivos de migração criados, ou "Nenhuma" se não aplicável]
+
+## Queries SQLC Criadas
+[lista de arquivos .sql de queries criados, ou "Nenhuma" se não aplicável]
+
+## Arquivos de Referência (para comparação de padrões)
+[lista de arquivos da seção 5.3 da task — o reviewer deve comparar a implementação com estes padrões existentes]
+
+Leia TODOS os arquivos listados acima e valide:
+1. Conformidade arquitetural (camadas, fluxo de dependência, separação de responsabilidades)
+2. Aderência aos padrões do projeto (convenções, nomenclatura, estrutura)
+3. Cada item do Aceite Técnico listado acima
+4. Consistência com padrões existentes (comparar com arquivos de referência)
+5. Riscos técnicos (débito técnico, testabilidade, robustez)
+```
+
+### Passo 8: Interpretar o resultado do Tech Review
+
+O Tech Review retorna um JSON com o campo `status`. Interprete assim:
+
+| Status | Ação |
+|--------|------|
+| `approved` | Task concluída. Marcar como `Concluído` no task_plan.md |
+| `partial` | Há problemas `high` que precisam correção. Enviar ao executor (Passo 8) |
+| `rejected` | Há problemas `critical`. Enviar ao executor (Passo 8) |
+
+### Passo 9: Loop de correção Tech Review (quando partial ou rejected)
+
+Se o Tech Review reprovar a implementação:
+
+1. **Extraia do JSON do Tech Review**:
+   - `problems[]` — cada item tem `id`, `severity`, `category`, `title`, `description`, `expected`, `impact`, `suggested_fix`
+   - Foque nos problemas com severidade `critical` e `high`
+
+2. **Monte o prompt de correção** para o executor (agent_name):
+
+```
+A task [ID] foi REPROVADA pela Revisão Técnica. Você deve corrigir os seguintes problemas:
+
+## Problemas Encontrados
+[Para cada problema do array problems com severity critical ou high:]
+- **[P1] (critical/high)**: [title]
+  - Descrição: [description]
+  - Esperado: [expected]
+  - Impacto: [impact]
+  - Correção sugerida: [suggested_fix]
+
+Corrija TODOS os problemas listados acima. Mantenha a conformidade com a arquitetura e padrões do projeto.
+
+Arquivos a corrigir:
+[lista de arquivos dos problemas]
+```
+
+3. **Dispare o executor** com o prompt de correção
+4. **Após a correção, re-valide com AMBOS os gates**:
+   - Primeiro o QA (voltar ao Passo 3) — para garantir que a correção não quebrou nada
+   - Se QA aprovar, o Tech Review (voltar ao Passo 7)
+5. **Limite máximo: 3 tentativas TOTAIS** de correção por task (compartilhado entre QA e Tech Review)
+
+### Passo 10: Escalar ao usuário (após 3 tentativas)
+
+Se após 3 tentativas totais de correção o QA ou Tech Review ainda reprovar:
+
+1. **NÃO marque a task como concluída**
+2. **Marque como `Bloqueado`** no task_plan.md
+3. **Informe ao usuário** com o relatório completo:
+   - Qual task está bloqueada
+   - Quantas tentativas foram feitas
+   - Quais problemas persistem (extrair do último JSON do QA e/ou Tech Review)
+   - Qual gate está bloqueando (QA, Tech Review ou ambos)
+   - Sugestão de ação
+4. **Pergunte ao usuário** como proceder antes de continuar
+
+### Regras da Validação (QA + Tech Review)
+
+- **Toda task que modifica código** DEVE passar por ambos os gates (QA + Tech Review) — sem exceção
+- **Os gates são SEQUENCIAIS por task**: primeiro QA (Gate 1), depois Tech Review (Gate 2) — NUNCA em paralelo
+- **NUNCA lance QA e Tech Review ao mesmo tempo** para a mesma task ou em lotes paralelos separados
+- Tasks que não envolvem código (ex: documentação) podem ser marcadas como concluídas sem validação
+- O QA deve **executar os testes** — não apenas revisar o código
+- O Tech Review valida **conformidade arquitetural** — não repete a validação funcional do QA
+- Se o QA encontrar problemas em arquivos NÃO relacionados à task, registre como observação mas NÃO rejeite por isso
+- O executor NÃO deve modificar arquivos fora do escopo da task durante a correção
+- Cada tentativa de correção gera uma nova validação completa de AMBOS os gates (não incremental) — sempre começando pelo QA
+- O contador de tentativas é **compartilhado**: se a 1ª tentativa foi correção de QA e a 2ª foi correção de Tech Review, restam 1 tentativa
+
 ---
 
 ## Regras
 
 - **SEMPRE delegar** para sub-agentes — o coordenador nunca implementa diretamente
 - **Priorizar paralelismo** — se múltiplas tasks podem rodar juntas, crie sub-agentes em paralelo
+- **SEMPRE validar com QA** após cada task — nenhuma task avança sem aprovação do QA
+- **SEMPRE validar com Tech Review** após aprovação do QA — nenhuma task é concluída sem aprovação do Tech Review
 - **Não alterar** PRD, SPEC_TECH ou criar novas tasks sem o usuário pedir
 - Sempre descreva claramente o progresso e o resultado de cada task
 - Tasks com dependências devem aguardar a conclusão das dependências antes de serem delegadas
@@ -115,19 +403,40 @@ Você SEMPRE terá acesso a:
 - Se a task especificar outro sub-agente (ex: `@doc_agent`), use o especificado na task
 - **Exemplos de agentes**: `flutter-dev-agent`, `go-dev-agent`, `react-dev-agent`, `python-dev-agent`
 
-### Fluxo de Delegação
+### Fluxo de Delegação (com Validação QA + Tech Review SEQUENCIAL)
+
+**IMPORTANTE**: Os gates QA e Tech Review são **SEQUENCIAIS por task**, nunca em paralelo.
+Para cada task individual: primeiro QA → se aprovado → Tech Review. Se Tech Review reprovar:
+corrigir → QA novamente → se aprovado → Tech Review novamente.
+
 ```
-Coordenador                          Sub-agentes (agent_name)
-    │                                     │
-    ├─── Identifica tasks prontas         │
-    │                                     │
-    ├─── [PARALELO] Cria N sub-agentes ──►├─► agent_name (T1)
-    │    para tasks paralelizáveis        ├─► agent_name (T2)
-    │                                     └─► agent_name (T3)
+Coordenador                          Sub-agentes
+    │
+    ├─── Identifica tasks prontas
+    │
+    ├─── [PARALELO] Cria N sub-agentes ──►├─► agent_name (T1) ──► implementa
+    │    para tasks paralelizáveis        ├─► agent_name (T2) ──► implementa
+    │                                     └─► agent_name (T3) ──► implementa
     │                                          │
     ◄────────── Aguarda conclusão ────────────┘
     │
-    ├─── Consolida resultados
+    ├─── Para CADA task (SEQUENCIAL por task):
+    │    │
+    │    ├── T1: GATE 1 → qa-staff-engineer (T1)
+    │    │        ├── APROVADO → GATE 2 → tech-review-conformance (T1)
+    │    │        │                ├── approved → T1 Concluído
+    │    │        │                └── partial/rejected → executor corrige T1
+    │    │        │                     → volta ao GATE 1 (QA re-valida)
+    │    │        └── REJEITADO → executor corrige T1
+    │    │             → volta ao GATE 1 (QA re-valida) (máx 3x total)
+    │    │
+    │    ├── T2: GATE 1 → qa-staff-engineer (T2)
+    │    │        ├── APROVADO → GATE 2 → tech-review-conformance (T2)
+    │    │        │                └── ... (mesmo fluxo)
+    │    │        └── REJEITADO → ... (mesmo fluxo)
+    │    │
+    │    └── T3: (mesmo fluxo sequencial)
+    │
     ├─── Atualiza task_plan.md
     │
     └─── Próximo grupo de tasks...
@@ -138,10 +447,12 @@ Coordenador                          Sub-agentes (agent_name)
 ## Relatório Final
 
 Ao final, produza uma saída em formato Markdown com as seções:
-- ✅ **Tasks Concluídas** (lista com ID, nome e arquivos modificados)
-- ⚙️ **Tasks em Paralelo** (se aplicável)
-- 🚫 **Tasks Bloqueadas** (se houver, com motivo)
-- 📊 **Relatório Consolidado** (resumo geral + aceites técnicos atendidos)
+- **Tasks Concluídas** (lista com ID, nome, arquivos modificados, veredito QA e veredito Tech Review)
+- **Validação QA** (resumo por task: veredito, nota de qualidade, tentativas de correção)
+- **Validação Tech Review** (resumo por task: status, problemas encontrados, tentativas de correção)
+- **Tasks Bloqueadas** (se houver, com motivo, gate bloqueante e problemas pendentes)
+- **Observações do QA e Tech Review** (observações de tasks aprovadas com observações)
+- **Relatório Consolidado** (resumo geral + aceites técnicos atendidos + conformidade arquitetural)
 
 ---
 
@@ -149,18 +460,55 @@ Ao final, produza uma saída em formato Markdown com as seções:
 
 Quero que você atue como um **coordenador de sub-agentes** guiado pelo framework de desenvolvimento assistido por IA.
 
-1. Extraia **nome-feature** e **agent_name** de `$ARGUMENTS`
-2. Leia o `task_plan.md` em `docs/<nome-feature>/task_plan.md`
+1. Extraia **task_plan_path** e **agent_name** de `$ARGUMENTS`
+2. Leia o `task_plan.md` fornecido. Extraia os caminhos de **SPEC_TECH** e **PRD** da seção 1 (Identificação)
 3. Consulte a tabela de **Rastreabilidade User Stories -> Tasks** (seção 5 do task_plan) para entender a cobertura
 4. Descubra quais tasks estão prontas para execução (respeitando dependências)
 5. **DELEGUE cada task para o sub-agente (agent_name)** — nunca execute diretamente
-6. Para cada task, carregue `docs/<nome-feature>/tasks/<ID>.md` e passe as seções relevantes ao sub-agente
-7. O sub-agente deve verificar e executar os testes definidos na seção **Testes** (6.1 a 6.4) de cada task
-8. **Maximize o paralelismo**: crie multiplos sub-agentes simultaneamente sempre que possivel
-9. Aguarde os sub-agentes concluirem e consolide os resultados
-10. Atualize o plano com os novos status
-11. Reporte o que foi feito em um relatorio estruturado
-
-**Lembre-se**: Voce e o orquestrador, nao o executor. Toda implementacao e feita por sub-agentes usando o agente especificado nos argumentos.
+6. Para cada task, carregue `[diretório-base]/tasks/<ID>.md` e passe as seções relevantes ao sub-agente
+7. O sub-agente deve criar e executar os testes definidos na seção **Testes** (6.1 a 6.4) de cada task
+8. **Após cada task ser implementada, VALIDE com qa-staff-engineer** (modo VALIDAR_IMPLEMENTACAO) — Gate 1
+9. **Se o QA rejeitar, envie as correções de volta ao executor** (máx 3 tentativas totais)
+10. **Após aprovação do QA, VALIDE com tech-review-conformance** — Gate 2
+11. **Se o Tech Review reprovar, envie as correções de volta ao executor** e re-valide com AMBOS os gates
+12. **Se após 3 tentativas totais o QA ou Tech Review ainda reprovar, ESCALE ao usuário** — NÃO continue
+13. **Maximize o paralelismo**: crie múltiplos sub-agentes simultaneamente sempre que possível
+14. Atualize o plano com os novos status (somente após aprovação de AMBOS os gates)
+15. Reporte o que foi feito em um relatório estruturado incluindo vereditos do QA e Tech Review
+
+**Lembre-se**: Você é o orquestrador, não o executor. Toda implementação é feita por sub-agentes usando o agente especificado nos argumentos. Validação funcional é feita pelo qa-staff-engineer. Validação técnica é feita pelo tech-review-conformance. Nenhuma task é concluída sem aprovação de AMBOS os gates. **Os gates são SEQUENCIAIS por task**: primeiro QA, depois Tech Review — NUNCA em paralelo. Se Tech Review reprovar, corrija e volte ao QA antes de rodar Tech Review novamente.
+
+---
+
+## Estado do Pipeline (sdd_state.yaml)
+
+Ao iniciar a execucao, atualize o `sdd_state.yaml` no diretorio base da feature:
+
+```yaml
+current_step: execution
+steps:
+  execution:
+    status: in_progress
+    tasks_completed: 0
+    tasks_total: <N>
+```
+
+A cada task concluida (aprovada por QA + Tech Review), atualize `tasks_completed`.
+
+Ao finalizar todas as tasks:
+
+```yaml
+current_step: execution
+steps:
+  execution:
+    status: completed
+    tasks_completed: <N>
+    tasks_total: <N>
+    summary: "<N/N tasks concluidas>. <bloqueadas se houver>"
+```
+
+Se o `sdd_state.yaml` nao existir, nao crie — o generate-prd e responsavel por criar.
+
+---
 
 $ARGUMENTS