Camada L4 · Harness — o maestro

Imagine uma orquestra. Os músicos são o council (a deliberação) e o swarm (a execução). O maestro não toca nenhum instrumento: ele dá as entradas, lê o andamento e fecha a peça. No Alembic, esse maestro é o HarnessCore — e a sala de concerto (CLI, navegador, outro programa via MCP) é só onde a música é ouvida, nunca onde ela é composta.

O HarnessCore recebe um PhaseJob, conduz council + swarm e emite um fluxo de HarnessEvent por três raias (swimlanes). Ele não conhece nenhum transport.

O que "transport-neutral" significa

O arquivo core.ts define uma única classe, HarnessCore, que não sabe como é invocada. Ela não abre socket, não lê argv, não formata saída para um terminal. Tudo o que ela faz é pura orquestração: conduzir o council, conduzir o swarm e emitir um fluxo de eventos. Quem decide como o usuário fala com ela mora fora — nos adaptadores.

// core.ts
export class HarnessCore {
  readonly runId: string;
  readonly bus: EventBus;
  // seams injetáveis: now(), bus, runDebate, runSwarm, adapters…
  constructor(options: HarnessCoreOptions) { /* … */ }

  poll(): RunSnapshot { return this.snapshotState; }
  start(job: PhaseJob): Result<RunSnapshot, string> { /* … */ }
  async fanout(job: PhaseJob): Promise<Result<RunSnapshot, string>> { /* … */ }
  report(): RunSnapshot { /* … */ }
}

Toda a orquestração do core cabe em quatro métodos. Clique em cada um para ver o que ele faz e qual raia ele acende.

* report() é idempotente: chamá-lo duas vezes emite um segundo frame, mas não altera o resultado.

Além do core de orquestração, o L4 abriga o funnel (funnel.ts): o orquestrador de destilação em quatro tiers. Para a maioria dos usuários, funnel.ts é o ponto de entrada principal, via o comando distill no CLI. Ele empurra um corpus por quatro estações, cada uma mais cara e mais criteriosa que a anterior.

O bridge.ts é a peça que fecha o ciclo: ele liga a saída verificada-GO do funnel à fábrica de marketing. A função distillAndMarket roda o funnel sobre um corpus, pega cada verifiedSignal, transforma em um AssetsManifest versionado via runMarketingBatch, e persiste os manifests num store append-only que deduplica.

Uma esteira em quatro estações: runFunnel → verifiedSignals → runMarketingBatch → persistManifests. A dependência só anda numa direção.

// bridge.ts
export const distillAndMarket = async (corpusDir, options) => {
  const funnel    = await runFunnel(corpusDir, options.funnel);
  const marketing = await runMarketingBatch(
    funnel.verifiedSignals, options.marketing,
  );
  const manifestsWritten = await persistManifests(
    marketing.manifests, options.funnel,
  );
  return { funnel, marketing, manifestsWritten };
};

Agora a parte que fecha a camada: os adaptadores. Os três falam com o mesmo HarnessCore. Nenhum deles contém orquestração — eles só traduzem entre o mundo externo (terminal, HTTP, JSON-RPC) e os verbos do core.

Três superfícies, um só núcleo. Trocar de transport nunca duplica a lógica — ela mora só no core.

Vamos seguir um run de uma fase pelo core, do start ao report, e ver quais eventos cada verbo solta.