feat(phase32): L-2.1 Stage-1 UsingResolver JoinIR integration + cleanup

Phase 32 L-2.1 complete implementation:

1. Stage-1 UsingResolver main line JoinIR connection
   - CFG-based LoopForm construction for resolve_for_source/5
   - LoopToJoinLowerer integration with handwritten fallback
   - JSON snapshot tests 6/6 PASS

2. JoinIR/VM Bridge improvements
   - Simplified join_ir_vm_bridge.rs dispatch logic
   - Enhanced json.rs serialization
   - PHI core boxes cleanup (local_scope_inspector, loop_exit_liveness, loop_var_classifier)

3. Stage-1 CLI enhancements
   - Extended args.rs, groups.rs, mod.rs for new options
   - Improved stage1_bridge module (args, env, mod)
   - Updated stage1_cli.hako

4. MIR builder cleanup
   - Simplified if_form.rs control flow
   - Removed dead code from loop_builder.rs
   - Enhanced phi_merge.rs

5. Runner module updates
   - json_v0_bridge/lowering.rs improvements
   - dispatch.rs, selfhost.rs, modes/vm.rs cleanup

6. Documentation updates
   - CURRENT_TASK.md, AGENTS.md
   - Various docs/ updates

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

docs/development/design/extern-vs-boxcall.md

@@ -32,7 +32,7 @@ Extern vs BoxCall — 分離方針とスロット/アリティ一覧（Phase 12
 - BoxCall: vtable（TypeRegistry のスロット）→ PIC（poly→mono）→ 汎用メソッド呼び。
   - STRICT: 未登録メソッドは型名・メソッド名・arity・known一覧を含めてエラー。
 - ExternCall: `extern_registry` で iface/method/arity を登録、任意で slot 経由のハンドラに集約。
-  - `NYASH_EXTERN_ROUTE_SLOTS=1` で name→slot 専用ハンドラへ（VM/JITの挙動安定）。
+  - name→slot 専用ハンドラは検討のみ。旧 `NYASH_EXTERN_ROUTE_SLOTS` は未使用につき撤去。
 
 TypeRegistryの代表スロット
 - InstanceBox: 1(getField), 2(setField), 3(has), 4(size)
@@ -50,7 +50,6 @@ Extern スロット（抜粋）
 環境変数
 - `NYASH_ABI_VTABLE`: VMのvtable経路有効化
 - `NYASH_ABI_STRICT`: STRICT診断を有効化
-- `NYASH_EXTERN_ROUTE_SLOTS`: Externをslot経路に統一
+- `NYASH_EXTERN_ROUTE_SLOTS`: （撤去済み）Externをslot経路に統一するトグル
 - `NYASH_JIT_HOST_BRIDGE`: JITのhost-bridge（by-slot経路）を有効化
-- `NYASH_VM_PIC_THRESHOLD`: PICモノ化しきい値（既定=8）
-
+- `NYASH_VM_PIC_THRESHOLD`: （撤去済み）PICモノ化しきい値トグル

docs/development/refactoring/candidates_phase15.md

@@ -18,7 +18,7 @@ High‑Value Candidates
 
 - VM dispatch integration
   - Gradually route the big `match` in VM through `backend/dispatch.rs` (already scaffolded). Start with side‑effect‑free ops (Const/Compare/TypeOp) to de‑risk.
-  - Add opt‑in flag `NYASH_VM_USE_DISPATCH=1` to gate behavior during the transition.
+  - (撤去済み) `NYASH_VM_USE_DISPATCH=1` でのディスパッチ経路スイッチ案は廃止。
 
 - Env access centralization
   - Replace scattered `std::env::var("NYASH_*")` with `config::env` getters in hot paths (VM tracing, GC barriers, resolver toggles).
@@ -42,4 +42,3 @@ Suggested Sequencing
 Notes
 - Keep JIT/Cranelift untouched in this phase to avoid drift from the mainline policy.
 - Prefer file‑level docs on new modules to guide incremental migration.
-

docs/development/roadmap/README.md

