00-run-exercise

name	00-run-exercise
description	障害対応机上演習を開始・再開・進行するための人間向け唯一の入口。ステップ別skillとagentを調整し、中間ファイル、IPC、ポストモーテム生成を管理する必要があるときに使う。

障害対応机上演習ランナー

このskillは、演習を通常実行するための唯一の入口です。演習中、Coding Agentは人間へ直接質問・回答してはいけません。質問、回答、能動通知、ポストモーテムなど、人間に見せる内容は必ず ../../shared/references/ipc-protocol.md に従って会話用プロセスへ送ります。

言語

人間に見せる質問、回答、通知、ポストモーテムは必ず日本語で書きます。内部メモ、ファイル名、固定フォーマットの識別子は、形式の安定性を優先して英語を使ってもかまいません。

入力

• SCENARIO.tsv
• 事前生成再利用モードのとき: timelines/<scenario-id>/ 配下の事前生成データ（TIMELINE-1.tsv / QUESTIONS-1.tsv / ANSWERS-1.tsv）
• ./ops から作成された観測情報一覧TSV
• ./ref 配下の仕様・設計文書
• ./ops 配下の障害対応手順書・監視手順・Runbook
• 任意の指定シナリオID（操作者がシナリオを明示指定した場合）
• 任意の演習済みシナリオID一覧
• EVAL_CRITERIA.md
• docs/SPEC.md

出力

• .ai/runs/<run-id>/ 配下の中間ファイル
• 参加者に表示するIPCメッセージ
• .ai/runs/<run-id>/postmortem.md
• 公開ログと内部ログ

共通仕様

• 中間ファイルを書いたり検証したりする前に ../../shared/references/data-formats.md を読む。
• IPCを送受信する前に ../../shared/references/ipc-protocol.md を読む。
• 参加者への送信は ttx-ai-send、参加者入力の受信は ttx-ai-recv を使う。python・nc・直接の socket 実装で送受信してはいけない。socket は既定パスを 3 ツールで共有するため通常 --socket は不要。別パスにしたいときだけ全ツールへ同じ --socket（または環境変数 TTX_SOCKET）を指定する。

IPC 障害時の扱い（接続喪失＝中断）

対象は、最初の開示（ステップ9 06-disclose-first-event の ttx-ai-send）以降のライブ進行（質疑ループ＝ステップ10〜12 の ttx-ai-send／ttx-ai-recv を含む）。ここで終了コード2（IPC 障害）が返ったら、会話用プロセス（ttx-human または Slack ゲートウェイ）が終了し会話用 UDS が失われたとみなす。リトライしない。 接続喪失による中断として /abort 相当で即座に終了する: timeline_cursor.json を aborted にし、ポストモーテムを作らず、以後いっさい IPC 送受信を行わない（相手が存在しないため、中断通知も送らない）。切断を internal_log.jsonl に記録して演習プロセスを終了する。

例外1（起動前）: ステップ3(b) の起動確認ゲート、ステップ3.5 の設定質疑（ttx-ai-send --type question／ttx-ai-recv）、ステップ4冒頭の開始メッセージ送信は最初の開示より前であり、そこでの終了コード2 は「まだ ttx-human を起動していない／socket パス不一致」を意味する。ここでは中断ではなく、操作者へ再提示して起動を待つ（このセクションの対象外。ヘッドレスではゲートウェイがサーバを起動済みのため通常は成功する）。ただしステップ3.5 の設定質疑で ttx-ai-recv が**待機タイムアウト（終了コード5）**を返した場合は、参加者が規定時間応答しなかったということなので、最初の開示前ではあるが /abort 相当の中断として扱う（timeline_cursor.json を aborted にし、ポストモーテムは作らない。ヘッドレスではゲートウェイが終了文言を投稿するため中断通知は二重に送らない）。

例外2（終了処理）: 終了処理（ステップ13）の postmortem 送信が終了コード2 になった場合は別扱い。ポストモーテムは既に生成済みで状態も finished のため、カーソルを書き換えず・破棄せず、リトライもせず送信を諦めて終了する（中断＝aborted にはしない）。

