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).

開発進捗

最新: 実機テストにチャートが必要な検査(校正・撮影・保存中/校正中に閉じる)を追加し ImagingSource で合格.17 次元の変換のノイズ(白色票の点状のノイズ・白飛び)は上流 v1.6 から同じと確認(対策は要判断) ※ 本欄は最新ステップ 1 行のみ上書き更新.詳細な進捗履歴(動機・設計判断・失敗パターン)は 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
  • 診断・評価機能は Release に含めない: ビルドフラグ(MEMMONITOR・WHITEBOARD)でコードごと出し分ける(ENV_06)

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 <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 / 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