@k2works/claude-code-booster 3.3.1 → 3.4.0

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

@@ -60,6 +60,7 @@ Claude Code をより効率的に使うための基本設定テンプレート
 | :--- | :--- |
 | `analyzing-review` | 分析成果物のマルチパースペクティブレビュー。XP エージェント 5 名（PM、アーキテクト、ID、テスター、ユーザー代表）を並列起動。 |
 | `developing-review` | 開発成果物のマルチパースペクティブレビュー。XP エージェント 5 名（プログラマー、テスター、アーキテクト、TW、ユーザー代表）を並列起動。 |
+| `developing-uiux-review` | UI/UX 成果物のマルチパースペクティブレビュー。XP エージェント 2 名（インタラクションデザイナー、ユーザー代表）を並列起動。 |
 | `operating-review` | 運用成果物のマルチパースペクティブレビュー。XP エージェント 3 名（アーキテクト、テスター、PM）を並列起動。 |
 
 #### 計画・進捗系
@@ -69,6 +70,7 @@ Claude Code をより効率的に使うための基本設定テンプレート
 | `planning-releases` | アジャイルなリリース計画とイテレーション計画を作成・管理。 |
 | `syncing-github-project` | リリース計画を GitHub Project・Issue・Milestone に同期。 |
 | `tracking-progress` | プロジェクトの開発進捗を包括的に分析しレポート生成。 |
+| `validating-iteration-plan` | イテレーション計画と上流設計ドキュメント群との整合性を検証。 |
 
 #### 運用系
 
@@ -165,6 +167,7 @@ Claude Code をより効率的に使うための基本設定テンプレート
 │   ├── developing-frontend/SKILL.md
 │   ├── developing-release/SKILL.md
 │   ├── developing-review/SKILL.md
+│   ├── developing-uiux-review/SKILL.md
 │   ├── operating-setup/SKILL.md
 │   ├── operating-qt/SKILL.md
 │   ├── operating-script/SKILL.md
@@ -183,7 +186,8 @@ Claude Code をより効率的に使うための基本設定テンプレート
 │   ├── orchestrating-analysis/SKILL.md
 │   ├── orchestrating-development/SKILL.md
 │   ├── orchestrating-operation/SKILL.md
-│   └── orchestrating-project/SKILL.md
+│   ├── orchestrating-project/SKILL.md
+│   └── validating-iteration-plan/SKILL.md
 ├── README.md
 ├── settings.json                       # Claude Code 設定
 └── settings.local.json                 # ローカル環境用設定

package/lib/assets/.claude/agent-memory/xp-programmer/MEMORY.md

@@ -0,0 +1,6 @@
+# Agent Memory Index
+
+## Project memories
+- [project_cargo_tracker.md](project_cargo_tracker.md) — cargo-tracker のプロジェクト構成と gradlew 実行場所、既存テスト失敗状況
+- [project_ddd_patterns.md](project_ddd_patterns.md) — cargo-tracker の DDD パターン（集約・値オブジェクト・ドメインイベントの実装規約）
+- [project_us07_route_assignment.md](project_us07_route_assignment.md) — US07 route assignment: H2-compatible Flyway migrations, insert/update switching in repository, WebMvcTest mock requirements

package/lib/assets/.claude/agent-memory/xp-programmer/project_cargo_tracker.md

@@ -0,0 +1,11 @@
+---
+name: cargo-tracker-project-context
+description: case-study-cargo-tracker プロジェクトの基本構成と開発上の注意点
+type: project
+---
+
+Spring Boot 3.4.x / Java 25 / Gradle プロジェクト。`apps/cargo-tracker/` 配下に gradlew.bat がある。
+
+**Why:** リポジトリルートではなく `apps/cargo-tracker/` でコマンドを実行する必要がある。また既存の統合テスト（BookingRepository 統合テスト、ShipperRepository 統合テスト、Spring コンテキストテスト）は現時点で失敗しており、これらは既存の事前失敗であることが確認済み。
+
+**How to apply:** テスト実行コマンドは `Set-Location "C:\Users\PC202411-1\IdeaProjects\case-study-cargo-tracker\apps\cargo-tracker"; & ".\gradlew.bat" "test"` を使う。全テスト実行時に既存失敗があっても quote コンテキストが Green ならば問題なし。

package/lib/assets/.claude/agent-memory/xp-programmer/project_ddd_patterns.md

