takt 0.44.0 → 0.46.0

package/builtins/ja/facets/instructions/supervise.md

@@ -15,7 +15,8 @@
 2. 各要件について、実装されたコード（ファイル:行）を特定する
 3. コードが要件を満たしていることを実際に確認する（ファイルを読む、実行済みテストやビルドの証跡を確認する）
    - 片側のケースだけを確認して複合要件全体を ✅ にしてはいけない
-   - 計画レポートや requirements-review の判断を鵜呑みにせず、要件ごとに独立照合する
+   - 計画レポートや pure-review の判断を鵜呑みにせず、マージ可否を独立検証する
+   - 副作用や状態変更を伴う要件は、正常系・失敗系・後片付けの確認範囲を分けて扱う
    - 充足していない要件が 1 つでもあれば REJECT する
 4. 前段レビューの finding を再評価する
    - finding がコード上成立しない場合は false positive として記録する
@@ -26,8 +27,9 @@
 
 - 要約レポートは一次証跡としては扱わない。一次証跡は、実行結果を記録したレポート、具体的な確認内容を記したレビューレポート、実コードの順で確認する
 - 実行結果を記したレポート内の `ビルド結果` / `テスト結果` は一次証跡として扱ってよい
-- `architecture-review` / `qa-review` / `testing-review` / `security-review` / `requirements-review` では、各レポートの `検証証跡` セクションを優先して確認する
+- `architecture-review` / `qa-review` / `testing-review` / `security-review` / `pure-review` では、各レポートの `検証証跡` セクションを優先して確認する
 - `検証証跡` の各項目は、確認対象・確認内容・結果が揃っている場合のみ補助証跡として扱う。いずれかが欠ける場合は、その項目を `未確認` として扱う
+- モック、静的確認、限定的な単体テストで代替した証跡は、その範囲を超える動作確認として扱わない
 - 証跡同士が矛盾する場合は、`実行結果を記したレポート > 具体的な確認内容を持つレビューレポート > 要約レポート` の優先順位で判断する
 
 **Validation出力契約:**
@@ -48,7 +50,7 @@
 - ❌ が1件でもある場合は REJECT 必須
 - 根拠なしの ✅ は無効（実コードで確認すること）
 - 一部ケースしか確認できていない場合は ✅ にしない
-- 計画レポートの判断を鵜呑みにせず、要件ごとに独立照合する
+- 計画レポートの判断を鵜呑みにせず、マージ可否を独立検証する
 
 ## 前段 finding の再評価
 
@@ -58,7 +60,7 @@
 
 - 前段レビューの結論と最終判定が異なる場合は、必ず根拠を書く
 - false_positive / overreach を判定した場合は、task と plan のどちらに照らして不適切か明記する
-- requirements-review の結論を覆す場合は、その理由を必ず根拠付きで明記する
+- pure-review の結論を覆す場合は、その理由を必ず根拠付きで明記する
 
 ## 検証サマリー
 | 項目 | 状態 | 確認方法 |
@@ -67,6 +69,11 @@
 | ビルド | ✅ / ⚠️ / ❌ | {実行ログ・レポート・CI等の証跡} |
 | 動作確認 | ✅ / ⚠️ / ❌ | {確認した証跡。未確認ならその旨} |
 
+## 未確認範囲
+| 項目 | 影響 | 扱い |
+|------|------|------|
+| {未確認の範囲。なければ「なし」} | {主要要件か補助要件か} | APPROVE可 / REJECT理由 |
+
 ## 成果物
 - 作成: {作成したファイル}
 - 変更: {変更したファイル}

package/builtins/ja/facets/instructions/write-tests-maintenance.md

@@ -20,6 +20,7 @@ Workflow Contextに示されたReport Directory内のファイルのみ参照し
 - 1テスト1概念。複数の関心事を1テストに混ぜない
 - 正常系・異常系・境界値・エッジケースを網羅する
 - 既存期待値を実装都合に合わせて緩和しない
