Alembic · Blind Planning · Passo 3

Os três acordes

Mission (Droid) + Workflow (Claude) + Swarm (Kimi) — a mecânica extraída de cada um, as interfaces deles não copiadas — fundidos em verbos de um só arquivo: alembic.plan.ts, executado deterministicamente sob Loop Engineering.

Leia primeiro (fonte primária)

03-three-chords-spec.md — "Spec dos Três Acordes (Mission · Workflow · Swarm)"

Esta lição destila o spec de fusão real (docs/alembic/03-three-chords-spec.md, de 2026-06-21) e o PROMPT-BLIND-PLANNING.md §Fase 1–2. Toda regra, schema e nome de arquivo aqui sai de um documento real do repo — nada é inventado. O exemplo que seguimos a lição inteira é o plano feature-auth (discover → build → prove) do §2 do spec.

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

O que você vai conseguir fazer

Nomear os três acordes e dizer de qual ferramenta cada um foi destilado — Mission (Droid), Workflow (Claude), Swarm (Kimi).
Explicar por que o Alembic copia a mecânica, e não a UI — a regra de ouro "transcreva a partitura, não o palco".
Ler o alembic.plan.ts de feature-auth e apontar onde cada verbo (swarm, council, mission, parallel) entra no caminho.
Citar pelo menos quatro das regras de fusão R1–R10 e dizer quem as faz cumprir (prelude, VM, Proof Gate, roster).

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

Você fez os Passos 1 e 2: sabe que o harness é o produto e que toda afirmação precisa de evidência (comando + linha, path lido).
Você sabe ler um pseudocódigo simples. Não precisa dominar TypeScript — traduzimos cada trecho.
Você não precisa ter usado Droid, Claude Code ou Kimi. A gente explica o que cada um faz de relevante, do zero.

A ideia central

O blind planning tem duas fases. Na Fase 1, três investigações independentes fazem engenharia reversa de três ferramentas de agentes. Na Fase 2, a gente não junta as três interfaces num Frankenstein — a gente extrai a mecânica de cada uma e a reescreve como um verbo só do Alembic.

Pense em três bandas tocando músicas diferentes. Droid sabe rodar uma "missão": exige um contrato de aceite antes de começar e valida marco a marco. Claude Code sabe um "workflow": um script determinístico com fases e paralelismo, que dá pra retomar. Kimi sabe um "swarm": disparar muitos agentes pequenos sobre uma lista de itens.

O Alembic não quer ser a quarta banda nem colar pedaços das três. Ele escreve uma partitura nova — o arquivo alembic.plan.ts — que, numa só execução, chama o movimento "missão", o movimento "workflow" e o movimento "swarm" quando precisar. Os três acordes, numa só mão.

Pense como… transcrever as partituras de três bandas — não remontar o palco delas. Você ouve o que cada banda toca de melhor, escreve as notas numa pauta nova e rege você mesmo. A analogia quebra num ponto: aqui a "transcrição" é código tipado que a máquina executa igual toda vez — não interpretação de músico.

Por baixo do capô

A Fase 1 produz três relatórios de RE com piso de tamanho — droid-cli-missions-reverse-engineering.md, claude-code-dynamic-workflows-reverse-engineering.md e kimi-code-agent-swarm-reverse-engineering.md — e cada afirmação de comportamento precisa de prova: a string do binário + um path em disco, ou a linha de um brightdata scrape (a disciplina de evidência do Passo 2). A Fase 2 funde os três contratos numa interface única, AlembicHooks, executada pela VM do plano.

O ponto central do spec (§1): "Um único run pode misturar todos no mesmo arquivo. O Conductor executa o script deterministicamente; o LLM só gera/edita o arquivo antes do run." Ou seja: o modelo escreve a partitura; quem rege é uma máquina previsível.

Infográfico: três partituras distintas rotuladas Mission (Droid), Workflow (Claude) e Swarm (Kimi) à esquerda convergem por uma seta para uma única partitura nova chamada alembic.plan.ts, regida por um Conductor com a legenda HarnessCore; faixa abaixo diz mecânica extraída, interfaces não copiadas

