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>

CURRENT_TASK.md

@@ -17,11 +17,37 @@
 - .hako 側:
   - Stage‑B コンパイラ本体 / LoopSSA v2 / BreakFinderBox / PhiInjectorBox はまだ部分実装。
   - JSON v0 / selfhost ルートは Rust 側の LoopForm v2 規約に追いつかせる必要がある。
+- Stage‑B / FuncScanner ライン:
+  - Phase 25.3 をクローズし、`stageb_fib_program_defs_canary_vm.sh` が緑（`defs` に `TestBox.fib/Main.main`、fib.body.body[*] に `Loop`）。
+  - Stage‑B は block パーサ優先 + defs を Block 包みで構造化。次手: Stage‑1 UsingResolver ループの Region+next_i 揃え / Stage‑1 CLI program-json selfhost 準備。
 
 ---
 
 ## 1. 最近完了した重要タスク
 
+### 1-0. Phase 25.3 — FuncScanner / Stage‑B defs 安定化（完了）
+
+**目的**
+- Stage‑B / FuncScanner ラインで defs が欠落したり Loop が脱落する問題を塞ぎ、selfhost 側の canary を緑に戻す。
+
+**やったこと**
+- StageBDriverBox.main:
+  - main 本文を `{…}` で包んだ block パーサ優先で Program(JSON) に組み立て、defs には `{"type":"Block","body":[…]}` 形式で埋め込むよう整理。
+  - Program パーサ fallback は `HAKO_STAGEB_PROGRAM_PARSE_FALLBACK=1` の opt-in に封じ込め（skip_ws 崩れを回避）。
+- StageBFuncScannerBox._scan_methods:
+  - block パーサ優先に統一し、Program パーサは `HAKO_STAGEB_FUNC_SCAN_PROG_FALLBACK=1` でのみ有効化。
+  - defs パラメータに必ず `me` を足す従来挙動は維持（TestBox/Main いずれも同型で出力）。
+- Rust 層の追加変更なし（LoopForm v2 / LoopSnapshotMergeBox をそのまま利用）。
+
+**結果**
+- `tools/smokes/v2/profiles/quick/core/phase251/stageb_fib_program_defs_canary_vm.sh` が安定して PASS。
+  - `Program.kind == "Program"`
+  - `defs` に `TestBox.fib` / `Main.main` を保持していること。
+  - `TestBox.fib.body.body[*]` に `Loop` ノードが含まれること。
+  を満たした状態で `rc=0` になることを確認。
+- FuncScanner / Stage‑B 経由の fib defs ラインは LoopForm v2 + LoopSnapshotMergeBox 上で構造的に安定したとみなし、Phase 25.3 はクローズ。
+- 次フェーズの入口が整理できたので、Stage‑1 UsingResolver ループ（Region+next_i 形）と Stage‑1 CLI program-json/selfhost 導線に着手可能。
+
 ### 1-1. Phase 25.1m — Static Method / LoopForm v2 continue + PHI Fix（完了）
 
 **目的**
@@ -138,6 +164,26 @@
 
 ---
 
