@k2works/claude-code-booster 3.5.0 → 3.6.1

package/lib/assets/docs/article/getting-start-tdd/elixir/07-structs-and-protocols.md

@@ -1,110 +1,110 @@
-# 第 7 章: 構造体とプロトコルによるポリモーフィズム
-
-## 7.1 はじめに
-
-この章では、`defstruct` と `defprotocol` を使って、Elixir で型ごとに振る舞いを切り替える方法を学びます。FizzBuzz の値オブジェクトを導入し、`Type01`、`Type02`、`Type03` が同じインターフェース `generate/1` を実装する形でポリモーフィズムを実現します。
-
-## 7.2 defstruct で値オブジェクトを定義する
-
-FizzBuzz の入力値を表す値オブジェクト `FizzBuzz.Model.Value` を定義します。`@enforce_keys` で必須フィールドを宣言すると、不完全な構造体生成を防げます。
-
-```elixir
-defmodule FizzBuzz.Model.Value do
-  @enforce_keys [:number]
-  defstruct [:number]
-
-  @type t :: %__MODULE__{
-          number: pos_integer()
-        }
-end
-```
-
-`@enforce_keys [:number]` により、`%FizzBuzz.Model.Value{}` のような生成は実行時エラーになり、`number` の設定漏れを早期に検出できます。
-
-## 7.3 defprotocol で共通インターフェースを定義する
-
-次に、生成処理の共通契約として `Generatable` プロトコルを定義します。
-
-```elixir
-defprotocol FizzBuzz.Generatable do
-  @spec generate(t()) :: String.t()
-  def generate(value)
-end
-```
-
-プロトコルは「どの型であっても `generate/1` を呼べる」という抽象化を提供します。実際の処理は各構造体の `defimpl` で分岐します。
-
-## 7.4 defimpl で Type01 / Type02 / Type03 を実装する
-
-`Type01`、`Type02`、`Type03` は、それぞれ通常数値、3 の倍数、5 の倍数を表す構造体とします。
-
-```elixir
-defmodule FizzBuzz.Model.Type01 do
-  @enforce_keys [:value]
-  defstruct [:value]
-end
-
-defmodule FizzBuzz.Model.Type02 do
-  @enforce_keys [:value]
-  defstruct [:value]
-end
-
-defmodule FizzBuzz.Model.Type03 do
-  @enforce_keys [:value]
-  defstruct [:value]
-end
-
-defimpl FizzBuzz.Generatable, for: FizzBuzz.Model.Type01 do
-  def generate(%FizzBuzz.Model.Type01{value: value}), do: Integer.to_string(value.number)
-end
-
-defimpl FizzBuzz.Generatable, for: FizzBuzz.Model.Type02 do
-  def generate(%FizzBuzz.Model.Type02{}), do: "Fizz"
-end
-
-defimpl FizzBuzz.Generatable, for: FizzBuzz.Model.Type03 do
-  def generate(%FizzBuzz.Model.Type03{}), do: "Buzz"
-end
-```
-
-この設計では、呼び出し側は具体型を意識せず、`FizzBuzz.Generatable.generate/1` だけを呼べばよくなります。
-
-## 7.5 ExUnit でプロトコル実装を検証する
-
-プロトコルの振る舞いは ExUnit で確認できます。
-
-```elixir
-defmodule FizzBuzz.GeneratableTest do
-  use ExUnit.Case, async: true
-
-  alias FizzBuzz.Generatable
-  alias FizzBuzz.Model.{Type01, Type02, Type03, Value}
-
-  test "Type01 は数値文字列を返す" do
-    value = %Value{number: 1}
-    assert Generatable.generate(%Type01{value: value}) == "1"
-  end
-
-  test "Type02 は Fizz を返す" do
-    value = %Value{number: 3}
-    assert Generatable.generate(%Type02{value: value}) == "Fizz"
-  end
-
-  test "Type03 は Buzz を返す" do
-    value = %Value{number: 5}
-    assert Generatable.generate(%Type03{value: value}) == "Buzz"
-  end
-
-  test "Value は number が必須" do
-    assert_raise ArgumentError, fn ->
-      struct!(Value, %{})
-    end
-  end
-end
-```
-
-`struct!/2` を使うと、`@enforce_keys` の違反をテストで明示的に確認できます。
-
-## 7.6 まとめ
-
-この章では、`defstruct` と `@enforce_keys` で値オブジェクトを定義し、`defprotocol` / `defimpl` で型ごとに `generate/1` を実装しました。Elixir では継承ではなく、プロトコルでポリモーフィズムを組み立てるのが実践的です。
+# 第 7 章: 構造体とプロトコルによるポリモーフィズム
+
+## 7.1 はじめに
+
+この章では、`defstruct` と `defprotocol` を使って、Elixir で型ごとに振る舞いを切り替える方法を学びます。FizzBuzz の値オブジェクトを導入し、`Type01`、`Type02`、`Type03` が同じインターフェース `generate/1` を実装する形でポリモーフィズムを実現します。
+
+## 7.2 defstruct で値オブジェクトを定義する
+
+FizzBuzz の入力値を表す値オブジェクト `FizzBuzz.Model.Value` を定義します。`@enforce_keys` で必須フィールドを宣言すると、不完全な構造体生成を防げます。
+
+```elixir
+defmodule FizzBuzz.Model.Value do
+  @enforce_keys [:number]
+  defstruct [:number]
+
+  @type t :: %__MODULE__{
+          number: pos_integer()
+        }
+end
+```
+
+`@enforce_keys [:number]` により、`%FizzBuzz.Model.Value{}` のような生成は実行時エラーになり、`number` の設定漏れを早期に検出できます。
+
+## 7.3 defprotocol で共通インターフェースを定義する
+
+次に、生成処理の共通契約として `Generatable` プロトコルを定義します。
+
+```elixir
+defprotocol FizzBuzz.Generatable do
+  @spec generate(t()) :: String.t()
+  def generate(value)
+end
+```
+
+プロトコルは「どの型であっても `generate/1` を呼べる」という抽象化を提供します。実際の処理は各構造体の `defimpl` で分岐します。
+
+## 7.4 defimpl で Type01 / Type02 / Type03 を実装する
+
+`Type01`、`Type02`、`Type03` は、それぞれ通常数値、3 の倍数、5 の倍数を表す構造体とします。
+
+```elixir
+defmodule FizzBuzz.Model.Type01 do
+  @enforce_keys [:value]
+  defstruct [:value]
+end
+
+defmodule FizzBuzz.Model.Type02 do
+  @enforce_keys [:value]
+  defstruct [:value]
+end
+
+defmodule FizzBuzz.Model.Type03 do
+  @enforce_keys [:value]
+  defstruct [:value]
+end
+
+defimpl FizzBuzz.Generatable, for: FizzBuzz.Model.Type01 do
+  def generate(%FizzBuzz.Model.Type01{value: value}), do: Integer.to_string(value.number)
+end
+
+defimpl FizzBuzz.Generatable, for: FizzBuzz.Model.Type02 do
+  def generate(%FizzBuzz.Model.Type02{}), do: "Fizz"
+end
+
+defimpl FizzBuzz.Generatable, for: FizzBuzz.Model.Type03 do
+  def generate(%FizzBuzz.Model.Type03{}), do: "Buzz"
+end
+```
+
+この設計では、呼び出し側は具体型を意識せず、`FizzBuzz.Generatable.generate/1` だけを呼べばよくなります。
+
+## 7.5 ExUnit でプロトコル実装を検証する
+
+プロトコルの振る舞いは ExUnit で確認できます。
+
+```elixir
+defmodule FizzBuzz.GeneratableTest do
+  use ExUnit.Case, async: true
+
+  alias FizzBuzz.Generatable
+  alias FizzBuzz.Model.{Type01, Type02, Type03, Value}
+
+  test "Type01 は数値文字列を返す" do
+    value = %Value{number: 1}
+    assert Generatable.generate(%Type01{value: value}) == "1"
+  end
+
+  test "Type02 は Fizz を返す" do
+    value = %Value{number: 3}
+    assert Generatable.generate(%Type02{value: value}) == "Fizz"
+  end
+
+  test "Type03 は Buzz を返す" do
+    value = %Value{number: 5}
+    assert Generatable.generate(%Type03{value: value}) == "Buzz"
+  end
+
+  test "Value は number が必須" do
+    assert_raise ArgumentError, fn ->
+      struct!(Value, %{})
+    end
+  end
+end
+```
+
+`struct!/2` を使うと、`@enforce_keys` の違反をテストで明示的に確認できます。
+
+## 7.6 まとめ
+
+この章では、`defstruct` と `@enforce_keys` で値オブジェクトを定義し、`defprotocol` / `defimpl` で型ごとに `generate/1` を実装しました。Elixir では継承ではなく、プロトコルでポリモーフィズムを組み立てるのが実践的です。

