spec-runner 1.1.13 → 1.1.16

package/spec-runner/templates/.github/skills/architecture-skill-development/SKILL.md

@@ -35,20 +35,22 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 
 ## Phase 3: skill / rule / template へ分解
 
+ファイルを作成する前に **`.github/instructions/harness-formats.instructions.md`** を読み、フォーマットを確認する。
+
 1. 会話フローは skill にする
 2. 常時守る約束は rule にする
 3. 毎回コピーする設計書は template にする
 
-### plugin-development を種として使う
+### docs-driven-seed を種として使う
 
-新規開発フローの skill を作る場合は、`plugin-development` を種として使う。
-`plugin-development` はプラグイン型アーキテクチャ向けの reference workflow であり、
+新規開発フローの skill を作る場合は、`docs-driven-seed` を種として使う。
+`docs-driven-seed` は UC/DDD 駆動の docs 正本開発フローの参照実装であり、
 そのまま使うのではなく、**このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作る**ことを目的とする。
 
 具体的には:
-- `.claude/skills/plugin-development/SKILL.md` をコピーして、project 専用の開発 skill の土台にする
+- `.claude/skills/docs-driven-seed/SKILL.md` をコピーして、project 専用の開発 skill の土台にする
 - フェーズ構成・テンプレートパス・用語をこのプロジェクトの実態に合わせて書き換える
-- 元の `plugin-development` は書き換え完了後にアーカイブ候補とする（Phase 7 で提案する）
+- 元の `docs-driven-seed` は書き換え完了後にアーカイブ候補とする（Phase 7 で提案する）
 
 ユーザーに確認・承認を得る
 
@@ -109,7 +111,7 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 |---|---|
 | `architecture-definition` | 新規プロジェクト初期化専用。アーキテクチャ確定後は不要 |
 | `existing-project-to-docs` | 既存プロジェクト取り込み専用。docs 生成後は不要 |
-| `plugin-development` | Phase 3 で project 専用 skill の種として使い終えたら不要 |
+| `docs-driven-seed` | Phase 3 で project 専用 skill の種として使い終えたら不要 |
 | `architecture-skill-development`（このファイル自身） | project 専用 skill が安定したら不要。ただしアーキテクチャが大きく変わる場合は再利用する可能性があるため、削除ではなくアーカイブを推奨 |
 
 ### 手順
@@ -117,7 +119,10 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 1. 上記の候補をユーザーに提示し、整理してよいか確認する
 2. 承認を得た skill を `.claude/skills/` と `.github/skills/` から削除する
 3. 必要であれば削除前にバックアップ先をユーザーに伝える
-4. `CLAUDE.md` を更新する
+4. `.spec-runner/` の不要ファイルも整理する
+   - `intake/current-system-inventory.md` — docs に昇格済みなら削除してよい
+   - `architecture/architecture.yaml` — project 専用 skill が完成し、参照不要になったら削除してよい
+5. `CLAUDE.md` を更新する
    - 「初回自動起動」セクション（spec-runner インストール時に生成されたもの）を削除する
    - 作成した project 専用 skill の名前と使いどころを記載する
    - 例:

package/spec-runner/templates/.github/skills/design-change/SKILL.md

@@ -41,16 +41,16 @@ Phase 6: TDD → 実装 → 検証
 3. 各案について概要・メリット・デメリット・適合性を示す
 4. ユーザーが案を決定する
 5. テンプレート `templates/90_ADR/ADRテンプレート.md` をコピーして生成する
-6. ファイル名は `mmdd-{日本語タイトル}.md` 形式にする（例: `0404-キャッシュ戦略の変更.md`）
+6. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
 
 ### ADR 配置ルール
 
-| 変更スコープ | 配置先 |
-|------------|--------|
-| 横断的な決定 | `docs/02_概要設計/90_ADR/` |
-| 特定ドメイン寄りの決定 | `docs/02_概要設計/<ドメイン>/90_ADR/` |
-
-MVP では `docs/02_概要設計/90_ADR/` に集約する。
+| 対象 | 配置先 |
+|------|--------|
+| システム横断の決定 | `docs/02_概要設計/90_ADR/全体/` |
+| ドメイン設計の決定 | `docs/02_概要設計/90_ADR/ドメイン/` |
+| UC フローの決定 | `docs/02_概要設計/90_ADR/UC/` |
+| DB・外部サービスの決定 | `docs/02_概要設計/90_ADR/DB/` |
 
 ## Phase 3: 影響ドキュメントの確定
 
