@tyhld/conductor 0.8.0 → 0.9.0

package/dist/relay.js

@@ -15,7 +15,7 @@
  * 【役割（段3で「配達係」に絞った）】
  *   relay がするのは「指示を職人へ届け、終わったことを中央へ書き戻す」ことだけ。
  *     ① 指示の取得 ② 本文の投入 ③ アイドル判定 ④ Claude箱の確認 ⑤ tmux在否
- *     ⑦⑧ 完了検出 ⑪ 生存報告 ⑰〜㉑ 再送・中央照合・孤児復元 ㉒ 緊急停止・現場トグル ㉓ 適応ポーリング
+ *     ⑦⑧ 完了検出 ⑪ 生存報告 ⑲〜㉑ 中央照合・孤児復元 ㉒ 緊急停止・現場トグル ㉓ 適応ポーリング
  *   ★職人の画面から「質問の中身」を読んで意味を解釈すること、職人の端末でキーを押すことはしない。
  *     許可の確認と応答は PermissionRequest フック（scripts/hooks/permission_request_hook.py）が
  *     データ経路（POST /api/conductor/hook-requests）で担う。画面スクレイプに依存しない。
@@ -48,7 +48,7 @@ export const RELAY_PENDING_TIMEOUT_MS = (() => {
     const parsed = Number(raw);
     return Number.isFinite(parsed) && parsed > 0 ? parsed : def;
 })();
