@k2works/claude-code-booster 0.3.0 → 0.5.0

package/lib/assets/.claude/README.md

@@ -64,6 +64,8 @@ Claude Code をもっと便利に使うための設定集です。
 | `/progress`             | 進捗確認をする。                                                    |
 | `/next`                 | 次タスクを確認する。                                                  |
 | `/analysis`             | 開発標準の分析ワークフローを実行する。                                         |
+| `/dev`                  | 開発標準の開発ワークフローを実行する。                                         |
+| `/ops`                  | 開発標準の運用ワークフローを実行する。                                         |
 
 
 ### Roles（役割設定）

package/lib/assets/.claude/commands/dev.md

@@ -0,0 +1,105 @@
+## Development Guide Reference
+
+コーディングとテストガイドを参照し、TDD サイクルに従った開発を支援します。
+
+### 使い方
+
+```bash
+/dev [オプション]
+```
+
+### オプション
+
+- なし : ガイド全体の要約と TDD サイクルの説明
+- `--tdd` : TDD の Red-Green-Refactor サイクルの詳細
+- `--approach` : インサイドアウト/アウトサイドインアプローチの選択指針
+- `--checklist` : コミット前の品質チェックリスト表示
+- `--refactor` : リファクタリングパターンの一覧
+- `--test` : テスト作成のベストプラクティス
+
+### 基本例
+
+```bash
+# TDD サイクルの開始
+/dev --tdd
+「現在のタスクに対して Red-Green-Refactor サイクルを開始」
+
+# アプローチ戦略の確認
+/dev --approach
+「実装アプローチ（インサイドアウト/アウトサイドイン）の選択を支援」
+
+# 品質チェックの実行
+/dev --checklist
+「コミット前の必須確認事項を順次実行」
+
+# リファクタリング支援
+/dev --refactor
+「現在のコードに適用可能なリファクタリングパターンを提案」
+```
+
+### 詳細機能
+
+#### TDD サイクルの実践
+
+Red-Green-Refactor サイクルを厳密に実行：
+
+1. **Red フェーズ**: 失敗するテストを最初に書く
+2. **Green フェーズ**: テストを通す最小限のコードを実装
+3. **Refactor フェーズ**: 重複を除去し設計を改善
+4. @docs/reference/コーディングとテストガイド.md のワークフローに従う
+
+```bash
+# 新機能の TDD 実装開始
+/dev --tdd
+「User エンティティのテストから開始します」
+```
+- @docs/design/architecture_backend.md を参照
+- @docs/design/architecture_frontend.md を参照
+- @docs/design/data-model.md を参照
+- @docs/design/domain-model.md を参照
+- @docs/design/tech_stack.md を参照
+
+#### アプローチ戦略の選択
+
+プロジェクトの状態に応じた最適なアプローチを選択：
+
+- **インサイドアウト**: データ層から開始し上位層へ展開
+- **アウトサイドイン**: UI から開始しドメインロジックを段階的に実装
+
+### Claude との連携
+
+```bash
+# 現在のコードを分析してリファクタリング提案
+cat src/User.java
+/dev --refactor
+「このクラスに適用可能なリファクタリングパターンを分析」
+
+# テストカバレッジを確認してテスト追加
+npm run test:coverage
+/dev --test
+「カバレッジが低い箇所のテストを追加」
+
+# コミット前の品質確認
+git status
+/dev --checklist
+「全ての品質基準を満たすまで確認を実行」
+```
+
+### 注意事項
+
+- **前提条件**: プロジェクトのテスト環境が設定済みであること
+- **制限事項**: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）
+- **推奨事項**: コミット前に必ず品質チェックリストを実行
+
+### ベストプラクティス
+
+1. **TODO 駆動開発**: タスクを細かい TODO に分割してから実装開始
+2. **小さなサイクル**: Red-Green-Refactor を 10-15 分で完了させる
+3. **継続的コミット**: 各サイクル完了時に動作する状態でコミット
+4. **Rule of Three**: 同じコードが 3 回現れたらリファクタリング
+
+### 関連コマンド
+
+- `/task` : タスク管理と TODO リストの作成
+- `/review` : コードレビューの実施
+- `/test` : テスト実行と結果確認

package/lib/assets/.claude/commands/ops.md

@@ -14,6 +14,7 @@
 - `--setup [環境名]` : 環境構築の初期設定とインフラ準備
   - `--setup Java` : Java開発環境の構築とSpring Bootプロジェクトセットアップ
   - `--setup FrontEnd` : TypeScript/React開発環境の構築とViteプロジェクトセットアップ
+  - `--setup C#WPF` : C# WPF開発環境の構築とClean Architectureプロジェクトセットアップ
 - `--build` : アプリケーションのビルドとパッケージング
 - `--deploy <環境>` : 指定環境へのデプロイ実行
 - `--status <環境>` : 特定環境の動作状況確認
@@ -22,6 +23,7 @@
 - `--health` : システム全体のヘルスチェック実行
 - `--backup` : データベース・設定ファイルのバックアップ作成
 - `--restore <バックアップ>` : 指定バックアップからの復元
+- `--daily` : 日次運用タスクの自動実行（日誌生成と概要編集）
 
 ### 基本例
 