ref / ops の参照

対応者からの質問に答えるために必要な場合、./ref 配下の仕様・設計文書と ./ops 配下の障害対応手順書・監視手順・Runbook を参照してよいです。ただし参照は「ある情報が観測可能・開示可能か」を判断する目的に限り、開示してよいのは現在または過去のタイムライン上で観測可能な事実だけです。次に確認すべき手順・監視項目・調査方法といった"手がかり"は、手順書や仕様に載っていても開示しません（対応者自身に調べさせる）。

ヘッドレスモード（Slack ゲートウェイ経由）

Slack ゲートウェイ（tools/ttx-slack）から codex exec で非対話起動された場合は、ヘッドレスモードで動きます。判定条件: 環境変数 TTX_SOCKET が設定済みで、起動プロンプトにヘッドレス実行の指示がある（会話用プロセスは既にゲートウェイが起動済み）。

ヘッドレスモードでは、物理画面前提の対話的セットアップだけを省略します。訓練モード選択とシナリオ選択（ステップ3.5）は省略せず、CLI と同じく IPC 経由で参加者へ尋ねます（Slack スレッドで @ttx への返信として行われる）。

• 省略する: ステップ1（install-ttx.sh。ゲートウェイ環境に導入済み前提）と、ステップ3（別窓起動・起動確認ゲート・画面隠しの理解確認・10秒カウントダウン）。これらは「操作者が画面を見ている」前提の手順で、Slack には該当しません（GM 側の物理画面が存在しない）。ステップ2の準備モードの内部決定とステップ3.5の設定質疑は省略しません。
• socket: 既にゲートウェイが TTX_SOCKET のパスで会話用プロセス相当（ttxserver）を起動済みです。ttx-ai-send / ttx-ai-recv はこの TTX_SOCKET を使います（--socket 明示は不要）。
• 設定質疑（ステップ3.5）: 訓練モード（全体／個別）とシナリオ選択を ttx-ai-send --type question で尋ね、ttx-ai-recv で回答を受け取ります（CLI と同一）。起動プロンプトでシナリオID（例 SCN-007）が指定されていればシナリオ選択質問は省略してそのIDを採用しますが、訓練モードの質問は必ず行います（明示指定ショートカット）。
• そのまま実行する: ステップ4以降（状況選定→理想タイムライン→想定質問→想定回答→開示レビュー→最初のイベント開示→ライブ質疑ループ→タイムライン進行→終了判定→ポストモーテム）を通常どおり進めます。終了時の ttx-ai-send --type postmortem がゲートウェイ側の終了検知トリガになります。ゲートウェイが先に落ちるなどで IPC が終了コード2（IPC 障害）になった場合は、「IPC 障害時の扱い」に従いリトライせず接続喪失中断で終了します。
• abort / 待機タイムアウトの扱い: /abort を受けた場合、または ttx-ai-recv が待機タイムアウト（exit5）を返した場合、ゲートウェイが参加者向けに終了メッセージを投稿するため（GM 終了 → codex 終了をゲートウェイが検知して投稿）、ヘッドレスでは中断通知を二重に送らず、ポストモーテムを作らずに終了します。なお会話用プロセスはゲートウェイが起動するため、待機タイムアウトの長さはゲートウェイの --recv-timeout（既定30分）に従います。
• reasoning effort: ゲートウェイが codex exec に -c model_reasoning_effort="low" を渡すため、ヘッドレスでは既定で低く設定済みです（ライブ進行のテンポ向け。GM 側で下げ直す必要はありません）。

以降の「実行手順」は対話モードの記述です。ヘッドレスモードでは上記のとおり省略・自動化して読み替えてください。

実行手順

1. 会話用プロセス用バイナリを用意する（Go 環境不要）: scripts/install-ttx.sh を実行する。これは ttx-human / ttx-ai-send / ttx-ai-recv が未導入または古い場合だけ、GitHub Release のビルド済みバイナリを取得して PATH 上のディレクトリへ配置する冪等なスクリプトで、gh が無ければ導入を試み、未認証なら gh auth login を案内する。実行後 command -v ttx-human ttx-ai-send ttx-ai-recv で PATH 解決を確認する。スクリプトが失敗したら、標準エラーに出る原因と対処（例: gh auth login、Release 公開待ち）を操作者へそのまま提示し、先へ進まない。socket は省略すると既定パスを使い、3 ツールが同じ既定 socket を共有する（別パスにしたいときだけ全ツールへ同じ --socket か TTX_SOCKET を指定）。別窓での起動はステップ3で指示する。
2. 準備モードを内部で決め、起動時のシナリオ指定があれば控える。 訓練モードとシナリオの選択は操作者へ Codex 端末で尋ねず、ステップ3.5 で会話用プロセス（IPC）経由で参加者へ尋ねる。ここで行うのは次の内部準備だけで、操作者へ選択肢は出さない。
   • 準備モード（アドホック生成／事前生成再利用）は GM 内部判断で自動決定する（参加者にも操作者にも尋ねない）。テンポを優先し、選ばれたシナリオに事前生成3点（TIMELINE-1.tsv / QUESTIONS-1.tsv / ANSWERS-1.tsv）が timelines/<SCN>/ に揃っていれば再利用、無ければアドホック生成にする（再利用は自由度が低いが高速、アドホックは自由度が高いが低速）。準備モードは選ばれたシナリオが定まって初めて確定するので、ここでは方針だけを決めておき、実際の判定はステップ3.5・ステップ4（01a）で行う。
   • 起動時にシナリオID（例 SCN-007）が明示指定されていれば控えておく（CLI では操作者が起動時に指定、Slack では初回メンションで指定）。指定があればステップ3.5 のシナリオ選択質問を省略してそのIDを採用する（明示指定ショートカット＝01a の selection_method=specified）。ただし訓練モードの質問は指定の有無にかかわらず必ずステップ3.5 で行う。
3. 別窓で会話用プロセスを起動してもらい、起動を確認してから画面隠しのカウントダウンに入る。 ここまではまだ隠し情報を一切出していないので、ステップ1〜2 と同じく操作者へ直接尋ねてよい（画面を見ていても安全）。
   • (a) 別窓起動の指示: 操作者へ「新しいターミナルの窓（またはタブ）を開き、ttx-human を実行して、演習が終わるまでそのまま起動したままにしてください」と案内する。提示するコマンドは PATH 配置済みの素のコマンド ttx-human（scripts/install-ttx.sh が PATH 外へ配置した場合のみ、スクリプトが示した起動コマンドを使う）。socket は省略してよい（既定パス共有）。会話用プロセスは接続が閉じても終了しないので、演習中は1つ起動したままでよい。
   • (b) 起動確認ゲート: 「別窓で ttx-human を起動しましたか？ (Y/N)」と尋ねる。Y を受け取るまで先へ進まない（N や不明瞭なら (a) を再提示）。Y を受け取ったら裏取りとして ttx-ai-recv --no-wait を1回実行し、終了コードで起動を確認する: 4（接続済み・入力なし）または 0（接続済み。演習前の誤入力が1件返るだけなので破棄してよい）なら起動済みとみなす。2（接続失敗）なら未起動か、ttx-human と GM 側ツールで socket パスが食い違っている。まず (a) を再提示して起動を確認する。起動済みなのに 2 が続く場合は、別窓の ttx-human の先頭に表示されている listening on <パス> の行のパスを操作者に読み上げてもらい、そのパスを ttx-ai-recv / ttx-ai-send の --socket（または環境変数 TTX_SOCKET）へ同じ値で指定して揃える。
   • (c) 画面隠しの理解確認とカウントダウン: 起動確認後、ここから先は隠し情報を扱うため、演習ファイル（SCENARIO.tsv・scenarios/・timelines/・./ref・./ops など）を読む前に、まず操作者へこれからやるべきことと、Y を押した後に起こることを予告したうえで確認する: 「これから演習を開始します。参加者から、ゲームマスター側（Claude Code / Cursor）の思考過程や内部情報が映る画面が見えないように隠す必要があります。準備ができたら Y を入力してください。Y を押すと 10秒のカウントダウンが始まり、その10秒の間に画面を隠していただきます（こちらからの完了確認はありません）。理解しましたか？ (Y/N)」。Y（理解した）を受け取るまで先へ進まない（N や不明瞭な応答なら同じ案内を再提示する）。Y を受け取ったら「10秒以内に画面を隠してください」と案内し、すぐフォアグラウンドで可視カウントダウンを実行する（例: for i in 10 9 8 7 6 5 4 3 2 1; do printf '残り %s 秒…\n' "$i"; sleep 1; done; printf '0 — 開始します\n'）。秒数は seq ではなく明示列挙にして移植性を確保する。このカウントダウンが完了するまで次へ進まない（フォアグラウンドでブロックするため、隠す10秒の間に隠し情報を読み始めないことが構造的に保証される）。なお Codex など一部の環境では数字が最後に一括表示されることがあるが、10秒の待機自体は成立するので問題ない。画面を隠せたか（完了）の確認は求めてはいけない（操作者が返信のため画面を見続けるのを避けるため、隠す動作自体は必ずタイマー方式にする）。これ以降は操作者（Codex 端末）へ選択肢や確認を提示しない。 判断が必要な場合はエージェントが最良と考える選択肢を自動で選び、選定理由は internal_log.jsonl にのみ記録する（操作者の入力を待たない）。操作者（Codex 端末）への選択・確認が必要なものはステップ1〜2と、この起動確認・理解確認で済ませてある。訓練モードとシナリオの選択は、この後ステップ3.5 で会話用プロセス（ttx-human／Slack）経由で参加者へ尋ねる（操作者端末ではなく IPC へ送るので画面隠し後でも矛盾しない。送るのは開示可能な情報だけ）。 3.5. 設定質疑フェーズ（IPC 経由）。 画面隠し後、最初の開示（ステップ9）より前に、訓練モードとシナリオを会話用プロセス経由で参加者へ尋ねる。各質問は ttx-ai-send --type question で送り、回答は ttx-ai-recv --wait で1件受け取る（回答は type:"input" で返るが、ここでは質問・行動ではなく設定回答として解釈する）。設定質疑は参加者の回答待ちなので --thinking は点けない（思考中表示は開始メッセージ＝ステップ4から点ける）。送ってよいのは開示可能な情報だけ（訓練モードの問い、01b の表示3列、参加者本人の所属部署名）で、シナリオ概要・受動対応部署名・未来イベントは送らない。
   • (a) 訓練モードを尋ねる: 「全体訓練（おひとりで全部門の対応を担います）と個別訓練（自部門だけを担当し、他部門は GM が代行します）のどちらにしますか？」と question で尋ね、回答を受ける。曖昧・無回答や、明示指定シナリオだけが与えられて訓練モードが読み取れない場合は**全体訓練（既定）**とみなす。全体訓練は training_mode=whole、個別訓練は training_mode=individual。
   • (b) 個別訓練なら自部門を尋ねる: 「あなたの所属部署を教えてください」と question で尋ね、回答を SCENARIO-LIST.tsv の部署表記へ正規化した1つを primary_department にする。全体訓練では自部門は尋ねない（primary_department は空）。
   • (c) シナリオを尋ねる（ステップ2 で起動時の明示指定を控えてある場合はこの (c) を省略し、そのIDを採用する）: 次の選び方を番号付きで question 提示し、「番号、またはシナリオID（例 SCN-007）で返信してください」と促す。
     1. 無作為におすすめ: 未演習から無作為に1つ選ぶ（01a の無作為選定。所属部署で絞らない。個別訓練では 01a が自部門の関与するシナリオに絞る）。
     2. 部署から無作為におすすめ: 部署キーワードで ../01b-list-scenarios/SKILL.md の候補を絞り、その候補からGMが無作為に1つ選ぶ（参加者には一覧を見せず、選ばれたIDを明示指定として扱う）。個別訓練では (b) の自部門を使い、全体訓練ではこの場で所属部署キーワードを尋ねる。
     3. 部署から一覧を確認: 部署キーワードで 01b 一覧を絞り、表示3列（シナリオID・初動対応部署・最初の開示可能イベント）を question で提示してからIDを尋ねる（2往復）。個別訓練では自部門、全体訓練では所属部署キーワードを尋ねる。
     4. 全体の一覧を確認: 01b で全件の表示3列を question で提示してからIDを尋ねる（2往復）。
     • シナリオIDを直接返してきた場合や、一覧から選んだ場合は明示指定（01a の selection_method=specified）として扱う。
   • (d) 決まった値（訓練モード・個別なら自部門・シナリオID または無作為指示）を控えてステップ4へ渡す。 実際の状況選定（01a の実行と situation.tsv 書き込み）はステップ4で行う。01a が situation.tsv に training_mode と primary_department を書き、06・07・10・12 はそれを読んでモードに応じて振る舞う（訓練モードは引数で逐次渡すのではなく situation.tsv を唯一の真実源とする）。準備モードはステップ2の方針に従い、選ばれたシナリオに事前生成3点が揃えば再利用、無ければアドホック生成にする（明示指定で事前生成が無い場合もアドホック生成を既定採用し internal_log.jsonl に記録する。画面隠し後は操作者へ確認できないため）。
   • エッジケース:
     • 所属部署キーワードに一致が0件のとき（個別訓練では初動対応部署にも受動対応部署にも一致しないとき）は、01b が全件一覧を出すので、別の所属部署キーワード・シナリオIDの明示指定・無作為選定のいずれにするかを question で参加者へ尋ね直す。
     • 返ってきたシナリオIDが SCENARIO.tsv に無い場合は 01a が検出するので、question で選び直しを促す（最初の開示前なので再質問してよい）。
     • 設定質疑中に /abort（type:"control"）が来たら中断する（timeline_cursor.json を aborted、ポストモーテムなし、ステップ13の中断分岐）。/giveup はまだ演習が始まっていないので /abort と同様に中断する（ポストモーテムは作れない）。/claim は設定中には対象が無いので、question で「いまは演習開始前の設定中です」と短く返して設定質疑を続ける。
