Curso de Fusão (Alembic × Hermes) · Visual Course

O pipeline de gates: cinco checkpoints em volta de um run

Um run não apenas "executa e termina". Ele atravessa uma sequência de gates — Scope, Council, Proof, Validator, Publish — e cada um pode pará-lo. Alguns são de pré-voo, um fecha o run, um é opcional, e o último exige um humano. Juntos, eles são a disciplina que transforma "o agente produziu algo" em "o agente produziu algo verificado". É exatamente aqui também que encaixa o ReviewGate do loop de aprendizado (lições 4 e 8). Fonte: @alembic/coda + @alembic/mission + @alembic/forge.

Leia primeiro (fonte primária)

Os cinco arquivos de gate do repo — lidos verbatim

Esta lição é citada de arquivo real: packages/forge/src/scope.ts (Scope), packages/mission/src/council-gate.ts + packages/harness/src/core.ts (Council), packages/coda/src/proof.ts (Proof), packages/coda/src/validator.ts (Validator) e packages/coda/src/publish.ts (Publish). Nada aqui é inventado — toda afirmação tem um arquivo atrás.

Leia a versão simples, ou abra a camada técnica em qualquer seção.

O que você vai conseguir fazer

Nomear os cinco gates em ordem e dizer qual é pré-voo, qual fecha o run e qual exige um humano.
Explicar por que todo gate falha fechado — o padrão é parar/parquear, nunca presumir OK.
Dizer por que o Proof Gate lê o event journal, e não o checkpoint, e por que isso o torna robusto.
Distinguir o Council Gate (pré-voo, decide se começa) do Validator Gate (pós-trabalho, decide se emite).
Conectar o ReviewGate do aprendizado a esta mesma família de gates.

Suposições tolas (o que presumimos de você — bem pouco)

Você já viu, em alguma lição anterior, que o Alembic devolve Result em vez de lançar exceção — e que "falha" é um valor, não um susto.
Você sabe ler pseudocódigo simples. Não precisa saber TypeScript — vamos traduzir cada trecho.
Você não precisa saber o que é "fail-closed", "event journal" ou "checkpoint". A gente constrói cada termo do zero aqui.

A grande ideia

Um gate é uma cancela. Antes de o run seguir adiante, ele precisa passar — e se não passar, a cancela fica fechada. O segredo do Alembic é que fechado é o estado padrão: nenhum gate "deixa passar na dúvida".

Pense em cinco catracas numa esteira de fábrica. A peça (o run) entra pela esquerda e precisa cruzar cinco catracas para sair pela direita. A primeira só monta a estação de trabalho. A segunda pode vetar tudo antes de começar. A terceira é a mais dura — confere, com um comando real, se o trabalho de fato funcionou. A quarta chama um juiz independente (quem construiu não pode ser quem aprova). A quinta é a única que precisa de uma pessoa assinando, porque o passo dela é irreversível: publicar para fora.

Pense como… as comportas de um canal (as eclusas que elevam um barco de um nível para outro): a água só sobe quando a comporta anterior está travada e a verificação foi feita. Ninguém abre a próxima comporta "torcendo para dar certo". A analogia quebra num ponto: numa eclusa a falha é rara; aqui o sistema assume que o modelo vai errar — e desenha as comportas em volta dessa certeza.

Por baixo do capô

Os cinco gates vivem em três pacotes: o Scope Gate em @alembic/forge (scope.ts); o Council Gate em @alembic/mission (council-gate.ts), com o HarnessCore.fanout em @alembic/harness aplicando a mesma ideia internamente; e os três últimos — Proof, Validator, Publish — em @alembic/coda (proof.ts, validator.ts, publish.ts). Cada um devolve um Result<T, Error>: o sucesso é ok(...), e a recusa é um err(...) que o chamador usa para falhar o run fechado.

Não é coincidência que sejam Result e não exceções: o pipeline inteiro é controle de fluxo uniforme. Quem orquestra ramifica em result.ok — nunca precisa de try/catch para descobrir que um gate fechou.

Infográfico dos cinco gates do Alembic em fila como cancelas numa esteira: Scope (materializa o run-dir, pré-voo), Council (GO/NO_GO opcional, pré-voo), Proof (roda unit.proof[] como bash -c, a espinha determinística), Validator (council independente + verifier, só approved emite), Publish (park quando fechado, porta humana); uma faixa lembra que todo gate falha fechado.

Os cinco gates em volta de um run. A peça atravessa da esquerda para a direita; qualquer cancela fechada para o run no lugar.

Guarde istoFail-closed = o padrão de um gate é não prosseguir. Onde um sistema descuidado diria "deu erro, mas segue", o Alembic diz "na dúvida, pare ou parqueie para um humano". Essa única regra é o que faz os cinco gates valerem alguma coisa.

A escolha de projeto que define os cinco gates: o padrão é fechar, não abrir.

A fila, em ordem

Os cinco aparecem sempre na mesma sequência. Dois são de pré-voo (rodam antes do trabalho), um é a espinha determinística, um é a revisão independente e o último é a porta humana para o passo de fora.

A sequência canônica + a nota de que o ReviewGate é da mesma família. Adaptado da fonte original em inglês.

Faça sua aposta antes de revelar

De cara: dos cinco gates, quantos você acha que são opcionais (podem ser ligados ou desligados)? E qual é o único que exige uma pessoa?

Um é opcional: o Council Gate (ligado por --council / config do plano). Os outros quatro fazem parte do caminho normal. E o único que exige um humano é o Publish Gate — porque seu passo (publicar para fora) é irreversível. Os demais decidem com lógica; o Publish decide com uma assinatura humana.

borda

Scope Gate

Monta o diretório do run e copia GOAL.md, o plano e o contrato para dentro dele.

forge/src/scope.ts fecha quando: um resume tenta trocar o escopo → err("resume mismatch…")

① Scope Gate — materializar o diretório do run

A rampa de entrada. Antes de qualquer trabalho, o run precisa de um lugar para morar.

loadScope(input) (em forge/src/scope.ts) copia o GOAL.md, o módulo de plano e o contrato de validação para um diretório do run e semeia o esqueleto dele: as subpastas council/, units/, workflows/, park/, course/ e reports/, mais os arquivos meta.json, o LOOP-LOG.md e o review.md.

A regra de segurança chave: um resume não pode trocar de escopo. Ao retomar um run existente, o GOAL.md, o caminho do plano e o contrato são comparados contra o meta.json salvo — e qualquer diferença devolve um err("resume mismatch: …"). Você não consegue, sem querer, re-escopar um run que está apenas continuando.

Pense como… abrir uma pasta de obra numa construtora: tem a planta aprovada (GOAL), o cronograma (plano) e o contrato — e cada gaveta já rotulada (as subpastas). Se alguém tentar reabrir a pasta de uma obra antiga e enfiar uma planta diferente, o arquivo trava: aquela pasta é daquela obra.

O que o código diz

O cabeçalho de loadScope documenta literalmente: "writes index.json, meta.json, tasks.json, run-state.json; seeds LOOP-LOG.md and review.md; creates subdirectories: council/, units/, workflows/, park/, course/, reports/". Na ramificação de resume, ele lê meta.json e devolve err("cannot read meta.json for resumed run") se não conseguir, e três err distintos de resume mismatch — um para o GOAL.md, um para o caminho do plano e um para o contrato de validação.

A on-ramp: copiar + semear o run-dir; o resume é travado contra o meta.json salvo.

DicaPense no Scope Gate como o gate que cria o "ambiente" onde os outros quatro vão escrever suas evidências (units/<id>/proof-results.jsonl, t4-parked.jsonl…). Sem ele, não há onde os outros gates deixarem rastro.

Por que são Result, não exceções: controle de fluxo uniforme — quem orquestra só olha result.ok.

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

A pergunta que vem antes do trabalho: "isto deve sequer começar?"

runCouncilGate (em mission/src/council-gate.ts) roda um conselho antes de o trabalho começar e devolve uma CouncilDecision agregada. NO_GO significa que a missão não deve prosseguir. É opcional (ligado por --council / config do plano) — um veto de pré-voo, não uma revisão depois do fato.

O núcleo do harness reforça a mesma ideia por dentro: no fanout do HarnessCore (harness/src/core.ts), o conselho roda primeiro e um NO_GO faz curto-circuito antes de qualquer worker ser despachado. O comentário no código é direto: "um board que não dá sinal verde não deve gerar trabalho autônomo".

Pense como… a reunião de "lançar ou não lançar" antes de o foguete acender os motores. Se a sala diz NO_GO, ninguém abasteceu nada à toa — a decisão veio antes do gasto. Comparar com a revisão pós-voo (que é o Validator Gate): uma decide se decola; a outra examina os destroços ou o sucesso depois.

O que o código diz

O cabeçalho de runCouncilGate documenta: "returns a GO / NO_GO verdict. NO_GO is fail-closed: the mission aborts before any worker is dispatched." Em core.ts, dentro de fanout: if (job.council) { ... if (decided.value === 'NO_GO') ... emite 'phase halted: council returned NO_GO' e devolve sem entrar na fase de partição/drain dos workers.

// harness/src/core.ts — fanout: o conselho roda primeiro; NO_GO faz curto-circuito
async fanout(job) {
  if (job.council) {
    const decided = await this.deliberate(job.council);
    if (decided.value === 'NO_GO')
      return halt('phase halted: council returned NO_GO'); // nenhum worker despachado
  }
  // só aqui começa a partição + drain dos workers…
}

GO abre o caminho dos workers; NO_GO faz curto-circuito antes de gastar qualquer trabalho autônomo.

Quando cada gate roda: dois antes do trabalho, dois depois, um no momento de mandar para fora.

③ Proof Gate — a espinha determinística

Este é o gate que faz "funciona" significar alguma coisa. Sem ele, "deu certo" é só uma opinião.

Cada string em unit.proof[] de uma missão vira uma tarefa de comando bash -c que depende da tarefa da unidade. O Proof Gate lê o estado dessas tarefas e falha o run fechado se qualquer uma saiu com código diferente de zero. Não há "aviso e segue": uma prova que falha derruba o run.

Um detalhe sutil e importante: ele lê o estado das tarefas a partir do event journal (o events.jsonl, append-only), e não do checkpoint. Por quê? Porque um store compartilhado pode ter seu checkpoint.json sobrescrito por uma chamada posterior de runSwarm — mas o journal, que só cresce, guarda todo evento task-state para sempre. Ler o journal torna o gate robusto através de múltiplas chamadas. Os resultados são gravados em units/<unitId>/proof-results.jsonl.

Pense como… a diferença entre alguém dizer que pagou a conta e o extrato bancário mostrando o débito. O checkpoint é como o último print que pode ter sido tirado por cima de outro; o journal é o extrato completo, linha a linha, que ninguém apaga. Em caso de dúvida, você confia no extrato.

O que o código diz

runProofGate chama store.readEvents(), monta um Map de task-state por id, filtra as tarefas com metadata.kind === 'proof' e marca cada uma como complete só se state?.status === 'done'. Ao final, const failed = results.filter(r => r.outcome === 'failed'); se houver alguma, devolve err(new Error("Proof Gate failed: " + summary)), com um resumo por unidade (unit=… index=… command="…"). Antes disso, escreve o proof-results.jsonl de cada unidade, ordenado por proofIndex.

// packages/coda/src/proof.ts (condensado) — lê o journal, falha fechado
const events = await store.readEvents();        // o journal append-only, não o checkpoint
for (const e of events.value)
  if (e.kind === 'task-state') stateById.set(e.payload.id, e.payload);

// toda tarefa com metadata.kind === 'proof' PRECISA ter saído 0 (status === 'done')
const failed = results.filter(r => r.outcome === 'failed');
if (failed.length > 0)
  return err(new Error(`Proof Gate failed: ${summary}`)); // chamador falha o run fechado

Infográfico do Proof Gate: o checkpoint.json é sobrescrito por cada runSwarm, mas o events.jsonl append-only guarda todo evento task-state; runProofGate lê só o journal via store.readEvents, marca cada prova como done (exit 0) ou failed, escreve units/<id>/proof-results.jsonl e devolve err quando algo falha.

Por que o gate lê o journal append-only e não o checkpoint: o journal é a fonte da verdade que sobrevive a múltiplas chamadas runSwarm.

Exemplo guiado — uma prova que falha

A unidade u1 declara proof: ['pnpm -w test']. O compilador transforma isso numa tarefa bash -c "pnpm -w test" com metadata.kind === 'proof', dependente de u1.

O comando roda e sai com código 1 (um teste quebrou). O swarm grava um evento task-state com status diferente de 'done' no events.jsonl.

O Proof Gate lê o journal, vê que a prova não está done, marca-a como failed e escreve o proof-results.jsonl da unidade mesmo assim (o rastro fica).

Ele devolve err("Proof Gate failed: unit=u1 index=0 command=\"pnpm -w test\""). O chamador falha o run fechado. Nada de "passou com ressalvas".

Agora você: a unidade tinha proof: ['pnpm -r typecheck', 'pnpm -w test'] e o typecheck saiu 0 mas o test saiu 1. Quantas linhas o proof-results.jsonl da unidade tem, e o run passa? (Resposta: duas linhas — uma complete, uma failed — e o run NÃO passa, porque basta uma falha.)

O caminho de uma prova: declaração → comando real → linha de resultado persistida.

A frase para levar: o Proof Gate é a encarnação, no nível do motor, da disciplina do Proof Gate que você viu o curso inteiro: nenhuma afirmação conta sem um comando real saindo 0.

④ Validator Gate — quem constrói não pode validar

Provas dizem que os comandos passaram. O Validator Gate adiciona um juízo — e quem o emite nunca é quem construiu.

runValidatorGate (em coda/src/validator.ts) roda um conselho independente de validadores mais um painel verifier sobre a evidência de cada milestone. Só approved === true (o painel está verificado e não foi parqueado) permite a emissão; um NO_GO ou um painel rejeitado parqueia para revisão humana. Há um seam opcional de fusion que cuida das unidades T4 / de alto risco.

A separação é o ponto inteiro: o agente que produziu o trabalho nunca é o que assina embaixo. Provas são determinísticas (o comando passa ou não); o Validator adiciona a camada qualitativa — alguém de fora olhando a evidência.

Pense como… revisão por pares num jornal sério: o repórter (quem construiu) não é quem decide publicar; um editor independente lê a matéria e ou aprova, ou manda de volta. Em matéria sensível (T4), entra um segundo editor sênior (o fusion). A analogia quebra num ponto: aqui, "mandar de volta" não é opcional — é o estado padrão na dúvida.

O que o código diz

O cabeçalho documenta: "the verifier panel checks the council decision. The result is fail-closed: only `approved === true` means the work may emit." A linha-chave: approved: panel.verdict === 'verified' && panel.parkedTier === undefined — verificado E sem tier parqueado. O verdict do painel mapeia para 'GO' (verified), 'NO_GO' (rejected) ou 'PIVOT'. Quando a unidade é T4 e há um fusion injetado, runValidatorGate delega a ele logo no início (if (options.t4 && options.fusion) return options.fusion(options)).

Revisão independente: só approved === true emite; o resto parqueia. T4 desvia pelo seam opcional fusion.

A condição-E exata: verificado e sem tier parqueado. Basta um lado falhar para parquear.

⑤ Publish Gate — parqueia quando fechado

O último passo é o irreversível: mandar algo para fora. Por isso, é o único gate cuja chave é uma assinatura humana.

Qualquer publicação para fora precisa passar por este gate (coda/src/publish.ts). Fechado (sem aprovação) → o artefato é parqueado em t4-parked.jsonl e espera a aprovação humana. Aberto (aprovado) → ele é publicado pelos gist/pages fornecidos. Um gist é obrigatório quando aprovado; o Cloudflare Pages é opcional.

Isso espelha o princípio do "humano-no-ponto-de-ship" (ADR-0005): o passo de fora, irreversível, é deliberadamente o que exige uma pessoa.

Pense como… o botão de lançar um míssil que precisa de duas chaves giradas ao mesmo tempo: o sistema pode preparar tudo, mas o ato irreversível só acontece com a mão humana na chave. Aqui a "chave" é o approved; sem ela, o artefato fica numa gaveta etiquetada (t4-parked.jsonl), pronto, mas não enviado.

O que o código diz

Em runPublishGate: se !options.approved, ele dá appendFile de um registro { runId, artifactPath, reason: 'publish-gate', at } no t4-parked.jsonl e devolve ok({ decision: 'parked' }). Se aprovado e sem publisher de gist, devolve err('approved publish gate requires a gist publisher'). Com gist (e, opcionalmente, pages), devolve ok({ decision: 'published', gistUrl, pagesUrl? }).

// packages/coda/src/publish.ts (condensado) — park quando fechado
if (!options.approved) {
  await appendFile(parkedPath, JSON.stringify({
    runId, artifactPath, reason: 'publish-gate', at: Date.now()
  }) + '\n');
  return ok({ decision: 'parked' });          // espera a aprovação humana
}
if (!gistPublisher)
  return err(new Error('approved publish gate requires a gist publisher'));

A bifurcação humana: sem approved, parqueia; com ele, publica via gist (e Pages, se houver).

Por que o humano fica aqui (ADR-0005): o sistema prepara tudo, mas só uma pessoa gira a chave do passo que não dá para desfazer.

Onde o loop de aprendizado pluga

A mesma família de gate, aplicada ao próprio motor

O passo de aprendizado do pacote de fusão (lições 4 e 8) é guardado por um ReviewGate com scoreThresholdGate(0.7) — um membro desta mesma família de gates. Os cinco gates acima governam o que um run tem permissão de mandar para fora; o ReviewGate governa o que um run terminado tem permissão de sedimentar em memória e skills. Mesma filosofia, aplicada à autoevolução do motor: só aprenda de vitórias validadas. É por isso que a matriz de fusão chama o loop de aprendizado de um CLONE que "compõe com o validator gate" em vez de substituí-lo.

Duas aplicações da mesma ideia de gate: o ship do run e a memória do motor.

Confusões comuns

"O Council Gate e o Validator Gate são a mesma coisa." Não. O Council Gate é um GO/NO_GO de pré-voo opcional, antes de o trabalho começar; o Validator Gate é uma revisão independente pós-trabalho da evidência produzida. Um decide se começa; o outro decide se o que foi produzido pode ser emitido.

"Publicar é só gravar o artefato para fora." Só se o gate estiver aberto. Fechado, ele parqueia o artefato em t4-parked.jsonl para um humano — a ação de fora, irreversível, é de propósito a que exige uma pessoa (ADR-0005).

"Se o Proof Gate passou, está pronto para ship." Não necessariamente. Provas são a espinha determinística, mas o Validator Gate ainda adiciona o juízo independente, e o Publish Gate ainda exige o humano. Passar nas provas é necessário, não suficiente.

CuidadoNenhum gate "degrada" para aviso. Em todos os cinco, o caminho de falha é fechar — devolver err e parar, ou parquear. Se você esperava um "passou com warnings", esqueça: aqui não existe.

começa opcional · NO_GO aborta cedo Validator Gate QUANDO: depois do trabalho DECIDE: se a evidência pode emitir independente · NO_GO parqueia

A confusão mais comum, resolvida: um decide se começa, o outro decide se o produzido pode sair.

Tabela-resumo dos cinco

Gate	Quando	O que decide	Falha = ?
① Scope	entrada	monta o run-dir; trava o resume	err("resume mismatch")
② Council	pré-voo (opcional)	se a missão começa	NO_GO → aborta antes dos workers
③ Proof	após o trabalho	se os comandos saíram 0	err → run falha fechado
④ Validator	após o trabalho	se a evidência convence	parqueia p/ humano
⑤ Publish	no ship	se sai para fora	park em t4-parked.jsonl

Passar nas provas é o começo, não o fim: o ship ainda exige o juízo independente e a mão humana.

Recapitulando em 6 slides

A virada de chave

Um run não só executa

Ele atravessa cinco gates — Scope, Council, Proof, Validator, Publish. Cada um pode pará-lo. É o que separa "produziu algo" de "produziu algo verificado".

A regra de ouro

Todo gate falha fechado

O padrão na dúvida é parar ou parquear — nunca "presumir OK". Sem essa regra, os cinco gates não valeriam nada.

Os dois de pré-voo

Scope monta · Council veta

Scope copia GOAL/plano/contrato e trava o resume contra o meta.json. Council (opcional) dá GO/NO_GO antes de qualquer worker rodar.

A espinha

Proof lê o journal

Cada unit.proof[] vira um bash -c; saída != 0 falha o run. Ele lê o events.jsonl append-only — não o checkpoint, que pode ser sobrescrito.

Juízo + humano

Validator revisa · Publish assina

Validator: council independente + verifier, só approved emite (quem constrói ≠ quem aprova). Publish: parqueia em t4-parked.jsonl até um humano aprovar.

A conexão

O ReviewGate é da família

O loop de aprendizado tem um ReviewGate (limiar 0.7) da mesma família: só sedimenta em memória/skills o que foi validado. A seguir (18): council e verifier por dentro.

1 / 6setas ← →

Simples ↔ Técnico: a mesma ideia, duas alturas

Alterne entre a explicação leiga e a precisa. Use a aba "Técnico" quando quiser os nomes reais; a "Simples" quando quiser a intuição.

Em linguagem de gente: são cinco catracas numa esteira. A primeira monta a estação. A segunda pode cancelar tudo antes de começar. A terceira confere com um comando de verdade se o trabalho funcionou. A quarta chama um juiz de fora. A quinta precisa de uma pessoa para liberar a saída. Em todas, "na dúvida" significa parar — nunca seguir torcendo.

Com os termos reais: loadScope (forge) materializa o run-dir e trava o resume contra meta.json; runCouncilGate (mission) + HarnessCore.fanout fazem o NO_GO de pré-voo curto-circuitar antes de despachar workers; runProofGate (coda) lê store.readEvents() e devolve err em qualquer prova != done; runValidatorGate (coda) emite só com panel.verdict === 'verified' && parkedTier === undefined, com seam fusion para T4; runPublishGate (coda) parqueia em t4-parked.jsonl quando !approved, senão publica via gist (obrigatório) e pages (opcional).

Cartões de memória

Vire cada cartão (clique, ou Enter/Espaço) e tente responder antes de ver o verso. É prática de recuperação — vale mais que reler.

A ordem

Quais são os cinco gates, em sequência?

clique para virar

① Scope · ② Council · ③ Proof · ④ Validator · ⑤ Publish. Dois pré-voo, um determinístico, um independente, um humano.

Regra de ouro

O que significa "fail-closed" num gate?

clique para virar

O padrão é não prosseguir: na dúvida, o gate para ou parqueia para um humano — nunca "presume OK e segue".

Proof

Por que o Proof Gate lê o journal e não o checkpoint?

clique para virar

O checkpoint.json pode ser sobrescrito por outra chamada runSwarm; o events.jsonl é append-only e guarda todo task-state. O journal é a fonte da verdade.

Council vs Validator

Qual a diferença entre Council e Validator?

clique para virar

Council: pré-voo opcional, decide se começa. Validator: pós-trabalho, decide se a evidência produzida pode emitir.

Validator

Que condição exata libera a emissão no Validator Gate?

clique para virar

approved === true: o painel está verified e sem tier parqueado. Quem constrói nunca é quem aprova; T4 desvia para o seam fusion.

Publish

O que acontece num Publish Gate fechado?

clique para virar

O artefato é parqueado em t4-parked.jsonl (com reason: 'publish-gate') e espera a aprovação humana. O passo de fora é irreversível — por isso exige uma pessoa (ADR-0005).

As cinco frases que resumem a lição

Um run atravessa cinco gates; qualquer um pode pará-lo no lugar.
Todo gate falha fechado — o padrão é parar/parquear, jamais presumir OK.
Scope monta o run-dir e trava o resume contra o meta.json.
Proof é a espinha determinística: lê o journal e exige todo unit.proof[] saindo 0.
Validator dá o juízo independente; Publish exige a assinatura humana no passo irreversível.

Verifique

Responda os três. O placar embaixo acompanha seus acertos — é revisão espaçada, não prova.

Quiz da lição 17

1. O comando proof[] de uma unidade sai com código diferente de zero. O que o Proof Gate faz?

Correta: b. Toda tarefa com metadata.kind === 'proof' precisa estar done (saída 0). Qualquer falha entra num resumo e o gate devolve err, falhando o run fechado. Provas são a espinha determinística — não degradam para aviso.

2. Por que o Proof Gate lê o estado das tarefas a partir do event journal, e não do checkpoint?

Correta: c. Um store compartilhado pode ter o checkpoint.json sobrescrito por uma chamada posterior, mas o events.jsonl append-only retém todo evento task-state. Ler o journal torna o gate robusto através de runs com múltiplas chamadas.

3. O Validator Gate existe além do Proof Gate. O que ele acrescenta que as provas não dão?

Correta: d. Provas são checagens determinísticas de comando; o Validator Gate adiciona a revisão qualitativa independente (quem constrói não valida), parqueando para um humano num NO_GO ou painel rejeitado. Os dois são complementares, não duplicados.

Acertos: 0/3

packages/coda/src/proof.ts

Proof Gate · lê o journal · falha fechado

packages/coda/src/validator.ts

council independente + painel · só approved emite

packages/coda/src/publish.ts

park em t4-parked.jsonl quando fechado

packages/mission/src/council-gate.ts

GO/NO_GO de pré-voo · + harness/src/core.ts

packages/forge/src/scope.ts

Scope Gate · resume-mismatch · layout do run-dir

Próxima: council e verifier

como o conselho e o painel decidem por dentro

Você é o aluno e também o professor: pergunte-se "se eu tivesse que escolher um gate para nunca remover, qual seria — e por quê?" Se a resposta não vier na ponta da língua, releia o Proof Gate: ele é o único que transforma "funciona" de opinião em fato. A seguir (18): abrimos o Council e o Verifier por dentro — como um board delibera, agrega votos e por que o verifier observa em vez de votar.