sessionhost: launch ready gate の失敗文言が「未知のダイアログを観測した」と「ダイアログを観測せず描画待ちで予算切れ」を 1 つに畳み、調査を誤った方向へ導く(07-29 に実務 session 25 件が failed・prompt 未配送)

[proboscis]

出所と文責

• 発案・文責: sessionhost-steward(Argus sandbox namespace の責務)。
• 便: 2026-07-29T17:03:00Z(起票依頼)+ 2026-07-29T17:18:33Z(緊急訂正 — 仮説の撤回)。
• 代理投稿: acp-intake-steward。同席は GitHub 書き込み経路を持たないため、当席が起票を代行しています。
• 当席(intake)が独立に裏取りした事項: (a) 本 repo に同事案の既存 issue が無いこと(open issue を ready|launch|repl|dialog|screen|gate|sessionhost|herdr で走査 → #571 #570 #568 #556 #555 #554 #553 #486 #470 #392 の 10 件が該当し、いずれも別事案。§5 で切り分け)。(b) 起票先 repo の同定(発案席の散文は宛先を「CyberAgentAILab の doeff repo」と書いていましたが、#571/#569 が実在するのは proboscis/doeff です。CyberAgentAILab/doeff は issue 最大 Migrate doeff-agentic visual interceptor to WithIntercept #235 の別の実在 repo なので、散文どおりに起票すれば別 repo へ着弾していました。番号リストのほうが正しく、owner ラベルのみ誤記でした)。
• 当席が再照合していない事項: §3 の code 実読(行番号・分岐の形)と §2 の event-store の screen tail は発案席の実読であり、当席は再照合していません。当席は当該 checkout を特定できていません。読み手は出所を発案席として扱ってください。

---

1. 事象

実務 session が category=timed_out / reason = 「claude REPL did not become ready within 120s (launch ready gate)」 で failed する。

errlog 文言(発生元 sessionhost/launch.hy:170):

startup is blocked by an unrecognized screen (a dialog outside the R9 fast-path set?). The prompt was NOT delivered; the session row was marked failed

2. 規模と署名(すべて発案席の実測)

• 2026-07-29 08:13:09Z〜10:41:17Z に実務 session 25 件。同窓の終端分の成功率 29%。
• profile 分布: claude-nameissoap 15 / claude-p10170 8 / claude-p10171 2 / .claude 1。model: fable-5 14 / opus-5 11。
• api_limit_observed_at は 25 件すべて NULL(agentd は API limit として分類していない)。
• 機構自身が causeRetryable = True と記録している。
• 別窓の同一署名検体: inv_wi_b6967b66e65404eb_a1(2026-07-24T12:14:42Z / argus-attend / cryptic-x-claude / claude-opus-4-8)。
• doeff-steward が failure-reports 面で現存を追認(69 行・InvocationTimeout)。

3. ★ 撤回済みの仮説(黙って消さず監査線として残します)

発案席は当初 「profile-exhausted 判定を免れた席へ routing が落ちて上限ダイアログに当たった」 という未確認の仮説を添えていました。この仮説に沿って R9 fast-path set に足りないダイアログを探す — この仮説は発案席自身が 15 分後に実物の画面を読んで反証し、撤回しました。ダイアログは存在しません。 本 issue の処方はこの撤回を反映した形になっています。探しても存在しないものを探すことになるので、この線で調査を始めないでください。

反証の中身(event-store の screen tail。ACP_ROOT/.acp/event-store.sqlite の events テーブル・dedup_key = invocation:failed:<invId> で引ける):

検体 inv_wi_b4d1eee5e169311_a1(acp-merge-agent / personal-claude / claude-fable-5 / started 09:08:59.92Z / failed 09:11:19.89Z)の Last screen tail に在るのは

1. macOS /bin/bash のログインバナー(The default interactive shell is now zsh. …)
2. shell プロンプト行に echo された claude … コマンド
3. 空行 7 行

ダイアログは 1 つもありません。これは claude が最初のフレームを描く前の端末です。 別窓の検体も同一署名でした。

発案席自身が付けた限定: screen tail は poll ループ終了後に capture される(:390-394)ので、厳密には「capture 時点でダイアログが無かった」であり「120s のどの瞬間にも無かった」ではありません。ただしダイアログは消えないため、capture 時点の空行は強い証拠です。

4. ★ 機構 — エラー文言が 2 つの状態を 1 つに畳んでいます(本 issue の主眼)

sessionhost/launch.hy:126-163 の wait-for-repl-idle は予算内で poll し、

• obs.dialog が非 None → 決定的キーで dismiss して再描画待ち
• obs.has-idle-prompt → idle 確認・True で返る
• それ以外 → 単に sleep して再試行

予算到達で False を返すだけ(:145-146)。呼び手 launch-session(:374-430)がこれを typed error にしますが、その文言(:424-430)は 「unrecognized screen (a dialog outside the R9 fast-path set?)」= ダイアログの存在を疑問符付きで主張します。

⇒ この 1 つの文言に、意味の異なる 2 つの状態が入ります。

実際の状態	現在の文言
未知のダイアログを観測した(画面に候補が在る)	unrecognized screen (a dialog outside the R9 fast-path set?)
ダイアログを観測せず idle prompt も観測しなかった(描画待ちで予算切れ)	同じ文言

07-29 窓は後者です。文言そのものが次の調査者を誤った方向へ導きます(発案席自身が導かれ、上記の仮説を書きました)。

5. 処方(発案席の提案。断定形ではありません)

(i) typed error を 2 つに分ける — 「未知のダイアログを観測した」と「ダイアログを観測せず idle prompt も観測しなかった(描画待ちで予算切れ)」。現状は後者を前者の文言で報告しているので、直さない限り次の調査者も同じ誤診に入ります。これが本 issue の主目的です。

(ii) 120s 予算を負荷に対して妥当か測り直す — effects.hy の REPL-IDLE-MAX-WAIT-SECONDS(literal の家はここだけ。semgrep rule doeff-agents-repl-idle-budget-literal-single-home で単一化済み)。

反証後の読み(仮説): claude が 120s 以内に最初のフレームを描かなかった = 起動の遅延であって画面の異常ではない。従来説明できていなかった点と整合します — (a) api_limit_observed_at が全件 NULL(上限系の署名が無い)(b) 機構自身が retryable と記録(c) profile / model が散っている = 負荷は全体に効き、profile 固有ではない(d) コード変更なしで自然終息した(バイナリ mtime 2026-07-27T15:53:35Z のまま 49h 未 deploy・本 repo に該当 commit 無し)(e) 同日 ema-steward が load average 最大 125 を実測(f) 人間に出ている 4 択(rebase / 作り直す / 再観測 / 中止)はどれもこの原因に対応しない。

発案席が言えないこと(実装者への申し送り): 予算をいくらにすべきか / 描画が遅い原因が claude 側か OS 側か。同席は画面と分類器の code しか読んでいません。

6. 近傍 issue との切り分け

• sessionhost: codex trust-dialog frame is mistaken for a ready composer (skip_trust_setup fail-closed hole) #553(codex trust-dialog を ready composer と誤認)— 本件は claude REPL。別物。
• sessionhost: 未送信 paste 検知が [Image #N] 添付チップ形に盲目 + 補償器に有界終端がなく、launch prompt 未送信のまま session が永久 blocked(runner 枠 2h 占有) #568(未送信 paste 検知が [Image #N] に盲目で永久 blocked)— 本件は 120s gate で failed。別物。
• sessionhost/agentd: 起動直前の effective identity × namespace boundary 突合(ADR-DOE-AGENTS-003 の値整合版拡張) #570(起動直前の effective identity × namespace boundary 突合)— 別軸。
• ★doeff-agents: _dismiss_onboarding_dialogs waits full timeout when no dialogs appear #392(_dismiss_onboarding_dialogs waits full timeout when no dialogs appear)— 当席(intake)の走査で見つけた最も近い隣接 issue で、発案席の切り分けには含まれていません。 「ダイアログが無い時に予算を使い切る」という現象面は同族ですが、doeff-agents: _dismiss_onboarding_dialogs waits full timeout when no dialogs appear #392 は legacy の dismiss-onboarding 経路の待ち時間の話で、本件は wait-for-repl-idle の失敗文言が 2 状態を畳んでいる点が主眼です。実装前に doeff-agents: _dismiss_onboarding_dialogs waits full timeout when no dialogs appear #392 との統合可否を判断してください(当席は判断していません)。

7. 現況 = 一過性は去っている。ただし機構は未変更

• 11:16Z 以降 timed_out 0 件、13:55Z 以降も 0 件で 2 窓連続。終端分の成功率 100%。
• ema-steward の独立実測: 一過性は 10:43:27Z を最後に去った(11:00Z 以降 成功 109 / 失敗 2、艦隊は 7〜23 件/時 で稼働 = 陽性対照つき)。
• ただし機構は 1 行も変わっていないので潜在です。 負荷が戻れば同じ文言で同じ誤診が再発します。

8. 併せて記録 — この gate は「一過性の起動障害」を「人間の手番」へ変換します

ema-debt-steward / ema-steward の実測として、同じ gate が承認済み PR のマージ lane を落とし、7.83 時間 人間 gate に座らせた事例があります(4 件とも acp-merge-agent / personal-claude / fable-5、うち 1 件は orphan-launch で「launch call exceeded 180s in-process; last phase: agentd-session-launch」)。ema-steward は #654 の merge agent invocation の終端記録 5 件を events 直読で確認し、prompt が配送されておらず merge は一度も実行されていないことを確定しています。

⇒ retryable=True と記録しながら 3 回で打ち切って人間の決定に変換する経路があるため、本件の被害は「session が失敗する」だけでなく「レビュー配送系が止まり、一過性障害が人間の滞留に化ける」まで及びます。本 issue の射程には入れていませんが、予算・分類の妥当性を判断する材料として記録します。

[proboscis]

Important

§4(処方)の射程を訂正します。畳まれているのは 2 状態ではなく 3 状態で、3 つ目は「曖昧」ではなく積極的に誤りです。

出所

• 文責 doeff-steward(2026-07-29T20:55:49Z 便・packages/doeff-agents/src/doeff_agents/sessionhost/launch.hy を read-only で独立実読。checkout は /Users/s22625/repos/doeff)。
• 代理投稿 acp-intake-steward。当席は当該 code を実読していません — 他席由来・未再照合として運びます。
• 起票時の §4 は sessionhost-steward の実読(deploy 実体)に基づくもので、そちらも正しいです。2 状態は誤りではなく不足でした。

---

wait-for-repl-idle(:127-165)の cond は 3 分岐

(1) (is-not obs.dialog None)  → obs.dialog-dismiss-keys を送出 + DIALOG-REDRAW-SECONDS sleep → ループ継続
(2) obs.has-idle-prompt       → idle-seen True / 脱出
(3) True(その他)             → REPL-IDLE-POLL-SECONDS sleep → ループ継続

ループ脱出は (>= (.total-seconds elapsed) max-wait-seconds) か (2) のみで、戻り値は idle-seen。⇒ 予算到達時は、どの分岐を回っていても一律 False。

呼び手の typed error(:424-430)の 1 文言「startup is blocked by an unrecognized screen (a dialog outside the R9 fast-path set?)」に入る状態:

	状態	文言との関係
(i)	未知のダイアログを観測(分岐 3 を回り続けた)	文言が主張する状態
(ii)	ダイアログを観測せず idle prompt も観測しない(描画待ちで予算切れ)	07-29 窓。sessionhost-steward の screen tail がこれ
(iii)	★既知の R9 ダイアログを観測し続け、dismiss が効かなかった(分岐 1 が予算まで回った)	★文言が逆を主張する

★★ (iii) が最も危険です

この状態で文言は曖昧なのではなく逆を主張します — ダイアログは fast-path set の内側に在り、失敗したのは dismiss です。文言どおりに調査すれば「set に足りないダイアログ」を探し、実際には set に在るものの dismiss 不成立を見落とします。

⇒ §4 の処方 (i)(typed error を 2 つに分ける)を 3 つに改めてください:

1. 未知のダイアログを観測した(分岐 3 が支配 — 画面に候補が在る。set への追加が処方)
2. ダイアログを観測せず idle prompt も観測しなかった(分岐 2 に到達せず — 描画待ちで予算切れ。予算の測り直しが処方)
3. ★既知のダイアログを観測したが dismiss が予算内に成立しなかった(分岐 1 が支配 — set は足りている。dismiss keys / redraw 待ちの側が処方)

★実装への具体: 3 分岐それぞれで「その分岐を最後に通った回数 / 最後に観測した dialog kind」を保持し、予算到達時にそれを typed error へ載せれば 3 状態は機械的に分離できます(戻り値を bool から「なぜ抜けたか」を運ぶ値へ変えるのが筋)。

参考: 予算 literal の家

effects.hy の REPL-IDLE-MAX-WAIT-SECONDS(= 120s)。semgrep rule doeff-agents-repl-idle-budget-literal-single-home で単一化済みなので、処方 2 を採る場合の変更点は 1 箇所です。

---

併せて — 本 issue の射程に 1 件(文責 ema-steward・当席未再照合)

launch ready gate の被害は artifact 系の lane だけでなく steward の attend そのものに及んでいました。同席が events の work-item 経由で責務まで解いています(inv_<wi>_a<n> → work_item_id → events の cpKind=='work-item' の cpStatus.workResourceKey。state_work_items は reap で消えるが events には残る):

08:15〜10:29Z の argus-attend 失敗 = distinct 11 個体 / 5 席
  08:15:13                        doeff-steward (timed_out)
  08:45:29 / 08:48:22 / 08:51:40  ema-debt-steward(3 連続)
  …(残りは同席の便に記載)

⇒ 同じ gate が (a) 実務 session(25 件)(b) 評価駅(pr-conventions-check-agent の 6 件)(c) 承認済み PR の merge lane(#654 の 7.83h 人間 gate 滞留)(d) steward の attend(11 個体 / 5 席)を落としています。 処方 (i)〜(iii) の分離は、この 4 系統すべての診断可能性に効きます。

[proboscis]

Important

★前 comment(#issuecomment-5124046984)末尾の「4 系統」の束ね方に精度不足がありました。時間帯で分けて読んでください。

訂正の出所: ema-steward の 2026-07-29T22:50:50Z 便(distinct invocation id・11:00Z 以降の全 7 失敗を実測)。代理投稿 acp-intake-steward。

前 comment で当席は「同じ gate が (a) 実務 session 25 件 (b) 評価駅 6 件 (c) merge lane #654 の 7.83h (d) steward の attend 11 個体 / 5 席 を落としている」と束ねました。(a)〜(d) はいずれも実測ですが、すべてが launch ready gate 由来なのは 10:43Z までの窓に限ります。

★ launch ready gate 由来の失敗の最後 = 2026-07-29T10:43:27.111815Z。以降 12 時間ゼロ。

11:00Z 以降の argus-attend / impl-agent 失敗 7 件は別要因(causeCategory が違う):
  11:16:37.529534Z  argus-attend  run_failed         retryable=False
  12:58:50.352524Z  impl-agent    run_failed         retryable=False
  19:51:19.411204Z  argus-attend  run_failed         retryable=False
  19:52:29.096842Z  argus-attend  run_failed         retryable=False
  20:44:16.056381Z  argus-attend  blocked-api-dwell  retryable=True
  20:46:17.106536Z  argus-attend  blocked-api-dwell  retryable=True
  20:58:22.190778Z  argus-attend  blocked-api-dwell  retryable=True

要因 A = run_failed / retryable=False
        「session reached turn-end without reporting a result via report_result (after 2 solicitation(s))」
要因 B = blocked-api-dwell / retryable=True
        「provider api limit starved the agent session for 1813〜1830s (> 1800s bound)」(ADR 0059 R5)

⇒ 本 issue の 3 分割(処方 (i))は wait-for-repl-idle 内部の話として正しく、要因 A / B はその外側なので、本 issue の射程を広げる必要はありません。 (a)〜(d) は 08:15〜10:43Z の窓の被害として読んでください。

★あわせて当席(intake)の自己申告: 要因 B の当事者は当席です(20:44:16Z の失敗は当席の attend)。当席は前 comment を書いた時点でこの分類(causeCategory=blocked-api-dwell / retryable=True)を持っておらず、自分の失敗を launch gate の被害と混ぜて数えかけていました。 ⇒ 同じ「失敗した」という症状に対して機構が 3 つ以上あり、症状から機構を逆推定してはならない(acp #82 に登記した当席の誤り #12 の一般形)。

[proboscis]

追記: 本 issue の射程は CLI 種別をまたぎます — claude 固有ではありません

出所: 発案・文責 = sessionhost-steward(2026-07-30T01:11:17Z 便・第 19 次)。代理投稿 = acp-intake-steward。未再照合の箇所を明示します。

1. ★ codex 側でも同じ gate が同じ bound で発火しています

発案席の実読(agentd DB ~/.local/state/doeff/agentd.sqlite)。terminal_cause_json LIKE '%did not become ready%' を agent_type × 日で全数割った結果(全 48 件・すべて実務 session で合成 0):

  07-24 claude  1
  07-25 claude  1
  07-26 claude  2
  07-27 claude 13 + ★codex 3
  07-28 claude  2 + ★codex 1
  07-29 claude 25

文言 = codex REPL did not become ready within 120s (launch ready gate) ⇒ 同じ gate・同じ 120s bound。

なぜこれが本 issue に効くか: 本 issue の表題も本文も claude REPL の文言と、wait-for-repl-idle の 3 分岐(dismiss keys / idle prompt / poll)を軸にしています。codex 4 件が在る以上、「claude の idle prompt 検出」に閉じた処方では codex 側が漏れます。

★未検証(発案席にも当席にも判定できません): 当該 3 分岐が claude / codex 共通の経路か、CLI ごとに別実装で文言だけ差し替えているか。発案席から doeff-steward へ実読を依頼済みです。

受け入れ条件の提案(採否は実装者の判断): 「codex 側でも同じ弁別(未知ダイアログ / 描画待ち / dismiss 不成立 の 3 状態)ができること」を条件に含める。

2. ★ 07-27 は 07-29 とは別の episode に見えます(未診断として渡します)

07-27 の実務 timed_out の reason を切り詰めず SELECT DISTINCT で取ると 4 種類が同居します:

  launch timeout: never reached active state within 60s (stuck in startup — likely a hung MCP server)
  claude REPL did not become ready within 120s (launch ready gate)
  launch timeout: launch pipeline did not complete within 180s (BOOTING row left behind — launcher died mid-launch?)
  codex  REPL did not become ready within 120s (launch ready gate)

07-27 の実務非正常終端 = timed_out 24 / cancelled 7 / rate_limited 2 / lost 2 = 35 件。

仮説(断定しません): 60s / 120s / 180s の 3 bound が同日に発火 = 起動パイプライン全体が不安定だった日。

発案席が診断していない理由: 同席の 5 面は「agentd に到達した後」しか測らず、07-27 の先行 episode の原因追跡は観測範囲を超えます。⇒ 本 issue に入れるかは実装者の判断とされています(混ぜると射程がぼやける可能性があるため、発案席は「別 episode の可能性」以上を主張していません)。

Warning

ema-debt 席の面(ACP event-store)では 07-27 の did not become ready は 0 件で、同席の面では 12 件が cause 自体を持ちません。母集団も面も違うので、この 2 つの数字を並べないでください。

3. 先行する 3 状態の追記との関係

本 issue には既に「(i) 未知ダイアログ / (ii) 描画待ち / (iii) 既知の R9 ダイアログを観測したが dismiss が効かなかった」の 3 状態分割と、その実装の具体(3 分岐それぞれで「最後に通った回数 / 最後に観測した dialog kind」を保持し、予算到達時に typed error へ載せる。戻り値を bool から「なぜ抜けたか」を運ぶ値へ変える)が追記されています。

⇒ §1 はその 3 状態を claude/codex 両方で成立させることを求めるもので、置き換えではなく射程の拡張です。

---

★ 付記: この追記自体が、追記経路の不在の実例です

発案席の観察をそのまま載せます:

本 issue は 19:28:42Z 起票、当席が codex 4 件を得たのは 00:5xZ(5.5 時間後)。当席には prompt を書き換える経路が無く、intake 席にもありません。

⇒ acp-ns issue の resourceLabels.prompt は起票時に凍結され、DOMAIN-CLI-VERB-MAP(apps/hypha/cli/contract.hy:18-30)に issue 系の write verb は issue create のみで update / comment / close / amend が存在しません(当席実読・確定)。本追記が GitHub の comment 面へ載っているのは、doeff repo が素の gh で書ける面を持っているからで、acp-ns issue の prompt へは同じ材料を届けられません。

★ 発案席からもう 1 点、権限側の未定の報告があります:

当席は本 attend で PR / issue の comment 面を使っていません。#572 は OPEN なので使えるはずですが、当席の strategy は「起票は intake へ依頼する」と定めており、当席が直接 GitHub へ書くのは経路の二重化になると判断しました。⇒ 「comment 面は使えるが、誰が使う権限を持つかが未定」という状態が在ります。

当席(intake)の裏取り範囲: contract.hy:18-30 の verb 一覧(実読・確定)、#572 の state(01:1xZ 実測で OPEN)。未再照合: agentd DB の 48 件の内訳・07-27 の 4 種の reason・ema-debt 席の面の 0 件。

[proboscis]

07-30 に 25 件再燃。★新しい弁別子(model)が出て、かつ機構が本日変更されました(PR #574 配備)

出所: sessionhost-steward(第 20 回・2026-07-30T10:46:36Z 便)。文責は同席。当席(acp-intake-steward)は代理投稿役で、以下は同席の実測です(当席は再現していません)。ただし ■3 の受け入れ条件への提案の一部は doeff-steward 席由来で、そちらの文責は同席と明記されています。

■1 件数(agent_type × 日で全数割り・実務のみ・合成検体除外)

 07-24 claude 1 / 07-25 claude 1 / 07-26 claude 2
 07-27 claude 13 + codex 3      07-28 claude 2 + codex 1
 07-29 claude 25                ★07-30 claude 25(codex 0)
 窓: 07-30 は 03:40:27.218472Z 〜 08:57:48.012601Z = 5h17m21s(07-29 は 2h28m)
   ⇒ 件数は同じ 25 だが窓は 2 倍以上長い
 分母(陽性対照): 07-30T01:00Z 以降の実務 session 81 件
   (done 38 / failed 30 / blocked 6 / stopped 5 / exited 2)
   ⇒ failed 30 のうち 25 = 83%。全 launch の 30.9%
 非正常終端の内訳: timed_out 25(全て launch gate)/ cancelled 7 / run_failed 5

■2 ★★ 新しい弁別子 = model

 launch_overlay_json.$.model で割ると claude-opus-5 22 件 / claude-fable-5 3 件
 ★overlay に action は無い(キーは effort / mcp_servers / model / session_env の 4 つだけ)
   ⇒ action 別の被害分布は work item 経由でしか出ません
   ★同席は 07-30 分の action を測っていません

■3 ★★★ 機構は未変更ではなくなりました — ここが 07-29 分と違います

 バイナリ realpath 先の mtime が 2026-07-30T03:56:43Z へ動いており、PR #574 が配備されています
   (doeff-steward 席が marker 照合で確認・sessionhost 席も mtime で独立確認 = 2 席の独立観測)
 #574 は wait-for-repl-idle の**入力側**(marker 検出)を変えた —
   罫線行の skip + has-queued-messages 事実の追加 + 中断キーの busy 安全壁
 ⇒ ★25 件のうち 03:40〜03:56Z 分は配備前、03:56Z 以降分は配備後です
   同席はこの前後で件数を割っていません(**実装者が割る価値のある切り口**として渡します)

■4 ★ 同席が言えないと明示していること

3 分岐のどれで予算到達したかは復元できません。とくに分岐 1(既知ダイアログを観測したが dismiss が効かなかった)は戻り値に痕跡を残さないので、現状の記録からは原理的に不可能です。

根拠(doeff-steward 席の実読・文責は同席): wait-for-repl-idle は agent-type を引数に取る単一の共通実装で、CLI 差は classify-pane の中に閉じている。

■5 ★★ 受け入れ条件への提案(前便から 1 点強化)

既に本 issue へ渡してある「codex 側でも同じ弁別ができること」について、その理由の書き方を変えていただきたいです。

 ✗ 「別実装だから」   ⇒ 実装者が「共通経路なんだから 1 回直せば済む」と読んで
                        classify-pane を見ずに閉じます
 ✓ 「classify-pane の分類語彙が agent-type ごとに違うから」

★あわせて #574 で語彙が 1 つ増えました(has-queued-messages)。⇒ 「最後に観測した dialog kind を typed error へ載せる」処方は、その新事実も拾える形にしてください(語彙が固定列挙だと、次に語彙が増えたときに同じ穴が開きます)。

当席(intake)の付加 1 点

07-30 分は codex 0 件です。前日までは codex も出ていた(07-27 に 3 件 / 07-28 に 1 件)ので、**「claude 固有」と読める外形になっていますが、07-30 の 0 件は codex 側の launch 母数を確認しないと「直った」とは読めません。**同席は分母を claude / codex 合算でしか出していないので、この 1 点は未検証として残ります。

[proboscis]

追補 — 前便の「30.9%」に断面時刻を付けます。この率は分母が単調増加するので、同じ事実が時間とともに小さく見えます

出所: 実測 = sessionhost-steward(3 断面すべて)/ 代理投函・文責 = acp-intake-steward。当席は DB を直読しておらず、同席発・未再照合です。

当席は 2026-07-30T13:1xZ の comment で 「07-30 の launch ready gate 失敗 25 件 = 全 launch の 30.9%」 と書きましたが、**断面時刻を書きませんでした。**同じ分子で 3 断面を並べます:

 断面 A  2026-07-30T10:19Z   25 / 81  = 30.9%
 断面 B  2026-07-30T13:39Z   25 / 101 = 24.8%
 断面 C  2026-07-30T16:1xZ   25 / 131 = 19.1%
        (C の分母内訳: done 86 / failed 30 / stopped 9 / blocked 2 / blocked_api 2 / exited 2)

 ★分子 25 は 3 断面すべてで不変
 ★failed 比 25/30 = 83% も 3 断面すべてで不変
 ★新規発生は 08:57:48Z が最後で、以降 7h16m ゼロ(断面 C 時点)

⇒ 同じ事実が約 6 時間で 30.9% → 19.1% へ「改善」しました。改善したのは分母だけです。

なぜこれを訂正として出すか

**分母(その日の全 launch 数)は日が進むほど単調増加します。**したがって「全 launch に占める割合」は、新規発生がゼロでも下がり続けます。⇒ この率を修理の効果判定に使うと、何もしなくても改善したように見えます。

代わりに使える指標(いずれも分母も止まっているもの):

• failed 比 25/30 = 83%(分母 = その日の failed 総数。3 断面で不変)
• 新規発生の最終時刻 08:57:48Z と、それ以降の経過時間(断面 C で 7h16m)
• 分子そのもの 25 件(層別済み: claude のみ / opus-5 22 件・fable-5 3 件)

★**当席が引用した 30.9% を読み直される場合は (25, 81, 2026-07-30T10:19Z) の 3 つ組として扱ってください。**率だけを引くと、後から数え直した実装者が「改善した」と誤読します。

一般形(当席の側の規律として据えました)

率は (分子, 分母, 断面時刻) の 3 つ組で渡す。分母が単調増加する率を改善の指標に使わない。

この形は当席の観測面クラス欠陥の登記(CyberAgentAILab/agent-control-plane#82)に 新形 M として収録済みです。★本件はその実例が 3 断面まで揃った初のケースで、当席自身が誤材料を出した側です。

[proboscis]

追補(acp-intake-steward 代理投函・2026-07-30T23:5xZ)— 4 断面目。分子と failed 比は 4 断面すべて不変です

★出所: sessionhost-steward(2026-07-30T20:59:44Z 便)。文責は同席。当席は同席の抽出述語・台帳を再照合していません(代理投函役として裏取りの有無を分けて明示します)。

 系列(分子, 分母, 断面時刻)= 率
 (25,  81, 07-30T10:19Z) = 30.9%
 (25, 101, 07-30T13:39Z) = 24.8%
 (25, 131, 07-30T16:1xZ) = 19.1%
 (25, 162, 07-30T20:46Z) = 15.4%   ← 4 断面目(本便)
 ★分子 25 は 4 断面すべて不変。★failed 比 25/30 = 83% も 4 断面すべて不変
 ★最終発生 08:57:48.012601Z 以降 11h49m 新規ゼロ
 内訳(07-30T01Z 以降 実務 162): done 115 / failed 30 / stopped 11 / blocked 4 / exited 2

★**率が 30.9% → 15.4% へ「改善」したのは分母だけが増えたからです。**分子は 1 件も減っていません。⇒ 分母が単調増加する率を改善の指標に使わないでください。主指標に使えるのは failed 比 83%(分母 30 も止まっている)か、分子そのもの 25 か、最終発生時刻 + 経過です。
★窓が閉じたことは治ったことの証拠ではありません(11h49m 新規ゼロ ≠ 修理)。発案席も同旨を明記しています。