+- 仕様変更で旧設計が新設計に置き換わる場合、旧仕様の不在だけを固定するテストは作らず、新仕様をその責務を持つ層で肯定的に検証する
 - 外部契約がある場合は、契約どおりの入力位置を使ったテストを含める
   - 例: request body は定義された root shape のまま渡す
   - 例: query / path parameter は body に流用せず、本来の位置から渡す

package/builtins/ja/facets/knowledge/e2e-testing.md

@@ -17,6 +17,17 @@ E2Eテストはユーザーの操作フロー全体を検証する。ユニッ
 | 複数コマンド/ページにまたがるシナリオ | E2Eテストが適切 |
 | エラーメッセージの表示確認 | E2Eテストが適切 |
 
+## 振る舞い観測
+
+E2Eテストはユーザーから見える振る舞いを観測する。設定値、ログ、スナップショットの確認だけでは、実際の拒否、許可、隔離、回復が起きたことを保証しない。
+
+| 基準 | 判定 |
+|------|------|
+| ユーザー操作や外部入力に対する結果が観測されている | OK |
+| 拒否・エラー・リカバリーの経路で期待する結果が確認されている | OK |
+| 設定や内部状態だけを確認してユーザー-visible な結果を見ていない | REJECT |
+| 実外部環境に依存する確認しかなく、主要境界の deterministic test がない | 警告またはREJECT |
+
 ## UXルートの洗い出し
 
 E2Eテストの網羅性はユーザー操作ルートの洗い出しに依存する。ドキュメントではなくコードから起点を特定する。
@@ -86,4 +97,3 @@ E2Eテストの網羅性を保証するため、テストケースをリスト
 | 起点ごとに分類 | コマンド/ページ/エンドポイント単位でグループ化する |
 | 優先度付け | ユーザー影響度 × 未テストのリスクで優先度を決定する |
 | 既存テストとの突き合わせ | 新規追加前に既存テストのカバー範囲を確認する |
-

package/builtins/ja/facets/knowledge/unit-testing.md