package/lib/assets/docs/article/getting-start-tdd/elixir/08-pattern-matching-and-guards.md

@@ -1,108 +1,108 @@
-# 第 8 章: パターンマッチとガード節
-
-## 8.1 はじめに
-
-この章では、Elixir の分岐を読みやすく保つために、関数頭部のパターンマッチ、`when` ガード節、`case` と `cond` の使い分けを整理します。あわせて、タグ付きタプル `{:ok, value}` / `{:error, reason}` による結果表現も確認します。
-
-## 8.2 関数頭部でのパターンマッチ
-
-Elixir では値ごとの分岐を関数定義に直接書けます。
-
-```elixir
-defmodule FizzBuzz.Factory do
-  alias FizzBuzz.Model.{Type01, Type02, Type03, Value}
-
-  def create(1), do: %Type01{value: %Value{number: 1}}
-  def create(2), do: %Type01{value: %Value{number: 2}}
-  def create(3), do: %Type02{value: %Value{number: 3}}
-  def create(5), do: %Type03{value: %Value{number: 5}}
-  def create(_), do: :unsupported
-end
-```
-
-`def create(1)`、`def create(2)`、`def create(_)` のように書くと、`if` より宣言的で見通しがよくなります。
-
-## 8.3 ガード節で入力条件を制約する
-
-パターンだけで不足する条件は `when` を使います。
-
-```elixir
-defmodule FizzBuzz.Validator do
-  def validate(number) when is_integer(number) and number > 0, do: {:ok, number}
-  def validate(number) when is_integer(number), do: {:error, :non_positive}
-  def validate(_), do: {:error, :not_integer}
-end
-```
-
-`when is_integer(number) and number > 0` により、正常系の条件を関数シグネチャ近くで明示できます。
-
-## 8.4 case 式と cond 式の使い分け
-
-`case` は「値の形」を分岐するときに向いており、`cond` は「複数の真偽条件」を評価するときに向いています。
-
-```elixir
-defmodule FizzBuzz.Renderer do
-  def from_result(result) do
-    case result do
-      {:ok, value} -> "ok: #{value}"
-      {:error, reason} -> "error: #{reason}"
-    end
-  end
-
-  def classify(number) do
-    cond do
-      rem(number, 15) == 0 -> :fizz_buzz
-      rem(number, 3) == 0 -> :fizz
-      rem(number, 5) == 0 -> :buzz
-      true -> :number
-    end
-  end
-end
-```
-
-- `case`: `{:ok, value}` のようなタグ付きデータを分解する。
-- `cond`: `rem/2` の結果など条件式を上から順に判定する。
-
-## 8.5 ExUnit で分岐をテストする
-
-分岐ロジックは仕様が崩れやすいため、タグ付きタプルまで含めてテストします。
-
-```elixir
-defmodule FizzBuzz.PatternMatchingTest do
-  use ExUnit.Case, async: true
-
-  alias FizzBuzz.Factory
-  alias FizzBuzz.Renderer
-  alias FizzBuzz.Validator
-  alias FizzBuzz.Model.Type02
-
-  test "create/1 は 3 を Type02 として生成する" do
-    assert %Type02{} = Factory.create(3)
-  end
-
-  test "validate/1 は正の整数を {:ok, value} で返す" do
-    assert Validator.validate(10) == {:ok, 10}
-  end
-
-  test "validate/1 は不正な入力を {:error, reason} で返す" do
-    assert Validator.validate(0) == {:error, :non_positive}
-    assert Validator.validate("10") == {:error, :not_integer}
-  end
-
-  test "from_result/1 はタグ付きタプルを文字列化する" do
-    assert Renderer.from_result({:ok, "Fizz"}) == "ok: Fizz"
-    assert Renderer.from_result({:error, :not_integer}) == "error: not_integer"
-  end
-
-  test "classify/1 は cond で優先順位どおりに判定する" do
-    assert Renderer.classify(15) == :fizz_buzz
-    assert Renderer.classify(6) == :fizz
-    assert Renderer.classify(10) == :buzz
-    assert Renderer.classify(7) == :number
-  end
-end
-```
-
-## 8.6 まとめ
-
-この章では、関数頭部のパターンマッチ、`when` ガード節、`case` と `cond` の使い分け、タグ付きタプルによる結果表現を確認しました。これらを組み合わせると、分岐が増えても読みやすさと安全性を維持できます。
+# 第 8 章: パターンマッチとガード節
+
+## 8.1 はじめに
+
+この章では、Elixir の分岐を読みやすく保つために、関数頭部のパターンマッチ、`when` ガード節、`case` と `cond` の使い分けを整理します。あわせて、タグ付きタプル `{:ok, value}` / `{:error, reason}` による結果表現も確認します。
+
+## 8.2 関数頭部でのパターンマッチ
+
+Elixir では値ごとの分岐を関数定義に直接書けます。
+
+```elixir
+defmodule FizzBuzz.Factory do
+  alias FizzBuzz.Model.{Type01, Type02, Type03, Value}
+
+  def create(1), do: %Type01{value: %Value{number: 1}}
+  def create(2), do: %Type01{value: %Value{number: 2}}
+  def create(3), do: %Type02{value: %Value{number: 3}}
+  def create(5), do: %Type03{value: %Value{number: 5}}
+  def create(_), do: :unsupported
+end
+```
+
+`def create(1)`、`def create(2)`、`def create(_)` のように書くと、`if` より宣言的で見通しがよくなります。
+
+## 8.3 ガード節で入力条件を制約する
+
+パターンだけで不足する条件は `when` を使います。
+
+```elixir
+defmodule FizzBuzz.Validator do
+  def validate(number) when is_integer(number) and number > 0, do: {:ok, number}
+  def validate(number) when is_integer(number), do: {:error, :non_positive}
+  def validate(_), do: {:error, :not_integer}
+end
+```
+
+`when is_integer(number) and number > 0` により、正常系の条件を関数シグネチャ近くで明示できます。
+
+## 8.4 case 式と cond 式の使い分け
+
+`case` は「値の形」を分岐するときに向いており、`cond` は「複数の真偽条件」を評価するときに向いています。
+
+```elixir
+defmodule FizzBuzz.Renderer do
+  def from_result(result) do
+    case result do
+      {:ok, value} -> "ok: #{value}"
+      {:error, reason} -> "error: #{reason}"
+    end
+  end
+
+  def classify(number) do
+    cond do
+      rem(number, 15) == 0 -> :fizz_buzz
+      rem(number, 3) == 0 -> :fizz
+      rem(number, 5) == 0 -> :buzz
+      true -> :number
+    end
+  end
+end
+```
+
+- `case`: `{:ok, value}` のようなタグ付きデータを分解する。
+- `cond`: `rem/2` の結果など条件式を上から順に判定する。
+
+## 8.5 ExUnit で分岐をテストする
+
+分岐ロジックは仕様が崩れやすいため、タグ付きタプルまで含めてテストします。
+
+```elixir
+defmodule FizzBuzz.PatternMatchingTest do
+  use ExUnit.Case, async: true
+
+  alias FizzBuzz.Factory
+  alias FizzBuzz.Renderer
+  alias FizzBuzz.Validator
+  alias FizzBuzz.Model.Type02
+
+  test "create/1 は 3 を Type02 として生成する" do
+    assert %Type02{} = Factory.create(3)
+  end
+
+  test "validate/1 は正の整数を {:ok, value} で返す" do
+    assert Validator.validate(10) == {:ok, 10}
+  end
+
+  test "validate/1 は不正な入力を {:error, reason} で返す" do
+    assert Validator.validate(0) == {:error, :non_positive}
+    assert Validator.validate("10") == {:error, :not_integer}
+  end
+
+  test "from_result/1 はタグ付きタプルを文字列化する" do
+    assert Renderer.from_result({:ok, "Fizz"}) == "ok: Fizz"
+    assert Renderer.from_result({:error, :not_integer}) == "error: not_integer"
+  end
+
+  test "classify/1 は cond で優先順位どおりに判定する" do
+    assert Renderer.classify(15) == :fizz_buzz
+    assert Renderer.classify(6) == :fizz
+    assert Renderer.classify(10) == :buzz
+    assert Renderer.classify(7) == :number
+  end
+end
+```
+
+## 8.6 まとめ
+
+この章では、関数頭部のパターンマッチ、`when` ガード節、`case` と `cond` の使い分け、タグ付きタプルによる結果表現を確認しました。これらを組み合わせると、分岐が増えても読みやすさと安全性を維持できます。

