# CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
## Project Overview
日本語で表示と説明をする
– currently a standard Flutter starter project with counter demo functionality. The project appears to be in early development phase with Japanese documentation files indicating MVP development phases.
## Common Development Commands
### WSL環境でのFlutter実行方法
WSL環境では改行コード問題によりFlutterコマンドが直接実行できないため、PowerShell経由で実行します。
#### テスト実行スクリプト
“`bash
# run_flutter_test.sh – PowerShell経由でFlutterテストを実行
#!/bin/bash
PROJECT_DIR=“/mnt/e/fultter/koukyuuhs/hsplus“
cd “$PROJECT_DIR“
powershell.exe -Command “cd ‘E:\fultter\koukyuuhs\hsplus’; flutter test $1“
“`
– flutter test –coverage | cat
flutter test –no-pub –reporter=expandedなども使用
使用方法：
“`bash
chmod +x run_flutter_test.sh
sed -i ‘s/\r$//‘ run_flutter_test.sh # 改行コード修正
./run_flutter_test.sh test/services/widget_color_service_test.dart
“`
### Build and Run
– `./run_flutter_test.sh` – Run all tests via PowerShell
– `powershell.exe -Command “cd ‘E:\fultter\koukyuuhs\hsplus’; flutter run”` – Run app
– `powershell.exe -Command “cd ‘E:\fultter\koukyuuhs\hsplus’; flutter build apk”` – Build APK
### Testing
– `./run_flutter_test.sh test/` – Run all unit and widget tests
– `./run_flutter_test.sh test/specific_test.dart` – Run specific test file
### Code Quality
– `powershell.exe -Command “cd ‘E:\fultter\koukyuuhs\hsplus’; flutter analyze”` – Static analysis
– `powershell.exe -Command “cd ‘E:\fultter\koukyuuhs\hsplus’; flutter pub get”` – Get dependencies
### Development Tools
– `powershell.exe -Command “cd ‘E:\fultter\koukyuuhs\hsplus’; flutter clean”` – Clean build
– `powershell.exe -Command “cd ‘E:\fultter\koukyuuhs\hsplus’; flutter doctor”` – Check setup
### 改行コード問題の対処
WSLで作成したスクリプトには以下を実行：
“`bash
sed -i ‘s/\r$//‘ filename.sh # CRLFをLFに変換
“`
## Project Structure
### Core Application
– `lib/main.dart` – Main application entry point with basic counter demo
– `pubspec.yaml` – Project configuration and dependencies
### Platform-Specific Code
– `android/` – Android-specific configuration and native code
– `ios/` – iOS-specific configuration and native code
– `web/` – Web platform assets and configuration
– `linux/`, `macos/`, `windows/` – Desktop platform configurations
### Testing
– `test/widget_test.dart` – Basic widget test for counter functionality
### Documentation
– `MVPタスク.md` – MVP task documentation (currently empty)
– `MVPタスクフェーズ２.md` – MVP phase 2 tasks (currently empty)
– `アーキテクチャ.md` – Architecture documentation (currently empty)
– log.md
-assets\json\area.json
## Development Configuration
### Dart/Flutter Analysis
– Uses `package:flutter_lints/flutter.yaml` for code analysis
– Standard Flutter linting rules are enabled
– Custom lint rules can be configured in `analysis_options.yaml`
### Dependencies
– Flutter SDK version: ^3.7.2
– Core dependencies: `flutter`, `cupertino_icons`
– Dev dependencies: `flutter_test`, `flutter_lints`
## Architecture Notes
This is currently a standard Flutter starter project with the default counter app implementation. The project structure suggests plans for more complex development based on the Japanese documentation files, but the actual architecture is not yet implemented.
The project supports all major Flutter platforms (Android, iOS, Web, Linux, macOS, Windows) with standard platform configurations.
## Coding Rules and Standards
**myrulereadOK** – これらのルールを必ず適用してください。
### 開発プロセス – テスト駆動開発 (TDD)
私たちは、品質を保証し、自信を持って開発を進めるために、テスト駆動開発（TDD）を標準プロセスとします。
#### TDDサイクル
以下のサイクルを厳格に遵守します。
1. **TODOリストの作成 (Plan)**
– これから実装する機能や修正項目を、具体的なタスクとしてリストアップします。（例: `// TODO: プレイヤーがジャンプする機能を追加`）
– タスクが完了したら、`DONE`マークを付けます。
2. **テストの先行 (Red)**
– TODOリストからタスクを1つ選び、そのタスクの成功を定義するテストコードを先に書きます。この時点では、実装が存在しないためテストは失敗します。
3. **失敗の確認 (Red)**
– すべてのテストを実行し、新しく追加したテストが期待通りに「失敗」することを確認します。これにより、テストが正しく機能していることを保証します。
4. **最小限の実装 (Green)**
– 先に書いたテストをパスさせるための、最小限かつ最もシンプルなコードを記述します。この段階では、コードの綺麗さよりもテストをパスすることを優先します。
5. **成功の確認 (Green)**
– 再度すべてのテストを実行し、すべてのテストが「成功」することを確認します。
6. **リファクタリング (Refactor)**
– テストが成功している状態を維持しながら、コードの品質を向上させます（可読性の向上、重複の排除、設計の改善など）。リファクタリング後も、すべてのテストが成功することを必ず確認します。
—
### 0. ルール確認
毎回このルールを読み、「myrulereadOK」と必ず宣言してください。
必要時にはlog.mdを参照し進捗状況を確認する。log.mdは適宜更新する
### 1. コード・ドキュメント
– 変数・関数・クラスには必ず型を明示する（any禁止）
– 必要に応じて独自型を作成する
– 関数内に空行を入れない
– ファイルごとにexportは1つだけ
### 2. 命名規則
– クラス名：PascalCase
– 変数・関数・メソッド名：camelCase
– ファイル・ディレクトリ名：underscores_case
– 環境変数：UPPERCASE
– マジックナンバー禁止。定数で管理
– 関数名は動詞で始める
– ブール値はisX, hasX, canXなど動詞で
– 略語は原則禁止（API, URL, i, j, err, ctx, req, res, nextは例外）
– 単語は省略せず正しいスペルで
– ハードコードは禁止
### 3. 関数・メソッド
– 1関数は20命令未満、単一責任にする
– 巨大なbuildメソッドを持つウィジェットは避け、意味のある単位でウィジェットを分割
– buildメソッドが長大になっている場合、その一部を別のStatelessWidgetやStatefulWidgetとして切り出す
– リストのアイテム、ボタン、カード表示など、独立したUI部品を別Widgetにする
– ScaffoldのbodyやappBarなども、複雑であれば別Widgetにする
– 動詞＋目的語で命名。bool返却はisX, hasX, canXなど
– void返却はexecuteX, saveXなど
– ネストは早期returnやユーティリティ関数で回避
– map, filter, reduce等の高階関数を活用
– シンプルな関数はアロー関数、複雑なものは名前付き関数
– デフォルト値を活用しnullチェックを減らす
– パラメータ・戻り値が多い場合はオブジェクトでまとめる（RO-RO）
– 必要な型を定義
– 抽象度は1段階に
– コードの重複を確認し減らす
– ハードコードは行わない
### 4. データ
– プリミティブ型の乱用禁止。複合型でカプセル化
– バリデーションはクラス内部で。関数内でのバリデーション禁止
– データは不変を推奨。readonly/as constを活用
### 5. クラス
– SOLID原則を守る
– 継承より合成を優先
– インターフェースで契約を定義
– 小さなクラス（200命令未満、publicメソッド10個未満、プロパティ10個未満）
– コードが大量になってきた場合は関連性の高いコード（クラス、関数、定数など）を一つのファイルにまとめ、importを使ってファイルを分割・連携させる
– 例：user_profile_screen.dart, user_profile_viewmodel.dart, user_card.dart のようにファイルを分ける
### 6. 例外
– 予期しないエラーのみ例外で処理
– catch時は問題修正・文脈追加のみ。その他はグローバルハンドラ
– flutter analyzeで指摘される警告(warning)や提案(hint)は、原則として修正、無視する場合は、その理由をコメントに残す
– flutter analyzerを必要時実施しデバックをする
### 7. テスト
– テスト駆動開発を基本とする。全てにテストを実施して
– Arrange-Act-Assertパターン
– テスト変数はinputX, mockX, actualX, expectedX等で明確に
– 各public関数にユニットテスト。依存はテストダブルで
– 各モジュールに受け入れテスト（Given-When-Then）
### 8. Flutter固有
– UIのコードとビジネスロジック（データの取得、計算、状態変化など）を積極的に分離し、互いの依存度を下げる
– ロジックのテストをUIとは独立して行えるようにする
– 状態管理を明確にし、予期せぬバグを防ぐ
– 特にsetStateを多用している箇所や、buildメソッド内で複雑なデータ処理を行っている箇所に行う
– 状態管理ライブラリ (Provider, Riverpod, Bloc/Cubit など) の導入を強く推奨
– 例：APIからのデータ取得、フォームの入力値の管理、計算処理などを別のクラス（ViewModel, Controller, Blocなど）に移動
– freezedコードジェネレーションライブラリも積極的に使用する
– print禁止。debugPrintやkDebugModeで制御
– クリーンアーキテクチャを採用（modules, controllers, services, repositories, entities）
– データ永続化はリポジトリパターン
– 依存性管理はgetIt（service/repositoryはsingleton、usecaseはfactory、controllerはlazy singleton）
– ルーティングはAutoRoute。データ受け渡しはextrasで
– プロジェクトで使用する状態管理ライブラリ（Provider, Riverpod, Blocなど）を決定し、その使い方を一貫させる
– 再利用コードはextensionで管理
– テーマはThemeData、翻訳はAppLocalizations、定数はconstantsで管理
– Widgetツリーは浅く保ち、再利用可能な小コンポーネントに分割することを強く推奨
– constコンストラクタを積極活用
– 必要時は必ずpubspec.yamlも確認し記載する
### 9. コメント
– コメントは「なぜ」を中心に記述する
– コメントは日本語で書く
– コードを読めばわかる「何をしているか」ではなく、「なぜこの実装にしたのか」という理由や背景、複雑なロジックの意図などをわかりやすくコメントで補足する
– 特に拡張性や保守性を意識し後からリファクタリングしやすいようにコメントする
### 10. Flutterテスト
– 小さい単位からテスト駆動開発を行う
– 標準のwidgetテストを使用
– 各APIモジュールにintegrationテストを実施
### 11. その他
– PowerShellでは && が使えないので注意
– log.mdに進捗状況を必ずメモします。日付けとコメントを入力 yyyy/mm/dd