[🤖] Mesmo com um coordenador, preciso dirigir pessoalmente todas as sessões

✨ Resumo do GPT-5.6 Sol

Ao tentar dividir a produção de um folheto entre várias sessões, temi que o coordenador apenas recebesse relatórios até perder o contexto. Este é o registro de como mandei revisar a Skill para poder dirigir todas as sessões sem perder o estado da coordenação.

Por que eu não confiava no coordenador

Hoje recebi no trabalho a tarefa de produzir um folheto. Como nunca tinha feito um, pensei que seria útil ter um coordenador para ler os materiais relacionados, dividir o que precisava ser feito e coordenar várias sessões do Codex. Eu queria que ele lesse todos os chats do projeto atual e orientasse cada sessão sobre o que deveria avançar.

Mas a preocupação apareceu assim que dei a ordem.

Será que ele não vai ficar apenas recebendo relatórios como antes, perder o contexto e começar a falar bobagem?

Não era uma desconfiança vaga. Eu já tinha separado o coordenador dos workers e visto os relatórios engolirem a conversa do coordenador. Foi por isso que reconstruí a Skill custom-coordinate-parallel-workers em torno de relatórios em arquivos e checkpoints. Na época, também testei a ferramenta local de estados, mas não cheguei a operar todo o fluxo até o fim com várias sessões reais do Codex.

Desta vez eu tinha um trabalho real: o folheto. Porém, quando estava prestes a entregar novamente o papel de coordenador, percebi que acumular relatórios organizados em arquivos não resolveria tudo. Enquanto o coordenador lê os relatórios e distribui o trabalho, eu não sou alguém que fica parado observando. Vou continuar abrindo as várias sessões, corrigir na hora qualquer direção errada, fornecer mais material quando necessário e mudar as prioridades.

Para o coordenador funcionar corretamente, o estado da coordenação precisava resistir mesmo quando eu interviesse diretamente em outras sessões.

Vou continuar dando ordens nas outras sessões

A primeira atualização da Skill ainda parecia uma estrutura na qual eu dava ordens ao coordenador e observava as demais sessões executarem as instruções dele. Eu disse novamente, sem demora.

Eu também preciso poder dar todo tipo de ordem nessas sessões.

Eu não queria uma estrutura em que o coordenador monopolizasse toda a autoridade de instrução. Ele só precisa administrar o objetivo geral, a propriedade do trabalho, as dependências e a ordem de integração. Mas quem continua olhando o resultado concreto de cada sessão de trabalho e tomando decisões sou eu. Se eu disser para um worker ajustar um texto ou mudar o resultado dentro do escopo atual, ele deve aplicar isso imediatamente. Por outro lado, se a instrução alcançar arquivos de outra sessão, um contrato compartilhado, deployment ou estado externo, ele não pode ampliar o escopo por conta própria. Deve preservar o resultado que pedi e parar para que o coordenador reorganize o trabalho.

Foi com esse critério que mandei revisar novamente custom-coordinate-parallel-workers. Mesmo quando eu desse uma instrução adicional depois do fim de uma tarefa, ela não poderia mais ser esmagada em um único resumo de 256 caracteres. O resultado desejado, o que precisava ser preservado, os arquivos afetados, os efeitos externos e a sessão de origem da instrução passaram a ser registrados separadamente. Mesmo que o coordenador perdesse a memória da conversa, ele precisaria recuperar minha instrução dos arquivos.

Também impedi que o coordenador encerrasse uma solicitação de alteração apenas escrevendo “aceita”. Ela só pode ser considerada concluída quando estiver ligada a um novo relatório com a mudança real ou a uma nova assignment. Como uma ligação por si só também não prova que o conteúdo está correto, mantive ainda uma etapa que exige comparar o resultado solicitado e as condições de preservação com o diff real.

O importante não era aumentar a quantidade de arquivos de estado. Era garantir que minha instrução não desaparecesse quando eu falasse diretamente com qualquer sessão e, ao mesmo tempo, que ela não quebrasse silenciosamente a propriedade geral.

Não uni o coordenador à sessão de auditoria

Durante a revisão, também pensei se custom-coordinate-parallel-workers não exercia praticamente o mesmo papel da Graph Engineering Gate Skill que eu tinha criado no dia anterior. Na época, ela se chamava custom-graph-engineering-gate. As duas lidavam com várias sessões e estados de review, então uni-las parecia fazer sentido.

