Forge

O problema

Todo projeto que eu começava fora do expediente gastava os primeiros dias na mesma coisa: escolher a stack, montar lint, configurar teste, escrever o esqueleto de deploy. O código que importava só começava depois — e boa parte dos projetos morria antes de chegar lá.

Assistentes de IA resolveram o rascunho, não o processo. Um modelo escreve um componente muito rápido; ele também escreve o componente errado muito rápido, e na conversa seguinte não lembra por que a decisão anterior foi tomada. O gargalo deixou de ser digitar código e passou a ser manter uma decisão de pé por tempo suficiente para o código valer alguma coisa.

A decisão

O Forge é uma fábrica com constituição escrita: um documento de leis que todo agente lê antes de agir, e hooks de shell que bloqueiam o que a lei proíbe.

A primeira lei é spec antes de código. Nada não-trivial vira implementação sem passar por design aprovado, requisitos e uma lista de tasks. A segunda é gastar token em decisão e economizar em execução: arquitetura roda em Opus, implementação em Sonnet, pesquisa e scaffolding em Haiku. A terceira é a que mais mudou o resultado na prática — hook, não prompt. Regra escrita em prompt é sugestão; um modelo com pressa a contorna sem má-fé. Regra escrita em hook é um processo que retorna exit 1 e a edição não acontece.

Hoje são 24 hooks fazendo esse trabalho: bloqueiam segredo em commit, rm -rf, curl | sh, push forçado sem flag explícita, e código de produção escrito antes do teste que o justifica.

Como funciona

O isolamento é a parte menos óbvia do desenho. Cada subagente roda em uma janela de contexto própria: o architect não vê o histórico de implementação, o debugger não vê as tentativas que falharam antes dele. Isso custa alguns tokens de repetição e compra a única coisa que importa em cadeia longa — um agente não herda o viés do agente anterior.

A escada de review

Código que passa no teste não é código aprovado. O Forge separa três perguntas diferentes e proíbe fazê-las ao mesmo tempo.

O reviewer-spec pergunta se o código faz o que a task pediu e se o teste veio antes. O reviewer-quality pergunta se está seguro, tipado e limpo. O verifier não pergunta nada: sobe a aplicação e olha. É o estágio que mais achou problema real — build verde, teste verde e o efeito visível quebrado no navegador, juntos, com uma frequência que incomoda.

Uma coisa que aprendi da forma cara: gate aplicado por persuasão não é gate, é moeda. Numa rodada o reviewer-quality aceitou um argumento no lugar do token e rodou; na rodada seguinte, diante do mesmo argumento, recusou — corretamente. Um portão que às vezes abre com conversa não é um portão. A regra virou determinística: token no input, sempre, sem exceção negociável.

Quando falha

O Forge tem permissão explícita para desistir.

O implementer tenta corrigir uma vez no mesmo contexto. Um hook conta as falhas: três seguidas e a task cai para o debugger, em Sonnet, com contexto limpo. Se o debugger não resolver em dois ciclos, ele escala para uma variante em Opus. Se essa falhar em três ciclos, o sistema para e pergunta a um humano. Não inventa solução, não reescreve a spec para o bug caber nela.

O mesmo vale para divergência: quando o código e a spec discordam, a fábrica congela e mostra o diff conceitual, em vez de escolher sozinha qual dos dois estava certo.

O que isso parece na prática

Este site foi gerado assim. O ciclo, resumido:

/forge-new "portfólio pessoal — cena fotográfica navegável"

  router        track LANDING · forma Astro/SSG · sem framework de UI
  architect     design.md aprovado · 7 rotas · 1 ilha de câmera WAAPI
  spec-writer   92 requisitos · 131 tasks
  implementer   TASK-001 teste vermelho → verde
  review        spec ok · quality ok · verify ok
  …
  gate          lint · types · build · unit · e2e

  186 entradas concluídas · 150 commits · a página que você está lendo

Nenhum arquivo deste portfólio foi escrito fora desse ciclo. A regra da fábrica vale para a própria fábrica: quando eu quis mudar o brilho de uma tela na cena, o pedido virou task, teste, review e verificação no navegador — não uma linha de CSS trocada na pressa.

Onde ele erra

A telemetria mostrou dois erros que o meu palpite não pegaria.

O gate estava no comando errado. A escada de três estágios é obrigatória no comando que cria um projeto, mas depois do MVP um projeto passa a viver no comando de correção, onde o gate não existia. Medindo o histórico, a maior parte das tasks concluídas tinha rodado com um só estágio de review, não três — a escada continuava especificada, só que num lugar que já não rodava mais. Hoje o comando de correção conta commits desde o último review completo e força o lote quando passa do limiar.

Retrospectiva sem ledger é conversa. As primeiras retros geravam propostas de melhoria excelentes que ninguém verificava depois. Cada melhoria aplicada agora escreve uma linha em um ledger com uma promessa verificável e um jeito de conferir — e a retro seguinte é obrigada a cobrar a linha anterior antes de propor qualquer coisa nova.

Estado

Quatro tracks (landing, SaaS full-stack, front separado de back .NET, e mobile Flutter para as lojas), 21 subagentes, 19 skills, 13 comandos e 24 hooks. Oito projetos saíram da fábrica até agora — este é um deles, e é o único que você pode abrir e clicar.

O Forge é privado: ele carrega decisões de arquitetura e telemetria de trabalho que não fazem sentido em repositório aberto. Se você quiser conversar sobre como ele é montado por dentro, é só chamar.