CRDD UI契約と振る舞い仕様の対応関係

September 12, 2026 · View on GitHub

Version: v0.20.1 Status: Stable Owner: Qual-Lab Last Updated: 2026-09-06 Related:

この文書で分かること（非規範の案内）

  • UIと振る舞い仕様をなぜ並行して扱うか
  • 表示・操作とシステムの振る舞いの責務をどう分けるか
  • 両方の成果物をどう対応付けるか
  • 片方だけ完成したように見える状態をどう防ぐか
  • アーキテクチャへ渡す前に何を共同確認するか

1. 目的と適用範囲（Purpose and Boundary）

本書は、利用者に見えるUI契約とシステムの振る舞い仕様が、同じプロダクト意図、機能、ユースケース、利用者操作、状態を矛盾なく成立させるための対応レビュー契約を定義する。

UI契約
= 利用者が何を認識し、判断し、操作し、どのフィードバックを受けるか

振る舞い仕様
= どの条件と状態で処理が始まり、何が変化し、何が返り、失敗時にどう振る舞うか

対レビュー
= 両者が同じ意味を、各項目の決定権限から矛盾なく表しているか

本書は第三の工程、第三の項目の決定権限、またはUIとSPECを統合した新しい安定コンテキストを作らない。本書の対応レビュー契約は規範であり、規範強度と運用規模は文書化に従う。UI工程の入口、網羅範囲、完了条件、ゲート、監査はUI、振る舞い仕様工程は振る舞い仕様を正本とする。

2. UI・振る舞い仕様の対応レビュー契約

2.1. 入口契約

対応レビューは対象範囲について、次を受け取る。

  • 情報源となるREQ / UX / IAと対象改訂版
  • IA設定候補／モデル、担当責任者／決定権限、適用対象範囲、継承／上書き
  • IAが所有する情報提示の意味構造（Information Presentation Model）のうち、共有すべき選択コンテキスト（Shared Context）、作業モード（Mode）、一時的 / 永続的な意味（Temporal Role）、可視性の義務（Visibility Obligation）
  • 適用するアクセシビリティプロファイルと代替操作の義務
  • 適用するUIテーマ（UI Theme）、操作パターン（Interaction Pattern）、UI部品状態（UI Component State）と視覚表現方針（Visual Direction）上の不変条件
  • 対応単位候補となる機能、ユースケース、利用者操作、状態を持つインタラクション
  • 対象UI-*とSPEC-*、または各工程の下書き／候補
  • UI網羅範囲の要約、SPEC網羅範囲の要約、未解決事項、人間レビュー結果
  • 情報源となるIA工程移行レビュー結果、レビュー済み改訂版、または明示されたreview_exception
  • IA、UI、SPECで発火した変更影響の伝播確認結果、情報源の改訂版、または明示されたpropagation_exception
  • 対象のUI上の義務、振る舞い上の義務、例外候補

片側が未着手でもレビューを開始し、他方に必要な義務を発見してよい。ただし、存在しない契約をAIが推測で補完して対応関係が成立したと扱わない。

2.2. 対応付け変換

各対応単位について、次を意味のある関係で対応づける。

  • UI側: 操作、表示状態、フィードバック、設定／制御、UIテーマ、操作パターン、UI部品状態、回復
  • SPEC側: 発火条件、事前条件、システム状態、結果、設定／方針の振る舞い、失敗、回復
情報源意図 / 対応づけ単位
├─ UI契約: 認識 / 操作 / 表示 / フィードバック
└─ 振る舞い仕様: 条件 / 状態 / 振る舞い / 結果
                    ↓
          対応関係の一貫性結果

両者を同じ文体や一つの成果物へ統合する必要はない。項目の決定権限を保ったまま、不一致、欠落、例外、検証方法を明らかにする。

2.3. 必要な対応関係の網羅範囲

対象範囲のすべての対応単位について、次を判定する。

観点UI契約側振る舞い仕様側
情報源／目的利用者の目標、UX / IAの意図システムが成立させる結果、情報源となるREQ / UX / IA
操作／発火条件利用者または外部アクターの操作発火条件、アクター、決定権限
利用可否表示、非表示、無効、理由事前条件、権限、機能／依存関係の利用可否
入力入力、選択、形式、補助妥当性確認、正規化、拒否条件
設定／方針現在値／有効値、適用対象範囲、継承／上書きの説明、変更／リセット操作選択肢／範囲、既定値の情報源、優先順位、権限、適用／リセット／回復の振る舞い
UIテーマ現在／有効なUIテーマ、変更可能な差分軸、不変の意味、プレビュー／リセット／フィードバック選択／自動選択、既定値、優先順位、保存、適用、代替／回復
UI部品／UI設計パターンUI部品状態、UI差分、インタラクションの見せ方、利用条件・例外発火条件、状態の意味、結果、失敗／回復、例外条件
投影同期 / 選択コンテキスト共有同一対象の複数の投影（Projection）間のハイライト、Tab自動切替、Focus / Scroll位置の復元、遷移先の表示同期の発火条件、同期対象、失敗時の振る舞い
作業モード切替Tab / Segmented Control / Route等での作業モード切替表現、切替後も維持する文脈の見せ方切替条件、保存、未保存変更、権限
可視性常時表示、折りたたみ、Tab、Drawer等への具体化と、同一文脈に置く情報の配置表示 / 非表示条件、権限による表示差
一時的 / 永続的な意味一時的な思考として扱うか正式な記録として扱うかの見せ分け、未保存 / 自動保存 / 破棄の提示と回復導線保存先、保存時点、自動保存の契機、消失条件
処理中読み込み中、進捗、操作可否処理状態、タイムアウト、並行処理、部分結果
状態表示状態、保証の見せ方ドメイン / システム状態、状態遷移
成功／出力完了フィードバック、結果、次の操作成功条件、出力、永続化、副作用
空／不明空・未取得・結果不明の意味データ不存在、未確定、照会・再確認の振る舞い
失敗／回復メッセージ、保持内容、再試行／支援導線失敗分類、保護、再試行、代替、回復
権限操作可否、理由、情報開示実行許可、禁止時の結果、監査
取消／元に戻す取消・復元操作とフィードバック取消、ロールバック、補償、不可逆条件
重複／競合二重操作防止、競合表示冪等性、競合、古い、重複時の結果
データ／内容情報源、鮮度、マスキング、表示名データの情報源、更新条件、プライバシー、保持期間、結果の意味
AI／外部操作来歴、不確実性、人間確認、同意推定状態、承認、実行権限、提供側障害
利用可能な操作キーボード / フォーカス / 意味 / 読み上げ順序 / 代替操作入力方式に依存しない発火条件、同等の権限／結果／失敗／回復、時間制限・入力保持
検証UIの検証義務、視覚／インタラクションの検証観点、必要な専門家レビュー／利用者評価振る舞いの検証義務、期待結果／失敗条件、テスト／ログ等の検証観点。両側を評価規則と検証項目へ接続する

全懸念をすべての対応単位へ機械的に実装する必要はない。適用しない懸念はNot Applicableとして、対象項目の人間の決定権限者が理由と影響を確認する。

2.4. 対応関係の網羅状態

各対応単位と懸念を、Complete for Scope、Partial — Human Authorized、Blocked、Not Started、Not Applicableで追跡する。

代表的な一画面、正常パス、一つの操作、またはUI / SPECの片側が完成したことを、対象範囲全体の対応レビュー完了と表現してはならない。

UIの網羅範囲とSPECの網羅範囲は別々に保持し、対応関係の網羅範囲へ合算して曖昧にしない。

対応関係の網羅状態を進捗として集約する場合は進捗管理の対の成立度に従う。UIと振る舞い仕様の進捗の平均を、対の成立度として扱わない。

2.5. 人間による判断

各項目の人間の決定権限者は、対応単位、重要状態の利用者向け意味、情報開示、不可逆操作、回復 / 代替動作、リスク受容、対応レビューの例外、Not Applicable、部分引き渡しを決定する。

AIは対応候補、不一致、欠落、選択肢を提示できるが、業務規則、決定権限、成功・失敗の意味、片側を正しいものとして自己決定しない。

対応関係について、対象項目の人間の決定権限者による判断、制約、学び、根拠、指摘事項を確定または変更した時点で、変更影響の伝播確認が必要かを判定する。確認が必要な場合は、IA以前のコンテキスト、UI / SPECの両側、アーキテクチャ以降への影響を更新・再監査するまで対応レビューを通常完了としない。

2.6. 完了条件と対応レビュー判定

対応レビュー判定を人間へ提示する前に、次を行う。

  1. 対象対応単位／改訂版へ、契約確認と本共有契約の「必要な対応関係の網羅範囲」「対応レビュー監査チェックリスト」に対する専門品質確認を含む工程移行レビューを実行する。
  2. 対応関係の指摘事項をUI、振る舞い仕様、または責務を持つ上流工程で修正する。
  3. UIと振る舞い仕様の更新改訂版を再レビューし、Passを得る。
  4. 対象内容と工程移行の人間の決定権限者が、内容とレビュー結果を確認して移行を決定する。

専門品質確認は、次の三つを分ける。

確認対象基準
本共有契約の対応関係必要な対応関係の網羅範囲と対応レビュー監査チェックリスト
UI工程同工程の「必要な責務の網羅」と「工程監査チェックリスト」。別途確認する
振る舞い仕様工程同工程の「必要な責務の網羅」と「工程監査チェックリスト」。別途確認する

一つの工程移行レビューへ結果を統合してよい。ただし、本共有契約のPassでUIまたは振る舞い仕様の個別確認を代替せず、個別確認のPassだけで対応関係全体をPassにしない。

レビューの省略、未評価の必須専門観点、または未解消の指摘事項を伴う移行は、人間が指示するレビュー例外がある場合だけ通常経路と区別して扱う。

対応レビューは次を満たした場合に、対象範囲について完了できる。

  • 全対応単位と必須の対応関係の網羅範囲を判定している
  • UI-*とSPEC-*の関係、または承認済み例外を辿れる
  • 操作 / 契機、状態、結果、失敗、権限、回復の重要な不一致がない
  • 適用対象のUIテーマ、操作パターン、UI部品状態がUIとSPECで対応し、視覚差分によって振る舞いの意味が変わっていない
  • 適用対象の投影同期 / 選択コンテキスト共有と作業モード切替がUIとSPECで対応し、同期の発火条件 / 同期対象 / 失敗時の振る舞いと、切替条件 / 保存 / 未保存変更 / 権限が片側だけになっていない
  • 適用対象の可視性の義務がUIとSPECで対応し、UI側の具体化とSPEC側の表示 / 非表示条件・権限による表示差が片側だけになっていない
  • 適用対象の一時的 / 永続的な意味がUIとSPECで対応し、UI側の見せ分け・未保存 / 自動保存 / 破棄の提示と、SPEC側の保存先 / 保存時点 / 消失条件が片側だけになっていない
  • 未解決事項、Not Applicable、部分承認、リスクを記録している
  • UIとSPECの各工程ゲートを独立して評価している
  • 受入条件と取得予定根拠が両側で対応している
  • UIと振る舞い仕様の検証義務、検証項目、評価規則が対応し、片側の結果だけで対全体の成立を推定していない
  • 発火した変更影響の伝播確認がPassであり、必要な正本更新と再監査が完了している

対応レビュー完了だけではUI工程またはSPEC工程の完了にならない。反対に、UIまたはSPECの個別ゲートは、該当する対応レビューが未完了なら実装への通常引き渡しを許可しない。

UIが存在しない振る舞い、実振る舞いを持たないプロトタイプ等は、5章の例外条件を満たす場合に限り対応レビューの例外として扱う。

