Review pull-from-HEAD pattern for skill upgrade flow

[edmondscommerce]

Context

Plan 00109 makes the client-pushed skill scripts/upgrade.sh a thin shim that fetches raw/main/scripts/upgrade.sh and execs it. Same hot-patch pattern as version_check SessionStart advisory.

User accepted pull-from-HEAD as established — hot-patchable without a release. Worth a structured review later.

Tradeoff space

Source	Pros	Cons
raw/main/scripts/upgrade.sh (current)	Hot-patchable. Zero release-cycle latency.	No integrity verification. Mid-release window can return inconsistent script.
releases/latest/download/upgrade.sh + bootstrap-checksums.txt	sha256-verified. Atomic with release.	Frozen at release. v3.9.x and v3.10.0 SEV-class bugs both made worse by this pattern.
Pinned tag via HOOKS_DAEMON_UPGRADE_REF (Plan 00109 ships opt-in default main)	Paranoid users can pin.	One more env var to document.

What to evaluate when revisiting

1. Have we hot-patched the upgrade flow on main since Plan 00109 shipped? If yes, hot-patch value is real.
2. Has anyone been bitten by mid-release inconsistent main? If yes, switch to verified release artifact.
3. Could git verify-tag give us signed-tag verification instead of sha256?
4. Should HOOKS_DAEMON_UPGRADE_REF get promoted from opt-in escape hatch to a documented pin recommendation?

Out of scope

• User-facing CLI (/hooks-daemon upgrade) stays the same.
• Sibling scripts (daemon-cli.sh, health-check.sh, init-handlers.sh) — separate plan thins them; revisit at the same time.

Tracking

• Plan 00109 (current): skill thin-shim + atomic upgrade commit
• Plan 00104, 00105: original self-bootstrap design