CRDD実装工程（Implementation）

September 12, 2026 · View on GitHub

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

実装を適用するプロジェクトでは、本書のPhase Process Contractを実装工程内の正本として使用する。

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

承認済みコンテキストとアーキテクチャを実装へどう変換するか

コード、構成、移行、開発者テストの責務

実装中に見つかった逸脱や制約をどこへ返すか

実装完了と検証完了をどう区別するか

検証へ渡す前に何を確認するか

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

実装は、承認済みコンテキスト、振る舞い仕様、アーキテクチャ、および該当する変更トレースを、コード、構成、移行、開発者テスト、ビルド成果物へ変換する工程である。

アーキテクチャ   = 実装が従う境界、契約、制約、規則を定義する
実装 = それらを実行可能成果物へ具体化する
検証   = 対象改訂版で契約が成立したか独立して確認する

動くコードは上位契約やアーキテクチャの代替ではない。実装中に不足、矛盾、成立不能、未承認変更を発見した場合は、コードで暗黙解決せず、観察済み事実、影響、選択肢を該当決定権限へ戻す。

実装の出口はReady for Verificationであり、VerifiedまたはAcceptedではない。

工程実行契約（Phase Process Contract）

本章は実装工程の入口、変換、責務網羅範囲、出口、工程ゲート、監査の正本である。本章の規範性と運用規模は文書化に従う。後続章は本契約を成果物、開発者テスト、スキル実行へ具体化し、独自の完了条件を持たない。

工程入口契約（Phase Entry Contract）

実装は対象範囲について次を受け取る。

情報源となるREQ / UX / IAへのトレース
該当する変更トレースと対象改訂版 / 基準版
承認済みUI契約、視覚表現方針（Visual Direction）、適用するUIテーマ（UI Theme）/ UI部品（UI Component）/ UI設計パターン（UI Design Pattern）/ 外部視覚成果物（External Visual Artifact）、振る舞い仕様
プラットフォーム非依存のデザインシステム参照実装（Design System Reference）。対象プラットフォームへの変換は実装が担う
アーキテクチャ境界、実装 / コーディング規則、禁止事項
データ／インターフェース／セキュリティ／運用契約
互換性 / 移行 / ロールバック、処理能力 / リソース制約
受入基準と検証義務
環境、依存関係、ビルド / デプロイ条件
網羅範囲の要約、未解決事項、人間レビュー結果
アーキテクチャ→実装工程移行レビュー結果、レビュー済み改訂版、または明示されたreview_exception
アーキテクチャで発火した変更影響の伝播確認結果、情報源の改訂版、または明示されたpropagation_exception

部分引き渡しの場合は、承認された対象範囲、未決事項、暫定制約、リスク、後続担当責任者、人間承認も必要である。情報源間に競合がある場合は、優先順位を推測して実装しない。

変換契約（Transformation Contract）

承認済みコンテキストを、コード、構成、スキーマ / データ移行、依存関係 / ビルド定義、実行可能な規則、開発者テスト、生成済み / パッケージ成果物、実装根拠へ変換する。

実装は振る舞い、受入条件、決定権限、データの意味、セキュリティ境界、互換性 / 処理能力に関する振る舞いを新しく決めない。変更が必要な場合は、該当するSPEC、UI、アーキテクチャ、変更または人間の判断へ戻す。

実装は品質保証の実装開始前の基準点を受け取り、開発者テスト、ログ、メトリクス、テスト用制御点、環境、データを具体化する。実装が開発者テストを完成させても、独立検証の設計、検証義務の評価またはリスク受容を自己確定しない。

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

対象範囲について次の責務を適用範囲で判定する。

