@k2works/claude-code-booster 4.1.0 → 4.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -17,6 +17,27 @@ FizzBuzz 問題を題材に、TDD(テスト駆動開発)の手法を実践
17
17
 
18
18
  チュートリアルを始める前に、開発環境を準備する。環境構築は**ユーザーにインストラクションを提示し、合意を得てから**進める。勝手にコマンドを実行しない。
19
19
 
20
+ #### コード配置ルール
21
+
22
+ チュートリアルで作成するコードは `apps/` 配下に**言語ごとのディレクトリ**を切って配置する。言語環境・プロジェクト初期化・ソース・テストはすべてそのディレクトリ内で完結させ、他言語と干渉しないようにする。
23
+
24
+ ```text
25
+ apps/
26
+ ├── java/ # Java プロジェクト(build.gradle, src/ など)
27
+ ├── python/ # Python プロジェクト(pyproject.toml, tests/ など)
28
+ ├── typescript/ # TypeScript プロジェクト(package.json, src/ など)
29
+ ├── go/ # Go プロジェクト(go.mod, *_test.go など)
30
+ ├── rust/ # Rust プロジェクト(Cargo.toml, src/ など)
31
+ └── ... # その他の言語も同様に `apps/{lang}/` を作成
32
+ ```
33
+
34
+ **進め方**:
35
+
36
+ 1. 選択言語のディレクトリ `apps/{lang}/` が存在するか確認する
37
+ 2. なければ作成し、各言語標準のプロジェクト初期化コマンド(`cargo init`、`npm init`、`go mod init` 等)をユーザーの合意を得てから実行する
38
+ 3. 以降のテスト・実装コードはすべてこのディレクトリ配下に記述する
39
+
40
+
20
41
  #### 推奨環境: GitHub Codespaces
21
42
 
22
43
  最もスムーズに始められる環境。devcontainer に Nix が設定済みで、言語ごとの開発環境が即座に利用可能。
@@ -35,10 +56,31 @@ nix develop .#node # JavaScript/TypeScript の場合
35
56
 
36
57
  | OS | パッケージマネージャ | 環境構築方法 |
37
58
  |----|--------------------|-------------|
