# TIASJudgeModel

舌領域をセグメンテーション済みの舌画像から舌色 5 分類（紫・暗赤・紅・淡紅・淡白）を推定する機械学習モデルの研究開発．
学習は研究室の計算サーバで行い，臨床データは手元 PC に置かない．

## 開発進捗

最新: データセット構成を調査し SPEC・ENV_03 に反映．次は PLAN_02 の Step 1（基盤: 設定スキーマ・合成データ・manifest・患者単位分割）
※ 本欄は**最新ステップ 1 行のみ上書き更新**．詳細な進捗履歴（動機・設計判断・失敗パターン）は [docs/PROGRESS.md](docs/PROGRESS.md) に追記する．運用ルールは `.claude/rules/progress-log.md` を参照（該当ファイル編集時に自動ロードされる）．

## 必須ルール（コード実装時）

- **臨床データを手元 PC に置かない．リポジトリにも入れない**．実データを触るコードはサーバでのみ動かし，手元は合成データで確認する（[PLAN_01](docs/03_PLAN/PLAN_01_要件定義書.md)）
- ログ・例外メッセージに患者 ID・画像ファイル名を出さない（件数・行番号で示す）
- 手元へ回収するのは指標・図・ログ・重みのみ（画像・manifest・個票は回収しない．[SPEC_01](docs/04_SPEC/SPEC_01_アーキテクチャ設計.md)「回収ホワイトリスト」）
- データ分割は必ず患者単位で行う（[SPEC_02](docs/04_SPEC/SPEC_02_学習・評価仕様.md)）
- 舌色そのものがラベルであるため，色を変えるデータ拡張は既定で使わない（SPEC_02）
- パッケージ管理は uv のみ（`uv add`）．絶対パスのハードコード禁止（ENV_02「環境再現性のルール」）
- コーディング規約・構成・テスト方針・エラー処理は `.claude/rules/`（coding-style / project-structure / testing / error-handling）が該当ファイル編集時に自動ロードされる

### Git 運用

- ブランチ名・コミットメッセージの書式は `.claude/rules/git-conventions.md` に従う（常時ロードされる）
- コミットは `/commit` を使用する（push・PR 作成は `/commit push`，マージ・プルまで行う場合は `/commit merge`）
- **`/commit` はユーザーが明示的に指示した時のみ実行する．Claude が自発的に `/commit` や `git commit` を呼んではならない**（`/implement` 完了後も，案内するだけで自分ではコミットしない．`/commit` skill は `disable-model-invocation` によりユーザー起動限定として強制されている）
  - **例外**: 以下の無人運転ループはユーザー承認済みの例外として専用ブランチに自律コミットする．いずれも push・PR・マージ・`main` への操作はしない（取り込みは人間が `/commit push` 等で行う）
    - `/auto-refactor`（リファクタ／ドキュメント整理ループ）→ `refactor/` 専用ブランチ
    - `/auto-audit`（バグ／脆弱性の巡回監査ループ）→ `fix/` 専用ブランチ
  - **例外（`main` へのマージ）**: `/deps-update` は，Dependabot が作成した依存更新 PR に限り，ゲート（メジャー更新でない・競合なし・CI 緑またはローカル検証緑）を満たすものを `gh pr merge` で `main` に取り込む（ユーザーが明示的に起動した時のみ．メジャー更新・CI 赤・PR が付かない alert は報告して人間が判断する）
- **ops-runner によるマージは承認済みの定常操作**: `/commit merge` および `/deps-update` では，ユーザーが明示的に起動したことを受けて，ops-runner サブエージェント（軽量モデル）が手順書に従い `git push` → `gh pr create` → `gh pr merge --merge --delete-branch` で自リポジトリの PR を `main` にマージする．force push・`--admin`・`main` への直接 push は行わない（権限設定は `docs/01_GUIDE/GUIDE_01` の「Claude Code の権限設定」）

### テンプレート同期

- テンプレートの更新は `/sync-template` で取り込む
- テンプレート由来のファイル（`.claude/agents/`・`skills/`・`rules/`・`hooks/`，`docs/01_GUIDE/`）を**このプロジェクトの都合で意図的に変更した**ときは，`.claude/template-overrides.md`（テンプレート改変台帳）に理由付きで記録する（`.claude/rules/template-customization.md`．該当ファイル編集時に自動ロードされる）．記録が無いと次回同期で改変が消えうる

### タスク管理（任意）

