exp-probe

Exp Probe：必要なら一度だけ質問 → 実行 → 記録 → 1行で報告

プローブは、1つの質問に低コストで答えるためにあります。正直さ以外は、すべて最小限にします。

• まず、質問を1つに絞ります（「設定Xはメモリに収まるか」「このNaNは再現するか」「不足しているアンカー値は何か」など）。質問を言葉にできないなら、これはプローブではありません。
• 意味を歪めずに縮小します。 サンプル数やステップ数は減らしても、測定対象の意味（シーケンス長、バッチの意味、dtype）は変えません。報告時には、何をどのように縮小したかを正確に明記します。
• 実際のエントリーポイントを再現します。 プローブは、書き換えた即席の経路ではなく、実行時と同じランチャー／フラグ（例：事前チェックモード）を通して実行します。実際の経路を迂回するプローブでは、その経路について何も証明できません。プローブのコードは、プロジェクトのスクラッチ／実験領域にプローブごとに分離して置き、すべての研究コードと同じルール、つまり防御的プログラミングをしないことに従います。コードは最小限にし、実際のエラーはそのまま終了させます。環境の障害（デバイスの競合、ディスク容量不足など）は環境の問題として診断し、回避するためのパッチは当てません。
• 低コストでも事前チェックを行います。 実行時と同じ手順で一度だけ確認します。環境が有効であること、そしてプラットフォーム独自のツール（nvidia-smi、npu-smi、mthreads-smi、…）で稼働中のデバイスを確認し、空いているデバイスを選んで、プラットフォームの可視デバイス用変数を通じて明示的に指定すること（デフォルトは使いません）。誰かが使っているデバイスをプローブが使えば、その人の実行もあなたの実行も無駄になります。
• プローブは低コストであることが前提なので、実行完了までその場で待つのが通常です。プローブの実行に時間がかかる場合（フルサイズモデルの健全性チェック、遅いデータセットなど）は、ターンを保留せず、exp-batch と同じ委譲パターン、つまりバックグラウンドで起動して later で再開します。
• ユーザーへの質問は最大1つまでで、質問自体が曖昧な場合に限ります。計画書や、何度も質問を重ねること、サブエージェントは不要です。
• キャンペーンから見つけられる場所に記録します。 プロジェクトのルールに従ったスクラッチ領域に、設定、観測結果、終了ステータスを記録します。プローブの回答によってキャンペーンのセルを除外できる場合、その主張と根拠をキャンペーンの除外記録に残し、影響するセルを明記します。
• 1行で報告します。 質問、観測した回答、コスト、そして何が可能になったか、または何を除外できたかを記します。回答が「不明／結論不能」の場合はそう伝え、次に行う最小のプローブを提案します。黙ってバッチへ格上げしてはいけません。