Alembic Completo · Passo 8 de 8 · Encerramento

Glossário visual

O curso inteiro cabe em um vocabulário. Aqui estão os termos canônicos do motor — cada um com definição, âncora real no código, a confusão que ele costuma causar e a prática que o fixa. É a carta de navegação para tudo que você leu de L0 a L4, mais um teste honesto para fechar.

Ou abra um por vez ao longo da página.

Por que um glossário no final

Um termo mal entendido é um bug esperando para acontecer. Quando alguém acha que Result "às vezes lança", ou que o frontier "vê o corpus inteiro", ou que MAX_DEPTH é só uma sugestão, a próxima mudança de código quebra uma invariante sem perceber. Este glossário existe para que isso não aconteça.

O que assumimos de você aqui

Você passou pelas lições de L0 a L4 — ou pelo menos quer um mapa rápido de tudo.
Você não precisa decorar nada: o glossário é para consultar, não para memorizar.
Você quer saber onde cada conceito vive no código, não só o que ele significa.

Ao fim desta lição você consegue

Nomear cada uma das 5 camadas e o que cada uma garante.
Explicar a cintura estreita (Result never-throws) e por que tudo passa por ela.
Descrever o funil T0→T3 e onde cada portão fail-closed atua.
Recitar as 6 invariantes que o Reviewer caça em todo PR.
Achar a âncora de arquivo de qualquer termo quando for mexer no código.

Por que ler a carta antes de mexer no código: o entendimento certo impede o bug na origem.

Guarde isto Um glossário vivo é parte da arquitetura. Cada termo aqui tem 1+ âncora real (arquivo:linha). Quando você for tocar código que mexe num conceito, volte aqui antes — é mais barato reler a carta do que reaprender pelo bug.

O mapa das camadas

As cinco camadas formam uma esteira: o item entra cru na L0, é processado pelo funil, passa por adapters (L1) que falam com modelos, é avaliado pelo council (L2), pode ser dividido em tarefas pelo swarm (L3), e tudo é orquestrado pelo harness (L4). Duas faixas atravessam todas: a factory (que constrói o próprio Alembic) e os cross-cutting (PII, budget, design).

Diagrama das cinco camadas do Alembic (L0 Contracts+ETL, L1 Adapters, L2 Council, L3 Swarm, L4 Harness) dispostas como estações da esquerda para a direita, atravessadas por uma faixa central rotulada 'cintura estreita — Result never-throws', com cartões satélite de Factory ADW e cross-cutting PII/Budget/Impeccable e uma legenda de cores.

As 5 camadas + a cintura que as une + as duas faixas transversais. Toda a engine fala apenas com a cintura.

Clique em uma camada para filtrar o glossário abaixo por ela

Leitura do mapa: as setas vão sempre na mesma direção (L0→L4). Nada "sobe" — uma camada nunca importa de uma camada acima dela. A faixa da cintura toca todas porque toda chamada que pode falhar devolve Result, em qualquer lugar do sistema.

Glossário interativo

Busque por nome (ex.: Result, MAX_DEPTH, verifier) ou filtre por camada. Cada carta traz a definição, as âncoras reais no código, a confusão comum e uma prática curta. Os termos abaixo são o vocabulário canônico do motor.

Mostrando todos os 20 termos

Result (discriminado) L0

União ModelRunResult = Success | Failure com discriminante ok: boolean. Toda operação que pode falhar — em especial chamadas de modelo — nunca lança e sempre devolve este tipo.

contracts/result.ts:20 (def + tryCatchAsync:60)
contracts/model.ts:30 (ModelRunResult)
adapter-core.ts:60 (guardedAttempt → Result)

Confusão comum: "posso dar throw dentro do adapter e tratar no chamador". Não. O contrato público é Result; qualquer exceção interna vira failure tipado antes de subir.

Prática: escreva um teste que força um attempt a lançar e confirme que o Result final é failure (e o circuit-breaker recebeu o feedback).

ModelAdapter (cintura estreita) L1

