@tyhld/conductor 0.3.0

package/dist/relay.js

@@ -0,0 +1,1315 @@
+/**
+ * @tyhld/conductor — ADR-029 relay 段階3。
+ *
+ * heartbeat 常駐(src/cli.ts)に「指示の取得 → アイドル判定 → tmux送信 →
+ * 完了マーカー検出 → 状態書き戻し」を足すためのモジュール。
+ *
+ * 【最重要の安全方針】
+ *   最悪のケース = 作業中の送信先CC(以下 CC2)へ誤爆して混線・破壊すること。
+ *   これを絶対に回避するため、判定はすべて保守的（少しでも作業中っぽければ送らない）。
+ *   送り損ねは次ポーリングで再挑戦できるので無害。「誤爆より送り遅れ」。
+ *
+ * 既存の heartbeat 機能・送信先API・認可(共有シークレット Bearer)は変更しない。足すだけ。
+ * 鍵はコードに書かず、必ず環境変数経由で受け取る。
+ */
+import { execFileSync } from 'node:child_process';
+// ───────────────────────────────────────────────────────────────────────────
+// 調整可能な定数（後でチューニングできるよう、ここに集約する）
+// ───────────────────────────────────────────────────────────────────────────
+/** 静止確認・プロンプト判定に使う「画面末尾の行数」。 */
+export const RELAY_TAIL_LINES = 40;
+/** 静止確認: 1回目と2回目の capture の間隔(ms)。この間に画面が動けば「作業中」。 */
+export const RELAY_SETTLE_MS = 1500;
+/**
+ * pending（送信済みDONE待ち）を諦めるまでの上限(ms)。既定15分。
+ *   CC2 が異常終了(例:529)等で DONE を返さないと pending に固着し後続を拾えなくなるため、
+ *   この時間を超えたら relay 内部で pending を解除して次へ進む（サーバ status は戻さない）。
+ *   環境変数 RELAY_PENDING_TIMEOUT_MS で上書き可（正の数のみ採用、不正値は既定にフォールバック）。
+ *   CC2 の正常作業も長くなり得るので、誤って諦めないよう十分大きめにする。
+ */
+export const RELAY_PENDING_TIMEOUT_MS = (() => {
+    const def = 15 * 60 * 1000; // 900000ms = 15分
+    const raw = (process.env.RELAY_PENDING_TIMEOUT_MS ?? '').trim();
+    if (raw === '')
+        return def;
+    const parsed = Number(raw);
+    return Number.isFinite(parsed) && parsed > 0 ? parsed : def;
+})();
+/** 環境変数を正の数として読む（空/不正は既定へフォールバック）。再送ポリシーの定数で使う。 */
+function envPositiveNumber(name, def) {
+    const raw = (process.env[name] ?? '').trim();
+    if (raw === '')
+        return def;
+    const parsed = Number(raw);
+    return Number.isFinite(parsed) && parsed > 0 ? parsed : def;
+}
+/**
+ * 自動再送(2-a)のポリシー。生存中の職人が動かないときに同一指示を再送する。
+ *   - RELAY_RESEND_DELAY_MS: 初回送信(sentAt)から最初の再送までの待機(ms)。既定30秒。
+ *   - RELAY_RESEND_INTERVAL_MS: 2回目以降(fast相)の再送間隔(ms)。直近送信(lastSentAt)基準。既定30秒。
+ *   - RELAY_RESEND_MAX: fast再送の回数。これを超えたら fast を打ち切り、★以後は低頻度(slow相)で
+ *     再配信を継続する（従来のように完全には止めない）。既定3。
+ *   - RELAY_RESEND_SLOW_INTERVAL_MS: fast上限到達後の低頻度再配信の間隔(ms)。既定2分。
+ *     起動順レース（職人が relay より後から起動）で fast を使い切った後でも、職人が起動して
+ *     未着信＋アイドルになれば次の slow tick で必ず届くようにする根治。最終打ち切りは pending
+ *     タイムアウト(RELAY_PENDING_TIMEOUT_MS)に委ねる。暴走防止は decideResend が
+ *     「未着信(anchor未可視)かつ idleStable かつ 間隔経過」のときだけ送ることで担保。
+ * いずれも環境変数で上書き可（正の数のみ採用）。
+ */
+export const RELAY_RESEND_DELAY_MS = envPositiveNumber('RELAY_RESEND_DELAY_MS', 30 * 1000);
+export const RELAY_RESEND_INTERVAL_MS = envPositiveNumber('RELAY_RESEND_INTERVAL_MS', 30 * 1000);
+export const RELAY_RESEND_MAX = envPositiveNumber('RELAY_RESEND_MAX', 3);
+export const RELAY_RESEND_SLOW_INTERVAL_MS = envPositiveNumber('RELAY_RESEND_SLOW_INTERVAL_MS', 2 * 60 * 1000);
+/**
+ * 同一 command を relay が配達する累計回数の絶対上限（保険・無限ループの構造的封じ込め）。
+ *   初回送信＋自動再送＋sent孤児復元後の再送を、プロセス内で id 単位に通算する。
+ *
+ * 【なぜ必要か】RELAY_RESEND_MAX は fast相→slow相の“間隔”を切り替えるだけで、slow相は打ち切らず
+ *   低頻度に再配信を継続する設計（起動順レース根治）。そのため職人窓が永久に未着信/未DONEのとき、
+ *   「slow再送 → pending タイムアウト(15分)で解除 → fetchCommand が同じ queued を再取得 → 再び pending →
+ *   slow再送 …」のサイクルが（resendCount がその都度0にリセットされるため）事実上無限に続く穴が残る。
+ *   この上限を超えた command はプロセス内で「配達放棄(abandoned)」とし、二度と配達しない（WARNログを残す）。
+ *
+ * 【スコープ】プロセス再起動でカウンタ/放棄集合はリセットされる（サーバAPIは変更しない方針のため永続化しない）。
+ *   これは許容範囲: DONE 到達済みの command はそもそもサーバが queued を返さない＝再取得されない。
+ *   本上限は「完了通知が単線で切れて詰まった」異常時に無限ループを構造的に不可能化するための保険。
+ *   環境変数 RELAY_DELIVER_MAX で上書き可（正の数のみ）。既定20（初回1＋再送19相当）。
+ */
+export const RELAY_DELIVER_MAX = envPositiveNumber('RELAY_DELIVER_MAX', 20);
+/**
+ * sent孤児の復元(2-b)を有効化するか。既定有効。CONDUCTOR_RESTORE_ORPHANS が
+ * 0/false/no/off（大小無視）のときだけ無効化する（安全に止められる逃げ道）。
+ */
+export const RELAY_RESTORE_ORPHANS_ENABLED = !/^(0|false|no|off)$/i.test((process.env.CONDUCTOR_RESTORE_ORPHANS ?? '').trim());
+/**
+ * 孤児取得APIのタイムアウト(ms)。devlog 到達不能でも relay 起動がハングしないよう短め。
+ *   環境変数 CONDUCTOR_RESTORE_ORPHANS_TIMEOUT_MS で上書き可（正の数のみ）。既定5秒。
+ */
+export const RELAY_ORPHAN_FETCH_TIMEOUT_MS = envPositiveNumber('CONDUCTOR_RESTORE_ORPHANS_TIMEOUT_MS', 5 * 1000);
+/**
+ * 外部完了検出の中央 status probe（fetchCommandStatus）のタイムアウト(ms)。既定5s。
+ *   pending(着信確認済み)＋職人アイドルのときだけ叩く最善努力プローブ。中央到達不能でも tick を
+ *   ハングさせないため短めに切り、失敗は null（＝従来の副シグナル/タイムアウトへ無損失縮退）。
+ */
+export const RELAY_STATUS_FETCH_TIMEOUT_MS = envPositiveNumber('RELAY_STATUS_FETCH_TIMEOUT_MS', 5 * 1000);
+/**
+ * 生存ハートビート(案①・調査 cmqbuch4l)の送信間隔(ms)。既定2.5分。
+ *   pending(送信済みDONE待ち)で職人が busy のとき、この間隔で中央へ「まだ作業中」を通知し
+ *   中央の lastSeenAt を更新する。中央の auto-fail TTL(既定15分)より十分短くし、長時間作業中の
+ *   sent が誤って failed 化されないようにする。毎tick送らずここでスロットルする。
+ *   環境変数 RELAY_HEARTBEAT_INTERVAL_MS で上書き可（正の数のみ）。
+ */
+export const RELAY_HEARTBEAT_INTERVAL_MS = envPositiveNumber('RELAY_HEARTBEAT_INTERVAL_MS', 150 * 1000);
+/**
+ * 「実際に処理中のときだけ出る、確実なシグナル」だけを持つ（小文字化して部分一致で判定）。
+ * 一つでも末尾付近にあれば送らない。
+ *
+ * 【なぜ絞るか】以前は running/working/thinking/tool use/press up to 等の一般語も入れていたが、
+ * これらは CC2 の通常画面や週替わりヒント（例: "Feature of the week: /loop ..."）に紛れて
+ * 誤検出し、アイドルなのに永久に送れない不具合を招いた。判定は一般語の有無では行わない。
+ *   - 'esc to interrupt': Claude Code が処理ループ中に必ず出す、最も確実な表示。主シグナル。
+ *   - 'compacting': 自動コンパクト中の確実な処理表示（通常画面・ヒント文には出ない）。
+ * スピナーグリフ（BUSY_GLYPHS）は実処理中のみ点滅するので併用する。
+ */
+export const BUSY_MARKERS = [
+    'esc to interrupt',
+    'compacting',
+];
+/**
+ * 「作業中」を示すスピナーグリフ。末尾付近にあれば送らない。
+ * 実処理中だけ点滅する Braille スピナーのみを残す。
+ * （飾り記号 '✶ ✻ ✽ ✢ ✳ ✦ ✧' は Claude Code のアイドル時UI（ウェルカム表示・Tip行等）にも
+ *  出るため、アイドルなのに永久 busy 判定となる誤検出源だったので除外した。
+ *  '·' のような普通の出力に頻出する記号も入れない。）
+ */
+export const BUSY_GLYPHS = ['⠋', '⠙', '⠹', '⠸', '⠼', '⠴', '⠦', '⠧', '⠇', '⠏'];
+/**
+ * CC2 の作業報告を囲ませる行マーカー（ADR-029 報告集約・送信側）。
+ * CC2 はこの2行で報告本文を挟んで出力し、relay が間の行群を抜き出して中央へ送る。
+ * BUSY_MARKERS / BUSY_GLYPHS / `DONE:` のいずれとも文字列が衝突しない（アイドル判定・完了判定を汚さない）。
+ */
+export const REPORT_START = 'REPORT_START';
+export const REPORT_END = 'REPORT_END';
+/** 連続スキップ何回でアイドル誤判定の疑いをWARNするか（観測のみ・送信挙動は変えない）。 */
+export const RELAY_SKIP_WARN_THRESHOLD = 6;
+/** 初期状態を作る。 */
+export function createRelayState() {
+    return {
+        pending: null,
+        running: false,
+        restored: false,
+        lastHalted: null,
+        lastSkippedId: null,
+        skipCount: 0,
+        skipWarned: false,
+        lastHeartbeatAt: null,
+        deliverCounts: new Map(),
+        abandoned: new Set(),
+    };
+}
+/**
+ * この command を（初回/再送問わず）まだ配達してよいか。純粋関数（I/Oなし＝単体テスト可能）。
+ *   - 既に放棄済み(abandoned) → false。
+ *   - 累計配達回数が RELAY_DELIVER_MAX 以上 → false（もう配達しない＝無限ループ防止の絶対上限）。
+ */
+export function canDeliver(state, id) {
+    if (state.abandoned.has(id))
+        return false;
+    return (state.deliverCounts.get(id) ?? 0) < RELAY_DELIVER_MAX;
+}
+/** 配達成功を1件記録して累計を返す（初回送信・再送の両方の成功時に呼ぶ）。 */
+export function markDelivered(state, id) {
+    const n = (state.deliverCounts.get(id) ?? 0) + 1;
+    state.deliverCounts.set(id, n);
+    return n;
+}
+// ───────────────────────────────────────────────────────────────────────────
+// 純粋関数（外部I/Oなし＝単体テスト/ドライランしやすい）
+// ───────────────────────────────────────────────────────────────────────────
+const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
+/** 末尾の空行を除いた「末尾 RELAY_TAIL_LINES 行」を文字列で返す。静止比較の単位。 */
+export function tailOf(text) {
+    const lines = text.replace(/\r/g, '').split('\n');
+    while (lines.length > 0 && lines[lines.length - 1].trim() === '')
+        lines.pop();
+    return lines.slice(-RELAY_TAIL_LINES).join('\n');
+}
+/**
+ * 画面末尾に「確実な処理中シグナル（esc to interrupt / compacting / スピナーグリフ）」が
+ * あるかを判定する純粋関数。末尾 RELAY_TAIL_LINES 行だけを見る（looksIdle と同じ範囲）。
+ *   - busy 判定を looksIdle から切り出して再利用可能にしたもの（自動再送の可否判定でも使う）。
+ *   - looksIdle はこれが true なら即アイドル不成立に倒す。
+ */
+export function hasBusySignal(text) {
+    const lines = text.replace(/\r/g, '').split('\n');
+    while (lines.length > 0 && lines[lines.length - 1].trim() === '')
+        lines.pop();
+    const tail = lines.slice(-RELAY_TAIL_LINES);
+    const tailText = tail.join('\n');
+    const lower = tailText.toLowerCase();
+    if (BUSY_MARKERS.some((m) => lower.includes(m)))
+        return true;
+    if (BUSY_GLYPHS.some((g) => tailText.includes(g)))
+        return true;
+    return false;
+}
+/**
+ * 画面テキストから「アイドルか」を判定する純粋関数（判定(a)）。
+ *   方針:「確実な処理中シグナル（esc to interrupt / compacting / スピナーグリフ）が無く、
+ *   かつ末尾付近に入力待ちプロンプト行がある」ときだけアイドルとみなす。一般語では判定しない。
+ *   週替わりヒントやバナーが上にあっても、末尾に入力待ちがあればアイドルと判定できる。
+ *   曖昧なら false（＝送らない側）に倒す。
+ */
+export function looksIdle(text) {
+    const lines = text.replace(/\r/g, '').split('\n');
+    while (lines.length > 0 && lines[lines.length - 1].trim() === '')
+        lines.pop();
+    const tail = lines.slice(-RELAY_TAIL_LINES);
+    // 確実な処理中シグナルがあれば即アウト（作業中とみなす）。
+    if (hasBusySignal(text))
+        return false;
+    // 許可プロンプト表示中はアイドルとみなさない（落とし穴ガード）。
+    //   Claude Code の許可プロンプト("❯ 1. Yes" 等)も `❯` で始まる行を含むため、下の hasPrompt が
+    //   true になりアイドル誤判定し得る。許可プロンプト中に relay の pending ループが新規指示や再送を
+    //   流し込むと、選択メニューに指示文が打ち込まれて混線する。許可プロンプト中は必ず非アイドルに倒し、
+    //   応答は専用の許可ループ(permission.ts)にのみ委ねる（送信経路の唯一化＝CC2書き込みの排他）。
+    if (hasPermissionPrompt(text).isPrompt)
+        return false;
+    // 入力待ちプロンプト行の検出。
+    // tmux のボックス装飾(│ | 空白)を行頭から剥がし、残りが入力待ちプロンプト記号で始まれば入力待ち。
+    // CC2 (Claude Code v2系) の実プロンプトは `❯`(U+276F) のみを採用する。
+    // 【後方互換 `>` 許容を撤去】`>` 始まりは bash の継続プロンプトや独自PS1など
+    //   非claude窓にも出るため、待機と誤認して非claude窓へ誤爆する穴の原因だった。
+    //   claude の入力プロンプトは `❯` なので、`❯` 始まりだけをアイドルとみなす。
+    const hasPrompt = tail.some((line) => {
+        const stripped = line.replace(/^[│|\s]+/, '');
+        return stripped.startsWith('❯');
+    });
+    return hasPrompt;
+}
+/**
+ * 許可プロンプトに固有で、通常画面・週替わりヒント・報告/ENQUEUE出力のいずれにも出ない綴り。
+ *   - 質問行: "Do you want to proceed?" / "Do you want to allow this connection?" 等。
+ *   - 選択肢行: "❯ 1. Yes" / "1. Yes"（番号付き選択メニューの先頭）。
+ * 【誤検出を絶対に避ける】質問行と "1. Yes" 選択肢行の「両方」が末尾付近に在るときだけ許可プロンプトと
+ *   みなす。どちらか一方だけ（例: 文章中の "yes"）では成立させない。これにより looksIdle を不当に
+ *   false へ倒して relay を永久に黙らせる事故（過去の busy 誤検出と同型の罠）を防ぐ。
+ */
+const PERMISSION_QUESTION_RE = /do you want to (proceed|allow|create|run|make|continue|apply|delete|overwrite|trust|execute)/i;
+/** 選択肢「1. Yes」行（行頭の `❯` カーソルは任意）。`1.` でも `1)` でも拾う。 */
+const PERMISSION_YES_RE = /^❯?\s*1[.)]\s*yes\b/i;
+/** 種別 network 判定に使う、接続許可特有の語。 */
+const PERMISSION_NETWORK_RE = /connection|connect to|fetch|request to|url|domain|host\b|network/i;
+/** tmux のボックス装飾(│ ╎ ┃ | と前後空白)を行から剥がす。 */
+function stripBoxDecoration(line) {
+    return line
+        .replace(/^[│|╎┃\s]+/, '')
+        .replace(/[│|╎┃\s]+$/, '')
+        .trim();
+}
+/**
+ * 画面テキストに「許可プロンプト（Do you want to ... ＋ 1. Yes 選択肢）」が出ているかを判定する純粋関数。
+ *   - 末尾付近のみ見る（許可プロンプトは常に画面下部に描画される）。枠が高いことがあるので少し広めに取る。
+ *   - 質問行と "1. Yes" 選択肢行の両方が在るときだけ isPrompt=true（誤検出をしない最優先）。
+ *   - command は枠上辺(╭)〜質問行の内容行を best-effort で結合（抽出不能でも検知自体は成立）。
+ *   - kind は質問文の語から network / command を推定（不明は 'command' に寄せる）。
+ */
+export function hasPermissionPrompt(text) {
+    const NONE = { isPrompt: false, command: '', kind: 'unknown' };
+    const allLines = text.replace(/\r/g, '').split('\n');
+    // 末尾付近（枠の高さを考慮し RELAY_TAIL_LINES より広めの 50 行）だけを対象にする。
+    const span = Math.max(RELAY_TAIL_LINES, 50);
+    const lines = allLines.slice(-span);
+    const stripped = lines.map(stripBoxDecoration);
+    // 質問行（"Do you want to ..."）を末尾側から探す。
+    let questionIdx = -1;
+    for (let i = stripped.length - 1; i >= 0; i--) {
+        if (PERMISSION_QUESTION_RE.test(stripped[i])) {
+            questionIdx = i;
+            break;
+        }
+    }
+    if (questionIdx < 0)
+        return NONE;
+    // "1. Yes" 選択肢行が在るか（質問行とセットで初めて許可プロンプトと確定する）。
+    if (!stripped.some((s) => PERMISSION_YES_RE.test(s)))
+        return NONE;
+    // 種別: 質問文に接続許可特有の語があれば network、無ければ command（ツール実行許可）。
+    const kind = PERMISSION_NETWORK_RE.test(stripped[questionIdx])
+        ? 'network'
+        : 'command';
+    // command 抽出(best-effort): 質問行の直上にある枠上辺(╭)以降〜質問行までの内容行を結合する。
+    let topIdx = 0;
+    for (let i = questionIdx - 1; i >= 0; i--) {
+        if (lines[i].includes('╭')) {
+            topIdx = i + 1;
+            break;
+        }
+    }
+    const content = [];
+    for (let i = topIdx; i < questionIdx; i++) {
+        const s = stripped[i];
+        if (s !== '')
+            content.push(s);
+    }
+    const command = content.join(' ').replace(/\s+/g, ' ').trim();
+    return { isPrompt: true, command, kind };
+}
+/**
+ * セッション評価などの「想定外モーダル」（Yes/No の許可ではなく、閉じるだけでよい類）を検知する純粋関数。
+ *   例: 「How is Claude doing this session? 1:Bad 2:Fine 3:Good 0:Dismiss」。
+ *
+ * 【なぜ別関数か】これは許可プロンプト(hasPermissionPrompt: "Do you want to … 1.Yes")とは別物で、
+ *   ALLOW/DENY の安全判断対象ではない。放置すると CC1B 自身がこれで固まり、全現場の許可判断が
+ *   止まる（指示 cmqc0ynkb の副因）。検知したら Esc で**閉じるだけ**にする（Yes/No は絶対に押さない）。
+ *
+ * 【誤爆を避ける】許可プロンプト(1.Yes)とは綴りが重ならない2パターンのいずれかが末尾付近に在るときだけ true:
+ *   - 評価モーダル特有の質問文 /how is claude doing/i
+ *   - 「0. Dismiss」/「0) Dismiss」選択肢行（行頭から単独。許可メニューは 1/2/3 で 0:Dismiss を持たない）
+ */
+const DISMISS_RATING_RE = /how is claude doing/i;
+const DISMISS_OPTION_RE = /^❯?\s*0\s*[.)]?\s*dismiss\b/i;
+export function hasDismissablePrompt(text) {
+    const allLines = text.replace(/\r/g, '').split('\n');
+    const span = Math.max(RELAY_TAIL_LINES, 50);
+    const lines = allLines.slice(-span).map(stripBoxDecoration);
+    return lines.some((s) => DISMISS_RATING_RE.test(s) || DISMISS_OPTION_RE.test(s));
+}
+/**
+ * Claude Code 固有の表示マーカー（小文字化して部分一致で判定・内容ベースのガード用）。
+ * 名前一致＋`❯`プロンプトだけでは、fish/starship 等 `❯` を入力記号に使う非claude窓へ
+ * 誤爆し得る。送信直前に capture へこのいずれかが含まれるときだけ送ることで、その穴を塞ぐ。
+ *   - 'claude code': 起動バナー（ウェルカム画面）に出る固有文字列。
+ *   - '? for shortcuts': 入力枠フッターのヒント。アイドルで入力欄が空のとき表示される。
+ *   - 'accept edits on' / 'esc to interrupt' / 'for agents': FleetView系フッターの語。
+ *       それぞれ「権限モード行(accept edits on)」「busy中の中断ヒント(esc to interrupt)」
+ *       「エージェント切替ヒント(← for agents)」として画面末尾に出る。入力欄に未送信の残テキストが
+ *       あると '? for shortcuts' が隠れて偽陰性になるが、これらフッター語は残テキスト有無に関係なく
+ *       出るため取りこぼしを救える。いずれも素のシェルや一般TUIには出ない Claude Code 固有語に
+ *       限定し、非claude窓への誤検知を避ける。
+ * いずれも素のシェルや一般TUIには出ないため、非claude窓を確実に弾ける。
+ */
+export const CLAUDE_MARKERS = [
+    'claude code',
+    '? for shortcuts',
+    'accept edits on',
+    'esc to interrupt',
+    'for agents',
+];
+/**
+ * 入力枠の横罫線（全幅ルール）とみなす連続 `─`(U+2500) の最小本数。
+ * 短い装飾区切り線の誤検知を避けるため長め（全幅枠相当）に取る。
+ */
+const BOX_RULE_MIN_DASHES = 12;
+/**
+ * capture テキストが「Claude Code の箱」と言えるかを判定する純粋関数（内容ベースのガード）。
+ *
+ * 【判定: 恒久シグナル OR 既存マーカー（OR で後退させない）】
+ *   (a) 恒久シグナル: Claude Code は idle 時、画面末尾へ「入力枠＋`❯` プロンプト」を常に描画する。
+ *       バナー('claude code')がスクロールアウトしても、フッターヒントがローテーションしても、
+ *       この入力枠は出続けるため可視範囲依存に強い。枠の描画は2バリエーションを許容する:
+ *         (a-1) 角丸ボックス: 上辺 `╭──…` / 下辺 `╰──…`（または右上 `…─╮` / 右下 `…─╯`）。
+ *         (a-2) 直線フルワイド罫線: コーナー無しで `─` が BOX_RULE_MIN_DASHES 本以上連続する横線。
+ *               FleetView 等で角丸でなく直線 ──── の枠を描く版を取りこぼさないため。
+ *       いずれも `❯` プロンプト行との同時存在で枠と判定。素のシェルや fish/starship 等
+ *       （`❯` は使うが全幅 ─ 罫線も角丸枠も描かない）には出ないので非claude窓を弾ける。
+ *   (b) 既存マーカー: CLAUDE_MARKERS のいずれか（従来挙動を温存・取りこぼし防止）。
+ *   どちらかが成立すれば true。両方不成立なら false（＝送らない側）。
+ */
+export function looksLikeClaude(text) {
+    const lower = text.toLowerCase();
+    if (CLAUDE_MARKERS.some((m) => lower.includes(m)))
+        return true;
+    // 恒久シグナル: 入力枠の罫線と `❯` プロンプト行の同時存在。
+    const lines = text.replace(/\r/g, '').split('\n');
+    const hasPrompt = lines.some((line) => line.replace(/^[│|\s]+/, '').startsWith('❯'));
+    // 枠線は2種類を許容（描画バリエーション差を吸収）:
+    //   (1) 角丸ボックス: 上辺 `╭──…` / 下辺 `╰──…`（または右上 `…─╮` / 右下 `…─╯`）。
+    //   (2) 直線フルワイド罫線: `─` が BOX_RULE_MIN_DASHES 本以上連続する横線（角丸でない版）。
+    const straightRule = new RegExp(`─{${BOX_RULE_MIN_DASHES},}`);
+    const hasFrame = lines.some((line) => /[╭╰]─{2,}|─{2,}[╮╯]/.test(line) || straightRule.test(line));
+    return hasPrompt && hasFrame;
+}
+/**
+ * 画面テキストに「完了マーカー DONE:{site} が単独で出力されているか」を判定する純粋関数。
+ *
+ * 注意: 送信本文自体に "...必ず DONE:{site} とだけ出力してください" という指示文が含まれ、
+ * それが画面にエコーされる。これを完了と誤検出しないよう、
+ * 「marker 以外の文字（装飾を除く）がほぼ残らない＝marker 単独の行」だけを完了とみなす。
+ * 最も新しい(末尾側の) marker 行で判定する。
+ */
+/** 1行が「DONE:{site} 単独行」か。marker と装飾・空白を除いて何も残らなければ単独。 */
+function isStandaloneDoneLine(line, marker) {
+    if (!line.includes(marker))
+        return false;
+    const rest = line.replace(marker, '').replace(/[│|>⏺●○•*·\s]/g, '');
+    return rest.length === 0;
+}
+export function hasDoneMarker(text, site) {
+    const marker = `DONE:${site}`;
+    const lines = text.replace(/\r/g, '').split('\n');
+    for (let i = lines.length - 1; i >= 0; i--) {
+        if (!lines[i].includes(marker))
+            continue;
+        // marker を含む最も新しい行が「単独行」かどうかで判定。
+        return isStandaloneDoneLine(lines[i], marker);
+    }
+    return false;
+}
+/**
+ * 送信ごとの一意アンカートークンの接頭辞。送信本文の末尾に `${SEND_ANCHOR_PREFIX}:{id}` を埋め込み、
+ * 画面にエコーされたこの行を「今回ジョブの境界」として使う。
+ * BUSY_MARKERS / `DONE:` / `REPORT_*` のいずれとも衝突しない綴りにする（他判定を汚さない）。
+ */
+export const SEND_ANCHOR_PREFIX = 'CONDUCTOR_JOB';
+/** 指示idから送信アンカー文字列を作る純粋関数。id は中央発番で globally unique＝他出力と衝突しない。 */
+export function buildAnchor(id) {
+    return `${SEND_ANCHOR_PREFIX}:${id}`;
+}
+/**
+ * capture テキストから「アンカーが最後に現れた行より下」だけを切り出す純粋関数。
+ *   - アンカーは今回送信した指示文の末尾に在り、画面では『送信したユーザ入力のエコー』の最後に出る。
+ *     その下に職人(CC2)の応答が描画されるので、下側だけ見れば今回ジョブの出力に限定できる。
+ *   - 最後の出現を採るのは、職人が応答中にプロンプトを引用してアンカーを再掲しても、
+ *     最終的な DONE 行はさらにその下に出るため取りこぼさないようにするため。
+ *   - アンカーが画面外（2000行窓から流出）なら null（＝まだ確証なし。保守側で完了とみなさない）。
+ */
+export function sliceBelowAnchor(text, anchor) {
+    const lines = text.replace(/\r/g, '').split('\n');
+    let anchorIdx = -1;
+    for (let i = lines.length - 1; i >= 0; i--) {
+        if (lines[i].includes(anchor)) {
+            anchorIdx = i;
+            break;
+        }
+    }
+    if (anchorIdx < 0)
+        return null;
+    return lines.slice(anchorIdx + 1).join('\n');
+}
+/** テキスト中に「DONE:{site} 単独行」が1つでもあるか（装飾を除いて marker 単独）。 */
+export function hasStandaloneDone(text, site) {
+    const marker = `DONE:${site}`;
+    const lines = text.replace(/\r/g, '').split('\n');
+    return lines.some((line) => isStandaloneDoneLine(line, marker));
+}
+/**
+ * アンカー基準の完了判定（根治の中核）。
+ *   「アンカーより下の領域」に DONE:{site} 単独行があれば完了とみなす。
+ *   - churn で古い DONE が窓上端から押し出されても、過去ジョブの DONE が窓に残っていても、
+ *     見るのはアンカーより下＝今回ジョブの出力だけなので、誤検出も見逃しも起きない。
+ *   - 送信本文エコー由来の非単独 DONE（指示文「…必ず DONE:{site} とだけ…」）は
+ *     isStandaloneDoneLine が弾く＆そもそもアンカー行と同一論理行＝アンカーより上に来るので対象外。
+ *   - アンカーが画面外なら false（保守側＝完了とみなさず、次tick再確認 / 最終的に pending タイムアウト）。
+ */
+export function hasDoneBelowAnchor(text, site, anchor) {
+    const below = sliceBelowAnchor(text, anchor);
+    if (below === null)
+        return false;
+    return hasStandaloneDone(below, site);
+}
+/**
+ * 生存中の職人が動かないときの自動再送の可否を判定する純粋関数（2-a の核心）。
+ *
+ * 【二重実行を防ぐ冪等性が最優先】判定の順序がそのまま安全の優先順位:
+ *   1) アンカー(CONDUCTOR_JOB:{id})が画面に出ている＝tmuxへ着信済み。アイドルでも再送しない。
+ *      （職人が読んで思考中の可能性。これが二重実行防止の核心。経過時間より着信判定を優先する）
+ *   2) busy（esc to interrupt / compacting / スピナー）＝実処理中なら再送しない（混線回避）。
+ *   3) 二重チェックのアイドル(isIdleStable)が不成立なら再送しない（保守的）。
+ *   4) 送信間隔が lastSentAt から未経過なら待つ。間隔は「初回=delay / fast相(回数<max)=interval /
+ *      ★slow相(回数≥max)=slowInterval」。
+ *   5) 上を全て満たす＝未着信かつ静止かつ閾値経過 → 'resend'。
+ *
+ * ★起動順レース根治（不具合A）: かつては「最大再送回数到達で 'stop'（打ち切り）」だったが、
+ *   これだと職人が relay より後から起動したケースで二度と届かなかった。本実装は上限到達で
+ *   打ち切らず、間隔を slowInterval に広げて低頻度で再配信を継続する（職人が起動して未着信＋
+ *   アイドルになれば次の slow tick で必ず届く）。暴走しないのは、再送が常に「未着信(anchor未可視)
+ *   かつ idleStable かつ 間隔経過」を満たすときだけ＝着信済み/busy/非アイドルの間は一切送らないため。
+ *   最終的な打ち切りは外側の pending タイムアウト(RELAY_PENDING_TIMEOUT_MS)に委ねる。
+ *
+ * capture は単一フレームの画面テキスト（着信判定 anchor とbusy判定に使う）。
+ * idleStable は呼び出し側で isIdleStable() を実行した二重チェック済みアイドルの真偽。
+ */
+export function decideResend(args) {
+    const { capture, anchor, idleStable, lastSentAt, resendCount, now, policy } = args;
+    // (1) 冪等性の核心: 着信済み（アンカーが画面に可視）ならアイドルでも再送しない。
+    if (capture.includes(anchor)) {
+        return { verdict: 'wait', reason: 'delivered (anchor visible on screen)' };
+    }
+    // (2) 実処理中シグナルがあれば再送しない（職人が動いている＝送信は届いて処理中の可能性）。
+    if (hasBusySignal(capture)) {
+        return { verdict: 'wait', reason: 'busy (work-in-progress signal)' };
+    }
+    // (3) 二重チェックのアイドルが不成立なら再送しない。
+    if (!idleStable) {
+        return { verdict: 'wait', reason: 'not idle-stable' };
+    }
+    // (4) 送信間隔（初回 delay / fast相 interval / ★slow相 slowInterval）未経過なら待つ。lastSentAt 基準。
+    //     fast相 = 回数 < maxResend、slow相 = 回数 ≥ maxResend（上限到達後も打ち切らず低頻度継続）。
+    const inSlowPhase = resendCount >= policy.maxResend;
+    const required = resendCount === 0
+        ? policy.resendDelayMs
+        : inSlowPhase
+            ? policy.resendSlowIntervalMs
+            : policy.resendIntervalMs;
+    if (now - lastSentAt < required) {
+        return { verdict: 'wait', reason: 'resend interval not elapsed' };
+    }
+    // (5) 未着信＋アイドル＋閾値経過 → 再送（上限後も slow相 で低頻度に継続）。
+    return {
+        verdict: 'resend',
+        reason: inSlowPhase
+            ? 'undelivered & idle-stable & slow-interval elapsed (post-max slow redelivery)'
+            : 'undelivered & idle-stable & interval elapsed',
+    };
+}
+/**
+ * 外部完了（中央で done/failed 化された案件）を検知して pending 追跡を解除すべきかを判定する純粋関数。
+ *
+ * 【背景・実地バグ 2026-07-04】relayTick の完了検出は「職人画面に DONE:{site} 単独行がエコーされる」
+ *   画面スクレイプが唯一の経路だった。ところが職人が devlog MCP の conductor_complete で中央を直接
+ *   done 化すると画面に DONE 行が出ないため、この検出が永遠に成立せず pending が固着し、
+ *   `return; // sent 中は新規取得しない` により次の queued へ二度と進めなくなる（relay 再起動でのみ復旧）。
+ *   これは「完了の真実は中央にあるのに relay が自前の画面検出だけを待っている」という設計の穴。
+ *
+ * 【判定の根拠＝根治方針「完了の真実は中央にある」への寄せ】
+ *   中央は「1現場同時1指示」で、ある指示が sent の間は新規 queued を返さない（fetchCommand=null）。
+ *   したがって次の条件が揃えば pending.id は中央で既に終端した確証になる:
+ *     - delivered（着信確認済み＝relay が status を 'sent' に遷移済み）で、
+ *     - 職人画面がアイドル（looksIdle＝処理中でも許可プロンプトでもない・入力待ち）で、
+ *     - fetchCommand が pending.id とは別の id の指示を返した（＝中央がもう次を配れる状態）。
+ *   このとき追跡を解除して次tickで新規指示を素直に取りに行けば、外部done化でも詰まらない。
+ *
+ * 【安全側（false=解除しない）に倒すケース】いずれも従来の画面DONE検出／pendingタイムアウトへ無損失縮退:
+ *   - delivered 前（まだ queued 据置・着信未確認）: 次のqueuedはpending自身なので誤検出しない。
+ *   - 非アイドル（busy/許可プロンプト等）: まだ職人が動作中の可能性 → 解除しない。
+ *   - 中央不達 or 次指示なし（nextCommandId=null）。
+ *   - 次指示が pending と同id（通常は起こらないが、念のため同一なら解除しない）。
+ *
+ * I/O を持たない純粋関数（fetchCommand の結果 id と画面アイドル判定を引数で受ける）＝単体テスト可能。
+ */
+export function detectExternalDone(args) {
+    if (!args.delivered)
+        return false; // 着信未確認＝中央はまだ queued。次のqueuedはpending自身。
+    if (!args.idle)
+        return false; // 職人が動作中/許可待ちの可能性 → 解除しない（保守的）。
+    if (args.nextCommandId === null)
+        return false; // 中央不達 or 次指示なし＝pendingは依然sent中。
+    return args.nextCommandId !== args.pendingId; // 別idが配信可能＝pendingは中央で終端済みの確証。
+}
+/**
+ * 中央が返した指示 status 文字列が「終端（もう作業しない状態）」かを判定する純粋関数。
+ *
+ * 【根治の中核】detectExternalDone は「次に別の queued がある」ときしか外部done化を検知できず、
+ *   キューが空(nextCommandId=null)だと conductor_complete 済みでも pending が 15分固着していた
+ *   （実地: 24hで完了の約8割が pendingタイムアウト固着）。中央の真実は「その id 単体の status」に
+ *   あるので、fetchCommandStatus で直接問い、終端ならキューの有無に関係なく追跡解除する。
+ *
+ * 終端とみなす綴り: done / failed / cancelled / canceled / abandoned（大小・前後空白は無視）。
+ *   queued / sent / running 等の「まだ生きている」status、および null（中央不達/未知）は終端でない。
+ *   曖昧なら false（＝解除しない安全側）に倒す（looksIdle と同じ保守方針）。
+ */
+export function isTerminalCommandStatus(status) {
+    if (status === null)
+        return false;
+    const s = status.trim().toLowerCase();
+    return s === 'done' || s === 'failed' || s === 'cancelled' || s === 'canceled' || s === 'abandoned';
+}
+/**
+ * sent孤児を 2-a の pending 構造へ変換する純粋関数（★送信はしない）。
+ *   - anchor は buildAnchor(id) で再生成（id 不変＝アンカー不変）。送信本文末尾のアンカーと一致するため、
+ *     復元後に画面へアンカーが残っていれば decideResend が「着信済み」と見て再送しない（二重実行防止）。
+ *   - resendCount=0 から再開。lastSentAt は取得した sentAt を流用（次の再送間隔判定の基準）。
+ *     孤児は sentAt が十分過去（TTL超）なので、未着信なら次tickの decideResend で即 resend 判定になり得る。
+ *   - delivered=true: 孤児は元々サーバ status=sent＝過去に着信確認を経て sent 化済みの段階。
+ *     復元後に再度 patchStatus('sent') する必要はなく、DONE 待ち/再送のみを担う。
+ */
+export function orphanToPending(orphan) {
+    return {
+        id: orphan.id,
+        site: orphan.site,
+        sentAt: orphan.sentAt,
+        anchor: buildAnchor(orphan.id),
+        body: orphan.body,
+        resendCount: 0,
+        lastSentAt: orphan.sentAt,
+        resendExhaustedWarned: false,
+        delivered: true,
+    };
+}
+/**
+ * 単一 pending スロットへ復元する孤児を1件選ぶ純粋関数（二重復元・上書き防止の核心）。
+ *   - 既に pending がある（同一プロセスで送信中／既に復元済み）→ null（復元しない）。
+ *     これにより「同一idの二重復元」も「別idでの上書き」も起きない（1現場同時1指示の不変条件を守る）。
+ *   - pending が無く孤児があれば、最も古い(sentAt最小)1件を選ぶ（決定的・最優先で処理すべき滞留）。
+ */
+export function selectOrphanToRestore(orphans, currentPending) {
+    if (currentPending !== null)
+        return null;
+    if (orphans.length === 0)
+        return null;
+    return orphans.reduce((oldest, o) => (o.sentAt < oldest.sentAt ? o : oldest));
+}
+/**
+ * 実際に tmux へ流し込む1行テキストを組み立てる純粋関数。
+ *   送る本文 = 指示body + 報告マーカー指示 + 完了マーカー指示。
+ * CC2 の途中送信を防ぐため、改行はすべて空白に潰して「1行=1メッセージ」にする
+ * （本文内に生 Enter を含めない＝送信は末尾の Enter 1回だけにするため）。
+ *
+ * 完了時に CC2 へ求める出力形式:
+ *   1) 報告を ${REPORT_START} と ${REPORT_END} の2行で挟んで出力（変更ファイル・要点・チェック結果を簡潔に）。
+ *   2) その後の最終行に必ず DONE:{site} とだけ出力（既存の完了運用＝relay画面スクレイプの高速パスを維持）。
+ *   3) さらに devlog MCP の conductor_complete を commandId=<id> で1回呼ぶ（案D・relay非依存の確実な完了通知）。
+ *      relay 再起動・画面churn で (1)(2) のスクレイプ検出が落ちても、中央が (3) で確実に done を立てる二重防御。
+ *
+ * anchor: この送信に固有のアンカートークン（buildAnchor(id)＝`CONDUCTOR_JOB:<id>`）。本文の「最後」に置くことで、
+ *   画面では送信エコーの末尾に出る＝完了検出(hasDoneBelowAnchor)の境界になる。
+ *   末尾に置く理由: アンカーより上に来る指示文中の "DONE:{site}" を完了検出から確実に除外するため。
+ */
+export function buildSendText(body, site, anchor) {
+    const marker = `DONE:${site}`;
+    // anchor から素の commandId を取り出す（conductor_complete に渡す引数。接頭辞無しなので新たな
+    // アンカー一致を作らず、sliceBelowAnchor/decideResend の境界判定に干渉しない）。
+    const commandId = anchor.startsWith(`${SEND_ANCHOR_PREFIX}:`)
+        ? anchor.slice(SEND_ANCHOR_PREFIX.length + 1)
+        : anchor;
+    const full = `${body}\n\n` +
+        `作業がすべて完了したら、まず報告を ${REPORT_START} と ${REPORT_END} の2行で挟んで出力してください` +
+        `（変更ファイル・要点・チェック結果を簡潔に）。` +
+        `その後の最終行に必ず ${marker} とだけ出力してください。\n\n` +
+        // ★案D（relay非依存の確実な完了通知）: 完了したら必ず devlog MCP の conductor_complete を呼ぶ。
+        `そして完了したら必ず、devlog の MCP ツール conductor_complete を commandId="${commandId}" で1回だけ呼んでください` +
+        `（relayに依存しない確実な完了通知です。report 引数に上記の報告本文を添えても構いません）。\n\n` +
+        // アンカー（管理用ジョブ印）は必ず本文の最後に置く。完了検出の境界として使う。
+        `（管理用ジョブ印・変更不要: ${anchor}）`;
+    // 改行(と連続改行)を空白1個に潰し、前後を整える。
+    return full.replace(/\r?\n+/g, ' ').replace(/\s+/g, ' ').trim();
+}
+/**
+ * 画面テキストから CC2 の報告本文を抜き出す純粋関数（ADR-029 報告集約・送信側）。
+ *
+ * 方針:
+ *   - 行単位で「装飾を除くと ${REPORT_START} / ${REPORT_END} だけが残る行」をマーカー行とみなす。
+ *     送信本文のエコー行は1行に両マーカー＋指示文が同居するため、装飾除去後に空にならず
+ *     マーカー行と判定されない（＝誤抽出しない）。
+ *   - マーカーが複数あれば「最後のペア」（最後の END と、その直前の最も近い START）を採用する。
+ *     CC2 の実報告は送信本文エコーより後（画面下側）に出るため、最後のペア採用で実報告を拾える。
+ *   - START/END が無い・対応が壊れている・中身が空のときは null（報告なし）。done化は妨げない。
+ *
+ * 限界（今回スコープ外）: tmux capture-pane は画面に見えている範囲しか取れないため、
+ *   報告がスクロールで流れると全文は取れない（取れた範囲を report とする）。
+ */
+export function extractReport(text) {
+    const lines = text.replace(/\r/g, '').split('\n');
+    // 装飾（ボックス罫線・行頭バレット・空白）を除いた中身を返す。
+    const stripped = (line) => line.replace(/[│|>⏺●○•*·]/g, '').trim();
+    // 最後の END マーカー行を探す。
+    let endIdx = -1;
+    for (let i = lines.length - 1; i >= 0; i--) {
+        if (stripped(lines[i]) === REPORT_END) {
+            endIdx = i;
+            break;
+        }
+    }
+    if (endIdx < 0)
+        return null;
+    // その直前にある最も近い START マーカー行を探す。
+    let startIdx = -1;
+    for (let i = endIdx - 1; i >= 0; i--) {
+        if (stripped(lines[i]) === REPORT_START) {
+            startIdx = i;
+            break;
+        }
+    }
+    if (startIdx < 0)
+        return null;
+    // 間の行群を取り出し、前後の空行を trim。
+    const inner = lines.slice(startIdx + 1, endIdx);
+    while (inner.length > 0 && inner[0].trim() === '')
+        inner.shift();
+    while (inner.length > 0 && inner[inner.length - 1].trim() === '')
+        inner.pop();
+    const report = inner.join('\n').trim();
+    return report.length > 0 ? report : null;
+}
+// ───────────────────────────────────────────────────────────────────────────
+// tmux I/O（失敗は握りつぶして null/false。送らない側に倒すため）
+// ───────────────────────────────────────────────────────────────────────────
+/** tmux セッション {site} が存在するか。tmux 未インストール時も false。 */
+export function tmuxHasSession(site) {
+    try {
+        execFileSync('tmux', ['has-session', '-t', site], { stdio: 'ignore' });
+        return true;
+    }
+    catch {
+        return false;
+    }
+}
+/** capture-pane で遡るスクロールバック行数。可視画面＋この行数の履歴を取る。 */
+export const RELAY_CAPTURE_SCROLLBACK_LINES = 2000;
+/**
+ * tmux セッション {site} の画面を取得。失敗時 null。
+ *
+ * 【可視画面＋履歴を取る理由（症状A/Bの根治）】
+ *   以前は `-p` のみ＝可視画面1枚しか取らず、目印が画面外へ流れると失われた：
+ *     A) claude箱マーカー(バナー)がスクロールアウト→送信スキップ。
+ *     B) REPORT_START がスクロールアウト→報告抽出 null／DONE 取りこぼしで pending 固着。
+ *   `-S -{N}` で直近 N 行の履歴も含めて取得し、流れた目印を拾えるようにする。
+ *   末尾基準の判定（looksIdle/isIdleStable）は取得テキストの末尾 RELAY_TAIL_LINES 行だけを
+ *   slice するため、取得範囲を広げても idle 判定の挙動は不変（下端で従来どおり効く）。
+ */
+export function tmuxCapture(site) {
+    try {
+        return execFileSync('tmux', ['capture-pane', '-t', site, '-p', '-S', `-${RELAY_CAPTURE_SCROLLBACK_LINES}`], {
+            stdio: ['ignore', 'pipe', 'ignore'],
+            encoding: 'utf8',
+        });
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * tmux へ本文を1メッセージとして送り、最後に Enter を1回だけ送る。
+ *   - `--` で本文をオプション扱いさせない。
+ *   - 引数配列で渡すのでシェルのエスケープは不要（日本語・記号もリテラルで渡る）。
+ *   - 本文に生 Enter を含めない（buildSendText で改行を潰してある）。
+ * 成否を boolean で返す。
+ */
+export function sendToTmux(site, text) {
+    try {
+        execFileSync('tmux', ['send-keys', '-t', site, '--', text], { stdio: 'ignore' });
+        execFileSync('tmux', ['send-keys', '-t', site, 'Enter'], { stdio: 'ignore' });
+        return true;
+    }
+    catch {
+        return false;
+    }
+}
+/**
+ * tmux セッションへ「単一キー」を送る（Enter は付けない）。
+ *   許可プロンプトの番号選択メニューは、数字キー単押しで該当肢を即選択して進む（Enter不要）。
+ *   そのため ALLOW→"1" / DENY→"3" は send-keys でキーだけ送る。`--` も Enter も付けない。
+ *   （sendToTmux は本文＋Enter＝1メッセージ送信用。選択肢キー送信とは用途が異なるので別関数にする。）
+ * 成否を boolean で返す（失敗は握って false＝送らない側）。
+ */
+export function sendKeyToTmux(site, key) {
+    try {
+        execFileSync('tmux', ['send-keys', '-t', site, key], { stdio: 'ignore' });
+        return true;
+    }
+    catch {
+        return false;
+    }
+}
+/**
+ * 二重チェックの「アイドル」判定。
+ *   RELAY_SETTLE_MS あけて2回 capture し、両方で looksIdle が成立（❯入力待ち行あり＋
+ *   BUSY_MARKERS/スピナー不在）すれば idle とみなす。
+ *   いずれかの capture が失敗、または looksIdle 不成立なら false（送らない側）。
+ *
+ * 【設計変更】以前は末尾40行の完全一致（tailOf(cap1) === tailOf(cap2)）も要求していたが、
+ *   アイドルでも入力枠のヒント文ローテーション等で末尾が微変動すると永久に静止と見なされず、
+ *   同一指示を毎tickスキップし続ける不具合の原因だった。
+ *   「2回連続でアイドルに見える」ことで十分保守的なので、末尾全文一致は要求しない。
+ */
+export async function isIdleStable(site) {
+    const cap1 = tmuxCapture(site);
+    if (cap1 === null || !looksIdle(cap1))
+        return false;
+    await sleep(RELAY_SETTLE_MS);
+    const cap2 = tmuxCapture(site);
+    if (cap2 === null || !looksIdle(cap2))
+        return false;
+    return true;
+}
+// ───────────────────────────────────────────────────────────────────────────
+// 中央API I/O
+// ───────────────────────────────────────────────────────────────────────────
+const now = () => new Date().toLocaleTimeString();
+const log = (msg) => console.log(`[relay] ${now()} ${msg}`);
+/**
+ * 共有シークレットを Bearer で付ける認可ヘッダを組み立てる（全API共通・コピペ増殖を避ける）。
+ * 鍵はコードに書かず cfg.secret（環境変数由来）からのみ受け取る。
+ */
+function authHeaders(cfg) {
+    return { Authorization: `Bearer ${cfg.secret}` };
+}
+/**
+ * 中央の緊急停止フラグを取得。GET {url}/api/conductor/control（共有シークレット Bearer）。
+ *
+ * 【最重要・安全側のフェイルセーフ】
+ *   取得失敗（ネットワーク不通 / HTTP非2xx / 応答が不正）のときは relayHalted=true とみなす。
+ *   理由: 中央と通信できない時に勝手に送るのは危険。「通信できない＝送らない」が安全。
+ *   ok=false でその旨を呼び出し側へ伝え、ログを遷移時だけに絞れるようにする。
+ */
+export async function fetchControl(cfg) {
+    try {
+        // ?site= を付けて per-site の relayEnabled も同時に取得（ADR-038）。site 無し応答とも後方互換。
+        const url = `${cfg.url}/api/conductor/control?site=${encodeURIComponent(cfg.site)}`;
+        const res = await fetch(url, { headers: authHeaders(cfg) });
+        if (!res.ok) {
+            return { relayHalted: true, ok: false, detail: `HTTP ${res.status}` };
+        }
+        const data = await res.json().catch(() => null);
+        const halted = data?.relayHalted;
+        if (typeof halted !== 'boolean') {
+            return { relayHalted: true, ok: false, detail: '応答が不正' };
+        }
+        // per-site 子トグル。boolean ならその値、欠落/不正は undefined＝ON(稼働)フォールバック。
+        const enabledRaw = data?.relayEnabled;
+        const relayEnabled = typeof enabledRaw === 'boolean' ? enabledRaw : undefined;
+        return { relayHalted: halted, ok: true, detail: '', relayEnabled };
+    }
+    catch (err) {
+        return {
+            relayHalted: true,
+            ok: false,
+            detail: err instanceof Error ? err.message : String(err),
+        };
+    }
+}
+/**
+ * 自分宛(machine+site)の queued 指示を取得。先頭1件だけ返す（1現場同時1指示）。
+ * 空/エラー/不正は null。
+ */
+export async function fetchCommand(cfg) {
+    const u = `${cfg.url}/api/conductor/commands` +
+        `?machine=${encodeURIComponent(cfg.machine)}&site=${encodeURIComponent(cfg.site)}`;
+    try {
+        const res = await fetch(u, { headers: authHeaders(cfg) });
+        if (!res.ok) {
+            log(`site=${cfg.site} commands取得 -> HTTP ${res.status} NG`);
+            return null;
+        }
+        const data = await res.json().catch(() => null);
+        const queued = Array.isArray(data)
+            ? data
+            : data?.queued ?? [];
+        if (!Array.isArray(queued) || queued.length === 0)
+            return null;
+        const first = queued[0];
+        if (!first || first.id == null || typeof first.body !== 'string') {
+            log(`site=${cfg.site} 指示の形式が不正のためスキップ`);
+            return null;
+        }
+        return { id: String(first.id), body: first.body };
+    }
+    catch (err) {
+        log(`site=${cfg.site} commands取得 -> 失敗: ${err instanceof Error ? err.message : String(err)}`);
+        return null;
+    }
+}
+/**
+ * 指示の状態を遷移させる。PATCH /api/conductor/commands/{id} body:{status, report?}。
+ *   - report（任意）: 抜き出せた CC2 の報告本文。done遷移と一緒に送る。中央が2万字で切り詰める。
+ *     null/未指定なら report は送らず status のみ（従来どおり）。
+ *   - 409（他が sent 中などの安全弁）→ false（送らない）。
+ *   - 200 → true。
+ */
+export async function patchStatus(cfg, id, status, report) {
+    try {
+        const payload = report != null ? { status, report } : { status };
+        const res = await fetch(`${cfg.url}/api/conductor/commands/${encodeURIComponent(id)}`, {
+            method: 'PATCH',
+            headers: {
+                ...authHeaders(cfg),
+                'Content-Type': 'application/json',
+            },
+            body: JSON.stringify(payload),
+        });
+        if (res.status === 409) {
+            log(`site=${cfg.site} id=${id} ${status}遷移 -> 409 安全弁により中止`);
+            return false;
+        }
+        if (!res.ok) {
+            log(`site=${cfg.site} id=${id} ${status}遷移 -> HTTP ${res.status} NG`);
+            return false;
+        }
+        return true;
+    }
+    catch (err) {
+        log(`site=${cfg.site} id=${id} ${status}遷移 -> 失敗: ${err instanceof Error ? err.message : String(err)}`);
+        return false;
+    }
+}
+/**
+ * 指示 {id} 単体の現在 status を中央へ問う（外部完了検出の根治プローブ）。
+ *   GET /api/conductor/commands/{id}（共有シークレット Bearer）。応答 JSON から status 文字列を拾う。
+ *   - 応答形は `{ status }` / `{ command: { status } }` / 素の command オブジェクトのいずれも許容する。
+ *   - status を確定的に読めた場合のみ小文字化して返す。それ以外（非2xx・404・タイムアウト・通信失敗・
+ *     status 欠落/非文字列）はすべて null＝「中央不達 or 未知」を意味し、呼び出し側は従来経路
+ *     （detectExternalDone の副シグナル／pendingタイムアウト）へ無損失で縮退する。
+ *   - 最善努力プローブなので失敗はログを出さず握りつぶす（delivered＋アイドル毎tickで叩くため冗長ログ回避）。
+ *
+ * 【デプロイ順の安全性】このエンドポイントが中央(devlog-tracker)に未実装の間は 404/非2xx→null となり、
+ *   relay は従来どおり動く（無害・無損失）。中央側 PR が入った時点で自動的に根治が効き始める。
+ */
+export async function fetchCommandStatus(cfg, id) {
+    try {
+        const res = await fetch(`${cfg.url}/api/conductor/commands/${encodeURIComponent(id)}`, {
+            headers: authHeaders(cfg),
+            signal: AbortSignal.timeout(RELAY_STATUS_FETCH_TIMEOUT_MS),
+        });
+        if (!res.ok)
+            return null; // 404(未実装/purge済) 含め非2xx は未知＝null で縮退。
+        const data = await res.json().catch(() => null);
+        if (data === null || typeof data !== 'object')
+            return null;
+        // `{status}` / `{command:{status}}` / 素の command のいずれからも status を拾う。
+        const top = data.status;
+        const nested = data.command?.status;
+        const raw = typeof top === 'string' ? top : typeof nested === 'string' ? nested : null;
+        return raw === null ? null : raw.trim().toLowerCase();
+    }
+    catch {
+        return null; // タイムアウト/通信失敗＝未知。従来経路へ縮退（安全側）。
+    }
+}
+/**
+ * 生存ハートビートを中央へ送る（案①・調査 cmqbuch4l）。
+ *   PATCH /api/conductor/commands/{id}/seen（共有シークレット Bearer）。
+ *   中央は where{id,status:'sent'} の指示にだけ lastSeenAt=now() を刻む（終端後は無視＝冪等）。
+ *
+ * 【方針】これは「中央へ生存を知らせるだけ」の最善努力通知。失敗は致命ではないので patchStatus 同様
+ *   例外を外へ投げず、ここで握りつぶしてログのみ出す。中央不達時は lastSeenAt が更新されず、
+ *   中央側は従来どおり sentAt 基準（15分 TTL）へ無損失で縮退する（後方互換）。
+ */
+export async function sendHeartbeat(cfg, id) {
+    try {
+        const res = await fetch(`${cfg.url}/api/conductor/commands/${encodeURIComponent(id)}/seen`, {
+            method: 'PATCH',
+            headers: authHeaders(cfg),
+        });
+        if (!res.ok) {
+            log(`site=${cfg.site} id=${id} heartbeat -> HTTP ${res.status} NG（次回再試行・縮退で安全）`);
+        }
+    }
+    catch (err) {
+        log(`site=${cfg.site} id=${id} heartbeat -> 失敗: ${err instanceof Error ? err.message : String(err)}（縮退で安全）`);
+    }
+}
+/**
+ * 自分宛(machine+site)の sent孤児を取得。GET /api/conductor/commands/orphans（共有シークレット Bearer）。
+ *   - タイムアウト(RELAY_ORPHAN_FETCH_TIMEOUT_MS)を付け、devlog 到達不能でも起動がハングしない。
+ *   - 空配列/エラー/未到達/不正応答はすべて [] を返す（起動を妨げないフェイルセーフ）。
+ *   - sentAt は数値(ms)でも ISO 文字列でも受け、解釈不能なら現在時刻にフォールバック
+ *     （= 次の再送まで delay 待ちになる安全側）。
+ */
+export async function fetchOrphans(cfg) {
+    const u = `${cfg.url}/api/conductor/commands/orphans` +
+        `?machine=${encodeURIComponent(cfg.machine)}&site=${encodeURIComponent(cfg.site)}`;
+    try {
+        const res = await fetch(u, {
+            headers: authHeaders(cfg),
+            signal: AbortSignal.timeout(RELAY_ORPHAN_FETCH_TIMEOUT_MS),
+        });
+        if (!res.ok) {
+            log(`WARN site=${cfg.site} orphans取得 -> HTTP ${res.status}（起動は継続）`);
+            return [];
+        }
+        const data = await res.json().catch(() => null);
+        const arr = Array.isArray(data)
+            ? data
+            : data?.orphans ?? [];
+        if (!Array.isArray(arr))
+            return [];
+        const out = [];
+        for (const item of arr) {
+            const it = item;
+            if (!it || it.id == null || typeof it.body !== 'string')
+                continue;
+            const site = typeof it.site === 'string' ? it.site : cfg.site;
+            const sentAt = typeof it.sentAt === 'number'
+                ? it.sentAt
+                : typeof it.sentAt === 'string'
+                    ? Date.parse(it.sentAt)
+                    : NaN;
+            out.push({
+                id: String(it.id),
+                site,
+                body: it.body,
+                sentAt: Number.isFinite(sentAt) ? sentAt : Date.now(),
+            });
+        }
+        return out;
+    }
+    catch (err) {
+        // タイムアウト/ネットワーク不通も握りつぶす（起動を妨げない）。
+        log(`WARN site=${cfg.site} orphans取得 -> 失敗: ${err instanceof Error ? err.message : String(err)}（起動は継続）`);
+        return [];
+    }
+}
+/**
+ * sent孤児を pending へ復元する（2-b・起動後1回）。★ここでは送信しない＝pendingに積むだけ。
+ *   実際の再送可否は次の relayTick の decideResend（着信済みなら再送しない等の冪等ガード）に委ねる。
+ *   - 無効化(CONDUCTOR_RESTORE_ORPHANS=off)・取得空・pending占有中は何もしない。
+ *   - フェイルセーフ: fetchOrphans が [] を返すケースは静かに通常起動を続ける。
+ */
+export async function restoreOrphans(cfg, state) {
+    if (!RELAY_RESTORE_ORPHANS_ENABLED)
+        return;
+    const orphans = await fetchOrphans(cfg);
+    const pick = selectOrphanToRestore(orphans, state.pending);
+    if (pick === null) {
+        if (orphans.length > 0) {
+            log(`site=${cfg.site} orphan復元: pending占有中につきスキップ（孤児${orphans.length}件は次プロセスへ）`);
+        }
+        return;
+    }
+    state.pending = orphanToPending(pick);
+    log(`site=${cfg.site} id=${pick.id} を sent孤児から pending へ復元（★送信せず・次tickで2-a判定）`);
+}
+// ───────────────────────────────────────────────────────────────────────────
+// relay 本体（1ポーリング分）
+// ───────────────────────────────────────────────────────────────────────────
+/**
+ * relay の1tick。CONDUCTOR_RELAY_INTERVAL_SEC ごとに呼ばれる想定。
+ *
+ * 流れ:
+ *   - pending(送信済みDONE待ち)があれば、完了マーカー検出だけ行う
+ *     （sent 中はサーバも新規指示を返さないので取得しない）。停止中でも継続する
+ *     （既に送った指示の後始末は進める）。
+ *   - 緊急停止フラグを確認。停止中なら新規の取得・送信は一切しない。
+ *   - pending が無く停止中でもなければ、取得 → アイドル判定 → sent遷移 → 送信。
+ *
+ * すべての判定は保守的（少しでも怪しければ送らない／次回再挑戦）。
+ */
+export async function relayTick(cfg, state) {
+    if (state.running)
+        return; // 前回の tick が走行中ならスキップ
+    state.running = true;
+    try {
+        // ── sent孤児の復元(2-b・起動後1回) ──
+        // cli.ts を触らず「起動時1回」を実現するため、最初の tick でだけ復元する。
+        // 失敗しても再試行しない（フラグを先に立てる＝起動を妨げない／多重実行防止）。
+        // ★復元は pending に積むだけ。再送可否は下の pending 分岐 = decideResend に一元化する。
+        if (!state.restored) {
+            state.restored = true;
+            await restoreOrphans(cfg, state);
+        }
+        // ── 完了マーカー検出（pending があれば最優先・停止中でも継続） ──
+        if (state.pending) {
+            const cap = tmuxCapture(cfg.site);
+            if (cap === null)
+                return; // tmux未取得: 次回再確認
+            // ── 着信確認 → 初めて sent 化（不具合B 根治・案: アンカー可視を確認してから sent） ──
+            // 初回 send-keys 成功だけでは「送ったが職人画面に入っていない」(起動順レース/モーダル等)が
+            // あり得るため、サーバ status は送信直後ではなく「アンカー(CONDUCTOR_JOB:{id})が画面に
+            // エコーされた＝確かに着信した」を確認してから 'sent' にする。それまでは queued 据置＝
+            // 管制で「送信済」と誤表示しない。delivered になるまでは下の自動再送が（未着信＋アイドル時に）
+            // 配信を担保する。DONE:{site} はアンカーより下に出る＝着信確認はDONE検出より必ず先に成立する。
+            if (!state.pending.delivered && cap.includes(state.pending.anchor)) {
+                if (await patchStatus(cfg, state.pending.id, 'sent')) {
+                    state.pending.delivered = true;
+                    // DONE 待ちの上限時間は「着信＝作業開始」時点から数え直す（送信〜着信の遅延で
+                    // 早期に pending タイムアウトしないように）。再送間隔基準の lastSentAt は触らない。
+                    state.pending.sentAt = Date.now();
+                    state.lastHeartbeatAt = null;
+                    log(`site=${cfg.site} id=${state.pending.id} 着信確認 → sent`);
+                }
+                // patchStatus 失敗時は delivered=false のまま（次tick再確認）。queued 据置で安全側。
+            }
+            // アンカー（今回送信の境界）より下だけを見て DONE:{site} 単独行を探す。
+            // churn で古い DONE が押し出されても・過去ジョブの DONE が窓に残っても、誤検出/見逃しなし。
+            const below = sliceBelowAnchor(cap, state.pending.anchor);
+            if (below !== null && hasStandaloneDone(below, cfg.site)) {
+                // 報告本文も「アンカーより下」から抜き出す（今回ジョブの報告に限定。過去報告の誤添付を防ぐ）。
+                const report = extractReport(below);
+                const ok = await patchStatus(cfg, state.pending.id, 'done', report);
+                if (ok) {
+                    log(`site=${cfg.site} id=${state.pending.id} done${report != null ? '（報告添付）' : ''}`);
+                    state.pending = null;
+                }
+                return; // sent 中は新規取得しない
+            }
+            // ── 外部完了の検出（中央が真実・conductor_complete 等でdone化された案件の追跡解除・根治） ──
+            // 職人が devlog MCP の conductor_complete で中央を直接done化すると、画面に DONE:{site} 行が
+            // 出ないため上の画面スクレイプでは完了を永遠に検知できない（2026-07-04 実地バグ）。
+            //
+            // 【根治の核＝完了の真実は中央にある】pending.id 単体の status を中央へ直接問い(fetchCommandStatus)、
+            //   done/failed 等の終端なら「次の queued の有無に関係なく」追跡解除する。これが真の根治：
+            //   旧 detectExternalDone は「別の次指示が queued にある」ときしか救えず、キューが空だと
+            //   conductor_complete 済みでも 15分固着していた（実地: 完了の約8割が pendingタイムアウト固着）。
+            // 【副シグナル温存＝無損失縮退】中央 status が読めない(null＝エンドポイント未実装/不達)ときだけ、
+            //   従来の detectExternalDone（別idが配れる＝終端の確証）へフォールバックする。中央側 status API が
+            //   入るまではこの副シグナルが従来どおり効き、入った後は主シグナル(status)が確実に固着を断つ。
+            // HTTP コストを抑えるため delivered＋アイドルのときだけ probe する（busyな通常作業中は叩かない）。
+            const idle = looksIdle(cap);
+            if (state.pending.delivered && idle) {
+                const centralStatus = await fetchCommandStatus(cfg, state.pending.id);
+                if (isTerminalCommandStatus(centralStatus)) {
+                    log(`site=${cfg.site} id=${state.pending.id} は中央で終端(status=${centralStatus})を確認` +
+                        '（外部完了検出・キュー有無に依らず）→ 追跡解除し次tickで新規取得');
+                    state.pending = null;
+                    state.lastHeartbeatAt = null; // 次指示の生存HBは先頭から数え直す（前指示のスロットル引継ぎ防止）。
+                    return; // 次tickで halt確認→fetchCommand→アイドル判定→送信の通常経路を通す。
+                }
+                // 中央 status が未知(null)のときのみ、従来の副シグナル（別idが配信可能＝終端の確証）で救う。
+                //   中央が sent/queued 等の「生存中」を明示的に返した場合は解除しない（中央の真実を尊重）。
+                if (centralStatus === null) {
+                    const next = await fetchCommand(cfg);
+                    const nextId = next?.id ?? null;
+                    if (detectExternalDone({
+                        delivered: state.pending.delivered,
+                        pendingId: state.pending.id,
+                        idle,
+                        nextCommandId: nextId,
+                    })) {
+                        log(`site=${cfg.site} id=${state.pending.id} は中央で終端済み（外部完了検出：` +
+                            `次指示 id=${nextId} が配信可能・status API不達時の副シグナル）→ 追跡解除し次tickで新規取得`);
+                        state.pending = null;
+                        state.lastHeartbeatAt = null;
+                        return; // 次tickで halt確認→fetchCommand→アイドル判定→送信の通常経路を通す。
+                    }
+                }
+            }
+            // ── 生存ハートビート(案①・調査 cmqbuch4l) ──
+            // 職人が確実に busy（esc to interrupt 等）なら「まだ作業中」を中央へ通知し lastSeenAt を更新する。
+            // 中央はこれを生存基準（COALESCE(lastSeenAt,sentAt)>cutoff）に使い、長時間作業中の sent を
+            // 15分 TTL で誤って failed 化しない。毎tick送らず RELAY_HEARTBEAT_INTERVAL_MS でスロットルする。
+            // 送信失敗は握りつぶし（sendHeartbeat 内でログのみ）→中央不達時は従来 sentAt 基準へ無損失縮退。
+            if (hasBusySignal(cap)) {
+                const nowMs = Date.now();
+                if (state.lastHeartbeatAt === null ||
+                    nowMs - state.lastHeartbeatAt >= RELAY_HEARTBEAT_INTERVAL_MS) {
+                    state.lastHeartbeatAt = nowMs;
+                    await sendHeartbeat(cfg, state.pending.id);
+                }
+            }
+            // ── 生存中の自動再送(2-a)。DONE 未達のとき、未着信＋アイドルなら同一指示を再送する ──
+            // 冪等性最優先: 着信判定(anchor可視)は cap から即わかる。アイドルの二重チェック
+            // (isIdleStable=1.5s sleep) は「未着信」のときだけ実行し、着信済みの通常経路では待たない。
+            // 判定そのものは純粋関数 decideResend に委譲（着信済み/busy/非アイドル/間隔を一括で結論）。
+            // 上限到達後は打ち切らず slow相 で低頻度に再配信を継続する（起動順レース根治）。
+            //
+            // ★delivered 永続ガード（不具合A・再送ループ根治）: 一度「着信確認 → sent」で delivered=true に
+            //   なった指示は、以後ライブ画面で anchor が churn により窓(capture-pane の可視＋scrollback)から
+            //   押し出されて見えなくなっても、二度と自動再送しない。従来は decideResend(1) と呼出側の
+            //   delivered をいずれも「その場の cap.includes(anchor)」で毎tick再導出していたため、確定済みの
+            //   着信が undelivered へ逆戻りして再送ループ化していた（職人へ同一 commandId が連続着信し、
+            //   既に done でも送り続ける）。着信確認済みは永続フラグを唯一の真とし、完了検出は上の DONE
+            //   スクレイプ、固着回避は下の pending タイムアウトに委ねる。
+            //   delivered=false の間（初回着信前・起動順レース）は従来どおり未着信＋アイドルで再送して配信を担保する。
+            if (!state.pending.delivered) {
+                const delivered = cap.includes(state.pending.anchor);
+                const idleStable = delivered ? false : await isIdleStable(cfg.site);
+                const decision = decideResend({
+                    capture: cap,
+                    anchor: state.pending.anchor,
+                    idleStable,
+                    sentAt: state.pending.sentAt,
+                    lastSentAt: state.pending.lastSentAt,
+                    resendCount: state.pending.resendCount,
+                    now: Date.now(),
+                    policy: {
+                        resendDelayMs: RELAY_RESEND_DELAY_MS,
+                        resendIntervalMs: RELAY_RESEND_INTERVAL_MS,
+                        maxResend: RELAY_RESEND_MAX,
+                        resendSlowIntervalMs: RELAY_RESEND_SLOW_INTERVAL_MS,
+                    },
+                });
+                if (decision.verdict === 'resend') {
+                    // ── 配達回数の絶対上限（保険・無限ループの構造的封じ込め） ──
+                    // slow相は打ち切らず継続する設計＋pendingタイムアウト後の再取得で、職人窓が永久に
+                    // 未着信/未DONEだと事実上無限に再配達し得る。累計が上限を超えたらこの command を放棄し
+                    // 二度と配達しない（pendingを解除し abandoned へ。完了は職人の conductor_complete か
+                    // 画面DONE検出という別経路に委ねる）。
+                    if (!canDeliver(state, state.pending.id)) {
+                        if (!state.abandoned.has(state.pending.id)) {
+                            state.abandoned.add(state.pending.id);
+                            log(`WARN site=${cfg.site} id=${state.pending.id} 配達回数が上限(${RELAY_DELIVER_MAX})に到達。` +
+                                '再配達を放棄し pending を解除（無限ループの構造的封じ込め。' +
+                                '完了通知は職人の conductor_complete か画面DONE検出に委ねる）');
+                        }
+                        state.pending = null;
+                        return;
+                    }
+                    // 送信直前ガード（looksLikeClaude）も初回送信と同様に尊重し、非claude窓への誤爆を防ぐ。
+                    const guardCap = tmuxCapture(cfg.site);
+                    if (guardCap === null || !looksLikeClaude(guardCap)) {
+                        log(`WARN site=${cfg.site} id=${state.pending.id} 再送直前にClaude Codeの箱を` +
+                            '確認できず再送中止（次tick再判定）');
+                        return;
+                    }
+                    // fast相 / slow相 の別（このtickの送信が低頻度再配信フェーズか）。回数++前に判定する。
+                    const slow = state.pending.resendCount >= RELAY_RESEND_MAX;
+                    // id 不変＝anchor 不変なので、初回と同一の送信テキストを再生成する。
+                    const text = buildSendText(state.pending.body, cfg.site, state.pending.anchor);
+                    if (!sendToTmux(cfg.site, text)) {
+                        log(`再送 send-keys failed, keep pending: ${cfg.site}/${state.pending.id}`);
+                        return;
+                    }
+                    state.pending.resendCount += 1;
+                    state.pending.lastSentAt = Date.now();
+                    // 累計配達回数を通算（pending 入れ替えをまたいで id 単位に数える＝絶対上限の基準）。
+                    markDelivered(state, state.pending.id);
+                    // fast相→slow相への移行ログは一度だけ（多重ログ防止）。打ち切りはせず低頻度で継続する旨を記す。
+                    if (slow && !state.pending.resendExhaustedWarned) {
+                        state.pending.resendExhaustedWarned = true;
+                        log(`site=${cfg.site} id=${state.pending.id} fast再送上限(${RELAY_RESEND_MAX})到達。` +
+                            `以後は ${Math.round(RELAY_RESEND_SLOW_INTERVAL_MS / 1000)}s 間隔で低頻度に再配信を継続` +
+                            '（職人が後から起動しても届くようにする・打ち切りは pending タイムアウトに委ねる）');
+                    }
+                    log(`site=${cfg.site} id=${state.pending.id} 自動再送 #${state.pending.resendCount}` +
+                        `（${slow ? '低頻度(slow)' : '未着信＋アイドル'}: ${decision.reason}）`);
+                    return; // sent 中は新規取得しない
+                }
+                // 'wait' は再送せずタイムアウト判定へ進む（decideResend は 'stop' を返さない＝低頻度継続）。
+            }
+            // DONE 未達のまま上限時間を超えたら、固着回避のため relay 内部で pending を解除して次へ進む。
+            // （CC2 の異常終了等で DONE が永遠に来ないケースの根治。サーバ status は戻さない＝relay内部のみ。）
+            const elapsedMs = Date.now() - state.pending.sentAt;
+            if (elapsedMs > RELAY_PENDING_TIMEOUT_MS) {
+                log(`WARN site=${cfg.site} id=${state.pending.id} が pending タイムアウト` +
+                    `(${Math.round(elapsedMs / 1000)}s)。DONE未達のため解除し次へ進む`);
+                state.pending = null;
+            }
+            return; // sent 中は新規取得しない
+        }
+        // ── 停止フラグ確認（新規の取得・送信のみ止める） ──
+        // 停止条件は3つ: ①通信不能（安全側）②グローバル緊急停止 relayHalted（後方互換）
+        //   ③この現場の子トグル relayEnabled=false（ADR-038）。relayEnabled が undefined（未取得）は
+        //   ON(稼働)扱いでフォールバックする（停止しない）。ログは状態が変わった時だけ出す。
+        const ctl = await fetchControl(cfg);
+        const haltedBySite = ctl.relayEnabled === false;
+        if (ctl.relayHalted || haltedBySite) {
+            if (state.lastHalted !== true) {
+                log(!ctl.ok
+                    ? `中央と通信できないため安全側で送信を停止します（${ctl.detail}）`
+                    : haltedBySite
+                        ? `この現場(${cfg.site})の relay送信トグルがOFF(停止)のため送信しません`
+                        : 'relay停止中(緊急停止スイッチON)のため送信しません');
+            }
+            state.lastHalted = true;
+            return;
+        }
+        if (state.lastHalted === true) {
+            log('停止が解除されました。relayを再開します');
+        }
+        state.lastHalted = false;
+        // ── 新規指示の取得 ──
+        const cmd = await fetchCommand(cfg);
+        if (!cmd)
+            return; // 指示なし
+        // ── 配達放棄ガード（無限ループの構造的封じ込め） ──
+        // 配達回数上限を超えて放棄した command は、サーバがまだ queued を返しても（＝完了通知が
+        // 単線で切れて詰まった状態でも）二度と配達しない。放棄時に既にWARNを出しているので静かにスキップ。
+        if (state.abandoned.has(cmd.id)) {
+            return;
+        }
+        // ── アイドル判定（保守的・二重チェック） ──
+        if (!tmuxHasSession(cfg.site)) {
+            log(`site=${cfg.site} id=${cmd.id} tmux未起動のため送らずスキップ`);
+            return;
+        }
+        if (!(await isIdleStable(cfg.site))) {
+            // 連続スキップ回数を可観測化（観測のみ・送信挙動は変えない）。
+            // 別idに変わっていたら連続をリセットしてから数え直す。
+            if (state.lastSkippedId !== cmd.id) {
+                state.lastSkippedId = cmd.id;
+                state.skipCount = 0;
+                state.skipWarned = false;
+            }
+            state.skipCount += 1;
+            log(`site=${cfg.site} id=${cmd.id} 作業中の可能性ありスキップ（次回再判定）`);
+            if (state.skipCount > RELAY_SKIP_WARN_THRESHOLD && !state.skipWarned) {
+                state.skipWarned = true;
+                log(`WARN site=${cfg.site} id=${cmd.id} が${state.skipCount}回連続スキップ。` +
+                    `アイドル誤判定の疑い`);
+            }
+            return;
+        }
+        // ここまで来たらアイドル判定が通った＝この id の連続スキップは解消。
+        state.lastSkippedId = null;
+        state.skipCount = 0;
+        state.skipWarned = false;
+        // ── 内容ベースのガード（送信直前・最終確認） ──
+        // 名前一致＋❯プロンプトだけでは fish/starship 等 ❯ を使う非claude窓に誤爆し得るため、
+        // 送信直前に capture し直し、Claude Code 固有マーカーが確認できる時だけ送る。
+        // 確認できなければ sent 遷移もせずスキップ＋WARN（サーバ status は queued のまま温存）。
+        const guardCap = tmuxCapture(cfg.site);
+        if (guardCap === null || !looksLikeClaude(guardCap)) {
+            log(`WARN site=${cfg.site} id=${cmd.id} Claude Codeの箱と確認できないため送信せずスキップ` +
+                '（名前一致でも非claude窓への誤爆を防止）');
+            return;
+        }
+        // ── tmux 送信 ──
+        // この送信に固有のアンカー（buildAnchor(id)）を本文末尾に埋め込む。
+        //   画面にエコーされたアンカー行を「今回ジョブの境界」として記録し、完了検出は
+        //   アンカーより下＝今回ジョブの出力だけを見る（churn・過去ジョブ DONE に強い）。
+        const anchor = buildAnchor(cmd.id);
+        const text = buildSendText(cmd.body, cfg.site, anchor);
+        if (!sendToTmux(cfg.site, text)) {
+            // 送信失敗（sendToTmux は内部で例外も握って false を返す）。status は queued のまま据え置く。
+            log(`send-keys failed, keep queued: ${cfg.site}/${cmd.id}`);
+            return;
+        }
+        // 送信成功 → pending を立てて DONE を待つ。★ただし sent 化はここではしない（不具合B 根治）。
+        //   send-keys 成功＝tmuxへキー送出に成功、だけでは「職人画面に本文が入った」保証にならない
+        //   （起動順レースで relay が職人より先に走り旧/未準備セッションへ送る等）。そのため status は
+        //   queued 据置のまま delivered=false で開始し、次tick以降にアンカーが画面へエコーされた＝
+        //   確かに着信した、を確認してから patchStatus('sent') する（上の delivered 分岐）。
+        //   着信するまでは decideResend が（未着信＋アイドル時に）fast→slow で再配信を継続する。
+        const sentAt = Date.now();
+        state.pending = {
+            id: cmd.id,
+            site: cfg.site,
+            sentAt,
+            anchor,
+            body: cmd.body,
+            resendCount: 0,
+            lastSentAt: sentAt,
+            resendExhaustedWarned: false,
+            delivered: false,
+        };
+        // 累計配達回数を通算（初回送信も1件として数える＝絶対上限 RELAY_DELIVER_MAX の基準）。
+        markDelivered(state, cmd.id);
+        // 新しい指示の生存ハートビートは先頭から数え直す（前指示のスロットルを引き継がない）。
+        state.lastHeartbeatAt = null;
+        log(`site=${cfg.site} id=${cmd.id} 送信（着信確認待ち・queued据置）`);
+    }
+    finally {
+        state.running = false;
+    }
+}