責務	実装で明らかにすること
対象範囲とトレース	変更トレース、UI / SPEC、アーキテクチャ、受入条件、変更対象へのトレース
コードと境界	モジュール、依存方向、公開インターフェース、禁止境界の遵守
構成 / 環境	既定値、環境差分、シークレット参照、機能 / 実行環境設定
データ／インターフェース	スキーマ、直列化、妥当性確認、API／イベント契約、正本の遵守
振る舞い / 失敗	成功、失敗、回復、権限、取消、代替動作、副作用
UI／視覚表現の実現	視覚表現方針、UIテーマ／デザイントークン（Design Token）、UI部品／UI設計パターン、論理画面／表示状態／UI差分（UI Variant）、UI素材／モーション、アクセシビリティ、外部視覚成果物の改訂版との対応、デザインシステム参照実装（Design System Reference）の対象プラットフォームへの変換
並行処理 / リソース	冪等性、トランザクション、タイムアウト、再試行、競合、割当上限、整理
セキュリティ / プライバシー / AI	保護、データ最小化、決定権限、同意、外部操作、監査
移行 / 互換性	移行コード、デプロイ順序、ロールバック、既存データ / 利用先の保護
依存関係 / ビルド	バージョン、ロック、ライセンス / セキュリティ制約、ビルド / パッケージ、生成物
可観測性 / 操作	ログ、指標、トレース、警告用兆候、診断可能な状態
開発者テスト／確認	検証設計へ接続する単体テスト／部品テスト／契約テスト／結合テスト、回帰テスト、静的／ビルド確認、必要なログ／メトリクス／テスト用制御点、環境、データ
逸脱と引き渡し	実際の影響、既知の制約、根拠、検証義務、未解決事項

すべてを全変更へ機械的に要求しない。適用しない責務はNot Applicableとして理由と人間確認を残す。主要正常パスの動作や一部テスト合格だけで対象範囲全体を完了扱いしない。

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

各実装義務を、Complete for Scope、Partial — Human Authorized、Blocked、Not Started、Not Applicableで追跡する。

対象範囲にはコードだけでなく、構成、データ、移行、生成成果物、依存関係、テスト、利用側、環境を含める。変更していない層も、影響を受けるなら網羅範囲対象である。

人間による判断（Human Decisions）

各項目の人間の決定権限者は、対象範囲変更、上位契約変更、アーキテクチャ境界変更、重大依存関係追加、不可逆移行、セキュリティ / プライバシーリスク、互換性破壊、コスト / 予定トレードオフ、リスク受容、部分引き渡しを決定する。

AIまたは実装担当は実装案、規則案、テスト、逸脱、影響を提示できるが、これらを自己承認しない。

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

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

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

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

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

通常の検証への引き渡しは、対象範囲がComplete for Scopeで、対象内容と検証への移行を人間の決定権限者が承認し、ビルド / 静的確認と必要な開発者テストが成功し、29_Verification.mdの受信条件を満たす場合に限る。

引き渡しでは、対象範囲 / 改訂版、変更成果物、適用したアーキテクチャ規則、開発者テスト / 確認結果、実行 / 再現方法、環境、移行 / ロールバック、逸脱、既知の制約、実装根拠、検証義務、網羅状態、未解決事項を渡す。

部分引き渡しには、未実装・未確認対象範囲、リスク、暫定処置、受信先、後続担当責任者の人間承認を必要とする。ImplementedをVerifiedとして渡さない。

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

変更トレース、UI / SPEC、アーキテクチャ、受入条件へトレースできる
コード、構成、移行、依存関係、開発者テストが対象範囲で整合している
アーキテクチャ境界、実装規則、セキュリティ / データ契約を遵守している
成功、失敗、回復、権限、並行処理、可観測性を適用範囲で実装している
UI対象では、視覚表現方針、UIテーマ／デザイントークン、UI部品／UI設計パターン、論理画面／表示状態／UI差分、UI素材／モーション、アクセシビリティを承認済みUIとアーキテクチャに従って実装し、視覚的な論理画面を持つ対象範囲ではデザインシステム参照実装の対象プラットフォームへの変換を承認済みUIの意味を変えずに完了している
ビルド、静的確認、必要な開発者テストが対象改訂版で成功している
単体試験が適用される場合、分岐網羅率100%を目標として測定し、未達または除外があれば対象、理由、残るリスク、代替確認、担当責任者、人間の判断が必要な範囲、再確認条件を明示している
検証設計に基づく開発者テスト、ログ、メトリクス、テスト用制御点、環境、データを実行可能な形へ具体化し、実装の専門観点でレビューしている
互換性、移行、ロールバック、リソース制約を適用範囲で実装・確認している
対象改訂版、環境、実行方法、逸脱、既知の制約が特定されている
対象範囲変更、上位変更、リスク受容、部分引き渡しを人間判断へ戻している
発火した変更影響の伝播確認がPassであり、必要な正本更新と再監査が完了している
対象改訂版の工程移行レビューが、適用される専門観点をすべて評価したうえでPassであり、移行に影響する指摘事項の是正と再レビューが完了している

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