Interface mínima: { id, run(input): Promise<ModelRunResult> }. Várias implementações (cliproxyapi, local, offline, retry, breaker, cost…). Todo o sistema — funnel, council, swarm, factory — fala apenas com esta interface.

contracts/model.ts:30 (def)
adapter-core.ts:23-100 (runWithGuards spine)
registry.ts (createAdapterRegistry) · router.ts (pickAdapter)

Confusão: "vou chamar o SDK direto para economizar uma camada". Quebra a cintura, perde retry/breaker/custo e viola a invariante de nunca lançar.

Prática: adicione um provider fake no registry e rode um distill offline. Trace a chamada até o Result retornado.

runWithGuards L1

Spine reutilizável que transforma uma "tentativa única" num ModelAdapter compliant: validação → circuit-breaker → attempt → retry (com backoff) → feedback no breaker → Result (nunca throw).

adapter-core.ts:23-100 (fluxo completo)
adapter-core.ts:82-100 (guardedAttempt)
adapter-core.test.ts (429 + breaker half-open)

Confusão: "o retry é responsabilidade do provider". Não. Retry e breaker são cross-cutting e vivem no guard; o provider só implementa attempt.

Prática: force um 429 no provider fake e observe o retry + o breaker em half-open.

Funnel Tier (T0–T3) L0

Pipeline de ETL barato em 4 estágios. T0 = determinístico 100% ($0, SHA-256 incremental). T1 = LLM local. T2 = frontier batched. T3 = Council GO/PIVOT/NO-GO (~$0,03, gated pelo verifier).

harness/funnel.ts:83 (runFunnel)
etl/pipeline.ts:27 (runT0Pipeline)

Confusão: "T2 toca todo o corpus". Falso. O frontier só vê a shortlist do T1 (centenas de itens, não 128k).

Prática: rode alembic distill … --offline sobre o fixture e conte quantos itens cada tier processou.

priorFor + routesToResidue L0

Heurística determinística do T0 que atribui um prior de sinal por família (Transcripts alto, Unknown baixo) e decide se o item vai para o residue (baixa prioridade) ou segue para a extração T1.

etl/priors.ts (priorFor + routesToResidue)
etl/pipeline.ts:27 (runT0Pipeline)

Confusão: "tudo vai para o LLM". Não — o T0 já descarta ou rebaixa a maior parte do volume antes de qualquer chamada paga.

Prática: inspecione o residue de um run T0 e veja quais famílias dominam.

Verifier (maker-checker) L2

Gate T3+ que separa debate (maker) de verificação independente (checker). Usa oráculos puros (ClaimOracle) sobre a evidência. Abaixo do mínimo de agentes válidos ou falha numa lente → NO-GO ou park T4.

council/verifier.ts:19-84 (ClaimOracle + oracles)
council/verifier-panel.ts:21-44 (3 lentes)

Confusão: "o council é só prompt de debate". Falso — o verifier é código determinístico que pode vetar o debate inteiro.

Prática: abra verifier-panel.test.ts e rode um GO com evidência zero → observe o veto de faithfulness.

preserve-dissent veto + Verifier Panel L2

3 lentes (coerência, faithfulness, domínio). Quorum 2/3 mais qualquer reject HARD (em especial faithfulness ou evidência-zero) bloqueia a emissão. O dissenso é preservado, não suprimido.

verifier-panel.ts:21-44 (lentes + veto)
verifier-panel.ts:40 (floors de faithfulness)

Confusão: "quorum resolve tudo". Não — o veto de dissent é hard e prevalece sobre o quorum.

Prática: simule um GO com confiança < 0,5 em faithfulness e veja o painel rejeitar.

Debate phases + contrarian-last L2

Ordem serial de fases no debate (otimista → analista → pessimista/contrarian por último). O contrarian vê tudo que foi dito antes e é obrigado a dissentir. Preserva diversidade de pensamento.

council/debate.ts:31-159 (phases + buildVote)
debate.ts:108-159 (fluxo do membro + priorPhases)

Confusão: "todos rodam em paralelo e só depois se olham". Não — o contrarian é último por design e recebe o histórico completo.

