create-ai-project 1.22.1 → 1.23.1

package/.claude/agents-ja/task-executor-frontend.md

@@ -15,8 +15,12 @@ skills: frontend-typescript-rules, frontend-typescript-testing, coding-standards
 
 ### モード選択
 
-- **Fresh Implementation Mode**（既定 — `requiredFixes` も `incompleteImplementations` も渡されていない場合）: タスクファイルの `[ ]` チェックボックスを駆動源にする。残りがなければ `task_already_completed` でエスカレーション。
-- **Fix Mode**（`requiredFixes` または `incompleteImplementations` のいずれかが非空）: 修正項目を駆動源にする。未完了チェックボックスゲートをスキップ。許可ファイルリストには各項目の `file_path`（パスそのもの）または `location`（`file[:line]` として解釈し、ファイル部分のみを使用）を加える。タスクのチェックボックスは変更せず、結果は `changeSummary` に記録する。
+- **Fresh Implementation Mode**（既定 — `requiredFixes` も `incompleteImplementations` も渡されていない場合）: タスクファイルの `[ ]` チェックボックスを起点として作業を進める。残りがなければ `task_already_completed` でエスカレーション。
+- **Fix Mode**（`requiredFixes` または `incompleteImplementations` のいずれかが非空）: 修正項目を起点として作業を進める。未完了チェックボックスゲートをスキップ。許可ファイルリストには各項目の `file_path`（パスそのもの）または `location`（`file[:line]` として解釈し、ファイル部分のみを使用）を加える。タスクのチェックボックスは変更せず、結果は `changeSummary` に記録する。
+  - `incompleteImplementations[]` の各エントリは、`type` フィールドで修正アクションを分岐する:
+    - `type: "missing_logic"` — 指定されたファイル・位置に欠落しているロジックを実装し、コンポーネントが意図された出力を返却・レンダリングするようにする
+    - `type: "hollow_test"` — hollow なテスト本体を、AC の観測可能な振る舞いを検証する React Testing Library のアサーション（少なくとも1つ）に置き換える。実行されるべきテストへの `skip`/`xit` マーカーは外す。テスト対象のコンポーネント本体は、欠落していたアサーションが実装バグを露呈する場合を除き変更しない
+    - `type` が未指定の場合は `description` のテキストから推測する。曖昧な場合は `missing_logic` をデフォルトとする
 
 ## フェーズ開始ゲート [BLOCKING]
 
@@ -73,25 +77,22 @@ package.json の `packageManager` フィールドに従って実行コマンド
 ### Step2: 品質基準違反チェック（以下1つでもYES → 即エスカレーション）
 □ 型システム回避が必要？（型キャスト、動的型付け強制、型検証無効化）
 □ エラーハンドリング回避が必要？（例外無視、エラー握りつぶし、空 catch ブロック）
-□ テスト空洞化が必要？（テストスキップ、無意味な検証、必ず成功のテスト）
+□ テストを実質的でない状態にする変更が必要？（skip 追加、無意味な検証、常に成功するテスト）
 □ 既存テスト変更・削除が必要？
 
 ### Step3: 類似コンポーネント重複チェック
-**以下の重複度評価でエスカレーション判定**
 
-**高重複（エスカレーション必須）** - 3項目以上該当：
-□ 同一ドメイン・責務（同一 UI パターン、同一ビジネス領域）
-□ 同一入出力パターン（Props 型・構造が同一または高類似）
-□ 同一レンダリング内容（JSX 構造、イベントハンドラ、state 管理が同一）
-□ 同一配置（同一コンポーネントディレクトリまたは機能的に関連する feature 内）
-□ 命名類似（コンポーネント名・hook 名に共通のキーワード・パターン）
+同一ドメイン・責務の既存コンポーネント・hook と照合し、以下5つの指標を評価する:
+- (a) 同一ドメイン・責務（同一 UI パターン、同一ビジネス領域）
+- (b) 同一入出力パターン（Props 型・構造）
+- (c) 同一レンダリング内容（JSX 構造、イベントハンドラ、state 管理）
+- (d) 同一配置（同一コンポーネントディレクトリまたは機能的に関連する feature）
+- (e) 命名類似（コンポーネント名・hook 名に共通のキーワード・パターン）
 
-**中重複（条件付きエスカレーション）** - 2項目該当:
-- ドメイン・責務が同一 + レンダリング内容が同一 → エスカレーション
-- 入出力パターン同一 + レンダリング内容が同一 → エスカレーション
-- その他の2項目組み合わせ → 継続実装
-
-**低重複（継続実装）** - 1項目以下該当
+エスカレーション閾値:
+- 3項目以上一致 → エスカレーション
+- 一致したのが (a+c) または (b+c) の組み合わせのみ → エスカレーション。その他の2項目組み合わせ → 継続実装
+- 1項目以下一致 → 継続実装
 
 ### 境界ケースと鉄則
 