@@ -62,7 +62,7 @@ MVP では `docs/02_概要設計/90_ADR/` に集約する。
 
 ## Phase 4: 概要設計の修正
 
-1. `ユースケース一覧.md` / `システム全体俯瞰.md` / UC 個別文書 / ADR を必要順に修正する
+1. `ユースケース一覧.md` / `システム全体俯瞰.md` / `ドメインモデル.md` / ADR を必要順に修正する
 2. 修正完了ごとにチェックリストを更新する
 3. 全概要設計の修正完了後、ユーザーに確認・承認を得る
 
@@ -73,10 +73,11 @@ MVP では `docs/02_概要設計/90_ADR/` に集約する。
 
 ## Phase 5: 詳細設計の修正
 
-1. `docs/03_詳細設計/src/**` を `src/` ミラーで修正する
-2. 補助設計が必要な場合だけ `docs/03_詳細設計/infrastructure/**` を修正する
-3. frontmatter の `depends_on` / `maps_to` を更新する
-4. ユーザーに最終確認を得る
+1. `docs/03_詳細設計/01_ドメイン/**` のドメイン設計を修正する
+2. `docs/03_詳細設計/02_ユースケース/**` の UC 設計を修正する
+3. DB・外部サービスの変更がある場合は `docs/03_詳細設計/03_DB・外部サービス/**` を修正する
+4. frontmatter の `depends_on` / `maps_to` を更新する
+5. ユーザーに最終確認を得る
 
 ## Phase 6: TDD → 実装 → 検証
 

