hakorune/CURRENT_TASK.md

Current Task

このファイルは「いま何に集中しているか」と「次にやり得る候補」だけを書く軽量ビューだよ。
詳細ログや過去フェーズの記録は docs/development/current/main/ 以下の各 phase-*.md と
joinir-architecture-overview.md を真実のソースとして扱うことにするね。

---

🎯 今フォーカスしているテーマ（2025-12-10 時点のスナップショット）

0. Phase 231 完了 ✅: ExprLowerer パイロット実装（Pattern2 条件式限定）

目的: Phase 230 で決めた ExprLowerer / ScopeManager の設計が、実際の JoinIR コードに素直に乗るかを検証。

実装内容:

• ScopeManager trait: 変数参照を統一的に扱う trait（ConditionEnv / LoopBodyLocalEnv / CapturedEnv / CarrierInfo を統合）
• Pattern2ScopeManager: Pattern2 専用の薄いラッパー（promoted_loopbodylocals 対応含む）
• ExprLowerer: 式 lowering を1箇所に集約（パイロット段階）
• Pattern2 統合: break 条件の pre-validation として ExprLowerer を試行（fallback 完備）

成果:

• ✅ 全 Pattern2 テスト PASS（最新: cargo test --release で 894/897 緑、残りは array_filter 系 3 件のみ）
• ✅ ExprLowerer が簡単な条件式（i >= 5 など）を正常に検証
• ✅ 複雑なパターンは UnsupportedNode エラーで legacy path へ fallback（Fail-Safe 設計）
• ✅ 箱化・モジュール化の原則に準拠（ScopeManager は trait、ExprLowerer は再利用可能）

次のステップ:

• Phase 232 ✅: 7 FAIL の棚卸し（P0/P1/P2 分類）完了
• Phase 233: loop_update_summary テストを AST ベース API に揃えて Phase 219 以降の設計に追随（テスト負債の解消）
• Phase 234+: MethodCall / NewBox など General context 対応（ExprLowerer 拡張案）

1. JoinIR ループ基盤の状態

• LoopBuilder は完全削除済みで、ループは JoinIR Pattern1–4（while / break / if‑PHI / continue）＋ P5(Trim系) で統一。
• JoinValueSpace / LoopHeaderPhi / ExitLine / JoinInlineBoundary / JoinIRVerifier まで含めた 「Loop → JoinIR → MIR → return」のパイプラインは、代表パターンと JsonParser ミニケースで安定している。
• Phase 213–217 完了: P3(if‑PHI) は if‑sum 最小パターン（phase212_if_sum_min.hako）まで AST ベースで一般化済みで、 Phase 215 で ExprResult の出口契約を Pattern2 と同じ形に揃えて RC=2 まで通すようになった。 Phase 216 で selfhost 側の production test も検証完了。 Phase 217 でマルチキャリア if‑sum（sum+count）も追加実装0行で動作確認 - Phase 195/214/215 の箱組合せで完璧動作。
• Phase 218 調査完了: JsonParser-style if‑sum 適用を試行し、パターン認識のギャップを特定。
  • Phantom count carrier が誤検出され、is_if_sum_pattern() が false を返す根本原因を解明。
  • AST ベース lowerer は実装済みだが、carrier 検出ロジックの問題で起動されていないことを確認。
• Phase 219 完了: Phantom carrier bug 修正 - 名前ベース推定削除、代入ベース検出に統一。
  • analyze_loop_updates_from_ast() で assignment-based detection 実装
  • RHS structure classification + name heuristic で CounterLike/AccumulationLike 判定
  • phase212 で AST lowerer 正常起動確認（is_simple_if_sum_pattern() = true）
  • phase218/217 は Phase 214+ (condition variable support) でブロック中
• Phase 220 完了 ✅: P3 if-sum ConditionEnv 統合 + ExprResult routing 統一化
  • Phase 220-C: condition variable remap fix（condition_bindings 事前登録）
  • Phase 219-fix: ConditionPatternBox で複雑条件フィルタリング（i % 2 == 1 → legacy mode）
  • Phase 220-D: loop 条件変数サポート（loop(i < len) → ConditionEnv 経由で解決）
  • Phase 221: ExprResult routing 実装（expr_result → carrier PHI dst）
  • Phase 221-R: ExprResultResolver Box 箱化（Phase 33 パターン準拠、-37 行削減）
  • 成果: phase212_if_sum_min.hako → RC=2 達成、P3/P2 の expr-result 経路完全統一
  • 次フェーズ: P3/P2 expr-result 経路が揃ったので、JsonParser/selfhost への実戦適用フェーズへ移行