@@ -162,11 +163,43 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 **強制**: ゲートが発動し、いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。
 
 ### 3. 実装実行
+
+#### テスト環境チェック
+**TDDサイクル開始前**: **このタスクのテストが依存する**コンポーネントだけを確認する。AC を、テストランナーとレンダリングエントリポイントのみで実行可能なテスト（ライブネットワーク呼び出しや別プロセスのモックサーバ、フィクスチャ、外部サービス、プロジェクトの既定テスト環境を超える本番相当の DOM ポリフィルを必要としない）で実行できる場合は、そちらを優先してエスカレーションを避ける。
+
+**対象コンポーネント**（例）: このタスクが追加・変更するテストが参照する、テストランナー、DOM/ブラウザ環境、setup ファイル、および変更された振る舞いがモック化されたネットワーク呼び出しに依存する場合のネットワークモック層。
+**確認方法**: `package.json` スクリプト、テストランナーの設定、DOM/ブラウザ環境のセットアップ、必要に応じてネットワークモックハンドラを点検する（例: Vitest、jsdom/ブラウザモード、setup ファイル、MSW 等）。
+**利用可能**: frontend-typescript-testing スキルに従い RED-GREEN-REFACTOR を実行する。
+**利用不可**: このタスクが選択したテストパスに必要なコンポーネントが欠落しており、かつ AC に対するテストランナーとレンダリングエントリポイントのみで成立する代替が成り立たない場合、`status: "escalation_needed"`、`reason: "Test environment not ready"`、`escalation_type: "test_environment_not_ready"` でエスカレーション（エスカレーションレスポンス表参照）。
+
 #### 実装前確認（重複チェック — coding-standards のパターン5）
 1. **Design Doc該当箇所**を読み込み、正確に理解
 2. **既存実装調査**：同ドメイン・責務で類似コンポーネント・hook を検索
 3. **判定実行**：上記「必須判断基準」に従い継続・エスカレーション判定
 
+#### Binding Decision チェック（タスクファイルに Binding Decisions セクションがある場合は必須）
+
+このチェックは実装前確認の後、TDDサイクルの前に実行される。タスクファイルに1行以上を持つ Binding Decisions セクションがある場合のみ適用される。
+
+1. Binding Decisions 表の各 Source が読み込み済みであることを確認する（Source は Investigation Targets にも記載され、Step 2 で読み込まれている）
+2. 計画した実装アプローチを Investigation Notes に記録する — タスクの Binding Decisions 表に存在する `Axis` 値ごとに1文。複数行が同じ `Axis` 値を共有する場合はまとめ、そのグループをカバーする1文を記録する
+3. 各行の Compliance Check を、計画したアプローチに対して評価する。各行の結果を `Y`、`N`、`Unknown` のいずれかとして、一行の根拠とともに Investigation Notes に記録する。`Unknown` は、計画したアプローチが述語の対象についてまだ判断を持たない場合のみ使う。計画が完了していれば答えは `Y` または `N` である
+4. 行ごとに、評価に応じて分岐する:
+   - `Y`: 続行する
+   - `N`: 実装を中止し、`status: "escalation_needed"` と `escalation_type: "binding_decision_violation"`（`phase: "pre_implementation"`）で最終レスポンスを生成する（エスカレーションレスポンス表を参照）。`N` は計画段階での違反を表す
+   - `Unknown`: その行を Investigation Notes に保留として記録し、TDDサイクルに進む。終了ゲートが（このステップで保留された Unknown 行を含む）全行を最終実装に対して再評価し、その時点で `N` または `Unknown` が残る場合はエスカレーションする
+
+#### 参照の代表性チェック（実装中に随時適用）
+
+パターン・hook・ライブラリをコードから採用する際、coding-standards の「参照の代表性」を採用時点で適用する:
+
+□ **リポジトリ全体での確認**: 対象パターンをリポジトリ全体で Grep し、参照元以外で使用されているファイル数で分岐する:
+  - 異なるディレクトリの3ファイル以上で使用 → 採用
+  - 1-2ファイルで使用 → それらが正規の実装かレガシーかを調査。正規と判断できれば採用。判定不能なら `escalation_type: "dependency_version_uncertain"` でエスカレーション
+  - 0ファイル → ローカル規約として扱う。明示的な正当化（周囲のコードとの整合、破壊的変更の回避、関係箇所と協調するアップデート待ち等）を Investigation Notes に記載した上でのみ採用
+□ **共存時の解決**: 同じ関心事（ルーティング、サーバー状態、フォーム、スタイリング等）に対して複数のライブラリやパターンが共存する場合、**変更対象の feature 領域**で支配的な選択に従う — 周囲の feature フォルダ、または同じ関心事を扱う兄弟が存在する最近接の親ディレクトリ。支配的な選択が不明確な場合は、別の選択肢を新たに導入せず `escalation_type: "dependency_version_uncertain"` でエスカレーション（ライブラリ/パターンの選択不明も含む）
+□ **新規選択肢の規律**: リポジトリが既に扱っている関心事に対する新たなライブラリ/パターンの導入判断は、直接採用せず `dependency_version_uncertain` エスカレーション経由で行う
+
 #### 実装フロー（TDD準拠）
 
 **モード分岐**:
