fix(desktop): make Windows updates complete end to end

[royalaid]

Motivation

On Windows, a Desktop update must replace files inside the managed Hermes virtual environment. A live Python process can keep those files mapped (.pyd native extensions, the Python launcher, or Hermes executables), so updating underneath it can leave the install half-replaced. Refusing that mutation is correct; making the user manually hunt down Hermes-owned descendants is not.

The current Desktop flow already stops the backend it directly owns and verifies that venv\\Scripts\\hermes.exe is unlocked. That does not prove the target installation has no remaining Python descendants. Field logs repeatedly show the shim unlocked while the existing venv-blocker scanner still reports 1–32 holders, including managed serve, gateway, MCP, ACP, and Python worker processes.

The same incident exposed a second failure mode: after the checkout updated successfully, a content-hash shortcut could skip rebuilding the packaged Desktop and relaunch stale code. The update UI then appeared to succeed even though the packaged commit lagged HEAD.

Fix

Keep the existing Windows update architecture, but make its ownership and success gates explicit:

1. Release Desktop's tracked backend trees.
2. Scan the target installation with the existing venv-blocker scanner.
3. For scanner-proven holders only, run Windows taskkill /T /F on each distinct PID, settle, and re-scan for at most three passes.
4. Prefer the staged Tauri Hermes-Setup.exe --update --branch <branch> handoff when it exists, restoring the branded blue updater window with per-step progress and live output.
5. Use scripts/desktop-update/windows.ps1 only when no staged installer exists, preserving CLI/source installs.
6. Force the updater's Desktop rebuild, then compare checkout HEAD with the packaged resources/install-stamp.json commit before relaunch. A mismatch is a failed update, not success.
7. In the CLI packaging path, require the packaged install-stamp commit to equal checkout HEAD even when the renderer content hash is unchanged.

This is deliberately not a system-wide Python kill. Eligibility remains owned by the existing scanner: only processes it associates with the target Hermes installation are terminated, and the final scan is still the fail-closed gate.

Why the staged installer wins

The staged Tauri installer is the visible update surface users expect. The earlier Desktop selector resolved both candidates but always chose the repository PowerShell script, so the script silently shadowed Hermes-Setup.exe whenever both existed. Selection now has one tested precedence point: staged installer first, repository script fallback.

Pre-#74782 staged installers keep the existing marker pre-write compatibility path, so restoring installer precedence does not reintroduce the self-marker deadlock.

Related bugs and prior approaches

Report / PR	Relationship to this PR
#61514	Persistent orphaned venv-resident children; this PR adds the missing scanner-verified force-drain action.
#74805	First-attempt process-table settling; bounded settle/re-scan covers the transient case.
#78037	Broader Windows pipeline proposal; this PR keeps the existing architecture and fixes the observed blocker, handoff, and stale-package invariants.
#75498 / #75556 / #75631	Tauri/marker handoff failures; compatibility behavior is preserved without VBScript or a private transport.

Windows identity repair

The update path also keeps the user-visible identity repair needed after a successful rebuild:

• stamp Hermes.exe with Hermes file metadata and fail a Windows package if stamping fails;
• set the packaged AUMID and taskbar relaunch details;
• write System.Title = Hermes and System.AppUserModel.ID = com.nousresearch.hermes on Start Menu and Desktop shortcuts;
• repair those shortcuts after an updater rebuild and on first launch of the upgraded app.

Verification

• 87 focused Electron updater tests across seven files;
• Electron main-process typecheck and focused lint/format checks;
• 60 Rust bootstrap-installer tests;
• focused Python package-commit invariant tests;
• updater selector coverage for staged-first, script-only, and no-handoff cases;
• stale checkout/package SHA coverage after a forced rebuild;
• PR CI green on the current head.

Canary

The native Windows release candidate is built from fork-integration plus the staged-installer precedence change. The remaining live canary will record the visible click-through and verify, in one run:

1. the scanner finds and force-drains target-install process trees;
2. the blue Tauri updater appears instead of the script-only handoff;
3. the updater completes and relaunches Hermes;
4. the relaunched package install-stamp commit equals checkout HEAD.

No WSL path or bridge-quiesce bypass is part of the canary.

[royalaid]

Actually me here, just want to say I am still working on this specific PR as the fixes that were generated first used VBscript and other nonsense so I am still auditing the full update path and working to shave down the PR as it has a lot of changes that don't really need to be here

[dontcallmejames]

Windows reproduction / design constraint from a real affected installation:

• The original false positive was a long managed-runtime gateway argv truncated before -m hermes_cli.main gateway run classification; 0b33ee88e / fix(update): classify venv holders on the full cmdline, truncate only for display #78188 address that independently.
• After that fix, the remaining update coordination problem is the Desktop-owned python -m hermes_cli.main serve backend racing the handoff, plus normal ACP-client descendants (for example Buzz-launched hermes-acp.exe) holding managed-runtime files.
• The safe policy should be: identify and coordinate only the Desktop-owned backend; re-scan; then refuse unknown/ACP/external holders with an actionable result. Avoid runtime-wide or scanner-wide taskkill /T /F, because unrelated workloads can legitimately use the managed runtime.

I verified a successful Windows in-app path as: update action → Desktop clean exit → updater exit code 0 → Desktop relaunch. The durable design should retain that atomic handoff while preserving the no-broad-kill boundary.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(desktop): make Windows updates complete end to end

• apps/bootstrap-installer/src-tauri/src/bootstrap.rs (resolve_windows_desktop_exe_for_machines): when no candidate matches a runnable PE machine, the code falls back to all existing candidates (let eligible = if matching.is_empty() { existing } else { matching }) and picks the newest. On an x64 host whose build produced only win-arm64-unpacked/Hermes.exe, the updater would relaunch an executable the host cannot run — and verify_packaged_desktop_commit (update.rs) would happily verify that wrong-arch package because the stamp matches. Consider returning None when existing is non-empty but matching is empty, so the rebuild-verification path surfaces the problem instead of launching an un-runnable binary.
• hermes_cli/main.py (_detect_venv_python_processes): force_drain_eligible is exe_norm.startswith(venv_prefix) — i.e. any process executing from this venv's interpreter is a tree-kill target during update, including a user's manually started hermes serve, a gateway, or a long-running CLI session, not just the Desktop-owned backend. The PR's own design note says to "identify and coordinate only the Desktop-owned backend; re-scan; then refuse unknown/ACP/external holders." The current eligibility is broader than that stated policy — suggest narrowing it to desktop-spawned backends, or documenting the wider blast radius in the scanner output.
• apps/desktop/scripts/after-pack.mjs: the hook now propagates identity-stamp failures so a build hard-fails when rcedit/stamping is unavailable or transiently broken. Intentional per the identity invariant, but note the Windows update build now depends on the rcedit tool being present and healthy at pack time; a transient failure aborts the entire update rather than just shipping a stock icon. Consider a retry or a clearer preflight error (e.g., "rcedit unavailable") so the failure mode is diagnosable.
• Minor: commit verification now exists in two places reading two different stamp files — the Rust gate reads resources/install-stamp.json beside the packaged exe (update.rs) while the Python build decision reads desktop-build-stamp.json under HERMES_HOME (hermes_cli/main.py _desktop_build_needed). Both drive the same invariant; worth a comment cross-referencing them so they don't drift.

[royalaid]

Superseded by #92879 — rebased onto current main after ~1,700 commits of drift, and reduced to the core fix: a consent-gated, authenticated drain of the Hermes processes that block a Windows update, so a blocked update finally has a way forward instead of a dead-end dialog. The new revision extends the safeToStop blocker taxonomy that main shipped in the meantime, and answers the review feedback here in its body.