CRDD振る舞い仕様（Behavior Specification）

September 12, 2026 · View on GitHub

Version: v0.20.1 Status: Stable Owner: Qual-Lab Skill ID: skill.spec.behavior Last Updated: 2026-09-06 Related:

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

条件、契機、システム状態ごとのシステムの振る舞いをどう定めるか

例外、失敗、回復、権限、設定をどう仕様化するか

UIとの対応と責務境界

実装・検証可能な受入条件をどう作るか

アーキテクチャへ渡す前に何を確認するか

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

振る舞い仕様は、要求、UX / IAの意図、機能、ユースケース、利用者操作、業務規則を、検証可能な条件、システム状態、システムの振る舞い、結果、例外、受入条件へ変換する工程である。

どの条件で
誰または何が、どの決定権限により
どの状態から何を行い
何が変わり、何が返り
失敗、競合、取消、回復時にどうなり
何をもって成立と判断するか

振る舞い仕様は要求、UX成果、UI表現、アーキテクチャ方式、コードの代替ではない。UXや設計意図をEARSへ機械変換したり、現行実装を正しい仕様として採用したり、AIが業務規則を創作したりしない。

工程実行契約（Phase Process Contract）

本章は振る舞い仕様工程の入口、変換、責務網羅範囲、出口、工程ゲート、監査の正本である。本章の規範性と運用規模は文書化に従う。後続章は本契約を成果物構造とスキル実行へ具体化し、独自の完了条件を持たない。成果物の統合・分割・配置は同書に従う。

工程入口契約（Phase Entry Contract）

振る舞い仕様は対象範囲について、次を受け取る。

情報源となるREQ / UX / IA、保持する意図、目指さないこと、検証義務
機能 / ユースケース / 利用者操作、対応単位候補
アクター / 決定権限、IAオブジェクト / 関係 / 状態遷移 / 状態概念
IAが所有する情報提示の意味構造（Information Presentation Model）のうち、共有すべき選択コンテキスト（Shared Context）の同期義務、作業モード（Mode）の切替条件、情報の一時的 / 永続的な意味（Temporal Role）に対応する保存義務、可視性の義務（Visibility Obligation）に対応する表示 / 非表示条件と権限による表示差
構成候補 / モデル、担当責任者 / 決定権限、適用対象範囲、継承 / 上書き
振る舞い上の義務、業務規則またはその決定権限
対応するUI契約候補、利用側 / 運用フィードバック候補
適用するアクセシビリティプロファイルと代替操作義務
適用する品質懸念プロファイル、品質、互換性、処理能力、プライバシー、コスト等の制約
IAの網羅範囲の要約、未解決事項、人間による判断結果
IA → 振る舞い仕様工程移行レビュー結果、レビュー済み改訂版、または明示されたreview_exception
IA／SPECで発火した変更影響の伝播確認結果、情報源の改訂版、または明示されたpropagation_exception
既存の振る舞い / コード / 文書と、その決定権限 / 改訂版

通常はIAの完了条件と引き渡しから受け取り、UIと並行・反復して具体化する。情報源となる要求、振る舞いの義務、アクター／決定権限、対象範囲、人間レビューが不足する場合は課題探索・要求形成、IA、人間による判断へ戻す。IAがPartial — Human Authorizedの場合は、承認された対象範囲だけを扱い、未網羅項目、リスク、後続担当責任者を引き継ぐ。

変換契約（Transformation Contract）

振る舞い上の義務、検証上の義務、品質上の懸念、構成候補、UIから受け取るUIテーマ（UI Theme）／操作パターン（Interaction Pattern）／UI部品状態（UI Component State）の義務を、検証可能な振る舞いへ変換する。必要に応じて次を定義する。

