@k2works/claude-code-booster 4.4.1 → 4.5.0

package/lib/assets/docs/article/getting-start-tdd/integration/06-learning-roadmap.md

@@ -22,14 +22,14 @@ Java ──→ Python
 
 **Java を最初に学ぶ理由**:
 
-
+
 - 静的型付けと OOP の概念が明確に分かれている
 - JUnit 5 の構造が TDD の基本パターンを学ぶのに最適
 - エコシステムが成熟しており、学習リソースが豊富
 
 **Python を 2 番目に学ぶ理由**:
 
-
+
 - Java との対比で動的型付けの利点と欠点を体感できる
 - pytest のシンプルさが TDD の本質を理解させる
 - マルチパラダイムへの橋渡し
@@ -55,7 +55,7 @@ TypeScript ──→ Ruby ──→ Go or Rust
 
 **Go と Rust はどちらか一方を選択、または順に学習**:
 
-
+
 - **Go**: シンプルさを重視する場合。インターフェースの構造的部分型が新鮮
 - **Rust**: 型安全性を深く理解したい場合。所有権システムが根本的に新しい
 
@@ -82,14 +82,14 @@ F# ──→ Scala ──→ Elixir or Clojure ──→ Haskell
 
 **F# を FP の入口に選ぶ理由**:
 
-
+
 - C# と同じ .NET ランタイム上で動作し、既存知識を活かせる
 - 判別共用体とパターンマッチングが FP の核心を教えてくれる
 - パイプライン演算子がデータフローの思考法を身につけさせる
 
 **Haskell を最後に学ぶ理由**:
 
-
+
 - 純粋関数型の概念（モナド、型クラス）は他の FP 言語の基礎があると理解しやすい
 - 他の言語で「なぜ FP が有用か」を体感した後に、最も厳密な FP を学ぶ
 
@@ -193,21 +193,21 @@ PHP と C# は上記のフェーズに含まれていませんが、以下のタ
 
 **フェーズ 1**:
 
-
+
 - TDD の Red-Green-Refactor サイクルを体に染み込ませる
 - テストを「先に」書く習慣を確立する
 - 静的型付けと動的型付けの違いを体感する
 
 **フェーズ 2**:
 
-
+
 - 同じ FizzBuzz 仕様を異なる言語で実装し、「何が同じで何が違うか」を意識する
 - 各言語のイディオムを尊重する（Go のシンプルさ、Ruby の表現力）
 - リンターの指摘を通じて「その言語らしいコード」を学ぶ
 
 **フェーズ 3**:
 
-
+
 - 「なぜ不変データが有用か」を自分の言葉で説明できるようになる
 - パターンマッチングの威力を体感する
 - モナドを「怖いもの」ではなく「便利な道具」として理解する

package/lib/assets/docs/article/getting-start-tdd/ruby/11-immutable-data-and-pipeline.md

@@ -20,7 +20,7 @@ end
 
 `dup.freeze` のパターンにより:
 
-
+
 - `dup` で元の配列を変更しない
 - `freeze` で内部配列の変更を禁止
 
@@ -173,7 +173,7 @@ end
 
 `then` を使うことで、処理の流れが上から下へ自然に読めます:
 
-
+
 1. `(1..@count)` — 1 から count の Range を作成
 2. `.map { ... }` — 各数値を FizzBuzzValue に変換
 3. `.then { ... }` — 結果の配列を FizzBuzzList でラップ

package/lib/assets/docs/article/grokkingfp/all/part-2-ch03-immutable-data.md

@@ -980,15 +980,15 @@ rectangle "Level 4: 慣習的" #LightCoral {
 
 1. **take/drop 系**: Haskell, Clojure, Elixir, Scala, Java (Vavr), Ruby
 
-
+
    - 関数型言語の伝統的なスタイル。意図が明確
 2. **インデックス記法系**: Python `[:]`, Rust `[..]`
 
-
+
    - 最も簡潔。Python のスライス記法は特に強力
 3. **メソッドチェーン系**: TypeScript `.slice()`, C# `.Skip().Take()`
 
-
+
    - OOP スタイルとの親和性が高い
 
 ### 発見 3: replan パターンの共通構造

package/lib/assets/docs/article/grokkingfp/all/part-3-ch06-option.md

@@ -624,19 +624,19 @@ rectangle "Level 4: nil ベース + 言語機能" #LightCoral {
 
 1. **内包表記系**: Scala (for), Haskell (do), C# (LINQ), Clojure (when-let)
 
-
+
    - ネストが平坦化され、最も可読性が高い
 2. **演算子系**: Rust (`?`)
 
-
+
    - 最も簡潔で、通常のコードに自然に溶け込む
 3. **パイプ系**: F# (`|>`), Elixir (`with`), TypeScript (`pipe`)
 
-
+
    - データの流れが明確
 4. **flatMap チェーン系**: Java, Python, Ruby
 
-
+
    - 糖衣構文がなく、ネストが深くなりやすい
 
 ### 発見 3: Option は Part II の flatMap の延長線上にある

package/lib/assets/docs/article/grokkingfp/all/writing-plan.md

@@ -178,7 +178,7 @@
 1. 全 11 言語の part-2.md の第 3 章部分を読み込む
 2. 不変データ構造の実現方法を 4 カテゴリに分類
 
-
+
    - 言語組み込み（Haskell, Clojure, Elixir, F#）
    - デフォルト不変（Rust）
    - case class / record（Scala, Java 16+, C# 9+）
@@ -220,7 +220,7 @@
 2. map/filter/fold の共通概念を解説
 3. パイプライン記法の違いを比較
 
-
+
    - Elixir/F# パイプ演算子 `|>`
    - Haskell 関数合成 `.` / `$`
    - Clojure スレッディングマクロ `->` / `->>`
@@ -263,7 +263,7 @@
 2. flatMap/bind の共通概念（コンテキスト付き計算の連鎖）を解説
 3. 糖衣構文の比較
 
-
+
    - Scala for 内包表記
    - Haskell do 記法
    - C# LINQ クエリ式
@@ -324,7 +324,7 @@
 2. Option/Maybe の共通概念（null の型安全な代替）を解説
 3. 実装方式を 3 カテゴリに分類
 
-
+
    - 言語組み込み: Haskell Maybe, Rust Option, F# Option
    - 標準ライブラリ: Scala Option, Java Optional
    - サードパーティ: fp-ts Option, returns Maybe, dry-monads Maybe, LanguageExt Option, Vavr Option
@@ -399,7 +399,7 @@
 1. 全 11 言語の part-4.md の第 8 章部分を読み込む
 2. IO の抽象化を 4 レベルに分類
 
-
+
    - Level 4: 言語組み込み IO モナド（Haskell）
    - Level 3: ライブラリ IO 型（Scala cats-effect, C# LanguageExt Eff）
    - Level 2: 軽量 IO コンテナ（Python returns IO, TypeScript fp-ts Task, Ruby dry Task）
@@ -441,7 +441,7 @@
 2. 遅延評価とストリームの共通概念を解説
 3. ストリーム処理の実装アプローチを比較
 
-
+
    - 専用ライブラリ: Scala fs2, Haskell conduit
    - 言語組み込み: Elixir Stream, Rust Iterator, Python ジェネレータ, Ruby Enumerator::Lazy
    - ライブラリ拡張: TypeScript AsyncIterable, Java Vavr Stream, C# StreamT, F# Seq
@@ -492,7 +492,7 @@
 1. 全 11 言語の part-5.md を読み込む（最大ボリューム）
 2. 並行処理モデルを 5 カテゴリに分類
 
-
+
    - Actor モデル: Elixir OTP/GenServer
    - STM（Software Transactional Memory）: Haskell STM, Clojure ref
    - Fiber / 軽量スレッド: Scala Fiber, Java Virtual Thread
@@ -536,7 +536,7 @@
 2. TravelGuide アプリの共通アーキテクチャを抽出
 3. DI（依存性注入）の関数型アプローチを比較
 
-
+
    - Reader モナド: Scala, TypeScript
    - 型クラス / trait: Haskell, Rust
    - Protocol / ビヘイビア: Python, Elixir

package/lib/assets/docs/article/grokkingfp/elixir/part-1.md

@@ -423,7 +423,7 @@ end
 
 この関数は:
 
-
+
 - 6人以上のグループ → 20% のチップ
 - 1-5人のグループ → 10% のチップ
 - 0人（空リスト） → 0% のチップ

package/lib/assets/docs/article/grokkingfp/elixir/part-5.md

@@ -480,7 +480,7 @@ time < 200_000  # true（200ms未満）
 
 主なコンポーネント:
 
-
+
 - **GenServer**: 汎用サーバープロセス
 - **Supervisor**: プロセスの監視と再起動
 - **Application**: アプリケーションの管理

package/lib/assets/docs/article/grokkingfp/elixir/part-6.md

