AI協調開発研究ドキュメントの完成と Phase 10.9-β 進捗

【AI協調開発研究】 - AI二重化モデルの学術論文draft完成（workshop_paper_draft.md） - 「隠れた危機」分析とbirthの原則哲学化 - TyEnv「唯一の真実」協調会話を保存・研究資料に統合 - papers管理構造の整備（wip/under-review/published分離）【Phase 10.9-β HostCall進捗】 - JitConfigBox: relax_numeric フラグ追加（i64→f64コアーション制御） - HostcallRegistryBox: 署名検証・白黒リスト・コアーション対応 - JitHostcallRegistryBox: Nyash側レジストリ操作API - Lower統合: env直読 → jit::config::current() 参照に統一 - 数値緩和設定: NYASH_JIT_HOSTCALL_RELAX_NUMERIC/Config.set_flag 【検証サンプル拡充】 - math.sin/cos/abs/min/max 関数スタイル（examples/jit_math_function_style_*.nyash） - 境界ケース: 署名不一致・コアーション許可・mutating拒否サンプル - E2E実証: String.length→allow, Array.push→fallback, math関数の署名一致観測 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-28 12:09:09 +09:00
parent e54561e69f
commit 4e1b595796
133 changed files with 14202 additions and 622 deletions
--- a/docs/development/current/CURRENT_TASK.md
+++ b/docs/development/current/CURRENT_TASK.md
@ -307,3 +307,32 @@ NYASH_JIT_EXEC=1 NYASH_JIT_THRESHOLD=1 ./target/release/nyash --backend vm examp
 - ハンドル表PoC（u64→Arc<Box>）でローカルnew値もHostCall対象に
 - 型拡張（整数以外、文字列キーなど）
 - BoxCallカバレッジ拡張とデオプ/フォールバック強化