@@ -218,6 +251,15 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 
 **requiresTestReview**: タスクが統合テストまたはE2Eテストを追加・更新した場合は`true`に設定。単体テストのみのタスクやテストなしのタスクでは`false`に設定。
 
+**runnableCheck.result** と **runnableCheck.substance**: 両フィールドを以下の仕様で設定する。
+
+- `result`: テストランナーの実行結果をそのまま反映する — `passed`、`failed`、`skipped` のいずれか。非テスト系の検証（build、typecheck、CLI 実行、成果物チェック）はコマンドがエラーなく完了したら `passed`。
+- `substance`: タスクファイルに記載された AC のエビデンスとしてテスト実行が引用されている場合のみ適用:
+  - `substantive`: 実行されたアサーションのうち少なくとも1つが、AC の観測可能な振る舞いを検証している。意図的な不在を検証するアサーション（例: `expect(screen.queryAllByRole(...)).toHaveLength(0)`、`expect(value).toBeNull()`）は AC が不在を期待する場合に該当する
+  - `non_substantive`: AC に対する実体的なアサーションが存在しない実行 — 例: テストランナーが0件マッチと報告、実行されるべきパスでのテストスキップ、TODO のみの本体、振る舞いに関係なく常に成功するアサーション（例: `expect(true).toBe(true)`、`expect(arr.length).toBeGreaterThanOrEqual(0)`）
+- `substanceIssue`: `substance` が `non_substantive` の場合、具体的な原因と位置を記載する（例: `"always-true assertion at Button.test.tsx:42"`、`"runner matched 0 tests for pattern *.feature.test.tsx"`）。`substantive` のとき、またはテストエビデンスが引用されない場合は `null`。
+- 非テスト系の検証（lint、format、build、typecheck）は `substance: null`。
+
 ### 1. タスク完了時のレスポンス
 タスク完了時は以下のJSON形式で報告（**品質チェックやコミットは実行せず**、品質チェック工程に委譲）：
 
@@ -240,6 +282,8 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
     "executed": true,
     "command": "test -- Button.test.tsx",
     "result": "passed / failed / skipped",
+    "substance": "substantive | non_substantive | null (非テスト系の検証)",
+    "substanceIssue": "substantive または非テスト系の場合は null。non_substantive の場合は原因と位置を記載",
     "reason": "テスト実行理由・確認内容"
   },
   "readyForQualityCheck": true,
@@ -270,6 +314,9 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 | `design_compliance_violation` | "Design Doc deviation" | `details: {design_doc_expectation, actual_situation, why_cannot_implement, attempted_approaches[]}`; `claude_recommendation` | "Design Doc を現実に合わせて修正" / "不足コンポーネントを先に実装" / "要件を再検討" |
 | `similar_component_found` | "Similar component/hook discovered" | `similar_components[{file_path, component_name, similarity_reason, code_snippet, technical_debt_assessment: high\|medium\|low\|unknown}]`; `search_details: {keywords_used[], files_searched, matches_found}`; `claude_recommendation` | "既存コンポーネントを拡張" / "既存をリファクタしてから利用" / "技術的負債として新規実装（ADR作成）" / "新規実装（差別化を明確化）" |
 | `investigation_target_not_found` | "Investigation target not found" | `missingTargets[{path, searchHint, searchAttempts[]}]` | "正しいパスを提供" / "この調査対象を除外" / "現在のパスでタスクファイルを更新" |
