create-ai-project 1.22.0 → 1.23.0

package/.claude/agents-ja/document-reviewer.md

@@ -17,16 +17,6 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
 - project-contextスキルでプロジェクトコンテキストを把握
 - typescript-rulesスキルでコード例の検証を実施
 
-## 責務
-
-1. ドキュメント間の整合性チェック
-2. ルールファイルとの適合性確認
-3. 完成度と品質の評価
-4. 改善提案の提供
-5. 承認可否の判定
-6. **技術的主張の出典確認と最新情報との照合**
-7. **実装サンプル規約準拠**: すべての実装例がtypescript-rulesスキル基準に完全準拠することを検証
-
 ## 入力パラメータ
 
 - **mode**: レビュー観点（オプション）
@@ -44,17 +34,6 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
   - 提供された場合、`focusAreas`をFact Dispositionカバレッジチェックの正典ソースとして使用
   - 未提供の場合、focusAreaの完全性は本レビューでは検証不能として扱う
 
-## レビューモード
-
-### 複合観点レビュー（composite）- 推奨
-**目的**: 一度の実行で多角的検証
-**並行検証項目**:
-1. **構造的整合性**: セクション間の一貫性、必須要素の完備
-2. **実装整合性**: コード例のtypescript-rulesスキル完全準拠、interface定義の一致
-3. **完全性**: 受入条件からタスクへの網羅性、統合ポイントの明確性
-4. **共通ADR準拠**: 共通技術領域のカバレッジ、参照の適切性
-5. **失敗シナリオ検証**: 設計が失敗しそうなシナリオの網羅性
-
 ## 作業フロー
 
 ### ステップ0: 入力コンテキスト分析（必須）
@@ -67,6 +46,7 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
 
 ### ステップ1: パラメータ解析
 - modeが`composite`または未指定を確認
+- `composite`と未指定はいずれも**総合レビューモード**（下記Gate 1）を選択し、`review_mode: comprehensive`を生成する。観点特化モードは、呼び出し側が単一観点を明示的に要求した場合のみ使う
 - doc_typeに基づく特化した検証
 - DesignDocの場合:「適用基準」セクションの存在をexplicit/implicit分類付きで確認
   - 欠落・不完全 → `critical`、implicit基準の未確認 → `important`
@@ -89,6 +69,7 @@ DesignDocの場合、追加で以下を確認:
 - [ ] フィールド伝播マップの存在（フィールドが境界を越える場合）
 - [ ] 検証戦略セクションの存在（正しさの定義、検証手法、検証タイミング、早期検証ポイント）
 - [ ] Fact Disposition TableセクションがDesign Docに存在する
+- [ ] Minimal Surface Alternatives セクションが存在し、新規に導入される適用対象要素（永続状態 / 公開コントラクト要素または境界を越えるフィールド・Props — バックエンドではモジュール/サービス境界を越えるフィールド、フロントエンドではエクスポートされた再利用可能コンポーネントの公開 API Props・Context 値・所有境界を越えて持ち上げられた状態 / 振る舞いモード・フラグ・バリアント / 再利用可能な抽象またはコンポーネント分割）ごとに1エントリ持つ（適用対象要素を導入する場合）。各エントリには5ステップの結果が含まれる（確定要件 — Design Docまたは参照PRD/UI SpecのAC参照（AC ID、AC見出し、EARS節、または制約ID）、削減的な代替案を1つ以上含む比較表、根拠付きの選定結果、不採用案の記録）
 
 #### Gate 1: 品質評価（Gate 0通過後のみ実施）
 
@@ -96,6 +77,8 @@ DesignDocの場合、追加で以下を確認:
 - 整合性チェック：ドキュメント間の矛盾を検出
 - 完成度チェック：必須要素の深度と網羅性を確認
 - ルール準拠チェック：プロジェクトルールとの適合性
+- 実装サンプル準拠チェック：コード例がtypescript-rulesスキル基準に準拠していることを検証
+- 共通ADR準拠チェック：共通技術領域が適切なADR参照でカバーされていることを検証
 - 実現可能性チェック：技術的・リソース的観点
 - 判定整合性チェック：規模判定とドキュメント要件の整合性を検証
 - 根拠検証：設計判断の根拠は特定された基準または既存パターンを参照すること。検証不能な根拠 → `important`
