hunt-regressions

候補の検出

使用する場合

入力：封印済みの準備資料、凍結済みの S0/S1、変更のコンテキスト、レジストリの割り当て。 再試行時は、この割り当てにおける以前の候補 ID マッピングを含めます。独立して使用する場合も含め、これらは呼び出し元が指定します。 対象作業に着手する前に、プロジェクトガイダンスに従ってください。

使用しない場合

既知の候補を立証する場合は使用しません。再現を使用してください。検出では発見事項を確認できません。

調査

1. 標準と ファイル契約を読みます。準備状況を確認し、凍結済みの変更メッセージ、PR の議論、セキュリティ文書を読んで、意図とサポート対象の用途を把握します。
2. 差分全体を確認し、呼び出し元から実際のインターフェースまで、変更された動作をたどります。 凍結済みの情報源と提供されたコンテキストを使い、後からの修正、アドバイザリー、その他のレビューは使いません。
3. 各手掛かりについて、変更されたコード、以前サポートされていた動作、到達可能なトリガー、提案する新たな欠陥、誤検出の確認事項、必要な証明を記録します。古いバグまたは不完全な修正を示唆する、提供済みの手掛かりは、判定のために残します。 PoC の作成は再現に委ねます。
4. 安定した仮説キーと割り当てられたエージェントハンドルを使い、registry.py の candidate を通じて各手掛かりの ID を確保します。再試行時は同じキーを再利用します。 候補ファイルと hunt.json に、ID、ファイルのマッピング、網羅範囲、制限事項を記録します。 リストが空でも有効です。 作業が妨げられた場合は、部分的な網羅範囲と未確認の領域を記録します。パッケージを封印します。

結果の報告

詳細な証拠は封印済みパッケージに保管します。返す内容は次のみにしてください。

• Status: complete または blocked。記録と一致させます。
• Record: 封印済み hunt.json のパス、または生成されなかった理由。
• Result: 候補数と重要な網羅範囲の不足。
• Blocker: blocked の場合、不足している前提条件または必要な呼び出し元の対応。

退けるべき合理化

• 「ヘルパーが、作り出した入力で失敗する」：そのヘルパーに到達する、サポート対象のインターフェースを示してください。