コードが上位契約またはアーキテクチャを無言で置換している
テストを通すために受入条件、保護、契約を弱めている
コードだけを変更し、構成、移行、生成成果物、テスト、利用側影響が追従していない
エラー、権限、回復、並行処理、整理、可観測性の実装漏れ
共有UI部品／共有実行環境部品、スキーマ、API変更の既存データ／利用側／層への影響漏れ
視覚表現方針、UIテーマ／デザイントークン、UI部品／UI設計パターン、外部視覚成果物の改訂版との差分を実装都合で無言変更している
デザインシステム参照実装のプラットフォーム変換で、UIが所有する情報優先度、意味、操作の優先順位を実装都合で変えている
実装固有規則が正本化されず、会話またはコード内だけに存在する
開発者テスト結果または実装者確認を独立検証として扱っている
分岐網羅率の分母、測定対象または除外が不明である、未達理由が「測定困難」「既存コード」「時間不足」だけである、または数値を上げるために到達可能な分岐を除外していないか
検証設計に必要な開発者テスト、ログ、メトリクス、テスト用制御点、環境またはデータの未実装、未接続、もしくは実装の専門観点で未評価でないか
網羅範囲の要約、逸脱、既知の制約、実装根拠の欠落
確定・変更した判断、制約、逸脱、学び、根拠、指摘事項に対する上流・同層探索、正本反映、再監査が欠落していないか
独立レビューまたは必要な専門観点の確認が未実施でないか。旧改訂版のレビュー流用、指摘事項未修正の持ち越し、監査実行完了を対象の合格とみなしていないか

2. 実装モデル

2.1. 規則の決定権限と成果物の配置

プロジェクト固有のコーディング規則と実装規則の正本Markdownは06_Architectureへ置く。アーキテクチャは規則の意味、適用対象範囲、理由、禁止事項、例外承認、検査方法を所有する。

40_Developまたはプロジェクトの通常実装領域には、情報源となるコード、テストコード、構成、移行、ビルド / パッケージ定義、リンター / フォーマッター / コンパイラ設定、生成成果物を置く。CRDD管理用Markdownの配置先にしない。

実装担当は不足規則の案と判断理由を06_Architectureの該当成果物へ提案・追記してよい。ただし、境界、技術、依存関係、セキュリティ、データ、互換性等を変える規則は、アーキテクチャの決定権限と人間によるレビューなしに確定しない。

規則の意味と決定権限 = アーキテクチャ / 人間
コード・テスト・強制設定   = 実装
適合性と成立の判定    = 検証 / 人間

リンター、フォーマッター、型検査、静的解析ツール、ビルド確認等の実行可能な強制手段は実装成果物として配置し、対応するアーキテクチャ規則へトレースする。

2.2. 対象範囲・影響・変更規律

変更前に、直接変更する成果物と、影響を受けるモジュール、論理画面、利用側、データ、インターフェース、構成、移行、テスト、操作を特定する。共有UI部品または実行環境部品、スキーマ、API、規則の変更は、局所変更として扱わない。

実装は最小の差分量ではなく、意味的に閉じた最小変更集合を作る。変更集合には必要に応じて、コード、構成、生成規則、移行、開発者テスト、利用側、文書および検証手段を含める。一部だけを小さく変更して契約を未成立にしない。

実装前後で、少なくとも次を説明できるようにする。

変更前に成立している契約と挙動
今回変える意味と変更仮説
絶対に変えてはならない保持条件
変更後に新しく成立すべき契約と挙動
影響を受ける対象、利用側および検証方法

機械的な移行と意味上の変更を同じバッチへ無自覚に混在させない。混在する場合は差分、レビュー順序、ロールバック、検証を分離して説明し、該当CHGの想定／実際の影響へ反映する。重複処理を発見した場合は、意味上の決定権限と影響を確認し、共通責務へ統合するか、分離理由を残す。

実装中に対象範囲外変更が必要になった場合は、ついでに変更せず変更対象範囲と影響を更新する。

2.3. コード・設定・ビルド・実行環境

コードは、アーキテクチャ境界、依存方向、データ / インターフェース契約、エラー / ログ記録規則に従う。

構成では次を明確にし、コードと設定の組み合わせを再現可能にする。

環境差分
既定値と上書き
シークレット参照
機能フラグの決定権限

利用者・組織向け選好 / 方針 / 設定の選択肢、既定値、優先順位、変更効果は、承認済みSPECを実現する。実装で新しく決めてはならない。技術構成はアーキテクチャの境界と規則に従う。

