adi_dev_workflow 1.0.0 → 1.1.1

package/frameworks/commands/ministack/generate-tasks.md

@@ -1,22 +1,207 @@
 ---
-description: Gera tasks atomicas e executaveis a partir de INTENT e SCOPE aprovados
-argument-hint: [INTENT aprovada + SCOPE aprovado]
+description: "Gera TASKS do miniStack a partir de INTENT e SCOPE aprovados. Params: <intent.md> <scope.md>"
+argument-hint: "<intent.md ex: docs/carrinho-compra/v1/intent.md> <scope.md ex: docs/carrinho-compra/v1/scope.md>"
 ---
 
-Use a skill **ministack-expert** para gerar as TASKS (ETAPA 3).
+Use a skill **ministack-tasks-expert** para gerar as TASKS.
 
 ## Contexto
 
-Voce deve seguir as regras e o processo da **ETAPA 3: TASKS** definida na skill ministack-expert.
+Voce deve seguir as regras e o processo definidos na skill ministack-tasks-expert.
 
-> **Nota**: A secao de testes de cada task sera delegada automaticamente ao subagente `ministack-qa-expert`. Voce nao precisa chamar `/generate-tests` separadamente — o ministack-expert ja coordena a delegacao QA internamente.
+O $ARGUMENTS deve conter:
+1. **caminho do intent.md** (obrigatorio)
+2. **caminho do scope.md** (obrigatorio)
+
+O task_plan.md e as tasks individuais serao gerados no mesmo diretorio dos arquivos de entrada.
 
 ## Regras Adicionais
 
 - **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
 - **NUNCA** deduza escopo ou invente informacoes — na **DUVIDA PERGUNTE AO USUARIO**
 - Liste **TODOS** os arquivos envolvidos e as acoes (criar/modificar/remover) em cada task — economiza tokens e scans