2.7. 対応レビュー監査チェックリスト

  • 対応単位または対象UI-* / SPEC-*の未特定
  • 操作に対応しない契機、または利用者へ届かない重要振る舞い
  • UI状態とシステム状態の無条件な一対一化
  • 設定UIとSPECの選択肢、既定値、実効値、対象範囲、優先順位、権限、変更効果、リセット / 回復の不一致
  • UIテーマの選択、自動選択、既定値、優先順位、永続化、適用失敗、代替動作 / 回復の片側欠落
  • 投影同期（ハイライト、Tab自動切替、Focus / Scroll復元）または作業モード切替（切替条件、保存、未保存変更、権限）の片側欠落
  • IAが常時アクセス可能または同一文脈に存在すべきとした情報を、UI側の折りたたみ / Tab / Drawerへの具体化だけで扱い、SPEC側に表示 / 非表示条件と権限による表示差がない状態
  • IAが一時的 / 永続的な意味を確定した情報について、保存先 / 保存時点 / 消失条件がSPECにない、またはUI側に未保存・自動保存・破棄の提示と回復導線がない片側欠落
  • 操作パターンまたはUI部品状態の見た目だけがあり、契機、結果、失敗 / 回復がSPECにない
  • 読み込み中 / 空 / 不明 / 失敗 / 権限 / 競合 / 取消 / 回復の片側欠落
  • キーボード、フォーカス、意味、代替操作等をUIだけの表現とし、同等の契機、結果、失敗、回復がSPEC側にない
  • UIによる業務規則、決定権限、状態遷移の創作
  • SPECによる視覚表現、情報優先度、利用者向け文言の創作
  • AIの提案、人間の承認、実行、検証の状態の意味を混同する
  • Figmaやプロトタイプだけによる振る舞い確定、EARS文だけによるUI / UX確定
  • 片側の実装都合による情報源となるUX／IAの意図の無断変更
  • 対応関係の網羅範囲、未解決事項、人間レビュー、例外理由、検証対応の欠落
  • UIと振る舞い仕様の検証義務、検証項目または評価規則が片側だけにあり、一方の専門家レビュー、利用者評価またはテスト結果だけで対全体を確認済みとしている状態
  • 対応関係に関する判断、制約、学習、根拠、指摘事項に対する上流・同層探索、両側の正本反映、下流再探索、再監査の欠落
  • 本共有契約の専門品質確認、またはUI・振る舞い仕様の両工程に必要な専門観点の確認が未実施でないか。片側だけのレビュー、共有契約と個別工程のレビューの相互流用、旧改訂版のレビュー流用、指摘事項未修正の持ち越し、監査実行完了を対応レビュー合格とみなしていないか

3. 項目の決定権限と対応関係

3.1. 分離された決定権限

UIとSPECが同じ懸念を扱う場合も、項目の決定権限は分離する。

観点UIの決定権限SPECの決定権限対応レビューの焦点
操作認識・操作・フィードバック契機・条件・結果操作が意図した振る舞いを開始するか
状態提示 / 保証ドメイン / システム状態利用者へ正しい意味が伝わるか
失敗メッセージ・回復導線失敗条件・保護・回復処理原因を断定しすぎず回復可能か
権限操作可否・説明認可規則開示と実行制御が一致するか
設定 / 方針現在 / 実効値、対象範囲、変更・リセット操作、影響説明選択肢 / 範囲、既定値、優先順位、権限、変更効果、回復利用者が実際に有効な値と変更結果を正しく理解・制御できるか
UIテーマ現在／有効なUIテーマ、変更可能な差分軸、プレビュー、適用結果選択／自動選択、既定値、優先順位、保存、代替／回復UIテーマ間で意味を維持し、実際の選択・適用結果を理解・回復できるか
UI部品 / UI設計パターンUI部品状態 / UI差分、インタラクション、利用規則、例外契機、状態の意味、結果、失敗 / 回復再利用表現が未定義振る舞いを暗黙に作らないか
投影同期 / 選択コンテキスト共有ハイライト、Tab自動切替、Focus / Scroll位置の復元、遷移先の表示同期の発火条件、同期対象、失敗時の振る舞い同期の見せ方と発火・失敗条件が一致するか
作業モード切替Tab / Segmented Control / Route等での切替表現、維持する文脈の見せ方切替条件、保存、未保存変更、権限作業モードが変わっても意味と権限が一致するか
可視性常時表示 / 折りたたみ / Tab / Drawer等への具体化、同一文脈への配置表示 / 非表示条件、権限による表示差IAが常時アクセス可能とした情報や隠してはならないリスクが、具体化と表示条件の両側で保たれるか
一時的 / 永続的な意味一時／永続の見せ分け、未保存 / 自動保存 / 破棄の提示、回復導線保存先、保存時点、自動保存の契機、消失条件利用者が「消えるもの」と「残るもの」を取り違えないか
取消 / 元に戻す利用可能な操作取消 / ロールバック規則UIが不可能な回復を約束しないか
利用可能操作認識可能な意味、キーボード / フォーカス、代替インタラクション入力方式に依存しない条件、同等結果、時間制限、入力保持特定の感覚・入力方式を使えない利用者にも同じ成果と回復が成立するか
受入条件利用者から観測する成立システムから観測する成立同じ成果を検証できるか

