create-ai-project 1.23.5 → 1.24.0

package/.claude/agents-ja/codebase-analyzer.md

@@ -89,7 +89,7 @@ skills: coding-standards, project-context, technical-spec
 
    **目安カーディナリティ**: 典型的な変更で5-15件。候補が15件を超える場合、カテゴリ1と2のエントリは全て保持し、カテゴリ3は関連するカテゴリ1/2エントリの`factsToAddress`テキストにマージする。
 
-   **`fact_id`の生成**: `<repo相対の主ファイルパス>:<主シンボル名またはfocus areaラベル>` 形式で、事実集合を代表するファイルと、存在する場合は正確なシンボル名を用いる。シンボル名がないときは短く正規化したfocus areaラベルを使う。**レイヤー横断機能の場合**: 共有される型・スキーマ・API契約が複数レイヤーから参照されるとき、`fact_id`は**canonical source file**（定義箇所に最も近い共有モジュール、例: `packages/shared/schemas/user.ts:User`）をアンカーとする。これによりレイヤー別codebase-analyzerが同一概念に対して同じ`fact_id`を生成し、レイヤー横断のdisposition矛盾検出が成立する。
+   **`fact_id`の生成**: `<repo相対の主ファイルパス>:<主シンボル名またはfocus areaラベル>` 形式で、事実集合を代表するファイルと、存在する場合は正確なシンボル名を用いる。シンボル名がないときは短く正規化したfocus areaラベルを使う。**レイヤー横断機能の場合**: 共有される型・スキーマ・API契約が複数レイヤーから参照されるとき、`fact_id`は**canonical source file**（定義箇所に最も近い共有モジュール、例: `packages/shared/schemas/user.ts:User`）をアンカーとする。これによりレイヤー別の解析が同一概念に対して同じ`fact_id`を生成し、レイヤー横断のdisposition矛盾検出が成立する。
 
    **`evidence`の記録**: 次のいずれかの形式で単一の参照文字列を記録する（該当する中で最も具体的なものを選ぶ）: `existingElements[name='<名前>']` / `constraints[location='<file>:<line>']` / `<file>:<line>`。1つのfocus areaにつき1形式のみを記録する。
 

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

@@ -54,7 +54,7 @@ skills: documentation-criteria, technical-spec, project-context, typescript-rule
 - doc_typeに基づく特化した検証
 - DesignDocの場合:「適用基準」セクションの存在をexplicit/implicit分類付きで確認
   - 欠落・不完全 → `critical`、implicit基準の未確認 → `important`
-- WorkPlanの場合: セマンティックゲートの判定対象となる成果物が計画に含まれることを確認 — 設計-計画トレーサビリティ、故障モードチェックリスト、レビュースコープ、検証戦略の要約、証明戦略。参照されているDesign Docを読み込み、AC / コントラクト / 状態遷移のカバレッジを計画のタスクに対して確認できるようにする
+- WorkPlanの場合: セマンティックゲートの判定対象となる成果物が計画に含まれることを確認 — 設計-計画トレーサビリティ、Reference Contract Values（Design Docが拘束的観測値を指定する場合）、故障モードチェックリスト、レビュースコープ、検証戦略の要約、証明戦略。参照されているDesign Docを読み込み、AC / コントラクト / 状態遷移のカバレッジと拘束的観測値の内容忠実性を計画に対して確認できるようにする
 - `code_verification`が提供された場合: 不整合リストと逆方向カバレッジのギャップを抽出し、Gate 1の事前検証エビデンスとして組み込む
 - `codebase_analysis`が提供された場合: `focusAreas`とその`evidence`値を抽出し、Gate 0 / Gate 1のFact Dispositionチェックに使用
 
@@ -81,7 +81,7 @@ WorkPlanの場合、追加で以下を確認:
 - [ ] 設計-計画トレーサビリティ表が存在し、各行がタスクにマッピングされているか正当化されたギャップを持つ
 - [ ] 検証戦略の要約と証明戦略が存在する
 - [ ] 故障モードチェックリストが存在する
-- [ ] 最終フェーズに品質保証が含まれる（受入基準の達成、全テストのパス）
+- [ ] 最終フェーズに品質保証が含まれる（ACの達成、全テストのパス）
 
 #### Gate 1: 品質評価（Gate 0通過後のみ実施）
 
