O Controlador e os Workers

O FlowForge não trata a IA como um único gênio que você fica reinvocando sem parar. Ele roda um modelo de orquestração: um controlador — o ACE — que decide, um banco de agentes especialistas que executam, e workers isolados que levam um ticket da branch até um pull request revisado. Este capítulo explica quem faz o quê e onde o fundador permanece no circuito.

O controlador — ACE

O controlador tem um nome: ACE, apelido O Controlador — o parceiro com quem você conversa, e a personificação da promessa Never Alone do FlowForge (Capítulo 1). O trabalho do ACE é entregar a intenção do fundador de forma rápida e bem-feita, e ele tem duas ferramentas para isso:

• Orquestrar — despachar agentes especialistas quando o trabalho é paralelo, exige domínio técnico profundo, ou é substancial o bastante para valer uma branch isolada e uma revisão independente.
• Executar diretamente — fazer a própria mudança quando isso é mais rápido: edições pequenas e reversíveis, e todo diagnóstico, leitura e investigação.

Isso é o dial de cerimônia. Não existe regra de que o controlador jamais possa tocar em código, nem regra de que tudo precise virar uma saga multiagente. O antigo enquadramento de “sempre orquestre, nunca execute” estava errado — ele transformava correções de cinco minutos em produções. A regra real é bom senso, dimensionado ao risco e ao tamanho.

O banco de especialistas

O FlowForge vem com um elenco de agentes especialistas — arquitetura, backend, frontend, design, banco de dados, segurança, QA, documentação, interface de terminal e outros. Cada um detém domínio técnico profundo e atualizado, e é despachado para o trabalho em que é melhor. O trabalho de design passa por uma autoridade de design que entrega um brief por superfície; o trabalho de interface de terminal passa por um arquiteto de TUI que decide a composição antes de um agente-folha escrever o código da view. A regra de roteamento é simples: recorra ao especialista quando ele multiplica você, e diga o porquê quando não o fizer.

Workers: um ticket, uma branch isolada

A implementação de um ticket roda como um worker — não como uma subtarefa improvisada. Um worker recebe:

• seu próprio cronômetro (o registro faturável),
• sua própria branch de feature em uma worktree isolada (para que workers paralelos nunca colidam nos mesmos arquivos),
• um portão de verificação de ticket no spawn (um ticket fechado não consegue iniciar um worker), e
• um relay de volta ao controlador.

O isolamento importa: um worker que rodasse no checkout principal amontoaria seus entregáveis sem rastreamento e os perderia. Cada worker é dono da própria árvore, faz o seu trabalho, abre um pull request em rascunho e sinaliza concluído com fatos — nunca com um veredito autodeclarado.

O portão de revisão

Um worker nunca corrige a própria prova. O veredito que abre o portão vem de uma revisão independente — um veículo novo e separado que revisa o pull request contra a barra de aceite do blueprint. Dois invariantes protegem o merge:

• Sem merge no vermelho. Uma verificação de CI falhando barra o merge, sempre.
• Sem merge sem um GOLDEN independente. A aprovação do revisor é um portão obrigatório; o worker que escreveu o código não pode postar o veredito que o libera.

O controlador relata o que a revisão encontrou, reclassificando a severidade bruta em termos do domínio do produto para o fundador — um “BLOCKER” do revisor é um insumo a julgar, não uma manchete a repetir como papagaio.

O fundador permanece no circuito no que importa

Merges, ações irreversíveis, mudanças de escopo e decisões voltadas ao cliente são do fundador. Os passos rotineiros, não. E, por padrão, um humano faz o merge final — o FlowForge não faz merge automático a menos que uma flag de autonomia permanente esteja explicitamente ligada. A atenção do fundador é gasta onde muda o resultado, e em nenhum outro lugar.

Por que isso importa

O modelo de orquestração é como o FlowForge escala sem perder o controle. Os especialistas trazem profundidade, os workers trazem isolamento e um rastro documental limpo, a revisão independente traz confiança, e o controlador mantém a coisa toda apontada para o que o fundador de fato quer — rápido quando dá, cuidadoso onde é preciso.