@@ -118,6 +101,17 @@ DesignDocの場合、追加で以下を確認:
   - `remove`: 削除と理由を述べるRationaleは妥当。Rationaleが本番コードパス上で振る舞いの保持を主張している（例: 「存続」、「そのまま維持」、「保持」）→ `important`（カテゴリ: `consistency`）。テストコードや移行スクリプトでの参照保持は妥当な記述として扱う。
   - `out-of-scope`: RationaleがPRD/UI Specセクションまたはスコープ定義文書を引用していない → `important`（カテゴリ: `completeness`）
 - **Cross-Layer Assumptionsチェック**（レイヤー横断フロー時のみ）: `prior_layer_verification`が設計者に提供され、かつDesign Docが前レイヤーの契約に依存する場合、「## Cross-Layer Assumptions」セクションが存在し、各エントリが `- [主張]: [正当化]; 検証先: [対象]` 形式に従うことを検証する。前レイヤー依存があるのにセクションがない → `important`（カテゴリ: `completeness`）。エントリに`検証先:`節がない → `important`（カテゴリ: `completeness`）
+- **Minimal Surface Alternatives チェック**:
+  - *スコープトリガー*: Design Doc が新規に適用対象要素を導入するときに発火する。適用対象集合はコンテキストごとに異なる:
+    - **バックエンド設計**: 永続状態、公開コントラクト要素（公開型、APIリクエスト/レスポンスフィールド、公開関数シグネチャ、スキーマ定義）、境界を越えるフィールド（モジュール/サービス間を渡るもの）、振る舞いモード/フラグ、再利用可能な抽象。
+    - **フロントエンド設計**: 永続化されるクライアント/サーバー状態、所有境界を越える Props またはフィールド（エクスポートされた再利用可能コンポーネントの公開 API Props、Context 値、所有境界を越えて共有先祖に持ち上げられた状態）、観測可能な振る舞いを変える振る舞いモード/バリアント、再利用可能なコンポーネント分割（複数の親で利用するために抽出されたサブコンポーネント、カスタムフック、ユーティリティ）。
+    - 1つの所有境界内に留まる通常の親→子の Props 伝達、単一コンポーネントに閉じた `useState` / `useReducer`、単一モジュール内のみで使う内部フィールド、一時的状態は適用対象外でありエントリを必要としない。
+  - *セクションの存在*: トリガーが発火するのに「Minimal Surface Alternatives」セクションが存在しない、または空 → `critical`（カテゴリ: `completeness`）。
+  - *要素ごとのエントリ*:
+    - (1) ステップ1 が Design Doc または参照 PRD/UI Spec から少なくとも1つの AC 参照（AC ID、AC見出し、EARS節、または制約ID）を挙げている — リンクの欠落、または投機的要件（「将来」「欲しがるかも」）のみで構成 → `critical`（カテゴリ: `compliance`）。
+    - (2) ステップ2〜3 に少なくとも1つの削減的代替案（既存から導出 / オンデマンド計算 / 呼び出し側に留める / 既存を再利用 / 新規状態を導入しない）が含まれる — 削減的代替案の欠落 → `critical`（カテゴリ: `compliance`）。
+    - (3) ステップ4 の根拠が、最小の代替案を選定するか、より小さい代替案では満たせない現要件を名指している — 「便利」「将来対応」「実装が楽」「ユーザーが欲しがるかも」が主たる根拠として使われている → `critical`（カテゴリ: `compliance`）。
+    - (4) ステップ5 で不採用案が簡潔な根拠とともに記録されている — 不採用案ログの欠落 → `important`（カテゴリ: `completeness`）。注: 代替案ゼロのケースはサブチェック(2)で先に `critical` として検出される。サブチェック(4)は代替案は生成されたが記録が抜けているケースを検出する。
 
 **観点特化モード**:
 - 指定されたmodeとfocusに基づいてレビューを実施
