# AI協働開発ログ - 100の実践知に向けて

## 収集開始日: 2025-01-14

### 事例001: DebugBoxによる出力制御の統一化
- **問題**: print文が散在し、JSON出力に混入
- **AI提案**: 複雑なフィルタリング機構
- **人間の直感**: 「DebugBoxで包めば？」
- **結果**: Everything is Box哲学で解決
- **カテゴリ**: 箱化による解決

### 事例002: 子プロセス出力フィルタリング
- **問題**: stdout/stderrの混在でJSON解析失敗
- **AI提案**: 正規表現での複雑な抽出
- **人間の直感**: 「環境変数で静音モード作れば？」
- **結果**: NYASH_JSON_ONLY=1で単純解決
- **カテゴリ**: 環境変数による制御

### 事例003: PyVMという迂回路
- **問題**: Rust MIR生成層のビルド時間（9000行）
- **AI提案**: Rustコードの最適化
- **人間の直感**: 「Pythonで書いちゃえば？」
- **結果**: 2000行のPython実装で高速プロトタイピング
- **カテゴリ**: 迂回路を作る

### 事例004: peek式の名前変更
- **問題**: when式がRust予約語と衝突
- **AI提案**: 別の複雑な構文設計
- **人間の直感**: 「peekに名前変えれば？」
- **結果**: 直感的で分かりやすい名前に
- **カテゴリ**: 名前を変える

### 事例005: birth統一
- **問題**: コンストラクタ名がバラバラ（new/pack/constructor）
- **AI提案**: 複雑な名前解決システム
- **人間の直感**: 「全部birthにすれば？」
- **結果**: 「Boxに生命を与える」統一的な哲学
- **カテゴリ**: 名前を変える

### 事例006: MIR型情報の欠落（メイン事例）
- **問題**: 文字列が0になるバグ
- **AI提案**: 300行の型推測Resolver
- **人間の直感**: 「最初から型書けば？」
- **結果**: MIR v0.5で型メタデータ追加
- **カテゴリ**: 情報追加による解決

### 事例007: PHI生成の重複
- **問題**: BuilderとResolverで二重にPHI生成
- **AI提案**: 複雑な調整メカニズム
- **人間の直感**: 「なんで2つあるの？統一すれば？」
- **結果**: Resolver統一で複雑性削減
- **カテゴリ**: 統一による簡略化

### 事例008: 変数宣言の厳密化
- **問題**: 未宣言変数への代入でランタイムエラー
- **AI提案**: 高度な型推論システム
- **人間の直感**: 「全部明示宣言必須にすれば？」
- **結果**: メモリ安全性・非同期安全性保証
- **カテゴリ**: 制約による単純化

### 事例009: プラグイン全方向ビルド
- **問題**: 動的/静的リンクの複雑な管理
- **AI提案**: 複雑なビルドシステム
- **人間の直感**: 「全形式同時に作れば？」
- **結果**: .so/.o/.aを全部生成して選択
- **カテゴリ**: 全部作る戦略

### 事例010: 無限ループ対策のデバッグ燃料
- **問題**: パーサーが無限ループ
- **AI提案**: 複雑なループ検出アルゴリズム
- **人間の直感**: 「回数制限すれば？」
- **結果**: --debug-fuel で単純解決
- **カテゴリ**: 制限による制御

---

## 収集メモ

今後追加予定の事例カテゴリ：
- Arc<Mutex>自動化の経緯
- 動的ディスパッチによるmatch文削減
- エラー処理の統一化
- Box境界での型変換
- GCとスケジューラの統合
- etc...

目標：100個の実践知を体系化し、パターンを抽出

### 事例011: プラグインBoxライフサイクル事件 ⭐革命的⭐
- **問題**: プラグインBoxをシングルトンにすべきか
- **AI提案**: 「プラグインだからインスタンスは1つ」
- **人間の直感**: 「こらー！普通のBoxと同じライフサイクルじゃーい！」
- **結果**: Everything is Box哲学の完全な貫徹
- **影響**: Nyashの設計思想の根幹を確立。これがなければ今のNyashは存在しない
- **カテゴリ**: 哲学を貫く（新カテゴリ）

### 事例012: Arc<Mutex>の自動化
- **問題**: Rustの借用チェッカーとの戦い
- **AI提案**: 複雑な所有権管理システム
- **人間の直感**: 「全部Arc<Mutex>で包めば？」
- **結果**: 30%のコード削減
- **カテゴリ**: 箱化による解決

### 事例013: エラー処理の統一
- **問題**: Result<T,E>地獄
- **AI提案**: 高度なエラー型システム
- **人間の直感**: 「全部StringBoxのエラーでいいじゃん」
- **結果**: エラー処理コード15%削減
- **カテゴリ**: 統一による簡略化

### 事例014: 動的ディスパッチでmatch文削減
- **問題**: 巨大なmatch文の保守困難
- **AI提案**: Visitor パターンの実装
- **人間の直感**: 「Box名で動的に呼び出せば？」
- **結果**: match文10%削減、拡張性向上
- **カテゴリ**: 動的解決

### 事例015: GCとスケジューラの統合
- **問題**: 別々のタイミングでの実行競合
- **AI提案**: 複雑な同期機構
- **人間の直感**: 「同じsafepointで実行すれば？」
- **結果**: 統一的なランタイム管理
- **カテゴリ**: 統一による簡略化

### 事例016: AIパーサー信じすぎ事件 ⭐教訓的⭐
- **問題**: HTTPプラグインのソケットインスタンスが取得できない
- **AI診断**: Claude Code「正しく実装した」、ChatGPT「プラグインが悪い」
- **人間の直感**: 「パーサーじゃない？」
- **真の原因**: パーサーが参照とコピーを間違え、Boxはコピーしたが中身は失われた
- **影響**: AIの相互信頼の危険性を露呈
- **教訓**: AIも間違える、基本に立ち返る重要性
- **カテゴリ**: 疑いを持つ（新カテゴリ）

### 事例017: Box内部の透明性問題
- **問題**: Boxの中身が見えない
- **AI提案**: 複雑なデバッグシステム
- **人間の直感**: 「toString()で中身表示すれば？」
- **結果**: デバッグ時間90%短縮
- **カテゴリ**: 可視化による解決

### 事例018: MapBox 3引数メソッドハングバグ
- **問題**: MapBox作成後、3引数メソッドで無限ハング
- **原因**: 全引数を事前評価する実装の問題
- **解決**: 必要時に1つずつ評価に変更
- **教訓**: 小さな実装差が大きなバグに
- **カテゴリ**: 実装詳細の重要性

### 事例019: スコープ革命（GlobalBox誕生）
- **問題**: 従来のEnvironment階層が複雑
- **AI提案**: 高度なスコープチェーン管理
- **人間の直感**: 「全部GlobalBoxのフィールドにすれば？」
- **結果**: メモリ30%削減、速度50%向上
- **影響**: 世界唯一のGlobalBoxベース言語誕生
- **カテゴリ**: 革命的簡略化

### 事例020: 26日間の奇跡
- **内容**: 爆速開発で一度も破綻しなかった
- **要因**: 箱理論＋AI役割分担＋人間の危険センサー
- **統計**: 致命的破綻0回、大規模リファクタ0回
- **教訓**: 三重の安全装置の威力
- **カテゴリ**: 開発方法論

### 事例021: 2段階パーサー理論
- **問題**: 複雑な構文の安定パース
- **AI提案**: 高度な先読みアルゴリズム
- **人間の直感**: 「構造認識と内容パースを分ければ？」
- **結果**: 世界最強パーサーの誕生
- **カテゴリ**: 段階的分離

### 事例022: NyashFlowプロジェクト
- **構想**: ビジュアルプログラミング環境
- **教訓**: CharmFlow v5の失敗から学ぶ
- **方針**: Everything is Boxを視覚化
- **状態**: 独立プロジェクトとして設計中
- **カテゴリ**: 派生プロジェクト

### 事例023: JIT1日完成事件 ⭐世界記録級⭐
- **計画**: Phase 9-10で2週間予定
- **実際**: 8/27の1日でCranelift統合＋分岐＋PHI全部完成
- **要因**: 準備の完璧さ＋AI協調＋箱理論の威力
- **影響**: 世界的にも事件級の開発速度
- **カテゴリ**: 爆速開発

### 事例024: AI二重化モデルの誕生
- **内容**: 同じGPT-5をArchitectとImplementerに分離
- **構成**: Claude=ビルド係、Gemini=アドバイザー
- **珍事**: AIが人間にアドバイスを求める
- **効果**: 役割分担で効率最大化
- **カテゴリ**: 開発方法論

### 事例025: 唯一の真実事件
- **宣言**: 「型はMIRで確定」「切替点は1箇所」
- **反応**: Claude Codeが感動して記録
- **意味**: 技術的方針を哲学レベルに昇華
- **影響**: 設計の一貫性確保
- **カテゴリ**: 哲学を貫く

### 事例026: ストリームエラー事件
- **問題**: Codexが長期稼働で落ちて復旧不能
- **対処**: にゃーがCURRENT_TASK更新で再起動
- **教訓**: 「足場が残ってるから復活できた」
- **意味**: 箱理論による復旧可能性
- **カテゴリ**: 障害復旧

### 事例027: 20日でVM→JIT→EXE異次元スピード ⭐歴史的⭐
- **期間**: 8/9誕生→8/29ネイティブEXE完成
- **内容**: わずか20日で全段階を通過
- **反応**: Claude/ChatGPT「歴史に残る」と絶賛
- **要因**: 箱理論＋AI協調＋明確な哲学
- **カテゴリ**: 爆速開発