@@ -6,6 +6,7 @@
 - **現在のタスク**: [../../CURRENT_TASK.md](../../CURRENT_TASK.md)
 - **Phase 8.3**: Box操作WASM実装（Copilot担当）
 - **Phase 8.4**: ネイティブコンパイル実装計画（AI大会議策定済み）
+- **Stage‑1 / JSON v0**: Stage‑1 CLI minimal は Program(JSON v0) まで安定到達済み、Ny compiler 経路の JSON v0→MIR 統一は Phase 28.2 以降で追う
 
 ## 🚀 ネイティブコンパイル計画 (2025-08-14策定)
 

docs/development/roadmap/phases/phase-25.1/span-trace.md

@@ -3,3 +3,5 @@
 - 方針: MIR 命令に AST Span を持たせ、VMError (StepBudgetExceeded) で fn/bb/inst に加えて .hako 行番号を出す。
 - 実装: MirInstruction 生成時に current_span を保存し、VM 側で last_inst_idx から Span を引いてエラーに埋め込む。Span が無い場合は従来どおり fn/bb/inst のみ。
 - 状態: Stage‑1 CLI の MIR には Span 未付与なので行番号はまだ出ていないが、Span 付き MIR なら `... (file.hako:line:col)` まで表示できる。
+- ダンプ: `RUST_MIR_DUMP_PATH=/tmp/foo.mir` を指定すると、VM 実行前の MirModule をファイルに出力できる（`--dump-mir` のファイル版）。Stage‑1/Stage‑B 経路でも共通で使う想定。
+- JSON v0 経路: `json_v0_bridge::maybe_dump_mir` が Program(JSON v0)→MIR 直後に動くので、Span が付いていればそこで観測できる（AST 直通の MirPrinter dump では Span 表示なし）。

docs/development/roadmap/phases/phase-25.1/stage1-cli-loop-analysis.md

@@ -4,7 +4,7 @@
 - `Stage‑1 CLI → BuildBox.emit_program_json_v0` 実行時に VM が step budget を食い尽くしている原因を、  
   ループ構造と BoxCall 依存の観点から整理しておくためのメモだよ。
 
-## 1. 観測された症状
+## 1. 観測された症状（修正前スナップショット）
 
 - コマンド例:
   ```bash
@@ -13,12 +13,22 @@
   STAGE1_EMIT_PROGRAM_JSON=1 \
   ./target/release/hakorune apps/tests/minimal_ssa_skip_ws.hako
   ```
-- 状態:
+-- 状態（修正前）:
   - `[stage1-bridge/trace]` ＋ `[stage1-cli/debug] emit_program_json ENTRY` が出ており、  
     Stage1CliMain.main/0 〜 stage1_cli.hako 実行までは到達している。
   - その後 `BuildBox.emit_program_json_v0` 実行中に VM が `vm step budget exceeded`（max_steps=1_000_000→2_000_000 でも NG）。
   - FileBox/ArrayBox などの plugin 未ロード警告も併発。
-  - 現状は **ステップ上限＋プラグイン依存** が阻害要因となって、program-json 自体は得られていない。
+  - 当時は **ステップ上限＋プラグイン依存** が阻害要因となって、program-json 自体は得られていなかった。
+
+## 1.1 現在の状態（2025-11 時点）
+
+- ParserBox / StringHelpers / 各種 parser_* 箱のすべての  
+  `loop(cont == 1) { if cond { ... } else { cont = 0 } }` 形式のループを、
+  `loop(true) { if cond { ...; continue } break }` 形式に統一した。
+- 代表ループ（`parse_program2` 本体、ws_init、セミコロン消費、string/number/map/array/control/exception/stmt/expr 系ループ）を一括で MirBuilder-friendly な形に寄せた結果、
+  - `NYASH_USE_STAGE1_CLI=1 STAGE1_EMIT_PROGRAM_JSON=1 HAKO_VM_MAX_STEPS=2000000 NYASH_STAGE1_INPUT=apps/tests/minimal_ssa_skip_ws.hako ./target/release/hakorune`
+    で **step budget 超過無し**、Program(JSON v0) が `{"version":0,"kind":"Program","body":[]}` として出力されることを確認済み。
+  - VM の step budget エラーには fn/bb/last_inst ＋ Span（あれば .hako:line）が付くようになっており、将来の類似ケースも追いやすい。
 
 ## 2. emit_program_json_v0 周辺のループ構造（概観）
 

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