アクター / 決定権限、契機、事前条件
入力 / 妥当性確認、選択肢 / 既定値 / 実効値
システム状態、振る舞い、出力 / 状態遷移
失敗 / 例外、権限、冪等性
取消 / 元に戻す / 再試行、外部依存関係
利用側互換性、処理能力 / 品質に関する振る舞い
受入基準

SPECは利用側または利用者から観測可能な契約を定義し、実行時部品構成、サーバー台数、キュー規模、自動スケーリング、DB接続、キャッシュ、提供側選択等の成立方式を決めない。

状態遷移、権限、例外、回復、副作用、受入条件を観測可能な検証義務へ具体化し、期待する結果と失敗条件を品質保証の検証設計へ渡す。個別のテスト実装または独立検証の手順は本工程で先取りしない。

必要な責務の網羅（Required Responsibility Coverage）

対象範囲の各REQ、ユースケース、利用者操作、振る舞い上の義務について、次を網羅する。

責務	必要なコンテキスト
情報源と対象範囲	情報源となるREQ / UX / IA、目的、保持する意図、目指さないこと、検証義務、改訂版、関係
アクターと入口	アクター / 決定権限、契機、事前条件、機能フラグ、入力 / 妥当性確認
システム状態と成功	現在のシステム状態、振る舞い、出力、状態遷移、副作用、成功条件
失敗と回復	妥当性確認、権限、競合、タイムアウト、依存関係の失敗、代替動作、再試行、回復、入力保持、代替操作からの同等結果
完全性と制御	冪等性、並行処理、重複、取消、元に戻す、ロールバック / 補償、監査
外部依存関係	利用側、提供側、利用不可 / 一部完了 / 縮退時の振る舞い、観察可能な結果
互換性	利用側契約、バージョン、破壊的 / 非破壊、廃止、移行期間の振る舞い
処理能力と品質	適用する品質上の懸念、応答 / 完了条件、レート制限、キュー / 拒否 / 流量制限 / 縮退、品質条件
AI / データ / 外部操作	同意に関するシステム状態、入力対象範囲、推論 / 来歴、人間の承認、プライバシー / 保持期間、コスト保護策、操作上限
構成と方針	許可された選択肢 / 範囲、既定値の情報源、実効値、対象範囲、継承 / 上書き、権限、妥当性確認、適用時点、副作用、リセット / ロールバック、失敗 / 回復、監査。UIテーマを選択・自動適用する場合は優先順位、永続化、未対応の組み合わせ、代替動作とUIテーマとの対
投影（Projection）同期・作業モード・可視性・一時的 / 永続的な意味	IAが所有する共有すべき選択コンテキストの同期発火条件 / 同期対象 / 失敗時の振る舞い、作業モードの切替条件 / 保存 / 未保存変更 / 権限、情報の一時的 / 永続的な意味に対応する保存義務、可視性の義務に対応する表示 / 非表示条件と権限による表示差と、それぞれのUIとの対
受入条件とトレース	受入基準、検証義務、検証意図、期待結果、失敗条件、環境差分、検証観点、UI／利用側対、網羅範囲／未解決事項

すべての責務を全振る舞いへ機械的に記載する必要はない。適用しない責務はNot Applicableとして理由と人間確認を残す。

対象範囲と網羅状態（Scope and Coverage State）

各REQ / ユースケース / 利用者操作 / 振る舞い上の義務と各SPEC責務を、Complete for Scope、Partial — Human Authorized、Blocked、Not Started、Not Applicableで追跡する。

一つの正常パス、EARS文、システム状態図、API定義、既存コード、または対応UIの完成を、対象範囲全体の振る舞い仕様完了と表現してはならない。

人間による判断（Human Decisions）

各項目について、その人間の決定権限者が次を決定する。

業務規則、アクター／決定権限、操作権限
構成の既定値 / 方針 / 上書き
リスク受容、不可逆処理、代替動作
互換性破壊とコスト / 品質トレードオフ
Not Applicableと部分引き渡し