+### 1-4. Phase 25.1A‑3 — Stage‑1 CLI bridge（stub 実装）
+
+- Rust 側: `src/runner/stage1_bridge.rs` を `run_refactored` 入口に組み込み、`NYASH_USE_STAGE1_CLI=1` かつ再入ガードなしのときに `lang/src/runner/stage1_cli.hako` を子プロセスで起動する。`STAGE1_EMIT_PROGRAM_JSON` / `STAGE1_EMIT_MIR_JSON` / `STAGE1_BACKEND` / `STAGE1_PROGRAM_JSON` で mode 選択。entry override は `STAGE1_CLI_ENTRY` / `HAKORUNE_STAGE1_ENTRY`。
+- .hako 側: `Stage1Cli` に最低限の本体を実装。
+  - `emit_program_json`: Stage‑1 UsingResolver で prefix を結合し、BuildBox.emit_program_json_v0 で Program(JSON v0) を返す。
+  - `emit_mir_json`: `MirBuilderBox.emit_from_program_json_v0` をそのまま呼ぶ（delegate 未設定なら null）。
+  - `run_program_json`: backend==llvm の場合は `env.codegen.emit_object` まで通す。vm/pyvm は当面 MIR(JSON) を stdout に出すのみ（実行は Stage0 橋渡し未配線）。
+  - CLI: `emit program-json|mir-json` / `run --backend ... <src>` を受理。`NYASH_SCRIPT_ARGS_JSON` を JSON で best-effort 伝播。
+- Docs: `docs/development/roadmap/phases/phase-25.1/stage1-usingresolver-loopform.md` に stub 状態を追記（run は暫定挙動）。
+- Known gaps: vm/pyvm 実行はまだ Stage0 への橋渡し未着手。llvm も emit object 止まり（link/exec は後続）。
+
+### 1-5. Phase 25.1A‑4 — Using SSOT 薄設計＋BuildBox include 除去
+
+- SSOT: `lang/src/using/resolve_ssot_box.hako` に README 相当のコメントと I/F（resolve_modules/resolve_prefix）を追加。現状は no-op だが「using をここで扱う」窓口を固定。
+- Stage1UsingResolver: `resolve_for_program_json` を追加し、SSOT を呼ぶ導線だけ確保（現状は透過返し）。
+- BuildBox: 先頭の `include` を削除し、`using lang.compiler.entry.bundle_resolver as BundleResolver` に置換（Stage‑B パーサが include を解せない問題の足場づくり）。
+- 実行確認: `NYASH_ALLOW_NYASH=1 HAKO_ALLOW_NYASH=1 NYASH_USE_STAGE1_CLI=1 STAGE1_EMIT_PROGRAM_JSON=1 ... cargo run --bin hakorune -- basic_test.hako` が RC=0 で完走（ただし stdout は `RC: 0` のみ、program-json 出力は未配線）。`cargo run ... emit program-json` は Rust CLI 側の表面が未対応のためエラー（想定挙動）。
+
+---
+
 ## 2. まだ残っている問題・課題（2025-11-18 時点）
 
 ### 2-1. Stage‑B 本体の型エラー（`String > Integer(13)`）
@@ -230,27 +276,51 @@
 
 ## 3. 次にやること（候補タスク）
 
-ここから先は「どのフェーズを進めるか」をそのときの優先度で選ぶ感じだよ。
+ここから先は「どのフェーズを進めるか」をそのときの優先度で選ぶ感じだよ。  
+Rust 側は LoopForm v2 / Stage‑B fib / Stage‑1 UsingResolver 構造テストまで一通り整ったので、当面は Stage‑1 CLI / selfhost ラインの小さな箱から進める。
 
-1. **Stage‑B / BreakFinder / FuncScanner ラインの SSA 根治（Phase 25.1m 続き）**
-   - JSON v0 bridge の Loop lowering で、`backedge_to_cond` が `Jump` だけでなく `Branch(cond→header/exit)` も認識するように修正（`loop_.rs`）。  
-     → BreakFinderBox._find_loops/2 のような break を含むループでも header PHI が正しく張られるようにした。
-   - BreakFinderBox は解析用の static box として扱い、`me._find_loops` / `me._jumps_to` を `BreakFinderBox._find_loops` / `_jumps_to` に正規化。  
-     → `me` 未定義による Undefined ValueId を避ける。
-   - Stage‑B → Stage‑1 パーサ経路は、`ParserBox.parse_program2` のトップレベルループではなく、`parse_block2` で `Main.main` の本文をブロックとしてパースし、  
-     Program(JSON v0) を自前で組み立てる構造に変更（Stage‑B 固まり問題を回避）。
+### A. Stage‑1 CLI / Stage0 ブリッジ（Phase 25.1 — いまここ）
 
