@k2works/claude-code-booster 6.2.0 → 6.3.1

package/lib/assets/docs/article/getting-start-tdd/elixir/01-todo-list-and-first-test.md

@@ -1,96 +0,0 @@
----
-type: Article
-title: "第 1 章: TODO リストと最初のテスト"
-description: "この章では、FizzBuzz 問題を小さな TODO リストに分解し、ExUnit で最初のテストを書きます。"
-tags: [article, getting-start-tdd, elixir]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 1 章: TODO リストと最初のテスト
-
-## 1.1 はじめに
-
-この章では、FizzBuzz 問題を小さな TODO リストに分解し、ExUnit で最初のテストを書きます。TDD の最初の一歩は、いきなり実装することではなく、失敗するテストから始めることです。
-
-## 1.2 FizzBuzz の仕様と TODO リスト
-
-対象の仕様は次のとおりです。
-
-```text
-1 から 100 までの数を出力する。
-3 の倍数は Fizz、5 の倍数は Buzz、3 と 5 の両方の倍数は FizzBuzz を出力する。
-```
-
-まずは仕様を TODO リストに分解します。
-
-- [ ] 数を文字列として返す
-- [ ] 3 の倍数で Fizz を返す
-- [ ] 5 の倍数で Buzz を返す
-- [ ] 15 の倍数で FizzBuzz を返す
-- [ ] 1 から 100 までの結果をリストで作る
-
-最初のタスクとして「1 を渡すと文字列 1 を返す」だけを扱います。
-
-## 1.3 ExUnit の基本
-
-Elixir では `mix new` で作成したプロジェクトに ExUnit が標準で含まれます。最小のテストは `test` マクロと `assert` マクロで書けます。
-
-```elixir
-# test/fizz_buzz_test.exs
-
-defmodule FizzBuzzTest do
-  use ExUnit.Case
-
-  test "1 を渡すと文字列 1 を返す" do
-    assert FizzBuzz.generate(1) == "1"
-  end
-end
-```
-
-- `test` はテストケースを定義します。
-- `assert` は期待値を検証します。
-
-## 1.4 mix test の使い方
-
-テスト実行は `mix test` を使います。
-
-```bash
-$ mix test
-```
-
-この時点では `FizzBuzz` モジュールが未実装なので、テストは失敗します。これが Red です。
-
-## 1.5 Red から Green へ
-
-### Red: 最初の失敗するテスト
-
-先ほどのテストを実行すると、例えば次のように失敗します。
-
-```text
-** (UndefinedFunctionError) function FizzBuzz.generate/1 is undefined
-```
-
-### Green: 仮実装で通す
-
-まずは最小限の仮実装でテストを通します。
-
-```elixir
-# lib/fizz_buzz.ex
-
-defmodule FizzBuzz do
-  def generate(1), do: "1"
-end
-```
-
-再度 `mix test` を実行します。
-
-```bash
-$ mix test
-```
-
-1 件のテストが成功すれば Green です。まだ汎用的ではありませんが、TDD ではこの小さな成功を積み重ねます。
-
-## 1.6 まとめ
-
-この章では、TODO リスト駆動で最小タスクを切り出し、ExUnit の `test` / `assert` と `mix test` の基本を確認しました。さらに、最初の失敗するテストを書いてから仮実装で成功させる Red → Green を体験しました。

package/lib/assets/docs/article/getting-start-tdd/elixir/02-fake-it-and-triangulation.md

@@ -1,104 +0,0 @@
----
-type: Article
-title: "第 2 章: 仮実装と三角測量"
-description: "前章では「1 を渡すと文字列 1 を返す」を仮実装で通しました。"
-tags: [article, getting-start-tdd, elixir]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 2 章: 仮実装と三角測量
-
-## 2.1 はじめに
-
-前章では「1 を渡すと文字列 1 を返す」を仮実装で通しました。この章では、仮実装から三角測量へ進み、実装を一般化します。
-
-## 2.2 仮実装の限界
-
-前章の実装は次のようなハードコードでした。
-
-```elixir
-defmodule FizzBuzz do
-  def generate(1), do: "1"
-end
-```
-
-この実装は `1` 以外に対応できません。ここで新しいテストを追加して、一般化の必要性を明確にします。
-
-## 2.3 三角測量: 2 を追加する
-
-ExUnit の `describe` ブロックで関心ごとをまとめます。
-
-```elixir
-# test/fizz_buzz_test.exs
-
-defmodule FizzBuzzTest do
-  use ExUnit.Case
-
-  describe "generate/1" do
-    test "1 を渡すと文字列 1 を返す" do
-      assert FizzBuzz.generate(1) == "1"
-    end
-
-    test "2 を渡すと文字列 2 を返す" do
-      assert FizzBuzz.generate(2) == "2"
-    end
-  end
-end
-```
-
-`mix test` を実行すると失敗します。Green にするため、仮実装から一段進めます。
-
-```elixir
-# lib/fizz_buzz.ex
-
-defmodule FizzBuzz do
-  def generate(n), do: Integer.to_string(n)
-end
-```
-
-この変更で、`1` と `2` の両方が通ります。複数の具体例から実装を引き出すのが三角測量です。
-
-## 2.4 3 の倍数で Fizz
-
-次に、FizzBuzz の本題を追加します。
-
-```elixir
-# test/fizz_buzz_test.exs
-
-defmodule FizzBuzzTest do
-  use ExUnit.Case
-
-  describe "generate/1" do
-    test "1 を渡すと文字列 1 を返す" do
-      assert FizzBuzz.generate(1) == "1"
-    end
-
-    test "2 を渡すと文字列 2 を返す" do
-      assert FizzBuzz.generate(2) == "2"
-    end
-
-    test "3 の倍数を渡すと Fizz を返す" do
-      assert FizzBuzz.generate(3) == "Fizz"
-      assert FizzBuzz.generate(6) == "Fizz"
-    end
-  end
-end
-```
-
-これを通す最小実装は次のように書けます。
-
-```elixir
-# lib/fizz_buzz.ex
-
-defmodule FizzBuzz do
-  def generate(n) when rem(n, 3) == 0, do: "Fizz"
-  def generate(n), do: Integer.to_string(n)
-end
-```
-
-`mix test` が成功すれば Green です。
-
-## 2.5 まとめ
-
-この章では、ハードコードの仮実装から、複数ケースによる三角測量で一般化する流れを学びました。また、`describe` でテストを整理し、「2 を渡すと文字列 2」「3 の倍数で Fizz」を ExUnit で表現しました。