AIは候補、不足、競合、受入条件案を提示できる。ただし、未決規則、既定値、方針、決定権限を推測で確定しない。

対象項目の人間の決定権限者による判断、制約、学び、根拠、指摘事項を確定または変更した時点で、変更影響の伝播確認が必要かを判定する。確認が必要な場合は、関連する上流・同層コンテキストと下流への影響を更新・再監査するまで通常完了としない。

完了条件と引渡し（Exit and Handoff）

通常引き渡し候補を人間のゲートへ提示する前に、次を行う。

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

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

UIと振る舞い仕様は並行・反復して具体化してよい。UIから振る舞いの不足を、SPECからフィードバック / 回復の不足を発見できるが、片側の進捗を他方または対応レビューの完了とみなさない。

通常のアーキテクチャへの引き渡しは、対象範囲がComplete for Scopeで、対象内容とアーキテクチャへの移行を人間の決定権限者が承認し、UIがある対象範囲では対応レビューを完了し、検証可能な受入条件を持ち、アーキテクチャ工程の入口契約を満たす場合に限る。

直接UIがない場合は、利用側契約または運用フィードバックとの対応と、直接UIがない場合の例外の人間確認を示す。部分引き渡しには、対象範囲、未定義振る舞い / 例外 / 受入条件、UIとの対応不足、リスク、受信先、後続担当責任者の人間承認を必要とする。

工程移行の判定基準（Phase Gate Criteria）

情報源となるREQ / UX / IA、対象ユースケース / 利用者操作へトレースできる
情報源となる要求の検証義務と適用品質上の懸念を、観測可能な振る舞い、品質条件、受入条件へ処置している
全振る舞い上の義務と必要な責務の網羅を対象範囲で判定している
アクター / 決定権限、契機、事前条件、システム状態、振る舞い、結果、重要失敗 / 例外が観察・検証可能である
権限、冪等性、取消 / 元に戻す / 再試行、依存関係、回復を適用範囲で判定している
アクセシビリティプロファイルまたはUI契約が代替操作を要求する場合、入力方式に依存しない契機、同等結果、失敗 / 回復、時間制限、入力保持を定義している
構成候補の選択肢 / 範囲、既定値の情報源、実効値、対象範囲、継承 / 上書き、権限、変更効果、リセット / 回復を定義している
IAから共有すべき選択コンテキスト、作業モード、情報の一時的 / 永続的な意味、可視性の義務を受け取る対象範囲では、同一対象の投影間の同期の発火条件 / 同期対象 / 失敗時の振る舞い、作業モードの切替条件 / 保存 / 未保存変更 / 権限、対応する保存義務、および可視性の義務に対応する表示 / 非表示条件と権限による表示差を、UI契約と対にして定義している
利用側互換性、処理能力 / 品質に関する振る舞い、移行期間の振る舞いを必要範囲で定義している
AI / 個人データを扱う対象範囲では同意、推論 / 来歴、外部操作権限、プライバシー / 保持期間、コスト保護策が観測可能な振る舞いである
UI契約または利用先／運用契約と整合している
受入基準と根拠取得方法を定義している
振る舞い仕様が所有する検証義務、検証意図、期待結果、失敗条件、検証観点を検証設計へ接続し、振る舞い仕様の専門観点でレビューしている
網羅範囲の不足、Not Applicable、部分引き渡し承認を記録している
アーキテクチャ工程の入口契約を満たす
発火した変更影響の伝播確認がPassであり、必要な正本更新と再監査が完了している
対象改訂版の工程移行レビューが、適用される専門観点をすべて評価したうえでPassであり、移行に影響する指摘事項の是正と再レビューが完了している

工程監査チェックリスト（Phase Audit Checklist）