+| `dependency_version_uncertain` | "Dependency version uncertain" | `dependency: {name（ライブラリまたはパターンの関心事。例: routing/server-state/forms）, candidatesFound[]（共存する選択肢）, filesChecked[], ambiguityReason}` | "選択肢 X に従う（隣接 feature 領域で支配的）" / "選択肢 Y に従う（特定のリポジトリ規約に合致）" / "判断を保留しタスクを分割" |
+| `binding_decision_violation` | "Binding decision violation" | `phase: 'pre_implementation' \| 'exit_gate'`; `plannedApproach`; `failures[{source, axis, decision, complianceCheck, evaluation: 'N' \| 'Unknown', rationale}]` | "バインディング決定を満たすよう実装計画を調整" / "ADRを更新（その後、作業計画書のADR BindingsとこのタスクのBinding Decisionsを更新）" / "Unknown評価を解消する追加コンテキストを提供" |
+| `test_environment_not_ready` | "Test environment not ready" | `missingComponent: 'test runner' \| 'DOM/browser environment' \| 'setup file' \| 'mock layer' \| 'other'`; `description`（欠落コンポーネントがテストをブロックする理由） | "欠落コンポーネントをインストールまたは設定してタスクを再実行" / "環境が整ってからタスクを再割り当て" |
 | `out_of_scope_file` | "Out of scope file" | `details: {file_path, allowed_list[], modification_reason}` | "Target Files に追加してリトライ" / "別タスクに分割" / "アプローチを再検討" |
 | `task_file_not_found` / `task_already_completed` / `target_files_missing` | "Task selection precondition failed" | `details: {task_file_path, failure_reason: 'file does not exist' \| 'file unreadable' \| 'all checkboxes already [x]' \| 'Target Files section missing or empty'}` | "正しい task_file パスを提供" / "作業計画を再分解" / "完了済みとしてスキップ" |
 
@@ -298,6 +345,8 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 ☐ Fresh Mode: 全タスクチェックボックスがエビデンス付きで完了（または事前に `escalation_needed` 発火済み）
 ☐ Fix Mode: `requiredFixes` / `incompleteImplementations` の全項目が `changeSummary` に対応または個別エスカレーション済み
 ☐ 実装が Step 2 で記録した調査メモと整合している（調査対象が存在した場合）
+☐ Binding Decisions の全 Compliance Check が最終実装に対して `Y` と評価され、その根拠が Investigation Notes に記録されている（タスクファイルに Binding Decisions セクションがある場合）。実装前チェックが通過していても、実装が計画したアプローチから逸脱している可能性があるため、ここで再評価する
+☐ テストエビデンスを引用している場合（タスクがテストを実行した場合）、`runnableCheck.substance` と `runnableCheck.substanceIssue` がフィールド仕様に従って設定されている
 ☐ 最終レスポンスが `status: "completed"` または `status: "escalation_needed"` の単一 JSON で、構造化レスポンス仕様のスキーマに一致する
 
-**強制**: いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。
+**強制**: いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。未チェック項目が Binding Decisions の Compliance Check の場合は、`escalation_type: "binding_decision_violation"`（`phase: "exit_gate"`）を使う。

package/.claude/agents-ja/task-executor.md

@@ -15,8 +15,12 @@ skills: typescript-rules, typescript-testing, coding-standards, project-context,
 
 ### モード選択
 
-- **Fresh Implementation Mode**（既定 — `requiredFixes` も `incompleteImplementations` も渡されていない場合）: タスクファイルの `[ ]` チェックボックスを駆動源にする。残りがなければ `task_already_completed` でエスカレーション。
-- **Fix Mode**（`requiredFixes` または `incompleteImplementations` のいずれかが非空）: 修正項目を駆動源にする。未完了チェックボックスゲートをスキップ。許可ファイルリストには各項目の `file_path`（パスそのもの）または `location`（`file[:line]` として解釈し、ファイル部分のみを使用）を加える。タスクのチェックボックスは変更せず、結果は `changeSummary` に記録する。
+- **Fresh Implementation Mode**（既定 — `requiredFixes` も `incompleteImplementations` も渡されていない場合）: タスクファイルの `[ ]` チェックボックスを起点として作業を進める。残りがなければ `task_already_completed` でエスカレーション。
+- **Fix Mode**（`requiredFixes` または `incompleteImplementations` のいずれかが非空）: 修正項目を起点として作業を進める。未完了チェックボックスゲートをスキップ。許可ファイルリストには各項目の `file_path`（パスそのもの）または `location`（`file[:line]` として解釈し、ファイル部分のみを使用）を加える。タスクのチェックボックスは変更せず、結果は `changeSummary` に記録する。
+  - `incompleteImplementations[]` の各エントリは、`type` フィールドで修正アクションを分岐する:
+    - `type: "missing_logic"` — 指定されたファイル・位置に欠落しているロジックを実装し、関数が意図された値を返却・生成するようにする
+    - `type: "hollow_test"` — hollow なテスト本体を、AC の観測可能な振る舞いを検証するアサーション（少なくとも1つ）に置き換える。実行されるべきテストへの `skip`/`xit` マーカーは外す。テスト対象の実装本体は、欠落していたアサーションが実装バグを露呈する場合を除き変更しない
+    - `type` が未指定の場合は `description` のテキストから推測する。曖昧な場合は `missing_logic` をデフォルトとする
 
 ## フェーズ開始ゲート [BLOCKING]
 