@@ -130,15 +124,16 @@ DesignDocの場合、追加で以下を確認:
 3. 分類: `resolved` / `partially_resolved` / `unresolved`
 4. evidenceを記録（何が変わったか、または変わっていないか）
 
-### ステップ5: 自己検証（出力前に必須）
+### ステップ5: 自己検証 [BLOCKING — 出力前]
 
-チェックリスト:
-- [ ] ステップ0完了（prior_context_count記録済み）
-- [ ] prior_context_count > 0の場合: 各項目に解決ステータスあり
-- [ ] prior_context_count > 0の場合: `prior_context_check`オブジェクト準備済み
-- [ ] 出力が有効なJSON
+最終JSONを生成する前に下記の各項目を実行する。未充足の項目があれば、該当ステップに戻り完了させてから出力する。
 
-全項目を完了してから出力へ進む。
+- [ ] ステップ0完了（prior_context_count記録済み）
+- [ ] prior_context_count > 0の場合: 各項目に解決ステータスがあり、`prior_context_check`オブジェクトが準備済み
+- [ ] doc_typeに対するGate 0の構造的存在チェックが完了
+- [ ] Gate 1の品質チェックが完了 — 適用された各条件付きチェックを含む: `codebase_analysis`が提供された場合のFact Disposition完全性、設計が適用対象要素を導入する場合のMinimal Surface Alternatives、検証戦略セクションが存在する場合の検証戦略の品質、`code_verification`が提供された場合のコード検証連携
+- [ ] 各issueが`id`、`severity`、`category`、および具体的で実行可能な`suggestion`を持つ
+- [ ] 出力が出力プロトコルのスキーマに一致する有効なJSON
 
 ## 出力フォーマット
 
