npm - @k2works/claude-code-booster - Versions diffs - 6.2.0 → 6.3.1 - Mend

@k2works/claude-code-booster 6.2.0 → 6.3.1

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.

Files changed (618) hide show

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

@@ -1,195 +0,0 @@
----
-type: Article
-title: "第 6 章: タスクランナーと CI/CD"
-description: "TDD を継続するには、テスト・整形・静的解析を毎回確実に実行できる仕組みが必要です。"
-tags: [article, getting-start-tdd, scala]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-# 第 6 章: タスクランナーと CI/CD
-## 6.1 はじめに
-TDD を継続するには、テスト・整形・静的解析を毎回確実に実行できる仕組みが必要です。
-この章では、`Makefile`、`sbt` タスク、Nix 開発環境、GitHub Actions を使って開発タスクを自動化します。
-## 6.2 Nix による開発環境
-本プロジェクトでは Nix Flakes で開発環境を宣言的に管理しています。
-`ops/nix/environments/scala/shell.nix` に Scala 環境の定義があります。
-```nix
-{ packages ? import <nixpkgs> {} }:
-let
-  baseShell = import ../../shells/shell.nix { inherit packages; };
-in
-packages.mkShell {
-  inherit (baseShell) pure;
-  buildInputs = baseShell.buildInputs ++ (with packages; [
-    scala_3
-    sbt
-    metals
-    scala-cli
-  ]);
-  shellHook = ''
-    ${baseShell.shellHook}
-    echo "Scala development environment activated"
-  '';
-}
-```
-環境の起動:
-```bash
-nix develop .#scala
-```
-これにより、Scala 3、sbt、Metals、scala-cli が揃った環境に入れます。
-チーム全員が同じツールバージョンを使えるため、「自分のマシンでは動く」問題を防げます。
-## 6.3 Makefile によるタスク管理
-`apps/scala/Makefile` には、日常的に使うタスクが定義されています。
-```makefile
-.PHONY: test fmt fmt-check lint complexity check build run clean
-test:
-	sbt test
-fmt:
-	sbt scalafmt
-fmt-check:
-	sbt scalafmtCheck
-lint:
-	sbt compile
-complexity:
-	bash scripts/complexity.sh --threshold 10 src
-check: fmt-check lint complexity test
-```
-この構成の狙いは、`make check` 1 つで品質ゲートをまとめて実行できる点です。
-- `test`: 単体テスト実行
-- `fmt` / `fmt-check`: フォーマット適用と検証
-- `lint`: コンパイルによる静的チェック
-- `complexity`: コード複雑度チェック
-- `check`: CI と同等のローカル検証
-Nix 環境内で実行するのが前提です:
-```bash
-nix develop .#scala --command make check
-```
-## 6.4 sbt のカスタムタスク
-`sbt` では `build.sbt` に独自タスクを追加できます。
-たとえば、テストと整形確認をまとめたタスクは次のように定義できます。
-```scala
-lazy val verify = taskKey[Unit]("Run format check and tests")
-verify := {
-  (Compile / compile).value
-  (Test / test).value
-}
-```
-また、`~` prefix を使うとファイル変更を監視して自動実行できます。
-```bash
-nix develop .#scala --command sbt ~test
-```
-TDD の Red → Green を高速に回すときに有効です。
-## 6.5 GitHub Actions による CI/CD
-`.github/workflows/scala-ci.yml` では、Nix を活用して CI を実行しています。
-```yaml
-name: Scala CI
-on:
-  push:
-    branches: [main, develop]
-    paths:
-      - "apps/scala/**"
-      - ".github/workflows/scala-ci.yml"
-  pull_request:
-    branches: [main]
-    paths:
-      - "apps/scala/**"
-permissions:
-  contents: read
-jobs:
-  test:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout the repository
-        uses: actions/checkout@v4
-      - name: Install Nix
-        uses: cachix/install-nix-action@v30
-        with:
-          nix_path: nixpkgs=channel:nixos-unstable
-      - name: Cache Nix store
-        uses: actions/cache@v4
-        with:
-          path: /tmp/nix-cache
-          key: ${{ runner.os }}-nix-scala-${{ hashFiles('flake.lock', 'ops/nix/environments/scala/shell.nix') }}
-          restore-keys: |
-            ${{ runner.os }}-nix-scala-
-      - name: Check formatting
-        run: nix develop .#scala --command bash -c "cd apps/scala && sbt scalafmtCheck"
-      - name: Compile (lint)
-        run: nix develop .#scala --command bash -c "cd apps/scala && sbt compile"
-      - name: Run complexity check
-        run: nix develop .#scala --command bash -c "cd apps/scala && bash scripts/complexity.sh --threshold 10 src"
-      - name: Run tests
-        run: nix develop .#scala --command bash -c "cd apps/scala && sbt test"
-```
-### Nix を CI で使う利点
-- **環境の再現性**: ローカルと CI で同じ Nix 環境を使うため、環境差異による失敗がない
-- **ツールバージョンの固定**: `flake.lock` でパッケージバージョンが固定される
-- **キャッシュの効率化**: `flake.lock` と `shell.nix` のハッシュでキャッシュキーを生成し、変更時のみ再構築
-- **統一的なパターン**: Clojure、.NET など他の言語と同じ CI パターンを使える
-## 6.6 開発ワークフロー
-Red-Green-Refactor を自動化で支える基本フローは次の通りです。
-1. 環境起動: `nix develop .#scala` で開発環境に入る
-2. Red: 失敗するテストを追加し、`make test` で失敗を確認
-3. Green: 最小実装で `make test` を通過
-4. Refactor: `make check` で整形・コンパイル・複雑度・テストを一括確認
-5. Push: GitHub Actions で Nix 環境内の同じチェックを再実行
-ローカルと CI で同じ Nix 環境・同じコマンドを使うことで、環境差分による失敗を防げます。
-## 6.7 まとめ
-この章では、Scala 開発の自動化基盤を整理しました。
-- Nix Flakes で開発環境を宣言的に管理し、再現性を確保する
-- `Makefile` で日常タスクを短いコマンドに集約する
-- `sbt` のタスクと監視実行で開発サイクルを高速化する
-- GitHub Actions で Nix 環境を使い、ローカルと同一の品質ゲートを適用する
-第 2 部の環境整備が完了したので、次章からはオブジェクト指向設計に進みます。

