mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-11-06 05:17:15 +00:00
kshitijk4poor
e090092285
A catalog memory provider (Honcho today) has no way to own its per-profile setup or its dashboard config file, so core carries that code for it: profile create/rename edit Honcho's host blocks and the dashboard has a Honcho-only storage kind that imports the plugin's private modules. These seams let a provider do that work itself; core's Honcho code is untouched here and is removed in a follow-up once the plugin implements them. - MemoryProvider.on_profile_created(profile_name, hermes_home) / on_profile_renamed(old, new, hermes_home): called from create_profile (CLI, dashboard, Desktop/TUI) and rename_profile for the provider the profile's effective config selects, with that profile's home and its own .env secrets bound. A failing hook or unreadable config is logged and never fails the create or rename. No-ops by default. - storage=STORAGE_PROVIDER in config_schema.py, with read_config_fields(hermes_home) / write_config_fields(values, hermes_home): the provider owns its file layout. Core keeps value coercion, placeholders, write-only secrets, the memory.provider switch and the 400 on a refused write, and saves secrets to .env only after the provider accepted them. _record_profile_rename moves to profile_identity.py (profiles.py line budget).