hermes - 💡(How to fix) Fix [Feature]: hermes update should track the latest release, not the latest main commit

Summary

hermes update upgrades to the latest commit on main, not the latest tagged release. This means every update pulls in unreleased, rolling code. There's no supported way to track stable releases, and a user pinned to a release tag is actively forced back onto main.

Current behavior (hermes_cli/main.py)

• The update target defaults to main (_resolve_update_branch); tags are never a candidate.
• It pulls to the tip of origin/main — i.e. whatever was merged most recently, including commits that may be hotfixed minutes later.
• L9043-9053: if HEAD is detached (the state you're in when pinned to a tag), it prints ⚠ Currently on detached HEAD — switching to main for update... and runs git checkout main. So pinning to a release cannot survive an update — the command drags you back to main.

Why this matters

Releases (vYYYY.M.D tags) exist precisely to mark vetted, stable points. But the update path bypasses them entirely and always lands users on bleeding-edge main. Anyone who wants "only run code that made it into a tagged release" has no way to express that — and the tool works against them.

Proposal

1. Default hermes update to the latest release tag (newest vYYYY.M.D) instead of the latest main commit. This is the safer default for the typical user who just wants a working, stable install.
2. Support targeting a specific release, e.g. hermes update --release <tag> (and a --release latest / --channel=stable form for the newest tag).
3. Keep main as an opt-in fast channel for users who explicitly want bleeding-edge, e.g. hermes update --branch main / --channel=edge — preserving today's behavior for those who want it.
4. Stop force-switching an intentionally tag-pinned (detached HEAD) install onto main; treat a tag-pin as a valid state to update within the release channel.

Illustrative risk (not the core ask, just motivation)

A main HEAD between two tags once shipped a runtime ImportError — a "prune unused imports" commit dropped a re-export still used elsewhere, fixed a few commits later. A release-tracking user would never have hit that window; a main-tracking user could. (The existing post-pull guard only py_compiles files, so a valid-syntax ImportError slips through regardless.)

Today's manual workaround

cd ~/.hermes/hermes-agent
git fetch --tags origin
git checkout $(git tag --sort=-creatordate | head -1)   # latest release
uv pip install -e .   # or pip install -e .
hermes gateway restart

...and then not run hermes update, since it would switch back to main.

Environment: pinned v2026.5.29 (hermes-agent 0.15.1), Linux.