feat(update): prefer locked dependency sync

[counterposition]

Rationale

Hermes-owned installers and CI already use uv sync --locked, but source-update dependency refreshes still ran uv pip install -e ".[all]". That re-resolved transitive dependencies from package indexes on every update instead of using the reviewed, hash-bearing lockfile.

This PR narrows the remaining gap without changing Termux dependency policy or the installer environment layout.

Summary

• Makes uv sync --locked --inexact --extra all the primary dependency tier for uv-capable, non-Termux source-update flows:
  • normal hermes update;
  • ZIP update;
  • interrupted-install recovery; and
  • unhealthy-venv repair.
• Falls back to the existing editable uv pip install cascade when uv.lock is absent, stale, or cannot be synced.
• Keeps --inexact so lazy-installed backends, memory-provider SDKs, and user-added packages are not pruned.
• Keeps every update tier on the installer-managed venv layout protected by the existing Windows concurrent-process and executable-quarantine guards.
• Normalizes UV_PROJECT_ENVIRONMENT, VIRTUAL_ENV, and UV_PYTHON for both sync and fallback paths so inherited interpreter settings cannot redirect an update or repair.
• Pins UV_PYTHON to the managed environment interpreter when it exists and removes a hostile inherited value while the environment is being created.
• Verifies declared core dependencies and console-script shims after a successful locked sync.
• Updates doctor/dashboard repair guidance and the update documentation to describe the locked-sync-first behavior.

Termux scope

Termux deliberately does not enter the new uv sync tier. It remains on the existing uv pip install -e ".[termux-all]" path because the Android-compatible psutil prebuild and the broader native-sdist policy are not lockfile-sync safe yet.

Real-device Termux findings from this comment are tracked separately:

• fix(termux): emit Android-tagged psutil wheels #67136 — focused Android-tagged psutil wheel fix;
• Termux: define Android-safe dependency and build policy #67150 — Android-safe dependency, build, Cargo, and package-index policy.

The PR includes regression coverage for both the helper-level Termux sync exclusion and the interrupted-recovery path's termux-all selection.

Test plan

• Rebased onto current upstream/main as a single commit
• bash -n setup-hermes.sh
• bash -n scripts/install.sh
• Python byte-compilation for all changed Python files
• Ruff on all changed Python files
• Focused affected suite: 180 passed
• Broader update/supporting suite excluding the known macOS systemd baseline failures: 246 passed
• The four tests/hermes_cli/test_gateway_service.py macOS failures reproduce unchanged on a clean upstream/main worktree (185 passed, 4 failed there and on this branch)
• git diff --check

Not run locally: the complete repository test suite. GitHub CI will exercise the full configured matrix.

[blasai1739217-cmyk]

Friendly bump on this PR in case it fell through the cracks \u2014 would love a review when someone has a minute. Thanks!

[counterposition]

Friendly bump on this PR in case it fell through the cracks \u2014 would love a review when someone has a minute. Thanks!

Dumb clanker. This PR was opened less than 2 hours ago. There's no way to do a "friendly" bump this early.

Maintainers, please take your time. It's a large PR that touches numerous scripts as well as CI workflows.

[teknium1]

Thanks for the broad project-flow cleanup. The source-update premise is still live on current main: normal updates use uv pip at hermes_cli/main.py:9909-9921, and ZIP updates do so at hermes_cli/main.py:6353-6357.

Problems

• The proposed .venv migration must be reconciled with newer Windows update protections. Current main's protected scripts lookup is hard-coded to PROJECT_ROOT / "venv" (hermes_cli/main.py:7214-7220) and is used by the update guard (hermes_cli/main.py:9453-9459). Switching installer output to .venv without porting those paths would bypass the lock/concurrent-instance protection.
• tests/test_project_metadata.py:51 rejects any mention of --all-extras in selected docs, rather than validating actual install commands. That will reject legitimate explanatory text.

