O Forge transforma uma ideia crua em trabalho entregue. A lição 8 percorreu seus sete passos. Esta lição é sobre quem faz o trabalho uma vez que o contrato existe — e a única regra que define todo o método: tudo roda away-from-keyboard (AFK), e o único papel do humano é observar. Você vai conhecer a equipe de três agentes, ver como um modelo de topo passa uma unidade para qualquer outro agente por uma linha de comando one-shot, e aprender exatamente quando — e somente quando — o loop pode parar e perguntar algo a você.
Imagine uma cozinha durante o pico do jantar. Há um chef de cozinha no passe que nunca toca numa panela — ele lê as comandas, decide qual cozinheiro recebe qual prato, e prova cada prato antes de sair. Há os cozinheiros de linha, cada um fazendo um prato de cada vez. E há um segundo provador no passe que confere cada prato pronto — e, crucialmente, esse provador nunca é o cozinheiro que o fez. Você, o dono, está no salão. Você não cozinha. Você não prova. Você lê o quadro na parede que diz o que está no fogo, o que está empratado e o que voltou.
É exatamente esse o formato de uma execução AFK de Loop Engineering. Três tipos de agente fazem todo o trabalho entre si, e você — o humano — está no salão lendo o quadro. Todo o sentido do método é que você nunca executa nada: nem a construção, nem a checagem, nem mesmo a revisão final de qualidade. Você observa. O sistema é construído de modo que observar seja suficiente.
Os três papéis são o Orquestrador (o chef de cozinha no passe), o Executor (um cozinheiro de linha) e o Validador (o segundo provador). Todos são agnósticos de modelo — qualquer um deles pode ser qualquer modelo de IA por trás de qualquer linha de comando. O que nunca muda é a divisão do trabalho: quem decide nunca constrói, quem constrói nunca aprova o próprio trabalho, e o humano nunca pega numa panela.
A frase para guardar: numa execução AFK, toda ação é tomada por um agente. A contribuição inteira do humano é observabilidade — ler o que aconteceu. O loop interrompe você por exatamente um motivo, e vamos nomeá-lo com precisão abaixo.
Pense nisso como… o controle de tráfego aéreo. Os controladores roteiam cada avião, e um conjunto separado de olhos confirma cada pouso — mas os executivos da companhia aérea, lá em cima, nunca tocam num microfone da torre. Eles leem o painel de partidas. Se surge uma decisão genuinamente nova que só um humano com autoridade pode tomar, então um controlador atende o telefone. Até esse momento, o quadro é o trabalho inteiro. Diferente de uma torre de controle real, aqui até o "segundo par de olhos" é outro agente — o humano está um passo mais afastado.
O front-end Forge tem sete passos: grill → research (opcional) → prototype (opcional) → PRD → issues → implement → review. Esta lição dá zoom no passo seis, implement, e nos agentes que conduzem os passos seis e sete. Quando o implement começa, o contrato já existe: um GOAL.md com um done-when mensurável, e um quadro de issues (tickets) com relações BLOCKING explícitas — um kanban. O implement é o loop rodando sobre esse quadro, AFK.
O modelo de execução sobreposto ao loop é multiagente. O único loop interno que você já conhece — LEARN → ANALYZE → EXECUTE uma unidade delimitada → VERIFY no boundary real → DECIDE — não muda. O que muda é que os passos são distribuídos: o Orquestrador é dono de LEARN/ANALYZE/DECIDE e do roteamento; um Executor é dono de EXECUTE para uma unidade; o Validador é dono de VERIFY para essa unidade, no boundary real, e nunca é o agente que produziu o artefato.
"AFK" é a restrição de operação, não um luxo opcional. O sistema é desenhado de modo que nenhum passo exija que o humano aja. O humano lê LOOP-LOG.md, review.md e o status da execução. A única exceção — uma bifurcação genuinamente user-only — é um handoff estruturado, pronto para decisão, coberto na última seção. Todo o resto, incluindo a revisão de QA, é feito por agentes.
Três papéis dividem o trabalho, e cada um carrega uma regra rígida sobre o que ele não deve fazer. As regras são o que mantêm o sistema honesto — não são estilo, são estrutura.
Orquestrador · o plano de controle
Decide e roteia. Nunca constrói.
Captura o escopo, compila o contrato, quebra o trabalho em unidades delimitadas, entrega cada unidade a um Executor e roteia o resultado a um Validador. É dono do plano e do veredito — o "o que vem a seguir" — mas nunca escreve o código ou o documento em si.
Nunca: produz o artefato que ele deveria estar coordenando.
Executor · o construtor
Constrói exatamente uma unidade delimitada.
Recebe um único Contrato de Unidade — um ticket, um done-when, os arquivos que ele pode tocar — e produz o artefato: o código, o documento, a config. Uma unidade de cada vez. Ele não decide o que fazer a seguir e não pode declarar-se correto.
Nunca: aprova o próprio trabalho — esse é o papel do Validador.
Validador · o portão de prova
Prova o resultado no boundary real.
Pega a unidade pronta e o contrato, então roda a checagem de verdade — o teste, o build, a requisição contra a coisa real — e reporta passou ou falhou com evidência. Uma alegação nunca basta; ele precisa produzir prova.
Nunca: é o mesmo agente que construiu a unidade. Construtor ≠ verificador, sempre.
A regra estrutural
Independência não é uma preferência, é a parede de sustentação. Se o Executor pudesse avaliar a si mesmo, "pronto" significaria "o construtor acha que está pronto" — exatamente a falha que todo o loop existe para evitar. O Validador ser um agente diferente é o que transforma "acho que funciona" em "aqui está a prova de que funciona".
Um Executor nunca recebe a meta inteira. Ele recebe um Contrato de Unidade: um id de ticket, a única condição done-when que o fecha, o escopo explícito de arquivos/área que ele pode tocar, e a fatia relevante de contexto. É isso que torna "uma unidade delimitada" aplicável — o Executor não pode divagar, porque seu contrato só descreve um pedaço de trabalho.
Delimitar a unidade também delimita o raio de impacto se o Executor errar, e é o que permite ao Orquestrador rodar vários Executores em paralelo em tickets não bloqueantes sem que colidam. Tickets ligados por uma aresta BLOCKING são serializados; tickets independentes são distribuídos em paralelo.
Um modelo a quem se pede construir e verificar a própria saída é estruturalmente enviesado a declarar sucesso — ele já se comprometeu com uma interpretação da tarefa. Entregar a verificação a um agente novo, que só vê o contrato e o artefato, remove esse viés. O Validador roda a checagem no boundary real (o Proof Gate) e emite evidência, não uma opinião. O Orquestrador então DECIDE com base na evidência.
Esta é a mesma disciplina que você viu na lição VERIFY, agora tornada organizacional: a separação entre "quem construiu" e "quem provou" é imposta usando dois agentes diferentes, não confiando que um agente seja imparcial.
Aqui estão os três papéis como um triângulo. Leia as setas: o Orquestrador atribui trabalho para baixo, a um Executor, e roteia o resultado para o lado, a um Validador; o Validador envia um veredito de volta para cima. A linha tracejada é o único caminho que não existe — um Executor provando o próprio trabalho. Essa seta ausente é todo o desenho.
Um arranjo ingênuo é um cano reto: o modelo constrói, o mesmo modelo confere, o humano aprova. Esse cano tem duas corrupções — o construtor avalia a si mesmo, e o humano está no caminho de execução. O triângulo remove ambas. A verificação é um vértice separado (um agente diferente), e o humano fica totalmente desacoplado, ligado apenas por uma linha somente-leitura. O plano de controle (Orquestrador) é o ápice justamente porque ele nunca deve ser um trabalhador — seu papel é impedir que as duas corrupções voltem a se infiltrar.
cli -pAqui está a parte que torna a equipe cross-agent. O Orquestrador não precisa fazer cada unidade ele mesmo, e os agentes não precisam ser todos o mesmo modelo. Um modelo forte fica no topo e delega cada unidade para baixo, para o agente que for melhor para ela — literalmente rodando a linha de comando desse agente em modo one-shot e lendo o que volta.
"Modo one-shot" significa: você chama o CLI do outro agente com um único prompt, ele faz a unidade, imprime um resultado e encerra. Sem sessão de chat para babá. A maioria dos agentes de código expõe isso como uma flag -p ("print" / prompt) — por exemplo claude -p "…", codex -p "…", kimi -p "…". Esse formato uniforme -p é o fio entre os agentes: o Orquestrador escreve um prompt, envia pela linha e recebe texto de volta. O roster — quais agentes estão de plantão nesta execução — é declarado logo no início, e é agnóstico por padrão: qualquer agente capaz pode ocupar qualquer assento.
Pense nisso como… um chef de cozinha que pode ligar para qualquer cozinha da cidade. "Faça este prato para mim, aqui está a receita e as restrições, mande de volta." Cada cozinha fala o mesmo protocolo de pedido (a chamada -p), então o chef não se importa com qual cozinha o assume. Diferente de um telefonema, o pedido e a resposta são texto puro que o chef registra — então cada repasse fica no histórico.
-p de cada agente — permite ao Orquestrador rotear qualquer unidade para qualquer agente do roster declarado e então ler o texto de volta.A delegação cross-agent é deliberadamente a interface de menor denominador comum: um comando de shell com um prompt que roda até o fim e imprime um resultado. Sem sessão de longa duração, sem protocolo proprietário. É por isso que o roster é agnóstico — qualquer coisa que você possa invocar como tool -p "<prompt>" de um shell pode ser um Executor ou um Validador. Modelos acessíveis apenas por um proxy compatível com OpenAI (por exemplo Minimax via cliproxyapi) ainda apresentam o mesmo formato one-shot.
O roster é declarado de antemão para que a execução seja reprodutível e para que o Orquestrador possa rotear por aptidão: um modelo barato e rápido para unidades de boilerplate, um modelo mais forte para a difícil, e um modelo diferente ainda como Validador, para que a independência valha também entre fornecedores. O Orquestrador captura o prompt de cada chamada e o texto retornado no log da execução, que é o que o humano depois lê.
# o Orquestrador delegando uma unidade, depois um agente DIFERENTE provando-a codex -p "$(cat unit-PRJ-114.contract.md)" > out/PRJ-114.patch claude -p "Validate PRJ-114 against done-when. Run the gate. Report PASS/FAIL + evidence." \ > out/PRJ-114.verdict.md # construtor = codex, validador = claude — nunca o mesmo agente
Agora siga uma única unidade pela equipe. Escolha um desfecho abaixo, então pressione Próximo para acender cada passo: o Orquestrador despacha a unidade, um Executor a constrói, um Validador diferente a prova no boundary real, e o Orquestrador decide. Observe onde uma prova que falha volta para uma reconstrução, e onde uma pergunta genuinamente user-only se desvia para o humano.
Comece aqui
Uma unidade está pronta para despachar
Pressione Próximo para seguir o caminho prova passa. Troque o desfecho acima para ver uma prova que falha voltar para uma reconstrução, ou uma bifurcação user-only chegar ao humano.
O losango é VERIFY no boundary real, executado pelo Validador. DECIDE é o Orquestrador lendo o veredito: passa → fecha a unidade e escolhe a próxima; falha → devolve a unidade a um Executor com a evidência da falha anexada, depois re-prova (a prova é perecível, então é re-executada após qualquer mudança); bifurca → o ramo raro em que o próximo passo exige uma decisão humana, que vira um handoff estruturado. Repare no que não está aqui: um caminho em que o Executor se declara pronto, e um caminho em que o humano roda a checagem.
Saia do zoom de uma unidade para a execução inteira. O quadro abaixo é o kanban de unidades, com quatro colunas: Na fila (esperando, talvez bloqueada por outro ticket), Despachada (um Executor está construindo), Em prova (um Validador está checando no boundary real) e Fechada (a prova passou). Cada cartão mostra o id da unidade, uma etiqueta de quem (qual papel a detém no momento) e o agente atribuído a partir do roster. Pressione a seta de um cartão para avançá-lo uma coluna — ou arraste-o. As contagens no topo permanecem honestas.
Esta é a visão que um humano dá uma olhada para responder "como vai a execução?" — sem tocar numa única unidade. Você está lendo o quadro, exatamente como o método pretende.
Pense nisso como… o trilho de comandas na janela da cozinha. As comandas deslizam para a direita: lançada, cozinhando, empratando, saiu. Uma olhada diz ao dono o quão sobrecarregada está a linha — e o dono ainda assim nunca pega numa panela. Diferente de um trilho de papel, a etiqueta de quem também diz qual estação (qual agente) detém cada comanda agora.
Cada unidade é um objeto com um campo col que só pode ser queued, dispatched, proving ou closed. As colunas na tela não são a fonte da verdade — o array de objetos de unidade é. Mover um cartão apenas muda esse único campo e repinta; o botão de seta e um soltar de arrastar-e-soltar ambos chamam o mesmo moveTo(), então as duas interações nunca podem discordar. Este é o mesmo formato do quadro de issues que o Forge produz, menos a rede.
A etiqueta de quem é derivada da coluna: uma unidade em dispatched é detida por um Executor, uma em proving por um Validador, uma closed foi assinada pelo Orquestrador com base na evidência do Validador. A coluna é o papel — que é exatamente por que o mesmo agente nunca pode ser construtor e verificador da mesma unidade.
function moveTo(id, col) { const u = units.find(x => x.id === id); if (!u || u.col === col) return; u.col = col; // single source of truth render(); // repaint every column from state }
Conduza o ciclo de vida de uma unidade na mão. Pressione um evento e veja o estado destacado mover-se e o painel atualizar. Os botões ficam acinzentados no instante em que um movimento não é permitido a partir de onde você está — porque o ciclo de vida é um conjunto fixo de transições legais. Repare que você nunca pode pular de construída direto para fechada: uma unidade precisa ser provada pelo Validador primeiro. E repare que o único botão que um humano chega a pressionar fica atrás do estado bifurca — em todo o resto, os agentes conduzem.
O nó preenchido de cor argila é onde a unidade está agora. Os nós esmaecidos são inalcançáveis a partir daqui.
Estado atual
QUEUED
A unidade está no quadro, esperando. O Orquestrador vai despachá-la para um Executor.
Transições permitidas
Log da execução (é isto que o humano lê)
Tudo o que o simulador faz é conduzido por esta tabela. Os botões a leem para decidir o que habilitar; pressionar um consulta machine[state][event] e move para lá. O movimento ilegal que você não pode fazer — BUILD → CLOSED — simplesmente não está na tabela, então não pode ser tomado. Essa entrada ausente é a regra "uma unidade precisa ser provada antes de fechar".
const machine = { QUEUED: { dispatch: 'BUILD' }, BUILD: { submit: 'PROVE' }, // Executor → Validador PROVE: { pass: 'CLOSED', fail: 'BUILD', // veredito do portão de prova fork: 'FORK' }, // raro: precisa de um humano FORK: { resolve: 'CLOSED' }, // decisão humana aplicada CLOSED: {} // terminal — provada e pronta };
O log da execução que o simulador imprime é um substituto para o LOOP-LOG.md: cada evento, quem o tomou e o estado resultante. Esse log é a janela do humano para uma execução AFK.
Nem toda capacidade é igualmente segura de entregar a uma equipe autônoma. Por isso a execução declara níveis de autorização — chaves para o que os agentes têm permissão de fazer sem um humano. Crucialmente, algumas capacidades dependem de outras: você não pode deixar um agente fazer push para um remoto até que ele tenha permissão de commitar; você não pode conceder acesso a produção até que o acesso a staging esteja ligado. Ligue um nível mais alto enquanto seu pré-requisito está desligado e o painel avisa que a concessão não vai valer — exatamente como uma feature flag cujo suporte está faltando.
Acione as chaves abaixo. Ligue push-remote enquanto commit-local está desligado e veja o aviso deslizar para dentro. A linha de resumo sempre relê o conjunto de capacidades que estão de fato ativas. O único nível que é especial é user-gated: é a chave explícita de "perguntar a um humano" — o único caminho sancionado para o loop envolver você.
Pense nisso como… chaves num molho, onde algumas portas ficam atrás de outras. A chave do cofre é inútil até que você primeiro tenha permissão de passar pela porta do escritório. Um bom molho de chaves avisa de cara: "esta aqui precisa da chave do escritório primeiro."
Capacidades de fato concedidas
Os níveis são um registro booleano plano; um segundo objeto lista os pré-requisitos de cada nível. Após qualquer alternância, o editor confere cada nível habilitado contra sua lista de requires. Um nível que está ligado mas sem um pré-requisito está insatisfeito — ele desenha o aviso em linha e é excluído do conjunto "de fato concedido" que o resumo relê. Este é o mesmo formato de resolução de dependências das arestas BLOCKING do Forge entre tickets: você não pode honrar o dependente até que seu bloqueador esteja satisfeito.
O ponto para uma execução AFK: a autorização é declarada e checada por máquina, então a equipe pode rodar sem supervisão dentro exatamente do envelope que você definiu — e o humano só é envolvido pelo nível explícito user_gated, nunca como uma dependência acidental de tocar o trabalho normal.
const requires = { read_repo: [], // nível base commit_local: ['read_repo'], // precisa ler antes de escrever push_remote: ['commit_local'], // precisa commitar antes do push deploy_prod: ['push_remote'], // concessão mais afiada, cadeia mais profunda user_gated: [] // a chave explícita de "perguntar a um humano" };
Esta é a tese em uma imagem. O loop à esquerda é um ciclo fechado que os agentes rodam entre si — learn, analyze, execute, verify, decide, voltas e voltas. O humano é a figura à direita, fora do ciclo, ligado por uma única linha somente-leitura aos artefatos que o loop emite. O humano lê; o humano não estende a mão para dentro.
O humano não está no caminho de execução (não constrói), nem no caminho de verificação (não roda a checagem), nem no caminho de QA (não faz a revisão). Até o QA de autorrevisão no passo sete é um agente que emite review.md como um relatório de observabilidade — uma coisa para ler, não uma tarefa para fazer. A linha somente-leitura do humano toca três artefatos: LOOP-LOG.md (a narrativa em andamento), review.md (a passada de QA) e o status da execução (quais unidades estão onde). Se o humano quer mudar de direção, ele muda o contrato (GOAL.md) — ainda assim não estende a mão para dentro de um turno em andamento.
Então como é, na prática, "ler o quadro"? Assim. Os quatro blocos no topo são os sinais vitais da execução — quantas unidades estão provadas, quão rápido o loop está girando, quantas provas estão falhando e quanto a equipe está gastando. Abaixo deles, uma tabela lista cada unidade em voo com um selo colorido: provada, construindo, bloqueada ou bifurca (esperando um humano). Pressione Atualizar para uma nova leitura, ou ligue Ao vivo para vê-la pulsar — do jeito que você daria uma olhada numa execução noturna durante o café.
Este é o trabalho inteiro do humano renderizado como uma tela: ler o resumo, varrer as linhas, identificar a única unidade parada em bifurca que quer uma decisão. Você nunca clica numa unidade para fazê-la — você lê.
Status da execução — PRJ "checkout-v2" · loop AFK
orquestrador: modelo de topo · roster: codex / claude / kimi · lendo LOOP-LOG.md
| Unidade | Estado | Falhas de prova | Último evento |
|---|
Um único array de objetos de unidade conduz tanto a tabela quanto a etiqueta de resumo. Cada pulso perturba as métricas dentro de limites realistas e recalcula o estado de cada unidade, depois re-deriva o banner geral: qualquer unidade bloqueada → vermelho, qualquer em bifurca → "precisa de você", senão saudável. Os deltas dos KPIs são coloridos pelo significado, não pela direção da seta — uma cadência caindo é boa (verde) ainda que a seta aponte para baixo; uma taxa de provas que falham subindo é ruim (ferrugem) ainda que sua seta aponte para cima.
Esta é a face legível do LOOP-LOG.md + o status da execução. Numa execução real esses números vêm do log que o Orquestrador escreve enquanto despacha e os Validadores reportam. O selo "bifurca" é a única célula que jamais chama por um humano — todo o resto está ali apenas para ser lido.
Se o humano nunca executa, quando o loop de fato envolve você? Exatamente uma vez por ocasião: quando o próximo passo é uma genuína decisão user-only — algo que nenhum agente tem a autoridade ou a informação para resolver. Um novo compromisso legal. Gastar dinheiro de verdade acima de um teto. Escolher entre duas direções de produto válidas. Decidir qual de dois caminhos irreversíveis tomar.
Quando isso acontece, o loop não chuta em silêncio e não trava em silêncio. Ele empacota um handoff: uma nota curta, pronta para decisão, que enuncia a bifurcação, as opções, os trade-offs e uma recomendação — e então espera. Você a lê, você decide, você devolve a decisão, e a equipe retoma. Essa é a única interrupção sancionada, e ainda tem o formato de observabilidade: você está lendo uma decisão preparada, não fazendo o trabalho.
Pense nisso como… uma equipe cirúrgica que faz uma pausa para chamar a família só para uma verdadeira decisão de consentimento — nunca para perguntar qual pinça usar. Tudo o que é rotineiro eles tratam; a única chamada irredutivelmente humana eles preparam de forma limpa e aguardam. Diferente da sala de cirurgia, aqui a pausa é registrada e a recomendação anotada, então a decisão é rápida e fica no histórico.
Uma bifurcação escala para o humano apenas se ela for ao mesmo tempo irredutível (nenhuma prova, nenhuma política e nenhuma cláusula do contrato pode resolvê-la) e presa à autoridade (ela precisa do mandato de um humano — dinheiro, jurídico ou uma chamada de valores). Qualquer coisa que um agente possa resolver com evidência ou relendo o GOAL.md é tratada dentro do loop. O handoff é deliberadamente pronto para decisão: ele faz a análise por você e termina com uma recomendação, então sua parte é um sim/não/escolha, não um projeto de pesquisa. Isso mantém a interrupção rara e curta — e mantém o papel do humano com formato de observabilidade mesmo no único momento em que ele age.
Operacionalmente, o escalonamento cavalga o nível user_gated da seção anterior: se aquela chave está desligada, o loop não deve inventar uma interrupção; ele registra o bloqueador e para o ramo afetado em vez disso, deixando o resto do quadro rodando.
Nada disto é mágica. A equipe é um punhado de chamadas de shell e um roster declarado. Aqui está o formato de uma execução de implement AFK: o Orquestrador lê o contrato, itera sobre as unidades prontas, despacha cada uma a um Executor via a chamada -p daquele agente, envia o resultado a um agente diferente para provar, e escreve tudo no log que o humano lê.
# roster declarado de antemão — agnóstico por padrão EXECUTORS=("codex" "kimi") # agentes de construção VALIDATOR="claude" # agente de prova — NUNCA um dos executores while read -r unit; do # LEARN/ANALYZE: próxima unidade pronta (desbloqueada) agent="${EXECUTORS[$((RANDOM % ${#EXECUTORS[@]}))]}" # EXECUTE: despacha uma unidade delimitada, one-shot "$agent" -p "$(unit_contract "$unit")" > "out/$unit.artifact" # VERIFY: um agente DIFERENTE prova no boundary real "$VALIDATOR" -p "Prove $unit vs done-when. Run the gate. PASS/FAIL + evidence." \ > "out/$unit.verdict" # DECIDE: lê o veredito, registra, fecha ou recoloca na fila decide "$unit" >> LOOP-LOG.md done < <(ready_units GOAL.md) # review: um agente de QA independente emite um relatório de observabilidade "$VALIDATOR" -p "QA the whole change vs GOAL.md. Emit review.md." > review.md
A orquestração exata vive na skill loop-engineering. Para encontrar as regras de AFK e cross-agent e o fluxo do forge:
# o contrato AFK + multiagente e o fluxo de 7 passos do forge cat ~/.claude/skills/loop-engineering/forge-flow.md grep -rn "cli -p\|Validator\|Orchestrator\|AFK\|observability" \ ~/.claude/skills/loop-engineering/
Os três invariantes que o código impõe: (1) o Validador nunca está em EXECUTORS; (2) toda unidade passa por uma prova antes que decide possa fechá-la; (3) a única escrita que o humano faz é no GOAL.md — nunca dentro de um turno em andamento. O roster é o único botão que você ajusta por execução; todo o resto decorre do contrato.
Amarre tudo com uma unidade na execução "checkout-v2", o ticket PRJ-114 · add a coupon field to checkout. Veja onde cada papel age e onde você não age.
PRJ-114 está desbloqueado e escreve seu Contrato de Unidade — o único done-when ("um cupom válido reduz o total; um inválido mostra um erro"), os arquivos que ele pode tocar, a fatia de contexto.codex -p "<contract>". O Codex escreve o campo, a validação e um teste, depois imprime um patch e encerra.claude -p "Prove PRJ-114 at the real boundary…". O Claude aplica o patch, roda o checkout contra um cupom real e um ruim, e reporta FAIL — o caso inválido lança uma exceção em vez de mostrar um erro, com o stack trace como evidência.PRJ-114 na fila para um Executor com a evidência anexada. O Codex conserta o caminho de erro; o Validador re-prova (a prova é perecível) e agora reporta PASS com ambos os casos passando.PRJ-114, anexa o rastro inteiro ao LOOP-LOG.md e escolhe a próxima unidade.PRJ-114 ficou vermelho uma vez e depois fechou verde. Você não fez nada — e nada precisou de você. Nenhuma bifurcação user-only surgiu, então o loop nunca perguntou.Conte as ações humanas naquele exemplo: zero. Esse é um turno AFK saudável. A única coisa que teria puxado você para dentro seria uma bifurcação genuinamente user-only — e não houve nenhuma.
# LOOP-LOG.md — PRJ-114 10:02 orch ANALYZE PRJ-114 pronta (sem bloqueadores) · contrato escrito 10:02 exec EXECUTE codex -p → out/PRJ-114.patch 10:05 valid VERIFY claude -p → FAIL: caminho de cupom inválido lança exceção (rastro anexado) 10:05 orch DECIDE recoloca PRJ-114 na fila com evidência 10:07 exec EXECUTE codex -p → out/PRJ-114.patch (v2) 10:09 valid VERIFY claude -p → PASS: ambos os casos verdes 10:09 orch DECIDE fecha PRJ-114 · próxima: PRJ-115
Repare nos atores alternados exec/valid e em que VERIFY nunca compartilha um agente com o EXECUTE acima dele. O nome do humano não aparece em lugar nenhum deste rastro — que é a condição de sucesso.
Três perguntas rápidas. Escolha uma resposta em cada — corrige no clique e diz o porquê.
Numa execução AFK, qual é o papel do humano?
Por que o Validador precisa ser um agente diferente do Executor?
O que o Orquestrador faz, e não faz?