f4ab5ca5f4
Consolidate dual entry points into unified NormalizationPlan system: Problem: - Dual entry points: try_normalized_shadow() + suffix_router_box - ~220 lines of duplicated pattern detection logic - Maintenance burden: changes required in two places Solution: - New normalization module with Box-First architecture - NormalizationPlanBox: Single source of truth for pattern detection - NormalizationExecuteBox: Single source of truth for execution Implementation: - src/mir/builder/control_flow/normalization/ (new module) - README.md: Design contract (SSOT) - plan.rs: NormalizationPlan data structure - plan_box.rs: Pattern detection (7 unit tests) - execute_box.rs: Execution logic - mod.rs: Module integration Refactored files: - routing.rs::try_normalized_shadow(): 165 → 87 lines (-78 lines) - suffix_router_box::try_lower_loop_suffix(): 258 → 116 lines (-142 lines) Pattern support maintained: - Phase 131: loop(true) only (consumed: 1) - Phase 132: loop + single post (consumed: 3) - Phase 133: loop + multiple post (consumed: 2+N) Box-First principles: - Plan Box: Detection responsibility only - Execute Box: Execution responsibility only - README.md: Contract documentation (SSOT) - Clear separation enables independent testing Test results: - cargo test --lib: 1186 PASS (10 new tests added) - Phase 133 VM/LLVM EXE: PASS (exit code 6) - Phase 132 LLVM EXE: PASS (exit code 3) - Phase 131 LLVM EXE: PASS (exit code 1) Benefits: - Code duplication eliminated (~220 lines) - Single source of truth for normalization decisions - Improved maintainability and testability - Future-proof extensibility (easy to add new patterns) Default behavior unchanged: Dev-only guard maintained Related: Phase 134 normalization infrastructure improvement 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Phase ドキュメント
このフォルダは、実装フェーズ（Phase 131, Phase 33 等）ごとの詳細記録を保管します。
現在の Phase
- Phase 132: Exit Values Parity (VM == LLVM)
- Phase 133: Promoted carrier join_id（Trim）修正
- Phase 134: Plugin loader best-effort loading
- Phase 135: ConditionLoweringBox allocator SSOT（ValueId 衝突の根治）
- Phase 136: MirBuilder Context SSOT 化（+ ValueId allocator 掃討）
- Phase 137–141: Loop Canonicalizer（前処理 SSOT）導入（Phase 137 フォルダに統合して記録）
- Phase 91–92: Selfhost depth‑2 coverage（P5b escape recognition → lowering）
- Phase 94–100: P5b escape E2E / Trim policy / pinned + accumulator（VM/LLVM EXE parity）
- Phase 102: real-app read_quoted loop regression（VM + LLVM EXE）
- Phase 103: if-only regression baseline（VM + LLVM EXE / plan）
- Phase 113: if-only partial assign parity（片側代入の保持 merge）
- Phase 107–109: real-app depth-scan / policy router SSOT / error hint SSOT
- Phase 110–112: ControlTree / StepTree（構造SSOT, dev-only）※設計SSOTは
../design/control-tree.md
Phase フォルダ構成（推奨）
phases/phase-131/
├── README.md (Phase 全体概要)
├── 131-03-llvm-lowering-inventory.md (LLVM 部分のテスト・検証)
├── 131-11-case-c-summary.md (Case C 実装サマリー)
└── phase131-11-case-c-root-cause-analysis.md (根本原因分析)
参照方法
- 現在の Phase を知りたい → ../10-Now.md
- 該当 Phase を詳しく知りたい → フォルダを開く
- 設計背景を知りたい → ../design/
- 調査ログを見たい → ../investigations/
Phase 命名規則
- ファイル名:
phase-<N>-<title>/(例:phase-131/) - 文書名:
<N>-<NN>-<topic>.md(例:131-11-case-c-summary.md)- Phase 番号で自然にソート可能
- 同一 Phase 内で段階的に追跡可能
作成ルール（SSOT）
詳しくは ../DOCS_LAYOUT.md を参照。
- ✅ 置き場所:
phases/phase-<N>/配下のみ - ✅ 内容: Phase の実装記録・進捗・チェックリスト・検証結果
- ❌ 避けるべき: 複数 Phase で参照される設計・アーキテクチャ（→ design/ へ）
最終更新: 2025-12-18