Auditoria de fluxo05 set 2026 · Fable

Duas horas de trabalho.
Onde a coordenação pesa.

O sinal mais forte é a repetição de trabalho de coordenação: consultar agentes, recarregar regras e abrir tarefas sobre o próprio fluxo.

O recorte analisado

08:47:42 → 10:47:42 · Brasília

Cada cor é um arquivo da mesma cadeia. As quatro divisões são retomadas após auto-clear.

2.524 registros em cinco arquivos. Primeiro registro às 08:49:57; último às 10:47:39. A faixa cobre 117min42s entre extremos, não tempo de execução contínua.

Janela pedida: 120 minutos. Sem registros nos 2min15s iniciais. Os horários 10h59–11h03 são de entrega dos relatórios, não do material analisado.

O que o orquestrador chamou

469 chamadas de ferramenta

Contagem de chamadas, não duração nem custo. Bash inclui despacho, consulta, diagnóstico e outras operações. Volume não é prova de desperdício.

15 inícios de agente36 comandos de espera34 retornos rápidos em background

Os retornos rápidos medem a ferramenta do pai. Não provam que os executores ficaram parados.

Achados e ações

5 grupos · evidência separada de proposta

01Acompanhamento · prioridade 1Despachar não garante que a entrega volte ao usuário.

Evidência: 36 esperas; 34 retornaram em menos de 5 segundos, em background. O agente fer-81 acumulou 13 leituras de terminal e 10 esperas no levantamento por comandos.
Problema: O pai alterna entre consultar de novo e encerrar a resposta. Falta um caminho confirmado do término do filho até a revisão e a entrega.
Ação: Registrar cinco estados por unidade: enviado, recebido, em execução, resultado disponível e revisado. Só marcar recebido após evidência de que o brief entrou. Um observador fora do contexto do modelo sinaliza resultado ou bloqueio; o pai lê o terminal apenas para diagnosticar.
Teste: Medir tempo entre resultado salvo e revisão. Meta inicial: até 60 segundos. Simular auto-clear do pai, bloqueio do filho e prompt que não chega. O registro deve sobreviver aos três.
Cuidado: idle não basta para declarar conclusão. Um arquivo também não basta se ainda estiver sendo escrito. Exigir sinal de término e validar a entrega.

Fontes: timing.md, achado 2; tools.md, achado 1. Evidência alta; desenho proposto ainda não testado.

02Contexto · prioridade 2O auto-clear reinicia uma lista de oito skills.

Evidência: Quatro retomadas completas repetiram oito skills. Mais três chamadas no fim de um segmento somam 35. Os segmentos completos após a primeira retomada duraram cerca de 50, 14 e 15 minutos.
Problema: A continuação de uma tarefa já em execução passa por regras de entrevista e planejamento sem uma nova decisão que as justifique.
Ação: Trocar a lista fixa por um resumo curto de retomada: objetivo do dono, restrições obrigatórias, unidades vivas, evidências e próxima ação. Carregar a skill completa quando a próxima operação depender dela.
Teste: Após auto-clear, recuperar uma unidade ativa em até 15 segundos e sem recarregar skills sem relação com a próxima ação. Conferir se as restrições continuam presentes.
Cuidado: Uma marca “já leu” fora da janela não devolve instruções ao modelo. Preservar o conteúdo mínimo, não apenas a marca. A auditoria não mediu quanto cada skill contribuiu para os tokens.

Fontes: policy.md, achado 1; timing.md, achado 1. Repetição comprovada; contribuição para os clears não isolada.

03Escopo · prioridade 3Melhorar o fluxo compete com terminar a prova do produto.

Evidência: 116 chamadas ao Linear, incluindo 49 save_issue e 32 comentários. O relatório identifica tarefas de harness abertas durante a prova ao vivo e correções do usuário para recuperar o objetivo ponta a ponta.
Problema: A regra de auto-melhoria exige registrar, criar tarefa e despachar no mesmo segmento. Um problema de coordenação passa a disputar executor e atenção com a entrega original.
Ação: Registrar a melhoria quando aparecer; executar imediatamente apenas se ela bloquear a entrega atual. Agrupar as demais para depois da prova. Manter o objetivo e o critério de conclusão no card principal.
Teste: Nenhuma melhoria não bloqueante começa enquanto a prova principal está pendente. Após uma retomada, o pai recupera o critério de conclusão sem pedir que o dono repita.
Cuidado: 49 chamadas de salvamento não significam 49 tarefas novas. Escritas de memória são úteis; o alvo é a concorrência desnecessária com o trabalho principal.

