Alembic × Hermes · O Curso de Fusão · Parte 4 — Método e labs

O framework de fusão: CLONE / ADAPT / MERGE / IGNORE

A lição 3 apresentou as quatro disposições. Esta percorre o procedimento de decisão de ponta a ponta: as duas perguntas que você faz de cada capacidade, por que o mesmo input pode cair em qualquer um dos quatro vereditos, e quatro exemplos resolvidos — por que o learning loop é a pedra angular dos CLONEs, por que o MCP client é um MERGE que está parado, por que delegation é um IGNORE, e por que o neutts é um IGNORE por um motivo diferente. É o framework reutilizável para absorver um sistema dentro de outro sem inchá-lo. Fonte: docs/alembic-hermes-fusion-matrix.md.

Leia primeiro (fonte primária)

docs/alembic-hermes-fusion-matrix.md (lido verbatim)

Esta lição destila a matriz real: a legenda das disposições (§1), as duas perguntas do método (§2 intro), o conjunto CLONE + a pedra angular do learning-loop (§2.1, §3), o MERGE do MCP client (§2.2) + a ordem de implementação #5 (§5), o IGNORE de delegation + o insight portável (§2.4), e os IGNOREs de neutts / computer-use / mensageria (§2.4). Nenhum veredito é inventado; cada um cita evidência verificada do mapa.

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

Ao fim desta lição você vai saber

As duas perguntas que a matriz faz de toda capacidade — e o 2×2 que elas produzem.
Por que existem dois quadrantes IGNORE diferentes: "já melhor" e "fora da missão".
Por que o learning loop é um CLONE — e não um CLONE qualquer, mas a pedra angular.
A diferença entre a disposição (o veredito) e o cronograma (quando construir).
Por que "inédito" é necessário mas nunca anula "fora da missão".

Suposições tolas (assumimos pouco de você)

Você lembra, da lição 3, que a fusão classifica cada capacidade do Hermes em uma de quatro disposições.
Você viu o swarm (lição 19) e o learning loop / memória (lições 7–13) — eles voltam como exemplos aqui.
Você sabe que "absorver um sistema em outro" corre o risco de importar a sprawl junto. Se não, tudo bem — é exatamente o problema que o framework resolve.

As duas perguntas — e o 2×2 que elas produzem

Imagine que você vai mudar de casa e encontra a casa de outra pessoa cheia de coisas. Você não joga tudo no caminhão. De cada item, faz duas perguntas: "eu já tenho um igual?" e "o dele é melhor do que o meu, ou é algo que eu nem tenho?". A resposta às duas decide se você copia, combina com o que já tem, ou deixa para trás — e sempre com um motivo dito em voz alta, nunca um dar de ombros.

Analogia: o framework de fusão é essa mudança disciplinada. CLONE = "não tenho e é ótimo, levo de perto". MERGE/ADAPT = "tenho metade, junto numa coisa só, melhor". IGNORE = "já tenho melhor" ou "é ótimo mas não cabe na minha vida". Quatro destinos, uma decisão defensável por item, zero "copiei porque estava lá".

Para cada capacidade do sistema-fonte, a matriz faz exatamente duas perguntas, cada uma respondida contra evidência verificada do mapa (nunca de memória):

O alvo já tem um equivalente? (respondido contra o mapa do Alembic, com evidência citada)
A versão da fonte é superior ou inédita? (respondido contra o mapa do Hermes)

A disposição decorre do par. É, na prática, um 2×2:

$Infográfico de matriz 2x2 de decisão: o eixo horizontal pergunta 'O alvo já tem algo equivalente?' (NÃO/lacuna à esquerda, SIM à direita) e o eixo vertical 'A versão da fonte é superior ou inédita?' (inédita/melhor em cima, mais fraca embaixo); os quatro quadrantes são CLONE (superior-esquerdo, clay), MERGE/ADAPT (superior-direito, slate-blue), IGNORE fora do escopo (inferior-esquerdo, olive) e IGNORE já melhor (inferior-direito, olive), cada um com seus exemplos.$

As duas perguntas viram os dois eixos; cada quadrante é um veredito. Note os dois IGNORE — um por já-melhor, outro por fora-da-missão.

O 2×2: duas perguntas, quatro vereditos

Uma capacidade é descartada porque o alvo já faz melhor (delegation → o swarm) ou porque é inédita mas fora da missão (neutts). Ambos são IGNOREs justificados — a matriz exige um motivo.

Explore os quatro quadrantes. Clique em um veredito para ver o que faz uma capacidade cair ali:

Preveja antes de continuar

