O loop em movimento: AFK — você observa, não conduz

O que "AFK" significa precisamente aqui

AFK não é "dispare e reze". É um loop autônomo rigorosamente delimitado com três garantias estruturais. Um: toda passada termina num Proof Gate real — a mudança é exercitada contra o limite de verdade (o executor de testes, o endpoint HTTP, o arquivo em disco, a página renderizada), nunca uma alegação ou um mock. Dois: o loop anexa cada passada a um artefato observável (LOOP-LOG.md) e mantém um status ao vivo, de modo que a execução é legível sem interrompê-la. Três: o loop bloqueia o humano somente numa bifurcação genuína que só o usuário resolve — uma decisão que nenhuma quantidade de coleta de evidência consegue resolver (uma decisão de produto, uma ação irreversível, uma credencial faltando). Todo o resto ele resolve sozinho e registra.

Observabilidade vs controle

Em termos de operações, o humano fica no plano de observabilidade, não no plano de controle. Você consome sinais — LOOP-LOG.md, o checklist do done-when, o status por passada, o review.md ao fim da execução. Você não emite ações de controle dentro do loop entre as passadas. A separação é deliberada: um humano no caminho de controle por passada é o gargalo que torna a autonomia de longo prazo impossível. Tire o humano do caminho, deixe a ele uma janela clara para dentro, e o loop pode rodar por horas.

Para onde o resto do curso vai daqui

Esta lição é a dobradiça. O Módulo 2 ensinou os cinco movimentos; este os mostra rodando sem supervisão. O Módulo 3 (o Forge) envolve um front-end completo em torno de uma execução AFK — um Executor constrói cada ticket e um Validator independente o prova contra o GOAL.md (o Validator nunca é quem construiu), e uma passada final de QA AFK emite o review.md como um relatório de observabilidade. O fio que amarra tudo é exatamente a afirmação desta lição: tudo roda AFK; o único papel do humano é observabilidade.

Por que o humano é desenhado fora do anel

O posicionamento é o ponto inteiro do diagrama. Ponha o humano dentro do anel — fazendo a chamada DECIDE a cada passada, ou avaliando o VERIFY a olho — e o loop só consegue avançar na velocidade e na disponibilidade humanas. Ponha o humano fora, com uma janela somente-leitura para os artefatos, e o loop avança na velocidade da máquina enquanto permanece totalmente legível. A seta de LOOP-LOG.md para o humano aponta numa só direção: informação para fora, nenhum controle para dentro.

A aresta DECIDE é o que faz disso um loop, não uma linha

A seta isolada mais importante é a que vai de DECIDE de volta à próxima passada. Se VERIFY prova pronto, DECIDE para a execução. Se VERIFY mostra que a lacuna estreitou mas não fechou, DECIDE alimenta um plano melhorado de volta no LEARN e o anel gira de novo. Se VERIFY revela uma bifurcação que só o usuário resolve, DECIDE pausa e levanta um handoff. Três resultados, dos quais um (e só um) envolve você — e, mesmo assim, apenas como quem decide numa bifurcação, não como condutor das passadas de rotina.

A passada como código — o switch DECIDE

Uma passada é uma função. LEARN, ANALYZE, EXECUTE, então VERIFY retorna um veredito, e DECIDE é um switch de três vias sobre esse veredito. Repare que nada neste loop chama de volta um humano, exceto o único ramo explícito de handoff — e esse ramo dispara somente em fork, nunca numa passada de rotina.

async function pass(goal, log) {
  const state = await learn(goal);          // see the real state
  const unit  = analyze(state, goal);       // classify gap, pick ONE
  await execute(unit);                     // one bounded change
  const proof = await verify(unit, goal);  // at the REAL boundary

  log.append(proof);                       // observability, every pass

  switch (proof.verdict) {
    case 'done':     return { stop: true };          // converged
    case 'progress': return { stop: false };         // iterate → next pass
    case 'fork':     return handoff(proof);        // the ONLY human pull-in
  }
}

while (!(await pass(goal, log)).stop) { /* AFK: no human between passes */ }

Por que três resultados e não dois

Um loop ingênuo tem dois resultados: pronto, ou tente de novo. O terceiro — fork — é o que mantém a autonomia segura. Sem ele, um loop que esbarra numa pergunta genuinamente humana ou chuta (e produz lixo confiante) ou roda para sempre. Com ele, o loop faz a coisa honesta: para, empacota a decisão e a revela. A disciplina é que fork é raro e específico — uma decisão de produto, uma ação irreversível, um segredo faltando — nunca "isso é difícil" ou "por favor confirme este passo de rotina".

