feat(joinir): Phase 248 - Normalized JoinIR infrastructure

Major refactoring of JoinIR normalization pipeline: Key changes: - Structured→Normalized→MIR(direct) pipeline established - ShapeGuard enhanced with Pattern2 loop validation - dev_env.rs: New development fixtures and env control - fixtures.rs: jsonparser_parse_number_real fixture - normalized_bridge/direct.rs: Direct MIR generation from Normalized - pattern2_step_schedule.rs: Extracted step scheduling logic Files changed: - normalized.rs: Enhanced NormalizedJoinModule with DevEnv support - shape_guard.rs: Pattern2-specific validation (+300 lines) - normalized_bridge.rs: Unified bridge with direct path - loop_with_break_minimal.rs: Integrated step scheduling - Deleted: step_schedule.rs (moved to pattern2_step_schedule.rs) New files: - param_guess.rs: Loop parameter inference - pattern2_step_schedule.rs: Step scheduling for Pattern2 - phase43-norm-canon-p2-mid.md: Design doc Tests: 937/937 PASS (+6 from baseline 931) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-12 03:15:45 +09:00
parent 59caf5864c
commit ed8e2d3142
32 changed files with 1559 additions and 421 deletions
--- a/docs/development/current/main/joinir-architecture-overview.md
+++ b/docs/development/current/main/joinir-architecture-overview.md
@ -987,7 +987,7 @@ JoinIR は Rust 側だけでなく、将来的に .hako selfhost コンパイラ
     - [x] 退行なし: Phase 190-196 テスト全 PASS ✅
   - 詳細: phase197-lightweight-loops-deployment.md

-7. **JsonParser/selfhost 実戦 JoinIR 適用状況** (2025-12-09 更新)
+7. **JsonParser/selfhost 実戦 JoinIR 適用状況** (2025-12-09 更新 → Phase 42 で棚卸し済み)

 | Function | Pattern | Status | Note |
 |----------|---------|--------|------|
@ -998,15 +998,15 @@ JoinIR は Rust 側だけでなく、将来的に .hako selfhost コンパイラ
 | `phase195_sum_count` | P3 | ✅ JoinIR OK | Phase 196 検証済み（multi-carrier）|
 | `loop_if_phi` | P3 | ✅ JoinIR OK | Phase 196 検証済み（single-carrier）|
 | `loop_min_while` | P1 | ✅ JoinIR OK | Phase 165 基本検証済み |
-| `_parse_number` | P2 | ⚠️ Deferred | ConditionEnv 制約（Phase 200+）|
-| `_atoi` | P2 | ⚠️ Deferred | ConditionEnv 制約（Phase 200+）|
+| `_parse_number` | P2 | ✅ JoinIR OK | Phase 245B-IMPL: P2-Mid（num_str LoopState キャリア）を Structured→Normalized(dev, direct) で固定 |
+| `_atoi` | P2 | ✅ JoinIR OK | Phase 246-EX で NumberAccumulation パターンとして統合（P2-Mid、Normalized: mini + real(dev, 符号対応) / canonical 準備中）|
 | `_parse_string` | P3 | ⚠️ Deferred | 複雑キャリア（Phase 195+ 拡張後）|
 | `_unescape_string` | P3 | ⚠️ Deferred | 複雑キャリア（Phase 195+ 拡張後）|
 | `_parse_array` | - | ⚠️ Deferred | 複数 MethodCall（Phase 195+）|
 | `_parse_object` | - | ⚠️ Deferred | 複数 MethodCall（Phase 195+）|

-**Coverage**: 7/13 ループ JoinIR 対応済み（54%）
-**Verification**: 4/7 ループ E2E PASS、3/7 structural/routing 確認済み
+**Coverage**: 9/13 ループ JoinIR 対応済み（約 69%）
+**Verification**: 代表ループ（P1/P2 Core + Trim/P3）については E2E テストで挙動確認済み。詳細なケースごとの状況は各 Phase ドキュメント（Phase 197/245/246 など）を参照。

 8. **JsonParser 残り複雑ループへの適用（Phase 198+, 200+）**
   - Phase 200+: ConditionEnv 拡張 (function-scoped variables) → _parse_number, _atoi