依存関係は必要なバージョンを宣言・固定し、ビルド / パッケージが対象改訂版から再現できるようにする。生成済みコード / 成果物は情報源、生成手順、更新条件を追跡し、手修正と再生成の競合を避ける。

即時再読み込み対象外の処理、キャッシュ、生成済みコード、移行、ビルド成果物等を変更した場合は、変更が反映された実実行環境またはビルド成果物で開発者確認を行う。この確認は独立検証の代替ではない。

アーキテクチャの資源取得transactionに該当する実装では、対象範囲で到達し得るobserver、Identity取得、再検証、parserまたは初期化をcleanup／retention分類の外へ置かない。ID取得前のcleanup不明ではPathや未検証値からRecovery IDを作らない。複合transactionは内包producerのtyped failure集合を外側consumerまで保持し、同じ取得primitiveを使う公開入口または診断入口を水平探索して、入口ごとの偽clean、未分類例外またはRecovery案内欠落を残さない。非該当処理へRecovery Authorityを追加しない。

正常パスだけでなく、境界、空、不明、失敗、権限、競合、古い、再試行、取消、並行実行、依存関係停止を適用範囲で実装する。

冪等性、トランザクション、ロック、キュー、タイムアウト、再試行間隔、整理、安全な停止、部分失敗、背圧制御は、SPECとアーキテクチャが定める振る舞い / 回復契約に従う。実装しやすさを理由に原子性や回復の意味を変更しない。

アーキテクチャが重要とした状態、遷移、資源、ロック、AuthorityおよびEffectは、実装上の所有者、状態変更またはEffect発生点、失敗時の閉じ方、cleanup／Recovery、および終了後観測を担うsymbolまたは構成へ全数対応づける。

対応先のない設計要素、設計上の根拠がない実装上の状態・資源・Effect、または実装されたが検証接続のない要素を、命名の類似、コメント、状態名、試験件数またはcoverage率から接続済みと推定しない。

実装中に新しい状態、資源、ロック、通知順、Authority、Effectまたは利用側が必要になった場合は、局所実装へ閉じずアーキテクチャと検証設計へ戻して対応を更新する。

小規模で単純な対象では既存のコード参照と試験名から対応を取得できればよく、専用台帳を一律に作らない。

一つの処理が主資源に付随してtemporary、marker、lock、listener、child processまたはRecovery記録を生成し得る場合、それらを同じ資源閉包として実装・cleanup・終了後観測へ伝播する。主資源だけを削除できたことからcleanupConfirmedへ昇格せず、不存在を成功条件に使う場合は、権限拒否、共有競合またはI/O失敗を不存在へ二値化しない。

複数層をまたぐ変更では、DB、API、イベント / IPC、UI、外部提供側の実際のデータフローを開発者テストで確認する。特定層の単体テストだけで全体成立を推測しない。

Trust、Authority、Recoveryまたは安全上重要な結果を層間で搬送する実装では、production wiringから実producer、対象範囲で把握できるproduction consumerおよび外部公開契約を列挙し、producerが実際に返すvariant／field／byte列と順序をconsumerの受理・拒否・公開projectionへ対応付ける。

肯定試験は実producer出力、またはproductionと共有するCanonical validator／generatorから作る。consumerだけへ手書きした到達不能fixtureはconsumer局所の挙動確認には使えるが、producerとの結合成立根拠にしない。

別の呼出しまたはprocessで保護対象Effect／Recoveryの十分な根拠または不可欠なAuthority predicateになる耐久状態を追加した場合だけ、Authorityの発行・再開・失効をArchitectureと検証設計へ戻す。

発行条件成立前の失敗は非発行、exact発行後の失敗は同一Recovery intentの保持を許し、retryで別・拡大Authorityを生成しない。

通常のqueue、progress、checkpointまたはEvidenceを、それだけでAuthorityへ昇格しない。

2.5. 移行・互換性・ロールバック

移行はスキーマ / データ変換だけでなく、コード、構成、利用側、デプロイ順序、補完処理、機能フラグ、ロールバックを一つの実行連番として扱う。

既存データと利用側を使った開発者テストを行い、再実行、部分失敗、中断、旧新バージョン共存を適用範囲で確認する。破壊的変更やロールバック不能が判明した場合は、暫定コードで隠さずアーキテクチャ / 変更トレース / 人間の判断へ戻す。