REQ / ユースケース / 利用者操作 / 振る舞い上の義務の未変換
正常パスだけの仕様、曖昧な結果、観察不能な受入条件
失敗、権限、回復、冪等性、取消、依存関係の適用判定漏れ
UI上のキーボード、代替操作、時間延長、エラー訂正を見た目だけで成立させ、対応振る舞いの契機、結果、保持、回復が未定義
IAの構成候補に対応する選択肢 / 範囲、既定値、実効値、権限、適用時点、変更効果、リセット / 回復の欠落
IAが渡した共有すべき選択コンテキスト、作業モード、一時的 / 永続的な意味、可視性の義務に対する、同一対象の投影間の同期（発火条件 / 同期対象 / 失敗時の振る舞い）、作業モード切替（切替条件 / 保存 / 未保存変更 / 権限）、保存義務および表示 / 非表示条件・権限による表示差の欠落、またはUI側の見せ方だけで成立させている状態
互換性、バージョン、廃止、移行期間の振る舞い、処理能力 / 品質の漏れ
要求から渡された検証義務または適用品質上の懸念の未処置
UI / 利用側契約との操作、システム状態、失敗、回復、権限の不一致
AIを扱う対象範囲で同意を表示だけにし、実行停止・取消・外部操作権限を定義していない
SPECによるUX / UIの意図、アーキテクチャ方式、実装詳細の先取り
現行コードや観察された振る舞いの無条件な正本化、UX成果のEARS化
情報源のトレース、網羅範囲の要約、未解決事項、人間によるレビュー、判断 / 判断理由の欠落
アーキテクチャまたは実装への暗黙引き渡し
振る舞い仕様の検証義務、検証意図、期待結果、失敗条件または検証観点が未記録、検証設計へ未接続、または振る舞い仕様の専門観点で未評価でないか
確定・変更した判断、制約、学び、根拠、指摘事項に対する上流・同層探索、正本反映、再監査が欠落していないか
独立レビューまたは必要な専門観点の確認が未実施でないか。旧改訂版のレビュー流用、指摘事項未修正の持ち越し、監査実行完了を対象の合格とみなしていないか

2. 振る舞い仕様モデル

2.1. 振る舞い単位・状態・結果

振る舞い単位は、機能、ユースケース、利用者操作、イベント、予約操作等の意味ある処理単位である。アクター / 決定権限、契機、事前条件、現在のシステム状態、入力、振る舞い、出力 / 状態遷移、成功条件を対応づける。

システム状態名だけを列挙せず、各システム状態の意味、入口 / 出口条件、許可操作、観測可能な結果を説明する。UIがある場合、表示状態との対応は24_UI_Behavior_Specification.mdに従う。

対象に実在する終端を、下流の設計・検証より先に、次の結果母集団として適用範囲で定義する。

結果の区分	定義する経路・状態
正常	成立条件を満たして期待どおり完了する経路
準正常	処置を限定して完了または安全に拒否する経路
異常	失敗、取消、タイムアウト、競合、判定不能等の経路
回復	回復を要する経路と再開後に成立する状態

各結果には、観測可能な契機、事前条件、システム状態、結果、適用される場合の決定権限または副作用、事後条件を対応づける。

適用しない次元はNot Applicableとし、単純な振る舞いへ架空の母集団、決定権限、回復状態を作らない。

「ない」ことが観測できる振る舞いを変える場合は、次を区別する。

値が存在しないこと（absent）
値として明示的な空（null）が与えられていること
不要と確認済みであること
判定不能であること（unknown）

安全な拒否、回復が必要、処理の再起動が必要も、対象の契約に含まれる場合だけ結果として定義する。

定義した意味は利用側が推測で補正したり既定値へ正規化したりしてはならず、値の不在と明示的な空を同一の結果へ丸めない。対象の契約でこれらが同じ振る舞いになる場合はその旨を示し、契約に存在しない区別を機械的に追加しない。

本節は結果母集団の観測可能な意味だけを所有する。状態、資源、決定権限、副作用でどう成立させるかはアーキテクチャ、何を観測して成立・不成立を判定するかは品質保証の検証設計が所有し、本節でそれらの詳細な対応づけや網羅規則を重複させない。