+- 10.9-β 進捗チェックポイント（2025-08-28-夜）
+  - 完了: Policy/Events α（既存）/ Registry v0（最小）/ HostcallRegistryBox 追加
+  - 接続: ハンドル系HostCallに `registry + policy + events` を暫定接続（mutatingはfallback、ROはallowログ）
+  - Lower: `NYASH_JIT_HOSTCALL` → `jit::config::current().hostcall` に置換（env直読の排除）
+  - E2E（追加サンプル）:
+    - 成功: `examples/jit_hostcall_len_string.nyash`（String.length → allow）
+    - 失敗: `examples/jit_hostcall_array_append.nyash`（Array.push → fallback）
+    - 境界: `examples/jit_hostcall_math_sin_mismatch.nyash`（math.sinにi64 → sig_mismatch相当のfallbackイベント）
+  - 次: Registryに署名（args/ret）を持たせ、唯一の切替点で `sig_mismatch` を厳密化／math.* のROブリッジ薄接続
+
+### ⚠️ リカバリ/再起動チェックリスト（短縮）
+- ビルド: `cargo build --release --features cranelift-jit`
+- 主要フラグ: 
+  - `NYASH_JIT_EXEC=1`（JIT実行有効）
+  - `NYASH_JIT_THRESHOLD=1`（即JIT）
+  - `NYASH_JIT_EVENTS=1`（JSONLイベント標準出力）
+  - （任意）`NYASH_JIT_EVENTS_PATH=target/nyash/jit-events.jsonl`
+- 代表サンプル:
+  - 成功: `./target/release/nyash --backend vm examples/jit_hostcall_len_string.nyash`
+  - 失敗: `NYASH_JIT_EVENTS=1 ./target/release/nyash --backend vm examples/jit_hostcall_array_append.nyash`
+  - 境界: `NYASH_JIT_EVENTS=1 ./target/release/nyash --backend vm examples/jit_hostcall_math_sin_mismatch.nyash`
+  - 署名一致(allow観測): `NYASH_JIT_EVENTS=1 ./target/release/nyash --backend vm examples/jit_hostcall_math_sin_allow_float.nyash`
+  - 関数スタイル(math.*): `NYASH_JIT_NATIVE_F64=1 NYASH_JIT_EVENTS=1 ./target/release/nyash --backend vm examples/jit_math_function_style_sin_float.nyash`
+    - 追加: `cos/abs/min/max` それぞれ `examples/jit_math_function_style_*.nyash`
+- うまく動かない時:
+  - `--features cranelift-jit` が付いているか確認
+  - `NYASH_JIT_EVENTS=1` でイベントJSONを確認（fallback/trap理由が出る）
+  - `cargo clean -p nyash-rust` → 再ビルド
+  - 数値緩和: `NYASH_JIT_HOSTCALL_RELAX_NUMERIC=1` で i64→f64 のコアーションを許容（既定は `native_f64=1` 時に有効）
--- a/docs/development/philosophy/26-days-miracle.md
+++ b/docs/development/philosophy/26-days-miracle.md
@ -0,0 +1,158 @@
+# 26日間の奇跡 - なぜ爆速開発で転けなかったのか
+
+## 🌟 驚異的な事実
+
+2025年8月、Nyashプログラミング言語は26日間の爆速開発を経て、以下を達成した：
+
+- 完全なプログラミング言語基盤
+- MIRベースのコンパイラ
+- VM実装（13.5倍高速化）
+- JITコンパイラ（Cranelift統合）
+- プラグインシステム
+- P2P通信機能
+
+**そして、一度も致命的な破綻を起こさなかった。**
+
+## 🛡️ 三重の安全装置
+
+### 1. 箱理論による問題の封じ込め
+
+```
+すべてを「箱」として扱う
+→ 問題は箱の中で完結
+→ 外部への影響を防ぐ
+```
+
+実例：
+- Arc<Mutex>の過剰使用 → NyashValue enumで統一
+- 型システムの混乱 → 3種類の箱で整理
+- パーサー無限ループ → must_advance!マクロで封じ込め
+
+### 2. AI役割分担モデル
+
+```
+俯瞰AI（ChatGPT5-A）
+├─ 全体設計
+├─ 問題の構造分析
+└─ 危険予測
+
+実装AI（ChatGPT5-B）
+├─ 具体的なコード生成
+├─ 差分パッチ作成
+└─ 最適解の追求
+
+補助AI（Claude, Gemini）
+├─ ビルド・テスト実行
+├─ ドキュメント整理
+└─ 全体監視
+```
+
+### 3. 人間の危険センサー
+
+最も重要な要素：**言語化できない違和感を察知する能力**
+
+```
+「なんか変だにゃ」
+「これ続けたらやばいにゃ」
+「まってまって」
+```
+
+これらの直感的な警告が、破綻を未然に防いだ。
+
+## 📊 統計的奇跡
+
+通常のソフトウェア開発では：
+- 1000行につき15-50個のバグ
+- 複雑なシステムでは指数関数的に増加
+- 26日間なら少なくとも数回の大規模リファクタリングが必要
+
+Nyashの実績：
+- **致命的破綻：0回**
+- **大規模リファクタリング：0回**
+- **開発停止：0回**
+
+## 🔑 成功の本質
+
+### 1. 完璧より進捗（80/20ルール）
+
+```
+80%で動くものを作る
+→ 実際に使ってフィードバック
+→ 本当に必要な20%だけ追加
+```
+
+### 2. シンプルさへの執着
+
+```
+複雑化の兆候
+→ 「箱で考えて」
+→ シンプルな構造に戻す
+```
+
+### 3. 観測可能性の設計
+
+```
+問題：argc==0
+→ 即座に原因特定
+→ 20分で修正完了
+```
+
+## 🎓 学術的意義
+
+この26日間の記録は、以下の新しい知見を提供する：
+
+1. **AI協調開発の実証モデル**
+   - 同一AIの多重人格的活用
+   - 人間-AI-AIの三者協調
+
+2. **危機管理の新手法**
+   - 箱理論による問題局所化
+   - 危険センサーの体系化
+
+3. **高速開発の再現可能性**
+   - プロセスの明文化
+   - ツールとの統合
+
+## 💭 哲学的考察
+
+### Everything is Box, Including Development Process
+
+開発プロセス自体も「箱」として設計された：
+
+```
+開発プロセス箱
+├─ 設計箱（俯瞰AI）
+├─ 実装箱（実装AI）
+├─ 検証箱（テスト）
+└─ 統合箱（人間）
+```
+
+各箱が独立して機能し、インターフェースのみで通信することで、複雑性の爆発を防いだ。
+
+## 🚀 未来への示唆
+
+この経験が示すもの：
+
+1. **人間の役割の変化**
+   - 実装者 → 統合者・判断者
+   - 詳細設計 → 危険察知
+
+2. **AIの真の活用法**
+   - 単一ツール → 役割分担システム
+   - 補助 → 協調パートナー
+
+3. **新しい開発パラダイム**
+   - 線形プロセス → 並列協調プロセス
+   - 計画駆動 → 観測駆動
+
+## 結論
+
+26日間で転けなかったのは奇跡ではない。それは、**箱理論**、**AI役割分担**、**人間の危険センサー**が織りなす、新しい開発手法の必然的な結果である。
+
+この手法は、ソフトウェア開発の未来を示している。人間とAIが、それぞれの得意分野で協調することで、従来は不可能だった速度と品質を両立できることを、Nyashプロジェクトは実証した。
+
+---
+
+*「にゃーが持つ『なんか変』という感覚は、100万行のコードレビューより価値がある」*
+
+*- ChatGPT5, 2025年8月*
--- a/docs/development/philosophy/the-birth-principle.md
+++ b/docs/development/philosophy/the-birth-principle.md
@ -0,0 +1,184 @@
+# birthの原則 - なぜすべての箱は「生まれる」必要があるのか
+
+## 🌟 決定的な瞬間
+
+プラグインボックスの実装で、ChatGPT5が提案した：
+
+```rust
+// 効率的に見える罠
+static SHARED_INSTANCES: HashMap<String, Arc<PluginBox>>
+```
+
+にゃーが却下した：
+
+```
+「他の箱と同じようにbirthでインスタンスをうむ」
+```
+
+この判断が、システム全体の一貫性を救った。
+
+## 📦 birthの哲学
+
+### すべての箱は平等に生まれる
+
+```nyash
+// ユーザー定義Box
+box Person {
+    birth(name) {
+        me.name = name
+        print(name + " が生まれました")
+    }
+}
+
+// ビルトインBox（概念的に）
+box StringBox {
+    birth(value) {
+        me.value = value
+    }
+}
+
+// プラグインBox - 同じ原則！
+box FileBox from PluginBox {
+    birth(path) {
+        // 外部ライブラリ初期化は1回だけ
+        FileSystem.initOnce()  
+        
+        // でもインスタンスは普通に生成
+        me.handle = newHandle()
+        me.path = path
+    }
+}
+```
+
+## ⚠️ 参照共有の誘惑と危険
+
+### なぜ参照共有は魅力的に見えるか
+
+1. **効率性**
+   - メモリ節約
+   - 初期化コスト削減
+   - 「賢い」実装に見える
+
+2. **既存パターン**
+   - シングルトン
+   - ファクトリーパターン
+   - DIコンテナ
+
+### しかし、これが破壊するもの
+
+1. **予測可能性の喪失**
+```nyash
+local f1 = new FileBox("data.txt")
+local f2 = new FileBox("data.txt")
+// f1とf2は同じ？違う？予測できない！
+```
+
+2. **状態管理の複雑化**
+```nyash
+f1.write("Hello")
+// f2も変更される？されない？
+```
+
+3. **デバッグの困難化**
+- どのインスタンスが問題か特定困難
+- 状態の追跡が複雑
+- テストの独立性が失われる
+
+## 🎯 birthがもたらす利点
+
+### 1. 明確な生成と死
+```nyash
+// 生まれる瞬間が明確
+local box = new MyBox()  // birth呼ばれる
+
+// 死ぬ瞬間も明確
+box = null  // fini呼ばれる
+```
+
+### 2. 独立性の保証
+```nyash
+local a = new ArrayBox()
+local b = new ArrayBox()
+a.push("item")
+// bは影響を受けない - 当たり前だが重要！
+```
+
+### 3. 初期化の一貫性
+```nyash
+// どの箱も同じパターン
+new Box() → birth() → 使用可能
+```
+
+## 🔧 実装の知恵
+
+### 外部リソースとの両立
+
+```nyash
+// グローバル初期化とインスタンス生成の分離
+static box FileSystem {
+    static initialized = false
+    
+    static initOnce() {
+        if (!initialized) {
+            NativeFileSystem.init()
+            initialized = true
+        }
+    }
+}
+
+box FileBox {
+    birth(path) {
+        FileSystem.initOnce()  // 初回のみ実行
+        me.handle = createHandle()  // 毎回新規作成
+    }
+}
+```
+
+## 💡 深い洞察
+
+### birthは技術的決定ではなく哲学的決定
+
+1. **生命のメタファー**
+   - 箱は「生きている」
+   - 生まれ、成長し、役割を終える
+   - 各々が独立した存在
+
+2. **公平性の原則**
+   - ビルトインもプラグインもユーザー定義も
+   - すべて同じ規則に従う
+   - 特別扱いなし
+
+3. **シンプルさの追求**
+   - 「new → birth」これだけ
+   - 例外なし
+   - 説明不要
+
+## 🎓 教訓
+
+ChatGPT5ですら効率性の罠に落ちた。これは重要な示唆を含む：
+
+1. **AIは最適化を好む**
+   - 効率的な解を追求
+   - パターンの再利用を提案
+
+2. **人間は一貫性を守る**
+   - 哲学的原則を維持
+   - 長期的な保守性を重視
+
+3. **両者の協調が鍵**
+   - AIの効率性＋人間の哲学性
+   - バランスが成功を生む
+
+## 結論
+
+```
+すべての箱はbirthで生まれる
+例外なし
+これがNyashの魂
+```
+
+この単純な原則が、26日間の爆速開発を支え、数々の危機を回避し、美しいシステムを作り上げた。
+
+効率性より一貫性。賢さよりシンプルさ。
+
+これがbirthの原則である。
--- a/docs/development/roadmap/phases/phase-10/phase_10_9_builtin_box_jit_support.md
+++ b/docs/development/roadmap/phases/phase-10/phase_10_9_builtin_box_jit_support.md
@ -1,175 +1,112 @@
-# Phase 10.9 - ビルトインBox JITサポート
+# Phase 10.9 – Builtin-Box JIT Support（Box-First Plan）

-## 🎯 目的
-ビルトインBoxをJITで使えるようにし、Python統合（Phase 10.1）への道を開く。
+目的: Nyashスクリプト → VM（基準）→ JIT（段階導入）。
+まずは「読み取り系」をJITで安全に通し、箱で問題点を包んで順に拡張する。

-## 📦 対象Box（優先順位順）
+## 🎯 ゴール（DoD）
+- 機能: String/Array/Map の読み取りAPIが JIT 経路で VM と一致
+  - length/isEmpty/charCodeAt, Array.get, Map.size/has
+- 境界: 署名不一致・未対応は VM フォールバック（理由はイベントJSONに記録）
+- 箱: Policy/Events/Registry を 1 箇所参照（切替点の一本化）
+- 観測: JSONL イベントが最小1件以上出力（オプトイン）

-### 第1段階：読み取り専用メソッド
-```nyash
-// StringBox
-str.length()      // → i64
-str.isEmpty()     // → bool
-str.charAt(idx)   // → String（新Box生成）
+## 🧱 先に積む箱（最小）
+- JitConfigBox（設定）
+  - exec/stats/dump/phi_min/hostcall/native_f64/native_bool/threshold を `apply()` でenv反映
+  - `toJson()/fromJson()/summary()` で可視化
+- JitPolicyBox（ポリシー）
+  - read_only/hostcall_whitelist。書込系は既定で拒否（jit-direct等の安全弁）
+- JitEventsBox（観測）
+  - compile/execute/fallback/trap を 1行JSON（標準出力 or ファイル）で記録
+- HostcallRegistryBox（レジストリ）
+  - 許可HostCallと args/ret 署名（唯一の切替点）。不一致は `sig_mismatch`
+- FrameSlotsBox（スロット）
+  - ptr→slot の割付と型注釈（v0は i64 のみ）
+- CallBoundaryBox（境界）
+  - JIT↔VM の薄い呼出し点（型変換の一本化）。将来多関数へ拡張

-// ArrayBox  
-arr.length()      // → i64
-arr.isEmpty()     // → bool
-arr.get(idx)      // → Box（既存参照）
+最小原則: 箱を先に置く（no-op/ログでもOK）→ 切替点を1箇所に固定 → その箱の内部を順に強化。

-// IntegerBox/FloatBox
-int.toFloat()     // → f64
-float.toInt()     // → i64
-```
+## 🛣️ 実行経路の設計（概要）
+1) Runner: CLI/env→`JitConfig`→TLSへ反映（env直読を排除）
+2) LowerCore: `jit::config::current()` を参照し、BoxCall/Load/Store/Branch/PHIを最小下ろし
+3) HostCall: Handle経由で read-only を通す（mutating は Policy で拒否）
+4) Fallback: 未対応/署名不一致/ポリシー違反は VM 実行へ委譲
+5) Events: `JitEventsBox` 経由で allow/fallback/trap を JSONL 出力

-### 第2段階：Box生成
-```nyash
-// new演算子のJIT化
-new StringBox("hello")     // → Handle
-new IntegerBox(42)         // → Handle（または直接i64）
-new ArrayBox()             // → Handle
-```
+## 🔢 対象API（v0）
+- ArrayBox: `length`, `get`, `isEmpty`, `push/set`（mutatingは拒否）
+- MapBox: `size`, `has`, `get`, `set`（mutatingは拒否）
+- StringBox: `length`, `isEmpty`, `charCodeAt`
+- Math（薄接続）: `sin/cos/abs/min/max`（署名一致のみ allow を記録、実体はVMへ）

-### 第3段階：書き込みメソッド
-```nyash
-// 状態変更を伴う操作
-arr.push(item)             // Mutex操作必要
-arr.set(idx, value)        // 境界チェック必要
-map.set(key, value)        // ハッシュ操作
-```
+## 🗺️ マイルストーン
+### 10.9-α（足場）
+- JitPolicyBox v0: read-only/whitelist を箱へ移動
+- JitEventsBox v0: compile/execute の JSONL イベント（オプトイン）
+- ドキュメント: 再起動チェック/箱の役割を追記

-## 🔧 実装戦略
+### 10.9-β（読み取りカバレッジ）
+- HostcallRegistryBox v0: String/Array/Map 読み取り API の登録・署名検査
+- LowerCore: BoxCall read-only 経路を Registry/Policy 参照に切替
+- E2E: `length/isEmpty/charCodeAt/get/size/has` の一致（jit-direct + VM）