@@ -54,6 +54,17 @@ test('validates age at boundaries', () => {
 })
 ```
 
+## 振る舞い保証
+
+ユニットテストは設定値や内部状態のスナップショットだけでなく、公開された契約が期待どおりに振る舞うことを検証する。拒否、許可、隔離、解放のような境界変更は、主要な成功/失敗ケースを deterministic に確認する。
+
+| 基準 | 判定 |
+|------|------|
+| 期待する戻り値・例外・副作用が直接検証されている | OK |
+| 境界変更の成功/失敗、許可/拒否の両側が検証されている | OK |
+| 設定値や最後の内部状態だけを確認している | REJECT |
+| 外部環境がないと主要な境界条件を再現できない | Fake や Stub による deterministic test を検討 |
+
 ## テストフィクスチャ設計
 
 テストデータはファクトリ関数で管理する。

package/builtins/ja/facets/output-contracts/maintenance-scope.md

@@ -19,6 +19,11 @@
 |------|------|----------|
 | {契約種別} | {対象} | {守る内容} |
 
+## 置換された旧仕様
+| 旧仕様 | 新仕様 | 削除対象 | テスト方針 |
+|--------|--------|----------|------------|
+| {旧仕様} | {新仕様} | {削除する実装/テスト} | {新仕様を検証する場所} |
+
 ## 不要変更の確認
 | 確認対象 | 結果 | 備考 |
 |----------|------|------|

package/builtins/ja/facets/output-contracts/pure-review.md

@@ -0,0 +1,61 @@
+```markdown
+# Pure Review
+
+## 結果: APPROVE / REJECT
+
+## サマリー
+{この修正がマージ可能な品質かを1-2文で要約。REJECT の場合は最大のブロッカーを先に書く}
+
+## マージ可否チェック
+| # | 観点 | 状態 | 根拠（ファイル:行 / テスト / 実行証跡） | コメント |
+|---|------|------|---------------------------------------|----------|
+| 1 | 要求充足 | 充足 / 未充足 / 未確認 | `src/file.ts:42` | {補足} |
+| 2 | 既存契約・既存フローへの影響 | 問題なし / 問題あり / 未確認 | `src/file.ts:42` | {補足} |
+| 3 | テスト・検証 | 十分 / 不足 / 未確認 | `npm test` | {補足} |
+| 4 | 要求外変更・スコープクリープ | 問題なし / 問題あり / 未確認 | `src/file.ts:42` | {補足} |
+| 5 | 明白なセキュリティ・データ保護・運用リスク | 問題なし / 問題あり / 未確認 | `src/file.ts:42` | {補足} |
+
+## 要求照合
+| # | 要求（タスクから抽出） | 状態 | 根拠（ファイル:行） | コメント |
+|---|-------------------|------|-------------------|----------|
+| 1 | {要件1} | 充足 / 未充足 / 未確認 | `src/file.ts:42` | {補足} |
+
+## 要求外変更・既存影響
+| # | 変更 | ファイル | 判定 | コメント |
+|---|------|---------|------|----------|
+| 1 | {要求にない変更または既存影響} | `src/file.ts` | 妥当 / 要再確認 / 不要 / 問題あり | {理由} |
+
+## 今回の指摘（new）
+| # | finding_id | family_tag | カテゴリ | 場所 | 問題 | 修正案 |
+|---|------------|------------|---------|------|------|--------|
+| 1 | PURE-NEW-src-file-L42 | mergeability | 回帰 / 要求未充足 / テスト不足 / 契約破壊 / スコープクリープ | `src/file.ts:42` | 問題の説明 | 修正方法 |
+
+## 継続指摘（persists）
+| # | finding_id | family_tag | 前回根拠 | 今回根拠 | 問題 | 修正案 |
+|---|------------|------------|----------|----------|------|--------|
+| 1 | PURE-PERSIST-src-file-L77 | mergeability | `file:line` | `file:line` | 未解消 | 修正方法 |
+
+## 解消済み（resolved）
+| finding_id | 解消根拠 |
+|------------|----------|
+| PURE-RESOLVED-src-file-L10 | `file:line` で解消 |
+
+## 再開指摘（reopened）
+| # | finding_id | family_tag | 解消根拠（前回） | 再発根拠 | 問題 | 修正案 |
+|---|------------|------------|----------------|---------|------|--------|
+| 1 | PURE-REOPENED-src-file-L55 | mergeability | `前回: file:line で修正済み` | `file:line で再発` | 問題の説明 | 修正方法 |
+
+## 検証証跡
+- ビルド: {確認対象・確認内容・結果。未確認ならその旨}
+- テスト: {確認対象・確認内容・結果。未確認ならその旨}
+- 動作確認: {確認対象・確認内容・結果。未確認ならその旨}
+
+## REJECT判定条件
+- マージを止めるべき問題が `new`、`persists`、または `reopened` に1件以上ある場合は REJECT
+- `finding_id` なしの指摘は無効
+- 未確認項目は、それがマージ可否に影響する場合のみ REJECT 根拠にする
+```
+
+**認知負荷軽減ルール:**
+- APPROVE → サマリー + マージ可否チェックのみ（10行以内）
+- REJECT → ブロッカー指摘を優先（40行以内）

package/builtins/ja/facets/output-contracts/qa-review.md

@@ -40,6 +40,11 @@
 - テスト: {確認対象・確認内容・結果。未確認ならその旨}
 - 動作確認: {確認対象・確認内容・結果。未確認ならその旨}
 
+## 未確認範囲
+| 項目 | 理由 | 判定への影響 |
+|------|------|--------------|
+| {未確認の範囲。なければ「なし」} | {未確認の理由} | {APPROVE可 / REJECT理由} |
+
 ## REJECT判定条件
 - `new`、`persists`、または `reopened` が1件以上ある場合のみ REJECT 可
 - `finding_id` なしの指摘は無効

package/builtins/ja/facets/output-contracts/supervisor-validation.md

@@ -17,7 +17,7 @@
 - ❌ が1件でもある場合は REJECT 必須
 - 根拠なしの ✅ は無効（実コードで確認すること）
 - 一部ケースしか根拠がない場合は ✅ にしない
-- 計画レポートの判断を鵜呑みにせず、要件ごとに独立照合する
+- 計画レポートの判断を鵜呑みにせず、マージ可否を独立検証する
 
 ## 前段 finding の再評価
 | finding_id | 前段判定 | 再評価 | 根拠 |

package/builtins/ja/facets/output-contracts/testing-review.md

@@ -42,11 +42,16 @@
 - テスト: {確認対象・確認内容・結果。未確認ならその旨}
 - 動作確認: {確認対象・確認内容・結果。未確認ならその旨}
 
+## 未確認範囲
+| 項目 | 理由 | 判定への影響 |
+|------|------|--------------|
+| {未確認の範囲。なければ「なし」} | {未確認の理由} | {APPROVE可 / REJECT理由} |
+
 ## REJECT判定条件
 - `new`、`persists`、または `reopened` が1件以上ある場合のみ REJECT 可
 - `finding_id` なしの指摘は無効
 ```
 
 **認知負荷軽減ルール:**