A execução inteira em um objeto

O painel é uma máquina de estados finitos — o mesmo formato do próprio loop. Há um estado atual, um conjunto fixo de movimentos e uma tabela que mapeia (state, move) → nextState. Os botões leem a tabela para decidir o que habilitar; você não consegue disparar um movimento que não seja legal a partir do estado atual, que é exatamente por que o loop não consegue "pular" o Proof Gate. CONVERGED é terminal (a execução acabou). BLOCKED é um estado especial: o único movimento para sair dele é resolve, e resolve é do humano.

const run = {
  IDLE: { start: 'RUN' },
  RUN:  { verify: 'VER' },                 // always pass through proof
  VER:  { done: 'DONE', again: 'ITER',    // converge or loop…
          fork: 'BLK' },                   // …or raise a fork
  ITER: { start: 'RUN' },                 // next pass, autonomously
  BLK:  { resolve: 'IDLE' },              // the ONLY human move
  DONE: {}                              // terminal — converged
};

Por que desabilitar em vez de ignorar

Quando um movimento não está na tabela para o estado atual, o botão fica desabilitado, não silenciosamente inerte. Essa restrição visível é o ensinamento: as opções do loop são finitas e conhecidas a cada passo, então seu comportamento é previsível e legível de fora. Um humano assistindo ao painel sempre consegue responder "o que pode acontecer a seguir?" sem ler nenhum código — o que é a essência da observabilidade.

Máquina de estados, não um vídeo

O movimento é uma máquina de estados finitos de cinco fases em JS puro — learn, analyze, execute, verify, decide. Cada compasso interpola o token com requestAnimationFrame e uma curva ease-in-out; Reproduzir dispara automaticamente o próximo compasso num timer (o comportamento AFK), Pausar o limpa. Não há <video>, nem GIF, nem biblioteca — então ele desliza, percorre e reinicia de forma determinística. O ponto verde que sempre orbita é um único <animateMotion> declarativo com repeatCount="indefinite", sinalizando "o loop está vivo" com zero JS.

Respeitando movimento reduzido

Honrar prefers-reduced-motion: reduce é inegociável para uma lição que se apoia em animação. Quando está ativado, as interpolações do JS viram saltos instantâneos (o token ainda se move entre etapas, só não desliza), e toda a sequência é narrada na legenda aria-live="polite" para que um usuário de leitor de tela — ou qualquer pessoa que desligou o movimento — receba cada compasso em palavras. A órbita declarativa é intencionalmente sutil e de baixo contraste para não distrair; um build mais rígido poderia pausá-la sob a mesma media query.

O que uma entrada real de LOOP-LOG.md contém

Cada passada anexa um registro pequeno, somente-de-anexo. O formato é deliberado: um timestamp, qual unidade foi tentada, o veredito do Proof Gate e a evidência daquele veredito — o comando de fato executado e seu resultado de fato, nunca uma paráfrase. Essa última parte é o que torna o log confiável: o humano lê a prova, não a opinião do loop sobre si mesmo.

## pass 3 · 2026-06-15T14:22:09Z
unit:    add /health endpoint + smoke test
verify:  curl -s -o /dev/null -w '%{http_code}' :3000/health
result:  200            # real boundary, not a claim
verdict: progress      # done-when: 3/5 met → iterate
next:    a11y sweep on the pricing view

Somente-de-anexo é uma vantagem

O log nunca é reescrito, só anexado. Isso dá ao observador um histórico completo e ordenado da execução — cada passada, cada veredito, cada pedaço de evidência — para que um humano chegando tarde possa reconstruir exatamente o que aconteceu sem ter assistido ao vivo. É o gravador de voo do loop. Quando a execução finalmente converge (ou bifurca), o mesmo artefato é a base do review.md de fim de execução que a passada de QA emite.

A linha só-humano

Repare que o último item do done-when — "Copy de preços aprovada" — está marcado como só humano. O loop consegue levar os outros quatro ao verde inteiramente por conta própria. Ele fisicamente não consegue marcar o quinto, porque é uma decisão de produto. Esse único item é o que acaba virando o veredito azul e levantando o handoff. Tudo acima dele é trabalho do loop; aquela única linha é sua.

