feat(hermes): integrate Hermes support into the application.

[danzhewuju]

Description

This MR adds initial Hermes support to the application and integrates it into the existing provider management flow. It introduces Hermes config read/write support, live config import, provider add/update/remove handling, current provider persistence, and basic CLI/TUI integration.

Hermes is also added to app visibility settings, app type parsing, and related provider display logic. Test coverage is included for app registration, visible app settings, and current provider behavior so that the integration stays consistent with the existing OpenCode / OpenClaw flow.

Screenshot

issues

#132

[SaladDay]

This is a very large project. You can send me an email(saladday@foxmail.com), and we can discuss the specific support plan.🙂

[danzhewuju]

I resolved a conflict today. Do you have time to review this PR recently? @SaladDay

[SaladDay]

Thank you for your contribution. I will review it soon.

[SaladDay]

The direction is useful, but I can't merge this as-is because the Hermes integration is not yet aligned with upstream behavior.

The main blockers are:

1. Hermes MCP is not wired up. The PR adds Hermes flags, but sync/remove/import paths are empty
   or skipped. Upstream has full mcp/hermes.rs logic for converting, preserving Hermes-specific
   fields, importing, and removing servers.

2. Hermes Skills support is incomplete. The schema adds enabled_hermes, but the skills DAO does
   not read/write it, and SkillService still excludes Hermes from supported apps. This means the TUI
   can expose the concept, but enablement will not persist or sync to ~/.hermes/skills.

3. hermes_config.rs is much smaller than upstream and misses important behavior: provider key
   normalization, models array/dict conversion, providers: dict read-only handling, section-level
   YAML writes, field preservation, MCP section helpers, backups, and memory helpers. This can write
   config that Hermes does not actually understand.

4. The TUI provider form is not functionally equivalent to upstream. Upstream supports a model
   list with model id, display name, context length, fetch models, and provider-level
   rate_limit_delay. This PR currently has a single model field plus raw JSON editing, so it does
   not match the required feature surface.

5. Hermes memory management is missing. Upstream exposes Hermes memory read/write, enable
   toggles, limits, and a Memory panel. Dashboard can be deferred, but memory management still needs
   to be implemented.

Please rework this by porting the upstream Hermes backend behavior first, then make the TUI match
the same functional surface. Once MCP, Skills, provider config, and Memory are aligned with
.upstream, I can review the UI details and smaller edge cases.

[danzhewuju]

The direction is useful, but I can't merge this as-is because the Hermes integration is not yet aligned with upstream behavior.

The main blockers are:

1. Hermes MCP is not wired up. The PR adds Hermes flags, but sync/remove/import paths are empty
   or skipped. Upstream has full mcp/hermes.rs logic for converting, preserving Hermes-specific
   fields, importing, and removing servers.
2. Hermes Skills support is incomplete. The schema adds enabled_hermes, but the skills DAO does
   not read/write it, and SkillService still excludes Hermes from supported apps. This means the TUI
   can expose the concept, but enablement will not persist or sync to ~/.hermes/skills.
3. hermes_config.rs is much smaller than upstream and misses important behavior: provider key
   normalization, models array/dict conversion, providers: dict read-only handling, section-level
   YAML writes, field preservation, MCP section helpers, backups, and memory helpers. This can write
   config that Hermes does not actually understand.
4. The TUI provider form is not functionally equivalent to upstream. Upstream supports a model
   list with model id, display name, context length, fetch models, and provider-level
   rate_limit_delay. This PR currently has a single model field plus raw JSON editing, so it does
   not match the required feature surface.
5. Hermes memory management is missing. Upstream exposes Hermes memory read/write, enable
   toggles, limits, and a Memory panel. Dashboard can be deferred, but memory management still needs
   to be implemented.

Please rework this by porting the upstream Hermes backend behavior first, then make the TUI match the same functional surface. Once MCP, Skills, provider config, and Memory are aligned with .upstream, I can review the UI details and smaller edge cases.

Thank you for your review. Your feedback is very helpful. This PR indeed lacks full support for certain features. I will make changes as soon as possible based on your suggestions.