# TIAS Shot 舌診用の撮影ソフトウェア（WinForms / .NET Framework 4.8 / x64）．産業用カメラ（ImagingSource・Lumenera）で舌を撮影し，舌診チャートによる自動校正と色変換行列の算出を経て sRGB 変換画像を保存する．上流（nakaguchi）v1.7 からのフォークで，クラッシュ・メモリリーク修正と性能改善を積んでいる（[docs/変更まとめ_v1.6-v1.7から.md](docs/変更まとめ_v1.6-v1.7から.md)）． ## 開発進捗 最新: 実機テストにチャートが必要な検査（校正・撮影・保存中/校正中に閉じる）を追加し ImagingSource で合格．17 次元の変換のノイズ（白色票の点状のノイズ・白飛び）は上流 v1.6 から同じと確認（対策は要判断） ※ 本欄は**最新ステップ 1 行のみ上書き更新**．詳細な進捗履歴（動機・設計判断・失敗パターン）は [docs/PROGRESS.md](docs/PROGRESS.md) に追記する．運用ルールは `.claude/rules/progress-log.md` を参照（該当ファイル編集時に自動ロードされる）． ## 必須ルール（コード実装時） ### プロジェクト固有の規約（本体は `.claude/rules/` の path-scoped rule・該当ファイル編集時に自動ロード） - **テスト方針**（`.claude/rules/testing.md`）: 4 層モデル．ピュアロジック・結合ロジック（`CameraBase`・`Form1` を偽カメラ＋ヘッドレス Form1 で）・SDK アダプタから切り出した判断ロジックは NUnit で自動テストし，実機確認は SDK の実呼び出しと見た目だけに絞る（移行計画は PLAN_05）．テストも **x64 必須**（`AnyCPU` はネイティブ DLL ロードで実行時に失敗） - **エラーハンドリング方針**（`.claude/rules/error-handling.md`）: `ErrorMsg`＋`bool` 返却・`ShowMessage`/`MessageBox`・`Debug.WriteLine` の既存パターンに従う．空 `catch` 禁止．**`Mat`・`Bitmap` 等のネイティブ資源は `using`／`try-finally` で確実に解放**（GC 任せはリーク→OOM/GDI 枯渇クラッシュ） - ※ コーディング規約（coding-style）・プロジェクト構成規則（project-structure）は**未整備**（GUIDE_01 の規約整備フェーズ参照） ### rule 未収載の固有不変条件（コード変更時に壊さないこと） - **プレビュー表示 Bitmap の所有権モデル**: カメラコールバックが渡す入力 bmp は「読むだけ」，表示は UI 所有コピー（`FastClone`），入力の Dispose 責任は呼び出し側．コールバックスレッドから毎フレーム `Invalidate()` しない（描画はタイマー駆動）．経緯は [PLAN_03](docs/03_PLAN/PLAN_03_プレビューメモリリーク修正計画.md) - **診断・評価機能は Release に含めない**: ビルドフラグ（`MEMMONITOR`・`WHITEBOARD`）でコードごと出し分ける（[ENV_06](docs/02_ENV/ENV_06_ビルド構成とビルドフラグ.md)） ### 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` 等で行う） - `/setup`（プロジェクト立ち上げ）→ `chore/project-setup` 専用ブランチ（フェーズごとに 1 コミット） - `/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 で管理してよい．`/task-create`（起票・事前計画）→ `/task-start `（着手準備）→ `/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 / testing / error-handling）に path-scoped rule として定義されている（git-conventions は常時，他は該当ファイル編集時に自動ロード） - ※ コーディング規約・プロジェクト構成規則は未整備（GUIDE_01 の規約整備フェーズ参照） ### 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 - ディレクトリ構成: docs/02_ENV/ENV_05_ディレクトリ構成.md - ビルド構成とビルドフラグ: docs/02_ENV/ENV_06_ビルド構成とビルドフラグ.md ### 03_PLAN（計画） - プレビューメモリリーク修正計画: docs/03_PLAN/PLAN_03_プレビューメモリリーク修正計画.md - 性能評価計測計画: docs/03_PLAN/PLAN_04_性能評価計測計画.md - テスト網羅性向上計画（4 層モデルへの移行）: docs/03_PLAN/PLAN_05_テスト網羅性向上計画.md - 実機自動テスト計画（Claude が実機を操作して層④を確認する）: docs/03_PLAN/PLAN_06_実機自動テスト計画.md - ※ PLAN_01（リファクタリング）・PLAN_02（バグ修正）は完了につき削除済み（要点は docs/PROGRESS.md，経緯は git 履歴） ### 04_SPEC（仕様・設計） - 機能仕様: docs/04_SPEC/SPEC_01_機能仕様.md - 設定ファイル仕様: docs/04_SPEC/SPEC_02_設定ファイル仕様.md - 白板撮影プロトコル（照明均一性評価）: docs/04_SPEC/SPEC_03_白板撮影_照明均一性評価.md - 白板撮影データ仕様（SmTIAS 引き渡し用）: docs/04_SPEC/SPEC_04_白板撮影データ仕様.md ### 05_TECH（技術設計） - クラス設計: docs/05_TECH/TECH_01_クラス設計.md - カメラ制御仕様: docs/05_TECH/TECH_02_カメラ制御仕様.md - 色補正処理仕様: docs/05_TECH/TECH_03_色補正処理仕様.md ### 06_TEST（テスト） - テスト仕様（回帰・手動テスト手順）: docs/06_TEST/TEST_01_テスト仕様.md - 性能評価計測結果（v1.6/v1.7/現行の 3 版比較）: docs/06_TEST/TEST_02_性能評価計測結果.md - メモリ修正効果計測（自動ベンチ）: docs/06_TEST/TEST_03_メモリ修正効果計測.md ### その他（docs 直下） - 進捗フルログ: docs/PROGRESS.md - 上流向け変更サマリ（v1.6/v1.7 から何をどう直したか・差分確認付き）: docs/変更まとめ_v1.6-v1.7から.md