Prática: leia debate.ts:108-159 e simule um round de 3 membros; observe o contrarian recebendo as priorPhases.

MAX_DEPTH = 2 L3

Limite estrutural de profundidade no orquestrador 3-tier. Orchestrator = depth 0, Lead = 1, Worker = 2 (leaf). O worker nunca pode criar subtarefas. Previne explosão e recursão infinita.

swarm/types.ts:32 (MAX_DEPTH)
swarm/orchestrator.ts:31-46 (enforcement em canSpawn)

Confusão: "dá para aninhar workers à vontade". Não — a constante é hard e é checada em canSpawn.

Prática: tente criar uma tarefa com subtasks em depth 2 e observe o fail-closed.

Journal-before-action + replayInto L3

Todo estado de tarefa é journalado (append-only) antes da execução. Em crash, replayInto reconstrói o queue a partir do journal + park-ledger. Garante at-least-once sem double-spend em adapters pagos.

swarm/store.ts (journal + checkpoint)
swarm/orchestrator.ts (replayInto)

Confusão: "o resume re-executa tudo". Não — tarefas terminais são puladas; só órfãs em "running" voltam para ready.

Prática: mate um worker no meio do run e rode resume. Veja que tarefas já done não re-executam.

withWorktree (isolation + teardown) L3

Primitivo de resource-safety: cria worktree + branch, executa o worker dentro e faz teardown garantido no finally (sucesso, erro ou throw). Vazar worktree é erro grave.

swarm/worktree.ts (withWorktree + finally)
swarm/process.ts (runProcess endurecido)

Confusão: "em caso de erro o cleanup pode falhar". O design engole o erro de cleanup para não mascarar o sucesso do trabalho principal.

Prática: rode um task com isolate:true e confirme que o worktree some mesmo se o comando falhar.

Background (detached) workers + report-file L3

Workers que sobrevivem à morte do pai. O orchestrator coordena só via arquivo de report (.inprogress → .complete/.failed). Usado para comandos longos que não devem bloquear o slot.

swarm/background.ts (dispatcher + poll)
swarm/background-entry.ts

Confusão: "é fire-and-forget". Não — o orchestrator faz poll do report-file e re-attach no resume.

Prática: lance um background task, mate o processo pai, rode resume e veja o worker re-anexar.

HarnessCore (transport-neutral) L4

Núcleo de orquestração que expõe runFunnel + EventBus. Clientes finos (CLI, HTTP/SSE, MCP RO, console) só injetam adapters/stores e consomem o bus. O kernel não sabe como é chamado.

harness/core.ts:41-50 (HarnessCore)
harness/funnel.ts:83 (runFunnel) · harness/server.ts

Confusão: "o servidor HTTP é o coração". Não — o core é puro; o server é só um adaptador fino de transporte.

Prática: instancie HarnessCore com adapters fake e chame runFunnel direto (sem CLI nem HTTP).

distillAndMarket bridge L4

Composição runFunnel → runMarketingBatch (sinais verified-GO, PII-safe). Persiste cada AssetsManifest num store append-only content-addressed (Marketing/manifests.jsonl).

harness/bridge.ts:11-28
harness/manifest-store.ts

Confusão: "marketing roda só no produto". Não — o bridge já existe no harness; o próprio motor pode gerar criativos antes de entregar.

Prática: rode distillAndMarket offline com budget suficiente e inspecione o manifests.jsonl.

emitSafeSignal + assertRedactedForEmit Cross

Gate fail-closed de PII. Qualquer sinal de canal privado (whatsapp, discord, skool, circle) passa por redactSignal + assertRedactedForEmit antes de qualquer chamada de modelo ou write em store.

etl/pii.ts (assertRedactedForEmit + PRIVATE_CHANNELS)
harness/funnel.ts:243 (emitSafeSignal)

Confusão: "a redação acontece depois da chamada T1". Não — é feita no extractionInput, antes do adapter.run.

Prática: injete um pacote com PII plantada no fixture e confirme que o sinal emitido não contém dados sensíveis.

Budget fail-closed Cross

