@k2works/claude-code-booster 4.11.0 → 4.12.0

package/lib/assets/docs/article/getting-start-tdd/elixir/04-version-control-and-conventional-commits.md

@@ -1,96 +1,96 @@
-# 第 4 章: バージョン管理と Conventional Commits
-
-## 4.1 はじめに
-
-この章では、Elixir プロジェクトを安全に育てるための Git の基本操作と、Conventional Commits の実践方法を学びます。TDD では小さな変更を頻繁にコミットするため、履歴の読みやすさが品質に直結します。
-
-## 4.2 Git の基本操作
-
-まずは作業の最小ループを押さえます。
-
-```bash
-# 変更確認
-git status
-
-# 差分確認
-git diff
-
-# ステージング
-git add lib/fizz_buzz.ex test/fizz_buzz_test.exs
-
-# コミット
-git commit -m "test: add test for fizzbuzz list generation"
-
-# 履歴確認
-git log --oneline --decorate -n 10
-```
-
-TDD では次の粒度でコミットすると履歴が明確です。
-
-- Red: 失敗するテスト追加
-- Green: テストを通す最小実装
-- Refactor: 振る舞いを変えない整理
-
-## 4.3 Conventional Commits のルール
-
-Conventional Commits は、コミットメッセージを `type: summary` 形式で統一する規約です。
-
-代表的な `type` は次のとおりです。
-
-- `feat`: ユーザーに見える機能追加
-- `fix`: バグ修正
-- `docs`: ドキュメント変更
-- `refactor`: 振る舞いを変えない内部改善
-- `test`: テスト追加・修正
-- `chore`: ビルドや設定などの雑務変更
-
-例:
-
-```text
-feat: add generate_list/0 for 1..100 fizzbuzz output
-fix: handle 15 multiples before 3 and 5 checks
-docs: add chapter 4 for git workflow
-test: add cases for fizz and buzz boundaries
-refactor: simplify generate/1 with cond ordering
-chore: update ci cache key for nix flake
-```
-
-## 4.4 Elixir プロジェクトでのコミット例
-
-`apps/elixir` の FizzBuzz 実装を例に、実際のコミット単位を示します。
-
-```bash
-# Red
-git add test/fizz_buzz_test.exs
-git commit -m "test: add failing test for generate_list/0"
-
-# Green
-git add lib/fizz_buzz.ex
-git commit -m "feat: implement generate_list/0 with enum map"
-
-# Refactor
-git add lib/fizz_buzz.ex test/fizz_buzz_test.exs
-git commit -m "refactor: improve readability of fizzbuzz conditions"
-```
-
-ポイントは、1 コミット 1 意図です。`feat` と `refactor` を同一コミットに混ぜないことで、レビューしやすくなります。
-
-## 4.5 .gitignore の設定
-
-Elixir ではビルド成果物と依存パッケージを Git 管理対象から除外します。`apps/elixir/.gitignore` には少なくとも次を含めます。
-
-```gitignore
-/_build/
-/deps/
-.elixir_ls/
-```
-
-- `/_build/`: `mix compile` の生成物
-- `/deps/`: `mix deps.get` で取得される依存コード
-- `.elixir_ls/`: Elixir Language Server の作業ディレクトリ
-
-これらを除外すると、環境依存ファイルの混入を防げます。
-
-## 4.6 まとめ
-
-この章では、Git の基本操作、Conventional Commits の主要ルール、Elixir プロジェクトでの具体的なコミット例、`.gitignore` の重要設定を確認しました。以降の章では、この履歴運用を前提に品質チェックと自動化を強化します。
+# 第 4 章: バージョン管理と Conventional Commits
+
+## 4.1 はじめに
+
+この章では、Elixir プロジェクトを安全に育てるための Git の基本操作と、Conventional Commits の実践方法を学びます。TDD では小さな変更を頻繁にコミットするため、履歴の読みやすさが品質に直結します。
+
+## 4.2 Git の基本操作
+
+まずは作業の最小ループを押さえます。
+
+```bash
+# 変更確認
+git status
+
+# 差分確認
+git diff
+
+# ステージング
+git add lib/fizz_buzz.ex test/fizz_buzz_test.exs
+
+# コミット
+git commit -m "test: add test for fizzbuzz list generation"
+
+# 履歴確認
+git log --oneline --decorate -n 10
+```
+
+TDD では次の粒度でコミットすると履歴が明確です。
+
+- Red: 失敗するテスト追加
+- Green: テストを通す最小実装
+- Refactor: 振る舞いを変えない整理
+
+## 4.3 Conventional Commits のルール
+
+Conventional Commits は、コミットメッセージを `type: summary` 形式で統一する規約です。
+
+代表的な `type` は次のとおりです。
+
+- `feat`: ユーザーに見える機能追加
+- `fix`: バグ修正
+- `docs`: ドキュメント変更
+- `refactor`: 振る舞いを変えない内部改善
+- `test`: テスト追加・修正
+- `chore`: ビルドや設定などの雑務変更
+
+例:
+
+```text
+feat: add generate_list/0 for 1..100 fizzbuzz output
+fix: handle 15 multiples before 3 and 5 checks
+docs: add chapter 4 for git workflow
+test: add cases for fizz and buzz boundaries
+refactor: simplify generate/1 with cond ordering
+chore: update ci cache key for nix flake
+```
+
+## 4.4 Elixir プロジェクトでのコミット例
+
+`apps/elixir` の FizzBuzz 実装を例に、実際のコミット単位を示します。
+
+```bash
+# Red
+git add test/fizz_buzz_test.exs
+git commit -m "test: add failing test for generate_list/0"
+
+# Green
+git add lib/fizz_buzz.ex
+git commit -m "feat: implement generate_list/0 with enum map"
+
+# Refactor
+git add lib/fizz_buzz.ex test/fizz_buzz_test.exs
+git commit -m "refactor: improve readability of fizzbuzz conditions"
+```
+
+ポイントは、1 コミット 1 意図です。`feat` と `refactor` を同一コミットに混ぜないことで、レビューしやすくなります。
+
+## 4.5 .gitignore の設定
+
+Elixir ではビルド成果物と依存パッケージを Git 管理対象から除外します。`apps/elixir/.gitignore` には少なくとも次を含めます。
+
+```gitignore
+/_build/
+/deps/
+.elixir_ls/
+```
+
+- `/_build/`: `mix compile` の生成物
+- `/deps/`: `mix deps.get` で取得される依存コード
+- `.elixir_ls/`: Elixir Language Server の作業ディレクトリ
+
+これらを除外すると、環境依存ファイルの混入を防げます。
+
+## 4.6 まとめ
+
+この章では、Git の基本操作、Conventional Commits の主要ルール、Elixir プロジェクトでの具体的なコミット例、`.gitignore` の重要設定を確認しました。以降の章では、この履歴運用を前提に品質チェックと自動化を強化します。