2.2. 失敗・回復・整合性

重要失敗では、発生条件、保護するデータ / システム状態、利用者または利用側へ返す結果、入力保持、再試行 / 代替動作 / 回復、ログ / 監査を定義する。

妥当性確認
認証 / 認可
競合 / 古い
利用不能 / タイムアウト
外部依存関係
データ完全性
未対応状態
想定外失敗

二重実行や並行更新があり得る場合は、冪等性、重複判定結果、競合検出、再試行規則を定義する。取消、元に戻す、ロールバック、補償を区別し、不可逆なら理由と観測可能な結果を示す。

アクセシビリティプロファイルまたはUI契約がキーボード、代替インタラクション、時間延長、エラー訂正等を要求する場合、特定の参照先、ジェスチャー、感覚入力だけを振る舞い開始条件にしない。代替経路でも同じ決定権限、妥当性確認、結果、失敗、入力保持、回復が成立するよう定義し、差異が必要なら理由と利用者影響を明示する。

2.3. 利用側互換性と処理能力の振る舞い

API、IPC、イベント、バッチ、コマンド等を外部利用側が利用する場合、次を観測可能な契約として定義する。

項目、パラメータ、状態、エラー、イベントの意味
破壊的 / 非破壊変更、バージョン選択、廃止予定条件
旧バージョンの利用可能期間、移行中の共存振る舞い
廃止通知、失敗、代替動作、回復、対象利用側
既存データや利用側への受入基準

処理能力またはインフラストラクチャ制約が利用側へ見える場合は、応答 / 完了条件、同時実行やリクエスト量の品質条件、レート制限、タイムアウト、キュー / 拒否 / 流量制限 / 縮退、部分完了、再試行 / 回復を定義する。

SPECは成立させるべき観測可能な振る舞いと受入条件を定義する。構成、自動スケーリング、キュー実装、データベース、キャッシュ、提供側等の方式はアーキテクチャへ渡す。

2.4. AI・同意・データ・外部操作

AIの振る舞いでは、入力対象範囲、データ送信、プロンプト / モデル境界、出力状態、確信度 / 不確実性、情報源 / 来歴、人間によるレビュー、代替動作、提供側の失敗、保存・公開・実行条件を定義する。AI出力を判断または実行結果と同一視しない。

同意は対話表示ではなく実行条件である。未同意、状態不明、取消済み、期限切れ、対象範囲変更、保存失敗時の開始・停止・取消振る舞いを定義する。安全または法的に不合格終了済みが必要な対象範囲では、その条件と利用者へ返す結果を明示する。

外部操作は01_Principles.mdの段階的自律性を、読み取り、提案、人間が承認した実行、限定自動実行等の振る舞いへ変換する。決定権限、頻度、量、対象、時間、コスト、確認、冪等性、取消、回復、監査の上限を定義する。

2.5. 設定と方針の振る舞い

IAの構成候補を、観測・検証可能な振る舞いへ具体化する。

許可選択肢 / 範囲 / 形式
既定値価値と既定値情報源
現在 / 有効価値
適用済み主体 / 対象範囲
継承 / 上書き / 優先順位
読み込み / 変更 / 承認決定権限
妥当性確認 / 競合
適用時機 / 伝播 / 側影響
取消 / 差戻し / リセット / ロールバック
失敗 / 部分適用 / 回復
監査 / 根拠 / 受入条件

Defaultは単なる初期画面値ではなく、未設定時にシステムが採用する振る舞いである。個人選好、組織方針、システムの既定値、一時的上書きが競合する場合は、優先順位と利用者へ返す実効値を定義する。変更が非同期、段階反映、不可逆、既存データへ影響する場合は、適用時点、対象、部分失敗、ロールバック / 回復を明示する。