@@ -0,0 +1,27 @@
+---
+name: cargo-tracker-ddd-patterns
+description: case-study-cargo-tracker の DDD パターン（集約、値オブジェクト、ドメインイベント）の実装規約
+type: project
+---
+
+## 集約ルート（Aggregate Root）パターン
+- `register()`/`issue()` ファクトリメソッドでドメインイベントを発行し集約を生成
+- `reconstitute()` ファクトリメソッドはドメインイベントを発行せず永続化ストアから再構成
+- 全フィールドは `final`（イミュータブル）
+- `domainEvents` は `List<DomainEvent>` で内部に持ち、`getDomainEvents()` で `unmodifiableList` を返す
+
+## 値オブジェクト（Value Object）パターン
+- コンストラクタで全バリデーション（null/blank チェック、正数チェック）
+- `equals()/hashCode()` を実装
+- `BigDecimal` の `equals` では精度差異が出るため `compareTo()==0` と `stripTrailingZeros()` を使う
+
+## ドメインイベント
+- `DomainEvent` はマーカーインターフェース
+- イベントは Java `record` で実装（例: `record QuoteIssuedEvent(QuoteId quoteId, QuoteNumber quoteNumber) implements DomainEvent`）
+
+## package-info.java
+- コンテキストルートに `@NonNullApi` アノテーション付きの package-info.java を作成
+
+**Why:** booking コンテキストが確立したパターン。quote コンテキスト実装時に同一パターンを踏襲した。
+
+**How to apply:** 新しいコンテキスト実装時に同様のパターンを使う。

package/lib/assets/.claude/agent-memory/xp-programmer/project_us07_route_assignment.md

@@ -0,0 +1,19 @@
+---
+name: US07 route assignment implementation
+description: Implementation patterns and notes for US07 (route selection and booking assignment)
+type: project
+---
+
+US07 implemented on 2026-04-02. All 253 tests pass with inside-out TDD.
+
+**Key patterns:**
+- Added AssignedRoute value object (record), BookingRouteAssignedEvent, Booking.assignRoute() to domain layer
+- Added AssignRouteCommand + AssignRouteCommandService to application layer
+- Flyway V006 adds 3 columns to bookings table; H2-compatible: one ALTER TABLE per column
+- BookingRecord record added 3 fields (after status, before createdAt)
+- BookingMapper.java: added update() method; BookingRepositoryImpl.save() switches insert/update via findById check
+- WebMvcTest: must add @MockitoBean for AssignRouteCommandService in BookingRestControllerTest and BookingWebControllerTest
+
+**Why:** H2 does not support ADD COLUMN c1, c2 in one statement. Must split into separate ALTER TABLE statements.
+
+**How to apply:** When creating Flyway migrations, use H2-compatible syntax. Split multi-column additions into separate ALTER TABLE statements.