「共有懸念」は共同所有を意味しない。各側が自分の項目を正本化し、対応レビューが関係と整合を検査する。

3.2. 対応単位と対応数

対応単位は原則として機能、ユースケース、利用者操作、状態を持つインタラクションであり、画面名やファイル名ではない。

悪い対応:
画面 Spec.md ⇄ 画面 A Spec.md

意味に基づく対応:
論点を承認するUI契約 ⇄ 論点承認の振る舞い仕様
論点を検索するUI契約 ⇄ 論点検索の振る舞い仕様

一つのUI操作が複数振る舞いを協調させる場合や、一つの振る舞いを複数画面領域から利用する場合があるため、対は一対一に限定しない。多重度と責務を関係として説明する。

3.3. 安定コンテキストと成果物の境界

対は既存のUI-*とSPEC-*をpairs_with等の意味ある関係で接続する。対そのもの、対応付けマトリクス、レビュー結果へ新しいCRDD標準安定コンテキストIDを発行しない。文書番号やファイル名へUI / SPEC IDを埋め込まない。

対応付けマトリクスはレビュー表示であり、UI契約または振る舞い仕様本文の代替正本ではない。単純な対象では同一成果物へUIとSPECを併記してよいが、項目の決定権限、安定コンテキスト、改訂版、網羅範囲を区別する。

3.4. 競合の解決

不一致が見つかった場合、実装済み、詳細、作成日時が新しい等の理由だけで片側を優先しない。

情報源となるUX / IA / REQと判断を確認する
UI項目かSPEC項目かを確認する
不足、誤り、意味変更、上流競合を分類する
必要な人間による判断または上流再開を行う
正本改訂版と対応関係を更新する

4. 契約を横断する観点

4.1. 状態と保証の対応

表示状態とドメイン / システム状態は一対一とは限らない。重要な状態では、内部で成立していること、利用者へ伝えること、その結果を何が保証するかを分ける。

ドメイン / システム状態 = 内部で成立している状態
表示状態    = 利用者へ伝える状態
保証状態       = その結果を確認した根拠または確からしさ

応答喪失等で結果が不明な場合、UIは成功・失敗を推測せず、SPECは不明を観測・再確認・回復できる振る舞いとして扱う。

4.2. 操作・非同期処理・回復

主要操作では、操作可能条件、契機、即時フィードバック、処理中操作、二重実行、成功・失敗、取消 / 元に戻す、次操作を対応づける。

操作を非表示または無効にする場合、機能の存在や利用不可理由を知らせる必要、代替手段、将来利用可能性と、情報開示によるセキュリティリスクをUI / SPECの両側から判断する。

非同期処理では、要求済み、待機中、処理中、一部完了、成功、失敗、取消済み、期限切れ等から適用状態を判断し、進捗、タイムアウト、再訪、再試行、冪等性、部分完了を両側で整合させる。実際に取得できない進捗率をUIで演出しない。

レート制限、処理能力不足、依存関係停止等でキュー、拒否、流量制限、縮退が起こる場合、SPECの観測可能な振る舞いと、UIの待機・拒否・縮退・再試行フィードバックを対応づける。

