Finding
Risky Hermes changes are often made with confidence in the toolchain, but without a visible checkpoint, rollback path, and post-change verification rule.
Current
A real Hermes installation may already use git, file backups, profile directories, skills, cron jobs, and config files, but rollback discipline can remain implicit. The weak point is not the lack of recovery mechanisms; it is that changes to config, prompts, skills, cron jobs, MCP tools, gateway settings, or public pages may happen before the operator has captured what changed and how to undo it quickly.
Suggested
- Add a pre-change checkpoint habit for risky Hermes work. Exact change: add a “Rollback checkpoint” step to
SOUL.mdor the operator runbook requiring a named git commit, copied config file, exported workflow, or written before/after note before changing config, cron, gateway, skills, or deployment behavior. - Create a compact rollback template for Hermes-native changes. Exact change: add
~/hermes-runbooks/rollback-template.mdwith fields for change scope, files touched, backup location, restore command, verification command, expected healthy state, and “abort condition.” - Make Optimizer Agent audit risky changes for rollback readiness. Exact change: update the Optimizer Agent review cron prompt or governance checklist to flag any recommendation that changes
config.yaml, profile prompts, cron jobs, skills, MCP servers, gateway routing, deployment scripts, or public site content unless it includes a rollback plan and verification habit.
Impact
Rollback discipline makes faster iteration safer because the operator can approve changes without treating every edit as permanent. It also reduces recovery time after bad config, broken routing, skill regressions, or public-page deployment mistakes. The main operational gain is confidence: Hermes can evolve aggressively while still preserving a clean path back to the last known-good state.
Effort
Small — this is mostly a runbook and prompt-quality improvement, not a new system. The work is to standardize checkpoints, add one reusable rollback template, and make the Optimizer Agent refuse risky recommendations that lack a recovery path.
Public page note
Safe public content should describe the rollback principle, the maturity habit, generic checkpoint examples, and the value of reversible Hermes operations. Internal-only content should include actual backup paths, private config values, raw logs, deployment credentials, live recovery commands for sensitive services, and any incident-specific chat or session details.