training-check

トレーニングチェック

各レビュー担当者の枠の前に、選択可能なレビュー担当者に従ってください： 呼び出しを解決 → .aris/reviewer.json → Codex をデフォルトにする（新しいネイティブレビュー担当者） 標準のヘルパーリゾルバー経由で reviewer_route.py を使用し、この 枠のティア、新しいコンテキスト、ソース／画像入力、決定論的なゲートを維持します。 以下の Codex の例／ピン留め設定は backend=codex にのみ適用されます。他のルートでは、それぞれの初回呼び出し／応答の契約が適用されます。ルートと実際に返された ID を保存してください。 選択したものが利用できない場合は REVIEW_UNAVAILABLE とします。実際のファミリー／完了状況／スコープから受け入れ可否を分類します。 呼び出し時のレビュー担当者／モデル／推論精度のオーバーライドは、レビュー担当者を含む子プロセスに引き継いでください。生成ワーカーは変更しません。

現在、インタラクティブ監視／交互式トレーニング監視モードです。

現在のセッションを開いたままにし、現在のターミナルに直接報告してください。ユーザーはこのターミナルで更新を確認しています。デフォルトでは、30 分ごとにトレーニングの健全性を確認し、各チェックの後に簡潔でありながら完全な分析レポートを出力し、次回のチェック時刻を示してから、監視を続けてください。

このスキルが確認するのは、基本的なプロセスの健全性ではなく、トレーニングの品質です。tmux セッションが存在するか、GPU がアイドル状態かといったプロセスの健全性チェックは、ウォッチドッグ形式のツールで処理できます。このスキルでは、実行を続ける価値があるかどうかに重点を置きます。

最初に確認する入力情報

最初のチェックの前に、監視に必要な最低限の情報を特定するか、ユーザーに確認してください：

• 利用できる場合は、WandB の実行パスまたは URL。
• 代替ログのパス、SSH コマンド、または最近のトレーニングログを読み取るローカルコマンド。
• トレーニングの目標、想定ベースライン、成功を判断する主要なメトリクス。
• 必要に応じて停止できるよう、トレーニングの起動方法。
• 判断と根拠を記録するプロジェクトメモのパス。

情報源が利用できない場合は、そのことを明確に伝え、利用できる情報源で続行してください。WandB と代替ログの両方にアクセスできない場合は、接続の問題を報告し、このラウンドを WAIT と分類して、後で再確認してください。データにアクセスできないという理由だけで、トレーニングに問題があると推測してはいけません。

ラウンドごとのチェック

各ラウンドでは、設定されている場合、最初に WandB を読み取ってください。WandB にアクセスできない場合は、代替ログを読み取ってください。少なくとも以下を確認してください：

• 直近のチェックポイントまたはステップにおけるトレーニング損失の傾向。
• 評価メトリクスと、ベースラインに対して改善、横ばい、または悪化しているかどうか。
• 損失、勾配、活性化、または記録されたメトリクスにおける NaN または Inf。
• 突発的な損失の急増、発散、または繰り返し失敗する評価。
• 学習率スケジュールの挙動。
• 記録されている場合は、勾配ノルム。
• 実行がもはや有用でないことを示唆する停滞パターン。

現在のターミナルに、次の構成でレポートを 1 つ出力してください：

## Training Check - <local timestamp>

- Data source: wandb_ok | log_fallback | unreachable
- Run: <wandb run or training identifier>
- Recent metrics: <loss/eval/lr/grad summary>
- Anomalies: <NaN/Inf/spike/divergence/plateau findings>
- Evidence: <WandB URL, log lines, metric values, or files inspected>
- Decision: CONTINUE | WAIT | STOP
- Reason: <why this decision is justified>
- Next check: <local timestamp, normally 30 minutes later unless ending>

判断は次のように使用してください：

判断	意味	対応
CONTINUE	実行はトレーニングを続けるのに十分健全に見えます。	監視を続け、30 分後に再確認します。
WAIT	根拠が不確か、ノイズが多い、時期尚早、または一時的にアクセスできません。	トレーニングを停止せず、監視を続けて後で再確認します。
STOP	トレーニングに明らかな問題があるか、続ける価値がなくなっています。	トレーニングタスクを停止し、根拠を保存してメモを記録し、最終サマリーを出力して監視を終了します。

停止動作

判断が STOP の場合：

• トレーニングタスクを停止します。
• コンテキストに stop_command が含まれている場合は、最初に stop_command を実行します。
• stop_command を利用できない場合は、トレーニングの起動方法に応じて、該当する tmux セッション、ローカルプロセス、リモートプロセス、スケジューラージョブ、またはノートブックジョブを停止するなど、適切な停止操作を選択します。
• 証拠を保存します。WandB の URL、主要なメトリクス、関連するログの抜粋、確認したファイル、停止理由を記録します。
• デバッグと今後の分析のために、プロジェクトノートを追記します。
• ターミナルに FINAL_SUMMARY を出力します。
• 対話形式の監視ループを終了します。

通常のメトリクスの揺らぎが最初に見られただけで停止してはいけません。継続的な傾向、重大な障害、または明らかな乖離がないか確認してください。後から別のエージェントや人間が実行を停止した理由を理解できるよう、十分な証拠を必ず残してください。

対話ループのガイダンス

• 通常の確認間隔は30分です。
• あるラウンドの判断が CONTINUE の場合は、次回の確認時刻を伝え、その時刻まで待機します。
• あるラウンドの判断が WAIT の場合は、不足している、またはノイズの多い証拠を説明し、後で再確認します。実行に懸念があるものの、まだ停止するほどではない場合に限り、短い間隔を使用します。
• 異常から回復した場合は、そのことを明示して監視を続けます。
• ユーザー向けの報告はターミナルで読みやすい長さに保ちつつ、具体的なメトリクス値と証拠のパスを含めます。