天文エージェントのデバッグと振り返り
症状を最初に失敗した契約に特定し、必要なレイヤーを修正し、それぞれのレイヤーに対して、正しく動作していること、メカニズムが有効であること、実際の利益があることを個別に証明します。3つの結論は独立して記録されます。
本スキルは「天文agnet」プロジェクトの読み取り可能な履歴資料から抽出されたものです。ケーススタディは診断の手がかりであり、現在の実装に同じ欠陥が存在することを意味するものではありません。履歴の予算、ノード、日付、カード名、合格ラインは新しいタスクのデフォルト定数と見なすことはできません。
身元の確立
目標が、バグ修正、診断、等価加速、戦略スコア向上、または修正の納品のいずれであるかを確認します。実際のパスと現在のバージョンを特定し、CURRENT、フリーズリスト、レシート、最終パッケージを確認します。身元は、ソースコード、入力、設定、結果のハッシュに基づいて決定されます。
公式プロトコル/スコアラーのバージョン、オンラインで可視のフィールド、initializeの制約、実行モード、CPUキャリブレーション、独立したウォールクロック制限を記録します。サイトの一般的なエラーメッセージまたは同名のローカルカードがある場合にのみ、クラウド側の根本原因はまだ特定されていません。
完全有効、予算終了、技術的失敗、ユーザー中断、診断完了だが科学的ゲートを通過していない、を区別します。一部の季節スコアは完全シーズンランキングに含まれません。欠損値はnullのまま保持します。
症状に応じたリファレンスの参照
- 不正なアクション、起動/ABI/manifest/ZIP、データ番号、バックアップクリーンアップ： protocol-and-data.md を参照。
- 割り当てが多いが低スコア、ゼロスコア、レポート漏れ、REQ/リクエスト漏れ、再生の不一致： state-and-physics.md を参照。
- タイムアウト、モデルに利益なし、診断加速でシーズン全体が変わらない、ホールドアウト/検収失敗： budget-and-experiments.md を参照。
- 過去の反例と修正証拠の確認： casebook.md を参照。原ファイルの身元確認： evidence.md と corpus-index.tsv を参照。
最初の不一致点を見つける
実際のデータフローに従って比較します：入力/制約 → 消費メッセージ → 状態/キャッシュ → 候補エントリー → フルスコア/割り当て → 最終アクション → 公式実行 → フィードバック決済。
同じ入力からの最小失敗状態または不変トレースから最初の不一致点（first divergence）を見つけ、期待値、実際の値、単位、分母、サンプル選択とソースを保存します。ソースコード再現、ログ関連付け、メカニズム仮説、利益証拠をそれぞれラベル付けします。
まずプロトコル、身元、再生の汚染を修正し、その後科学的差異を説明します。忠実な再生（faithful replay）は元の消費シーケンスを再現します。過去の振る舞いを変更することは新しい候補であり、元のトレースに混入してはいけません。初期化または重要なメッセージが欠落している場合は、識別可能な境界で停止し、隠れた状態を補完してはいけません。
最小限の反証可能な対照の設計
一つの仮説には、それを反証できる一つのテストを対応させます。合成フィクスチャで境界を検証し、公開状態シャドウでエントリーと選択メカニズムを検証し、完全ペアシーズンで総合パフォーマンスを検証し、独立ホールドアウトで限定された汎化を検証します。各レイヤーはそのレイヤーの結論のみをサポートします。
今回関連する保留項目を列挙します：物理/スコアリング、公開情報、RNG、メッセージ順序、台帳、ネイティブABI、候補/tie順序、課金。等価加速がアクションや候補セットを変更する場合、戦略変更として再分類します。
戦略候補はまず、実際の候補チェーンに入れるか、精密計算されるか、完了保護を満たすか、実行選択を変更するかを追跡します。所定のメカニズムゲートを通過しない場合は、その仮説を閉じます。プロトコル修正は実際の境界反例を使用して検収し、正常カードのアクション変更を強制しません。
限定された検証の実行
スコアリングとリモートモデルは現在の認可と限られた予算を継承し、クローズされた研究の残りクォータは継承しません。変更に応じて意味のある境界、差分、正常コントロールを選択します。
プロジェクトがレジストラを使用する場合、起動前に planned が成功したことを確認し、身元の読み戻し、ソース/入力ハッシュと出力分離を確認します。登録が失敗した場合は、まず失敗を処理します。例外は still finally で実際のコストとリクエスト回数を決済します。技術的修正はサブバージョンを使用して失敗した親バージョンを保持します。事後登録は retrospective と明記します。
最終ソースコードは同一起源、同一入力、同一課金 OFF/ON で比較します。ソースコード変更後は、そのソースコードに一致する証拠のみを参照します。所定のゲートを項目ごとに報告します：完全な最終状態、予算、REQ、リクエスト、科学/総スコア、要求されたAPIロール。必須ゲートのいずれかが失敗した場合は未検収です。
失敗後は、新しい証拠を持つ根本原因仮説に切り替えます。シードを変更したり、ソースコードを選んだり、合格ラインを変更したり、スキャンを拡大したりすることは、元の検収の修正ではありません。選択または診断に使用されたホールドアウトセットは開発データに変換され、その後の汎化には新しいホールドアウトが使用されます。
出力と完了基準
問題の規模に応じて出力します：
症状と最初の失敗箇所：
証拠レベルとソース身元：
根本原因 確認済み / 未確認：
最小変更と保留項目：
結果：プロトコル / 状態 / メカニズム / 全シーズン / ホールドアウト / デプロイメント
失敗、未実行項目、不確実性：
次の仮説を区別するための最小テスト：
アップロードパッケージは最終フリーズソースコードから生成され、新しいディレクトリで公式manifestパーサーによってbuild/runが駆動され、JSONL、リソース、source/ZIPハッシュが検証されます。mock、ローカルネイティブ、リアルAPI、Linux、サイトはそれぞれ報告されます。代替はできません。
新しい経験則は、適用条件、最小再現、証拠を添付し、実際に決定を変更したルールのみを保持します。