exec

対象：ユーザーが実行を求めたプログラム・スクリプトのうち，数十秒を超えて走るもの——学習・評価・データ処理・サーバ等，起動したまま会話を続けたり離席したりし得る実行．

このうち常駐するもの（サーバ・デーモン・監視プロセス）には「完了」が無い——手順4・5（完了照合・完了通知）は適用せず，起動を確認したら Monitor が異常だけを見張り続ける（ops-exit= が出たなら，それは正常終了ではなく落ちた合図である）．

対象外：数十秒で終わる実行——テスト・ビルド・lint・ワンライナー・git 操作など，結果をその場で見て次の一手を決めるもの．通常のフォアグラウンド実行で足りる（/refine:code ・ /assignment:program ・ /groundwork:impl 等が行う実行確認はここに属し，本スキルを挟まない）．所要時間が読めなければまず短命として実行し，数十秒で返らなければ中断して本スキルで起動し直す．

手順

1. 寿命を決めて起動する．どちらの形でもログ・終了コードの刻印は下の「実行の正典」に従う．

   • セッション内：1時間以内に終わると見込めるもの．Bash を run_in_background: true で起動する——ハーネスが完了時に通知する．セッションを閉じるとジョブも終わる．

   • 分離：1時間を超えうるもの，またはユーザーの離席・セッション終了が見込まれるもの．親シェルから切り離し，セッションが閉じてもジョブを残す——切り離せているかは，別の Bash 呼び出し（＝新しいシェル）からプロセスがまだ見えることで確かめる：

     mkdir -p logs; nohup sh -c '<コマンド> > logs/<名前>.log 2>&1; echo "ops-exit=$?" >> logs/<名前>.log' > /dev/null 2>&1 & echo $! > logs/<名前>.pid
     

     区切りは ; であって && ではない——&& で繋ぐと & がその AND リスト全体をバックグラウンドに送り，echo $! が mkdir より先に走って logs/ 不在で落ちる（かつ $! がジョブでなくサブシェルを指す）．

     この形はハーネスの完了通知を持たない——完了は手順2の Monitor が ops-exit= で拾い，セッションが閉じた後は /ops:progress がログから復元する．迷ったら分離を選ぶ（ジョブを失わない側に倒す）．

2. Monitor を張る：persistent: true を必ず指定する——既定5分・上限1時間のタイムアウトでは長時間ジョブの後半を見失う．tail は -n +1 -F でログの冒頭から読む——起動直後の即死（import エラー・パス誤り・権限）が Monitor を張る前に済んでいても取りこぼさない．したがって起動後に待って生存確認する手順は要らない（フォアグラウンドの sleep はハーネスで禁じられており，そもそも打てない）．

   tail -n +1 -F logs/<名前>.log | grep -E --line-buffered "<進捗マイルストーン>|ops-exit=|Traceback|Error|Exception|Killed|OOM|Segmentation fault|Fatal"
   

   • 失敗を必ず捕らえる：「今このジョブがクラッシュしたらこの grep は何か出すか」を問う——出ないなら広げる．ops-exit= は常に含める：これがあれば，正常終了も異常終了もハングも，沈黙のまま見過ごされることがない．
   • 進捗は間引く：毎ステップ出る行を入れてはならない．Monitor はイベントが溢れると自動停止され，肝心の失敗を取り逃す．エポック完了・評価結果など，数分に1回程度に落ちるマイルストーンだけを選ぶ．

3. 状況把握手段を案内する：対象がライブダッシュボード・TensorBoard・進捗 URL 等を自分で提供していないか探す（生成される HTML/JSON，ログ冒頭の URL）．見つかればその URL を，無ければログの場所と所要時間の見積もり（過去の同種実行や進捗の速度から分かるとき）を一言で伝える．確認は求めず，伝えるだけでよい．

4. 終了したらログ全文と成果物を照合する：ops-exit= の値（またはハーネスの完了通知）を鵜呑みにせず，ログを実際に読んで裏取りする．完了時に生成されるはずの成果物（チェックポイント・出力ファイル等，特定できるとき）が実在するかも確かめる——ログにエラーが無いことは成果物の存在を保証しない．

5. 離席が見込まれたジョブは，成功・失敗を問わず完了時に1回 PushNotification を送る（status: "proactive"，200字以内）：離れている間に終わったことこそ知らせるべき情報である．失敗ならどこで何が起きたかの要点を，成功なら主要な結果（accuracy 等）を一言で．ユーザーが今まさに会話中で見ているものには送らない．

6. Monitor を止める：プロセス終了を確認したら TaskStop で閉じる．

実行の正典

• シェル：起動も監視も Bash ツール（Windows では Git Bash）で行う——POSIX のコマンドが両プラットフォームで通る．
• ログ：logs/<名前>.log にリダイレクトだけで書き出す（> logs/<名前>.log 2>&1）．| tee 等の中継パイプは付けない——パイプラインの終了コードは最後のコマンドのものになり，本体の異常終了が 0 にマスクされる．logs/ が git 管理下に入るなら .gitignore への追加を促す（実行の痕跡であって成果物ではない）．
• 終了コードの刻印：本体の直後に echo "ops-exit=$?" >> logs/<名前>.log を必ず続ける——これがログだけから完了・失敗を判定できる唯一の痕跡であり，Monitor の完了シグナルであり，セッションが尽きた後に /ops:progress が拾う手掛かりになる．
• 起動はこちらが打つ：ユーザーがターミナルで直接起動したプロセスの標準エラーは，そのセッションと共に失われ後から追跡できない．

自己点検

• 対象判定：数十秒で終わる実行に本スキルを被せていないか．
• 寿命判定：離席が見込まれるのにセッション内モードで起動していないか．
• Monitor の広さ：失敗シグネチャと ops-exit= を含み，クラッシュ時に必ず何か出るか．
• Monitor の細かさ：進捗行が細かすぎてイベントが溢れないか．
• 沈黙を成功と読まない：完了は ops-exit= と成果物の実在で裏取りしたか．

制約

• 会話は止めない：起動・監視・案内（手順1〜3）を終えたら完了を待たず，指示も待たずに通常の会話を続ける——手順4以降はジョブが終わった時点で働く．状況確認が来たら /ops:progress の手順で答える．
• 不可逆・有償・占有は起動前に承認を得る：データの削除・上書き，本番環境への反映，課金の発生する実行（API の大量呼び出し・クラウド計算資源），GPU 等の長時間占有を伴うなら，何が起きるかを告げて承認を得てから起動する——バックグラウンドで走り出したものは取り消しが利きにくい．
• 実行内容そのもの（コマンド・引数・設定）は勝手に変えない．変える必要があれば問う．

失敗時

/heal:skill を呼ぶ．