@ -1247,3 +1247,61 @@ Normalized JoinIR を 1 段挟むと、開発の手触りがどう変わるか

 - Normalized ブリッジを direct 実装と Structured 再構成の二段に分離し、shape_guard で direct 対象（P1/P2 ミニ + JsonParser skip_ws/atoi ミニ）だけを Normalized→MIR 直接生成に切り替えた。
 - direct 経路は `normalized_bridge::direct` に閉じ込め、非対応形状は `[joinir/normalized-bridge/fallback]` ログ付きで Structured 再構成経路に落とす構造に整理。dev テストでは direct 経路の VM 出力が従来経路と一致することを固定。
+
+### 3.15 Phase 37-NORM-JP-REAL – JsonParser `_skip_whitespace` 本体を dev Normalized で比較
+
+- JsonParser 本体の `_skip_whitespace` ループを Program(JSON) フィクスチャ化し、`shape_guard` で real 版を検知して Structured→Normalized→MIR(direct) の dev 経路に通すように拡張。`extract_value` は `&&`/`||` を BinOp として受け付けるようにした。
+- Break パターンのパラメータ推定を柔軟化（loop_var/acc/n が無いケースでも loop_var を優先し、acc が無ければ同一キャリアとして扱う）し、skip_ws real の構造で panic しないようにした。
+- tests/normalized_joinir_min.rs に `_skip_whitespace` real フィクスチャの VM 比較テストを追加し、env ON 時は Structured→Normalized→MIR(direct) と Structured 直経路の stdout が一致することを固定（env OFF は既存経路のまま）。
+- normalized_dev 用フィクスチャは `docs/private/roadmap2/phases/normalized_dev/fixtures/` に配置し、Program(JSON) から `AstToJoinIrLowerer` で読み込む運用に統一した。
+
+### 3.16 Phase 38-NORM-OBS – Normalized dev ログ/Fail‑Fast の整備
+
+- Normalized/JoinIR dev 経路のログカテゴリを `[joinir/normalized-bridge/*]` / `[joinir/normalized-dev/shape]` に統一し、`JOINIR_TEST_DEBUG` フラグ下のみ詳細を出すよう静音化。Verifier/Fail‑Fast メッセージも shape/役割付きに整理してデバッグ観測性を強化。
+
+### 3.17 Phase 40-NORM-CANON-TESTS – テスト側で Normalized を“当たり前”に通す
+
+- `normalized_dev_enabled()` と env ガードを整理し、P1/P2 ミニ + JsonParser skip_ws/atoi ミニ/real の代表テストは「Normalized dev 経路が必ず通る」前提にする（壊れたら normalized_* スイートが赤になる）。
+- 既存の Structured 直経路は比較用に維持しつつ、tests/normalized_joinir_min.rs 経路では Structured→Normalized→MIR(direct) が第一観測点になるように整備（本番 CLI は Structured→MIR のまま）。
+
+### 3.18 Phase 41-NORM-CANON-P2-CORE – Pattern2 コアケースの canonical Normalized 化
+
+- Pattern2 のコアセット（P2 ミニ + JsonParser skip_ws/atoi ミニ/real）について、JoinIR→MIR Bridge の既定を Normalized→MIR に寄せ、Structured→MIR は比較テスト用/フォールバック用の位置づけにする（Fail‑Fast ポリシーは維持）。
+- `shape_guard` で「Normalized 対応と宣言した P2 コアループ」は常に Normalized 経路を通すようにし、Normalized 側の invariant 破損は dev では panic、本番では明示エラーで早期検出する設計に寄せる。
+
+### 3.19 Phase 42-NORM-P2-INVENTORY – P2 コア/ミドル/ヘビーの棚卸し
+
+- JsonParser / selfhost で **現役の P2 ループ** を洗い出し、次の 3 クラスに整理した：
+  - **P2-Core**（すでに Normalized canonical なもの）
+    - test fixture 系: `loop_min_while` P2 ミニ, Phase 34 break fixture (`i/acc/n`)
+    - JsonParser 系: `_skip_whitespace` mini/real, `_atoi` mini
+    - これらは Phase 36–41 で **Structured→Normalized→MIR(direct)** が canonical になっており、`bridge_joinir_to_mir` でも優先的に Normalized 経路が選ばれる。
+  - **P2-Mid**（次に Normalized を当てる候補）
+    - JsonParser: `_parse_number`, `_atoi` 本体, `_atof_loop`
+    - いずれも Pattern2 Break で JoinIR(Structured) には載っており（Phase 245/246 系）、Normalized への写像は今後の拡張対象として扱う。
+  - **P2-Heavy**（複数 MethodCall / 複雑キャリアを持つもの）
+    - JsonParser: `_parse_string`, `_parse_array`, `_parse_object`, `_unescape_string`
+    - P2/P3/P4 が混在し、複雑なキャリアや MethodCall 多数のため、Phase 43 以降の後続フェーズで設計する。
+- P2-Core については Phase 41 で canonical Normalized 化が完了しており、Structured→MIR は比較テスト用 / フォールバック用の経路として扱う。
+- P2-Mid のうち、Phase 43 ではまず `_parse_number` を第 1 候補、`_atoi` 本体を第 2 候補として扱い、Normalized→MIR(direct) に必要な追加インフラ（EnvLayout 拡張 / JpInst パターン拡張）を段階的に入れていく前提を整理した。
+
+### 3.20 Phase 43-NORM-CANON-P2-MID – JsonParser 本命 P2（_parse_number/_atoi）への適用
+
+- JsonParser `_parse_number` / `_atoi` 本体の Pattern2 ループを、既存インフラ（DigitPos dual 値, LoopLocalZero, StepScheduleBox, ExprLowerer/MethodCall, Normalized ブリッジ）上で Structured→Normalized→MIR(direct) に載せる。
+- dev で Structured 直経路との VM 実行結果一致を固定した上で、段階的に「この関数だけ Normalized canonical」とみなすプロファイル/フラグを導入し、最終的に JsonParser P2 の canonical route を Normalized 側に寄せるための足場にする。
+- Phase 43-A（dev 専用）: `_atoi` 本体を Program(JSON) フィクスチャ `jsonparser_atoi_real` で Structured→Normalized→MIR(direct) に通し、Structured 直経路との VM 出力一致を比較テストで固定（符号あり/なしの簡易パスまで対応。canonical 化は後続フェーズで検討）。
+- Phase 43-C（dev 専用）: `_parse_number` 本体を Program(JSON) フィクスチャ `jsonparser_parse_number_real` で Structured→Normalized→MIR(direct) に通し、`num_str = num_str + ch` の LoopState キャリアを含めた状態で Structured 直経路との VM 出力一致を比較テストで固定。
+
+### 3.21 Phase 44-SHAPE-CAP – shape_guard の能力ベース化（計画）
+
+- 現状の shape_guard は `JsonparserSkipWsMini/Real`, `JsonparserAtoiMini/Real` など「関数名ベースの個別 shape」が増えつつあるため、将来的には:
+  - 「P2 / LoopParam1 / Carrier≤N / MethodCall パターン = このセット」のような **能力ベースの ShapeCapability テーブル** に寄せる。
+  - JsonParser/selfhost の各ループは「どの capability を満たしているか」を参照するだけにし、関数名ベタ書き依存を減らす。
+- この Phase では docs 上で API/テーブル設計を固め、コード側では shape_guard の内部表現を Capability 中心に書き換える前段として扱う。
+
+### 3.22 Phase 45-NORM-MODE – JoinIR モードの一本化（計画）
+
+- 現状は `normalized_dev_enabled()`, `NYASH_JOINIR_NORMALIZED_DEV_RUN`, `JOINIR_TEST_DEBUG` など複数の env/feature でモードを切り替えているため、将来的には:
+  - `JoinIrMode = { StructuredOnly, NormalizedDev, NormalizedCanonical }` のような enum を導入し、
+  - env/feature はこのモードの初期値を決めるだけに寄せる（コード側の `if`/分岐を減らす）。
+- この Phase では JoinIR パイプラインの「モード遷移図」と `JoinIrMode` API を docs で設計し、後続フェーズで実装に反映する計画を置いておく。
--- a/docs/development/current/main/phase181-jsonparser-loop-roadmap.md
+++ b/docs/development/current/main/phase181-jsonparser-loop-roadmap.md
@ -1,5 +1,8 @@
 # Phase 181: JsonParser 残りループ設計調査