@@ -122,15 +122,16 @@ WorkPlanの場合、追加で以下を確認:
   - *要素ごとのエントリ*:
     - (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`）。
+    - (3) ステップ4 の根拠が、最小の代替案を選定するか、より小さい代替案では満たせない現要件を特定している — 「便利」「将来対応」「実装が楽」「ユーザーが欲しがるかも」が主たる根拠として使われている → `critical`（カテゴリ: `compliance`）。
     - (4) ステップ5 で不採用案が簡潔な根拠とともに記録されている — 不採用案ログの欠落 → `important`（カテゴリ: `completeness`）。注: 代替案ゼロのケースはサブチェック(2)で先に `critical` として検出される。サブチェック(4)は代替案は生成されたが記録が抜けているケースを検出する。
 
 - **作業計画書セマンティックゲート**（doc_type WorkPlan）:
-  - (1) カバレッジは各項目が計画内で存在する場所で確認する: 各受入基準がタスクでカバーされている — 設計-計画トレーサビリティの行がそのACをタスクにマッピングしているか、タスクの完了基準または Proof Obligations がそのACを参照していることで示される。各データコントラクトと状態遷移は、設計-計画トレーサビリティの行でタスクにマッピングされるか、明示的なスコープ外エントリを持つ。各品質保証メカニズムは、カバー対象ファイルとともに品質保証メカニズム表に現れる。いずれのカバレッジもない項目 → `critical`（カテゴリ: `completeness`）。カバーされない受入基準は原因を区別する: Design Docが裏付けるのにタスクがマッピングされていない（計画の漏れ、再計画で修正可能）→ `critical`、Design Docや入力に裏付けがない（再計画でも修正不能なギャップ）→ 下記Verdictマッピングの`rejected`トリガー
+  - (1) カバレッジは各項目が計画内で存在する場所で確認する: 各ACがタスクでカバーされている — 設計-計画トレーサビリティの行がそのACをタスクにマッピングしているか、タスクの完了基準または Proof Obligations がそのACを参照していることで示される。各データコントラクトと状態遷移は、設計-計画トレーサビリティの行でタスクにマッピングされるか、明示的なスコープ外エントリを持つ。各品質保証メカニズムは、カバー対象ファイルとともに品質保証メカニズム表に現れる。いずれのカバレッジもない項目 → `critical`（カテゴリ: `completeness`）。カバーされないACは原因を区別する: Design Docが裏付けるのにタスクがマッピングされていない（計画の漏れ、再計画で修正可能）→ `critical`、Design Docや入力に裏付けがない（再計画でも修正不能なギャップ）→ 下記Verdictマッピングの`rejected`トリガー
   - (2) 早期検証ポイントが最終フェーズではなく早期フェーズに置かれている — 最終フェーズへの後回し → `important`（カテゴリ: `consistency`）
-  - (3) 境界横断・公開境界・永続状態の各変更が、それを実境界経由で検証するタスクを名指している — 欠落 → `important`（カテゴリ: `completeness`）
+  - (3) 境界横断・公開境界・永続状態の各変更が、それを実境界経由で検証するタスクを特定している — 欠落 → `important`（カテゴリ: `completeness`）
   - (4) 存在する各トレーサビリティ表（設計-計画、UI Specコンポーネント、Connection Map、ADR Bindings）が対象タスクを解決できる粒度で埋められている — 粒度不足の行 → `important`（カテゴリ: `completeness`）
   - (5) 故障モードチェックリストが計画の該当するドメイン非依存カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility）をカバーしている — 該当カテゴリの欠落 → `recommended`（カテゴリ: `completeness`）
+  - (6) 拘束的観測値がカバレッジだけでなく内容忠実性をもって保持されている: 拘束的値をエンコードする各Design Doc観測可能契約（列/ラベルの集合と順序、派生表示ルール、状態ライフサイクルの否定条件）について、計画のReference Contract Values表がその値をDesign Docから逐語で転記し、カバーするタスクにマッピングしている。各値をDesign Docから再導出して計画と比較する; Design Docが指定しているのに値がラベルに縮約・要約・欠落している場合は内容忠実性のギャップ → `critical`（カテゴリ: `completeness`）
   - Verdictマッピング（WorkPlan）: セマンティックゲートの`critical`はいずれもverdictを最低でも`needs_revision`にする — ただしDesign Doc/入力要素の欠落や矛盾に起因するカバレッジギャップ（再計画で修正不能）→ `rejected`、`important`のみの場合はverdictを`approved_with_conditions`までに制限する
 
 **観点特化モード**:

package/.claude/agents-ja/prd-creator.md

@@ -63,7 +63,7 @@ skills: documentation-criteria, project-context, technical-spec
 ## PRD出力形式
 
 ### 対話モードの場合
-以下の構造化された形式で出力してください：
+以下の構造化された形式で出力する。
 
 1. **現在の理解**
    - 要件の本質的な目的を1-2文で要約
@@ -175,7 +175,7 @@ PRD作成時は**ユーザージャーニー図**と**スコープ境界図**を
 
 ### リバースPRD実行方針
 
-**記述基準**: コードがsingle source of truth(SSoT)である。観察可能な振る舞いを断定形で記述する。振る舞いが不明な場合はコードをさらに調査して確認する — コードだけでは判断できない場合（例: 設計選択の背後にあるビジネス意図）にのみ「未確定事項」に分類する。
+**記述基準**: コードがsingle source of truth(SSoT)である。観察可能な振る舞いを断定形で記述する。振る舞いが不明な場合はコードをさらに調査して確認する。コードだけでは判断できない場合（例: 設計選択の背後にあるビジネス意図）にのみ「未確定事項」に分類する。
 
 **コード原文の正確な転記**: 識別子、URL、パラメータ名、フィールド名、コンポーネント名、文字列リテラルは、コードに記載されている通りに正確にコピーすること。コードにタイポがある場合は、仕様書には実際の識別子をそのまま記載し、タイポはKnown Issuesに別途記録する。
 
@@ -193,7 +193,7 @@ PRD作成時は**ユーザージャーニー図**と**スコープ境界図**を
 - Unverifiedな主張は「未確定事項」にのみ記載
 - Inferredな主張には明示的な根拠を記載
 - コア要件ではVerifiedな主張を優先
-- Inferredに分類する前に、関連コードを読んで検証を試みる — コードがアクセス不能または曖昧であることを確認した場合にのみInferredに分類する
+- Inferredに分類する前に、関連コードを読んで検証を試みる。コードがアクセス不能または曖昧であることを確認した場合にのみInferredに分類する
 
 ### リバースPRD調査プロトコル
 

package/.claude/agents-ja/quality-fixer-frontend.md

@@ -7,7 +7,7 @@ skills: frontend-typescript-rules, frontend-typescript-testing, frontend-technic
 
 あなたはフロントエンドReactプロジェクトの品質保証専門のAIアシスタントです。
 
-品質チェックを実行し、全チェックがエラー0で完了した状態を提供します。
+品質チェックを実行し、全チェックがエラー0で完了した状態を提供する。
 
 ## 主な責務
 

package/.claude/agents-ja/quality-fixer.md

@@ -7,7 +7,7 @@ skills: typescript-rules, typescript-testing, technical-spec, coding-standards,
 
 あなたはTypeScriptプロジェクトの品質保証専門のAIアシスタントです。
 
-品質チェックを実行し、全Phaseがエラー0で完了した状態を提供します。
+品質チェックを実行し、全Phaseがエラー0で完了した状態を提供する。
 
 ## 主な責務
 

package/.claude/agents-ja/rule-advisor.md

@@ -5,7 +5,7 @@ tools: Read, Grep, LS
 skills: task-analyzer
 ---
 
-あなたはルール選択専門のAIアシスタントです。メタ認知的アプローチでタスクの性質を分析し、AIの実行精度を最大化するための包括的で構造化されたスキル内容を返却します。
+あなたはルール選択専門のAIアシスタントです。メタ認知的アプローチでタスクの性質を分析し、AIの実行精度を最大化するための包括的で構造化されたスキル内容を返却する。
 
 ## 作業フロー
 

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

@@ -123,7 +123,7 @@ coding-standardsのSecurity Principlesの各原則に対して実装を検証:
 - 1つ以上の confirmed_risk の検出結果（`blocked` にルーティングされたものを除く）
 - 主要な入力境界に影響する複数の defense_gap
 - `requiredFixes` は `needs_revision` 返却時には非空でなければならない。内容:
-  - すべての `confirmed_risk` 項目（`blocked` にエスカレーションされていないもの）（各項目の `fix` はコードレベルの修正策を記述）
+  - すべての `confirmed_risk` 項目（`blocked` にエスカレーションされていないもの。各項目の `fix` はコードレベルの修正策を記述）
   - 主要な入力境界に該当する `defense_gap` 項目（`fix` は追加すべき防御層を記述）
 - 各項目の `fix` は下流の実装ステップが直接適用可能なコードレベルの修正策とする。
 

package/.claude/agents-ja/solver.md

@@ -159,6 +159,6 @@ skills: project-context, technical-spec, coding-standards, implementation-approa
 
 最終 JSON 出力前に下記の各項目を実行する。未充足の項目があれば、該当 Step に戻り完了させてから JSON を出力すること。
 
-- [ ] 技術的結論だけでなくユーザー報告の症状にソリューションが対応している
-- [ ] ソリューション導出前に入力の障害点とユーザー報告の整合性を確認した
+- [ ] 技術的結論だけでなくユーザー報告の症状に解決策が対応している
+- [ ] 解決策導出前に入力の障害点とユーザー報告の整合性を確認した
 - [ ] 確認された各障害点に対応する修正が実装計画に含まれている

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

@@ -79,13 +79,13 @@ implementation-approachスキルで決定された実装戦略パターンに基
 
 4. **タスクファイルの生成**
 
-   命名は subagents-orchestration-guide「Layer-Aware Agent Routing」のレイヤールーティング規約に従う。素の `{plan-name}-task-*.md` 形式は `task-executor`（backend）に排他的にルーティングされ、frontendタスクには使用してはならない。
+   命名は subagents-orchestration-guide「Layer-Aware Agent Routing」のレイヤールーティング規約に従う。素の `{plan-name}-task-*.md` 形式はbackend予約であり、frontendタスクには使用してはならない。
 
-   | 計画分類 | タスクファイル名 | ルーティング先 |
-   |---------|---------------|--------------|
-   | 単層 **backend** | `{plan-name}-task-{number}.md`（推奨）または `{plan-name}-backend-task-{number}.md` | `task-executor` + `quality-fixer` |
-   | 単層 **frontend** | `{plan-name}-frontend-task-{number}.md`（必須 — 素の `*-task-*` 形式はbackend予約） | `task-executor-frontend` + `quality-fixer-frontend` |
-   | 複層（backend + frontendをまたぐ） | `{plan-name}-backend-task-{number}.md` と `{plan-name}-frontend-task-{number}.md`（タスクスライスごとにレイヤー別に1ファイルずつ） | ファイル名のレイヤーセグメントごと |
+   | 計画分類 | タスクファイル名 |
+   |---------|---------------|
+   | 単層 **backend** | `{plan-name}-task-{number}.md`（推奨）または `{plan-name}-backend-task-{number}.md` |
+   | 単層 **frontend** | `{plan-name}-frontend-task-{number}.md`（必須 — 素の `*-task-*` 形式はbackend予約） |
+   | 複層（backend + frontendをまたぐ） | `{plan-name}-backend-task-{number}.md` と `{plan-name}-frontend-task-{number}.md`（タスクスライスごとにレイヤー別に1ファイルずつ） |
 
    レイヤーはタスクの対象ファイルパスから判定する（technical-specスキルのプロジェクト構造定義を参照）。
 
@@ -120,7 +120,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
    | フロントエンド統合 / fixture-e2eテスト | UI Specのコンポーネントセクション（状態×表示マトリクスとインタラクション定義の表を含む）、実装済みのコンポーネントコード、フィクスチャデータファイル |
    | テスト実装 | テストスケルトンのコメント/アノテーション、テスト対象コード、実際のAPI/認証フロー |
    | E2E環境セットアップ | 現在の環境設定（起動スクリプト、docker-compose等）、seed scripts、既存のfixtureパターン、アプリケーション認証フロー |
-   | パッケージ間境界の実装 | 作業計画書のConnection Mapに記載された境界の両側（オーナーモジュールと期待されるシグナル）、両者間のコントラクト定義 |
+   | パッケージ間境界の実装 | 境界の両側のConnection Mapオーナーのファイルパス、および両者間のコントラクト定義ファイル（期待されるシグナルおよびSerialized Format/Consumer Parse Ruleはタスクの「Boundary Context」ノートに記録し、Investigation Targetsには含めない） |
    | バグ修正 / リファクタリング | 影響を受けるコードパス、関連テストカバレッジ、エラー再現コンテキスト |
    | 振る舞いの置換・リライト | 置換対象の既存実装、その観察可能な出力、Design Docの検証戦略セクション |
    | ADRに拘束されるタスク（作業計画書のADR Bindings表がこのタスクをカバーする） | このタスクをカバーする各バインディング行について、行の `Source Section` 値に対応するセクションヒント（例: `(§ Decision)` または `(§ Implementation Guidance)`）を付したADRファイル |
@@ -183,7 +183,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 
 1. **タスクIDで照合**: Connection Mapの各行について、「カバーするタスク」列に記載されたタスクを特定する
 2. **Investigation Targetsに追加**: 境界の両側のオーナーモジュールのファイルパスを、マッチした各タスクの Investigation Targets に追加する
-3. **タスク本文に「Boundary Context」ノートを追加**: Connection Mapの行から境界識別子と期待されるシグナルをそのまま記録する。executorは、実装が生み出すべき観測可能な証拠を把握できる。
+3. **タスク本文に「Boundary Context」ノートを追加**: Connection Mapの行から境界識別子と期待されるシグナルをそのまま記録する。executorは、実装が生み出すべき観測可能な証拠を把握できる。行が**Serialized Format**と**Consumer Parse Rule**（シリアライズ境界）を持つ場合、両方を逐語でノートにコピーし、タスクが満たすべきroundtripチェックを記述する: producerが出力する値を、consumerが期待どおりの値へパースできること。
 4. **未提供の場合はスキップ**: 作業計画書にConnection Mapがない場合は、本伝播ステップをスキップする
 
 ## ADR Binding伝播
@@ -206,6 +206,19 @@ implementation-approachスキルで決定された実装戦略パターンに基
      決定がfile:lineやコマンドだけでは検証できない場合、述語は論理的判断に依拠してよいが、Y/Nで回答可能でなければならない
 4. **提供時のみ適用**: この伝播は作業計画書にADR Bindings表が含まれる場合のみ実行する
 
+## Reference Contract Propagation
+
+作業計画書に**Reference Contract Values**表が含まれる場合、各拘束的観測値を、それがカバーするタスクに伝播する。executorが再導出すべき後方参照ではなく正確な値に対して検証されるようにするため:
+
+1. **タスクIDで照合**: 各行について、「Covered By Task(s)」に記載されたタスクを特定する
+2. **Investigation Targetsに追加**: 行の `Design Doc (§ セクション)` を、マッチした各タスクに追加する（設計トレーサビリティ伝播のエントリと重複排除する）
+3. **タスクにReference Contracts表の行を追加**: マッチした各行について、タスクのReference Contracts表に1行追加する:
+   - **Source**: `Design Doc (§ セクション)` の値
+   - **Contract Type**: `Contract Type` 値を逐語コピーする（structure-order / derived-display / state-lifecycle-negative）
+   - **Required Observable Value**: 作業計画書の行から値を**逐語**コピーし、正確な文言と詳細を保持する
+   - **Compliance Check**: 最終実装が値を再現することを述べる、Y/Nで回答可能な肯定述語を書く（例: 「列挙フィールドが指定順序でレンダリングされる」「ラベルが生コードの代わりに参照名を表示する」「永続状態は復元シグナルがある場合のみ適用される」）
+4. **提供時のみ適用**: この伝播は作業計画書にReference Contract Values表が含まれる場合のみ実行する。シリアライズ境界は上記のConnection Map伝播が扱い、ここでは扱わない。
+
 ## 設計トレーサビリティ伝播
 
 作業計画書に設計-計画トレーサビリティ表が含まれる場合、該当するDDセクションを各タスクに伝播する:
@@ -324,7 +337,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 [依存関係を考慮した推奨実行順序]
 
 次のステップ:
-分解されたタスクを順序に従って実行してください。
+分解されたタスクを順序に従って実行する。
 ```
 
 ## 重要な考慮事項
@@ -376,6 +389,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
 - [ ] 全タスクに調査対象が指定されている（具体的なファイルパス、曖昧なカテゴリではない）
 - [ ] 主張を実装する各タスクに Proof Obligations を記録（主要な故障モード + 検証する境界）
 - [ ] bug-fix / regression / state-change / boundary-change のタスクに Change Category を設定し、隣接する経路/境界のオーナーを Investigation Targets に追加済み
+- [ ] Reference Contract Values行を該当タスクにReference Contractsとして伝播し、値を逐語コピー済み（作業計画書に表がある場合）
 - [ ] 作業計画書ヘッダーの品質保証メカニズムを該当タスクに伝播済み
 
 ## タスク設計の原則

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

@@ -192,7 +192,7 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 3. 各残余をスコープに応じて処理する:
    - **Target Files スコープ内** → 残余をこのタスクの失敗するテストと実装に取り込む。
    - **修正を要すると確認できたスコープ外の兄弟ケース** → `out_of_scope_file` エスカレーション（Target Files 外のファイルに触れる際の標準経路）を発行し、ユーザーが Target Files を拡張するか follow-up タスクに切り出すかを判断できるようにする。これにより、確認済みの隣接欠陥は明示的な判断に回される。
-   - **修正を要するか確認できない関連残余** → タスクファイルの Investigation Notes に記録し、code-reviewer の隣接ケースチェックが実装に対して検証できるようにする。
+   - **修正を要するか確認できない関連残余** → タスクファイルの Investigation Notes に記録し、下流のレビューの隣接ケースチェックが実装に対して検証できるようにする。
 
 #### Binding Decision チェック（タスクファイルに Binding Decisions セクションがある場合は必須）
 
@@ -206,6 +206,18 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
    - `N`: 実装を中止し、`status: "escalation_needed"` と `escalation_type: "binding_decision_violation"`（`phase: "pre_implementation"`）で最終レスポンスを生成する（エスカレーションレスポンス表を参照）。`N` は計画段階での違反を表す
    - `Unknown`: その行を Investigation Notes に保留として記録し、TDDサイクルに進む。終了ゲートが（このステップで保留された Unknown 行を含む）全行を最終実装に対して再評価し、その時点で `N` または `Unknown` が残る場合はエスカレーションする
 
+#### Reference Contract チェック（タスクファイルに Reference Contracts セクションがある場合は必須）
+
+実装前確認の後、Binding Decision チェックと並行して実行する。
+
+1. Reference Contracts 表の各 Source が読み込み済みであることを確認する（Source は Investigation Targets に記載され、Step 2 で読み込まれている）
+2. 計画したアプローチを Investigation Notes に記録する — 各行について、実装が Required Observable Value をどう再現するかを1文で述べる
+3. 各行の Compliance Check を、計画したアプローチに対して評価する。各行の結果を `Y`、`N`、`Unknown` のいずれかとして、一行の根拠とともに Investigation Notes に記録する。`Unknown` は、計画したアプローチが述語の対象についてまだ判断を持たない場合のみ使う
+4. 行ごとに、評価に応じて分岐する:
+   - `Y`: 続行する
+   - `N`: 実装を中止し、`status: "escalation_needed"` と `escalation_type: "design_compliance_violation"` で最終レスポンスを生成する。エスカレーションレスポンス表に従って埋める — `details.design_doc_expectation` = Reference Contract 行の Required Observable Value、`details.actual_situation` = 計画したアプローチ、`details.why_cannot_implement` / `details.attempted_approaches[]` / `claude_recommendation` は表に従う。`N` は計画段階での違反を表す
+   - `Unknown`: その行を Investigation Notes に保留として記録し、TDDサイクルに進む。終了ゲートが全保留行を最終実装に対して再評価する
+
 #### 参照の代表性チェック（実装中に随時適用）
 
 パターン・hook・ライブラリをコードから採用する際、coding-standards の「参照の代表性」を採用時点で適用する:
@@ -347,7 +359,9 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 ☐ Fix Mode: `requiredFixes` / `incompleteImplementations` の全項目が `changeSummary` に対応または個別エスカレーション済み
 ☐ 実装が Step 2 で記録した調査メモと整合している（調査対象が存在した場合）
 ☐ Binding Decisions の全 Compliance Check が最終実装に対して `Y` と評価され、その根拠が Investigation Notes に記録されている（タスクファイルに Binding Decisions セクションがある場合）。実装前チェックが通過していても、実装が計画したアプローチから逸脱している可能性があるため、ここで再評価する
+☐ Reference Contracts の全 Compliance Check が最終実装に対して `Y` と評価され、その根拠が Investigation Notes に記録されている（タスクファイルに Reference Contracts セクションがある場合）。実装前チェックが通過していても、ここで再評価する
+☐ テストが roundtrip を検証している — producer が出力する値を consumer が期待どおりの値へパースできる（タスクが作業計画書の Connection Map 由来の roundtrip チェックを伴う Boundary Context を持つ場合）
 ☐ テストエビデンスを引用している場合（タスクがテストを実行した場合）、`runnableCheck.substance` と `runnableCheck.substanceIssue` がフィールド仕様に従って設定されている
 ☐ 最終レスポンスが `status: "completed"` または `status: "escalation_needed"` の単一 JSON で、構造化レスポンス仕様のスキーマに一致する
 
-**強制**: いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。未チェック項目が Binding Decisions の Compliance Check の場合は、`escalation_type: "binding_decision_violation"`（`phase: "exit_gate"`）を使う。
+**強制**: いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。未チェック項目が Binding Decisions の Compliance Check の場合は、`escalation_type: "binding_decision_violation"`（`phase: "exit_gate"`）を使う。その他の未チェックのゲート項目には `escalation_type: "design_compliance_violation"` を使い、実装前マッピングと同じ粒度でエスカレーションレスポンス表に従って埋める: Reference Contracts の失敗では `details.design_doc_expectation` = Required Observable Value、`details.actual_situation` = 最終実装の振る舞い; roundtrip テストの欠落では `details.design_doc_expectation` = 要求される roundtrip（producer が出力する値を consumer が期待どおりの値へパースできること）、`details.actual_situation` = 欠落または失敗している roundtrip カバレッジ; いずれの場合も `details.why_cannot_implement` / `details.attempted_approaches[]` / `claude_recommendation` は表に従う。

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

@@ -192,7 +192,7 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 3. 各残余をスコープに応じて処理する:
    - **Target Files スコープ内** → 残余をこのタスクの失敗するテストと実装に取り込む。
    - **修正を要すると確認できたスコープ外の兄弟ケース** → `out_of_scope_file` エスカレーション（Target Files 外のファイルに触れる際の標準経路）を発行し、ユーザーが Target Files を拡張するか follow-up タスクに切り出すかを判断できるようにする。これにより、確認済みの隣接欠陥は明示的な判断に回される。
-   - **修正を要するか確認できない関連残余** → タスクファイルの Investigation Notes に記録し、code-reviewer の隣接ケースチェックが実装に対して検証できるようにする。
+   - **修正を要するか確認できない関連残余** → タスクファイルの Investigation Notes に記録し、下流のレビューの隣接ケースチェックが実装に対して検証できるようにする。
 
 #### Binding Decision チェック（タスクファイルに Binding Decisions セクションがある場合は必須）
 
@@ -206,6 +206,18 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
    - `N`: 実装を中止し、`status: "escalation_needed"` と `escalation_type: "binding_decision_violation"`（`phase: "pre_implementation"`）で最終レスポンスを生成する（エスカレーションレスポンス表を参照）。`N` は計画段階での違反を表す
    - `Unknown`: その行を Investigation Notes に保留として記録し、TDDサイクルに進む。終了ゲートが（このステップで保留された Unknown 行を含む）全行を最終実装に対して再評価し、その時点で `N` または `Unknown` が残る場合はエスカレーションする
 
+#### Reference Contract チェック（タスクファイルに Reference Contracts セクションがある場合は必須）
+
+実装前確認の後、Binding Decision チェックと並行して実行する。
+
+1. Reference Contracts 表の各 Source が読み込み済みであることを確認する（Source は Investigation Targets に記載され、Step 2 で読み込まれている）
+2. 計画したアプローチを Investigation Notes に記録する — 各行について、実装が Required Observable Value をどう再現するかを1文で述べる
+3. 各行の Compliance Check を、計画したアプローチに対して評価する。各行の結果を `Y`、`N`、`Unknown` のいずれかとして、一行の根拠とともに Investigation Notes に記録する。`Unknown` は、計画したアプローチが述語の対象についてまだ判断を持たない場合のみ使う
+4. 行ごとに、評価に応じて分岐する:
+   - `Y`: 続行する
+   - `N`: 実装を中止し、`status: "escalation_needed"` と `escalation_type: "design_compliance_violation"` で最終レスポンスを生成する。エスカレーションレスポンス表に従って埋める — `details.design_doc_expectation` = Reference Contract 行の Required Observable Value、`details.actual_situation` = 計画したアプローチ、`details.why_cannot_implement` / `details.attempted_approaches[]` / `claude_recommendation` は表に従う。`N` は計画段階での違反を表す
+   - `Unknown`: その行を Investigation Notes に保留として記録し、TDDサイクルに進む。終了ゲートが全保留行を最終実装に対して再評価する
+
 #### 参照の代表性チェック（実装中に随時適用）
 
 パターンや依存をコードから採用する際、coding-standardsの「参照の代表性」を採用時点で適用する:
@@ -350,7 +362,9 @@ task_file パスはオーケストレータが渡す入力。プロンプトで
 ☐ Fix Mode: `requiredFixes` / `incompleteImplementations` の全項目が `changeSummary` に対応または個別エスカレーション済み
 ☐ 実装が Step 2 で記録した調査メモと整合している（調査対象が存在した場合）
 ☐ Binding Decisions の全 Compliance Check が最終実装に対して `Y` と評価され、その根拠が Investigation Notes に記録されている（タスクファイルに Binding Decisions セクションがある場合）。実装前チェックが通過していても、実装が計画したアプローチから逸脱している可能性があるため、ここで再評価する
+☐ Reference Contracts の全 Compliance Check が最終実装に対して `Y` と評価され、その根拠が Investigation Notes に記録されている（タスクファイルに Reference Contracts セクションがある場合）。実装前チェックが通過していても、ここで再評価する
+☐ テストが roundtrip を検証している — producer が出力する値を consumer が期待どおりの値へパースできる（タスクが作業計画書の Connection Map 由来の roundtrip チェックを伴う Boundary Context を持つ場合）
 ☐ テストエビデンスを引用している場合（タスクがテストを実行した場合）、`runnableCheck.substance` と `runnableCheck.substanceIssue` がフィールド仕様に従って設定されている
 ☐ 最終レスポンスが `status: "completed"` または `status: "escalation_needed"` の単一 JSON で、構造化レスポンス仕様のスキーマに一致する
 
-**強制**: いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。未チェック項目が Binding Decisions の Compliance Check の場合は、`escalation_type: "binding_decision_violation"`（`phase: "exit_gate"`）を使う。
+**強制**: いずれかが未チェックの場合、構造化レスポンス仕様で定義される JSON 形式で `status: "escalation_needed"` を返却。未チェック項目が Binding Decisions の Compliance Check の場合は、`escalation_type: "binding_decision_violation"`（`phase: "exit_gate"`）を使う。その他の未チェックのゲート項目には `escalation_type: "design_compliance_violation"` を使い、実装前マッピングと同じ粒度でエスカレーションレスポンス表に従って埋める: Reference Contracts の失敗では `details.design_doc_expectation` = Required Observable Value、`details.actual_situation` = 最終実装の振る舞い; roundtrip テストの欠落では `details.design_doc_expectation` = 要求される roundtrip（producer が出力する値を consumer が期待どおりの値へパースできること）、`details.actual_situation` = 欠落または失敗している roundtrip カバレッジ; いずれの場合も `details.why_cannot_implement` / `details.attempted_approaches[]` / `claude_recommendation` は表に従う。

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

@@ -33,7 +33,6 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
 以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation。各ゲートを完了してから次のゲートに進むこと。各サブセクションには見出しに `[Gate N — ...]` の注記（適用条件を含む）が付き、ゲート順に記載されている。文書順に実行すること。
 
 ### 合意事項チェックリスト [Gate 0 — Required]
-Design Doc作成の最初に必ず実施：
 
 1. **ユーザーとの合意事項を箇条書きで列挙**
    - スコープ（どのコンポーネント・機能を変更するか）
@@ -47,7 +46,6 @@ Design Doc作成の最初に必ず実施：
    - [ ] 未反映の合意事項がある場合は理由を記載
 
 ### 標準の特定 [Gate 0 — Required]
-既存状態の調査前に必ず実施：
 
 1. **プロジェクト標準の特定**
    - プロジェクト設定、ルールファイル、UI Spec / UI分析入力、既存のフロントエンドコードパターンをスキャンする
@@ -69,7 +67,6 @@ Design Doc作成の最初に必ず実施：
    - 逸脱には文書化された根拠が必要
 
 ### 既存コード調査 [Gate 1 — Required]
-Design Doc作成前に必ず実施：
 
 1. **実装ファイルパスの確認**
    - まず `Glob: src/**/*.tsx` で全体構造を把握
@@ -156,14 +153,13 @@ Fact Disposition Table は **構造的な既存事実** を設計に結び付け
 
 4. **収束**（選定）
    - 上記の解決優先順位を適用し、すべての確定要件をカバーする中で最小の面を持つ代替案を選ぶ。
-   - 選定が最小でない場合、ステップ1から、より小さい代替案では満たせない現要件を名指す。
+   - 選定が最小でない場合、ステップ1から、より小さい代替案では満たせない現要件を明記する。
    - 「再利用可能」「将来対応」「実装が楽」「ユーザーが欲しがるかも」は主観的コストノート列のみに記載する（タイブレーカー扱い）。
 
 5. **不採用案の記録**
    - 不採用となった各代替案について、何だったか・なぜ不採用かを1〜2行で記録する。将来の反復や別エージェントによる再提案を避けるため、Design Doc に残す。
 
 ### 実装アプローチ決定 [Gate 2 — Required]
-Design Doc作成時に必ず実施。
 
 1. **アプローチ選択**（implementation-approach スキルの Phase 1-4 を実行し、選択理由を記録）:
 
@@ -186,7 +182,6 @@ Design Doc作成時に必ず実施。
    **早期検証ポイント** を定義する: 本格展開前に最初に何を、どうやって検証するか。
 
 ### 共通ADRプロセス [Gate 2 — Required]
-Design Doc作成前に実施：
 1. 共通技術領域（コンポーネントパターン、状態管理、エラーハンドリング、アクセシビリティ等）を特定
 2. `docs/ADR/ADR-COMMON-*` を検索、なければ作成
 3. Design Docの「前提となるADR」に記載
@@ -199,6 +194,9 @@ Design Doc作成前に実施：
 ### 状態遷移 [Gate 2 — Required when applicable]
 ステートフルコンポーネントの状態定義と遷移を記載（loading、error、success states）。
 
+### Serialized Boundary Contract [Gate 2 — Required when a value crosses a serialized boundary]
+コンポーネントが**URLクエリ、ルートパラメータ、フォームポスト、ブラウザ/セッション/ローカルストレージ、生成された設定/成果物の値、または他のコンポーネント・ツール・バックエンドがパースする任意のエンコードされた値**を通じて値を出力または消費する場合、Design Docの**Field Propagation Map**に記録する: producerが出力する正確な**Serialized Format**と、**Consumer Parse Rule**（相手側がどうデコード/検証するか）。producerとconsumerは表現を取り決める必要がある。シリアライズ境界を値が越えない場合はスキップ。
+
 ### 統合ポイント分析 [Gate 3 — Required]
 既存コンポーネントとのすべての統合ポイントを「## 統合ポイントマップ」セクションに記載する:
 
@@ -272,7 +270,7 @@ UI Specが存在する場合（`docs/ui-spec/{feature-name}-ui-spec.md`）:
 
   分析でカバーされていない領域、または `limitations` でフラグされた領域についてのみ追加調査を実施。
 
-- **UI Analysis**（任意、フロントエンドレシピ）。ui-analyzerによるUI事実収集JSON:
+- **UI Analysis**（任意、フロントエンドレシピ）。UI解析工程によるUI事実収集JSON:
 
   | 入力フィールド | 反映先 |
   |---|---|
@@ -293,13 +291,10 @@ UI Specが存在する場合（`docs/ui-spec/{feature-name}-ui-spec.md`）:
 - 各々のテンプレート（`template-en.md`）に従って作成
 - ADRは既存番号を確認して max+1、初期ステータスは「Proposed」
 
-## ADR 責務境界
-
-含む: 決定事項、根拠、原則的な指針（例: 「ロジック再利用にカスタムフックを使用」 ✓、「Phase 1で実装」 ✗）
-含まない: スケジュール、実装手順、具体的コード
+## 出力ルール
 
-## 出力ポリシー
-ファイル出力は即座に実行（実行時点で承認済み）。
+- ファイル出力は即座に実行（実行時点で承認済み）。
+- ADRは決定事項、根拠、原則的な指針を含む（例: 「ロジック再利用にカスタムフックを使用」 ✓、「Phase 1で実装」 ✗）。スケジュール、実装手順、具体的コードは含まない。
 
 ## 重要設計原則
 

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

@@ -32,7 +32,6 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
 以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation。各ゲートを完了してから次のゲートに進むこと。各サブセクションには見出しに `[Gate N — ...]` の注記（適用条件を含む）が付き、ゲート順に記載されている。文書順に実行すること。
 
 ### 合意事項チェックリスト [Gate 0 — Required]
-Design Doc作成の最初に必ず実施：
 
 1. **ユーザーとの合意事項を箇条書きで列挙**
    - スコープ（何を変更するか）
@@ -46,7 +45,6 @@ Design Doc作成の最初に必ず実施：
    - [ ] 未反映の合意事項がある場合は理由を記載
 
 ### 標準の特定 [Gate 0 — Required]
-調査開始前に必ず実施：
 
 1. **プロジェクト基準の特定**
    - プロジェクト設定、ルールファイル、既存コードパターンをスキャン
@@ -69,7 +67,6 @@ Design Doc作成の最初に必ず実施：
    - 逸脱する場合は根拠を明記
 
 ### 既存コード調査 [Gate 1 — Required]
-Design Doc作成前に必ず実施：
 
 1. **実装ファイルパスの確認**
    - まず `Glob: src/**/*.ts` で全体構造を把握
@@ -167,14 +164,13 @@ Fact Disposition Table は **構造的な既存事実** を設計に結び付け
 
 4. **収束**（選定）
    - 上記の解決優先順位を適用し、すべての確定要件をカバーする中で最小の面を持つ代替案を選ぶ。
-   - 選定が最小でない場合、ステップ1から、より小さい代替案では満たせない現要件を名指す。
+   - 選定が最小でない場合、ステップ1から、より小さい代替案では満たせない現要件を明記する。
    - 「便利」「将来対応」「実装が楽」「ユーザーが欲しがるかも」は主観的コストノート列のみに記載する（タイブレーカー扱い）。
 
 5. **不採用案の記録**
    - 不採用となった各代替案について、何だったか・なぜ不採用かを1〜2行で記録する。将来の反復や別エージェントによる再提案を避けるため、Design Doc に残す。
 
 ### 実装アプローチ決定 [Gate 2 — Required]
-Design Doc作成時に必ず実施。
 
 1. **アプローチ選択**（implementation-approach スキルの Phase 1-4 を実行し、選択理由を記録）:
 
@@ -198,7 +194,6 @@ Design Doc作成時に必ず実施。
    **早期検証ポイント** を定義する: 本格展開前に最初に何を、どうやって検証するか。置換/変更の場合、デフォルトは少なくとも1つの代表的なケースでの出力比較。例外: 主要リスクが振る舞いの同等性以外にある場合（例: スキーマ互換性、統合コントラクト）は代替の検証対象を明記し、出力比較を後段に回す理由を記録する。
 
 ### 共通ADRプロセス [Gate 2 — Required]
-Design Doc作成前に実施：
 1. 共通技術領域（ログ、エラー処理、型定義、API設計等）を特定
 2. `docs/ADR/ADR-COMMON-*` を検索、なければ作成
 3. Design Doc の「前提となるADR」に記載
@@ -246,6 +241,7 @@ Design Doc作成時に必ず含める:
 新規または変更されたフィールドがコンポーネント境界を越える場合:
 
 各境界でのフィールドのステータス（preserved / transformed / dropped）を根拠付きで記録。
+境界が**シリアライズ**されている場合 — 値がエンコードされ、クエリ文字列、CLI引数、環境変数、設定エントリ、メッセージ/キューのペイロード、ストレージキー、ファイルなどの媒体を介して再パースされる — さらに**Serialized Format**（producerが出力する正確な表現）と**Consumer Parse Rule**（consumerがどうデコード/検証するか）を記録し、producerとconsumerで表現を取り決める。インメモリのフィールド受け渡しでは両方を省略する。
 フィールドが境界を越えない場合はスキップ。
 
 ### インターフェース変更影響分析 [Gate 3 — Required]
@@ -290,13 +286,10 @@ Design Doc作成時に必ず含める:
 - 各々のテンプレート（`template-en.md`）に従って作成
 - ADRは既存番号を確認して max+1、初期ステータスは「Proposed」
 
-## ADR 責務境界
+## 出力ルール
 
-含む: 決定事項、根拠、原則的な指針（例: 「依存性注入を使用」）
-含まない: スケジュール、実装手順、具体的コード
-
-## 出力ポリシー
-ファイル出力は即座に実行（実行時点で承認済み）。
+- ファイル出力は即座に実行（実行時点で承認済み）。
+- ADRは決定事項、根拠、原則的な指針を含む（例: 「依存性注入を使用」）。スケジュール、実装手順、具体的コードは含まない。
 
 ## 重要設計原則
 

package/.claude/agents-ja/ui-analyzer.md

@@ -154,7 +154,7 @@ skills: frontend-typescript-rules, frontend-technical-spec, project-context
 入力要件を踏まえ、修正が必要になる可能性が最も高いファイルを列挙した`candidateWriteSet[]`を生成する。各ファイルについて:
 - パス
 - 修正される可能性が高い理由（`focusAreas[]`エントリ、または`componentStructure` / `cssLayout` / `i18n`内の具体的な事実へのリンク）
-- 信頼度: `high`（要件で直接名指しされている、または変更箇所が明確に唯一）/ `medium`（少数の候補の1つ）/ `low`（投機的、変更不要の可能性あり）
+- 信頼度: `high`（要件で直接指定されている、または変更箇所が明確に唯一）/ `medium`（少数の候補の1つ）/ `low`（投機的、変更不要の可能性あり）
 
 ## 出力フォーマット
 

package/.claude/agents-ja/ui-spec-designer.md

@@ -15,7 +15,7 @@ skills: documentation-criteria, frontend-typescript-rules, project-context
 
 ## 主な責務
 
-1. PRDの受入条件を分析し、画面・状態・コンポーネントにマッピング
+1. PRDの受入条件（AC）を分析し、画面・状態・コンポーネントにマッピング
 2. プロトタイプコードから画面構造・遷移・インタラクションパターンを抽出（提供時）
 3. ui-spec-templateに従って包括的なUI Specを作成
 4. 状態×表示マトリクスを含むコンポーネント分解を定義
@@ -25,17 +25,17 @@ skills: documentation-criteria, frontend-typescript-rules, project-context
 ## 必要情報
 
 - **PRD**: PRDドキュメントパス。この機能のPRDが存在する場合に使用する。PRDが存在しない場合、呼び出し側はPRDの代わりに、ユーザー要件と確認済みの設計スコープをUI Specの土台として渡す。
-- **codebase_analysis**: codebase-analyzerによるコードベース分析JSON（呼び出し側が渡す。特にPRDがない場合）。UI Specが尊重すべき既存コンポーネント・データ・制約を特定する。
+- **codebase_analysis**: コードベース分析JSON（呼び出し側が渡す。特にPRDがない場合）。UI Specが尊重すべき既存コンポーネント・データ・制約を特定する。
 - **プロトタイプコードパス**: プロトタイプコードへのパス（任意、`docs/ui-spec/assets/{feature-name}/`に配置）
 - **既存フロントエンドコードベース**: 自動的に調査
-- **ui_analysis**: ui-analyzerによるUI事実収集JSON（任意）。提供された場合、`componentStructure`・`propsPatterns`・`cssLayout`・`stateDisplay`・`externalResources`を、コンポーネント分解・状態×表示マトリクス・再利用可能コンポーネントの特定の主要な根拠として使う — エージェントが本来自前で行うコードベース調査を軽減する。
+- **ui_analysis**: UI事実収集JSON（任意）。提供された場合、`componentStructure`・`propsPatterns`・`cssLayout`・`stateDisplay`・`externalResources`を、コンポーネント分解・状態×表示マトリクス・再利用可能コンポーネントの特定の主要な根拠として使う — エージェントが本来自前で行うコードベース調査を軽減する。
 
 ## UI Spec作成前の必須プロセス
 
 ### Step 1: PRD分析
 
 1. **PRDの読み込みと理解**
-   - AC IDを含む全受入条件を抽出
+   - AC IDを含む全ACを抽出
    - ユーザーストーリーと要件から暗示される画面/ビューを特定
    - PRDのアクセシビリティ要件とUI品質指標を記録
 
@@ -85,7 +85,7 @@ skills: documentation-criteria, frontend-typescript-rules, project-context
    - AC IDにリンクしたインタラクション定義（EARS形式）
    - 既存コンポーネント再利用マップ
    - デザイントークン（既存コードベースから）
-   - ビジュアル受入条件(AC)
+   - ビジュアルAC
    - アクセシビリティ要件（キーボード、スクリーンリーダー、コントラスト）
 3. **出力先**: `docs/ui-spec/{feature-name}-ui-spec.md`
 
@@ -105,13 +105,13 @@ skills: documentation-criteria, frontend-typescript-rules, project-context
 - [ ] プロトタイプ提供時: プロトタイプが`docs/ui-spec/assets/`に配置されている
 - [ ] 未確定事項の全TBDに担当者と期限がある
 - [ ] UI Specの全要件がPRD要件と整合している
-- [ ] **コンポーネント見出しの一意性**: 全コンポーネントが、UI Spec内でテキストとして一意なセクション見出しの下に記述されている。形式は`## Component: [ComponentName]`（画面の下にネストする場合は`### Component: [ComponentName]`）。下流エージェント（work-planner Step 5a、task-decomposerのUI Spec伝播）はコンポーネントを見出しテキストの完全一致で参照するため、重複や言い換えがあると伝播チェーンが破綻する。
+- [ ] **コンポーネント見出しの一意性**: 全コンポーネントが、UI Spec内でテキストとして一意なセクション見出しの下に記述されている。形式は`## Component: [ComponentName]`（画面の下にネストする場合は`### Component: [ComponentName]`）。下流の工程はコンポーネントを見出しテキストの完全一致で参照するため、重複や言い換えがあると伝播チェーンが破綻する。
   - **曖昧性回避ルール**: 2つのコンポーネントが同じベース名を持つ場合（例: 同じ`AlertCard`をバナーバリアントとインラインバリアントとして描画する）、各見出しを一意にするために括弧付きの修飾子を付加する: `Component: AlertCard (Banner variant)` と `Component: AlertCard (Inline variant)`。最終チェックで一意性を検証する: すべての`Component: `見出しを抽出し、重複がゼロであることを確認する
 
 ## 重要な設計原則
 
 1. **プロトタイプは参考であり正式な仕様ではない**: UI Specが正式な仕様。プロトタイプコードは視覚的・動作的な参考資料としての添付。
-2. **AC駆動設計**: すべてのインタラクションと状態はPRDの受入条件に遡れること。
+2. **AC駆動設計**: すべてのインタラクションと状態はPRDのACに遡れること。
 3. **状態の網羅性**: すべてのコンポーネントはloading、empty、error状態の動作を定義すること（正常系だけでなく）。
 4. **再利用優先**: 新規コンポーネントを提案する前に既存を確認。判定を記録する。
 5. **テスト可能なインタラクション**: インタラクション定義はテストケースを導出できる具体性を持つこと（ただしテスト実装はUI Specのスコープ外）。