org-escalation: 判断仰ぎ・スコープ拡張・ブロッカーのエスカレーション

ワーカーから「承認を仰ぎます」「判断仰ぎます」「続行可否を確認」「スコープ拡張」「提案」「想定外」「runbook 逸脱」「ブロック」「ブロッカー」「block」等を含む peer message を受け取ったとき、窓口は 一次承認せず 人間にエスカレーションする。窓口は伝言役であり判断レイヤーではない。

輸送層（transport）両系 — 既定 broker / opt-in renga: 本ファイル（および各スキル）の peer message・pane 操作は mcp__org-broker__* で書いてあり、ORG_TRANSPORT 無設定＝既定 broker ではそのまま従えばよい。ORG_TRANSPORT=renga（opt-in、切戻し可）では MCP サーバー名が renga-peers になり、完全修飾名が mcp__org-broker__* → mcp__renga-peers__* に機械置換される（引数形・セマンティクスは同一なので操作の論理は変わらない）。輸送依存で手順が変わる差は次の 3 点:

• 受信モデル（既定 = push 一次 = claude/channel / pull フォールバック）: 既定 broker は push 一次に設計されている（runtime push-first 0.1.24+、設計 SoT は transport-lab docs/design/broker-native-roles.md §9）: 各ペイン同居の channel sidecar（server:org-broker-channel）が broker キューを ~1 秒間隔で claim→push し、notifications/claude/channel で本文を idle セッションへ注入する（「受けたら即応答」契機が生まれる）。ワーカー ack（to_id="worker-{task_id}"）・retro gate ack（to_id="dispatcher"）・ディスパッチャー handover 経路の send_message / check_messages / send_keys / inspect_pane は同じツール名（mcp__org-broker__*）で動く。pull はフォールバック層: sidecar 不在 / unhealthy（heartbeat timeout で delivery_mode=PULL）/ channel 非対応ペイン（codex pull-peer）/ claude.ai login 不在時は、各役割が自身の cadence で能動的に check_messages する（役割別 cadence: worker=ターン境界 / 完了後 bounded /loop・dispatcher=/loop 3m・secretary=ターン冒頭。「ナッジを見たら check_messages」prose は撤回せずこの fallback cadence として読む）。ORG_TRANSPORT=renga（opt-in）では、ワーカー報告・ディスパッチャー応答が <channel source="renga-peers" …> として in-band で push される（renga の in-band push と broker push 一次は同じ即応契機）。契約面は Surface 8 + push-primary amendment で push 一次が ratified 済み（2026-06-15、S3。pull は fallback として retain・renga 不変）。
• spawn 儀式（既定 = folder-trust 承認 + dev-channel sidecar 承認の 2 段）: 子ペイン起動時、既定 broker は --mcp-config <broker> を注入し Claude Code の folder-trust プロンプトを画面判定で機械承認するのに加えて、push 一次のため channel sidecar を --dangerously-load-development-channels server:org-broker-channel で load し dev-channel 承認プロンプト（spawn-flow 3-3b）を画面判定で機械承認する（folder-trust + dev-channel の 2 段承認。詳細は .dispatcher/references/spawn-flow.md 3-2 / 3-3b、設計は broker-native-roles.md §9.5）。ORG_TRANSPORT=renga（opt-in）では --dangerously-load-development-channels server:renga-peers を注入し「Load development channel?」を画面判定で承認する 1 段。注: attention watcher は transport 非依存の CLI ペインであり、folder-trust / dev-channel いずれの 2 段承認の対象外（spawn 儀式の反転に巻き込まない）。 画面判定 = inspect_pane → claude-org-runtime dispatcher spawn-prompt-step が返した 1 手だけを send_keys する反復（runtime 0.1.43+）。盲目 Enter は禁止（folder-trust の初期カーソルは「No, exit」で、Enter 一発はワーカーを終了させる）。手順は spawn-flow 3-3b。
• エラー分岐（既定 = broker 拡張コード込み）: 既定 broker は shared codes（pane_not_found / last_pane / invalid-params、Surface 6）に加え broker 固有 [token_invalid] / [session_invalid] / [tool_not_authorized] / [no_backend]（= adapter_unavailable）/ [nudge_failed] / [peer_not_found] / [name_taken] / [unknown_tool] を返しうる（未知コードは default-branch で escalate）。ORG_TRANSPORT=renga 時は broker 固有コードは発生せず shared codes + renga 固有コードのみ。

