dotfiles-autoupdate: keep the gantry CLI in step with prod

[DJRHails]

Why

The gantry CLI is a uv tool installed from a local checkout directory on every host, and that receipt shape can never self-update — uv tool upgrade just re-reads whatever commit the working tree happens to sit at. taffy ran a 16-minor-versions-stale CLI (0.203.0 vs prod 0.219.1) until a missing transcribe subcommand gave it away on 2026-08-17, and even the hand-run upgrade only reached the checkout's own stale 0.216.1.

What

• ensure_gantry_cli_fresh in the daily autoupdate: compares the installed version against prod /health (one curl/day when current) and on drift reinstalls from git+https://github.com/DJRHails/gantry@main — gantry deploys straight off main, so main is the released version. --force migrates the old directory-shaped receipt to the git source on first fire, so the local checkout stops mattering. Hosts without the tool are skipped (installing fresh stays a human action — the token needs wiring by hand); every failure path logs and returns 0.
• skill doc (gantry-cli/references/install.md): install recipe now uses the git source, documents the auto-update, and taffy's host-inventory row corrected (token has been wired since 2026-08-17).

The private-repo clone rides ensure_github_ssh_rewrite's insteadOf on keyed hosts; the pi package refresh already proves agent-less git-over-SSH works from the timer environment.

Verification

Ran the updated script end-to-end on taffy against real drift:

gantry: updated 0.216.1 -> 0.229.1 (prod is 0.229.1)

Receipt now git = "https://github.com/DJRHails/gantry?rev=main"; gantry agents works. shellcheck clean; new code shfmt -i 2 clean (pre-existing drift in untouched lines left alone).

via claude @ taffy

[DJRHails]

Automated post-merge review — one finding posted inline, fix follows in a separate PR since this one is already merged.

via gantry

[DJRHails]

Review Summary

Post-merge review (direct single-pass — 59 changed lines across 2 files, under the multi-agent threshold). The new ensure_gantry_cli_fresh step is solid: every failure path returns 0, the version-parse chain was verified against live data (prod /health reports 0.229.1+b173c13 → parses to 0.229.1, exactly matching uv tool list's gantry v0.229.1), and the encrypted install.md delta (reviewed decrypted via the fleet key) accurately documents the new behaviour.

Findings

#	Severity	Finding	Resolution
F1	P3	ensure_gantry_cli_fresh runs before ensure_github_ssh_rewrite, contradicting its own comment: the private-repo https clone relies on the insteadOf rewrite that step writes, so keyed hosts in the migration window fail their first update and converge a day late	Fixed in follow-up PR #133 (this PR is already merged): one-line call reorder + the ordering constraint stated in the function comment
—	P4	Exact-equality version check reinstalls daily whenever prod lags main (deploy in flight/failed) — harmless churn, and the (prod is X) log line already surfaces it	Informational, no change
—	P4	uv tool list | grep -m1 is the SIGPIPE-shaped pipeline ensure_sfw_fresh's comment warns about; here it's safe (`

Verification

• Syntax: bash -n clean
• Lint: shellcheck clean; shfmt clean on this PR's lines (drift exists only in pre-existing code)
• Live probe: prod /health version format round-trips correctly through the grep/cut/${prod%%+*} chain
• Pre-commit hooks (repo has no CI): all passed on the fix commit, including gitleaks/trufflehog and the glassine suites

Commit

a001b1c — dotfiles-autoupdate: run the ssh rewrite before the gantry CLI refresh (PR #133)

Verdict: approve

via gantry