create-ai-project 1.23.5 → 1.24.0

package/.claude/agents-ja/work-planner.md

@@ -21,33 +21,33 @@ skills: documentation-criteria, project-context, technical-spec, implementation-
 
 ### 1. 入力ドキュメントの読み込み
 Design Doc、UI Spec、PRD、ADR（提供されている場合）を読み込み、以下を抽出:
-- 受入条件と実装アプローチ
+- 受入条件（AC）と実装アプローチ
 - 技術的依存関係と実装順序
 - 統合ポイントとそのコントラクト
 - **検証戦略**: 正しさの証明方法（正しさの定義、検証手法、検証タイミング）と早期検証ポイント（最初の検証対象、成功基準、失敗時の対応）
 - **品質保証メカニズム**: Design Docの「品質保証メカニズム」セクションから`adopted`ステータスの全項目を抽出 — 実装時に適用すべき品質ゲート
 
-### 2. テスト設計情報の処理（提供時）
-テストスケルトンファイルを読み込み、メタ情報を抽出（テスト設計情報の処理セクションを参照）。
+### 2. テスト設計情報の取り込み（提供時）
+テストスケルトンファイルを読み込み、メタ情報を抽出する（詳細手順は後述）。
 
 ### 3. 実装戦略の選択
-テストスケルトンが提供されている場合は戦略A（TDD）、そうでなければ戦略B（実装優先）を選択。実装戦略の選択セクションを参照。
+テストスケルトンが提供されている場合は戦略A（TDD）、そうでなければ戦略B（実装優先）を選択する（詳細は後述）。
 
 ### 4. フェーズの構成
 
 **全アプローチ共通**:
 - **検証戦略の要約を作業計画書ヘッダーに記載**（後続タスクへの参照用）
 - **採用した品質保証メカニズムを作業計画書ヘッダーに記載**（後続タスクへの参照用） — 各メカニズムについてツール名、検証内容、設定パス、カバー範囲（Design Docのファイルパスまたはディレクトリプレフィックス、スコープが限定されない場合は "project-wide"）を記載
-- **証明戦略を作業計画書ヘッダーに記載**（plan template参照） — 証明義務の出所（スケルトンが提供される場合はテストスケルトンの注釈、なければ各ACの主要な故障モード）を明示し、主張を実装する各タスクが下流レビュー用に Proof Obligations を記録する旨を記載する
-- **レビュースコープを作業計画書ヘッダーに記録** — 実装前の新規計画では Design Doc とタスク対象ファイルから導出した変更予定ファイルの範囲、既存作業に対する改訂計画ではベースブランチと diff範囲 — を記録し、作業計画書レビューと下流検証が同一スコープを共有できるようにする
+- **証明戦略を作業計画書ヘッダーに記載**（plan template参照） — 証明義務の出所（スケルトンが提供される場合はテストスケルトンの注釈、なければ各ACの主要な故障モード）を明示し、振る舞いの主張を持つ各タスクが、下流のレビュー用に Proof Obligations を記録する旨を記載する
+- **レビュースコープを作業計画書ヘッダーに記録** — 実装前の新規計画では Design Doc とタスク対象ファイルから導出した変更予定ファイルの範囲、既存作業に対する改訂計画ではベースブランチと diff範囲を記録し、作業計画書レビューと下流検証が同一スコープを共有できるようにする
 - **故障モードチェックリストを作業計画書に含める**（plan template参照） — ドメイン非依存の8つの故障カテゴリ（same-value, no-op, empty input, invalid option, missing config, unavailable boundary, shared-state dependency, rollback-only visibility）をすべて列挙し、該当するものに印を付け、該当する各カテゴリをカバーするタスクにマッピングする。エントリにはプロジェクト固有の名称を含めない
-- 検証戦略の検証タイミングに対応するフェーズに検証タスクを配置
+- 検証戦略の実行タイミングに対応するフェーズに検証タスクを配置
 - テストスケルトンが提供されている場合、統合テスト実装を対応するフェーズに配置し、E2Eテスト実行を最終フェーズに配置
-- テストスケルトンが提供されていない場合、Design Docの受入条件に基づくテスト実装タスクを含める
+- テストスケルトンが提供されていない場合、Design DocのACに基づくテスト実装タスクを含める
 - 最終フェーズは常に品質保証
 
 **E2Eギャップチェック（全戦略共通）**:
-利用可能なテストスケルトンを確認した後、2つのE2Eレーン（fixture-e2e、service-integration-e2e — integration-e2e-testingスキル参照）を独立してチェックする。マルチステップユーザージャーニーは以下の条件をすべて満たす場合に存在する: (1) 2つ以上の異なるインタラクション境界が順番に通過される、(2) ステップ間で状態が伝搬する、(3) ジャーニーに完了ポイントがある。**ユーザー向け**ジャーニーとは、人間のユーザーが直接ステップをトリガーし結果を観察するもの（UI、CLI、直接的なAPIインタラクション経由）であり、サービス内部パイプラインは含まない。
+利用可能なテストスケルトンを確認した後、2つのE2Eレーン（fixture-e2e、service-integration-e2e — integration-e2e-testingスキル参照）を独立してチェックする。マルチステップユーザージャーニーは以下の条件をすべて満たす場合に存在する: (1) 2つ以上の異なるインタラクション境界を順番に通過する、(2) ステップ間で状態が伝搬する、(3) ジャーニーに完了ポイントがある。ユーザー向けジャーニーとは、人間が直接ステップをトリガーし結果を観察するもの（UI、CLI、直接的なAPIインタラクション経由）であり、サービス内部パイプラインは含まない。
 
 ```
 fixture-e2e gap:
@@ -55,9 +55,7 @@ fixture-e2e gap:
     AND e2eAbsenceReason.fixtureE2eが伝達されていない
     AND Design DocまたはUI Specにユーザー向けマルチステップジャーニーが含まれる
   THEN 作業計画書ヘッダーに追記:
-    fixture-e2e Gap: この機能にはユーザー向けマルチステップジャーニーが含まれますが、
-    fixture-e2eスケルトンが提供されていません。UI実装フェーズの前に、受入テスト生成
-    へ差し戻して fixture-e2e 候補を評価する。
+    fixture-e2e Gap: この機能にはユーザー向けマルチステップジャーニーが含まれるが、fixture-e2eスケルトンが提供されていない。UI実装フェーズの前に、受入テスト生成へ差し戻して fixture-e2e 候補を評価する。
     検出されたジャーニー: [ジャーニーの説明とAC参照のリスト]
 
 service-integration-e2e gap:
@@ -66,17 +64,15 @@ service-integration-e2e gap:
     AND Design Docがジャーニーに実サービス間検証（複数サービスをまたぐデータ永続化、
         トランザクション整合性、外部サービスコントラクト）を要求する
   THEN 作業計画書ヘッダーに追記:
-    service-integration-e2e Gap: この機能はサービス境界をまたぎ、正しさが
-    実サービス間挙動に依存しますが、service-integration-e2eスケルトンが
-    提供されていません。
+    service-integration-e2e Gap: この機能はサービス境界をまたぎ、正しさが実サービス間挙動に依存するが、service-integration-e2eスケルトンが提供されていない。
     検出された境界: [境界の記述とAC参照のリスト]
 ```
 