環境変数、提供側固有パラメータ、リソース規模等が利用者・利用側から観測できない成立方式だけである場合はアーキテクチャの技術構成へ渡す。プロダクトの振る舞い、可用性、品質、コスト、プライバシーへ影響する部分はSPECの観測可能な契約として残す。

UIテーマを利用者、OS、組織方針、利用状況等が選択する場合は、選択可能な差分軸、既定値の情報源、自動選択、優先順位、永続化、適用時点、リセット、未対応の組み合わせ、適用失敗時の代替動作 / 回復を本節で定義する。

色やデザイントークン値、UI部品の形状はUI、デザイントークンのモードや実行環境切替方式はアーキテクチャに残す。SPECは観測可能な選択・適用結果だけを所有する。

2.6. EARSの使用

EARSは振る舞い、例外、受入基準を曖昧なく表すための任意の構文であり、すべてのSPECをEARSだけで記述する必要はない。

EARSパターン	形式
Ubiquitous	`The system shall <response>.`
Event-driven	`When <trigger>, the system shall <response>.`
状態駆動	`While <state>, the system shall <response>.`
望ましくない振る舞い	`If <unwanted condition>, then the system shall <response>.`
Optional Feature	`Where <feature is enabled>, the system shall <response>.`

自然言語でも条件と結果を明確にする。UX成果、体験原則、IAの意図、視覚／設計意図をEARSへ圧縮しない。形式構文を使っても情報源コンテキスト、判断理由、例外、回復を失わせない。

2.7. 受入条件と根拠

受入基準は、対象改訂版、入力／条件、観察可能な結果、重要失敗、環境差分、根拠取得方法を説明できるようにする。

弱い:
正しく動作すること。

観察可能:
クラウド提供側が利用不可の状態で認知を実行した場合、
システムはローカル提供側へ自動代替動作せず、
利用不可状態と理由を返すこと。

受入条件はテスト手順や実装方式そのものではない。検証が新しい根拠を取得できる契約を示し、実際の成立判定は29_Verification.mdへ渡す。

2.8. 既存系・安定コンテキスト・根拠・判断

既存系では文書化された振る舞い、実装された振る舞い、観察された実行環境の振る舞い、運用上実務、期待する振る舞いの候補、復元した意図の候補を分離する。現行コードや長期間の挙動を望ましい仕様と断定せず、人間確認または追加根拠まで候補として扱う。

SPEC-*は複数成果物や工程から参照し、独立レビュー、置換、影響追跡を必要とする条件、システム状態、振る舞い、例外、受入条件等の意味単位へ付与する。文書名・機能名・EARS文・テスト名・文書番号と安定コンテキストIDを同一視せず、一つの振る舞い仕様成果物内に複数のSPEC-*が存在してよい。

全段落、全受入条件、根拠、判断、テスト、アーキテクチャ節、実装処理へ機械的にSPEC IDを発行しない。SPECは情報源となるREQ-* / UX-* / IA-*、pairs_with UI-*、アーキテクチャ、検証と関係で接続する。

振る舞いの根拠は対象成果物内または最も近い親フォルダのEvidence/へ置く。業務規則、決定権限、操作権限、不可逆処理、代替動作、互換性破壊、リスク受容の決定は、結果となるSPECの正本成果物のDecision / Rationaleへ理由、根拠、代替、影響を残す。

3. スキル実行接続部（Guided Skill Adapter）

3.1. 実行時の決定権限（Runtime Authority）

skill.spec.behaviorは、工程実行契約を11_Skill.mdの実行の状態遷移、ガイド付き対話、人間によるレビュー、引き渡しに従って実行する振る舞い仕様固有接続部である。本書では実行状態、一時停止 / 再開、共通の質問規則、サブエージェントの状態遷移、成果物の登録を再定義しない。

開始時は、システムがどの条件と状態でどう振る舞い、成功、失敗、再試行をどう扱うかを定義し、UX / UIの意図は保持したまま検証可能な振る舞いだけを精密化することを説明する。