Os três acordes viram uma só partitura. A mecânica de cada ferramenta é transcrita; a interface de cada uma fica para trás. Fonte: 03-three-chords-spec.md §1.

acordes fundidos (Mission · Workflow · Swarm)

verbos na interface AlembicHooks

regras de fusão R1–R10 (tabela master)

Não colamos as interfaces; transcrevemos a mecânica de cada uma para um único plano determinístico. Esse é o coração da Fase 2.

Os três acordes, em uma figura

Antes do detalhe, a visão de cima: cada acorde traz um verbo (ou um conjuntinho de verbos) para a partitura. Mission traz mission(); Workflow traz phase(), agent() e parallel(); Swarm traz swarm(). E há um verbo extra, council(), que é o portão de decisão GO/NO_GO entre as fases.

Três acordes → uma interface (AlembicHooks) → uma VM determinística. O council() é o quinto verbo, o portão entre fases. Fonte: 03-three-chords-spec.md §1, §3.

Antes de revelar — arrisque um palpite

Se o Alembic transcreve a mecânica e não a UI, o que ele deliberadamente deixa de fora de cada ferramenta?

A interface de usuário e o jeito de operar de cada uma: as telas do Droid, o REPL do Claude Code, o painel do Kimi. O que ele guarda é o comportamento que torna cada acorde confiável — o contrato-antes-do-run do Mission, o determinismo do Workflow, a rampa e o exclusive-deny do Swarm. "Transcreve a partitura, não o palco."

Tabela de fusão (o mapa lado a lado)

A forma mais rápida de "ver" a fusão é alinhar os mesmos conceitos nas quatro colunas. Cada linha é uma pergunta — "qual é a unidade atômica de trabalho?", "como se faz paralelismo?", "onde mora o estado?" — e cada ferramenta responde do seu jeito. A última coluna é como o Alembic unifica.

Pergunta	Missions (Droid)	Workflows (Claude)	Swarm (Kimi)	Alembic (unificado)
Unidade atômica	feature / unit	`agent()`	um `item` de `items[]`	unit / task
Paralelismo	validação por milestone	`parallel()`, cap 16	rampa 5 + 700 ms	configurável (cap 16)
Onde mora o estado	`~/.factory/missions/`	script + `cache.json`	`wire.jsonl` por agente	`~/.alembic/runs/`
Porta de entrada	`validation-contract`	`export const meta`	`prompt_template` + itens	prelude + plano tipado
Retomar	propose → approve	`resumeFromRunId`	`resume_agent_ids`	`args.resume` + checkpoint
Verbo no plano	—	—	—	`mission()` · `agent()/phase()/parallel()` · `swarm()`

Fonte: 03-three-chords-spec.md §4–6, §10 (Mapeamento RE → Alembic verb).

Por que isso importa: a tabela mostra que os três acordes respondem às mesmas perguntas — então não há contradição em fundi-los. Eles são três respostas a um problema comum (orquestrar agentes com confiabilidade), e o Alembic escolhe a melhor de cada e dá um nome só.

O DNA de cada acorde

Agora um por um. Cada acorde tem um "DNA" — o punhado de regras de comportamento que o tornam o que é. Use as abas para ver os três; depois a gente liga cada DNA a um trecho de código real.

O DNA dos três acordes, lado a lado. Cada um vira um verbo da interface AlembicHooks. Fonte: 03-three-chords-spec.md §4–6.

Acorde Mission · origem Droid

A obsessão do Mission é contrato antes de execução. Você não roda nada sem um validation-contract que diga o "done-when" comportamental; cada unit roda numa sessão fresca (sem contaminação de contexto); e cada marco passa por validators.