• Phase 221 実戦投入完了 ✅: JsonParser 数値ループの棚卸し・制約整理
  • 実戦 OK: 5/9 テスト PASS（NumberAccumulation, if-sum, captured vars）
  • 制約発見: 3種の既知制約を整理（LoopBodyLocal in condition, MethodCall whitelist, if condition pattern）
  • 次の候補: LoopBodyLocal 条件対応（Pattern 5+ 拡張）、if condition 左辺変数対応
• Phase 222 完了 ✅: If Condition 正規化（左リテラル/変数同士対応）
  • ConditionPatternBox 拡張: normalize_comparison() で 0 < i → i > 0 正規化
  • if-sum 統合: extract_loop_condition() を正規化ベースに変更
  • テスト: phase222_if_cond_left_literal_min.hako → RC=2 達成
  • 制約解決: Phase 221 の "if condition pattern" 制約を解消
• Phase 223 完了 ✅: LoopBodyLocal Condition Promotion（条件昇格システム）
  • Phase 223-1 完了 ✅: 包括的棚卸（Category A: 6 patterns, Category B: 1, Category C: 2）
  • Phase 223-2 完了 ✅: API レベル設計（LoopBodyCondPromoter Box, P0: Pattern4/_skip_whitespace 向け）
    • 既存箱との役割整理（LoopConditionScopeBox, LoopBodyCarrierPromoter, TrimLoopLowerer）
    • Promotion API 定義（ConditionPromotionRequest/Result）
    • Pattern4 統合方針（promotion-first, Fail-Fast fallback）
  • Phase 223-3 完了 ✅: 実装完了（LoopBodyCondPromoter 抽出, Pattern4 統合, E2E テスト）
    • LoopBodyCondPromoter Box 実装（loop_body_cond_promoter.rs）
    • extract_continue_condition(): body 内 if 文から continue 条件を抽出
    • Pattern4 への統合: LoopBodyLocal 昇格成功時に lowering 続行（以前は Fail-Fast）
    • E2E テスト: apps/tests/phase223_p4_skip_whitespace_min.hako（昇格成功 → Pattern4 lowering 続行確認）
    • 5 unit tests PASS、ビルド成功、ドキュメント更新完了
  • 残課題: JoinIR Trim lowering（Phase 172+）で完全な RC 正確性を実現する必要あり
• Phase 223.5 完了 ✅: LoopBodyCondPromoter の Pattern2 統合
  • Pattern2 統合: header/break 条件両方を分析し昇格を試みる
  • A-4 テスト追加: apps/tests/phase2235_p2_digit_pos_min.hako（cascading LoopBodyLocal パターン → Fail-Fast 確認）
  • error_messages.rs 拡張: format_error_pattern2_promotion_failed() 等追加
  • 成果: Pattern2/4 両方から LoopBodyCondPromoter を使う統一構造が完成
