progress

対象：ユーザーが尋ねた既存のプロセス・ジョブと，それが残す痕跡（ログ・終了コード・チェックポイント・ダッシュボード等）．前セッションで /ops:exec が分離起動したジョブも対象——ハーネスの完了通知は届かないが，ログの ops-exit= から結末を復元できる．

手順

1. プロセスを特定する：対象の名前や文脈が分かれば下の「プロセス列挙の正典」で列挙し，分からなければ会話中の直近の実行や作業ディレクトリから推測する．/ops:exec が分離起動したジョブなら logs/<名前>.pid が手掛かりになる．見つからなければ「動いているプロセスが見当たらない」と正直に伝え，手順2で結末を確かめる．
2. 痕跡を探す：logs/（/ops:exec の出力先）をまず見て，無ければ他の典型的な出力先（runs/・output/・checkpoints/・wandb/ 等）や対象スクリプトより新しいファイルを探す．ライブ状況ページ（ダッシュボード HTML+JSON・TensorBoard・MLflow 等）が既にあれば，自前で指標を再構成せずそれを最優先で案内する——車輪の再発明をしない．
3. 結末か途中かを見極める：ログ末尾に ops-exit=<N> があればそのジョブは終了している——N が 0 なら正常終了，非 0 なら異常終了として，ログのエラー箇所と成果物の実在を突き合わせて報告する．ops-exit= が無くプロセスも見当たらないときは，強制終了（OOM・Kill・マシン再起動）か /ops:exec 以外の手段で起動されたかのいずれか——成果物の有無で見極める．ログの沈黙を「順調」と決めつけない．
4. 今の状態を要約する：走っているなら，経過時間・進捗（ステップ/エポック等が分かれば）・直近の指標・見込み終了時刻を簡潔に示す．
5. その場のログ取得手段が無いと分かったら一言添える：対象が /ops:exec 経由で起動されていない（標準エラーが未リダイレクト）場合，今は状況を伝えられても，この先クラッシュしたときのトレースバックは失われる可能性がある旨を伝え，次回は実行そのものを任せてもらえば防げると添える．
6. 深掘りが要る場合のみ調べを広げる：ログにエラーが無いのに異常終了した形跡があるときは，dmesg/journalctl（権限が要ることがある）・GPU メモリ状況・再現実行に進む——通常の状況確認では不要，聞かれた分だけ答える．

プロセス列挙の正典

• Windows：PowerShell の Get-CimInstance Win32_Process | Where-Object CommandLine -like '*<対象>*' | Select-Object ProcessId, CreationDate, CommandLine を使う．Git Bash の ps は使わない——MSYS が追跡するプロセスしか見えず，コマンドライン引数も落ちるため，どのスクリプトが走っているか判別できない．
• POSIX：ps -eo pid,etime,args | grep <対象>（経過時間と全引数が要る）．

自己点検

• 不在の報告：プロセスが見当たらないとき，無いことを正直に伝えたか——存在するかのように語っていないか．
• 列挙の手段：Windows で ps を使っていないか——引数が落ちて別のジョブと取り違える．
• 既存の活用：既存のライブ状況ページがあるのに，自前で指標を再構成していないか．
• 沈黙を成功と読まない：ログの沈黙を「順調」と決めつけず，ops-exit= と成果物で結末を裏取りしたか．

制約

調べるだけで手を出さない——プロセスの停止・再起動・設定変更はしない（必要と思えば提案し，承認を得てから /ops:exec に渡す）．ログ・成果物・ダッシュボードは読み込みのみ．

失敗時

/heal:skill を呼ぶ．