# 開発進捗ログ - [x] **環境整備（テンプレート同期・docs 番号修正）** (2026-06-06): プログラミングテンプレートを初回同期（エージェント/コマンド/GUIDE_05 等を取り込み）し、docs カテゴリ番号を命名規則（GUIDE_03）に整合（PLAN→03 / SPEC→04 / TECH→05）。リモートをセルフホスト Git から GitHub（rintoHasegawa/TIASshot, Private）へ移行。 - [x] **CameraBase のリファクタリング（責務分離 Phase 1〜4）** (2026-06-06): 肥大化していた `CameraBase` の責務を分離。`Cameras/`・`UI/`（Phase1）、色補正→`ColorCorrection/ColorCorrector`（Phase2）、チャート検出→`ChartDetection/ChartDetector`（Phase3）、ファイル I/O・サウンド→`Utils/IoUtil`（Phase4）。 - 動機: `CameraBase` にカメラ制御・チャート検出・色補正・ファイル I/O・サウンドが集中していた。 - 方針: **挙動は一切変えない**（PLAN_01）。各フェーズで計算/検出/I-O ロジックが元コードと文字単位で一致することを確認し、ビルドは全フェーズ 0 エラー 0 警告。 - 設計判断（PLAN_01 当初案からの変更）: 派生クラス（IScam/Lucam）と共有する状態に結合するメンバーは分離先に移さず `CameraBase` に残した。具体的には `UpdateRate`/`GetRatio`（ゲイン補正）、`SetSaveFolder`/`WriteInfo`/`SetInfo`（`_saveFolder`/`_ShotInfo` 経由）。後者 2 つは純粋ロジックのみ `IoUtil` へ移し、`CameraBase` 側は薄いラッパーとした。 - 回帰検証: リファクタ前に実機で基準データ（`_基準データ_refactor前/`、特に `TCC_RGB.csv`）を取得して保管。実機の再校正は物理入力が変わり数値が一致しないため、回帰は「同一入力での計算一致」＋「コードの文字単位一致」で担保した。 - [x] **CameraBase リファクタリング Phase 5（IScam/Lucam の重複処理を集約）** (2026-06-07): Phase 1〜4 後も派生クラスに残っていたプレビュー/校正フローと撮影ループの重複を、`CameraBase` のテンプレートメソッドに集約。カメラ固有のゲイン反映・フレーム取得・撮影前後処理のみ抽象メソッドで派生クラスに残した。 - 方針: **挙動は一切変えない**。自動テスト不可（ハードウェア/ネイティブ/WinForms 密結合）のため、ビルド 0/0 ＋ diff の処理順序目視一致 ＋ 実機撮影確認で担保。 - 設計判断: `IScam` の撮影前後処理（Sink 切替・最初のフレーム捨て）は `Lucam` と実行順序が異なるため共通骨格に取り込まず派生側に残した（順序維持を優先）。 - 失敗パターン: 校正収束時のデバッグログを撮影情報記録とまとめて `CalcTcc` の後に移したことで元の「ログ→CalcTcc→記録」順がずれた → テストで検出し、`CalcTcc` 前に呼ぶ専用フックへ分離して厳密な順序一致を回復。 - [x] **PLAN_02 優先度1: `_shots` のスレッドセーフ化（連続撮影クラッシュ修正）** (2026-06-07): 連続撮影で4枚以上取得するとたまにクラッシュする不具合を修正。根本原因は `_shots`（`List`）を撮影スレッドと保存スレッドで無保護に共有していたこと（容量拡張時のリサイズ競合・TOCTOU）。 - 設計判断: `ConcurrentQueue` 単体ではなく `BlockingCollection` を採用し生産者-消費者パイプライン化。`GetConsumingEnumerable`/`CompleteAdding` で `Thread.Sleep` ポーリング待機を排除。保存連番は独立カウンタで従来順序を維持。 - 堅牢化: 撮影ループを `try/finally` で包み、例外時も `CompleteAdding()` を必ず呼んで消費者（保存スレッド）の永久ブロックを防止（例外はそのまま伝播。ユーザー向けエラー表示・撮影中断は優先度3 で別途）。 - 回帰検証: 自動テスト不可（ハードウェア依存）のため、ビルド 0/0 ＋ 実機（校正・連続撮影・複数回・連番一致）確認 ＋ 設計レビューで担保。 - [x] **テスト方針（GUIDE_08）整備** (2026-06-07): 立ち上げフローの規約整備フェーズが未着手だったため、品質管理の土台としてテスト方針を策定。ハードウェア結合層（カメラ/UI/スレッド）と純粋ロジック層を分け、後者を NUnit で自動テスト、前者をビルド＋手動＋実機回帰で担保する方針。 - 動機: `/implement` のテストフェーズが毎回「テスト不可」で終わっていたが、実態は純粋ロジック層（`ColorCorrector` 等）にテストプロジェクトを立てていなかっただけ、という認識のズレを是正。 - 後段: テストプロジェクト（`TIASshot.Tests`, NUnit / x64 / .NET Framework 4.8）の立ち上げと `ColorCorrector`・`Config`・`IoUtil` 等の初期テスト作成（次ステップ）。 - [x] **エラーハンドリング方針（GUIDE_09）整備** (2026-06-07): 既存の実装パターン（`ErrorMsg`＋`bool` 返却・`MessageBox`・`Debug.WriteLine`・`ShowMessage`）を土台に，エラーの分類（起動時致命／処理中の回復可能／プログラミングエラー）・処理方法・ログ方針を軽量に標準化。 - 動機: PLAN_02 優先度3（撮影中の例外をクラッシュさせずエラー表示・中断する修正）の前に方針を確定し，場当たり実装を避けるため。 - 設計判断: ログは `Debug.WriteLine` のみとし永続ログファイルは作らない（撮影現場での解析が必要になったら別途見直す）。空 `catch` 禁止・例外時のスレッド同期資源の `finally` 終端を明文化。 - 残: GUIDE_06 コーディング規約・GUIDE_07 ディレクトリ構造規則は未整備のまま（既存の de-facto 確立により優先度低）。