-2. **Stage‑B 再入ガード `env.set/2` の整理**
-   - 再入ガードを Box 内 state で持つ方向か、Rust 側に dev 専用 extern を追加するかを決める。
-   - どちらにしても「本番経路（prod ランナー）には影響しない」ようフラグでガードする。
+- A‑1: Stage‑1 CLI stub を Stage0 Rust ランナーから呼び出すブリッジ（DONE）  
+  - 実装: `src/runner/stage1_bridge.rs` ＋ `src/runner/mod.rs` に `maybe_run_stage1_cli_stub` を追加。  
+    - `NYASH_USE_STAGE1_CLI=1`（既定 OFF）かつ `NYASH_STAGE1_CLI_CHILD!=1` のときにだけ有効。  
+    - entry `.hako` は `STAGE1_CLI_ENTRY` / `HAKORUNE_STAGE1_ENTRY` で上書き可能（既定: `lang/src/runner/stage1_cli.hako`）。  
+    - 入力ファイル / モード:
+      - `STAGE1_EMIT_PROGRAM_JSON=1`: `hakorune emit program-json <source.hako>` を子プロセスで実行。  
+      - `STAGE1_EMIT_MIR_JSON=1`: `STAGE1_PROGRAM_JSON` があれば `--from-program-json`、なければ `<source.hako>` から `emit mir-json`。  
+      - 上記どちらも無い場合: `hakorune run --backend <backend> <source.hako>`（backend は `STAGE1_BACKEND` か CLI の backend 設定）。  
+    - `NYASH_SCRIPT_ARGS_JSON` を拾って `--` 以降の script 引数も Stage‑1 側に転送。  
+    - 再入防止として子プロセスには `NYASH_STAGE1_CLI_CHILD=1` を付与（子側からは Rust ブリッジを素通り）。
+- A‑2: Stage‑1 CLI skeleton の責務を doc に固定（DONE）  
+  - `lang/src/runner/stage1_cli.hako` で `Stage1Cli.emit_program_json/emit_mir_json/run_program_json/stage1_main` のシグネチャとトグルトポロジーを固定。  
+  - `docs/development/roadmap/phases/phase-25.1/stage1-usingresolver-loopform.md` に Rust 側ブリッジの振る舞いとトグル名（`NYASH_USE_STAGE1_CLI` / `STAGE1_EMIT_*` / `STAGE1_BACKEND` / `NYASH_STAGE1_CLI_CHILD`）を追記。
+- A‑3: 次ステップ（未着手）  
+  - Stage‑1 CLI skeleton に Stage‑B/BuildBox/MirBuilder 呼び出しを順に実装し、「Program(JSON)/MIR(JSON) を selfhost 経由で emit できる」状態まで持っていく。  
+  - `tools/selfhost/run_stage1_cli.sh` から呼び出す selfhost パスと、Rust CLl からのブリッジパスの両方で JSON I/O 契約が同じになるように揃える。
 
-3. **.hako LoopSSA v2 実装（LoopForm v2 への追従）**
-   - Rust LoopForm v2 の規約（Carrier/Pinned / preheader/header/latch/exit）を `.hako` の LoopSSA に輸入。
-   - Stage‑B Test2 / selfhost CLI の JSON→MIR 経路で MirVerifier 緑を目標にする。
+### B. Stage‑1 UsingResolver / LoopForm v2 ライン（Phase 25.1e 系フォロー）
 
