Curso do Produto Alembic · Visual Course

Casos de uso ponta a ponta

A história completa, numa página: do corpus de IA jurídica ao signal "fábrica de petições personalizadas", à campanha da C.D Advocacia, até a funcionária Iris — cada passo um comando real que você roda e verifica.

Leia primeiro (fonte primária)

REVIEW.md — "A história as-built completa do motor (98 PRs, 27 pacotes, 1364 testes verdes)"

Esta lição destila o REVIEW.md numa só coisa: as três jornadas reais que costuram TODOS os pacotes do Alembic num organismo único — e mostra onde o $0 vira gasto.

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

A grande ideia

O que assumimos de você (muito pouco)

Você abriu pelo menos uma lição anterior — ou pelo menos sabe que o Alembic tem dois lados: um motor de destilação e um harness de agentes.
Você consegue colar um comando num terminal. Não precisa programar.
Você quer ver as peças juntas, não mais uma peça isolada. Esta é a lição que amarra tudo.

As sete lições anteriores ensinaram peças: o funil, os tijolos atômicos, o swarm e os gates, o AI Employee, a marketing factory, a factory/forge. Esta lição final não ensina nenhuma peça nova — ela encadeia as peças em três jornadas reais, ponta a ponta, todas dentro do mesmo exemplo recorrente do curso.

Pense em três caminhos que partem de uma só matéria-prima — um corpus de IA jurídica (transcripts, bookmarks, repos, notas):

Fluxo A — do corpus à venture: destile o corpus, ele cospe BUSINESS SIGNALS; um signal (“fábrica de petições personalizadas”) vira uma venture rodada pelo harness.
Fluxo B — a campanha de um cliente: descubra o brief da C.D Advocacia, gere a campanha em dry-run $0, e só então (gated) gere o vídeo de verdade.
Fluxo C — contratar a funcionária: defina a Iris, inspecione-a, rode um turno em preview offline, e só então (gated) coloque-a --online com memória que persiste.

Pense como… uma destilaria que abastece toda uma vila: o mesmo alambique central enche vials de conhecimento e oportunidade (A), e dessas oportunidades nascem oficinas — uma fábrica de campanhas (B) e uma artesã contratada que atende o balcão (C). Onde a analogia quebra: numa vila real você não tem um interruptor que separa “ensaiar de graça” de “gastar dinheiro de verdade” — no Alembic você tem, e ele é o herói desta lição.

O losango é a decisão: a partir do mesmo corpus, o que você quer determina o fluxo — uma venture (A), uma campanha de cliente (B) ou uma funcionária (C). Os três convivem.

Por baixo do capô

Os três fluxos não são features separadas: são composições da mesma cintura estreita. Todo comando devolve Result<T, Error> de @alembic/contracts (sucesso-ou-erro como valor, nunca exceção), todo IO passa por FsPort de @alembic/etl, e todo comando roda offline determinístico ($0) por padrão. O Fluxo A usa @alembic/etl (funil) + @alembic/swarm/@alembic/harness (orquestração). O Fluxo B usa @alembic/marketing-factory. O Fluxo C usa @alembic/hermes/employee. Os três escrevem em stores append-only sob .alembic/.

A regra que se repete nos três: nenhum flag sozinho gasta. Rede real = --online; geração paga de vídeo = --approve e --yes juntos. É a trava de gasto, e ela é estrutural — está no parser de args, não num “cuidado” verbal.

O que você vai conseguir fazer

Ao fim desta lição você consegue

Rodar o Fluxo A: distill um corpus e ler os BUSINESS SIGNALS que viram uma venture.
Rodar o Fluxo B: marketing discover da C.D → marketing campaign em dry-run $0.
Rodar o Fluxo C: definir a Iris e usar employee show/explain/run em preview offline.
Apontar, em qualquer um dos três, exatamente onde o $0 vira gasto real — e que flag abre cada trava.
Encadear os três num único roteiro reproduzível, verificando cada passo na fronteira real.

A história em um mapa