package/lib/assets/docs/article/getting-start-tdd/scala/07-case-classes-and-traits.md DELETED Viewed

@@ -1,148 +0,0 @@
----
-type: Article
-title: "第 7 章: ケースクラスとトレイトによるポリモーフィズム"
-description: "第 1 部〜第 2 部で TDD の基本サイクルと開発環境を整えました。"
-tags: [article, getting-start-tdd, scala]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-# 第 7 章: ケースクラスとトレイトによるポリモーフィズム
-## 7.1 はじめに
-第 1 部〜第 2 部で TDD の基本サイクルと開発環境を整えました。ここからは FizzBuzz に追加仕様を導入し、オブジェクト指向設計を進めます。
-今回の追加仕様は、FizzBuzz のタイプバリエーションです。
-- Type01: 通常の FizzBuzz（3 の倍数で Fizz、5 の倍数で Buzz、15 の倍数で FizzBuzz）
-- Type02: 数値のみ（常に数値文字列を返す）
-- Type03: FizzBuzz のみ（15 の倍数のみ FizzBuzz、それ以外は数値文字列）
-Scala では `case class` と `trait` を組み合わせることで、型安全なポリモーフィズムをシンプルに表現できます。
-## 7.2 TODO リスト
-既存 TODO に加えて、タイプバリエーションに関する TODO を整理します。
-- [x] ~~1 を渡したら "1" を返す~~
-- [x] ~~3 の倍数のときは "Fizz" を返す~~
-- [x] ~~5 の倍数のときは "Buzz" を返す~~
-- [x] ~~15 の倍数のときは "FizzBuzz" を返す~~
-- [x] ~~1 から 100 までのリストを返す~~
-- [ ] Type01 のルールを実装する
-- [ ] Type02 のルールを実装する
-- [ ] Type03 のルールを実装する
-- [ ] 未定義タイプで例外を送出する
-## 7.3 値オブジェクト（case class）
-単一値の表現には `case class FizzBuzzValue` を使います。
-```scala
-case class FizzBuzzValue(number: Int, value: String):
-  require(number > 0, s"数値は正の整数でなければなりません: $number")
-  override def toString: String = value
-```
-`case class` の主な特徴は次のとおりです。
-- 不変データを簡潔に定義できる
-- `equals` / `hashCode` / `toString` が自動生成される
-- パターンマッチに自然に対応できる
-また、`require` により「正の整数であること」という事前条件をコンストラクタ境界で保証しています。
-## 7.4 ファーストクラスコレクション
-複数値の表現には `FizzBuzzList` を使います。
-```scala
-case class FizzBuzzList(values: List[FizzBuzzValue]):
-  require(values.nonEmpty, "リストは空であってはなりません")
-  def toStringList: List[String] = values.map(_.value)
-  def count: Int = values.length
-```
-`List[FizzBuzzValue]` を直接扱わず、`FizzBuzzList` にラップすることで、コレクション操作をドメインの語彙で表現できます。
-実装ではコンパニオンオブジェクトに `create` を持たせ、生成ロジックを集約しています。
-```scala
-object FizzBuzzList:
-  def create(count: Int, fizzBuzzType: FizzBuzzType): FizzBuzzList =
-    val values = (1 to count).map { n =>
-      FizzBuzzValue(n, fizzBuzzType.generate(n))
-    }.toList
-    FizzBuzzList(values)
-```
-## 7.5 トレイトによるポリモーフィズム
-FizzBuzz のタイプごとの差し替えポイントは `FizzBuzzType` で抽象化します。
-```scala
-sealed trait FizzBuzzType:
-  def generate(number: Int): String
-```
-実装は 3 つの `case object` です。
-```scala
-object FizzBuzzType:
-  case object Type01 extends FizzBuzzType:
-    def generate(number: Int): String =
-      number match
-        case n if n % 15 == 0 => "FizzBuzz"
-        case n if n % 3 == 0  => "Fizz"
-        case n if n % 5 == 0  => "Buzz"
-        case n                => n.toString
-  case object Type02 extends FizzBuzzType:
-    def generate(number: Int): String = number.toString
-  case object Type03 extends FizzBuzzType:
-    def generate(number: Int): String =
-      number match
-        case n if n % 15 == 0 => "FizzBuzz"
-        case n                => n.toString
-```
-`sealed` を付けることで実装候補を同一ファイルに閉じ込められ、コンパイラの網羅性チェックが効くようになります。
-## 7.6 テスト
-`TypeSpec` では各タイプとファクトリメソッドを検証しています。
-```scala
-class TypeSpec extends AnyFunSuite:
-  test("Type01: 3 の倍数で Fizz を返す") {
-    assert(FizzBuzzType.Type01.generate(3) === "Fizz")
-  }
-  test("Type02: 15 を渡すと 15 を返す") {
-    assert(FizzBuzzType.Type02.generate(15) === "15")
-  }
-  test("Type03: 15 の倍数で FizzBuzz を返す") {
-    assert(FizzBuzzType.Type03.generate(15) === "FizzBuzz")
-  }
-  test("create: 未定義のタイプで例外が発生する") {
-    assertThrows[IllegalArgumentException] {
-      FizzBuzzType.create(4)
-    }
-  }
-```
-タイプごとの振る舞いを個別に固定することで、追加仕様時の回帰を防げます。
-## 7.7 まとめ
-この章では、`case class` と `trait` を使って FizzBuzz の型安全な設計を行いました。
-- `FizzBuzzValue` で値を明示的に表現
-- `FizzBuzzList` でコレクション操作をカプセル化
-- `FizzBuzzType` のポリモーフィズムでタイプ差分を分離
-次章では、`match` と `sealed trait` をさらに掘り下げ、Scala らしい分岐設計を整理します。

