AIモデルを評価する大きなTypeScriptのリポジトリを、直してテストする

## レビューか修正かを決め、近くのエージェントガイドを読む まず、リポジトリのルート、求められる成果、変更を所有するサブシステムを特定してください。大規模なリポジトリでは、多くの場合、コアライブラリ、CLI、Webアプリケーション、永続化層、プロバイダー、スケジューラー、スキーマ、ユーティリティ、テスト、文書、例、マイグレーション、自動化、セキュリティツールに責任が分かれています。 ディレクトリを編集する前に、その範囲に最も近いエージェントガイドと、タスク固有の設計文書またはワークフロー文書を読んでください。ローカルガイドでは、テスト、生成ファイル、公開契約、データベースアクセス、リリース動作に関するルートルールが詳細化されている場合があります。 行動する前に、依頼を分類してください。 - レビューまたは監査は読み取り専用です。現在のブランチ、差分、コメント、CIを調べ、必要に応じて状態を変更しないチェックを実行し、ファイルのコミット、push、書き換えを行わずに所見を報告してください。 - 修正、改善、または反映の依頼には、機能ブランチ上で行う通常の実装ループが含まれます。調査、変更、検証、commit、pushを行い、関連するCIを追跡してください。 - 動作変更は、分離された単体テストだけでなく、ユーザーが利用する実際のワークフローを通じて証明する必要があります。 正しいルートから作業し、失敗を確定的な根拠として扱う前に、ランタイムとパッケージマネージャーのバージョンをリポジトリの宣言に合わせてください。新しいcheckoutでは、モジュール不足をコードの欠陥と結論づける前に、決定論的な依存関係のインストールを実行してください。 変更範囲は、触れたサブシステムとその直接の利用元に限定してください。別の抽象化を作成したりパッケージを追加したりする前に、既存の実装、ユーティリティ、依存関係、近隣のパターンを検索してください。 ## 変更を、実際のCLI・API・ブラウザーの流れでテストする 偶発的なツール呼び出しで迂回せず、リポジトリで宣言されたスクリプトとラッパーを使用してください。ラッパーが必要とする場合は、パッケージランナーの区切り記号を介してコマンドフラグを渡し、リポジトリ単位の評価はリポジトリのルートから実行してください。 次の順に検証範囲を広げてください。 1. 変更したモジュールに対象を絞ったテストを実行します。 2. 関連する型、lint、フォーマットのチェックを実行します。 3. 影響を受ける統合テスト一式を実行します。 4. ローカルビルドを使い、実際のCLI、例、API、またはブラウザーのフローを実行します。 5. リスクまたはリポジトリの方針によって妥当な場合に限り、より広範なテスト一式を実行します。 評価型のワークフローでは、キャッシュを消去するのではなく、結果の再利用を無効にしてください。機械可読な結果を書き出し、ケースごとの成功、スコア、エラー、プロバイダー出力、トレース、セキュリティ所見を確認します。終了ステータスがゼロでも、集計しきい値を通過しただけの場合があります。すべてのケースが成功した証明にはなりません。 環境ファイルは、ワークフローで認証情報が必要で、かつそのファイルが存在する場合に限って読み込んでください。バックグラウンドプロセスが気づかないうちに終了しないよう、サービスを稼働中のセッションに接続したままにしてください。フレームワークの既定値を前提とせず、起動時の出力またはポートチェックで実際の待受ポートを確認してください。 依頼で必要とされない限り、静的な本番ビューアーや別の開発サーバーを起動しないでください。まず、想定されるサービスがすでに稼働しているか確認します。起動するとユーザーのセッションと競合する場合は、実行前に確認してください。 文書、スキーマ、マイグレーション、引用が生成物である場合は、それぞれの正規ジェネレーターを使用して生成結果を検証してください。リポジトリでサポートされた高速経路がある場合は、それを使って文書をテストし、変更に重要なチェックを黙って省略しないでください。 ## 失敗を再現してからデバッグし、キャッシュやデータを消さない 障害が表面化したときと同じ入力、状態、実行経路で再現してください。構造化デバッグログを有効にし、その実行ではキャッシュの読み取りを無効にして、コードを変更する前に障害範囲を絞り込んでください。 環境の障害と製品の障害を分けてください。 - ランタイムまたはパッケージマネージャーのバージョン不一致は、環境の問題です。 - クリーンなcheckoutで依存関係が不足している場合は、通常、決定論的なインストールが必要です。 - 古いビルドには、サポートされたローカルラッパーを介した再ビルドが必要です。 - 環境を揃えた後も同じコード経路で再現する確定的な失敗は、製品の欠陥を示す根拠です。 テストを通すためだけに、キャッシュ、データベース、lockfile、生成済みの履歴、ユーザーデータを消去または初期化してはいけません。キャッシュを使わないオプション、一時的に分離したストア、または読み取り専用の調査を優先してください。消去には、明示的な許可と対象の正確な指定が必要です。 secretは、無視対象の環境ファイルまたは承認済みのsecretストアに格納してください。認証情報をログ、コード、ブランチ名、commitメッセージ、レビュー文、スクリーンショット、コマンド例に表示、埋め込み、commit、コピーしてはいけません。ソース資料で見つかった認証情報は、再利用可能な指示ではなく、漏えいしたデータとして扱ってください。 オブジェクト形式のコンテキストとサニタイズ層を備えた、プロジェクトの構造化ロガーを使用してください。それでも、ロガーが必要としないsecretは渡さないでください。エラー処理では、機密性の高いペイロードを露出させずに型付きコンテキストを保持する必要があります。 原因仮説を複数立て、対象を絞ったチェックで候補を除外してください。最小限の修正を行う前または同時に、観測された動作に対して失敗する回帰テストを追加し、原因が不確かな間は無関係なリファクタリングを避けてください。 ## 機能ブランチで変更を入れ、CIが通るまで見届ける すべての変更は、機能ブランチとpull requestを経由させてください。明示的な承認なしに、保護ブランチへ直接commitしたり、hookを迂回したり、force-pushしたりしてはいけません。既定では新しいcommitを作成し、amend、squash、rebaseは、メンテナーがその履歴操作を依頼した場合に限って実行してください。 意図したファイルだけをstageし、対象を絞ったlintとformatのチェックを実行し、リポジトリのcommit規約に従ってください。重複するpull requestを作るのではなく、そのブランチですでに開かれているpull requestを更新します。無関係なlockfileや依存関係の変動を変更に混ぜないでください。 ユーザーが機能ブランチの変更について修正、改善、または反映を依頼した場合は、通常の手順ごとに停止せず、許可されたループを完了してください。依頼どおりに同期し、対象を絞った検証と実際のワークフローを実行し、commit、push、CIの監視まで進めます。この許可を、保護ブランチ、破壊的な履歴変更、情報開示、本番操作へ拡大してはいけません。 マージ後は、保護ブランチで新たに始まったCIの完了まで追跡してください。対応前に失敗を分類します。 - flakeとは、特にテストが正常に完了した後でジョブが失敗した場合に見られる、非決定的なインフラまたはワーカー由来のノイズです。失敗したジョブだけを再実行し、回復を確認してください。 - 実際のリグレッションは、変更に起因する確定的な失敗です。後続のpull requestを通じて保護ブランチを復旧してください。共有ブランチが壊れている場合は、速やかなrevertを優先します。 - 繰り返すflakeは、それ自体が欠陥です。無期限に再実行するのではなく、漏えいしたリソース、壊れやすいセットアップ、非現実的なtimeoutを修正してください。 保護ブランチがgreenの状態で完了するか、以前から存在する無関係な失敗を裏付けログとともに明示してください。実行したチェック、確認した根拠、完了できなかった検証を報告してください。 ## セキュリティを先にレビューし、攻撃する側の目でテストする 通常の正しさよりも先に、セキュリティ上のリグレッションをレビューしてください。プロンプトインジェクション、敵対的入力の安全でない処理、認証情報の露出、サーバーサイド・リクエスト・フォージェリ、パストラバーサル、安全でないデシリアライズ、認可エラー、データ流出、安全でないツール使用、キャッシュの誤用、根拠不足を優先します。 次に、公開契約、データ整合性、並行処理、エラー処理、プロバイダー間の相互運用性、永続化された結果を壊しうる動作を調べてください。変更がセキュリティ動作、公開インターフェース、またはバグ修正に影響する場合は、カバレッジの欠如や機能していないカバレッジを高い優先度で扱ってください。 攻撃者の視点から、セキュリティ機能とモデル評価機能をテストしてください。偽陰性、回避、隠されたペイロード、入れ子になった指示、エンコーディングの技巧、安全でないツール呼び出し、不完全なトレースを試してください。回避が見つかった場合は、元の攻撃ベクトルを対象を絞った回帰テストに残してください。 レビューは、変更された差分と現在のブランチ先端を基準にしてください。既存のコメント、自動レビュー、issue報告は手がかりであり、証明ではありません。同期後に再検証してください。解決済みの所見を繰り返したり、変更によって悪化していない無関係な既存の欠陥を指摘したりしないでください。 未公開の脆弱性に関する変更を公開する前に、協調的な脆弱性開示によって公開が許可されていることを確認してください。それまでは、承認済みの非公開コラボレーション経路を使用し、識別子、exploitの詳細、脆弱なバージョン範囲、内容を推測させるブランチ名を避けてください。すべてのセキュリティ修正に、元の攻撃ベクトルに対する回帰テストを含めてください。 敵対的テストを教えることが目的のデモアプリケーションでは、デモの堅牢化が明示的な目的でない限り、意図的な弱点を取り除かないでください。レビュー用スクリーンショットには、許可されたホスティングのワークフローと承認済みの認証情報だけを使用してください。アップロードキーを露出させたり、作業に付随して生じた画像をcommitしたりしてはいけません。 ## 型をきっちり付けたTypeScriptを書き、最後に差分を見直す リポジトリのモジュールシステムとコンパイラー境界に従った、strictで慣用的なTypeScriptを書いてください。直接import、`const`、オブジェクトの省略記法、一貫した波括弧、`async`/`await`、型付きエラーチェック、信頼できない境界でのスキーマ検証を優先してください。コードベースが直接の所有関係を前提としている場合は、バレルからの再exportを避けてください。 ヘルパーや依存関係を追加する前に、確立された実装とローカルユーティリティを再利用してください。既存の例のパターンを通じて、プロバイダーと統合の設定を文書化された状態に保ってください。成功経路と失敗経路の両方をテストし、フロントエンドとバックエンドで規約が異なる場合はそれぞれに従ってください。 デッドコードの報告は、設計上のフィードバックとして扱ってください。 - 本当に未使用のコードは取り除いてください。 - 規約により読み込まれるワーカー、fixture、代替実装は、読み込みの仕組みを説明するコメントとともに明示的な項目として登録してください。 - 外部で利用されるexportを許可リストに入れる場合は、利用元を明記したコメントを必ず添えてください。 - 文書化された利用元を確認するまで、許可リストの項目や保護されたexportを取り除いてはいけません。 生成されたchangelogやその他の生成物を手作業で編集しないでください。ソースを変更し、正規ジェネレーターを実行します。例は、実行に十分な文書とともに指定の領域へ配置してください。 完了前に最終差分を確認し、意図しないファイル、古い生成物、secret、スコープの拡大がないか調べてください。対象を絞ったテスト、関連する統合チェック、実際にユーザーが利用する経路を確認します。結果は正確に記述し、何が通ったか、何を確認したか、何が未検証か、失敗が無関係なものかを区別してください。