-4. **Selfhost / CLI 周辺のテスト整理**
-   - 代表的な selfhost / Stage‑B / Stage‑1 CLI ケースに対して、
-     「Phase 25.1m でどこまで緑になったか」「どこから先が 25.1k 以降の仕事か」を tests / tools 側で見える化する。
+- B‑1: entry UsingResolver の Region+next_i 化とコメント整備（おおむね DONE）  
+  - `lang/src/compiler/entry/using_resolver_box.hako` の 3 ループ（entries / JSON スキャン / modules_list）は Region+next_i 形に揃え済み。  
+  - 役割コメント: `resolve_for_source`（Stage‑B body_src を受けて prefix を返す）、`_collect_using_entries`（JSON スキャンして entries を集める）、`_build_module_map`（modules_list を map 化）を明記済み。  
+  - `HAKO_STAGEB_APPLY_USINGS=0` の時は prefix を空 string にしつつ、depth ガードだけは走らせる仕様もコメントで固定。
+- B‑2: UsingResolver 構造テスト（ループ形/PHI）の拡充（DONE）  
+  - `src/tests/mir_stage1_using_resolver_verify.rs` に Region+next_i ループと early-exit JSON スキャンパターンの軽量テストを追加。  
+  - これらは cargo test 経路で常時緑を維持し、v2 quick スモークへの昇格は「実行時間とノイズを見ながら後続フェーズで検討」という扱いにする（docs にメモ済み）。
+- B‑3: pipeline_v2 UsingResolver との責務境界（DONE）  
+  - `lang/src/compiler/pipeline_v2/using_resolver_box.hako` 冒頭に、「entry 側=ファイル I/O + using 収集」「pipeline_v2 側=modules_json 上の alias/path 解決」と役割メモを追加。  
+  - RegexFlow ベースの単一路ループは Region 化不要（stateful helper）とし、LoopForm v2 の観点からも「観測対象外」とする。
+
+### C. Stage‑B / LoopSSA / Selfhost まわり（中期タスク）
+
+- C‑1: Stage‑B 再入ガード `env.set/2` の整理（据え置き）  
+  - dev 専用 extern を Rust 側に追加するか、Stage‑B 箱側で state に寄せるかを決める必要があるが、現在はループ/PHI ラインを優先し保留。  
+  - このタスクに着手するときは「prod/CI 経路から完全に切り離した dev ガード」として設計する。
+- C‑2: .hako LoopSSA v2 実装（Rust LoopForm v2 への追従）  
+  - Rust LoopForm v2 の Carrier/Pinned/BodyLocalInOut モデルを `.hako` の LoopSSA に輸入し、Stage‑B Test2 / selfhost CLI でも MirVerifier 緑を目指す中〜長期タスク。  
+  - 具体的な対象: `lang/src/compiler/builder/ssa/loopssa.hako` と Stage‑B/BreakFinder 周辺の region 化済みループ。
+- C‑3: Selfhost / CLI 周辺のテスト整理  
+  - 代表的な selfhost / Stage‑B / Stage‑1 CLI ケースを tests/tools 側でタグ付け（quick/integration/selfhost）、Phase 25.1 の「どこまでが Rust 側」「どこからが Stage1 側」を見える化する。
 
 ---
 
@@ -268,44 +338,51 @@
 次にどの箱から攻めるか決めたら、ここに箇条書きで足していこうね。  
 
 
-## 2-? Stage‑B FuncScanner / LoopSnapshotMergeBox / MIR ロガー（in progress）
+## 3. これからやるタスクのラフ一覧（25.1 / Stage‑1 系）
 