Um só diagrama, da matéria-prima à funcionária. Leia da esquerda para a direita: a mesma origem (o corpus) ramifica nos três fluxos desta lição.

O mapa mestre — esquerda → direita: o corpus destila em duas saídas; o signal vira venture (A); a venture serve a campanha da C.D (B); a Iris opera tudo (C). Cada lição anterior viveu numa caixa deste mapa.

Faça uma aposta antes de continuar

Quantos dos três fluxos, rodados em sua forma padrão (sem nenhuma flag extra), gastam dinheiro ou tocam a internet?

Zero. Os três fluxos, na forma padrão, são offline e $0. distill roda --offline; marketing campaign é dry-run em toda etapa; employee run imprime um preview sem chamar modelo. Gastar exige flags explícitas — e é isso que a seção “O que é gated” destrincha.

A wide overhead illustration of a single glowing copper distillation still at the left of a workshop bench, its output splitting into three warm curving pipes that each run to a di — A wide overhead illustration of a single glowing copper distillation still at the left of a workshop bench, it

Fluxo A · do corpus à venture

O primeiro fluxo é o porquê do Alembic existir: transformar conhecimento bruto em oportunidade acionável, sem humano no meio. Você aponta o funil para um corpus, ele roteia cada item por tiers (T0→T3) e deposita duas saídas — LEARNINGS (o que aprendeu, citável) e BUSINESS SIGNALS (o que fazer com isso).

Fluxo A — distill --offline roteia o corpus por T0→T3 e deposita LEARNINGS + opportunity; status confirma os stores; um signal escolhido vira um run com goal+plan no harness, que materializa a venture.

A sequência real, passo a passo (cada linha é um comando que você cola):

terminal · Fluxo A (offline, $0)

# 1. destile o corpus — offline, determinístico, $0
alembic distill ~/corpora/ia-juridica --offline

# 2. confirme o que o funil depositou (os dois stores)
alembic status
# → default tier T4 · phases: discover -> validate -> design -> plan -> build -> review -> ship
# → stores: 4 opportunity, 0 learnings

# 3. um BUSINESS SIGNAL ("fábrica de petições personalizadas") vira um escopo;
#    o harness o forja em venture (gates: Scope→Council→Proof→Validator→Publish)
alembic run --goal GOAL.md --plan alembic.plan.ts --yes

A saída real, verbatim. O passo 2 imprime exatamente:

default tier T4 · phases: discover -> validate -> design -> plan -> build -> review -> ship · stores: 4 opportunity, 0 learnings

. Aquele 4 opportunity são quatro BUSINESS SIGNALS prontos para virar venture — incluindo o nosso.

Por baixo do capô

O funil vive em @alembic/etl (lição 0002). Ele lê o corpus por FsPort (nunca fs direto), roteia cada item por tiers — T0 hermético, T1 cita o evidence field, até T3 — e deposita em dois stores append-only sob .alembic/. --offline garante $0 e determinismo (o VM rejeita Date.now()/Math.random() no plano). PII falha fechado.

O passo 3 é o harness (lições 0004): run --goal GOAL.md --plan alembic.plan.ts executa uma mission com units[] e proof[] — cada proof[] é um bash -c que falha fechado se sair não-zero. Os cinco gates (Scope → Council → Proof → Validator → Publish) liberam o passo seguinte. --yes evita a pausa interativa; tarefas tier T4 ainda param para o humano (approve/reject/propose).

O funil tem DUAS saídas, não uma: LEARNINGS (o que aprendeu, para consulta) e BUSINESS SIGNALS (o que fazer, para virar venture). O Fluxo A pega o segundo.

Guarde istoO Fluxo A é o motor inteiro num arco: corpus → (funil) → SIGNALS → (harness) → venture. As lições 0002 e 0004 ensinaram as duas metades; aqui elas se tocam.

Fluxo B · a campanha da C.D Advocacia

