MÓDULO 4.1

⚠️ 6 armadilhas e correções

Permissões, conflito, ocioso, tokens, perda, aprovação — diagnóstico e correção.

6
Tópicos
50
Minutos
Intermediário
Nível
Diagnóstico
Tipo
1

🔓 Pedir permissões a toda hora

Sintoma: cada teammate trava perguntando permissão para npm, git, etc. Pré-aprovar dobra produtividade.

📌 Allowlist canônica

Cole isso e ajuste.

  • •Bash(npm install)
  • •Bash(npm test*)
  • •Bash(git status)
  • •Bash(git diff*)
  • •Edit, Write, Read

⚠️ Não use --dangerously-skip em prod

Atalho perigoso. Allowlist específica é o caminho certo.

2

📁 Conflito de arquivo

Dois teammates editando o mesmo arquivo; segundo sobrescreve. É o erro mais difícil de detectar — não há crash, só código faltando.

📌 Detecção

Como auditar.

  • •git diff por autor (teammate name)
  • •Procure 2 commits no mesmo arquivo
  • •Compare deliverables vs spawn
  • •QA reproduz bug que 'já corrigiu'

💡 Prevenção

Territórios por pasta no spawn: 'Backend possui src/api/, ninguém mais escreve lá'.

3

😴 Agente ocioso

Teammate fica esperando; trabalho dele depende do anterior. Se 1 dos 5 fica ocioso 80% do tempo, você paga 5× e obtém 4×. Custo silencioso.

📌 Como evitar

Tasks independentes na partida.

  • •QA roda mocks enquanto Dev codifica
  • •Frontend trabalha em UI estática enquanto Backend monta API
  • •Security audita arquivos prontos enquanto outros continuam
  • •Lead nunca espera por todos para falar
4

💸 Muitos tokens

Conta dispara, throughput não acompanha. Sintoma típico de 'swarm' com 10+ agentes. Reduzir teammates ou trocar Sonnet por Haiku no QA corta 30-50% do custo.

📊 Mix recomendado por papel

  • QA simples → Haiku
  • Tech Writer → Haiku
  • Dev padrão → Sonnet
  • Architect → Opus (sparingly)
  • Security Reviewer → Sonnet
5

📂 Trabalho perdido

Sessão fecha mal e algumas decisões/análises ficam só na memória do teammate — perdidas. Salvar em arquivo é a única memória durável.

📌 Padrões de persistência

Onde salvar o quê.

  • •Arquivos temporários por papel em tmp/
  • •Resumos finais em docs/
  • •Commit incremental no git
  • •Mailbox preserva mensagens — leia antes do cleanup
6

❓ Aprovação errada

Lead aprova planos ruins ou rejeita planos bons; critério mal calibrado. No início, peça revisão humana; depois delegue.

1

Fase 1

Manual

Humano aprova primeiros 5-10 planos

2

Captura

Listar critérios

Anote o que você usou para decidir

3

Codifica

Critérios no prompt do lead

Cole os critérios capturados

4

Delega

Lead aprova

Você só auditoria pós

5

Auditoria

Refina

Ajusta se taxa de aprovação x retrabalho desviar

📌 Resumo do Módulo

✓
Pedir permissões a toda hora — Pré-aprove no settings
✓
Conflito de arquivo — Atribua donos
✓
Agente ocioso — Trabalho independente
✓
Muitos tokens — Menos agentes, modelos certos
✓
Trabalho perdido — Persista cedo, persista frequente
✓
Aprovação errada — Calibre com humano antes

Próximo módulo:

4.2 — Quando usar Teams