契約面の正本は docs/contracts/backend-interface-contract.md Surface 8（broker auth & delivery、ratified 2026-06-14）+ 末尾「Ratified amendment (2026-06-15): push-primary delivery」（S3。broker push 一次が既定の契約、pull は structural fallback として retain）、設計 SoT は transport-lab docs/design/broker-native-roles.md §9（push 一次）/ docs/design/ja-migration-plan.md §5・§8。opt-in renga は削除せず常時有効な fallback として維持する（切戻しの安全装置）。broker 実走（dogfood）は Epic #6 Issue G スコープであり、本ファイルの既定運用経路ではない（既定の二フレーム注記（Refs #604）: ここでの「既定 broker」はコード既定フレーム — tools/transport.py: DEFAULT_TRANSPORT が runtime 0.1.28 (Epic #586) で broker にフリップ済みで、ja 生成器・transport.resolve() はこのコードフレームで render するため生成面はこう表示する。別に運用既定フレームがあり、broker 実走 dogfood が Epic #6 Issue G まで未活性のため運用上の既定経路は renga。両フレームは指す対象（コード定数 vs 運用経路）が異なり矛盾しない。総説は root CLAUDE.md「輸送層（transport）両系」節。）

状態保存の必要性: 窓口再起動・引き継ぎで pending 判断を失わないため、 Progress Log / events / pending-decisions register の 3 層に同時記録する。 どれが欠落してもディスパッチャーの SECRETARY_RELAY_GAP_SUSPECTED 検出 (../../../.dispatcher/references/worker-monitoring.md Step 5.1) が誤発火 / 見逃しになる。

正準フロー

1. 最初に worker へ ack を返す（状態保存・user 伝達より前に発行する）。文面は .claude/skills/org-delegate/references/ack-template.md §「判断仰ぎ ack」を一次参照する（本 SKILL は重複コピーを置かない）。

   • Secretary は一次承認しない。worker への返答も「受領しました、人間に確認します」のみ
   • 「ユーザーは選択肢 X を選んだから自動的に含意される」「一気通貫の意図に含まれる」等の自己解釈で承認してはならない（この禁止の正本は本スキル。root CLAUDE.md「ワーカーからの判断仰ぎは人間にエスカレーションする」節は要約）
   • ack ≠ user 承認: ack は worker dead-lock 解除のための受領確認であり、push/PR 権限を生まない

