hermes - 💡(How to fix) Fix hermes doctor: add 'doctor.ignore' config to silence checks for features the user has opted out of [1 participants]

Summary

hermes doctor reports many warnings for optional providers, integrations, and tools that the user has explicitly chosen not to install or use. There is no way to tell doctor "I don't need this" short of editing source. For long-term users this turns the doctor output into mostly-irrelevant noise that drowns the genuinely actionable warnings (config issues, missing required keys, broken submodules).

A doctor.ignore config key would let users opt out of specific checks while keeping the default "show everything" behavior for new users.

Related: #17929 (a real bug that gets buried under unrelated ⚠ lines today).

Background

Current behavior (HEAD 2d137074a): doctor walks a hardcoded list of capabilities and emits ⚠ for each unconfigured one, with no way to acknowledge "this is intentional". A typical experienced user sees something like:

◆ Auth Providers
  ⚠ Nous Portal auth (not logged in)
  ⚠ Google Gemini OAuth (not logged in)
◆ External Tools
  ⚠ WhatsApp bridge deps (3 critical, 0 high, 0 moderate ...)
◆ API Connectivity
  ⚠ OpenRouter API (not configured)
◆ Tool Availability
  ⚠ homeassistant (system dependency not met)
  ⚠ moa (missing OPENROUTER_API_KEY)
  ⚠ rl (missing TINKER_API_KEY, WANDB_API_KEY)
  ⚠ hermes-yuanbao (system dependency not met)
  ⚠ spotify (system dependency not met)

None of these are problems — the user simply doesn't use those features. Today doctor has no signal of intent vs. omission, so it conservatively warns on everything.

Proposed feature

A doctor section in config.yaml with a flat ignore list keyed by stable check IDs:

doctor:
  ignore:
    - nous-portal
    - gemini-oauth
    - openrouter
    - homeassistant
    - hermes-yuanbao
    - spotify
    - moa
    - rl
    - tinker-atropos
    - whatsapp-bridge-audit

A flat list (rather than nested-by-section) keeps the config minimal — section names rot when doctor reorganizes, but check IDs are referenced directly in code and can be kept stable. Open to a nested form if maintainer prefers; happy to either.

Behavior:

• A check whose ID is in doctor.ignore is skipped silently.
• hermes doctor --show-ignored re-includes them (for "I want to revisit my opt-outs"), printed in a dimmed style or grouped under a separate ◆ Ignored section.
• hermes doctor --fix continues to ignore them (no surprise side effects).
• The default config (no doctor.ignore key) is unchanged — new users still see everything.

Implementation sketch

hermes_cli/doctor.py already has localized check functions and string-formatted check labels. The minimal change is:

1. Define a stable check ID at every check_warn(...) and check_ok(...) call site that corresponds to an opt-out-able capability. (Many already have natural IDs from TOOLSET_REQUIREMENTS, provider_id, submodule directory names.)
2. Wrap check_warn / check_ok with a thin _emit(check_id, status, text, detail) helper that consults doctor.ignore from config and skips when matched.
3. Document the supported IDs via hermes doctor --list-check-ids.

The bulk of the logic touches doctor.py's run_doctor(). Estimated diff: < 200 lines, no behavioral change for users who don't add the config block.

Why a config knob, not a CLI flag

hermes doctor is run interactively, in CI smoke tests, and indirectly by hermes setup / hermes update / various error paths that suggest "run hermes doctor for diagnostics." A CLI flag would help interactive use only; a persistent config makes the noise reduction stick across all entry points.

Adjacent: misleading "no API key in .env" warning

While we're touching this area, the ⚠ No API key found in ~/.hermes/.env check is a particularly common source of confusion for users who store provider keys in auth.json / credential_pool (the documented path for alibaba-coding-plan, claude_code, openai-codex, etc.). Suggest gating this warning on whether auth.json has any populated credential_pool entries before printing it. Happy to fold this fix into the same PR if maintainer wants.

Willing to PR

If the design above is acceptable I am willing to send a PR. Confirm:

1. Preferred config shape (flat as proposed vs. nested-by-section).
2. Whether --show-ignored and --list-check-ids flags are wanted.
3. Whether to bundle the misleading-.env fix in the same PR.