Update & rollback

Update, rollback, refresh, and runtime releases. An update activates only a revision merged on the sum origin default branch, resolved to an immutable SHA.

Update and roll back

./bin/sumctl update check          # fetch origin, resolve the merged revision, report default/active/compatibility
./bin/sumctl update apply          # stage the release, validate coexistence, switch .local/current, fast-forward a clean clone
./bin/sumctl update status
./bin/sumctl update rollback       # reselect the recorded previous approved runtime; records, questions, reports, worktrees stay
./bin/sumctl update recover --generation GENERATION

It never resets, stashes, or force-updates a dirty or diverged tree, never edits a development or task checkout, never restarts Herdr, agents, dev services, or a connected MCP server, and never upgrades Herdr. Staged files are not approval. An interrupted update requires explicit generation-bound recovery before another apply or rollback. Commands already running finish on the runtime they resolved; worker briefs carry stable <installation>/bin/sumctlcommands, so their callbacks keep working across the switch. A refusal names the exact incompatibility and leaves the old installation serving.

Refresh running sessions

./bin/sumctl refresh request               # coordinator contract plus every non-archived task
./bin/sumctl refresh status                # confirmed / submitted-unconfirmed / pending-busy / pending-unreachable / unreachable / capability-deferred
./bin/sumctl refresh adopt --coordinator rN

An update changes which code new commands run; a refresh asks the sessions that are already running to reread their operating instructions, one at a time, without restarting anyone. Only a pane that exists, runs in the recorded checkout, and is reported idle or done receives a short fixed message naming the revision. A worker adopts at its next safe point with brief adopt. Four things stay separate: the installation default, the runtime a process actually resolved, the revision requested of a session, and the revision that session reports it has read. A submitted prompt is not a receipt and a receipt is not proof of compliance.

Runtime releases

./bin/sumctl release stage            # builds .local/releases/<sha> for HEAD; nothing is activated
./bin/sumctl release list

A release holds the committed sum tree, its own pinned tool links, its own Go Mesh binary, and a release.json manifest with source SHA, content hashes, dependency pins, and contract versions. It is validated before it appears, kept read-only, and never contains state. Re-running mise run setup never rewrites an existing native binary or retargets a tool link either.