削除、公開、送信、上書き、権限変更等では、確認だけを安全性とみなさず、影響表示、決定権限、不可逆条件、ロールバック / 補償、監査根拠を対応づける。

4.3. 失敗・データ・表現

重要失敗では、発生条件、保護する対象、利用者へ伝える意味、入力保持、再試行 / 回復、支援、ログ / 根拠を対応づける。内部エラーコードをそのまま表示せず、すべてを「予期しないエラー」へ潰さない。

表示データでは、情報源、鮮度、欠損、形式、ローカライズ、プライバシー / マスキング、更新条件を対応づける。UI文言は、SPECが保証しない成功、承認、保存、最新性を断定しない。

4.4. AI・同意・外部操作

AIを扱う対象範囲では、AIの提案、人間レビュー済み、承認済み、実行要求済み、実行済み、検証済み等の意味を必要範囲で分離する。UIは情報源 / 来歴、不確実性、人間確認、修正・却下を表現し、SPECは入力対象範囲、推論、承認条件、提供側の失敗、保存・公開・実行条件を定義する。

同意は表示だけで成立しない。UIの同意・変更・撤回操作と、SPECの開始条件、対象範囲、取消・期限切れ時の停止、失敗時振る舞いを対応づける。

外部操作では、UIが対象、範囲、影響、決定権限を理解可能にし、SPECが比率、量、対象、時間、承認、冪等性、取消、回復、監査を制御する。

4.5. 設定と方針の対応

設定では、UIが表示する現在 / 実効値、既定値 / 継承値 / 上書き値 / 方針管理の意味、適用対象範囲、変更決定権限、影響の事前表示、保存・反映・リセット時のフィードバックを、SPECの選択肢 / 範囲、既定値の情報源、優先順位、権限、適用時点、副作用、失敗 / 回復と対応づける。

UIだけに存在する設定、SPECだけに存在して利用者または運用者が確認・制御できない設定を放置しない。IAの構成モデルから意図的に固定した項目、直接UIを持たない方針 / 運用構成は、理由、決定権限、利用先 / 運用フィードバックとの対応レビュー例外を示す。

UIテーマを利用者、OS、組織方針等が選択する場合も本節を適用する。

  • UIは現在値、有効なUIテーマ、変更可能な差分軸、適用対象範囲、プレビュー、リセット、適用結果を示す。
  • SPECは既定値の情報源、自動選択、優先順位、永続化、適用時点、失敗時代替動作 / 回復を定義する。

単なる静的なブランド差分で選択振る舞いがない場合は、その理由を示して振る舞いとの対応をNot Applicableにできる。

4.6. 検証の対応

受入条件はUIとSPECで同じ文章にする必要はない。UI側は利用者が認識・操作・回復できること、SPEC側は条件、状態、振る舞い、結果を新しい根拠で確認できることを定義する。

対応レビューは、同じ情報源となる成果について、どのUIの根拠と振る舞いの根拠を組み合わせるかを示す。実装済み、テストの合格、Figma完成のいずれか一つを対応成立としない。

UIと振る舞い仕様の検証義務、検証項目、評価規則の対応も確認する。UI側の専門家レビューまたは利用者評価と、振る舞い側のテスト結果の一方だけから対全体の成立を推定せず、品質保証に従って検証義務ごとの評価へ接続する。

EARS等の正式構文は振る舞い仕様、Figma等の視覚成果物はUIの各正本規則に従う。対契約はそれらの詳細な作成規則を再定義しない。

5. 例外と既存系

5.1. UIだけの対象または模擬プロトタイプ

価値仮説や操作性を検証するプロトタイプでは、完全な振る舞い仕様なしに模擬した振る舞いを利用してよい。ただし、実振る舞いとシミュレーション、検証対象、未確定振る舞い、使用禁止範囲を明示し、対応レビュー完了または実装可能契約と表現しない。

5.2. 直接UIを持たない振る舞い

API、バッチ、背景ジョブ、自動化等で直接UIを持たない場合、UI側をNot Applicableにできる。利用先契約、運用フィードバック、監視、停止、回復、監査用の表示面の必要性を判定し、人間が例外理由を確認する。