-- A secao de **testes** de cada task sera preenchida por um subagente QA especializado (`ministack-qa-expert`)
+
+---
+
+## Estrutura de Saida (Formato Modular)
+
+A skill gera **arquivos individuais** para cada task, nao um arquivo monolitico:
+
+```
+docs/[nome-feature]/vN/
+  task_plan.md       # Indice: macro-fases, grafo de dependencias, visao consolidada
+  tasks/
+    T1.md            # Task individual completa
+    T2.md
+    T3.md
+    ...
+```
+
+---
+
+## Delegacao QA — Secao de Testes de cada Task
+
+A **secao de Testes** de cada task NAO deve ser preenchida pela skill. Voce DEVE delegar para o agente **qa-staff-engineer** que retorna um JSON estruturado. Depois, voce converte o resultado em markdown na secao de Testes.
+
+### Quando executar
+
+Para **cada task**, apos a skill preencher todas as secoes exceto Testes, **ANTES de salvar os arquivos finais**. Se varias tasks estao sendo criadas, voce pode disparar agentes QA em **paralelo** para maximizar eficiencia.
+
+### Passo 1: Preparar a lista de arquivos
+
+Monte a lista de `arquivos` que o agente deve ler para CADA task. Inclua:
+
+- **INTENT aprovada**: `docs/[nome-feature]/vN/intent.md`
+- **SCOPE aprovado**: `docs/[nome-feature]/vN/scope.md`
+- **Testes existentes**: busque arquivos de teste relacionados aos arquivos impactados pela task
+- **Codigo-fonte existente**: arquivos listados na task (a criar ou modificar)
+
+### Passo 2: Preparar as instrucoes
+
+Monte o campo `instrucoes` com:
+
+1. O conteudo completo da **task parcial** que a skill montou ate o momento
+2. Os **criterios de conclusao** da task
+3. Os **arquivos impactados** pela task — para o QA saber quais camadas testar
+4. O **tipo da task** (cria handler, cria service, cria repository, cria migracao, etc.)
+
+### Passo 3: Disparar o agente
+
+Lance o agente usando a ferramenta `Agent` com:
+
+- **subagent_type**: `qa-staff-engineer`
+- **description**: "QA gerar testes task TN"
+- **prompt**: Monte o prompt com os 3 parametros obrigatorios:
+
+```
+Voce foi invocado com os seguintes parametros:
+
+1. **modo**: GERAR_TESTES
+2. **arquivos**: [lista de caminhos dos arquivos preparados no Passo 1]
+3. **instrucoes**: [conteudo preparado no Passo 2]
+```
+
+### Passo 4: Converter JSON em formato tabular (secao Testes)
+
+O agente QA retorna um JSON com `casos_teste[]`. Voce DEVE converter para o formato **tabular** da secao de Testes usando o mapeamento abaixo:
+
+#### Mapeamento de tipos
+
+| Campo `tipo` no JSON | Subsecao destino |
+|---------------------|-----------------|
+| `UNITARIO` | **5.1 Testes Unitarios** |
+| `INTEGRACAO` | **5.2 Testes de Integracao** |
+| `E2E` | **5.3 Testes E2E** |
+| `SEGURANCA` | **5.4 Cenarios de Erro** |
+| `PERFORMANCE` | **5.4 Cenarios de Erro** |
+
+Alem dos testes tipo `SEGURANCA` e `PERFORMANCE`, inclua em 5.4 todos os `casos_teste` com `categoria` igual a: `tratamento_erro`, `caso_extremo`, `fronteira`.
+
+#### Formato de saida por subsecao
+
+O formato DEVE seguir o **formato tabular** do template de task individual. Isso garante clareza sobre o objetivo real de cada teste.
+
+Infira o nome do arquivo de teste a partir do componente testado:
+- Handler → `[nome]_handler_test.go`
+- Service → `[nome]_service_test.go`
+- Repository → `[nome]_repository_test.go`
+
+Infira o nome da funcao de teste a partir do titulo do CT:
+- Use formato `TestNomeMetodo_CenarioDescritivo` (Go convention)
+
+**5.1 Testes Unitarios** — formato tabular agrupado por componente:
+
+```markdown
+#### [Camada]: [NomeComponente] (`arquivo_test.go`)
+
+Mock: [interfaces mockadas]
+
+| CT | Teste | Objetivo | Input | Expected | Mock |
+|----|-------|----------|-------|----------|------|
+| CT-XX | TestMetodo_Cenario | Verificar que [comportamento] quando [condicao] | dados entrada | resultado esperado | dependencias mockadas |
+```
+
+**5.2 Testes de Integracao** — formato tabular com Setup:
+
+```markdown
+#### [CamadaA + CamadaB] (`arquivo_test.go`)
+
+Setup: [banco in-memory, migracoes, fixtures]
+
+| CT | Teste | Objetivo | Fluxo | Validacao |
+|----|-------|----------|-------|-----------|
+| CT-XX | TestIntegracao_Cenario | Verificar que [comportamento] quando [condicao] | Passos do fluxo | Assertions esperadas |
+```
+
+**5.3 Testes E2E** — formato descritivo por fluxo:
+
+```markdown
+#### Fluxo: [Nome do Fluxo] (CT-XX)
+- **Objetivo**: (1 frase descrevendo o que este fluxo E2E valida de ponta a ponta)
+- **Pre-condicoes**: (estado inicial do sistema)
+- **Passos**:
+  1. Passo 1
+  2. Passo 2
+- **Validacoes**: (assertions sobre dados e estado final)
+```
+
+**5.4 Cenarios de Erro** — formato tabular:
+
+```markdown
+| Cenario | Objetivo | Trigger | Codigo/Status | Log Esperado |
+|---------|----------|---------|---------------|-------------|
+| Descricao | Verificar que [constraint] impede [operacao] | Acao trigger | Codigo erro | Mensagem log |
+```
+
+#### Testes Existentes a Modificar
+
+Apos as subsecoes 5.1-5.4, adicione a tabela de testes existentes:
+
+```markdown
+#### Testes Existentes a Modificar
+| Arquivo | Motivo da Modificacao |
+|---------|----------------------|
+```
+
+Se nenhum: `> Nenhum teste existente impactado.`
+
+### Passo 5: Validar como engenheiro de tarefas
+
+Antes de integrar a secao de Testes na task:
+
+1. Verifique **coerencia** com os arquivos impactados (os componentes testados existem?)
+2. Verifique que os testes cobrem os **criterios de conclusao** da task
+3. Ajuste nomenclatura para seguir padroes do projeto
+4. Para tasks sem codigo (documentacao, configuracao): "N/A — task nao envolve codigo testavel"
+
+### Passo 6: Salvar e apresentar
+
+1. Salve cada task individual em `docs/[nome-feature]/vN/tasks/T[N].md`
+2. Salve o task plan em `docs/[nome-feature]/vN/task_plan.md`
+3. Apresente ao usuario para aprovacao
+
+**NAO peca aprovacao isolada da secao de testes** — apresente as tasks completas para validacao.
+
+---
+
+## Estado do Pipeline (ministack_state.yaml)
+
+Apos salvar o task_plan.md e todas as tasks com sucesso, atualize o arquivo `ministack_state.yaml` no mesmo diretorio:
+
+```yaml
+# atualizar apenas estes campos:
+current_step: task_plan
+steps:
+  task_plan:
+    status: completed
+    summary: "<N tasks>, <M fases>, <P paralelizaveis>"
+  execution:
+    status: pending
+    tasks_total: <N>
+    tasks_completed: 0
+```
+
+Se o `ministack_state.yaml` nao existir, nao crie — o generate-intent e responsavel por criar.
 
 ## Entrada
 

package/frameworks/commands/ministack/generate-tech-direction.md

@@ -0,0 +1,43 @@
+---
+description: "Gera TECH DIRECTION do miniStack a partir de INTENT aprovada. Param: caminho do intent.md"
+argument-hint: "<intent.md ex: docs/carrinho-compra/v1/intent.md>"
+---
+
+Use a skill **ministack-tech-direction-expert** para gerar o tech_direction.md.
+
+## Contexto
+
+Voce deve atuar como um **Arquiteto de Software Senior** especializado em tomada de decisao tecnica e seguir todo o processo interativo definido na skill ministack-tech-direction-expert para construir um tech_direction completo.
+
+## Pre-requisito
+
+Antes de iniciar, verifique se `.claude/rules/project-profile.md` existe. Se NAO existir, interrompa e peca ao usuario para executar `/generate-project-profile` primeiro.
+
+## Regras Adicionais
+
+- **Claude Code**: use a ferramenta `AskUserQuestion` para esclarecer duvidas com o usuario
+- **NUNCA** deduza decisoes ou invente informacoes — na **DUVIDA PERGUNTE AO USUARIO**
+- Leia o **project-profile.md** para entender stack, padroes e convencoes do projeto
+- Pesquise o codebase ANTES de fazer perguntas (regras, padroes, libs)
+- Faca **UMA pergunta por vez**, aguardando a resposta antes de avancar
+- **SEMPRE** salve o arquivo fisico antes de apresentar ao usuario
+- O arquivo deve ser salvo no mesmo diretorio da INTENT: `docs/[nome-feature]/vN/tech_direction.md`
+
+## Estado do Pipeline (ministack_state.yaml)
+
+Apos salvar o tech_direction.md com sucesso, atualize o arquivo `ministack_state.yaml` no mesmo diretorio:
+
+```yaml
+# atualizar apenas estes campos:
+current_step: tech_direction
+steps:
+  tech_direction:
+    status: completed
+    summary: "<listar as principais decisoes tecnicas em 1 frase>"
+```
+
+Se o `ministack_state.yaml` nao existir, nao crie — o generate-intent e responsavel por criar.
+
+## Entrada
+
+$ARGUMENTS