4. 開始メッセージを送ってから状況ファイルを書く。 ステップ3.5 で訓練モードとシナリオが決まったので、最初の開示（ステップ9）までの準備（ステップ4〜8の理想タイムライン生成〜開示レビュー）に数分かかる旨を参加者へ伝え、思考中表示（応答待ちスピナー）を点ける開始メッセージを送る: ttx-ai-send --type notification --thinking --text '演習を開始します。最初のメッセージまで1〜2分ほどお待ちください。'。これは開示前のメッセージなので、ここで終了コード2（IPC 障害）が返っても中断（abort）ではなく「IPC 障害時の扱い」の例外1（起動前）と同じ扱いにする（対話モードでは未起動／socket 不一致として再提示し起動を待つ。ヘッドレスではゲートウェイがサーバを起動済みのため通常は成功する）。--thinking で点けた思考中表示は、ステップ9の最初のイベント開示（フラグなしの notification）の表示で自動的に解除されるので、明示的に消す送信は不要。その後 ../01a-select-scenario/SKILL.md にステップ3.5 で決めた訓練モード・自部門・シナリオID（または無作為指示）と準備モードを渡して状況を選び、最初の状況ファイルを書く（明示指定IDがあればそれを採用、無作為指示なら無作為選定。再利用モードでは事前生成3点が揃うシナリオに限定）。
5. .ai/agents/02-build-ideal-timeline.md を使って理想タイムライン（TIMELINE-1.tsv）を用意する。アドホック生成モードなら新規生成、再利用モードなら timelines/<primary_scenario_id>/TIMELINE-1.tsv を読み込む。
6. .ai/agents/03-build-expected-questions.md を使って、最新の現在タイムラインから想定質問集を作る（事前生成 QUESTIONS-1.tsv は参考資料）。
7. .ai/agents/04-build-expected-answers.md を使って、最新の現在タイムラインから想定回答集を作る（事前生成 ANSWERS-1.tsv は参考資料）。
8. .ai/agents/05-review-disclosure.md を使って、開示してはいけない情報が混ざっていないか確認する。
9. ../06-disclose-first-event/SKILL.md で最初の公開イベントをIPCへ送る。
10. ttx-ai-recv --wait で参加者の入力を1件受け取り、.ai/agents/07-handle-question-or-action.md で扱う。（この最初の受信で ttx-ai-recv が終了コード2＝IPC 障害を返した場合は「IPC 障害時の扱い」に従い、リトライせず接続喪失中断する。）入力が /giveup（type:"control"）なら、07 が .ai/runs/<run-id>/timeline_cursor.json を finished にし、ステップ13へ進む。入力が /abort（type:"control"）なら、07 が timeline_cursor.json を aborted にし、ポストモーテムを作らずステップ13へ進む。入力が /claim（type:"control"）なら 07 が前提への異議申し立てとして扱う（本文なしなら awaiting_claim を真にして争点を尋ね、次の入力を主張として扱う。本文ありなら主張を CLAIMS.tsv に暫定採用記録し、直前の行動を新しい前提で再評価する。タイムラインが変われば以降は通常どおりステップ11へ流れる）。ttx-ai-recv が**終了コード 5（待機タイムアウト）**を返したら、規定時間（既定30分）参加者入力が来なかったということなので、入力としては扱わず /abort と同様に timeline_cursor.json を aborted にし、ポストモーテムを作らずステップ13へ進む（ホスト側のツールタイムアウトで recv を再実行している場合も、サーバが総アイドル時間で打ち切るので exit5 はいずれ返る）。
11. タイムラインが変わった場合、.ai/agents/08-update-answer-set.md と .ai/agents/09-review-updated-disclosure.md を使って回答集を更新・再レビューする。
12. ../10-advance-timeline/SKILL.md と ../11-loop-or-finish/SKILL.md で次イベントへ進むか終了するかを決める。
13. 終了時の処理は timeline_cursor.json のカーソル状態で分岐する。
    • finished（タイムライン終端または /giveup）: .ai/agents/12-build-postmortem.md でポストモーテムを作り、ttx-ai-send --type postmortem で参加者へ送る。
    • aborted（/abort または ttx-ai-recv の待機タイムアウト=exit5）: ポストモーテムを作らない。 短い中断通知を ttx-ai-send --type notification で送り（送らないと会話用プロセスが応答待ち表示のまま残るため必ず送る。本文は /abort なら 演習を中断しました。ポストモーテムは作成しません。、待機タイムアウトなら 一定時間入力がなかったため演習を終了しました。ポストモーテムは作成しません。。ただしヘッドレスモードでは上記「ヘッドレスモード」節の指示が優先で、この中断通知は送らない＝ゲートウェイが終了文言を投稿するため二重送信しない）、IPC ではなく操作者へ直接、ライブループ用に下げた reasoning effort（low）を元に戻すリマインドを行う（12-build-postmortem.md のリマインドと同趣旨）。なお接続喪失（IPC 障害＝終了コード2）による中断は IPC 障害の時点で既に終了しており（「IPC 障害時の扱い」）、ここへは到達しない（相手が居ないため中断通知も送らない）。 どちらの場合も、その後は操作者が会話用プロセス（ttx-human）を終了してよい（stdin を閉じる、または Ctrl-C）。