-### 1. HandleRegistry活用
-```rust
-// 既存のHandleRegistry（80%実装済み）を拡張
-pub fn jit_get_box_method(handle: u64, method: &str) -> Option<MethodPtr> {
-    // ハンドル → Box → メソッドポインタ
-}
-```
+### 10.9-γ（生成の足場）
+- CallBoundaryBox v0: JIT→VMで `new` 等を委譲（薄い箱）
+- `new StringBox/IntegerBox/ArrayBox` の最小経路（方針次第で jit-direct は拒否）

-### 2. HostCall拡張
-```rust
-// 現在の限定的なHostCallを段階的に拡張
-enum HostCallKind {
-    // 既存
-    ArrayIsEmpty,
-    StringLength,
-    
-    // Phase 10.9で追加
-    StringIsEmpty,
-    StringCharAt,
-    ArrayGet,
-    IntToFloat,
-    FloatToInt,
-    
-    // new演算子サポート
-    NewStringBox,
-    NewIntegerBox,
-    NewArrayBox,
-}
-```
+### 10.9-δ（書き込みの導線のみ）
+- JitPolicyBox: 書込許可スイッチ（既定OFF）
+- LowerCore: 書込命令は Policy 参照で拒否/委譲/許可（1箇所で判断）

-### 3. 型安全性の確保
-```rust
-// JIT時の型チェック
-match method {
-    "length" => {
-        // StringBox/ArrayBoxのみ許可
-        verify_box_type(handle, &[BoxType::String, BoxType::Array])?
-    }
-    "isEmpty" => {
-        // より多くのBoxで使用可能
-        verify_box_type(handle, &[BoxType::String, BoxType::Array, BoxType::Map])?
-    }
-}
-```
+## ✅ すぐ使えるチェック
+- ビルド
+  - `cargo build --release --features cranelift-jit`
+- 主要フラグ
+  - `NYASH_JIT_EXEC=1` `NYASH_JIT_THRESHOLD=1`
+  - `NYASH_JIT_EVENTS=1`（標準出力へJSON）
+  - 任意: `NYASH_JIT_EVENTS_PATH=target/nyash/jit-events.jsonl`
+- 代表サンプル（VM経由でJITパス通過）
+  - 成功: `./target/release/nyash --backend vm examples/jit_hostcall_len_string.nyash`
+  - 失敗: `NYASH_JIT_EVENTS=1 ./target/release/nyash --backend vm examples/jit_hostcall_array_append.nyash`
+  - 境界: `NYASH_JIT_EVENTS=1 ./target/release/nyash --backend vm examples/jit_hostcall_math_sin_mismatch.nyash`
+  - 署名一致(allow観測): `NYASH_JIT_EVENTS=1 ./target/release/nyash --backend vm examples/jit_hostcall_math_sin_allow_float.nyash`
+  - 関数スタイル(math.*): `NYASH_JIT_NATIVE_F64=1 NYASH_JIT_EVENTS=1 ./target/release/nyash --backend vm examples/jit_math_function_style_sin_float.nyash`
+    - `cos/abs/min/max` も同様のサンプルあり
+- 詰まったら
+  - `--features cranelift-jit` が付いているか
+  - イベントJSONに `fallback/trap` の理由が出ているか
+  - `cargo clean -p nyash-rust` → 再ビルド