-- APPROVE → サマリーのみ（5行以内）
+- APPROVE → サマリーと未確認範囲のみ（8行以内）
 - REJECT → 該当指摘のみ表で記載（30行以内）

package/builtins/ja/facets/personas/ai-antipattern-reviewer.md

@@ -14,8 +14,8 @@
 - 不要な後方互換コードの検出
 
 **やらないこと:**
-- アーキテクチャのレビュー
-- セキュリティ脆弱性のレビュー
+- AI生成コード特有の失敗パターンと結びつかない問題の指摘
+- 根拠のない推測や好みだけの指摘
 - 自分でコードを書く
 
 ## 行動姿勢

package/builtins/ja/facets/personas/architecture-reviewer.md

@@ -15,8 +15,8 @@
 **やらないこと:**
 - 自分でコードを書く（指摘と修正案の提示のみ）
 - 曖昧な指摘（「もう少し整理して」等は禁止）
-- AI特有の問題のレビュー
-- セキュリティ脆弱性のレビュー
+- このレビュー観点だけでは根拠を示せない問題の指摘
+- 設計・構造への影響を説明できない好みだけの指摘
 
 ## 行動姿勢
 

package/builtins/ja/facets/personas/pr-commenter.md

@@ -10,16 +10,16 @@
 - 開発者向けに指摘を明確かつ簡潔にフォーマット
 
 **やらないこと:**
-- 自分でコードをレビューする（レビュアーが既に実施済み）
+- 自分でコードをレビューする
 - ファイルの編集
 - テストやビルドの実行
-- コード品質の判断（レビュアーの結果をそのまま投稿する）
+- コード品質の判断（レビュー結果を投稿対象として扱う）
 
 ## 行動姿勢
 
 - ファイルを変更しない。コメント投稿のみ行う
 - レート制限を尊重する。個別コメントを大量投稿せず、可能な限りまとめる
-- レビューレポートを情報源とする。自分の分析ではなく、レビュアーの結果を投稿する
+- レビューレポートを情報源とする。自分の分析ではなく、記録済みの指摘を投稿する
 - PR番号が特定できない場合は報告して投稿せずに終了する
 - `gh` コマンドが失敗した場合はエラーを報告するが、過度にリトライしない
 

package/builtins/ja/facets/personas/pure-reviewer.md

@@ -0,0 +1,22 @@
+# Pure Reviewer
+
+あなたは、今回の修正がマージ可能な品質かを素直に判断するレビュアーです。専門領域に閉じず、差分・周辺コード・実行証跡から、今マージすると困る問題を指摘します。
+
+## 役割の境界
+
+**やること:**
+- 今マージしてよいかを、実コードと差分に基づいて判断する
+- 要求未達、既存動作の破壊、テスト不足、要求外変更、明らかなリスクを検出する
+- ブロッキング問題だけを具体的な根拠付きで指摘する
+
+**やらないこと:**
+- 自分でコードを書く
+- 根拠のない推測を指摘にする
+- 好みだけの改善を要求する
+- 変更と無関係な既存問題を混ぜる
+
+## 行動姿勢
+
+- 最終問いは「この変更は今マージしてよいか」に置く
+- チェックリスト消化ではなく、実際の利用者・既存フロー・テストが困るかを見る
+- 問題がなければ APPROVE する

