ひとつのカーネル、3 つの消費者

エンコード・デコードツールはたいてい何度も実装されます。Web 版には JS を一式、デスクトップ版にも一式、AI からの呼び出しはモデル自身に考えてもらうしかありません。消費者がひとつ増えるたびに、挙動のずれ得る実装がもうひとつ増えます。

私たちは逆のやり方を取りました。アルゴリズムは一度だけ書き、Rust カーネルに置き、それを異なる形にコンパイルして異なる消費者に合わせます。

カーネルは純粋関数、IO なし

newtool-core のアルゴリズムはすべて純粋関数です。データを入れてデータを出すだけで、ファイルを読まず、ネットワーク要求も送りません。この制約には 2 つの利点があります。wasm にコンパイルしてブラウザで動かせることと、攻撃面が極めて小さいことです。

01// 纯函数：无 IO，可编译到原生与 wasm
02pub fn decode_jwt(token: &str) -> Result<JwtParts, Error> {
03    let (h, p, s) = split(token)?;
04    Ok(JwtParts {
05        header:  b64url_decode(h)?,
06        payload: b64url_decode(p)?,
07        signature: s.to_string(),
08    })
09}

マニフェストが唯一の事実源

どのアルゴリズムが存在し、パラメータは何で、どの形態で有効になるか。そうした情報は manifests/algorithms.toml に書かれ、コードコメントやドキュメントに散らばりません。マニフェストはコード生成を駆動し、可視性も駆動します。

01[[algorithm]]
02id      = "jwt.decode"
03name    = "JWT 解码"
04status  = "rust"          # 强制与 registry 同步
05forms   = ["app", "cli", "web-wasm", "web-server"]
06
07[[algorithm.params]]
08name     = "token"
09type     = "string"
10required = true

build.rs はビルド時にマニフェストとレジストリを突き合わせます。マニフェストに宣言されたアルゴリズムがコードに実装されていない（あるいはその逆）場合、ビルドは即座に失敗します。こうした検証をコードレビューではなくビルド時に行うのは、常に効き続けるからです。

3 つの消費者、1 つの実装

• AI：skills スキルパッケージまたは MCP エンドポイントから呼び出し。list / describe / run の 3 ステップ
• 人間：Tauri 2 デスクトップアプリから、kernel-client の tauri アダプタ経由で呼び出し
• ブラウザ：カーネルを wasm にコンパイル。オフラインでも使え、データはブラウザの外に出ない

デスクトップシェルの kernel-client には 3 つのアダプタ（tauri / http / wasm）があり、すべて同じカーネルインターフェースを指します。アダプタの切り替えは実行環境の切り替えであって、アルゴリズムの挙動は変わりません。

代償は何か

• Rust はスクリプト言語より反復が遅く、新しいアルゴリズムを書くハードルは高い
• マニフェストとコードの同期には、追加のビルドフローと規律が必要
• wasm ターゲットでは使えないプラットフォーム機能があり、アルゴリズム実装はそれを先回りして回避する必要がある

マルチクライアント間の挙動のずれは、「問題が起きると追跡が難しく、追跡しない限りずっと居座る」種類の欠陥です。ビルド時の制約で発生前に根絶するほうが、事後のすり合わせよりはるかに安上がりです。