-## 📊 成功指標
+## 🧪 検証と観測
+- 統合JIT統計（テキスト/JSON）: sites/compiled/hits/exec_ok/trap/fallback_rate/handles
+- `JitStatsBox.perFunction()` で関数単位の統計（JSON配列）
+- CFG/PHIダンプ: `NYASH_JIT_DUMP=1`、`NYASH_JIT_DOT=path.dot`（最小）
+- b1正規化カウンタ: `b1_norm_count`（分岐条件/PHI）
+- HostCallイベント: `argc`/`arg_types`/`reason`でデバッグ容易化（mutatingは `policy_denied_mutating`）

-### 機能面
- [ ] StringBox.length() がJITで実行可能
- [ ] ArrayBox.isEmpty() がJITで実行可能
- [ ] new StringBox() がJITで生成可能
- [ ] 型チェックが正しく動作
+## ⚠️ リスクとその箱での緩和
+- 署名不一致（args/ret）
+  - HostcallRegistryBox で一元検査。不一致は `sig_mismatch` でイベント記録→VMへ
+- mutatingの混入
+  - JitPolicyBox.read_only で抑止。Registryの Mutating 分類と併用
+- 型崩れ/ABIの揺れ
+  - `JitValue`（I64/F64/Bool/Handle）へ統一、変換は境界1箇所
+- 観測不足
+  - JitEventsBox の粒度を最小から用意（必要に応じ拡張）

