AIが作ったプルリクエストを、人のレビューを通してオープンソースに出す

## AIの作業だと明記し、自分で作ったブランチだけにプッシュする 外部への書き込み、課題チケットの所有権、ブランチ、帰属表示を、統制された操作として扱う。 - AIが生成したプルリクエストの説明、レビューコメント、課題チケットへのコメントであることを明示し、プロジェクトが求める場合は人間の操作者名を記載する。 - 操作者または作成者の身元は、認証済みの情報源から特定する。身元を推測してはならず、取得に失敗した場合は名前を省く。 - AIが支援したコミットには、所定の共同作者トレーラーを追加する。 - プロジェクトの上限がその値である場合、操作者1人につき1日に10件を超えるプルリクエストを開かない。数を増やすより、少数の完成した十分にテスト済みの変更を優先する。 - 適格で未割り当ての課題チケットだけを扱う。実装前に課題チケットを操作者へ割り当て、作業中の状態へ移す。 - エージェント自身が作成したブランチだけへプッシュする。明示的な許可なしに貢献者のブランチへプッシュしてはならない。 - 上流リポジトリへ未整理のブランチを増やすより個人フォークを優先し、トピックと課題識別子を含む有用なブランチ名を付け、マージまたは却下の後にブランチを削除する。 プルリクエストのメタデータを最新に保つ。プッシュするたびにタイトルと説明を更新し、変更一式の全体を正確に表す状態を維持する。 ## コードを直す前に、変更の履歴と過去の課題チケットを読む 誤って見えるコードが欠陥だと決めつけない。長期間運用されてきたシステムでは、現在の実装からは見えない過去の制約がコードに組み込まれていることが多い。 1. 報告された問題を再現して妥当性を検証し、不完全または誤った前提を問い直す。 2. ファイルの履歴と変更行の作成者情報を調べ、関連するコミットメッセージと紐づく課題チケットを読んで、コードが存在する理由を理解する。 3. 関連する課題チケットを検索し、却下された方法、過去の議論、意図的な判断を確認する。 4. 対象領域の設計文書を読み、特にセキュリティ、テレメトリー、ログコンテキスト、公開命名契約を確認する。 5. あるモジュールが別のモジュールを置き換えた場合は、意図した変更と偶発的な欠落を区別する。 6. 提案した修正が過去の意図的な変更を元に戻す場合は、立ち止まって再検討する。それでも元に戻すことが妥当なら、当初の理由があるにもかかわらず必要な理由を説明する。 実装前に、判明した事実、リスク、曖昧さ、問題自体が無効である可能性を操作者へ提示する。プルリクエストをレビューする時も同じ厳密さを適用する。 外部依存関係の現在のバージョン、リリース、動作は、信頼できる正本で検証する。変化する外部プロジェクトについて、モデルの学習知識だけを根拠に断定してはならない。 ## テストの固定スリープを、時間の上限がある待ち方に置き換える テストで固定時間のスリープを使用してはならない。テストが遅く、不安定で、非決定的になる。 - コンポーネントに時間制限付きの標準アサーションがある場合、それがすでに表現できる条件にはそのアサーションを使う。 - 次の操作前に中間件数を待つ場合など、それ以外の条件には非同期待機ユーティリティを使う。 - 標準のブロッキングアサーションをポーリングユーティリティで包まない。既存のラッチの周りで重複してポーリングすることになる。 - 待機ユーティリティを使う場合は、最大タイムアウトを必ず明示する。 - アサーション付き条件または明確な述語を使い、ビジーウェイトループは決して使わない。 - 固定時間のスリープを含む既存テストを変更する場合は、標準の時間制限付きアサーションまたは汎用待機ユーティリティへ移行する。 たとえば、`MockEndpoint.assertIsSatisfied()`は内部ですでに待機し、Awaitilityは`MockEndpoint`で表現できない条件に適している。新しいテストへ`Thread.sleep()`を導入してはならない。 ## 誰を信頼するかを決め、脆弱性は非公開の手順で報告する 誰を信頼するか、信頼境界をどこに置くか、何がフレームワークの責任に属するかは、プロジェクトの正規の脅威モデルに基づいて判断する。 - コード作成者とデプロイ操作者が実行可能なルート、式、機密情報、ネットワーク公開範囲、ランタイム設定を意図的に構成する場合、その作成者と操作者を信頼された主体として扱う。 - 外部メッセージ送信者と、信頼されたルートを流れるすべてのデータを信頼できないものとして扱う。 - フレームワーク自体が、信頼できないデータをコード実行、ファイル読み取り、リクエスト偽造、認可回避へ変換してはならない。 - 信頼された作成者による意図的なコード実行、操作者の設定ミス、明示的なオプトインで有効になった危険な動作は、それだけではフレームワークの脆弱性ではない。 有効な指摘は、既定または合理的に想定される構成で信頼境界が破られることを示す。典型例には、安全でないデシリアライズ、XXE、式インジェクション、パストラバーサル、SSRF、ヘッダーを利用したディスパッチの悪用、認証または認可の回避、機密情報の漏えい、安全でない既定値、フレームワークが構築するクエリへのインジェクションがある。 必要な制御を欠くリソース枯渇、意図的に公開した管理画面、到達不能な推移的依存関係に関する指摘、境界侵害の実証を伴わないスキャナーの出力は、通常フレームワークの対象外となる。 疑わしい脆弱性を公開の課題チケット、プルリクエスト、メーリングリスト、その他の公開経路で開示してはならない。非公開の報告手順に従い、公開作業を停止する。 ## 信頼できない受信データを止め、危ないセキュリティ設定は既定で無効にする コンシューマー、パーサー、データ形式、型変換器、集約ストア、セキュリティに関わるオプションを、具体的な悪用経路に照らしてレビューする。 - 信頼できない受信メッセージからフレームワーク内部のヘッダーを、厳密かつ大文字小文字を区別しない方法でディスパッチ前に除外する。 - 適切な入力フィルターなしに、信頼できないオブジェクトをデシリアライズしてはならない。 - 機密情報を機密情報用メタデータとして印付けし、安全でない構成スイッチをリスク分類に割り当てる。 - セキュリティに関わる既定値は、明示的に有効化されない限り拒否を維持する。既定値の緩和には、アップグレードノートとメンテナーの明示的な承認が必要となる。 - 認証と認可のオプションが、発行者、対象者、署名、および保護すると明示したすべてのサブパスを実際に検証することを確認する。 デプロイでは、本番用セキュリティプロファイルを使い、承認済みの保管庫から機密情報を解決し、検証済みTLSを構成し、信頼できないコンシューマーで安全でないシリアライズを無効にし、管理画面とランタイム管理機能を信頼されたネットワーク内に限定する。 セキュリティレビューでは、信頼されたルートの動作とフレームワークの動作を区別しながら、信頼できないデータが境界を越えることを防ぐ。 ## 変更ごとにテストとユーザー向け文書を足し、生成物もコミットする すべての機能追加とバグ修正には、適切なテストとユーザー向け文書が必要となる。変更した既定値、検出動作、名称変更または提供を終えたオプション、ヘッダーの変更、APIまたはSPIの変更、非推奨化、移行手順を該当ガイドに記載する。 - 変更範囲に対して、リポジトリ所定のフォーマット、インポート順、スタイル、単体テスト、統合テスト、ソース検査を実行する。 - 生成物を再生成してコミットし、生成された変更をCIが初めて見つける状態にしない。 - ローカル検証で全解析器を実行しない場合でも、静的解析の新しい問題、保守性の低下、一般的な弱点パターン、非推奨APIを持ち込まない。 - 2つのクラスが同じ単純名を持つ場合を除き、完全修飾クラス名ではなくインポートと単純名を使う。生成コードの明示的な除外規則を維持する。 - 新しい公開APIの型とメソッドには、所定の導入バージョンタグを追加し、次回リリースのバージョンを使い、他の文書タグの後に配置する。 - 入れ子の拡張機能を検出するすべてのメタデータレジストリを更新する。ソースディレクトリがあるだけでは、ビルド、カタログ、生成文書から拡張機能が見えるとは限らない。 - 統合テスト用コンテナでは、対応するすべてのアーキテクチャを検証する。イメージが存在しない場合は、承認済みレジストリミラーまたはアーキテクチャ別の明示的なスキップを使う。 - 内部ページには内部文書参照を使い、バージョンをまたぐアンカーは開発ブランチだけでなくリリース済みの対象でも検証する。 機能を非推奨にする場合は、ビルドメタデータ、APIアノテーション、文書タイトル、アップグレードガイドを一緒に更新する。 ## マージの前に、2人にレビューを頼み、人の承認を1件もらう プルリクエストがレビュー可能になった時だけレビューを依頼し、下書きの間は決して依頼しない。 - 最近のファイル履歴と変更行の作成者情報から関連する現役メンテナーを特定し、適切なレビュー担当者を少なくとも2人指定する。 - すべてのコメントへ対応して検査を成功状態へ戻した後、既存のレビュー担当者へ再度レビューを依頼する。 - 未解決のレビュー会話が1つでも残っている間はマージしてはならない。 - 人間による承認を少なくとも1件必須とし、エージェント自身のプルリクエストを自ら承認してはならない。 - リリースマイルストーンを対象ブランチから導出し、課題チケットを閉じる前にマイルストーンと課題チケットの修正バージョンを両方設定する。 - プルリクエスト作成者をプログラムで特定し、プルリクエストと課題チケットを正しく割り当て、課題チケットと変更内容に対応するカテゴリラベルを付ける。 - フォーマット、型検査、lint、テスト、セキュリティ検査がすべて成功する1本の成功チェーンの後ろに、公開とマージを置く。 - 最終マージコミットに所定のAI共同作者情報を保持する。 - マージ後に、修正バージョンとプルリクエストへのリンクを付けて課題チケットを解決し、ブランチを削除する。 ユーザーから見える動作、意味のある検証、文書への影響、未解決のリスク、実行できなかった検査を要約する。ローカルテストだけではCIの成功を証明できず、証拠が不完全な状態でリリース準備完了とは言えない。