package/lib/assets/docs/article/getting-start-tdd/elixir/03-obvious-implementation-and-refactoring.md

@@ -1,118 +0,0 @@
----
-type: Article
-title: "第 3 章: 明白な実装とリファクタリング"
-description: "この章では FizzBuzz の仕様を cond で明白に実装し、1 から 100 までのリスト生成まで完成させます。"
-tags: [article, getting-start-tdd, elixir]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 3 章: 明白な実装とリファクタリング
-
-## 3.1 はじめに
-
-この章では FizzBuzz の仕様を `cond` で明白に実装し、1 から 100 までのリスト生成まで完成させます。最後に、読みやすさを高めるリファクタリングの観点を確認します。
-
-## 3.2 cond による明白な実装
-
-まずは必要なテストを追加します。
-
-```elixir
-# test/fizz_buzz_test.exs
-
-defmodule FizzBuzzTest do
-  use ExUnit.Case
-
-  describe "generate/1" do
-    test "5 の倍数を渡すと Buzz を返す" do
-      assert FizzBuzz.generate(5) == "Buzz"
-    end
-
-    test "15 の倍数を渡すと FizzBuzz を返す" do
-      assert FizzBuzz.generate(15) == "FizzBuzz"
-    end
-  end
-end
-```
-
-このテストを通す明白な実装は次のとおりです。
-
-```elixir
-# lib/fizz_buzz.ex
-
-defmodule FizzBuzz do
-  def generate(n) do
-    cond do
-      rem(n, 15) == 0 -> "FizzBuzz"
-      rem(n, 3) == 0 -> "Fizz"
-      rem(n, 5) == 0 -> "Buzz"
-      true -> Integer.to_string(n)
-    end
-  end
-end
-```
-
-15 を先に判定することがポイントです。
-
-## 3.3 1 から 100 までのリスト生成
-
-続いて、結果一覧を作る関数のテストを書きます。
-
-```elixir
-# test/fizz_buzz_test.exs
-
-defmodule FizzBuzzTest do
-  use ExUnit.Case
-
-  describe "generate_list/0" do
-    test "1 から 100 までの FizzBuzz リストを返す" do
-      result = FizzBuzz.generate_list()
-
-      assert length(result) == 100
-      assert Enum.at(result, 0) == "1"
-      assert Enum.at(result, 2) == "Fizz"
-      assert Enum.at(result, 4) == "Buzz"
-      assert Enum.at(result, 14) == "FizzBuzz"
-    end
-  end
-end
-```
-
-実装はパイプライン演算子 `|>` を使うと読みやすくなります。
-
-```elixir
-# lib/fizz_buzz.ex
-
-defmodule FizzBuzz do
-  def generate(n) do
-    cond do
-      rem(n, 15) == 0 -> "FizzBuzz"
-      rem(n, 3) == 0 -> "Fizz"
-      rem(n, 5) == 0 -> "Buzz"
-      true -> Integer.to_string(n)
-    end
-  end
-
-  def generate_list do
-    1..100
-    |> Enum.map(&generate/1)
-  end
-end
-```
-
-`|>` は「左の結果を右の関数に渡す」演算子です。データの流れを上から下に読めるため、処理の意図が明確になります。
-
-## 3.4 リファクタリングのポイント
-
-テストがすべて通る状態を保ちながら、次を確認します。
-
-- 判定順が明確か（`15` → `3` → `5`）
-- 重複した変換処理がないか
-- 関数名が役割を正しく表しているか
-- テストの責務が分離されているか（`describe` ごとに関心を分ける）
-
-必要なら、テストデータを増やして安全に整理します。TDD では「動くこと」と「読みやすいこと」を両立させます。
-
-## 3.5 まとめ
-
-この章では、`cond` を使った明白な実装で `Buzz` と `FizzBuzz` を追加し、`1..100` のリスト生成を完成させました。さらに `|>` の基本と、テストを守りながら進めるリファクタリングの観点を確認しました。

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

@@ -1,105 +0,0 @@
----
-type: Article
-title: "第 4 章: バージョン管理と Conventional Commits"
-description: "この章では、Elixir プロジェクトを安全に育てるための Git の基本操作と、Conventional Commits の実践方法を学びます。"
-tags: [article, getting-start-tdd, elixir]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 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,97 +0,0 @@
----
-type: Article
-title: "第 5 章: パッケージ管理と静的解析"
-description: "この章では、Elixir の依存管理とコード品質チェックを扱います。"
-tags: [article, getting-start-tdd, elixir]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 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,80 +0,0 @@
----
-type: Article
-title: "第 6 章: タスクランナーと CI/CD"
-description: "この章では、ローカル開発と CI を同じ実行基盤でそろえる方法を扱います。"
-tags: [article, getting-start-tdd, elixir]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 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 の反復を壊さない自動化基盤が整います。