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 das 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. Fonte: docs/alembic-hermes-fusion-matrix.md.
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):
A disposição decorre do par. É, com efeito, um 2×2:
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 matriz exige uma razão, nunca um dar de ombros.
P1: o Alembic tem um ciclo fechado de auto-aperfeiçoamento? A resposta do mapa: não — "learning loop/curator/background review = 0 hits". Um gap genuíno. P2: a versão do Hermes é valiosa? Sim — é "o mecanismo 'auto-aperfeiçoante' principal e a maior lacuna do Alembic". Inédito + alto valor ⇒ CLONE. E não um clone qualquer — a pedra angular, porque compõe com o que o Alembic já tem:
// 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
Ele "compõe com o validator gate em vez de substituí-lo" — as escritas do revisor passam pelo Validator Gate existente do Alembic antes de sedimentar (lição 17), dando "aprenda só com vitórias validadas". É 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.
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. Mas está estacionado, não construído: a ordem de implementação o lista em #5 (Medium), depois dos cinco CLONEs Easy. MERGE é o veredito; o cronograma o adia.
P1: o Alembic delega trabalho a sub-agentes? Enfaticamente sim — o swarm (lição 19): "swarm=63 hits: orquestrador de 3 camadas, lead-worker, profundidade-limitada, fila de tasks com portão de dependências, PARL reward". P2: o delegate_tool.py do Hermes (3188 LOC) é 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: 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". Um bom IGNORE colhe a única ideia que vale manter.
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: "Stack de 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. A mesma lógica IGNORE o computer-use (vincula um runtime nativo), os 23 adapters 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 media de resto ADAPTada (lição 13). A disposição é por-capacidade, e "inédito" nunca sobrepõe "fora-da-missão".
O ponto inteiro do framework é absorver um agente de 30k linhas num motor TypeScript focado sem importar seu sprawl. CLONE só as peças inéditas de alto valor; MERGE o que se sobrepõe numa superfície mais rica; IGNORE — com uma razão — 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 MERGEs aterrissando 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á".
delegate_tool.py do Hermes é um IGNORE em vez de um CLONE?faster-whisper é IGNORADO dentro da ferramenta de media de resto portada.