Um modelo, duas vistas

Um único array de objetos de etapa alimenta tanto a tabela quanto a pílula de resumo. Cada tique perturba as métricas dentro de limites realistas, recomputa o status de cada etapa, então re-deriva o banner: qualquer etapa com prova falha → vermelho, qualquer etapa esperando humano → azul, senão verde/convergindo. Os deltas dos KPIs são coloridos por significado — "chamados ao humano" em queda é bom (verde), mesmo que ambas as setas possam apontar para o mesmo lado. O ponto inteiro de uma leitura de status é que o olho lê a cor primeiro.

O que "saudável" significa para uma execução do loop

Para uma execução AFK, "saudável" é uma coisa específica: as passadas estão completando, a taxa de falha da prova é baixa ou caindo, o done-when está subindo, e os chamados ao humano estão em zero. Uma execução que itera feliz sem ninguém tocá-la é o estado ideal — significa que o loop está fazendo exatamente o seu trabalho. O número que você mais observa é "chamados ao humano": enquanto permanecer em zero, você pode ficar longe do teclado.

O quadro é estado, não pixels

Cada ticket é um objeto com um campo col que só pode ser triage, progress ou done. As colunas na tela não são a fonte da verdade — o array de objetos de ticket é. "Rodar uma passada do loop" encontra o ticket desbloqueado de maior prioridade, o avança uma coluna e re-pinta. Um ticket com a flag human não atendida pode mover para dentro de andamento mas não consegue chegar a Pronto — espelhando exatamente o loop: o Executor o constrói, o Validator (um agente diferente, nunca quem construiu) tenta prová-lo, e o Proof Gate se recusa a aprovar uma decisão só humana.

function runOnePass() {
  const t = tickets
    .filter(x => x.col !== 'done' && !x.blocked)
    .sort(byPriority)[0];
  if (!t) return raiseHandoff();   // only blocked work left → you
  t.col = next(t.col);             // triage→progress→done
  if (t.human && t.col === 'done') t.col = 'progress'; // can't auto-finish a fork
  render();
}

As relações de bloqueio mantêm tudo honesto

No Forge, os tickets carregam arestas de bloqueio — o ticket B não pode começar até o ticket A estar pronto e provado. O loop as respeita automaticamente quando escolhe a próxima unidade desbloqueada, e é por isso que uma execução longa não precisa de um humano sequenciando o trabalho: o grafo de dependências mais a ordem de prioridade bastam. O único papel de sequenciamento do humano é o primeiríssimo (escrever a meta) e o último de todos (uma bifurcação genuína).

O log da execução e o review.md são artefatos diferentes

O LOOP-LOG.md é escrito durante a execução, passada a passada, pelo próprio loop — é o gravador de voo bruto. O review.md é escrito depois da execução por uma passada de QA AFK separada cujo único trabalho é observabilidade: ela lê o estado concluído, re-checa o done-when de forma independente e escreve um veredito legível por humanos. Crucialmente, o QA é ele próprio AFK — o humano não o roda. O humano lê a saída dele. Até a revisão da execução é automatizada; seu papel permanece pura observação.

Por que uma falha de prova no log é um bom sinal

A passada 3 falhar no seu Proof Gate, e então ser capturada e repetida, é o sistema funcionando corretamente. Uma execução com zero falhas de prova ao longo de muitas passadas é mais suspeita, não menos — pode significar que o portão é fraco demais para capturar qualquer coisa. A presença de uma falha capturada-e-recuperada no log é evidência de que o limite é real. O observador deveria se tranquilizar com isso, não se alarmar.

Abra o contrato e os artefatos da execução

# read the AFK + observability flow that this lesson teaches
cat ~/.claude/skills/loop-engineering/forge-flow.md

# during a run, tail the flight recorder without touching the loop
tail -f LOOP-LOG.md

# after a run, read the AFK QA's observability report
cat review.md

A disciplina que isto codifica

Das próprias regras de trabalho do projeto: "TUDO roda AFK; o humano só tem observabilidade (lê LOOP-LOG.md/review.md/status, não executa nada — nem o QA)." Ou seja: tudo roda AFK; o humano só tem observabilidade — lê o log, a revisão e o status, e não executa nada, nem o QA. O Validator nunca é quem construiu a unidade, e o humano bloqueia apenas numa bifurcação genuína só do usuário via handoff. Esta lição é essa regra, tornada visível.