2.6. ガバナンス・セキュリティ・プライバシー・AI制御

同意、権限、データ境界、外部操作権限は、該当対象範囲のUI表示だけでなく実行経路の保護として実装する。

UI、API、バッチ、キュー、再試行、管理者パスで同じ決定権限を強制する
許可されたデータだけを取得・保存・送信する
外部データと信頼済み指示を構造的に分離する
操作対象範囲、対象、量、比率、時間、コストを実行時に検証する
情報源、アクター、承認、実行、結果を監査可能にする
保護の判定不能時振る舞いをSPEC / アーキテクチャどおりに実装する
許可した処理境界と境界外接続を別のデータ・権限境界で扱い、境界内では許可された最小情報だけを送り、境界外の検索、ブラウザ、外部AI、API、MCP、生成サービス、ログまたは支援窓口へ内部コンテキストを直接送る経路を作らない
許可した処理境界内では、対象リスクに応じて分類、目的・操作、送信先、再識別可能性および許可を検査し、許可された最小情報だけを送る。許可した処理境界の外側で調査・情報取得を行う場合は、内部コンテキストとは別に削除・抽象化・最小化した調査コンテキストを作り、送信前に検査する。許可または安全な分離を判定できない場合は閉じる
外部結果の本文、メタデータおよび指示風内容を信頼済み命令・権限・ツール操作から分離する
認証情報の値をコード、プロンプト、ログ、テスト根拠またはコンテキスト成果物へ保存せず、安全な実行時注入と失効可能性を維持する

セキュリティまたはプライバシー規則をテストしにくいことを理由に保護を省略したり、既定で有効な境界を無断で機能フラグから無効化したりしない。不足契約はSPEC / アーキテクチャへ戻す。

新しいパッケージ、GitHub Actions等の自動化、MCPサーバー、プラグイン、スキル、エージェント定義、モデル、外部APIまたは生成サービスは供給網の実行資産として扱う。採用時は必要性、情報源、管理主体、版、完全性、ライセンス、既知のセキュリティ情報、要求権限、ネットワーク送信、推移的な実行物、更新・失効・代替・復旧を対象リスクに応じて確認する。通常依存へ個別の完全契約を一律に要求しないが、外部送信、コード実行、認証情報、ビルド・リリースまたは高い権限を持つ依存を、通常依存という理由だけで明示管理から外さない。

2.7. 開発者テストと独立検証

実装担当は、変更を成立させる開発者テストをコードとともに作成・更新する。

目的	実装の責務
論理と状態	単体テスト／部品テスト、境界／失敗／回帰テスト
契約	API / イベント / スキーマ / 利用側契約テスト
統合	変更した層、データフロー、外部境界の結合テスト
移行	既存データ、再実行、ロールバック、旧新共存の開発者テスト
実行可能な規則	静的確認、ビルド、種別 / セキュリティ / 依存関係確認
実行環境	対象ビルド / 処理での開発者スモーク確認

状態、資源、ロック、AuthorityまたはEffectを含む変更の開発者テストは、正常・準正常・異常の適用経路ごとに、設計要素、実装上の発生／変更点、観測手段、終了後条件を対応づける。状態名や返却値だけから資源解放、Authority失効、Effect 0またはcleanup成立を推定せず、可能な限り実receipt、ledger、observer、公開結果または独立した終了後観測で確認する。対応する検証がない要素は、理由付き非該当または未確認として扱い、実装完了へ暗黙変換しない。

層間契約の結合試験では、production wiringから得たproducer出力とconsumer入力の一致を少なくとも一経路で確認する。手書きfixtureを使う場合は、実producerから生成したもの、共有Canonical契約で生成・検証したもの、consumerだけの局所fixtureを区別し、最後の種類だけからEnd-to-End成立を主張しない。

テストの技術形式だけでは実装と検証を区別できない。同じE2Eや結合テストでも、実装を支える開発者テストと、対象改訂版に対する独立受入条件 / 保証では決定権限と根拠が異なる。

検証は開発者テストを再実行・再利用してよいが、実装者の成功報告だけで成立判定しない。実装担当も、受入条件 / E2Eという名称だけを理由にテスト作成を検証へ丸投げしない。

テストコードは実装成果物として40_Developまたはプロジェクトの通常テスト配置へ置く。テスト目的、対象契約、テストデータ、環境、改訂版を追跡可能にする。