中間ディレクトリ

演習ごとに .ai/runs/<run-id>/ を作り、すべてのステップ出力を保存します。

タイムラインは TIMELINE-<N>.tsv で版管理します。バージョン1（TIMELINE-1.tsv）が理想タイムラインで、初期の現在タイムラインを兼ねます。対応者の行動でタイムラインが理想から変化すると TIMELINE-2.tsv, TIMELINE-3.tsv … と版が増え、最新版が現在タイムラインです。TIMELINE-1.tsv は上書きしません。命名の詳細は ../../shared/references/data-formats.md を参照します。

事前生成再利用モードでは、正本 timelines/<scenario-id>/{TIMELINE-1,QUESTIONS-1,ANSWERS-1}.tsv を入力・参考として使います。timelines/ は不変、.ai/runs/<run-id>/ は1回の演習の作業ディレクトリです。

既存runで互換性のある名前が使われていない限り、次のファイル名を使います。

• situation.tsv
• TIMELINE-<N>.tsv（版1＝理想、最新＝現在タイムライン）
• QUESTIONS-1.tsv（想定質問集）
• ANSWERS-<N>.tsv（想定回答ドラフト）
• REVIEWED-ANSWERS-<N>.tsv（開示レビュー済み回答）
• DISCLOSURE-REVIEW-<N>.md（開示レビュー記録）
• timeline_cursor.json
• CLAIMS.tsv（/claim で暫定採用された主張の記録）
• public_log.jsonl
• internal_log.jsonl
• postmortem.md