package/frameworks/commands/ministack/run-ministack-tasks.md

@@ -1,55 +1,374 @@
 ---
-description: Coordena sub-agentes para executar tasks aprovadas com maximo paralelismo
-argument-hint: [caminho da feature] [agente opcional ex: go-backend-implementer]
+description: "Executa tasks do miniStack via sub-agentes. Params: <task_plan.md> <agent_name> (ex: docs/carrinho-compra/v1/task_plan.md go-expert)"
+argument-hint: "<caminho task_plan.md ex: docs/carrinho-compra/v1/task_plan.md> <agent_name ex: go-expert>"
 ---
+Voce e um **Coordenador de Sub-agentes** dentro do framework miniStack. Seu papel e **orquestrar**, nao executar diretamente.
 
-Use a skill **ministack-expert** para executar as TASKS (ETAPA 5).
+## Parametros
 
-## Contexto
+O `$ARGUMENTS` deve conter:
 
-Voce deve seguir as regras e o processo da **ETAPA 5: EXECUCAO** definida na skill ministack-expert.
+1. **task_plan_path** (obrigatorio) — Caminho do task_plan.md (ex: `docs/carrinho-compra/v1/task_plan.md`)
+2. **agent_name** (obrigatorio) — Nome do sub-agente executor (ex: `go-expert`, `flutter-dev-agent`)
 
-## Argumentos
+**Formato:** `[task_plan_path] [agent_name]`
 
-O `$ARGUMENTS` pode conter:
+A partir do **task_plan_path**, derive:
+- **diretorio base**: diretorio pai do task_plan.md (ex: `docs/carrinho-compra/v1/`)
+- **tasks individuais**: `[diretorio-base]/tasks/T*.md`
+- **intent.md** e **scope.md**: extrair os caminhos da secao 1 (Identificacao) do task_plan.md — campos **Intent** e **Scope**
 
-1. **Caminho da feature** (obrigatorio) - Ex: `docs/nome-feature/v1`
-2. **Agente/Subagente** (opcional) - Nome do agente a ser usado para execucao
+## Contexto do Framework
 
-**Formatos aceitos:**
-- `docs/minha-feature/v1` - Usa execucao padrao
-- `docs/minha-feature/v1 go-backend-implementer` - Usa agente especifico
+O fluxo oficial e:
+- **INTENT** → define O QUE / POR QUE
+- **SCOPE** → define COMO
+- **TASKS** → definem O QUE IMPLEMENTAR AGORA
 
