REA CI とテスト監査
どのチェックが依然として実際のリグレッションを検出し、どのコストを削除してもその防御力を損なわないかを確立します。成果は、検証済みの修正、エビデンスに基づく推奨、または明示的な中止判断となります。
チェックアウトの AGENTS.md、テストガイド、およびコントリビューションルールに従ってください。以前の監査から覚えているコマンドではなく、現在のコマンドと固定されたツールチェーンを使用してください。要求されたスコープを維持してください。調査だけでは編集は許可されません。このスキルは Issue の公開、プッシュ、マージの権限を付与しません。既存のユーザー承認は引き続き適用されます。監査ノートと生結果は追跡対象ツリーの外、通常はタスク固有の /tmp ディレクトリに保管してください。
実行されたベースラインを確立する
ユーザーが最新の main を要求したときに取得します。ベースライン SHA と検査対象のワークフローリビジョンを固定します。コードを変更または比較するときは、分離されたワークツリーを使用してください。別のタスクのチェックアウトを変更しないでください。ダーティな変更、および正確なコマンド、ツールチェーン、ホスト、選択されたテスト、計装、前提条件を記録してください。古い実行は、たとえ main が進んでも、その実行されたリビジョンのエビデンスとなります。
ワークフロートリガー、変更パス選択、ジョブ依存関係、再利用可能なアクション、パッケージスクリプト、テスト発見、アーティファクトプロデューサー、レポートゲートを、実際に実行されるコマンドまでトレースしてください。スクリプト、生成データ、ランタイム登録、インポートグラフに欠けているサブプロセス境界を含めてください。ポジティブセレクションパスとネガティブセレクションパスの両方を確認してください。必要なファイルは、意図されたテスト構成ごとに1回発見されなければなりません。意図的なプラットフォーム/構成の繰り返しは別個のカバレッジです。明示的なテストの欠落や必要なレポートの欠落がグリーンになってはいけません。オプションレーンはスキップしても構いませんが、その記載された前提条件は保持してください。
既存のタイミングと失敗のアーティファクトを使用して、疑わしいファミリーを選択してください。関連するチェックを実行してベースラインを確立してください。広範な CI 診断や、焦点を絞ったチェックでは解決できない不確実性のためには、完全なローカルスイートを予約してください。すべてのドキュメント編集のたびに、変更されていない完全なスイートを再構築または再実行しないでください。
障害または防御を証明する
各候補について、期待される観測可能な動作とその所有者を述べ、次に本番動作に対する最小の再現を構築してください。修正箇所を決定する前に、プロデューサーと影響を受けるコンシューマを追跡してください。
- ドリフトの場合: フィクスチャを現在の受理要件、プロトコル応答、名前付きコントラクト、ツールバージョン、実際のパブリックエントリポイントと比較してください。もっともらしいモックは、そのテストがカバーすると主張する動作の前に失敗する可能性があります。影響を受けるフィクスチャファミリー全体（他のバージョン文字列を含む）を検索してください。意図的に不正なフィクスチャは保持し、意図された拒否をテストしてください。
- 疑わしいグリーンテストの場合: 分離されたコピーで関連する動作を摂動させるか、制御された障害を注入してください。既存のアサーションまたはゲートがそれを検出することを確認してください。テストが単にモックを繰り返しているだけ、廃止されたコードをインポートしているだけ、またはサブプロセス/チェッカーの障害を隠している可能性があります。実験後はミューテーションを元に戻してください。
- 共有セットアップまたはプルーニングの場合: 異なるアサーションを保持されているシナリオにマッピングしてください。不正な入力、キャンセル、クリーンアップ失敗、パーミッション、キャパシティ、アイデンティティ、意味のある並行性相互作用を保持してください。ケースをスキップしたりオラクルを弱めたりする高速実行は改善ではありません。
- プロバイダカバレッジの場合: 偽プロデューサー、境界、実際のエンジンのエビデンスを分離してください。名前付きのスキップと前提条件を検査してください。フィクスチャは実際の Ghidra、LLDB、ブラウザ、またはその他のプロバイダの動作を確立しません。
発見事項を、再現された欠陥、サポートされるコスト、仮説、または利用不可のエビデンスとして分類してください。ベースラインコマンド、観測された出力/終了ステータス、期待される結果、影響範囲、競合する説明を記録してください。main での障害は既存のものである可能性があります。それ自体で CI 監査に関係なくなるわけではありません。PR の障害は、実行されたリビジョンとクリーンなベースラインを使用して属性付けし、以前の障害との類似性だけで判断しないでください。特定の一時的な説明をテストするためだけに再試行してください。元の障害は保持し、繰り返しがエビデンスを追加しなくなったら停止してください。合格した再試行は根本原因や修正を確立しません。
ゲートを失わずに効率性を評価する
速度低下、キャッシング、ランナー待機、共有アーティファクト、ログノイズを調査するときは、測定と CI チェックを読んでください。同等の完了した作業を比較してから、高速化を主張してください。セットアップ/ビルド時間、テスト実行、カバレッジ計装、依存関係待機、ランナースケジューリングを区別してください。どのコストが未測定のままかを述べてください。
正確性カバレッジを縮小する前に、証明済みの重複準備の削除、不変セットアップの再利用、繰り返されるサブプロセス作業の削減を優先してください。ライフサイクルまたは並行性がオラクルである場合は、独立したセッションを保持してください。ライブテストは新鮮に保ってください。キャッシュされた以前の合格は、現在のホスト、インストールされたプロバイダの内容、パーミッション、または外部状態を検証できません。
修正、検証、およびスコープ内で引き継ぐ
実装が許可されている場合、所有する境界で最小の構造変更を行い、正しい理由でベースラインで失敗するリグレッションを追加してください。影響を受けるコンシューマと意味のあるネガティブパスを再テストしてください。それらのメカニズムが変更された場合は、キャッシュ無効化または発見を検証してください。インストールされている Turbo ドキュメントを読んでから、その設定またはコマンドを変更してください。
リポジトリの該当するチェックを実行し、承認されたマージの前に完全な現在の HEAD CI 結果を検査してください。必要なカバレッジと発見ゲートを保持してください。障害を抑制したり、無差別再試行を追加したり、タイムアウトを引き上げたり、CI をグリーンにするためだけに異なるアサーションを削除したりしないでください。これらの制御への変更には、独自の実証された理由と保持された障害検出が必要です。
確認された各 Issue を、正確なリビジョン、再現、結果、提案された修正、検証の限界とともに報告してください。パフォーマンスは、パーセンテージだけでなく、ワークロードと測定値で報告してください。要求された場合は英語で Issue/PR レコードを使用してください。ユーザーの割り当て、コミット ID、レビュー、マージの設定に従ってください。ただし、他のユーザーに対してそれらを想定しないでください。承認されたライフサイクルがある場合のみ、レビュー準備完了の PR をオープンしてください。必要なレビュー結果を解決し、マージ後にテストされたツリーに対して最終的な main を確認してください。
承認された作業が検証されたとき、残りの利点が証明されていないとき、またはさらなる変更が正確性を投機的な速度と交換することになるときに停止してください。本当の不確実性をリストアップしますが、それらを追加の最適化ラウンドに変えないでください。