-- StageBFuncScannerBox を `compiler_stageb.hako` 内に追加し、StageBDriverBox.main からは FuncScannerBox ではなくこちらを呼ぶ構成にしている。
-- VM 側の Undefined value（BreakFinderBox._find_loops/2）は LoopForm v2 / continue + PHI 修正で解消済み。
-- FuncScannerBox.scan_all_boxes/1 については、Phase 25.2 で `LoopSnapshotMergeBox` を導入し、continue/break/exit スナップショットのマージを一元化したことで
-  13 個の continue を含む複雑ループでも Undefined Value が出ないところまで到達しており、
-  さらに `lang/src/compiler/tests/funcscanner_fib_min.hako` を使った最小ハーネスでも `NYASH_VM_VERIFY_MIR=1` で Undefined Value が再現しないところまで確認済み。
-  - LoopSnapshotMergeBox 実装: `src/mir/phi_core/loop_snapshot_merge.rs`
-    - `merge_continue_for_header` / `merge_exit` / `optimize_same_value` / `sanitize_inputs` など、ヘッダ/exit PHI 用の入力統合ロジックを提供。
-  - LoopBuilder / LoopFormBuilder は、この箱を経由して continue_merge / exit PHI を構成するようにリファクタ済み。
-- 代表テスト:
-  - ループ系: `mir_stageb_loop_break_continue::*` / `mir_loopform_exit_phi::*` / `mir_stageb_like_args_length::*` はすべて PASS。
-  - 手書きループ:
-    - 基本ループ: sum=10（0+1+2+3+4）✅
-    - break/continue を含むループ: sum=19, i=7 ✅
-    - body-local 変数を含むループ: result=6, i=3 ✅（exit PHI で body-local を正しく統合）
-- StageBFuncScannerBox.scan_all_boxes(src) は依然として fib サンプルに対して defs=[]（Program(JSON) に `TestBox.fib` が載っていない）という問題が残っているため、
-  次の担当者は StageBFuncScannerBox.scan_all_boxes/1 と FuncScannerBox.scan_all_boxes/1 の MIR を比較しつつ、
-  Stage‑B body 抽出 → StageBFuncScannerBox.scan_all_boxes → Program(JSON v0).defs 注入の導線自体を見直してほしい（LoopForm/PHI/スナップショット側は LoopSnapshotMergeBox で安定化済み）。
-- Phase 25.3 では、FuncScanner / Stage‑B ラインの観測専用として `.hako` から直接 MIR ログを埋め込める `__mir__` 構文を導入した。
-  - 構文: `__mir__.log("label", v1, v2, ...)` / `__mir__.mark("label")`
-  - lowering: `MirInstruction::DebugLog { message: "label", values: [v1, v2, ...] }` に変換される（LoopForm/PHI には影響しない）。
-  - 実行: `NYASH_MIR_DEBUG_LOG=1` のときだけ `[MIR-LOG] label: %id=value ...` を VM 側で出力し、それ以外は no-op。
-  - 実装ポイント: `src/mir/builder/calls/build.rs` の `build_method_call_impl` で `__mir__` receiver を検出し、`try_build_mir_debug_call` で `DebugLog` 命令に directly lowering している。
-  - これにより、FuncScannerBox.scan_all_boxes や StageBFuncScannerBox.scan_all_boxes のループ頭や `box` 検出位置にラベルを打ち、
-    VM 実行ログと合わせて「どの経路で未初期化の値が残っているか」を .hako 側から追いやすくなった。
-  - 併せて `MirBuilder::handle_me_method_call` を `MeCallPolicyBox` で箱化し、me-call のフォールバックを静的メソッド降下に統一した。
-    - `Box.method/Arity` lowered 関数が存在する場合は従来どおり `me` を先頭引数にした Global call。
-    - 存在しない場合は `handle_static_method_call(cls, method, arguments)` に委譲し、static helper（FuncScannerBox._parse_params / _strip_comments など）呼び出しとして扱う。
-    - これにより static box 文脈で「実体のない me を receiver にした Method call」が生成される経路が閉じられ、FuncScannerBox._scan_methods/4 系の UndefinedValue は Rust 側で構造的に防止されている。
+ここから先は「まず設計と箱分割を書いてから実装」という方針で進めるタスク群だよ。
 
+### A. Rust 層解析（LoopForm v2 / JSON v0 / Stage‑1 観測）
 
-## 3. Static Box フィールド仕様ドキュメント（完了）
+- A-1: LoopForm v2 / LoopSnapshotMerge の入口確認  
+  - `src/mir/loop_builder.rs` / `src/mir/phi_core/loopform_builder.rs` / `src/mir/phi_core/loop_snapshot_merge.rs` を「Stage‑1 から見た導線」として読み直し、どのレイヤで Carrier / Pinned / BodyLocalInOut が決まるかを short メモ化する。
+- A-2: JSON v0 → MIR ブリッジの導線整理  
+  - `src/runner/json_v0_bridge/lowering/`（特に `loop_.rs`）を通して、Program(JSON v0).body / defs.body(Block) が LoopForm v2 までどう運ばれるかを図として docs に落とす。
+- A-3: Stage‑1 UsingResolver の MIR 観測  
+  - 既存テスト `src/tests/mir_stage1_using_resolver_verify.rs` の MIR dump を元に、「どのループが Region+next_i 化候補か」「既に問題なく LoopForm に乗っている場所はどこか」を箇条書きで整理する。
 
