Coda — o tribunal de saída do engine
Ao fim desta lição você sabe por que nada sai do Alembic sem prova executada, por que quem constrói nunca valida, e como o loop de auto-aprendizado (ADR-0018) sedimenta só vitórias validadas — desligado por padrão.
- Explicar por que o Proof Gate lê o journal de eventos, não o checkpoint
- Enunciar a regra "quem constrói não valida" e onde ela está no código
- Dizer o que o gate coordenado ADICIONA sem mudar decisão nenhuma
- Traçar o caminho propõe→dispõe do learning-gate com o corte 0.7
A grande ideia
O @alembic/coda é onde o engine deixa de confiar em si mesmo. Todo trabalho que quer SAIR — código, veredito, curso publicado — atravessa uma fila de cancelas independentes: prova executada (Proof), escrutínio de quem não construiu (Validator, e o irmão aditivo Coordinated), e um portão de publicação que parkeia o irreversível (Publish). Depois do run, um passo OPCIONAL de aprendizado propõe memórias — e um gate as dispõe.
Pense como… o controle de qualidade de uma fábrica: a peça só embarca depois do teste de bancada (rodar, não olhar), da inspeção por um fiscal de OUTRO turno, e do carimbo de expedição — e o que for perigoso fica retido para assinatura humana. A analogia quebra: aqui até o "manual de lições aprendidas" da fábrica passa por um fiscal antes de ganhar uma página nova.
O pipeline em uma imagem
Proof Gate — prova executada, não prometida
Cada string em unit.proof[] vira uma task bash -c que DEPENDE da unidade (lição 10 mostra o compilador). O gate então pergunta uma coisa só: toda task com metadata.kind: 'proof' terminou com exit 0? Ele agrega por unidade, grava units/<id>/proof-results.jsonl e, se qualquer prova falhou, devolve err — o run fecha (packages/coda/src/proof.ts:26-99).
O gate lê os estados do journal append-only de eventos (store.readEvents() → últimas task-state por id), não do checkpoint.json — porque múltiplos runSwarm no mesmo store SOBRESCREVEM o checkpoint, mas o events.jsonl guarda tudo (proof.ts:22-41). Mesma filosofia dos 5 substores da lição 06: o log é a verdade.
Camada técnica — comandos desta seção
# inspecionar as provas de um run real alembic runs list cat <runDir>/units/u1/proof-results.jsonl # {unitId, proofIndex, command, outcome, output|error} # o gate no código sed -n '26,99p' packages/coda/src/proof.ts
Validator Gate — quem constrói não valida
A regra está escrita no topo do arquivo: "Who builds must not validate" (packages/coda/src/validator.ts:24). Um board INDEPENDENTE de 3 validadores (analyst, pragmatist skeptical, contrarian na fase "challenge") delibera sobre o resultado da unidade/milestone; depois um painel verificador (verifyPanel) checa a própria decisão do council. O resultado é fail-closed: { decision, verdict: verified|needs-review|rejected, approved } — e só approved === true permite emissão (validator.ts:89-110). Para unidades T4 existe um seam injetável de fusion (validador multi-modelo de alta confiança) que substitui o painel (validator.ts:105-110).
Coordinated — multi-lente por risco, sem tocar na decisão
Opt-in via alembic run --coordinated: um irmão ADITIVO que roda runCoordinatedValidatorGate (coordinated-validator.ts:476) sobre as mesmas unidades e grava cada veredito em units/<id>/coordinated-verdict.json — nunca muda a decisão do council e nunca falha o run. O tier de risco escolhe o painel: T4/highStakes → full; T3 → lite (ou full acima de 4000 chars); T0/T1 → trivial abaixo de 400 palavras (coordinated-validator.ts:168-173). Seis lenses com escopo apertado — requirements, completeness, coherence, correctness, security, risk (coordinated-validator.ts:76-128) — revisam via ModelAdapter injetado.
coordinated-validator.ts:20-23).Publish Gate — o carimbo de expedição
Toda ação de publicação para FORA (curso visual-teach, manifest) passa por runPublishGate (packages/coda/src/publish.ts:63): sem aprovação, o artefato é parkeado no ledger de irreversibilidade t4-parked.jsonl e espera humano; com aprovação, publica pelos publishers INJETADOS (gist obrigatório, pages opcional) e devolve { decision: 'parked' | 'published', gistUrl?, pagesUrl? }. Publicar é a única ação outward do engine — e mesmo ela tem cancela.
Learning-gate — o loop que sedimenta só vitórias
O ADR-0018 definiu o kernel propõe→dispõe: reviewAndLearn(summary, { proposer, gate, memory }) em @alembic/hermes/learning (review.ts:54). O que faltava era compor os três ports com colaboradores reais — e packages/coda/src/learning-gate.ts é exatamente esse wiring: um ReviewProposer vira UMA chamada de modelo pelo ModelAdapter; o Validator da seção 4 vira o ReviewGate (a memória só sedimenta o que passa no gate REAL de qualidade); e o fallback conservador é scoreThresholdGate com corte 0.7 (hermes/src/learning/gate.ts:19-25). Tudo OPT-IN: alembic run --learn, default false (apps/cli/src/args.ts:214-218) — sem a flag, o run é byte-idêntico.
As defesas do proposer
O reviewer lê um resumo NÃO-CONFIÁVEL (pode citar tool output e páginas baixadas), então o system prompt anexa o injectionDefenseFragment compartilhado (learning-gate.ts:63-73). A resposta precisa ser um array JSON de propostas {target: memory|user, op: add|replace|remove, rationale, score 0..1}; corpo não-array falha o passo FECHADO — "um reviewer quebrado não pode parecer um reviewer sem nada a dizer" (learning-gate.ts:106-121). E o kernel re-valida cada proposta com Zod ANTES de qualquer escrita, porque em produção o proposer é output de modelo, não código confiável.
score >= 0.7 (DEFAULT_REVIEW_SCORE_THRESHOLD, hermes/src/learning/gate.ts:19-25). O desenho preferido continua sendo o Validator real como ReviewGate — mas o loop nunca fica sem cancela.Experimente
Feche a lição recuperando os contratos de cabeça.