package/lib/assets/.claude/skills/validating-iteration-plan/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: validating-iteration-plan
+description: イテレーション計画と上流設計ドキュメント群（ユーザーストーリー、ドメインモデル、データモデル、UI 設計）との整合性を検証する。「イテレーション計画を検証したい」「計画の整合性をチェックして」「イテレーション計画を作成した」「計画と設計ドキュメントの不整合を確認したい」といった場面で発動する。planning-releases でイテレーション計画を作成した直後にも積極的に使用すること。計画作成後に必ず本検証を実施することで、開発着手前にドキュメント間の不整合を検知・修正できる。
+---
+
+# イテレーション計画の整合性検証
+
+イテレーション計画は複数の設計ドキュメントから情報を引用・参照するため、ドキュメント間の不整合がそのまま実装の不整合に直結する。計画作成後に本検証を実施し、開発着手前に不整合を検知・修正する。
+
+## 検証対象ドキュメント
+
+| # | 検証対象 | パス | 検証内容 |
+|---|---------|------|---------|
+| 1 | ユーザーストーリー | `docs/requirements/user_story.md` | ストーリー ID・タイトル・アクター・受入基準の一致 |
+| 2 | ドメインモデル | `docs/design/domain-model.md` | 集約・エンティティ・値オブジェクトの名称・構造・関連の一致 |
+| 3 | データモデル | `docs/design/data-model.md` | テーブル名・カラム名・型・制約・命名規約の一致 |
+| 4 | UI 設計（ビュー） | `docs/design/ui_design.md` | ワイヤーフレーム構造・ナビバー形式・テーブル表記・URL パスの一致 |
+| 5 | UI 設計（インタラクション） | `docs/design/ui_design.md` | 画面遷移・htmx パターン・PRG パターン・エラー処理・フィードバックメッセージの一致 |
+| 6 | ゴールの整合性 | イテレーション計画全体 | ゴール・ストーリー・設計・タスク・見積もりの内部整合性 |
+
+## 検証手順
+
+6 ステップを順に実行する。各ステップは並列実行も可能。不整合を発見した場合はイテレーション計画を修正し、変更点を注記する。
+
+### ステップ 1: ユーザーストーリーとの整合性
+
+イテレーション計画の「ストーリー詳細」セクションと `user_story.md` を比較する。
+
+**チェック項目**:
+
+- [ ] ストーリー ID（US番号）が一致している
+- [ ] ストーリータイトルが一致している
+- [ ] アクター（「として」の部分）が一致している
+- [ ] ストーリー文（「したい」「なぜなら」の部分）が一致している（省略なく全文一致）
+- [ ] 受入基準の項目数と内容が一致している
+- [ ] 対応 UC 番号が一致している
+
+**よくある不整合**:
+
+- ストーリー文の一部省略（例: 「予約情報」-> 元は「予約情報（出発地・目的地・期限・貨物仕様）」）
+- 受入基準の列挙が省略されている（例: 制約条件の具体名が省略）
+
+### ステップ 2: ドメインモデルとの整合性
+
+イテレーション計画の「設計 > ドメインモデル」セクションと `domain-model.md` を比較する。
+
+**チェック項目**:
+
+- [ ] 集約ルートの名称が一致している
+- [ ] 値オブジェクトの名称・フィールドが一致している（例: `Schedule` vs `VoyageSchedule`）
+- [ ] エンティティの名称・フィールドが一致している（例: `CarrierMovement` vs `VoyageSchedule`）
+- [ ] 共有カーネル参照が正しい（例: `Location` を使うべき箇所で `String` になっていないか）
+- [ ] 既存の集約構造を破壊する変更になっていないか
+- [ ] 新規追加の場合、既存構造との関連が明記されているか
+- [ ] domain-model.md への反映が必要な変更点が注記されているか
+
+**よくある不整合**:
+
+- 既存の値オブジェクト名と異なる名称を使用（例: `Schedule` -> `VoyageSchedule`）
+- 既存の集約構造（親子関係）を無視した新規モデル設計
+- 共有カーネル（`Location`）を参照せず、直接 `String` で locode を保持
+
+### ステップ 3: データモデルとの整合性
+
+イテレーション計画の「設計 > データモデル」セクションと `data-model.md` を比較する。
+
+**チェック項目**:
+
+- [ ] テーブル名の単数形/複数形が data-model.md の規約と一致している
+- [ ] PK 設計が一致している（サロゲートキー `BIGSERIAL` + 業務キー `UK` の規約）
+- [ ] FK の参照先がサロゲートキー（`id`）を参照している（業務キー直接参照になっていないか）
+- [ ] カラム名が一致している（例: `departure_location_unlocode` vs `departure_location`）
+- [ ] データ型が一致している（例: `TIMESTAMP` vs `DATE`）
+- [ ] 順序カラム名が一致している（例: `seq_number` vs `sequence_order`）
+- [ ] 監査カラム（`created_at`・`updated_at`）が含まれている
+- [ ] DB 構文が一致している（例: `BIGSERIAL` vs `AUTO_INCREMENT`）
+- [ ] 既存テーブルの拡張か新規テーブルかが明確に区別されている
+- [ ] 新規テーブルの場合、既存テーブルとの関係が既存の設計と整合しているか
+
+**よくある不整合**:
+
+- テーブル名が複数形（`voyages`）-> data-model.md は単数形（`voyage`）
+- PK が業務キー直接（`voyage_number PRIMARY KEY`）-> 規約はサロゲートキー + UK
+- FK が業務キー参照（`REFERENCES voyages(voyage_number)`）-> 規約は `voyage.id` 参照
+- PostgreSQL 構文（`BIGSERIAL`）と MySQL 構文（`AUTO_INCREMENT`）の混在
+
+### ステップ 4: UI 設計（ビュー）との整合性
+
+イテレーション計画の「設計 > ユーザーインターフェース > ビュー」セクションと `ui_design.md` を比較する。
+
+**チェック項目**:
+
+- [ ] ナビバー構造が `{/ <b>CargoTracker</b> | メニュー... | [ログアウト] }` 形式と一致している
+- [ ] テーブルヘッダー表記が `**太字**` 形式と一致している（`^カレット^` 形式になっていないか）
+- [ ] URL パスが画面一覧の規約と一致している
+- [ ] 新規画面の画面一覧エントリが定義されている
+- [ ] 既存画面の拡張の場合、拡張箇所が明確に区別されている
+- [ ] 検索フォームのレイアウトが既存画面と一致している
+- [ ] ボタン配置・ラベルが既存画面のパターンと一致している
+
+**よくある不整合**:
+
+- 独自のナビバー構造を使用
+- テーブルヘッダーの表記形式が異なる
+- URL パスが未定義
+- 既存画面との関係（拡張 vs 新規）が不明確
+
+### ステップ 5: UI 設計（インタラクション）との整合性
+
+イテレーション計画の「設計 > ユーザーインターフェース > インタラクション」セクションと `ui_design.md` の画面遷移図・htmx パターン・フィードバック規約を比較する。
+
+**チェック項目**:
+
+- [ ] 画面遷移図に全画面の state が定義されている（URL パス・説明テキスト付き）
+- [ ] バリデーションエラーの自己ループ遷移が全フォーム画面に定義されている
+- [ ] 遷移方式（GET / PRG）が各遷移に明記されている
+- [ ] 既存の state（航路一覧等）との遷移関係が定義されている
+- [ ] htmx パターン（`hx-get`/`hx-post`・`hx-target`・`hx-swap`）が定義されている
+- [ ] フィードバックメッセージ（成功・警告・エラー）とスタイル（`alert-*`）が定義されている
+- [ ] htmx エラーハンドリング（`htmx:responseError`）への対応が考慮されている
+
+**よくある不整合**:
+
+- バリデーションエラー自己ループ遷移の欠落
+- htmx パターンの記述がない（画面遷移図のみで動的更新方式が不明）
+- フィードバックメッセージの定義がない
+- 既存画面 state との遷移関係が切断されている
+
+### ステップ 6: ゴールの整合性（最終確認）
+
+イテレーション計画全体を俯瞰し、イテレーションのゴールと各ストーリー・設計・タスクが一貫しているかを確認する。ステップ 1-5 が個別ドキュメントとの突合であるのに対し、本ステップは計画内部の論理的整合性を検証する最終関門である。
+
+**チェック項目**:
+
+- [ ] イテレーションゴール（目的・達成条件）が明確に記述されている
+- [ ] 含まれる全ストーリーがゴールの達成に寄与している（ゴールと無関係なストーリーが混入していないか）
+- [ ] ゴールの達成に必要なストーリーが欠落していないか
+- [ ] ストーリー間の依存関係が識別され、実装順序に反映されている
+- [ ] 設計セクション（ドメインモデル・データモデル・UI）がストーリーの受入基準を満たすに十分な内容か
+- [ ] タスク分割がストーリーの受入基準をすべてカバーしている
+- [ ] 見積もり（ストーリーポイント）の合計がチームのベロシティと整合しているか
+- [ ] 前イテレーションからの持ち越し事項が反映されているか
+
+**よくある不整合**:
+
+- ゴールが抽象的すぎて達成条件が判断できない（例: 「航路管理機能を改善する」→ 具体的な完了基準がない）
+- ゴールに対して過剰なストーリーが含まれている（スコープクリープ）
+- 設計セクションの内容がストーリーの一部しかカバーしていない
+- タスク分割が設計セクションと対応していない（設計にあるがタスクにない、またはその逆）
+- ベロシティを超えるポイントが計画されている
+
+## 検証結果の報告
+
+検証完了後、以下の形式で報告する。
+
+```markdown
+## 整合性検証結果
+
+### 検証対象
+- イテレーション計画: `docs/development/iteration_plan-N.md`
+
+### 検証結果サマリー
+
+| ステップ | 検証対象 | 結果 | 不整合件数 |
+|---------|---------|------|-----------|
+| 1 | ユーザーストーリー | OK / NG | N 件 |
+| 2 | ドメインモデル | OK / NG | N 件 |
+| 3 | データモデル | OK / NG | N 件 |
+| 4 | UI 設計（ビュー） | OK / NG | N 件 |
+| 5 | UI 設計（インタラクション） | OK / NG | N 件 |
+| 6 | ゴールの整合性 | OK / NG | N 件 |
+
+### 不整合一覧（NG の場合のみ）
+
+#### ステップ N: 〇〇との不整合
+
+| # | 不整合内容 | 計画の記述 | 正しい記述（ドキュメント準拠） | 修正要否 |
+|---|----------|-----------|---------------------------|---------|
+| 1 | ... | ... | ... | 要修正 |
+```
+
+## 注意事項
+
+- 検証は計画作成直後に実施する（開発着手前に不整合を解消する）
+- 既存ドキュメントへの反映が必要な変更点は、イテレーション計画内に「注」として明記する
+- イテレーション完了時に、注記された変更点を各設計ドキュメントに反映する
+- 不整合を発見した場合、イテレーション計画側を設計ドキュメントに合わせて修正する（設計ドキュメントが正）

package/lib/assets/CLAUDE.md

@@ -67,6 +67,7 @@
 | `planning-releases` | リリース・イテレーション計画 |
 | `syncing-github-project` | GitHub Project 同期 |
 | `tracking-progress` | 進捗分析・レポート |
+| `validating-iteration-plan` | イテレーション計画の整合性検証 |
 
 ### 運用
 

package/package.json

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