package/lib/assets/docs/article/getting-start-tdd/scala/08-pattern-matching-and-sealed-traits.md DELETED Viewed

@@ -1,115 +0,0 @@
----
-type: Article
-title: "第 8 章: パターンマッチとシールドトレイト"
-description: "Scala の match は単なる switch の置き換えではなく、型と条件を統合して表現できる強力な構文です。"
-tags: [article, getting-start-tdd, scala]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-# 第 8 章: パターンマッチとシールドトレイト
-## 8.1 はじめに
-Scala の `match` は単なる `switch` の置き換えではなく、型と条件を統合して表現できる強力な構文です。`sealed trait` と組み合わせると、代数的データ型（ADT）として安全に分岐を記述できます。
-この章では、FizzBuzz のタイプ生成と変換ロジックを題材に、パターンマッチの基本と網羅性チェックを確認します。
-## 8.2 パターンマッチの基本
-`match/case` の基本構文は次のとおりです。
-```scala
-def generate(number: Int): String =
-  number match
-    case n if n % 15 == 0 => "FizzBuzz"
-    case n if n % 3 == 0  => "Fizz"
-    case n if n % 5 == 0  => "Buzz"
-    case n                => n.toString
-```
-重要な要素は 3 つです。
-- `match/case` で分岐を宣言的に記述できる
-- `case n if ...` のガード条件で複合条件を自然に表現できる
-- `case _` や `case n` でワイルドカード／フォールバックを定義できる
-## 8.3 シールドトレイトと網羅性
-`sealed trait` は「この抽象型の実装は同一ファイル内に限定する」という制約を与えます。
-```scala
-sealed trait FizzBuzzType:
-  def generate(number: Int): String
-```
-この制約により、コンパイラは次を支援できます。
-- 実装候補を把握し、網羅性を検証できる
-- `match` で未処理ケースがあると警告できる
-- 将来の型追加時に、分岐漏れを早期に検知できる
-`sealed trait` は ADT を安全に扱うための土台です。
-## 8.4 ファクトリメソッド
-タイプ番号から `FizzBuzzType` を生成する実装です。
-```scala
-def create(typeNumber: Int): FizzBuzzType =
-  typeNumber match
-    case 1 => Type01
-    case 2 => Type02
-    case 3 => Type03
-    case _ => throw IllegalArgumentException(s"未定義のタイプ: $typeNumber")
-```
-生成責務を `FizzBuzzType.create` に集約することで、呼び出し側は型番号の解釈を意識せずに済みます。
-## 8.5 Strategy パターンとの対応
-OOP の Strategy パターンでは、アルゴリズムをインターフェースで抽象化し、実行時に具象実装を差し替えます。
-FizzBuzz では次の対応になります。
-- Strategy の抽象: `FizzBuzzType`（`sealed trait`）
-- 具体 Strategy: `Type01` / `Type02` / `Type03`
-- Strategy 選択: `FizzBuzzType.create(typeNumber)`
-この構成により、呼び出し側の条件分岐を排除し、ポリモーフィズムで振る舞いを切り替えられます。
-## 8.6 テスト
-ファクトリメソッドは `TypeSpec` で次のように検証しています。
-```scala
-test("create: タイプ 1 を生成できる") {
-  assert(FizzBuzzType.create(1) === FizzBuzzType.Type01)
-}
-test("create: タイプ 2 を生成できる") {
-  assert(FizzBuzzType.create(2) === FizzBuzzType.Type02)
-}
-test("create: タイプ 3 を生成できる") {
-  assert(FizzBuzzType.create(3) === FizzBuzzType.Type03)
-}
-test("create: 未定義のタイプで例外が発生する") {
-  assertThrows[IllegalArgumentException] {
-    FizzBuzzType.create(4)
-  }
-}
-```
-正常系と異常系を両方固定することで、生成ルールの変更に対して安全にリファクタリングできます。
-## 8.7 まとめ
-この章では、Scala のパターンマッチと `sealed trait` の組み合わせを確認しました。
-- `match/case` とガード条件で分岐を明確化
-- `sealed trait` で実装範囲を制約し、網羅性チェックを有効化
-- `create` ファクトリで Strategy の切り替えを一元化
-次章では、ここまで作成したドメインモデルをパッケージ単位で整理し、モジュール設計としてまとめます。

