Análise de orquestração · dudata-hub · 14/07/2026

Sessão 64ea7b1d: orquestrador Fable + 9 subagents

Dia de integração: merge de 6 PRs da migração Google Forms, fix estrutural do bug de auth (#283) com validação em browser real, e instalação do app iOS no iPhone físico. Janela 10:49–16:37 (≈2h48 ativas, dois intervalos ociosos).

6,5/10
nota geral de orquestração

A execução mecânica foi majoritariamente delegada (79% das tool calls rodaram em subagents Sonnet) e o orquestrador reservou pra si o trabalho de julgamento: diagnóstico de causa-raiz, prompts cirúrgicos, steering. Dois defeitos puxam a nota. O primeiro é a fase do iPhone feita inteira inline no Fable (com 8 retries idênticos de um comando quebrado); o segundo, um vazamento de modelo via SendMessage que fez 19% do output dos subagents rodar em Fable, driblando o hook de guarda.

9
subagents (todos Sonnet no spawn)
7
PRs mergeados (6 da fila + #286)
533k
tokens de output no total
608
tool calls (128 main · 480 subs)
31
tool calls com erro (18 no main)
3
SendMessages de steering

Quanto foi delegado

Delegação depende da régua: o volume mecânico foi pros subagents; o gasto de tokens ficou no orquestrador.

Mutações de arquivo (Edit/Write)98,5% delegado
67 edições em subagents · 1 no main (settings.local.json, autorizada), fora 3 mutações via bash (printf/sed em .env)
Tool calls (execução)78,9% delegado
480 calls em subagents · 128 no main (96 Bash, 14 Read, 9 Agent, 3 SendMessage…)
Tokens de output37,8% delegado
201.723 tokens em subagents · 331.703 no orquestrador (coordenação + investigação #283 + fase iPhone inline)
Output por modelo (quanto custou em Fable)69,5% Fable · 30,5% Sonnet
370.668 tokens Fable (331.703 main + 38.965 vazados dentro de subagents) · 162.758 Sonnet
Fable 5 (orquestrador) Sonnet 5 (subagents)

Output por agente (tokens, segmentado por modelo)

Escala: 100% ≈ 60k tokens. Os segmentos azuis dentro de subagents são o vazamento via SendMessage.

Fix #283: auth gate oficial · 43min · 117 calls55.046
Validar #283 em browser real · 35min · 107 calls46.464
Rebase-fix PR #272 · 20min · 74 calls32.052
Rebase-fix PR #273 · 13min · 34 calls21.205
E2E integrado na main · 7min · 48 calls14.066
Rebase-fix PR #271 · 6min · 48 calls14.003
Rebase-fix PR #269 · 8min · 29 calls12.166
Rebase-fix PR #268 · 3min · 19 calls5.963
Build iOS "no Simulator" · 23s · morto pelo usuário758
Orquestrador (main, Fable)331.703
P1 merges: 85,5k · P2 auth #283: 201,1k · P3 iPhone: 45,0k. Barra fora de escala (5,5× o maior subagent).

Timeline por fase

10:49–11:58
9/10

P1 · Fila de merges (6 PRs)

Padrão exemplar: PR #270 mergeado direto; #269, #273, #272, #268 e #271 cada um com um subagent Sonnet de rebase-fix (prompts de ~2,5k chars), sequência obrigatória (cada rebase depende da main pós-merge anterior), E2E integrado no final. Main só decidiu, mergeou e monitorou: 0 edições de código próprias.

13:18–14:36
7/10

P2 · Bug #283 (ConvexError "Não autenticado")

Uso correto da inteligência do orquestrador: ele mesmo diagnosticou a causa-raiz (leu router, rotas, guard, doc do TanStack via Context7) e escreveu um prompt de 4,8k chars pro agente de fix; validação em browser delegada em paralelo (26 min de overlap real) e steering via SendMessage apontando a linha exata onde o script morria. Contras: os 2 SendMessages retomaram os subagents em Fable (vazamento de 39k tokens), e o main re-rodou o harness de validação 3× ele próprio, duplicando o trabalho do agente de validação. Com 201k tokens de main, foi a fase mais cara.

16:16–16:37
2/10

P3 · Instalar app no iPhone físico

Leu errado o pedido: spawnou "Build Release iOS no Simulator" quando o alvo era o aparelho físico (usuário matou o agente em 23s), e em vez de re-delegar com a instrução corrigida, assumiu tudo inline no Fable: 8 execuções consecutivas de cp .env … falhando com o mesmo erro (o arquivo não existia; só rodou ls .env* na 9ª tentativa), 10 tool calls com erro em ~30, usuário explodindo no chat. O install em si terminou OK (build device, reautorização de developer, launch com sucesso), mas foi a antítese da regra "trabalho mecânico → modelo barato" e do "errou 3× → pare e releia".

O que ficou no main, e devia mesmo ficar

  • Decisões de merge, sequenciamento da fila e resolução das 2 negações do classifier (pedindo autorização ao usuário).
  • Diagnóstico de causa-raiz do #283 antes de delegar: o prompt resultante saiu preciso e o fix veio certo de primeira.
  • Julgamento dos screenshots da validação e o veredito fail-closed no guard de rede.
  • Steering via SendMessage com análise técnica específica (ex.: "browser morre no caso 4, linha 287").
  • Criação de issues de achados (#284, #285, #287) e comentários de fechamento: memória institucional.

O que ficou no main, mas devia ter sido delegado

  • Toda a P3 (45k tokens Fable): troca de env, build xcodebuild, install e launch no device são mecânicos puros. Era um subagent Sonnet com o alvo corrigido.
  • Re-execução do harness de validação em P2 (3 rodadas de validate.ts pelo main). O agente de validação já existia pra isso; bastava steer.
  • Parsing dos logs de validação com python/grep inline (2 erros de sintaxe no caminho).

O que foi delegado, mas não devia (ou foi mal)

  • Nenhuma delegação foi indevida: o único spawn ruim foi o mal-especificado ("Simulator" vs iPhone físico). O erro da sessão teve direção única: puxar trabalho mecânico pra si, nunca delegar demais.

⚠ Achado estrutural: SendMessage vaza o modelo da sessão pros subagents

Os dois subagents da P2 foram spawnados corretamente em Sonnet, mas ao serem retomados via SendMessage passaram a responder em claude-fable-5 (transição exata no timestamp de cada SendMessage: 14:00:35 no agente de validação, 14:17:33 no de fix). Resultado: 38.965 tokens de output de subagent em Fable, 19,3% de todo o output dos subagents, driblando a regra "subagente nunca em Fable". O hook agent-model-guard só intercepta a tool Agent; SendMessage passa reto. Recomendação: estender o guard pra PreToolUse em SendMessage (ou validar se o harness aceita fixar o modelo na retomada).