Você levou um config.yaml antigo para uma máquina nova, ou desinstalou um plugin algumas semanas atrás e renomeou um toolset. O Hermes inicia, conversa e parece perfeitamente saudável — até que um dia um bot de plataforma para de responder, ou uma classe inteira de ferramentas simplesmente desaparece. Você abre o arquivo de config e todos os nomes que esperava continuam ali.

Isso é config rot: os nomes de toolset salvos em platform_toolsets são o que o Hermes acreditava existir no momento de salvar. Depois que um plugin é removido ou um toolset é renomeado, esses nomes não apontam para nada, e o runtime os ignora em silêncio. Um patch mesclado em 2026-09-29 (PR #127782, recuperando o #127392 e mantendo a autoria original) faz o hermes config check reportar as seleções obsoletas e alinha o julgamento dele com o do runtime.

Um único resolver, três pontos de chamada

O núcleo estrutural do patch é condensar a pergunta “este nome salvo ainda é um toolset real?” em uma única função:

# hermes_cli/toolset_validation.py
def saved_toolset_resolver(config: dict) -> Callable[[str], bool]:
    """is_valid_toolset for a saved platform_toolsets list, mirroring what
    tools_config._get_platform_tools lets through."""

Tanto o hermes config check quanto o hermes config migrate agora passam por ela. Por que isso importa? Porque antes da correção o migrate avisava sobre nomes de servidores MCP e bundles de plugin-plataforma configurados corretamente — a ponto de sugerir que você trocasse 'hermes-teams' por 'hermes-teams'. Uma verificação de migração que discute consigo mesma é puro ruído.

As novas regras merecem ser lembradas, já que explicam por que sua config parou de gritar:

• Um servidor MCP configurado conta como conhecido, mesmo quando declara enabled: false. Ele está inativo, não é um erro de digitação. O código antigo tratava “inativo” como “não reconhecido” e produzia um “unknown toolset — did you mean hermes-cli?” inútil.
• known_plugin_toolsets deixou de ser prova de que um toolset existe. Ele registra o que uma plataforma recebeu no momento de salvar, então escondia exatamente o caso para o qual essa verificação existe: nomes deixados para trás por plugins desinstalados.
• A busca de plugins e a varredura do manifest de plataforma rodam apenas para nomes que as verificações mais baratas não conseguem resolver. Uma config limpa nunca dispara a descoberta de plugins, então a verificação em si não custa nada.

Plataformas desativadas: julgadas como o runtime as enxerga

A segunda família de alarmes falsos vinha de plugins.disabled. O runtime é tolerante quanto ao formato — só honra uma lista — mas a verificação antiga julgava o valor YAML cru, então esta linha:

plugins:
  disabled: platforms/telegram   # a string, ignored by the runtime

era reportada como “platform disabled” enquanto o runtime continuava carregando a plataforma numa boa. Agora a verificação lê pelo próprio leitor do runtime (_get_disabled_plugins()), então um valor que não é lista não é mais reportado como se desativasse alguma coisa.

E quando ela de fato reporta, verifica se as credenciais obrigatórias da plataforma estão realmente configuradas:

platform plugin 'platforms/telegram' is disabled while its required credentials are configured.
Run `hermes plugins enable platforms/telegram` if you want it active.

Repare no “required”: o critério é _platform_manifest_env_entries(optional=False), então variáveis opcionais nunca contam. Uma plataforma desativada sem token é deixada em paz, e uma variável de ambiente opcional não pode ser confundida com “você claramente queria rodar isso”.

Um crash corrigido e uma verificação removida

Mais duas coisas que parecem não ter relação, mas têm:

• Um mcp_servers malformado não derruba mais o comando. Escreva-o como lista por acidente (mcp_servers: [a]) e o código antigo levantava um traceback de AttributeError; agora ele roda e reporta o problema como um diagnóstico comum. Um comando de diagnóstico que morre é o tipo menos útil de falha.
• A verificação do toolsets de nível superior foi embora. O PR original também validava a chave toolsets de topo, mas a CLI resolve toolsets a partir de --toolsets ou platform_toolsets, e lê a chave de topo apenas para o opt-in legado do kanban. Verificar uma chave que o runtime nunca lê só inventa trabalho para você.

A tabela abaixo vem da própria execução de validação do patch (hermes config check real, HERMES_HOME temporário), com o comportamento antigo à esquerda:

Caso	Antes	Agora
platform_toolsets.cli lista um nome removido	reportado	reportado
toolset de um plugin desinstalado, lembrado em known_plugin_toolsets	silencioso	reportado
servidor MCP com enabled: false listado em platform_toolsets	“unknown toolset, did you mean hermes-cli?”	silencioso
mcp_servers: [a] (formato errado)	traceback de AttributeError	roda
plugins.disabled: platforms/telegram (string) com um token configurado	reportado como desativado (o runtime ainda o carrega)	silencioso
plugins.disabled: [platforms/telegram] com um token configurado	reportado	reportado

Por que sua config antiga ainda é interpretada

Uma verruga histórica é fácil de passar batido: builds antigos do hermes config set armazenavam um argumento de array JSON puro como string, então uma config pode conter isto:

platform_toolsets:
  cli: '["browser", "terminal"]'    # a string, not a list

O runtime, o hermes doctor e o hermes plugins enable agora leem essa seção pelo mesmo parser, então concordam sobre o que você configurou. Quando um único leitor carrega sua própria gambiarra de compatibilidade, os outros dois acabam enxergando uma configuração diferente.

Quando rodar

Versão curta: depois de trocar de máquina, desinstalar um plugin, renomear um toolset ou atualizar de um build mais antigo.

hermes config check      # report saved selections that no longer resolve
hermes config migrate    # migrate and repair using the same resolver
hermes tools             # interactively pick toolsets again
hermes plugins enable platforms/telegram   # enable a platform the check flagged

Três julgamentos práticos:

1. Diante de “desativado enquanto suas credenciais obrigatórias estão configuradas”, pergunte-se se você o desativou de propósito. A própria verificação admite isso — uma credencial configurada é só um motivo para mencionar o caso. Se você quer a plataforma ativa, rode o hermes plugins enable sugerido.
2. Diante de um nome de toolset que não resolve mais, não o apague na hora. Verifique se ele pertencia a um plugin desinstalado; se você ainda quer essa capacidade, reinstale o plugin. Apagar o nome só significa reconfigurá-lo depois.
3. Um config check limpo não é uma config perfeita. Ele só julga se as seleções salvas podem ser honradas pelo runtime — não se o seu modelo é uma boa escolha ou se suas chaves estão em dia. Use o hermes doctor para esse tipo de pergunta.

E essa verificação só se torna útil se a própria config permanecer organizada: o guia de configuração de MCP e o artigo sobre o catálogo de plugins defendem a mesma ideia — adicionar e remover plugins ou servidores MCP precisa ser seguido de uma limpeza na config. Este patch tira essa etapa da sua memória e a coloca em um comando.

A versão curta

• O hermes config check agora reporta nomes salvos em platform_toolsets que não resolvem mais, além de plataformas desativadas enquanto suas credenciais obrigatórias estão configuradas.
• Ele compartilha um único resolver com o hermes config migrate, acabando com avisos que se contradiziam, como sugerir 'hermes-teams' para 'hermes-teams'.
• O julgamento acompanha o runtime: um servidor MCP desativado é conhecido, known_plugin_toolsets não é evidência, um plugins.disabled que não é lista não mente mais, variáveis de ambiente opcionais nunca contam como obrigatórias.
• A descoberta de plugins roda só quando necessário, então uma config limpa não paga nada; um mcp_servers malformado não derruba mais o comando.
• A verificação da chave toolsets de nível superior foi removida porque a CLI nunca a lê (apenas o kanban legado).
• Rode isso depois de trocar de máquina, remover plugins ou atualizar, e repare com hermes config migrate e hermes tools.

Uso completo em hermes config e hermes plugins.