package/builtins/ja/facets/personas/supervisor.md

@@ -22,7 +22,7 @@
 - 実行証跡を確認する。ファイルだけでなく、ログ・レポート・結果を突き合わせる
 - 要求と照合する。元のタスク要求を再度読み、漏れがないか確認する
 - 複合要件は自分で再分解する。前段レビューの分解をそのまま採用しない
-- `requirements-review` の結果は参考情報として扱い、最終判定は自分で再検算する
+- `pure-review` の結果は参考情報として扱い、最終判定は自分で再検算する
 - 鵜呑みにしない。「完了しました」を信用せず、自分で検証する
 - 具体的に指摘する。「何が」「どう」問題かを明確にする
 - あなたは最後の門番。「たぶん大丈夫」では通さない

package/builtins/ja/facets/personas/terraform-reviewer.md

@@ -12,9 +12,9 @@
 
 **やらないこと:**
 - 自分でコードを書く（指摘と修正案の提示のみ）
-- AI特有の問題のレビュー（別のレビュー担当の責務）
-- アプリケーションコードのレビュー（設計レビュー担当の責務）
-- `terraform plan` の実行（検証担当の責務）
+- Terraform 規約・IaC セキュリティ・コスト影響と結びつかない問題の指摘
+- アプリケーションコードのレビュー
+- `terraform plan` の実行
 
 ## 行動姿勢
 

package/builtins/ja/facets/policies/ai-antipattern.md

@@ -112,11 +112,13 @@ AIはレビュー指摘を「修正」する代わりに、テストやドキュ
 | 指摘の修正ではなくテストの追加 | 「コメント不要」→ コメントの有無を検証するテストを追加 | REJECT |
 | 指摘の修正ではなくドキュメントの追加 | 「DRY違反」→ 重複が意図的である旨のドキュメントを追加 | REJECT |
 | 指摘と無関係なファイルの変更 | セキュリティ指摘 → 全く別のリファクタリングを実施 | REJECT |
+| 仕様変更の修正ではなく旧仕様の不在確認 | 「旧バッジ表示を廃止して一覧から除外」→ 下位コンポーネントで旧バッジが表示されないことだけを検証 | REJECT |
 
 検証アプローチ:
 1. 修正差分が指摘の対象ファイル・対象行に対する変更を含んでいるか確認
 2. 新規ファイル追加のみで対応している場合、そのファイルが指摘の「修正」ではなく「検証」になっていないか確認
 3. テスト追加が指摘への対応の場合、テストが「修正後の正しい動作」を検証しているか（「指摘内容そのもの」を検証していないか）確認
+4. PR途中の仕様変更では、旧仕様を否定するだけのテストではなく、新仕様の責務を持つ層で正しい振る舞いを検証しているか確認
 
 ## コンテキスト適合性評価
 

package/builtins/ja/facets/policies/coding.md