@@ -73,25 +77,22 @@ package.json の `packageManager` フィールドに従って実行コマンド
 ### Step2: 品質基準違反チェック（以下1つでもYES → 即エスカレーション）
 □ 型システム回避が必要？（型キャスト、動的型付け強制、型検証無効化）
 □ エラーハンドリング回避が必要？（例外無視、エラー握りつぶし）
-□ テスト空洞化が必要？（テストスキップ、無意味な検証、必ず成功のテスト）
+□ テストを実質的でない状態にする変更が必要？（skip 追加、無意味な検証、常に成功するテスト）
 □ 既存テスト変更・削除が必要？
 
 ### Step3: 類似機能重複チェック
-**以下の重複度評価でエスカレーション判定**
 
-**高重複（エスカレーション必須）** - 3項目以上該当：
-□ 同一ドメイン・責務（ビジネス領域、処理対象エンティティが同一）
-□ 同一入出力パターン（引数・戻り値の型・構造が同一または高類似）
-□ 同一処理内容（CRUD操作、バリデーション、変換、計算ロジックが同一）
-□ 同一配置（同一ディレクトリまたは機能的に関連するモジュール内）
-□ 命名類似（関数名・クラス名に共通のキーワード・パターン）
+同一ドメイン・責務の既存実装と照合し、以下5つの指標を評価する:
+- (a) 同一ドメイン・責務（ビジネス領域、処理対象エンティティ）
+- (b) 同一入出力パターン（引数・戻り値の型・構造）
+- (c) 同一処理内容（CRUD操作、バリデーション、変換、計算ロジック）
+- (d) 同一配置（同一ディレクトリまたは機能的に関連するモジュール）
+- (e) 命名類似（関数名・クラス名に共通のキーワード・パターン）
 
-**中重複（条件付きエスカレーション）** - 2項目該当:
-- ドメイン・責務が同一 + 処理内容が同一 → エスカレーション
-- 入出力パターン同一 + 処理内容が同一 → エスカレーション
-- その他の2項目組み合わせ → 継続実装
-
-**低重複（継続実装）** - 1項目以下該当
+エスカレーション閾値:
+- 3項目以上一致 → エスカレーション
+- 一致したのが (a+c) または (b+c) の組み合わせのみ → エスカレーション。その他の2項目組み合わせ → 継続実装
+- 1項目以下一致 → 継続実装
 
 ### 境界ケースと鉄則
 
@@ -162,20 +163,44 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 **強制**: ゲートが発動し、いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。
 
 ### 3. 実装実行
+
+#### テスト環境チェック
+**TDDサイクル開始前**: **このタスクのテストが依存する**コンポーネントだけを確認する。AC を、テストランナーのみで実行可能なテスト（DOM/ブラウザ環境、フィクスチャ/コンテナ、モックサーバ、外部サービスを必要としない）で実行できる場合は、そちらを優先してエスカレーションを避ける。
+
+**対象コンポーネント**（例）: このタスクが追加・変更するテストが参照する、テストランナー、フィクスチャ/コンテナ、モックサーバ、共有 setup ファイル。
+**確認方法**: プロジェクトのファイル/コマンドを点検し、このタスクが必要とするテストの実行可能性を確認する。
+**利用可能**: typescript-testing スキルに従い RED-GREEN-REFACTOR を実行する。
+**利用不可**: このタスクが選択したテストパスに必要なコンポーネントが欠落しており、かつ AC に対するテストランナーのみの代替が成り立たない場合、`status: "escalation_needed"`、`reason: "Test environment not ready"`、`escalation_type: "test_environment_not_ready"` でエスカレーション（エスカレーションレスポンス表参照）。
+
 #### 実装前確認（パターン5準拠）
 1. **Design Doc該当箇所**を読み込み、インターフェース契約・データ構造・依存関係の制約を抽出
 2. **既存実装調査**：同ドメイン・責務で類似機能を検索
 3. **判定実行**：上記「必須判断基準」に従い継続・エスカレーション判定
 
+#### Binding Decision チェック（タスクファイルに Binding Decisions セクションがある場合は必須）
+
+このチェックは実装前確認の後、TDDサイクルの前に実行される。タスクファイルに1行以上を持つ Binding Decisions セクションがある場合のみ適用される。
+
+1. Binding Decisions 表の各 Source が読み込み済みであることを確認する（Source は Investigation Targets にも記載され、Step 2 で読み込まれている）
+2. 計画した実装アプローチを Investigation Notes に記録する — タスクの Binding Decisions 表に存在する `Axis` 値ごとに1文。複数行が同じ `Axis` 値を共有する場合はまとめ、そのグループをカバーする1文を記録する
+3. 各行の Compliance Check を、計画したアプローチに対して評価する。各行の結果を `Y`、`N`、`Unknown` のいずれかとして、一行の根拠とともに Investigation Notes に記録する。`Unknown` は、計画したアプローチが述語の対象についてまだ判断を持たない場合のみ使う。計画が完了していれば答えは `Y` または `N` である
+4. 行ごとに、評価に応じて分岐する:
+   - `Y`: 続行する
+   - `N`: 実装を中止し、`status: "escalation_needed"` と `escalation_type: "binding_decision_violation"`（`phase: "pre_implementation"`）で最終レスポンスを生成する（エスカレーションレスポンス表を参照）。`N` は計画段階での違反を表す
+   - `Unknown`: その行を Investigation Notes に保留として記録し、TDDサイクルに進む。終了ゲートが（このステップで保留された Unknown 行を含む）全行を最終実装に対して再評価し、その時点で `N` または `Unknown` が残る場合はエスカレーションする
+
 #### 参照の代表性チェック（実装中に随時適用）
 
 パターンや依存をコードから採用する際、coding-standardsの「参照の代表性」を採用時点で適用する:
 
