Às vezes o que você entrega ao harness não é uma spec — é um palpite. "Me construa uma coisa que faz mais ou menos isto." O loop que você conheceu nas lições anteriores precisa de um pronto mensurável contra o qual rodar, e um palpite não tem um. Forge é o front-end que transforma o palpite nesse contrato: sete passos que sabatinam a ideia, a escrevem como um PRD, a fatiam em tickets e um GOAL.md, e então entregam tudo ao loop para construir e provar — enquanto você apenas observa.
O loop das lições anteriores é preciso: cada passo escolhe uma unidade delimitada, faz a mudança e a prova no limite real. Mas essa precisão precisa de algo para mirar — um "pronto" mensurável. Dê a ele uma spec afiada e ele roda lindamente. Dê a ele um desejo vago — "me construa uma ferramenta que ajuda as pessoas a acompanhar suas leituras" — e ele não tem nada nítido contra o qual se verificar. Ele teria que adivinhar o que você quis dizer, e adivinhar é exatamente o que todo este método existe para evitar.
Forge é a parte que você roda antes do loop, quando tudo o que você tem é um palpite. Seu único trabalho é transformar essa ideia bruta em um contrato real contra o qual o loop pode construir: uma descrição escrita, uma lista de trabalho fatiada, e um arquivo de objetivo com uma linha de chegada mensurável. Uma vez que o Forge fez seu trabalho, o loop assume — e agora ele sabe exatamente como o sucesso se parece.
Crucialmente, o Forge faz isso com você, mas em sua maior parte sem precisar de você. Você joga a ideia bruta lá dentro e então dá um passo atrás para observar. A máquina interroga o próprio raciocínio, preenche as próprias lacunas, e só te dá um toque no ombro para a rara decisão que genuinamente só você pode tomar — uma verdadeira bifurcação no caminho, como "isto deve ser gratuito ou pago?" Todo o resto, ela descobre e escreve para que você possa ler depois.
Pense nisso como… dar um briefing a um arquiteto. Você não entrega plantas de engenharia — você diz "quero uma casa clara e aberta para uma família de quatro, perto do jardim." Um bom arquiteto não sai despejando concreto. Ele faz perguntas afiadas, esboça, e volta com plantas e uma lista de materiais que você pode aprovar. O Forge é o processo desse arquiteto: ele se recusa a construir até que o palpite tenha virado um plano preciso o bastante para construir a partir dele. O loop é a equipe de construção que então segue o plano.
O Forge é o front-end do loop, não um substituto dele. Ele roda uma vez, lá no começo, para fabricar as entradas que o loop presume já existirem: um PRD (a spec escrita), um conjunto de issues em um quadro kanban com relações de bloqueio, e um GOAL.md com um done-when mensurável. No momento em que esses existem, o loop de construção autônomo que você aprendeu nas lições 2 e 3 pode rodar, porque ele finalmente tem um contrato contra o qual verificar.
Quando o prompt com que você começa já é uma spec apertada — escopo claro, done-when óbvio — você pula o Forge e vai direto para o loop. O Forge justifica sua existência precisamente quando a entrada é crua: uma ideia, uma frase, um screenshot, um "não seria legal se…".
O fluxo inteiro cabe em uma linha: uma ideia bruta entra pela esquerda, passa por sete passos, e o que sai pela direita é um contrato preciso o bastante para o loop construir e provar. Os dois passos do meio em caixas tracejadas são opcionais — usados apenas quando a ideia precisa de mais embasamento ou de um visual rápido antes de ser escrita.
A única regra
O Forge não deixa a construção começar até que a ideia tenha virado um contrato com uma linha de chegada mensurável. Sem um done-when mensurável, sem construção.
Aqui está o fluxo inteiro como uma lista. Leia de cima para baixo — cada passo pega a saída do passo acima e a afia. Os passos 2 e 3 são puláveis; os outros cinco sempre rodam.
grill — sabatinar a ideia
A ideia é submetida a um teste de estresse com perguntas difíceis: para quem é isto, o que "bom" significa, o que está explicitamente fora de escopo, o que poderia dar errado. A maioria das perguntas a máquina responde sozinha, raciocinando em voz alta; só uma decisão genuinamente só-sua é escalada para você.
research — embasar na realidadeopcional
Se a ideia se apoia em fatos que vivem no mundo — o preço de um concorrente, o que uma API de fato retorna, se uma biblioteca ainda existe — esses são verificados contra uma fonte confiável em vez de presumidos. Pulado quando a ideia não precisa de fatos externos.
prototype — esboçar rápidoopcional
Um mock descartável ou uma tela rascunhada, apenas o suficiente para tornar a ideia concreta e pegar cedo um "não foi isso que imaginei" — antes de ser escrito na spec. Pulado quando o formato já está claro.
to-prd — escrever a spec
Tudo o que foi resolvido até aqui é escrito como um Documento de Requisitos de Produto (PRD): o problema, para quem é, o que está dentro e fora, e o que significa sucesso. Este é o primeiro artefato durável — a coisa contra a qual tudo o que vem depois é verificado.
issues + /goal GOAL.md — fatiar e fixar a linha de chegada
O PRD é cortado em pequenos tickets em um quadro kanban, com relações de bloqueio para que a ordem seja explícita (isto não pode começar até que aquilo esteja pronto). Ao lado dele, o GOAL.md registra o done-when mensurável usando a disciplina ultragoal — a única linha à qual o loop vai se submeter.
implement — o loop de construção AFK
Agora o loop roda, ticket por ticket, longe do teclado. Para cada ticket um Executor constrói a mudança e um Validador separado a prova no limite real. Você não está neste caminho — você está observando.
review — passe de QA AFK → review.md
Quando a construção converge, um passe final de qualidade roda — também longe do teclado — e escreve suas constatações em review.md, o relatório de observabilidade que você lê para ver como foi. Até o QA é algo que você observa, não algo que você roda à mão.
Os passos se alinham com movimentos concretos da suíte: grill (um passe de autoquestionamento), um passe opcional de research, um prototype opcional, to-prd (escreve o PRD), to-issues mais /goal (escreve os tickets do kanban e o GOAL.md), o loop implement, e um passe de review que emite o review.md. Cada passo deixa um arquivo durável para trás, e é isso que torna a execução observável depois do fato.
As relações de bloqueio nas issues importam: elas codificam a ordem de dependência para que o loop de construção nunca pegue um ticket cujos pré-requisitos não foram atendidos. É assim que uma lista plana de trabalho vira uma sequência segura para executar sem supervisão.
A razão de o Forge poder rodar enquanto você faz um café é que o trabalho é dividido entre três tipos de ator, cada um com uma faixa estrita. Conhecer as faixas é todo o truque para confiar no processo.
Você (o humano) faz a menor e mais valiosa coisa: entrega a ideia bruta, e então observa. Você lê os artefatos conforme eles aparecem — o PRD, o quadro, o review.md — mas você não conduz os passos. A única exceção é uma bifurcação genuína que só você pode resolver, na qual o Forge para e pergunta.
O modelo (o LLM) faz o raciocínio que antes precisava de uma reunião. No grill ele discute consigo mesmo — coloca a pergunta difícil, então a responde a partir da razão — e escreve a resposta. Ele se autorresponde em quase tudo; só escala a rara decisão que verdadeiramente pertence a você.
Os agentes fazem a construção, no passo implement, e vêm em dois papéis que nunca são o mesmo ator: um Executor escreve o código de um ticket, e um Validador prova que aquele ticket de fato funciona no limite real. Separá-los é deliberado — quem o construiu nunca é quem o certifica.
Pense nisso como… um set de filmagem. Você é o produtor que dá sinal verde ao conceito e assiste aos cortes do dia. O diretor (o modelo) toma as mil decisões criativas e só traz as maiores para você. A equipe (os agentes) de fato filma — e um supervisor de continuidade separado confere cada tomada, porque a pessoa que a filmou é a última que deveria julgar se ela ficou boa.
Agora torne isto concreto. Escolha um passo e uma lente — você mesmo, o modelo, ou os agentes — e o painel mostra exatamente o que aquele ator faz naquele passo, mais o arquivo ou artefato que ele deixa para trás. É a mesma ideia das três faixas acima, mas você a comanda: mude qualquer um dos controles e o readout se renderiza de novo.
Passo do Forge
Por qual lente
O painel não tem marcação por combinação. Cada controle segmentado apenas escreve um valor em um pequeno objeto state — state.step e state.lens — e um único render() lê ambos, pinta a pill, o título, a frase de papel e o readout de código. É o mesmo padrão dirigido por tokens de uma prévia de design-system: muda um valor, re-renderiza, sem marcação nova. Aqui os "tokens" são qual passo e de quem é a faixa.
A matriz é a lição em forma de dados: para um dado passo, a linha do humano é geralmente "observar / ler o artefato", a linha do modelo é "decidir e escrever", e a linha do agente só acende com trabalho real no implement (Executor constrói, Validador prova) e no review (o passe de QA AFK).
Dois artefatos merecem um olhar mais de perto, porque são eles que tornam a construção segura para rodar sem supervisão. O primeiro é o kanban de issues — o PRD picado em pequenos tickets, cada um com relações de bloqueio que dizem o que deve terminar antes que ele possa começar. O segundo é um GOAL.md que fixa a linha de chegada mensurável para a execução inteira, escrito com a disciplina ultragoal.
Por que os dois? As issues dizem o que construir e em que ordem; o GOAL.md diz como a execução sabe que de fato terminou. Sem a ordenação, um agente poderia pegar um ticket cujas fundações ainda não existem. Sem o done-when, o loop não teria limite contra o qual provar — exatamente o problema que o Forge existe para resolver.
Pense nisso como… uma ficha de receita fixada ao lado de uma lista de preparo. A lista de preparo (issues) é ordenada — pique antes de refogar, refogue antes de empratar. A ficha de receita (GOAL.md) é a única linha que te diz que o prato está finalizado: "serve quatro, empratado, molho reduzido." A equipe segue a lista de preparo; a ficha é como qualquer um sabe que deve parar.
GOAL.md guarda a única linha mensurável contra a qual o loop verifica.O /goal compila o GOAL.md sob a disciplina ultragoal: ele se recusa a finalizar até que o done-when seja mensurável e aprovado, e estrutura o arquivo em blocos explícitos (goal, context, constraints, verification, done-when). É essa estrutura que permite a um loop sem supervisão se verificar honestamente — há um alvo nomeado e testável em vez de um vibe.
As relações de bloqueio nas issues são um grafo de dependências, não decoração. O loop de construção só puxa um ticket quando seus bloqueadores estão Pronto, e é isso que impede uma execução AFK de construir o terceiro andar antes de a fundação existir.
O Forge não é abstrato — é uma sequência que você dispara e então vê produzir arquivos reais. Aqui está o formato de uma execução: um comando para começar a partir da ideia bruta, e os artefatos duráveis que aparecem conforme cada passo aterrissa. Note que, depois da primeira linha, seu trabalho é ler, não digitar.
# entregue a ideia bruta — esta é a única coisa que VOCÊ conduz forge "um pequeno app web para acompanhar os livros que estou lendo" # o Forge roda os passos e deixa artefatos que você LÊ, em ordem: PRD.md # a spec escrita (do to-prd) issues/ # tickets do kanban com relações de bloqueio GOAL.md # o done-when mensurável (do /goal, ultragoal) LOOP-LOG.md # o rastro corrente do loop de construção AFK (implement) review.md # as constatações do QA AFK (review) — sua leitura final
Você inicia o fluxo a partir da ideia bruta e então sai do caminho. Os artefatos acima são suas janelas para dentro: abra o PRD.md para conferir se a spec corresponde à sua intenção, percorra issues/ e o quadro para ver o fatiamento, leia o GOAL.md para confirmar que a linha de chegada é a que você queria, e acompanhe LOOP-LOG.md e review.md para observar a construção e seu QA sem tocar em nenhum dos dois.
Se o grill precisar de um fato do mundo durante o research, esse fato vem de uma fonte confiável — o Bright Data CLI (brightdata search "…"), nunca um palpite e nunca WebSearch/WebFetch. O único lugar em que o Forge para por você é uma bifurcação genuinamente só-sua; todo o resto ele se autorresponde e registra.
Vamos rodar uma única ideia bruta pelo Forge de ponta a ponta: "um pequeno app web para acompanhar os livros que estou lendo." Veja um desejo vago virar um contrato, e então uma coisa construída-e-provada — com você lendo junto, nunca conduzindo.
Ele coloca as perguntas difíceis e responde a maioria a partir da razão: "Acompanhar o quê — título, progresso, nota? Os três. Multiusuário? Não, single-user v1. Fora de escopo? Recursos sociais." Uma pergunta é uma bifurcação verdadeira — "guardar os dados localmente ou na nuvem?" — então ele escala essa para você e espera. Você responde "local por enquanto." Essa é a única vez em que ele precisa de você.
Nenhum fato externo para embasar e o formato é óbvio, então ambos os passos opcionais são pulados. O Forge não enche o fluxo com passos que a ideia não justifica.
PRD.md modeloTudo o que foi resolvido vira um PRD curto: problema, escopo single-user, os três campos acompanhados, armazenamento local, social explicitamente fora. Você o lê e confirma que corresponde ao que imaginou. Primeiro artefato durável, aprovado.
Cinco tickets aparecem: #1 scaffold → #2 data model → #3 add/list books → #4 progress + rating → #5 local persistence, cada um bloqueando o próximo. O GOAL.md registra o done-when: "consegue adicionar um livro, definir progresso e nota, os dados sobrevivem ao reload; suíte verde." Agora o loop tem um alvo.
O loop roda sem supervisão, ticket por ticket. Para o #3, o Executor escreve o código de add/list; o Validador — um ator diferente — de fato adiciona um livro e o lista de volta para prová-lo no limite real, não afirmando sucesso. Você o vê avançar no LOOP-LOG.md.
review.md agentes · AFKQuando o quadro está verde e o done-when do GOAL.md é atendido, um passe final de qualidade roda por conta própria e escreve suas constatações no review.md. Você lê esse relatório — e essa é a execução. Você entregou uma frase e uma decisão de bifurcação; todo o resto foi observado.
O que o Forge produziu
Uma frase virou um PRD aprovado, um quadro com bloqueio, um GOAL.md mensurável, um app construído e provado ticket a ticket, e um review.md para ler — com exatamente uma decisão humana na execução inteira. Esse é o acordo: você traz a ideia e seu julgamento sobre as bifurcações verdadeiras; a máquina traz a disciplina e as mãos.
Cada passo deixa uma linha que você pode ler depois do fato — a observabilidade na qual a suíte inteira roda (você a conhecerá por completo na lição 5). A construção nunca afirma sucesso; o Validador o prova.
# FORGE — "book tracker" grill # autorrespondeu 6 perguntas; escalou 1 bifurcação (storage) → humano: local research # pulado — nenhum fato externo necessário prototype # pulado — formato está claro to-prd # → PRD.md (single-user, 3 campos, social fora) to-issues # → #1..#5 com arestas de bloqueio /goal # → GOAL.md done-when (add/track/persist; suíte verde) implement # Executor constrói #1..#5; Validador prova cada um no limite review # → review.md (humano lê; execução completa)
Recordar vence reler. Responda cada uma de memória antes de espiar — a opção que você escolhe é corrigida na hora, com uma nota do porquê. As respostas estão espalhadas de propósito.
Q1Quando você deveria recorrer ao Forge em vez de ir direto para o loop?
Q2Durante o grill, o que o modelo faz com a maioria de suas perguntas difíceis?
Q3No passo implement, por que o Executor e o Validador nunca são o mesmo ator?
Q4O que as relações de bloqueio no quadro de issues de fato impõem?
Q5Ao longo de uma execução do Forge, qual é o papel do humano?
GOAL.md fica para a sua ideia? Pergunte. A seguir — agora que o contrato existe e a construção roda sem supervisão — vem como você observa uma execução sem nunca pisar em seu caminho: AFK + observabilidade: nunca no caminho.