3.2. SPEC固有の進行

手順	SPEC固有の変換	結果
読み込みと対象範囲	REQ、IA義務、対応単位、既存振る舞いを対応づける	SPECの網羅キュー
フレーム	アクター、決定権限、契機、事前条件、システム状態を定義する	振る舞いの境界
仕様化	振る舞い、結果、移行、失敗、回復を具体化する	振る舞い仕様
強化	権限、構成／方針、冪等性、依存関係、互換性、処理能力、AI／データを判定する	運用契約
受入	受入条件、環境、根拠候補を定義する	検証義務
レビューと引き渡し	対、網羅範囲、人間判断を確認する	アーキテクチャへの引き渡しまたは別経路

3.3. SPEC固有の質問観点

振る舞い合成（Behavioral Synthesis）

専門探索・収束契約を、振る舞い仕様では正常経路と例外欄を埋めるためでなく、利用者成果とシステム完全性を両立する振る舞い候補を合成するために使う。契機と期待結果から、即時失敗、再試行、待機、部分成功、代替、利用者への確認、取消、補償、縮退等のうち有力な意味を比較し、失敗意味、回復意味、人間の制御、整合性および副作用で批評する。

技術方式を仕様上の振る舞いへ無断で昇格せず、再試行、タイムアウト、冪等性、補償、競合解消等の既知パターンは候補生成の語彙として使用する。障害、並行、取消、部分結果または回復について利用者とシステムの結果を変え得る未評価の振る舞いが残る場合は収束済みとしない。

話題	質問の意図
契機 / アクター	何をきっかけに、誰がどの決定権限で開始するか
事前条件 / システム状態	開始前に何が成立し、どのシステム状態から始まるか
振る舞い / 結果	システムが何を行い、データ / システム状態 / 出力がどう変わるか
処理中	処理中、二重実行、並行操作、進捗をどう扱うか
失敗 / 回復	何を保護し、返し、保持し、再試行・回復するか
取消 / 元に戻す	開始後の取消、完了後の復元は可能か
依存関係	外部サービス、ネットワーク、AI提供側の停止時にどうするか
構成	何を選べ、既定値と実効値は何で、誰がどの対象範囲へ変更し、いつ反映・回復するか
受入条件	どの条件、結果、根拠で成立とするか

3.4. 状況に応じた経路と上位判断への移送

条件	移行先（Route）
情報源となる要求、業務規則、決定権限が不明	課題探索・要求形成 / 人間の判断
IAオブジェクト / 状態遷移 / 状態概念が不明	IA
UIとの操作 / システム状態 / 回復が競合	対応レビュー
技術方式、境界、処理能力設計が主題	アーキテクチャ / 技術検証
現行振る舞いの決定権限が不明	既存系逆方向 / 調査
受入条件を観測可能にできない	要求 / 振る舞いの再整理

AIへ対象範囲、権限、データ保持、リスク受容、不可逆処理、代替動作方針、互換性破壊の最終決定を要求された場合は確定しない。

サブエージェントを使う場合は10_Agent.mdに従い、状態遷移、失敗 / 回復、互換性、受入条件、対応関係の整合性等の限定対象範囲を委譲できる。振る舞い仕様、業務規則、対応レビュー、引き渡しの統合と人間確認は親エージェントが行う。

4. レビュー・引き渡し表示・フィードバック

4.1. SPEC固有の人間レビュー

共通レビュー契約は11_Skill.mdに従う。SPECレビューでは追加で次を確認する。

