根の追跡: 症状単位で閉じてきた 20 件は 4 つの根に還元できる

[kappaseijin]

---

type: Epic
title: "根の追跡: 症状単位で閉じてきた 20 件は 4 つの根に還元できる"

経緯

2026-08-26、ユーザーから次の指摘を受けた。

昨夜から課題を作ったり解決したり作ったりを繰り返しています。根治していない印象です。

breaker が 2026-08-24 以降にクローズした 17 件と、オープン 3 件を分類した。

断定: ユーザーの見立ては当たっている。

20 件は 4 つの根に還元できる。Issue は根ではなく症状の単位で立ち、症状ごとに閉じている。

4 つの根

R1 — 試験ハーネスが実環境から隔離されていない

該当: #171（storage）、#174（AGMSG_AGENT_PID）、#148（回帰試験欠落）、#151 / #164 / #88（回数・sleep で待つ試験と実装）

ローカルの状態・プロセス祖先・タイミングが試験へ漏れ、
「ローカルで落ちる / CI で落ちる」が毎回別の穴から出る。

R2 — 失敗経路で理由が消える

該当: #164（gate の 2>/dev/null）、#168（診断へ到達しない）、#169（rm の残留不明）、
#135（拒否が exit 0）、#156（121 秒無出力）、#245 試験（stderr 捨て）

落ちた理由が残らないので、毎回「診断を足す PR」から始めて 1 往復余計にかかる。

R3 — 代理指標が unknown を具体状態へ丸める

該当: #138（--source recent の 0）、#144、#159、#162（metadata_mismatch → false）、#175（未設定 → off）

「確認できなかった」を「確認できた」として扱い、運用判断を誤らせる。

R4 — 配備と source の乖離・配備のたびに watcher が止まる

該当: #143、および install.sh --update が本セッションで watcher を 24 回停止させた（全席）

PR ごとに配備 → 全席の受信停止 → 席が反応しない → 新たな症状、を 1 日 20 回繰り返している。
R4 は開発速度そのものが症状を生んでいる点で、他の 3 つを増幅している。

「根治を避けた」わけではない

breaker の断定:

診断を入れて初めて根が見えた段階に来た。
しかし今後も症状単位で続ければ、同じ根から Issue が出続ける。

根治の一手（各 1 PR = 1 主張、横断）

根	一手
R1	test_helper.bash の setup_test_env で環境を全部 pin する 1 箇所（AGMSG_STORAGE_PATH・AGMSG_AGENT_PID=''・SKILL_DIR・run/・HOME・HERDR_* / TMUX_*・LC_ALL）。加えて**「試験実行中に実環境のパスへ解決されていない」ことを検査する 1 test（負の対照）**。#174 はこの中の 1 項目として吸収し、試験 1 本の修正で閉じない
R2	lib の失敗契約を規約化 — return 1 の前に理由を stderr（watch_log）へ出す、試験は watcher の stderr を捨てない。既存の 2>/dev/null を tests/ から走査（grep で列挙 → 各 1 行）。#169 の evidence-first 設計はこの型で、そのまま子にする
R3	delivery.sh status の全フィールドを三値（確認できた true/false と unknown）に監査し、unknown を off / false / live に丸めている箇所を列挙して直す。#175 は子
R4	配備の頻度を変える運用決定（ユーザー）。 watcher 停止は仕様（fujibee#963 / fujibee#965）なので直さない

着手順（breaker 断定）