2. 状態を保存する（3 層同時、欠落禁止）:

   • .state/workers/worker-{task_id}.md の Progress Log に「判断仰ぎ受信」内容と要点を追記
   • DB の events テーブルに追記:

     bash tools/journal_append.sh worker_escalation worker=worker-{task_id} task={task_id} reason="<要約>"
     

   • pending-decisions register に追加 (Issue #297):

     python3 tools/pending_decisions.py append --task-id {task_id} --message "<本文要約>"   # Mac/Linux
     py -3 tools/pending_decisions.py append --task-id {task_id} --message "<本文要約>"     # Windows native
     

     同 task_id の pending entry が既存なら idempotent (no-op)。register はディスパッチャーの SECRETARY_RELAY_GAP_SUSPECTED 検出 (../../../.dispatcher/references/worker-monitoring.md Step 5.1) の primary lookup source

3. 人間に伝達する: 内容と選択肢を整理して提示する。選択肢を提示した時点（ask の瞬間） で、register を escalated に更新する直前/同時に attention watcher へ awaiting_user を即時 emit する（Issue #28、ask-time ゲート）:

   bash tools/journal_append.sh notify_sent kind=awaiting_user task_id={task_id} gate=escalation_to_user note="<選択肢提示の短い要約>"
   python3 tools/pending_decisions.py resolve --task-id {task_id} --kind to_user   # Mac/Linux
   py -3 tools/pending_decisions.py resolve --task-id {task_id} --kind to_user     # Windows native
   

   classifier が secretary_awaiting_user (default severity urgent) として拾い、判断を仰がれた瞬間に即ビープする。interactive ではユーザーが数十秒〜数分で返答するため pending_decision aging (15分) は実質発火せず、この ask-time emit が urgent 通知の主経路となる。Step 4.5 (escalation_reply_forward, 転送時) の emit はそのまま別タイミングとして残す（Step 3=ask 時 / 4.5=転送時）。本 emit は journal 1 行追記のみで register / pending_decisions の状態は触らない。

4. ユーザーから返答を受領した時点 — ワーカーへ転送する 前に user_replied_at marker を register に記録する (Issue #301):

   python3 tools/pending_decisions.py mark-user-replied --task-id {task_id}   # Mac/Linux
   py -3 tools/pending_decisions.py mark-user-replied --task-id {task_id}     # Windows native
   

   escalated entry が無ければ no-op、既に設定済みでも idempotent。これにより ../../../.dispatcher/references/worker-monitoring.md Step 5.1 (a-2) で「ユーザー返答済みなのに Secretary が転送忘れ」を deterministic に検知できる

4.5. awaiting_user 通知の emit（Issue #28）: mark-user-replied → resolve --kind to_worker の境界で、attention watcher に「ユーザー返答が secretary 側に着き、worker へ転送する間の secretary 側 user-driven 動作」を知らせる 1 行を emit する:

bash tools/journal_append.sh notify_sent kind=awaiting_user task_id={task_id} gate=escalation_reply_forward note="<decision の短い要約>"

claude-org-runtime の attention classifier が secretary_awaiting_user (default severity urgent) として拾う。CLAUDE.md「secretary が user の判断を待っている状態を通知する」節を参照。本 emit は escalated entry の有無に依らず副作用を残さない（journal 1 行追記のみ、register / pending_decisions は触らない）

5. ワーカーに人間判断を転送する (to_id="worker-{task_id}" で send_message)。伝達直後に register を resolved に更新:

   python3 tools/pending_decisions.py resolve --task-id {task_id} --kind to_worker   # Mac/Linux
   py -3 tools/pending_decisions.py resolve --task-id {task_id} --kind to_worker     # Windows native
   

register 更新が失敗したとき（Issue #1155）

Step 2〜5 の register 操作（append / resolve --kind to_user / mark-user-replied / resolve --kind to_worker）は、終了コードではなく出力された状態で成否を判断する。CLI は no_pending / no_escalated でも exit 0 を返すため。期待する出力は次のとおり:

操作	期待する出力
append	"status": "pending" の entry
resolve --kind to_user	"status": "escalated" の entry
mark-user-replied	user_replied_at が入った entry
resolve --kind to_worker	"status": "resolved" の entry

期待どおりでなかった（エラー終了・no_pending / no_escalated・出力なし）ときは、次の順で扱う:

0. append の失敗は 1・2 の確認を使わず、待機なしで append だけを 1 回再試行する。同じ task に pending entry が既にあれば append はそれを返すだけで二重登録しないので、再試行しても安全。出力された entry の received_at を以後の識別に使い、再試行も失敗したら 3 に進む。以下の 1・2 は append 以外の操作に当てる
1. python3 tools/pending_decisions.py stale --min-age-min 0（Windows native は py -3。未 resolved の entry を全件出す読み取り専用コマンド）で、対象の entry（task_id と、append が出力した received_at の組で特定する）の現在の状態を見る。task 単位の latest-resolution は使わない（同じ task に未 resolved の判断が複数あると、操作が触った entry とは別の entry を見てしまう）。対象 entry が既に期待する状態（resolve --kind to_worker なら一覧から消えていること）なら成功として扱い、そのまま進む。stale が {"status": "unreadable", ...}（exit 2）を返したときは一覧に無いことを成功とみなさず、再試行もせず 3 に進む
2. 期待する状態でなければ、失敗したその register 操作だけを待機なしで 1 回だけ再試行し、1 と同じ方法で対象 entry が期待する状態になったか確かめる。同じ task に対象より古い未 resolved の entry があるとき（resolve / mark-user-replied は最も古い entry を進めるので、再試行が別の判断を進めてしまう）は、再試行せず 3 に進む。フロー全体（ワーカーへの転送・人間への伝達）はやり直さない。転送済みの人間判断を二重に送ることになるため
3. 再試行も失敗したら、task_id・失敗した操作・ワーカー / 人間への転送が済んでいるか・エラー内容を人間に報告する。報告後は他の案件の処理を止めずに続ける。残った不整合は次回 /org-start の滞留一覧（.claude/skills/org-start/SKILL.md Block B 手順 3）にも「要確認」として出る

重複保険ポリシー

• Progress Log / journal events / pending-decisions register の 3 層は 重複保険として独立に維持する（欠落時の影響は冒頭の「状態保存の必要性」）
• ブロッカー報告も本スキルで扱う（.claude/skills/org-delegate/SKILL.md Step 5 の「0. 判断仰ぎ・スコープ拡張・ブロッカー」は本スキルへのポインタ）

発動条件外（本スキルで扱わないもの）

• 進捗報告（Progress Log 追記 + ack のみ。ユーザー報告・承認待ちは行わない） → .claude/skills/org-delegate/SKILL.md Step 5 (1)
• 完了報告（REVIEW 遷移 + ユーザー報告 + 承認待ち） → .claude/skills/org-delegate/SKILL.md Step 5 (2a)
• ユーザー承認後の push / PR 作成 / レビューループ / マージ後クローズ → .claude/skills/org-pull-request/SKILL.md
• ワーカー監視と介入判定（深掘り検出・Esc 中断・tight 修正指示）→ .claude/skills/org-delegate/SKILL.md 「ワーカー監視と介入判定」