# 開発ステップ (Development Steps)

[PLAN_01 要件定義書](PLAN_01_要件定義書.md)の成功基準に向けた実装の順序．仕様は [SPEC_01](../04_SPEC/SPEC_01_アーキテクチャ設計.md)〜[SPEC_03](../04_SPEC/SPEC_03_データセットと受け渡し.md)．

## 方針 (Policy)

- **マイルストーン 1 は舌色データだけ**で，取り込み → 版 → バンドル → 計算サーバ → TIASJudgeModel までを一通りつなぐ（2026-10-02 のユーザー判断）．セグメンテーション用データ・DeepTIAS の派生データはマイルストーン 2 以降にする
- 骨組みが種類の追加に耐えるかは，マイルストーン 1 の中でも**ダミーの所見の種類を 1 つ足すテスト**で確かめる（成功基準 5）
- 各ステップは `/implement` で進め，作業ブランチ → PR で `main` に入れる．Step 1〜5 は手元 PC だけで完結する（ダミーデータ）．Step 6 以降は研究室 PC・計算サーバを使う

## マイルストーン 1: 舌色データを基盤経由で使う (Milestone 1)

| Step | 内容 | 完了条件 |
| --- | --- | --- |
| 1 | **設定と目録の土台**: `config.py`（設定ファイルの読み込み・検証），`catalog/`（接続・マイグレーションの適用），`catalog/migrations/catalog/0001`（SPEC_02 の全表と最初の種類）・`identity/0001`（対応表），`tiasdata init`（2026-10-06 完了） | 一時ディレクトリの設定ファイルから `init` で目録ができ，`PRAGMA user_version` が最新になる．テスト（設定ファイル・マイグレーション）が通る |
| 2 | **ストア**: `store.py`（ハッシュ・コピー・照合），テスト用のダミーデータ（小さい画像・取り込み元のフォルダ）を作る `conftest.py`（2026-10-06 完了） | 同じ中身が 1 つにまとまり，コピー後の照合・上書きしないことがテストで確かめられる |
| 3 | **取り込みと点検**: `kinds/`（`tongue_color` の値の型），`importers/tongue_color_folders`（9 フォルダ＋対応表の xlsx → 症例・撮影・ファイル・所見・由来．患者 ID は `identity.sqlite` へ），`tiasdata import`・`stats`・`check`（2026-10-06 完了） | ダミーの 9 フォルダと対応表を取り込め，同じ患者の複数枚が同じ症例にまとまる．2 回実行しても同じ結果になる．想定外の構成・対応表に無い番号で停止する．保留リストの番号を飛ばし，保留の件数を報告する．出力に患者 ID・元のファイル名が出ない．`check` がストアの書き込み可能なファイル（読み取り専用が外れたもの）の数を報告する |
| 4 | **データセットと版**: `datasets/tongue_color.toml`，`datasets.py`（定義の評価・版の作成），`tiasdata dataset freeze`・`list`・`show` | 所見を足す・訂正しても過去の版の構成が変わらない．構成が同じなら版を作らない．ダミーの所見の種類を 1 つ足しても既存の表を変えずに済む（2026-10-06 完了） |
| 5 | **バンドル**: `bundle.py`（書き出し・読み込み・検証），`tiasdata export`，公開 API（`load`・`open_bundle`・`Bundle.fingerprint`） | 書き出したバンドルを目録なしで読める．改変・欠けを検出する．同じ版から同じ `manifest.csv` が得られる |
| 6 | **研究室 PC での運用開始**: 立ち上げの成果物と Step 1〜5 を `main` に取り込む → 研究室 PC に GitHub から clone・設定ファイル作成・`init` → 舌色データ（1085 枚）を取り込み → `check`・`stats` → 版 1 を作成 → `tiasdata backup` | すべて手元 PC から SSH で行える．取り込み 1076 枚＋保留 9 枚が 1085 枚・9 グループで TIASJudgeModel の TEST_01 と一致し，症例が約 450（2026-10-03 の照合値）になる．`check` が問題 0 件 |
| 7 | **計算サーバへの受け渡し**: `deliver.py`（tar・scp・展開・`sha256sum -c`・記録），`tiasdata deliver` | 版 1 を Newton・Archimedes に渡し，両方で照合が通り，`deliveries` に記録される．データが手元 PC を通らない |
| 8 | **TIASJudgeModel の切り替え**: TIASJudgeModel にサブモジュールを追加し，`tiasdata.load("tongue_color", version=1)` から現行の manifest の形に変換して学習・評価に使う（TIASJudgeModel 側の作業ブランチで行う） | 変換した manifest の件数・`label`・`severity` の内訳が，現行の manifest から保留の 9 枚を除いたものと一致し，`patient_id` が患者単位（約 450 人）になる．患者単位の分割で交差検証をやり直し，現行（画像単位）の成績との差を記録する．実験記録にバンドルの指紋が残る．研究室 PC の固定パスを書かずに済む |

- Step 6 の前に，立ち上げの成果物（`chore/project-setup`）を `main` に取り込む
- **舌色データセットの重複 5 組の扱い**（2026-10-06 のユーザー判断）: 基盤では正解を推測で決めず，確かめられるまで**保留**にする．保留リスト `holds/tiasjudgemodel.toml`（SPEC_03「保留リスト」）に 9 枚を載せ，取り込みで飛ばす
  - ファイルが同一で患者 ID が食い違う 2 組（122/184・548/566）: 両方とも保留．研究室のサーバの元のデータでどちらの患者かを確かめる
  - ラベルが違う 2 組（381/382・515/516）: 両方とも保留．評価者に正しいラベルを確かめる
  - ラベルが同じ重複の 1 組（508/509）: DeepTIAS の出力と完全一致する 508 を残し，509 だけ保留
  - 確かめ終わったらリストから外して取り込み直し，データセットの新しい版を作る
- Step 6・7 はコード（Step 7 の `deliver`）と運用（研究室 PC・サーバでの実行）が混ざる．運用の手順と結果は ENV_02・ENV_03 に記録する
- Step 8 の終了時点で PLAN_01 の成功基準 1〜7 を確認する

## マイルストーン 2 以降の候補 (Later Milestones)

優先度はマイルストーン 1 の完了後に決める．

| 候補 | 内容 |
| --- | --- |
| セグメンテーション用データ | TongueSegmentation（画像・正解マスク）を取り込む importer を追加する |
| DeepTIAS の派生データ | 撮影画像・カラーチャート画像と，DeepTIAS の出力（色補正後の画像・マスク・`analysis.csv`）を由来付きで登録する．旧 exe（2021 年 12 月版）と現行ソースの出力を版で区別する．取り込み元は整理済みの `DeepTIAS_TIASJudgeModel\<番号>\`（382・509・516 は元の出力ではなくコピーである点を由来に記録する） |
| 実際の患者 ID を持つデータ | 対応表（`identity.sqlite`）を使う取り込み．同じ患者の複数枚・経時的な撮影．倫理審査の保管ルールの確認が前提 |
| 他の所見 | 苔の色・厚さ，問診・体質等の種類を追加する |
| バックアップ | 目録・ストアを別の媒体に退避する方法を決めて手順化する（ストアのファイルは読み取り専用である点に注意） |
| データの削除 | 同意の撤回等でデータを本当に消す必要がある場合の専用コマンド（例: `tiasdata purge`）．影響する版を確かめ，削除を目録に記録してから，読み取り専用を外してストアから消す（SPEC_01「ストアの規則」） |
| TIASjudge・DeepTIAS からの利用 | 使う側を増やす |