validation-contract antes de executar → checado no prelude; a VM aborta se ausente (regra R1).
1 feature ≈ 1 sessão fresca → freshSessionPerUnit: true por padrão (regra R9).
Runner programático → a VM chama o adapter por unit; não é um LLM ad hoc.
Validators de milestone → milestoneValidation.scrutiny + userTesting[]; handoff em units/<id>/handoff.json.

Acorde Workflow · origem Claude

A obsessão do Workflow é determinismo e retomada. O corpo do plano não pode ter relógio nem aleatório; ele é um script com export const meta literal, fases nomeadas e paralelismo limitado — e dá pra retomar de onde parou via cache.

Script determinístico → sem Date.now() / Math.random() no corpo (regra R2; a VM faz lint + esbuild).
export const meta = { ... } as const → metadados literais.
phase(name, fn) → emite eventos phase-started/finished; parallel(fns) com cap 16.
Resume por cache (prompt, opts) → args.resume + checkpoint em workflows/cache.json.

Acorde Swarm · origem Kimi

A obsessão do Swarm é fan-out controlado. Você dá um template com {{item}} e uma lista; ele dispara muitos agentes — mas com rampa (pra não explodir tudo de uma vez), um teto, e a regra de que só pode haver um swarm por turno do orquestrador.

prompt_template + {{item}} → obrigatório quando há items; mínimo 2 itens.
Rampa 5 + 700 ms → ramp: { initial: 5, intervalMs: 700 }; teto maxConcurrency: 16.
Exclusive-deny → uma swarm() por turno do orquestrador (regra R3, enforce pela VM).
wire.jsonl por agente (append-only, regra R10); fan-in agregado em aggregate.xml + summary.md.

Por que copiar a mecânica, e não a UI

A MECÂNICA (copiamos)

A UI (descartamos)

A regra de ouro: a UI é como cada time opera o agente; a mecânica é por que o agente é confiável. O Alembic só quer a segunda — ela é portável, testável e independe de qualquer tela. Copiar a UI seria copiar o palco; o valor está na partitura.

No código — o `alembic.plan.ts` de feature-auth

Aqui está a partitura real do exemplo do spec: o plano feature-auth. Leia de cima pra baixo como um caminho: primeiro um swarm read-only mapeia o código; um council decide se vale a pena seguir; um mission constrói em sequência; e dois validators em paralelo provam o resultado. Os três acordes, num arquivo só.

Infográfico de pipeline da esquerda para a direita: phase('discover') com swarm() read-only, depois council() como portão de decisão com saídas GO para baixo e NO_GO para tudo, depois phase('build') com mission() em units schema-api-ui em sequência, depois phase('prove') com parallel() de dois validators, e estação final park ou ship

O caminho de um único run que mistura os três acordes — o exemplo feature-auth. Fonte: 03-three-chords-spec.md §2.

alembic.plan.ts — o cabeçalho determinístico

export const meta = {
  name: 'feature-auth',
  description: 'Tracer bullet auth: discover → build → prove',
  phases: ['discover', 'build', 'prove'],
  version: 1,
} as const;

import type { AlembicHooks } from '@alembic/harness';

export async function run(h: AlembicHooks) {
  const { phase, mission, swarm, agent, parallel, council } = h;

CHORD: Swarm — exploração read-only (DNA Kimi)

  await phase('discover', async () => {
    await swarm({
      profile: 'explore',
      promptTemplate: 'Read-only audit of {{item}}. Return paths + facts. No edits.',
      items: ['api', 'ui', 'tests', 'migrations', 'docs'],
    });
  });

O acorde Swarm na prática: cinco agentes read-only mapeiam o terreno em paralelo (com rampa), e o resultado vira insumo para a decisão. Fonte: 03-three-chords-spec.md §2, §5.

GATE: Council — portão GO / NO_GO (regra R4)

  const verdict = await council({
    board: 'tech-council',
    question: 'GO to implement auth tracer bullet?',
  });
  if (verdict === 'NO_GO') return { stopped: true };  // zero workers

CHORD: Mission — units em sequência (DNA Droid)

  await phase('build', async () => {
    await mission({
      freshSessionPerUnit: true,
      units: [
        { id: 'schema', tier: 'T2',
          proof: ['pnpm test --filter schema'] },
        { id: 'api', tier: 'T2', dependsOn: ['schema'],
          proof: ['curl -sf http://localhost:3000/health'] },
        { id: 'ui', tier: 'T2', dependsOn: ['api'],
          proof: ['pnpm e2e --grep auth'] },
      ],
      milestoneValidation: { scrutiny: true },
    });
  });

CHORD: Workflow — validators em paralelo (DNA Claude; regra R5)

  await phase('prove', async () => {
    await parallel([
      () => agent({ profile: 'validator', tier: 'T3',
        prompt: 'Scrutiny vs validation-contract. Builder was NOT you.' }),
      () => agent({ profile: 'validator', tier: 'T3',
        prompt: 'User-testing: signup + login. PASS/FAIL with evidence.' }),
    ]);
  });
}

A interface que une os acordes

Todos os verbos vêm de uma só interface (packages/alembic/src/hooks.ts, planejado):

export interface AlembicHooks {
  phase(name: string, fn: () => Promise<void>): Promise<void>;
  agent(opts: AgentOptions): Promise<AgentResult>;
  parallel(fns: Array<() => Promise<AgentResult>>): Promise<AgentResult[]>;
  mission(opts: MissionOptions): Promise<MissionResult>;
  swarm(opts: SwarmOptions): Promise<SwarmResult>;
  council(opts: CouncilOptions): Promise<'GO' | 'NO_GO'>;
}

O alembic.plan.ts é açúcar sobre um tasks.json (o RunSpec Zod de @alembic/swarm) para a lógica complexa — condicionais, validators em paralelo. Para runs simples, dá pra escrever o tasks.json direto. Fonte: 03-three-chords-spec.md §3, §7.

Trace o caminho de feature-auth (exemplo guiado → agora você)

discover. swarm() dispara 5 agentes read-only (um por item: api, ui, tests, migrations, docs). Eles só leem e devolvem fatos + paths. Nada é editado.

portão. council() pergunta "GO?". Se a resposta é NO_GO, o return encerra o run — e nenhum worker de build é criado (regra R4).

build. mission() roda 3 units em ordem por dependsOn: schema → api → ui. Cada unit, sessão fresca; cada proof[] precisa sair com código 0.

prove. parallel() roda 2 validators ao mesmo tempo — scrutiny e user-testing. O prompt diz explícito: "Builder was NOT you" (regra R5).

agora você: em qual passo o acorde Swarm aparece? E em qual o acorde Mission? (Respostas: passo 1 = Swarm; passo 3 = Mission; passos 2 e 4 = Workflow + Council.)

As regras de fusão R1–R10

Fundir três coisas só funciona se houver regras que evitem caos. O spec tem uma "tabela master" de dez regras (R1–R10): cada uma diz o quê, de onde veio (qual acorde) e quem a faz cumprir. Esse "quem faz cumprir" é o que torna a fusão real, e não um desejo.

As dez regras não são desejos: cada uma nasce de um acorde (ou do Loop Engineering) e tem um mecanismo que a faz cumprir. Fonte: 03-three-chords-spec.md §9.

#	Regra	Origem	Quem faz cumprir
R1	`validation-contract` antes do runner	Mission	prelude gate
R2	plano determinístico	Workflow	VM lint + esbuild
R3	`swarm()` exclusivo por turno	Swarm	VM scheduler
R4	Council NO_GO → zero workers	Alembic	`HarnessCore.fanout` ✅
R5	validator ≠ builder	Loop Eng	roster + auditoria de log
R6	T4 → park ledger	Swarm	`classifyPark` ✅
R7	`proof[]` na shell real	Loop Eng	Proof Gate runner
R8	1 unit bounded por passo	Loop Eng	granularidade da unit
R9	sessão fresca por unit	Mission	reset de sessão do adapter
R10	`wire.jsonl` append-only	Kimi	writer do store