Antes de toda chamada paga (T2/T3) o budget é checado. Se excedido → fail-closed imediato (sem chamada). O spend é metrado pelo registry mesmo quando o adapter não devolve costUsd.

harness/funnel.ts (budget guard)
etl/budget.ts

Confusão: "override de modelo barato burla o cap". Não — o pricing sempre usa o tier do registry (pricingModelId), nunca o override.

Prática: rode o funnel com budget:0 e confirme que T2/T3 não executam e o run é marcado como budget-exhausted.

Content-addressed run Cross

Todo run (model, council, swarm, marketing) gera arquivos determinísticos baseados no hash do input + config. Permite replay exato, caching e convergência de re-runs.

etl/stores.ts (appendStoreRecord + hashOf)
harness/manifest-store.ts (dedupe por sha256) · swarm/store.ts

Confusão: "os IDs são UUIDs aleatórios". Muitos são content-derived (manifestId, alguns run dirs) para garantir idempotência.

Prática: rode o mesmo distill duas vezes (não-dry-run) e confirme que o manifestId é idêntico.

ADW (Agentic Development Workflow) Factory

Loop meta: Planner (gh issues) → N implementers paralelos em sandboxes → Reviewer adversarial → Publisher (abre PR). Gates typecheck/build/test/impeccable antes do PR. Nunca push direto em main.

.factory/run.ts:22-153 (loop completo)
packages/factory/src/Orchestrator.ts

Confusão: "é só um template de editor". Falso — é o sistema que constrói o Alembic usando o próprio Alembic (meta).

Prática: rode pnpm factory (com .env) e observe um ciclo planner → implementer → reviewer.

CODING_STANDARDS (invariantes de código) Cross

Regras duras: Result never-throws, sem any, funções puras ≤50 loc, early return, named exports, 2 espaços, aspas simples, conventional commits. O Reviewer caça violações ativamente.

.factory/CODING_STANDARDS.md
.factory/run.ts:95 (Reviewer usa o padrão)

Confusão: "é só estilo". Não — quebrar Result ou usar any é defeito de arquitetura, não de formatação.

Prática: rode o reviewer mentalmente sobre um PR seu: quantas linhas violam o ≤50 loc ou o "no upward dep"?

Impeccable detect (gate de design) Cross

Comando que roda em todo docs/ e reprova low-contrast, texto minúsculo, em-dash em excesso, abas laterais, kickers repetidos e fontes proibidas. É o "council visual" do projeto.

package.json (script detect)
docs/ (todos os artefatos didáticos passam)

Confusão: "é só lint de HTML". Não — é a constituição visual que garante que todo material seja legível, acessível e anti-slop.

Prática: rode impeccable detect docs/ após editar qualquer página e corrija até exit 0.

Nenhum termo casa com a busca. Limpe o campo ou troque o filtro de camada.

Dica de uso O glossário é um índice de leitura. A âncora arquivo:linha de cada termo é o melhor lugar para começar a entender o conceito de verdade — abra o arquivo, leia o teste ao lado, rode a prática. A definição aqui é só o mapa; o código é o território.

A cintura, em uma carta

Se você guardar um único conceito deste curso, que seja este. A cintura estreita é a razão de o Alembic ser confiável: existe um tipo — Result — pelo qual toda chamada que pode falhar passa, sempre, sem exceção lançada. Os dois cartões abaixo são a mesma ideia, em dois níveis.

Em uma frase: em vez de "tentar e torcer para não estourar", toda função devolve uma caixa que ou diz "deu certo, aqui está o valor" ou "deu errado, aqui está o motivo". Quem chama é obrigado a abrir a caixa e tratar os dois casos. Erro nunca vira surpresa.

Tecnicamente: ModelRunResult é uma união discriminada por ok. runWithGuards embrulha qualquer attempt que possa lançar com tryCatchAsync e converte exceções em { ok:false, error } tipado antes de retornar. Como o tipo de retorno público é Result, o compilador força o tratamento de ambos os ramos — não existe caminho "esqueci do erro".

Exemplo guiado · a vida de uma chamada que falha

O funnel pede uma extração ao adapter.run(input) na camada L1.