-Se um agente for especificado, ele sera usado como `subagent_type` na ferramenta Task.
-Os agentes disponiveis podem ser encontrados em `.claude/agents/`.
+---
+
+## Instrucoes
+
+1. **Leia o `task_plan.md`** fornecido em `task_plan_path`. Extraia da secao 1 (Identificacao) os caminhos do **Intent** e **Scope**. Identifique todas as tasks, dependencias e ordem de execucao a partir da tabela de tasks e do grafo de dependencias.
+
+2. **Leia cada task individual** em `[diretorio-base]/tasks/T[N].md` para obter os detalhes completos (objetivo, arquivos, criterios, testes).
+
+3. **Construa o grafo de dependencias**:
+   - Cada task ID e um no
+   - A coluna "Dependencias" indica as arestas
+
+4. **Identifique tasks prontas para execucao**:
+   - Status `A Fazer` (ou vazio)
+   - Todas as dependencias estao concluidas
+
+5. **Agrupe tasks paralelizaveis e crie sub-agentes em paralelo**:
+   - Maximize o paralelismo: N tasks prontas = N sub-agentes em paralelo
+   - Se houver risco de conflito (mesmos arquivos), execute sequencialmente
+
+6. **Para cada task pronta, DELEGUE para o sub-agente (agent_name)**:
+   - Passe: o conteudo completo do arquivo da task individual (objetivo, descricao, criterio de conclusao, arquivos impactados, testes)
+   - O sub-agente deve consultar scope.md se necessario
+   - O sub-agente aplica as modificacoes no codigo
+   - O sub-agente cria e executa os testes definidos na secao de Testes
+   - **Apos implementar, o sub-agente DEVE executar o Checklist Final (secao 7 da task)** e validar cada item:
+     - [ ] Implementada conforme Scope
+     - [ ] Testes unitarios criados/atualizados
+     - [ ] Testes de integracao criados/atualizados
+     - [ ] Criterio de conclusao atendido
+     - [ ] Revisada
+   - Se algum item do checklist NAO estiver atendido, o sub-agente DEVE corrigir antes de reportar conclusao
+   - O sub-agente marca cada item como `[x]` no arquivo `tasks/T[N].md` ao confirmar
+   - O sub-agente tambem marca como `[x]` os itens de **Detalhes de Implementacao (secao 4)** conforme completar cada subtask
+
+7. **Apos o sub-agente concluir, VALIDE com QA e Tech Review** (ver secao abaixo)
+
+8. **Atualize a task individual** (apos aprovacao de AMBOS os gates):
+   - Marque Status como `Concluido` na secao 1 do arquivo `tasks/T[N].md`
+   - Confirme que a secao 7 (Checklist Final) tem todos os items `[x]`
+   - Confirme que a secao 4 (Detalhes de Implementacao) tem todos os items `[x]`
+
+9. **Atualize o task_plan.md** (apos aprovacao de AMBOS os gates):
+   - Marque a task com Status `Concluido` na tabela de tasks (secao 4)
+   - Marque a task com Status `Concluido` no grafo de dependencias (secao 5)
+
+10. **Apos TODAS as tasks concluidas, atualize os Criterios de Conclusao Geral (secao 7 do task_plan.md)**:
+    - Valide e marque cada item como `[x]`:
+      - [ ] Todas as tasks concluidas
+      - [ ] Objetivo tecnico atingido
+      - [ ] Codigo compila sem erros — executar `CGO_ENABLED=1 go build ./...`
+      - [ ] Testes unitarios passando — executar `CGO_ENABLED=1 go test ./... -v`
+      - [ ] Testes de integracao passando (se aplicavel)
+      - [ ] Testes e2e passando (se aplicavel)
+    - Se algum criterio NAO for atendido, investigue e corrija antes de marcar
+    - Atualize o Status do task_plan.md (secao 1) para `Concluido`
+
+---
+
+## Validacao pos-implementacao (QA + Tech Review)
+
+Apos CADA task ser implementada pelo sub-agente executor, voce DEVE validar a implementacao em **dois gates obrigatorios** antes de marcar a task como concluida:
+
+1. **Gate 1 — QA (qa-staff-engineer)**: validacao funcional, testes, criterios de aceite
+2. **Gate 2 — Tech Review (tech-review-conformance)**: conformidade arquitetural, padroes do projeto
+
+**Nenhuma task e considerada concluida sem aprovacao de AMBOS os gates.**
+
+### Fluxo de Validacao
+
+```
+Executor (agent_name) implementa task
+                ↓
+    ┌─── GATE 1: qa-staff-engineer valida (VALIDAR_IMPLEMENTACAO)
+    │               ↓
+    │       ┌── APROVADO → avancar para Gate 2
+    │       ├── APROVADO_COM_OBSERVACOES (0 criticos) → avancar para Gate 2, registrar obs
+    │       ├── APROVADO_COM_OBSERVACOES (com criticos) → corrigir (tratar como REJEITADO)
+    │       └── REJEITADO → enviar correcoes ao executor
+    │               ↓
+    │           Executor corrige → QA re-valida (max 3 tentativas)
+    │               ↓
+    │           Ainda rejeitado? → escalar ao usuario
+    │
+    └─── GATE 2: tech-review-conformance valida (apos QA aprovado)
+                    ↓
+            ┌── approved → task concluida, continuar
+            ├── partial → enviar correcoes ao executor
+            └── rejected → enviar correcoes ao executor
+                    ↓
+                Executor corrige
+                    ↓
+                QA re-valida + Tech Review re-valida (max 3 tentativas)
+                    ↓
+                Ainda rejeitado? → escalar ao usuario
+```
+
+### Passo 1: Preparar a lista de arquivos para o QA
+
+Apos o executor concluir, monte a lista de `arquivos` que o QA deve ler:
+
+- **Task implementada**: `[diretorio-base]/tasks/T[N].md` (arquivo individual da task)
+- **SCOPE**: `[diretorio-base]/scope.md`
+- **INTENT**: `[diretorio-base]/intent.md`
+- **Arquivos criados/modificados**: todos os arquivos que o executor criou ou modificou
+- **Arquivos de teste**: todos os arquivos de teste criados/modificados
+
+### Passo 2: Preparar as instrucoes para o QA
+
+Monte o campo `instrucoes` com:
+
+1. **ID e nome da task**: para contexto
+2. **Criterios de conclusao** da task — o QA deve validar CADA criterio
+3. **Testes definidos** na task — 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. Instrucao explicita: "Execute os testes e valide a implementacao contra os criterios 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
+
+| Veredito | Problemas Criticos | Acao |
+|----------|-------------------|------|
+| `APROVADO` | 0 | QA aprovado. **Avancar para Gate 2 (Tech Review)** |
+| `APROVADO_COM_OBSERVACOES` | 0 | QA aprovado. Registrar observacoes. **Avancar para Gate 2** |
+| `APROVADO_COM_OBSERVACOES` | > 0 | Tratar como REJEITADO — corrigir problemas criticos |
+| `REJEITADO` | qualquer | Enviar ao executor para correcao (Passo 5) |
+
+### Passo 5: Loop de correcao QA (quando REJEITADO)
+
+Se o QA rejeitar:
+
+1. **Extraia do JSON do QA**: problemas criticos, problemas altos, testes que falharam, criterios nao atendidos
+2. **Monte o prompt de correcao** para o executor com todos os problemas listados
+3. **Dispare o executor** com o prompt de correcao
+4. **Apos a correcao, re-valide** com o QA (voltar ao Passo 3)
+5. **Limite maximo: 3 tentativas** (compartilhado com Tech Review)
+
+### Passo 6: Preparar contexto para Tech Review
+
+Apos o QA aprovar, monte o contexto para o Tech Review:
+
+1. Da task: objetivo, descricao, criterios de conclusao, arquivos impactados
+2. Lista de todos os arquivos criados/modificados (codigo + testes)
+
+### Passo 7: Disparar o Tech Review (Gate 2)
 