Uma capacidade da fonte que o alvo não tem e que é claramente valiosa. Qual disposição?

CLONE. Pergunta 1 = não há equivalente (lacuna); Pergunta 2 = vale a pena ter. Inédito + valioso ⇒ porte o design de perto, adaptando tipos e convenções ao alvo. Foi exatamente aqui que caíram memory, learning loop, curator, web e clarify — o conjunto das lições 7–13.

As respostas são citadas, nunca lembradas

O que torna o 2×2 confiável não é o desenho — é a regra de que cada resposta carrega evidência verificada. A Pergunta 1 é respondida contra o docs/alembic-complete-map.md (com hit-counts e file:line); a Pergunta 2 contra o mapa do Hermes. Sem evidência, não há veredito — é a mesma disciplina de Proof-Gate da lição 20 aplicada a uma decisão de produto, não a uma linha de código.

A disciplina é estrutural: nenhum veredito sai sem uma evidência citada — é o Proof-Gate aplicado a uma decisão de produto.

docs/alembic-hermes-fusion-matrix.md §1 (legenda das disposições) + §2 (as duas perguntas).

Guarde isto Duas perguntas, quatro destinos. Tem equivalente? × É melhor/inédito? O cruzamento é o veredito. E há dois IGNORE, não um — o quadrante importa.

Exemplo 1 — learning loop: CLONE (a pedra angular)

P1: o Alembic tem um loop fechado de auto-melhoria? Resposta do mapa: não — "learning loop/curator/background review = 0 hits". Uma lacuna genuína. P2: a versão do Hermes é valiosa? Sim — é "o mecanismo 'auto-melhorável' por excelência e a maior ausência do Alembic". Inédito + alto valor ⇒ CLONE. E não um CLONE qualquer: a pedra angular, porque ele compõe com o que o Alembic já tem.

De pipeline para loop — o que o CLONE acrescenta

O reviewer escreve memória/skills duráveis; o curator gere o ciclo de vida; o próximo run lê o snapshot congelado. É o que transforma um pipeline de uma passada em um loop.

// docs/alembic-hermes-fusion-matrix.md §3 — a fusão, desenhada a partir da matriz
Alembic hoje: SOURCE → distill (funnel) → Learnings + Signals → [sem feedback]
Hermes soma:  run → fork de um reviewer só-memory/skill → escreve memory/skills duráveis
              → curator gere o ciclo de vida → o próximo run lê o snapshot renovado
Fundido:      distill → Learnings ─┐
                                   ├─► memory/skills (snapshot congelado) → próximo run + esperto
              run → review fork ───┘    ▲ o curator o mantém limpo

Ele "compõe com o validator gate em vez de substituí-lo" — as escritas do reviewer passam pelo Validator Gate existente do Alembic (lição 17) antes de sedimentar, dando "aprender só de wins validados".

Por que "pedra angular"? Porque ele não acrescenta uma peça isolada — ele fecha a arquitetura. Os CLONEs que você estudou nas lições 7–13 (memory, learning, curator, clarify, web) são exatamente este quadrante: inéditos, valiosos e compositivos com o motor que já existia.

O que "CLONE" significa na prática

CLONE não é copiar-colar Python no monorepo. É portar o design de perto, reescrevendo nos tipos e convenções do alvo: Result<T, Error> em vez de exceções, ports injetáveis em vez de IO direto, schemas Zod nas bordas de durabilidade. O resultado é o pacote @alembic/hermes com cinco subsistemas CLONE/ADAPT enxutos (memory, learning, clarify, web, media) — a forma do Hermes, a engenharia do Alembic.

A forma do Hermes, a engenharia do Alembic: o que cruza é o design, não o código — por isso CLONE não incha o monorepo com Python.

docs/alembic-hermes-fusion-matrix.md §2.1 (conjunto CLONE), §3 (a fusão do learning-loop), §4 (sketch do pacote @alembic/hermes).

Exemplo 2 — MCP client: MERGE (e parado)

P1: o Alembic tem MCP? Parcialmente — ele é um servidor MCP, read-only ("MCP=8 hits; harness handleMcpRequest"), mas não tem cliente. P2: é uma direção inédita? Sim — consumir servidores MCP externos é uma capacidade nova. Equivalente parcial + direção nova ⇒ MERGE dentro de @alembic/harness, não um pacote separado. Mas está parado, não construído.

A disposição é uma coisa; o cronograma é outra

O veredito é MERGE; a ordem de implementação põe o MCP client em #5 (Medium), depois dos cinco CLONEs Easy. Decidir o que algo é não obriga a fazê-lo agora.

