A newer release is news.
Not permission.

1. Check the release information

node momm/scripts/multi-review.mjs update

Reads the public manifest, compares versions and shows intervening release notes. It does not fetch Git objects, change code, relink a harness or install a tool. Network and validation failures leave the installation alone.

2. Inspect the actual changes

node momm/scripts/multi-review.mjs update --dry-run

This explicitly fetches the candidate into disposable staging and verifies its signature. The plan names the remote, tag, changed files and exact installation scopes. It shows the SKILL.md diff plus the full dispatcher diff, conservatively covering default rules and reviewer personas.

Because skills are linked from one shared clone, the plan includes sibling-skill and repository changes too. Your project’s own .reviewrules is not rewritten.

3. Choose whether to install

node momm/scripts/multi-review.mjs update --apply

A changed protocol requires another explicit decision:

node momm/scripts/multi-review.mjs update --apply --accept-protocol

For a script, add --yes to acknowledge the install plan. It never substitutes for --accept-protocol. The update command has no automatic mode. From 1.16 a separate, off-by-default automatic-update setting exists for the owner to switch on (Setup Center, or ~/.momm/settings.json); an agent never enables it, it applies only signature-verified releases, and protocol changes still need their own acceptance unless the owner has separately allowed that too.

The updater refuses a dirty checkout, verifies the signed package and SHA-256, checks out the exact commit in detached-HEAD state, and replays only the installation scopes in the receipt. It records success only after checking the resulting checkout and relinks.

Choose a channel, without changing code

node momm/scripts/multi-review.mjs update --channel pinned

Return to the previous installation

node momm/scripts/multi-review.mjs update --rollback

The previous commit, package digest and harness receipt are retained locally. If a release switch or interrupted process removes the regular updater, use the recovery command printed at installation/update. For a normal clone:

node .git/momm/update.mjs --rollback --yes

Rollback checks the retained Git objects and refuses to overwrite local edits. It is not a backup for a deleted clone, missing Git objects, removed harness tools or a damaged disk. Interrupted relinking may need the named prerequisite restored before recovery can finish. Git worktrees have a different administrative path; use the exact printed recovery path.

Trust on the way in

Signed tags are checked using gitsign, against the exact repository release-workflow identity and GitHub’s OIDC issuer. The updater does not install gitsign silently. If it is missing, install it deliberately using its official instructions and retry.

Verification can contact Sigstore’s trust and transparency services as well as GitHub. Package hashes cover Git’s canonical tracked file bytes, modes and paths, excluding versions.json to avoid a self-referential digest. Reports separately record hashes of the installed dispatcher, updater and protocol bytes.

A signature establishes release provenance—not correctness. Tests, review and your protocol acceptance still matter.

The daily check stays a check

A once-per-day notice makes one unauthenticated request for the public manifest, and never fetches code. NO_UPDATE_CHECK=1 or DO_NOT_TRACK=1 disables it. Explicitly running update is still your request for release information.

If an agent sees a newer version, it must tell you and stop the update workflow. It must not run --apply on its own initiative. Setup Center’s update button opens the same preview—not git pull.