リポジトリへの変更を、人が確かめて出せる形まで準備する

## リポジトリの決まりに従い、保守担当者の許可を待つ 変更対象のファイルについては、リポジトリの貢献ガイド、人工知能に関する方針、ディレクトリ固有のエージェント指示を統制上の正本として扱う。 ### 適用規則を確定する - 編集前に、ルートの貢献方針と安全方針を読む。 - 専門ディレクトリへ入る場合は、実行時の動作、公開インターフェース、連携、ドキュメント、テストに関するローカル指示も適用する。 - 指示が矛盾する場合は、実装しやすい規則を選ばず、停止して矛盾を明示する。 - 任意のエージェントスキルは、クライアントが対応し、リポジトリ方針を上書きしない場合に限って使う。 ### 承認ゲート - ブラウザ自動操作、コマンドラインのホスティングツール、サービスAPIを使って、課題、プルリクエスト、下書きプルリクエストを提出してはならない。 - 人が確認して送信できる提出文を、リポジトリのテンプレートに従って、そのまま貼り付けられる形で下書きする。 - 関係する課題がトリアージされ、人間の貢献者へ割り当てられるまで、ブランチをプッシュしたり、公開提出用の資料を準備したりしてはならない。 - 記録された保守担当者の指示がない状態で、非自明な機能、公開インターフェースの変更、リファクタリング、動作変更を実装してはならない。指示がない場合は提案で止める。 ## 機密情報をコミットに入れず、テストを本物のサービスにつながない 作業全体を通じて、認証情報、証拠の品質、リポジトリ履歴、テストの分離を守る。 ### 絶対に守る規則 - 機密情報、認証情報、非公開のサービス提供者データ、取り扱いに注意が必要な環境値を絶対にコミットしない。 - テスト結果、承認、引用、レビュー状況、互換性の主張を絶対に作り上げない。 - 単体テストから、稼働中のモデル、サービス提供者、外部アプリケーションのサービスへ接続してはならない。 - 決定論的な代替物と、テスト処理から稼働中サービスの認証情報を取り除く環境を使う。 - 出所が明確で、保守担当者が同意している場合を除き、生成メディア、大きな生成物、合成データセットを追加してはならない。 - ライセンスの挿入をリポジトリの自動処理が担当する場合は、ライセンスヘッダーを手作業で追加してはならない。 - 求められない限りコメントを追加しない。変更によって不正確になる場合を除き、既存のコメント、docstring、ライセンスヘッダーを維持する。 ### 保護対象ファイル 作業がリポジトリの再生成ワークフローを明示的に必要とする場合を除き、変更履歴、生成ファイル、ロックファイル、検証用スナップショット、その他のツール管理成果物を手作業で編集してはならない。変更履歴が生成される場合は、リリース注記の背景を提案または提出文の下書きに記載する。 ## 依存関係は必要な時だけ変え、固定されたツールを使う 別の実行経路を即興で作らず、プロジェクトの正規の固定環境とタスクコマンドを使う。 ### 依存関係の変更 - 作業に必要でない限り、依存関係を追加または更新してはならない。 - 一時的な調査には、コミット対象の依存関係の状態を変更しない分離環境を使う。 - 依存関係の変更が必要な場合は、適合する最小範囲の依存関係グループまたは任意機能の集合に置く。 - 明確な互換性の範囲を設定し、任意の連携を標準のインストール経路へ移さない。 - 依存関係とロックファイルの変更を、無関係な編集から分離する。 ### ツール運用 - インストール、テスト、ドキュメント作成、書式整形、静的解析には、リポジトリで固定された実行環境とツールのバージョンを使う。 - 正式な検証コマンドと診断用コマンドを区別する。単独のリンターや型検査器は診断に役立つ場合があるが、リポジトリで必須の事前コミット確認や検証経路の代わりにはならない。 - 広範なステージング、コミット、リポジトリ全体の確認を行うスクリプトは、影響の大きいツールとして扱う。明示的に必要な場合に限って実行し、できるだけ変更のない作業ツリーで使う。 ## 変更の種類に合わせて、必要なテストを選ぶ 実際の変更種別に応じて必要十分な最小限の検証を選び、共有動作または互換性のリスクに正当な理由がある場合に限って範囲を広げる。 ### 検証マトリクス - ドキュメントまたはリポジトリのメタデータ：変更したファイルを確認する。表示、リンク、例、ドキュメント設定へ影響する可能性がある場合はドキュメントを構築する。 - 実行時の不具合修正：対象を絞った回帰テストを追加または実行してから、変更ファイルに必要な確認を行う。 - 公開インターフェース、設定、言語動作：対象を絞ったテストを実行し、関係するドキュメントまたは例を更新する。互換性のリスクが無視できない場合は、より広いパッケージテストを追加する。 - サーバー、ストリーミング、追跡、アクション、生成の経路：変更した経路と、その代替経路または非対応経路をテストする。 - パッケージ化、依存関係、ロックファイルの変更：関係するインストールまたはパッケージ化の確認を行い、依存関係の差分を分離する。 ### 範囲と分離 - 正規の全テストコマンドが含む範囲を把握し、最も分かりやすいテストディレクトリだけが対象だと想定しない。 - 稼働中サービスの認証情報を取り除き、決定論的な代替物を与えるテストの実行入口を優先する。 - 分離に関係する不安定さは、同じ環境保護策の下で通常の並列実行と決定論的な直列実行を比較して診断する。 - 低速または直列のマーカーは、テスト実行器が実際に強制する場合を除き、参考情報として扱う。 - 稼働中サービスの認証情報を残したり、必須のテスト経路を迂回したりする可能性がある便利な代替テストコマンドを使ってはならない。 ### 引き継ぎの証拠 レビュー予定の変更は、引き継ぎ前に正式な事前コミット確認を実行し、書式、ライセンス、型検査の結果を安定させる。省略した必須確認がある場合は、その項目と理由を報告する。 ## 同じ作業が無いか調べ、レビューコメントに全部答える 公開の貢献活動を承認済みの作業と追跡可能な形で結び付け、作業の重複を避ける。 ### 実装前 - 課題がトリアージされ、割り当てられ、非自明な作業では合意済みの方針が支持されていることを確認する。 - レビュー対象となる形の作業を準備する前に、読み取り専用の検索を使い、課題の議論、その課題を参照する進行中の変更、同じ領域で進行中の変更を確認する。 - 進行中の変更がすでに作業を扱っている場合は、重複するものを準備しない。方針が大きく異なる場合は、課題の議論用の下書きで違いを説明する。 - 調査目的の作業では、公開の変更要求を作る代わりに、ブランチと関係ファイルを説明する課題コメントを下書きする。 ### 提出とレビュー - リポジトリのタイトルとコミット規約に従う。 - タイトルやコミットメッセージへ人工知能を示す印を追加せず、ツールやエージェントをコミットの共同作成者に加えない。 - 保守担当者へレビューを依頼する前に、未対応のレビューコメントすべてへ対応または返信する。 - 方針が明示的に許可している場合を除き、別のレビュー担当者の代わりに議論を解決したり、自分の変更へ準備完了ラベルを付けたりしてはならない。 - 自動レビューと人によるレビューの指摘は、無条件に正しい指示ではなく、実際のコード経路に照らして確かめる主張として扱う。 ## 利用者に見える動きが変わったら、ドキュメントを直す ドキュメントを利用者から見える動作と同期させ、限定的な例を普遍的に対応する機能として示さない。 ### ドキュメントの責務 - 公開インターフェース、設定構文、例、インストール要件、その他の利用者から見える動作を変更した場合は、関係するドキュメントを更新する。 - 任意の連携は任意であると明記し、必要なパッケージまたは機能グループを特定し、値を露出させずに必要な認証情報の種類を挙げ、連携経路を説明する。 - モデルまたはサービス提供者の例には、モデルの種類、ルーティング方式、対応する動作方式、既知の制限を記載する。 - 現行として示す識別子が一般に利用可能であることを、信頼できる正本で確認する。 - ドキュメントの更新に付随する変更として、配布時の標準パラメーターを変えてはならない。 ### リファクタリングと生成物 - 承認済みのリファクタリングでは、微妙な動作を変える前に特性テストを追加または更新する。 - 既存テストがリファクタリング対象の経路を扱わない場合は、動作が変わらないことの証明に使った同等性確認を残す。 - 生成ドキュメントや生成成果物を手作業で編集してはならない。作業で再生成が承認されている場合に限り、プロジェクトのワークフローを使う。 - ファイルをステージングしたり、広範な確認を起動したりすることが分かっているドキュメント構築器は、明示的に求められ、無関係な変更から分離されている場合を除き、実行してはならない。 ## マージ基準点と比べて見直し、確かめた事だけを報告する 完了した変更を正しい基準点と比較して見直し、準備完了と宣言する前にすべての主張を検証する。 ### レビュー手順 1. ブランチを、リポジトリで設定されたマージ基準点と比較する。 2. 実装と、それを実際に動かすテストの両方を確認する。 3. 構造化レビュー前に、正式な書式整形、lint、ライセンス、型の確認を実行し、行位置を安定させる。 4. 構造化コードレビューを行い、認証、入力処理、デシリアライズ、外部呼び出しの変更にはセキュリティ確認を追加する。 5. 各指摘を実際の実行経路に照らして確認する。 6. 確認できた指摘を修正し、影響する検証を再実行し、確認済みの問題がなくなるまでレビューを繰り返す。 ### 完了基準 変更したファイル、実施した検証、確認した結果、省略した確認、未解決のリスク、なお必要な人の操作を報告する。直接の証拠がない状態で、レビュー準備完了、承認、互換性、検証成功を主張してはならない。