Fonte: policy.md, achado 2. Correção do objetivo em 1ddd0620…:187–213; abertura da família de prova em :265–280.

04Ferramentas · prioridade 4Reescrever um comando recusado não resolve a restrição.

Evidência: O auditor de ferramentas identificou nove recusas de isolamento de worktree e cinco bloqueios do classificador. Também encontrou consultas repetidas e dois retornos Bash com mais de 30 mil caracteres.
Problema: Parte das tentativas muda variáveis, invólucros ou a forma do comando, mantendo a operação que foi recusada. Retornos grandes ainda levam conteúdo desnecessário à janela.
Ação: Classificar o primeiro erro: permissão, entrada, capacidade ou falha transitória. Em recusa de segurança, usar um caminho autorizado ou pedir a aprovação prevista. Não trocar de ferramenta para contornar a recusa. Resumir resultados antes de enviá-los ao modelo.
Teste: Zero novas tentativas semanticamente iguais após recusa de segurança. Cada repetição deve ter uma causa diferente e explícita. Limitar retornos de rotina a 8 mil caracteres.
Cuidado: Não remover os guards para melhorar a taxa de sucesso. As recomendações sobre CLIs alternativas no relatório precisam de verificação de disponibilidade.

Fonte: tools.md, achados 2 e 3. Recusas e tamanho de respostas observados; alternativas não executadas nesta auditoria.

05Regras · mudança transversalHá mais de uma instrução exigindo ser a primeira.

Evidência: Os mandatos pedem ler o handoff primeiro, carregar skills em resposta exclusiva, comentar no Linear antes de agir e despachar. A política manda delegar escritas no board, mas o pai fez 81 chamadas de salvamento de issues ou comentários.
Problema: O fluxo exige ordens incompatíveis. Cumprir uma deixa outra para trás, e o handoff repassa a contradição.
Ação: Definir uma sequência por papel: orquestrador retoma objetivo e unidades; executor lê a unidade e trabalha; auditor coleta e reporta. Um único procedimento resolve a precedência. Permitir ao pai atualizar o estado da unidade que coordena.
Teste: Ensaiar início novo, auto-clear, pergunta de status e entrega de filho. Cada cenário deve ter uma próxima ação inequívoca, sem uma cascata de carregamentos.
Cuidado: Reduzir regras redundantes sem retirar autorização, isolamento ou limites de produção.

Fonte: policy.md, achado 3. Contradições confrontadas com os arquivos locais consultados pelo auditor.

O que mudar primeiro

Fechar o caminho entre resultado e revisão.Responsável: integração Herdr + orquestrador. Primeiro ensaio: entrega do filho enquanto o pai passa por auto-clear.
Encurtar a retomada sem apagar as restrições.Responsável: procedimento de handoff. Remover a lista fixa de oito skills; preservar objetivo, restrições e unidades em andamento.
Separar prova do produto de manutenção do fluxo.Responsável: política de auto-melhoria. Só interromper a prova por um bloqueio real.
Repetir a medição numa nova janela de duas horas.Comparar atraso de revisão, chamadas por unidade e retomadas. Só chamar de ganho o que melhorar sem perder verificação.

Preservar

Panes identificados sobrevivendo ao auto-clear.
Linear como registro do objetivo e das entregas.
Isolamento de worktree e autorização.
Espera de 120s e limite de 10min já incorporados à skill consultada. Não são melhorias ainda pendentes.

Não concluir destes dados

Que silêncio do pai significa filho parado.
Que muitas chamadas significam pouco trabalho entregue.
Que as skills sozinhas causaram os clears.
Que há uma economia comprovada de tempo ou tokens. Não foi calculada.

A falha desta auditoria também conta

Os três resultados estavam salvos entre 10h59 e 11h03. Eu não os consolidei antes da sua cobrança. O lançador havia encerrado o acompanhamento após um erro de envio; iniciar os agentes manualmente não restabeleceu esse acompanhamento.

Esse caso reforça a prioridade 1. É evidência desta conversa, separada do recorte de duas horas do Fable.

Rastro e limites

Três revisões independentes por Cursor Grok 4.6 High. Censo de ferramentas recontado pelo coordenador. Relatórios: timing.md, tools.md e policy.md.

↳Cinco arquivos ligados por handoffs

As leituras de terminal têm contagens diferentes entre os auditores porque um conta comandos e outro inclui ocorrências em comandos compostos. Não foram somadas. Os logs completos dos filhos não fazem parte deste corpus.

Linear da auditoria sem autenticação: nenhum card criado. Nenhuma mudança aplicada a skills, hooks ou produto. Datas e números pertencem ao recorte fixado, não ao estado atual do Fable.