@@ -42,6 +44,10 @@
 /ops --setup FrontEnd
 「プロジェクト名と作成場所（デフォルト app/frontend）を対話式で確認後、docs/reference/TypeScriptアプリケーション環境構築ガイド.md、@docs/design/tech_stack.md、@docs/design/architecture_frontend.md を基にしたTypeScript/React開発環境の統合セットアップ」
 
+# C# WPF開発環境の構築
+/ops --setup C#WPF
+「プロジェクト名と作成場所（デフォルト app/wpfapp）を対話式で確認後、@docs/design/tech_stack.md、@docs/design/architecture_backend.md、@docs/design/architecture_frontend.md を基にしたC# WPF + Clean Architecture開発環境の統合セットアップ」
+
 # プロダクション環境へのデプロイ
 /ops --deploy production
 「本番環境への安全なデプロイ実行とヘルスチェック」
@@ -57,6 +63,10 @@
 # 緊急時のロールバック
 /ops --rollback production
 「本番環境を前の安定バージョンにロールバック」
+
+# 日次運用タスクの実行
+/ops --daily
+「日誌の自動生成と概要編集を実行」
 ```
 
 ### 詳細機能
@@ -146,7 +156,71 @@
 /ops --setup FrontEnd
 ```
 
+#### C# WPF開発環境の統合セットアップ
+
+ドキュメントベースの包括的C# WPF + Clean Architecture開発環境構築コマンド：
+
+```bash
+# ドキュメント準拠のC# WPF開発環境セットアップ（対話式）
+/ops --setup C#WPF
+```
+
 **参照ドキュメント**:
+- `@docs/design/tech_stack.md`: C# WPF技術スタック選定理由と詳細仕様
+- `@docs/design/architecture_backend.md`: Clean Architecture + MagicOnion サーバー設計詳細
+- `@docs/design/architecture_frontend.md`: WPF MVVM アーキテクチャとプレゼンテーション層設計詳細
+
+**初期設定プロセス**:
+
+🎯 **対話式プロジェクト設定**:
+- プロジェクト名の確認（例: AdventureWorks.PurchasingSystem）
+- ソリューション名の確認（例: AdventureWorks）
+- 作成場所の確認（デフォルト: `app/`配下）
+- データベース接続文字列の確認
+
+**注意点**
+- app/app のような構成にしてはいけない
+- app/{solution-name} のような構成すること
+- tech_stack.md の ディレクトリ構成詳細にしたがうこと
+- ディレクトリだけの場合もコミットしたいので `.gitkeep` を入れる
+- Javaの `src` や `tests` のようなディレクトリ構成にしないこと
+
+**構築される環境の詳細**:
+
+**📋 基盤技術** (@docs/design/tech_stack.md 準拠):
+- .NET 8.0 + C# 12
+- WPF + CommunityToolkit.Mvvm 8.x
+- MagicOnion 5.x (gRPC ベースRPC)
+- Dapper 2.x (Micro ORM)
+- Kamishibai 3.x (ナビゲーション)
+
+**🏗️ アーキテクチャ** (@docs/design/architecture_backend.md + @docs/design/architecture_frontend.md 準拠):
+- Clean Architecture（依存関係逆転）
+- Domain-Driven Design（ドメインモデル中心）
+- MVVM パターン（WPF標準）
+- レイヤー分離: Domain → Application → Infrastructure → Presentation
+- MagicOnion サーバーによるgRPC通信
+
+**💾 データベース環境**:
+- 開発・テスト: SQL Server LocalDB
+- 本番: SQL Server + Dapper
+- マイグレーション: DbUp 5.x
+- 接続プール: SqlConnection + HikariCP相当
+
+**🔍 品質管理ツール**:
+- テスト: NUnit 3 + FluentAssertions + Moq + Codeer.Friendly
+- 静的解析: SonarQube + StyleCop + FxCop
+- カバレッジ: OpenCover (Domain: 95%, Application: 85%目標)
+- UI テスト: Codeer.Friendly.Windows.Wpf
+- E2E テスト: Page Object Pattern
+
+**⚙️ 開発支援機能**:
+- Serilog (構造化ログ)
+- Docker Compose (開発環境)
+- MkDocs (ドキュメントサイト)
+- PlantUML (アーキテクチャ図)
+
+**TypeScript/React 参照ドキュメント**:
 - `docs/reference/TypeScriptアプリケーション環境構築ガイド.md`: TDD基盤セットアップ手順と開発規律
 - `@docs/design/tech_stack.md`: フロントエンド技術スタック選定理由と詳細仕様
 - `@docs/design/architecture_frontend.md`: SPA アーキテクチャとコンポーネント設計詳細