package/lib/assets/docs/article/getting-start-tdd/elixir/09-module-design-and-behaviours.md

@@ -1,104 +1,104 @@
-# 第 9 章: モジュール設計とビヘイビア
-
-## 9.1 はじめに
-
-この章では、モジュールの責務分割を保ちながら拡張しやすい構成を作るために、モジュールの入れ子、`@behaviour` / `@callback`、`alias` を使った設計を扱います。FizzBuzz のコマンド層を例に、共通インターフェースを実装する形へ整理します。
-
-## 9.2 モジュールの入れ子で責務を表現する
-
-Elixir はファイル階層とは独立して、名前空間で責務を整理できます。たとえば `FizzBuzz.Command.ValueCommand` は「単一値を扱うコマンド」を明確に示します。
-
-```elixir
-defmodule FizzBuzz.Command.ValueCommand do
-  def run(number), do: Integer.to_string(number)
-end
-```
-
-`FizzBuzz.Command` 配下に `ValueCommand` と `ListCommand` を置くと、同じ関心事のモジュール群を把握しやすくなります。
-
-## 9.3 @behaviour と @callback でインターフェースを定義する
-
-まずはコマンド共通の契約を `FizzBuzz.Command` ビヘイビアとして定義します。
-
-```elixir
-defmodule FizzBuzz.Command do
-  @callback run(input :: term()) :: {:ok, term()} | {:error, atom()}
-end
-```
-
-この `@callback` により、実装モジュールは `run/1` を提供する必要があります。未実装の場合、コンパイル時に警告が出るため、設計の抜け漏れを防げます。
-
-## 9.4 ValueCommand と ListCommand でビヘイビアを実装する
-
-`@behaviour FizzBuzz.Command` を指定し、`run/1` を実装します。`alias` を使ってモジュール参照を簡略化します。
-
-```elixir
-defmodule FizzBuzz.Command.ValueCommand do
-  @behaviour FizzBuzz.Command
-
-  alias FizzBuzz.FizzBuzzService
-
-  @impl true
-  def run(number) when is_integer(number) and number > 0 do
-    {:ok, FizzBuzzService.generate(number)}
-  end
-
-  @impl true
-  def run(_), do: {:error, :invalid_number}
-end
-
-defmodule FizzBuzz.Command.ListCommand do
-  @behaviour FizzBuzz.Command
-
-  alias FizzBuzz.FizzBuzzService
-
-  @impl true
-  def run(limit) when is_integer(limit) and limit > 0 do
-    values =
-      1..limit
-      |> Enum.map(&FizzBuzzService.generate/1)
-
-    {:ok, values}
-  end
-
-  @impl true
-  def run(_), do: {:error, :invalid_limit}
-end
-```
-
-`alias FizzBuzz.FizzBuzzService` を使うことで、`FizzBuzz.FizzBuzzService.generate/1` を `FizzBuzzService.generate/1` と短く書けます。
-
-## 9.5 ExUnit でビヘイビア実装を検証する
-
-各コマンドが同じ契約で動くことを ExUnit で確認します。
-
-```elixir
-defmodule FizzBuzz.CommandTest do
-  use ExUnit.Case, async: true
-
-  alias FizzBuzz.Command.{ListCommand, ValueCommand}
-
-  test "ValueCommand は単一値を処理する" do
-    assert ValueCommand.run(3) == {:ok, "Fizz"}
-  end
-
-  test "ValueCommand は不正値でエラーを返す" do
-    assert ValueCommand.run(0) == {:error, :invalid_number}
-    assert ValueCommand.run("3") == {:error, :invalid_number}
-  end
-
-  test "ListCommand は 1..limit の結果一覧を返す" do
-    assert ListCommand.run(5) == {:ok, ["1", "2", "Fizz", "4", "Buzz"]}
-  end
-
-  test "ListCommand は不正値でエラーを返す" do
-    assert ListCommand.run(-1) == {:error, :invalid_limit}
-  end
-end
-```
-
-`ValueCommand` と `ListCommand` は入出力対象が異なっても、同じ `run/1` 契約を守るため、呼び出し側の扱いを統一できます。
-
-## 9.6 まとめ
-
-この章では、`FizzBuzz.Command.ValueCommand` のようなモジュール入れ子で責務を整理し、`@behaviour` / `@callback` で契約を固定し、`alias` で記述を簡潔にする方法を確認しました。ビヘイビア中心の設計により、機能追加時も既存コードへの影響を局所化できます。
+# 第 9 章: モジュール設計とビヘイビア
+
+## 9.1 はじめに
+
+この章では、モジュールの責務分割を保ちながら拡張しやすい構成を作るために、モジュールの入れ子、`@behaviour` / `@callback`、`alias` を使った設計を扱います。FizzBuzz のコマンド層を例に、共通インターフェースを実装する形へ整理します。
+
+## 9.2 モジュールの入れ子で責務を表現する
+
+Elixir はファイル階層とは独立して、名前空間で責務を整理できます。たとえば `FizzBuzz.Command.ValueCommand` は「単一値を扱うコマンド」を明確に示します。
+
+```elixir
+defmodule FizzBuzz.Command.ValueCommand do
+  def run(number), do: Integer.to_string(number)
+end
+```
+
+`FizzBuzz.Command` 配下に `ValueCommand` と `ListCommand` を置くと、同じ関心事のモジュール群を把握しやすくなります。
+
+## 9.3 @behaviour と @callback でインターフェースを定義する
+
+まずはコマンド共通の契約を `FizzBuzz.Command` ビヘイビアとして定義します。
+
+```elixir
+defmodule FizzBuzz.Command do
+  @callback run(input :: term()) :: {:ok, term()} | {:error, atom()}
+end
+```
+
+この `@callback` により、実装モジュールは `run/1` を提供する必要があります。未実装の場合、コンパイル時に警告が出るため、設計の抜け漏れを防げます。
+
+## 9.4 ValueCommand と ListCommand でビヘイビアを実装する
+
+`@behaviour FizzBuzz.Command` を指定し、`run/1` を実装します。`alias` を使ってモジュール参照を簡略化します。
+
+```elixir
+defmodule FizzBuzz.Command.ValueCommand do
+  @behaviour FizzBuzz.Command
+
+  alias FizzBuzz.FizzBuzzService
+
+  @impl true
+  def run(number) when is_integer(number) and number > 0 do
+    {:ok, FizzBuzzService.generate(number)}
+  end
+
+  @impl true
+  def run(_), do: {:error, :invalid_number}
+end
+
+defmodule FizzBuzz.Command.ListCommand do
+  @behaviour FizzBuzz.Command
+
+  alias FizzBuzz.FizzBuzzService
+
+  @impl true
+  def run(limit) when is_integer(limit) and limit > 0 do
+    values =
+      1..limit
+      |> Enum.map(&FizzBuzzService.generate/1)
+
+    {:ok, values}
+  end
+
+  @impl true
+  def run(_), do: {:error, :invalid_limit}
+end
+```
+
+`alias FizzBuzz.FizzBuzzService` を使うことで、`FizzBuzz.FizzBuzzService.generate/1` を `FizzBuzzService.generate/1` と短く書けます。
+
+## 9.5 ExUnit でビヘイビア実装を検証する
+
+各コマンドが同じ契約で動くことを ExUnit で確認します。
+
+```elixir
+defmodule FizzBuzz.CommandTest do
+  use ExUnit.Case, async: true
+
+  alias FizzBuzz.Command.{ListCommand, ValueCommand}
+
+  test "ValueCommand は単一値を処理する" do
+    assert ValueCommand.run(3) == {:ok, "Fizz"}
+  end
+
+  test "ValueCommand は不正値でエラーを返す" do
+    assert ValueCommand.run(0) == {:error, :invalid_number}
+    assert ValueCommand.run("3") == {:error, :invalid_number}
+  end
+
+  test "ListCommand は 1..limit の結果一覧を返す" do
+    assert ListCommand.run(5) == {:ok, ["1", "2", "Fizz", "4", "Buzz"]}
+  end
+
+  test "ListCommand は不正値でエラーを返す" do
+    assert ListCommand.run(-1) == {:error, :invalid_limit}
+  end
+end
+```
+
+`ValueCommand` と `ListCommand` は入出力対象が異なっても、同じ `run/1` 契約を守るため、呼び出し側の扱いを統一できます。
+
+## 9.6 まとめ
+
+この章では、`FizzBuzz.Command.ValueCommand` のようなモジュール入れ子で責務を整理し、`@behaviour` / `@callback` で契約を固定し、`alias` で記述を簡潔にする方法を確認しました。ビヘイビア中心の設計により、機能追加時も既存コードへの影響を局所化できます。