Verificando acesso...

MÓDULO 3.3

📋 Aprovação de plano

Plan mode read-only, critérios de aprovação e ciclo de revisão.

6
Tópicos
50
Minutos
Intermediário
Nível
Mão na massa
Tipo
1

🔍 Plan mode read-only

Teammate inicia em plan mode (sem write tools), pesquisa, monta o plano e só depois passa para execução. Reduz drasticamente 'agente fez merda no caminho errado'.

📌 O que muda em plan mode

Escrita desativada por construção.

  • Read, Glob, Grep funcionam
  • Edit, Write, Bash bloqueados
  • Plano em formato estruturado
  • Sai automaticamente após aprovação

💡 Padrão para tarefas críticas

Migração de DB, refactor grande, mudança de arquitetura — sempre em plan mode obrigatório.

2

📤 Enviar plano ao lead

Teammate envia plano formalmente para o lead via approval request. Lead pode aprovar ou rejeitar com feedback. Rejeitado = volta para plan mode.

1

Pesquisa

Read-only

Teammate explora o código relevante

2

Plano

Estruturado

Lista passos concretos com paths

3

Approval request

Para o lead

Mensagem formal pedindo OK

4

Decisão

Aprovado ou rejeitado com feedback

Loop até OK ou abort

5

Execução

Write tools liberadas

Implementa o plano aprovado

3

📏 Critérios para o lead aprovar

'Só aprove se o plano cobre testes; rejeite se mexe em schema'. Critérios viram texto no prompt do lead. Sem critérios, o lead aprova quase tudo.

📌 Critérios típicos

Cole no prompt do spawn do lead.

  • Cobertura de testes obrigatória
  • Sem migração de DB sem flag
  • Sem novos endpoints públicos
  • Mudanças em < X linhas
  • Documentação atualizada

⚠️ Sem critério, sem portão

Aprovação vira carimbo. Defina critério antes de delegar a aprovação ao lead.

4

🔁 Ciclo de revisão

Quando rejeitado, teammate fica em plan mode, revisa com base no feedback e resubmete. É o equivalente a 'PR review' — só que no spawn.

✓ Loop saudável

  • Feedback específico
  • 1-2 ciclos de revisão
  • Ajustes incrementais
  • Critério estável

✗ Loop ruim

  • Feedback vago ('melhore')
  • > 3 ciclos sem convergir
  • Critério muda a cada round
  • Lead aprova por cansaço
5

👤 Você como aprovador

Em tarefas críticas, peça que todo plano passe pelo humano antes da execução. No início, é o melhor jeito de calibrar critérios.

💡 Estratégia de calibração

Aprove manualmente os primeiros 5-10 planos. Capture os critérios que você usou. Cole no prompt do lead. Delegue.

📌 Quando manter aprovação humana

Casos onde lead não tem alçada.

  • Mudanças em produção
  • Tools com efeito externo (email, slack)
  • Migração de DB
  • Quando o time é novo (calibração)
6

🧪 Lab: aprovador autônomo

Spawn de 'architect' em plan mode obrigatório, com 3 critérios de aprovação no prompt do lead. Ver o ciclo completo te dá confiança para operar sem aprovador humano.

📊 Lab spec

  • Tarefa: refactor do módulo de auth
  • Teammate: architect (Opus)
  • Plan mode: obrigatório
  • Critério 1: testes cobertos
  • Critério 2: sem schema change
  • Critério 3: backwards compat

📌 Resumo do Módulo

Plan mode read-only — Pesquisar antes de mexer
Enviar plano ao lead — Approval request
Critérios para o lead aprovar — Instruções no prompt
Ciclo de revisão — Plano → feedback → revisão
Você como aprovador — Quando assumir o controle
Lab: aprovador autônomo — Plan mode em prática

Próximo módulo:

3.4 — Hooks como quality gates