package/lib/assets/docs/article/getting-start-tdd/scala/09-packages-and-module-design.md DELETED Viewed

@@ -1,84 +0,0 @@
----
-type: Article
-title: "第 9 章: パッケージとモジュール設計"
-description: "クラスが増えると、実装の正しさだけでなく「どこに何を書くか」が品質に直結します。"
-tags: [article, getting-start-tdd, scala]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-# 第 9 章: パッケージとモジュール設計
-## 9.1 はじめに
-クラスが増えると、実装の正しさだけでなく「どこに何を書くか」が品質に直結します。この章では、FizzBuzz のコードを題材に、責務ごとに整理するモジュール設計を確認します。
-## 9.2 パッケージ構成
-現在の Scala 実装は次の構成です。
-```text
-fizzbuzz/
-├── FizzBuzz.scala          (公開 API)
-├── domain/
-│   ├── Type.scala          (ドメインタイプ)
-│   └── Model.scala         (値オブジェクト)
-└── application/
-    └── Command.scala       (コマンドパターン)
-```
-`domain` と `application` を分離することで、ビジネスルールとユースケース実行を明確に切り分けています。
-## 9.3 ドメイン層
-ドメイン層は「FizzBuzz として何が正しいか」を表現する層です。
-- `domain.Type`: 変換ルール（Type01/02/03）とファクトリメソッド
-- `domain.Model`: 値オブジェクト `FizzBuzzValue` とファーストクラスコレクション `FizzBuzzList`
-`require` による事前条件や `sealed trait` による型制約をドメイン側に置くことで、不正な状態の侵入を早期に防げます。
-## 9.4 アプリケーション層
-アプリケーション層はユースケースを実行する層です。
-- `application.Command`: `FizzBuzzCommand` と具象コマンド
-- `FizzBuzzValueCommand`: 単一値を返すユースケース
-- `FizzBuzzListCommand`: 複数値を改行区切り文字列として返すユースケース
-アプリケーション層は `domain` を利用しますが、`domain` は `application` に依存しません。この依存方向により、ビジネスルールを独立して保守できます。
-## 9.5 Command パターン
-`Command.scala` の中心となる実装です。
-```scala
-trait FizzBuzzCommand:
-  def execute(): String
-class FizzBuzzValueCommand(number: Int, typeNumber: Int) extends FizzBuzzCommand:
-  def execute(): String =
-    val fizzBuzzType = FizzBuzzType.create(typeNumber)
-    val value = FizzBuzzValue(number, fizzBuzzType.generate(number))
-    value.toString
-```
-同じインターフェース（`execute`）で操作を抽象化し、呼び出し側はコマンドの差し替えだけで振る舞いを変更できます。
-## 9.6 SOLID 原則との対応
-この構成は SOLID 原則に次のように対応します。
-- 単一責任: `Type.scala` は変換ルール、`Model.scala` は値表現、`Command.scala` は実行手順に責務分離
-- 開放閉鎖: 新しいタイプは `FizzBuzzType` の実装追加で拡張しやすい
-- 依存性逆転: `trait FizzBuzzCommand` と `trait FizzBuzzType` による抽象化で依存を安定化
-## 9.7 まとめ
-この章では、FizzBuzz 実装をパッケージ単位で整理し、モジュール設計の基本を確認しました。
-- `domain` にビジネスルールを集約
-- `application` にユースケース実行を集約
-- `trait` を軸に依存関係をシンプルに保つ
-第 3 部でオブジェクト指向設計の基盤が整ったので、次の第 4 部では関数型プログラミングの要素を取り入れて設計をさらに発展させます。

