リポジトリベース変更提案・実行 (Repo-grounded Change) は何をしますか？
既存プロジェクトに対する最適化リクエストを、確認済みの実装準備完了状態に変換し、承認されたオプションのみを実行します。
やりとりと承認の契約
- 解決策を推奨する前に、現在のリポジトリを調査すること。コード、テスト、設定、または該当するプロダクト文書から発見可能な事実についてユーザーに質問しないこと。
- ユーザーがオプションまたは変更ベースラインを明示的に承認するまで、読み取り専用のままにすること。診断やリポジトリ調査は編集を許可しない。
- 直接的で明確な実装リクエストに対してこのワークフローを強制しないこと。ユーザーが最初に評価を求めた場合、または選択が動作、互換性、リスク、スコープに実質的に影響を与える場合にのみ、このゲートを使用すること。
- 判断を要する質問のみをすること。構造化されたユーザー入力コントロールが利用可能な場合はそれを使用し、それ以外の場合は
Q1-Aのような簡潔なオプションコードを使用すること。 - 通常は相互に排他的な実現可能なオプションを2〜3個提供すること。推奨オプションを最初に配置し、その理由を説明すること。安全なオプションが1つしかない場合は、代わりに代替案が却下された理由を説明し、偽の選択肢を作成しないこと。
- 確認後は、無関係なクリーンアップを静かに追加せずに、選択されたオプションを実装すること。新しいリポジトリの事実が承認された動作、スコープ、移行、依存関係、または受け入れ基準を実質的に変更する場合は、中断して修正された決定を求めること。
証拠と決定のラベル
事実と解釈を分離してください：
ユーザー目標: ユーザーが述べた問題点と成果。コード事実: 現在のソース、テスト、ランタイム、または設定で観察される動作。ドキュメント事実: 該当する承認済みプロダクト文書で要求される動作。技術提案: 意図されたプロダクト動作を維持する実装推奨。製品仮定: 確認が必要な可逆的な仮定。未確認: 実装を妨げる未解決の選択。確認済み: ユーザーによって明示的に承認されたオプションまたはベースライン。今回不改: 承認された変更の範囲外にある動作またはコード。
ユーザーが特に指定しない限り、次の権限順序を使用します：
- 現在の明示的なユーザー指示。
- 現在のタスクで明示的に確認された決定。
- 該当する承認済みプロダクト仕様。
- 既存の動作に関する現在のコードとテスト。
- README ファイルと履歴文書。
矛盾を公開し、静かに1つのソースを選択しないでください。
ワークフロー
1. 現在の動作を発見する
references/discovery-and-impact.md を読んでください。問題点を再現または説明するために必要なリポジトリ領域のみを調査します。既存のユーザー変更を保護し、適切な場合に現在のテストベースラインを確立します。
オプションを提示する前に、現在の動作、ユーザーへの影響、関連するコード境界、不足している証拠を報告します。
2. 変更の目的を明確にする
リクエストを観察可能な結果と制約に変換します。オプション、スコープ、互換性戦略、または受け入れ結果を変更できる問題のみを明確にします。
リテラルな UI 用語が、誤ったインタラクションセマンティクスを導入する場合、それを必須の実装メカニズムとして扱わないでください。その区別を説明し、リポジトリ互換のオプションを提供します。
3. 実現可能なオプションを比較する
references/options-and-clarification.md を読んでください。ユーザーエクスペリエンス、維持される動作、状態とデータの互換性、アクセシビリティ、テストへの影響、実装工数、ロールバックの難易度、および意味のあるリスクを含む、プロダクトとエンジニアリングの影響を比較します。
4. 推奨変更仕様を作成する
references/change-spec-and-acceptance.md を読んでください。推奨されるオプションは、Codex によって直接実行可能でなければならず、以下を含みます：
- 目標の動作とインタラクション。
- 影響を受けるモジュール、コンポーネント、ファイル、インターフェース、状態。
- 互換性、永続性、移行、デグレード、ロールバックの処理（関連する場合）。
- 維持しなければならない動作とデータ。
- 明示的な除外事項。
- テスト計画と観察可能な受け入れ基準。
このステップではコードを変更しないでください。
5. 明示的な承認を得る
推奨事項と残りの選択肢を提示します。ユーザーにオプションを選択するか、最小限の必要な明確化ラウンドに回答するよう求めた後で停止します。
応答後、確認されたオプション、ユーザーによる修正、未解決の問題、ダウンストリームへの影響、最終的な受け入れベースラインを要約します。実装は、応答が明確に実行を許可した場合（例：「確認方案A」または「按推薦方方案執行」）にのみ開始します。
6. 承認されたオプションを実装する
ダーティなワークツリーを再確認し、無関係な変更を保持し、最小の一貫した実装を作成します。コメントは、明白でない不変条件や互換性の決定を説明するものであり、コードを言い換えるものではありません。
UI プレゼンテーションが削除されたからといって、基礎となるドメインデータを削除してはなりません。ただし、削除が明示的に承認された場合を除きます。永続化された状態、ルート、スキーマ、または列挙型を変更する場合、リポジトリがそれらが存在する可能性を示している場合は、レガシー値を処理します。
7. 検証して報告する
最初に焦点を絞ったテストを実行し、次に適切なリポジトリ全体のチェック（型チェック、リント、全テスト、ビルド、UI インタラクションまたはビジュアル検証など）を実行します。実行できなかったチェックが合格したと主張しないでください。
実装された成果、主要ファイル、検証証拠、既知の制限事項、および関連のない既存の警告を報告します。要求された検証面が利用できない場合は、それを開示し、承認なしに明示的に選択されたツールや環境をバイパスしないでください。
必須の停止条件
以下の場合に停止し、決定を求めてください：
- 2つの実現可能なオプションが実質的に異なるユーザー動作を生み出す。
- 実装に未承認の依存関係、統合、資格情報、移行、破壊的アクション、またはビジネスルールの変更が必要である。
- 現在のユーザー変更が必要な編集と重複しており、安全に保持できない。
- リポジトリの事実が承認されたオプションと矛盾する。
- 受け入れ基準を観察可能にできない。
- 変更を安全に完了するために承認されたスコープの拡張が必要である。
困難、期間、または通常の実装の詳細は、確認された決定を再開する理由にはなりません。
完了基準
選択されたオプションがスコープ内で実装され、互換性の決定が処理され、受け入れ基準が観察可能な証拠にマッピングされ、関連するチェックが実行され、制限事項が正直に報告された場合にのみ、ワークフローは完了です。