O segundo fluxo é uma venture servindo um cliente real. A C.D Advocacia (cliente #1) quer um vídeo. Você não escreve o brief à mão: parte de um pedido fino (“nome + o que querem”) e a fábrica descobre o brief rico, depois roda a campanha inteira em dry-run $0 — e só gera o vídeo de verdade quando você abre as duas travas juntas.

Fluxo B — marketing discover engorda um request fino num ClientBrief; marketing campaign roda discover→gerar→validar com a Higgsfield FALSA (offline) e devolve dryRun:true. A geração paga (linha tracejada) só dispara com --approve --yes juntos.

A sequência real — note que o request.json é exatamente o que os testes do produto usam:

request.json · o pedido fino da C.D (verbatim dos testes)

{
  "client": { "name": "C.D Advocacia", "website": "https://cd.adv.br" },
  "ask": "vídeo vertical cinematográfico em pt para reels"
}

terminal · Fluxo B (dry-run, $0)

# 1. descubra o brief rico a partir do pedido fino — offline $0
alembic marketing discover request.json --out brief.json
# → C.D Advocacia · video: cinematic 9:16 (pt) · provenance: offline-request

# 2. rode a campanha inteira em DRY-RUN — zero rede, zero gasto, em TODA etapa
alembic marketing campaign request.json --out plan.json
# → discover→briefToSignal+briefToFactoryOptions→runMarketingFactory(offline)
# → →validationPlan→cost preview ; dryRun:true

# 3. SÓ AGORA, gated: geração paga de verdade (as DUAS travas juntas)
alembic marketing campaign request.json --approve --yes

O parseAsk deriva determinísticamente os campos do vídeo a partir do texto livre — 2 campos viram um brief completo, e o que ele não sabe fica no default do schema (nunca fabricado).

A trava de gasto, em uma frase

marketing campaign request.json sozinho toca zero rede e gasta zero. --online liga a pesquisa real (brightdata, custa). --approve --yes juntos ligam a geração paga de vídeo. Um flag sozinho NUNCA gasta — é a mesma regra do marketing video.

Por baixo do capô

Tudo em @alembic/marketing-factory (lição 0006), o real CLI higgsfield atrás de uma anti-corruption layer. discoverClientBrief usa parseAsk para extrair determinísticamente a spec do vídeo (aspect/type/language/durationSec/hasSpeech) do texto livre; campos desconhecidos ficam no default do schema (nunca fabricados). briefToSignal projeta o brief de volta em businessSignalSchema para a fábrica existente consumir sem mudança.

runCampaign é o capstone do domínio: dry-run / $0 em cada estágio. briefToValidationPlan é PLAN-ONLY — descreve os critérios que um QA real aplicaria (aspect/lang/checkTranscript/brand/forbiddenVisuals), mas validateVideo não roda (não há artefato real no dry-run). Três travas opt-in: --online (pesquisa real, founder-gated), e --approve + --yes juntos (geração paga). Fail-closed em todo lugar.

Fluxo C · contratar e rodar a Iris

O terceiro fluxo coloca uma funcionária para operar o atendimento da venture. A Iris não é código novo: é uma composição — uma identidade (soul) + skills + memória multi-store + connectors + agenda, declaradas num único JSON. Você a inspeciona, entende como ela transforma um objetivo em ação, e roda um turno em preview offline antes de gastar um centavo.

Fluxo C — iris.json compõe 5 partes; show/explain/connectors/schedule inspecionam sem gastar; employee run dá o preview $0; --online chama o modelo e o write-back A3b persiste UM registro episódico de volta nos bound stores.

A definição real da Iris (exatamente o shape dos testes do produto):

~/.alembic/employees/iris.json

{
  "id": "iris",
  "soul": {
    "agent": "support-agent", "name": "Iris",
    "role": "customer support specialist",
    "values": ["empathy", "precision"], "expertise": ["billing"]
  },
  "skills": ["issue-triage", "meeting-notes"],
  "memory": { "agentId": "support-agent", "stores": ["episodic", "decision"] },
  "connectors": ["gmail", "slack"],
  "schedule": [{ "task": "sweep the support inbox", "cron": "0 9 * * 1" }]
}

terminal · Fluxo C (preview offline, $0)

# 1. liste e inspecione — quem é a Iris, o que ela compõe
alembic employee list
# → iris  Iris (customer support specialist)  skills:2  connectors:2

# 2. o mapa "reverse-engineer an agent" (observed/inferred/unknown)
alembic employee explain iris --goal "responder a dúvida de cobrança de um cliente"
# → 10 passos; planning+memory-update = observed; o resto inferred; unknown:2

# 3. o seam de connectors (todos unwired offline — adapters founder-gated)
alembic employee connectors iris
# → gmail unwired (no adapter) · slack unwired · note: real adapters founder-gated

# 4. as agendas → manifests de automação (PAUSED, registrável, não auto-roda)
alembic employee schedule iris
# → emp-iris-0 [PAUSED] 0 9 * * 1 claude-opus-4-8 · task: sweep the support inbox

# 5. rode UM turno — preview $0, NENHUM modelo chamado
alembic employee run iris --goal "responder a dúvida de cobrança de um cliente"
# → dry-run preview — no model called · model claude-opus-4-8
# → --- system (would be sent) --- You are Iris, customer support specialist. …

# 6. SÓ AGORA, gated: chamar o modelo de verdade + write-back episódico
alembic employee run iris --goal "…" --online

A régua honesta — dos 10 passos, só planning e memory-update são observed; o resto é inferred, e dois são unknown. O mapa nunca finge saber o que não pode inspecionar.

Por que isto é honesto. O employee explain tagueia cada um dos 10 passos como observed (lido da config), inferred (comportamento padrão do motor) ou unknown (interno não inspecionável). É a regra anti-fabricação estrutural: o mapa nunca afirma que um subsistema ainda-não-construído (runtime de connector, runner de scheduler) está operacional.

Por baixo do capô

Tudo em packages/hermes/src/employee/ (lição 0005). employee run sem flag chama buildEmployeeRunInput (PURO, determinístico): monta o system-prompt (renderEmployeePrompt = soul + ## Skills + ## Connectors + memória composta dos bound stores) e imprime o preview spend-safe — “o prompt que seria enviado” — sem chamar modelo. O modelId sai de soul.modelPreferences.primary ?? fallback ?? local-default.

--online (founder-gated) constrói o adapter real cliproxyapi (preflighted; fail-closed se o gateway/token faltar — sem gasto). O write-back A3b (#102): após um turno --online bem-sucedido, recordEmployeeTurn anexa UM registro episódico HONESTO (o goal real + um excerto da resposta, nunca um “aprendizado” fabricado) ao store episódico bound. É opt-in (sem binding episódico → no-op) e uma falha de escrita nunca quebra o turno. --no-memory-write desliga.

A wide illustration of an artisan reception desk where a friendly assistant figure stands ready, beside her a transparent glass panel showing a layered blueprint of her makeup: an — A wide illustration of an artisan reception desk where a friendly assistant figure stands ready, beside her a

O que é gated · $0 por padrão vs. gasto real

Esta é a seção que você precisa lembrar mais que qualquer outra. Nos três fluxos, o Alembic roda offline e $0 por padrão. Gastar dinheiro ou tocar a internet sempre exige uma flag explícita — e nenhuma flag sozinha gasta. Aqui está o mapa completo de todas as travas dos três fluxos num só diagrama.

O mapa do que é gated — a zona livre (esquerda) tem TODOS os comandos padrão, offline e $0. A parede tracejada é a trava. A zona de gasto (direita) só abre com a flag exata: --online para rede, --approve --yes juntos para geração paga, e a pausa T4 para o humano no harness.

O padrão é sempre a barrinha sólida no chão: $0. As barras tracejadas (o custo) só existem quando você abre a trava do fluxo — e nunca são acidentais.

Demo: o que esta combinação de flags realmente faz?

Ligue e desligue as flags e veja, ao vivo, se o comando fica spend-safe ou se entra na zona de gasto. (Demo construído para esta lição.)

comando base: alembic marketing campaign request.json

$0 SPEND-SAFEDry-run: discover→gerar(offline)→validationPlan→cost preview. Zero rede, zero gasto. Nenhuma flag ligada → o padrão. Tudo determinístico, escreve só em .alembic/.

A regra de ouro

Um flag sozinho nunca gasta. --approve sem --yes continua dry-run. --yes sem --approve continua dry-run. Só os dois juntos liberam a geração paga.

Por que estrutural

A trava vive no parser de args (apps/cli/src/args.ts), não num aviso verbal. O default é fail-closed: o caminho de gasto precisa ser escolhido, nunca é acidental.

Os dois caminhos lado a lado: o dry-run (esquerda) é o padrão e prova o $0; o real (direita) só é alcançado atravessando a trava (🔒) com a flag exata.

Cuidado“Gated” não é “quebrado”. Se você roda --online sem o gateway/token configurado, o comando falha fechado (erro claro, sem gasto) — ele não silenciosamente finge ter feito. Falta de credencial = erro honesto, não um custo surpresa.

Encadeando os três ponta a ponta

Agora o capstone de verdade: um único roteiro que vai do corpus à Iris, encadeando os três fluxos. Cada passo é verificável na fronteira real — e tudo abaixo é $0.

Worked example · do corpus à funcionária (offline, $0)

Destile o corpus. alembic distill ~/corpora/ia-juridica --offline → roteia por T0→T3, deposita LEARNINGS + opportunity. Verifique: alembic status imprime stores: 4 opportunity, 0 learnings.

Confirme o signal. Entre os 4 opportunity está “fábrica de petições personalizadas”. Verifique: o número 4 opportunity no status é a prova de que o funil cuspiu signals acionáveis.

Forje a venture (Fluxo A). alembic run --goal GOAL.md --plan alembic.plan.ts --yes → o harness corre os 5 gates. Verifique: proofs em units/<id>/proof-results.jsonl; falha fechada se algum proof[] sair não-zero.

Descubra o brief da C.D (Fluxo B). alembic marketing discover request.json --out brief.json → C.D Advocacia · video: cinematic 9:16 (pt) · provenance: offline-request. Verifique: provenance: offline-request prova que nenhuma rede foi tocada.

Rode a campanha em dry-run. alembic marketing campaign request.json --out plan.json → dryRun:true. Verifique: o campo dryRun:true no plan.json é a prova de $0.

Contrate a Iris (Fluxo C). alembic employee list → iris Iris (customer support specialist) skills:2 connectors:2. Verifique: employee connectors iris mostra tudo unwired (adapters founder-gated).

Rode o turno em preview. alembic employee run iris --goal "responder dúvida de cobrança" → dry-run preview — no model called. Verifique: no model called + o bloco --- system (would be sent) --- mostram o prompt sem gasto.

(Gated) abra as travas só quando quiser. Fluxo B paga: --approve --yes. Fluxo C real: --online. Pesquisa real: --online. Sem nenhuma dessas, todo o roteiro acima é $0.

O roteiro inteiro como linha do tempo: sete passos $0 e verificáveis (verde), e só o passo 8 (tracejado) abre uma trava — e apenas se você quiser ir além do ensaio.

Agora você tenta (sem rodar nada)

No passo 5, você quer a campanha com pesquisa real (brightdata) mas sem gerar vídeo pago. Qual a linha exata?

alembic marketing campaign request.json --online. O --online liga a pesquisa real (custa); como você não passou --approve --yes juntos, a geração de vídeo continua dry-run/$0. Pesquisa real, geração ainda em ensaio — exatamente as travas independentes.

Os três fluxos, lado a lado

O mesmo organismo, três usos. Note o padrão que se repete: cada fluxo tem um modo padrão $0 e uma trava explícita para o caminho caro.

	Fluxo A · venture	Fluxo B · campanha	Fluxo C · Iris
Entrada	corpus de IA jurídica	request fino {client, ask}	iris.json (5 partes)
Pacote núcleo	`@alembic/etl` + `harness`	`@alembic/marketing-factory`	`@alembic/hermes/employee`
Comando central	`distill` → `run`	`marketing campaign`	`employee run`
Saída $0	SIGNALS + venture (gates)	plan.json (`dryRun:true`)	preview do prompt (no model)
A trava	tier T4 (pausa humana)	`--approve --yes` (vídeo)	`--online` (modelo)
Prova de $0	`status` stores	`provenance: offline-request`	`no model called`

Não são três produtos: são três fachadas sobre a MESMA fundação — a cintura estreita (Result + FsPort + offline-default) e os mesmos stores append-only sob .alembic/.

O mesmo fato, em duas alturas

Os três fluxos são o mesmo motor visto de três ângulos. Você sempre roda algo de graça primeiro (um ensaio), confere a prova de que foi de graça, e só então — se quiser — abre uma trava para o passo que custa. É como um estúdio onde você ensaia à vontade e só liga as câmeras (e a conta) quando decide gravar.

Os três compõem a mesma cintura estreita: Result<T, Error> + FsPort + offline-default. O Fluxo A é distill (T0→T3, 2 stores) → run (mission/units/proof, 5 gates). O Fluxo B é discoverClientBrief → briefToSignal/briefToFactoryOptions → runMarketingFactory (Higgsfield fake) → briefToValidationPlan (plan-only). O Fluxo C é loadEmployee → renderEmployeePrompt + memory composer → buildEmployeeRunInput (preview) / runEmployeeTurn (--online) + recordEmployeeTurn (write-back A3b). Stores append-only sob .alembic/.

Veja você mesmo (fonte primária)

apps/cli/src/commands.ts — o wiring real de cada comando dos três fluxos

Cada run<Command> devolve Result<T, Error>; os testes em commands.test.ts exercitam exatamente os shapes de entrada que você colou nesta lição (a Iris, o request da C.D).

A wide split-scene illustration: on the left side a clean rehearsal stage bathed in soft green light where three small artifacts (a product, a film reel, a desk bell) sit at rest w — A wide split-scene illustration: on the left side a clean rehearsal stage bathed in soft green light where thr

Pratique a memória

Clique em cada cartão para virar (ou tecle Enter/Espaço). Recuperar de cabeça fixa melhor que reler.

Fluxo A

Que comando prova que o funil depositou BUSINESS SIGNALS?

clique para virar

alembic status — imprime stores: 4 opportunity, 0 learnings. Os 4 opportunity são os signals.

Fluxo B

Qual campo na saída do discover prova que nenhuma rede foi tocada?

clique para virar

provenance: offline-request. Se fosse --online e aprendesse algo, viraria online-research.

Fluxo C

O que a Iris COMPÕE num só JSON?

clique para virar

soul (identidade) + skills + memória multi-store + connectors + agenda. Composição, não código novo.

Trava

Um único flag (--approve OU --yes) gasta dinheiro?

clique para virar

Não. NUNCA. Só --approve E --yes juntos liberam a geração paga. Um sozinho = dry-run.

Honestidade

Quais as 3 tags do mapa employee explain?

clique para virar

observed (lido da config), inferred (padrão do motor), unknown (interno não inspecionável). Anti-fabricação estrutural.

Capstone

Qual a origem comum dos três fluxos?

clique para virar

O mesmo corpus de IA jurídica. A → venture; B → campanha C.D; C → Iris. Um só exemplo, três ângulos.

Recapitulando em slides

Use as setas ← → ou os botões. Seis slides fecham a história inteira.

Uma origem

Tudo começa no corpus

Um corpus de IA jurídica é a matéria-prima única. Os três fluxos desta lição partem dele — nada é inventado no meio do caminho.

Fluxo A

Do corpus à venture

distill cospe SIGNALS; status prova (4 opportunity); run --goal --plan forja a venture pelos 5 gates.

Fluxo B

A campanha da C.D

marketing discover engorda o brief; marketing campaign roda tudo em dry-run $0. provenance: offline-request é a prova.

Fluxo C

A funcionária Iris

Um JSON compõe soul+skills+memória+connectors+agenda. employee run dá preview $0; --online chama o modelo e lembra.

A trava

$0 por padrão, gasto por escolha

Os três rodam offline e $0 por padrão. Gastar = flag explícita. Nenhum flag sozinho gasta — é estrutural, no parser de args.

O capstone

Um organismo, não sete peças

Funil, harness, gates, employee, marketing factory, factory/forge — costurados num só roteiro, do corpus à Iris, verificável passo a passo.

1 / 6setas ← →

Experimente

Caminhe pelo Fluxo A estágio por estágio com o stepper abaixo. Cada estágio mostra o comando real, a saída verbatim e se é livre ($0) ou gated. (Demo construído para esta lição — clique nos pips ou use os botões.)

Estágio 1 de 4

$0 livre

DicaRode o roteiro do worked-example inteiro num diretório de teste. Como tudo é offline e escreve só em .alembic/, você pode rm -rf .alembic e começar de novo sem efeito colateral.

Você chegou ao fim do curso — do corpus à Iris, três fluxos, uma história. Qual deles você vai rodar primeiro? Pegue o roteiro da seção 7, escolha um diretório de teste e verifique cada prova ($0). Dúvida frequente: “e quando eu quiser de verdade?” — aí você abre uma trava de cada vez, e o motor te diz exatamente o que vai custar antes de cobrar.

As Dez coisas para levar do curso inteiro

A síntese — não sete produtos soltos, mas um motor com os pacotes do curso orbitando, e os três fluxos saindo dele como raios. Um organismo único.

As Dez verdades do Alembic ponta a ponta

O Alembic tem dois lados: um motor de destilação (corpus → LEARNINGS + SIGNALS) e um harness de agentes (signal → venture).
Tudo roda offline determinístico ($0) por padrão; --online opta por um backend real (pode custar).
A cintura estreita é Result<T, Error>: funções de biblioteca devolvem sucesso-ou-erro como valor, nunca lançam.
O funil roteia por tiers T0→T3; T4 pausa para o humano (approve/reject/propose).
Uma mission tem units[] e proof[]; cada proof é um bash -c que falha fechado.
Os cinco gates — Scope → Council → Proof → Validator → Publish — liberam cada passo seguinte.
A marketing factory é multi-tenant e dry-run $0 por padrão; geração paga exige --approve --yes juntos.
Um AI Employee (a Iris) COMPÕE soul + skills + memória + connectors + agenda; não é código novo, é composição.
O mapa employee explain tagueia tudo como observed / inferred / unknown — anti-fabricação estrutural.
Nenhum flag sozinho gasta. A trava é estrutural, no parser de args; o caminho caro é sempre uma escolha explícita.

Revisão final

Três perguntas que cruzam os três fluxos. Sua pontuação corre no rodapé do card.

Você consegue operar o Alembic ponta a ponta?

1. No Fluxo A, qual comando confirma que o funil depositou BUSINESS SIGNALS?

É a (b). alembic status reporta o pipeline e os stores; os 4 opportunity são os BUSINESS SIGNALS prontos. Nenhuma rede é necessária — é a saída offline verbatim do RESOURCES.md.

2. No Fluxo B, você quer pesquisa real MAS sem gerar vídeo pago. O que passa?

É a (c). --online liga só a pesquisa real (brightdata). A geração paga de vídeo exige --approve E --yes juntos — um flag sozinho nunca gera. As travas são independentes.

3. No Fluxo C, o que prova que employee run (sem flag) NÃO gastou?

É a (a). O preview imprime o prompt que seria enviado e diz no model called. A (c) está errada: o write-back episódico só ocorre num turno --online bem-sucedido. A (b) está errada: offline, os connectors são todos unwired.

Acertos: 0/3

Recapitulando em uma linha: um corpus, três fluxos, um motor. Destile para achar a oportunidade (A), fabrique a campanha do cliente (B), contrate a funcionária que opera (C) — sempre $0 por padrão, gasto só quando você abre a trava.