-/** 環境変数を正の数として読む（空/不正は既定へフォールバック）。再送ポリシーの定数で使う。 */
+/** 環境変数を正の数として読む（空/不正は既定へフォールバック）。各種の時間・回数の定数で使う。 */
 function envPositiveNumber(name, def) {
     const raw = (process.env[name] ?? '').trim();
     if (raw === '')
@@ -110,37 +110,17 @@ export function clampToCentralHold(ms) {
  *   環境変数 RELAY_KEEPALIVE_MAX_MS で上書き可（正の数のみ・★中央の上限までに切り詰める）。
  */
 export const RELAY_KEEPALIVE_MAX_MS = clampToCentralHold(envPositiveNumber('RELAY_KEEPALIVE_MAX_MS', CENTRAL_BUSY_HOLD_MAX_MS));
-/**
- * 自動再送(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 単位に通算する。
+ *   プロセス内で id 単位に通算する。
  *
- * 【なぜ必要か】RELAY_RESEND_MAX は fast相→slow相の“間隔”を切り替えるだけで、slow相は打ち切らず
- *   低頻度に再配信を継続する設計（起動順レース根治）。そのため職人窓が永久に未着信/未DONEのとき、
- *   「slow再送 → pending タイムアウト(15分)で解除 → fetchCommand が同じ queued を再取得 → 再び pending →
- *   slow再送 …」のサイクルが（resendCount がその都度0にリセットされるため）事実上無限に続く穴が残る。
- *   この上限を超えた command はプロセス内で「配達放棄(abandoned)」とし、二度と配達しない（WARNログを残す）。
+ * 【★ADR-023 以後の位置づけ】配達は「1指示につき1回だけ」になった（自動再送は撤去）。
+ *   それでも上限を残すのは、中央が同じ id を queued へ戻す運用（人が差し戻す・中央側の不具合）が
+ *   あり得るため。ここを超えた command はプロセス内で「配達放棄(abandoned)」とし二度と配達しない。
  *
  * 【スコープ】プロセス再起動でカウンタ/放棄集合はリセットされる（サーバAPIは変更しない方針のため永続化しない）。
- *   これは許容範囲: DONE 到達済みの command はそもそもサーバが queued を返さない＝再取得されない。
- *   本上限は「完了通知が単線で切れて詰まった」異常時に無限ループを構造的に不可能化するための保険。
- *   環境変数 RELAY_DELIVER_MAX で上書き可（正の数のみ）。既定20（初回1＋再送19相当）。
+ *   これは許容範囲: 配達直後に中央が sent になる＝サーバが同じ指示を queued として返さない。
+ *   環境変数 RELAY_DELIVER_MAX で上書き可（正の数のみ）。既定20。
  */
 export const RELAY_DELIVER_MAX = envPositiveNumber('RELAY_DELIVER_MAX', 20);
 /**
@@ -222,7 +202,7 @@ export function createRelayState() {
     };
 }
 /**
- * この command を（初回/再送問わず）まだ配達してよいか。純粋関数（I/Oなし＝単体テスト可能）。
+ * この command をまだ配達してよいか。純粋関数（I/Oなし＝単体テスト可能）。
  *   - 既に放棄済み(abandoned) → false。
  *   - 累計配達回数が RELAY_DELIVER_MAX 以上 → false（もう配達しない＝無限ループ防止の絶対上限）。
  */
@@ -231,7 +211,7 @@ export function canDeliver(state, id) {
         return false;
     return (state.deliverCounts.get(id) ?? 0) < RELAY_DELIVER_MAX;
 }
-/** 配達成功を1件記録して累計を返す（初回送信・再送の両方の成功時に呼ぶ）。 */
+/** 配達成功を1件記録して累計を返す（tmux への投入に成功したときに呼ぶ）。 */
 export function markDelivered(state, id) {
     const n = (state.deliverCounts.get(id) ?? 0) + 1;
     state.deliverCounts.set(id, n);
@@ -291,7 +271,7 @@ export function busyScanRegion(text) {
  *   - 走査対象は busyScanRegion＝入力枠フッター領域だけ（最後の横罫線より下）。トランスクリプト
  *     本文の busy 相当語で永久 busy 誤判定にならないための恒久修正。判別軸は v2.x 常時描画のフッター
  *     行（'esc to interrupt' を含む→busy / '? for shortcuts' を含む→idle）。
- *   - busy 判定を looksIdle から切り出して再利用可能にしたもの（自動再送の可否判定でも使う）。
+ *   - busy 判定を looksIdle から切り出して再利用可能にしたもの（生存通知の判定でも使う）。
  *   - looksIdle はこれが true なら即アイドル不成立に倒す。
  */
 export function hasBusySignal(text) {
@@ -368,7 +348,7 @@ export function looksIdle(text) {
         return false;
     // 選択メニュー表示中はアイドルとみなさない（落とし穴ガード・★撤去してはいけない要）。
     //   Claude Code の確認メニュー("❯ 1. Yes" 等)も `❯` で始まる行を含むため、下の hasPrompt が
-    //   true になりアイドル誤判定し得る。メニュー表示中に relay の pending ループが新規指示や再送を
+    //   true になりアイドル誤判定し得る。メニュー表示中に relay の pending ループが新規指示を
     //   流し込むと、選択メニューに指示文が打ち込まれて混線する（＝作業への割り込み事故）。
     //   ★段3で「質問の中身を読む処理」は全部撤去したが、この真偽ガードだけは残す（残す理由は
     //     hasChoiceMenu のコメント参照）。答えるのはフック経路の役目で、relay は一切押さない。
@@ -658,15 +638,18 @@ export function buildAnchor(id) {
  * 【なぜアンカーを求めていたのか】前の指示の DONE 行や報告を、今の指示のものと取り違えないため。
  *
  * 【根治】アンカーが見えないときも安全に全画面を見てよい条件がある:
- *   ★**アンカーが「一度見えた(delivered)」あとに「見えなくなった」なら、
+ *   ★**アンカーが「一度見えた」あとに「見えなくなった」なら、
  *     アンカーより上にあった前の指示の出力は、アンカーより先に画面から消えている。**
  *   画面は上から順に流れて出ていくので、アンカーが消えた時点で、その上にあった
  *   前の指示の DONE 行も必ず消えている。だから取り違えは構造的に起こらない。
  *
  * 返り:
  *   - アンカーが見える  → アンカーより下（従来どおり・いちばん厳しい）
- *   - アンカーが見えない かつ delivered → 画面全体（上記の理由で安全）
- *   - アンカーを一度も見ていない → null（まだ届いていない＝見に行かない）
+ *   - アンカーが見えない かつ wide → 画面全体（上記の理由で安全）
+ *   - それ以外（アンカーを一度も見ていない）→ null（見に行かない）
+ *
+ * ★第3引数は「画面をどこまで見てよいか」だけを表す（PendingEntry.screenDoneWide）。
+ *   ★配達したか・中央へ印を書いたかとは別物（混ぜていたのが ADR-023 の穴）。
  */
 // ───────────────────────────────────────────────────────────────────────────
 // Codex の完了・報告を受け取る口（★ADR-021）
@@ -728,11 +711,11 @@ export function takeCodexNotice(site, env = process.env) {
     }
     return latest;
 }
-export function sliceForDoneScan(text, anchor, delivered) {
+export function sliceForDoneScan(text, anchor, wide) {
     const below = sliceBelowAnchor(text, anchor);
     if (below !== null)
         return below;
-    return delivered ? text : null;
+    return wide ? text : null;
 }
 export function sliceBelowAnchor(text, anchor) {
     const lines = text.replace(/\r/g, '').split('\n');
@@ -768,61 +751,6 @@ export function hasDoneBelowAnchor(text, site, anchor) {
         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 追跡を解除すべきかを判定する純粋関数。
  *
@@ -835,13 +763,13 @@ export function decideResend(args) {
  * 【判定の根拠＝根治方針「完了の真実は中央にある」への寄せ】
  *   中央は「1現場同時1指示」で、ある指示が sent の間は新規 queued を返さない（fetchCommand=null）。
  *   したがって次の条件が揃えば pending.id は中央で既に終端した確証になる:
- *     - delivered（着信確認済み＝relay が status を 'sent' に遷移済み）で、
+ *     - sentMarked（中央へ「配達済み(sent)」を書けている＝中央はこの指示を queued として返さない）で、
  *     - 職人画面がアイドル（looksIdle＝処理中でも許可プロンプトでもない・入力待ち）で、
  *     - fetchCommand が pending.id とは別の id の指示を返した（＝中央がもう次を配れる状態）。
  *   このとき追跡を解除して次tickで新規指示を素直に取りに行けば、外部done化でも詰まらない。
  *
  * 【安全側（false=解除しない）に倒すケース】いずれも従来の画面DONE検出／pendingタイムアウトへ無損失縮退:
- *   - delivered 前（まだ queued 据置・着信未確認）: 次のqueuedはpending自身なので誤検出しない。
+ *   - sentMarked 前（中央はまだ queued 扱い）: 次のqueuedはpending自身なので誤検出しない。
  *   - 非アイドル（busy/許可プロンプト等）: まだ職人が動作中の可能性 → 解除しない。
  *   - 中央不達 or 次指示なし（nextCommandId=null）。
  *   - 次指示が pending と同id（通常は起こらないが、念のため同一なら解除しない）。
@@ -849,8 +777,8 @@ export function decideResend(args) {
  * I/O を持たない純粋関数（fetchCommand の結果 id と画面アイドル判定を引数で受ける）＝単体テスト可能。
  */
 export function detectExternalDone(args) {
-    if (!args.delivered)
-        return false; // 着信未確認＝中央はまだ queued。次のqueuedはpending自身。
+    if (!args.sentMarked)
+        return false; // 印が未記録＝中央はまだ queued。次のqueuedはpending自身。
     if (!args.idle)
         return false; // 職人が動作中/許可待ちの可能性 → 解除しない（保守的）。
     if (args.nextCommandId === null)
@@ -875,12 +803,6 @@ export function isTerminalCommandStatus(status) {
     const s = status.trim().toLowerCase();
     return s === 'done' || s === 'failed' || s === 'cancelled' || s === 'canceled' || s === 'abandoned';
 }
-/**
- * 中央が「まだ配達してよい＝生きている」と明示した status（これらだけ再送を許す）。
- *   queued=未配達 / sent=配達済み作業中 / stalled=無音だが未終端 / perm_wait=承認待ち / held=保留。
- *   held は「中央がまだ流す判断をしていない」＝再送してよい状態ではないので skip 側に置く。
- */
-const CENTRAL_LIVE_STATUSES = new Set(['queued', 'sent', 'stalled', 'perm_wait']);
 /**
  * 中央で dismissed/timeout も終端。isTerminalCommandStatus（既存・変更しない）は done/failed/
  * cancelled/canceled/abandoned のみを見るので、再配達の可否ではこの2つを足して判断する。
@@ -893,7 +815,7 @@ const CENTRAL_EXTRA_TERMINAL_STATUSES = new Set(['dismissed', 'timeout']);
  *   done / failed / cancelled / canceled / abandoned / dismissed / timeout のいずれか。
  *   null（中央不達・未知）や未知の綴りは false ＝「終わっているとは言えない」に倒す（保守的）。
  *
- * ★再配達の可否（decideCentralReconcile）と、生存の見張りを畳む判断（keepalive）で
+ * ★「配達済みの印(sent)を書き続けてよいか」と、生存の見張りを畳む判断（keepalive）で
  *   同じ物差しを使うためにここへ切り出した。判定が2か所に分かれて食い違うのを防ぐ。
  */
 export function isCentralFinished(status) {
@@ -903,41 +825,12 @@ export function isCentralFinished(status) {
     return isTerminalCommandStatus(s) || CENTRAL_EXTRA_TERMINAL_STATUSES.has(s);
 }
 /**
- * 「今から同一指示を再送しようとしている」tick で、中央 status と照合して最終判断する純粋関数。
- *
- * 【なぜ必要か】完了通知が conductor_complete（MCP直行）で立つと中央は done になるが、relay が画面の
- *   DONE 行を取りこぼすとローカル pending が残る。従来この再送経路(!delivered)は中央を一度も見ずに
- *   同一指示を送り続けていた（既存の中央照合は delivered＋アイドルの分岐にしか無く、!delivered な
- *   再送経路とは条件が排他だった）。ここで照合を挟むことで done 済みの再配達を構造的に断つ。
- *
- * 結論:
- *   - 'drop'   終端(done/failed/cancelled/canceled/abandoned/dismissed/timeout)。再送せず pending を
- *              解放し abandoned へ入れる（以後二度と配達しない）。
- *   - 'resend' 中央が生存(queued/sent/stalled/perm_wait)と明示。従来どおり再送してよい。
- *   - 'skip'   null（中央不達・404・タイムアウト＝未知）、または未知の綴り。このtickは何もせず次tickで
- *              再試行する。曖昧なら送らない安全側に倒す（誤再配達より遅延のほうが安い）。
- *
- * 【縮退の注意】中央に GET /api/conductor/commands/{id} が無い環境では常に null→'skip' となり自動再送は
- *   起きない。固着は従来どおり pending タイムアウト(RELAY_PENDING_TIMEOUT_MS)が解除する。
- */
-export function decideCentralReconcile(centralStatus) {
-    if (centralStatus === null)
-        return 'skip'; // 未知＝照合できず。送らない安全側。
-    if (isCentralFinished(centralStatus))
-        return 'drop';
-    const s = centralStatus.trim().toLowerCase();
-    if (CENTRAL_LIVE_STATUSES.has(s))
-        return 'resend';
-    return 'skip'; // 未知の綴り（将来の新status・held 等）は送らない安全側。
-}
-/**
- * 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 待ち/再送のみを担う。
+ * sent孤児を pending 構造へ変換する純粋関数（★送信はしない）。
+ *   - anchor は buildAnchor(id) で再生成（id 不変＝アンカー不変）＝完了検出の境界が復元前と揃う。
+ *   - delivered=true / sentMarked=true: 孤児は中央 status=sent＝既に配達され、印も付いている段階。
+ *     復元後の役目は「DONE を待つ／生存を伝える」だけで、★配達は二度としない。
+ *   - screenDoneWide=true: 孤児は送信から TTL 超＝前の指示の出力はとうに画面から流れている。
+ *     アンカーが見えなくても全画面から DONE を拾ってよい（ADR-020 と同じ根拠・従来と同じ挙動）。
  */
 export function orphanToPending(orphan) {
     return {
@@ -946,10 +839,9 @@ export function orphanToPending(orphan) {
         sentAt: orphan.sentAt,
         anchor: buildAnchor(orphan.id),
         body: orphan.body,
-        resendCount: 0,
-        lastSentAt: orphan.sentAt,
-        resendExhaustedWarned: false,
         delivered: true,
+        sentMarked: true,
+        screenDoneWide: true,
     };
 }
 /**
@@ -984,7 +876,7 @@ export function selectOrphanToRestore(orphans, currentPending) {
 export function buildSendText(body, site, anchor) {
     const marker = `DONE:${site}`;
     // anchor から素の commandId を取り出す（conductor_complete に渡す引数。接頭辞無しなので新たな
-    // アンカー一致を作らず、sliceBelowAnchor/decideResend の境界判定に干渉しない）。
+    // アンカー一致を作らず、sliceBelowAnchor の境界判定に干渉しない）。
     const commandId = anchor.startsWith(`${SEND_ANCHOR_PREFIX}:`)
         ? anchor.slice(SEND_ANCHOR_PREFIX.length + 1)
         : anchor;
@@ -1363,7 +1255,7 @@ export async function patchStatus(cfg, id, status, report) {
  *   - status を確定的に読めた場合のみ小文字化して返す。それ以外（非2xx・404・タイムアウト・通信失敗・
  *     status 欠落/非文字列）はすべて null＝「中央不達 or 未知」を意味し、呼び出し側は従来経路
  *     （detectExternalDone の副シグナル／pendingタイムアウト）へ無損失で縮退する。
- *   - 最善努力プローブなので失敗はログを出さず握りつぶす（delivered＋アイドル毎tickで叩くため冗長ログ回避）。
+ *   - 最善努力プローブなので失敗はログを出さず握りつぶす（アイドル毎tickで叩くため冗長ログ回避）。
  *
  * 【デプロイ順の安全性】このエンドポイントが中央(devlog-tracker)に未実装の間は 404/非2xx→null となり、
  *   relay は従来どおり動く（無害・無損失）。中央側 PR が入った時点で自動的に根治が効き始める。
@@ -1389,6 +1281,55 @@ export async function fetchCommandStatus(cfg, id) {
         return null; // タイムアウト/通信失敗＝未知。従来経路へ縮退（安全側）。
     }
 }
+/**
+ * 配達済みの指示に、中央（管制）で「配達済み(status=sent)」の印を付ける。★ADR-023 根治の要。
+ *
+ * 【なぜ要るか＝実地の穴 2026-09-04〜05】以前は「アンカー(CONDUCTOR_JOB:{id})が職人の画面に
+ *   エコーされたのを relay が見たら sent にする」だった。ところが職人（Claude Code）は
+ *   全画面表示＝tmux から見ると代替画面で【さかのぼれる行が1行も無い】ため、アンカーは数秒で
+ *   流れて消える。次の tick（15秒後）に見えていなければ、その便は永久に queued のまま＝
+ *   管制の札が「待っています」から動かない。実測: 2026-09-03〜05 の配達 251 件中 6 件がこれ。
+ *   そして queued のまま残った便は、職人が一瞬アイドルに見えた瞬間に再配達され得た（二重配達）。
+ *
+ * 【根治】配達したかどうかは send-keys の成否で決める（画面を読まない）。この関数は
+ *   「その事実を中央へ書く」だけを担い、書けるまで毎tick やり直す。★書けなくても再配達はしない。
+ *
+ * 中央が「もう終わっている」と言ったときだけ pending を畳む（印を書き続けても意味がないため）。
+ * すでに中央が sent（他経路で印が付いた・409 で弾かれた等）なら、印は付いているとみなして完了。
+ *
+ * @returns 印が付いた（または既に付いていた）なら true。
+ */
+export async function markSentAtCentral(cfg, state) {
+    const pending = state.pending;
+    if (pending === null)
+        return false;
+    if (pending.sentMarked)
+        return true;
+    if (await patchStatus(cfg, pending.id, 'sent')) {
+        pending.sentMarked = true;
+        log(`site=${cfg.site} id=${pending.id} 配達済み(sent)を管制へ記録`);
+        return true;
+    }
+    // 書けなかった。理由を中央に聞いて、やり直す意味があるかだけ判断する。
+    const centralStatus = await fetchCommandStatus(cfg, pending.id);
+    if (isCentralFinished(centralStatus)) {
+        // もう終わっている指示に印を付ける意味はない。追跡を畳んで次へ進む（固着させない）。
+        log(`site=${cfg.site} id=${pending.id} は中央で終端(status=${centralStatus})` +
+            '→配達済みの記録は不要。追跡を解除する');
+        state.pending = null;
+        state.lastHeartbeatAt = null;
+        return false;
+    }
+    if (centralStatus === 'sent') {
+        // 既に印が付いている（別経路／409 の相手が自分自身だった等）。書き直す必要はない。
+        pending.sentMarked = true;
+        log(`site=${cfg.site} id=${pending.id} 中央は既に sent＝配達済みの記録は完了とみなす`);
+        return true;
+    }
+    log(`WARN site=${cfg.site} id=${pending.id} 配達済み(sent)を管制へ書けなかった` +
+        `(中央status=${centralStatus ?? '不明'})→次tickで再試行（★再配達はしない）`);
+    return false;
+}
 /**
  * このtickで生存ハートビート(bare)を送るかを決める純粋関数（I/Oなし＝単体テスト可能）。
  *
@@ -1496,14 +1437,14 @@ export function noteBusyEdge(state, site, id, raise, logLine) {
 //   管制は「返事がありません」のまま戻らない（2026-09-01 実地）。中央側の戻り道は既にある
 //   （/seen の body 無し通知が stalled → sent へ戻す）ので、送り手を絶やさないだけで直る。
 //
-// 【この経路がやらないこと】★再送は一切しない（本文も再送回数も持たない）。やるのは
+// 【この経路がやらないこと】★配達は一切しない（本文を持たない）。やるのは
 //   ①生存通知 ②画面の DONE 行を見つけたときの完了報告 ③中央が終端なら畳む、の3つだけ。
 // ───────────────────────────────────────────────────────────────────────────
 /**
  * 見張りを引き継ぐ（pending → keepalive）。★I/Oなし＝単体テスト可能。
  *
  * 引き継がない条件（どちらも「引き継ぐ根拠がない／壊す」ケース）:
- *   - 未着信(delivered=false): アンカーが画面に出ていない＝職人に届いた確証がない。
+ *   - 未配達(delivered=false): tmux への投入に成功していない＝職人に届いていない。
  *     生きているかどうかを語る根拠が無いので、生存通知を送ってはいけない。
  *   - 既に別の見張りがある: 新しい指示で古い見張りを上書きしない（便の縛り）。同一現場に
  *     複数の in-flight が並ぶかどうかの整理は中央の inFlight ガードの仕事で、relay 側で
@@ -1584,7 +1525,7 @@ export async function keepaliveTick(cfg, state, deps = {}) {
     const expired = now - ka.startedAt >= RELAY_KEEPALIVE_MAX_MS;
     // 上限を過ぎているなら画面は見ない（畳むと決まっているので capture の費用をかけない）。
     const cap = expired ? null : capture(ka.site);
-    // ★見張りに入っている＝その指示は必ず着信済み（startKeepalive が delivered を要求する）。
+    // ★見張りに入っている＝その指示は必ず配達済み（startKeepalive が delivered を要求する）。
     //   よってアンカーが流れて消えていても、画面全体を見てよい（ADR-020）。
     const below = cap === null ? null : sliceForDoneScan(cap, ka.anchor, true);
     // ★「作業中です」の印は busy シグナルだけで決める（メニュー中は挙げない・shouldRaiseBusy）。
@@ -1652,7 +1593,7 @@ export async function keepaliveTick(cfg, state, deps = {}) {
  *   - タイムアウト(RELAY_ORPHAN_FETCH_TIMEOUT_MS)を付け、devlog 到達不能でも起動がハングしない。
  *   - 空配列/エラー/未到達/不正応答はすべて [] を返す（起動を妨げないフェイルセーフ）。
  *   - sentAt は数値(ms)でも ISO 文字列でも受け、解釈不能なら現在時刻にフォールバック
- *     （= 次の再送まで delay 待ちになる安全側）。
+ *     （= 安全側）。
  */
 export async function fetchOrphans(cfg) {
     const u = `${cfg.url}/api/conductor/commands/orphans` +
@@ -1700,7 +1641,7 @@ export async function fetchOrphans(cfg) {
 }
 /**
  * sent孤児を pending へ復元する（2-b・起動後1回）。★ここでは送信しない＝pendingに積むだけ。
- *   実際の再送可否は次の relayTick の decideResend（着信済みなら再送しない等の冪等ガード）に委ねる。
+ *   ★復元しても配達はしない。役目は「DONE を待つ／生存を伝える／中央の終端を見て畳む」だけ。
  *   - 無効化(CONDUCTOR_RESTORE_ORPHANS=off)・取得空・pending占有中は何もしない。
  *   - フェイルセーフ: fetchOrphans が [] を返すケースは静かに通常起動を続ける。
  */
@@ -1716,7 +1657,7 @@ export async function restoreOrphans(cfg, state) {
         return;
     }
     state.pending = orphanToPending(pick);
-    log(`site=${cfg.site} id=${pick.id} を sent孤児から pending へ復元（★送信せず・次tickで2-a判定）`);
+    log(`site=${cfg.site} id=${pick.id} を sent孤児から pending へ復元（★配達はしない・DONE待ちと生存通知だけ）`);
 }
 // ───────────────────────────────────────────────────────────────────────────
 // relay 本体（1ポーリング分）
@@ -1729,7 +1670,7 @@ export async function restoreOrphans(cfg, state) {
  *     （sent 中はサーバも新規指示を返さないので取得しない）。停止中でも継続する
  *     （既に送った指示の後始末は進める）。
  *   - 緊急停止フラグを確認。停止中なら新規の取得・送信は一切しない。
- *   - pending が無く停止中でもなければ、取得 → アイドル判定 → sent遷移 → 送信。
+ *   - pending が無く停止中でもなければ、取得 → アイドル判定 → 配達 →「配達済み(sent)」を管制へ記録。
  *
  * すべての判定は保守的（少しでも怪しければ送らない／次回再挑戦）。
  */
@@ -1745,7 +1686,7 @@ export async function relayTick(cfg, state) {
         // ── sent孤児の復元(2-b・起動後1回) ──
         // cli.ts を触らず「起動時1回」を実現するため、最初の tick でだけ復元する。
         // 失敗しても再試行しない（フラグを先に立てる＝起動を妨げない／多重実行防止）。
-        // ★復元は pending に積むだけ。再送可否は下の pending 分岐 = decideResend に一元化する。
+        // ★復元は pending に積むだけ（配達はしない）。
         if (!state.restored) {
             state.restored = true;
             await restoreOrphans(cfg, state);
@@ -1770,26 +1711,25 @@ export async function relayTick(cfg, state) {
             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 据置で安全側。
+            // ── 完了検出の走査範囲を広げてよいかの観測（★状態更新には使わない・ADR-023） ──
+            // アンカーを一度でも画面で見たら、以後アンカーが流れて消えても全画面から DONE を拾ってよい
+            // （ADR-020 の根拠）。★ここで観測するのは「どこまで見てよいか」だけで、配達の成否や
+            //   中央の status には一切関与しない。
+            if (!state.pending.screenDoneWide && cap.includes(state.pending.anchor)) {
+                state.pending.screenDoneWide = true;
+            }
+            // ── 「配達済み」の印を管制へ書く（★ADR-023 根治の要・書けるまで毎tick再試行） ──
+            // 配達したという事実は send-keys の成否で確定しており（下の初回送信部）、画面には頼らない。
+            // ここは「その事実を管制へ書けたか」だけを追う。書けていなければ毎tick やり直す。
+            // ★書けなくても再配達はしない（配達は済んでいる。足りないのは印だけ）。
+            if (!state.pending.sentMarked) {
+                await markSentAtCentral(cfg, state);
+                if (state.pending === null)
+                    return; // 中央が終端＝追跡を畳んだ。次tickで通常経路へ。
             }
             // アンカー（今回送信の境界）より下だけを見て DONE:{site} 単独行を探す。
             // churn で古い DONE が押し出されても・過去ジョブの DONE が窓に残っても、誤検出/見逃しなし。
-            // ★アンカーが既に流れて消えている場合は、着信を確認済み(delivered)なら画面全体を見る
+            // ★アンカーが既に流れて消えている場合は、一度アンカーを見ていれば画面全体を見る
             //   （ADR-020。全画面表示の職人はさかのぼれる行が無く、アンカーが数秒で消えるため）。
             // ★Codex は完了と報告が notify でデータとして届く（ADR-021）。画面より先にそちらを見る。
             //   届いていれば、そのまま【既存の完了経路】へ橋渡しする（道は1本のまま）。
@@ -1804,7 +1744,7 @@ export async function relayTick(cfg, state) {
                     return;
                 }
             }
-            const below = sliceForDoneScan(cap, state.pending.anchor, state.pending.delivered);
+            const below = sliceForDoneScan(cap, state.pending.anchor, state.pending.screenDoneWide);
             if (below !== null && hasStandaloneDone(below, cfg.site)) {
                 // 報告本文も「アンカーより下」から抜き出す（今回ジョブの報告に限定。過去報告の誤添付を防ぐ）。
                 const report = extractReport(below);
@@ -1826,9 +1766,9 @@ export async function relayTick(cfg, state) {
             // 【副シグナル温存＝無損失縮退】中央 status が読めない(null＝エンドポイント未実装/不達)ときだけ、
             //   従来の detectExternalDone（別idが配れる＝終端の確証）へフォールバックする。中央側 status API が
             //   入るまではこの副シグナルが従来どおり効き、入った後は主シグナル(status)が確実に固着を断つ。
-            // HTTP コストを抑えるため delivered＋アイドルのときだけ probe する（busyな通常作業中は叩かない）。
+            // HTTP コストを抑えるため「印が付いている＋アイドル」のときだけ probe する（busyな通常作業中は叩かない）。
             const idle = looksIdleFor(cap, kindOf(cfg));
-            if (state.pending.delivered && idle) {
+            if (state.pending.sentMarked && idle) {
                 const centralStatus = await fetchCommandStatus(cfg, state.pending.id);
                 if (isTerminalCommandStatus(centralStatus)) {
                     log(`site=${cfg.site} id=${state.pending.id} は中央で終端(status=${centralStatus})を確認` +
@@ -1843,7 +1783,7 @@ export async function relayTick(cfg, state) {
                     const next = await fetchCommand(cfg);
                     const nextId = next?.id ?? null;
                     if (detectExternalDone({
-                        delivered: state.pending.delivered,
+                        sentMarked: state.pending.sentMarked,
                         pendingId: state.pending.id,
                         idle,
                         nextCommandId: nextId,
@@ -1895,109 +1835,13 @@ export async function relayTick(cfg, state) {
                 noteBusyEdge(state, cfg.site, state.pending.id, raise, log);
                 await sendHeartbeat(cfg, state.pending.id, raise);
             }
-            // ── 生存中の自動再送(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') {
-                    // ── 中央status照合（done済み再配達の根治・2026-07-09 実地バグ） ──
-                    // 完了が conductor_complete(MCP直行) で立つと中央は done になるが、relay が画面のDONE行を
-                    // 取りこぼすとローカル pending が残り、この経路が同一指示を延々と再配達していた。上の
-                    // 「外部完了検出」は delivered＋アイドルでしか走らず、この !delivered な再送経路とは条件が
-                    // 排他なので一度も中央を見ていなかった。再送しようとする今このtickでだけ照合する
-                    // （毎tickのポーリングにはしない＝中央への負荷を増やさない）。
-                    const centralStatus = await fetchCommandStatus(cfg, state.pending.id);
-                    const reconcile = decideCentralReconcile(centralStatus);
-                    if (reconcile === 'drop') {
-                        state.abandoned.add(state.pending.id); // 以後この id は二度と配達しない。
-                        log(`site=${cfg.site} id=${state.pending.id} 中央で${centralStatus}確認` +
-                            '→再送中止・ローカル解放（done済み再配達の根治）');
-                        state.pending = null;
-                        state.lastHeartbeatAt = null;
-                        return; // 次tickで halt確認→fetchCommand→通常経路。
-                    }
-                    if (reconcile === 'skip') {
-                        // 中央不達/未知。再送を見送り次tickで再試行（照合失敗で relay 本体は落とさない）。
-                        log(`site=${cfg.site} id=${state.pending.id} 中央status照合できず` +
-                            `(status=${centralStatus ?? 'null'})→このtickは再送見送り（次tick再試行）`);
-                        return;
-                    }
-                    // ── 配達回数の絶対上限（保険・無限ループの構造的封じ込め） ──
-                    // 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 || !looksLikeAgent(guardCap, kindOf(cfg))) {
-                        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)) {
-                        // 失敗の理由（tmux の stderr）は sendToTmux が直前の行に出している。
-                        log(`再送 本文の投入に失敗, 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' を返さない＝低頻度継続）。
-            }
+            // ★ここに「未着信＋アイドルなら同じ便をもう一度送る」自動再送があった（ADR-023 で撤去）。
+            //   撤去した理由: 「着信したか」を画面のアンカーで判定していたが、職人（Claude Code）の
+            //   全画面表示ではアンカーが数秒で流れて消えるため、実際には届いて作業中の便まで
+            //   「未着信」に見えた。そこへアイドルが一瞬重なると同じ便を二重に配達し得た（実地の危険）。
+            //   いまは配達の成否を send-keys の成否で確定し、配達は1指示につき1回だけにしている。
+            //   届かなかった場合の受け皿は、①中央が sent→stalled→timeout として人に見せる
+            //   ②下の pending タイムアウトで現場を空ける、の2つ（★勝手に送り直さない）。
             // DONE 未達のまま上限時間を超えたら、固着回避のため relay 内部で pending を解除して次へ進む。
             // （CC2 の異常終了等で DONE が永遠に来ないケースの根治。サーバ status は戻さない＝relay内部のみ。）
             //
@@ -2010,10 +1854,19 @@ export async function relayTick(cfg, state) {
                 log(`WARN site=${cfg.site} id=${state.pending.id} が pending タイムアウト` +
                     `(${Math.round(elapsedMs / 1000)}s)。DONE未達のため解除し次へ進む` +
                     (handedOver
-                        ? `／★生存の見張りは継続（上限${Math.round(RELAY_KEEPALIVE_MAX_MS / 60000)}分・再送はしない）`
+                        ? `／★生存の見張りは継続（上限${Math.round(RELAY_KEEPALIVE_MAX_MS / 60000)}分・配り直しはしない）`
                         : state.keepalive !== null
                             ? `／見張りは引き継がず（別の指示 id=${state.keepalive.id} を見張り中）`
-                            : '／見張りは引き継がず（未着信＝生きている根拠がないため）'));
+                            : '／見張りは引き継がず（未配達＝生きている根拠がないため）'));
+                // ★印を書けないまま追跡を畳む場合の穴止め（ADR-023）。
+                //   印が無いと中央はこの指示を queued のまま返す＝次tickで【同じ便をもう一度配ってしまう】。
+                //   配達は済んでいる（職人は受け取って動いている）ので、二度と配らないと決める。
+                //   完了は職人の conductor_complete か画面の DONE 検出に委ねる。
+                if (!state.pending.sentMarked) {
+                    state.abandoned.add(state.pending.id);
+                    log(`WARN site=${cfg.site} id=${state.pending.id} は配達済みだが管制へ印を書けなかった。` +
+                        '★二重配達を避けるため、この指示は以後配達しない（完了は職人の conductor_complete に委ねる）');
+                }
                 state.pending = null;
             }
             return; // sent 中は新規取得しない
@@ -2049,6 +1902,15 @@ export async function relayTick(cfg, state) {
         if (state.abandoned.has(cmd.id)) {
             return;
         }
+        // ── 配達回数の絶対上限（保険） ──
+        // 通常は1指示につき1回しか配達しない（自動再送は ADR-023 で撤去）。それでも中央が同じ id を
+        // 何度も queued へ戻す異常が起きたときに、際限なく配り続けないための最後の砦。
+        if (!canDeliver(state, cmd.id)) {
+            state.abandoned.add(cmd.id);
+            log(`WARN site=${cfg.site} id=${cmd.id} 配達回数が上限(${RELAY_DELIVER_MAX})に到達。` +
+                '以後この指示は配達しない（無限ループの構造的封じ込め）');
+            return;
+        }
         // ── アイドル判定（保守的・二重チェック） ──
         if (!tmuxHasSession(cfg.site)) {
             log(`site=${cfg.site} id=${cmd.id} tmux未起動のため送らずスキップ`);
@@ -2097,12 +1959,13 @@ export async function relayTick(cfg, state) {
             log(`本文の投入に失敗, 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 で再配信を継続する。
+        // ── 送信成功＝★この時点で「配達した」（ADR-023 根治） ──
+        //   配達したかどうかは send-keys（load-buffer→paste-buffer→Enter）の成否だけで決める。
+        //   ★画面のスクレイプ（アンカーが見えたか）には頼らない。職人（Claude Code）は全画面表示で
+        //     さかのぼれる行が無く、アンカーは数秒で流れて消えるため、見えないことは「届いていない」
+        //     の根拠にならない（実測 2026-09-03〜05・これが札が「待っています」のまま動かない穴だった）。
+        //   届く先が本物の職人の箱であることは、直前の tmuxHasSession / isIdleStable / looksLikeAgent が
+        //   確認済み。だから「送れた＝配達できた」と扱ってよい。
         const sentAt = Date.now();
         state.pending = {
             id: cmd.id,
@@ -2110,16 +1973,18 @@ export async function relayTick(cfg, state) {
             sentAt,
             anchor,
             body: cmd.body,
-            resendCount: 0,
-            lastSentAt: sentAt,
-            resendExhaustedWarned: false,
-            delivered: false,
+            delivered: true,
+            sentMarked: false,
+            screenDoneWide: false,
         };
-        // 累計配達回数を通算（初回送信も1件として数える＝絶対上限 RELAY_DELIVER_MAX の基準）。
+        // 累計配達回数を通算（絶対上限 RELAY_DELIVER_MAX の基準）。
         markDelivered(state, cmd.id);
         // 新しい指示の生存ハートビートは先頭から数え直す（前指示のスロットルを引き継がない）。
         state.lastHeartbeatAt = null;
-        log(`site=${cfg.site} id=${cmd.id} 送信（着信確認待ち・queued据置）`);
+        log(`site=${cfg.site} id=${cmd.id} 配達しました`);
+        // ★配達の直後に「配達済み(sent)」を管制へ書く。書けなければ次tick以降で書けるまでやり直す
+        //   （markSentAtCentral）。★書けなくても再配達はしない。
+        await markSentAtCentral(cfg, state);
     }
     finally {
         state.running = false;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tyhld/conductor",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "description": "采配くん管制の見守りアプリ（conductor-agent）。各PCで常駐し、中央(devlog-tracker)へ定期的に生存報告(heartbeat)を送る常駐CLI。",
   "type": "module",
   "bin": {