-「伝達されていない」分岐は、上流の計画フローがテストスケルトン生成自体をスキップしたシナリオ — その場合、不在理由フィールド自体がwork-plannerに渡されないため、ギャップチェックは依然として走る。acceptance-test-generatorの契約により、スケルトンが生成された場合は `e2eAbsenceReason.<lane>` は null、生成されなかった場合は契約に列挙された文字列となる — どちらもフィールドは「伝達された」状態であり、ギャップ警告は発火しない。
+「伝達されていない」分岐は、上流の計画フローがテストスケルトン生成自体をスキップしたシナリオである。その場合、不在理由フィールド自体が渡されないため、ギャップチェックは依然として走る。テストスケルトン生成の契約により、スケルトンが生成された場合は `e2eAbsenceReason.<lane>` は null、生成されなかった場合は契約に列挙された文字列となる。どちらもフィールドは「伝達された」状態であり、ギャップ警告は発火しない。
 
-レーンの`e2eAbsenceReason`が文字列値（例: `no_multi_step_journey`、`below_threshold_user_confirmed`、`no_real_service_dependency` — レーンごとの許容値はacceptance-test-generatorを参照）を持つ場合、当該レーンの不在は意図的 — そのレーンのギャップチェックをスキップする。
+レーンの`e2eAbsenceReason`が文字列値（例: `no_multi_step_journey`、`below_threshold_user_confirmed`、`no_real_service_dependency`。レーンごとの許容値はテストスケルトン生成の契約を参照）を持つ場合、当該レーンの不在は意図的であるため、そのレーンのギャップチェックをスキップする。
 
-このチェックは戦略AまたはBのどちらが選択されていても適用される。統合テストスケルトンのみの提供はE2Eカバレッジを意味しない。サービス内部ジャーニー（非同期パイプライン、サービス間saga）は予約スロットルールではフラグしない — 通常のROIパスを通じた service-integration-e2e は依然として候補となり得る。
+このチェックは戦略AまたはBのどちらが選択されていても適用される。統合テストスケルトンのみの提供はE2Eカバレッジを意味しない。サービス内部ジャーニー（非同期パイプライン、サービス間saga）は予約スロットルールではフラグしない。通常のROIパスを通じた service-integration-e2e は依然として候補となり得る。
 
 **フェーズ構成**: Design Docの実装アプローチに基づいて選択。詳細はdocumentation-criteriaスキルのフェーズ分割基準を参照。plan-templateのOption A（垂直）またはOption B（水平）に従う。ハイブリッドの場合はOption Aをベースに、必要に応じて水平基盤フェーズを追加する。
 
@@ -96,36 +92,38 @@ service-integration-e2e gap:
 
 カバーするタスクがない項目はギャップステータスを`gap`とし、備考に理由を記載する。**トレーサビリティ表に`gap`が1件でも含まれる場合、計画書はドラフト状態とする。** ドラフトとして出力するが、ユーザーが各ギャップを確認するまで確定しない。理由なしのギャップ（備考が空）はエラーとして扱い、カバーするタスクを追加するか理由を記載してから進める。
 
+**拘束的観測値は逐語のまま転記する。** 拘束的観測値とは、列/ラベルの集合と順序（Contract Type は `structure-order`）、派生表示ルール（別フィールドから導出される表示値である `derived-display`）、または状態ライフサイクルの否定条件（状態が未使用のままでなければならない条件である `state-lifecycle-negative`）を指す。要約を経由すると正確な列/ラベルの順序や派生表示ルールが失われるため、これらは設計-計画トレーサビリティ表の要約されたDD項目からではなく、Design Docから直接特定する。各値はDesign Docから逐語でコピーして計画書の**Reference Contract Values**表（plan template参照）に記録し、値ごとに1行を、そのContract Typeトークンとともにカバーするタスクにマッピングする。値は全文を保持する。これにより、後続のタスクは要約を再構成するのではなく、この正確な値そのものと突き合わせて検証できる。本表が扱うのはDD由来の観測可能契約のみである。シリアライズ境界はConnection Map（ステップ5b）が、ADR由来の構造的決定はADR Bindings表が扱う。
+
 ### 5a. UI Specコンポーネントのタスクへのマッピング（UI Spec提供時）
 
-入力にUI Specが含まれる場合、コンポーネントと状態を実装タスクへマッピングする。task-decomposerは下流ステップでこのマッピングを読み込み、各タスクのInvestigation Targetsに反映する — このステップを行わないとUI Specがexecutorまで届かない。
+入力にUI Specが含まれる場合、コンポーネントと状態を実装タスクへマッピングする。このマッピングは下流ステップで読み込まれ、各タスクのInvestigation Targetsに反映される。この手順を行わないとUI Specが実装まで届かない。
 
 UI Specに記述された各コンポーネントについて:
-1. UI Specに記載されているとおりのセクション見出しを特定する（見出しが参照キー — ui-spec-designerの見出し一意性ルールを参照）
+1. UI Specに記載されているとおりのセクション見出しを特定する（見出しが参照キー。見出しは一意である）
 2. 実装がカバーすべき状態（default / loading / empty / error / partial）を特定する
 3. 当該コンポーネントまたはそのテストを実装する本計画内のタスクを特定する
 
 マッピング結果は **「UI Specコンポーネント → タスクマッピング」表**（plan-template参照）に記録する。コンポーネント1件につき1行。カバーするタスクがないコンポーネントは設計-計画トレーサビリティと同じく `gap` としてユーザー確認を要求する。
 
-### 5b. パッケージ間境界のタスクへのマッピング（実装がランタイム/デプロイ境界をまたぐ場合）
+### 5b. 境界タスクへのマッピング（ランタイム/デプロイ境界をまたぐ場合、または任意の境界をまたいでシリアライズされた値を渡す場合）
 
-実装がランタイムまたはデプロイ境界をまたぐ場合、Connection Mapを作成してtask-decomposerが境界の文脈を各タスクに伝播できるようにする。
+実装がランタイムまたはデプロイ境界をまたぐ場合、**または値がシリアライズされ（単一ランタイム内であっても）任意の境界をまたいで再パースされる場合**、Connection Mapを作成し、下流ステップで境界の文脈が各タスクに伝播されるようにする。
 
