hakorune/docs/予定/native-plan/copilot_issues_20250814_135116_backup.txt

# 🤖 Copilot様 作業予定・課題整理 (Phase 0-14 全体ロードマップ)
# Generated: 2025-08-14 (Git履歴から復元・更新)
# Purpose: Claude×Copilot協調開発のための情報共有

================================================================================
🎯 次期最優先タスク (Phase 8.5以降)
================================================================================

## 🚀 Phase 8.4完了報告 (2025-08-14)
Status: ✅ 完了 (Copilot PR #56マージ済み)

### ✅ AST→MIR Lowering完全実装
- User-defined Box: `box DataBox { init { value } }`
- Object creation: `new DataBox(42)`
- Field access: `obj.value` 
- Method calls: `c.increment()`
- Delegation: `from Parent.greet()`
- Static Main互換性維持

### 🧪 統合テスト結果（2025-08-14）
- ✅ **AST→MIR**: 完全動作
- ✅ **インタープリター**: 完全動作（結果30）
- 🚨 **VM**: 動作するが結果が`void`（要修正）
- 🚨 **WASM**: String constant未対応（Phase 8.5で解決）

### 📋 発見された課題
- VM実行結果問題: BoxCall後の戻り値が正しく返らない
- WASM対応不足: 複雑なMIR命令（String constant, BoxCall）に未対応
- 次期Phase 8.5での25命令MIR階層化が必要

================================================================================

## 🔧 Phase 8.5: MIR 25命令階層化（最優先）
Status: ⭐ **CRITICAL** 
Priority: **最重要** (Phase 8.4完了直後の次期目標)

### 🎯 実装目標
ChatGPT5 + AI大会議決定版25命令MIR実装
- 期間: 3週間
- 効果: VM/WASM問題根本解決
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md`

### 📋 25命令セマンティック階層化
**Tier-0: 普遍コア（8命令）**
```mir
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
```

**Tier-1: Nyashセマンティクス（12命令）**
```mir
NewBox, BoxFieldLoad, BoxFieldStore, BoxCall, Safepoint,
RefGet, RefSet, WeakNew, WeakLoad, WeakCheck, Send, Recv
```

**Tier-2: 実装補助・最適化友好（5命令）**
```mir
TailCall, Adopt, Release, MemCopy, AtomicFence
```

### 🎯 期待される効果
- **VM問題解決**: BoxCallの正しい実装で戻り値問題修正
- **WASM対応**: 階層化により複雑MIR→単純WASM変換
- **Everything is Box**: BoxFieldLoad/Storeで明確なBox中心設計
- **JIT準備**: セマンティクス保持で高度最適化基盤確立

================================================================================

## 🏎️ Phase 8.6: VM性能改善（緊急）
Status: 🚨 **緊急** 
Priority: **High** (Phase 8.5完了後)

### 🚨 緊急問題
**現状**: VM（119.80ms）< Interpreter（110.10ms）= 0.9倍の性能劣化
**新問題**: VM BoxCall後の戻り値が`void`（Phase 8.4テストで発見）

### 📋 技術的課題
- VM実行エンジンのプロファイリング
- 命令ディスパッチ最適化（threaded code等）
- レジスタベースVM化検討  
- メモリプール最適化
- BoxCall実装修正（戻り値問題）

### 🎯 成功基準
- VM性能 > Interpreter性能（最低2倍目標）
- BoxCall戻り値の正常動作
- MIR→VM変換時間の短縮

================================================================================

## 🧪 Phase 8.7: Real-world Memory Testing
Status: 📋 **計画済み**
Priority: **High** (Phase 8.5-8.6完了後)

### 🎯 実装目標
kilo（テキストエディタ）実装によるfini/weak参照システム実証
- 期間: 2週間
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md`

### 📋 検証項目
- 1000+オブジェクト管理テスト
- 循環参照回避確認（weak参照）
- fini()伝播の正確性確認
- WASM環境での動作確認

================================================================================
🗺️ Phase 0-14 全体ロードマップ (復元完了)
================================================================================

## Phase 0: Stabilize native CLI build (Linux/Windows)

Summary:
- CLIバイナリ nyash を最小構成で安定ビルド・実行できる状態にする。
- examples/GUI をデフォルトのビルド対象から外し、開発の足場を固める。

Why:
- 以降の MIR/VM/JIT 開発を素早く検証できる基盤づくり。

Scope:
- Cargo の features で GUI/examples 等を切り分け、デフォルトは CLI 最小にする。
- CLI オプションの動作点検（--dump-mir / --verify）。
- ローカル実行導線を README に明記（docs/guides/how-to-build-native/README.md）。

Tasks:
- Cargo.toml: examples/GUI を feature でガード（default は CLI 最小）。
- ビルド検証: `cargo build --bin nyash`（Linux/Windows）。
- 実行検証: `cargo run -- ./local_tests/sample.nyash`。
- ドキュメント: 上記手順を how-to-build-native に追記/点検。

Acceptance Criteria:
- Linux/Windows で `cargo build --bin nyash` が成功する。
- `local_tests/` 配下の簡単な .nyash が実行できる。
- 他 bin/examples が壊れていても `--bin nyash` だけで通る。

Out of Scope:
- examples/GUI の修理・最適化。
- JIT/AOT/WASM。

References:
- docs/guides/how-to-build-native/README.md
- docs/nativebuild大作戦/chatgptネイティブビルド大作戦.txt（Phase 0）
- CURRENT_TASK.md

Copilot Notes:
- まずは features 分離と `--bin nyash` でビルドが通る状態を作る。README の手順確認まで含めて PR に反映。

------------------------------------------------------------

## Phase 1: Minimal MIR + VM backend (lowering + runner)

Summary:
- AST → MIR の最小 lowering と、VM バックエンドでの実行を通す。

Scope:
- MIR: Const, BinOp, Compare, Branch, Jump, Phi, Return の最小命令
- Lowering: リテラル/二項演算/if/loop/return のみ
- VM: 上記命令の最小実装

Tasks:
- instruction.rs: 最小命令の定義
- builder.rs: 上記 AST 範囲を lowering
- vm.rs: 実装 + stats（命令数）

Acceptance Criteria:
- `--dump-mir` が最小サンプルで期待通り
- `--backend vm` で実行して結果一致

Out of Scope:
- 例外/関数/Box 参照/弱参照

------------------------------------------------------------

## Phase 2: Control-flow coverage (if/else/loop/phi correctness)

Summary:
- 制御フローの網羅と Phi の整合性検証を拡充。

Scope/Tasks:
- if/else nested, loop with breaks, nested loops のスナップショット
- Phi の入力ブロック/値の対応を Verifier で強化

Acceptance Criteria:
- 代表制御フローの snapshot が安定し、verify も通る

------------------------------------------------------------

## Phase 3: Exceptions (throw/try/catch/finally) minimal lowering

Summary:
- 例外機構の最小 lowering を導入（詳細設計は簡素）。

Scope/Tasks:
- MIR: Throw, TryBegin/TryEnd, Catch, FinallyBegin/End（最小）
- builder.rs: try/catch/finally ノードの下ろし
- VM: 例外伝播を最小で（未捕捉はエラー）

Acceptance Criteria:
- 代表 try/catch/finally のスナップショットと VM 実行

Out of Scope:
- 例外の型体系、詳細な stack map

------------------------------------------------------------

## Phase 4: Functions and calls (BoxCall minimal)

Summary:
- 関数呼び出し/BoxCall を最小導入（効果注釈は保守的）。

Scope/Tasks:
- MIR: Call, BoxCall（effects = READS_HEAP など保守）
- builder.rs: FunctionCall/MethodCall の最小対応
- VM: 呼び出し/戻り値

Acceptance Criteria:
- 簡単な関数定義/呼び出しの MIR/VM が通る

Out of Scope:
- 可変長/キーワード引数、FFI

------------------------------------------------------------

## Phase 5.0: Parser/AST stabilization for lowering

Summary:
- lowering 対象 AST の表現ぶれを修正、安定化。

Scope/Tasks:
- AST: If/Loop/Return/Assignment/Local などの統一
- Parser: エラー復帰/スパン情報の見直し

Acceptance Criteria:
- builder.rs の分岐がシンプル化、テストが安定

------------------------------------------------------------

## Phase 5.1: Control-flow edge cases + verifier hardening

Summary:
- ブロック未終端/未到達/自己分岐等の検証強化でクラッシュ回避。

Scope/Tasks:
- Verifier: 未終端ブロック検出、到達不能検出
- Builder: Jump/Branch の生成前後の状態管理改善

Acceptance Criteria:
- 不正ケースを含むスナップショット/verify が緑

------------------------------------------------------------

## Phase 5.2: Lowering for static box Main (BoxDeclaration → main body)

Summary:
- static box Main { main() { ... } } を MirBuilder で受け、main() の body を Program として lowering する経路を実装。

Scope/Tasks:
- AST: BoxDeclaration(is_static=true, name=Main) を検出 → main() を抽出
- Lowering: body を Program に変換して既存経路に渡す
- Tests: local_tests/mir_loop_no_local.nyash で dump/VM が通る

Acceptance Criteria:
- `--dump-mir` が static Main サンプルで成功
- `--backend vm` で実行成功

References:
- docs/guides/how-to-build-native/issues/phase5_2_static_main_lowering.md

------------------------------------------------------------

## Phase 6: Box ops minimal (Ref/Weak + Barriers no-op)

Summary:
- 参照/弱参照/バリア（no-op）を最小導入。

Scope/Tasks:
- MIR: RefNew/RefGet/RefSet/WeakNew/WeakLoad/BarrierRead/Write
- Lowering: New/FieldAccess/MethodCall の最小対応
- VM: 参照テーブル/weak テーブルで動作（fini 不変は維持）

Acceptance Criteria:
- 代表サンプルで dump/VM/verify が通る

References:
- docs/guides/how-to-build-native/issues/phase6_box_ops_minimal.md

------------------------------------------------------------

## Phase 7: Async model (nowait/await) in MIR

Summary:
- nowait/await を MIR に導入し、現行 FutureBox と連携。

Scope/Tasks:
- MIR: FutureNew/FutureSet/Await（スレッドベース）
- Lowering: nowait→Future 作成、await→wait_and_get
- VM: FutureBox 実装を利用

Acceptance Criteria:
- 代表ケースで正しく並行実行→await 回収

References:
- docs/guides/how-to-build-native/issues/phase7_async_mir.md

------------------------------------------------------------

## Phase 8: MIR→WASM codegen (browser/wasmtime; sandboxed; Rust runtime free)

Summary:
- MIR から素の WebAssembly を生成し、ブラウザ/wasmtime（WASI）でサンドボックス実行する。
- Rust はコンパイラ本体のみ。実行は純WASM＋ホストimport（env.print など）。

Scope/Tasks:
- ABI/Imports/Exports 定義（exports: main/memory、imports: env.print(i32) 等の最小）
- 線形メモリと簡易ヒープ（bump/自由リスト）
- 命令カバレッジ（段階導入）: 算術/比較/分岐/loop/return/print、RefNew/RefSet/RefGet（Phase 6 整合）、Weak/Barrier はダミー

Acceptance Criteria:
- wasmtime 実行で戻り値/print が期待通り（PoC1–2）
- Ref 系がメモリ上で正しく動作（PoC2）
- Weak/Barrier のダミー実装を含むWASMが生成・実行（PoC3）
- CLI `--backend wasm` は未実装でもよいが、実装する場合は明瞭にエラーメッセージ/誘導

References:
- docs/予定/native-plan/README.md（Phase 8 節）
- docs/説明書/wasm/*（ユーザー向けメモ）

### Phase 8.3 完了状況 (2025-08-14)
✅ Box操作WASM実装 (RefNew/RefGet/RefSet)
✅ ベンチマークシステム統合 (13.5倍実行高速化実証)
✅ CLI統合完了

------------------------------------------------------------

## 🔧 Phase 8.4: AST→MIR Lowering完全実装 (最優先)

Summary:
- ユーザー定義Box、フィールドアクセス等の未実装部分を完成
- Phase 8.3のBox操作WASMを実際にテスト可能にする

Priority: **Critical** (現在の最優先事項)
Expected Duration: 1週間

### 実装範囲
- [ ] ユーザー定義Box: `box DataBox { init { field } }`
- [ ] オブジェクト生成: `new DataBox()`  
- [ ] フィールドアクセス: `obj.field`
- [ ] フィールド代入: `obj.field = value`
- [ ] from構文: `from Parent.method()`
- [ ] override構文: `override method() { ... }`

### 成功基準
- Phase 8.3のBox操作WASMが実際に動作
- test_wasm_box_ops.nyash が正常実行
- ユーザー定義Boxの完全サポート

------------------------------------------------------------

## 🧠 Phase 8.5: MIRセマンティック階層化（AI大会議決定版）

Summary:
- 方針転換: ChatGPT5の20命令intrinsic戦略 → Gemini+Codex一致推奨の25命令階層化
- 理由: JIT/AOT最適化阻害・Everything is Box意味喪失・長期コスト増の問題判明
- 二相ロワリング: 25命令維持パス（VM/JIT/AOT）+ 20+intrinsic降格パス（WASM/最小実装）

Priority: High (Phase 8.4完了後)
Expected Duration: 3週間

### AI大会議分析結果
**Gemini先生（理論）**: 「賢いコンパイラは、賢いMIRから生まれる」
- RefNew/WeakLoadのintrinsic化は最適化機会を失う悪手
- セマンティック階層化で意味保持が最適化の鍵

**Codex先生（実装）**: 二相ロワリング戦略が実用的最適解
- 実装コスト: 5命令追加で10-20人日（intrinsic戦略より安い）
- マイクロベンチ実測でパフォーマンス検証

### 確定版MIR（25命令）- ChatGPT5完全仕様
**Tier-0: 普遍的コア（8命令）**
```mir
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
```

**Tier-1: Nyashセマンティクス（12命令）**
```mir
NewBox,        // 強所有のBox生成（所有森のノード）
BoxFieldLoad,  // Boxのフィールド読み（Everything is Box核心）
BoxFieldStore, // Boxのフィールド書き（mut効果）
BoxCall,       // Boxのメソッド呼び出し（動的/静的両方）
Safepoint,     // 分割finiや割込み許可ポイント
RefGet,        // 参照（強/弱を問わず）を値として取得
RefSet,        // 参照の差し替え（所有規則検証付き）
WeakNew,       // weak ハンドル生成（非所有リンク作成）
WeakLoad,      // weak から生存チェック付きで強参照取得（失効時null）
WeakCheck,     // weak の生存確認（bool）
Send,          // Bus送信（io効果）
Recv           // Bus受信（io効果）
```

**Tier-2: 実装補助・最適化友好（5命令）**
```mir
TailCall,      // 末尾呼び出し（スタック節約）
Adopt,         // 所有移管: this が子を強所有に取り込む
Release,       // 強所有を解除（weak化 or null化）
MemCopy,       // 小さなメモリ移動（構造体/配列最適化フック）
AtomicFence    // 並行時の順序保証（Actor/Port境界で使用）
```

### 二相ロワリング戦略
- パスA: VM/JIT/AOT向け（25命令のまま最適化）
- パスB: WASM/最小実装向け（25→20+intrinsic降格）
- バックエンド能力に応じて最適形式選択

### 効果（Effect）システム（ChatGPT5設計）
- **pure**: Const, BinOp, Compare, Phi, RefGet, WeakNew, WeakLoad, WeakCheck
- **mut**: BoxFieldStore, RefSet, Adopt, Release, MemCopy
- **io**: Send, Recv, Safepoint, AtomicFence
- **control**: Branch, Jump, Return, TailCall
- **context依存**: Call, BoxCall（呼び先効果に従属）

**最適化ルール**: 「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」

### 検証（Verifier）要件
- **所有森**: `strong in-degree ≤ 1`（NewBox/Adopt/Release/RefSetで常時検査）
- **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
- **weak/強相互**: 双方向とも強 → エラー（片側はWeakNew経由で弱化）
- **WeakLoad/WeakCheck**: 失効時はnull/falseを返す（例外禁止、決定的挙動）

### 🤖 Copilot協力期待
- **Tier-0/1実装**: Everything is Box哲学の完璧なIR化（BoxFieldLoad/Store核心）
- **weak参照システム**: WeakNew/WeakLoad/WeakCheck三位一体実装
- **所有移管**: Adopt/Release命令による安全で効率的なメモリ管理
- **効果システム**: pure/mut/io/control効果の正確な実装とVerifier統合
- **最適化フック**: TailCall/MemCopy/AtomicFenceの実装補助
- **二相ロワリング**: 25命令維持パス + 20+intrinsic降格パス構築

### 成功基準
- [ ] **25命令完全実装**: ChatGPT5仕様の完璧な実装
- [ ] **効果システム動作**: pure再順序化・mut依存保持・io順序保証
- [ ] **Verifier動作**: 所有森・strong循環・安全性検証
- [ ] **Golden MIRテスト**: 全バックエンドでMIR一致
- [ ] **行動一致テスト**: 同入力→同出力（weak失効時null/false含む）
- [ ] **性能要件**: VM≥Interpreter、WASM≥VM継続検証

### バックエンド指針（ChatGPT5設計）
- **Interpreter**: 25命令を素直に実装（正しさの基準）
- **VM**: Register-VM + direct-threading。Send/Recvはローカル判定時にインライン化
- **WASM**: Send/Recvはhost import。MemCopyはmemory.copyに対応
- **JIT（将来）**: TailCall最適化、WeakLoadは世代タグでO(1)生存チェック

References:
- docs/予定/native-plan/MIR仕様書.txt（ChatGPT5完全仕様）
- docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md

------------------------------------------------------------

## 🏎️ Phase 8.6: VM性能改善 (緊急)

Summary:
- VMがインタープリターより遅い問題（0.9倍）を解決
- MIR→VM実行の最適化でインタープリターを上回る性能へ

Priority: High (Phase 8.5完了後)
Expected Duration: 2週間

### 問題分析
**現状**: VM (119.80ms) < Interpreter (110.10ms)
**推定原因**:
- MIR変換オーバーヘッド
- VM命令ディスパッチの非効率性
- メモリ管理コスト

### 技術的アプローチ
- [ ] VM実行エンジンのプロファイリング
- [ ] 命令ディスパッチ最適化（threaded code等）
- [ ] レジスタベースVM化検討
- [ ] メモリプール最適化

### 🤖 Copilot協力期待
- VM実装のボトルネック特定
- 効率的な命令ディスパッチ実装
- スタックマシン vs レジスタマシン判断

### 成功基準
- VM性能 > Interpreter性能（最低2倍目標）
- MIR→VM変換時間の短縮
- メモリ使用量の削減

------------------------------------------------------------

## 🧪 Phase 8.7: Real-world Memory Management Testing (ChatGPT協調設計)

Summary:
- 実用アプリケーション開発によるNyashメモリ管理システムの実証テスト
- finiシステム・weak参照の実用性を複雑なアプリケーションで検証

Priority: High (Phase 8.4-8.6完了直後)
Expected Duration: 2週間

### Phase 8.7A: kilo（テキストエディタ）
**技術的特徴**:
- サイズ: <1k LOC（超小型、最初の成功体験）
- メモリパターン: Editor -> (Rows -> Syntax) 木構造＋相互参照
- ChatGPT設計: Editor削除でRows自動解放、逆参照をweak化

**実装範囲**:
- [ ] Editor/Row/EditorState基本構造実装
- [ ] weak参照による循環参照回避（`me.editor = weak editor_ref`）
- [ ] fini()システムによる自動メモリ解放
- [ ] 大量オブジェクト（1000+ Rows）管理テスト

**検証ポイント**:
- [ ] Editor削除でRows自動解放確認
- [ ] 相互参照でメモリリークなし確認  
- [ ] weak参照の自動null化確認
- [ ] fini()伝播の正確性確認

### Phase 9.5予定: tiny-web-server（HTTPサーバ）
**将来実装**（JIT実装後）:
- 複雑度: 中〜高（Server -> Clients -> Requests並行処理）
- I/O管理: ソケット・ファイルハンドルの確実解放
- 同時接続・早期切断・例外経路でのfini伝播テスト

### 🤖 Copilot協力期待
- 実用的なメモリ管理パターンの実装
- weak参照構文の適切な使用
- デバッグ支援機能（--debug-memory, --trace-weak）
- WASM環境でのメモリ管理互換性

### 成功基準
- [ ] 全テストケースでメモリリークなし
- [ ] 循環参照でも正常解放確認
- [ ] WASM実行でもメモリ管理正常
- [ ] ベンチマーク性能劣化なし

### 期待される効果
- Nyashメモリ管理システムの実用性実証
- Everything is Box哲学の実用レベル確認  
- メモリ安全なプログラミングパターン確立

References:
- docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md

------------------------------------------------------------

## 🚀 Phase 9: AOT WASM実装（最優先）

Summary:
- wasmtime compileによるAOT実行ファイル生成で確実なユーザー価値提供

Scope/Tasks:
- `wasmtime compile` 統合実装
- `--compile-native` / `--aot` CLI追加
- 単一バイナリ梱包（`include_bytes!`）
- 起動時間・配布サイズ最適化

Acceptance Criteria:
- `nyash --compile-native app.nyash -o app.exe` 動作
- 起動時間大幅短縮（JIT起動コスト除去）
- 配布可能実行ファイル生成

Priority: **Critical** (Phase 8.6完了直後)
Expected Duration: 2-3週間

### 技術的実装詳細
🤖 Copilot協力期待:
- wasmtime::Config統一実装
- .cwasm生成・実行パイプライン  
- 互換性キー管理（CPU機能・wasmtimeバージョン）
- パッケージング（単一バイナリ梱包）

### パフォーマンス目標
- 現在のWASM JIT (13.5倍実行) → AOT (500倍目標：起動含む)
- 配布ファイルサイズ: <10MB目標
- 起動時間: <100ms目標

### 期待される効果
- **即座実用価値**: 配布可能実行ファイル生成
- **差別化優位**: Everything is BoxのネイティブAOT実現
- **LLVM準備**: AOT基盤確立でLLVM移行準備

------------------------------------------------------------

## 🌐 Phase 9.5: HTTPサーバー実用テスト（AOT検証）

Summary:
- AOT実装完了後の複雑アプリケーション検証（並行処理・メモリ管理・実用性能）

Scope/Tasks:
- tiny-web-server実装（HTTP/1.1対応）
- 同時接続・早期切断・例外経路テスト
- AOT環境での真の性能測定
- 配布可能HTTPサーバーデモ

Acceptance Criteria:
- `http_server.exe`として配布可能
- 同時100接続でメモリリークなし
- fini()システム確実動作（I/Oハンドル解放）
- AOT性能でベンチマーク測定

Priority: High (Phase 9完了直後)
Expected Duration: 2週間

### 技術的複雑度
```nyash
box HTTPServer {
    init { clients, requests, handlers }
    
    acceptConnections() {
        loop(me.running) {
            local client = me.socket.accept()
            nowait me.handleClient(client)  // 非同期並行処理
        }
    }
    
    handleClient(client) {
        local request = client.readRequest()
        local response = me.processRequest(request)
        client.sendResponse(response)
        client.fini()  // 重要: 確実なリソース解放
    }
}
```

### 検証ポイント
- **並行処理**: nowait/awaitのAOT実行性能
- **メモリ管理**: Server→Clients→Requests木構造+weak参照
- **I/Oリソース**: ソケット・ファイルハンドルの確実解放
- **実用性能**: リアルHTTP負荷でのAOT効果測定

### 🤖 Copilot協力期待
- Socket・HTTP実装の効率化
- 複雑なメモリ管理パターン検証
- 負荷テスト・ベンチマーク整備
- AOT最適化効果の定量測定

------------------------------------------------------------

## 🏆 Phase 10: LLVM Direct AOT（最高性能実現）

Summary:
- MIR→LLVM IR直接変換による最高性能AOT実現（Cranelift JITスキップ）

Scope/Tasks:
- MIR→LLVM IR lowering実装
- エスケープ解析・ボックス化解除
- LTO・PGO・高度最適化統合
- Everything is Box最適化

Acceptance Criteria:
- 1000倍高速化達成
- プロダクションレベル最適化
- 他言語との競争力確立

Priority: Medium (Phase 9.5完了後)
Expected Duration: 4-6ヶ月

### 技術アプローチ
🤖 Copilot協力期待:
- **LLVM統合**: MIR→LLVM IR変換基盤
- **エスケープ解析**: Box→スタック値最適化
- **型特殊化**: コンパイル時型推論・特殊化
- **LTO統合**: Link-time optimization
- **PGO対応**: Profile-guided optimization

### Everything is Box最適化戦略
- **Box回避**: スタック割り当て・直接レジスタ配置
- **NaN Boxing**: 効率的な値表現
- **型推論**: コンパイル時型特定・最適化
- **メモリレイアウト**: 連続配置・キャッシュ効率

### パフォーマンス目標
- **実行性能**: 1000倍高速化（現在13.5倍 → 目標13500倍相当）
- **メモリ効率**: Box割当数80%削減
- **起動時間**: ネイティブレベル（<10ms）
- **競合比較**: C/C++/Rust並みの性能

### Cranelift JIT位置づけ変更
**Phase 12以降の将来オプション**:
- JIT開発体験向上（nyashプログラマー向け）
- REPL・インタラクティブ実行
- プロファイル駆動最適化
- 言語完成後の付加価値機能

------------------------------------------------------------

## Phase 11-14: Infrastructure & Polish

### Phase 11: MIR Optimization Framework
- エスケープ解析基盤
- 型特殊化・ボックス化解除
- デッドコード除去

### Phase 12: Advanced JIT Features  
- Profile-guided optimization
- インライン展開
- レジスタ割り当て最適化

### Phase 13: Production Readiness
- GC統合最適化
- メモリ使用量最適化
- 起動時間短縮

### Phase 14: Packaging/CI polish

Summary:
- Windows/Linux の配布パッケージ化と CI 整備。

Scope/Tasks:
- GitHub Actions: Windows(MSVC)/WSL+cargo-xwin のマトリクス
- dist/: nyash(.exe) + LICENSE/README 同梱

Acceptance Criteria:
- リリースアーティファクトが自動生成される

================================================================================
🧠 AI大会議 + 実用優先戦略で得られた技術的知見 (2025-08-14更新)
================================================================================

## Gemini先生の助言（修正適用）
✅ エスケープ解析・ボックス化解除が性能の鍵  
✅ wasmtime compileは短期的に実用的 → **Phase 9で最優先実装**
✅ WASM実行は確実に高速（13.5倍実証済み）
🔄 Cranelift → LLVM段階的アプローチ → **実用優先でLLVM直接へ**

## codex先生の助言（重点化）
✅ MIR前倒し実装推奨（全バックエンドが恩恵）
✅ wasmtime互換性管理が重要 → **AOT実装で最重要**
✅ CPU差異対応 (baseline/v3二段ビルド)
✅ 起動時間・割当削減・配布体験がKPI → **AOT価値の核心**

## Claude統合分析（実用優先）
✅ 実用価値最大化: WASM+AOTで十分な競争力
✅ 開発効率: Cranelift JITの恩恵限定的（cargo build変わらず）
✅ Everything is Box最適化が差別化の核心
✅ 時間効率: 2-3ヶ月節約でLLVM集中投資

## 🎯 実用優先戦略の確定理由
- **ユーザー体験**: WASM既に動作、AOTで配布価値追加
- **開発効率**: Cranelift JITは重複投資（Rust開発環境改善せず）
- **競合優位**: AOT+LLVM早期実現で差別化
- **リソース効果**: 限られた開発時間の最大効率化

================================================================================
💡 Copilot様への具体的お願い・相談事項
================================================================================

## 🔧 Phase 8.3完了・次期フェーズ準備

### MIRダイエット準備
❓ 現在35命令→20命令削減のintrinsic戦略実装は？
❓ ChatGPT5推奨の3-point setアプローチ最適化は？
❓ Portability Contract v0での互換性確保方法は？

### Phase 9 AOT WASM実装（最優先）
❓ wasmtime compileの実用配備方法は？
❓ .cwasm生成・単一バイナリ梱包戦略は？
❓ 互換性キー管理（CPU機能・wasmtimeバージョン）は？
❓ 起動時間最適化の実装アプローチは？

### Phase 9.5 HTTPサーバー検証
❓ Socket・HTTP実装の効率的な設計は？
❓ 並行処理でのメモリ管理パターンは？
❓ AOT環境でのI/Oリソース管理は？
❓ 負荷テスト・ベンチマーク設計は？

### Phase 10 LLVM Direct AOT
❓ MIR→LLVM IR変換の効率実装は？
❓ エスケープ解析・ボックス化解除の実装戦略は？
❓ LTO・PGO統合の技術的ハードルは？

## 🚀 長期戦略相談

### Everything is Box最適化
❓ Box操作の根本的高速化戦略は？
❓ エスケープ解析によるスタック化判定は？
❓ 型特殊化・ボックス化解除の実装戦略は？

### ベンチマーク拡張
❓ AOT性能測定の追加指標は？
❓ 1000倍高速化実現のマイルストーン設計は？
❓ 他言語(JavaScript V8, Rust, C++)との競争力分析は？
❓ HTTPサーバー負荷テストの効率設計は？

================================================================================
📊 進捗管理・コミュニケーション
================================================================================

## 🤝 協調開発ルール

### コミット・マージ戦略
✅ 大きな変更前にはdocs/CURRENT_TASK.mdで情報共有
✅ ベンチマーク機能は最優先で維持
✅ CLI統合は両機能を統合的に対応
✅ 競合発生時は機能優先度で解決

### 進捗報告
📅 週次: 進捗状況をCURRENT_TASK.mdに反映
📅 完了時: 新機能のベンチマーク結果を共有
📅 問題発生: AI大会議で技術的相談

### 品質保証
✅ cargo check でビルドエラーなし
✅ 既存ベンチマークが regression なし
✅ 新機能のドキュメント整備
✅ テストケース追加・CI通過

================================================================================
🎯 期待される成果・インパクト
================================================================================

## Phase 8完了時の成果 (達成済み)
🏆 RefNew/RefGet/RefSet WASM完全動作
🏆 Box操作ベンチマーク追加
🏆 メモリレイアウト最適化効果測定
🏆 オブジェクト指向プログラミングWASM対応
🏆 25命令MIR階層化完了（Phase 8.5）
🏆 VM性能改善完了（Phase 8.6）

## Phase 9-10実用優先展望
🚀 **AOT WASM実装** (Phase 9 - 2-3週間): 配布可能実行ファイル
🚀 **HTTPサーバー検証** (Phase 9.5 - 2週間): 実用アプリデモ
🚀 **LLVM Direct AOT** (Phase 10 - 4-6ヶ月): 1000倍高速化
🚀 **実用競争力確立**: 他言語との差別化完成

## 言語としての完成度向上
💎 Everything is Box哲学のネイティブ実現
💎 開発効率性と実行性能の両立
💎 4つの実行形態対応（Interpreter/VM/WASM/AOT）+ 将来JIT
💎 現代的言語としての地位確立

================================================================================
📞 連絡・相談方法
================================================================================

技術的相談や進捗報告は、以下の方法でお気軽にどうぞ：

1. 📝 GitHub Issues・Pull Request
2. 📋 docs/CURRENT_TASK.md コメント
3. 🤖 AI大会議 (重要な技術決定)
4. 💬 コミットメッセージでの進捗共有

どんな小さなことでも相談大歓迎です！
一緒にNyashを最高の言語にしていきましょう🚀

================================================================================
最終更新: 2025-08-14 (実用優先戦略・Phase 9-10再設計完了)
作成者: Claude (AI大会議結果 + 実用優先戦略統合)

🎯 重要な変更点:
- Phase 9: JIT planning → AOT WASM実装（最優先）
- Phase 9.5: HTTPサーバー実用テスト追加（AOT検証）
- Phase 10: AOT exploration → LLVM Direct AOT（最高性能）
- Cranelift JIT: Phase 12以降の将来オプションに変更
- HTTPサーバー: kilo後のタイミングで実用性能検証に特化
================================================================================