O provider real lança (timeout de rede). Dentro de runWithGuards, tryCatchAsync captura a exceção.

O guard alimenta o circuit-breaker, decide se faz retry com backoff e, esgotadas as tentativas, devolve { ok:false, error }.

O funnel recebe um Result failure — nunca uma exceção — e segue o caminho fail-closed (não emite, não cobra).

Agora você: percorra o mesmo caminho para um budget:0. Em que passo a chamada nem chega a tocar o provider? (Resposta: antes do passo 1 — o budget guard barra fail-closed.)

Pare e preveja

Um colega quer "só dar um throw rápido" dentro de um adapter novo para sinalizar um input inválido, e tratar lá em cima. O que o Reviewer (e o tipo) vão dizer?

Vão reprovar. O contrato público do adapter é Result; um input inválido deve virar { ok:false, error } tipado, não uma exceção. Lançar quebra a cintura, fura o retry/breaker e cria um caminho de erro invisível ao compilador.

Flashcard · cintura

O que toda chamada que pode falhar devolve?

clique para virar

Um Result<T,E> discriminado em ok — nunca lança. Exceções internas viram failure tipado antes de subir.

Flashcard · guards

De quem é o retry e o circuit-breaker?

clique para virar

Do runWithGuards (cross-cutting). O provider só implementa attempt; retry e breaker vivem no guard.

Flashcard · transporte

O servidor HTTP é o coração do harness?

clique para virar

Não. O HarnessCore é puro (runFunnel + EventBus). CLI, HTTP/SSE e MCP são só transportes finos que injetam adapters.

O funil barato

O segundo grande conceito: o Alembic gasta pouco porque descarta cedo e barato. O volume entra inteiro no T0 (de graça), e a cada tier sobra só uma fatia menor — até o council, que vê só o que sobreviveu aos portões.

Funil de quatro faixas (T0 determinístico $0 no topo largo, T1 LLM local, T2 frontier batched, T3 Council na ponta estreita) com três selos de portão fail-closed à esquerda (PII, Budget, Verifier) e um chip avisando que o frontier nunca vê 128k itens, ilustrando como o custo sobe enquanto o volume cai.

A largura da faixa é o volume; a cor mais quente é o custo. Descartar barato cedo é o que torna o caro raro.

Cada tier só vê o que o anterior deixou passar. O frontier nunca toca o corpus inteiro.

Os três portões fail-closed

Entre os tiers há três cadeados, todos fail-closed (na dúvida, barram): PII (assertRedactedForEmit, antes de tocar qualquer modelo), Budget (barra a chamada paga antes do provider) e Verifier (3 lentes + veto de dissent decidem o T3). Nenhum deles "deixa passar e corrige depois".

Lembre-se da L0: o T0 já decide o destino da maior parte do volume com priorFor + routesToResidue — sem nenhuma chamada paga.

As 6 invariantes load-bearing

Estas seis regras são o que impede regressão arquitetural. Não são estilo — são as vigas que sustentam o resto. O Reviewer da factory caça cada uma em todo PR.

Grade de seis cartões numerados em torno de um escudo central 'fail-closed por padrão', cada cartão nomeando uma invariante (Result nunca lança, Budget fail-closed, MAX_DEPTH=2, Verifier veta faithfulness, PII redigida antes de emitir, withWorktree teardown no finally) com a âncora de arquivo correspondente embaixo.

As 6 invariantes irradiando do princípio comum: fail-closed por padrão. Quebrar qualquer uma é defeito de arquitetura.

As 6 regras que o Reviewer nunca perdoa

Result nunca lança. Todo caminho que pode falhar devolve Result<T,E>. contracts/result.ts · contracts/model.ts
Budget fail-closed. Excedeu o budget → bloqueia antes de tocar o provider. etl/budget.ts · harness/funnel.ts
MAX_DEPTH = 2. Orchestrator 0, lead 1, worker 2 (leaf). Worker não cria subtarefa. swarm/types.ts:32
Verifier veta. Faithfulness reprovada bloqueia a emissão, mesmo com quorum. council/verifier-panel.ts:21-44
PII redigida antes de emitir. assertRedactedForEmit antes de qualquer modelo ou store. etl/pii.ts
withWorktree faz teardown no finally. Sempre — sucesso, erro ou throw. swarm/worktree.ts