-**境界がConnection Mapの対象となるのは、以下の条件をすべて満たす場合のみ**:
-- 両側が別プロセス、別サービス、または別ランタイムで動作する（例: Webクライアント ↔ HTTPサーバ、サービスA ↔ サービスB（ネットワーク経由）、フロントエンドバンドル ↔ バックエンドハンドラ）
-- 両者間でシリアライズされたコントラクトが交わされる（HTTPリクエスト/レスポンス、メッセージエンベロープ、RPC、イベントペイロード）
-- 一方の障害がもう一方で観測可能なシグナルを生む（ステータスコード、フィールド欠落、タイムアウト、メッセージドロップ）
+**境界がConnection Mapの対象となるのは、以下のいずれかの条件を満たす場合**:
+- *クロスプロセス*: 両側が別プロセス、別サービス、または別ランタイムで動作する（Webクライアント ↔ HTTPサーバ、サービスA ↔ サービスB、フロントエンドバンドル ↔ バックエンドハンドラ）。両者間でシリアライズされたコントラクトが交わされる（HTTPリクエスト/レスポンス、メッセージエンベロープ、RPC、イベントペイロード）。かつ一方の障害がもう一方で観測可能なシグナルを生む。
+- *ランタイム内シリアライズ*: 単一ランタイム内であっても、値がエンコードされ境界をまたいで再パースされる場合を指す。具体的には、クエリ文字列、CLI引数、環境変数、設定エントリ、メッセージ/キューのペイロード、ストレージキー、ファイルなどの媒体を介する（例: あるコンポーネントがエンコードした値を別のコンポーネントまたはプロセスが後でデコードする、ストレージに書き込まれ遷移後に読まれる値）。producerとconsumerは同一の表現をあらかじめ取り決めておく必要がある。
 
-**除外 — 以下はConnection Map対象外**:
-- 同一monorepo内での兄弟ユーティリティ、型定義、共有定数のimport（in-process、シリアライズコントラクトなし）
-- 同一ランタイム内のレイヤリング（例: handler → usecase → repository）
+**以下はConnection Map対象外**:
+- 同一monorepo内での兄弟ユーティリティ、型定義、共有定数のimport（in-process、シリアライズされた値なし）
+- 同一ランタイム内で値が型付きインメモリ呼び出しとして渡されるレイヤリング（例: handler → usecase → repository）
 - 同一成果物にコンパイル/バンドルされるソースコード依存
 
 該当する境界それぞれについて:
-1. 境界を特定する（例: `web → API gateway`、`service-A → service-B`、`frontend → shared client → backend handler`）
-2. 両側のオーナーモジュール/パッケージを特定する
-3. 境界が機能していることを裏付ける期待されるシグナルを特定する（例: スキーマXに一致するHTTP 200、トピックYへのメッセージpublish、テーブルZへの行挿入）
-4. 境界の両側を実装するタスクを特定する
+1. 境界を特定する（例: `service A → service B`、`producer → storage → consumer`、`エンコードされたパラメータ経由の component A → component B`）
+2. 両側のオーナー（producerとconsumer）を特定する。後続の工程でそのままInvestigation Targetとして読み取れるよう、モジュール/パッケージ/コンポーネント名ではなく具体的なファイルパスで記録する
+3. シリアライズ境界の場合、**Serialized Format**（producerが出力する正確な表現）と**Consumer Parse Rule**（consumerがどうデコード/検証するか）を記録する。producerとconsumerが値の特定のエンコーディング（クエリ文字列、ストレージキー、CLI引数、設定エントリ、メッセージフィールド）を取り決める必要がある場合に埋める。契約が期待されるシグナルで既に表現されている場合（例: ボディが合意スキーマに一致するクロスプロセス呼び出し）は両方を"—"にする
+4. 境界が機能していることを裏付ける期待されるシグナルを特定する（例: 合意スキーマに一致するレスポンス、consumerがproducerの値を再現すること）
+5. 境界の両側を実装するタスクを特定する
 
 マッピング結果は **「Connection Map」表**（plan-template参照）に記録する。該当する境界がない場合は本セクションを丸ごと省略する。
 
@@ -136,21 +134,21 @@ ADRが入力に含まれる場合、またはDesign Docが「Prerequisite ADRs
 参照される各ADRについて:
 1. ADRパスを解決する（ファイル規約: `docs/adr/ADR-[4桁]-[title].md`）:
    - フルパス（例: `docs/adr/ADR-0042-foo.md`） — そのまま使用
-   - IDのみ（例: `ADR-0042`） — `docs/adr/ADR-0042-*.md` をglobし、一致がちょうど1件であることを要求
+   - IDのみ（例: `ADR-0042`） — `docs/adr/ADR-0042-*.md` をglobし、一致が1件であることを要求
    - ディレクトリなしのファイル名（例: `ADR-0042-foo.md`） — `docs/adr/` を前置
    - globが0件または2件以上一致する場合、または解決したパスが存在しない場合、計画を確定させない。未解決のADR参照をユーザーに報告し、ADR Bindings表を完成させる前に正しいパスを要求する
 
    その後、ADRのDecisionおよびImplementation Guidanceセクションを読む
-2. **実装拘束的**な決定を抽出する — すなわち、5つのバインディング軸（配置、依存方向、コントラクト/スキーマ形状、データフロー、永続化）のいずれかを制約する決定。受入基準と必要な振る舞いはDesign Docに記録される。この表はADR由来の構造的制約のみを扱う
-3. 各バインディング決定を、ちょうど1つの軸（`placement` | `dependency_direction` | `contract_schema` | `data_flow` | `persistence`）に分類する — これが行の `Axis` 値となる
-4. 各バインディング決定について、どのセクション（`Decision` または `Implementation Guidance`）由来かを記録する — これが行の `Source Section` 値となる
-5. 各バインディング決定について、その決定が適用される計画上のタスクを特定する。Target files、レイヤー、またはコンポーネントスコープを使って関連性を判断する — この段階ではレイヤー/コンポーネントレベルのマッピングで十分
+2. **実装拘束的**な決定を抽出する。すなわち、5つのバインディング軸（配置、依存方向、コントラクト/スキーマ形状、データフロー、永続化）のいずれかを制約する決定である。ACと必要な振る舞いはDesign Docに記録される。この表はADR由来の構造的制約のみを扱う
+3. 各バインディング決定を、1つの軸（`placement` | `dependency_direction` | `contract_schema` | `data_flow` | `persistence`）に分類する。これが行の `Axis` 値となる
+4. 各バインディング決定について、どのセクション（`Decision` または `Implementation Guidance`）由来かを記録する。これが行の `Source Section` 値となる
+5. 各バインディング決定について、その決定が適用される計画上のタスクを特定する。Target files、レイヤー、またはコンポーネントスコープを使って関連性を判断する。この段階ではレイヤー/コンポーネントレベルのマッピングで十分
 6. バインディング決定ごとに1行を **ADR Bindings** 表（plan-template参照）に記録する
 
 参照されるADRのいずれにも実装拘束的な決定が含まれない場合は、表を省略する。
 
 ### 6. 完了条件付きタスクの定義
-各タスクについて、Design Docの受入条件から完了条件を導出。3要素の完了定義（実装完了、品質完了、統合完了）を適用。
+各タスクについて、Design DocのACから完了条件を導出。3要素の完了定義（実装完了、品質完了、統合完了）を適用。
 
 ### 7. 出力の生成（scale 別のテンプレート選択）
 
@@ -160,8 +158,8 @@ ADRが入力に含まれる場合、またはDesign Docが「Prerequisite ADRs
 ## Input Parameters
 
 - **mode**: `create`（デフォルト）| `update`