-- docs/reference/language/LANGUAGE_REFERENCE_2025.md: 3.4 Static Boxパターンに「static box 内のフィールドはすべて static フィールドとして扱われる」旨を明記した。
-- 言語仕様としては、static box の中では `PI: FloatBox` のような宣言で十分であり、追加の `static` キーワードは不要であることをドキュメント上で固定。
-- 次タスク候補（Claude Code 向け）: static box / box のフィールド挙動に関するサンプルとテスト（VM/JSON v0 両方）の整理、および static box 上の `me` セマンティクス（25.1p DebugLog フェーズと連動）の仕様化。
+### B. Stage‑1 UsingResolver 箱化・ループ整理（.hako 側）
 
+- B-1: Stage1UsingResolverBox の責務分割設計  
+  - `lang/src/compiler/entry/using_resolver_box.hako` を、collect_entries / modules_map / file_read などの小さいロジック箱に概念的に分割し、「どの箱が何を責務とするか」を docs に書く（実際のファイル分割は後段）。
+- B-2: すべてのループを Region+next_i 形に揃える計画  
+  - entry の UsingResolver 内に残っている「pos++/continue 多発型」ループを洗い出し、Region+next_i 形にどう書き換えるかを phase-25.1 docs に追記する。  
+  - 目的: LoopForm v2 / PHI から見たときに「1 region / 1 backedge / 明確な次位置決定」という形に統一する。
+  - 状況メモ: entry 側 3 ループ（entries/JSON scan/modules_list）は Region+next_i 化済み。残りなし。
+- B-3: pipeline_v2 UsingResolver との役割分担  
+  - `lang/src/compiler/pipeline_v2/using_resolver_box.hako` と entry/Stage1UsingResolverBox のどちらが「テキスト / JSON / modules_map」のどこまでを担当するかを整理し、責務境界をドキュメントに固定する。
+  - 状況メモ: pipeline_v2 側は modules_json の alias 解決のみ（RegexFlow.find_from の単一路ループ）。Region 化不要として据え置き、境界だけ明記。
+- B-4: 構造テストの追加計画  
+  - Region+next_i パターンの軽量 SSA テスト（すでに 1 本追加済み）を基準に、もう 1〜2 本、UsingResolver ソースに近いパターン（JSON スキャン＋early-exit）を追加する方針を決める。
+
+### C. Stage‑1 CLI / program-json / mir-json Self‑Host 準備
+
+- C-1: Stage‑1 CLI インターフェースの設計メモ  
+  - `.hako → Program(JSON)` / `Program(JSON) → MIR(JSON)` / `MIR(JSON) → 実行` を Stage‑1 側からどう呼び出すか（関数名・引数レベル）を docs に先に書く。
+- C-2: Stage‑B → Stage‑1 データフロー図  
+  - `compiler_stageb.hako` → Program(JSON v0) → Stage‑1 UsingResolver → MirBuilder までのパイプラインを Phase‑25.1 ドキュメントに 1 枚の図としてまとめる。
+- C-3: Rust CLI 側ブリッジの最小ガード案  
+  - Stage0/Rust CLI は「Program(JSON/MIR(JSON) を受け取り VM/LLVM に流すだけ」に縮退させる方針と、既定 OFF トグル（selfhost 入口）をどう切るかを設計メモとして追加。
+
+### D. 将来フェーズ向けメモ（variable_map 決定化ライン）
+
+- D-1: MirBuilder::variable_map / BoxCompilationContext::variable_map BTreeMap 化案  
+  - どの構造を HashMap→BTreeMap 化するか、どのテスト（`mir_funcscanner_skip_ws_vm_debug_flaky` など）で決定性を確認するかを Phase‑25.x の設計メモとして書いておく。
+- D-2: dev 専用 / flaky テストの扱い方針  
+  - どのテストが dev ignore（手動実行用）で、いつ/何を満たしたら常時有効に戻すかを、このファイルと関連 README に明確に残す。
+
+このセクションは「すぐ実装する TODO ではなく、25.1〜25.x ラインで踏むべき設計タスク一覧」として使う予定だよ。  
+（静的 me-call 修正の参考メモはここに残しつつ、別セクションは整理済み）
 
 ## 3. Phase 25.1q — LoopForm Front Unification（DONE / follow-up 別タスクへ）