Cuidado Estas seis não têm "exceção rápida". "Só desta vez vou dar throw / pular o budget / aninhar um worker" é exatamente o tipo de mudança que passa nos testes locais e quebra a invariante em produção. Se precisar furar uma, a resposta certa é mudar o design — ou parar (T4) e pedir revisão humana.

Verifique · funil & gates

Cinco perguntas sobre o pipeline barato, o PII gate, o budget fail-closed e o que realmente roda em cada tier. Cada opção revela a explicação ao clicar; o placar abaixo soma seus acertos.

Knowledge check · O funil T0–T3

1 · Qual tier é 100% determinístico, roda a $0 e já exclui Repos/Models + Repos/Prompts?

T0. É o estágio determinístico ($0): SHA-256 incremental + priorFor/routesToResidue, já excluindo famílias como Models/Prompts. T1 já usa um modelo local; T3 é o Council, no fim do funil. etl/pipeline.ts:27 · etl/priors.ts

2 · Onde a redação de PII de canais privados acontece em relação à chamada de modelo no T1?

Antes do adapter.run. A redação é feita no extractionInput, no funnel, antes de qualquer chamada de modelo — é um gate fail-closed, não uma limpeza posterior. harness/funnel.ts:243 (emitSafeSignal) · etl/pii.ts

3 · O que acontece quando o budget é atingido antes de uma chamada T2 ou T3?

Bloqueada fail-closed. O budget é checado antes de toda chamada paga; excedido, a chamada nem toca o provider e o run é marcado como budget-exhausted. harness/funnel.ts (budget guard) · etl/budget.ts

4 · Por que o frontier (T2) só toca uma fração pequena do corpus?

Porque T0 e T1 já filtraram. O T0 rebaixa/descarta a maior parte via priors e residue, e o T1 (LLM local) entrega só uma shortlist de alta confiança. O frontier nunca vê 128k itens. etl/priors.ts · hotpath do funnel

5 · O que impede a emissão no T3 mesmo quando os votos somam GO?

O Verifier Panel. São 3 lentes (coerência, faithfulness, domínio); qualquer reject hard — em especial faithfulness ou evidência-zero — veta mesmo com quorum GO. council/verifier-panel.ts:21-44

Acertos: 0/5

Verifique · as invariantes

Seis perguntas sobre as regras que sustentam a arquitetura. Se você acertar todas, domina o que o Reviewer caça em todo PR.

Knowledge check · As 6 invariantes

1 · Toda chamada de modelo (do T0 à Factory) deve retornar um tipo que:

Sempre Result, nunca lança. É a invariante #1: união discriminada em ok; exceções internas viram failure tipado antes de subir. contracts/result.ts:20 · contracts/model.ts:30

2 · O que acontece se o budget for excedido antes de uma chamada T2/T3?

Bloqueada, fail-closed. Nenhum fallback silencioso para modelo barato — o pricing usa sempre o tier do registry, não o override. harness/funnel.ts · etl/budget.ts

3 · Qual é a profundidade máxima estrutural de tarefas no Swarm?

MAX_DEPTH = 2. Orchestrator 0, lead 1, worker 2 (leaf). Worker nunca cria subtarefa; a constante é checada em canSpawn. swarm/types.ts:32 · swarm/orchestrator.ts:31-46

4 · Se a lente de faithfulness falha (mas as outras passam e há quorum), o Panel:

Veto hard. O preserve-dissent prevalece sobre o quorum: faithfulness reprovada bloqueia a emissão. council/verifier-panel.ts:21-44 · verifier-panel.ts:40

5 · Antes de um sinal de canal privado ir ao store ou a um modelo, o que ocorre?

Redação fail-closed. redactSignal + assertRedactedForEmit rodam no extractionInput, antes de qualquer modelo ou write. etl/pii.ts · harness/funnel.ts:243