package/spec-runner/templates/.github/skills/docs-driven-seed/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: docs-driven-seed
+description: UC/DDD 駆動の docs 正本開発フローの種。新規プロジェクトの初期テンプレートとして使い、architecture-skill-development でプロジェクト専用スキルに育てる。
+---
+
+# docs-driven-seed
+
+UC/DDD 駆動の docs 正本開発フローの**参照実装（種）**。
+プロジェクト固有のスキルに育てる前の出発点として使う。
+
+**このスキルをそのまま使い続けない。`architecture-skill-development` で自プロジェクト専用スキルに育てることを前提とする。**
+
+## 全体フロー
+
+```
+Phase 1: 要件定義
+Phase 2: 概要設計（ユースケース + ドメインモデル）
+Phase 3: ADR（必要時のみ）
+Phase 4: 詳細設計（ドメイン → UC → DB・外部サービス）
+Phase 5: TDD → 実装
+```
+
+## 前提ルール
+
+- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
+- 詳細設計は `01_ドメイン/` `02_ユースケース/` `03_DB・外部サービス/` の 3 層で構成する
+- UC がドメインを使う。ドメインの中に UC は入れない
+- `maps_to` は必ず設定する。パス推定に頼らない
+- ユーザー承認なしに次フェーズへ進めない
+
+## Phase 1: 要件定義
+
+1. 以下をユーザーにヒアリングする
+   - 解決すべき課題・提供価値
+   - 対象ユーザー
+   - 非機能要件・スコープ外
+   - 技術・ビジネス制約
+2. `docs/01_要件定義/要件定義.md` を作る
+3. ドメイン用語が出てきたら `docs/01_要件定義/ユビキタス言語辞書.md` に随時追記する
+4. ユーザーに確認・承認を得る
+
+### 出力
+
+```
+docs/01_要件定義/
+  要件定義.md
+  ユビキタス言語辞書.md
+```
+
+## Phase 2: 概要設計
+
+### 2-1. ユースケース一覧
+
+1. 要件定義からユースケースを洗い出す（Query / Command を意識）
+2. `docs/02_概要設計/ユースケース一覧.md` を作る
+3. ユーザーに確認・承認を得る
+
+### 2-2. ドメインモデル + システム全体俯瞰
+
+1. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を作る
+2. コンポーネント全体図・外部 IF を整理し `docs/02_概要設計/システム全体俯瞰.md` を作る
+3. ユーザーに確認・承認を得る
+
+### 出力
+
+```
+docs/02_概要設計/
+  ユースケース一覧.md
+  ドメインモデル.md
+  システム全体俯瞰.md
+  90_ADR/
+    全体/
+    ドメイン/
+    UC/
+    DB/
+```
+
+## Phase 3: ADR（必要時のみ）
+
+1. 設計判断が必要な場合だけ ADR を作る
+2. **必ず 3 案を比較する**
+3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
+
+| 対象 | 配置先 |
+|------|--------|
+| システム横断の決定 | `90_ADR/全体/` |
+| ドメイン設計の決定 | `90_ADR/ドメイン/` |
+| UC フローの決定 | `90_ADR/UC/` |
+| DB・外部サービスの決定 | `90_ADR/DB/` |
+
+4. 採用案を概要設計へ反映してから次へ進む
+
+## Phase 4: 詳細設計
+
+**ドメイン → UC → DB・外部サービス の順に設計する。**
+
+### 4-1. ドメイン
+
+テンプレート: `templates/03_詳細設計/01_ドメイン/{ドメイン名}.md`
+
+```
+docs/03_詳細設計/01_ドメイン/
+  {ドメイン名}.md
+```
+
+### 4-2. ユースケース
+
+シーケンス図は UC ファイルに Mermaid で埋め込む。
+
+テンプレート: `templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md`
+
+```
+docs/03_詳細設計/02_ユースケース/
+  UC-{日本語名}.md
+```
+
+### 4-3. DB・外部サービス（必要時のみ）
+
+```
+docs/03_詳細設計/03_DB・外部サービス/
+  スキーマ定義.dbml
+  外部サービス.md
+```
+
+ユーザーに確認・承認を得る
+
+## Phase 5: TDD → 実装
+
+`test-driven-development` スキルへ移行する。
+
+### 実装完了後
+
+- `@design-reviewer` — 設計書⇔実装の整合性チェック
+- `@code-reviewer` — コーディング規約への適合チェック
+
+## 原則
+
+- **このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てることを前提とする**
+- **ドメインを先に設計し、UC はドメインを参照する形で書く**
+- **`maps_to` は必ず設定する。パス推定に頼らない**

package/spec-runner/templates/.github/skills/docs-driven-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/01_/343/203/211/343/203/241/343/202/244/343/203/263/{/343/203/211/343/203/241/343/202/244/343/203/263/345/220/215}.md

@@ -0,0 +1,39 @@
+---
+spec_runner:
+  node_id: detail.domain.{ドメイン名}
+  kind: detailed_design
+  depends_on:
+    - overview.domain_model
+  maps_to:
+    - src/domain/{ドメイン名}/
+---
+
+# {ドメイン名} ドメイン詳細設計
+
+## 責務
+
+- {このドメインが扱うビジネス概念}
+- {このドメインの不変条件・制約}
+
+## 集約
+
+| 集約 | 責務 | ルートエンティティ |
+|------|------|----------------|
+| {集約名} | {責務} | {ルートエンティティ名} |
+
+## 値オブジェクト
+
+| 値オブジェクト | 制約・ルール |
+|--------------|------------|
+| {名前} | {制約} |
+
+## ドメインルール
+
+- {ルール1}
+- {ルール2}
+
+## テスト観点
+
+- {正常系の観点}
+- {ルール違反の観点}
+- {境界条件の観点}

package/spec-runner/templates/.github/skills/docs-driven-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/02_/343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/UC-{/346/227/245/346/234/254/350/252/236/345/220/215}.md

