# Current Task — JoinIR / PHI 削減スナップショット + Ring0/FileBox I/O パイプライン（2025-12-03 時点）

> このファイルは「今どこまで終わっていて、次に何をやるか」を把握するためのスナップショットだよ。
> 過去の詳細ログは `docs/private/roadmap2/CURRENT_TASK_2025-11-29_full.md` や各 Phase の README/TASKS を見てね。

---

## Ring0/FileBox I/O ライン - Phase 106-112 完全完成！ ✅ 2025-12-03

### 📦 Phase 106-112 完了サマリ

| Phase | 実装内容 | 状態 | 詳細 |
|-------|--------|------|------|
| **106** | provider_lock 整理・Fail-Fast 強化 | ✅ | CoreBoxId に責務一本化、MissingService チェック |
| **107** | Ring0.FsApi ↔ FileIo Bridge | ✅ | Ring0FsFileIo 実装、UTF-8 テキスト I/O パイプライン |
| **108** | FileBox write/write_all 実装 | ✅ | truncate mode（毎回上書き）、13 テスト PASS |
| **109** | RuntimeProfile 機構（Default/NoFs） | ✅ | 条件付き core_required、プロファイル対応完備 |
| **110** | FileHandleBox（ハンドルベース複数回アクセス） | ✅ | open/read/write/close ライフサイクル、7 テスト PASS |
| **110.5** | コード改善（优先度1-4） | ✅ | 8 unit + 4 integration テスト追加、エラー SSOT 確立 |
| **111** | append モード + metadata 拡張 | ✅ | "a" mode サポート、size/exists/is_file/is_dir、4 テスト PASS |
| **112** | Ring0 Service Registry 統一化 | ✅ | Ring0Registry factory pattern、NoFsApi 実装、拡張基盤完備 |
| **113** | FileHandleBox Nyash 公開 API | ✅ | ny_* メソッド公開、BoxFactory 登録、6 unit + 1 .hako テスト PASS |

### 🏗️ 設計の完成度

**Ring0 → Ring1 → Language の 3 層パイプライン完全実装**:

```
【Ring0 レイヤー】FsApi trait（read/write/append/metadata/exists）
        ↓
【Ring0.std_impls】std::fs 経由での実装
        ↓
【Ring1 FileIo】FileIo trait（open/read/write/close + mode 切り替え）
        ↓
【Ring1 Ring0FsFileIo】FsApi をラップ、mode ベースの truncate/append
        ↓
【Language】FileBox（ワンショット）+ FileHandleBox（複数回アクセス）
        ↓
【Profile】Default（全機能）/ NoFs（disabled）
```

### 📊 統計

- **総コミット数**: 8 commits (52c13e65 ~ Phase 113)
- **修正ファイル数**: 39 ファイル
- **コード行数**: +1,560 insertions, -150 deletions（設計 + 実装 + テスト）
- **テスト統計**: 39 テスト全 PASS（Unit + Integration + .hako）
- **ドキュメント**: 7 つの詳細指示書 + docs 更新（Phase 113 含む）

### 🚀 次フェーズ予定（Ring0/File I/O ラインは第1章クローズ）

- ~~**Phase 113**: FileHandleBox NyashBox 公開 API（.hako 側からの呼び出し）~~ ✅ 完了（2025-12-04）
- ~~**Phase 114**: FileIo 機能拡張（exists/stat/canonicalize）~~ ✅ 完了（2025-12-04）
- ~~**Phase 115**: FileHandleBox 箱化・モジュール化~~ ✅ 完了（2025-12-04）
- **Phase 116+**: Ring0 まわりは「バグ or 明確な必要が出たら叩く」モードに移行（並行アクセス・encoding・追加プロファイル等は Backlog に退避）

---

## Phase 115: FileHandleBox 箱化・モジュール化

**実装日**: 2025-12-04
**統計**:
- ny_* メソッド: 52行 → 8行（マクロ化で85%削減）
- テストヘルパー: handle_box.rs から外出し（tests/common/file_box_helpers.rs）
- コード行数: +112行, -62行（実質+50行でマクロ・ヘルパー・ドキュメント追加）
  - handle_box.rs: +72行, -62行（マクロ定義+ドキュメント追加）
  - tests/common/: +40行（新規ファイル2つ）

**効果**:
- ny_* メソッドの重複パターンをマクロで一元管理
- テスト共有化で保守性向上（tests/common/file_box_helpers.rs）
- 実装の意図がより明確に（Phase 115 コメント追加）
- 全27テスト PASS（0 failed, 1 ignored）

**修正ファイル**:
- `tests/common/file_box_helpers.rs`: 新規作成（+39行）
- `tests/common/mod.rs`: 新規作成（+1行）
- `src/boxes/file/handle_box.rs`: マクロ化・ドキュメント更新（+72行, -62行）

**実装詳細**:
1. **テストヘルパー外出し**: `setup_test_file`, `cleanup_test_file`, `init_test_provider` を tests/common/file_box_helpers.rs に移動
2. **ny_* メソッド統一化**: 4つのマクロ（ny_wrap_void, ny_wrap_string, ny_wrap_bool, ny_wrap_integer）で8メソッドを統一
3. **ドキュメント追加**: Phase 115 の Code Organization セクション追加

**技術的工夫**:
- マクロの `$display_name` パラメータで柔軟なエラーメッセージ生成（"write_all" → "write"）
- `#[allow(unused_mut)]` で &mut self パラメータの警告抑制
- `stringify!()` と `trim_start_matches("ny_")` でメソッド名の自動生成

---

## 0. 現在地ざっくり（JoinIR / selfhost ライン）

- **✅ JoinIR ラインは Phase 68 で一旦 Chapter Close！**
  - Phase 27-67 で JoinIR の「第1章（構造 + PHI + 型ヒント SSOT）」が完了。
  - 4つの柱（Structure / Scope / JoinIR / Type Hints）が確立。
  - Trio 削除ライン（Phase 70 完了）を経て、wasm/Web デモラインと最適化ラインに分岐。
  - 詳細: [phase-30-final-joinir-world/README.md](docs/private/roadmap2/phases/phase-30-final-joinir-world/README.md)