Cuidado MERGE não quer dizer "construa agora". MERGE é a disposição (combinar numa superfície existente); o cronograma é separado. O MCP client é um MERGE parado em #5.

Por que MERGE e não um pacote novo

O Alembic já fala MCP como servidor dentro do harness (handleMcpRequest). Um cliente MCP — consumir ferramentas de servidores externos — pertence ao mesmo lugar: a superfície de rede do harness. Criar um @alembic/mcp-client separado fragmentaria uma capacidade que é naturalmente uma só. MERGE = uma superfície mais rica, não mais uma caixa.

MERGE escolhe a casa existente: o cliente MCP entra no harness ao lado do servidor, não num pacote novo que partiria uma capacidade naturalmente única.

docs/alembic-hermes-fusion-matrix.md §2.2 (MERGE do MCP client) + §5 (ordem de implementação, #5 Medium).

Exemplo 3 — delegation: IGNORE (já melhor)

P1: o Alembic delega trabalho a sub-agentes? Enfaticamente sim — o swarm (lição 19): "swarm=63 hits: orquestrador de 3 tiers, lead-worker, profundidade limitada, fila dependency-gated, reward PARL". P2: o delegate_tool.py (3188 LOC) do Hermes é melhor? Não — o Alembic "já faz isso nativamente e melhor". Equivalente existe e é superior ⇒ IGNORE. Mas a matriz ainda extrai um insight portável em vez de descartar por atacado.

Um bom IGNORE colhe a única ideia que vale

O subsistema é descartado, mas a regra de cache-safety da delegação assíncrona — a conclusão volta como um turn novo — é guardada. Um IGNORE disciplinado não joga fora a única boa ideia.

As quatro propriedades nativas do swarm (lição 19) são exatamente o que o delegate_tool.py não tem — a evidência que torna o veredito IGNORE inevitável.

Esta é a razão pela qual a lição 19 existe. O swarm é o pacote que torna o delegate_tool.py um IGNORE: profundidade limitada, resume à prova de crash e park T4 nativos. Portar o Hermes aqui seria duplicar um subsistema inferior.

O insight que sobreviveu ao IGNORE

A delegação assíncrona do Hermes tem uma regra de segurança de cache que vale guardar: a conclusão de uma tarefa delegada re-entra como um novo turn, nunca no meio do contexto. Isso preserva a chave de cache do turn corrente. O swarm do Alembic já adota a mesma postura (o seam do dispatcher acomoda exatamente isso). IGNORE não significa "não aprendi nada" — significa "não porto o subsistema".

docs/alembic-hermes-fusion-matrix.md §2.4 (IGNORE de delegation + insight portável); docs/alembic-complete-map.md §7.6 (swarm, o equivalente).

Exemplo 4 — neutts (TTS local): IGNORE (fora da missão)

Este é o outro tipo de IGNORE. P1: o Alembic tem TTS neural local? Não. P2: é inédito? Sim. Então por que não CLONE? Porque ele falha no teste da missão: "stack ML só-Python (neutts, espeak-ng). Difícil de portar, sem valor de missão". Inédito é necessário, mas não suficiente — uma capacidade também precisa caber na missão e nas restrições do alvo.

Infográfico vertical com os quatro exemplos resolvidos empilhados: learning loop (P1 não, P2 sim → CLONE, a pedra angular), MCP client (P1 parcial, P2 sim → MERGE mas parado em #5), delegation (P1 sim, P2 não → IGNORE já melhor, guarda 1 insight), e neutts (P1 não, P2 inédito mas fora da missão → IGNORE fora da missão); cada faixa mostra Pergunta 1 e Pergunta 2 chegando a um veredito.

O mesmo par de perguntas, quatro vereditos diferentes — porque a segunda pergunta carrega também o teste de missão. "Inédito" nunca anula "fora da missão".

Por que neutts NÃO é CLONE

Os outros IGNOREs por fora-da-missão

A mesma lógica IGNORA o computer-use (amarra um runtime nativo), os 23 adapters de plataformas de mensageria (o Alembic é um motor interno, não um gateway de assistente pessoal) e o caminho local faster-whisper dentro de uma ferramenta de mídia que, no resto, é ADAPTada (lição 13). A disposição é por-capacidade: "inédito" nunca atropela "fora da missão".

Flashcard · recuperação

neutts é inédito ao Alembic. Por que ainda é IGNORE?

clique para virar

Resposta

Inédito não basta. Tem de caber na missão/restrições. neutts é stack ML só-Python, difícil de portar, sem valor de missão → IGNORE (fora da missão). O mesmo motivo que IGNORA o faster-whisper dentro do media tool já portado.

Por-capacidade, não por-pacote

O ponto fino: uma mesma ferramenta do Hermes pode ser ADAPTada no todo e ter partes IGNORADAS. A ferramenta de mídia é ADAPTada, mas seu caminho local faster-whisper é IGNORADO (mesma razão de missão/portabilidade que neutts). A unidade de decisão é a capacidade, não o arquivo — é o que mantém a fusão cirúrgica em vez de tudo-ou-nada.

docs/alembic-hermes-fusion-matrix.md §2.4 (IGNOREs de neutts/computer-use/mensageria; faster-whisper dentro do media ADAPTado).

A disciplina que evita o bloat

O objetivo do framework

A questão toda é absorver um agente de 30 mil linhas em um motor TypeScript focado sem importar a sprawl dele. CLONE só as peças inéditas de alto valor; MERGE o que se sobrepõe numa superfície mais rica; IGNORE — com motivo — tanto o que você já faz melhor quanto o que não cabe. O resultado é o pacote @alembic/hermes: cinco subsistemas CLONE/ADAPT enxutos (memory, learning, clarify, web, media), com os MERGEs pousando em suas casas existentes e tudo fora-da-missão deixado para trás. Quatro vereditos, uma decisão defensável por capacidade, zero "copiamos porque estava lá".

O recorte final: cinco subsistemas enxutos no novo pacote, os MERGEs em suas casas, e tudo fora-da-missão ou já-melhor deixado para trás — sem sprawl importada.

Nada aqui é específico do Hermes: duas perguntas citadas, quatro saídas. É um procedimento geral para absorver um sistema em outro sem inchá-lo.

Exemplo guiado — rode o framework numa capacidade nova

Pegue a capacidade hipotética session_search do Hermes (busca em sessões salvas). P1: o Alembic tem busca em sessões? Cheque o mapa, não a memória.

Suponha que o mapa diga "não há equivalente". Lacuna ⇒ candidata a CLONE — se passar na P2.

P2: é valiosa e cabe na missão (um motor que aprende quer reler sessões)? Se sim em ambos ⇒ CLONE. Se "inédita mas fora da missão" ⇒ IGNORE (fora da missão).

Agora você: e se a P1 revelasse que o Alembic já tem um índice de embeddings que cobre busca em sessões, e o do Hermes não fosse melhor? (Resposta: equivalente existe e não é superado ⇒ IGNORE "já melhor" — mas colha qualquer insight portável antes de descartar.)

subsistemas CLONE/ADAPT em @alembic/hermes

quadrantes IGNORE distintos (já-melhor · fora-da-missão)

motivo obrigatório por veredito — nunca um dar de ombros

O framework é reutilizável fora desta fusão

Nada nas duas perguntas é específico do Hermes. "Tenho equivalente? × É melhor/inédito e cabe?" é um procedimento geral para absorver qualquer sistema em outro sem inchá-lo — desde que cada resposta cite evidência verificada e cada IGNORE carregue um motivo. É o irmão, no nível de produto, do método de reverse-engineering da lição 20.

docs/alembic-hermes-fusion-matrix.md §4 (o pacote) — e o método generalizável de §1–§2.

Confusões comuns

Qualidade não é o eixo: uma capacidade excelente pode ser IGNORE por fora-da-missão, e uma redundante por já-melhor. O que muda é o motivo, não a existência dele.

"IGNORE quer dizer que a capacidade era ruim." Não — dois fatos bem diferentes viram IGNORE: coisas que o alvo já faz melhor (delegation) e coisas genuinamente boas mas fora da missão (neutts, 23 adapters de mensageria). O veredito é sobre fit, não qualidade, e sempre carrega um motivo declarado.

"MERGE quer dizer construir já." Não necessariamente. MERGE é a disposição (combinar numa superfície existente); o cronograma é separado. O MCP client é um MERGE parado em #5, atrás dos cinco CLONEs Easy. Decidir o que algo é não compromete você a fazê-lo a seguir.

"Inédito sempre vira CLONE." Não — inédito é necessário, mas não suficiente. Precisa também caber na missão e nas restrições. neutts é inédito e mesmo assim IGNORE (fora da missão); o faster-whisper é IGNORE dentro de uma ferramenta que no resto é ADAPTada.

Em uma frase: o framework de fusão pergunta de cada coisa "eu já tenho?" e "o seu é melhor ou novo — e cabe na minha vida?", e responde copiar, combinar ou deixar para trás — sempre com um porquê.

Em uma frase: para cada capacidade, P1 (equivalente no alvo?) × P2 (fonte superior/inédita E dentro da missão?) → {CLONE, MERGE/ADAPT, IGNORE(já-melhor), IGNORE(fora-da-missão)}, cada veredito citando evidência do mapa e carregando um motivo; a disposição é por-capacidade e independente do cronograma.

Recapitulando em 6 slides

Slide 1 · O procedimento

duas perguntas, um 2×2

"Tenho equivalente?" × "é melhor/inédito?" — o cruzamento é o veredito. Cada resposta cita o mapa.

Slide 2 · CLONE

learning loop, a pedra angular

Lacuna (0 hits) + alto valor ⇒ CLONE. Compõe com o Validator Gate: aprende só de wins validados.

Slide 3 · MERGE

MCP client — e parado

Servidor existe, cliente é novo ⇒ MERGE no harness. Mas parado em #5: disposição ≠ cronograma.

Slide 4 · IGNORE (já melhor)

delegation → o swarm vence

O swarm (63 hits) já delega melhor ⇒ IGNORE. Mas colhe 1 insight: a conclusão re-entra como novo turn.

Slide 5 · IGNORE (fora da missão)

neutts — inédito não basta

Stack ML só-Python, sem valor de missão ⇒ IGNORE. "Inédito" nunca atropela "fora da missão".

Slide 6 · A disciplina

absorver sem inchar

5 CLONE/ADAPT em @alembic/hermes, MERGEs em casa, fora-da-missão deixado para trás. Um motivo por veredito.

Slide 1 / 6 use ← →

Recall ativo: feche os olhos e recite as quatro disposições e os dois sentidos de IGNORE — CLONE, MERGE/ADAPT, IGNORE(já-melhor), IGNORE(fora-da-missão). Depois confira na seção 1.

Concluída a trilha Motor & método (14–21): você já raciocina do contrato à capacidade. A seguir, os labs (22–30) põem o framework a construir de verdade.

Você completou a trilha Motor & método. As lições 14–21 cobriram o motor em que a fusão se encaixa (cintura estreita, funil, quatro invariantes, pipeline de gates, council/verifier, swarm) e a disciplina por trás dele (método de reverse-engineering, framework de fusão). Junto com a narrativa (1–6) e os mergulhos de subsistema (7–13), você já raciocina sobre Alembic × Hermes do contrato à capacidade. Releia a Lição 3 e os quatro vereditos vão soar como consequências óbvias de duas perguntas. A seguir, a trilha de labs e tópicos avançados (22–30) põe tudo em prática.

Verifique seu entendimento

Três perguntas — a pontuação corre conforme você responde

1. Uma capacidade da fonte é inédita (o alvo não tem) e de alto valor. Qual disposição?

Correto: c. Inédito (P1 = sem equivalente) + valioso (P2 = vale a pena) ⇒ CLONE. O learning loop, memory, curator, web e clarify caíram todos aqui — o conjunto das lições 7–13.

2. Por que o delegate_tool.py do Hermes é um IGNORE e não um CLONE?

Correto: b. P1 = o Alembic tem (o swarm, 63 hits); P2 = o do Hermes não é melhor. Equivalente + não-superior ⇒ IGNORE — o quadrante "já melhor". Um IGNORE disciplinado ainda colhe a única ideia que vale.

3. neutts (TTS neural local) é inédito ao Alembic. Por que ainda é IGNORE?

Correto: d. O segundo quadrante IGNORE: uma capacidade que o alvo não tem mas que é fora-da-missão ou tecnicamente incompatível. "Inédito" nunca atropela "não cabe" — a mesma razão pela qual o caminho local faster-whisper é IGNORADO dentro da ferramenta de mídia já portada.

Acertos: 0/3

As cinco verdades do framework de fusão

Duas perguntas por capacidade: "tenho equivalente?" e "a fonte é superior/inédita?".
O cruzamento é o veredito: CLONE · MERGE/ADAPT · IGNORE(já-melhor) · IGNORE(fora-da-missão).
Há dois IGNORE: o alvo já faz melhor, ou é bom mas fora da missão — sempre com motivo.
Disposição ≠ cronograma: o MCP client é MERGE e mesmo assim está parado em #5.
"Inédito" é necessário, não suficiente — precisa caber na missão; e a unidade de decisão é a capacidade, não o pacote.

Pergunta para levar adiante: você acabou de ver o framework decidir o que construir. A próxima lição, "Lab: construir um subsistema", desce ao chão de fábrica — pega uma capacidade CLONE e a constrói de verdade no monorepo, com testes verdes. Como você transformaria o veredito "CLONE o learning loop" em um pacote que passa pnpm -r typecheck && pnpm -r build && pnpm -w test?