A causa raiz dos bugs de "info repetida em turns anteriores" era o
default_scope ASC do Message conflitando com .order(desc) no debounce
(ver commit f1d3a124d). Como já corrigi com .reorder, as Camadas 2, 3 e
4 viraram peso morto que adicionava latência/false positive sem ganho.
Removido:
- Camada 2 (factual sem tool → retrigger force_factual_tool)
- Camada 3 (strip de linhas repetidas com pool de outgoings anteriores)
- Camada 4 (topic gating: bloqueio quando resposta tem tópico não pedido)
- Tracker de tool calls em McpController (suportava Camada 2)
- Snapshot baseline em OutgoingJob (suportava Camada 2)
- Regra "🚨 NÃO CONFIE NA SUA MEMÓRIA" das 4 SOUL.md Hermes
Mantido:
- Camada 1: handoff intencional ("Um momento — vou verificar") +
loop detection (Jaccard >= 0.50 ou pergunta reformulada com 3+
keywords). Genuíno pra bot externo (Claro/Vivo) e loops óbvios.
- Label-guard em OutgoingJob (não dispatch se conv tem triagem_humana).
- Auto-react ambient (feature original).
- Reorder fix no combined_incoming_content (causa raiz).
Memory + user_profile reabilitados nos 4 Hermes (config.yaml) e no
template do hermes-provision pra futuros agentes. Sem memória, cliente
precisa repetir nome/CPF/contexto a cada turn — UX horrível.
Contaminação cross-unit que justificava desligar vinha de outro bug
(X-Captain-Assistant-Id apontando pro parent), já corrigido.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Antes: header MCP era setado como PARENT_ASSISTANT_ID (Captain interno).
Tools como faq_lookup buscavam dados do parent — quando Hermes id=10
tinha FAQ "senha=Prime2025" mas parent id=1 tinha FAQ "senha presencial",
o Hermes respondia com a do parent (errada).
Agora: usa ASSISTANT_ID (id próprio do Hermes recém-criado). FAQs e
qualquer outra tool que filtra por assistant.id pegam os dados certos.
Migração manual aplicada nos 4 Hermes existentes (valentina/nina/lara_h/
juliana_qnn1) trocando 6→7, 4→8, 3→9, 1→10. Sessions e state.db dos 4
foram limpos pra evitar contaminação do histórico anterior.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sem isso, todo agente novo herdava "em Ponta Negra, Natal/RN" da SOUL.md
template (Valentina é Dolce Amore — Natal). Caso real: Juliana Qnn01
respondia "em Ponta Negra, Natal/RN" sendo de Ceilândia/DF.
Adiciona campo city ao spec e sed que substitui pela localização correta
quando setado. Spec já tinha "city" no header docstring, só não era lido.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- bin/hermes-validate <slug>: 44 checks de saúde (DB, filesystem, systemd,
routing, MCP tools, humanização). Saída textual ou --json. Exit 0 sem FAIL.
- bin/hermes-provision: sed adicional substitui exemplos hardcoded de
categorias Dolce Amore (Mini Chalé 45 etc) pelas 3 primeiras categorias
da unidade nova; evita resíduo em descrições de tools.
- Fix bash: trocar `|| echo 0` por `|| true` em greps (evita "0\n0" quando
grep -c não acha e ainda imprime contagem).
Validado em juliana_qnn1: 43 PASS / 0 FAIL / 1 WARN (gallery seed pendente).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bug: Juliana de Qnn01 oferecia categorias do Dolce Amore (Apartamento,
Mini Chalé 45, Suíte Ouro). Vazamento via:
1. Hermes daemon memory_enabled+user_profile_enabled — acumula contexto
entre turnos no mesmo profile.
2. Codex/ChatGPT memória user-level — todos os profiles compartilham o
mesmo OAuth (borbamachadoo@gmail.com), então ChatGPT lembra de
conversas com Valentina e bleeda no LLM da Juliana.
3. Tool descriptions com exemplos motel-flavored (já corrigido em commit
anterior).
Fix permanente no script hermes-provision:
- sed do config.yaml zera memory_enabled e user_profile_enabled
- append no SOUL.md adiciona "REGRA CRÍTICA — IGNORE OUTRAS UNIDADES"
com lista explícita de categorias válidas (extraída do spec.categories)
e instrução pro LLM ignorar memória de outras unidades.
Aplicado retroativamente em juliana_qnn1 + sessions/state.db limpos.
Próximos agentes do Construtor nascem com essa proteção por padrão.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bug: find_or_initialize_by(name: ...) batia em captain_interno existente
com mesmo nome (ex: 'Juliana') e SOBRESCREVIA engine='hermes'. Resultado:
Juliana captain_interno virou Hermes, atendimento legado quebrou.
Fix: chave passa a ser (account_id, hermes_profile_name=slug). Auto-sufixa
nome com ' · Hermes' se colidir com captain_interno do mesmo nome (a não
ser que já tenha 'Hermes' no nome). Também grava captain_unit_id no
record (relação direta agora que existe a coluna).
Reverti manualmente Juliana id=1 + criei id=10 'Juliana · Hermes' fix in
DB. Future provisionamentos pelo Construtor usam o caminho corrigido.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bash script em bin/hermes-provision (instalado em /usr/local/bin/ na VPS)
que recebe spec JSON via stdin e provisiona um agente Hermes ponta-a-ponta:
- Valida spec (slug regex, preços 0-5000, períodos/buckets do catálogo)
- Aloca porta livre no range 8650-8699
- Gera HMAC secret via openssl rand
- Cria Captain::Unit (find_or_create), Captain::PricingCategory/Amount,
Captain::Assistant (engine=hermes) via docker exec rails runner
- Copia template profile da Valentina, patcheia config.yaml com porta +
X-Captain-Assistant-Id (parent_id se setado, senão self id)
- Escreve SOUL.md/SKILL.md do spec
- Gera webhook_subscriptions.json com secret
- Cria systemd unit hermes@<slug>.service e enable+start
- rsync profile pra repo de backup git local
- Idempotente: re-rodar com mesmo slug não duplica nada (find_or_create)
- --dry-run valida sem escrever
- --rollback <slug> destrói tudo (DB + systemd + filesystem)
Construtor (Hermes daemon) chama via terminal skill nativa:
echo '<spec>' | /usr/local/bin/hermes-provision
Próximo passo: atualizar SOUL.md/SKILL.md do Construtor pra invocar
o script ao final do fluxo socrático.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