+Status: Historical + Updated in Phase 42  
+Note: Phase 181 時点の設計調査に基づくドキュメントだよ。最新の P2 分類と JoinIR/Normalized 状態は、このファイル内の「Phase 42 時点の P2 インベントリ」と `joinir-architecture-overview.md` を SSOT として見てね。
+
 ## 概要

 JsonParser（`tools/hako_shared/json_parser.hako`）の全11ループを詳細に分析し、
@ -201,6 +204,34 @@ loop(i < len) {

 **実行可能性**: ✅ Phase 182+ で実装可能（Pattern2 Break、_atoi の後継）

+## Phase 42 時点の P2 インベントリ（JsonParser）
+
+Phase 42 では、上の 11 ループについて「P2 としてどこまで JoinIR / Normalized で扱えているか」を棚卸しして、P2-Core / P2-Mid / P2-Heavy の 3 クラスに整理したよ。
+
+### 1. 分類ポリシー
+
+- **P2-Core**: 既に Normalized→MIR(direct) まで実装され、Phase 41 で canonical route（既定経路）として扱っているループ群。
+- **P2-Mid**: JoinIR(Structured) には載っているが、Normalized はこれから本格対応する「次候補」のループ群。
+- **P2-Heavy**: MethodCall 多数・複雑キャリアなどの理由で、Normalized 対応は Phase 43 以降に送っている重めのループ群。
+
+### 2. JsonParser ループの現在ステータス（2025‑12 時点）
+
+| # | ループ | Pattern | P2 クラス | JoinIR 状態 | Normalized 状態 | 備考 |
+|----|--------|---------|-----------|-------------|-----------------|------|
+| 1 | _skip_whitespace | P2 / P5 Trim | P2-Core | ✅ JoinIR OK（Phase 173, 197, 245 系） | ✅ Normalized→MIR(direct) / canonical（Phase 37, 41） | mini / real の両方をフィクスチャ化して dev / canonical で比較済み |
+| 2 | _trim (leading) | P2 / P5 Trim | P2-Heavy | ✅ JoinIR OK（TrimLoopHelper 経由） | 未対応（P5 専用経路のまま） | Trim/P5 専用 lowerer で処理。Normalized 対応は将来検討 |
+| 3 | _trim (trailing) | P2 / P5 Trim | P2-Heavy | ✅ JoinIR OK | 未対応 | leading と同様に Trim/P5 ラインで運用 |
+| 4 | _parse_number | P2 Break | P2-Mid | ✅ JoinIR OK（Phase 245-EX） | ✅ dev Normalized→MIR(direct)（Phase 43-C、フィクスチャ `jsonparser_parse_number_real`。num_str は現状仕様のまま据え置き） | header/break/p 更新は JoinIR 経路に載せ済み。数値正規化は Phase 43 以降で拡張予定 |
+| 5 | _parse_string | P2/P4 | P2-Heavy | 部分的に JoinIR 対応（Pattern3/4 拡張後に対象） | 未対応 | return/continue・複数キャリアを含むため heavy クラス扱い |
+| 6 | _atoi | P2 Break | P2-Mid | ✅ JoinIR OK（Phase 246-EX） | ✅ dev Normalized→MIR(direct)（mini + 本体符号あり/なし、Phase 43-A） | P2-Core には `_atoi` mini fixture が入っている。本体は Phase 43 以降で canonical 化予定 |
+| 7 | _match_literal | P1 Simple | （P1） | ✅ JoinIR OK | Normalized 対応は P1 ラインで別途管理 | P1 simple なので P2 クラス分類の対象外。Phase 197 で JoinIR E2E 検証済み |
+| 8 | _parse_array | P4 Continue | P2-Heavy | ⚠️ Deferred（複数 MethodCall） | 未対応 | continue + MethodCall 多数のため heavy クラス。ConditionEnv/MethodCall 拡張後に扱う |
+| 9 | _parse_object | P4 Continue | P2-Heavy | ⚠️ Deferred | 未対応 | _parse_array と同種の heavy ループ |
+| 10 | _unescape_string | P4 Continue | P2-Heavy | ⚠️ Deferred | 未対応 | 複数キャリア + flatten を含む。Pattern3/4 拡張後の対象 |
+| 11 | _atof_loop | P2 Break | P2-Mid | JoinIR 対応候補（_atoi と同型） | 未対応 | `_atoi` 後継として P2-Mid 候補に分類。Phase 43 以降で `_atoi` 本体と一緒に扱う想定 |
+
+最新の canonical / dev Normalized 経路や Shape 判定ロジックの詳細は `joinir-architecture-overview.md`（Phase 35–41 セクション）を参照してね。
+
 ## Pattern × Box マトリクス（JsonParser全体）

 ```
--- a/docs/development/current/main/phase223-loopbodylocal-condition-inventory.md
+++ b/docs/development/current/main/phase223-loopbodylocal-condition-inventory.md
@ -1,5 +1,8 @@
 # Phase 223-1: LoopBodyLocal in Condition - Comprehensive Inventory

+Status: Historical（Phase 26-H 以降の Normalized / DigitPos 導入で一部内容が古くなっています）  
+Note: LoopBodyLocal が原因で Fail-Fast していたループの在庫を Phase 223 時点で一覧化したメモだよ。DigitPos 系などの一部ループはその後の Phase 224/26-H/34 系で解消済みなので、最新の対応状況は `joinir-architecture-overview.md` と Phase 42 の P2 インベントリを合わせて参照してね。
+
 ## Purpose

 This document inventories all loops that are currently **blocked** by the LoopConditionScopeBox Fail-Fast mechanism because they have `LoopBodyLocal` variables appearing in loop conditions (header, break, or continue).
--- a/docs/development/current/main/phase224-digitpos-condition-normalizer.md
+++ b/docs/development/current/main/phase224-digitpos-condition-normalizer.md
@ -1,5 +1,8 @@
 # Phase 224-E: DigitPos Condition Normalizer

+Status: Active（DigitPos 条件正規化ラインの設計メモ / 実装ガイド）  
+Scope: digit_pos → is_digit_pos Carrier / ConditionEnv / ExprLowerer の正規化経路の SSOT ドキュメントだよ。Phase 26‑H / 34 系の JsonParser `_parse_number` / `_atoi` でもこの設計を前提にしている。
+
 ## Problem Statement

 ### Background
--- a/docs/development/current/main/phase245b-jsonparser-num-str-carrier-design.md
+++ b/docs/development/current/main/phase245b-jsonparser-num-str-carrier-design.md
@ -1,5 +1,6 @@
-Status: Draft  
-Scope: `_parse_number` で `num_str` を Pattern2/P5 のキャリアとして扱うかどうかを決める設計フェーズ（コード変更なし）。
+Status: Implemented (Phase 245B-IMPL)  
+Scope: `_parse_number` で `num_str` を Pattern2/P5 のキャリアとして扱うかどうかを決める設計フェーズ（実装は Structured→Normalized dev フィクスチャで完了）。
+Notes: jsonparser_parse_number_real フィクスチャで `num_str = num_str + ch` を LoopState キャリアとして実装し、dev Normalized 比較テストで固定済み。

 # Phase 245B: JsonParser `_parse_number` の `num_str` キャリア設計

--- a/docs/development/current/main/phase245b-num_str-carrier-design.md
+++ b/docs/development/current/main/phase245b-num_str-carrier-design.md
@ -1,8 +1,9 @@
 # Phase 245B: num_str Carrier Design Document

-**Status**: Design Phase
+**Status**: Implemented (Phase 245B-IMPL)
 **Target**: `_parse_number` loop の `num_str` 文字列キャリア対応
 **Scope**: Pattern 2 (loop with break) + 既存インフラ活用
+**Notes**: jsonparser_parse_number_real フィクスチャを Structured→Normalized→MIR(direct) で実装し、`num_str = num_str + ch` を LoopState キャリアとして dev テスト固定済み。

 ---

--- a/docs/development/current/main/phase43-norm-canon-p2-mid.md
+++ b/docs/development/current/main/phase43-norm-canon-p2-mid.md
@ -0,0 +1,148 @@
+Status: Planned  
+Scope: Phase 43‑NORM‑CANON‑P2‑MID — JsonParser 本命 P2（`_parse_number` / `_atoi` 本体 / `_atof_loop`）を Normalized 基準に寄せるための事前設計メモ。
+Update (Phase 43-A): `_atoi` 本体を Program(JSON) フィクスチャ `jsonparser_atoi_real` で dev Normalized→MIR(direct) 経路に載せ、Structured 直経路との VM 出力一致を確認済み（符号あり/なしの簡易パスまで対応。canonical 化は後続で検討）。
+Update (Phase 43-C): `_parse_number` 本体を Program(JSON) フィクスチャ `jsonparser_parse_number_real` で dev Normalized→MIR(direct) 経路に載せ、Structured 直経路との VM 出力一致を dev テストで固定（num_str は現状仕様のまま据え置き）。
+
+# Phase 43‑NORM‑CANON‑P2‑MID 設計メモ（JsonParser P2‑Mid 向け Normalized 拡張）
+
+## 0. ゴールと前提
+
+- ゴール
+  - JsonParser の本命 P2 ループ（P2‑Mid）を、既存の Normalized インフラの延長で扱えるようにするための設計方針を固める。
+  - 特に `_parse_number` / `_atoi` 本体 / `_atof_loop` について、
+    - どのキャリア・body‑local を EnvLayout に載せるか
+    - どの JpInst / JpOp パターンが追加で必要か
+    - StepScheduleBox / DigitPos / NumberAccumulation との責務分担
+    を整理する。
+- 前提
+  - P2‑Core（P2 ミニ + JP skip_ws mini/real + JP atoi mini）は Phase 41 までで Normalized→MIR(direct) が canonical 済み。
+  - P2‑Mid は **JoinIR(Structured) までは載っているが Normalized は未対応** の状態（Phase 245/246 系）。
+  - 本メモは「設計レベル」で止め、実装・テスト追加は後続フェーズ（43 実装回）で扱う。
+
+---
+
+## 1. 対象ループと P2‑Mid クラスの整理
+
+- 対象とする P2‑Mid（JsonParser 側）
+  - `_parse_number`（数値文字列の収集 + digit_pos break）
+  - `_atoi` 本体（範囲チェック + digit_pos + NumberAccumulation）
+  - `_atof_loop`（構造的には `_atoi` と同型の浮動小数点版）
+- すべて Pattern2 Break で、既に JoinIR(Structured) には載っている：
+  - `_parse_number` → Phase 245‑EX で header / break / `p` 更新を Pattern2 に統合済み（`num_str` は当面対象外）。
+  - `_atoi` → Phase 246‑EX で DigitPos dual 値 + NumberAccumulation パターンとして JoinIR 経路に統合済み。
+  - `_atof_loop` → 設計上 `_atoi` と同型とみなし、P2‑Mid クラスに含める。
+- P2‑Core との差分
+  - P2 ミニ / skip_ws / atoi ミニに比べて：
+    - Carrier の本数（`p` + `result` + 場合によっては `num_str`）が増える。
+    - body‑local / Derived Carrier（`digit_pos`, `is_digit_pos`, `digit_value` 等）の依存関係が複雑。
+    - 一部で文字列連結（`num_str = num_str + ch`）や Range チェック（`"0" <= ch <= "9"`）が入る。
+
+---
+
+## 2. Normalized IR に必要な拡張（EnvLayout / JpInst / JpOp）
+
+### 2.1 EnvLayout / フィールド設計
+
+- P2‑Mid で EnvLayout に載せる候補
+  - LoopState キャリア
+    - `_parse_number`: `p`（必須）、`num_str`（Phase 43 では **オプション**、まず `p` 単独で正規化する案も許容）。
+    - `_atoi` 本体 / `_atof_loop`: `i`, `result`（NumberAccumulation キャリア）。
+  - Condition 専用 / FromHost
+    - `len` / `s` / `digits` などの不変値は ParamRole::Condition として EnvLayout 側に持たない（現状どおり）。
+  - Derived LoopState（DigitPos 系）
+    - P2‑Core で既に導入済みの `digit_value` / `is_digit_pos` と同じ方針：
+      - EnvLayout に「FromHost ではない LoopState キャリア」として載せる。
+      - host_slot を持たず、ExitBinding には出さない（ループ内部完結キャリア）。
+
+### 2.2 JpInst / JpOp 側の必要パターン
+
+- 既存の Normalized が既に扱っているもの
+  - `Let { dst, op: Const / BinOp / Unary / Compare / BoxCall, args }`
+  - `If { cond, then_target, else_target, env }`
+  - `TailCallFn` / `TailCallKont`（loop_step / k_exit のみ）
+- P2‑Mid で追加検証・明文化が必要なパターン
+  - `_parse_number`
+    - `substring` / `indexOf` の BoxCall パターン（P2‑Core でも使用済みだが、`num_str` 周辺の利用を含めてドキュメントで SSOT 化する）。
+    - 文字列連結 `num_str = num_str + ch` を
+      - 当面は「扱わない」（`num_str` を Carrier から外す）案
+      - もしくは `BinOp(Add)` として Normalized→MIR 直ブリッジに追加する案
+      のどちらにするかを Phase 43 実装メモで最終決定する。
+  - `_atoi` 本体 / `_atof_loop`
+    - Range チェック `ch < "0" || ch > "9"`：
+      - ExprLowerer / ConditionEnv 側で既に対応済みであれば、Normalized には Compare + BinOp(or) の形で入る。
+      - Normalized では追加の JpOp は不要（Compare / BinOp を利用）。
+    - NumberAccumulation パターン：
+      - Structured 側では `UpdateRhs::NumberAccumulation` として扱っているので、
+        - Normalized → MIR 直ブリッジ側で「Mul + Add + digit_value」の形を既に対応済み。
+      - Phase 43 では `_atoi` 本体 / `_atof_loop` でも同じシーケンスになることを前提とし、JpInst 種別追加は行わない。
+
+---
+
+## 3. StepScheduleBox / DigitPos / NumberAccumulation の役割分担
+
+### 3.1 StepScheduleBox（評価順）の適用範囲
+
+- Phase 39 で導入した StepScheduleBox（Pattern2 用）は、P2‑Mid に対しても「どの StepKind をどの順番で評価するか」を決める SSOT として使う。
+- `_parse_number` / `_atoi` 本体 / `_atof_loop` では、以下のようなフラグを想定：
+  - `has_digitpos_body_local`（DigitPos 二重値を使うか）
+  - `has_number_accumulation`（結果キャリアに Mul+Add があるか）
+  - `has_bodylocal_break`（break 条件が body‑local に依存するか）
+- StepScheduleBox は、これらのフラグだけを見て
+  - 標準 P2: `[HeaderCond, BreakCheck, BodyInit, Updates, Tail]`
+  - DigitPos / atoi 系: `[HeaderCond, BodyInit, BreakCheck, Updates, Tail]`
+  など、評価順のバリエーションを返す「薄い箱」のまま保つ。
+- Pattern2 lowerer / Normalized 変換側は、この StepSchedule に従って
+  - header 条件
+  - body‑local init（DigitPos / Range check 等）
+  - break 条件
+  - carrier 更新（NumberAccumulation / i++ 等）
+  を「並べるだけ」にし、条件式の詳細や body‑local の構造には踏み込まない。
+
+### 3.2 DigitPos / NumberAccumulation との接続
+
+- DigitPos 系
+  - `digit_pos` → `is_digit_pos` / `digit_value` の二重値設計は、P2‑Core と同じく「LoopState キャリア（FromHost なし）」として EnvLayout に載せる。
+  - ExitBinding には出さず、Normalized→MIR 直ブリッジでも Loop 内部だけで完結させる。
+  - Break 条件 `digit_pos < 0` は Phase 224 の DigitPosConditionNormalizer（AST→`!is_digit_pos`）を前提にし、Normalized 側は `!is_digit_pos` という bool 条件だけを受け取る。
+- NumberAccumulation 系
+  - Structured 側の LoopUpdateAnalyzer / CarrierUpdateEmitter が `result = result * 10 + digit_value` パターンを `UpdateRhs::NumberAccumulation` として検出・JoinIR 生成済み。
+  - Normalized→MIR 直ブリッジは、P2‑Core と同じ Mul + Add シーケンスで MIR を吐く設計を維持し、P2‑Mid でも追加ロジックを増やさずに流用する。
+
+---
+
+## 4. Bridge / ShapeGuard / canonical 切り替え方針
+
+- ShapeGuard 拡張
+  - 既存の P2‑Core 判定（P2 ミニ / skip_ws mini/real / atoi mini）に加えて、
+    - `_parse_number` 本体
+    - `_atoi` 本体
+    - `_atof_loop`
+    を P2‑Mid として検出できる Shape 種別を追加する（例: `ShapeKind::JsonparserParseNumber`, `ShapeKind::JsonparserAtoiCore`）。
+  - Phase 43 実装フェーズでは、まず P2‑Mid ループを **dev only** の Normalized 対象にする（canonical 切り替えは Phase 43 後半〜Phase 44 相当で検討）。
+- Bridge 側の経路
+  - `bridge_joinir_to_mir` の入口で：
+    - P2‑Core: 既に canonical Normalized→MIR(direct)（Phase 41 の状態を維持）。
+    - P2‑Mid: `normalized_dev_enabled()` が true のときに限り Structured→Normalized→MIR(direct) を試し、テストで Structured 直経路と比較。
+  - Fail‑Fast 方針
+    - P2‑Mid では「Normalized が未対応の領域」がまだ多いため、
+      - dev / debug ビルドでは invariant 破壊・未対応命令で panic（Normalized 実装の穴を早期検出）。
+      - release / canonical OFF 時は Structured→MIR 直経路に落とす（サイレントフォールバックではなく「Normalized をそもそも使わない」構成にする）。
+
+---
+
+## 5. テストと完了条件（Phase 43 実装フェーズ向けメモ）
+
+- テスト戦略（概要）
+  - `_parse_number`:
+    - 代表ケース（"42", "7z" など）で
+      - Structured→MIR→VM
+      - Structured→Normalized→MIR(direct)→VM
+      の stdout / RC を比較する dev テストを追加。
+    - `num_str` をまだ Normalized キャリアに載せない場合でも、「p / break 条件 / DigitPos 周り」が齟齬なく動くことを確認する。
+  - `_atoi` 本体 / `_atof_loop`:
+    - 既存の `_atoi` mini dev fixture と同じ観点で、NumberAccumulation / DigitPos / Range check が Normalized 経路で再現できるかをチェック。
+    - Mini / 本体 / `_atof_loop` が同じ normalized helper / bridge ロジックを共有できることを確認する。
+- 完了条件（Phase 43 実装のためのチェックリスト）
+  - EnvLayout / JpInst / JpOp / StepScheduleBox / DigitPos / NumberAccumulation の役割分担が本メモの通りに整理されている。
+  - P2‑Mid（`_parse_number` / `_atoi` 本体 / `_atof_loop`）に対して、どこまでを Phase 43 で扱い、どこから先を後続フェーズに回すかの線引きが明文化されている。
+  - `joinir-architecture-overview.md` の Phase 43 セクション（3.20）と、この設計メモの内容が矛盾していない。