chore: Phase 25.1 完了 - LoopForm v2/Stage1 CLI/環境変数削減 + Phase 26-D からの変更

Phase 25.1 完了成果:
- ✅ LoopForm v2 テスト・ドキュメント・コメント完備
  - 4ケース（A/B/C/D）完全テストカバレッジ
  - 最小再現ケース作成（SSAバグ調査用）
  - SSOT文書作成（loopform_ssot.md）
  - 全ソースに [LoopForm] コメントタグ追加

- ✅ Stage-1 CLI デバッグ環境構築
  - stage1_cli.hako 実装
  - stage1_bridge.rs ブリッジ実装
  - デバッグツール作成（stage1_debug.sh/stage1_minimal.sh）
  - アーキテクチャ改善提案文書

- ✅ 環境変数削減計画策定
  - 25変数の完全調査・分類
  - 6段階削減ロードマップ（25→5、80%削減）
  - 即時削除可能変数特定（NYASH_CONFIG/NYASH_DEBUG）

Phase 26-D からの累積変更:
- PHI実装改善（ExitPhiBuilder/HeaderPhiBuilder等）
- MIRビルダーリファクタリング
- 型伝播・最適化パス改善
- その他約300ファイルの累積変更

🎯 技術的成果:
- SSAバグ根本原因特定（条件分岐内loop変数変更）
- Region+next_iパターン適用完了（UsingCollectorBox等）
- LoopFormパターン文書化・テスト化完了
- セルフホスティング基盤強化

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: ChatGPT <noreply@openai.com>
Co-Authored-By: Task Assistant <task@anthropic.com>

docs/development/roadmap/phases/phase-25.1/README.md

@@ -43,9 +43,9 @@ Status: design+partial implementation（Stage1 ビルド導線の初期版まで
 - Rust VM/LLVM のコア（MIR インタプリタ／コード生成）の提供。
 - Stage1 で AOT されたコア関数（後述）を呼び出すランチャ。
 
-**禁止/抑制:**
-- パーサ高レイヤ／Stage‑B／MirBuilder／AotPrep／numeric core のロジックを Rust 側に新規追加しない。
-- 新しい Box 実装やランタイム機能を Rust に持ち込まない（Phase 25 Rust Freeze を継続）。
+**禁止/抑制（緩和版）:**
+- パーサ高レイヤ／Stage‑B／MirBuilder／AotPrep／numeric core の**意味論そのもの**を Rust 側に新規実装しない（Self‑Host の責務）。
+- 新しい Box 実装や高レベルランタイム機能を Rust に持ち込むのは原則避ける（ただし Stage‑1 ブリッジやエラーログ改善など、導線・可観測性に必要な最小限の変更は許可）。
 
 ### Stage1 — Hakorune Selfhost Binary
 
@@ -157,6 +157,11 @@ Status: design+partial implementation（Stage1 ビルド導線の初期版まで
 - [ ] Stage0→Stage1→Stage1' のビルドシーケンスを文章で定義（どの組み合わせで自己一致チェックを行うか）。
 - [ ] 「普段使うのは Stage1」「問題発生時に Stage0 から再生成」という運用パターンを docs に記載。
 
+### E. Stage‑1 UsingResolver / LoopForm v2 対応（設計）
+
+- [x] 設計ドラフトを追加（`stage1-usingresolver-loopform.md`）。Region+next_i 形ループと Carrier/Pinned 対応の指針を明文化。
+- [x] Rust 側の観測結果を反映し、具体的なリライト手順とテスト項目を更新する（JSON→LoopForm v2 導線／Stage‑B→Stage‑1 データフローのテキスト図を追記）。
+
 ## 実装チェックリスト（25.1 実行順案）
 
 ### 1. バイナリ命名と役割の明確化

docs/development/roadmap/phases/phase-25.1/stage1-usingresolver-loopform.md