- **最終ゴール**
  - 制御構造と PHI の意味論は **JoinIR（＋LoopScopeShape/IfPhiContext 等の薄い箱）** に一本化する。
  - 実行の SSOT は VM / LLVM ラインとし、JoinIR→MIR→VM/LLVM は「構造 SSOT → 実行 SSOT」への変換として扱う。
  - 既存の PHI 箱（if_phi.rs / PhiBuilderBox / conservative.rs / Trio 等）は、JoinIR 側のカバレッジが十分になったところから順に削っていく。
- Stage-3 parser デフォルトON化（Phase 30.1 完了）: `config::env::parser_stage3_enabled()` で NYASH_FEATURES=stage3 をSSOT化し、legacy env は明示OFF専用の互換に縮退。
- JoinIR Strict 着手（Phase 81）: `NYASH_JOINIR_STRICT=1` で代表パスのフォールバックを禁止（JoinIR失敗は即エラー）。dev/trace は観測のみ継続。

- **これから（Phase 12x〜 JoinIR 第2章）**
  - wasm/Web デモライン: JoinIR ベースの軽量デモ実装（必要になったときに再開）。
  - 最適化ライン: JoinIR の最適化パスと LLVM/ny-llvmc 統合（Phase 12x+ 候補）。
  - Trio 削除ライン: 完了（Phase 70、LoopScopeShape SSOT）
  - JoinIR Strict ライン（Phase 81）: 代表 If/Loop/VM ブリッジについては `NYASH_JOINIR_STRICT=1` で常に JoinIR 経路のみを通すようにし、レガシー if_phi / LoopBuilder / 旧 MIR Builder は「未対応関数専用」に縮退。
  - **selfhost/hack_check ライン**: Stage‑3 selfhost 代表パスと `hako_check` を JoinIR Strict 経由で安定させ、「言語としての完成パス」を 1 本にする。

---

## 1. JoinIR 第1章完了までの道のり（Phase 33–67 簡潔版）

### Phase 33-62: 構造 + PHI + スコープの基盤構築 ✅ 完了

- **Phase 33-34**: IfSelect/IfMerge lowering 実装、AST→JoinIR Frontend 設計・実装（If/Loop/Break/Continue）
- **Phase 35-36**: PHI 箱削減 HIGH/MEDIUM（537行削減: if_body_local_merge / phi_invariants / LoopSnapshotMergeBox 縮退）
- **Phase 37-40**: If 側 PHI Level 1/2（設計＋array_ext.filter 移行、collect_assigned_vars 削除）
- **Phase 41-46**: If 側 PHI Level 3（NestedIfMerge、read_quoted_from、IfMerge 拡張）
- **Phase 49-56**: JoinIR Frontend 本線統合（print_tokens / filter）
- **Phase 57-62**: If 側 PHI 本体削減（conservative.rs 縮退、If Handler 箱化、PHI Core Cleanup）

**詳細**: 各 Phase の README を参照（`docs/private/roadmap2/phases/phase-*/README.md`）

---

### Phase 63-67: 型ヒントライン完全実装 ✅ 完了（2025-11-30）

#### Phase 63-3: JoinIR 型ヒント最小配線
- `JoinInst::Select` と `MergePair` に `type_hint: Option<MirType>` 追加
- 13ファイル更新、全 JoinIR テスト PASS

#### Phase 63-4: infer_type_from_phi 縮退設計
- 型ヒント優先＋従来ロジックフォールバック仕様を docs 化
- 削除条件 5/5 を定義（P1: IfSelectTest, P2: read_quoted/IfMerge, P3: Method/Box）

#### Phase 63-5: infer_type_from_phi 縮退実装
- `infer_type_from_phi_with_hint()` 実装（+44行）
- lifecycle.rs で呼び出し経路統一
- 削除条件達成率: 3/5（60%）

#### Phase 63-6: P1 ケース型ヒント完全実装
- `MirInstruction::Phi` に `type_hint` 追加（21ファイル修正）
- JoinIR→MIR Bridge で型ヒント伝播実装
- P1 ケース（IfSelectTest.*）で JoinIR 型ヒントのみで型決定
- 削除条件達成率: 4/5（80%）

#### Phase 64: P2 型ヒント拡大
- P2 ケース（read_quoted_from, IfMerge）型ヒント実装
- `is_type_hint_target()` 箱化（TypeHintPolicy 萌芽）
- 削除条件達成率: 4.5/5（90%）

#### Phase 65: P3-A/B 型ヒント実装
- P3-A: `type_inference.rs` 新設、`JoinInst::MethodCall` に型ヒント（StringBox メソッド）
- P3-B: `JoinInst::NewBox` に型ヒント（Box コンストラクタ）
- 代表ケースベースで削除条件 5/5 達成

#### Phase 66: P3-C ジェネリック型推論箱化
- `generic_type_resolver.rs` 新設（180行）
- `TypeHintPolicy::is_p3c_target()` 追加
- ArrayBox.get / MapBox.get 等のジェネリック型推論基盤確立

#### Phase 67: P3-C 実利用への一歩
- `phase67_generic_type_resolver.rs` テスト追加（3テスト全 PASS）
- lifecycle.rs に P3-C 経路フック追加（GenericTypeResolver 優先使用）
- A/B テストで旧経路との一致確認（11 tests PASS）

**技術的成果**:
- JoinIR が構造 + PHI + 型ヒントの SSOT として確立
- infer_type_from_phi は P3-C フォールバック専用に縮退
- 4つの柱（Structure / Scope / JoinIR / Type Hints）完成

### Phase 69: MIR 決定性 & Trio 経路の整理 ✅ 一部完了（2025-11-30）

- 目的: LoopSnapshotMergeBox / LoopForm 周辺の Inspector/Trio 依存を整理しつつ、MIR の predecessor 順を決定的にしてフラッキーテストを解消する。
- 実績:
  - 69-1: LoopSnapshotMergeBox と Trio 経路の現状を確認し、merge_exit_with_classification が LocalScopeInspectorBox を引き回しているだけであり、情報自体は LoopScopeShape/ExitAnalysis 側に揃っていることを整理。
  - 69-2: `merge_exit_with_classification` から Inspector 引数を削除し、LoopScopeShape/ExitAnalysis 経由で必要な情報を取る形に縮退（約 42 行削減）。既存の 3 テストはすべて PASS。
  - 69-3: `BasicBlock.predecessors` を `HashSet` → `BTreeSet` に変更するなど、MIR の predecessor イテレーションを決定的にし、これまで非決定性でフラッキーだった 2 つのループ系テストを安定化。loopform 14/14 / merge_exit 3/3 を含む関連テストはすべて PASS。