応答速度の方針

演習はテンポが重要です。応答が遅いと体験を損なうため、次の方針で速度を確保します。モデルは下げません。

• ライブの質疑・行動ループ（ステップ7〜11）では、モデルは維持したまま reasoning effort を下げる。操作者はセッションの effort を low に設定する（例: /efforts で low を選ぶ）。
• 準備ステップ（2〜5）は演習開始前で品質を優先したいので、高めの effort のままでよい。effort を low に下げるのはライブループに入ってからでよい。
• 演習が終わったら effort を元に戻す。ライブループ用に low へ下げた effort は演習終了後の通常作業では不適切なため、ポストモーテム生成（ステップ13）の後に元の effort へ戻すことを忘れない（ステップ13 の 12-build-postmortem.md でも操作者へリマインドする）。
• 生成コストを抑えるため、準備モードは事前生成再利用モードを優先して自動決定する（ステップ2の方針。選ばれたシナリオに事前生成3点が揃えば再利用、無ければアドホック生成）。
• 回答は観測可能な事実を端的に返す。詳細は .ai/agents/07-handle-question-or-action.md の「応答方針（速度）」に従う。

開示ルール

• 状況、未来のタイムライン、内部ログ、想定質問、想定回答、レビュー記録は内部情報として扱う。
• IPCには参加者に見せてよい情報だけを送る。内部情報やデバッグ情報は会話用プロセスへ送らず、中間ファイルまたは内部ログに書く。
• 現在または過去のタイムラインから観測できない事実を聞かれた場合は、「現時点ではわかりません」と答える。
• 回答は観測可能な事実を端的に返し、過度に考え込まない。
• 演習中は、agentの思考過程、隠しシナリオID、隠れた原因、未来イベント、レビュー記録を明かさない。
• GM の回答・能動通知の作り方は .ai/agents/07-handle-question-or-action.md「質問・行動への応答方針」に従う（判断フロー＋述べる/述べない）。要点: 推測・結論・状況の要約・聞かれていない上乗せ・関連性/優先度の枠付け・観測可能性/検証可能性の提示（「確認できます」「観測できます」「参照できます」等）・確認先の案内・設計説明はしない。尋ねられた観測値はシナリオ整合なら生成して述べてよい。確認先を明示しない曖昧な観測質問は聞き返す。
• 個別訓練では、自部門以外の部門は GM が NPC として演じる。NPC の内部判断・思考過程、シナリオの受動対応部署の一覧、未来イベントは開示しない。NPC が自部門へ送る対応要請・連携も、観測可能な事実だけを述べ、「〜が必要」等の示唆表現を含めない（次にやることは対応者自身に考えさせる）。

個別デバッグ

1つのステップだけをデバッグする場合は、対応するskillまたはagentを、前段の出力ファイルを固定入力として再実行します。ユーザーが明示的に求めない限り、前段ファイルを作り直してはいけません。