@@ -254,6 +328,36 @@
 /ops --health --dashboard
 ```
 
+#### 日次運用タスク
+
+プロジェクトの日常的な運用作業を自動化し、開発履歴の記録と管理を支援：
+
+```bash
+# 日次運用タスクの自動実行
+/ops --daily
+```
+
+**実行される作業**:
+
+**📝 日誌生成と管理**:
+1. `npm run journal` コマンドの実行
+2. Git コミット履歴から日付別の作業記録を自動生成
+3. `docs/journal/YYYYMMDD.md` 形式でファイル作成
+4. `mkdocs.yml` に自動登録
+
+**✏️ 概要の自動編集**:
+- 技術的な作業内容を簡潔に要約
+- DDD（ドメイン駆動設計）などの設計パターンへの言及
+- 実施した主要な変更と改善点の明確化
+- bounded context の整合性などアーキテクチャレベルの変更を強調
+- 型参照の更新、リファクタリング詳細、テスト戦略などを含む
+
+**生成される日誌の構成**:
+- コミットメッセージ
+- 変更されたファイル一覧
+- 詳細な diff 情報
+- 作業内容の技術的サマリー
+
 #### バックアップと災害復旧
 
 自動バックアップと迅速な災害復旧：
@@ -362,6 +466,23 @@ cat docs/design/architecture_frontend.md
 # → 開発ポート確認: "3000" (Enter でデフォルト採用)
 npm run dev
 「設計ドキュメント確認後、対話式でプロジェクト設定を確認し、TypeScript/React環境構築と開発サーバー起動」
+
+# ドキュメント準拠のC# WPF開発環境構築（対話式）
+cat docs/design/tech_stack.md
+cat docs/design/architecture_backend.md
+cat docs/design/architecture_frontend.md
+/ops --setup C#WPF
+# → ソリューション名入力: "AdventureWorks"
+# → プロジェクト名確認: "AdventureWorks.PurchasingSystem" (自動生成)
+# → 作成場所確認: "app/wpfapp/" (Enter でデフォルト採用)
+# → 接続文字列確認: "Server=(localdb)\\mssqllocaldb;..." (デフォルト採用)
+dotnet build
+「設計ドキュメント確認後、対話式でプロジェクト設定を確認し、C# WPF + Clean Architecture環境構築と初回ビルド実行」
+
+# 日次運用タスクと開発履歴管理
+git status
+/ops --daily
+「現在の作業状況を確認後、日誌生成と概要の自動編集を実行」
 ```
 
 ### 注意事項

package/lib/assets/.devcontainer/devcontainer.json

@@ -0,0 +1,34 @@
+// For format details, see https://aka.ms/devcontainer.json. For config options, see the
+// README at: https://github.com/devcontainers/templates/tree/main/src/docker-in-docker
+{
+	"name": "Case Study Game Dev Container",
+	// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
+	//"image": "mcr.microsoft.com/devcontainers/base:bullseye",
+	"build": {
+		"dockerfile": "../Dockerfile"
+	},
+
+	"features": {
+		"ghcr.io/devcontainers/features/docker-in-docker:2": {
+			"version": "latest",
+			"enableNonRootDocker": "true",
+			"moby": "true"
+		}
+	},
+
+	// Use 'forwardPorts' to make a list of ports inside the container available locally.
+	// "forwardPorts": [],
+
+	// Use 'postCreateCommand' to run commands after the container is created.
+	// "postCreateCommand": "docker --version",
+
+	// Configure tool-specific properties.
+  "customizations" : {
+    "jetbrains" : {
+      "backend" : "IntelliJ"
+    }
+  },
+
+	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
+	// "remoteUser": "root"
+}

package/lib/assets/docs/reference//343/202/263/343/203/274/343/203/207/343/202/243/343/203/263/343/202/260/343/201/250/343/203/206/343/202/271/343/203/210/343/202/254/343/202/244/343/203/211.md

@@ -0,0 +1,704 @@
+# コーディングとテストガイド
+
+## 概要
+
+このガイドは、開発ガイドのコーディングとテスト部分を詳細化したドキュメントです。TDD（テスト駆動開発）を中核とした実装プロセスの具体的な手順と、品質を維持するための規律を定義します。
+
+## 基本原則
+
+### TDD（Test-Driven Development）の三つの原則
+
+1. **失敗するテストを書くまで、プロダクションコードを書いてはならない**
+2. **失敗するテストは、失敗するのに十分なだけ書く**
+3. **現在失敗しているテストを成功させる以上のプロダクションコードを書いてはならない**
+
+### Red-Green-Refactor サイクル
+
+```plantuml
+@startuml
+skinparam state {
+  BackgroundColor Red
+  BackgroundColor LightGreen
+  BackgroundColor LightBlue
+}
+
+[*] --> Red
+state Red {
+  [*] --> テストを書く
+  テストを書く : 失敗する
+}
+Red --> Green : 最小限の実装
+
+state Green {
+  [*] --> テストが通る
+  テストが通る : 最小限のコード
+}
+Green --> Refactor : テスト成功
+
+state Refactor {
+  [*] --> リファクタリング
+  リファクタリング : 設計改善
+}
+Refactor --> Red : 次のテスト
+Refactor --> [*] : 完了
+
+note right of Red
+  失敗するテストを
+  最初に書く
+end note
+
+note right of Green
+  テストを通す
+  最小限のコードを書く
+end note
+
+note right of Refactor
+  重複を除去し
+  設計を改善する
+end note
+
+@enduml
+```
+
+## イテレーション開発フロー
+
+### 全体プロセス
+
+```plantuml
+@startuml "イテレーション開発プロセス"
+
+start
+
+partition "イテレーション開始" {
+}
+
+repeat :TODO確認;
+partition "TDD実装サイクル" {
+    repeat
+      :TODO選択;
+      
+      repeat
+        :失敗テスト作成 (Red);
+        :最小実装 (Green);
+        :リファクタリング (Refactor);
+        :品質チェック;
+        if (品質OK?) then (yes)
+          :コミット;
+        else (no)
+          :修正;
+        endif
+      repeat while (TODO完了?)
+      partition "コードレビュー" {
+      }
+    repeat while (全TODO完了?)
+}
+
+if (イテレーション完了?) then (yes)
+  partition "受け入れ" {
+    partition "ユーザーレビュー" {
+    }
+    if (受け入れOK?) then (yes)
+      partition "ふりかえり" {
+      }
+    else (no)
+      partition "修正対応" {
+      }
+    endif
+  }
+else (no)
+  partition "設計リファクタリング" {
+      partition "アーキテクチャリファクタリング" {
+      }
+      partition "データモデルリファクタリング" {
+      }
+      partition "ドメインモデルリファクタリング" {
+      }
+      partition "UIリファクタリング" {
+      }
+  }
+endif
+repeat while (次のTODO?)
+
+stop
+
+@enduml
+```
+
+## アプローチ戦略
+
+### インサイドアウト vs アウトサイドイン
+
+```plantuml
+@startuml
+title 実装アプローチ選択フロー
+
+start
+
+:ユーザーストーリー分析;
+
+if (基本CRUD実装済み?) then (はい)
+  if (ドメインロジックが複雑?) then (はい)
+    :ドメインモデル中心;
+    #lightgreen:アウトサイドイン推奨;
+    note right
+      UIからスタート
+      ドメインロジックを
+      段階的に実装
+    end note
+  else (いいえ)
+    :シンプルな機能追加;
+    #lightblue:どちらでも可;
+  endif
+else (いいえ)
+  :貧血ドメインモデル;
+  #yellow:インサイドアウト推奨;
+  note right
+    データ層から開始
+    基盤を固めて
+    上位層へ展開
+  end note
+endif
+
+if (API実装済み?) then (はい)
+  #lightblue:インサイドアウト活用;
+  note right
+    既存APIを利用し
+    内部実装を改善
+  end note
+else (いいえ)
+  #lightgreen:アウトサイドイン活用;
+  note right
+    UIのニーズから
+    API設計を導出
+  end note
+endif
+
+:アプローチ決定;
+
+stop
+@enduml
+```
+
+### インサイドアウトアプローチ
+
+```plantuml
+@startuml
+title インサイドアウトアプローチ
+
+participant "テスト" as test
+participant "データベース層" as db
+participant "インフラ層" as infra
+participant "ドメイン層" as domain
+participant "サービス層" as service
+participant "プレゼンテーション層" as ui
+
+== Phase 1: データベース ==
+test -> db: テーブル定義テスト
+activate db
+db --> test: スキーマ検証
+deactivate db
+
+== Phase 2: インフラストラクチャ ==
+test -> infra: リポジトリテスト
+activate infra
+infra -> db: CRUD操作
+db --> infra: 結果
+infra --> test: 永続化確認
+deactivate infra
+
+== Phase 3: ドメイン ==
+test -> domain: ビジネスロジックテスト
+activate domain
+domain -> infra: データ取得
+infra --> domain: エンティティ
+domain --> test: ビジネスルール検証
+deactivate domain
+
+== Phase 4: サービス ==
+test -> service: ユースケーステスト
+activate service
+service -> domain: ドメイン操作
+domain --> service: 結果
+service --> test: トランザクション確認
+deactivate service
+
+== Phase 5: プレゼンテーション ==
+test -> ui: UIテスト
+activate ui
+ui -> service: API呼び出し
+service --> ui: レスポンス
+ui --> test: 画面表示確認
+deactivate ui
+
+@enduml
+```
+
+### アウトサイドインアプローチ
+
+```plantuml
+@startuml
+title アウトサイドインアプローチ
+
+participant "受け入れテスト" as at
+participant "プレゼンテーション層" as ui
+participant "サービス層" as service
+participant "ドメイン層" as domain
+participant "インフラ層" as infra
+participant "データベース層" as db
+
+== Phase 1: 受け入れテスト ==
+at -> ui: ユーザーシナリオ
+activate at
+ui --> at: モック応答
+deactivate at
+
+== Phase 2: UI実装 ==
+at -> ui: UIテスト
+activate ui
+ui -> service: サービス呼び出し（モック）
+service --> ui: モックレスポンス
+ui --> at: 画面動作確認
+deactivate ui
+
+== Phase 3: サービス実装 ==
+at -> service: 統合テスト
+activate service
+service -> domain: ドメイン呼び出し（モック）
+domain --> service: モック結果
+service --> at: ビジネスロジック確認
+deactivate service
+
+== Phase 4: ドメイン実装 ==
+at -> domain: ドメインテスト
+activate domain
+domain -> infra: リポジトリ呼び出し（モック）
+infra --> domain: モックデータ
+domain --> at: ビジネスルール確認
+deactivate domain
+
+== Phase 5: インフラ実装 ==
+at -> infra: 永続化テスト
+activate infra
+infra -> db: DB操作
+db --> infra: 実データ
+infra --> at: データ永続化確認
+deactivate infra
+
+@enduml
+```
+
+## TDD実装の詳細手順
+
+### 1. TODO作成
+
+```markdown
+## TODOリストの例
+
+- [ ] ユーザー登録機能
+  - [ ] Userエンティティの作成
+    - [ ] 必須フィールドの検証
+    - [ ] メールアドレスの形式検証
+    - [ ] パスワードの強度チェック
+  - [ ] UserRepositoryの実装
+    - [ ] save()メソッド
+    - [ ] findByEmail()メソッド
+    - [ ] existsByEmail()メソッド
+  - [ ] UserServiceの実装
+    - [ ] register()メソッド
+    - [ ] 重複チェック
+    - [ ] パスワードハッシュ化
+  - [ ] UserControllerの実装
+    - [ ] POST /users エンドポイント
+    - [ ] バリデーション
+    - [ ] エラーハンドリング
+```
+
+### 2. Red フェーズ（失敗するテストを書く）
+
+```java
+// UserTest.java
+@Test
+void ユーザー作成時に必須フィールドが検証される() {
+    // Given
+    String email = "test@example.com";
+    String password = "SecurePass123!";
+    String name = "山田太郎";
+
+    // When
+    User user = new User(email, password, name);
+
+    // Then
+    assertThat(user.getEmail()).isEqualTo(email);
+    assertThat(user.getName()).isEqualTo(name);
+    // パスワードはハッシュ化されている
+    assertThat(user.getPassword()).isNotEqualTo(password);
+}
+
+@Test
+void 無効なメールアドレスで例外が発生する() {
+    // Given
+    String invalidEmail = "invalid-email";
+
+    // When/Then
+    assertThrows(IllegalArgumentException.class, () -> {
+        new User(invalidEmail, "password", "name");
+    });
+}
+```
+
+### 3. Green フェーズ（最小限の実装）
+
+```java
+// User.java
+public class User {
+    private String email;
+    private String password;
+    private String name;
+
+    public User(String email, String password, String name) {
+        if (!isValidEmail(email)) {
+            throw new IllegalArgumentException("無効なメールアドレス");
+        }
+        this.email = email;
+        this.password = hashPassword(password);
+        this.name = name;
+    }
+
+    private boolean isValidEmail(String email) {
+        return email != null && email.contains("@");
+    }
+
+    private String hashPassword(String password) {
+        // 簡単なハッシュ化の実装（後で改善）
+        return "hashed_" + password;
+    }
+
+    // getters...
+}
+```
+
+### 4. Refactor フェーズ（設計改善）
+
+```java
+// User.java (リファクタリング後)
+public class User {
+    private final Email email;
+    private final Password password;
+    private final Name name;
+
+    public User(String email, String password, String name) {
+        this.email = new Email(email);
+        this.password = new Password(password);
+        this.name = new Name(name);
+    }
+
+    // getters...
+}
+
+// Email.java (値オブジェクト)
+public class Email {
+    private static final Pattern VALID_EMAIL_PATTERN =
+        Pattern.compile("^[A-Za-z0-9+_.-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$");
+
+    private final String value;
+
+    public Email(String value) {
+        if (value == null || !VALID_EMAIL_PATTERN.matcher(value).matches()) {
+            throw new IllegalArgumentException("無効なメールアドレス: " + value);
+        }
+        this.value = value;
+    }
+
+    public String getValue() {
+        return value;
+    }
+}
+
+// Password.java (値オブジェクト)
+public class Password {
+    private static final int MIN_LENGTH = 8;
+    private final String hashedValue;
+
+    public Password(String rawPassword) {
+        validate(rawPassword);
+        this.hashedValue = BCrypt.hashpw(rawPassword, BCrypt.gensalt());
+    }
+
+    private void validate(String password) {
+        if (password == null || password.length() < MIN_LENGTH) {
+            throw new IllegalArgumentException(
+                "パスワードは" + MIN_LENGTH + "文字以上必要です"
+            );
+        }
+    }
+
+    public boolean matches(String rawPassword) {
+        return BCrypt.checkpw(rawPassword, hashedValue);
+    }
+}
+```
+
+## 品質チェックリスト
+
+### コミット前の必須確認事項
+
+```bash
+# 1. テスト実行
+./gradlew test  # または npm test
+
+# 2. コードフォーマット
+./gradlew spotlessApply  # または npm run format
+
+# 3. 静的解析
+./gradlew check  # または npm run lint
+
+# 4. ビルド確認
+./gradlew build  # または npm run build
+
+# 5. カバレッジ確認
+./gradlew jacocoTestReport  # または npm run test:coverage
+```
+
+### 品質基準
+
+| 項目 | 基準 | 必須/推奨 |
+|------|------|-----------|
+| テストカバレッジ | 80%以上 | 必須 |
+| 循環的複雑度 | 10以下 | 必須 |
+| メソッドの行数 | 20行以下 | 推奨 |
+| クラスの行数 | 200行以下 | 推奨 |
+| 重複コード | 0% | 必須 |
+| コンパイラ警告 | 0個 | 必須 |
+| Linter警告 | 0個 | 必須 |
+
+## コミット規約
+
+### コミットメッセージフォーマット
+
+```
+<type>(<scope>): <subject>
+
+<body>
+
+<footer>
+```
+
+### タイプ一覧
+
+| タイプ | 説明 | 例 |
+|--------|------|-----|
+| feat | 新機能追加 | `feat(auth): ユーザー認証機能を追加` |
+| fix | バグ修正 | `fix(api): NullPointerExceptionを修正` |
+| docs | ドキュメント変更 | `docs(readme): インストール手順を更新` |
+| style | コードスタイル変更 | `style: インデントを修正` |
+| refactor | リファクタリング | `refactor(user): Userクラスを値オブジェクトに分割` |
+| test | テスト追加・修正 | `test(user): ユーザー登録のテストを追加` |
+| chore | ビルド・ツール変更 | `chore(gradle): 依存関係を更新` |
+
+### コミット単位
+
+- **1コミット = 1論理的変更**
+- TODOリストの項目単位でコミット
+- Red-Green-Refactorサイクル完了時にコミット
+- ビルドが通る状態でコミット
+
+## テストの種類と戦略
+
+### テストピラミッド
+
+```plantuml
+@startuml
+skinparam defaultTextAlignment center
+
+rectangle "E2Eテスト\n(10%)" as e2e #LightCoral
+
+rectangle "統合テスト\n(30%)" as integration #LightSalmon
+
+rectangle "単体テスト\n(60%)" as unit #LightGreen
+
+e2e -[hidden]down-> integration
+integration -[hidden]down-> unit
+
+note right of e2e
+  ユーザーシナリオ
+  システム全体の動作確認
+  実行時間: 遅い
+end note
+
+note right of integration
+  モジュール間連携
+  API・DB接続テスト
+  実行時間: 中程度
+end note
+
+note right of unit
+  個別機能のテスト
+  ビジネスロジック検証
+  実行時間: 高速
+end note
+
+@enduml
+```
+
+### テスト作成のベストプラクティス
+
+#### 1. AAA パターン（Arrange-Act-Assert）
+
+```java
+@Test
+void 商品の在庫が減少する() {
+    // Arrange（準備）
+    Product product = new Product("商品A", 10);
+    int orderQuantity = 3;
+
+    // Act（実行）
+    product.reduceStock(orderQuantity);
+
+    // Assert（検証）
+    assertThat(product.getStock()).isEqualTo(7);
+}
+```
+
+#### 2. テストの命名規則
+
+```java
+// パターン1: 日本語での説明的な名前
+@Test
+void 在庫が不足している場合は注文できない() { }
+
+// パターン2: Given-When-Then形式
+@Test
+void given在庫10個_when15個注文_then在庫不足例外() { }
+
+// パターン3: メソッド名_条件_期待結果
+@Test
+void reduceStock_在庫不足_IllegalStateException() { }
+```
+
+#### 3. テストデータの準備
+
+```java
+// テストフィクスチャの使用
+public class UserTestFixture {
+    public static User createDefaultUser() {
+        return new User(
+            "test@example.com",
+            "password123",
+            "テストユーザー"
+        );
+    }
+
+    public static User createUserWithEmail(String email) {
+        return new User(
+            email,
+            "password123",
+            "テストユーザー"
+        );
+    }
+}
+```
+
+## リファクタリングパターン
+
+### よく使うリファクタリング手法
+
+| パターン | 適用場面 | 例 |
+|----------|----------|-----|
+| メソッド抽出 | 長いメソッドの分割 | 検証ロジックを別メソッドへ |
+| 変数抽出 | 複雑な式の簡略化 | 計算結果を一時変数へ |
+| クラス抽出 | 責務の分離 | 値オブジェクトの抽出 |
+| メソッド移動 | 適切なクラスへの配置 | ユーティリティメソッドの移動 |
+| 条件記述の分解 | 複雑な条件式の整理 | if文の条件をメソッド化 |
+| ループの分割 | 単一責任の原則適用 | 異なる処理を別ループへ |
+
+### リファクタリング実施のタイミング
+
+1. **Rule of Three（3回ルール）**
+   - 1回目: そのまま実装
+   - 2回目: 重複に気づくが我慢
+   - 3回目: リファクタリング実施
+
+2. **コードの臭い（Code Smells）を検知したとき**
+   - 長すぎるメソッド（20行以上）
+   - 大きすぎるクラス（200行以上）
+   - 長すぎるパラメータリスト（4個以上）
+   - データの群れ（同じ引数の組み合わせ）
+   - スイッチ文の重複
+
+## 継続的な改善
+
+### ふりかえりでの確認項目
+
+```markdown
+## イテレーションふりかえりテンプレート
+
+### Keep（継続すること）
+- [ ] TDDサイクルの実践
+- [ ] コードレビューの実施
+- [ ] 品質基準の維持
+
+### Problem（問題点）
+- [ ] テスト作成に時間がかかった箇所
+- [ ] リファクタリングが不十分な箇所
+- [ ] 技術的負債の発生箇所
+
+### Try（次に試すこと）
+- [ ] 新しいテスト手法の導入
+- [ ] リファクタリングの自動化
+- [ ] 品質メトリクスの改善
+
+### 数値指標
+- テストカバレッジ: ___%
+- ビルド成功率: ___%
+- バグ発生率: ___件/イテレーション
+- 平均サイクルタイム: ___時間
+```
+
+### 技術的負債の管理
+
+```plantuml
+@startuml
+title 技術的負債の対処フロー
+
+start
+
+:技術的負債の識別;
+note right
+  - コードレビューで発見
+  - 静的解析ツールの警告
+  - パフォーマンス問題
+end note
+
+if (緊急度は?) then (高)
+  :即座に対処;
+  #red:ホットフィックス;
+elseif (影響範囲は?) then (大)
+  :次イテレーションで対処;
+  #yellow:計画的リファクタリング;
+else (小)
+  :バックログに追加;
+  #lightgreen:継続的改善;
+endif
+
+:対処結果の記録;
+note right
+  - 対処内容
+  - 所要時間
+  - 学習事項
+end note
+
+stop
+
+@enduml
+```
+
+## まとめ
+
+コーディングとテストは、よいソフトウェアを作るための最も基本的で重要な活動です。TDDを中心としたこれらの規律を守ることで：
+
+1. **品質の作り込み** - バグの早期発見と修正
+2. **設計の改善** - 継続的なリファクタリング
+3. **変更容易性** - テストによる安全網
+4. **ドキュメント性** - テストが仕様書として機能
+
+これらの実践により、「変更を楽に安全にできて役に立つソフトウェア」の実現を目指します。