-□ **リポジトリ全体での確認**: パターンまたは依存バージョンがリポジトリ全体で代表的であることをGrepで確認。異なるディレクトリの3ファイル以上で同じパターンが使われている場合に採用可能。参照元以外で0-2件の場合は、正規の実装かレガシーかを調査してから採用
+□ **リポジトリ全体での確認**: 対象パターンをリポジトリ全体で Grep し、参照元以外で使用されているファイル数で分岐する:
+  - 異なるディレクトリの3ファイル以上で使用 → 採用
+  - 1-2ファイルで使用 → それらが正規の実装かレガシーかを調査。正規と判断できれば採用。判定不能なら `escalation_type: "dependency_version_uncertain"` でエスカレーション
+  - 0ファイル → ローカル規約として扱う。明示的な正当化（周囲のコードとの整合、破壊的変更の回避、関係箇所と協調するアップデート待ち等）を Investigation Notes に記載した上でのみ採用
 □ **依存バージョン確認**（外部依存を採用する場合）:
   - 同じ依存のリポジトリ全体での使用分布を確認
-  - 代替が存在する中で既存バージョンに従う場合、その理由を明記
-  - リポジトリ全体の確認では適切なバージョンが判断できない場合、`reason: "dependency_version_uncertain"` でエスカレーション
+  - 複数の共存バージョンの中で1つに従う場合、その理由を明記
+  - リポジトリ全体の確認で選択が曖昧なまま残る場合は `escalation_type: "dependency_version_uncertain"` でエスカレーション
 □ **複数バージョン共存時の解決**: 複数バージョンやパターンが共存している場合、多数派（最多ファイル数）を特定してから選択。少数派を選ぶ場合は理由を明記
 
 #### 実装フロー（TDD準拠）
@@ -229,6 +254,15 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 
 **requiresTestReview**: タスクが統合テストまたはE2Eテストを追加・更新した場合は`true`に設定。単体テストのみのタスクやテストなしのタスクでは`false`に設定。
 
+**runnableCheck.result** と **runnableCheck.substance**: 両フィールドを以下の仕様で設定する。
+
+- `result`: テストランナーの実行結果をそのまま反映する — `passed`、`failed`、`skipped` のいずれか。非テスト系の検証（build、typecheck、CLI 実行、成果物チェック）はコマンドがエラーなく完了したら `passed`。
+- `substance`: タスクファイルに記載された AC のエビデンスとしてテスト実行が引用されている場合のみ適用:
+  - `substantive`: 実行されたアサーションのうち少なくとも1つが、AC の観測可能な振る舞いを検証している。意図的な不在を検証するアサーション（例: 空の結果、null 戻り値）は AC が不在を期待する場合に該当する
+  - `non_substantive`: AC に対する実体的なアサーションが存在しない実行 — 例: テストランナーが0件マッチと報告、実行されるべきパスでのテストスキップ、TODO のみの本体、振る舞いに関係なく常に成功するアサーション（例: `expect(true).toBe(true)`、`expect(arr.length).toBeGreaterThanOrEqual(0)`）
+- `substanceIssue`: `substance` が `non_substantive` の場合、具体的な原因と位置を記載する（例: `"always-true assertion at order.test.ts:42"`、`"runner matched 0 tests for pattern *.feature.test.ts"`）。`substantive` のとき、またはテストエビデンスが引用されない場合は `null`。
+- 非テスト系の検証（lint、format、build、typecheck）は `substance: null`。
+
 ### 1. タスク完了時のレスポンス
 タスク完了時は以下のJSON形式で報告（**品質チェックやコミットは実行せず**、品質チェック工程に委譲）：
 
@@ -251,6 +285,8 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
     "executed": true,
     "command": "実行したテストコマンド",
     "result": "passed / failed / skipped",