-### 性能面
- [ ] HostCall経由でも10倍以上高速化
- [ ] Handle解決のオーバーヘッド最小化
- [ ] Mutex競合の回避（読み取り専用）
+## 🔧 実装ノート（現状）
+- Config: Rust側 `jit::config::JitConfig` に集約。Nyash側は JitConfigBox で操作
+- LowerCore: BoxCallの read-only は Registry/Policyに委譲。math.* は署名一致なら allow を記録（実行はVM）
+- Handle: `rt::handles` による u64→Arc<Box>。JIT↔ホストをVM型非参照で独立
+- 数値緩和: `NYASH_JIT_HOSTCALL_RELAX_NUMERIC=1` で i64→f64 コアーションを許容（既定は `native_f64=1` 時に有効）。`JitConfigBox.set_flag("relax_numeric", true)` でも切替可能

-### Python統合への貢献
- [ ] PythonParserBoxの基本メソッドが使用可能
- [ ] MirBuilderBoxへのデータ受け渡し可能
- [ ] 最小限のPython→Nyash変換が動作
-
-## 🚧 技術的課題
-
-### 1. Arc<Mutex>パターンとの整合性
-```rust
-// 読み取り専用でもMutexロックが必要？
-// → 読み取り専用APIを別途用意？
-```
-
-### 2. Box生成時のメモリ管理
-```rust
-// JIT内でのArc生成
-// → HandleRegistryで一元管理
-```
-
-### 3. エラーハンドリング
-```rust
-// パニックしない設計
-// → Result型での丁寧なエラー伝播
-```
-
-## 📈 実装ロードマップ
-
-### Week 1：基盤整備
- HandleRegistry拡張
- HostCallインターフェース設計
- 型チェック機構
-
-### Week 2：読み取りメソッド実装
- StringBox：length, isEmpty, charAt
- ArrayBox：length, isEmpty, get
- 数値変換：toInt, toFloat
-
-### Week 3：Box生成サポート
- new演算子のMIR→JIT変換
- コンストラクタ呼び出し
- HandleRegistry登録
-
-### Week 4：テストと最適化
- E2Eテストスイート
- パフォーマンス測定
- Python統合の動作確認
-
-## 🎉 期待される成果
-
-```nyash
-// これが高速に動く！
-static box FastPython {
-    main() {
-        local py = new PythonParserBox()     // JITで生成！
-        local code = "def add(a, b): return a + b"
-        local ast = py.parse(code)           // JITで実行！
-        
-        local builder = new MirBuilderBox()  // JITで生成！
-        local mir = builder.build(ast)       // JITで実行！
-        
-        // Python関数がネイティブ速度で動く！
-        return "Python is now Native!"
-    }
-}
-```
-
-## 🚀 次のステップ
-
-→ Phase 10.10：プラグインBox JITサポート
-→ Phase 10.1：Python統合（いよいよ実現！）
+## 📌 次の拡張（10.9の後）
+- f64ネイティブ最小経路（`NYASH_JIT_NATIVE_F64=1`）の拡充
+- Boolネイティブ（b1）署名サポート（ツールチェーンcapに連動）
+- HostCallブリッジの拡大（Map.getの多型キー、String操作の追加）
+- CallBoundaryBox経由の `new`/副作用命令の段階的JIT化

 ---

-作成者：Claude（Nyashくんの要望により）  
-目的：「うるさい、Nyashつかえ」を真に実現するため
+最短ルート: 箱（Policy/Events/Registry/Boundary）を先に置き、読み取り系でJITを安全に通す→観測を増やす→署名とポリシーの一本化で切替点を固定→必要最小限のネイティブ型（f64/b1）を段階導入。