38
- | Windows | [Scoop](https://scoop.sh/) | Scoop で各言語のランタイム・ビルドツールを直接インストール(Nix は非対応) |
59
+ | Windows(**WSL 推奨**) | [WSL](https://learn.microsoft.com/windows/wsl/) + [Nix](https://nixos.org/download) | WSL2(Ubuntu 等)に Nix をインストールし `nix develop .#{lang}` で開発環境に入る |
60
+ | Windows(ネイティブ) | [Scoop](https://scoop.sh/) | Scoop で各言語のランタイム・ビルドツールを直接インストール(Nix は非対応) |
39
61
  | macOS | [Homebrew](https://brew.sh/) + [Nix](https://nixos.org/download) | Nix で `nix develop .#{lang}` または Homebrew で個別インストール |
40
62
  | Linux | [Nix](https://nixos.org/download) | `nix develop .#{lang}` で開発環境に入る |
41
63
 
64
+ Windows ユーザーにはまず **WSL(Windows Subsystem for Linux)** を推奨する。WSL 上では Linux と同じく Nix / devcontainer がそのまま使え、教材の動作例ともっとも齟齬が少ない。WSL を利用できない事情がある場合に限り、ネイティブ Windows + Scoop の構成を提案する。
65
+
66
+ ##### Windows(WSL)での環境構築例
67
+
68
+ ```powershell
69
+ # PowerShell(管理者)で WSL2 と Ubuntu をインストール
70
+ wsl --install -d Ubuntu
71
+ # 再起動後、Ubuntu を起動し初期ユーザーを作成
72
+ ```
73
+
74
+ ```bash
75
+ # WSL(Ubuntu)内で Nix をインストール
76
+ sh <(curl -L https://nixos.org/nix/install) --daemon
77
+
78
+ # 以降は Linux と同じ手順
79
+ nix develop .#java # 例: Java の場合
80
+ ```
81
+
82
+ Windows 側のファイルシステム(`/mnt/c/...`)ではなく、WSL の Linux ファイルシステム(`~` 配下)にリポジトリを clone すると I/O 性能が大幅に向上する。
83
+
42
84
  ##### Windows(Scoop)での環境構築例
43
85
 
44
86
  Windows では Nix が使えないため、Scoop で各言語のツールを個別にインストールする。
@@ -145,11 +187,14 @@ scoop install php composer
145
187
  1. **章の導入**: その章で学ぶ概念と目標を簡潔に説明する
146
188
  2. **TODO リスト提示**: 章の TODO リストを提示し、全体像を共有する
147
189
  3. **段階的な課題提示**: 一度にすべてを見せず、1 ステップずつ課題を出す
148
- 4. **考えさせる**: テストコードを見せる前に「どんなテストを書くべきか?」と問いかける
149
- 5. **Red フェーズ**: 失敗するテストを書くよう促す。ユーザーが書いたテストにフィードバックを与える
150
- 6. **Green フェーズ**: テストを通す最小限のコードを書くよう促す。正解を教えるのではなくヒントを与える
151
- 7. **Refactor フェーズ**: コードの改善ポイントを一緒に考える
152
- 8. **振り返り**: ステップ完了後に学んだ概念を簡潔にまとめる
190
+ 4. **実装コードの提示**: 各ステップで教材に記載された **テストコード・実装コードを必ず提示** する。コードブロックと併せて「どのファイルのどの位置に書くか」も明示する
191
+ 5. **記述方法の選択**: コード提示後、ユーザーに以下のどちらで進めるかを尋ねる
192
+ - **手動記述**: ユーザーが自分の手でエディタに書き写す(学習効果が高い。推奨)
193
+ - **自動記述**: AI が Write/Edit ツールで該当ファイルに自動で記述する(テンポ重視・確認用)
194
+ 6. **Red フェーズ**: 提示したテストコードを記述し、失敗することを一緒に確認する
195
+ 7. **Green フェーズ**: 提示した最小限の実装コードを記述し、テストが通ることを確認する
196
+ 8. **Refactor フェーズ**: 提示したリファクタ後のコードを記述し、テストが通り続けることを確認する。併せて改善ポイントの意図を解説する
197
+ 9. **ステップ振り返り**: ステップ完了後に学んだ概念を簡潔にまとめる
153
198
 
154
199
  #### 対話のトーン
155
200
 
@@ -173,14 +218,40 @@ scoop install php composer
173
218
  - 長いセッションでは適度な区切り(章の終わり)で休憩を提案する
174
219
  - 次回再開時のために、現在の進捗状況を報告する
175
220
 
176
- ### Step 4: 章のまとめ
221
+ ### Step 4: 章のまとめと KPT 振り返り
177
222
 
178
223
  章の終わりに以下を実施する。
179
224
 
180
225
  1. 学んだ概念の要約
181
226
  2. TODO リストの最終状態確認
182
- 3. 次章の予告と接続
183
- 4. (希望があれば)追加の練習問題を提案
227
+ 3. **KPT 振り返りの実施**(必須)
228
+ 4. 次章の予告と接続
229
+ 5. (希望があれば)追加の練習問題を提案
230
+
231
+ #### KPT 振り返りの進め方
232
+
233
+ 各章の最後に、KPT フレームワークで振り返りを行う。ユーザーに以下の 3 観点を順に問いかけ、回答を整理してまとめる。
234
+
235
+ - **Keep(続けたいこと)**: この章でうまくいったこと、今後も続けたい学び方や習慣
236
+ - **Problem(問題点)**: 詰まった箇所、理解が曖昧なまま進んだ点、学習上の課題
237
+ - **Try(次に試すこと)**: 次章または次回の学習で試したい改善アクション
238
+
239
+ KPT は以下のフォーマットでまとめ、セッションログとしてユーザーに提示する。
240
+
241
+ ```markdown
242
+ ## 第 N 章 KPT 振り返り
243
+
244
+ ### Keep
245
+ - (続けたいこと)
246
+
247
+ ### Problem
248
+ - (問題点)
249
+
250
+ ### Try
251
+ - (次に試すこと)
252
+ ```
253
+
254
+ Problem で挙がった項目は、Try で具体的なアクションに変換するよう促す。Try は次章の進め方に反映させる。
184
255
 
185
256
  ## 応用: 複数言語での比較
186
257
 
@@ -192,4 +263,4 @@ scoop install php composer
192
263
  - コードを書くのはユーザー自身。AI はガイド役に徹する
193
264
  - ユーザーが「答えを教えて」と言った場合は教材のコードを提示するが、なぜそうなるかの理解を促す
194
265
  - 環境構築は必ずユーザーの合意を得てから進める。コマンドの実行前にインストラクションを提示し、確認を取る
195
- - GitHub Codespaces + Nix devcontainer が推奨環境。ローカルの場合は OS に応じたパッケージマネージャを使う(Windows: Scoop で各言語を直接インストール、macOS: Homebrew + Nix、Linux: Nix)
266
+ - GitHub Codespaces + Nix devcontainer が推奨環境。ローカルの場合は OS に応じたパッケージマネージャを使う(Windows: **WSL + Nix を第一推奨**、困難なら Scoop で各言語を直接インストール、macOS: Homebrew + Nix、Linux: Nix)
@@ -23,8 +23,8 @@
23
23
  | [レビュー](./review/index.md) | 分析・開発レビュー結果の記録 | `index.md` を整備済み |
24
24
  | [ADR](./adr/index.md) | Architecture Decision Records の管理 | `index.md` を整備済み |
25
25
  | [記事](./article/index.md) | 学習用の記事シリーズ一覧 | `index.md` を整備済み |
26
- | [リファレンス](./reference/index.md) | 開発ガイドラインやベストプラクティス | 29 件のドキュメントを配置 |
27
- | [テンプレート](./template/index.md) | 各種ドキュメントの作成テンプレート | 17 件のテンプレートを配置 |
26
+ | [リファレンス](./reference/index.md) | 開発ガイドラインやベストプラクティス | 30 件のドキュメントを配置 |
27
+ | [テンプレート](./template/index.md) | 各種ドキュメントの作成テンプレート | 18 件のテンプレートを配置 |
28
28
 
29
29
  ## 補足
30
30
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@k2works/claude-code-booster",
3
- "version": "4.1.0",
3
+ "version": "4.2.0",
4
4
  "description": "AI Agent Development Support Tool",
5
5
  "main": "main.js",
6
6
  "bin": {
@@ -1,6 +0,0 @@
1
- # Agent Memory Index
2
-
3
- ## Project memories
4
- - [project_cargo_tracker.md](project_cargo_tracker.md) — cargo-tracker のプロジェクト構成と gradlew 実行場所、既存テスト失敗状況
5
- - [project_ddd_patterns.md](project_ddd_patterns.md) — cargo-tracker の DDD パターン(集約・値オブジェクト・ドメインイベントの実装規約)
6
- - [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
@@ -1,11 +0,0 @@
1
- ---
2
- name: cargo-tracker-project-context
3
- description: case-study-cargo-tracker プロジェクトの基本構成と開発上の注意点
4
- type: project
5
- ---
6
-
7
- Spring Boot 3.4.x / Java 25 / Gradle プロジェクト。`apps/cargo-tracker/` 配下に gradlew.bat がある。
8
-
9
- **Why:** リポジトリルートではなく `apps/cargo-tracker/` でコマンドを実行する必要がある。また既存の統合テスト(BookingRepository 統合テスト、ShipperRepository 統合テスト、Spring コンテキストテスト)は現時点で失敗しており、これらは既存の事前失敗であることが確認済み。
10
-
11
- **How to apply:** テスト実行コマンドは `Set-Location "C:\Users\PC202411-1\IdeaProjects\case-study-cargo-tracker\apps\cargo-tracker"; & ".\gradlew.bat" "test"` を使う。全テスト実行時に既存失敗があっても quote コンテキストが Green ならば問題なし。
@@ -1,27 +0,0 @@
1
- ---
2
- name: cargo-tracker-ddd-patterns
3
- description: case-study-cargo-tracker の DDD パターン(集約、値オブジェクト、ドメインイベント)の実装規約
4
- type: project
5
- ---
6
-
7
- ## 集約ルート(Aggregate Root)パターン
8
- - `register()`/`issue()` ファクトリメソッドでドメインイベントを発行し集約を生成
9
- - `reconstitute()` ファクトリメソッドはドメインイベントを発行せず永続化ストアから再構成
10
- - 全フィールドは `final`(イミュータブル)
11
- - `domainEvents` は `List<DomainEvent>` で内部に持ち、`getDomainEvents()` で `unmodifiableList` を返す
12
-
13
- ## 値オブジェクト(Value Object)パターン
14
- - コンストラクタで全バリデーション(null/blank チェック、正数チェック)
15
- - `equals()/hashCode()` を実装
16
- - `BigDecimal` の `equals` では精度差異が出るため `compareTo()==0` と `stripTrailingZeros()` を使う
17
-
18
- ## ドメインイベント
19
- - `DomainEvent` はマーカーインターフェース
20
- - イベントは Java `record` で実装(例: `record QuoteIssuedEvent(QuoteId quoteId, QuoteNumber quoteNumber) implements DomainEvent`)
21
-
22
- ## package-info.java
23
- - コンテキストルートに `@NonNullApi` アノテーション付きの package-info.java を作成
24
-
25
- **Why:** booking コンテキストが確立したパターン。quote コンテキスト実装時に同一パターンを踏襲した。
26
-
27
- **How to apply:** 新しいコンテキスト実装時に同様のパターンを使う。
@@ -1,19 +0,0 @@
1
- ---
2
- name: US07 route assignment implementation
3
- description: Implementation patterns and notes for US07 (route selection and booking assignment)
4
- type: project
5
- ---
6
-
7
- US07 implemented on 2026-04-02. All 253 tests pass with inside-out TDD.
8
-
9
- **Key patterns:**
10
- - Added AssignedRoute value object (record), BookingRouteAssignedEvent, Booking.assignRoute() to domain layer
11
- - Added AssignRouteCommand + AssignRouteCommandService to application layer
12
- - Flyway V006 adds 3 columns to bookings table; H2-compatible: one ALTER TABLE per column
13
- - BookingRecord record added 3 fields (after status, before createdAt)
14
- - BookingMapper.java: added update() method; BookingRepositoryImpl.save() switches insert/update via findById check
15
- - WebMvcTest: must add @MockitoBean for AssignRouteCommandService in BookingRestControllerTest and BookingWebControllerTest
16
-
17
- **Why:** H2 does not support ADD COLUMN c1, c2 in one statement. Must split into separate ALTER TABLE statements.
18
-
19
- **How to apply:** When creating Flyway migrations, use H2-compatible syntax. Split multi-column additions into separate ALTER TABLE statements.