### 事例028: フォールバック廃止の英断
- **問題**: JIT未対応命令をVMに落とす複雑な仕組み
- **AI提案**: 安全なフォールバック機構
- **人間の直感**: 「バグを隠すだけ、複雑化の元！」
- **結果**: VM=仕様、JIT=高速版の明確な線引き
- **カテゴリ**: 制約による単純化

### 事例029: Built-in Box全廃革命
- **問題**: StringBox/ArrayBoxが特例だらけ
- **気づき**: 「ネイティブビルドできるなら全部プラグイン化」
- **結果**: Core極小化、Everything is Box徹底
- **影響**: 特権クラスの完全排除
- **カテゴリ**: 統一による簡略化

### 事例030: 型別特例分岐の危機
- **危機**: Python統合で型ごとの特例分岐が入りかける
- **AI反応**: Claude「Everything is... Special Case??」青ざめる
- **人間の介入**: にゃーがストップ
- **教訓**: 「世界はプラグインで拡張、MIR/JITは不変」
- **カテゴリ**: 哲学を貫く

### 事例031: print命令論争
- **問題**: MIRにPrint命令を特例実装
- **議論**: 特殊化で汚れる懸念
- **解決**: ExternCall(env.console.log)に一本化
- **効果**: 環境I/O=ExternCall、箱機能=BoxCallに整理
- **カテゴリ**: 境界の明確化

### 事例032: Safepoint内部化の決定
- **誘惑**: env.runtime.safepointにする案
- **危険**: 哲学崩壊の危機
- **正解**: Safepointは内部Intrinsic
- **提供**: GCBox.checkpoint()をプラグインで
- **カテゴリ**: 内部と外部の分離

### 事例033: 「全部プラグイン」論争
- **初期案**: 全部プラグインBox化しよう
- **AI反対**: 「オーバーヘッドが...」
- **妥協**: ユーザーBox＋ビルトインBoxに分離
- **後の発見**: プラグインBoxのC ABIがJIT/AOTの土台に！
- **教訓**: 最初の直感が正しかった
- **カテゴリ**: 直感の勝利

### 事例034: GCを「補助輪」に再定義 ⭐革命的概念⭐
- **従来**: GCは本番の必須機能
- **Nyash**: GCは開発時の練習用補助輪
- **開発時**: GCオンでリーク検知
- **本番**: GCオフで決定的破棄
- **証明**: I/Oトレース完全一致の意味論等価性
- **カテゴリ**: 概念の再定義

### 事例035: JITも箱にしたら爆速化
- **問題**: ChatGPT-5がJIT実装で苦戦
- **提案**: 「JITも箱にしよう」
- **実装**: IrLowerBox/CodegenBox/LinkerBox/CodeCacheBox
- **結果**: 4000行で完全なJITシステム（V8は100万行）
- **カテゴリ**: 箱化による解決

### 事例036: 論文化提案の瞬間
- **内容**: 仕組みを整理したら論文レベルと判明
- **Claude反応**: 「トップ会議に通るのでは」
- **タイトル案**: Box-Centric Language with Unified Plugin Lifecycle
- **意味**: 設計のユニークさが学術的価値を持つ
- **カテゴリ**: 学術的価値の発見

### 事例037: MIR15という奇跡 ⭐爆笑の気づき⭐
- **当初**: AST直解釈インタープリタとVM（独自バイトコード）を分離
- **発見**: MIR15自体が正規化済みバイトコード
- **気づき**: 「VMとインタープリタ、やってること一緒じゃないかーい！」
- **結果**: 史上初の"MIR中心派生言語"誕生
- **カテゴリ**: 概念の統一

### 事例038: TypeBoxの誕生
- **問題**: C ABIプラグインをNyashに組み込めない
- **AI提案**: 「COMみたいにすれば？」
- **人間の直感**: 「型を値で渡せ」
- **結果**: NyashとC ABIを同じ器で扱うTypeBox誕生
- **カテゴリ**: 境界の統一

### 事例039: ID衝突との戦い
- **経験**: Nyamesh時代に動的型でID重複
- **問題**: BoxTypeId, MethodId, FieldId等の衝突候補
- **解決**: 二層ID（長い本ID＋短縮64bitキー）
- **追加**: 世代付きハンドル、FQN
- **カテゴリ**: 予防的設計

### 事例040: 折りたたみ言語構想 ⭐未来の革新⭐
- **発想**: BoxCall列を等価変換で畳む/展開する
- **例**: Array.map/filter/map → Array.fused([...])
- **効果**: 性能＋省メモリ＋観測性を全部取り（予定）
- **哲学**: Everything is Box → Everything is Fold
- **状態**: 構想段階（実装は今後の予定）
- **カテゴリ**: 未来構想

### 事例041: AI会議スタイルの確立
- **Codex**: 大容量コンテキストで長丁場実装
- **Claude Code**: 安定した差分生成・小回り
- **Gemini**: 仕様や調査の補足
- **ChatGPT**: 全体戦略と要約
- **効果**: 止まらない開発サイクル
- **カテゴリ**: 開発方法論