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

A lição 3 introduziu as quatro disposições. Esta lição 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 dos quatro vereditos, e quatro exemplos trabalhados — por que o ciclo de aprendizado é um CLONE pedra-angular, por que o cliente MCP é um MERGE estacionado, por que a delegação é IGNORE, e por que o neutts é IGNORE por uma razão diferente. É o framework reutilizável para absorver um sistema noutro sem inchá-lo.

01 · As duas perguntas — e o 2×2 que produzem

Imagine que você vai mudar de casa e está diante de cada objeto da casa antiga: vale levar? A resposta nunca é "leve tudo" nem "jogue tudo" — você decide objeto por objeto, com duas perguntas simples. A matriz de fusão faz exatamente isso com cada capacidade do sistema-fonte (o Hermes), e cada resposta é dada contra evidência verificada do mapa — nunca de memória:

1. P1 · O alvo já tem um equivalente? (respondida contra o mapa do Alembic, com a evidência citada — ex.: contagem de hits no mapa de 1488 linhas)
2. P2 · A versão da fonte é superior ou inédita? (respondida contra o mapa do Hermes)

Cada pergunta é um "detector" simples

Antes de juntar as duas, veja cada uma isolada. A P1 é um detector de lacuna: ela varre o mapa do alvo atrás de um equivalente. A P2 é um detector de valor: a coisa nova é melhor, ou pelo menos inédita?

As duas respostas juntas: o 2×2

A disposição decorre do par de respostas. É, com efeito, uma matriz 2×2 — o eixo horizontal é a P1 (o alvo já tem?), o vertical é a P2 (a fonte é melhor/inédita?):

Note os dois quadrantes IGNORE: uma capacidade é descartada ou porque o alvo já a faz melhor (delegação → o swarm) ou porque é inédita mas fora-da-missão (neutts TTS local). Ambos são IGNOREs justificados — a legenda da matriz exige uma razão, nunca um dar de ombros ("IGNORE … OR it's out of scope for Alembic's mission. Justified.").

02 · O fluxograma de decisão (as duas perguntas, em sequência)

O 2×2 é a foto; o fluxograma é o filme — a ordem em que você faz as perguntas diante de uma capacidade nova. Siga as setas: cada losango é uma das duas perguntas, e há dois caminhos que terminam em IGNORE, por razões opostas. O caminho do delegate_tool.py e do neutts está anotado à direita.

03 · Veredito 1 — ciclo de aprendizado: CLONE (a pedra angular)

P1: o Alembic tem um ciclo fechado de auto-aperfeiçoamento? A resposta do mapa: não — "learning loop/curator/background review = 0 hits". Uma lacuna genuína. P2: a versão do Hermes é valiosa? Sim — é "the headline 'self-improving' mechanism and Alembic's biggest miss". Inédito + alto valor ⇒ CLONE. E não um clone qualquer — a pedra angular, porque compõe com o que o Alembic já tem em vez de substituir:

// docs/alembic-hermes-fusion-matrix.md §3 — a fusão, extraída da matriz
Alembic hoje:    SOURCE → distill (funil) → Learnings + Signals → [sem feedback]
Hermes adiciona: run → fork de revisor só-memory/skill → escreve memory/skills duráveis
                 → curator gerencia o ciclo de vida → próxima run lê o snapshot atualizado
Fundido:         distill → Learnings ─┐
                                      ├─► memory/skills (snapshot congelado) → próxima run mais esperta
                 run → fork de review ┘    ▲ curator mantém limpo

O mesmo desenho como diagrama de caixas: o funil que você já conhece (lição 15) e o fork de revisão do Hermes convergem nos stores duráveis, que realimentam a próxima run. É o que transforma um pipeline de um disparo num ciclo:

Ele "compõe com o validator gate em vez de substituí-lo" — as escritas do revisor passam pelo Validator Gate existente do Alembic (ADR-0006) antes de sedimentar (lição 17), dando "learn only from validated wins". É por isso que é a pedra angular: transforma um pipeline de um disparo em um ciclo, usando maquinário que o Alembic já tinha. Os CLONEs que você estudou nas lições 7–13 (memory, learning, curator, clarify, web) são exatamente este quadrante — todos marcados Easy na matriz, exceto o próprio learning loop, de "highest conceptual value".

04 · Veredito 2 — cliente MCP: MERGE (e estacionado)

P1: o Alembic tem MCP? Parcialmente — é um servidor MCP, read-only ("MCP=8 hits; harness handleMcpRequest"), mas não tem cliente. P2: direção inédita? Sim — consumir servidores MCP externos é uma capacidade nova. Equivalente parcial + direção nova ⇒ MERGE em @alembic/harness (não um pacote separado). A própria matriz rotula: "High-value MERGE". Mas o veredito não é o cronograma — está estacionado, listado em #5 (Medium), depois dos cinco CLONEs Easy.

05 · Veredito 3 — delegação: IGNORE (já melhor)

P1: o Alembic delega trabalho a sub-agentes? Enfaticamente sim — o swarm (lição 19): "swarm=63 hits: 3-tier orchestrator, lead-worker, depth-bound, dependency-gated task-queue, PARL reward". P2: o delegate_tool.py do Hermes (§3.8, 3188 LOC) é melhor? Não — o Alembic "already does this natively and better". Equivalente existe e é superior ⇒ IGNORE (o quadrante "já melhor"). Mas a matriz ainda extrai um insight portável em vez de descartar por atacado:

Manter a regra de cache-safety da delegação assíncrona — "a conclusão re-entra como um novo turno, nunca no meio do contexto" — é o que distingue um IGNORE disciplinado de um descarte cego. Um bom IGNORE colhe a única ideia que vale manter; ele não joga fora o aprendizado, joga fora o código.

06 · Veredito 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 falha no teste de missão: "Python-only ML stack (neutts, espeak-ng). Hard to port, no mission value." Inédito é necessário mas não suficiente — uma capacidade também precisa caber na missão e nas restrições do alvo. É um terceiro "portão" que se aplica só ao quadrante da lacuna:

A mesma lógica IGNORA o computer-use (vincula um runtime nativo), os 23 adapters de mensageria ("Alembic is an internal engine (ADR-0001), not a personal-assistant gateway"), o editor ACP, e — dentro de uma ferramenta de media de resto ADAPTada — o caminho local faster-whisper ("Local faster-whisper = IGNORE/sidecar (Python ML, no clean Node port)", lição 13). A disposição é por-capacidade, e "inédito" nunca sobrepõe "fora-da-missão".

07 · Aplique o procedimento na mão (passo a passo → agora você)

Você viu as duas perguntas, o 2×2 e quatro vereditos prontos. Agora rode o procedimento na mão, devagar, sobre uma capacidade que ainda não vimos: a busca em sessões do Hermes — session_search_tool.py §3.4 (797 LOC). Recuperar o procedimento — não só ler o veredito pronto — é o que fixa o framework. Cada passo é exatamente um movimento do fluxograma da seção 02, e a célula da matriz guarda a evidência de cada resposta.

O mesmo procedimento, visto como trilha de decisão para o caso resolvido — as setas são os ramos do fluxograma da seção 02 percorridos de verdade, terminando em ADAPT:

08 · CLONE / ADAPT / MERGE / IGNORE — lado a lado

Os quatro vereditos numa só tabela: o que cada disposição significa, o gatilho (qual par P1/P2 a aciona), para onde vai, e o exemplo trabalhado desta lição. A tabela diz a regra; o gráfico abaixo a torna visível.

As mesmas cinco linhas como faixas: cada disposição leva a quanto de código você importa para dentro do motor — CLONE/ADAPT trazem código novo; MERGE engrossa uma superfície existente; os dois IGNORE trazem zero código (no máximo uma ideia):

A ordem de implementação — disposição ≠ cronograma

Decidir a disposição é uma coisa; quando construir é outra. A matriz (§5) ordena por "value × (1 / coupling)", CLONEs primeiro porque são inéditos e autocontidos. Repare: o MERGE do cliente MCP fica em #5, atrás dos cinco CLONEs/ADAPTs Easy — um MERGE de alto valor que ainda assim espera:

09 · Roteie você mesmo (demo do 2×2)

Você viu as duas perguntas, o 2×2 e quatro vereditos. Agora roteie uma capacidade você mesmo: escolha uma resposta para cada pergunta e veja o quadrante acender e o veredito aparecer — exatamente o caminho que a matriz percorre. Experimente reproduzir os quatro exemplos da lição.

10 · Como isso se encaixa

Este framework não é uma peça de runtime — é a disciplina de decisão que precede a fusão inteira. Olhe a peça no seu lugar: a montante, dois mapas verificados o alimentam (a engenharia reversa do Hermes, Lição 2, e o mapa do próprio Alembic); esta peça aplica as duas perguntas a cada capacidade; a jusante, ela generaliza na matriz de fusão (Lição 3) item a item, e a matriz produz tanto a forma do pacote @alembic/hermes quanto a ordem de implementação value×(1/coupling). Em outras palavras: o framework é o operador, a matriz é o resultado de aplicá-lo a toda a superfície do Hermes.

As peças que se conectam a esta

O framework toca quatro outras lições — duas o alimentam, duas consomem o que ele decide:

11 · Na prática

Honestidade primeiro: não existe um alembic que "rode" o framework. Ele é um procedimento de decisão humano-no-comando — você aplica as duas perguntas a uma capacidade e escreve a disposição. O artefato que ele produz é um documento (docs/alembic-hermes-fusion-matrix.md). O que a CLI pode fazer é validar a coerência do stack que o framework decidiu construir — é o papel de alembic doctor --client-stack, que confere a forma do MODEL_REGISTRY e a coerência dos adapters, offline e a custo $0, sem rede.

# O framework é um procedimento de decisão — o artefato é um documento, não um comando.
# O que a CLI valida é a COERÊNCIA do stack que as disposições produziram:
$ alembic doctor --client-stack

# saída esperada (forma ilustrativa — o conteúdo depende do seu MODEL_REGISTRY):
#   client-stack: MODEL_REGISTRY shape OK · adapters coerentes
#   (offline · $0 · sem rede)
# Para a matriz que o framework preencheu, abra o documento-fonte:
$ cat docs/alembic-hermes-fusion-matrix.md

Fixe os conceitos (flashcards)

Clique pra virar. Tente lembrar a resposta antes de virar — recuperação ativa fixa mais que reler.

Confusões comuns