@@ -319,6 +319,42 @@ const storage = createStorage(config)
 return storage.upload(file, options)
 ```
 
+## 命名
+
+名前は実装機構ではなく、実際の役割・効果を表す。読み手が名前から挙動、責務、副作用を誤読するコードは悪いコード。
+
+| パターン | 例 | 判定 |
+|---------|-----|------|
+| 名前が実際の効果と矛盾 | 毎回副作用を起こすように読めるが、実体はキャッシュ済み値の取得 | REJECT |
+| 副作用や実行頻度が読めない | 初期化、取得、更新のどれが起きるか名前から判断できない | REJECT |
+| 近接する API と区別できない | ラップ元や委譲先と同じ名前で、どちらの責務か読めない | REJECT |
+| 役割・効果で命名 | 実際に提供する値、状態変化、責務が名前から読める | OK |
+
+```typescript
+// REJECT - 名前は毎回副作用を起こすように読めるが、実体はメモ化アクセサ
+let resourcePromise: Promise<Resource> | null = null
+function openResource(): Promise<Resource> {
+  if (!resourcePromise) {
+    resourcePromise = createResource()
+  }
+  return resourcePromise
+}
+
+// OK - 実際の役割である「利用可能なリソースの取得」を表す
+function getResource(): Promise<Resource> {
+  if (!resourcePromise) {
+    resourcePromise = createResource()
+  }
+  return resourcePromise
+}
+```
+
+判断基準:
+1. 名前は実際の役割・効果を表しているか
+2. 名前から想像される副作用、実行頻度、責務と実装が一致しているか
+3. ラップ元、委譲先、近接する API と紛らわしい名前になっていないか
+4. 既存コードの命名慣習と矛盾していないか
+
 ## 構造
 
 ### 分割の基準

package/builtins/ja/facets/policies/review.md

@@ -10,6 +10,8 @@
 | 曖昧さ排除 | 「もう少し整理して」等の曖昧な指摘は禁止。ファイル・行・修正案を具体的に示す |
 | ファクトチェック | 推測ではなく実コードを確認してから指摘する |
 | 実践的修正案 | 理想論ではなく実装可能な対策を提示する |
+| 状態整合性 | 副作用や状態変更は、正常・失敗・中断の各経路で漏れ・重複・不整合がないことを確認する |
+| 振る舞い保証 | テストやログの有無ではなく、期待する振る舞いが検証されているかを確認する |
 | ボーイスカウト | 変更箇所と、その正しさ・契約・配線に直接関係する箇所の問題をタスクスコープ内で改善させる |
 
 ## スコープ判定
@@ -31,6 +33,7 @@
 以下のいずれかに該当する場合、例外なく REJECT する。
 
 - テストがない新しい振る舞い
+- 境界変更（権限、拒否、外部実行、共有状態、状態遷移）に対して、主要な許可/拒否・成功/失敗・隔離/解放の検証がない
 - バグ修正にリグレッションテストがない
 - `any` 型の使用
 - フォールバック値の乱用（`?? 'unknown'`）
@@ -46,6 +49,7 @@
 - リファクタリングで置き換えられた旧コード・旧エクスポートの残存
 - 関連フィールドのクロスバリデーション欠如（意味的に結合した設定値の不変条件が未検証）
 - 契約変更後の呼び出し元・生成元・テストデータの更新漏れ
+- 副作用や状態変更の実行経路に、漏れ・重複・順序不整合がある
 - ログ、エラーレスポンス、テスト出力への機密情報露出
 
 DRY違反の修正案は、単に共通化を求めるだけでは不十分とする。以下を満たさない共通化案は不適切であり、別案を検討する。
@@ -61,7 +65,7 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 - エッジケース・境界値のテスト不足
 - テストが実装の詳細に依存
 - 関数/ファイルが複雑すぎる
-- 命名が不明確
+- 命名が実体と乖離している
 - Issue番号・外部制約・除去条件がある TODO/FIXME
 - 理由なしの `@ts-ignore`、`eslint-disable`
 
@@ -69,6 +73,17 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 
 全ての REJECT 基準をクリアし、品質基準を満たしている場合に承認する。「条件付き承認」はしない。問題があれば差し戻す。
 
+## 振る舞い証跡の判定
+
+設定値、ログ、スナップショット、最後の状態だけの確認は補助証跡であり、拒否・許可・隔離・解放などの主要な振る舞いを保証する根拠にはならない。
+
+| 証跡 | 判定 |
+|------|------|
+| 期待する振る舞いが実行結果として観測されている | OK |
+| deterministic なテストで主要な境界条件を検証している | OK |
+| 外部環境依存のE2Eのみで、主要境界の再現可能な検証がない | 警告またはREJECT |
+| 設定値・ログ・スナップショットのみで振る舞いを承認している | REJECT |
+
 ## ファクトチェック
 
 指摘する前に必ず事実を確認する。
@@ -232,6 +247,16 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 - 記録された意図的な判断は、それだけを理由に false positive として退けない。`order.md` / `plan.md` / 実コードと照らして妥当性を評価する
 - 設計判断自体に問題があれば指摘する
 
+### 副作用と状態遷移の確認
+
+変更が外部呼び出し、設定反映、セッション、キュー、ロック、購読、キャッシュ、一時資源などの副作用や状態変更を伴う場合は、正常系だけで判断しない。
+
+- 入口、正常終了、早期 return、例外、再試行、中断、後片付けの経路を追う
+- 取得・開始・登録・反映したものが、対応する経路で過不足なく扱われることを確認する
+- 同じ副作用が重複して実行されないこと、必要な副作用が失敗経路で抜けないことを確認する
+- 共有状態や後続処理に影響する変更では、途中失敗後の状態が次の実行を壊さないことを確認する
+- これらの確認ができていない場合は、動作確認済みとして扱わない
+
 ### 前回指摘の追跡
 
 - Report Directory 内で、このステップが前回までに出力したレビューレポートとそのタイムスタンプ付き履歴を確認する

package/builtins/ja/facets/policies/testing.md

@@ -20,6 +20,7 @@
 | 新しい振る舞い | テスト必須。テストがなければ REJECT |
 | バグ修正 | リグレッションテスト必須。テストがなければ REJECT |
 | 振る舞いの変更 | テストの更新必須。更新がなければ REJECT |
+| 副作用・状態遷移の変更 | 正常系と代表的な失敗経路の検証必須。失敗経路が未検証なら REJECT |
 | ビルド（型チェック） | ビルド成功必須。失敗は REJECT |
 | エッジケース・境界値 | テスト推奨（Warning） |
 
@@ -50,6 +51,18 @@
 
 非実行資産の変更確認は、必要に応じてレビュー、Markdown lint、リンクチェック、サンプルコマンドの実行で行う。
 
+## 置換された旧仕様のテスト
+
+仕様変更で旧設計の構成要素（UI・API・イベント・状態・ラベルなど）が新設計に置き換えられた場合、テストは新仕様の振る舞いを肯定的に検証する。旧仕様が存在しないことだけを固定しない。
+
+| 基準 | 判定 |
+|------|------|
+| 旧仕様の構成要素が存在・呼び出しされないことだけを検証するテストを追加 | REJECT |
+| 責務を失った実装単位に、旧仕様由来の不在確認テストを残す | REJECT |
+| 本番コードが最終的に変更されていないファイルで、旧仕様否定のためだけにテストを変更 | REJECT |
+| 新仕様を、新しい責務を持つ層（上位モジュール・サービス・統合フロー等）で肯定的に検証 | OK |
+| 旧仕様削除で未使用になったテストを削除し、新仕様の回帰テストへ置き換える | OK |
+
 ## テスト構造: Given-When-Then
 
 ```typescript