-- **scale**: `small` | `medium` | `large`（requirement-analyzer の判定結果。下記「scale 別の出力モード」で出力形式を切り替える）
-- **designDoc**: Design Docのパス（クロスレイヤー機能の場合は複数）。`scale: small` では Design Doc が存在しない場合があり、その際は requirement-analyzer の出力と PRD 更新メモから直接タスクを導出する。
+- **scale**: `small` | `medium` | `large`（要件分析の判定結果。下記「scale 別の出力モード」で出力形式を切り替える）
+- **designDoc**: Design Docのパス（クロスレイヤー機能の場合は複数）。`scale: small` では Design Doc が存在しない場合があり、その際は要件分析の出力と PRD 更新メモから直接タスクを導出する。
 - **uiSpec**（オプション）: UI Specificationのパス（フロントエンド/フルスタック機能）
 - **prd**（オプション）: PRDドキュメントのパス
 - **adr**（オプション）: ADRドキュメントのパス
@@ -172,8 +170,8 @@ ADRが入力に含まれる場合、またはDesign Docが「Prerequisite ADRs
 
 | scale | 出力 | 保存先 | 理由 |
 |---|---|---|---|
-| `small` | **task-template 形式**の単一タスクファイル（documentation-criteria スキル参照） | `docs/plans/tasks/{feature-name}-task-YYYYMMDD.md` | 1-2 ファイル規模ではタスク分解ステップを分けず、オーケストレーターが task-executor に `task_file` として渡すパスを本エージェントが直接生成する |
-| `medium` / `large` | **plan-template 形式**の作業計画書 | `docs/plans/{feature-name}-plan.md` | 個別タスクファイルへの分解は下流の task-decomposer が実施する |
+| `small` | **task-template 形式**の単一タスクファイル（documentation-criteria スキル参照） | `docs/plans/tasks/{feature-name}-task-YYYYMMDD.md` | 1-2 ファイル規模ではタスク分解ステップを分けず、実行工程へ `task_file` として渡すパスを本エージェントが直接生成する |
+| `medium` / `large` | **plan-template 形式**の作業計画書 | `docs/plans/{feature-name}-plan.md` | 個別タスクファイルへの分解は下流の工程が実施する |
 
 `small` モードではフェーズ構成（Step 4）と設計-計画トレーサビリティ表（Step 5）をスキップし、タスクファイルに `## Target Files`、`## Investigation Targets`、`## Investigation Notes`、`## Implementation Steps (TDD: Red-Green-Refactor)`、`## Quality Assurance Mechanisms`、`## Operation Verification Methods`、`## Completion Criteria` の各セクションと、`Metadata:` ブロック（`Dependencies:`、`Provides:`、`Size:`）を出力する。本スケールでは作業計画書ファイルを別途出力しない。
 
@@ -220,14 +218,13 @@ ADRが入力に含まれる場合、またはDesign Docが「Prerequisite ADRs
 - service-integration-e2eテスト: 最終フェーズでのみ実行（ローカルスタックに依存し、タスクサイクル内で回すには重すぎる傾向がある）
 
 #### メタ情報の活用
-テスト定義に含まれるメタ情報（@category, @dependency, @complexity等）を分析し、
-依存が少なく複雑度が低いものから順にフェーズ配置。
+テスト定義に含まれるメタ情報（@category, @dependency, @complexity等）を分析し、依存が少なく複雑度が低いものから順にフェーズへ配置する。
 
 ### 戦略B: 実装優先開発（テスト設計情報がない場合）
 
 #### Phase 1から開始
 実装を優先し、各フェーズで必要に応じてテストを追加。
-Design Docの受入条件を基に、段階的に品質を確保。
+Design DocのACを基に、段階的に品質を確保。
 
 ### テスト設計情報の処理（提供された場合）
 
@@ -277,7 +274,7 @@ E2Eテストスケルトンが提供された場合、2段階で環境前提条
 **fixture-e2e** の場合:
 - **フィクスチャデータ** → 「[機能]のUI状態用フィクスチャデータファイルの作成」
 - **モックバックエンド** → 「fixture-e2e用 MSW ハンドラの設定（プロジェクトのAPI面に対するブラウザランタイムのモック）」
-- **ブラウザハーネス** → 「fixture-e2e用のPlaywrightハーネス設定（ライブサービス不要）」
+- **ブラウザハーネス** → 「fixture-e2e用のPlaywrightハーネス設定（稼働中のサービスを必要としない）」
 
 **service-integration-e2e** の場合:
 - **Seed data** → 「service-integration-e2e用 seed data script の作成（テストユーザー、必要なレコード）」
@@ -301,7 +298,7 @@ E2Eテストスケルトンが提供された場合、2段階で環境前提条
 2. **タスク生成の原則**
    - 5個以上のテストケースは必ずサブタスク分解（セットアップ/高リスク/通常/低リスク）
    - 各タスクに「X件のテスト実装」を明記（進捗の定量化）
-   - トレーサビリティ明記：「AC1対応（3件）」形式で受入条件との対応を示す
+   - トレーサビリティ明記：「AC1対応（3件）」形式でACとの対応を示す
 
 3. **測定ツール実装の具体化**
    - 「Grade 8測定」「専門用語率計算」等の測定系テスト → 専用実装タスク化
@@ -329,7 +326,7 @@ Design Docで決定された実装アプローチと技術的依存関係に基
 
 ### フェーズ構成
 Design Docの技術的依存関係と実装アプローチに基づいてフェーズを構成。
-最終フェーズには必ず品質保証（全テスト通過、受入条件達成）を含める。
+最終フェーズには必ず品質保証（全テスト通過、AC達成）を含める。
 
 ### テストスケルトンの統合
 計画プロセス（フェーズ構成ステップ）で定義したテストスケルトン配置ルールに従う。
@@ -349,11 +346,14 @@ Design Docの技術的依存関係と実装アプローチに基づいてフェ
 - [ ] 設計-計画トレーサビリティ表の完成（DDの全技術要件がカテゴリ分類・マッピング済み）
   - [ ] 理由なしの`gap`がないこと
   - [ ] 理由ありの`gap`は計画承認前にユーザー確認を実施
+- [ ] Reference Contract Values表の完成（Design Docが拘束的観測値を指定する場合: 列/ラベルの順序、派生表示、状態ライフサイクルの否定条件）
+  - [ ] 各値がDesign Docから逐語コピーされ全文言を保持し、カバーするタスクにマッピングされている
 - [ ] UI Specコンポーネント → タスクマッピング表の完成（UI Spec提供時）
   - [ ] UI Specの全コンポーネントにカバーするタスクが存在、または明示的な`gap`理由がある
   - [ ] コンポーネント参照はUI Specのセクション見出しを完全一致で記載している
