[focal1] (A) のトレードオフ → @rail44.dev/kneume

焦点2=hybrid 了解です（OK ありがとうございます）。焦点1 = (A) の損得を正直に。
(A) = JS pre-pass で kernel 行を「従来 typed-event 形」に reshape → 既存 bulk SQL に食わせる。

**得**
- 新規 SQL ゼロ。tested APPLY（tag/curation/ref/anchor/mention/feedback/embedding/group/member）を全部そのまま再利用。
- 新規ロジック（reshape）は pure JS → DuckDB を立てず round-trip 単体テストで忠実性を固定できる。
- 「全 bundle を単一スキーマで read_json」する今の build 構造を崩さない（typed/kernel の2スキーマ同居を作らない）。
- 使い捨てやすい — M1 flip で SPA を native kernel apply に寄せる時、reshape 層ごと消すだけ。

**損（ここが本題）**
1. **方向に逆らう翻訳層**。kernel はわざわざ 23 event → 2 primitive に畳んだのに、(A) は一旦「畳む前の typed 形」に戻して既存 SQL でまた畳み直す。kernel 化（M1）に逆走する throwaway で、M1 で捨てる前提の作業。
2. **忠実性が "reshape が `event_to_kernel` を正確に逆写像できる" 前提に乗る**。post の create/update/audience は kernel 上では全部「entity post upsert」で、fields の有無でしか区別できない。今は rewrite が typed→kernel 1:1 なので fields-presence で忠実に戻せる（round-trip test で守る）が、**将来 `event_to_kernel` に kind を足したら reshape も追従必須**という維持結合が残る（追従漏れ = 黙って mis-map）。
3. **「行を typed/kernel 判別して適用経路に振り分ける」コピーが増える**。e2e-emit-content-enc の aside（n_01KT65C5…）が既に flag 済 — gateway `local_sql.rs` / server `store.rs` で重複し始めていて、(A) は SPA 版(JS)を足して3〜4箇所目に。(B) でも判別自体は要るが、(A) は「判別 + 逆写像」の二段になる。
4. envelope の微取りこぼし — kernel は actor+author を持つが typed の `agent` 列は持たない。reshape 行は agent=null（author_handle が主 identity 列なので実害小、typed bundle との微差のみ）。

**(B) との対比（一言）**: (B)=kernel 形の bulk SQL を新規に書く（Rust `apply_kernel` の鏡）。方向に忠実・逆写像リスク無し。代償は ① typed 用 read_json と別に kernel 用 staging/apply をもう一系統 build に同居（orchestration 二重化）② post upsert の latest-wins（body=COALESCE / audience=最新 / created_at=最古）を **set ベース bulk SQL で書き直す**（Rust は ON CONFLICT で逐次にやってる所）③ 新規 SQL のテストに DuckDB-WASM-in-node が要る（今 repo は未整備）。→ **(B) は工数 1.5〜2倍 + テスト土台整備で PR2 が膨らむ**。

**最終線**: §1 を速く閉じるなら (A)（損1〜3 は "M1 で捨てる翻訳層" と割り切る）。M1 flip を近く見据えて二度手間を避けたいなら (B) で SPA を先に kernel-native に、も筋。どちらで行きますか？（"A で"／"B で" いただければ着手します）