package/lib/assets/docs/article/getting-start-tdd/scala/10-higher-order-functions-and-composition.md DELETED Viewed

@@ -1,113 +0,0 @@
----
-type: Article
-title: "第 10 章: 高階関数と関数合成"
-description: "第 3 部ではケースクラスやトレイトを使って OOP の基礎を整理しました。"
-tags: [article, getting-start-tdd, scala]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-# 第 10 章: 高階関数と関数合成
-## 10.1 はじめに
-第 3 部ではケースクラスやトレイトを使って OOP の基礎を整理しました。第 4 部では Scala の関数型プログラミング（FP）に焦点を当てます。
-Scala では関数は第一級オブジェクトです。関数を変数に代入でき、引数として渡せて、戻り値として返せます。この性質により、柔軟で再利用しやすい実装が可能になります。
-## 10.2 高階関数
-高階関数は「関数を引数に取る、または関数を返す関数」です。`generateWith` は最小構成の例です。
-```scala
-def generateWith(rule: Int => String)(number: Int): String =
-  rule(number)
-```
-このメソッドは 2 つのパラメータリストを持つカリー化された形です。
-- 第 1 パラメータリスト: `rule`（`Int => String`）
-- 第 2 パラメータリスト: `number`（`Int`）
-使い方の例です。
-```scala
-val customRule: Int => String = n => if n % 2 == 0 then "Even" else "Odd"
-val generator = FizzBuzz.generateWith(customRule)
-assert(generator(2) == "Even")
-assert(generator(3) == "Odd")
-```
-`val generator = FizzBuzz.generateWith(customRule)` は部分適用です。ルールだけ先に固定し、後から数値だけ渡せるようになります。
-## 10.3 コレクション操作
-Scala のコレクションは `map`、`filter`、`reduce` のような高階関数を標準で備えています。
-- `map`: 各要素を変換する
-- `filter`: 条件に一致する要素だけ残す
-- `reduce`: 要素を 1 つの値に畳み込む
-FizzBuzz の実装では、`transform` と `filter` でこの考え方をそのまま表現しています。
-```scala
-def transform(values: List[String], f: String => String): List[String] =
-  values.map(f)
-def filter(values: List[String], predicate: String => Boolean): List[String] =
-  values.filter(predicate)
-```
-`transform` は変換ロジックを引数で受け取るため、`toUpperCase` 以外にも自由に差し替えできます。
-## 10.4 関数合成
-複数の小さな関数を組み合わせて新しい関数を作るのが関数合成です。実装は次のとおりです。
-```scala
-def compose(f: String => String, g: String => String): String => String =
-  f.compose(g)
-```
-`f.compose(g)` は `f(g(x))` を意味します。つまり右から左へ適用されます。対して `andThen` は `g(f(x))` で、左から右へ適用されます。
-```scala
-val addBrackets: String => String = s => s"[$s]"
-val toUpper: String => String = _.toUpperCase
-val composed = addBrackets.compose(toUpper) // addBrackets(toUpper(x))
-val piped = addBrackets.andThen(toUpper)    // toUpper(addBrackets(x))
-```
-この違いを理解すると、パイプライン処理を意図通りに組み立てられます。
-## 10.5 テスト
-実装した関数型メソッドは、次のようにテストできます。
-```scala
-test("generateWith: カスタムルールで生成する") {
-  val customRule: Int => String = n => if n % 2 == 0 then "Even" else "Odd"
-  assert(FizzBuzz.generateWith(customRule)(2) === "Even")
-}
-test("compose: 2 つの関数を合成する") {
-  val addBrackets: String => String = s => s"[$s]"
-  val toUpper: String => String = _.toUpperCase
-  val combined = FizzBuzz.compose(addBrackets, toUpper)
-  assert(combined("Fizz") === "[FIZZ]")
-}
-```
-高階関数や関数合成は抽象度が上がるため、入力と出力を明示したテストが特に重要です。
-## 10.6 まとめ
-この章では、Scala の関数型プログラミングの入口として次を確認しました。
-- 高階関数 `generateWith` とカリー化
-- `map`、`filter` を使うコレクション操作
-- `compose` と `andThen` の違い
-次章では、コレクション処理をさらに発展させ、`LazyList` による遅延評価を扱います。