アーキテクチャ
// ARCHITECTURE
3 つの実行レイヤー、1 つのバグに 1 つだけ。
Layer 1 のブラウザ内 WebAssembly、Layer 2 のコンテナ、そのどちらでも届かないもののための Layer 3。どのレイヤーで動くかはレシピが宣言します——あなたが選ぶ必要はありません。下表で 3 層を一望してから、深掘りに進めます。
ブラウザの中で、瞬時に。
Docker / microVM で、忠実度を。
L1・L2 が届かないもののための枠。
~4 GB 上限、本物の fork/exec、データレース、コンパイラ自体のビルド。wasm32-wasip1 / sqlite-wasm。Dockerfile + ghcr.io/aletheia-works/vivarium-<slug> + Codespaces バッジ。// 01 · LAYER 1
WebAssembly、ページの中で。
ユーザーのブラウザタブの中で再現が直接実行される層です。アカウントもインストールも不要、ページを開けばすぐ動きます。Phase 0〜2 で複数の Python / Ruby / PHP / Rust レシピを揃え（例: cpython#137205やpandas#56679）、現在は最も「ブラウザだけで完結する」surface です。
向くバグ
- アルゴリズムバグ（ソート、パース、テキスト処理）。
- データ処理のリグレッション（pandas / polars / numpy のシェイプバグなど）。
- データベースの動作バグ（SQLite のクエリ異常、JSON パスのエッジケース）。
- ファイルシステム・ネットワーク・プロセスモデルに触れない、ライブラリ内部のロジックバグ。
起動時間
- 初回（キャッシュなし）: 1〜10 秒。ランタイムのダウンロード（Pyodide ≈ 10 MB 圧縮）とインスタンス化が支配的。
- 2 回目以降: ブラウザのキャッシュが効いて 1 秒未満で起動。
- 再現スクリプトの実行自体: ミリ秒〜数秒。
届かないこと
- メモリ。 ブラウザタブはピーク 1 GB 超で性能が劣化、4 GB が実質上限。本番規模のデータは Layer 2 へ。
- システムコール。 本物の
fork/exec、本物のソケットは使えない。WASI シムが一般的なケースをカバー。 - 並行性バグ。 デフォルトはシングルスレッド。データレースやハイゼンバグは Layer 3 へ。
- コンパイラ自体のビルド。 Rust のバグはブラウザ内で再現できますが、Rust コンパイラ自体のビルドは Layer 2。
対応ランタイムと実例
- Python: Pyodide — live: cpython#137205やpandas#56679
- Rust:
wasm32-wasip1— live: (該当する live サンプルなし — ギャラリーを参照) - Ruby: Ruby.wasm — live: ruby#21709
- PHP: php-wasm — live: (該当する live サンプルなし — ギャラリーを参照)
- SQLite: sqlite-wasm（Pyodide 経由）— sqlite WASM ビルドを Pyodide 経由で叩くレシピは上の Python の項にまとまっている。
// 02 · LAYER 2
Docker / microVM、訪問者のマシン上で。
本物のファイルシステム、本物のプロセス、本物のネットワークが必要なバグのための層です。Vivarium 側で再現を実行するのではなく、訪問者自身の Docker（または Codespaces）で動かすカタログ型の配信モデルを採用しています。
向くバグ
- プロジェクト全体の再現——実際のパッケージインデックスへの依存解決を要するバグ。
- システムコール依存のバグ——本物の
fork、ソケット、ファイルロック、シグナル。 - ツールチェーン固有のバグ——特定の GCC、glibc、カーネル ABI の癖。
- プロセス間の相互作用が原因のマルチプロセスバグ。
使い方
各レシピページにはピン留めされた Dockerfile と、コピペ可能な docker run … コマンド、そして ghcr.io/aletheia-works/vivarium-<slug> に公開されたビルド済みイメージへのリンクが揃っています。CI で取得した verdict スナップショットがページ上に表示され、訪問者自身の docker run がライブ再現になります。Codespaces 対応のレシピには「Open in Codespaces」バッジも提供されます。
届かないこと
- ページ内では実行されない。 訪問者がローカルか Codespaces で実行します。
- Docker（または Codespaces アカウント）が必要。 どちらもない場合は、レシピと verdict スナップショットの閲覧のみ可能。
- 並行性そのものをデバッグするバグ。 Layer 2 は本物のスレッドで動きますが、ハイゼンバグの再現性確保は Layer 3 の領分。
// 03 · LAYER 3
L1・L2 が届かないもののための枠。
数回再実行しても再現する保証がないハイゼンバグのための層です。区分としては宣言されていますが、現在レシピはひとつもありません。
向くバグ
- データレース、メモリ順序バグ、単純な再実行では再現しない use-after-free。
- 長時間 replay シナリオ：何時間ものキャプチャ実行を数分で巻き戻す。
- 特定のメッセージインターリーブに依存する分散システムバグ。
- 事後フォレンジック分析——録音済みトレースを後ろに戻る形のデバッグ。
なぜ空なのか
最初の試みは rr の record-replay でしたが、撤去しました。rr は Linux/x86_64 専用で、PMU の露出と CPUID faulting を要求します。Windows や macOS の読み手はレシピを検証すらできず、実行できる環境がここまで限られると、正しい再現と壊れた再現を安く見分ける手段もありません。
空である理由
- 参入基準。 レシピは読み手自身が再現できなければならない。誰も独立に確認できない verdict は証拠ではない。
- カーネル依存の技術。 CRIU や Firecracker スナップショットも同じ Linux 依存を引き継ぐため、同じ基準を通す必要がある。
候補
- 決定論的シミュレーション（Antithesis 系）と WASI Preview 3+ が有望。ホストのカーネル機能に依存しないため。
- どれかが着地するまで、ギャラリーに L3 のエントリは出ません。
どのレイヤーで動くかは、レシピ側があらかじめ宣言しています。あなたが選ぶ必要はなく、レシピを開けば自動的にそのレイヤーで動作します。