Newer
Older
TIASshot / CLAUDE.md

TIAS Shot

舌診用の撮影ソフトウェア(WinForms / .NET Framework 4.8 / x64).産業用カメラ(ImagingSource・Lumenera)で舌を撮影し,舌診チャートによる自動校正と色変換行列の算出を経て sRGB 変換画像を保存する.上流(nakaguchi)v1.7 からのフォークで,クラッシュ・メモリリーク修正と性能改善を積んでいる(docs/変更まとめ_v1.6-v1.7から.md).

開発進捗

最新: 3 バージョン(v1.6/v1.7/現行)を実機 MEMMONITOR で性能評価計測し,2 段階改善(保存経路 v1.6→v1.7・プレビュー経路 v1.7→現行)を定量化(PLAN_04/TEST_02・PR #18).あわせて完了済み PLAN_01/02 と対比用 LEAKY_REPRO フラグを撤去(挙動不変・テスト 14/14 パス) ※ 本欄は最新ステップ 1 行のみ上書き更新.詳細な進捗履歴(動機・設計判断・失敗パターン)は docs/PROGRESS.md に追記する.運用ルールは .claude/rules/progress-log.md を参照(該当ファイル編集時に自動ロードされる).

必須ルール(コード実装時)

プロジェクト固有の規約(本体は .claude/rules/ の path-scoped rule・該当ファイル編集時に自動ロード)

  • テスト方針.claude/rules/testing.md): ピュアロジック層は NUnit で必ず自動テスト,ハードウェア結合層(カメラ/UI/スレッド)は対象外としビルド+実機で担保.テストも x64 必須AnyCPU はネイティブ DLL ロードで実行時に失敗)
  • エラーハンドリング方針.claude/rules/error-handling.md): ErrorMsgbool 返却・ShowMessage/MessageBoxDebug.WriteLine の既存パターンに従う.空 catch 禁止.MatBitmap 等のネイティブ資源は usingtry-finally で確実に解放(GC 任せはリーク→OOM/GDI 枯渇クラッシュ)
  • ※ コーディング規約(coding-style)・プロジェクト構成規則(project-structure)は未整備(GUIDE_01 の規約整備フェーズ参照)

rule 未収載の固有不変条件(コード変更時に壊さないこと)

  • プレビュー表示 Bitmap の所有権モデル: カメラコールバックが渡す入力 bmp は「読むだけ」,表示は UI 所有コピー(FastClone),入力の Dispose 責任は呼び出し側.コールバックスレッドから毎フレーム Invalidate() しない(描画はタイマー駆動).経緯は PLAN_03
  • 診断・評価機能は Release に含めない: ビルドフラグ(MEMMONITORWHITEBOARD)でコードごと出し分ける(ENV_06

Git 運用

  • ブランチ名・コミットメッセージの書式は .claude/rules/git-conventions.md に従う(常時ロードされる)
  • コミットは /commit を使用する(push・PR 作成は /commit push
  • /commit はユーザーが明示的に指示した時のみ実行する.Claude が自発的に /commitgit commit を呼んではならない/implement 完了後も,案内するだけで自分ではコミットしない./commit skill は disable-model-invocation によりユーザー起動限定として強制されている)
    • 例外: 以下の無人運転ループはユーザー承認済みの例外として専用ブランチに自律コミットする.いずれも push・PR・マージ・main への操作はしない(取り込みは人間が /commit push 等で行う)
      • /auto-refactor(リファクタ/ドキュメント整理ループ)→ refactor/ 専用ブランチ
      • /auto-audit(バグ/脆弱性の巡回監査ループ)→ fix/ 専用ブランチ

エージェントチーム(GUIDE_02 準拠)

  • 実装は /implement <タスク> で開始する(コーディング → テスト → リファクタリング → ドキュメント更新)
  • Phase 1 後に人間が動作確認,Phase 2 でテスト失敗時のみ方針判断
  • Phase 2 成功後は Phase 3 → Phase 4 まで自動で進む(Phase 4 で更新がある場合のみ確認)
  • テスト・リファクタリングをスキップしない

開発コマンド

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

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

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

  • 外部サービスの設定(コンソール操作,セキュリティルール変更等)
  • 実機・ブラウザでの動作確認
  • ストアへのアップロード・リリース作業

ドキュメント

設計・規約に関する情報は 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 / 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
  • ※ 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