fix(cli): align mops update with outdated, and say it rewrites mops.toml

[Kamirus]

Three consistency gaps between mops update and mops outdated, all of which make a scripted update quietly misbehave.

mops update reported failure and exited 0

$ mops update no-such-package
  Package "no-such-package" is not installed!
Before: $? = 0
After:  $? = 2

A typo in a scripted update looked like success. It now exits 2 — the same code mops outdated uses for "the check could not be completed" (#734) — for an unknown package and for a missing mops.toml. 1 is deliberately not reused: it means "updates are available", which cannot be a terminal state for a command whose job is to apply them.

The two commands could disagree about GitHub deps

#734 extracted getAvailableGithubUpdates precisely so outdated and update could not drift apart on what "out of date" means for a repo = "..." dependency — but update kept its own inline loop resolving branch heads, so the rule still existed twice. It now uses the helper. The helper needed no changes: it already carries the repo, branch, resolved head and dependency name, which is exactly enough to rebuild the pin URL.

Behaviour is preserved deliberately and specifically: the same add(url, { dev, lock: "skip" }, name) call, dev still derived from where the dependency is declared, the alias key still passed through as the manifest key, and a failed lookup still prints and lets the rest of the run continue. Two visible nuances: lookups now run concurrently rather than sequentially (same request count against GitHub's 60/hour limit), and lookup errors print after the re-pins rather than interleaved with them.

Neither --help nor the docs said it rewrites your manifest

mops update is cargo upgrade semantics — it rewrites mops.toml — not cargo update, which only touches the lockfile. #723 records the decision to keep the name (under exact pins there is only one update operation that can exist, so there is no ambiguity to resolve, and renaming would be breaking). The agreed remedy was to say so plainly, which neither the help text nor the doc page did:

$ mops update --help
Rewrite the versions in mops.toml to the highest semver-compatible ones within
the caret bound (does not cross major versions, or pre-1.0 minor versions)

Rewrites the new versions into mops.toml, and keeps mops.lock in sync.
GitHub dependencies are re-pinned to their branch head (one GitHub API call each).

Exit codes:
  0  mops.toml is up to date
  2  the update could not be run (no mops.toml, unknown [pkg])

Follow-up worth flagging

One divergence of the same family is left in place: update still exits 0 when a GitHub lookup fails — it prints Failed to update <name>: … and carries on — where outdated exits 2. Changing it would alter behaviour beyond the scope of aligning the "not installed" case, so it is called out rather than folded in.

Items 35, 36 and 37 in #723.

🤖 Generated with Claude Code

[github-actions]

Cursor AI review

👍 APPROVE — looks safe to merge

Category	Assessment	Details
Summary	✅	Aligns mops update with mops outdated: exit 2 for missing config/unknown pkg, shared getAvailableGithubUpdates, and docs/help stating it rewrites mops.toml.
Code Quality	✅	Removes duplicated GitHub branch-head loop in update.ts in favor of getAvailableGithubUpdates in available-updates.ts; URL rebuild (org/name + branch + latest) matches the prior add(...) shape.
Consistency	✅	Exit 2 matches outdated.ts; --help/docs/skills/changelog updated together; tests mirror outdated.test.ts mocking style.
Security	✅	No auth/integrity changes; traced update → add / checkIntegrity / getAvailableGithubUpdates → getGithubCommit — same pin rewrite path, no widened trust.
Tests	✅	cli/tests/update-command.test.ts covers exit 2/0, registry add args (incl. pinned alias + --dev), GitHub re-pin/no-op/filter, and lookup/add failure continue-on-error.
Maintainability	✅	Single shared “outdated GitHub dep” rule prevents command drift; intentional leftover (GitHub lookup failure still exits 0 on update) is documented in the PR body.

Verdict

Decision: APPROVE
Risk: Low
Reason: Contained CLI consistency/docs fix with equivalence verified against the shared GitHub helper and solid unit coverage; exit-code correction is intentional and matches outdated.

---

Generated for commit 8319328

[automation-sa-sre]

Automated approval: the AI review verdict for 5141264 is APPROVE. See the "Cursor AI review" comment for details.

[automation-sa-sre]

Automated approval: the AI review verdict for 8319328 is APPROVE. See the "Cursor AI review" comment for details.