@@ -32,6 +32,11 @@ Phase 25.1 A-3: `.hako` 側 Stage1Cli skeleton に env-only 実処理を実装
 - Stage1 は **自分で VM/LLVM を実装しない**。常に Ring0 のサービス（env.codegen/env.mirbuilder, NyRT/ny-llvmc 等）を経由して実行・AOT する。
 - Stage1 CLI は「どのステージまで進めるか」と「どのバックエンドで実行/ビルドするか」を宣言的に指定するだけに留める。
 - Stage1 バイナリ自体は Stage0 の CLI からは独立しており、Stage0 はあくまで「ブートストラップおよびランタイムサービス提供者」として扱う。
+- JSON v0 境界の扱い:
+- Stage0 直通: Rust AST → MirCompiler で MIR を生成し、`--dump-mir` は MirPrinter の stdout 出力のみ（Program(JSON v0) は介さない）。
+- Stage1/selfhost: BuildBox/ParserBox などが `Program(JSON v0)` を返し、Stage0 は `json_v0_bridge::parse_json_v0_to_module` → `maybe_dump_mir`（`RUST_MIR_DUMP_PATH`/`--dump-mir` 両対応） → VM/LLVM という共通導線で処理する。
+- Stage‑1 専用モード: `STAGE1_EMIT_MIR_JSON=1` で Program(JSON v0) を生成して Rust 側が即座に MIR 化し dump/emit までを行う（実行はしない。`RUST_MIR_DUMP_PATH` / `--dump-mir` / `--emit-mir-json` が JSON v0→MIR 共通パスで効く）。
+- CLI フラグ整理: `.hako` / Stage‑1 を経由する入口は `--hako-emit-program-json` / `--hako-emit-mir-json` / `--hako-run` を前置きで区別する（内部で Stage‑1 stub を呼び出し、JSON v0 境界から先は共通パスへ流す）。
 
 ## トップレベル構文
 
@@ -251,13 +256,15 @@ hakorune emit mir-json [-o <out>] [--quiet] <source.hako>
   - `mir_stage1_cli_emit_program_min_compiles_and_verifies`:
     - Stage1Cli + UsingResolver + BuildBox を含んだモジュールが MIR 生成・verify まで通ることを確認（SSA/PHI 崩壊なし）。
   - `mir_stage1_cli_emit_program_min_exec_hits_type_error`:
-    - VM 実行まで進め、Stage‑1 CLI 経路の型エラーや未解決呼び出しが発生しないことを確認するための箱（現在は安定化済み）。
+    - VM 実行まで進め、Stage‑1 CLI 経路の型エラーや未解決呼び出しが発生しないことを確認するための箱（現在は LoopForm/ParserBox 修正により安定化済み）。
 
 ### Stage‑1 CLI 環境変数（env-only 仕様）
 
 - Stage0 の `stage1_bridge.rs` から `.hako` 側 `stage1_cli.hako` を呼び出す際の最低限の ENV:
   - `STAGE1_EMIT_PROGRAM_JSON` / `STAGE1_EMIT_MIR_JSON` / `NYASH_USE_STAGE1_CLI`:
-    - モード選択（emit_program_json / emit_mir_json / run）。
+    - モード選択（emit_program_json / emit_mir_json / run）。  
+      - `STAGE1_EMIT_PROGRAM_JSON=1`: Program(JSON v0) を stdout に出して終了（VM 実行なし）。
+      - `STAGE1_EMIT_MIR_JSON=1`: Program(JSON v0) を JSON v0 ブリッジで MIR(JSON) に変換し、`--dump-mir` / `RUST_MIR_DUMP_PATH` / `--emit-mir-json` を通す emit 専用モード（VM 実行なし）。
   - `STAGE1_SOURCE`:
     - .hako ソースパス（FileBox 経由で読み込むときに使用）。
   - `STAGE1_SOURCE_TEXT`: