fix(update): a successful update no longer credits or ignores surviving unmanaged serve runtimes (#100479, salvage #100490 + #100493)

[teknium1]

Summary

A successful hermes update no longer reports a clean success while an unmanaged hermes serve / hermes dashboard runtime (sshd-spawned serve --isolated, manual CLI serve — no systemd unit) keeps running pre-update code: the survivor is warned about, reconciled as unaccounted, and the update exits 1 with a partial receipt (#100479; salvage of #100490 + #100493).

Changes

• hermes_cli/update_inventory.py — match_runtime_outcomes (cherry-pick @chelsealong fix(update): stop crediting unmanaged serve runtimes with a gateway's restart #100490, widened): serve/dashboard runtimes never borrow the gateway's bookkeeping. The original PR restricted the bare hermes-gateway unit fallback to kind == "gateway"; the widening applies the same rule to the two sibling sites it missed — relaunched_profiles / externally_supervised_profiles (a manually relaunched default gateway credited the serve too) and the profile-substring unit match (hermes-gateway-work.service credited the work serve). Serve/dashboard rows now reconcile against their own hermes-serve* / hermes-dashboard* unit vocabulary (exact names, user/ scope prefix tolerated) or, when the caller supplies the (pid, create_time) survivor probe (stale_serve_pids=), by incarnation liveness: gone ⇒ restarted, still alive ⇒ unaccounted, probe failed ⇒ fail closed.
• hermes_cli/update_cmd.py — success path (cherry-pick @twotnguyen fix(update): warn surviving pre-update serve and dashboard runtimes on success (#100479) #100493, widened): _surviving_pre_update_serve_runtimes() + _warn_stale_serve_runtimes() now run on the clean success path (previously only reachable from the abort-recovery except handler, so dead on every successful update). The widening feeds those rows into the Phase-2 reconciliation so a survivor escalates (exit 1 + partial receipt + runtime_outcomes row) instead of being printed and forgotten under a ✓.
• report_unaccounted_runtimes: an unaccounted serve/dashboard names the serve remedy (systemctl --user restart hermes-serve.service / relaunch hermes serve) instead of hermes gateway restart, which cannot reach it.
• contributors/emails/nguyenngoctinh011258@gmail.com → twotnguyen (attribution audit).

Slots into #91277 Phase 2 (plan-vs-execution reconciliation) — observability/tripwire fix, no restart-behavior change; it does not stop or relaunch unmanaged serves (no relaunch authority), that remains #99450 / Phase 2 proper.

Validation

Check	Result
tests/hermes_cli/test_restart_plan_reconciliation.py	17 passed (6 new)
tests/hermes_cli/test_update_fleet_restart_pending.py	15 passed (2 new: warn-on-success from #100493, end-to-end escalate: warn + unaccounted + exit 1 + receipt)
Sabotage — update_inventory.py reverted to main	6 new reconciliation tests fail ('restarted' == 'unaccounted')
Sabotage — update_cmd.py reverted to main	both update-path tests fail ('pid 5555' in out, exit code)
Neighbors: test_windows_update_restart_reconciliation 4, test_update_autostash 30, test_serve_runtime_inventory 12, test_update_inventory 11, test_update_serve_generation_recovery 59, test_fleet_matrix_down_state 7, test_update_restart_recovery 17	all passed
test_update_head_moved_gate.py::test_update_success_when_head_moves	1 failed — pre-existing on origin/main (fails identically with main's update_cmd.py/update_inventory.py checked out), unrelated
ruff check on touched files	clean
scripts/audit_pr_attribution.py	all emails mapped

Live repro: real imports from this worktree, isolated temp HERMES_HOME, real spawn-ledger file, a REAL child process registered as an unmanaged serve (no unit, no live spawner), plus a systemd gateway whose hermes-gateway.service the restart phase restarted; driven through the real hermes_cli.main.cmd_update success path with the repo's git mocks — before (origin/main): match_runtime_outcomes → serve outcome: 'restarted' on both the unit-name path and the relaunched_profiles path, report_unaccounted_runtimes → False, no "still run pre-update code" line printed, receipt runtime_outcomes credits the serve as restarted; after: serve outcome: 'unaccounted' on both paths, ⚠ These serve/dashboard processes still run pre-update code … pid <child> printed, ⚠ Planned runtimes the restart phase never touched: ✗ serve [default] pid <child> with the serve remedy, cmd_update exit 1, receipt outcome: partial.

Closes #100479
Closes #100490
Closes #100493

Credit: @chelsealong (#100490, first — reconciliation guard + test, cherry-picked with authorship preserved) and @twotnguyen (#100493 — success-path survivor warning + update-path test, cherry-picked with authorship preserved). Thanks to @teamster22 for the field report and the AST-verified root cause in #100479.

Infographic

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 42c089f — chore: map contributor email for salvaged #100493}

⚠️ Warnings

OSV vulnerability scan · View job

13 known vulnerabilities found in pinned dependencies.

• CVE-2026-67213 in website/package-lock.json
• CVE-2026-71554 in uv.lock
• CVE-2026-73088 in package-lock.json
• CVE-2026-73088 in website/package-lock.json
• GHSA-8423-8fgw-73vq in uv.lock
• CVE-2026-70608 in package-lock.json
• CVE-2026-73089 in package-lock.json
• CVE-2026-73089 in website/package-lock.json
• CVE-2026-84371 in package-lock.json
• CVE-2026-56876 in package-lock.json
• CVE-2026-70606 in package-lock.json
• GHSA-wwv5-g3v4-889x in uv.lock
• CVE-2026-71554 in uv.lock

How to fix:

Review the findings in the Security tab. Update the affected dependencies if a patched version is available.

---

debug info

CI timings

CI timings · View report · View job

Wall time 5m56s vs 5m18s (+11.9%). 3 job(s) slower, 11 faster,

• OS-specific tests / Windows-only tests: -53.0s
• Check no committed infographics / check-no-committed-infographics: -47.0s
• Python lints / ruff enforcement (blocking): -41.0s
• OSV scan / Scan lockfiles / osv-scan: -28.0s
• OSV scan / Emit review status: +24.0s