O loop central precisa de um done-when mensurável antes de poder rodar. Mas a maior parte do trabalho real começa como uma frase vaga — "deixa eu adicionar alertas de busca salva." O Forge é o front-end opcional que endurece essa frase em um escopo mensurável e então conduz a construção inteira, AFK. Sete passos: grill → research → prototype → PRD → issues → implement → review. Depois ele converge no curso que você está lendo agora mesmo.
Você já aprendeu o loop: learn → analyze → executar uma unidade delimitada → verificar no boundary real → decidir. O loop é um motor brilhante. Mas um motor precisa de combustível do tipo certo. O combustível do loop é um done-when mensurável — uma linha de chegada que uma máquina consegue checar. Dê a ele "fazer alertas" e ele não tem linha de chegada, então nunca consegue parar. Dê a ele "um usuário consegue salvar uma busca, e em até 60 segundos após um novo match um e-mail chega, comprovado contra uma caixa de entrada ao vivo" e o loop sabe o exato momento em que está concluído.
A maioria das tarefas não chega com essa linha de chegada anexada. Elas chegam como uma ideia crua. O Forge é o front-end que transforma a ideia crua na linha de chegada — e depois segue adiante, até o entregue, sem você tocar no teclado. Ele é opcional: se o seu escopo já está nítido, você pula o Forge e vai direto para o loop. Se está difuso — o que é a maior parte das vezes — você roda o Forge primeiro.
O Forge tem sete passos, e vamos dar a cada um seu próprio momento nesta lição:
1. Grill — fazer a ideia debater consigo mesma até o escopo ficar afiado. 2. Research (opcional) — cachear a exploração difícil em uma nota durável. 3. Prototype (opcional) — código descartável para evidência real. 4. PRD — escrever o destino. 5. Issues — quebrar em tickets ordenados por dependência e compilar o GOAL.md, o contrato da run. 6. Implement — um Executor constrói cada ticket, um Validator independente o comprova. 7. Review — o QA AFK escreve um relatório de observabilidade que você lê.
Duas ideias sustentam o todo, e vale dizê-las uma vez, com clareza, antes de irmos adiante. Primeira: tudo roda AFK — away from keyboard, longe do teclado. Seu único trabalho é observabilidade: você lê o que aconteceu, você não executa nada. Segunda: o passo que transforma a saída do grill em um contrato é o GOAL.md, e o done-when mensurável desse contrato é a condição de saída do loop. O Forge se recusa até a compilar o GOAL.md enquanto o done-when não for algo que uma máquina possa checar.
Pense nisso como… a forja de um ferreiro. Você traz um pedaço de ferro bruto — sua ideia crua. Você não martela ele frio; você aquece, dobra, testa o fio, reaquece, dobra de novo. Cada dobra é um passo. O que sai do outro lado é uma lâmina acabada com um fio testado — sua feature entregue com um done-when comprovado. Onde a analogia quebra: um ferreiro de verdade martela com as próprias mãos; aqui o ferreiro é uma equipe de agentes e você só assiste às faíscas (lê os logs).
O Forge é um front-end e harness aditivos acoplados ao loop do loop-engineering. Ele não substitui nada na skill central — ele a alimenta. Seus métodos componentes vêm empacotados de forma self-contained sob forge/ para que o loop nunca dependa de uma skill externa estar instalada; cada arquivo de método se chama METHOD.md (não SKILL.md) para que nenhum skill-loader os registre como skills de topo duplicadas.
Os sete passos mapeiam nos cinco verbos do loop: grill = LEARN + ANALYZE; research = LEARN; prototype = o Proof Gate aplicado cedo; PRD = ANALYZE; issues = ANALYZE (decompor) + compilar o contrato; implement = EXECUTE + VERIFY + DECIDE, em loop; review = VERIFY, AFK. O oitavo momento, converge, é o inalterado Course Gate da skill central: entregar o resultado mais um curso visual-teach completo.
Vamos costurar uma ideia concreta por cada passo: a feature de "alertas de busca salva" do app Atlas. A frase crua — "deixar os usuários serem notificados sobre novos matches" — é exatamente o tipo de pedido vago que o Forge existe para endurecer. Ao final, você terá assistido ela virar um done-when mensurável, um quadro de tickets ordenado por dependência, uma build comprovada e um relatório de review.
O Forge apenas ACRESCENTA um caminho para dentro do loop existente. Ele não muda nada no loop central, nos gates ou no protocolo de grill — ele os reaproveita. O tier de autorização destrutivo / voltado para fora permanece user-gated. O entregável continua sendo resultado + curso.
A objeção óbvia: por que não simplesmente apontar o agente para a ideia e deixar rodar? Porque um agente sem linha de chegada se comporta exatamente como uma pessoa sem linha de chegada — ele divaga, faz polimento excessivo, declara vitória sobre a coisa errada, ou roda para sempre. O custo de um começo vago não é pago lá no início; ele é pago depois, multiplicado, em retrabalho. Um front-end paga um custo pequeno e delimitado agora para evitar um custo grande e ilimitado depois.
Abaixo está um mergulho profundo na ideia, no formato de um explicador de feature de verdade: uma lista de conteúdos, uma simulação interativa que você pode rodar, o contrato em três visões (a ideia crua, o escopo endurecido, o GOAL.md compilado) e um FAQ com as perguntas que as pessoas de fato fazem. Rode a simulação — envie runs no modo "mergulhar de cabeça" contra runs no modo "front-end primeiro" e observe o contador de trabalho desperdiçado.
Mergulho na feature · Por que endurecer o escopo antes de construir
Uma quantidade delimitada de raciocínio no início (o grill e um contrato) converte uma build em aberto em uma de forma fechada. Forma fechada significa que o loop tem uma saída; em aberto significa que não tem. O front-end é barato; um loop sem saída não é.
Mergulhar de cabeça parece mais rápido nos primeiros dez minutos e é mais lento nas dez horas seguintes. O agente redescobre as mesmas ambiguidades vez após vez, constrói coisas que ninguém pediu e — pior — não sabe dizer quando está pronto, porque nada lhe disse o que pronto significa.
Cada clique é uma unidade de trabalho. No modo mergulhar não há contrato, então um terço do trabalho cai fora do escopo e precisa ser refeito. No modo forjar o contrato pega o desvio antes que ele custe qualquer coisa. Observe o contador de trabalho desperdiçado.
done-when quase tudo é entregue.A mesma feature em três níveis de zoom: a ideia crua de onde o Forge parte, o escopo endurecido em que o grill converge e o GOAL.md compilado — o contrato da run, checável por máquina, cujo done-when é a saída do loop.
# o que você digitou "Deixar os usuários serem notificados sobre novos matches de uma busca salva." # sem resposta possível do jeito que está escrito: # notificados como? e-mail? push? in-app? # quão recente é 'novo'? minutos? horas? # o que prova que funciona — e onde?
Meta um usuário salva uma busca; novos matches disparam um e-mail. Canal só e-mail no v1 (push adiado — ver research.md). Recente "novo" = deu match desde o último alerta; entregue < 60s. Escopo salvar/listar/excluir uma busca; um matcher; um mailer. Fora digests, push, dedup por resultado além de 24h. Prova sandbox SMTP ao vivo recebe o e-mail em até 60s.
<goal> Alertas de busca salva entregues no Atlas, canal e-mail. <context> repo=atlas; matcher reaproveita o serviço de search/index. <constraints> sem quebra de schema; reaproveitar o mailer existente. <verification> rodar o e2e: salvar uma busca, inserir uma linha que dá match, conferir que um e-mail chega no sandbox SMTP. <done-when> e2e sai 0; e-mail recebido < 60s; 0 diffs de schema.
Encontre você mesmo: grep -rn "done-when" forge/ GOAL.md
done-when tem um retorno enorme.done-when mensurável e uma mudança delimitada. Aí você pula direto para o loop central na skill principal. O Forge é para o caso comum em que o prompt é uma ideia crua, ainda não uma linha de chegada. Pular os passos opcionais (research, prototype) também tudo bem quando o escopo é familiar.brightdata — search, scrape ou uma sessão de browser ao vivo. Nunca WebSearch/WebFetch e nunca o MCP do Bright Data. Quando o grill ou um prototype precisa de um fato atual (o rate limit de uma API, a API atual de uma biblioteca), ele puxa evidência real em vez de adivinhar da memória.Seja p a probabilidade de uma unidade de trabalho estar fora do escopo. Mergulhar de cabeça paga aproximadamente 1/(1−p) unidades de esforço por unidade entregue — cada unidade fora do escopo é construída, descoberta e reconstruída. O contrato converte a maior parte desse p em uma checagem de gate barata antes da construção, então o multiplicador colapsa em direção a 1. A simulação acima usa p ≈ 1/3, uma estimativa conservadora para pedidos genuinamente vagos.
O passo /goal do Forge se recusa a compilar o GOAL.md enquanto o done-when não nomear (1) uma métrica ou artefato observável, (2) uma comparação ou limiar e (3) o boundary onde ele é checado. "Os alertas funcionam" falha nos três; "o e2e sai 0 e o e-mail chega no sandbox SMTP em até 60s, com 0 diffs de schema" passa nos três. Essa recusa é a propriedade de segurança mais importante do front-end.
Antes de percorrermos cada passo, aqui está todo o pipeline de relance. Leia da esquerda para a direita: uma ideia crua entra no Setup, roda o grill, opcionalmente desvia por research e prototype, vira um PRD, depois um quadro de issues mais um GOAL.md, depois o loop de build AFK, depois o review AFK — e por fim converge no curso. As duas caixas desenhadas com bordas tracejadas são os passos opcionais; a seta curva embaixo mostra que você pode voltar para o grill, o research ou o prototype em qualquer passagem, não só no início.
A forma a guardar: uma ordem padrão, não fases rígidas. Research e Prototype são opcionais. Um escopo nítido e familiar os pula e vai direto do grill ao PRD. E no momento em que qualquer passo bate num desconhecido que precisa de evidência real, você pode voltar para o grill, o research ou o prototype — é isso que o loop de feedback significa.
Agora os mesmos sete passos como um slideshow — uma ideia grande por slide, para você absorver a forma antes do detalhe. Clique em Próximo, toque num ponto, ou use as setas esquerda / direita. Voltamos a cada passo em profundidade logo depois.
O slideshow lhe deu a forma; agora sinta o movimento. Escolha uma situação de partida, depois aperte Próximo para conduzir a ideia de alertas de busca salva pelo Forge, um passo de cada vez. Cada caminho mostra uma escolha real: uma ideia nova roda o pipeline inteiro; um escopo já nítido pula os passos opcionais; e um desconhecido no meio da build volta para o grill. Observe quais caixas acendem — e quais são puladas.
Comece aqui
Escolha uma run, depois aperte Próximo
A run ideia nova percorre o pipeline inteiro. Troque o chip acima para ver como um escopo nítido pula os passos opcionais, ou como um desconhecido no meio da build volta para o grill.
O fluxograma é um esboço literal da orquestração. O grill é um parallel() de chamadas agent() de perspectiva; research e prototype são folds condicionais de volta ao documento de escopo; PRD → GOAL → issues é um pipeline() curto; implement é um pipeline(ordered(issues), build, validate); review é um agent() final que emite review.md. Os losangos "escopo nítido?" e "bateu num desconhecido?" são ramos reais nesse script, não decoração.
A seta tracejada cor de barro — de um desconhecido no meio da build de volta ao grill — é a diferença entre um plano frágil de uma tacada só e um robusto. Quando o Implement bate em algo que o plano não previu (uma API se comporta diferente do assumido), a jogada certa não é chutar; é re-grill, opcionalmente research ou prototype para evidência real, dobrar isso de volta e continuar. Os passos opcionais são ferramentas alcançáveis em qualquer passagem, não gates que você passa uma vez.
Dois dos sete passos são opcionais: Research e Prototype. Eles não são passos menores — são ferramentas poderosas que você usa quando a situação pede, e pula quando não. A pergunta que decide é simples: este desconhecido precisa de um parágrafo de fatos, ou de um artefato de evidência rodando?
Se o desconhecido é "como é de fato a API desta biblioteca, qual o rate limit real daquele serviço" — isso é research: cacheie os fatos uma vez em research.md (fatos da web via CLI brightdata) para nunca reexplorar. Se o desconhecido é "essa abordagem vai funcionar, como isso se comporta" — isso precisa de prototype: código descartável que produz evidência real, deixando assets reaproveitáveis para trás. E se o escopo já é familiar, você pula os dois.
forge/research/METHOD.md existe para cachear uma fase de "explorar" difícil uma vez num research.md durável, para que a mesma API ou domínio desconhecido nunca seja reexplorado numa passagem posterior. Seus fatos precisam ser reais e atuais — puxados com a CLI brightdata (search / scrape / browser ao vivo), nunca inventados da memória paramétrica e nunca via WebSearch/WebFetch ou o MCP do Bright Data. Pule quando o escopo é familiar, ou quando o desconhecido precisa de um artefato rodando (→ Prototype).
forge/prototype/METHOD.md é o Proof Gate aplicado cedo: resolver uma ideia em código descartável para obter evidência real de um desconhecido antes de se comprometer com ela. O código é descartável, mas deixa duas coisas duráveis — a evidência, que dobra de volta no grill, e assets reaproveitáveis, que podem seguir para a implementação. É uma ferramenta, não uma fase: recorra a ela em qualquer passagem.
Esta é a regra que vale memorizar: grill, research e prototype podem ser alcançados em qualquer passagem — inclusive no meio do Implement — sempre que o loop bate num desconhecido que precisa de evidência real, não só no início. A ordem padrão é uma conveniência, não uma jaula.
O grill é onde uma ideia crua vira um escopo afiado. O truque é que ele faz isso sem lhe fazer uma única pergunta. Em vez de entrevistar o humano, o Orchestrator gera vários sub-agentes de perspectiva — um que empurra por valor para o usuário, um que checa viabilidade, um que caça risco, um que defende a coisa mais simples que poderia funcionar e um que sonda a entrada mais difícil. Eles perguntam e respondem uns aos outros, ancorados nos docs que você nomeou, e seguem até convergir em algo pronto para decisão.
No nosso exemplo recorrente, a ideia crua é "deixar os usuários serem notificados sobre novos matches." O grill transforma isso em: só e-mail no v1; "novo" significa que deu match desde o último alerta; entregue em até 60 segundos; salvar / listar / excluir uma busca salva; um matcher; um mailer; digests e push estão explicitamente de fora. Isso é um escopo contra o qual uma máquina consegue construir.
Pense nisso como… uma reunião de pauta numa redação antes de uma matéria ir ao ar. Ninguém publica o primeiro pitch. O repórter, o cético, o advogado e o editor empurram cada um pelo seu ângulo até o que sobra ficar afiado e defensável. Onde a analogia quebra: a reunião tem pessoas; o grill tem agentes debatendo entre si, e só uma bifurcação genuinamente author-only chega a escalar até você.
O trabalho do grill é convergência, não exaustão. Ele para quando o escopo está pronto para decisão — afiado o bastante para construir — não quando toda pergunta possível foi feita. Grelhar demais é seu próprio anti-padrão.
O método vive em forge/grill-with-docs/METHOD.md (com ADR-FORMAT.md e CONTEXT-FORMAT.md ao lado). Ele roda a entrevista do grill AFK: em vez de entrevistar o usuário, o Orchestrator gera N sub-agentes de perspectiva que PERGUNTAM e RESPONDEM o grill entre si, ancorados nos docs nomeados, até convergir. As perspectivas clássicas são valor-para-o-usuário, viabilidade, risco, coisa-mais-simples e entrada-mais-difícil.
Só uma bifurcação author-only genuína escala — uma decisão irreversível, voltada para fora, ou de intenção de negócio que a máquina não tem autoridade para tomar. Ela é escalada via forge/handoff como um pacote pronto para decisão com uma recomendação, nunca como uma pergunta em aberto. Todo o resto o grill resolve sozinho.
# spawn perspectives that ask + answer among themselves const answers = await parallel(PERSPECTIVES.map(p => () => agent(grillPrompt(p, scope), { schema: QA }))) let scopeDoc = synthesizeScope(answers) # converge → sharp scope
Às vezes a build vai esbarrar de cabeça em território que ninguém na equipe conhece bem: uma API desconhecida, uma biblioteca que você nunca usou, um domínio com regras próprias, um codebase grande, ou prior art que vale estudar. Explorar isso durante a build é caro — você reexploraria toda vez que voltasse. O research cacheia essa exploração uma vez, numa nota durável chamada research.md, para que o conhecimento fique escrito e seja reaproveitado.
Para os alertas de busca salva, a pergunta de research poderia ser: o nosso mailer existente suporta os headers de que precisamos, e qual é o orçamento real de queries do serviço de search? Esses são fatos — e fatos vêm da CLI brightdata (busca na web, scraping de uma página de doc, ou uma sessão de browser ao vivo), nunca de um chute. As respostas caem no research.md e o grill as dobra de volta.
Pense nisso como… ler o mapa da trilha e checar o tempo antes de uma caminhada, e então anotar os fatos-chave num cartão que você guarda no bolso. Você não rechecar a previsão a cada bifurcação — você cacheou uma vez. Onde a analogia quebra: um mapa de trilha é estático; o research.md é vivo, e você acrescenta a ele sempre que um novo desconhecido se revela com forma de fato.
forge/research/METHOD.md transforma uma fase de explorar difícil num artefato durável para que seja pago uma vez só. A regra é estrita quanto à proveniência: todo fato externo é puxado com a CLI brightdata — brightdata search "<query>", brightdata scrape <url>, ou uma sessão de browser ao vivo — e nunca via WebSearch/WebFetch ou o MCP do Bright Data. Uma afirmação sem fonte real é um chute, e chutes não entram no research.md.
Pule o Research quando o escopo é familiar (você já conhece as APIs e o domínio), ou quando o desconhecido não pode ser resolvido por fatos e precisa de um artefato rodando — esse é o trabalho do Prototype. O Research responde "o que é verdade"; o Prototype responde "vai funcionar".
como o research dobra de volta no escopoif (needsResearch(scopeDoc)) scopeDoc = fold(scopeDoc, await agent(researchPrompt(scopeDoc))) # web facts via brightdata → research.md
Algumas perguntas não podem ser respondidas lendo — só construindo. Esse matcher vai mesmo disparar na linha que eu espero? Um e-mail realmente chega, de ponta a ponta? Para essas, você escreve um programinha descartável que produz evidência real. O código em si é descartável; o que você guarda é a evidência (que dobra de volta no grill) e quaisquer assets reaproveitáveis (que seguem para a build de verdade).
O Prototype é o Proof Gate aplicado cedo: em vez de assumir que uma abordagem funciona e descobrir o contrário após uma build inteira, você comprova a parte arriscada numa tarde. Para os alertas de busca salva, um prototype poderia ligar um resultado de busca falso direto no mailer e confirmar que uma mensagem cai num sandbox SMTP local — prova, antes de uma única linha de produção ser escrita.
Pense nisso como… um chef provando o molho com uma colher antes de empratar o prato inteiro. A colherada é jogada fora, mas ela lhe disse que o tempero está certo. Onde a analogia quebra: a colherada some; um prototype pode deixar pedaços reaproveitáveis — um config, uma fixture, um helper — que sobrevivem até a cozinha.
O Prototype é uma ferramenta, não uma fase. Você pode recorrer a ele em qualquer passagem — inclusive no meio do Implement — no momento em que um desconhecido precisa de um artefato rodando em vez de um parágrafo. Realimente a evidência no grill e continue.
forge/prototype/METHOD.md (com LOGIC.md e UI.md) resolve uma ideia em código para feedback cedo e para obter evidência REAL de um desconhecido. Duas saídas sobrevivem ao código descartável: a evidência (dobrada de volta no grill / escopo) e assets reaproveitáveis que mais tarde podem ser reusados na implementação. Aplicar o Proof Gate aqui — no desconhecido mais arriscado, cedo — é muito mais barato do que descobrir que a abordagem estava errada após uma build inteira.
for (const u of unknowns(scopeDoc)) scopeDoc = fold(scopeDoc, await agent(prototypePrompt(u))) # real evidence, not a guess
A esta altura o escopo está afiado e quaisquer desconhecidos estão resolvidos. O PRD escreve tudo isso como o destino: o que a feature é, para quem é, as user stories e as notas de implementação. É o "o quê e por quê" contra o qual o resto da run é medido — mais amplo que o escopo de um único loop, mas não um romance; um documento enxuto, não um paredão.
Uma forma útil de ler um PRD é como um plano por fases que você pode clicar e percorrer. Abaixo, o trabalho de alertas de busca salva está disposto em quatro fases — cada uma com sua meta, suas tarefas, seus riscos e a barra de saída que a deixa avançar. Clique num marco no topo (ou foque a barra e use as setas) para abrir o card da fase. Note que cada fase só avança quando cumpre uma barra de saída mensurável — a mesma disciplina do done-when do loop, aplicada no nível do plano.
Meta: um usuário consegue salvar, listar e excluir uma busca. O armazenamento e a API existem antes de qualquer coisa tentar dar match contra eles.
saved_search (migração aditiva, sem quebra)Meta: quando aparece uma nova linha que dá match numa busca salva, produzir um evento de "novo match" — reaproveitando o serviço de search/index existente, não um segundo matcher.
last_alerted_at por busca salvamatch.new para o mailer consumirMeta: um evento match.new vira um e-mail através do mailer existente — sem novo stack de e-mail.
match.new produz uma mensagem bem formadaMeta: o próprio done-when — um teste de ponta a ponta automatizado que comprova a cadeia inteira no boundary real, a condição de saída do loop.
forge/to-prd/METHOD.md emite o escopo endurecido como um PRD descrevendo o destino, com user stories e notas de implementação. Na escala de zoom que você viu na lição 2 — PRD → SCOPE.md → GOAL.md — o PRD é o mais amplo: o porquê e o quê da feature inteira. Ele enquadra o trabalho; por si só não dá ao loop uma saída. A saída vem do GOAL.md (próximo passo), cujo done-when a barra de saída de cada fase prenuncia.
Todo card de fase carrega uma barra de saída — um gate mensurável, não um clima. "A Fase 2 foi bem" não é um gate; "inserir uma linha que dá match emite exatamente um evento e um match já alertado não dispara de novo" é. O plano se mantém honesto sob pressão porque uma fase não pode avançar até suas caixas estarem marcadas — a mesma propriedade que o done-when do loop dá a um único ciclo.
Um PRD descreve o destino, mas um agente não constrói "um destino" — ele constrói um ticket delimitado de cada vez. Então o Forge transforma o PRD em tickets individuais, cada um uma unidade pequena e bem especificada. A parte crucial: os tickets carregam relações de bloqueio. Você não consegue enviar o e-mail antes de conseguir dar match numa linha; não consegue dar match numa linha antes de uma busca estar armazenada. Essas dependências fazem do quadro um kanban ordenado por dependência — o trabalho flui na única ordem que pode de fato dar certo.
Ao lado dos tickets, o Forge compila o GOAL.md — o contrato da run autônoma. Seu done-when mensurável é a condição de saída do loop, e ele serve também de barra de aceitação de cada ticket. E aqui está o guard-rail que torna tudo isso confiável: o Forge se recusa a compilar o GOAL.md enquanto o done-when não for mensurável. Sem linha de chegada mensurável, sem run.
Abaixo está esse quadro, ao vivo. Um card com dependências inacabadas está bloqueado — hachurado e travado; você literalmente não consegue avançá-lo até que aquilo de que ele depende esteja pronto. Resolva seus bloqueadores e ele destrava. Tente mover F (a prova de ponta a ponta) antes de suas dependências estarem prontas e o quadro não deixa — é a relação de bloqueio impondo a única ordem segura. Mova os cards com a seta, ou arraste-os, e veja as contagens e os cadeados se atualizarem.
forge/to-issues/METHOD.md transforma o PRD e o GOAL em tickets individuais com relações de bloqueio — um kanban ordenado por dependência — onde cada ticket é um Unit Contract delimitado (a mesma unidade que o passo EXECUTE do loop central constrói). As arestas de bloqueio não são cosméticas: elas são a ordem topológica que o loop de Implement precisa respeitar, para que um ticket nunca seja tentado antes de o trabalho de que ele depende existir.
forge/forge-goal/METHOD.md compila o GOAL.md com cinco blocos XML: <goal>, <context>, <constraints>, <verification> e <done-when>. Ele segue a disciplina ultragoal — encaixe da meta → loop com um verificador Proof-Gate → gates anti-trapaça / de aprovação → red-team → ativar — que você verá por completo na lição 10. A regra dura: ele se recusa a compilar enquanto o done-when não for mensurável. Essa única recusa é o que garante que o loop a jusante sempre tenha uma saída.
const prd = await agent(toPrdPrompt(scopeDoc), { schema: PRD }) const goal = await agent(goalPrompt(prd), { schema: GOAL }) # refuse unless done-when measurable const issues = await agent(toIssuesPrompt(prd, goal),{ schema: ISSUES }) # tickets + blocking edges
É aqui que o Forge entrega o volante ao loop central que você já conhece — e nunca o pega de volta até o trabalho estar pronto. Num loop, um agente de código trabalha o kanban em ordem de bloqueio. Para cada ticket, um Executor o constrói, e então um Validator independente comprova o resultado contra o GOAL.md no boundary real — o Proof Gate, nunca um claim, nunca um mock. A única regra que torna isso honesto: o Validator nunca é quem construiu. Um agente diferente avalia o trabalho, para que ninguém corrija a própria lição de casa.
Se um ticket continua falhando do mesmo jeito, a equipe corrige a causa raiz — e se o plano ou o prompt é a causa raiz, ela melhora isso e re-roda. Toda passagem é registrada no LOOP-LOG.md, que é um dos arquivos que você lê para observar. O loop continua até todo ticket estar pronto e comprovado.
Esta é a ponte entre este módulo e o loop central que você estudou. O diagrama abaixo mostra exatamente onde cada passo do Forge cai dentro de learn → analyze → execute → verify → decide.
Cross-agent e agnóstico: o Executor e o Validator podem ser qualquer agente — Claude Code, Grok, Kimi, pi, Council, Codex — despachados headless via o cli -p daquele agente. O único invariante é que o Validator seja um agente diferente daquele que construiu.
Implement é EXECUTE + VERIFY + DECIDE, rodado como um loop sobre o kanban em ordem de bloqueio. Um Executor constrói um ticket de cada vez; um Validator independente comprova cada resultado contra o GOAL.md no boundary real (o Proof Gate — nunca um claim/mock; o Validator nunca é quem construiu). Analise cada resultado; se um ticket continua falhando do mesmo jeito, corrija a causa raiz — e se o prompt/plano é a causa raiz, melhore-o e re-rode. Registre as passagens no LOOP-LOG.md. Faça o loop até todo ticket estar pronto e comprovado.
O loop é agnóstico de agente mas roda como um tier: um modelo de topo orquestra e delega unidades delimitadas para executores de tier médio via o cli -p headless (one-shot, não-interativo) de cada agente — do mesmo jeito que os adapters do Council disparam cada CLI. O Validator é sempre um agente diferente daquele que construiu; os tiers de autorização ainda se aplicam por agente (um executor delegado recebe permissão de execute, não destrutiva / voltada para fora).
const results = await pipeline(ordered(issues), i => agent(executePrompt(i)), # Executor: one bounded unit (any agent via cli -p) r => agent(validatePrompt(r, goal), { schema: VERDICT })) # Validator: real-boundary proof; never the builder # loop on any unmet done-when (improve the artifact OR the prompt)
A build está pronta e todo ticket foi comprovado conforme caía. O Review é a varredura final e independente: uma passagem de QA AFK que checa cada user story e done-when contra o boundary real mais uma vez, e escreve o resultado num arquivo chamado review.md. Crucialmente, este é um QA que você lê, não um QA que você executa. A máquina roda as checagens; o review.md é um relatório de observabilidade para você.
Por critério, o relatório diz: o que foi construído, o resultado da verificação e um ponteiro para a evidência. Ele também lista lacunas residuais e um conjunto "sinalizado para ciência" — os julgamentos de gosto, UX e produto que uma máquina não consegue fazer e quer que um humano fique ciente. Você observa; o loop nunca bloqueia em você. (A única exceção, como sempre, é uma bifurcação genuinamente author-only, que é escalada como um handoff pronto para decisão — nunca como review de rotina.)
Pense nisso como… o relatório pós-pouso de um voo esperando na sua caixa de entrada. A aeronave já pousou em segurança; o relatório lhe diz como foi o voo, o que observar da próxima vez, e qualquer coisa que precise da decisão de um humano. Você o lê — não lhe pediram para pilotar o avião. Onde a analogia quebra: um relatório de voo é estático; o review.md aponta para evidência ao vivo que você pode re-rodar.
O único papel do humano ao longo dos sete passos é observabilidade. Você lê o LOOP-LOG.md, o review.md e o status da run. Você nunca executa nada — nem mesmo o QA. O loop bloqueia em você apenas por uma bifurcação genuinamente author-only, via um handoff pronto para decisão.
forge/review/METHOD.md roda o QA AFK: o Validator independente (mais um agente de QA, se útil) checa cada user story / done-when contra o boundary real (Proof Gate) e emite o review.md — por critério: o que foi construído, o resultado da verificação, o ponteiro para a evidência; mais lacunas residuais e uma lista sinalizada para ciência (gosto / UX / produto que a máquina não consegue julgar). O humano apenas observa; o loop nunca bloqueia nele.
forge/handoff/METHOD.md empacota um handoff pronto para decisão quando — e somente quando — uma bifurcação genuinamente author-only aparece (irreversível, voltada para fora, ou de intenção de negócio). Ele carrega uma recomendação, não uma pergunta em aberto. Esta é a única circunstância em que o loop AFK pausa por um humano, e ela nunca é disparada por review ou QA de rotina.
const review = await agent(reviewPrompt(prd, goal, results)) # → review.md, an observability report the human READS # then CONVERGE → deliver result + a full visual-teach course
Já que seu único trabalho é observar, ajuda ver exatamente como isso se parece. Este é um painel de status ao vivo de uma run do Forge — a build de alertas de busca salva. Quatro números de destaque no topo (passos concluídos, tickets comprovados, trabalho desperdiçado, recência contra o orçamento de 60s), depois uma linha por passo com seu estado e o ponteiro de evidência que você abriria para verificar. Aperte Atualizar para uma nova leitura, ou ligue o Ao vivo para acompanhar a run progredir — do jeito que você daria uma olhada enquanto ela roda AFK.
Run do Forge — alertas de busca salva do Atlas
AFK · você observa · contrato = done-when do GOAL.md
| Passo do Forge | Estado | Passou | Evidência que você pode abrir |
|---|
Observabilidade não é uma metáfora aqui — é toda a interface do humano com uma run AFK. Os artefatos são arquivos reais: LOOP-LOG.md (toda passagem e seu resultado), review.md (o relatório final de QA) e o status da run (o tipo de quadro acima). Você lê esses. Você não roda a build, não roda o validator e não executa o QA. As linhas "Pulado (opcional)" são Research e Prototype quando o escopo era familiar o bastante para não precisar deles.
O bloco de trabalho desperdiçado é toda a tese do front-end transformada num número. Porque o grill produziu um escopo mensurável e o Validator faz o gate de cada ticket no boundary real, o trabalho fora do escopo é pego antes de acumular. Uma run que se mantém em zero unidades desperdiçadas é uma run cujo contrato está fazendo seu trabalho.
O Forge não termina em "funciona". O último compasso é converge: entregar o resultado pronto e um curso visual-teach completo — como o que você está lendo. Este é o inalterado Course Gate da skill central. O ponto é que o conhecimento construído durante uma run não deveria evaporar quando a run acaba; ele é destilado em algo de que uma pessoa pode aprender depois.
Então o arco completo, de ponta a ponta, é: Setup → Grill → (Research) → (Prototype) → PRD → Issues + GOAL.md → Implement → Review → Converge. Uma frase crua entrou; uma feature comprovada e um curso ensinável saíram — e você apenas observou o tempo todo.
Tudo nesta lição é real e empacotado. Os métodos do Forge vivem self-contained sob forge/, cada um como um METHOD.md em nossas próprias palavras, para que o loop nunca dependa de uma skill externa. Aqui está o mapa, e como abri-lo você mesmo.
# the seven methods, self-contained under forge/ forge/grill-with-docs/METHOD.md # 1 · grill (+ ADR-FORMAT.md, CONTEXT-FORMAT.md) forge/research/METHOD.md # 2 · research (optional) → research.md, brightdata facts forge/prototype/METHOD.md # 3 · prototype (optional) (+ LOGIC.md, UI.md) forge/to-prd/METHOD.md # 4 · PRD — destination + user stories forge/forge-goal/METHOD.md # 5 · GOAL.md — refuse unless done-when measurable forge/to-issues/METHOD.md # 5 · tickets + blocking relationships (kanban) forge/review/METHOD.md # 7 · AFK QA → review.md (observability) forge/handoff/METHOD.md # the user-only-fork escape hatch (decision-ready)
# read the front-end overview cat ~/.claude/skills/loop-engineering/forge-flow.md # list the bundled methods ls ~/.claude/skills/loop-engineering/forge/*/METHOD.md # find the measurable-done-when guardrail grep -rn "done-when" ~/.claude/skills/loop-engineering/forge/
A equipe mapeia diretamente na ferramenta Workflow: o Orchestrator é o script; o grill de autodebate e as passagens de Executor / Validator são parallel() / pipeline() de chamadas agent(). O Forge só invoca a ferramenta Workflow quando o usuário optou pela orquestração multi-agente — invocar este fluxo é esse opt-in.
Uma precisão que vale manter clara para a lição 10: ultragoal é a disciplina de meta durável por trás do /goal, e ela é agnóstica de agente / CLI / modelo. Ativação universal é simplesmente uma run de GOAL.md durável sob o loop; o comando nativo "create goal" de uma ferramenta é um exemplo opcional de ativação, nunca um requisito.
Lembrar vence reler. Responda de memória antes de espiar — cada pergunta corrige no clique, e o feedback nomeia a ideia para você reforçar qualquer coisa confusa.
1. Qual é a única coisa sem a qual o passo /goal do Forge se recusa a compilar?
2. Research e Prototype são melhor descritos como:
3. No loop de Implement, quem comprova um ticket contra o GOAL.md?
4. O que faz do quadro de issues um kanban ordenado por dependência?
5. Durante uma run do Forge, o papel do humano é:
6. De onde vêm os fatos da web durante grill, research ou verify?
GOAL.md real compilado de uma frase, ou tracear como um desconhecido no meio da build reentra no grill? Peça, e faremos no seu exemplo. A seguir, a lição 9 dá um zoom na equipe que faz o Implement funcionar: o Orchestrator, o Executor e o Validator — e exatamente como a observabilidade mantém você fora do caminho de execução.