-- [ ] Connection Map表の完成（実装が複数のパッケージ/サービスをまたぐ場合）
-  - [ ] 各境界にオーナーモジュールと期待されるシグナルが記載されている
+- [ ] Connection Map表の完成（パッケージ/サービスをまたぐ場合、または任意の境界をまたいでシリアライズされた値を渡す場合）
+  - [ ] 各境界にオーナーのファイルパスと期待されるシグナルが記載されている
+  - [ ] シリアライズ境界にSerialized FormatとConsumer Parse Ruleが記録されている
   - [ ] 各境界の両側に少なくとも1つのカバータスクがマッピングされている
 - [ ] ADR Bindings表の完成（ADRが提供される、またはDesign Docから参照される場合）
   - [ ] 各行が1つの実装拘束的な決定を表す（配置、依存、コントラクト、データフロー、永続化）

package/.claude/commands-ja/build.md

@@ -9,7 +9,7 @@ description: 分解済みタスクを自律実行モードで実装
 **実行プロトコル**:
 1. **全作業をAgentツールでサブエージェントに委譲** — サブエージェントの呼び出し、データの受け渡し、結果の報告（許可ツール: subagents-orchestration-guideスキル「オーケストレーターの許可ツール」参照）
 2. **4ステップサイクルに厳密に従う**: task-executor → エスカレーションチェック → quality-fixer → commit
-3. **自律実行モード移行**: ユーザーの実行指示とタスクファイルの存在をもってバッチ承認とする
+3. **自律実行モード移行**: ユーザーの実行指示とタスクファイルの存在をバッチ承認とみなす
 4. **スコープ**: 全タスクのコミット完了またはエスカレーション発生で完了
 
 **重要**: 全てのコミット前にquality-fixerを実行。

package/.claude/commands-ja/design.md

@@ -2,7 +2,7 @@
 description: コードベース分析から設計書作成まで実行
 ---
 
-**コマンドコンテキスト**: このコマンドは設計フェーズ専用です。
+**コマンドコンテキスト**: このコマンドは設計フェーズ専用である。
 
 ## オーケストレーター定義
 

package/.claude/commands-ja/diagnose.md

@@ -13,7 +13,7 @@ description: 問題を調査し、検証を経て解決策を導出する
 - 検証 → verifierに委譲
 - 解決策導出 → solverに委譲
 
-オーケストレーターがサブエージェントを呼び出し、構造化JSONを受け渡します。
+オーケストレーターがサブエージェントを呼び出し、構造化JSONを受け渡す。
 
 **タスク登録**: 実行ステップをTaskCreateで登録し、計画的にタスクを進める
 

package/.claude/commands-ja/front-build.md

@@ -9,7 +9,7 @@ description: フロントエンド実装を自律実行モードで実行
 **実行プロトコル**:
 1. **全作業をAgentツールでサブエージェントに委譲** — サブエージェントの呼び出し、成果物パスの受け渡し、結果の報告（許可ツール: subagents-orchestration-guideスキル「オーケストレーターの許可ツール」参照）
 2. **4ステップサイクルに厳密に従う**: task-executor-frontend → エスカレーションチェック → quality-fixer-frontend → commit
-3. **自律実行モード移行**: ユーザーの実行指示とタスクファイルの存在をもってバッチ承認とする
+3. **自律実行モード移行**: ユーザーの実行指示とタスクファイルの存在をバッチ承認とみなす
 4. **スコープ**: 全タスクのコミット完了またはエスカレーションで責務完了
 
 **重要**: 全てのコミット前にquality-fixer-frontendを実行。

package/.claude/commands-ja/front-design.md

@@ -2,19 +2,19 @@
 description: コードベース分析からフロントエンド設計ドキュメント作成まで実行
 ---
 
-**コマンドコンテキスト**: このコマンドはフロントエンド設計フェーズ専用です。
+**コマンドコンテキスト**: このコマンドはフロントエンド設計フェーズ専用である。
 
 ## オーケストレーター定義
 
 **コアアイデンティティ**: 「私はオーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
 **実行プロトコル**:
-1. **全ての作業をサブエージェントに委譲** — サブエージェントを呼び出し、データを橋渡しし、結果を報告する。唯一の例外はStep 1のスコープブートストラップで、シードファイルの特定に限定したレシピ内オーケストレータータスク。
+1. **全ての作業をサブエージェントに委譲** — サブエージェントを呼び出し、データを受け渡し、結果を報告する。唯一の例外はStep 1のスコープブートストラップで、シードファイルの特定に限定したレシピ内オーケストレータータスク。
 2. **以下のフロントエンド設計フローを順に実行**（このコマンドは中規模/大規模のフロントエンドを対象） — 分岐のない固定の線形シーケンス:
    - 実行: スコープブートストラップ → codebase-analyzer → [停止: スコープ確認] → ui-analyzer → ui-spec-designer → technical-designer-frontend → code-verifier → document-reviewer → design-sync
    - technical-designer-frontendは、設計にアーキテクチャ決定が伴う場合（documentation-criteriaに従う）に前提となるADRを作成する。ADRはDesign Docを置き換えない — フローは常にDesign Doc作成と検証チェーン全体を通過する
    - **`[停止: ...]`マーカーごとに停止** → 次に進む前にユーザー承認を待つ
-3. **スコープ**: 設計ドキュメントの承認をもって完了
+3. **スコープ**: 設計ドキュメントが承認されたら完了
 
 **subagents-orchestration-guideの利用**: オーケストレーション原則とScale Determination表を参照する。このコマンドは独自の開始順序を定義する — ガイドのrequirement-analyzer起点フローはここでは適用しない。
 

package/.claude/commands-ja/front-plan.md

@@ -2,14 +2,14 @@
 description: 設計ドキュメントからフロントエンド作業計画書を作成し計画承認を取得
 ---
 
-**コマンドコンテキスト**: このコマンドはフロントエンド計画フェーズ専用です。
+**コマンドコンテキスト**: このコマンドはフロントエンド計画フェーズ専用である。
 
 ## オーケストレーター定義
 
 **コアアイデンティティ**: 「私はオーケストレーターである。」（subagents-orchestration-guideスキル参照）
 
 **実行プロトコル**:
-1. **全ての作業をサブエージェントに委譲** — サブエージェントを呼び出し、データを橋渡しし、結果を報告する
+1. **全ての作業をサブエージェントに委譲** — サブエージェントを呼び出し、データを受け渡し、結果を報告する
 2. **subagents-orchestration-guideスキルの計画フローに従う**:
    - 以下に定義されたステップを実行
    - **完了前に停止し、計画内容の承認を取得する**

package/.claude/commands-ja/implement.md

@@ -4,7 +4,7 @@ description: オーケストレーターとして要件分析から実装まで
 
 **コマンドコンテキスト**: 実装の完全サイクル管理（要件分析→設計→計画→実装→品質保証）
 
-subagents-orchestration-guideスキルの指針に従い、オーケストレーターとして振る舞います — 全作業をAgentツールでサブエージェントに委譲し、データを受け渡し、結果を報告（許可ツール: subagents-orchestration-guideスキル「オーケストレーターの許可ツール」参照）。
+subagents-orchestration-guideスキルの指針に従い、オーケストレーターとして振る舞う。全作業をAgentツールでサブエージェントに委譲し、データを受け渡し、結果を報告する（許可ツール: subagents-orchestration-guideスキル「オーケストレーターの許可ツール」参照）。
 
 ## 実行判断フロー
 