@@ -0,0 +1,55 @@
+---
+spec_runner:
+  node_id: detail.usecase.{UC名}
+  kind: detailed_design
+  depends_on:
+    - overview.use_case_list
+    - detail.domain.{ドメイン名}
+  maps_to:
+    - src/application/{uc_name}/
+    - tests/application/{uc_name}/
+---
+
+# UC-{UC名} 詳細設計
+
+## 概要
+
+- 使用するドメイン: {ドメイン名}
+- トリガー: {何がこのUCを呼び出すか}
+- 事前条件: {UCが成立するために必要な状態}
+- 事後条件: {UC完了後の状態}
+
+## 入出力
+
+| 種別 | 名前 | 型 | 説明 |
+|------|------|----|------|
+| 入力 | {入力名} | {型} | {説明} |
+| 出力 | {出力名} | {型} | {説明} |
+
+## 主要フロー
+
+```mermaid
+sequenceDiagram
+  {シーケンス図}
+```
+
+1. {ステップ1}
+2. {ステップ2}
+
+## 判断条件
+
+| 判断ポイント | 条件 | アクション |
+|------------|------|----------|
+| {判断ポイント} | {条件} | {アクション} |
+
+## エラーポリシー
+
+| エラーケース | 発生条件 | 対応 |
+|------------|---------|------|
+| {エラーケース} | {発生条件} | {対応} |
+
+## テスト観点
+
+- {正常系の観点}
+- {異常系の観点}
+- {境界条件の観点}

package/spec-runner/templates/.github/skills/existing-project-to-docs/SKILL.md

@@ -27,22 +27,25 @@ Phase 5: architecture contract 化
 
 ## Phase 2: 要件とユースケースの抽出
 
-1. 既存機能からユースケースを逆算する
+1. `current-system-inventory.md` を起点に、既存機能からユースケースを逆算する
 2. `docs/01_要件定義/要件定義.md` と `docs/02_概要設計/ユースケース一覧.md` の draft を作る
-3. ユーザーに確認・承認を得る
+3. ドメイン用語が識別できたら `docs/01_要件定義/ユビキタス言語辞書.md` も draft する
+4. ユーザーに確認・承認を得る
 
 ## Phase 3: 概要設計の draft 化
 
-1. `docs/02_概要設計/システム全体俯瞰.md` を作る
-2. 必要なら ADR 候補も洗い出す
-3. ユーザーに確認・承認を得る
+1. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を draft する
+2. `docs/02_概要設計/システム全体俯瞰.md` を作る
+3. 必要なら ADR 候補も洗い出す（配置先は `90_ADR/全体/` / `ドメイン/` / `UC/` / `DB/`）
+4. ユーザーに確認・承認を得る
 
 ## Phase 4: 詳細設計の draft 化
 
-1. `docs/03_詳細設計/src/**` を `src/` ミラーで作る
-2. `maps_to` に対応コードとテストを入れる
-3. 補助設計が必要なら `docs/03_詳細設計/infrastructure/**` を作る
-4. ユーザーに確認・承認を得る
+1. ドメインごとにビジネスルール・集約を整理し `docs/03_詳細設計/01_ドメイン/{ドメイン名}.md` を draft する
+2. UC ごとに `docs/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を draft する
+3. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/03_DB・外部サービス/` を作る
+4. 各ファイルの `maps_to` に対応コードとテストを入れる
+5. ユーザーに確認・承認を得る
 
 ## Phase 5: architecture contract 化
 

package/spec-runner/templates/.github/skills/harness-engineering/SKILL.md

@@ -68,6 +68,8 @@ Phase 4: 影響範囲の反映確認
 
 ## Phase 3: skill / rule / agent / template の修正
 
+ファイルを作成・修正する前に **`.github/instructions/harness-formats.instructions.md`** を読み、フォーマットを確認する。
+
 1. 対象ファイルを特定する
 2. 意図が変わらない最小差分で修正する
 3. 片系だけでなく、対応するテンプレートも揃えて更新する
@@ -91,6 +93,8 @@ Phase 4: 影響範囲の反映確認
 - Claude / Copilot の対応ファイルに反映漏れがないか
 - 今回限りのノイズをルール化していないか
 - skill 名・起動条件・使いどころを変更した場合、`CLAUDE.md` の記述と一致しているか
+- `CLAUDE.md` が肥大化していないか（20行超えたら `instructions/` や `skills/` へ移動を検討する）
+- docs 構造・命名規則・node_id 体系に影響する変更の場合、`design-docs.instructions.md` と整合しているか
 
 ## 原則
 