5.3. 読取り専用またはUI内で完結する観点

読取り専用の表示面でも、データの情報源、鮮度、空、未知、失敗、権限との対応を確認する。

純粋なレイアウト、視覚表現、クライアント内の一時的な提示等で、システムの振る舞いとの対が不要な懸念はNot Applicableにできる。ただし、データ、永続化、権限、共有状態、外部操作へ影響しないことを説明する。

5.4. 逆引きと既存系の整合

既存系では観察されたUI、観察された実行環境の振る舞い、コード / API / データ、既存文書、操作を根拠として対応関係を復元してよい。

観察されたUI契約候補
観察された振る舞い
文書化済み振る舞い
想定契約候補
既知不具合 / 不整合
回復済み意図候補

現行UI、実装、長期間の運用を意図された契約と断定しない。復元候補は人間確認または追加根拠を得るまで確定UI / SPECとして扱わない。

6. 対応レビュー表示とフィードバック

6.1. 標準対応付け表示

次は対応レビューを表現する標準表示であり、独立ファイルを要求しない。UI側は04_UI/01_User_Interface.md、振る舞い仕様側は05_SPEC/01_Behavior_Specification.mdの固定入口から、同じ対象範囲の対応レビューへ到達できるようにする。対応表示を別成果物へ分けても、両入口から参照し、片側だけの第二の正本にしない。

対象範囲 / 対応づけ単位 / 情報源の改訂版
UIのID / 改訂版 / 成果物参照
SPEC ID / 改訂版 / 成果物参照
対応関係 / 多重度
適用されるアクセシビリティプロファイル / 基準

懸念
UI契約の意味
振る舞い仕様の意味
一貫性結果
網羅範囲状態
未解決不足 / 例外 / リスク
判断 / 判断理由参照
受入条件 / 根拠計画
人間による判断結果
変更影響の伝播確認結果／情報源の改訂版／是正／伝播例外
工程移行レビュー結果 / レビュー済みUI・SPEC改訂版 / 指摘事項の処置 / レビュー例外

対応レビュー結果は、プロジェクト内で「整合」「不足」「競合」「非適用」等と表現してよい。Consistent、Gap、Conflict、Not Applicableは機械可読な値を必要とする場合の非規範例であり、CRDD共通の正式状態値ではない。UI / SPECの成果物状態、工程承認、検証結果と混同しない。

6.2. レビューと引き渡し

レビューでは、対象範囲の対応関係の網羅範囲、重大な不一致、片側だけの推測、例外、リスク、各正本へ必要な修正を提示する。不一致の解消はUIまたはSPECの正本成果物へ反映し、対応付け表示だけを書き換えて終了しない。

アーキテクチャ、実装、検証への引き渡しは、UIとSPECの各工程の契約、対応レビュー判定、変換・引き渡しの不変条件をすべて満たす。部分引き渡しは、対象対応単位、未解決懸念、リスク、後続担当責任者を工程移行の人間の決定権限者が承認した場合に限る。

アーキテクチャへの引き渡しはUI／SPECの引き渡し表示を縮小再掲して受信条件を減らさず、アーキテクチャ工程の入口契約が要求する全コンテキストを、UI／SPECの正本成果物への参照と各網羅状態付きで渡す。

6.3. フィードバックと変更

UI具体化で新しい状態や回復が必要と判明した場合はSPECへ、SPEC具体化で新しいフィードバックや操作が必要と判明した場合はUIへ戻す。情報源となるUX／IAの意図が変わる場合は上流も再開する。

実装、検証、運用で対応関係の競合を発見した場合、観察された根拠を保存し、UI／SPECのどちらが誤りか、両方の上流前提が誤りかを判断する。同じ意味の明確化は既存IDの改訂版、意味の置換は新IDとsupersedesを用い、pairs_with関係と影響コンテキストを更新する。

7. 最終原則

人間に見えることと、システムで起きることは、別の項目の決定権限で設計する。
しかし、同じプロダクト意図を成立させる意味の上では切断しない。