package/lib/assets/docs/article/getting-start-tdd/elixir/05-package-management-and-static-analysis.md

@@ -1,88 +1,88 @@
-# 第 5 章: パッケージ管理と静的解析
-
-## 5.1 はじめに
-
-この章では、Elixir の依存管理とコード品質チェックを扱います。`Mix`、`Hex`、`Credo`、`mix format`、複雑度チェックを組み合わせ、TDD の継続速度と品質を両立します。
-
-## 5.2 Mix による依存管理
-
-Elixir の依存関係は `mix.exs` の `deps/0` で定義します。
-
-```elixir
-# apps/elixir/mix.exs
-
-defp deps do
-  [
-    {:credo, "~> 1.7", only: [:dev, :test], runtime: false}
-  ]
-end
-```
-
-依存追加後は `mix deps.get` で取得します。
-
-```bash
-cd apps/elixir
-mix deps.get
-```
-
-`only: [:dev, :test]` を使うと、開発時だけ必要なツール依存を本番実行から分離できます。
-
-## 5.3 Hex パッケージマネージャ
-
-`Hex` は Elixir の公式パッケージレジストリです。`mix deps.get` は `Hex` から依存を解決し、`mix.lock` にバージョンを固定します。
-
-日常的に使う操作は次のとおりです。
-
-```bash
-mix deps.get        # 依存取得
-mix deps.update all # 依存更新
-mix deps.tree       # 依存ツリー確認
-```
-
-チーム開発では `mix.lock` をコミットし、依存の再現性を確保します。
-
-## 5.4 Credo による静的解析
-
-`Credo` は Elixir の静的解析ツールです。本プロジェクトでは厳格モードを使います。
-
-```bash
-mix credo --strict
-```
-
-`--strict` は警告を増やし、早い段階で設計上の問題や可読性低下を検出できます。`apps/elixir/Makefile` でも `lint` タスクとして定義されています。
-
-## 5.5 mix format と .formatter.exs
-
-コードフォーマットは `mix format` で統一します。
-
-```bash
-mix format
-mix format --check-formatted
-```
-
-`apps/elixir/.formatter.exs` では対象ファイルを次のように設定しています。
-
-```elixir
-[
-  inputs: ["{mix,.formatter}.exs", "{config,lib,test}/**/*.{ex,exs}"]
-]
-```
-
-CI では `--check-formatted` を使い、未整形コードの混入を防ぎます。
-
-## 5.6 コード複雑度チェック
-
-本プロジェクトでは `scripts/complexity.sh` で循環複雑度を簡易計測します。
-
-```bash
-bash scripts/complexity.sh --threshold 10 lib
-```
-
-- `--threshold 10`: 閾値を 10 に設定
-- `lib`: チェック対象ディレクトリ
-
-このチェックを `make complexity` や CI に組み込むことで、関数の肥大化を継続的に抑制できます。
-
-## 5.7 まとめ
-
-この章では、`mix.exs` の `deps` を起点にした依存管理、`Hex` によるパッケージ解決、`Credo` と `mix format` による静的品質担保、`scripts/complexity.sh` による複雑度管理を確認しました。次章では、これらを `Makefile` と CI/CD に統合します。
+# 第 5 章: パッケージ管理と静的解析
+
+## 5.1 はじめに
+
+この章では、Elixir の依存管理とコード品質チェックを扱います。`Mix`、`Hex`、`Credo`、`mix format`、複雑度チェックを組み合わせ、TDD の継続速度と品質を両立します。
+
+## 5.2 Mix による依存管理
+
+Elixir の依存関係は `mix.exs` の `deps/0` で定義します。
+
+```elixir
+# apps/elixir/mix.exs
+
+defp deps do
+  [
+    {:credo, "~> 1.7", only: [:dev, :test], runtime: false}
+  ]
+end
+```
+
+依存追加後は `mix deps.get` で取得します。
+
+```bash
+cd apps/elixir
+mix deps.get
+```
+
+`only: [:dev, :test]` を使うと、開発時だけ必要なツール依存を本番実行から分離できます。
+
+## 5.3 Hex パッケージマネージャ
+
+`Hex` は Elixir の公式パッケージレジストリです。`mix deps.get` は `Hex` から依存を解決し、`mix.lock` にバージョンを固定します。
+
+日常的に使う操作は次のとおりです。
+
+```bash
+mix deps.get        # 依存取得
+mix deps.update all # 依存更新
+mix deps.tree       # 依存ツリー確認
+```
+
+チーム開発では `mix.lock` をコミットし、依存の再現性を確保します。
+
+## 5.4 Credo による静的解析
+
+`Credo` は Elixir の静的解析ツールです。本プロジェクトでは厳格モードを使います。
+
+```bash
+mix credo --strict
+```
+
+`--strict` は警告を増やし、早い段階で設計上の問題や可読性低下を検出できます。`apps/elixir/Makefile` でも `lint` タスクとして定義されています。
+
+## 5.5 mix format と .formatter.exs
+
+コードフォーマットは `mix format` で統一します。
+
+```bash
+mix format
+mix format --check-formatted
+```
+
+`apps/elixir/.formatter.exs` では対象ファイルを次のように設定しています。
+
+```elixir
+[
+  inputs: ["{mix,.formatter}.exs", "{config,lib,test}/**/*.{ex,exs}"]
+]
+```
+
+CI では `--check-formatted` を使い、未整形コードの混入を防ぎます。
+
+## 5.6 コード複雑度チェック
+
+本プロジェクトでは `scripts/complexity.sh` で循環複雑度を簡易計測します。
+
+```bash
+bash scripts/complexity.sh --threshold 10 lib
+```
+
+- `--threshold 10`: 閾値を 10 に設定
+- `lib`: チェック対象ディレクトリ
+
+このチェックを `make complexity` や CI に組み込むことで、関数の肥大化を継続的に抑制できます。
+
+## 5.7 まとめ
+
+この章では、`mix.exs` の `deps` を起点にした依存管理、`Hex` によるパッケージ解決、`Credo` と `mix format` による静的品質担保、`scripts/complexity.sh` による複雑度管理を確認しました。次章では、これらを `Makefile` と CI/CD に統合します。