@@ -859,7 +859,7 @@ p5 --> p6
 
 以下の要件で `DataAccess` を拡張してください:
 
-
+
 - 新しいコールバック `find_restaurants_near_location` を追加
 - 戻り値は `{:ok, [Restaurant.t()]} | {:error, String.t()}`
 

package/lib/assets/docs/article/grokkingfp/fsharp/part-6.md

@@ -759,7 +759,7 @@ p5 --> p6
 
 以下の要件で `IDataAccess` を拡張してください:
 
-
+
 - 新しいメソッド `FindHotelsNearLocation` を追加
 - 戻り値は `Async<Result<Hotel list, string>>`
 

package/lib/assets/docs/article/grokkingfp/haskell/part-4.md

@@ -89,7 +89,7 @@ castTheDie = randomRIO (1, 6)
 
 Scala との違い:
 
-
+
 - Scala: `IO.delay(random.nextInt(6) + 1)` で副作用をラップ
 - Haskell: `randomRIO` 自体が `IO Int` を返す
 

package/lib/assets/docs/article/grokkingfp/haskell/part-6.md

@@ -660,7 +660,7 @@ p5 --> p6
 
 以下の要件で `DataAccess` を拡張してください:
 
-
+
 - 新しいフィールド `findHotelsNearLocation` を追加
 - 戻り値は `IO (Either String [Hotel])`
 

package/lib/assets/docs/article/grokkingfp/java/part-1.md