Desta vez não uni nada de imediato. Usei custom-deliberate para submeter a ideia a uma revisão crítica. A conclusão foi manter as duas separadas.

custom-coordinate-parallel-workers é controle de execução: administra propriedade de arquivos entre sessões de trabalho, instruções do usuário, relatórios, Git index, ordem de integração e efeitos externos. Já a Skill de auditoria examina, em uma sessão separada e sem o contexto anterior, um resultado que já foi integrado e congelado. Quando o coordenador revisa relatórios, está decidindo se o trabalho pode ser integrado. Isso é review de integração, não o veredito de um auditor independente.

Unir as duas poderia anexar automaticamente uma sessão de auditoria a todo trabalho paralelo. Também poderia fazer uma review comum do coordenador parecer uma auditoria independente. Por isso mantive as Skills separadas e apenas deixei explícito o limite entre elas. Uma sessão independente de auditoria só deve ser aberta quando o resultado realmente precisar dela, depois que o coordenador congelar esse resultado.

Decidi não confundir uma estrutura maior com uma estrutura mais segura. Os papéis necessários devem se conectar, mas não ser fundidos sob a aparência de que são o mesmo papel.

A instrução de transição que realmente entreguei ao coordenador

Eu não me limitei a definir princípios em palavras. Escrevi e entreguei à sessão do coordenador uma longa instrução de transição exigindo que primeiro reconstruísse os arquivos atuais e as sessões existentes, classificasse os conflitos e somente depois emitisse assignments. Registrei de uma vez que alterações existentes não poderiam ser apagadas descuidadamente, que as instruções dadas diretamente pelo usuário em cada sessão deveriam ser preservadas, que cada worker só poderia modificar seus próprios paths e que apenas o coordenador cuidaria da integração e do Git.

O texto original continha detalhes capazes de identificar o trabalho e os materiais reais, por isso não o publiquei integralmente. Anexo apenas uma cópia pública em que o nome da empresa, a área de atuação, nomes de clientes e de materiais de casos, serviços específicos e paths locais pessoais foram substituídos por expressões genéricas.

Ver a instrução pública e redigida de transição do coordenador

Vou dizer que é suficiente depois do trabalho real

Transições de estado, propriedade de arquivos, dependências, congelamento, instruções adicionais do usuário e recuperação de arquivos de estado antigos foram cobertos por testes automáticos. Durante a revisão crítica, também encontrei e fechei uma brecha que permitia encerrar uma solicitação aceita sem ligá-la a um novo resultado.

Mesmo assim, perguntei mais uma vez.

Foi aprimorado o suficiente?

A resposta foi que havia o bastante para iniciar um pilot controlado, mas não para dizer que o funcionamento tinha sido comprovado em várias sessões reais do Codex. Esta conversa era uma side session, então eu não podia abrir workers reais e testar ao mesmo tempo entrega de notificações, intervenção do usuário e recuperação do coordenador. Uma máquina de estados local passar não é a mesma evidência que ver o coordenador interpretar e integrar corretamente minhas instruções durante um trabalho longo.

Por isso decidi não imaginar e acrescentar mais regras aqui. Na sessão do coordenador, vou dividir de verdade o trabalho do folheto, observar cada sessão pessoalmente e dar instruções intermediárias. Vou acompanhar até o fim se o coordenador perde minhas instruções, invade a propriedade de outra sessão ou consegue recuperar o objetivo original e a próxima ação mesmo com o acúmulo de relatórios. Se o resultado sair hoje, continuo escrevendo hoje; se sair amanhã, continuo amanhã.

Depois de terminar o artigo, também reavaliei o nome da Skill de auditoria. O nome anterior, custom-graph-engineering-gate, explicava o conceito de origem, mas não mostrava o que a Skill realmente fazia.

O que faço de fato é interromper um resultado de trabalho e abrir uma sessão de auditoria separada. Por isso mudei o nome atual para custom-open-audit-session. O nome antigo permanece no registro daquela época, mas agora este é o único nome a ser chamado.

Não é preciso adiar também a conclusão deste artigo. Hoje eu não decidi confiar no coordenador. Deixei clara a condição de que a estrutura não pode desmoronar mesmo quando eu intervier diretamente em todas as sessões e, no lugar de afirmar que era suficiente, deixei um E2E para ser verificado em trabalho real.

Se esta estrutura merece confiança não será decidido por explicações nem pela quantidade de tests, mas pelo trabalho real do folheto que eu mesmo acompanharei.