6 · O que o withWorktree garante mesmo quando o worker lança ou é abortado?

Teardown no finally. O cleanup roda sempre; o design ainda engole erro de cleanup para não mascarar o sucesso do trabalho principal. swarm/worktree.ts (withWorktree + finally)

Acertos: 0/6

Recapitulando o curso inteiro

Você chegou ao fim do currículo fonte-de-verdade. O slide-deck abaixo reconstrói a jornada: as 5 camadas, a cintura que as une, os hot paths que ligam tudo e o playbook do operador. Use as setas (ou ← →) para passar.

Recap · A esteira

Cinco camadas, uma direção

O item entra cru na L0, é filtrado pelo funil, passa por adapters (L1), é julgado pelo council (L2), pode virar tarefas no swarm (L3) e é orquestrado pelo harness (L4). Nada sobe: nenhuma camada importa de cima.

Recap · L0

Contracts + ETL: a fundação barata

Result e o ModelAdapter nascem aqui, e o funil T0 já decide o destino da maior parte do volume com priorFor — de graça, antes de qualquer modelo. Descartar barato cedo é a primeira regra.

Recap · L1

Adapters: a cintura que nunca lança

Todo o sistema fala com uma interface mínima. runWithGuards embrulha cada tentativa com validação, retry e circuit-breaker e sempre devolve Result. O erro nunca vira surpresa.

Recap · L2

Council: debate que pode ser vetado

O debate (maker) é separado da verificação (checker). O Verifier Panel — 3 lentes + veto de dissent — pode barrar um GO inteiro. Confiança vem de código determinístico, não de prompt.

Recap · L3

Swarm: paralelo com freios

MAX_DEPTH = 2 impede recursão; o journal-before-action torna o resume seguro sem double-spend; o withWorktree garante teardown no finally. Concorrência sem caos.

Recap · L4 + hot paths + operador

Harness: o núcleo que tudo orquestra

O HarnessCore expõe runFunnel + EventBus; CLI, HTTP/SSE e MCP são transportes finos. Os hot paths (funnel, council T3, factory ADW) costuram as camadas, e o operador dirige tudo pelos comandos e gates fail-closed (PII, budget, verifier).

Slide 1 / 6 Use ← →

Contracts + ETL

Result, Zod, priors, funil T0 a $0.

Adapters

A cintura: runWithGuards, retry, breaker, never-throws.

Council

Maker-checker, 3 lentes, veto de dissent.

Swarm

MAX_DEPTH 2, journal, worktree, background.

Harness

Core puro, runFunnel, EventBus, bridge.

O fio que costura tudo: uma cintura estreita (Result), gates fail-closed (PII, budget, verifier), runs content-addressed (replay) e o journal-before-action. Esses quatro princípios reaparecem em cada camada — é por isso que o motor é previsível.

Próximos passos

Este glossário é vivo: novos termos entram quando um conceito se estabiliza em três ou mais lugares com âncoras reais. Daqui, escolha por onde aprofundar.

Releia uma camada

Volte às lições de L0 a L4 com este vocabulário na mão — agora cada termo tem um lugar no mapa, e a leitura rende muito mais.

Abra as âncoras

Pegue três termos que ainda te confundem, abra os arquivos arquivo:linha no editor e rode a prática de cada um. O código é o território.

Siga os hot paths

Releia o passo 6 (Hot paths) traçando o funnel, o council T3 e o factory ADW termo a termo — é onde as camadas se costuram de verdade.

Volte ao playbook

Com o passo 7 (Playbook do operador), rode os comandos e provoque cada gate fail-closed (budget:0, PII plantada) para vê-los barrar.

Para onde ir agora

Voltar ao índice do curso →

O índice tem as oito etapas em ordem. Releia qualquer camada que ainda não esteja firme — e da próxima vez que for mexer no código, comece por este glossário.

Encerramento. Se você consegue explicar, sem olhar, a cintura estreita, o funil T0→T3 e as 6 invariantes, você entende o Alembic no nível em que ele foi construído. Era esse o destino do curso. Bom trabalho — e até a próxima leitura do código.