Fonte: 03-three-chords-spec.md §9 (Regras de fusão — tabela master). O ✅ marca o que o RE achou já implementado no repo.

R4 EM AÇÃO — Council NO_GO corta a árvore

R5 EM AÇÃO — validator ≠ builder

Cuidado — armadilha de iniciante Esquecer que R2 proíbe não-determinismo no corpo do plano. Um Date.now(), um new Date() ou um Math.random() dentro de run() quebra a retomada — a VM rejeita o plano no lint. Datas e ids vêm de args, nunca gerados na hora.

Experimente: escolha um acorde

Clique num acorde. À esquerda você vê o DNA dele; à direita, o trecho real de alembic.plan.ts que o usa. É a mesma coisa nas duas alturas — a regra e o código que a encarna.

mission

Acorde Mission

Contrato antes de execução. Cada unit roda em sessão fresca e cada marco passa por validators.

origem: Droid · spec §4

Você é o aluno e também o regente: pergunte-se "se eu escrevesse o alembic.plan.ts da minha tarefa, qual acorde abriria o run?" — quase sempre é o Swarm (mapear o terreno antes) ou o Mission (já sei o que construir). A seguir (0004): o Playbook do prompt cego — como colar os prompts, comparar N planos independentes, pontuar com rubrica e exigir as seções de entrega.

Recapitulando em 6 slides

A virada de chave

Três acordes, uma partitura

Mission (Droid) + Workflow (Claude) + Swarm (Kimi). A gente extrai a mecânica de cada um e a reescreve como um verbo do Alembic — não cola as três UIs.

A regra de ouro

A partitura, não o palco

Copiamos o comportamento que torna cada acorde confiável (contrato, determinismo, rampa). Descartamos a UI — telas, REPL, painel — porque ela é presa à ferramenta.

A partitura única

alembic.plan.ts

Um arquivo, uma interface (AlembicHooks), executado por uma VM determinística. O LLM só escreve o arquivo antes do run; quem rege é a máquina.

O caminho de feature-auth

discover → gate → build → prove

swarm() mapeia read-only → council() decide GO/NO_GO → mission() constrói schema→api→ui em sequência → parallel() roda 2 validators.

As regras que seguram a fusão

R1–R10, cada uma com dono

R1 contrato antes do run (prelude) · R2 determinismo (VM) · R3 swarm exclusivo (scheduler) · R4 NO_GO → zero workers · R5 validator ≠ builder. Toda regra tem quem a faz cumprir.

Para a próxima

O playbook do prompt cego

A lição 0004 mostra como operar isso: colar os prompts, comparar N planos independentes (blind), pontuar com rubrica e exigir as seções de entrega em PLAN.md.

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: três bandas tocam coisas diferentes, mas você só quer as notas que importam de cada uma. Você as transcreve para uma pauta nova e rege você mesmo, uma vez, do mesmo jeito. As bandas (as ferramentas) ensinaram como tocar bem; o palco delas você não leva.

Com os termos reais: a Fase 2 funde os contratos de três REs numa interface AlembicHooks com seis verbos (phase, agent, parallel, mission, swarm, council). A VM executa alembic.plan.ts deterministicamente (R2: lint + esbuild rejeitam relógio/RNG no corpo); o prelude exige validation-contract (R1); o scheduler serializa swarms (R3); a Proof Gate roda unit.proof[] como bash -c fail-closed (R7). É açúcar tipado sobre o RunSpec de @alembic/swarm.

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.

Os três acordes

Quais são os três acordes e de onde cada um veio?

clique para virar

Mission (Droid), Workflow (Claude Code), Swarm (Kimi). Mais o council() como portão de decisão.

Regra de ouro

O Alembic copia o quê de cada ferramenta — e descarta o quê?

clique para virar

Copia a mecânica (o comportamento que dá confiabilidade). Descarta a UI (telas, REPL, painel). "A partitura, não o palco."

DNA Mission

Qual a obsessão do acorde Mission?

clique para virar