- やるべきことを GitHub Issues で管理してよい（solo / team 共通）．`/task-create`（起票・事前計画）→ `/task-start <Issue番号>`（着手準備）→ `/task-handoff`（中断時の引継ぎメモ投稿）を使う
- Issue は必須ではない．小さい変更や試験的作業は Issue 無しで進めてよい
- solo モードでは進捗記録（`.claude/rules/progress-log.md`）は従来どおり運用し，Issue はタスクの管理・引継ぎの補助として使う

### エージェントチーム（GUIDE_02 準拠）

- 実装は `/implement <タスク>` で開始する（コーディング → テスト → リファクタリング → ドキュメント更新）
- Phase 1 後に人間が動作確認，Phase 2 でテスト失敗時のみ方針判断
- Phase 2 成功後は Phase 3 → Phase 4 まで自動で進む（Phase 4 で更新がある場合のみ確認）
- テスト・リファクタリングをスキップしない
- 検証プロファイル（`.claude/verify-profile.md`）を用意したプロジェクトでは，Phase 1 の後に Phase 1b（verifier による動作確認．対象はローカル環境と，プロファイルが根拠つきで許可した検証用環境のみ．本番は対象外）が入り，人間が確認する範囲が絞られる（単独実行は `/verify`）．プロファイルが無ければ Phase 1b はスキップされ，動作確認は従来どおり人間が行う．**verifier の OK は人間の動作確認の代わりにならない**

### 開発コマンド

- 起動・テスト・lint 等の開発コマンドは `docs/02_ENV/ENV_04_開発コマンド.md` にまとめる．**存在する場合は実行前に必ず参照し，推測でコマンドを試さない**
- コマンドが新しく確定・変更された時は同ファイルに反映する（無ければその時点で作成する．`/implement` の Phase 4 でも見直される）

### 手動確認が必要な作業（自分で完了させないこと）

以下は実装完了後にユーザーへ報告し，確認・実施を依頼すること．

- 外部サービスの設定（コンソール操作，セキュリティルール変更等）
  - 例外: `gh` CLI で操作できる GitHub リポジトリ設定（Dependabot alerts / security updates の有効化）は Claude が `gh api` で行う（手順は `.claude/skills/setup/reference.md`，背景は GUIDE_01「環境構築」）
- 実機・ブラウザでの動作確認（`verifier` による自動検証は前段であり，これを置き換えない）
- ストアへのアップロード・リリース作業

## ドキュメント

設計・規約に関する情報は docs/ にある．
コードを書く前に関連するファイルを読むこと．

### 01_GUIDE（規約・ルール）

- プロジェクト立ち上げフロー: docs/01_GUIDE/GUIDE_01_プロジェクト立ち上げフロー.md
- エージェント運用ルール: docs/01_GUIDE/GUIDE_02_エージェント運用ルール.md
- ※ Git 規約・ドキュメント書式・命名規則・進捗記録・テンプレート改変記録は `.claude/rules/`（git-conventions / markdown-style / docs-naming / progress-log / template-customization）に定義されている（git-conventions は常時，他は該当ファイル編集時に自動ロード）
- ※ コーディング規約・プロジェクト構成・テスト方針・エラー処理は path-scoped rules（`.claude/rules/` の coding-style / project-structure / testing / error-handling）として定義済み（該当ファイル編集時に自動ロード）

### 02_ENV（環境）

- 技術スタック: docs/02_ENV/ENV_01_技術スタック.md
- 環境構築手順: docs/02_ENV/ENV_02_環境構築手順.md
- 管理者用環境構築手順: docs/02_ENV/ENV_03_管理者用環境構築手順.md
- 開発コマンド: docs/02_ENV/ENV_04_開発コマンド.md

### 03_PLAN（計画）

- 要件定義書: docs/03_PLAN/PLAN_01_要件定義書.md
- 開発ステップ: docs/03_PLAN/PLAN_02_開発ステップ.md

### 04_SPEC（仕様・設計）

- アーキテクチャ設計: docs/04_SPEC/SPEC_01_アーキテクチャ設計.md
- 学習・評価仕様: docs/04_SPEC/SPEC_02_学習・評価仕様.md

### 05_TECH（技術設計）

<!-- 実装フェーズで必要になった時に追加する（立ち上げ時の対象外） -->

### 06_TEST（テスト）

- データセット構成調査: docs/06_TEST/TEST_01_データセット構成調査.md