@@ -112,6 +112,7 @@ source -> | Stage-B (block) |  -->  | Stage-1 UsingRes |  -->  | MirBuilder (.ha
 ### ループ洗い出しメモ（entry / pipeline_v2）
 - entry UsingResolver（lang/src/compiler/entry/using_resolver_box.hako）
   - Region+next_i 化済み: entries イテレーション / JSON スキャン / modules_list 分割
+  - 追加テスト: modules_list 分割ループ（start/next_start）をそのまま MIR 化できることを `mir_stage1_using_resolver_module_map_regionized_verifies` で固定。
   - 残り: なし（現状の 3 ループは all Region 形）
 - pipeline_v2 UsingResolver（lang/src/compiler/pipeline_v2/using_resolver_box.hako）
   - 役割: modules_json 上で alias を解決する stateful helper（テキスト収集は entry 側）。

docs/development/roadmap/phases/phase-25.3-funcscanner/README.md

@@ -1,5 +1,7 @@
 # Phase 25.3 — FuncScanner / Stage‑B defs 安定化
 
+Status: 完了（Stage‑B fib defs canary 緑／2025-11 時点）
+
 ## スコープ / ゴール
 
 - 対象レイヤ
@@ -22,6 +24,30 @@
   - Loop/PHI の意味論は **LoopFormBuilder + LoopSnapshotMergeBox** に完全委譲したまま、
     - FuncScanner / Stage‑B は「テキストスキャン＋JSON 組み立て」の箱として綺麗に分離された状態にする。
 
+## 完了ステータス（2024-11-20 時点）
+
+- `tools/smokes/v2/profiles/quick/core/phase251/stageb_fib_program_defs_canary_vm.sh` が緑（Phase 25.3 の完了条件）。
+  - `defs` に `TestBox.fib` / `Main.main` が入り、`TestBox.fib.body.body[*]` に `Loop` ノードが含まれる状態を固定。
+- Stage‑B 本線の整理:
+  - `StageBDriverBox.main`: main 本文は `{…}` で包んだ block パーサ優先で JSON 化し、defs 側は `{"type":"Block","body":[…]}` に構造化して注入。
+  - `StageBFuncScannerBox._scan_methods`: block パーサ優先に揃え、Program パーサは `HAKO_STAGEB_FUNC_SCAN_PROG_FALLBACK=1` の opt-in 時だけ使う安全側トグルに変更（skip_ws 崩れの再発防止）。
+- Rust 層は無改変（LoopForm v2 / LoopSnapshotMergeBox の SSOT をそのまま利用）。
+
+## JSON v0 フロントと AOT ルートの契約（Phase 25.3 時点）
+
+- Program(JSON v0) の形:
+  - ルートは常に `{"version":0,"kind":"Program","body":[...]}`
+  - defs は `\"defs\":[{ \"name\", \"params\", \"box\", \"body\" }]` を追加する形で注入する。
+  - Stage‑B / FuncScanner 経由の `defs[*].body` は必ず `{\"type\":\"Block\",\"body\":[Stmt...]}` でラップし、AOT/VM 側からは「通常の Block ノード」として読めるようにする。
+- フロント/バックエンドの責務分離:
+  - Stage‑B / FuncScanner: `.hako` テキスト → Program(JSON v0) まで（ループ/PHI の意味論は持たない）。
+  - Rust 側 LoopForm v2 / JSON v0 Bridge: Program(JSON v0) → MIR/AOT まで（Loop/PHI/SSA の SSOT）。
+- Stage‑B トグル整理（抜粋）:
+  - `HAKO_STAGEB_FUNC_SCAN=1`（既定）: defs を常に埋める。`0` で Stage‑B からの defs 注入を無効化。
+  - `HAKO_STAGEB_PROGRAM_PARSE_FALLBACK=1`: main 本文で Program パーサ fallback を有効化（既定は OFF、block パーサ優先）。
+  - `HAKO_STAGEB_FUNC_SCAN_PROG_FALLBACK=1`: FuncScanner 側で Program パーサ fallback を有効化（既定は OFF）。  
+    通常の開発・CI ではいずれも OFF にしておき、VM/パーサ調査時だけ opt‑in で使う想定。
+
 ## すでに前提としている状態
 
 - LoopForm v2 / PHI / snapshot:
@@ -118,27 +144,28 @@ FuncScanner / Stage‑B のデバッグ時には、`scan_all_boxes` のループ
   - ここでの主なバグは「SSA ではなく、Stage‑B が fib ソースから defs を組み立てきれていないこと」なので、  
     ループ構造や LoopForm には手を入れず、Stage‑B 側のテキスト処理と defs 生成パスを中心に見る。
 
-### 4. fib defs canary & ドキュメント更新
+### 4. fib defs canary & ドキュメント更新（完了）
 
 - 対象:
   - `tools/smokes/v2/profiles/quick/core/phase251/stageb_fib_program_defs_canary_vm.sh`
   - `docs/development/roadmap/phases/phase-25.1q/README.md`
   - `CURRENT_TASK.md`
 
-- やること:
-  - canary スクリプトで:
-    - `Program.kind == "Program"`
-    - `defs` に `TestBox.fib` が存在すること。
-    - `TestBox.fib.body` に `Loop` ノードが含まれること。
-    を満たした状態で `rc=0` になるまで確認する。
-  - Phase 25.1q / 25.2 の README には、
-    - 「loop/PHI/スナップショットの SSOT は LoopForm v2 + LoopSnapshotMergeBox」
-    - 「Phase 25.3 で FuncScanner / Stage‑B defs もこの土台の上に載せた」
-    というつながりを 1〜2 行で追記する。
-  - `CURRENT_TASK.md` には:
-    - Phase 25.3 のタスク完了状況（FuncScanner fib / Stage‑B fib canary 緑）と、
-    - その後に繋がる Stage‑1 UsingResolver / Stage‑1 CLI self‑host ラインへのブリッジ
-    を短く整理しておく。
+今回の結果:
+- `tools/smokes/v2/profiles/quick/core/phase251/stageb_fib_program_defs_canary_vm.sh` は `rc=0` で安定緑。
+- canary 内部で確認している条件:
+  - `Program.kind == "Program"`
+  - `defs` に `TestBox.fib` / `Main.main` が含まれていること。
+  - `TestBox.fib.body` の直下（`body.body[*]`）に `Loop` ノードが最低 1 つ含まれていること。
+- これにより、FuncScanner / Stage‑B 経由の fib defs ラインは LoopForm v2 + LoopSnapshotMergeBox の上で構造的に安定したとみなせる。
+
+ドキュメント側:
+- Phase 25.1q / 25.2 の README には、
+  - 「loop/PHI/スナップショットの SSOT は LoopForm v2 + LoopSnapshotMergeBox」
+  - 「Phase 25.3 で FuncScanner / Stage‑B defs もこの土台の上に載せた」
+  という関係を 1〜2 行で追記済み。
+- `CURRENT_TASK.md` では Phase 25.3 を「Stage‑B fib defs canary 緑」まで完了したフェーズとして整理し、
+  次フェーズを Stage‑1 UsingResolver ループ整理 / Stage‑1 CLI program-json selfhost 導線に設定した。
 
 ### 5. mir_funcscanner_skip_ws 系テストの扱い（flaky → dev 専用）
 

docs/development/roadmap/phases/phase-25/README.md

@@ -69,7 +69,7 @@ Related docs:
   - `IntArrayCore`（数値一次元配列コア）
   - `MatI64`（行列箱・i64版）
  などを、「Rust プラグイン実装」ではなく **Hakorune 実装＋ごく薄い intrinsic** に置き換えるための設計ロードマップを固める。
-- 新しい箱・数値カーネル・標準ランタイム機能は **原則 .hako で実装する** 方針を明文化し、「Rust Freeze Policy（Self‑Host First）」を Phase 25 で具体化する。
+- 新しい箱・数値カーネル・標準ランタイム機能は **原則 .hako で実装する** 方針を明文化し、「Rust Minimal Policy（Self‑Host First, but not Frozen）」として Phase 25 で具体化する。
 
 ## レイヤー方針（Ring0 / Ring1）
 
@@ -82,8 +82,8 @@ Related docs:
 - **汎用 intrinsic** のみ提供（例: メモリ確保・生ポインタload/store・基本的な memcpy 等）
 
 **禁止 / 抑制:**
-- 新しい Box 種類（IntArrayCore / MatI64 / StringBuilder 等）を Rust 側に増やさない。
-- 新しい最適化ロジック・言語ルール・Box メソッド実装を Rust に追加しない（AGENTS.md 5.2 Rust Freeze Policy に準拠）。
+- 新しい Box 種類（IntArrayCore / MatI64 / StringBuilder 等）の**本体ロジック**を Rust 側に増やさない（型安全な intrinsic のみに留める）。
+- 新しい最適化ロジック・言語ルール・Box メソッド実装を Rust に追加しない（AGENTS.md 5.2 Rust Minimal Policy に準拠）。
 
 ### Ring1（Hakorune / Nyash ― System サブセット）
 
@@ -112,11 +112,11 @@ Related docs:
 
 Phase 25 は「設計とロードマップの確定」が主目的。実装・移行作業自体は後続フェーズ（22.x/26.x など）で分割実施する。
 
-### 1) Rust Freeze の明文化とチェックリスト
+### 1) Rust Minimal Policy の明文化とチェックリスト
 
-- 既存の「Rust Freeze Policy（Self‑Host First）」を、ランタイム/箱/数値系に特化して再整理:
+- 既存の「Rust Freeze Policy（Self‑Host First）」を、「Self‑Host を支える最小＋必要な整備は許可する」Rust Minimal Policy として再整理:
   - 新規 Box / ランタイム機能は Rust ではなく .hako で実装する。
-  - Rust 変更は「最小の intrinsic 追加」か「バグ修正」に限定。
+  - Rust 変更は「最小の intrinsic 追加」「Stage‑1/Stage‑B ブリッジの改善」「エラーログ・可観測性の向上」か「バグ修正」に限定。
 - PR / フェーズ用チェックリスト案を作成:
   - [ ] この変更は Ring0 の責務か？（VM/allocator/LLVM/OS FFI のみ）
   - [ ] 新しい Box/アルゴリズムを Rust に追加していないか？

docs/development/runtime/cli-hakorune-stage1.md

@@ -1,6 +1,6 @@
 # Stage1 Hakorune CLI Design（Proposal）
 
-Status: design-only（Phase 25.1 時点では仕様策定と導線の整理まで）
+Status: design-only + Stage0 stub 実装済み（Phase 25.1 時点では仕様策定と導線の整理まで。selfhost EXE 本体は未実装）
 
 ## ゴール
 
@@ -15,6 +15,8 @@ Status: design-only（Phase 25.1 時点では仕様策定と導線の整理ま
   - 役割: プロセス起動・VM/LLVM コア・ny-llvmc 呼び出しなどの「Ring0」。
   - Ny 側からは `env.mirbuilder.emit` / `env.codegen.emit_object` / `env.codegen.link_object` などの extern 名で見える。
   - Stage1 実行時は「CLI として」ではなく、これらのランタイムサービス層（C-ABI/extern）として利用することを前提とする。
+  - Phase 25.1 現在は、Rust Stage0 から `.hako` 側 stub CLI（`lang/src/runner/stage1_cli.hako`）を子プロセスとして起動する
+    ブリッジ（`src/runner/stage1_bridge.rs`）のみ実装済みで、自己ホスト EXE（`target/selfhost/hakorune`）はまだ設計段階。
 - Stage1（Hakorune selfhost CLI）
   - 実体: `target/selfhost/hakorune`（Phase 25.1 では Ny Executor プロトタイプ）。
   - 役割: `.hako → Program(JSON) → MIR(JSON) → 実行/EXE` というパイプラインの制御。
@@ -64,6 +66,10 @@ Phase 25.1a では、**`emit program-json` / `emit mir-json` / `build exe` の 3
   - `--quiet` でログ抑制、`-o/--out` で出力 EXE パスを指定可能。C-API トグル（`NYASH_LLVM_USE_CAPI`, `HAKO_V1_EXTERN_PROVIDER_C_ABI`）が無効な場合は fail-fast。
 - Stage1 バイナリ（`target/selfhost/hakorune`）を直接叩く際は `NYASH_NYRT_SILENT_RESULT=1` を付与し、stdout に JSON だけを流す運用を徹底する（`tools/selfhost/run_stage1_cli.sh` が環境セットとバイナリ検出を担当）。
 
+#### デバッグ Tips（Phase 25.1a）
+- `STAGE1_CLI_DEBUG=1` を付けると `.hako` 側 `stage1_main` の ENTRY ログが出る。Rust ブリッジが正しく Stage1 stub を呼んでいるか確認する際に使う。
+- `NYASH_CLI_VERBOSE=1` か `2` を付けると Rust 側 bridge (`stage1_bridge.rs`) が子プロセス起動ログを出力する。
+
 ## `run` コマンド
 
 ```text