- 未了:
  - 69-5: conservative.rs の docs/ 移設も今後の小フェーズとして残しておく。
- 追加完了 (Phase 70):
  - 69-4: Trio 3 箱（LoopVarClassBox / LoopExitLivenessBox / LocalScopeInspectorBox）を削除し、LoopScopeShape を SSOT とする構成に移行。2025-12-01 時点でコードベース再スキャン済みで、Trio 本体ファイルおよび Trio Box 直接参照は **src/mir/** から完全に除去されていることを確認（名称としての「Trio」は docs の歴史メモ内にのみ残存）。

## 2. 次の一手（Phase 69+）

### 直近の候補タスク

- **P3-C 拡大 / If PHI 本体削除**（Phase 70+ 候補）
  - GenericTypeResolver 経由で全 P3-C ケースをカバー
  - `infer_type_from_phi` 本体削除と if_phi.rs 大掃除

- **Phase 71: Self‑Hosting 再ブートストラップ（初回観測完了！ 2025-12-02）** ✅
  - `docs/private/roadmap2/phases/phase-71-selfhost-reboot/README.md` で代表パス 1 本（Stage‑3 + JoinIR 前提）と ENV 方針を整理済み。
  - 代表パス（確定）: `NYASH_FEATURES=stage3 NYASH_USE_NY_COMPILER=1 NYASH_NY_COMPILER_EMIT_ONLY=1 NYASH_SELFHOST_KEEP_RAW=1 ./tools/selfhost/selfhost_build.sh --in apps/tests/stage1_run_min.hako --run`
  - **Phase 71初回実行成果 (2025-12-02)**:
    - ✅ Phase 70完了直後にPhase 71代表パス実行成功
    - ✅ RAW観測レイヤ活用成功 (`logs/selfhost/stageb_20251202_101623_2665649.log` 707K)
    - ✅ 根本原因特定: **SSA undef (4件)** + **dev verify (1件)** が Program JSON emit失敗を引き起こしている
    - ✅ JoinIR/プラグイン初期化は **問題なし** (JoinIR経路正常動作、プラグイン成功確認)
  - **SSA undef詳細 (初回観測時)**:
    1. `ParserCommonUtilsBox.trim/1` - ValueId(272)未定義
    2. `ParserBox.trim/1` - ValueId(272)未定義
    3. `Main._parse_number/1` - ValueId(12)未定義
    4. `ParserBox.parse_block2/2` - ValueId(440)未定義  
    → Phase 71-SSA での `.hako` 側整理により、現在はいずれも解消済み（SSA undef 13件→0件）。
  - **dev verify警告 (初回観測時)**: `StageBDriverBox` NewBox直後にbirth()未呼び出し  
    → StageBDriverBox が static box であることを考慮し、lifecycle.rs 側の特例で警告は解消済み。
  - **完了判定基準**: 観測窓としてのPhase 71は完了。代表 selfhost パスで JSON v0 emit→VM 実行（出力 `abc`）まで通ることを確認済みで、  
    SSA 修正は今後 Stage‑B 他ケースと s3/parity 系にフォーカスする。
  - **詳細レポート**: `docs/development/current/main/phase71-findings-20251202.md` と Phase 71-SSA 追加レポート
  - quick プロファイルでは JoinIR/VM 系は緑維持を目標としつつ、selfhost_minimal / stageb_min_emit は「SSA ラインの観測窓」として赤許容。Stage‑B/SSA 起因の赤は Phase 71-SSA 側でハンドルする。

- **Phase 72: JoinIR dev フラグ棚卸し** ✅
  - `config::env::joinir_core_enabled()` / `joinir_dev_enabled()` を追加し、Core/DevOnly/Deprecated の区分を整理。
  - `NYASH_JOINIR_EXPERIMENT` や `HAKO_JOINIR_IF_SELECT` を含む JoinIR 関連フラグの読み書きを、  
    `src/config/env/joinir_dev.rs` / `src/tests/helpers/joinir_env.rs` 経由の SSOT に統一（本体コードからの `std::env` 直読みを排除）。
  - docs/private/roadmap2/phases/phase-72-joinir-dev-flags/README.md に一覧表と実装状況メモを追加済み。

- **Phase 73: ENV 整理・不要フラグ削除（JoinIR＋Stage‑3 周辺）**
  - docs/private/roadmap2/phases/phase-73-env-cleanup/README.md に Stage‑3 / JoinIR / その他 ENV の棚卸しと Dead/Alias/Keep の分類方針を追加
  - 実コードからは `parser_stage3_enabled()` / `joinir_core_enabled()` / `joinir_dev_enabled()` 経由で判定し、legacy/env 名は Alias-only 扱いとして段階的に削除候補へ寄せていく
  - Stage‑3 旧 ENV は tools/selfhost/hako_check + JoinIR/LoopForm/PHI テスト + Stage‑1/SSA 代表テスト（Batch‑C）からは排除済みで、残りは dev/perf 用や一部 SSA/Stage‑B 系テストと docs の歴史メモに限定されている（Phase 73‑11 で現状を棚卸し済み）

- **Phase 73-7: Stage‑3 旧 ENV の縮退**
  - tools/selfhost/hako_check から `NYASH_PARSER_STAGE3` / `HAKO_PARSER_STAGE3` を順次削除し、Stage‑3 gate を `NYASH_FEATURES=stage3` ベースに移行開始
  - Rust tests 側の Stage‑3 alias は次フェーズでグループごとに `NYASH_FEATURES=stage3` へ寄せる予定

- **Phase 73-8: Rust tests Batch‑A の Stage‑3 ENV 縮退**
  - JoinIR/PHI 周辺の代表テスト（mir_loopform_* / mir_joinir_* の一部）を対象に、`NYASH_PARSER_STAGE3` / `HAKO_PARSER_STAGE3` を `NYASH_FEATURES=stage3` に置き換え開始

- **Phase 73-9: Rust tests Batch‑B の Stage‑3 ENV 縮退**
  - 残りの JoinIR 系テスト（joinir_runner_min / mir_joinir_* / joinir_json_min / joinir_vm_bridge_* / joinir/mainline_phase49）についても、Stage‑3 旧 ENV を廃止し `NYASH_FEATURES=stage3` ベースに統一

- **wasm/Web デモライン**（Phase 71 候補）
  - JoinIR ベースの軽量デモ実装
  - ブラウザで動く最小構成

- **最適化ライン**（Phase 72+ 候補）
  - JoinIR 最適化パス実装
  - LLVM/ny-llvmc 統合強化

### 今後の優先タスク順（selfhost + hack_check 観点の整理）

1. **Phase 71-SSA/selfhost 再ブートストラップの収束**
   - 代表パス（selfhost_build + stage1_run_min.hako）が JSON v0 emit→VM 実行まで通ることは確認済みとし、
     以降は Stage‑B 他ケースと s3/parity 系を「SSA ラインの観測窓」として整理していく。
   - この段階では JoinIR Strict は代表 if/loop/VM ブリッジに限定し、selfhost_minimal/stageb_min_emit の赤は SSA 側の課題として扱う。
2. **Phase 72–73: ENV / JoinIR dev フラグの集約完了** ✅
   - `joinir_core_enabled()` / `joinir_dev_enabled()` / `parser_stage3_enabled()` を SSOT として使い切り、tools/selfhost/hako_check/tests から旧 ENV を整理する。
   - ここまでで「selfhost / hack_check / tests が同じ Stage‑3 + JoinIR/ENV ポリシー上に乗る」状態を目指す。
3. **Phase 80: VM/LLVM 本線の JoinIR 統一** ✅ **完了**（2025-12-02 c61f4bc7）
   - 代表 if/loop の本線化を実装。`joinir_core_enabled()` 時は JoinIR→MIR 経路が既定となり、レガシー経路は JoinIR 未対応ケース専用に縮退。
   - SSOT ヘルパー（`should_try_joinir_mainline()` / `should_panic_on_joinir_failure()`）を実装。
   - **Phase 82**: JOINIR_TARGETS テーブル SSOT 化（93f51e40）完了。
4. **Phase 81: selfhost 用 JoinIR Strict＋fail-fast の確立** ✅ **完了**（2025-12-02 a9e10d2a）
   - selfhost_build.sh に `--core` / `--strict` オプション追加。環境変数 `NYASH_JOINIR_CORE` / `NYASH_JOINIR_STRICT` を子プロセスに自動伝播。
   - 代表パス（skip_ws / trim / resolve / print_tokens / filter / Stage‑1/Stage‑B 代表）が JoinIR 経由でのみ通る Strict モード実装完了。
   - hack_check ラインは引き続き「Stage‑3 + 旧 MIR Builder + VM」の安定ルートとして維持。
5. **Phase 82-if-phi-retire: P3-C 完了＋if_phi.rs 削除ライン** ← **継続中**
   - dev フラグ `NYASH_PHI_FALLBACK_DISABLED=1` で `infer_type_from_phi_with_hint` の呼び出しを fail-fast 検出する経路を追加済み（joinir_dev::phi_fallback_disabled）。
   - `lifecycle.rs` の return 型推論バグ（中間値 `const void` を見てしまう問題）を修正し、Case D を 51 件 → 20 件に削減済み。
   - Phase 83〜84-4 による追加削減で Case D は 0 件となり、`infer_type_from_phi*` への依存は実質的になくなった。コード上の定義削除と `phi_core::if_phi` モジュールの整理は Phase 84-5（if_phi.rs 削除ライン）で実施予定。

6. **Phase 83-typehint-p3d: 既知メソッド戻り値型推論（P3-D）** ✅ **完了**
   - ChatGPT Pro 設計の MethodReturnHintBox を実装（8ae1eabc）。`TypeHintPolicy` → `MethodReturnHintBox` → `TypeAnnotationBox` → `GenericTypeResolver` という箱構造を確立。
   - BoxCall/Call/TypeOp の既知メソッド戻り値型を P3-D として吸収し、Case D を 20 件 → 15 件に削減。
   - 将来の Method Registry 統一時にも差し替えやすい API になっており、型ヒントラインの構造的な整理が完了。

7. **Phase 84-1: Const 命令型アノテーション** ✅ **完了**
   - `src/mir/builder/emission/constant.rs` に Integer/Bool/Float/Null/Void 用の型登録を追加（40dfbc68）。String と同様に `value_types` へ MirType を記録。
   - Case D のうち Const 命令の型欠如が原因だったグループを解消し、Case D は 15 件 → 12 件に縮小。
   - 残り 12 件は Copy/PHI 経由の edge パターン（Loop break/continue / If merge など）に集中しており、Phase 84-2/84-3 の対象として切り出された。

8. **Phase 84-2: CopyTypePropagator による Copy 型伝播** ✅ **完了**
   - `src/mir/phi_core/copy_type_propagator.rs` に CopyTypePropagator 箱を追加し、MIR 関数内の `Copy { dst, src }` を固定点ループで走査して `value_types` に型を伝播。
   - `lifecycle.rs` の return 型推論前に CopyTypePropagator を走らせることで、Copy チェーンだけで説明できる Case D を削減（12 件 → 9 件）。
   - ベースラインテストは 489 passed, 34 failed → 494 passed, 33 failed と改善。残りの Case D は await/try-catch や多段 PHI など PHI 主体のパターンに集中しており、Phase 84-3（PhiTypeResolver）での限定的な PHI 型推論強化に引き継ぎ。

9. **Phase 84-3: PhiTypeResolver による PHI + Copy グラフ推論** ✅ **完了**
   - `src/mir/phi_core/phi_type_resolver.rs` に PhiTypeResolver 箱を追加し、`Copy`/`Phi` グラフを DFS/BFS で辿って末端の base 定義型が 1 種類に揃う場合のみ MirType を返す仕組みを実装。
   - lifecycle.rs の return 型推論フローに統合し、P3-D / Const / CopyTypePropagator で埋まらない一部ケースを吸収することで Case D を 9 件 → 4 件に削減。
   - 残り 4 件（await 構文 / QMark 構文 / Stage1 CLI 2 テスト）は、BoxCall/Await/QMark の戻り値型が `value_types` に未登録なことが原因であり、PhiTypeResolver 自体の限界ではないことが Task 調査で確認された（Phase 84-4 の BoxCall/Await 型登録ラインに引き継ぎ）。

10. **Phase 84-4: BoxCall 戻り値型登録（Await/QMark 含む）** ✅ **完了**
    - `src/mir/builder/utils.rs` に `infer_boxcall_return_type()` ヘルパーを追加し、StringBox/IntegerBox/BoolBox/ArrayBox/MapBox/Result-like（QMark 相当）/Stage1CliBox など計 27 メソッドの戻り値型を一元管理。
    - BoxCall lowering 経路（emit_box_or_plugin_call 相当）から `infer_boxcall_return_type()` を呼び出し、戻り値 ValueId に対応する MirType を `value_types` に登録。
    - Await/QMark 系は BoxCall 経路の型登録で全て解消され、追加の Await 専用実装は不要。
    - `NYASH_PHI_FALLBACK_DISABLED=1 cargo test --release --lib` 実行時の Case D panic は 4 件 → 0 件となり、Case D 完全解消を達成。型生成（Const/BoxCall）・型伝播（CopyTypePropagator/PhiTypeResolver）・統合（GenericTypeResolver）の 3 層構造が箱として完成し、if_phi フォールバック削除に進める状態になった（Phase 84-5 / 82 の最終仕上げ）。

11. **Phase 85-ring0-runtime: Ring0/Ring1/Plugin 層の設計整理** ⏳ **設計中**
    - Ring0 は Box を知らない最小カーネル API（Mem/Io/Time/Log/Fs/Thread 等）に限定し、実装は `Ring0Context` + adapter 1 箇所に集約する方針を docs に固定済み。
    - Ring1-core（StringBox/ArrayBox/MapBox/FileBox/ConsoleBox 等）と ring1-optional/selfhost/user_plugin を 4 層に分類し、「core_required は静的必須セット、optional と user は PluginHost の上に載る」設計を言語化済み。
    - `docs/development/current/main/ring0-inventory.md` に println!/eprintln! や fs/time/thread を含む Ring0 候補呼び出し、Box/プラグイン/カーネル実装数の調査結果をまとめ、Phase 88/90 で代表パスを Ring0Context に移行済み（残りは Phase 99 以降の段階移行対象）。
    - Phase 87–97 で CoreBoxId/CoreMethodId/CoreServices/PluginHost/Adapter/Service API の実装とテストが完了し、Box 名・メソッド名と core_required Box の初期化は `src/runtime/core_box_ids.rs` と `src/runtime/core_services.rs` に集約された。Phase 98 で Console/String/Array/Map の代表パス 7 箇所が CoreServices 経由に切り替わり、今後の ring0/ring1-core 変更はこの SSOT に対してのみ行えばよい状態になっている。
    - **Phase 95.5: Ring0 統合完了**（2025-12-03）
      - ✅ ConsoleService が Ring0Context に直結（println → Ring0Context.log.info, print → Ring0Context.io.stdout_write）
      - ✅ StringService が純粋関数化（Box 状態不要）
      - ✅ #[allow(dead_code)] 削減: 6箇所 → 4箇所（2削減）
      - ✅ ログ経路統一: Ring0 → Ring1-Core → 実行パス
      - **設計原則確立**: Ring0 直結型（ConsoleService）と純粋関数型（StringService）の2パターン
      - **次のステップ**: Phase 96 で ArrayService/MapService 実装（状態管理必要）、代表パス拡大（5-10箇所）
    - **Phase 96: ArrayService/MapService 実装**（2025-12-03）
      - ✅ ArrayService/MapService 実装完了（downcast型パターン）
      - ✅ #[allow(dead_code)] 根絶: 4箇所 → 0箇所（完全削減）
      - ✅ 3つのサービス実装パターン確立（Ring0直結/純粋関数/downcast型）
    - **Phase 97: IntegerService/BoolService 実装**（2025-12-03）
      - ✅ IntegerService/BoolService 実装完了
      - ✅ CoreServices 5種類完成（Console/String/Array/Map/Integer/Bool）
      - ✅ プリミティブ型の完全統合達成
    - **Phase 98: ConsoleService 代表パス拡張**（2025-12-03）
      - ✅ console_println! マクロ導入（Graceful Degradation 実装）
      - ✅ 7箇所で println!/eprintln! → console_println! 移行完了
      - ✅ selfhost/VM 実行経路の代表パスカバー達成
    - **Phase 98.5: Arc 簡略化 & コメント統一**（2025-12-03）
      - ✅ #[allow(clippy::arc_with_non_send_sync)] 削減: 4箇所 → 1箇所
      - ✅ 全 CoreServices に統一コメント追加
      - ✅ コード品質向上（Clippy warnings 削減）
    - **Phase 99: ログ/出力ポリシー確定**（2025-12-03）
      - ✅ logging_policy.md 新規作成（3層分離設計・マクロポリシー・テスト方針を文書化）
      - ✅ ring0-inventory.md 更新（println! 残件分類・Ring0.log 活用計画を記載）
      - ✅ core_boxes_design.md Section 15.6-A 追記（統一設計の補強）
      - ✅ 残り ~1477 箇所の println!/eprintln! を「後工程で片付けられる設計」に整理
      - **設計フェーズのみ**: コード変更なし、docs ベースでポリシー確定
    - **Phase 100: user-facing 出力の CoreServices 化**（2025-12-03）
      - ✅ selfhost.rs: 6箇所 → console_println!（CoreInitError, Result 出力）
      - ✅ llvm.rs: 23箇所 → console_println!（エラー、成功メッセージ、実行結果）
      - ✅ 合計 29箇所完了（Phase 98: 7 + Phase 100: 29 = 36箇所）
      - ✅ cargo build --release 成功、全テスト PASS（core_services: 11, plugin_host: 7）
      - ✅ デバッグログとユーザー向け出力の明確な分離達成
      - **除外**: llvm.rs の `[joinir/llvm]`, `[parse/context]` デバッグログ（Phase 101-A で対応）
      - **次のステップ**: Phase 101-102 で残り ~330箇所の段階的移行
    - **Phase 101-A: dev-debug ログの Ring0.log 統一**（2025-12-03）← NEW
      - ✅ llvm.rs: 13箇所 → Ring0.log（`[joinir/llvm]`, `[parse/context]`）
      - ✅ loop_form.rs: 全 `[loopform]` ログ → Ring0.log
      - ✅ phi_core: 21箇所 → Ring0.log（`[loopform/prepare]`, `[loopform/seal_phis]`, `[Option C]`）
      - ✅ 合計 34箇所完了（llvm: 13 + loop_form: すべて + phi_core: 21）
      - ✅ cargo build --release 成功（警告のみ、エラーなし）
      - ✅ VM実行テスト: loop_min_while.hako 正常動作
      - ✅ Ring0.log で dev-debug ログを一元管理達成
      - **環境変数**: `NYASH_LOOPFORM_DEBUG=1`, `NYASH_OPTION_C_DEBUG=1` で制御
      - **次のステップ**: Phase 101-B/C で残り ~585箇所の段階的移行
    - **Phase 101-B: internal/test ログ整理（Rust 側）**（2025-12-04）
      - ✅ internal/dev println!/eprintln! 113箇所を Ring0.log に移行（provider_lock / plugin_loader_unified / type_meta / deprecations / leak_tracker / provider_verify / scheduler / gc_controller / box_registry / plugin_loader_v2 周辺 / runner trace / mir verifier / mir core basic_block/control_form/hints/effect/printer/optimizer / loop_builder/phi_ops / builder/type_registry / region/observer / extern_functions / plugin types finalize trace / joinir_if_phi_selector / observe/types+resolve / join_ir_vm_bridge_dispatch run_generic / loop_builder/control など）
      - ✅ logging_policy.md / ring0-inventory.md にテスト出力許容ポリシーと残件概算を追記（残 ~475–495）
      - ⏭️ 残り internal/dev ログは Phase 101-C 以降で段階的に処理（user-facing/.hako は別ライン）
    - **Phase 104: .hako側ロギング設計**（2025-12-04）
      - ✅ ConsoleBox適切な使い方ガイド作成
      - ✅ 4つのロギングカテゴリ確立（user-facing/dev-debug/monitoring/internal Rust）
      - ✅ 3つのロギングBoxパターン設計（Lightweight/Structured/Contextual）
      - ✅ hako_logging_design.md 作成、logging_policy.md 更新
      - **スコープ**: .hako アプリケーション側のロギングベストプラクティス確立
    - **Phase 105: Logger Box Framework設計**（2025-12-04）
      - ✅ Logger Box インターフェース設計（ログレベル: DEBUG/INFO/WARN/ERROR）
      - ✅ 3つの設計パターン文書化（Lightweight/Structured/Contextual）
      - ✅ リファレンス実装例作成（pseudo-code、実行テストは Phase 106+）
      - ✅ logger_box_design.md 作成（500+ lines）
      - ✅ logging_policy.md / hako_logging_design.md / ring0-inventory.md にクロスリファレンス追加
      - **スコープ**: 設計＋ドキュメントのみ（Rust実装なし、Phase 106+で実装）
      - **成果**: ConsoleBox基盤の構造化ロギングフレームワーク確立
      - **次のステップ**: Phase 106（FileBox provider_lock & Fail-Fast）、Phase 107（FsApi 統合 or Logger 出力先拡張）
    - **Phase 106: FileBox provider_lock & Fail-Fast**（2025-12-03）
      - ✅ FileBox provider_lock 機構実装（OnceLock ベース）
      - ✅ CoreBoxId.is_core_required() による Fail-Fast チェック
      - ✅ 設計統一（案B）: provider_lock SSOT 化
      - ✅ テスト完了: plugin_host tests 全PASS
    - **Phase 107: FsApi / FileIo 統合**（2025-12-03）
      - ✅ Ring0FsFileIo 実装（Ring0.FsApi 経由の FileIo）
      - ✅ FileBox → Ring0FsFileIo → Ring0.FsApi → std::fs パイプライン確立
      - ✅ 自動登録機構: with_core_from_registry() で Ring0FsFileIo を自動登録
      - ✅ テスト完了: ring0_fs_fileio tests 全PASS
    - **Phase 108: FileBox write/write_all 実装**（2025-12-03）✅ **完了**
      - ✅ FileIo trait に write() メソッド追加
      - ✅ Ring0FsFileIo に write() 実装（truncate mode）
      - ✅ FileBox.write() / write_all() が Ring0.FsApi 経由で動作
      - ✅ FileCaps.write = true（標準プロファイルで書き込み対応）
      - ✅ テスト完了: Round-trip / truncate / read-only provider 拒否 全PASS
      - **設計決定**: write mode は truncate（毎回上書き）、append は Phase 109+
      - **次のステップ**: Phase 109（minimal/no-fs プロファイル）、Phase 110（FileHandleBox）

12. **Phase 86: BoxFactory Priority 正常化** ✅ **完了**（2025-12-02）
    - **目的**: BoxFactory のデフォルトポリシーを `BuiltinFirst` から `StrictPluginFirst` に変更し、プラグイン版 Box が正常に使用できるよう正常化。
    - **実装内容**:
      - ✅ 現状仕様の文書化（`docs/development/current/main/factory_priority.md`）
      - ✅ `UnifiedBoxRegistry::new()` を 1 行修正（`with_policy(BuiltinFirst)` → `with_env_policy()`）
      - ✅ テスト 5 件追加・全パス（default policy / env override / reserved protection / plugin override / non-reserved priority）
      - ✅ Phase 85 README 準備完了（`docs/private/roadmap2/phases/phase-85-ring0-runtime/README.md`）
    - **効果**:
      - プラグイン版 StringBox/ArrayBox/MapBox が正常に使用可能に
      - core_required Box（StringBox/IntegerBox/BoolBox/ArrayBox/MapBox 等）の予約名保護維持
      - 環境変数 `NYASH_BOX_FACTORY_POLICY` による柔軟な制御が可能
      - テスト改善：500 passed, 34 failed → 506 passed, 33 failed（+6 passed, -1 failed）
    - **詳細**: [factory_priority.md](docs/development/current/main/factory_priority.md)

### バックログ

#### ロギングフレームワーク拡張（Phase 106+）

- **Phase 106: Logger Box 出力リダイレクト**
  - Logger Box から FileBox へのログ出力機能実装
  - Logger Box から NetworkBox へのリモートログ送信機能実装
  - Phase 105 で設計した interface 互換性維持

- **Phase 107: アプリケーション移行**
  - hako_check を Logger Box 使用に移行
  - selfhost-compiler を Logger Box 使用に移行
  - Nyash ツール全体のロギング標準化

- **Phase 108+: 高度ロギング機能**
  - 構造化ロギング（JSON format）
  - ログアグリゲーション
  - パフォーマンスメトリクス

#### その他

- Stage‑B/selfhost smokes の扱い整理（Phase 30.1 フォロー）
  - quick プロファイルで `stage1_launcher_*` / `phase251*` 系が Stage‑3 デフォルト環境で不安定。今後、quick では SKIP にするか、Stage‑B emit 抽出ロジックを安定化するかを決める。
  - `MirFunction.blocks: HashMap` → `BTreeMap` で非決定的テスト解消
  - Phase 25.1 同様のパターン適用
  - selfhost Stage‑B 子プロセスへのソース渡し経路の簡素化（`--source "$SRC_CONTENT"` で argv を肥大化させず、HAKO_SRC 環境変数や一時ファイル経由に統一する設計を将来フェーズで検討）。

- Phase 71-SSA: Stage‑B / selfhost ラインは「SSA デバッグ用の観測窓」として切り出し、  
  代表パス（selfhost_build + stage1_run_min.hako）が JSON v0 emit まで通るかどうかを別フェーズで追う。  
  詳細: `docs/private/roadmap2/phases/phase-71-ssa-debug/README.md`

- Phase 81-JoinIR-Strict: JoinIR を「if/loop/PHI の真」として扱い、  
  JoinIR 対象関数では `if_phi` / `LoopBuilder` / 旧 MIR Builder にフォールバックしない Strict モードを導入する。  
  代表 If/Loop（mir_joinir_if_select / mir_stage1_staticcompiler_receiver / mir_joinir_stage1_using_resolver_min）は  
  `NYASH_JOINIR_CORE=1 NYASH_JOINIR_STRICT=1` で全て green を確認済み（Strict で lowering 失敗なし）。  
  代表パス（skip_ws / trim / resolve / print_tokens / filter / read_quoted / Stage‑1/Stage‑B 代表）では、  
  JoinIR lowering / VM ブリッジ失敗を即エラー扱いとし、レガシー経路は「未対応関数専用」に縮退させる。

- Phase 82-if-phi-retire（予定）: P3-C ジェネリック型推論ラインを拡張し、  
  `lifecycle.rs` から `infer_type_from_phi*` 呼び出しを完全に排除する（P3-C まで GenericTypeResolver で食い切る）。  
  あわせて `collect_assigned_vars_via_joinir` を JoinIR/AST 側の分析モジュールに移動し、  
  `phi_core::if_phi` への実コードからの参照をゼロにした上で `if_phi.rs` 本体を削除する（歴史メモは docs 側にのみ保持）。

- Phase 74-SSA-static-delegation（将来フェーズ候補）: Phase 71-SSA で判明した「static box 委譲時に ValueId マッピングが壊れる」  
  Rust MIR ビルダー側の根本バグを正式に修正するライン。  
  現 HEAD では `.hako` 層で ParserBox → ParserStringUtilsBox などの委譲を外すことで SSA undef は 13件→0件に根治しており、  
  最小 .hako ではバグを再現できないため、MIR Builder の修正は **再現用テストを用意できる将来フェーズに委譲**する。  
  当面は「box→static box への薄い委譲メソッドを増やさない」というコーディング規約で安全運用し、  
  Phase 74 では commit 13ce9e68 以前の形を元にした再現用テスト＋MIR Builder 修正＋委譲パターンの復活をまとめて扱う。

---

## 3. 旧フェーズ（過去ログへのポインタ）

古いフェーズの詳細な経緯やログは、以下のドキュメントと  
`docs/private/roadmap2/CURRENT_TASK_2025-11-29_full.md` を見てね。

- Phase 21.7 — Static Box Methodization
  - StaticMethodId / NamingBox で BoxName.method/arity 名前解決の SSOT 化。
  - docs: `docs/development/current/main/phase-21.7-naming-ssot-checklist.md` など。
- Phase 25.x / 26.x — LoopForm v2 / LoopSSA v2 / Exit PHI / ExitLiveness
  - LoopForm v2 / LoopSSA v2 の整備と Exit PHI / ExitLiveness まわりの 4 箱構成。
- Phase 27–32 — JoinIR 初期実験〜汎用化
  - LoopToJoinLowerer / LoopScopeShape / JoinIR VM Bridge を minimal ケースから Stage‑1 / Stage‑B へ広げていくライン。
  - docs: `docs/private/roadmap2/phases/phase-27-joinir*`, `phase-31-looptojoin-lowerer`, `phase-32-joinir-complete-migration` など。

CURRENT_TASK.md 自体は「いまどこを触っているか」と「次に何をやるか」を  
1 画面で把握できる軽さを維持する方針だよ。***

---

## Phase 109: RuntimeProfile 機構実装完了 ✅ (2025-12-03)

### 実装内容

**ゴール**: FileBox を profile 依存の conditional required に変更し、minimal/no-fs プロファイルをサポート

**実装完了項目**:
1. ✅ RuntimeProfile enum + is_required_in() ヘルパー
   - `src/runtime/runtime_profile.rs`: RuntimeProfile::Default/NoFs 定義
   - `src/runtime/core_box_ids.rs`: CoreBoxId.is_required_in(profile) 追加
2. ✅ PluginHost profile-aware 初期化
   - `src/runtime/plugin_host.rs`: profile 引数追加、FileBox provider チェック実装
3. ✅ initialize_runtime() に profile 読み込み機構
   - `src/runtime/mod.rs`: 環境変数読み込み層（責務分離）
4. ✅ NoFsFileIo stub 実装
   - `src/providers/ring1/file/nofs_fileio.rs`: FileBox 無効化スタブ
   - `src/runtime/provider_lock.rs`: init_filebox_provider_for_profile()
5. ✅ ドキュメント更新
   - `phase108_filebox_write_semantics.md`: Section 9 追加
   - `core_boxes_design.md`: Section 5.4 追加

**テスト結果**:
- ✅ test_core_box_id_is_required_in_default
- ✅ test_core_box_id_is_required_in_nofs
- ✅ test_with_core_from_registry_nofs_filebox_optional
- ✅ test_nofs_fileio_caps/open/read/write/close_unsupported (5 tests)
- ✅ cargo build --release: 成功
- ✅ cargo test --release --lib: Phase 109 tests 全 PASS

**設計原則**:
- **責務分離**: initialize_runtime() のみが env を読む、PluginHost は profile を受け取る
- **Fail-Fast 維持**: Default profile では FileBox provider 必須
- **Logger/ConsoleService 有効**: NoFs でも Ring0.log と ConsoleBox は動作
- **互換性保証**: Default profile で Phase 107/108 の動作を完全維持

**将来拡張予定** (Phase 113+):

- TestMock: テスト用にすべての外部 I/O を in‑memory mock に差し替える
- Sandbox: 外部 I/O を禁止（FileBox/NetworkBox 等を一律無効化）
- ReadOnly: FileBox.write を禁止し、read のみ許可
- Embedded: 組み込み用に GC/メモリ制約を強めたプロファイル

**次のタスク候補**:
- ✅ Phase 110: FileHandleBox（複数ファイル同時アクセス） — **完了** (2025-12-03)
- Phase 111: append mode 追加 + FileHandleBox metadata
- Phase 112: Ring0 service registry 統一化

---

## Phase 110: FileHandleBox 実装完了 ✅ (2025-12-03)

### 実装内容

**FileHandleBox（ハンドルベース複数回アクセス I/O）の完全実装**

**ゴール**: FileBox（1ショット I/O）を補完するハンドルベースのファイル I/O を実装

**実装完了項目**:
1. ✅ FileHandleBox struct + NyashBox trait 実装
   - `src/boxes/file/handle_box.rs`: 新規作成（450行）
   - 独立インスタンス設計（各ハンドルが独自の Ring0FsFileIo を保持）
2. ✅ API 実装
   - `new()` - ハンドル作成（ファイル未open）
   - `open(path, mode)` - ファイルを開く（"r" or "w"）
   - `read_to_string()` - ファイル内容読み込み
   - `write_all(content)` - ファイル書き込み
   - `close()` - ファイルを閉じる
   - `is_open()` - open 状態確認
3. ✅ プロファイル対応
   - Default ✅: Ring0FsFileIo 経由で完全なファイル I/O
   - NoFs ❌: open() が即座にエラー
4. ✅ テスト実装（7テスト全PASS）
   - 基本的な書き込み・読み込み
   - 二重 open エラー
   - close 後アクセスエラー
   - read mode で write エラー
   - 複数回書き込み
   - 未サポートモードエラー
   - 独立インスタンス動作確認
5. ✅ ドキュメント更新
   - `core_boxes_design.md`: Section 16 追加
   - `ring0-inventory.md`: Phase 110 完了マーク
   - `phase110_filehandlebox_design.md`: 完全仕様（既存）

**テスト結果**:
- ✅ test_filehandlebox_basic_write_read
- ✅ test_filehandlebox_double_open_error
- ✅ test_filehandlebox_closed_access_error
- ✅ test_filehandlebox_write_wrong_mode
- ✅ test_filehandlebox_multiple_writes
- ✅ test_filehandlebox_unsupported_mode
- ✅ test_filehandlebox_independent_instances
- ✅ cargo build --release: 成功
- ✅ cargo test --release: 7/7 PASS

**設計原則**:
- **Fail-Fast**: 二重 open、close 後アクセス、NoFs profile で即座にエラー
- **独立インスタンス**: 各 FileHandleBox が独自の Ring0FsFileIo を保持（複数ファイル同時アクセス可能）
- **Ring0 再利用**: Ring0FsFileIo を内部で使用（レイヤー統一）
- **後方互換性**: FileBox の既存 API 変更なし

**FileBox との違い**:
- FileBox: 1ショット I/O（read/write 1回ずつ、ファイルを開いて→読む/書く→閉じるを隠す）
- FileHandleBox: 複数回アクセス I/O（open → read/write（複数回可）→ close を明示的に制御）

**実装詳細**:
```rust
// 各 FileHandleBox が独自の Ring0FsFileIo を作成
let ring0 = get_global_ring0();
let io: Arc<dyn FileIo> = Arc::new(Ring0FsFileIo::new(ring0.clone()));

// Write mode の処理
if mode == "w" {
    // ファイルが存在しない場合は空ファイルを作成
    if !ring0.fs.exists(path_obj) {
        ring0.fs.write_all(path_obj, &[])?;
    }
}
```

**将来拡張予定**:
- Phase 111: append mode ("a") サポート
- Phase 112: file metadata / stat（size, mtime 等）
- Phase 113: Ring0 service registry 統一化
- Phase 114: 並行アクセス安全性（Arc<Mutex<...>>）
- Phase 115: file encoding explicit 指定（UTF-8 以外）

**関連ドキュメント**:
- [Phase 110 設計書](docs/development/current/main/phase110_filehandlebox_design.md)
- [Core Boxes Design](docs/development/current/main/core_boxes_design.md#section-16-phase-110---filehandlebox)
- [Ring0 Inventory](docs/development/current/main/ring0-inventory.md)

**次のタスク候補**:
- Phase 111: FileHandleBox append mode 追加 + metadata サポート
- Phase 112: Ring0 service registry 統一化
- Phase 113: FileIo trait 拡張（exists/stat/canonicalize）