# 開発進捗ログ

<!--
本ファイルは追記型のフル進捗ログ．

- 最新エントリは下に追記する（時系列順．古いものが上，新しいものが下）
- CLAUDE.md の「開発進捗」セクションは最新 1 行のみ（上書き運用）
- 詳細・失敗パターン・設計判断はすべて本ファイルに残す
- 書式・運用ルールは .claude/rules/progress-log.md を参照
  （本ファイルの編集時に自動ロードされる）
-->

- [x] **プロジェクト立ち上げ（GUIDE_01）**: 要件定義・技術選定・環境構築・仕様設計・規約整備・開発計画を `chore/project-setup` で完了（2026-10-02）．solo モード
  - 動機: 舌診研究の各リポジトリが研究室 PC のフォルダを個別に読む形をやめ，データセット名と版で取り出せる共通の入口を作る
  - 設計判断: 目録は SQLite ＋ SHA-256 名のストア（取り込み時にコピー．原本参照より版の再現が確実）．計算サーバへは版ごとのバンドル（`SHA256SUMS` 付き）を直送．所見は種類の定義＋ JSON 値で持ち，種類の追加で表を作り直さない
  - 運用: 研究室 PC は手元 PC から `ssh labpc` で操作し，研究室 PC では編集しない．研究室 PC に uv 0.12.22・Python 3.12.15 を導入済み．検証プロファイルは作らない（CLI はテストと `tiasdata check` で確認する）
  - 未実装・後段: `main` がまだ存在しない（GitHub・GitBucket とも空）．取り込み後に研究室 PC へ clone する（ENV_02）．次は PLAN_02 Step 1
- [x] **舌色データが 1 患者 1 枚でないことの反映**: 研究室 PC の対応表（`DeepTIAS後_ID_番号.xlsx`）と件数だけで照合し，1085 枚が約 450 人分（2 枚以上の患者 239 人・874 枚）と判明（2026-10-03）．取り込みで対応表を読み，患者単位で症例をまとめる設計に直した（PLAN_01・PLAN_02・SPEC_01〜03・ENV_01）
  - 影響: TIASJudgeModel は画像 ID を `patient_id` にしており，同じ患者の画像が学習と評価に分かれている可能性がある．基盤経由に切り替える Step 8 で患者単位の分割に直し，成績の差を記録する
  - 判断: xlsx を読む openpyxl は任意の依存（`import`）にし，使う側には入れない
- [x] **研究室 PC の DeepTIAS 出力の整理**: 空き容量の不足（1.09 GB）を受け，舌色データセットで使った画像の DeepTIAS 出力だけを番号ごとのフォルダ `DeepTIAS_TIASJudgeModel\<番号>\` へ移し（同じドライブ内の移動．約 40.6 GB），使わない出力（約 8.1 GB）を削除した（2026-10-03．空き 9.5 GB）．元のデータは研究室のサーバにある
  - 方法: 対応表の xlsx（番号・何枚目・患者 ID）で引き，`2-cropped` × `3-resized` の作り直しが舌色データセットの画像と画素で一致するかで確認．対応表どおりで引けない 192 件（撮影日等の下位フォルダ・ID と合わないフォルダ名・何枚目の誤り等）は画素の一致で探して全件特定した．Claude は件数だけを見て，番号以外の名前・患者 ID は表示していない．移動・削除はユーザーが実行
  - 設計判断: 名前の規則を推測せず画素の一致を正とした（対応表の誤り 29 件を含めて確実に特定できるため）．`LabImg` × `4-mask` は撮影画像全体の大きさで，データセットの画像（枠の大きさ）とは一致しない
  - 発見: 同じ写真の重複が 5 組（PLAN_01「現在あるデータ」）．うち 2 組はラベルが違う．取り込み（Step 3）までに扱いを決める
- [x] **研究室 PC の臨床データを E ドライブへ移した**: 研究室 PC に E ドライブ（内蔵 SSD・約 465GB）ができたため，`C:\Users\Papin\clinical-data\` 全体（26,268 ファイル・45.30GB）を `E:\clinical-data\` へコピーし，SHA-256 と構成の照合の後に C 側を削除した（2026-10-06．C の空き 53.5GB）．docs・`.claude/repo-access.json`・`lab-pc-operation.md` のパスを書き換えた
  - 失敗パターン: C 側の削除が読み取り専用の属性が付いたフォルダで止まった（`shutil.rmtree` の WinError 5）．属性を外して再試行する `onexc` で解決．コピー済み・照合済みだったためデータの欠損は無し
  - 未実装・後段: TIASJudgeModel の手順書の原本のパスが古い．E ドライブの暗号化（BitLocker）は未定（ENV_03「人間が確認すべき事項」）
- [x] **PLAN_02 Step 1: 設定と目録の土台**: 設定ファイルの読み込み・検証，SQLite の目録と対応表のマイグレーション（SPEC_02 の全表と最初の種類），`tiasdata init` を実装（2026-10-06）
  - 設計判断: マイグレーションはリポジトリ直下ではなくパッケージ内（`src/tiasdata/catalog/migrations/`）に置く（サブモジュール・パッケージとして使ったときも見つけられるようにするため）．目録と対応表は別系列で版を管理する．凍結した版・所見の書き換え禁止，種類の整合，書式（日時は秒まで）を SQL の CHECK・トリガで強制する（SPEC_02「スキーマで強制する規則」）
  - 失敗パターン: ① SQLite の CHECK は NULL を違反としないため，`value_schema_version >= 1` が NULL ですり抜けた／② INTEGER 以外の主キーに NULL が入った → どちらも `IS NOT NULL`・`NOT NULL` を明示して解決．③ Windows でパイプ・SSH 越しの出力が cp932 で化けた → CLI の入口で標準出力・標準エラーを UTF-8 に切り替えた．④ `ruff format .` が docs/ の Markdown 内のコード例を整形した → `extend-exclude` に docs を追加
- [x] **PLAN_02 Step 2: ストア**: SHA-256 名のストアへの取り込み（一時ファイル → 照合 → 正式な名前）・点検用の照合と，テスト用のダミーデータ（舌色の 9 フォルダ構成）を実装（2026-10-06）
  - 設計判断: ストアのファイルは読み取り専用にする（誤操作対策．「直したい」場合も書き換えず，新しいファイル・所見の訂正・新しい版で扱う．本当に消す場合は将来の専用コマンドで記録を残して消す）．store フォルダが無ければ作らずに止める．同じ中身で拡張子が違うファイルは Step 3 の取り込みで止める
  - 追加の判断: 既にあるファイルを再利用したとき（同じ中身を再び取り込んだとき）も読み取り専用を付け直す（バックアップからの復元・手作業等で属性が外れたファイルを守り直すため）．取り込みで触らないファイルの属性は，Step 3 の `check` で書き込み可能なファイルの数として報告する
  - 未実装・後段: POSIX（os.link）の分岐は Windows では未検証