Fluxo de Trabalho e a Máquina Automatizada

Este capítulo é a visão de cima: como a máquina inteira se encaixa, os portões que a mantêm honesta, a automação que a deixa rodar enquanto você dorme, e os controles que mantêm você no comando dela.

A visão de cima: Fundador → ACE → orquestradores → agentes

O modelo é simples de descrever e verdadeiro na prática. O trabalho flui para baixo por uma cadeia de comando, e os resultados fluem de volta para cima por ela:

        FUNDADOR  (você — define a intenção, ratifica planos, faz merge do que importa)
           │
           ▼
          ACE   (O Controlador — decide, despacha, retransmite)
           │
           ▼
     ORQUESTRADORES  (workers — um ticket cada, worktree isolado, PR em rascunho)
           │
           ▼
        AGENTES   (o banco de especialistas — profundidade sob demanda)

• Você define a intenção e detém as duas decisões que importam — o plano está certo, e o merge está certo.
• ACE — o controlador, a personificação do Never Alone — decide o que fazer diretamente e o que despachar, e depois retransmite os resultados para você em termos simples.
• Orquestradores são workers: cada um carrega um ticket em um worktree isolado, da branch até um pull request em rascunho já revisado.
• Agentes são o banco de especialistas (Capítulo 10) — despachados para o trabalho em que são melhores.

A mesma imagem é desenhada como um gráfico formal de blueprint, renderizado pelo gerador de gráficos do FlowForge em ambos os temas — os estilos brand-black e cianotipo de desenho de engenharia — para que ela pertença igualmente ao terminal, a um PDF e a uma parede:

Os portões que a mantêm honesta

Velocidade sem portões é apenas um jeito mais rápido de entregar um bug. A automação do FlowForge é confiável por causa dos portões que ela nunca pode pular:

• O portão de revisão (GOLDEN). Um worker nunca corrige a própria prova. Um revisor independente — um veículo novo e separado — revisa o pull request contra a régua de aceite do blueprint e posta o veredito GOLDEN que libera o portão. O worker que escreveu o código não pode postar o veredito que o libera.
• Nenhum merge no vermelho. Um check de CI falhando bloqueia o merge, sempre.
• O portão de TDD. Mudanças no código core precisam ser entregues com seus testes. O ponto de estrangulamento do merge recusa estruturalmente um pull request cujas mudanças de core não carreguem mudanças de teste — isso é imposto, não apenas recomendado.
• O portão de blueprint. Trabalho do tamanho de uma feature precisa de seus artefatos de blueprint — requisitos, um brief do product owner, um registro de arquitetura — antes de o código ser despachado. Trabalho trivial e de correção de bug passa livre; o portão é escalonado por tamanho, para nunca gritar lobo à toa.

Dois pontos de contato do fundador, e nenhum a mais: você ratifica o plano, e você (por padrão) faz o merge final. Tudo o que fica entre os dois é trabalho da máquina.

A máquina AAA: automação em que você pode confiar

Com os portões no lugar, o FlowForge pode automatizar com segurança o trabalho braçal ao redor deles — a diferença entre uma demo e um software triple-A que se entrega sozinho:

• As ondas disparam sozinhas. Os tickets de um milestone são emitidos como uma onda ordenada por dependências; conforme as dependências de cada ticket são liberadas, os próximos workers disparam automaticamente. Você não precisa lançar cada passo manualmente.
• Automerge (opt-in). Com a flag permanente de autonomia ligada (on), um pull request totalmente verificado — aberto, mergeável, GOLDEN no head e verde — é mesclado sem intervenção humana, sem esperar por sua tecla. A flag dispensa apenas o m humano final; ela nunca pode contornar os portões de GOLDEN ou de CI verde, que ficam a montante e são estruturalmente inalcançáveis sem passar por eles. Ela vem desligada por padrão — apresentar o merge para o seu sinal verde é o padrão seguro até você decidir o contrário.
• Ratificação em tempo de documentação. A disciplina de blueprint roda no tempo do planejamento, então os documentos existem antes do código — não como um detalhe deixado para depois.
• Nenhum papagaio. A máquina nunca repete uma alegação que não checou. A nota de severidade de um revisor é um insumo para julgar, não uma manchete para ecoar; o “pronto” de um worker é um conjunto de fatos a verificar, não um veredito a retransmitir.

Automação e controle não estão em tensão aqui — os portões são exatamente o que torna a automação segura de se confiar.

A doutrina dos ponteiros

Esta é a disciplina que impede a máquina de derivar para a ficção. Orquestradores nunca recebem a resposta pronta — eles recebem um ponteiro, e verificam na fonte.

• Um worker recebe a informação “o contrato está em ADR-0078” ou “o formato da API está no arquivo swagger” — nunca uma paráfrase do que esses documentos dizem.
• Ele lê a fonte primária e constrói contra ela, para que a implementação não derive de um resumo sutilmente errado.
• O revisor faz o mesmo, ao contrário: verifica o trabalho contra as fontes primárias, não contra a descrição que o worker fez do trabalho.

Nunca resumos, nunca suposições. O blueprint é a fonte da verdade; o código segue o blueprint, nunca o contrário.

htmlinsteadofmds

Um blueprint escrito como um arquivo Markdown cru é honesto, mas feio — e quando uma parte interessada ratifica um .md, ela está aprovando algo que não consegue realmente ver. O FlowForge fecha essa lacuna.

Aponte o motor de documentação para qualquer arquivo Markdown e ele renderiza, em uma fração de segundo, um arquétipo HTML com o estilo da marca — perfeito tanto no modo escuro quanto no claro — que você pode colocar na frente de um colega de equipe, um cliente ou um investidor:

flowforge docs render <file.md> --out <dir>

Uma fonte feia, uma renderização bonita e apresentável — sem reestruturar, sem estilizar à mão. Isso, sozinho, muda a ratificação: as pessoas aprovam o que conseguem ver.

Dentro do cockpit e do aplicativo desktop, isso é renderizado direto no painel de preview e na Documents Drawer — você nunca precisa sair do FlowForge para ler o próprio trabalho.

Os controles — recomendados pela ciência, decididos por você

O FlowForge é entregue com padrões extraídos de experiência e evidência — mas eles são controles, não leis. Cada um deles vive na tela Settings (S no cockpit, Capítulo 9), e é você quem os ajusta:

Ao lado desses ficam as escolhas de fluxo de trabalho que o FlowForge recomenda — a disciplina git-flow (branch de feature sempre, nunca commit direto na main), deploy-from-main para que a main sempre seja igual ao código do cliente, e a telemetria de Quality Zone por worker, para que você possa ver a saúde do trabalho enquanto ele roda. Padrões recomendados, cada um deles seu para ajustar.

ForgePlays

Um ForgePlay é uma execução nomeada e guiada de uma cerimônia inteira — um único comando que percorre uma sequência dirigida de passos, com os portões do fundador embutidos exatamente onde o plano precisa deles (Capítulo 7). O fluxo emblemático, Planejar uma Feature, transforma uma ideia em linguagem simples em tickets devidamente vinculados e documentados, com exatamente dois portões. Outros fluxos aterrissam uma base de código legada ou levantam uma landing page. Os fluxos não removem o seu julgamento — eles removem o trabalho braçal ao redor dele.

Visão de futuro — os fluxos que ainda vêm

A biblioteca de ForgePlays foi projetada para crescer. No roadmap:

• Um fluxo de campanha de lançamento — leva uma feature já entregue até o seu anúncio.
• Um especialista em tráfego pago — um agente de marketing que planeja e ajusta a aquisição.
• Reels com Video-LLM — transforma um release em vídeos curtos e compartilháveis do produto, automaticamente.

O padrão é sempre o mesmo: uma cerimônia que vale a pena repetir se torna um fluxo que você pode apertar.

Para onde ir agora

• O catálogo vivo de especialistas: flowforgesoft.com/agents
• O produto, os preços e a história: flowforgesoft.com
• Instale em uma linha: curl get.flowforgesoft.com/install.sh | sh

Por que isso importa

A máquina não é mágica e não é uma caixa-preta. É uma cadeia de comando clara, um pequeno conjunto de portões que nunca podem ser pulados, e um grande conjunto de controles que você comanda. É isso que permite ao FlowForge rodar rápido e continuar confiável ao mesmo tempo — automatizado onde é seguro, contido por portões onde importa, e sempre apontado para o que você realmente pediu.