package/.claude/commands-ja/plan.md

@@ -2,7 +2,7 @@
 description: 設計書から作業計画書を作成し計画承認を取得
 ---
 
-**コマンドコンテキスト**: このコマンドは計画フェーズ専用です。
+**コマンドコンテキスト**: このコマンドは計画フェーズ専用である。
 
 ## オーケストレーター定義
 
@@ -71,7 +71,7 @@ description: 設計書から作業計画書を作成し計画承認を取得
    - レビュー済みの作業計画書をユーザーにバッチ承認のため提示する。変更要望があればwork-plannerを修正パラメータで再実行し、ステップ4を再実行する。
    - スコープが不明確なステップや外部依存があるステップを強調し、ユーザーに確認を求める
 
-選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にします。
+選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にする。
 
 **スコープ**: 作業計画書作成と計画内容の承認取得まで。
 

package/.claude/commands-ja/prepare-implementation.md

@@ -87,7 +87,7 @@ R4とR5は、トリガー信号が作業計画書に現れた場合のみ評価
 2. すべての対象ファイルパスを以下のマーカーに照らしてタスクの**レイヤー**を判定する:
    - **backend**: 全対象ファイルパスが `**/api/**`、`**/server/**`、`**/services/**`、`**/backend/**`、`**/handlers/**`、`**/repositories/**` のいずれかにマッチする場合
    - **frontend**: 全対象ファイルパスが `**/components/**`、`**/pages/**`、`**/web/**`、`**/frontend/**`、`**/*.tsx`、`**/*.jsx` のいずれかにマッチする場合
-   - **prep-only**（言語/ランタイムに依存しない、機能実装ではない準備系のタスク）: 全対象ファイルパスが `docs/**`、`scripts/**`、`tests/fixtures/**`、`tests/e2e/data/**`、`tests/e2e/fixtures/**`、ルート直下の設定ファイル（`*.json`、`*.yml`、`*.config.*`）のいずれかにマッチする場合。**backend**のexecutor / quality-fixer（`task-executor` + `quality-fixer`）にルーティングする — Reactに固有の関心事を含まないため
+   - **prep-only**（言語/ランタイムに依存しない、機能実装ではない準備系のタスク）: 全対象ファイルパスが `docs/**`、`scripts/**`、`tests/fixtures/**`、`tests/e2e/data/**`、`tests/e2e/fixtures/**`、ルート直下の設定ファイル（`*.json`、`*.yml`、`*.config.*`）のいずれかにマッチする場合。Reactに固有の関心事を含まないため、**backend**のexecutor / quality-fixer（`task-executor` + `quality-fixer`）にルーティングする
    - **mixed**（対象ファイルがbackendとfrontendの両方のマーカーをまたぐ、または機能マーカーとprep-onlyマーカーをまたぐことで実装と準備が同居する）→ ユーザーにエスカレーション。レイヤーごとにタスクを分割するよう依頼する
    - **unrecognized**（上記いずれのマーカーにもマッチしない — 例: プロジェクトが使用する非標準のトップレベルディレクトリ）→ ユーザーにエスカレーション。(a) どのexecutor / quality-fixerが本タスクを実行すべきか判断するか、(b) プロジェクトが異なるパスを使用している場合はマーカーを更新するかを依頼する
 
@@ -95,7 +95,7 @@ R4とR5は、トリガー信号が作業計画書に現れた場合のみ評価
 3. Phase 0タスクファイルを `docs/plans/tasks/{plan-name}-backend-task-prep-{NN}.md`（backend または prep-only）または `docs/plans/tasks/{plan-name}-frontend-task-prep-{NN}.md`（frontend）として、documentation-criteriaスキルのタスクテンプレートで作成する。`-task-prep-`セグメントは本レシピが prep タスクと実装タスクを区別できるようにし、他レシピで使われる `{plan-name}-{layer}-task-*` マッチャーも維持する。prep-only タスクは Step 5 で backend executor にルーティングされるよう `-backend-task-prep-` のファイル名を使用する
 4. これらのタスクをPhase 0として（Phase 1の前に）作業計画書に挿入する
 
-提案された解消タスクのリストを AskUserQuestion でユーザーに提示する。明示的な承認後にのみ進める — これは本レシピ内で唯一の人間ゲートである。
+提案された解消タスクのリストを AskUserQuestion でユーザーに提示する。明示的な承認後にのみ進める。これは本レシピ内で唯一の人間ゲートである。
 
 ### Step 5: 解消タスクの実行
 
@@ -119,9 +119,9 @@ R4とR5は、トリガー信号が作業計画書に現れた場合のみ評価
 
 2. **作業計画書に Phase 0 完了を記録する**: コミットした各 Phase 0 解消タスクについて、作業計画書の Phase 0 セクションのチェックボックスを `[x]` にし、コミット済みである旨を注記する（` — committed` を付す）。これにより完了結果が計画書に残り、下流の task-decomposer がコミット済みの Phase 0 を再生成・再実行せずスキップできる。
 
-3. **Readiness Report の提示**: Readiness Report（下記の出力フォーマット参照）をユーザーに提示する。レポートはセッション内で提示し、作業計画書には書き込まない — 本レシピの永続的な成果物は、コミット済みの Phase 0 解消タスク（Step 6.2 で計画書に完了として記録）であり、永続化されたレポートではない。
+3. **Readiness Report の提示**: Readiness Report（下記の出力フォーマット参照）をユーザーに提示する。レポートはセッション内で提示し、作業計画書には書き込まない。本レシピの永続的な成果物は、コミット済みの Phase 0 解消タスク（Step 6.2 で計画書に完了として記録）であり、永続化されたレポートではない。
 
-4. **最終クリーンアップ**: 本実行で作成した、現在の `{plan-name}` に該当するprepタスクファイル（`docs/plans/tasks/{plan-name}-backend-task-prep-*.md` および `docs/plans/tasks/{plan-name}-frontend-task-prep-*.md`）と、prepフェーズ用に生成されたフェーズ完了ファイル（`docs/plans/tasks/{plan-name}-phase0-completion.md` が存在する場合。prepタスクはPhase 0に置かれるため）をすべて削除する。他の計画のprepタスクファイルはスコープ外 — 本レシピは現在の実行で作成したものだけを削除する。作業内容はコミット済みで、`docs/plans/`はレシピ実行間で保持しない一時的な作業状態である。作業計画書本体は下流のbuild/implementフェーズのために保持する。
+4. **最終クリーンアップ**: 本実行で作成した、現在の `{plan-name}` に該当するprepタスクファイル（`docs/plans/tasks/{plan-name}-backend-task-prep-*.md` および `docs/plans/tasks/{plan-name}-frontend-task-prep-*.md`）と、prepフェーズ用に生成されたフェーズ完了ファイル（`docs/plans/tasks/{plan-name}-phase0-completion.md` が存在する場合。prepタスクはPhase 0に置かれるため）をすべて削除する。他の計画のprepタスクファイルはスコープ外であり、本レシピは現在の実行で作成したものだけを削除する。作業内容はコミット済みで、`docs/plans/`はレシピ実行間で保持しない一時的な作業状態である。作業計画書本体は下流のbuild/implementフェーズのために保持する。
 
 5. **終了**:
 

