Finding
Hermes configuration changes often become risky when provider, gateway, TTS, model, or dashboard edits are made directly without a small-change, backup, and verification discipline.
Current
A real Hermes installation typically has several configuration surfaces: config files, profile settings, gateway settings, environment references, model/provider routing, TTS options, and public dashboard copy. The weak point is not knowing how to edit them; it is making an urgent change without first identifying the exact file, preserving a rollback path, limiting the diff, and verifying the live behavior afterward.
Suggested
- Add a config-change runbook for all Hermes-native settings. Exact change: Create or update
docs/runbooks/hermes-config-change.mdwith this checklist: identify target file or dashboard setting, record intended outcome, create backup, make the smallest possible edit, restart only the required service, verify behavior, and document rollback. - Add a “minimal diff only” rule to the operator profile. Exact change: Patch
SOUL.mdor the optimizer-agent operating prompt with: “For Hermes provider, gateway, TTS, model, dashboard, or env-related changes, read the current config first, change only the necessary key, avoid broad rewrites, and include a rollback note before recommending deployment.” - Add a post-change verification habit for sensitive config edits. Exact change: Add a verification section to the relevant config skill or runbook requiring one concrete check after each change, such as
hermes config get,hermes tools, a gateway smoke test, a TTS sample, a dashboard route check, or a model fallback test, depending on the edited surface.
Impact
This turns configuration work from “edit and hope” into a controlled operational procedure. It reduces downtime, prevents accidental provider or gateway breakage, and makes rollback possible when a change behaves differently in production. It also keeps public dashboard and achievement pages aligned with real Hermes behavior without exposing private settings.
Effort
Small — the main work is adding one runbook, one operating rule, and one verification checklist; the discipline then repeats across future config changes.
Public page note
Safe public content: the maturity principle, generic config-change workflow, example verification habits, and the operational benefit of backups, minimal diffs, and smoke tests. Internal-only content: actual config files, env values, provider keys, gateway tokens, private dashboard settings, raw logs, chat transcripts, filesystem paths containing secrets, and any live action console details.