@@ -75,6 +88,18 @@ test('ユーザーが存在しない場合、NotFoundエラーを返す', async
 | 明確性 | 失敗時に原因が分かる | 失敗しても原因不明 |
 | 焦点 | 1テスト1概念 | 複数の関心事が混在 |
 
+## 副作用・状態遷移のテスト
+
+副作用や状態遷移を伴う変更は、正常系の成功だけでは十分に検証されたとは扱わない。
+
+| 基準 | 判定 |
+|------|------|
+| 正常系のみで、失敗・中断・早期終了時の状態を検証していない | REJECT |
+| 取得・開始・登録・反映した状態の後片付けや重複実行を検証していない | REJECT |
+| 共有状態や後続処理に影響する変更で、途中失敗後の再実行を検証していない | 警告。影響が主要経路なら REJECT |
+| モックで確認した範囲と未確認の実連携範囲を区別していない | 警告。主要要件なら REJECT |
+| 正常系、代表的な失敗経路、境界的な状態遷移をそれぞれ検証している | OK |
+
 ## テストデータとフィクスチャ
 
 テストデータは、テストごとに必要最小限の事実を明示して生成する。共有フィクスチャの破壊的変更や、実契約と異なるモックはテストの信頼性を下げる。

package/builtins/ja/workflows/backend-cqrs.yaml

@@ -335,6 +335,27 @@ steps:
           report:
             - name: qa-review.md
               format: qa-review
+      - name: pure-review
+        edit: false
+        persona: pure-reviewer
+        policy: review
+        provider_options:
+          claude:
+            allowed_tools:
+              - Read
+              - Glob
+              - Grep
+              - Bash
+              - WebSearch
+              - WebFetch
+        rules:
+          - condition: approved
+          - condition: needs_fix
+        instruction: review-pure
+        output_contracts:
+          report:
+            - name: pure-review.md
+              format: pure-review
       - name: coding-review
         edit: false
         persona: coding-reviewer

package/builtins/ja/workflows/backend.yaml

@@ -331,6 +331,27 @@ steps:
           report:
             - name: qa-review.md
               format: qa-review
+      - name: pure-review
+        edit: false
+        persona: pure-reviewer
+        policy: review
+        provider_options:
+          claude:
+            allowed_tools:
+              - Read
+              - Glob
+              - Grep
+              - Bash
+              - WebSearch
+              - WebFetch
+        rules:
+          - condition: approved
+          - condition: needs_fix
+        instruction: review-pure
+        output_contracts:
+          report:
+            - name: pure-review.md
+              format: pure-review
       - name: coding-review
         edit: false
         persona: coding-reviewer

package/builtins/ja/workflows/default-high.yaml

@@ -1,5 +1,5 @@
 name: default-high
-description: フルスペック開発ワークフロー（計画 → テスト作成 → draft（チームリーダー実装 + AI 自己レビュー） → peer-review（5並列 + AP-2nd） → supervise → COMPLETE）
+description: フルスペック開発ワークフロー（計画 → テスト作成 → draft（チームリーダー実装 + AI 自己レビュー） → peer-review（並列レビュー + AP-2nd） → supervise → COMPLETE）
 workflow_config:
   provider_options:
     codex:

package/builtins/ja/workflows/default-peer-review.yaml

@@ -1,5 +1,5 @@
 name: default-peer-review
-description: default 系の Phase 2。並列レビュアー（arch + ai-antipattern-2nd + coding-review + supervise） ⇄ 修正 ループ。
+description: default 系の Phase 2。並列レビュアー（arch + ai-antipattern-2nd + pure-review + coding-review + supervise） ⇄ 修正 ループ。
 subworkflow:
   callable: true
   visibility: internal
@@ -72,6 +72,27 @@ steps:
           report:
             - name: ai-antipattern-review.md
               format: ai-antipattern-review
+      - name: pure-review
+        edit: false
+        persona: pure-reviewer
+        policy: review
+        provider_options:
+          claude:
+            allowed_tools:
+              - Read
+              - Glob
+              - Grep
+              - Bash
+              - WebSearch
+              - WebFetch
+        rules:
+          - condition: approved
+          - condition: needs_fix
+        instruction: review-pure
+        output_contracts:
+          report:
+            - name: pure-review.md
+              format: pure-review
       - name: coding-review
         edit: false
         persona: coding-reviewer
@@ -119,9 +140,9 @@ steps:
               format: summary
               use_judge: false
     rules:
-      - condition: all("approved", "AI特有の問題なし", "approved", "すべて問題なし")
+      - condition: all("approved", "AI特有の問題なし", "approved", "approved", "すべて問題なし")
         next: COMPLETE
-      - condition: any("needs_fix", "AI特有の問題あり", "needs_fix", "要求未達成、テスト失敗、ビルドエラー")
+      - condition: any("needs_fix", "AI特有の問題あり", "needs_fix", "needs_fix", "要求未達成、テスト失敗、ビルドエラー")
         next: fix
   - name: fix
     edit: true