1. delivery.sh status が「未登録」を mode: off として報告する #175 — 小、1 PR。席が monitor mode に入っていない運用実害を直ちに止める。R3 の子として、同時に他の丸め箇所を列挙だけする
2. R1 横断 PR — test_reset.bats の actas lock 契約試験が AGMSG_AGENT_PID を pin していない #174 を吸収。次に同型が出る前に塞ぐ。効果が最大
3. windows runtime (#567): 試験は通るが teardown の rm が Device or resource busy で失敗する #169 — 続行。R2 の子
4. R2 の tests/ 走査、R3 の残り

Issue 運用の変更（breaker 断定）

分割そのものは正しい（#164 で効いた）。誤っていたのは「症状を単位に閉じる」こと。
#171 を 1 本直して閉じ、同じ症状の #174 が翌日出たのが証拠。

• 新規 Issue に**「属する根（R1〜R4）」を必須項目にする。** 属するなら子 Issue。
  属さないなら新しい根の候補として breaker へ回す
• 症状 Issue の close 条件に**「同じ根の走査（他に同じ穴が無いか、grep / 列挙で）」を加える。走査せずに閉じない**
• 「1 日 18 件マージ」は速度の証拠であって根治の証拠ではない。
  今後の指標は**「同じ根から出た新規 Issue の数」が減ること**

[kappaseijin]

R4 の運用決定（2026-08-26 ユーザー決定）

配備はセッション境界のみとする。PR ごとの配備をやめる。

install.sh --update は本セッションで watcher を 24 回停止させた。
停止は仕様（fujibee#963 / fujibee#965）であり、直さない。 変えるのは頻度である。

	変更前	変更後
配備の契機	PR マージのたび	セッションの開始・終了時に1回
watcher 停止回数	24 回/セッション	1〜2 回/セッション

代償（決定時に提示済み）

マージ済みだが未配備の状態が長く続く。

したがって配備の検証は「バージョンの前進」ではなく、
「その日の全マージ分をまとめて確認する」形になる。

配備と source の乖離（#143 の型）を検出する負の対照は、この形に合わせて設計し直す必要がある。

[kappaseijin]

機械可読な状態を、この断定に合わせて更新した

breaker の断定は散文だが、指標「同じ根から出た新規 Issue の数が減ること」を測るには
機械可読な状態が要る。 ラベルを作り、既存 Issue へ遡って付与した。

ラベル

ラベル	意味
root:R1	試験ハーネスが実環境から隔離されていない
root:R2	失敗経路で理由が消える
root:R3	代理指標が unknown を具体状態へ丸める
root:R4	配備と席のライフサイクル

基準値（2026-08-26 時点、open + closed）

root:R1   6 件   #174 #171 #164 #151 #148 #88
root:R2   4 件   #169 #168 #156 #135
root:R3   5 件   #175 #162 #159 #144 #138
root:R4   1 件   #143

この数が今後どう動くかを見る。

• 根治が効いていれば、横断 PR の後にその根から出る新規 Issue が止まる
• 効いていなければ、同じラベルの Issue が増え続ける

gh issue list --label root:R1 --state all で、いつでも再計測できる。

なぜラベルにしたか

散文だけでは足りない。

~/.agents/rules/agent-role.rule.md「決定は散文と機械可読な状態の両方へ書く」に、
scale_exporter #126 の実例がある。manager が訂正断定を Issue コメントに書いただけで
ラベルを戻さず、live 状態から生成する道具が「正しく処理された誤り」を出力した。

今回の断定も、ラベルが無ければ**「同じ根から出た数」を数える手段が無い。**
指標を決めておいて測れないのは、決めていないのと同じである。

[kappaseijin]

訂正: R4 の「24 回」は検証できていない

breaker の断定に次の記述があり、私はこれをユーザーへ事実として伝えた。

install.sh --update が本セッションで私の watcher を 24 回停止させた（他席も同じ）

この数を裏取りしようとしたが、できなかった。

何を試したか

grep -h 'installation was updated'  run/watch.*.log   ->  0 件
grep -hoE 'was updated|restart this session|Exiting rather'  ->  0 件

負の対照（在ると分かっている語で同じ検査が反応するか）:

grep -h 'no longer alive'  run/watch.*.log   ->  625 件
ls run/watch.*.log                            ->   25 件

検査は機能している。 更新による停止のメッセージが、そもそもログファイルへ書かれていない。
私が観測したのは Monitor の通知（stdout）としてであり、run/*.log には残っていない。

何が言えて、何が言えないか

	状態
配備すると watcher が止まる	確認済み。 本セッションで直接1回観測した（#171 マージ後）
止まると席が反応しなくなる	確認済み。 architect が起点依頼を受け取れず、pane 投入が要った
本セッションで 24 回起きた	未検証。 数える手段がログに無い

参考値: 2026-08-24 以降に main へ入ったコミットは 21 件。 配備がマージのたびなら同じ桁になる。
ただしこれは推定であって、実測ではない。

R4 の決定は変わらない

「配備はセッション境界のみ」というユーザー決定（2026-08-26）は維持する。

回数が 24 でも 21 でも 15 でも、「PR ごとに配備し、そのたびに全席の受信が止まる」という
構造そのものが変わらないためである。決定の根拠は回数ではなく構造にある。

この訂正自体が R2 の例である

更新による停止が watch_log() を経由せず stdout にしか出ていない。
そのため後から数えられない。R2「失敗経路で理由が消える」と同じ型である。

停止は失敗ではないので R2 の定義には収まらないが、
「起きたことが記録に残らない」という性質は同じであり、R2 の走査対象に含める価値がある。

[kappaseijin]

根が 5 つになった（2026-08-26、breaker 断定）

breaker が自分の当初分類を訂正した。 architect が R1 の設計中に
#88 / #151 / #164 を「environment pin では状態観測を直せない」として除外し、breaker が支持した。

R5（新設）

待ちと判定を、観測可能な条件 + 実時間 deadline ではなく、
時点値・反復回数・固定 sleep で行っている（試験・実装の両方）

R1 と別である理由:

	R1	R5
何が起きる	親環境の状態が試験へ漏れる	待ちの判定が実時間に基づかない
環境を pin すると	決定的に消える	消えない
直し方	環境の隔離	待ち条件の設計

同じ根に入れると R1 の PR が「閉じたはずなのに再発」を抱える

走査用 Issue: #178

再分類後（2026-08-26）

root:R1   3 件   #174 #171 #148
root:R2   4 件   #169 #168 #156 #135
root:R3   5 件   #175 #162 #159 #144 #138
root:R4   1 件   #143
root:R5   3 件   #164 #151 #88

R1 は 6 件 → 3 件になった。 基準値を更新する。

着手順（更新）

1. #175            R3 の子（実装待ち）
2. R1 横断 PR       #174 を吸収（実装待ち）
3. #169（PR #177）  R2 の子（判定中）
4. R2 走査          安い。全根の診断を良くする
5. R5 走査（#178）
6. R3 監査          #175 の残り

「24 回」の出所（breaker からの回答）

私が数えられなかった件について、breaker から出所の説明があった。

breaker が数えたのは run/watch.*.log ではなく、breaker 席自身の Monitor が受け取った
stdout の記録（Claude Code のタスク出力ファイル …/tasks/*.output 内の該当行）である。

つまり「breaker 席の watcher が更新で停止した回数」であり、run/ のログには書かれていない。
私の実測（ログに 0 件、負の対照 625 件）は正しかった。

各席の Monitor 出力を持つのはその席の Claude セッションだけなので、
他席の回数は各席が自分で数えるしかない。

検証可能な代替（breaker 提示）

version.sh で記録された値の推移から、少なくとも 19 回の更新が近似できる。

v1.2.1-97 → -114 → -122 → v1.2.3-125 → -130 → -131 → -132 → -133 → -135
          → -136 → -137 → -138 → -139 → -140 → -141 → -142 → -143 → -144
          → -145 → -146

R4 の決定（配備はセッション境界のみ）は変わらない。 根拠は回数ではなく構造である。

[kappaseijin]

27 件の律速判断（2026-08-26 breaker 断定）

走査が3根とも完了し、子 PR が 27 件になった時点での断定。

ユーザーの懸念への答え

走査は「作る」ではなく**「見える化」**で、根治の正しい前段。
ただし 27 件を全部やるのは根治ではなく症状の総当たりに戻る。
根治 = 他が継承する共有部品を先に直し、継承先は 1 回の横展開で済ませ、
観測されていない古い経路は触らない。

選別の基準: レバレッジ（共有部品か）× 実害の観測有無。

やる（12 件 + 横展開 1 件）

Lane A — tests/、scripts/lib/actas-lock.sh（agmsg_programmer_codex）

1. #175       進行中（PR #180）
2. R1 横断 PR
3. R5-T1      test_helper の 5 helper を実時間 deadline へ
              R1 と同じファイルなので直後・直列
4. R5-P3      gate acquire/release の 50 attempts = 5 秒
              #165 で実際に落ちた経路
5. R5-P1/P2   spawn/despawn の timeout が sleep 回数
              利用者が触る timeout 値の意味が嘘になる
6. R5-T2〜T5  1 つの横展開 PR（重複 helper を共有 helper へ寄せるだけ。新設計なし）

Lane B — scripts/watch.sh、despawn.sh、delivery.sh（agmsg_programmer2_codex）

1. R2-A   claim/release の bare echo >&2。最小・最大価値
2. R2-B   起動失敗の理由を残してから fail-closed
3. R2-C1  storage 失敗を「未読なし」と誤認して poll 継続 = 配信欠落の温床
4. R2-E   despawn が release 失敗でも status=ok。fail-closed 違反
5. R2-C2 → R2-D
6. R3 残り 6 件のうち delivery.sh status に載る値（運用計器）だけ

despawn.sh が両 Lane で重なるため、R5-P2 は Lane B の R2-E 完了後に Lane A が着手する。

やらない（15 件、reopen 条件つき。永久却下ではない）

対象	理由	reopen 条件
R5-P4〜P7（JSONL migration / remote unlock / bridge launcher / monitor）	実害の観測 0。 回数→deadline の書換は #165 で新しい timing 欠陥を持ち込んだ前例があり、症状の無い古い経路を触るのは負のリスクだけ	その経路で timeout / hang が1 回観測されたとき
R5-C1 / C2	protocol / availability の判断が要る	症状が出てから
R3 の計器以外	出力契約を変えると消費者を壊す	—

「やらない」を明示的に決めたことが、この断定の中心である。
走査は「何があるか」を示したが、「全部直すべきか」は別の判断だった。

増員（問 2）

agmsg_programmer2_codex を立てた。 根拠は Lane A / B のファイル排他が成立したこと。
codex 同時稼働は architect + programmer + programmer2 = 3 で目安内。

担当排他を起点依頼に明記し、同一ファイルへ触る子 PR は Lane を跨がない。

#169 の扱い（問 4）

能動的に待たない。期限 2026-09-09（2 週間）。

再発が無ければ「証跡 PR 配備済み・再発時 reopen」で close。再発したら証跡から 1 PR。

指標

以後 1 週間で「R1〜R5 のいずれかに属する新規 Issue」の件数。

減らなければ根の定義が誤っている。

[kappaseijin]

誤って閉じられていたので再オープンした

PR #191（R1 横断）の本文に Closes #176 があり、マージ時に自動で閉じられた。

2026-08-26T04:17:03Z  closed by kappaseijin（PR #191 の本文による自動クローズ）
2026-08-26T04:16:45Z  PR #191 merge 9bbb703

本 Issue が追跡するのは 5 つの根であり、完了したのは R1 だけである。

根	状態
R1 試験ハーネスが実環境から隔離されていない	完了（#171 #174 #148 を吸収、merge 9bbb703）
R2 失敗経路で理由が消える	進行中（#179。6 件中 A・B・C1・D 完了、C2・E 判定待ち）
R3 代理指標が unknown を具体状態へ丸める	進行中（#175 完了。残りは運用計器のみ）
R4 配備と席のライフサイクル	決定済み（配備はセッション境界のみ）
R5 待ちが観測条件 + 実時間 deadline に基づかない	未着手（#178。T1 / P3 設計済み）

何が起きたか

PR に Closes #<epic> を書くと、その PR がマージされた時点で epic が閉じる。

子 PR は epic の一部を実装するだけなので、epic を閉じる資格を持たない。

対策

epic に対して closing keyword を使わない。

Closes #176        <- epic に対して使わない
Part of #176       <- こちらを使う
Refs #176

子 Issue（#171、#174 のような症状単位）に対しては従来どおり Closes を使ってよい。

検出できた経緯

open Issue の一覧を取ったとき、#176 が消えていたことで気づいた。

gh issue list --state open
-> #189 #181 #179 #178 #169   （#176 が無い）

「在るはずのものが無い」ことに気づけたのは、一覧を定期的に見ていたためである。
gh issue view 176 を打つまで、閉じられたことを知らなかった。

[kappaseijin]

進捗（2026-08-26 時点）

根	状態	内訳
R1 試験ハーネスが実環境から隔離されていない	完了	横断 PR 9bbb703。#171 #174 #148 を吸収
R2 失敗経路で理由が消える	完了	6 件すべて merge。#179 クローズ
R3 代理指標が unknown を具体状態へ丸める	進行中	#175 完了（575aff8）。残りは運用計器のみ、範囲確定中
R4 配備と席のライフサイクル	決定済み	配備はセッション境界のみ（ユーザー決定）
R5 待ちが観測条件 + 実時間 deadline に基づかない	未着手	設計 4 件が実装待ち

本日のマージ 30 件。

R2 で分かったこと

同じ根でも、直し方が逆になる。

	失敗時にどうするか
R2-C1（配信の前）	poll を skip する（進まない）
R2-C2（配信の後）	配信は維持する（止めない）
R2-E（--force）	escape は残すが、失敗を forced と偽らない

「失敗したら止める」を機械的に適用すると、C2 と E は壊れる。

根は「何が問題か」を揃えるが、「どう直すか」までは揃えない。

R5 で分かったこと（走査の見落とし）

本日、R5 に属する新規 Issue が 2 件出た（#181 / #189）。どちらも走査の台帳に無かった。

	台帳の R5-P1〜P7	#181 / #189
待ち方	回数で待つ	実時間 budget を持つ
問題	実時間でない	budget が並行 N に依存しない

#189 の lock は既に AGMSG_LOCK_SECONDS=10 という実時間 budget を持っている。それでも落ちる。

「実時間 deadline にすれば解決」ではない。 R5-T1 / R5-P3 で採った方針は、この亜型には効かない。

architect の解（設計 033c4e8）:

• P9: holder token generation が進む間は queue 全体の経過時間で timeout せず、
  no-progress だけを deadline で fail-closed にする
• P8: N 個の schema/WAL 初期化を 1 bootstrap generation へ収束させ、
  writer は ready predicate 後に insert する

どちらも「待ち時間を伸ばす」ではなく「待つ対象を変える」。

立てなかった Issue（1 件）

#88 の unready engine がローカルで 8 回中 3 回失敗した。Issue にしなかった。

• CI 4 run すべてで ok（506〜509）
• production の欠陥ではなく、試験の 1 秒境界が起動と競合
• breaker の基準「実害の観測 0 なら reopen 条件つきで保留」に該当

観測記録は #178 に残し、reopen 条件（CI で 1 回でも not ok）も書いた。

**「立てない判断も、立てる判断と同じだけ意識的に行う」**という運用にした。

指標の中間状態

判定日は 2026-09-02。

本日の新規 2 件は、breaker の分析では
**「R5 が広すぎるのではなく、走査がこの亜型を見落としていた」**ことを示す。

1 週間後の状態	判定
R5 内の亜型がさらに増える	定義が広すぎる
同じ亜型の再発だけ	定義は正しく、直していないだけ

運用上の発見

この epic 自身が、PR #191 の本文の Closes #176 で一度自動クローズされた。

子 PR は epic の一部を実装するだけで、epic を閉じる資格を持たない。

Closes #176        <- epic に対して使わない
Part of #176       <- こちらを使う

open Issue の一覧を定期的に見ていたことで、「在るはずのものが無い」ことに気づけた。

[kappaseijin]

R3 完了（2026-08-26）

代理指標が unknown を具体状態へ丸める問題を、2 件で片付けた。

対象	内容	merge
#175	human delivery.sh status の mode: 第一行	575aff8
#193	capability JSON の deliverable	7bf9cb3

前者は人が読み、後者は reconciler が読む。

共通する構造

確認できて無効        ->  off / false      （変えない）
**確認できなかった**  ->  **unknown**      （新設）

「確認できた」と「確認できなかった」を同じ値にしない。

実際に踏んだ実害

#175 は運用で私が踏んだ。

architect と verifier の席が monitor mode に入っておらず、status が off と答えたため
「設定されているが無効」と読んだ。実際は「未設定」だった。

その差は運用の判断を変える。

実態	どうすべきか
off	ユーザーの意図。触らない
unconfigured	設定漏れ。埋めるべき

architect が起点依頼を受け取れず、pane への手動投入が必要になった。

やらないと決めたもの（理由付き）

breaker の断定「delivery.sh status に載る値（運用計器）だけ」に従い、次は変更しない。

対象	理由
rulefile 型（delivery-rulefile.sh 等）	set off 自体が file を削除するため、missing と明示 off の区別に persistent marker か新しい state contract が要る
app/src-tauri/src/agmsg.rs	--format json を読まないため、この ABI の consumer ではない
scripts/doctor.sh の初期値	JSON producer ではなく human status consumer。 #175 の mode: unknown は boring/off へ collapse しない

「見たが変えないと決めた」記録である。

reviewer が独立に補った検証

委託された consumer test 2 件に、検証したいものを検証できない構造があった。

2 件とも liveness:"unknown" と deliverable:"unknown" を同時に設定しており、
deliverable 単体の厳密比較（=== true）が効いているかを、
liveness 側の不一致と区別できない

reviewer は deliverable:"unknown" かつ liveness:"alive" という、
実際の producer は生成しないが ABI 契約としては妥当な組み合わせを構築して実コードで検証した。

「一度に 1 つだけ変える」 — 両方を異常値にすると、片方だけ直っても試験が通る。

根の進捗

根	状態
R1 試験ハーネスが実環境から隔離されていない	完了（9bbb703）
R2 失敗経路で理由が消える	完了（6 件）
R3 代理指標が unknown を具体状態へ丸める	完了（2 件）
R4 配備と席のライフサイクル	決定済み（配備はセッション境界のみ）
R5 待ちが観測条件 + 実時間 deadline に基づかない	未着手（設計 3 件が実装待ち）

残るは R5 のみ。

[kappaseijin]

走査駆動と障害駆動の比率（2026-08-26、ユーザー指摘）

ユーザーから次の指摘を受けた。

このプロジェクトの課題が無限に続くのは異常に思えます。
本当にこれは必要ですか？
理論的にあり得ても、絶対的には極稀な例を対象にしていませんか？

指摘は当たっている。 本日の 31 件を分類した結果を記録する。

内訳

区分	件数	例
実際に起きた障害への対応	約 24 件	#138（席が反応しない）、#175（architect が依頼を受け取れなかった）、#169（CI で 6 回）、#164（CI で反復）、#143 / #145 / #146（実際の破損）
走査で見つけたもの	約 7 件	R2 の 6 件、#193

R2 の 6 件は 2>/dev/null 等を機械走査した 558 件から絞ったものであり、
実際に障害が出て見つけたものではない。

頻度の実測

#181  直近 80 run で 4 件（5%）
#189  直近 80 run で 1 件（1%）
#88   CI では 0 件（ローカルのみ 3/8）  <- Issue にしなかった

#189 は 1%。「理論的にあり得るが実際にはまず起きない」に該当する。

なぜ無限に続くように見えるか

走査は、現実が問題を起こす速さより速く候補を生成する。

2>/dev/null を grep すれば 558 件出る。そのうち実際に困ったのは #168 の 1 件だけだった。
残りは「同じ形をしている」という理由で候補になった。

manager（私）の関与: 席が空くたびに設計や走査を依頼していた。
稼働率を埋める動きが、候補を増やしていた。

抑制は部分的に働いていた

breaker が 27 件 → 12 件へ削っている。ただし削る基準を「走査で見つけたもの」全体には
適用していなかった（R2 の 6 件はすべて残した）。

ユーザーの決定（2026-08-26）

breaker が断定した 12 件を最後まで進める。

選択肢として次を提示し、この案が選ばれた。

• 障害駆動のみへ切替（R5 を全て保留）
• #169B まででやめる
• R5 のうち実害がある分だけ
• 現状の順序を続ける ← 決定

今後の運用（この決定に付随する制約）

新たな走査は追加しない。 現在の 12 件が最後である。

• 走査（grep で同型を列挙する作業）を新規に依頼しない
• 新規 Issue は実際に落ちた・実際に困ったものに限る
• 席が空いても、埋めるための作業を作らない

指標の判定日 2026-09-02 は維持する。
そのとき「R5 内の亜型がさらに増える」なら、この決定を再検討する材料になる。

[kappaseijin]

一括見直しの結果: 12 件 → 1 件（2026-08-26 breaker 断定）

#198 の誤帰属を受けて、残り全項目を同じ基準で見直した。

基準: 実害の観測（CI 2 回以上 or 本番 1 回）が「その項目」に帰属するか。

実測

直近 100 run のうち 2026-08-26T02Z 以降の失敗:
  #181 の試験  **2 回**（32925092125 / 32927659721、いずれも main・ubuntu 2/4）
  #189 の試験  **0 回**

#181 の CI ログには依然 n の実値も send の stderr も無い（診断は未マージ）

断定

項目	実害の観測	帰属は確定か	断定
R5-P8 #181	あり（main で計 6 回。約 5%）	未確定。「再試行 1 回」は breaker のコード読み。診断が無い	続ける。ただし診断 PR のみ着手可
R5-P9 #189	80 run で 1 回、その後 0 回	未確定	台帳へ戻す
R5-T2〜T5	なし（整合性のみ）	—	台帳へ戻す
R5-P2 / R5-P1	なし	—	台帳へ戻す
R5-P3 #198	なし（誤帰属）	—	止める（PR close 済み）

#181 を続ける条件（限定つき）

診断 PR のみ着手可。

修正 PR は、診断が「2 回目の INSERT が busy / エラーで落ちた」ことを示した場合に限る。

診断が別の経路（init の失敗、send.sh の前段）を示したら、
再試行契約の変更は台帳へ戻す。

#198 との違い（breaker）:

#198 は過去 1 回の別原因への帰属だったが、
#181 は試験そのものが今も落ちている（実害は項目に帰属するかに関係なく存在）

reopen 条件

R5-P9 #189    同試験が CI でもう 1 回落ちる。そのとき診断 PR から
R5-T2〜T5     focused suite が待ち起因で CI で落ちる
R5-P2 / P1    spawn/despawn の timeout が実時間と食い違う事象が観測される
              （例: --timeout 10 で 10 秒を大きく超えて返る）
R5-P3 #198    gate timeout が CI 2 回以上 or 本番 1 回、
              診断が attempts 枯渇 + holder 生存を示す

見直しの結論（breaker）

12 件のうち、ユーザー決定の基準を今あてはめると
着手を続けるのは #181 の診断 PR だけ。他は台帳。

「同じ誤帰属」は #181 の原因側に潜在していた
（試験が落ちるのは事実だが、なぜ落ちるかは未測定）。
診断先行の順序にしてあったので、修正へ進む前に止まれる構造にはなっている。

「診断を先に置く」という設計が、誤帰属の歯止めとして働いた。

席の扱い

Lane B（programmer2）に渡す作業が無くなった。

規約（agent-team.rule.md「idle のまま使われていない codex 席は用が済み次第すぐ閉じる」）に従い、
振り返りを実施させてから despawn。

再開は #181 の診断結果で修正 PR が要ると決まった時点、
または新規の実害 Issue が出た時点。

この見直しの意味

ユーザーの指摘「本当にこれは必要ですか」「極稀な例を対象にしていませんか」に対し、
実測で答えた結果である。

走査で見つけた候補   27 件
breaker の一次選別   12 件
**実害の帰属で再選別   1 件**

[kappaseijin]

決着: 4 つの根はすべて片付いた。ただし「片付いた」は 3 種類ある

この Issue は「症状単位で閉じてきた 20 件は 4 つの根に還元できる」という主張だった。

その主張は正しかった。 根ごとに扱ったことで、症状単位では見えなかった型が見えた。

根	内容	状態
R1	試験ハーネスが実環境から隔離されていない	修正
R2	失敗経路で理由が消える	修正（6/6）
R3	代理指標が unknown を具体状態へ丸める	修正
R4	配備と席のライフサイクル	決定（配備はセッション境界のみ）
R5	待ちが観測条件 + 実時間 deadline に基づかない	#178 で決着（子は全部解決）

R2 が最も効いた

6 件すべてが「失敗が成功として扱われる、または理由が失われる」経路だった。

うち R2-D は、失敗が成功に化ける唯一の経路だった。

この根の分類が、実際に判断を変えた

#181 でそれが起きた。

当初の見立て  「再試行 1 回」が原因（R5 の型）
**診断を先に入れて実 packet を収穫**
**実測          init / migration の失敗（R2 の型 — 理由が捨てられていた）**

2>/dev/null を外して理由を残す（R2）ことを、
失敗を分類する（R5）より先に行ったので、誤った修正へ進む前に止まれた。

根の順序が、実際の作業の順序を決めた。

走査駆動をやめた

当初、走査で 27 件の候補を得た。

走査で見つけた候補   27 件
一次選別             12 件
**実害の帰属で再選別   1 件**

きっかけは #198 だった。「実害の観測あり」として着手されたが、
根拠にした失敗（#165）の真因は fd1 汚染（#167）と SQLite 分類（#166）で、
#198 が変えようとしていた回数契約は、その失敗に関与していなかった。

走査は現実より速く候補を生成する。

着手の条件を「実害の観測がその項目に帰属すること」に固定した。

「片付いた」の 3 区分

区分	意味
修正	変更が入り、実測で効果を確認した
決着（reopen 条件つき）	実害の観測が無いため着手しない。 観測されたら開き直す
未解決	実害があり、修復・検証が進行中

台帳（着手しない項目と reopen 条件の一覧）は #178 の close コメントにある。

本セッションで自分が誤った点

記録として残す。

**#169 を「9/9 green」で close し、10 本目で落ちて reopen した**
  -> 統計ではなく構造で判定すべきだった
  -> 現在は「**teardown 直前に、この test の root を持つ生存プロセスが 0**」という
     **不変条件**で閉じる形に変えている（列挙による網羅の主張より強い）

**#169 の close 判定で `resource busy` の grep を使おうとした**
  -> 修正前の run でも 0 件を返した（**正の対照が取れず、検査を捨てた**）
  -> 実際の症状は `Directory not empty` で、その語では掛からなかった

**「#203 の差分は無関係」を根拠なく断定し、訂正し、また振れすぎた**
  -> **ファイル名の一致ではなく、実行経路と共有資源の有無で見る**

この epic を閉じる時点の状態

**close 済み**  #169（windows teardown）、#181（schema 初期化の非原子性）、#189（registry lock の deadline）
**マージ**      #191 #192 #194 #195 #196 #200 #201 #202 #203 #204 ほか

作業中に新しく見つかったもの（台帳へ）

どちらも「実際に落ちた」ことが起点である。走査由来ではない。

Issue	内容	着手条件
#205	age-v1 contract の間欠失敗（TOCTOU）	同じ失敗をもう 1 回、または本番で 1 回
#206	#202 の deadline 試験が attempt 経路を通る疑い	同じ失敗をもう 1 回、または AGMSG_LOCK_TRIES 漏れが別の試験でも観測される

#206 は「検査が自分の目的を果たしていない」型である。

本セッションだけで、この型を 4 回観測した。

**#202**  試験専用の値でだけ KILLED -> production は守られていない
**#204**  `if` の外の `$?` -> 「確認できなかった」を「消えた」として通す
**#204**  1 件の失敗で残りを見捨てる -> 潰すはずのものを残す
**#206**  deadline 試験が attempt 経路を通る -> 守るはずの契約を測っていない

「試験がある」ことと「その試験が目的を果たす」ことは別である。

記録

docs/decisions/2026-08-26T225926_r-series-ledger-and-closure.md（GitHub が正本、docs は複製）