package/lib/assets/docs/article/getting-start-tdd/elixir/06-task-runner-and-ci-cd.md

@@ -1,71 +1,71 @@
-# 第 6 章: タスクランナーと CI/CD
-
-## 6.1 はじめに
-
-この章では、ローカル開発と CI を同じ実行基盤でそろえる方法を扱います。Nix で環境差分を吸収し、`Makefile` と GitHub Actions で品質チェックを自動化します。
-
-## 6.2 Nix 開発環境による環境管理
-
-本プロジェクトの Elixir 開発環境は Nix で提供されています。次のコマンドで同一ツールチェーンに入れます。
-
-```bash
-nix develop .#elixir
-```
-
-この方式により、OS 差分やローカルの手動セットアップ差分を最小化できます。CI でも同じ `nix develop .#elixir` を使うため、ローカル再現性が高くなります。
-
-## 6.3 Makefile でのタスク管理
-
-`apps/elixir/Makefile` には主要タスクが定義されています。
-
-- `make test`: `mix test`
-- `make fmt`: `mix format`
-- `make fmt-check`: `mix format --check-formatted`
-- `make lint`: `mix credo --strict`
-- `make complexity`: `bash scripts/complexity.sh --threshold 10 lib`
-- `make check`: `fmt-check` + `lint` + `complexity` + `test`
-
-開発中は `make check` を最終ゲートにすると、レビュー前の品質をそろえやすくなります。
-
-## 6.4 mix の監視実行と高速テスト
-
-Elixir ではファイル更新検知に Linux 固有の `inotify-tools` は不要です。継続実行したい場合は監視実行を利用します。
-
-```bash
-mix test --watch
-```
-
-また、変更影響のあるテストだけを優先して回すには `--stale` が有効です。
-
-```bash
-mix test --stale
-```
-
-- `--watch`: 保存ごとに再実行
-- `--stale`: 変更があったモジュールに関連するテスト中心で実行
-
-日常開発は `mix test --stale`、節目では `mix test` や `make check` を回す運用が実践的です。
-
-## 6.5 GitHub Actions での Nix ベース CI/CD
-
-Elixir 用 CI は最初から Nix ベースで構築されています。`.github/workflows/elixir-ci.yml` では次の流れを実行します。
-
-1. `actions/checkout@v4`
-2. `cachix/install-nix-action@v30` で Nix を導入
-3. `nix develop .#elixir --command ...` で依存取得・Format・Lint・複雑度・テストを実行
-
-例:
-
-```yaml
-- name: Install Nix
-  uses: cachix/install-nix-action@v30
-
-- name: Run tests
-  run: nix develop .#elixir --command bash -c "cd apps/elixir && mix test"
-```
-
-重要なのは、ローカルと CI が同じ `nix develop` を起点にしている点です。これにより「ローカルでは通るが CI で失敗する」を減らせます。
-
-## 6.6 まとめ
-
-この章では、`nix develop .#elixir` による環境統一、`Makefile` によるタスク標準化、`mix test --watch` / `mix test --stale` の使い分け、GitHub Actions の Nix ベース CI を確認しました。これで TDD の反復を壊さない自動化基盤が整います。
+# 第 6 章: タスクランナーと CI/CD
+
+## 6.1 はじめに
+
+この章では、ローカル開発と CI を同じ実行基盤でそろえる方法を扱います。Nix で環境差分を吸収し、`Makefile` と GitHub Actions で品質チェックを自動化します。
+
+## 6.2 Nix 開発環境による環境管理
+
+本プロジェクトの Elixir 開発環境は Nix で提供されています。次のコマンドで同一ツールチェーンに入れます。
+
+```bash
+nix develop .#elixir
+```
+
+この方式により、OS 差分やローカルの手動セットアップ差分を最小化できます。CI でも同じ `nix develop .#elixir` を使うため、ローカル再現性が高くなります。
+
+## 6.3 Makefile でのタスク管理
+
+`apps/elixir/Makefile` には主要タスクが定義されています。
+
+- `make test`: `mix test`
+- `make fmt`: `mix format`
+- `make fmt-check`: `mix format --check-formatted`
+- `make lint`: `mix credo --strict`
+- `make complexity`: `bash scripts/complexity.sh --threshold 10 lib`
+- `make check`: `fmt-check` + `lint` + `complexity` + `test`
+
+開発中は `make check` を最終ゲートにすると、レビュー前の品質をそろえやすくなります。
+
+## 6.4 mix の監視実行と高速テスト
+
+Elixir ではファイル更新検知に Linux 固有の `inotify-tools` は不要です。継続実行したい場合は監視実行を利用します。
+
+```bash
+mix test --watch
+```
+
+また、変更影響のあるテストだけを優先して回すには `--stale` が有効です。
+
+```bash
+mix test --stale
+```
+
+- `--watch`: 保存ごとに再実行
+- `--stale`: 変更があったモジュールに関連するテスト中心で実行
+
+日常開発は `mix test --stale`、節目では `mix test` や `make check` を回す運用が実践的です。
+
+## 6.5 GitHub Actions での Nix ベース CI/CD
+
+Elixir 用 CI は最初から Nix ベースで構築されています。`.github/workflows/elixir-ci.yml` では次の流れを実行します。
+
+1. `actions/checkout@v4`
+2. `cachix/install-nix-action@v30` で Nix を導入
+3. `nix develop .#elixir --command ...` で依存取得・Format・Lint・複雑度・テストを実行
+
+例:
+
+```yaml
+- name: Install Nix
+  uses: cachix/install-nix-action@v30
+
+- name: Run tests
+  run: nix develop .#elixir --command bash -c "cd apps/elixir && mix test"
+```
+
+重要なのは、ローカルと CI が同じ `nix develop` を起点にしている点です。これにより「ローカルでは通るが CI で失敗する」を減らせます。
+
+## 6.6 まとめ
+
+この章では、`nix develop .#elixir` による環境統一、`Makefile` によるタスク標準化、`mix test --watch` / `mix test --stale` の使い分け、GitHub Actions の Nix ベース CI を確認しました。これで TDD の反復を壊さない自動化基盤が整います。