• Phase 224: DigitPosPromoter を本線統合（Two-tier: Trim→DigitPos）し、ConditionAlias で digit_pos 条件を carrier 参照にブリッジ（詳細: PHASE_224_SUMMARY.md）。
• Phase 224-E: DigitPosConditionNormalizer で digit_pos < 0 → !is_digit_pos に正規化し、phase2235_p2_digit_pos_min.hako を RC=0 のインフラ確認テストとして固定。
• Phase 225: body-local init MethodCall を CoreMethodId メタ駆動に一本化し、substring/indexOf whitelist のハードコードを除去。
• Phase 226: cascading LoopBodyLocal init を ConditionEnv→LoopBodyLocalEnv 優先で解決し、digit_pos = digits.indexOf(ch) を通過（残課題: 旧 SSA-undef）。
• Phase 227–228: CarrierRole(ConditionOnly) + CarrierInit(BoolConst(false)) で header PHI entry/ExitLine 再接続を整理し、Pattern4 continue バグも封じ込め。
• Phase 223–228 リファクタ調査: ConditionAlias 冗長性や ConditionOnly フィルタ重複を棚卸し、phase223-228-refactoring-opportunities.md / phase229-action-plan.md に統合。
• Phase 229: digit_pos P2 ラインを「インフラ完成」で固定し、数値ロジックは次フェーズへ送る（RC=0 は仕様）。
• Phase 230: ExprLowerer/ScopeManager 設計（docs のみで、条件式/Init/Update lowering を統合するためのインターフェース設計）。
• Phase 232: 残り 7 FAIL を「箱 / パターン / レイヤ」ごとに棚卸しし、P0/P1/P2 に分類して次フェーズ（core 修正かパターン拡張か）を選びやすくする設計フェーズ（基本 docs のみ、ArrayExtBox.filter 系 3 件を P2 に残す整理）。
• Phase 233: loop_update_summary テストを AST ベース API に刷新し、deprecated wrapper 依存の FAIL を解消（7→3 FAIL）。
• Phase 234: ArrayExtBox.filter 系 3 FAIL について、P3 if-PHI で正式サポートするか当面 Fail-Fast として残すかを docs ベースで決める設計フェーズ（実装は後続 Phase 24x 以降に送る）。
• Phase 235: ExprLowerer/ScopeManager のユニットテストを追加しつつ、Pattern2 の break 条件に validation-only で組み込み、既存の condition lowering と挙動が変わらないことを確認するパイロットフェーズ。
• Phase 236-EX: Pattern2 break 条件の lowering を ExprLowerer/ScopeManager 経由の本番経路に切り替え、全 E2E テストの挙動（RC/ログ）が従来と一致するかを確認するフェーズ（差分が出た場合は docs に記録して設計見直しに回す）。
• Phase 237-EX: JsonParser/selfhost のループ条件・break/continue 条件を棚卸しし、ExprLowerer/ScopeManager で優先対応すべきパターンをカタログ化する設計フェーズ（コード変更なし）。
• Phase 238-EX: ExprLowerer/ScopeManager/ConditionEnv/LoopBodyLocalEnv/UpdateEnv の責務と参照範囲を文書化し、「誰がどこまで見てよいか」を SSOT として固定するガイドライン整備フェーズ（コード変更なし）。***

2. JsonParser / Trim / selfhost への適用状況

• Trim 系:
  • _trim / _skip_whitespace の P5 パイプライン（LoopBodyLocal 昇格 → bool carrier → TrimLoopLowerer）は
    JoinIR→MIR まで end‑to‑end で安定動作。
• JsonParser:
  • 11 ループ中、基本形（P1/P2/P5 相当）の 7 本は JoinIR インフラ上で理論的にカバー可能と確認済み。
  • すでに JoinIR で実戦投入できているのは _skip_whitespace / _trim* / _match_literal / _atoi_min / _parse_number_min。
  • 残りの複雑ループ（_parse_array / _parse_object / _unescape_string / 本体 _parse_string など）は
    「LoopBodyLocal + 複数 MethodCall + 複数フラグ」という組み合わせで、今後の拡張対象として整理済み。
• selfhost (.hako):
  • selfhost stage‑3 depth‑1（Rust→.hako）までは JoinIR 経路で代表ケースが緑。
  • depth‑2（.hako 側で JSON/MIR を読み、JoinIR/MIR/VM/LLVM に流すライン）は、JsonParser 側のループカバレッジ拡張が前提。

3. 直近で意識しておきたい設計の芯

• Loop パターン空間は有限で整理済み:
  • P1: Simple While
  • P2: Break
  • P3: If‑PHI（単一/複数キャリア）
  • P4: Continue（then/else‑continue 正規化込み）
  • P5: LoopBodyLocal 昇格（Trim/JsonParser 用の部分適用）
• 「増やすべき」は新しい Pattern ではなく、既存 Pattern の前処理箱:
  • BoolExprLowerer / ConditionEnv / LoopConditionScopeBox / LoopBodyCarrierPromoter / TrimLoopHelper / ComplexAddendNormalizer / LoopBodyLocalEnv / UpdateEnv などで
    条件式とキャリア更新を吸収し、Pattern1–4 は「ループ骨格」に専念させる方針。
