**要求ソースの規律:**
- 目的・制約・受入条件を定められるのは、ユーザー指示、タスク指示書、そこで要件資料として指定されたソースだけです。現行コード、作業中の差分、テスト、レビュー報告、以前の応答、設計・品質上の参考資料は、現状の証拠、設計制約、または提案であり、それだけを根拠に新しい要求を作らないでください
- 分解した要件と完了契約には由来を付けてください。明示要求はソース箇所を示し、暗黙要求はそれがないと成立しない明示要求と理由を示し、維持事項は変更対象外にある観測可能な既存契約の証拠を示してください。契約置換では、変更対象外の既存契約、現行利用側の移行、旧契約の支援対象を別々の要件・完了契約として記録し、支援対象には要求ソースの明示箇所と対象・範囲を対応付けてください。いずれにも該当しないものは設計判断として扱い、要件や完了契約へ混ぜないでください
- ソースが複数の方法を許容している場合、方式を選ぶ前に許容集合全体を要件上で維持してください。名前が挙がった各選択肢に加え、「または同等の仕組み」のような開放選択肢も残し、列挙された方式だけへ暗黙に狭めないでください。調査後に一つを選んでも、選択理由は設計判断として記録し、選ばなかった方法の排除や選んだ内部構造を新しい受入条件にしないでください
- 採用した設計判断は実装アプローチを導いても、明示要求、不可欠な直接導出、または変更対象外として維持する既存契約でない限り、要求IDや完了契約IDを付けないでください
- 許容された複数案から一案を選んだ場合、完了契約にできるのは「許容集合を逸脱しないこと」と明示された維持範囲だけです。選んだ案を、維持要求が及ばない入力・経路まで固定する独立契約にしないでください
- 維持義務が特定の入力、モード、状態、または入口だけに適用される場合は、その境界を明示してください。要求ソースが選択肢を開いたままにしている別の範囲へ、現行動作や採用案を拡張しないでください。契約を適用範囲ごとに分け、許容集合が維持される範囲を示してください
- 型、ヘルパー、ファイル分割、削除、改名などの内部構造は、ソースが指定するか、観測可能な要求を成立させるため不可避な場合だけ完了義務にしてください
- 優先順位、既定値、設定形式、識別子、エラー時動作、初期化・再試行などのライフサイクルは、実装に決定が必要という理由だけで要求にはなりません。要求ソースに指定がなければ、確認事項または理由付きの設計判断として扱い、要求の由来を捏造しないでください
- 最終化する前に、要件と完了契約を一行ずつ再監査してください。要求ソースの記述、不可欠な因果、または変更対象外として維持する既存契約の証拠を示せない行は、要件・完了契約から設計判断または確認事項へ移してください