[aside] task lens(PR #402)を SPA-first で出し gateway 側 projection を seam に回したが、これで「消費 kind の schema を Rust と TS で二重定義」が otel.span に続く 2 例目になりつつある ── otel.span が deferred した「JSON-Schema な kind registry → Rust/TS を生成」を、そろそろ実需が後押しする。

PR #402 は task を SPA(TS)だけで定義(`tasks` 表 + `KERNEL_APPLY_SQL` の task arm + `Task` 型)、gateway の `task.rs` は『agent / run_sql から task を引く必要が出たら otel.span 同型で足す』seam にした。だがその seam を埋める時、task は kind schema(構造化フィールド + projection)を Rust 側にも手書き mirror することになり、Rust↔TS で drift しうる。

`otel_span.rs` 自身が follow-up として『language-neutral registry schema(JSON Schema)を cross-language の単一情報源にして Rust + TS(+ Python)を emit』を挙げている。task が 2 例目の消費 kind になることで、その registry は「いつか」でなく 2 kind 分の重複を今まさに生むので投資対効果が上がった。

今回触らない判断: PR #402 は read scaffold が scope。gateway arm も registry も別。

想定インパクト / トリガー: gateway `task.rs` を足す(= 3 例目以降の消費 kind を足す)タイミングで、各 kind を Rust+TS 手書きするか、JSON-Schema 1 定義から両方 emit するかの分岐。後者なら otel.span / task / 将来の reaction が 1 schema で揃う。同根の cross-impl dup: [[n_01KT65C59PQVPF63DMCS09SAC3]](typed/kernel 判別の 3 重複)/ [[n_01KT6ZHGZAS23D4XF9QDHP9FEY]](run_sql wrapper の server↔gateway 二重)。