claude-org-ja: Skill for Claude Code

dispatcher-resume: ディスパッチャーの復帰

/dispatcher-handover で書き出した .state/dispatcher-handover.md を読み込み、 ディスパッチャーとして最低限の自覚（組織員としての立ち位置・進行中の派遣・監視 対象ワーカー）を復元し、/loop 3m の worker monitoring を再開する。

前提:

• ワーカー / 窓口のペインは前 session から生きたまま残っている。 新たに spawn しない（/org-start ではない）。キュレーターは常駐しない（起動中の curator が居れば Step 5 で追跡を引き継ぐ）。
• 自ペイン（name=dispatcher）も生きている。secretary が send_keys で /clear → /dispatcher-resume を打鍵した直後の状態。pane_id / peer_id は 変わっていないはずだが、必ず観測し、観測で確定できた値だけを state.db に atomic 更新する（確定できなかった値は書かず既存値を保持する。Step 0 / Step 2）。
• state DB (.state/state.db) はそのまま使う。
• 監視 gap を埋める内部状態ファイル（.state/dispatcher-event-cursor.txt（backend session に束縛された poll_events cursor） / .state/dispatcher/worker-idle-state.json / .state/dispatcher/curate-inflight.json（存在時） / .state/pending_decisions.json）は 前 session から残っている。新規作成・初期化・削除しない（既存値からそのまま継続。 消すと前 session からの監視連続性が壊れる）。
• handover ファイルが存在しないか古すぎる場合は、/org-start を案内して停止する。
• /clear は /loop の予約を消さない。前 session の監視ループの予約は /clear の後も 残っており、同じ指示文で /loop をもう一度打つと予約が 2 本になる。監視ループを張る前に 必ず CronList で確かめる（Step 5。経緯は .claude/skills/dispatcher-resume/references/rationale.md §4）。

自動引き継ぎ（auto op=<OP> 付きで呼ばれたとき）

context-handover watcher（tools/context_handover_watch.py）が /dispatcher-handover auto op=<OP> → /clear → /dispatcher-resume auto op=<OP> を打鍵する。 手順は通常の resume と同じで、違いは次の 3 つだけ:

• 完了の event（末尾「イベント記録」）に op=<OP> を付ける。watcher はこの行で復帰の完了を判定する。 Step 0 の前の already_consumed に落ちた場合（watcher の再送など）も、(i) と unknown の 分岐の終わりに同じ形の行を note=already_consumed で 1 行書く。初期化はやり直さない。
• Step 6 の後に、/clear の前後に届いて会話から消えた入力を処理する（Step 6.5）。
• 窓口への DISPATCHER_RESUMED / DISPATCHER_RESUMED_IDLE は通常どおり送る。

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

• 受信モデル: 既定 broker は push 一次（各ペイン同居の channel sidecar server:org-broker-channel が broker キューを ~1 秒間隔で claim→notifications/claude/channel で idle セッションへ本文注入。pull = ナッジ + check_messages は sidecar 不在 / unhealthy / channel 非対応ペイン（codex pull-peer）/ claude.ai login 不在時のフォールバック層）。ORG_TRANSPORT=renga 時は dispatcher / worker メッセージが <channel source="renga-peers" …> として in-band で push される。
• spawn 儀式: 既定 broker は --mcp-config <broker> 注入による Claude Code folder-trust プロンプトの画面判定による機械承認に加え、push 一次のため channel sidecar を --dangerously-load-development-channels server:org-broker-channel で load し dev-channel 承認プロンプトを画面判定で機械承認する（2 段承認）。ORG_TRANSPORT=renga 時は --dangerously-load-development-channels server:renga-peers の「Load development channel?」を画面判定で承認する 1 段。 画面判定 = 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 は shared codes（pane_not_found / last_pane / invalid-params）に加え broker 固有 [token_invalid] / [session_invalid] / [tool_not_authorized] / [no_backend]（= adapter_unavailable）/ [nudge_failed] / [peer_not_found] / [name_taken] を返しうる（未知コードは default-branch で escalate）。ORG_TRANSPORT=renga 時は broker 固有コードは発生しない。

new_tab / focus_pane は broker surface に無い（意図的除外）。契約面の正本は docs/contracts/backend-interface-contract.md Surface 8 + push-primary amendment（broker push 一次が 既定の契約、pull は fallback として retain）。opt-in renga は削除せず常時有効な切戻しの安全装置として維持する。broker 実走（dogfood）は Epic #6 Issue G スコープで本ファイルの既定運用経路ではない（二フレーム注記（Refs #604）: ここの「既定 broker」はコード既定（tools/transport.py: DEFAULT_TRANSPORT、生成面はこれで render）。運用既定は broker dogfood が Epic #6 Issue G まで未活性のため renga で、両者は指す対象が異なり矛盾しない。総説は root CLAUDE.md。）