-## Contexto Obrigatorio
+**Somente apos o QA aprovar**, lance o agente:
 
-Antes de executar qualquer task, voce **DEVE** ler:
+- **subagent_type**: `tech-review-conformance`
+- **description**: "Tech Review task TN"
+- **prompt**:
 
-1. **`intent.md`** - Define o objetivo e contexto da feature
-2. **`scope.md`** - Define o escopo aprovado e limites
-3. **`tasks.md`** - Contem as tasks aprovadas para execucao
+```
+Realize a revisao tecnica da task [ID] - [Nome da Task].
 
-> Toda execucao deve respeitar a intent e os limites do scope.
-> Se uma task conflitar com estes documentos, **PARE e avise**.
+## Contexto da Task
+- **Objetivo**: [conteudo da task]
+- **Criterios de Conclusao**: [criterios]
 
-## Execucao em Paralelo
+## Arquivos Implementados (DEVE LER TODOS)
+[lista de todos os arquivos criados/modificados]
 
-- **Tasks independentes**: Lance multiplas chamadas Task em paralelo na mesma mensagem
-- **Tasks dependentes**: Execute sequencialmente, aguardando conclusao da anterior
-- **Maximo de paralelismo**: Priorize lancar o maior numero possivel de tasks simultaneas
+## Arquivos de Teste (DEVE LER TODOS)
+[lista de arquivos de teste]
 
-## Fluxo
+Leia TODOS os arquivos listados e valide:
+1. Conformidade arquitetural (camadas, fluxo de dependencia, separacao de responsabilidades)
+2. Aderencia aos padroes do projeto (convencoes, nomenclatura, estrutura)
+3. Cada criterio de conclusao
+4. Riscos tecnicos (debito tecnico, testabilidade, robustez)
+```
 