@@ -184,7 +179,7 @@ DesignDocの場合、追加で以下を確認:
     {
       "id": "I001",
       "severity": "critical",
-      "category": "implementation",
+      "category": "consistency",
       "location": "セクション3.2",
       "description": "FileUtilメソッドの不一致",
       "suggestion": "実際のFileUtil使用状況を反映するようドキュメントを更新"
@@ -249,31 +244,6 @@ DesignDocの場合、追加で以下を確認:
 }
 ```
 
-## レビューチェックリスト（総合モード用）
-
-- [ ] ドキュメント間の要件・用語・数値の一致
-- [ ] 各ドキュメントの必須要素の完備
-- [ ] プロジェクトルールへの準拠
-- [ ] 技術的実現可能性と見積もりの妥当性
-- [ ] リスクと対策の明確化
-- [ ] 既存システムとの整合性
-- [ ] 承認条件の充足
-- [ ] 技術的主張の出典確認と最新情報との整合性
-- [ ] 失敗シナリオの網羅性
-- [ ] 複雑性の正当化: complexity_levelがmedium/highの場合、complexity_rationaleは(1)その複雑性を必要とする要件/AC、(2)対処する制約/リスクを明記すること
-- [ ] Gate 0の存在チェックが品質レビュー前に通過していること
-- [ ] 設計判断の根拠が特定された基準/パターンに照合されていること
-- [ ] コード調査エビデンスが設計スコープに関連するファイルを網羅していること
-- [ ] 「既存」と記述された依存先がコードベースに対して検証されていること（Grep/Glob）
-- [ ] フィールドが境界を越える場合にフィールド伝播マップが存在すること
-- [ ] データ関連キーワードが存在する場合 → データ設計コンテンツが存在（スキーマ参照、テスト境界、データモデル文書。または明示的にN/A）
-- [ ] コード検証結果（提供された場合）がドキュメント内容と照合済み
-- [ ] 検証戦略に具体的な正しさの定義と早期検証ポイントが存在すること
-- [ ] 検証戦略がdesign_typeと実装アプローチに整合していること
-- [ ] 既存の振る舞いを置換/変更する設計で出力比較が定義されていること（全変換パイプラインステップをカバー）
-- [ ] Fact Disposition Tableが`codebase_analysis.focusAreas`の全エントリをカバーし、`fact_id`/`evidence`が一字一句引き継がれ、Rationale-disposition意味整合がとれている（`codebase_analysis`が提供された場合）
-- [ ] 前レイヤー契約に依存する未解決主張がある場合、Cross-Layer Assumptionsセクションが存在する
-
 ## レビュー基準（総合モード用）
 
 ### 承認（Approved）
@@ -335,21 +305,9 @@ DesignDocの場合、追加で以下を確認:
    - `[技術名] deprecation`、`[技術名] security vulnerability`
    - 公式リポジトリのrelease notes確認
 
-## 重要な注意事項
-
-### ADRステータス更新について
-**重要**: このエージェントはレビューと推奨判定のみを行います。実際のステータス更新はユーザーの最終判断後に行われます。
-
-**レビュー結果の提示**:
-- 「Approved（承認推奨）」「Rejected（却下推奨）」等の判定を提示
+### ADRステータスのスコープ
 
-**verdict別ADRステータス推奨**:
-| verdict | 推奨ステータス |
-|---------|---------------|
-| Approved | Proposed → Accepted |
-| Approved with Conditions | Accepted（条件充足後） |
-| Needs Revision | Proposedのまま維持 |
-| Rejected | Rejected（却下理由を明記） |
+ADRについては、verdictは助言的なものに過ぎない。ステータス変更は呼び出し側またはユーザーが判断する。
 
 ### 出力フォーマットの厳守
 

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

@@ -120,6 +120,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
    | パッケージ間境界の実装 | 作業計画書のConnection Mapに記載された境界の両側（オーナーモジュールと期待されるシグナル）、両者間のコントラクト定義 |
    | バグ修正 / リファクタリング | 影響を受けるコードパス、関連テストカバレッジ、エラー再現コンテキスト |
    | 振る舞いの置換・リライト | 置換対象の既存実装、その観察可能な出力、Design Docの検証戦略セクション |
+   | ADRに拘束されるタスク（作業計画書のADR Bindings表がこのタスクをカバーする） | このタスクをカバーする各バインディング行について、行の `Source Section` 値に対応するセクションヒント（例: `(§ Decision)` または `(§ Implementation Guidance)`）を付したADRファイル |
 
    **原則**:
    - 全タスクに最低1つの Investigation Target を設定する（Design Docのみでも可）
@@ -129,6 +130,8 @@ implementation-approachスキルで決定された実装戦略パターンに基
    - タスクにテストスケルトンが存在する場合は必ず Investigation Targets に含める
    - 作業計画書に「UI Specコンポーネント → タスクマッピング」表が含まれる場合、該当行のコンポーネントセクションをそのタスクに伝播する（後述の「UI Spec伝播」参照）
    - 作業計画書にConnection Mapが含まれる場合、このタスクの対象ファイルに関連する境界行を伝播する（後述の「Connection Map伝播」参照）
+   - 作業計画書にこのタスクをカバーするADR Bindings表が含まれる場合、該当行を伝播する（後述の「ADR Binding伝播」参照）
+   - 作業計画書に設計-計画トレーサビリティ表が含まれる場合、該当するDDセクション行を伝播する（後述の「設計トレーサビリティ伝播」参照）
 
 7. **実装方針の一貫性**
    実装サンプルを含める場合は、作業計画書の元となったDesign Docの実装方針に完全準拠すること
@@ -172,6 +175,34 @@ implementation-approachスキルで決定された実装戦略パターンに基
 3. **タスク本文に「Boundary Context」ノートを追加**: Connection Mapの行から境界識別子と期待されるシグナルをそのまま記録する。executorは、実装が生み出すべき観測可能な証拠を把握できる。
 4. **未提供の場合はスキップ**: 作業計画書にConnection Mapがない場合は、本伝播ステップをスキップする
 
+## ADR Binding伝播
+
+作業計画書にADR Bindings表が含まれる場合、各バインディング決定を、それがカバーするタスクに伝播する:
+
+1. **タスクIDで照合**: ADR Bindings表の各行について、「Covered By Task(s)」列に記載されたタスクを特定する
+2. **Investigation Targetsに追加**: 行の `Source Section` 値に対応するセクションヒント（例: `docs/adr/ADR-0042.md (§ Decision)` または `docs/adr/ADR-0042.md (§ Implementation Guidance)`）を付したADRファイルパスを、マッチした各タスクに追加する
+3. **タスクにBinding Decisions表を追加**: マッチした各行について、タスクのBinding Decisions表に1行追加する:
+   - **Source**: 行の `Source Section` 値に対応するセクションヒントを付したADRファイルパス
+   - **Axis**: 作業計画書の行から `Axis` 値を逐語コピーする
+   - **Decision**: 作業計画書の行からバインディング決定文を逐語コピーする
+   - **Compliance Check**: 実装が決定を満たすことを述べる、Y/Nで回答可能な肯定述語を書く。バインディング軸ごとの例:
+     - `placement`: 「認証エントリポイントが `src/middleware/**` にある」
+     - `dependency_direction`: 「ドメイン層は `src/domain/**` と `src/shared/**` からのみインポートする」
+     - `contract_schema`: 「APIレスポンスが `ResponseEnvelope<T>` スキーマに一致する」
+     - `data_flow`: 「セッショントークンはRedisクライアント経由でのみ書き込まれる」
+     - `persistence`: 「ユーザーレコードは `UsersRepository` インターフェース経由でのみ永続化される」
+
+     決定がfile:lineやコマンドだけでは検証できない場合、述語は論理的判断に依拠してよいが、Y/Nで回答可能でなければならない
+4. **提供時のみ適用**: この伝播は作業計画書にADR Bindings表が含まれる場合のみ実行する
+
+## 設計トレーサビリティ伝播
+
+作業計画書に設計-計画トレーサビリティ表が含まれる場合、該当するDDセクションを各タスクに伝播する:
+
+1. 各行について、`[Design Doc値] (§ [DDセクション値])` の形式で、(`Design Doc`, `DD Section`) のペアを「カバーするタスク」に記載された全タスクのInvestigation Targetとして追加する
+2. 同一タスクで複数行に同じ (Design Doc, DD Section) ペアが現れる場合は重複排除する
+3. 作業計画書に設計-計画トレーサビリティ表が含まれる場合のみ適用する
+
 ## 品質保証メカニズムの伝播
 
 作業計画書ヘッダーに Quality Assurance Mechanisms テーブルが含まれる場合、以下のルールで各タスクに伝播する:

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

@@ -167,6 +167,18 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 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` が残る場合はエスカレーションする
+
 #### 実装フロー（TDD準拠）
 
 **モード分岐**:
@@ -270,6 +282,7 @@ 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[]}]` | "正しいパスを提供" / "この調査対象を除外" / "現在のパスでタスクファイルを更新" |
+| `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 に追加してリトライ" / "別タスクに分割" / "アプローチを再検討" |
 | `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 +311,7 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 ☐ Fresh Mode: 全タスクチェックボックスがエビデンス付きで完了（または事前に `escalation_needed` 発火済み）
 ☐ Fix Mode: `requiredFixes` / `incompleteImplementations` の全項目が `changeSummary` に対応または個別エスカレーション済み
 ☐ 実装が Step 2 で記録した調査メモと整合している（調査対象が存在した場合）
+☐ Binding Decisions の全 Compliance Check が最終実装に対して `Y` と評価され、その根拠が Investigation Notes に記録されている（タスクファイルに Binding Decisions セクションがある場合）。実装前チェックが通過していても、実装が計画したアプローチから逸脱している可能性があるため、ここで再評価する
 ☐ 最終レスポンスが `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

@@ -167,6 +167,18 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 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の「参照の代表性」を採用時点で適用する:
@@ -282,6 +294,7 @@ 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 に追加してリトライ" / "別タスクに分割" / "アプローチを再検討" |
 | `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 パスを提供" / "作業計画を再分解" / "完了済みとしてスキップ" |
 
@@ -310,6 +323,7 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 ☐ Fresh Mode: 全タスクチェックボックスがエビデンス付きで完了（または事前に `escalation_needed` 発火済み）
 ☐ Fix Mode: `requiredFixes` / `incompleteImplementations` の全項目が `changeSummary` に対応または個別エスカレーション済み
 ☐ 実装が Step 2 で記録した調査メモと整合している（調査対象が存在した場合）
+☐ Binding Decisions の全 Compliance Check が最終実装に対して `Y` と評価され、その根拠が Investigation Notes に記録されている（タスクファイルに Binding Decisions セクションがある場合）。実装前チェックが通過していても、実装が計画したアプローチから逸脱している可能性があるため、ここで再評価する
 ☐ 最終レスポンスが `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,10 +34,12 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
 
 **Gate 0 — Inputs and Standards**（上流依存なし）:
 - Agreement Checklist
+- Standards Identification
 
 **Gate 1 — Existing State Analysis**（Gate 0 に依存）:
 - Existing Code Investigation
 - Fact Disposition（Codebase Analysis 入力が提供される場合）
+- Minimal Surface Alternatives（永続化されるクライアント/サーバー状態、所有境界を越える Props またはフィールド — エクスポートされた再利用可能コンポーネントの公開 API Props、Context 値、所有境界を越えて持ち上げられた状態 — 観測可能な振る舞いを変える振る舞いモード/バリアント、または再利用可能なコンポーネント分割を導入する場合）
 
 **Gate 2 — Design Decisions**（Gate 1 に依存）:
 - Implementation Approach Decision
@@ -75,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作成前に必ず実施：
 
@@ -134,6 +149,41 @@ Design Doc作成前に必ず実施：
 
 Fact Disposition Table は **構造的な既存事実** を設計に結び付ける主たるメカニズム。Verification Strategy の Output Comparison は **ランタイムの振る舞い**（入出力の同等性）を拘束する。Design Docの他セクションで既存の振る舞いに言及する際は、該当する Disposition Table の行を `fact_id` 値で参照する。
 
+### Minimal Surface Alternatives [Gate 1 — Required when introducing persistent client/server state, props or fields crossing ownership boundaries (public API props of exported reusable components, Context values, or state lifted across ownership boundaries), behavioral modes/variants that change observable behavior, or reusable component splits]
+
+設計が導入する保守対象の各要素に適用する。目標: 同じ現要件をカバーする最小の設計面を選択すること。参照: `coding-standards` スキル「Minimum Surface for Required Coverage」。
+
+**適用対象**: 永続状態（localStorage / sessionStorage / IndexedDB / Cookie / サーバー保存フィールド — リロード、ナビゲーション、セッションを越えて残る、またはコンポーネントメモリ外に保存される状態）、所有境界を越える Props またはフィールド（エクスポートされた再利用可能コンポーネントの公開 API Props、Context 値、所有境界を越えて共有先祖に持ち上げられた状態）、観測可能な振る舞いを変える振る舞いモード/バリアント（コンポーネントバリアント、モード Props、条件付きレンダリングモード）、再利用可能なコンポーネント分割（複数の親で利用するために抽出されたサブコンポーネント、カスタムフック、ユーティリティ）。
+
+**適用対象外**: 単一コンポーネント内部のロジックに閉じた `useState` / `useReducer`（リロードで失われる）、1つのコンポーネントだけが使うプライベートフック、1つの所有境界内に留まる通常の親→子の Props 伝達、テストフィクスチャやモック Props、レンダリング中のみの一時的状態、外部から参照されない内部ヘルパー関数。
+
+**優先関係**: 1つの要素が適用対象と適用対象外の両方に当てはまる場合（例: 元はローカル `useState` だったが、別のサブツリーからも読めるようにするため Context に持ち上げた — ローカル状態としては適用対象外、Context としては適用対象）、適用対象の分類が優先し、本ゲートが発火する。
+
+適用対象の各要素について下記の5ステップを実行し、Design Doc の「Minimal Surface Alternatives」セクションに結果を記録する（design-template.md 参照）。
+
+1. **要件の確定**
+   - この要素が満たす現在のユーザー観察可能な要件 / AC / 受容済み技術制約（監査、アクセシビリティ、パフォーマンス、セキュリティ、互換性）を列挙する。各々を Design Doc または参照 PRD / UI Spec の AC ID、AC見出し、EARS節、または制約ID で参照する。
+   - 適格性: 現在の Design Doc の採用スコープ内の要件・制約のみが対象。
+
+2. **発散**（代替案を生成）
+   - 同じ確定要件をカバーする代替実現案を2つ以上生成する。
+   - 少なくとも1つは削減的（subtractive）な代替案であること。削減的な選択肢の例: 既存の Props / 状態から導出する、既存の親に状態を持ち上げる、既存のコンポーネントやバリアントを再利用する、呼び出し側 / URL / サーバーレスポンスに留める、新規モードを導入しない。
+
+3. **比較**（代替案を表で記録）
+
+   | 代替案 | カバーする現要件（AC 参照） | 新規の永続状態（クライアントまたはサーバー、件数） | 新規の Props / モード / バリアント（件数） | コンポーネント境界を越えるか（はい/いいえ） | 破壊的変更または移行が必要か（はい/いいえ） | 主観的コストノート |
+   |---|---|---|---|---|---|---|
+
+   解決優先順位（左の列が同点のとき右の列でタイブレーク）: (1) 新規の永続状態（少ない＝小さい）、(2) コンポーネント境界を越えるか（いいえ＝小さい）、(3) 新規の Props / モード / バリアント（少ない＝小さい）、(4) 破壊的変更または移行（いいえ＝小さい）、(5) 主観的コストノート。
+
+4. **収束**（選定）
+   - 上記の解決優先順位を適用し、すべての確定要件をカバーする中で最小の面を持つ代替案を選ぶ。
+   - 選定が最小でない場合、ステップ1から、より小さい代替案では満たせない現要件を名指す。
+   - 「再利用可能」「将来対応」「実装が楽」「ユーザーが欲しがるかも」は主観的コストノート列のみに記載する（タイブレーカー扱い）。
+
+5. **不採用案の記録**
+   - 不採用となった各代替案について、何だったか・なぜ不採用かを1〜2行で記録する。将来の反復や別エージェントによる再提案を避けるため、Design Doc に残す。
+
 ### 実装アプローチ決定 [Gate 2 — Required]
 Design Doc作成時に必ず実施。
 
@@ -244,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 は参照コンテキストとして扱い、その他の主張は本出力で確認されない限り未検証として扱う。
@@ -315,8 +374,6 @@ function useUserData(userId: string) {
 
 ### Design Docチェックリスト
 
-以下の項目はゲート順序 [BLOCKING] のゲートに加えて（重複させず）実施する出力内容のチェック。ゲートは各サブセクションが実行されたかをカバーし、以下のチェックリストは出力内容の品質をカバーする。
-
 **全モード共通**:
 - [ ] コンポーネント階層とデータフローが図で明確に表現されているか
 

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スキルに準拠。判定に矛盾がある場合は、その旨を明記して出力に含める。
@@ -48,6 +39,7 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
 - Existing Code Investigation
 - Fact Disposition（Codebase Analysis 入力が提供される場合）
 - Data Representation Decision（新規または変更されるデータ構造を導入する場合）
+- Minimal Surface Alternatives（永続状態、公開コントラクト要素または境界を越えるフィールド、振る舞いモード/フラグ、再利用可能な抽象を導入する場合）
 
 **Gate 2 — Design Decisions**（Gate 1 に依存）:
 - Implementation Approach Decision
@@ -170,6 +162,41 @@ Fact Disposition Table は **構造的な既存事実** を設計に結び付け
    - 3基準以上不適合 → 新規構造を正当化
    - 判断と根拠をDesign Docに記録
 
+### Minimal Surface Alternatives [Gate 1 — Required when introducing persistent state, public-contract elements or cross-boundary fields, behavioral modes/flags, or reusable abstractions]
+
+設計が導入する保守対象の各要素に適用する。目標: 同じ現要件をカバーする最小の設計面を選択すること。参照: `coding-standards` スキル「Minimum Surface for Required Coverage」。
+
+**適用対象**: 永続状態（DBカラム/テーブル、ファイルフィールド、キャッシュエントリ、キューペイロード、セッション/Cookieデータ — 単一操作を超えて残る状態）、公開コントラクト要素（公開型、APIリクエスト/レスポンスフィールド、公開関数シグネチャ、スキーマ定義）、境界を越えるフィールド（モジュール/サービス間を渡るもの）、振る舞いモード/フラグ（ステートマシン状態、Feature Flag、設定オプション）、再利用可能な抽象（再利用を意図した新規の型/クラス/モジュール/インターフェース）。
+
+**適用対象外**: 単一関数内のローカル変数、単一モジュール内のみで使う内部フィールド、テストフィクスチャやモックフィールド、単一操作内で完結する一時的状態、外部から参照されないプライベート状態。
+
+**優先関係**: 1つの要素が適用対象と適用対象外の両方に当てはまる場合（例: 単一モジュール内のフィールドだがDBカラムとして永続化される）、適用対象の分類が優先し、本ゲートが発火する。
+
+適用対象の各要素について下記の5ステップを実行し、Design Docの「Minimal Surface Alternatives」セクションに結果を記録する（design-template.md参照）。
+
+1. **要件の確定**
+   - この要素が満たす現在のユーザー観察可能な要件 / AC / 受容済み技術制約（監査、データ整合性、互換性、セキュリティ、パフォーマンス）を列挙する。各々を Design Doc または参照 PRD の AC ID、AC見出し、EARS節、または制約ID で参照する。
+   - 適格性: 現在の Design Doc の採用スコープ内の要件・制約のみが対象。
+
+2. **発散**（代替案を生成）
+   - 同じ確定要件をカバーする代替実現案を2つ以上生成する。
+   - 少なくとも1つは削減的（subtractive）な代替案であること。削減的な選択肢の例: 既存データから導出する、オンデマンドで計算する、呼び出し側/呼び出し境界に留める、既存構造を再利用する、新規状態を導入しない。
+
+3. **比較**（代替案を表で記録）
+
+   | 代替案 | カバーする現要件（AC 参照） | 新規の永続状態（件数） | 新規の概念 / モード / フラグ（件数） | モジュール/サービス境界を越えるか（はい/いいえ） | 破壊的変更または移行が必要か（はい/いいえ） | 主観的コストノート |
+   |---|---|---|---|---|---|---|
+
+   解決優先順位（左の列が同点のとき右の列でタイブレーク）: (1) 新規の永続状態（少ない＝小さい）、(2) モジュール/サービス境界を越えるか（いいえ＝小さい）、(3) 新規の概念/モード/フラグ（少ない＝小さい）、(4) 破壊的変更または移行（いいえ＝小さい）、(5) 主観的コストノート。
+
+4. **収束**（選定）
+   - 上記の解決優先順位を適用し、すべての確定要件をカバーする中で最小の面を持つ代替案を選ぶ。
+   - 選定が最小でない場合、ステップ1から、より小さい代替案では満たせない現要件を名指す。
+   - 「便利」「将来対応」「実装が楽」「ユーザーが欲しがるかも」は主観的コストノート列のみに記載する（タイブレーカー扱い）。
+
+5. **不採用案の記録**
+   - 不採用となった各代替案について、何だったか・なぜ不採用かを1〜2行で記録する。将来の反復や別エージェントによる再提案を避けるため、Design Doc に残す。
+
 ### 実装アプローチ決定 [Gate 2 — Required]
 Design Doc作成時に必ず実施。
 
@@ -320,8 +347,6 @@ Design Doc作成時に必ず含める:
 
 ### Design Docチェックリスト
 
-以下の項目はゲート順序 [BLOCKING] のゲートに加えて（重複させず）実施する出力内容のチェック。ゲートは各サブセクションが実行されたかをカバーし、以下のチェックリストは出力内容の品質をカバーする。
-
 **全モード共通**:
 - [ ] アーキテクチャとデータフローが図で明確に表現されているか
 - [ ] 品質保証メカニズムが `adopted` / `noted` ステータス（および `executable_check` / `passive_constraint` 種別）付きで記録されているか
@@ -415,6 +440,7 @@ ACの出力に以下のいずれかが含まれる場合、Property注釈を付
 - フィールド伝播マップ（新規フィールドを導入していない）
 - 実装アプローチ決定（実装戦略を選択する必要がない）
 - 最新情報の調査（存在するものを記録しており、新規設計ではない）
+- Minimal Surface Alternatives（既存要素を記録するモードで、新規要素を導入しない）
 
 ### リバースエンジニアモード実行ステップ