単体試験の対象となる実装では、品質保証に従い、分岐網羅率100%を既定目標とする。測定対象、分母、到達分岐数、割合、除外を対象改訂版に対応させる。未達または除外がある場合は、対象と具体的理由、残るリスク、代替確認、担当責任者、人間の判断が必要な範囲、再確認条件を取得可能にする。数値を上げるためだけに無意味なテストを追加したり、到達可能な分岐を測定対象から外したりしない。

2.8. 追跡・根拠・判断・逸脱

実装へCRDD標準安定コンテキストIDを新規発行しない。情報源 REQ-* / UX-* / IA-* / UI-* / SPEC-*、アーキテクチャ、変更トレース、検証とは成果物参照、コミット、プルリクエスト、テスト結果等で接続する。

実装根拠は対象改訂版、環境、コマンド / 手順、結果、成果物の場所を識別できるようにし、対象成果物内または最も近い親フォルダのEvidence/へ置く。検証根拠とは決定権限と目的を区別する。

アーキテクチャや上位契約を変える判断を実装注記だけで確定しない。実装固有の選択、逸脱、既知の制約は、結果となるコード／構成と、変更トレース、プルリクエスト、アーキテクチャの正本成果物等の適切な既存成果物へ理由、影響、根拠、担当責任者を残す。

実装完了時に、逸脱、既知の制約または未実装対象範囲が残り、対応、判断、再確認または監視を必要とする場合は、原則が定める後続追跡の不変条件に従って処置する。本書では接続先、理由付き終了または判断対象への接続の要件を繰り返さない。

40_DevelopへCRDD管理用Markdownを新設しない。

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

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

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

3.2. 実装固有の進行

手順	変換	出力
負荷	変更トレース、UI / SPEC、アーキテクチャ、規則、対象改訂版を対応づける	実装の網羅キュー
影響	直接変更と影響成果物、データ、利用側、テストを特定する	影響を受ける対象範囲
仮説	変更前、変更後、保持条件、対象判定方法を対応づけ、意味的に閉じた最小変更集合を定める	変更仮説、保持条件、変更集合
実装	コード、構成、移行、実行可能な規則を具体化する	実装成果物
実行	開発者テスト、静的 / ビルド確認、実行時確認を行う	実装根拠
逆向き照合	最終差分の各変更を変更仮説へ戻し、説明不能な差分、未変更の影響先、保持条件の破壊および対象リスク固有の失敗を探す	差分批評、追加修正または差戻し
整合	逸脱、既知の制約、実際の影響を正本へ戻す	更新したコンテキスト / 提案
引き渡し	改訂版、環境、根拠、検証義務を渡す	検証の準備完了

ファイル数、差分量、テスト数を進捗とみなさず、必要な責務の網羅と対象範囲で判定する。

専門探索・収束契約は、実装では変更仮説、保持条件、意味的に閉じた最小変更集合および差分の逆向き照合として適用する。最終差分の各変更が変更後の成立条件に必要であること、必要な利用側が未変更のまま残っていないこと、保持条件を壊していないことを説明できるようにする。

変更が複数の利用側、永続データ、互換性、配布または復旧へ及ぶ場合は、最終構造だけでなく安全に到達する実装戦略を合成する。対象に応じて、観測可能性やテスト接続点の先行追加、互換境界、一利用側ずつの移行、移行順序、途中検証、停止条件、復旧点および旧経路の除去条件を比較する。一括置換または段階移行のいずれも既定の正解にせず、各中間状態で保持条件と利用可能性が成立するかを説明する。

二重実行、二重書込、影経路または機能切替等、複数状態を並行させる方式は通常の軽量化手段としない。固有リスクを下げるために必要で、人間が対象、期間、比較方法、停止条件、データ整合、費用および撤去条件を判断した場合だけ候補にできる。移行方式が新しいプロダクト振る舞い、アーキテクチャ判断またはリスク受容を必要とする場合は実装内で確定しない。

対象リスクに応じて、競合、リーク、破損、古い状態、部分成功、再実行、互換性、権限、失敗からの回復、保守困難等の敵対的な失敗可能性を選んで確認する。すべての変更へ同じ敵対的試験集合または別の確認者を機械的に要求しないが、該当する重大な失敗可能性を理由なく対象外にしない。

説明不能な差分、未変更の影響先、保持条件の破壊、未確認の重大な失敗可能性、または実装中に発生した新しい要求・アーキテクチャ判断が残る場合は収束済みとしない。承認済み範囲を越える場合は変更集合を広げず、3.3に従って停止または差し戻す。