package/.claude/commands-ja/reverse-engineer.md

@@ -76,7 +76,7 @@ prompt: |
 - `prdUnits`全体の`sourceUnits`を結合・重複除去した集合が`discoveredUnits`のID集合と一致すること — 欠落や重複がないこと
 - 各discoveredUnitの`unitInventory`に少なくとも1つの非空カテゴリ（routes、testFiles、publicExports）があること。3つすべてが空のユニットは発見が不完全 — そのユニットのrelatedFilesにフォーカスしてscope-discovererを再実行する
 
-**人間レビューポイント**（有効時）: `$STEP_1_OUTPUT.prdUnits`とソースユニットのマッピングを提示する。ユーザーはグルーピングの確認、調整、またはスコープからの除外を行う。これは最も重要なレビューポイント — グルーピングの誤りはすべての下流ドキュメントに波及する。
+**人間レビューポイント**（有効時）: `$STEP_1_OUTPUT.prdUnits`とソースユニットのマッピングを提示する。ユーザーはグルーピングの確認、調整、またはスコープからの除外を行う。グルーピングの誤りはすべての下流ドキュメントに波及するため、これは最も重要なレビューポイントである。
 
 ### ステップ2-5: ユニット毎の処理
 

package/.claude/commands-ja/review.md

@@ -58,7 +58,7 @@ Agent toolでsecurity-reviewerを呼び出す:
 
 **両方の結果をサブエージェントの出力フィールドのみを使用して独立に報告**（サブエージェントのレスポンスにないフィールドを追加しない）。
 
-**早期終了（ルーティング対象なし）**: code-reviewer の `verdict` が `pass` かつ `acceptanceCriteria[]` のすべてのエントリが `status: "fulfilled"` かつ `identifierMismatches[]` が空かつ `qualityFindings[]` が空かつ security-reviewer の `findings[]` が空の場合、Steps 5-10 をスキップして直接 Step 11 へ進む — ルーティング対象がないため。クリーンな結果をユーザーに提示する。
+**早期終了（ルーティング対象なし）**: code-reviewer の `verdict` が `pass` かつ `acceptanceCriteria[]` のすべてのエントリが `status: "fulfilled"` かつ `identifierMismatches[]` が空かつ `qualityFindings[]` が空かつ security-reviewer の `findings[]` が空の場合、ルーティング対象がないため、Steps 5-10 をスキップして直接 Step 11 へ進む。クリーンな結果をユーザーに提示する。
 
 それ以外の場合、ユーザー提示の前に、オーケストレーターは以下のルールで finding ごとに推奨ルートを計算する（このルール自体は内部用 — ユーザー向けプロンプトには含めない）。ルールは code-reviewer の既存構造化フィールドのみを参照する。「DDの意図」のような解釈は不安定な推論を避けるため意図的に行わない:
 

package/.claude/commands-ja/task.md

@@ -4,11 +4,11 @@ description: タスクを適切なスキルに従って実行
 
 タスク: $ARGUMENTS
 
-実行前に、以下を明確にしてください：
+実行前に、以下を明確にする：
 
 1. **タスクの本質**: このタスクが本当に解決しようとしている問題は？
 2. **適用スキル**: このタスクに該当するスキルは？
 3. **初動**: スキルに基づく最初のアクションは？
 4. **スコープ境界**: このタスクの完了条件と責務範囲は？
 
-上記を明示してから作業を開始します。
+上記を明示してから作業を開始する。

package/.claude/commands-ja/update-doc.md

@@ -2,7 +2,7 @@
 description: 既存設計ドキュメント（Design Doc / PRD / ADR）をレビュー付きで更新
 ---
 
-**コマンドコンテキスト**: このコマンドは既存設計ドキュメントの更新専用です。
+**コマンドコンテキスト**: このコマンドは既存設計ドキュメントの更新専用である。
 
 ## オーケストレーター定義
 

package/.claude/skills-en/documentation-criteria/references/design-template.md

@@ -187,7 +187,7 @@ Evaluate existing structures: semantic fit, responsibility fit, lifecycle fit, b
 
 ### Minimal Surface Alternatives (When Introducing Maintenance-Surface Elements)
 
-One entry per new in-scope element (persistent state / public-contract element or cross-boundary field or prop / behavioral mode/flag/variant / reusable abstraction or component split). Records the 5-step output produced by the invoking designer agent. Reference: `coding-standards` skill, "Minimum Surface for Required Coverage".
+One entry per new in-scope element (persistent state / public-contract element or cross-boundary field or prop / behavioral mode/flag/variant / reusable abstraction or component split). Records the 5-step output produced by the invoking designer agent. Reference: the "Minimum Surface for Required Coverage" principle.
 
 #### Element 1: [name of the new element]
 
