dope-canvas
設計段階AI が生成した大量の Web 成果物のための無限キャンバス。
数百の生きた iframe はスケールせず、すべてを画像に平坦化すると選択やイベントの対象指定が失われます。dope-canvas は成果物を保持したまま扱います — ソース、永続状態、インタラクションツリー、描画キャッシュ、任意のライブランタイム — そのため Figma のような選択と有効化が残ります。リポジトリは開発前のベースライン段階で、アーキテクチャ・提供計画・セキュリティモデルはありますが、動くキャンバスはまだありません。
概要
iframe はブラウジングコンテキスト、DOM/CSS の状態、スクリプトの realm、リソース、描画状態を保持し続けるため、生成ページを数百枚生かしておくのは非常に高くつきます。ここでの設計上の答えが保持型の成果物モデル — `成果物 = ソース + 永続状態 + インタラクションツリー + 描画キャッシュ + 任意のライブランタイム` — であり、スナップショットは描画キャッシュにすぎません。ドキュメントとインタラクションのモデルは残り続け、選択、イベントルーティング、有効化、リビジョン安全な復元に使えます。
キャンバス側がカメラ移動、空間の仮想化、ライブ/スナップショットのライフサイクル、インタラクションのメタデータ、リソース予算、描画合成を担い、成果物側は HTML、CSS、制御された JavaScript を提供します。パッケージ分割もその境界に沿っています — protocol、spatial、core、artifact、security、runtime、renderer、editor。すべて private でバージョンは 0.0.0、安定した公開契約として提示されているものはありません。
2 つの制約が最初に明示されています。M0 のブラウザ検証ゲートを通過していないため、実験的な HTML-in-Canvas API への対応は「約束」ではなく「能力」にとどまること。そしてライセンスが未選択であり、メンテナーが追加するまでリポジトリの内容はオープンソースライセンスの下で提供されないことです。
できること
- 保持型の成果物モデル:スナップショットは描画キャッシュにすぎないため、選択とイベント対象指定が失われません。
- キャンバスがカメラ、空間の仮想化、ライブ/スナップショットのライフサイクル、リソース予算、合成を担います。
- パッケージ境界が設計を反映:protocol、spatial、core、artifact、security、runtime、renderer、editor。
- セキュリティは後付けの強化ではなく第一級のパッケージ — サニタイザー、URL ポリシー、クォータ、ケーパビリティ。
- 事前の文書が揃っています:技術設計、提供計画、セキュリティモデル、互換性戦略、ベンチマーク手順、未解決の論点。
使い始める
動作要件: Node.js 22.12+ と pnpm 10.33.2。