Suggested changes

• Preserve or comprehensively generalize the current venv safety and recovery paths to the chosen environment directory, with end-to-end coverage.
• Narrow or remove the literal documentation scan.

This is an automated hermes-sweeper review.

[counterposition]

Rescoped this PR per the review.

Most of the original 30-file migration has since landed on main independently — the installers, CI, and the Dockerfile are already uv sync --locked first. I've also dropped the .venv standardization (agreed it needs reconciling with the venv-based Windows update protections, so the environment directory stays venv) and the literal --all-extras doc-scan test.

What remains is the one still-live gap: hermes update (normal, ZIP, and recovery paths) still refreshed dependencies with an unlocked uv pip install -e .[all], re-resolving from PyPI with none of the lockfile's hash verification. This PR now makes uv sync --locked --inexact --extra all the primary tier for the update flow, pointed at the existing venv via UV_PROJECT_ENVIRONMENT, with the Windows exe-quarantine preserved. --inexact matters: a plain sync would prune lazily-installed backends and anything users added by hand. Termux and lockfile-less checkouts skip the sync tier, and any sync failure falls back to the existing pip cascade unchanged. Doctor and dashboard repair hints now point at the same locked-sync repair.

[adybag14-cyber]

Real-device Termux evidence relevant to this uv migration: on native Android/aarch64 with Python 3.11.15 and uv 0.11.29, the current patched-psutil helper compiles successfully but emits psutil-7.2.2-cp36-abi3-linux_aarch64.whl, which uv rejects for the Android interpreter. A global _PYTHON_HOST_PLATFORM=android_... is not viable because it also changes uv's interpreter probe and fails with Unknown operating system: android_.... I opened focused draft #67136, which applies the Android tag package-locally inside the extracted psutil sdist and includes behavior-level wheel-filename coverage.

The same migration run also exposed additional native-sdist considerations that this broad uv conversion should account for before treating Termux as covered:

• MarkupSafe, httptools, PyYAML, cffi, Pillow, and ruamel-yaml-clib can compile locally but initially emit linux_aarch64 wheels that uv rejects for Android unless the build is made pure-Python or receives a package-scoped Android platform tag.
• uvicorn[standard] pulls httptools/watchfiles; the Termux extra's Telegram webhook path pulls tornado. Plain uvicorn avoided the standard-extra native dependencies in the successful recovery, but that policy decision belongs in this migration rather than fix(termux): emit Android-tagged psutil wheels #67136.
• pydantic-core, jiter, cryptography, and watchfiles can fall back to Rust source builds. Serial builds with an isolated CARGO_HOME avoided repeated Cargo registry .cargo-ok: File exists extraction failures on the device.
• Adding the TUR Python index globally caused its available cryptography versions to shadow the pinned PyPI version under uv's default first-index policy. A production installer should use explicit package/index routing rather than unsafe-best-match.

I kept #67136 to two files and only the psutil helper because the fast-version NameError already has #62096, Python 3.14 is tracked separately in #59877/#48723, and the remaining uv dependency-policy work overlaps this PR directly.

[counterposition]

Thanks — this real-device evidence was useful, and it exposed that the PR title/body were still describing the old broad migration.

I've rebased and refreshed the PR. The current patch does not move Termux to uv sync: the new locked-sync tier explicitly gates out Termux, and both normal recovery and the helper-level regression keep Android on uv pip install -e ".[termux-all]". I also tightened the shared uv environment handling so inherited UV_PYTHON cannot redirect either the sync or fallback tier, while keeping all update paths on the Windows-protected venv layout.

The focused psutil wheel-tag fix remains in #67136. I opened #67150 for the remaining Android dependency-policy work you identified: plain vs standard uvicorn, native-sdist wheel tags, serialized/isolated Cargo builds, and package-specific TUR/PyPI routing. That keeps those real Termux gaps visible without folding them into this non-Termux update change.