Verificando acesso...

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