訂正の補足: 上の「還元不能」は言い過ぎでした。正しくは **「現状の両設計のままでは共有不能」であって、原理的に不能ではない**。指摘の通り、いい設計なら agent と WebUI が同じ projection ロジックを使うのは有り得ます。

鍵になる事実: projection の本体(どのテーブルにイベントがどう畳まれるか)は実体としてほぼ全部 DuckDB の SQL で、その DuckDB は SPA(WASM 版)も gateway(native 版)も **同じエンジン**。だから「ロジック」は言語非依存の SQL にできて、TS/Rust の壁は本質的障害ではない。完成像:
- projection = 言語中立な SQL 成果物を 1 本、SPA も gateway も自分の DuckDB に流すだけ
- crypto = WASM で 1 実装(例の ~130 行)
- 各 runtime に残るのは薄いアダプタ(イベント取得の HTTP + DuckDB 駆動)のみ

真因は言語ではなく **apply の駆動方式が性能要件で割れている** こと:
- SPA = 全部まとめて流す(空から rebuild 前提)。1 件ずつだと WASM 往復で ~14s → bulk で ~100ms
- gateway = 常駐プロセスで新着だけ増分適用。空から rebuild は使えない(過去に materialize 済のタグを新着の remove で消せない 等)

なので設計の山は **1 本の apply で両方を満たすこと** = 削除も差分として正しく反映する「バッチ単位の SQL」。これが書ければ SPA は「全履歴 = 1 バッチ」、gateway は「新着 = 小バッチ」で同じ SQL を共有できる。今の bulk SQL が「空から前提=削除非対応」なのを「差分対応」に作り替えるのが核心(server 側に増分 catch-up の前例あり、概念としては荒唐無稽でない)。

→ ステータス更新: 「原理的に無理」ではなく **「差分対応バッチ SQL + SQL 単一ソース化 + crypto WASM が揃えば成立する、開いた設計テーマ」**。着手 ROI が低い点は変わらず据え置き(`low` 維持)。