package/lib/assets/docs/reference//351/226/213/347/231/272/343/202/254/343/202/244/343/203/211.md

@@ -191,9 +191,9 @@ state イテレーション {
 @startuml
 
 [*] --> イテレーション計画
-イテレーション計画 --> ユーザーストーリー作成
-ユーザーストーリー作成 --> ユースケース作成
-ユースケース作成 --> コーディングとテスト
+イテレーション計画 --> ユースケース作成
+ユースケース作成 --> ユーザーストーリー作成
+ユーザーストーリー作成 --> コーディングとテスト
 アーキテクチャ設計 --> コーディングとテスト
 コーディングとテスト --> アーキテクチャ設計
 データモデル設計 --> コーディングとテスト
@@ -202,7 +202,7 @@ state イテレーション {
 コーディングとテスト --> ドメインモデル設計
 コーディングとテスト --> ユーザーインターフェース設計
 ユーザーインターフェース設計 --> コーディングとテスト
-コーディングとテスト --> ユースケース作成
+コーディングとテスト --> ユーザーストーリー作成
 コーディングとテスト --> イテレーションレビュー
 イテレーションレビュー --> イテレーション計画
 イテレーションレビュー --> [*]
@@ -210,173 +210,7 @@ state イテレーション {
 @enduml
 ```
 
-開発は、以下の2つのアプローチを状況に応じて使い分けます：
-
-1. インサイドアウトアプローチ
-- データモデルから実装を開始
-- ドメイン駆動設計に適合
-- テストファーストな開発
-
-2. アウトサイドインアプローチ
-- UIから実装を開始
-- プロトタイプ駆動開発に適合
-- モックを活用した開発
-
-
-```plantuml
-@startuml
-start
-:ユーザーストーリー;
-if (CRUD実装済み?) then (はい)
-  :ドメインモデル;
-  :アウトサイドイン;
-else (いいえ)
-  :貧血ドメインモデル;
-  :インサイドサイドアウト;
-endif
-if (API実装済み?) then (はい)
-  :インサイドサイドアウト;
-else (いいえ)
-  :アウトサイドイン;
-endif
-stop
-@enduml
-```
-#### インサイドアウト
-
-```plantuml
-@startuml
-start
-:データベース;
-:インフラストラクチャ層;
-:ドメイン層;
-:サービス層;
-:プレゼンテーション層;
-stop
-@enduml
-```
-
-```plantuml
-@startuml
-[*] --> コーディングとテスト
-コーディングとテスト --> TODO : TODOリストを作成
-TODO --> Red : 最小限の実装
-Red --> Green : テストを書く
-Green --> Refactor : リファクタリング
-Refactor --> Red : 次の実装
-Red : 動作の確認
-Green : テストが成功
-Refactor : コードの重複を除去してリファクタリング
-Refactor --> TODO : リファクタリングが完了したらTODOリストに戻る
-TODO --> コーディングとテスト : TODOリストが空になるまで繰り返す
-コーディングとテスト --> イテレーションレビュー
-@enduml
-```
-
-#### アウトサイドイン
-
-```plantuml
-@startuml
-start
-:プレゼンテーション層;
-:サービス層;
-:ドメイン層;
-:インフラストラクチャ層;
-:データベース;
-stop
-@enduml
-```
-
-```plantuml
-@startuml
-[*] --> コーディングとテスト
-コーディングとテスト --> TODO : TODOリストを作成
-TODO --> Red : テストを書く
-Red --> Green : 最小限の実装
-Green --> Refactor : リファクタリング
-Refactor --> Red : 次のテストを書く
-Red : テストに失敗
-Green : テストに通る最小限の実装
-Refactor : コードの重複を除去してリファクタリング
-Refactor --> TODO : リファクタリングが完了したらTODOリストに戻る
-TODO --> コーディングとテスト : TODOリストが空になるまで繰り返す
-コーディングとテスト --> イテレーションレビュー
-@enduml
-```
-
-### コーディングとテスト
-
-```plantuml
-@startuml "イテレーション開発プロセス"
-
-start
-
-partition "イテレーション開始" {
-}
-
-repeat :TODO確認;
-partition "TDD実装サイクル" {
-    repeat
-      :TODO選択;
-      
-      repeat
-        :失敗テスト作成 (Red);
-        :最小実装 (Green);
-        :リファクタリング (Refactor);
-        :品質チェック;
-        if (品質OK?) then (yes)
-          :コミット;
-        else (no)
-          :修正;
-        endif
-      repeat while (TODO完了?)
-      partition "コードレビュー" {
-      }
-    repeat while (全TODO完了?)
-}
-
-if (イテレーション完了?) then (yes)
-  partition "受け入れ" {
-    partition "ユーザーレビュー" {
-    }
-    if (受け入れOK?) then (yes)
-      partition "ふりかえり" {
-      }
-    else (no)
-      partition "修正対応" {
-      }
-    endif
-  }
-else (no)
-  partition "設計リファクタリング" {
-      partition "アーキテクチャリファクタリング" {
-      }
-      partition "データモデルリファクタリング" {
-      }
-      partition "ドメインモデルリファクタリング" {
-      }
-      partition "UIリファクタリング" {
-      }
-  }
-endif
-repeat while (次のTODO?)
-
-stop
-
-@enduml
-```
-- 必ずイテレーション単位で開発を行う
-- 勝手に次のイテレーションに進まない
-- コミットは必ずTODO単位で実施する
-- コミットの前に必ず品質確認を実施する
-- コミットメッセージはAngularのコミットメッセージの書き方を参考にする
-    - feat: 新機能の追加
-    - fix: バグ修正
-    - docs: ドキュメントの変更
-    - style: フォーマットやセミコロンの追加など、コードの動作に影響しない変更
-    - refactor: リファクタリング（バグ修正や機能追加ではない）
-    - test: テストコードの追加や修正
-    - chore: ビルドプロセスや補助ツールの変更
+開発の詳細は [コーディングとテストガイド](コーディングとテストガイド.md) を参照
 
 ## 運用
 

package/lib/assets/scripts/journal.js

@@ -4,6 +4,9 @@ import fs from 'fs';
 import path from 'path';
 import { execSync } from 'child_process';
 
+// Increase buffer to safely handle large diffs/logs
+const MAX_BUFFER = 256 * 1024 * 1024; // 256 MB
+
 // Function to register the journal:generate task
 export default function(gulp) {
   // Helper function to generate journal for a specific date
@@ -16,7 +19,7 @@ export default function(gulp) {
     const journalFile = path.join(journalDir, `${formattedDate}.md`);
 
     // Get commits for this date
-    const commits = execSync(`git log --since="${dateStr} 00:00:00" --until="${dateStr} 23:59:59" --format="%h %s%n%b"`, { maxBuffer: 1024 * 1024 * 10 }).toString();
+    const commits = execSync(`git log --since="${dateStr} 00:00:00" --until="${dateStr} 23:59:59" --format="%h %s%n%b"`, { maxBuffer: MAX_BUFFER }).toString();
 
     // Skip if no commits
     if (!commits.trim()) {
@@ -25,23 +28,30 @@ export default function(gulp) {
     }
 
     // Get detailed changes for each commit on this date
-    const commitHashesOutput = execSync(`git log --since="${dateStr} 00:00:00" --until="${dateStr} 23:59:59" --format="%h"`, { maxBuffer: 1024 * 1024 * 10 }).toString();
+    const commitHashesOutput = execSync(`git log --since="${dateStr} 00:00:00" --until="${dateStr} 23:59:59" --format="%h"`, { maxBuffer: MAX_BUFFER }).toString();
     const commitHashes = commitHashesOutput.split('\n').map(line => line.trim()).filter(Boolean);
 
     const detailedCommits = [];
 
     commitHashes.forEach(hash => {
       // Get commit details
-      const commitMessage = execSync(`git show -s --format="%s%n%b" ${hash}`, { maxBuffer: 1024 * 1024 * 10 }).toString().trim();
+      const commitMessage = execSync(`git show -s --format="%s%n%b" ${hash}`, { maxBuffer: MAX_BUFFER }).toString().trim();
 
       // Get files changed
-      const filesChangedOutput = execSync(`git show --name-status ${hash}`, { maxBuffer: 1024 * 1024 * 10 }).toString();
+      const filesChangedOutput = execSync(`git show --name-status ${hash}`, { maxBuffer: MAX_BUFFER }).toString();
       const filesChanged = filesChangedOutput.split('\n')
           .map(line => line.trim())
           .filter(line => /^[AMDRT]\s/.test(line));
 
-      // Get code changes (diff)
-      const diff = execSync(`git show ${hash} --color=never`, { maxBuffer: 1024 * 1024 * 10 }).toString();
+      // Get code changes (diff) with robust handling for large diffs
+      let diff = '';
+      try {
+        diff = execSync(`git show ${hash} --color=never`, { maxBuffer: MAX_BUFFER }).toString();
+      } catch (e) {
+        // Fallback to a summary if diff is too large or any error occurs
+        const summary = execSync(`git show --stat --oneline ${hash} --color=never`, { maxBuffer: MAX_BUFFER }).toString();
+        diff = `[Diff too large or failed to load. Showing summary instead.]\n\n${summary}`;
+      }
 
       detailedCommits.push({
         hash,
@@ -144,7 +154,7 @@ export default function(gulp) {
     }
 
     // Get all commit dates
-    const datesOutput = execSync('git log --format=%ad --date=short').toString();
+    const datesOutput = execSync('git log --format=%ad --date=short', { maxBuffer: MAX_BUFFER }).toString();
     const dates = [...new Set(datesOutput.split('\n').map(line => line.trim()).filter(Boolean))];
 
     dates.forEach(dateStr => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@k2works/claude-code-booster",
-  "version": "0.3.0",
+  "version": "0.5.0",
   "description": "AI Agent Development Support Tool",
   "main": "main.js",
   "bin": {