3.3. 停止・差戻し・上位判断への移送

次の場合は実装を停止または承認済み対象範囲へ限定し、該当決定権限へ戻す。

条件	移行先（Route）
SPECとアーキテクチャが矛盾、受入条件が観測不能	SPEC / アーキテクチャ / 人間の判断
アーキテクチャ規則または境界が不足	アーキテクチャ
安全な移行 / ロールバックが成立しない	アーキテクチャ / 変更トレース / 人間の判断
シークレット、権限、環境が不足	環境担当責任者 / 人間の決定権限
対象範囲外の共有UI部品／共有実行環境部品変更が必要	変更トレース／影響レビュー
セキュリティ / プライバシー / 互換性を弱める必要がある	関係する決定権限 / 人間の判断
リソース / コスト制約で処理能力に関する振る舞いを満たせない	アーキテクチャ / SPEC / 人間の判断
新しい業務規則が必要	課題探索・要求形成 / SPEC / 人間の判断

暫定実装で競合を隠さず、観察済み事実、影響、選択肢、推奨、必要な人間の判断を返す。

3.4. エージェントとサブエージェントの使用

エージェントまたはサブエージェントへ委譲する場合は10_Agent.mdに従い、モジュール、移行、開発者テスト、影響調査等の限定対象範囲を渡す。

親エージェントは変更対象範囲、禁止変更、対象改訂版、期待する出力、検証義務を明示し、結果を正本コンテキストへ統合して該当変更トレースへ接続する。サブエージェントの結果をそのままVerifiedまたは人間の判断にしない。

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

4.1. 実装固有の人間レビュー

人間レビューでは少なくとも次を確認する。

上位契約とアーキテクチャをコード都合で弱めていない
変更対象範囲と共有成果物、データ、利用側への影響が一致している
セキュリティ、移行、互換性、処理能力のリスクを隠していない
開発者テストが変更した振る舞い、失敗、境界を扱っている
変更前、変更後、保持条件および意味的に閉じた最小変更集合が一致している
最終差分に説明不能な変更、未変更の影響先または保持条件の破壊がない
対象リスクに応じた敵対的な失敗可能性を確認し、未評価範囲を隠していない
逸脱、既知の制約、未実装対象範囲が明確である
Ready for VerificationをVerifiedとしていない

4.2. 実装成果物／引き渡し表示

実装成果物の物理構造は採用技術とアーキテクチャ規則に従うため、CRDD共通の固定Markdown入口または案件規模別の文書構成を追加しない。構造を変える場合は、技術上の責務境界、生成・実行方法、レビュー容易性等の理由を示し、適用の深さや担当AIだけを理由に再編しない。対象範囲について次を参照可能にする。

対象範囲 / 改訂版 / 基準版
情報源変更トレース / UI / SPEC / アーキテクチャ
変更されたコード / 構成 / 移行 / 依存関係 / ビルド
実装済み義務 / アーキテクチャ規則適用済み
開発者テスト / 静的 / ビルド / 実行時確認結果
環境 / 実行 / 再現方法
移行 / ロールバック / 互換性
逸脱 / 既知制限 / 実際影響
実装根拠
検証義務
網羅範囲状態 / 未解決不足 / 人間レビュー
変更影響の伝播確認結果／情報源の改訂版／是正／伝播例外
工程移行レビュー結果 / レビュー済み改訂版 / 指摘事項処置 / レビュー例外

検証への引き渡しはこの表示を縮小再掲して受信条件を減らさず、正本成果物への参照と網羅状態付きで渡す。

4.3. 実装からのフィードバック

実装から得た成立条件、技術制約、失敗モード、実測値、依存関係制約、移行リスクは、アーキテクチャ、SPEC、UI、変更へ指摘事項または提案として戻す。

実装担当に上位成果物の編集権限があっても、意味上の決定権限を代替しない。上位変更が承認されるまで、コードを新しい正本として扱わない。

検証の指摘事項は原因に応じて実装へ戻る。修正後は対象改訂版と実装根拠を更新し、以前の検証結果を自動的に合格へ変更しない。

5. 最終原則（Final Principle）

実装は、設計をコードへ写して終わる工程ではない。

上位契約を守って実行可能成果物へ変換し、実装から得た学びを正しい決定権限へ戻し、独立して検証できる状態を作る。