package/spec-runner/templates/.github/skills/test-driven-development/SKILL.md

@@ -26,13 +26,89 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 テストより先にコードを書いたなら削除して最初からやり直す。
 「参考として残す」も「テストを書きながら適応させる」も不可。
 
+## テスト戦略：テストピラミッド
+
+実装前にどのテスト種別を書くかを決める。迷ったら**単体テストから始める**。
+
+```
+        /\
+       /E2E\        少数・遅い・ユーザーシナリオ全体
+      /------\
+     /  結合   \    中程度・モジュール間連携・外部境界
+    /----------\
+   /    単体    \   多数・高速・関数・クラス単位
+  /______________\
+```
+
+### 単体テスト（Unit）
+
+**対象:** 関数・クラス・モジュールの振る舞い（外部依存なし）
+
+**書くとき:**
+- ビジネスロジック・計算・変換処理
+- エラー処理・バリデーション
+- 状態変化（純粋関数・値オブジェクト）
+
+**外部依存の扱い:** 実際に遅い・副作用がある依存のみモック。それ以外は実物を使う。
+
+**速度目安:** ミリ秒単位。CI で毎回全件実行できる。
+
+### 結合テスト（Integration）
+
+**対象:** 複数モジュールの連携、DB・キャッシュ・外部APIとの境界
+
+**書くとき:**
+- DB へのクエリ・永続化
+- 外部サービス呼び出し（HTTP, メッセージキュー等）
+- 複数の集約をまたぐユースケース
+
+**外部依存の扱い:** 原則として実物を使う（テスト用 DB、テスト環境の外部サービス）。
+動かせない外部サービスのみスタブ／フェイクで代替する。
+
+**速度目安:** 秒単位。PR ごとに実行できる。
+
+### E2E テスト
+
+**対象:** ユーザーが実際に操作するシナリオ全体（UI から DB まで）
+
+**書くとき:**
+- 最重要のユーザーシナリオ（ハッピーパス）
+- リグレッションが致命的な機能（決済・認証等）
+
+**数を絞る:** E2E は維持コストが高い。書く前に「単体＋結合で代替できないか？」を問う。
+
+**速度目安:** 分単位。夜間や本番リリース前など頻度を落として実行。
+
+## テスト種別の選び方
+
+| 実装するもの | まず書くテスト | 追加で書くテスト |
+|---|---|---|
+| ロジック・計算 | 単体 | — |
+| DB 操作 | 結合 | — |
+| API エンドポイント | 結合 | 主要シナリオは E2E |
+| 複数サービスをまたぐフロー | 結合 | — |
+| ユーザー向け主要機能 | 単体＋結合 | E2E（絞る） |
+| バグ修正 | 最小レベルで再現テスト | — |
+
+**バグ修正の場合:** バグを再現できる最も低いレベルのテストを書く。
+単体で再現できるなら単体、DBが絡むなら結合。E2E で初めて再現するバグは、単体・結合に落とし込めないか検討する。
+
 ## テスト実行コマンド
 
 > このスキルはテンプレートとして配布されます。
 > `architecture-skill-development` を使ってプロジェクト固有のコマンドに書き換えてください。
 
 ```bash
-# 全テスト（プロジェクトのテストコマンドに置き換える）
+# 単体テスト（高速・毎回実行）
+<your-unit-test-command>
+
+# 結合テスト
+<your-integration-test-command>
+
+# E2E テスト
+<your-e2e-test-command>
+
+# 全テスト
 <your-test-command>
 
 # 特定ファイル
@@ -46,7 +122,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 ### RED - 失敗するテストを書く
 
-起きてほしいことを示す、最小のテストを1つ書く。
+テスト種別を決めたうえで、起きてほしいことを示す最小のテストを1つ書く。
 
 ```
 // 例（言語・フレームワークはプロジェクトに合わせる）
@@ -93,7 +169,7 @@ test("ある入力に対して期待する出力を返す", () => {
 `@test-runner` エージェントに委任して実行する。
 
 - テストが通る
-- **他のテストも全て通る**
+- **同種のテストが全て通る**（単体なら単体全件、結合なら結合全件）
 - 出力がクリーン（エラー、警告なし）
 - **カバレッジの未カバー行を確認** — 新規コードが未カバーなら追加テストを書く
 
@@ -122,18 +198,34 @@ GREEN / REFACTORフェーズで書く実装コードにもビジネスロジッ
 
 ## テスト構成
 
-テストファイルは `src/` と同じディレクトリ構造を `tests/` に鏡写しにする。
+```
+tests/
+  unit/        # 単体テスト（src/ と同じ構造を鏡写し）
+  integration/ # 結合テスト
+  e2e/         # E2E テスト
+```
+
+テストファイルは `src/` と同じディレクトリ構造を各テスト種別のディレクトリ内に鏡写しにする。
 
 ## fixture / テストデータの活用
 
 - テストごとに独立した状態を持つ
 - テストデータ生成にはヘルパ関数を定義して一貫性を保つ
 - 外部サービス（API・メール・ストレージ等）は必要な場合のみモックする
+- 結合テスト用のシードデータは `tests/integration/fixtures/` に置く
 
 ## モックのルール
 
 モックは分離の手段であり、テスト対象ではない。
 
+**テスト種別ごとのモック方針:**
+
+| テスト種別 | 原則 |
+|---|---|
+| 単体 | 外部 I/O（DB・HTTP・ファイル）のみモック可。ビジネスロジックはモックしない |
+| 結合 | 実物の外部依存を使う。動かせない外部サービスのみスタブ可 |
+| E2E | モックしない。全て実物 |
+
 **モック前の自問:**
 1. 「実メソッドにはどんな副作用があるか？」
 2. 「このテストはその副作用に依存しているか？」
@@ -168,6 +260,8 @@ GREEN / REFACTORフェーズで書く実装コードにもビジネスロジッ
 | テスト前にコードを書いた | コードを削除し、TDDで最初からやり直す |
 | テストが最初から通る | 既存挙動をテストしている。テストを修正する |
 | なぜ失敗したか説明できない | テストが正しいか再検討する |
+| 全部 E2E で書いた | ピラミッドが逆転している。単体・結合に落とし込む |
+| 全部モックだらけ | 結合が強すぎる。または結合テストを書くべき |
 
 **どれか1つでも当てはまるなら: コードを削除し、TDDで最初からやり直す。**
 
@@ -180,14 +274,15 @@ GREEN / REFACTORフェーズで書く実装コードにもビジネスロジッ
 
 完了宣言の前に:
 
+- [ ] 実装前にテスト種別（単体・結合・E2E）を決めた
 - [ ] 新規関数／メソッドにテストがある
 - [ ] 各テストは実装前に失敗するのを見た
 - [ ] 期待通りの理由で失敗した（機能不足であり誤字ではない）
 - [ ] 通す最小コードを書いた
-- [ ] 全テストが通る
+- [ ] 同種のテストが全件通る
 - [ ] 出力がクリーン（エラー、警告なし）
 - [ ] カバレッジを確認し、新規コードの未カバー行がない
-- [ ] 実コード中心（不可避な場合のみモック）
+- [ ] モック方針がテスト種別に合っている
 - [ ] エッジケースとエラーをカバーした
 
 すべてにチェックできないならTDDを飛ばしている。やり直すこと。
@@ -197,9 +292,11 @@ GREEN / REFACTORフェーズで書く実装コードにもビジネスロジッ
 | 問題 | 解決 |
 |------|------|
 | どうテストすべきか分からない | 望むAPIを書き、まずアサーションを書く。ユーザーに相談する |
+| どのテスト種別か迷う | 単体から始める。単体で書けないなら結合を検討する |
 | テストが複雑すぎる | 設計が複雑すぎる。インターフェースを簡素化する |
-| 何でもモック必須 | 結合が強すぎる。依存性注入を使う |
+| 何でもモック必須 | 結合が強すぎる。依存性注入を使う。または結合テストで書く |
 | セットアップが巨大 | fixtureやテストユーティリティに抽出する。それでも大きいなら設計を簡素化する |
+| E2E が遅すぎる | 単体・結合に落とし込めるか検討する |
 
 ## 最終ルール