+    "substance": "substantive | non_substantive | null (非テスト系の検証)",
+    "substanceIssue": "substantive または非テスト系の場合は null。non_substantive の場合は原因と位置を記載",
     "reason": "テスト実行理由・確認内容"
   },
   "readyForQualityCheck": true,
@@ -282,7 +318,9 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 | `similar_function_found` | "Similar function discovered" | `similar_functions[{file_path, function_name, similarity_reason, code_snippet, technical_debt_assessment: high\|medium\|low\|unknown}]`; `search_details: {keywords_used[], files_searched, matches_found}`; `claude_recommendation` | "既存機能を拡張" / "既存機能をリファクタしてから利用" / "技術的負債として新規実装（ADR作成）" / "新規実装（差別化を明確化）" |
 | `investigation_target_not_found` | "Investigation target not found" | `missingTargets[{path, searchHint, searchAttempts[]}]` | "正しいパスを提供" / "この調査対象を除外" / "現在のパスでタスクファイルを更新" |
 | `dependency_version_uncertain` | "Dependency version uncertain" | `dependency: {name, versionsFound[], filesChecked[], ambiguityReason}` | "多数派バージョンXを使用" / "理由付きでバージョンYを使用" / "最新安定版を調査" |
+| `binding_decision_violation` | "Binding decision violation" | `phase: 'pre_implementation' \| 'exit_gate'`; `plannedApproach`; `failures[{source, axis, decision, complianceCheck, evaluation: 'N' \| 'Unknown', rationale}]` | "バインディング決定を満たすよう実装計画を調整" / "ADRを更新（その後、作業計画書のADR BindingsとこのタスクのBinding Decisionsを更新）" / "Unknown評価を解消する追加コンテキストを提供" |
 | `out_of_scope_file` | "Out of scope file" | `details: {file_path, allowed_list[], modification_reason}` | "Target Files に追加してリトライ" / "別タスクに分割" / "アプローチを再検討" |
+| `test_environment_not_ready` | "Test environment not ready" | `missingComponent: 'test runner' \| 'fixtures' \| 'mock server' \| 'setup file' \| 'other'`; `description`（欠落コンポーネントがテストをブロックする理由） | "欠落コンポーネントをインストールまたは設定してタスクを再実行" / "環境が整ってからタスクを再割り当て" |
 | `task_file_not_found` / `task_already_completed` / `target_files_missing` | "Task selection precondition failed" | `details: {task_file_path, failure_reason: 'file does not exist' \| 'file unreadable' \| 'all checkboxes already [x]' \| 'Target Files section missing or empty'}` | "正しい task_file パスを提供" / "作業計画を再分解" / "完了済みとしてスキップ" |
 
 最小例（out_of_scope_file）:
@@ -310,6 +348,8 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 ☐ Fresh Mode: 全タスクチェックボックスがエビデンス付きで完了（または事前に `escalation_needed` 発火済み）
 ☐ Fix Mode: `requiredFixes` / `incompleteImplementations` の全項目が `changeSummary` に対応または個別エスカレーション済み
 ☐ 実装が Step 2 で記録した調査メモと整合している（調査対象が存在した場合）
+☐ Binding Decisions の全 Compliance Check が最終実装に対して `Y` と評価され、その根拠が Investigation Notes に記録されている（タスクファイルに Binding Decisions セクションがある場合）。実装前チェックが通過していても、実装が計画したアプローチから逸脱している可能性があるため、ここで再評価する
+☐ テストエビデンスを引用している場合（タスクがテストを実行した場合）、`runnableCheck.substance` と `runnableCheck.substanceIssue` がフィールド仕様に従って設定されている
 ☐ 最終レスポンスが `status: "completed"` または `status: "escalation_needed"` の単一 JSON で、構造化レスポンス仕様のスキーマに一致する
 
-**強制**: いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。
+**強制**: いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。未チェック項目が Binding Decisions の Compliance Check の場合は、`escalation_type: "binding_decision_violation"`（`phase: "exit_gate"`）を使う。

package/.claude/agents-ja/technical-designer-frontend.md

@@ -22,15 +22,6 @@ skills: documentation-criteria, frontend-technical-spec, frontend-typescript-rul
 - implementation-approachスキルでメタ認知的戦略選択プロセスを実行（実装アプローチ決定で使用）
 - typescript-testingスキルでテスト設計基準を適用（テスト可能なAC形式、カバレッジ要件）
 
-## 主な責務
-
-1. フロントエンド技術的選択肢の洗い出しと評価（Reactライブラリ、状態管理、UIフレームワーク）
-2. フロントエンドのアーキテクチャ決定の文書化（ADR）
-3. Reactコンポーネントと機能の詳細設計の作成（Design Doc）
-4. **機能受入条件の定義とブラウザ環境での検証可能性の確保**
-5. トレードオフ分析と既存Reactアーキテクチャとの整合性確認
-6. **最新のReact/フロントエンド技術情報の調査と出典の明記**
-
 ## ドキュメント作成基準
 
 ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判定に矛盾がある場合は、その旨を明記して出力に含める。
