O pipeline de portões: cinco checkpoints em torno de uma run

Uma run não apenas "executa e termina". Ela passa por uma sequência de portões — Scope, Council, Proof, Validator, Publish — cada um capaz de detê-la. Alguns são pré-voo, alguns fecham a run, um é opcional. Juntos são a disciplina que transforma "o agente produziu algo" em "o agente produziu algo verificado". É também exatamente onde o ReviewGate do ciclo de aprendizado (lições 4 e 8) se encaixa. Fonte: @alembic/coda + @alembic/mission + @alembic/forge.

O pipeline, em ordem

① Scope Gate — materializa o diretório da run

A rampa de entrada. loadScope(input) (forge/src/scope.ts) copia o GOAL.md, o módulo de plano e o contrato de validação para um diretório de run content-addressed e semeia seu layout (council/, units/, workflows/, park/, course/, reports/ + LOOP-LOG.md + review.md). Sua regra-chave de segurança: um resume não pode trocar o escopo — ao retomar, goal/plan/contract são validados contra o meta.json salvo, e qualquer divergência retorna err('resume mismatch: …'). Você não consegue re-escopar por acidente uma run que está retomando.

② Council Gate — GO/NO_GO de pré-voo opcional

runCouncilGate (mission/src/council-gate.ts) roda um board antes de o trabalho começar e retorna uma CouncilDecision agregada. NO_GO significa que a missão não deve prosseguir. É opcional (acionado por --council / config do plano) — um veto de pré-voo, não uma revisão posterior. O núcleo do harness impõe a mesma ideia internamente: no fanout, o council roda primeiro e um NO_GO faz curto-circuito antes de qualquer worker ser despachado — "um board que não dá sinal verde não deve gerar trabalho autônomo".

③ Proof Gate — a espinha determinística

Este é o portão que faz "funciona" significar algo. Cada string unit.proof[] numa missão compila para uma task de comando bash -c que depende da task da unit. O Proof Gate lê os estados das tasks e falha a run fechada em qualquer saída não-zero:

// packages/coda/src/proof.ts:26-99 (condensado) — falha fechado, lê o journal
// toda task com metadata.kind === 'proof' DEVE ter saído 0 (status === 'done')
for (const proof of proofTasks) {
  if (state(proof).status !== 'done') failures.push(summarize(proof)); // qualquer falha ⇒ err
}
if (failures.length) return err(perUnitSummary(failures));    // quem chama falha a run fechada

Um detalhe sutil e importante: ele lê os estados das tasks do journal de eventos, não do checkpoint — então sobrevive a sobrescritas de checkpoint entre múltiplas chamadas de runSwarm que compartilham um store. Resultados de proof são persistidos em units/<unitId>/proof-results.jsonl. Esta é a encarnação em nível de motor da disciplina de Proof Gate que você viu por todo o curso: nenhum claim conta sem um comando real saindo 0.

④ Validator Gate — quem constrói não valida

runValidatorGate (coda/src/validator.ts) roda um council independente de validadores mais um painel verificador sobre a evidência de cada milestone. Só approved === true (o painel é verificado e não estacionado) permite a emissão; um NO_GO ou um painel rejeitado estaciona para revisão humana. Uma costura fusion opcional trata unidades T4/alto-risco. A separação é o ponto — o agente que produziu o trabalho nunca é o que assina embaixo.

⑤ Publish Gate — estaciona quando fechado

Qualquer publicação voltada para fora deve passar por este portão (coda/src/publish.ts). Fechado → o artefato é estacionado em t4-parked.jsonl e aguarda aprovação humana; aberto → é publicado via os publishers gist/pages fornecidos. Isso alinha com o princípio do portão-humano-no-ship (ADR-0005): o passo irreversível e voltado para fora é o que um humano assina.

Confusões comuns