Contrato antes do run: sem validation-contract, a VM aborta (R1). Sessão fresca por unit (R9) + validators no milestone.

DNA Workflow

Qual a obsessão do acorde Workflow?

clique para virar

Determinismo + retomada: nada de Date.now()/Math.random() no corpo (R2); phase()/parallel(); resume por cache.

DNA Swarm

Qual a obsessão do acorde Swarm?

clique para virar

Fan-out controlado: prompt_template + {{item}}, rampa 5+700ms, teto 16, e um swarm por turno (R3). wire.jsonl por agente (R10).

Regra R4

O que acontece quando o council() devolve NO_GO?

clique para virar

Zero workers. O run para antes de criar qualquer agente de build — falha-fechado, garantido por HarnessCore.fanout. Dúvida custa zero spend.

As Dez ideias para levar desta lição

São três acordes: Mission (Droid), Workflow (Claude), Swarm (Kimi) — mais o council() como portão.
A Fase 2 não cola UIs; ela transcreve a mecânica de cada acorde para um verbo do Alembic.
"A partitura, não o palco": a UI é presa à ferramenta; a mecânica é portável e testável.
Tudo vira um arquivo: alembic.plan.ts, sob a interface AlembicHooks.
Quem rege é uma VM determinística; o LLM só escreve a partitura antes do run.
DNA Mission = contrato antes do run (R1) + sessão fresca (R9) + validators de milestone.
DNA Workflow = determinismo (R2, sem relógio/RNG) + phase/parallel + resume.
DNA Swarm = fan-out controlado (rampa 5+700ms, teto 16, exclusive-deny R3, wire.jsonl R10).
R4: Council NO_GO → zero workers; R5: validator ≠ builder. Cada regra tem dono.
O caminho de feature-auth: discover (swarm) → gate (council) → build (mission) → prove (parallel).

Verifique seu entendimento

Três perguntas. Escolha e leia o porquê de cada opção — o feedback ensina tanto quanto a pergunta.

Checagem cumulativa

Acerte as três para fechar a lição. A pontuação aparece abaixo.

1. O que a Fase 2 do blind planning faz com os três acordes?

(b). A Fase 2 extrai o comportamento de cada acorde e o reescreve como um verbo do Alembic (a partitura nova). Não é colar UIs (a) nem escolher uma só ferramenta (c) — é fundir a mecânica das três num alembic.plan.ts.

2. No plano de feature-auth, qual verbo abre a fase discover?

(c). discover dispara um swarm() read-only sobre ['api','ui','tests','migrations','docs'] — só leitura, devolvendo fatos + paths. O mission() (a) vem na fase build; o council() (b) é o portão entre discover e build.

3. Por que a regra R2 proíbe Date.now() no corpo do plano?

(a). O acorde Workflow exige um corpo determinístico: o mesmo plano deve produzir o mesmo caminho toda vez, senão o resume por cache (prompt, opts) não bate. A VM rejeita relógio/RNG no lint. (b) é falso (não é questão de velocidade) e (c) inventa uma dependência que não existe.

Acertos: 0/3

Em uma frase, para você mesmo: "Os três acordes são ____, ____ e ____; o Alembic copia a ____ de cada um e descarta a ____; e o portão entre fases é o ____." Se você preenche as seis lacunas, está pronto para o Passo 4.

A ideia central

Por baixo do capô

Os três acordes, em uma figura

Tabela de fusão (o mapa lado a lado)

O DNA de cada acorde

Por que copiar a mecânica, e não a UI

No código — o alembic.plan.ts de feature-auth

A interface que une os acordes

As regras de fusão R1–R10

Experimente: escolha um acorde

Acorde Mission

Recapitulando em 6 slides

Três acordes, uma partitura

A partitura, não o palco

alembic.plan.ts

discover → gate → build → prove

R1–R10, cada uma com dono

O playbook do prompt cego

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

Cartões de memória

Verifique seu entendimento

No código — o `alembic.plan.ts` de feature-auth