-1. **Recepcao e Validacao** — Ler tasks, validar, analisar paralelismo
-2. **Execucao Tecnica** — Executar passos conforme descrito
-3. **Validacao de Testes** — Executar testes relevantes
-4. **Aceite Tecnico** — Validar criterio de conclusao
-5. **Reporte Final** — Resumo do que foi feito
+### Passo 8: Interpretar resultado do Tech Review
 
-## Entrada
+| Status | Acao |
+|--------|------|
+| `approved` | Task concluida. Marcar como `Concluido` no arquivo da task e no task_plan.md |
+| `partial` | Ha problemas `high`. Enviar ao executor para correcao |
+| `rejected` | Ha problemas `critical`. Enviar ao executor para correcao |
 
-**Formato:** `[caminho-feature] [agente-opcional]`
+### Passo 9: Loop de correcao Tech Review
+
+Se o Tech Review reprovar:
+
+1. Extraia problemas do JSON (foque em `critical` e `high`)
+2. Monte prompt de correcao para o executor
+3. Dispare o executor
+4. **Re-valide com AMBOS os gates** (QA primeiro, depois Tech Review)
+5. **Limite maximo: 3 tentativas TOTAIS** (compartilhado entre QA e Tech Review)
+
+### Passo 10: Escalar ao usuario (apos 3 tentativas)
+
+Se apos 3 tentativas totais o QA ou Tech Review ainda reprovar:
+
+1. **NAO marque a task como concluida**
+2. **Marque como `Bloqueado`** no arquivo da task e no task_plan.md
+3. **Informe ao usuario** com: task bloqueada, tentativas feitas, problemas persistentes, gate bloqueante
+4. **Pergunte ao usuario** como proceder antes de continuar
+
+### Regras da Validacao
+
+- **Toda task que modifica codigo** DEVE passar por ambos os gates — sem excecao
+- **Os gates sao 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 nao envolvem codigo (ex: documentacao) podem ser marcadas concluidas sem gates
+- O QA deve **executar os testes** — nao apenas revisar o codigo
+- O Tech Review valida **conformidade arquitetural** — nao repete a validacao funcional do QA
+- Cada tentativa gera validacao completa de AMBOS os gates (nao incremental) — sempre comecando pelo QA
+- O contador de tentativas e **compartilhado** entre QA e Tech Review
+
+---
+
+## Regras
+
+- **SEMPRE delegar** para sub-agentes — o coordenador nunca implementa diretamente
+- **Priorizar paralelismo** — se multiplas tasks podem rodar juntas, crie sub-agentes em paralelo
+- **SEMPRE validar com QA** apos cada task
+- **SEMPRE validar com Tech Review** apos aprovacao do QA
+- **Nao alterar** intent, scope ou criar novas tasks sem o usuario pedir
+- Tasks com dependencias devem aguardar a conclusao das dependencias
+- Nunca delegar duas tasks que modificam o mesmo arquivo critico simultaneamente
+
+---
+
+## Delegacao para Sub-agentes
+
+### Regra Principal
+**TODA task deve ser delegada para um sub-agente**, independentemente de ser paralela ou sequencial. O coordenador **nunca executa tasks diretamente**.
+
+### Fluxo de Delegacao
+
+**IMPORTANTE**: Os gates QA e Tech Review sao **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
+    │
+    ├─── Le task_plan.md + tasks/T*.md
+    │
+    ├─── Identifica tasks prontas
+    │
+    ├─── [PARALELO] Delega N tasks ──►├─► agent_name (T1)
+    │                                 ├─► agent_name (T2)
+    │                                 └─► agent_name (T3)
+    │                                      │
+    ◄────── Aguarda conclusao ────────────┘
+    │
+    ├─── Para CADA task (SEQUENCIAL por task):
+    │    │
+    │    ├── T1: GATE 1 → qa-staff-engineer (T1)
+    │    │        ├── APROVADO → GATE 2 → tech-review-conformance (T1)
+    │    │        │                ├── approved → T1 Concluido
+    │    │        │                └── partial/rejected → executor corrige T1
+    │    │        │                     → volta ao GATE 1 (QA re-valida)
+    │    │        └── REJEITADO → executor corrige T1
+    │    │             → volta ao GATE 1 (QA re-valida) (max 3x total)
+    │    │
+    │    ├── T2: (mesmo fluxo sequencial)
+    │    └── T3: (mesmo fluxo sequencial)
+    │
+    ├─── Atualiza tasks/T[N].md + task_plan.md
+    └─── Proximo grupo de tasks...
+```
+
+---
+
+## Relatorio Final
+
+Ao final, produza saida em Markdown com:
+- **Tasks Concluidas** (ID, nome, arquivos modificados, veredito QA, veredito Tech Review)
+- **Validacao QA** (resumo por task: veredito, tentativas)
+- **Validacao Tech Review** (resumo por task: status, problemas)
+- **Tasks Bloqueadas** (se houver, com motivo e gate bloqueante)
+- **Observacoes** (de tasks aprovadas com observacoes)
+
+---
+
+## Prompt Base
+
+Quero que voce atue como um **coordenador de sub-agentes** guiado pelo framework miniStack.
+
+1. Extraia **task_plan_path** e **agent_name** de `$ARGUMENTS`
+2. Leia o `task_plan.md` fornecido. Extraia os caminhos de **Intent** e **Scope** da secao 1 (Identificacao). Leia cada `tasks/T[N].md` no diretorio-base
+3. Descubra quais tasks estao prontas para execucao (respeitando dependencias)
+4. **DELEGUE cada task para o sub-agente (agent_name)** — nunca execute diretamente
+5. O sub-agente deve criar e executar os testes definidos na secao de Testes de cada task
+6. **Apos cada task, VALIDE com qa-staff-engineer** (modo VALIDAR_IMPLEMENTACAO) — Gate 1
+7. **Se o QA rejeitar, envie correcoes ao executor** (max 3 tentativas totais)
+8. **Apos aprovacao do QA, VALIDE com tech-review-conformance** — Gate 2
+9. **Se o Tech Review reprovar, envie correcoes ao executor** e re-valide com AMBOS os gates
+10. **Se apos 3 tentativas o QA ou Tech Review ainda reprovar, ESCALE ao usuario** — NAO continue
+11. **Maximize o paralelismo**: crie multiplos sub-agentes simultaneamente sempre que possivel
+12. Atualize `tasks/T[N].md` e `task_plan.md` com os novos status (somente apos aprovacao de AMBOS os gates)
+13. 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. Validacao funcional pelo qa-staff-engineer. Validacao tecnica pelo tech-review-conformance. Nenhuma task e concluida sem aprovacao de AMBOS os gates. **Os gates sao 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 (ministack_state.yaml)
+
+Ao iniciar a execucao, atualize o `ministack_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 `ministack_state.yaml` nao existir, nao crie — o generate-intent e responsavel por criar.
+
+---
 
 $ARGUMENTS