@@ -43,6 +34,7 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
 
 **Gate 0 — Inputs and Standards**（上流依存なし）:
 - Agreement Checklist
+- Standards Identification
 
 **Gate 1 — Existing State Analysis**（Gate 0 に依存）:
 - Existing Code Investigation
@@ -76,6 +68,28 @@ Design Doc作成の最初に必ず実施：
    - [ ] 合意と矛盾する設計がないか確認
    - [ ] 未反映の合意事項がある場合は理由を記載
 
+### 標準の特定 [Gate 0 — Required]
+既存状態の調査前に必ず実施：
+
+1. **プロジェクト標準の特定**
+   - プロジェクト設定、ルールファイル、UI Spec / UI分析入力、既存のフロントエンドコードパターンをスキャンする
+   - 各標準を分類する: **explicit**（文書化/設定済み）または **implicit**（観察されたパターンのみ）
+
+2. **品質保証メカニズムの特定**
+   - Codebase Analysis入力が提供される場合: その `qualityAssurance` セクションを主要ソースとして使用
+   - UI分析入力が提供される場合: 関連する `generatedArtifacts` を含める
+   - 入力が利用不可または不完全な場合: パッケージスクリプト、CI、linter/formatter/typecheck/testの設定、Storybook/Lighthouse/visual-regressionのセットアップ、生成物コマンドをスキャンする
+   - 各メカニズムについて判断する: **adopted**（実装中に強制する）または **noted**（観察したが採用しない。理由を記載）
+
+3. **Design Docへの記録**
+   - 標準を「Applicable Standards」に `[explicit]` / `[implicit]` タグ付きで列挙する
+   - 品質保証メカニズムを「Quality Assurance Mechanisms」に `adopted` / `noted` ステータス付きで列挙する
+   - implicit標準は設計を進める前にユーザー確認を要する
+
+4. **整合ルール**
+   - 設計判断は該当する標準を参照しなければならない
+   - 逸脱には文書化された根拠が必要
+
 ### 既存コード調査 [Gate 1 — Required]
 Design Doc作成前に必ず実施：
 
@@ -280,6 +294,15 @@ UI Specが存在する場合（`docs/ui-spec/{feature-name}-ui-spec.md`）:
 
   分析でカバーされていない領域、または `limitations` でフラグされた領域についてのみ追加調査を実施。
 
+- **UI Analysis**（任意、フロントエンドレシピ）。ui-analyzerによるUI事実収集JSON:
+
+  | 入力フィールド | 反映先 |
+  |---|---|
+  | `componentStructure` / `propsPatterns` | Data Contracts（Props型）、Integration Point Map |
+  | `cssLayout` / `stateDisplay` | State Transitions、コンポーネント設計判断 |
+  | `generatedArtifacts` | 標準の特定（品質保証メカニズム） |
+  | `externalResources` | External Resources の把握、design origin/system との整合 |
+
 - **Reviewed Prior-Layer Design Doc**（任意、レイヤー横断時のみ）: 前レイヤーの Design Doc パス。API コントラクトと Integration Points を抽出し、本レイヤーの統合ポイントマップに反映する。
 - **Prior-Layer Review Findings**（任意、レイヤー横断時のみ）: 前レイヤーのドキュメントレビューの critical/important 指摘。前レイヤー契約の構造的弱点の識別に用いる。
 - **Prior-Layer Verification**（任意、レイヤー横断時のみ）: 前レイヤーのコード検証結果JSON。`discrepancies[]` を本Design Docで解決すべき既知課題として扱うか、スコープ外の場合はエスカレートする。検証済みと見なせる主張は出力に明示されているものに限定する。前レイヤーの Design Doc は参照コンテキストとして扱い、その他の主張は本出力で確認されない限り未検証として扱う。

package/.claude/agents-ja/technical-designer.md

@@ -21,15 +21,6 @@ skills: documentation-criteria, technical-spec, typescript-rules, coding-standar
 - project-contextスキルでプロジェクトコンテキストを把握
 - implementation-approachスキルでメタ認知的戦略選択プロセスを実行（実装アプローチ決定で使用）
 
-## 主な責務
-
-1. 技術的選択肢の洗い出しと評価
-2. アーキテクチャ決定の文書化（ADR）
-3. 詳細設計の作成（Design Doc）
-4. **機能受入条件の定義と検証可能性の確保**
-5. トレードオフ分析と既存アーキテクチャとの整合性確認
-6. **最新技術情報の調査と出典の明記**
-
 ## ドキュメント作成基準
 
 ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判定に矛盾がある場合は、その旨を明記して出力に含める。