[🛠] Conectei de verdade um coordenador e vários workers

✨ Resumo do GPT-5.6 Sol

Um registro de dividir um objetivo em vários Work Items, entregá-los a diferentes workers e deixar um coordenador verificar e integrar os resultados.

De workers repetitivos para workers baseados em Work Items

Em um projeto anterior de coleta de dados, eu também separava workers e coordenador. Naquela época, porém, os workers repetiam o mesmo batch segundo um goal fixo, enquanto o coordenador organizava periodicamente os resultados acumulados.

Desta vez foi diferente. Entreguei ao coordenador um objetivo em linguagem natural. Ele definiu as condições de conclusão e os Work Items, depois distribuiu arquivos e escopo entre os workers.

Cada worker -W- concluiu e verificou sua tarefa, depois entregou um commit. O coordenador -C- revisou esses resultados, integrou um por um e conferiu novamente o estado completo.

Mais workers também aumentaram o custo de integração

O fluxo em si era simples.

Entregar o objetivo
→ Dividir em Work Items
→ Executar e verificar em cada worker
→ Entregar os commits
→ O coordenador revisa e integra
→ Verificar novamente o estado completo

O melhor foi deixar claro quem cuidava de cada parte. Se uma tarefa falhasse, as outras não eram abaladas, e eu podia revisar cada resultado como um commit.

O problema também apareceu na hora. Quando abri workers demais, os relatórios chegaram todos de uma vez. Sessões duplicadas tornaram a gestão ainda mais complicada. Mais paralelismo não era automaticamente melhor. O trabalho precisava ser dividido dentro do que o coordenador realmente conseguia administrar.

Naquele dia, também refinei a baseline de Orchestrator e Acceptance, o Workflow e a Skill comuns e as regras operacionais das sessões de workers e coordenador.

O que quero automatizar no OpenClaw

Não quero reproduzir exatamente no produto as sessões, Worktrees e Branches que usei hoje. Quero automatizar as decisões por trás delas.

• até onde dividir um objetivo
• quem é responsável por cada resultado
• o que deve ser verificado antes de considerar uma tarefa concluída
• de onde recomeçar depois de uma falha

O OpenClaw precisava de um coordenador que gerenciasse a propriedade dos resultados, a verificação e os pontos de retomada, não apenas de mais workers.