hermes-updates

Topics in the source

• Hermes Updates
• When to Use
• Decide first
• Non-negotiables
• Failure-mode index
• Proof
• References

| You hear / see | Do | |---|---| | "upgrade Hermes", "update to latest", "are we behind?" | decide first → owner-requested upgrade | | update failed / CLI will not start after update | failure-mode index | | no dependency environment is committed … run hermes pm repair | references/install-layout.md | | hermes --version looks old, unattended timer silent for days | references/install-layout.md → updater frozen | | hermes: a source update is unfinished | advisory tail, no action needed | | deciding whether new commits are worth taking | drift assessment (references/upgrade-execution.md) | Load the runtime's own CLI reference (if the install ships one as a skill) for current command syntax; load the operations skill when the task also moves config, sessions, or backups. 1. Which channel? hermes update --check prints the channel and the offered commit. Official checkouts default to stable; a release channel installs an exact commit, so a healthy checkout is detached (git rev-parse --abbrev-ref HEAD → HEAD). Never add a main-only guard. 2. Behind what? git fetch --all --tags --prune, then git rev-list --left-right --count HEAD...origin/main. Judge staleness from · upstream vs git rev-

This is an excerpt. Refer to the complete source and its current requirements.