情報源となる要求と保持する意図が振る舞いと受入条件へ残っている
AIや現行コードが業務規則、決定権限、期待する振る舞いを創作していない
正常パスだけでなく失敗、権限、回復、依存関係を判定している
UIまたはアクセシビリティプロファイルが要求する代替操作で、同じ決定権限、結果、失敗、入力保持、回復が成立する
互換性、処理能力、AI / 同意 / 外部操作のリスクを隠していない
構成 / 方針の既定値、実効値、決定権限、変更効果、リセット / 回復をUIと対応づけている
UI / 利用側契約との対の競合を明示している
対象範囲全体の網羅範囲と部分承認範囲を誤認なく示している

05_SPEC/01_Behavior_Specification.mdを振る舞い仕様工程の固定入口とする。次は振る舞い仕様責務をプロジェクト内で表現する標準表示であり、各項目を独立ファイルにすることを要求しない。適用の深さでは入口や基本のファイル分割を変えず、記述、レビュー、根拠の深さを調整する。個別仕様を分ける場合も、入口から現在の網羅状態、UIとの対応、改訂版、未解決事項へ到達できるようにする。

対象範囲 / 網羅範囲要約 / 未解決不足
情報源となるREQ / UX / IA / 対応づけ単位
SPEC ID / 改訂版 / 状態
目的 / 保持する意図 / 目指さないこと
アクター / 決定権限 / 契機 / 事前条件 / 入力
状態 / 振る舞い / 出力 / 状態移行 / 側影響
失敗 / 例外 / 権限 / 回復 / 入力保持
代替運用 / 同等の結果 / 制限時間の振る舞い
冪等性 / 並行性 / 取消 / 元に戻す操作 / 再試行
外部依存関係 / 利用側契約
互換性 / バージョン / 移行-期間振る舞い
処理能力 / 品質条件
AI / 同意 / データ / 外部操作 / コスト保護策
構成 / 方針 / 既定値 / 有効価値 / 対象範囲 / 継承 / 上書き
投影同期 / 選択コンテキスト共有 / 作業モード切替 / 一時的・永続的な意味に対応する保存義務 / 可視性の義務に対応する表示・非表示条件と権限による表示差
受入条件基準 / 環境 / 根拠候補
`pairs_with` UI / 利用側 / 運用フィードバック
判断 / 判断理由
人間による判断結果
変更影響の伝播確認結果／情報源の改訂版／是正／伝播例外
工程移行レビュー結果 / レビュー済み改訂版 / 指摘事項処置 / レビュー例外

アーキテクチャへの共同引き渡し条件は対応レビューの引き渡しを正本とする。振る舞い仕様側はこの表示への参照とSPECの網羅状態を欠落なく渡す。

4.3. 振る舞い仕様へのフィードバック

UI、アーキテクチャ、実装、検証、運用から、システム状態、失敗、回復、互換性、処理能力、受入条件に関する学びが得られた場合はSPECへ戻す。同じ意味の明確化は同じSPEC-*の改訂版を更新し、意味を置換する場合は新しいSPEC-*を発行してsupersedesで接続する。

実装都合や既存コードだけで振る舞い仕様を無断変更せず、根拠と人間判断を結果となるSPEC成果物へ反映し、UIとの対応関係、網羅範囲、影響するアーキテクチャ / 検証を再確認する。

4.4. 外部出典の追跡

情報源の書誌情報、関係、網羅範囲の表明の意味はOverviewの情報源索引と外部情報源の追跡規則を正本とする。

情報源	関係	適用節	網羅範囲
`EARS`	`uses`	2.6 EARSの使用	`Selected Concepts`（選択した概念）。構文の使用は任意で、準拠は表明しない
`WCAG22`	`project_adopts`	2.2 代替操作、UI / SPECの対応関係、受入条件	採用する場合、プロジェクトプロファイルで適用基準と対象範囲を選ぶ

5. 最終原則（Final Principle）

振る舞い仕様は、正常系やEARS文を一つ書いて終わる工程ではない。
対象範囲の全要求、使用事例、振る舞い義務について、
条件、状態、結果、失敗、回復、受入条件をUI・アーキテクチャ・検証へ接続する。