docs(joinir): Update architecture docs for Phase 179-B completion

Phase 179-B Task 7: Document PatternPipelineContext in architecture
overview and record completion in CURRENT_TASK.md.

Changes:
- joinir-architecture-overview.md: Add PatternPipelineContext section
  - Document "解析済みコンテキスト箱" design philosophy
  - Explain analyzer-only dependencies and pattern-specific variants
  - Add design principles (Pure analysis container, Option<T> patterns, SSOT)
- CURRENT_TASK.md: Add Phase 179-B completion summary
  - Record all 7 tasks and their outcomes
  - Document line reduction: P1/P3 11%, P2 1.5%, P4 1.9%
  - Note design constraints for Pattern 2/4 complexity

Test Results:
- Pattern 1 (loop_min_while.hako): ✅ PASS
- Pattern 2 (joinir_min_loop.hako): ✅ PASS
- Pattern 3 (loop_if_phi.hako): ✅ PASS (sum=9)
- Pattern 4 (loop_continue_pattern4.hako): ✅ PASS (25)

All representative test cases pass with identical behavior.

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

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

CURRENT_TASK.md

@@ -98,6 +98,20 @@
         - Task 178-4: Legacy fallback コメント修正（LoopBuilder 削除済み反映）
         - **成果**: String loop は明示的エラー、numeric loop は正常動作維持
         - **注意**: グローバルテスト 79 件失敗は Phase 178 以前からの既知問題（別途対応）
+  - [x] **Phase 179-B: Generic Pattern Framework** ✅ (2025-12-08)
+        - Task 179-B-1: 設計ドキュメント作成（phase179-generic-pattern-framework.md）
+        - Task 179-B-2: PatternPipelineContext 実装（pattern_pipeline.rs）
+        - Task 179-B-3: Pattern 1 統一（168→149行, 11%削減）
+        - Task 179-B-4: Pattern 3 統一（168→149行, 11%削減）
+        - Task 179-B-5: Pattern 2 統一（517→509行, 1.5%削減）
+        - Task 179-B-6: Pattern 4 統一（422→414行, 1.9%削減）
+        - Task 179-B-7: テスト・ドキュメント更新（全代表ケース PASS）
+        - **成果**: 全パターン（P1/P2/P3/P4）で PatternPipelineContext 統一、
+                   前処理ロジック一本化、挙動不変（テスト全 PASS）。
+        - **設計原則**: Pure analysis container（解析のみ、emission なし）、
+                       Analyzer-only dependencies、Pattern-specific variants（Option<T>）。
+        - **注意**: Pattern 2/4 の複雑ロジック（Trim, carrier 解析）は inline 維持。
+                   将来 Phase 180+ で Trim module 化予定。
   - [ ] Phase 179+: JsonParser `_parse_array` / `_parse_object` など、残りの複雑ループを順次 P1–P5 の組み合わせで吸収していく。
         - String 連結ループは Phase 178 で Fail-Fast 化されたため、JoinIR string emit 対応が先に必要。
 

docs/development/current/main/joinir-architecture-overview.md

@@ -90,6 +90,19 @@ JoinIR ラインで守るべきルールを先に書いておくよ：
     - 全 Pattern 共通の初期化ロジック統一化（ループ変数抽出 + CarrierInfo 構築）。
     - 全パターンで boundary.loop_var_name を確実に設定し、SSA‑undef を防ぐ。
 
+- **PatternPipelineContext** (Phase 179-B)
+  - ファイル: `src/mir/builder/control_flow/joinir/patterns/pattern_pipeline.rs`
+  - 責務:
+    - 全 Pattern の前処理結果を格納する「解析済みコンテキスト箱」。
+    - CommonPatternInitializer + LoopScopeShapeBuilder の結果を統一的に保持。
+    - Pattern 1-4 の共通データ（loop_var_name, loop_var_id, carrier_info, loop_scope）を提供。
+    - Pattern 2/4 専用データ（condition_env, carrier_updates, trim_helper）は Option<T> で保持。
+    - **Analyzer-only dependencies**: 解析ロジックのみ依存、JoinIR emission ロジックは含まない。
+  - デザイン原則:
+    - Pure analysis container（前処理結果のみ保持、emission なし）
+    - Pattern-specific variants（Option<T> でパターン固有データ管理）
+    - Single source of truth（全パターンが同じ前処理経路を使用）
+
 - **JoinIRConversionPipeline** (Phase 33-22)
   - ファイル: `src/mir/builder/control_flow/joinir/patterns/conversion_pipeline.rs`
   - 責務: