ai-check-template 0.2.0-alpha.0

package/package-templates/docs/philosophy/given-when-then.md

@@ -0,0 +1,206 @@
+# Given-When-Then
+
+> **ステータス**: Draft v0.1（Phase 1 dogfooding 後に改訂予定）
+
+## このファイルの守備範囲
+
+Given-When-Then（GWT）構文の定義と、AI 駆動開発における受け入れ条件先行運用を扱う。
+
+GWT の「Then」を機械検証可能な「名」に変換する方法は [`formal-name-match.md`](./formal-name-match.md)、各層（Static / Unit / Integration / E2E / DB-RLS）での GWT 例は [`test-pyramid.md`](./test-pyramid.md)、GWT で書くべき観点を導く技法は [`qa-techniques.md`](./qa-techniques.md) を参照。
+
+## 概念定義
+
+Given-When-Then（GWT）は、**テストケース・受け入れ条件・要件を「前提 / 操作 / 期待結果」の 3 要素で表現する記法**。
+
+- **Given**: 前提条件（テスト開始時の状態）
+- **When**: 実行する操作（外部入力 / API 呼び出し / ユーザー操作）
+- **Then**: 期待結果（出力 / 状態変化 / 副作用）
+
+AI 駆動開発では、いきなり「実装してください」と AI に依頼すると、「正しさ」の基準が AI と人間で食い違う。**実装前に GWT で受け入れ条件を AI に書かせる**ことで、何をもって正しいかを先に固定する。
+
+GWT は形名参同の「名」を具体化するための記法。
+
+## GWT 構文
+
+### 基本形
+
+```
+Given: <前提条件>
+When: <操作>
+Then: <期待結果>
+```
+
+例:
+```
+Given: 未ログインのユーザーが商品一覧ページを開いている
+When: 商品詳細リンクをクリックする
+Then: 商品詳細ページが表示され、保存ボタンが「ログインが必要です」と表示される
+```
+
+### 複数 When（And）
+
+```
+Given: ユーザーがログインしている
+When: アイテム X を保存する
+And: 保存ボタンを再度クリックする
+Then: 保存が解除され、保存一覧から X が消える
+```
+
+ただし複数 When は責務が混在する兆候。可能ならテストケースを分ける。
+
+### 複数 Then（And）
+
+```
+Given: ユーザーがログイン済み
+When: プロフィール更新フォームを送信する
+Then: ステータス 200 が返る
+And: DB の users.updated_at が更新される
+And: 「保存しました」トーストが表示される
+```
+
+複数 Then は OK（1 操作で複数の副作用がある）。各 Then が独立に検証可能であることが重要。
+
+### Background（共通前提）
+
+複数のシナリオで前提が共通の場合、Background でまとめる:
+
+```
+Background:
+  Given: 一般ユーザー A がログイン済み
+  And: アイテム X, Y, Z が DB に存在する
+
+Scenario 1: 一覧表示
+  When: アイテム一覧ページを開く
+  Then: X, Y, Z がすべて表示される
+
+Scenario 2: 保存
+  When: アイテム X を保存する
+  Then: 保存一覧に X だけが表示される
+```
+
+## AI への指示パターン
+
+### 実装前: 受け入れ条件を先に出させる
+
+```
+この機能を実装する前に、Given-When-Then 形式で受け入れ条件を 5 件以上書いてください。
+
+含めるべき観点:
+- 正常系（最低 2 件）
+- 異常系（最低 2 件）
+- 境界ケース（最低 1 件）
+
+各シナリオは独立して検証可能であること。
+まだコードは書かないでください。
+```
+
+これにより、AI が「何を作るか」を曖昧なまま実装に入るのを防ぐ。
+
+### 実装後: GWT と実装の対応表を出させる
+
+```
+実装が完了したら、以下の表を出力してください。
+
+| Scenario | 検証コマンド | 実装ファイル | 検証結果 |
+|---|---|---|---|
+```
+
+GWT のシナリオ ID と実装の対応を明示することで、後からの保守が楽になる。
+
+### テスト生成: GWT からテストコードを生成
+
+```
+以下の GWT シナリオに対応するテストコードを生成してください。
+ただし以下の制約を守ってください:
+
+- Given は beforeEach または setup ステップに対応
+- When はテスト内の操作 (act) に対応
+- Then は assertion に対応
+- 1 Scenario = 1 test case
+- テスト種別（Unit / Integration / E2E）を明示
+```
+
+GWT は人間が読みやすいが、AI が直接実行できる形式ではない。GWT → テストコードへの変換を AI に任せる。
+
+## 受け入れ条件への落とし方
+
+GWT は人間が読みやすい一方、機械検証可能化が必要。以下の手順で「形名参同」の「名」に変換する。
+
+### 1. Then を測定可能な形にする
+
+悪い例:
+```
+Then: 正しく動作する
+```
+
+良い例:
+```
+Then: レスポンスステータスが 200 で、レスポンスボディの id フィールドが UUID v4 形式
+```
+
+### 2. 検証コマンドに対応させる
+
+```
+Scenario: ログイン成功
+  Given: 有効なメールアドレスとパスワードを保持
+  When: POST /auth/login を呼ぶ
+  Then: ステータス 200 とトークンが返る
+
+検証コマンド:
+  STATUS=$(curl -s -o /tmp/body -w "%{http_code}" -X POST /auth/login \
+    -d '{"email":"...","password":"..."}')
+  test "$STATUS" = "200" && jq -e '.token' /tmp/body
+```
+
+### 3. 失敗時の振る舞いも GWT で書く
+
+正常系だけでは「名」が不完全。異常系も明示する。
+
+```
+Scenario: ログイン失敗（無効パスワード）
+  Given: 登録済みメールアドレスを保持
+  When: 誤ったパスワードで POST /auth/login を呼ぶ
+  Then: ステータス 401 と { "error": "invalid_credentials" } が返る
+  And: DB の failed_attempts カウンターが +1 される
+```
+
+異常系の Then には「拒否される / エラーが返る / 副作用が起きない」を明示する。
+
+## アンチパターン
+
+| アンチパターン | 何が悪いか | 修正 |
+|---|---|---|
+| 曖昧な Given（「いい感じの状態」） | 再現できない、テストできない | 具体的な状態を列挙 |
+| 副作用を持つ When（内部で他処理を勝手に実行） | 何を検証しているか不明 | 1 When = 1 操作 |
+| 検証不能な Then（「ちゃんと動く」） | 機械検証できない | 出力 / 状態変化を具体化 |
+| Then が複数の責務（ログ + DB + API を 1 行で混在） | 失敗原因が特定できない | Scenario を分ける or And で並列化 |
+| Given に実装詳細（「内部で X 関数が呼ばれている」） | 仕様ではなく実装に依存 | 観測可能な状態のみ書く |
+| Scenario が長すぎる（10 行以上） | 1 Scenario が複数仕様を兼ねている | 分割する |
+| 期待結果が「画面に何か出る」 | 出力内容が確認不能 | 文言 or 構造を具体化 |
+
+## 形名参同との関係
+
+GWT の Then = 形名参同の「名」。実装後に Then を機械検証コマンドで照合することで、「名」と「形」の一致を確認する。
+
+```
+GWT の Then「ステータス 200 と token が返る」
+  ↓ 機械検証可能化
+名: HTTP status == 200, response.token != null
+  ↓ 実装後に測定
+形: curl コマンドの実測値
+  ↓ 照合
+名 == 形 ?
+```
+
+GWT を書いた段階で「名」がほぼ確定する。実装は「名」を満たすように行い、検証は「形」と照合するだけ。
+
+## 隣接する思想との関係
+
+- [`formal-name-match.md`](./formal-name-match.md) — GWT の Then を機械検証可能な「名」に変換し、「形」と照合する
+- [`test-pyramid.md`](./test-pyramid.md) — 各層（Static / Unit / Integration / E2E / DB-RLS）の GWT 例
+- [`qa-techniques.md`](./qa-techniques.md) — GWT で書くべき観点を導出する技法（同値分割・境界値・デシジョンテーブル等）
+
+## 出典
+
+- Notion ページ: `35b68c677f4380bfa1ffeab248264e92` — テストフロー再設計（参照日 2026-05-13）
+- 一次資料: Cucumber / Gherkin（Given-When-Then 構文の標準化）、BDD（Behavior-Driven Development）

package/package-templates/docs/philosophy/qa-techniques.md

@@ -0,0 +1,235 @@
+# QA 技法
+
+> **ステータス**: Draft v0.1（Phase 1 dogfooding 後に改訂予定）
+
+## このファイルの守備範囲
+
+「何をテストすべきか」を漏れなく導き出すための観点設計の体系（同値分割・境界値分析・デシジョンテーブル・状態遷移テスト・エラー推測・チェックリストベースドテスト）を扱う。
+
+これらの観点を「名」に変換するのは [`formal-name-match.md`](./formal-name-match.md)、観点を Given-When-Then で記述するのは [`given-when-then.md`](./given-when-then.md)、各層（Unit / Integration / E2E / DB-RLS）にどの技法を適用するかは [`test-pyramid.md`](./test-pyramid.md) を参照。
+
+## 概念定義
+
+QA 技法は、**「何をテストすべきか」を漏れなく導き出すための観点設計の体系**。テストコードを書く技術ではなく、**テストケースを設計する技術**。
+
+AI 駆動開発では「テストを書いて」と依頼すると正常系中心の薄いテストになりがち。AI に明示的に観点を渡すことで、境界条件・条件組み合わせ・状態遷移・例外系の網羅性が上がる。
+
+QA 技法は形名参同の「名」（成功基準）に含めるべきテスト観点を漏れなく抽出する道具。
+
+## 1. 同値分割
+
+入力空間を「同じ振る舞いをする値のグループ」に分け、各グループから 1 つだけ代表値を選ぶ技法。
+
+### 例: 「人数は 1〜4 名まで」というバリデーション
+- グループ A: 0 以下 → 無効
+- グループ B: 1〜4 → 有効
+- グループ C: 5 以上 → 無効
+
+3 グループ × 各 1 代表 = 3 テストケースで十分。100 件テストする必要はない。
+
+### 効果
+- 無駄なテストを減らす
+- 抜けを防ぐ（各グループ最低 1 件）
+
+### AI 指示プロンプト
+```
+このバリデーション（1〜4 名）について、同値分割で 3 グループに分け、
+各グループの代表値を 1 つずつ選んでテストケースを作成してください。
+```
+
+## 2. 境界値分析
+
+同値分割で分けたグループの**境目**を狙う技法。`>=` と `>`、`<=` と `<` の取り違えが境界で発生しやすい。
+
+### 例: 「人数は 1〜4 名まで」
+特に見るべき値: 0, 1, 4, 5
+
+- 0: 無効（下限の 1 つ外）
+- 1: 有効（下限）
+- 4: 有効（上限）
+- 5: 無効（上限の 1 つ外）
+
+AI が生成した実装でも、「1 以上」を `> 1` と書いてしまうケースが頻発する。境界値テストはこの種のバグを直接突く。
+
+### AI 指示プロンプト
+```
+このバリデーションのテストを追加してください。
+特に境界値として 0, 1, 4, 5 を必ず含めてください。
+これは「>= 1」と「> 0」、「<= 4」と「< 5」の取り違えを検出するためです。
+```
+
+## 3. デシジョンテーブル
+
+複数条件の組み合わせ漏れを防ぐ技法。表で全パターンを列挙し、各組み合わせの期待結果を明示する。
+
+### 例: 「通知メール送信条件」
+3 条件: イベント発生 / 通知 ON / メール登録あり
+
+| イベント発生 | 通知 ON | メール登録 | 結果 |
+|---|---|---|---|
+| Yes | Yes | Yes | 送信 |
+| Yes | Yes | No | 送信しない |
+| Yes | No | Yes | 送信しない |
+| No | Yes | Yes | 送信しない |
+| Yes | No | No | 送信しない |
+| No | Yes | No | 送信しない |
+| No | No | Yes | 送信しない |
+| No | No | No | 送信しない |
+
+3 条件 × 2 = 8 パターンを表で網羅。AI に「全パターン書いて」と依頼すれば漏れにくい。
+
+### AI 指示プロンプト
+```
+以下の仕様について、先にデシジョンテーブルを作成してください。
+3 条件の全 8 パターンを列挙し、各組み合わせの期待結果を明示してください。
+その後、各パターンに対応するテストケースを作成してください。
+```
+
+### 縮約
+
+条件数が多いと組み合わせが爆発する（4 条件 = 16 行、5 条件 = 32 行）。
+- 同じ結果の行は省略可（「他の条件が No なら結果も No」等）
+- 4 条件以上は仕様自体の見直し検討
+
+## 4. 状態遷移テスト
+
+状態を持つ機能で、「どの状態からどの状態へ遷移できるか」を検証する技法。
+
+### 例: 注文ステータス
+状態: pending / confirmed / shipped / delivered / cancelled
+
+許可される遷移:
+- pending → confirmed
+- confirmed → shipped
+- shipped → delivered
+- pending / confirmed → cancelled
+
+禁止される遷移（明示的にテスト）:
+- delivered → pending（巻き戻し）
+- cancelled → confirmed（キャンセル取り消し）
+- pending → shipped（confirmed をスキップ）
+
+不正遷移のテストが**特に重要**。AI は許可遷移だけテストしがちなので、明示する。
+
+### AI 指示プロンプト
+```
+注文ステータスの状態遷移について、先に遷移表を作成してください。
+許可される遷移と禁止される遷移を分け、両方をテストしてください。
+特に禁止される遷移が API 層で拒否されることを確認してください。
+```
+
+## 5. エラー推測
+
+過去の障害や運用知見から「ここは壊れやすい」と予測してテストする技法。経験ベース。
+
+### 実務で危ない例
+- 二重送信（「保存」連打）
+- 戻る操作後の再送信
+- タイムゾーン差分（UTC vs ローカル）
+- 空文字と null の混在
+- 全角半角混在（メールアドレス、電話番号）
+- 権限の抜け道（フロントで隠しただけで API は素通り）
+- 通信失敗時の中途半端な状態（「成功」表示なのに DB 未反映）
+- ロケール依存（日本語 / 英語 / 多言語）
+- 文字数上限の取り違え（バイト数 vs 文字数 vs Unicode コードポイント）
+- 並行リクエストでのレース（同じユーザーが 2 タブで操作）
+- 大量データでの性能劣化（1 万件以上のリスト）
+
+### AI 指示プロンプト
+```
+以下の機能について、エラー推測ベースで「壊れやすそうな点」を 5 件以上挙げてください。
+過去のソフトウェア障害でよくあるパターンを参考にしてください。
+その後、各点に対応するテストを作成してください。
+```
+
+これは経験ベースなので、組織で**過去障害知見をチェックリスト化**して AI に渡すと効く。
+失敗パターンは [`sage/failures.md`](../../../sage/failures.md) に蓄積する運用と相性がよい。
+
+## 6. チェックリストベースドテスト
+
+よく使う観点を**事前にチェックリスト化**しておき、毎回機械的に適用する技法。
+
+### 画面実装の標準チェックリスト
+- [ ] 正常系は動くか
+- [ ] バリデーションエラーが表示されるか
+- [ ] ローディング中に二重送信できないか
+- [ ] 権限がないユーザーに操作が見えないか
+- [ ] API 失敗時に UI が壊れないか
+- [ ] 成功表示と実データが一致するか
+- [ ] モバイル表示で崩れないか
+- [ ] console error が出ていないか
+- [ ] 戻る操作で状態が壊れないか
+- [ ] 空データ / 多量データで表示が崩れないか
+
+### API 実装の標準チェックリスト
+- [ ] 認証なしで 401 / 403
+- [ ] 権限不足で 403
+- [ ] 不正入力で 400 + エラーメッセージ
+- [ ] 存在しないリソースで 404
+- [ ] 重複作成で 409
+- [ ] レート制限で 429
+- [ ] 内部エラーで 500（スタックトレース漏洩なし）
+- [ ] 別ユーザーのリソースを ID で指定して 403 / 404
+
+### AI 指示プロンプト
+```
+以下の <画面|API> 実装について、標準チェックリスト全項目を順に検証するテストを作成してください。
+チェックリストは以下です:
+- <チェックリスト貼付>
+各項目で 1 テストケース以上書いてください。
+```
+
+## AI へのテスト依頼の型
+
+### 悪い依頼
+```
+この機能のテストを書いてください。
+```
+→ 正常系中心の薄いテストになる。
+
+### 少し良い依頼
+```
+この機能のテストを追加してください。
+同値分割、境界値分析、条件組み合わせ、状態遷移、null/空文字を含めてください。
+```
+→ 観点は広がるが、何を網羅するか不明瞭。
+
+### さらに良い依頼
+```
+この仕様について、以下を先に列挙してください。
+
+1. 同値分割（入力グループ分け）
+2. 境界値（各境目の値）
+3. デシジョンテーブル（条件組み合わせの全パターン）
+4. 状態遷移表（許可・禁止両方）
+5. エラー推測（壊れやすそうな点）
+
+その結果をもとにテストコードを作成してください。
+各テストケースが上記のどれに対応するかを明記してください。
+```
+→ 観点設計 → テスト生成 の 2 段階で漏れにくい。
+
+## 形名参同との関係
+
+QA 技法は形名参同の「名」を漏れなく構成するための観点リスト。
+
+- **同値分割** → 「名」を不要な重複なく列挙
+- **境界値** → 「名」に境目の値を漏らさない
+- **デシジョンテーブル** → 「名」に条件組み合わせを漏らさない
+- **状態遷移** → 「名」に不正遷移の拒否を含める
+- **エラー推測** → 「名」に運用上の事故パターンを含める
+- **チェックリスト** → 「名」を標準化して属人化を防ぐ
+
+QA 技法で導いた観点を [`given-when-then.md`](./given-when-then.md) の GWT 構文で書き、[`formal-name-match.md`](./formal-name-match.md) の形名照合ループで検証する。
+
+## 隣接する思想との関係
+
+- [`formal-name-match.md`](./formal-name-match.md) — QA 技法で導いた観点を「名」に変換し、実装後に「形」と照合
+- [`test-pyramid.md`](./test-pyramid.md) — 各 QA 技法を Unit / Integration / E2E / DB-RLS のどの層で適用するか
+- [`given-when-then.md`](./given-when-then.md) — QA 技法で導いた観点を Given-When-Then で記述する
+
+## 出典
+
+- Notion ページ: `dc8774cd03c8490688b066c2b0179cac` — AI 駆動開発時代に押さえる QA 技法（参照日 2026-05-13）
+- 元記事: Zenn「AI 駆動開発時代に、おさえておきたい QA 技法」
+- 一次資料: ISTQB Foundation Level Syllabus（同値分割・境界値・デシジョンテーブル・状態遷移）

package/package-templates/docs/philosophy/test-pyramid.md

@@ -0,0 +1,171 @@
+# テストピラミッド（責務分割）
+
+> **ステータス**: Draft v0.1（Phase 1 dogfooding 後に改訂予定）
+
+## このファイルの守備範囲
+
+テストを Static / Unit / Integration / E2E / DB-RLS / Monitoring の 6 層に分け、各層の責務と適切な量を定義する。E2E 偏重の弊害と、責務分割による解消を扱う。
+
+各層の「名」（成功基準）の照合は [`formal-name-match.md`](./formal-name-match.md)、各層に書くべき観点の抽出は [`qa-techniques.md`](./qa-techniques.md)、各層のケースを Given-When-Then で記述する方法は [`given-when-then.md`](./given-when-then.md) を参照。
+
+## 概念定義
+
+テストピラミッドは、**テストを責務別の層に分け、各層に適切な量・実行頻度・期待を割り当てる**設計思想。
+
+AI 駆動開発では「安心したいから E2E を増やす」傾向があるが、E2E が肥大化すると以下が起きる:
+
+- CI 時間が増えてフィードバックが遅くなる
+- flaky（不安定）テストで開発者が信頼しなくなる
+- 失敗時の原因特定が重くなる
+- 1 件の修正に対するメンテコストが上がる
+
+そのため、E2E の量は最小化し、**より下位の層（Static / Unit / Integration）で先に問題を捕まえる**設計が良い。
+
+「形名参同」の「名」（成功基準）を、各層でどう定義するかが本ドキュメントの主題。
+
+## 各層の定義
+
+### 1. Static check（最下層）
+
+プログラムを実行せず、ソースコードの静的解析で検出できる問題を扱う。
+
+- 型チェック（TypeScript の `tsc --noEmit`、Go の `go vet`、Rust の `cargo check` 等）
+- lint（ESLint / oxlint / Biome / Ruff 等）
+- 未使用コード検出（Knip / depcheck 等）
+- フォーマットチェック（Prettier / gofmt 等）
+
+実行コストは最も低く、フィードバックは最も速い。AI 駆動開発では実装直後の **fast loop** に必ず含める。
+
+### 2. Unit test
+
+純粋関数・モジュール単体の振る舞いを検証する。外部 I/O（ネットワーク / DB / ファイル / 時刻）に依存しない。
+
+- バリデーションロジック
+- 変換関数（時刻フォーマット、文字列変換等）
+- 状態遷移計算（reducer / state machine）
+- ドメインロジック（料金計算、権限判定等）
+
+実行は数 ms〜数百 ms。多数あっても CI を遅らせない。**最も多くのテストを書くべき層**。
+
+### 3. Integration test
+
+複数モジュールやレイヤをまたぐ結合動作を検証する。外部依存はモック化または local 実体を使う。
+
+- フォームのバリデーション + 送信フロー（UI + API）
+- API ハンドラー + DB（in-memory or local container）
+- 認可ロジック + ユーザー状態の組み合わせ
+- 画面表示と API 結果の整合
+
+実行コストは中程度。Unit よりは少なく、E2E よりは多く書く。
+
+### 4. E2E test
+
+実ブラウザまたは実環境で、エンドユーザー目線の重要導線を検証する。
+
+- サインアップ → ログイン → 主要機能利用
+- 決済フロー
+- 認証フロー（外部 IdP との連携を含む場合）
+
+実行コストは高い（数秒〜数十秒）。flaky 化しやすい。**事業上壊れたら致命的な導線のみ**に絞る。
+
+### 5. DB-RLS test
+
+データベース層、特に Row Level Security や権限制御を検証する。
+
+- 他人のデータが見えないこと（RLS）
+- 権限がないユーザーが書き込めないこと
+- 制約・トリガー・関数の動作
+
+専用ツール（pgTAP 等）を使うことが多い。SQL レベルで検証する。AI に「フロントで隠したから OK」と判断させないために**サーバー側のテストが必須**。
+
+### 6. Monitoring（本番）
+
+本番環境で再現困難な不具合を検知する。
+
+- エラーレート / レイテンシのアラート
+- セッションリプレイ
+- ヘルスチェック / 合成監視（Synthetic Monitoring）
+
+「テスト」ではないが、品質保証の連続体として扱う。本番で初めて発覚する問題は、次回のテスト設計にフィードバックする。
+
+## 責務分割表
+
+| 層 | 検証対象 | 実行頻度 | テスト数 | flake 許容 | 代表ツール例 |
+|---|---|---|---|---|---|
+| Static | 型・lint・未使用 | 毎保存 / pre-commit | - | なし | typecheck / lint / unused-detector |
+| Unit | 純粋ロジック | 毎保存 / CI | 多 | なし | unit test runner |
+| Integration | モジュール結合 | CI | 中 | 小 | test runner + testing-library |
+| E2E | 主要導線 | CI（smoke は PR、full は nightly 等） | 少 | 小 | browser automation |
+| DB-RLS | 権限境界 | CI | 中 | なし | SQL test framework |
+| Monitoring | 本番異常 | 常時 | - | - | APM / synthetic / error tracker |
+
+層を上に進むほど、コストが上がり、量が減る。これがピラミッドの形になる理由。
+
+## よくある失敗
+
+- **E2E 過多**: 安心感のために E2E を増やし、CI が 30 分超かかるようになる
+- **Unit 過少**: 純粋関数を E2E で検証してしまう
+- **DB-RLS 未検証**: フロントの表示制御だけで満足し、API 直叩きで漏洩
+- **Monitoring 設定漏れ**: 本番デプロイ後の異常検知がなく、ユーザー報告で気づく
+- **層を混ぜる**: 1 つのテストが「Unit + Integration + E2E」を兼ねて、失敗原因が不明
+- **責務外のテスト**: Static で検出すべき型エラーを Unit テストで catch しようとする
+- **flaky を放置**: 不安定 E2E を retry で誤魔化し、本物の障害を見逃す
+- **テストを実装の鏡にする**: 仕様ではなく実装をテストして、リファクタで全部壊れる
+
+## AI 駆動開発での適用
+
+AI に「テストを書いて」と言うと、無意識に E2E や Integration に寄りがち。**責務を明示して指示**する。
+
+### Unit を書かせる指示
+```
+このテストは Unit テストです。
+- 外部依存（DB / API / 時刻）はモック化または注入
+- 純粋関数として振る舞いを検証
+- 1 ケース 1 アサート
+- 同値分割と境界値を含める
+```
+
+### E2E を書かせる指示
+```
+このテストは E2E です。
+- 実ブラウザで操作
+- API 失敗時の表示、二重送信防止、戻る操作を含める
+- 主要導線（ログイン → 機能 X 利用）のみ
+- 副次的なバリエーションは E2E で扱わず Integration へ
+```
+
+### DB-RLS を書かせる指示
+```
+DB-RLS テストです。
+- SQL level でテストを書く
+- 他人のデータが見えないこと、書けないことの両方を検証
+- role / user_id / tenant_id 等の境界を網羅
+- 「フロントで弾いている」を理由に省略しない
+```
+
+## 形名参同との関係
+
+各層の「名」（成功基準）の典型:
+
+| 層 | 「名」の例 |
+|---|---|
+| Static | 型エラー 0、lint エラー 0、未使用 export 0 |
+| Unit | 全テスト pass、カバレッジ 80%+（または閾値） |
+| Integration | 主要結合シナリオの正常系・異常系の pass |
+| E2E | 主要導線の smoke test pass |
+| DB-RLS | 権限テスト全 pass、拒否ケース全カバー |
+| Monitoring | エラーレート < 0.1%、p95 レイテンシ < SLO |
+
+これらを「形」（実測値）と照合するのが [`formal-name-match.md`](./formal-name-match.md) の役割。
+
+## 隣接する思想との関係
+
+- [`formal-name-match.md`](./formal-name-match.md) — 各層で測定する「形」を「名」と照合する仕組み（形名参同）
+- [`given-when-then.md`](./given-when-then.md) — 各層のテストケースを Given-When-Then で記述する方法
+- [`qa-techniques.md`](./qa-techniques.md) — 各層に適用すべき QA 技法（境界値・状態遷移等）
+
+## 出典
+
+- Notion ページ: `35b68c677f4380bfa1ffeab248264e92` — テストフロー再設計（参照日 2026-05-13）
+- 一次資料: The Practical Test Pyramid（Martin Fowler）、Testing Trophy（Kent C. Dodds）
+- DB-RLS 層の補強: Supabase Testing Overview 公式ドキュメント（pgTAP 等の SQL レベル検証手段）。具体の pgTAP / InBucket テンプレートは `supabase-rls` プロファイル系の別 SPEC で扱う