@@ -343,7 +343,7 @@ public class TipCalculator {
 
 この関数は:
 
-
+
 - 6人以上のグループ → 20% のチップ
 - 1-5人のグループ → 10% のチップ
 - 0人（空リスト） → 0% のチップ

package/lib/assets/docs/article/grokkingfp/java/part-2.md

@@ -629,14 +629,14 @@ List<String> inside = radiuses.flatMap(r ->
 
 1. **イミュータブルなデータ操作**
 
-
+
    - Vavr の `List` は不変
    - `take`, `drop`, `append`, `appendAll` で新しいリストを作成
    - 元のデータは変更されない
 
 2. **高階関数**
 
-
+
    - `map`: 各要素を変換
    - `filter`: 条件に合う要素を抽出
    - `foldLeft`: 畳み込み
@@ -644,13 +644,13 @@ List<String> inside = radiuses.flatMap(r ->
 
 3. **関数を返す関数**
 
-
+
    - `Predicate<T>` を返すことで再利用可能なフィルタを作成
    - 部分適用のような効果を得られる
 
 4. **flatMap**
 
-
+
    - ネストしたリストを平坦化
    - `map` + `flatten` の組み合わせ
    - リストサイズが増減する変換に対応

package/lib/assets/docs/article/grokkingfp/java/part-6.md

@@ -417,7 +417,7 @@ public static int guideScore(Guide guide) {
 
 重要なポイント:
 
-
+
 - **オーバーフロー防止**: `long` を使用して大きな数値の合計を安全に計算
 - **上限値の設定**: 各スコア成分に最大値を設定してスコアを 0-100 の範囲に
 
@@ -1168,7 +1168,7 @@ p5 --> p6
 
 以下の要件で `DataAccess` を拡張してください:
 
-
+
 - 新しいメソッド `findHotelsNearLocation` を追加
 - 戻り値は `IO<List<Hotel>>`
 

package/lib/assets/docs/article/grokkingfp/python/part-1.md

@@ -147,7 +147,7 @@ class ShoppingCartBad:
 
 このコードの問題:
 
-
+
 1. `get_items()` が内部リストへの参照を返すため、外部から変更可能
 2. `_book_added` フラグと実際のアイテムの整合性が崩れる可能性がある
 
@@ -165,7 +165,7 @@ discount = get_discount_percentage(items)  # 5
 
 この純粋関数版の利点:
 
-
+
 - 状態を持たない
 - 同じ入力には常に同じ出力
 - テストが容易
@@ -186,7 +186,7 @@ def get_tip_percentage(names: list[str]) -> int:
 
 この関数は:
 
-
+
 - 6人以上のグループ → 20% のチップ
 - 1-5人のグループ → 10% のチップ
 - 0人（空リスト） → 0% のチップ

package/lib/assets/docs/article/grokkingfp/ruby/part-1.md

@@ -351,7 +351,7 @@ end
 
 この関数は:
 
-
+
 - 6人以上のグループ → 20% のチップ
 - 1-5人のグループ → 10% のチップ
 - 0人（空リスト） → 0% のチップ

package/lib/assets/docs/article/grokkingfp/ruby/part-6.md

@@ -1207,7 +1207,7 @@ p5 --> p6
 
 以下の要件で `DataAccess` を拡張してください:
 
-
+
 - 新しいメソッド `find_restaurants_near_location` を追加
 - 戻り値は `IO[{ success: Boolean, value/error: ... }]`
 

package/lib/assets/docs/article/grokkingfp/rust/part-4.md

@@ -87,7 +87,7 @@ pub fn possible_meetings(
 
 純粋関数は：
 
-
+
 - テストが容易
 - 並列実行が安全
 - 結果を予測可能

package/lib/assets/docs/article/grokkingfp/scala/part-1.md

@@ -297,7 +297,7 @@ object TipCalculator {
 
 この関数は:
 
-
+
 - 6人以上のグループ → 20% のチップ
 - 1-5人のグループ → 10% のチップ
 - 0人（空リスト） → 0% のチップ

package/lib/assets/docs/article/grokkingfp/scala/part-3.md

@@ -522,7 +522,7 @@ case class Artist(
 
 この設計には問題があります:
 
-
+
 - `isActive` が `true` の場合、`yearsActiveEnd` は何を入れるべき？
 - 無効な状態（`isActive = true` かつ `yearsActiveEnd = 2020`）を作れてしまう
 

package/lib/assets/docs/article/grokkingfp/scala/part-6.md

@@ -709,7 +709,7 @@ p5 --> p6
 
 以下の要件で `DataAccess` を拡張してください:
 
-
+
 - 新しいメソッド `findHotelsNearLocation` を追加
 - 戻り値は `IO[Either[String, List[Hotel]]]`
 

package/lib/assets/docs/article/grokkingfp/typescript/part-1.md

@@ -274,7 +274,7 @@ const getTipPercentage = (names: readonly string[]): number => {
 
 この関数は:
 
-
+
 - 6人以上のグループ → 20% のチップ
 - 1-5人のグループ → 10% のチップ
 - 0人（空リスト） → 0% のチップ

package/lib/assets/docs/article/grokkingfp/typescript/part-4.md

@@ -48,7 +48,7 @@ end note
 
 fp-ts では:
 
-
+
 - `IO<A>` は「実行すると `A` 型の値を返す同期的な副作用のある計算」
 - `Task<A>` は「実行すると `Promise<A>` を返す非同期的な副作用のある計算」
 - IO/Task 値を作成しただけでは副作用は発生しない

package/lib/assets/docs/article/grokkingfp/typescript/part-6.md

@@ -763,7 +763,7 @@ p5 --> p6
 
 以下の要件で `DataAccess` を拡張してください:
 
-
+
 - 新しいメソッド `findRestaurantsNearLocation` を追加
 - 戻り値は `Task<Either<string, readonly Restaurant[]>>`
 

package/lib/assets/docs/article/index.md

@@ -1,39 +1,39 @@
-# 記事
-
-学習用の記事シリーズ一覧です。
-
-複数言語を横断して比較しながら、TDD、関数型プログラミング、並行処理、設計パターン、データベース設計を段階的に学べます。
-
-## 記事シリーズ
-
-| シリーズ | テーマ | 言語数 | 特徴 |
-|------|------|------|------|
-| [テスト駆動開発から始めるプログラミング入門](getting-start-tdd/index.md) | TDD を軸にした言語入門 | 14 | 共通題材で Red-Green-Refactor を体験し、言語ごとの設計思想を比較できます。 |
-| [Grokking Functional Programming](grokkingfp/index.md) | 関数型プログラミング | 11 | 純粋関数、イミュータブルデータ、Option/Either、IO、並行処理まで体系的に学べます。 |
-| [Grokking Concurrency](grokking-concurrency/index.md) | 並行処理プログラミング | 8 | スレッド、同期、非同期、ノンブロッキング I/O、分散並列処理を多言語で比較できます。 |
-| [関数型デザイン - 原則、パターン、実践](functional-desgin-ppp/index.md) | 関数型デザインパターン | 6 | OOP のデザインパターンを関数型パラダイムでどう表現するかを実践的に学べます。 |
-| [実践データベース設計：基幹業務システム編](practical-database-design/index.md) | データベース設計 | - | 販売管理・財務会計・生産管理の基幹業務システムを題材に、業務フローとデータモデルを体系的に学べます。 |
-
-## 学び方のガイド
-
-- TDD を起点に言語の基礎を学ぶ場合は、[テスト駆動開発から始めるプログラミング入門](getting-start-tdd/index.md) から読み始めてください。
-- 関数型プログラミングを体系的に学ぶ場合は、[Grokking Functional Programming](grokkingfp/index.md) を参照してください。
-- 並行処理を重点的に学ぶ場合は、[Grokking Concurrency](grokking-concurrency/index.md) を参照してください。
-- 設計原則やパターンを深く学ぶ場合は、[関数型デザイン - 原則、パターン、実践](functional-desgin-ppp/index.md) を参照してください。
-- データベース設計を実践的に学ぶ場合は、[実践データベース設計：基幹業務システム編](practical-database-design/index.md) を参照してください。
-
-## 多言語統合解説
-
-シリーズ横断で比較しながら読みたい場合は、以下の統合記事が入口になります。
-
-- [Grokking Functional Programming 多言語統合解説](grokkingfp/all/index.md)
-- [Grokking Concurrency 多言語統合解説](grokking-concurrency/all/index.md)
-- [関数型デザイン 多言語統合解説](functional-desgin-ppp/all/index.md)
-
-## 参考元
-
-- [getting-started-tdd](https://github.com/k2works/getting-started-tdd)
-- [functional-desgin-ppp](https://github.com/k2works/functional-desgin-ppp)
-- [grokking-concurrency-exercise](https://github.com/k2works/grokking-concurrency-exercise)
-- [grokkingfp-excersice](https://github.com/k2works/grokkingfp-excersice)
-- [practical-database-design](https://github.com/k2works/practical-database-design)
+# 記事
+
+学習用の記事シリーズ一覧です。
+
+複数言語を横断して比較しながら、TDD、関数型プログラミング、並行処理、設計パターン、データベース設計を段階的に学べます。
+
+## 記事シリーズ
+
+| シリーズ | テーマ | 言語数 | 特徴 |
+|------|------|------|------|
+| [テスト駆動開発から始めるプログラミング入門](getting-start-tdd/index.md) | TDD を軸にした言語入門 | 14 | 共通題材で Red-Green-Refactor を体験し、言語ごとの設計思想を比較できます。 |
+| [Grokking Functional Programming](grokkingfp/index.md) | 関数型プログラミング | 11 | 純粋関数、イミュータブルデータ、Option/Either、IO、並行処理まで体系的に学べます。 |
+| [Grokking Concurrency](grokking-concurrency/index.md) | 並行処理プログラミング | 8 | スレッド、同期、非同期、ノンブロッキング I/O、分散並列処理を多言語で比較できます。 |
+| [関数型デザイン - 原則、パターン、実践](functional-desgin-ppp/index.md) | 関数型デザインパターン | 6 | OOP のデザインパターンを関数型パラダイムでどう表現するかを実践的に学べます。 |
+| [実践データベース設計：基幹業務システム編](practical-database-design/index.md) | データベース設計 | - | 販売管理・財務会計・生産管理の基幹業務システムを題材に、業務フローとデータモデルを体系的に学べます。 |
+
+## 学び方のガイド
+
+- TDD を起点に言語の基礎を学ぶ場合は、[テスト駆動開発から始めるプログラミング入門](getting-start-tdd/index.md) から読み始めてください。
+- 関数型プログラミングを体系的に学ぶ場合は、[Grokking Functional Programming](grokkingfp/index.md) を参照してください。
+- 並行処理を重点的に学ぶ場合は、[Grokking Concurrency](grokking-concurrency/index.md) を参照してください。
+- 設計原則やパターンを深く学ぶ場合は、[関数型デザイン - 原則、パターン、実践](functional-desgin-ppp/index.md) を参照してください。
+- データベース設計を実践的に学ぶ場合は、[実践データベース設計：基幹業務システム編](practical-database-design/index.md) を参照してください。
+
+## 多言語統合解説
+
+シリーズ横断で比較しながら読みたい場合は、以下の統合記事が入口になります。
+
+- [Grokking Functional Programming 多言語統合解説](grokkingfp/all/index.md)
+- [Grokking Concurrency 多言語統合解説](grokking-concurrency/all/index.md)
+- [関数型デザイン 多言語統合解説](functional-desgin-ppp/all/index.md)
+
+## 参考元
+
+- [getting-started-tdd](https://github.com/k2works/getting-started-tdd)
+- [functional-desgin-ppp](https://github.com/k2works/functional-desgin-ppp)
+- [grokking-concurrency-exercise](https://github.com/k2works/grokking-concurrency-exercise)
+- [grokkingfp-excersice](https://github.com/k2works/grokkingfp-excersice)
+- [practical-database-design](https://github.com/k2works/practical-database-design)

package/lib/assets/docs/design/index.md

@@ -1,44 +1,44 @@
-# 設計
-
-設計ドキュメントです。要件定義に基づき、バックエンド・フロントエンド・インフラのアーキテクチャから、データモデル、ドメインモデル、UI、テスト戦略、非機能要件、運用要件まで包括的に設計しています。
-
-## ドキュメント一覧
-
-### アーキテクチャ
-
-| ドキュメント | 概要 | 状況 |
-| :--- | :--- | :--- |
-| バックエンドアーキテクチャ | バックエンドの責務分割、レイヤ、連携方式を整理 | 未作成 |
-| フロントエンドアーキテクチャ | UI 構成、状態管理、画面遷移を整理 | 未作成 |
-| インフラストラクチャ | 実行環境、ネットワーク、デプロイ構成を整理 | 未作成 |
-
-### モデル設計
-
-| ドキュメント | 概要 | 状況 |
-| :--- | :--- | :--- |
-| データモデル設計 | 概念・論理データモデル、テーブル定義、ER 図を整理 | 未作成 |
-| ドメインモデル設計 | コンテキスト、集約、エンティティ、値オブジェクトを整理 | 未作成 |
-
-### UI/UX設計
-
-| ドキュメント | 概要 | 状況 |
-| :--- | :--- | :--- |
-| UI 設計 | 画面設計、画面遷移図、コンポーネント設計を整理 | 未作成 |
-
-### 品質・運用
-
-| ドキュメント | 概要 | 状況 |
-| :--- | :--- | :--- |
-| テスト戦略 | テストピラミッド、ツール、品質ゲートを整理 | 未作成 |
-| 非機能要件 | 性能、可用性、セキュリティ、保守性、拡張性を整理 | 未作成 |
-| 運用要件 | 監視、バックアップ、デプロイ、障害対応を整理 | 未作成 |
-
-### その他
-
-| ドキュメント | 概要 | 状況 |
-| :--- | :--- | :--- |
-| 技術スタック選定 | 技術スタック一覧とバージョン管理方針を整理 | 未作成 |
-
-## 補足
-
-- 実ドキュメントを追加したら、この一覧と `docs/index.md` を更新します。
+# 設計
+
+設計ドキュメントです。要件定義に基づき、バックエンド・フロントエンド・インフラのアーキテクチャから、データモデル、ドメインモデル、UI、テスト戦略、非機能要件、運用要件まで包括的に設計しています。
+
+## ドキュメント一覧
+
+### アーキテクチャ
+
+| ドキュメント | 概要 | 状況 |
+| :--- | :--- | :--- |
+| バックエンドアーキテクチャ | バックエンドの責務分割、レイヤ、連携方式を整理 | 未作成 |
+| フロントエンドアーキテクチャ | UI 構成、状態管理、画面遷移を整理 | 未作成 |
+| インフラストラクチャ | 実行環境、ネットワーク、デプロイ構成を整理 | 未作成 |
+
+### モデル設計
+
+| ドキュメント | 概要 | 状況 |
+| :--- | :--- | :--- |
+| データモデル設計 | 概念・論理データモデル、テーブル定義、ER 図を整理 | 未作成 |
+| ドメインモデル設計 | コンテキスト、集約、エンティティ、値オブジェクトを整理 | 未作成 |
+
+### UI/UX設計
+
+| ドキュメント | 概要 | 状況 |
+| :--- | :--- | :--- |
+| UI 設計 | 画面設計、画面遷移図、コンポーネント設計を整理 | 未作成 |
+
+### 品質・運用
+
+| ドキュメント | 概要 | 状況 |
+| :--- | :--- | :--- |
+| テスト戦略 | テストピラミッド、ツール、品質ゲートを整理 | 未作成 |
+| 非機能要件 | 性能、可用性、セキュリティ、保守性、拡張性を整理 | 未作成 |
+| 運用要件 | 監視、バックアップ、デプロイ、障害対応を整理 | 未作成 |
+
+### その他
+
+| ドキュメント | 概要 | 状況 |
+| :--- | :--- | :--- |
+| 技術スタック選定 | 技術スタック一覧とバージョン管理方針を整理 | 未作成 |
+
+## 補足
+
+- 実ドキュメントを追加したら、この一覧と `docs/index.md` を更新します。