@@ -254,7 +254,11 @@ Invariants:
 ```
 
 ### Field Propagation Map (When Fields Cross Boundaries)
+
+A boundary here includes a **serialized boundary** — a value encoded on one side and parsed on the other through a medium such as a query string, CLI argument, environment variable, config entry, message/queue payload, storage key, or file — not only in-memory crossings. For a serialized row, append `Serialized: [exact representation the producer emits]; Parse: [how the consumer decodes/validates it]` — the **Serialized Format** and **Consumer Parse Rule** — so producer and consumer agree; omit that suffix for in-memory crossings.
+
 - [field]: [ComponentA → B] — preserved / transformed / dropped — [reason]
+- [field]: [ComponentA → B] — transformed — Serialized: [exact representation]; Parse: [decode/validate rule] — [reason] (serialized boundary)
 
 ### State Transitions and Invariants
 

package/.claude/skills-en/documentation-criteria/references/plan-template.md

@@ -51,6 +51,14 @@ Maps each Design Doc technical requirement to the covering task(s). One row per
 
 **Gap Status values**: `covered` (task exists), `gap` (no task — requires justification in Notes, user confirmation required before plan approval)
 
+## Reference Contract Values
+
+Include this section when the Design Doc specifies a **binding observable value** the implementation must reproduce exactly — extract these from the Design Doc directly, not from the Traceability table's summarized DD Item: a column/label set and order, a derived-display rule (display value derived from another field), or a state-lifecycle negative (the condition under which the state must stay unused). The Traceability table records *that* a row is covered; this table carries the value *verbatim* so the covering task is checked against the exact contract rather than a re-derived summary. Serialized boundaries are owned by the Connection Map below; ADR-derived structural decisions by ADR Bindings. Omit the section when none apply.
+
+| Design Doc (§ Section) | Contract Type | Required Observable Value (verbatim) | Covered By Task(s) |
+|---|---|---|---|
+| [docs/design/XXX.md (§ Section)] | structure-order / derived-display / state-lifecycle-negative | [the exact value copied from the Design Doc — e.g., "the listed fields in the specified order"; "the label shows the looked-up name in place of the raw code"; "the persisted state is applied only when an explicit restore signal is present"] | [Phase X Task Y] |
+
 ## Failure Mode Checklist
 
 Domain-independent failure categories this implementation must guard against. Enumerate all eight categories, mark each in the Applies? column as yes/no, and list a covering task for each that applies; keep entries free of project-specific names.
@@ -68,13 +76,13 @@ Domain-independent failure categories this implementation must guard against. En
 
 ## UI Spec Component → Task Mapping
 
-Include this section when a UI Spec is among the inputs. Maps each component documented in the UI Spec to the task(s) that implement it. task-decomposer reads this table to populate each task's Investigation Targets with the corresponding UI Spec section. Omit the section when no UI Spec exists.
+Include this section when a UI Spec is among the inputs. Maps each component documented in the UI Spec to the task(s) that implement it. This table is read in a downstream step to populate each task's Investigation Targets with the corresponding UI Spec section. Omit the section when no UI Spec exists.
 
 | UI Spec Component (section heading) | States to Cover | Covered By Task(s) | Gap Status | Notes |
 |---|---|---|---|---|
 | [Use the UI Spec heading exactly as written, e.g., "§ Component: AlertCard"] | [default / loading / empty / error / partial — list the states the implementation must produce] | [Phase X Task Y] | covered | |
 
-**Reference key rule**: The component identifier in column 1 is the UI Spec section heading (verbatim). ui-spec-designer enforces unique component headings so this reference resolves to exactly one section.
+**Reference key rule**: The component identifier in column 1 is the UI Spec section heading (verbatim). Component headings are unique, so this reference resolves to exactly one section.
 
 **Gap Status values**: `covered` (task exists), `gap` (no task — requires justification in Notes, user confirmation required before plan approval)
 
@@ -92,11 +100,13 @@ One row per binding decision. A single ADR can contribute multiple rows. A singl
 
 ## Connection Map
 
-Include this section when the implementation crosses more than one package, service, or process boundary. Document each boundary so task-decomposer can propagate boundary context to the implementation tasks on each side. Omit the section when the implementation stays within a single package.
+Include this section when the implementation crosses a package, service, or process boundary, **or when a value is serialized and re-parsed across a boundary even within a single runtime** — through a medium such as a query string, route/CLI argument, environment variable, config entry, message/queue payload, storage key, or file (producer and consumer must agree on the exact representation). Document each boundary so boundary context propagates to the implementation tasks on each side in a downstream step. Record each Owner as concrete file path(s), not a bare module/package/component name, so it resolves as an Investigation Target the executor can read. Omit the section when no such boundary exists.
 
-| Boundary | Owner (left side) | Owner (right side) | Expected Signal | Covered By Task(s) |
-|---|---|---|---|---|
-| [e.g., "web client → API gateway"] | [module/package on the request side] | [module/package on the response side] | [Observable evidence the boundary works — e.g., "HTTP 200 with response matching ContractA", "row inserted in tableB", "message published to topicC"] | [Phase X Task Y on each side] |
+For a serialized boundary, fill Serialized Format and Consumer Parse Rule. Set both to "—" when the contract is already captured by the Expected Signal (e.g., a cross-process call whose body matches the agreed schema); fill them when producer and consumer must agree on a specific encoding of a value (query string, storage key, CLI argument, config entry, message field).
+
+| Boundary | Owner (left side) | Owner (right side) | Serialized Format | Consumer Parse Rule | Expected Signal | Covered By Task(s) |
+|---|---|---|---|---|---|---|
+| [producing side → consuming side] | [owner on the producing side — concrete file path(s)] | [owner on the consuming side — concrete file path(s)] | [exact representation the producer emits; "—" if not serialized] | [how the consumer decodes/validates it; "—" if not serialized] | [Observable evidence the boundary works — e.g., a response matching the agreed contract, or the consumer reproducing the producer's values] | [Phase X Task Y on each side] |
 
 ## Objective
 [Why this change is necessary, what problem it solves]

package/.claude/skills-en/documentation-criteria/references/task-template.md

@@ -33,6 +33,15 @@ Each row is an ADR decision the implementation in this task must comply with.
 |---|---|---|---|
 | [docs/adr/ADR-XXXX.md (§ <Source Section>) — substitute the section name (`Decision` or `Implementation Guidance`) from the matching work plan row] | [Axis value copied verbatim from the work plan's ADR Bindings row] | [Binding decision copied from the work plan's ADR Bindings row] | [Y/N-answerable positive predicate that evaluates whether the planned/final implementation satisfies the decision] |
 
+## Reference Contracts
+(Include this section when the work plan's Reference Contract Values table covers this task. Omit otherwise.)
+
+Each row is a DD-derived observable contract the implementation in this task must reproduce exactly. Serialized boundaries are carried by the Boundary Context (from the work plan's Connection Map); ADR-derived structural decisions by Binding Decisions above.
+
+| Source | Contract Type | Required Observable Value | Compliance Check |
+|---|---|---|---|
+| [Design Doc path (§ Section) copied from the matching work plan Reference Contract Values row] | [structure-order / derived-display / state-lifecycle-negative, copied from the work plan row] | [Required Observable Value copied verbatim from the work plan row] | [Y/N-answerable positive predicate that evaluates whether the planned/final implementation reproduces the value] |
+
 ## Investigation Notes
 (Implementation observations are appended here before implementation begins. When Binding Decisions exist, record the planned implementation approach and each Compliance Check result here.)
 
@@ -81,6 +90,7 @@ Each row is an ADR decision the implementation in this task must comply with.
 - [ ] Each Proof Obligation is met: the test turns red under its primary failure mode and exercises the stated boundary
 - [ ] Deliverables created (for research/design tasks)
 - [ ] (When Binding Decisions exist) Every Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes (file:line, test result, or command output)
+- [ ] (When Reference Contracts exist) Every Reference Contract Compliance Check evaluates to `Y` against the final implementation, with evidence recorded in Investigation Notes
 
 ## Notes
 - Impact scope: [Areas where changes may propagate]

package/.claude/skills-en/documentation-criteria/references/ui-spec-template.md

@@ -59,7 +59,7 @@ Map PRD acceptance criteria to prototype references. Skip this section if no pro
 
 ### Component: [ComponentName]
 
-> Component heading uniqueness: every `Component: [ComponentName]` heading must be unique within this UI Spec. work-planner and task-decomposer reference components by exact heading text — duplicate names or paraphrased headings break the propagation to implementation tasks.
+> Component heading uniqueness: every `Component: [ComponentName]` heading must be unique within this UI Spec. Downstream steps reference components by exact heading text — duplicate names or paraphrased headings break the propagation to implementation tasks.
 
 #### State x Display Matrix
 

package/.claude/skills-en/frontend-typescript-testing/references/e2e.md

@@ -2,7 +2,7 @@
 
 ## Lane Selection
 
-E2E tests in this workflow split into two lanes (defined in integration-e2e-testing skill):
+E2E tests in this workflow split into two lanes:
 
 | Lane | Backend setup | Use these patterns |
 |------|---------------|-------------------|