A matriz de fusão
Agora você tem dois sistemas: o motor do Alembic (Lição 1) e o Hermes Agent reconstruído por engenharia reversa (Lição 2). A matriz é a ponte — uma decisão item a item sobre o que fazer com cada capacidade do Hermes. Quatro verbos, uma regra cada: CLONE ADAPT MERGE IGNORE.
Esta lição destila esse documento, ancorado nas duas fundações verificadas (docs/alembic-complete-map.md e docs/hermes-complete-map.md). Toda contagem de ocorrências e LOC sai dali (rodapé). Por que importa pra missão: a matriz é o que separa "copiar tudo do Hermes" de "construir só o que torna o Alembic melhor" — e metade do valor está no que ela recusa.
- Derivar a disposição (CLONE/ADAPT/MERGE/IGNORE) de qualquer capacidade a partir de duas perguntas, respondidas contra um mapa verificado — nunca de memória.
- Ler a matriz 2×2 e explicar por que o quadrante "tem equivalente + Hermes melhor" vira MERGE, não CLONE.
- Justificar a coluna IGNORE: por que o
swarmderruba odelegate_tool.pye por que 23 adaptadores de mensagem ficam de fora. - Explicar por que o ciclo de aprendizado é a pedra angular — e por que foi de CLONE no papel para ADAPT na entrega (ADR-0018).
swarm=63 ocorrências (vence delegate)01 · O método: duas perguntas, uma disposição
Pense na matriz como um porteiro de loja diante de cada item do Hermes: ele não deixa tudo entrar, e não recusa tudo. Faz duas perguntas e, conforme o par de respostas, manda o item por uma de quatro portas. A matriz não é uma lista de desejos — é uma ferramenta de poda tanto quanto de construção.
As duas perguntas, cada uma respondida contra um mapa verificado (não de cabeça):
- P1 — O Alembic já tem um equivalente? respondida contra
docs/alembic-complete-map.md, com contagem de ocorrências sobre o mapa e pacotes nomeados como evidência. - P2 — A versão do Hermes é superior ou inédita? respondida contra
docs/hermes-complete-map.md.
A disposição decorre do par. O que não pôde ser confirmado foi marcado [uncertain] em vez de adivinhado — a mesma honestidade que a Lição 2 cobrava da engenharia reversa.
MCP=8, browser=13, skill=22, verifier=19, swarm=63) sobre o mapa de 1488 linhas, ou um pacote nomeado (ex.: packages/council/src/verifier-panel.ts). "Hermes" cita as §-seções de hermes-complete-map.md + LOC. Nada é decidido de memória; todo "Alembic tem/não tem X" tem evidência citada.02 · A matriz 2×2 — o cruzamento que decide tudo
As duas perguntas formam dois eixos. Cruze-os e cada capacidade cai num quadrante — e cada quadrante tem um verbo. Esta é a matriz no sentido literal: linhas = "Alembic já tem?", colunas = "Hermes é melhor/inédito?".
Repare na assimetria: três dos quatro quadrantes acabam reusando o que o Alembic já tem (dois IGNORE e o MERGE/ADAPT). Só o canto superior-direito — inédito e valioso — vira código novo de fato. É por isso que a coluna CLONE tem apenas cinco itens. A tabela abaixo fixa o verbo de cada quadrante:
| Verbo | Quando |
|---|---|
| CLONE | Inédito no Alembic; portar o design do Hermes de perto, adaptando tipos para @alembic/*. |
| ADAPT | O Alembic tem equivalente parcial / diferente; reimplementar a ideia do Hermes no estilo do Alembic. |
| MERGE | O Alembic já tem superfície afim; dobrar a capacidade do Hermes nela — uma superfície mais rica. |
| IGNORE | O Alembic já faz tão bem ou melhor, ou está fora do escopo da missão. Sempre justificado. |
Quantos itens em cada porta?
A distribuição confirma o chute (ou o corrige): a fusão é mais sobre recusar com critério do que sobre copiar. As barras abaixo são as contagens reais das quatro tabelas de disposição da matriz (§2.1–2.4):
03 · Decida você mesmo (interativo)
Internalize o porteiro: ajuste as duas perguntas nos botões e veja o quadrante acender com o verbo correspondente. É exatamente o cruzamento da matriz 2×2 — agora controlado por você.
Dois eixos, quatro saídas. Repare que "já tem + Hermes melhor" dá MERGE (dobra numa superfície existente), nunca CLONE — esse é o erro mais comum de quem lê a matriz.
Aplique o método na mão (passo a passo → agora você)
Você já viu o porteiro decidir no botão. Agora rode-o na mão, devagar, com um caso real — depois um é seu. Recuperar o procedimento (não só ver o veredito pronto) é o que fixa de verdade.
curator=0 ocorrências. Não há sidecar de telemetria de uso de skills. Resposta: NÃO.@alembic/hermes → learning/curator.ts, portando o design (não o Python) com Result/Zod/escritas atômicas.browser_tool.py)? Lembre: o Alembic já encapsula agent-browser somente-leitura (browser=13). Rode P1 e P2 antes de revelar.
browser=13) · P2 = SIM, o Hermes acrescenta a superfície de interação. JÁ tem + acrescenta → quadrante inferior-direito → MERGE: manter read-only como padrão e dobrar a interação atrás de opt-in explícito. Dica: o procedimento é sempre o mesmo — só mudam as duas respostas.04 · CLONE — os cinco inéditos de alto valor
Estes caem no canto superior-direito da matriz: não têm equivalente no Alembic (o mapa mostra zero ou ocorrências incidentais) e agregam valor. Por isso são portados de perto — adaptando o design, não copiando o Python.
| Capacidade | Fonte no Hermes | Por que CLONE |
|---|---|---|
| Memória em arquivo (snapshot congelado) | memory_tool.py §3.2 (1089 LOC) | MEMORY.md/USER.md limitados, injetados como snapshot congelado no início da sessão; escritas no meio da sessão tocam o disco mas nunca invalidam o cache de prefixo. Fundamental para o ciclo de aprendizado. |
| Ciclo de aprendizado por auto-revisão | background_review.py §1.10 | O mecanismo "auto-aperfeiçoável" principal — a maior lacuna do Alembic. (Entregue como ADAPT; veja o destaque na seção 08.) |
| Curador (ciclo de vida de skills) | curator.py + skill_usage.py §3.3 (900 LOC) | active→stale→archived, nunca deleta. Dá controle de qualidade ao ciclo. |
| Busca / extração web | web_tools.py §3.1 (1377 LOC) | HTTP+JSON puro sobre vários backends (Exa/Firecrawl/Parallel/Tavily) + compressão por LLM. Reforça a camada SOURCE (L-1) do funil. |
| Clarify (humano no loop) | clarify_*.py §3.7 | Perguntas estruturadas + gateway bloqueante. Vira a superfície de pergunta do portão humano T4. |
Result, FsPort, Zod, IDs por conteúdo). Todos vão para um único pacote novo, @alembic/hermes, com Result<T,E> em cada fronteira e nada que lance exceção (ADR-0009).05 · MERGE — dobrar em uma superfície afim
Estes caem no quadrante "já temos algo parecido e o Hermes acrescenta": a resposta não é construir do zero, é dobrar a capacidade numa superfície existente para ter uma só, mais rica. O caso-modelo é o MCP.
| Capacidade | Alembic hoje | Por que MERGE |
|---|---|---|
| Cliente MCP | O Alembic é um servidor MCP, somente-leitura — sem cliente (MCP=8 ocorrências) | Adicionar a capacidade de consumir servidores MCP externos. Alto valor; o SDK TS torna isso mais limpo que o original em Python. Estacionado como follow-up, ainda não conectado. |
| Automação de browser completa | encapsula agent-browser somente-leitura (browser=13 ocorrências) | Manter somente-leitura como padrão; combinar a superfície de interação atrás de opt-in explícito. |
| Autoria de skills + telemetria | carrega skills (skill=22 ocorrências) mas sem autoria pelo agente | Combinar create/edit/patch no loop-engineering para que skills criadas pelo agente alimentem o Curador. |
| Verifier / mixture-of-agents | verifier-panel do council (verifier=19 ocorrências) | O quórum de N-lentes + veto do Alembic é o equivalente mais rico do MoA — manter o do Alembic. |
Comparativo: verifier-panel do Alembic vs mixture-of-agents do Hermes
O MERGE mais sutil é o do verifier: aqui o Alembic não ganha nada do Hermes — ele já é o mais rico. Veja o trade-off lado a lado:
06 · ADAPT & IGNORE — o resto, justificado
ADAPT (equivalente parcial → reimplementar no estilo do Alembic): session-search FTS5, skills-hub, conceitos de kanban no swarm, blueprints de cron, transcrição na nuvem, análise de visão.
IGNORE — e a justificativa é a parte interessante:
| Capacidade | Por que IGNORE |
|---|---|
Delegação a subagentes (delegate_tool.py, 3188 LOC) | O swarm do Alembic (swarm=63 ocorrências: orquestrador de 3 níveis, lead-worker, com limite de profundidade, fila com dependências) já faz isso nativamente e melhor. Mantém um insight portátil: "a conclusão re-entra como um novo turno, nunca no meio do contexto". |
| Backends de terminal (6 contextos) | A factory do Alembic já entrega docker/podman/no-sandbox + isolamento git-worktree. Redundante. |
| Computer use, TTS neural local, faster-whisper | Stacks ML só-Python ou fora da missão distill→venture. Difícil portar, sem valor de missão. |
| 23 adaptadores de plataformas de mensagens | O Alembic é um motor interno (ADR-0001), não um gateway de assistente pessoal. Os clientes L4 são API/MCP/CLI/cockpit — não Telegram/WhatsApp. |
O IGNORE mais importante: swarm vs delegate_tool
A maior tool do Hermes na lista de IGNORE é a delegação — 3188 LOC. Recusá-la parece desperdício até você ver que o Alembic já tem o equivalente nativo e mais completo. É o comparativo que define o que "IGNORE = já tão bom" significa:
07 · A pedra angular: por que o ciclo de aprendizado fica acima de tudo
"O Alembic tem um funil de destilação e um portão de validador, mas nenhum ciclo fechado de auto-aperfeiçoamento. O ciclo de aprendizado do Hermes é a peça que falta, e ele compõe com o que o Alembic já tem em vez de substituir."
O funil transforma fontes em Learnings — mas nada realimenta esses learnings de volta ao motor. É um cano que termina no ar. O Hermes fecha esse ciclo. Veja o "antes e depois":
Duas razões para encaixar tão bem — e ambas são "encaixa", não "substitui":
08 · CLONE no papel, ADAPT na entrega (ADR-0018)
Aqui está a nuance que fecha a lição — e prova que a matriz é viva, não um decreto. O ciclo de aprendizado foi listado como CLONE, mas entregue como ADAPT. Por quê? Duas razões fundamentadas (ADR-0018):
AIAgent em Python para forkar como thread daemon, e auto-escrever burlaria o Validator Gate. Então o revisor propõe e o Validator do Alembic dispõe.Como o ADAPT funciona, passo a passo
O mecanismo virou reviewAndLearn(summary, { proposer, gate, memory }) — três portas injetadas, nada concreto. Siga o caminho de uma proposta, do resumo da run até a memória (ou ao descarte):
Essa nuance — revisor propõe, Validator dispõe, escritas com portão, tudo fail-closed — é a Lição 4 inteira. Aqui o que importa é o princípio: a matriz decide a intenção; o ADR registra como a intenção sobreviveu ao encontro com as invariantes do Alembic.
09 · Como isso se encaixa
Recue um passo e olhe a máquina inteira. A matriz não vive sozinha: ela é a dobradiça entre o que você descobriu e o que você construiu. À esquerda, os dois mapas verificados a alimentam; ela cospe um veredito por capacidade; esses veredictos viram decisões de build; as decisões viram subsistemas embarcados — e o último deles, o ciclo de aprendizado, fecha o laço de volta na origem. Sem a matriz no meio, "ler tudo do Hermes" e "construir o Alembic certo" seriam a mesma pilha indiscriminada.
Clique Percorrer o fluxo para acender um passo de cada vez — da fonte (mapas) até o laço que volta nela. A matriz é o único ponto onde o conhecimento vira decisão.
metodologia.html separado neste pacote do curso; o hub (../index.html) e a Lição 21 são a entrada de metodologia.Conecta com estas lições (e por quê)
hermes-complete-map.md que responde a pergunta P2 (a do Hermes é melhor/inédita?). Sem esse mapa, a coluna direita da matriz seria chute.reviewAndLearn, propõe→dispõe, fail-closed). A matriz decide a intenção; a Lição 4 mostra o código.delegate_tool.py (3188 LOC) é recusado — o swarm já faz delegação multi-nível nativamente e melhor.10 · Na prática
A matriz é um documento de decisão — sua "saída executável" é o stack que ela mandou construir e ligar. Você não roda "a matriz"; você inspeciona o que ela produziu de dois ângulos: (1) lê o veredito por capacidade no próprio documento; (2) confirma que o stack de modelos/adaptadores que sustenta esses subsistemas está coerente com alembic doctor --client-stack (offline, $0, sem rede). Abaixo, os dois passos reais.
A fonte de verdade da disposição de cada capacidade é a matriz em si. Abra-a e vá direto às quatro tabelas (§2.1–§2.4):
# a matriz completa — a fonte de toda disposição CLONE/ADAPT/MERGE/IGNORE docs/alembic-hermes-fusion-matrix.md # §1 legenda das disposições # §2 as quatro tabelas (2.1 CLONE · 2.2 MERGE · 2.3 ADAPT · 2.4 IGNORE) # §3 os dois CLONEs angulares · §4 esboço do pacote · §5 ordem de build
Ancorado nos dois mapas verificados: docs/alembic-complete-map.md (evidência de "Alembic hoje") e docs/hermes-complete-map.md (as §-seções do Hermes + LOC).
As disposições viraram subsistemas que rodam sobre o registro de modelos/adaptadores. Este comando valida a forma desse stack — offline, sem custo, sem rede:
$ alembic doctor --client-stack # saída esperada (offline, $0 — só valida a forma do MODEL_REGISTRY): doctor (client-stack): [OK] model-registry: N model(s) validated; 0 invalid, 0 with unknown adapter [OK] client-stack: offline mode: validated registry shape only; pass --online for live model smoke ($0 without it) summary: 2 ok, 0 warn, 0 fail
É fail-closed: qualquer entrada inválida do registro vira [FAIL] e saída não-zero — a mesma disciplina que a matriz exige (nada entra sem evidência). [uncertain] não existe um comando que "roda a matriz"; esta validação cobre o stack que ela mandou construir, não a decisão em si.
docs/alembic-hermes-fusion-matrix.md → §2.2 (tabela MERGE). Veja a coluna "Por que MERGE".docs/alembic-complete-map.md (procure MCP → conta as ocorrências; servidor existe, cliente não) · P2 contra docs/hermes-complete-map.md (§3.10 mcp_tool.py). Confira se seu par de respostas bate com a disposição da tabela.alembic doctor --client-stackO que procurar na saída:
[OK] model-registry e summary: … 0 fail. Se aparecer [FAIL], uma entrada do MODEL_REGISTRY está fora de forma (saída não-zero, fail-closed).pnpm -r typecheck && pnpm -r build && pnpm -w test — inclusive os testes de cada subsistema que a matriz mandou construir (ex.: pnpm --filter @alembic/hermes test).Fixe os conceitos (flashcards)
Clique pra virar. Tente lembrar a resposta antes de virar — recuperação ativa fixa mais que reler.
swarm=63 já faz delegação multi-nível nativamente e melhor. IGNORE = "já tão bom". Insight mantido: conclusão re-entra como novo turno, nunca no meio do contexto.AIAgent Python p/ forkar, e auto-escrever burlaria o Validator Gate. Virou passe pós-unidade: revisor propõe, Validator dispõe, fail-closed.Revisão cumulativa — recupere de memória
Antes de clicar: responda de cabeça. As quatro opções têm o mesmo tamanho de propósito — sem pista pela forma.
delegate_tool.py (delegação a subagentes, 3188 LOC) recebe a disposição IGNORE. Por quê?swarm=63 ocorrências — orquestrador de 3 níveis com lead-worker, limites de profundidade e fila com dependências; IGNORE aqui significa "já tão bom ou melhor". a erra o sentido de CLONE: a linguagem nunca é o bloqueio — todo CLONE porta o design, não o código; o motivo é que já temos melhor. b confunde os dois tipos de IGNORE: "fora de escopo" é o caso dos 23 adaptadores de mensagens, não o do swarm (que é "já tão bom"). d inventa uma dependência que não existe na justificativa. Um insight portátil é mantido: a conclusão re-entra como um novo turno, nunca no meio do contexto.MCP=8) mas não consegue consumir servidores externos; o cliente se dobra nessa superfície existente — o quadrante "já tem + Hermes acrescenta". a é factualmente falso: se já tivesse o cliente, não haveria o que fazer. c contradiz a decisão — MCP é justamente alto valor, só está estacionado como follow-up. d erra de novo na linguagem: o SDK TS torna o port mais limpo que o Python, não impossível.mcp_tool.py (4724), e tamanho não decide importância. b inverte a tese central: ele compõe com o funil, não o substitui. c é o oposto do que houve — esse CLONE virou ADAPT na entrega (ADR-0018).scoreThresholdGate(0,7) por padrão e o Validator do coda injetável depois — tudo fail-closed, com Zod na fronteira. b inventa um motivo de performance que não está na decisão. c confunde portão com tradução de linguagem — coisas distintas. d é falso: o MemoryStore já existe e é reusado (inclusive seu dedup); o ponto é validar antes de gravar, não a falta de armazenamento.