• Fail‑Fast 原則:
  • JoinIR 以外のループ lowering パスは存在しない（LoopBuilder は削除済み）。
  • 「わからないパターン」は必ず [joinir/freeze] 系の明示エラーにして、サイレントフォールバックはしない。

---

✅ 最近まとまった大きな塊（超要約）

ここ半年くらいで終わっている主な塊だけをざっくり書くね。
細かいタスク・バグ票・議論は phase-XXX*.md に全部残っているので、必要になったときだけそちらを読む想定。

• LoopBuilder 削除ライン（Phase 180 前後）
  • LoopBuilder を dev‑only → hard freeze → 物理削除まで完了。
  • Loop lowering の SSOT を JoinIR に一本化。
• LoopPattern / Router ライン（Phase 170–179）
  • LoopFeatures / LoopPatternKind / PatternRouter / PatternPipelineContext を整備。
  • Pattern1–4 の検出・ルーティングを「構造ベース＋AST features」で統一（関数名ベタ書き依存を除去）。
• Exit / Boundary / ValueId ライン（Phase 172–205）
  • ExitMeta / ExitLineReconnector / JoinInlineBoundary(+Builder) / LoopHeaderPhiBuilder を箱化。
  • JoinValueSpace（Param/Local 領域）＋ PHI 契約 Verifier で ValueId 衝突と PHI 破損を根治。
• P5(Trim/JsonParser) ライン（Phase 171–176, 173–175, 190–193）
  • LoopBodyLocal 昇格パイプライン（Trim, _skip_whitespace, _parse_string 簡易版）を構築。
  • StringAppend / NumberAccumulation / Complex addend 正規化など、更新式まわりの箱を揃えた。
• P3 (If‑PHI) 汎用化ライン（Phase 195–196, 212–215）
  • multi‑carrier P3 の JoinIR 生成を整理。
  • Select 展開 / JoinIR→MIR ブリッジ側のバグ（PHI inputs, back‑edge, 二重 remap）を修正。
  • if‑sum 最小パターンを AST ベースで一般化し、ExprResult Exit 契約まで Pattern2 と揃えた。

このあたりが「JoinIR ループ基盤の芯」で、以降の Phase は JsonParser/selfhost の各ループへの適用フェーズ、という位置づけだよ。

---

🧭 これからの候補（まだ「やる」とは決めていないメモ）

ここは「やることリスト」ではなく「今後やるとしたらこの辺」というメモにする。
実際に着手するタイミングで、別途 Phase/タスクを切る想定だよ。

1. JsonParser 残りループへの JoinIR 展開
   • _parse_array / _parse_object / _unescape_string / 本体 _parse_string など。
   • 既存の P2/P3/P4＋P5 パイプラインをどこまで延ばせるかを検証するフェーズ。
2. selfhost depth‑2 ラインの再開
   • .hako 側で Program/MIR JSON を読んで JoinIR/MIR/VM/LLVM に流すライン。
   • JsonParser 側のカバレッジが上がったあとに、小さいループから順に移植する。
3. JoinIR Verify / 最適化まわり
   • すでに PHI/ValueId 契約は debug ビルドで検証しているので、 必要なら SSA‐DFA や軽い最適化（Loop invariant / Strength reduction）を検討。

---

📎 このファイルの運用ルール（自分向けメモ）

• 過去フェーズの詳細な ToDo/Done リストは CURRENT_TASK には書かない。
  代わりに phase-XXX*.md と joinir-architecture-overview.md を SSOT として維持する。
• CURRENT_TASK は「あくまで最新のフォーカスと次の候補だけ」に絞る。
  目安として このファイル自体は 2〜3画面程度（〜300行以内） に収める。
• 新しい大フェーズを始めたら：
  1. まず docs 配下に phase-XXX-*.md を書く。
  2. CURRENT_TASK には「そのフェーズの一行要約」と「今のフォーカスかどうか」だけを書く。

Phase 230+: digit_pos / number-parsing を JsonParser 本体に統合し、num_str / p など数値意味論を詰めるフェーズだよ。