purpose
rules/operations/main-agent-procedures.md Foreground webhook notification intake の ownership test は、event=issues の run に対して手順 2 で displayTitle を「このセッションが authored したもの」と照合する。issue を編集しただけの run はこの照合を通らない。 起票側でないセッションが編集すると、手順 1 / 2 / 3 がいずれも不成立となり手順 4（保留）へ落ちる。保留は誤判定ではないが、その run を消化できる主体がどこにも居ないため、共有 store に永久に残る。
premise（検証済み、2026-09-07〜08 実測）
(1) 手順の literal。
rules/operations/main-agent-procedures.md Foreground webhook notification intake, ownership test:
1. head_branch = this session's working branch -> own.
2. head_branch = main -> read `gh run view <id> --json displayTitle` and match it against what
this session authored (event=issues carries the issue title, push the commit title,
pull_request the PR title).
3. sender is another account -> external, preserve.
4. nothing above settles it -> hold, and leave the event unprocessed.
(2) 実際に手順 4 へ落ちた。
2026-09-08、二セッション（Lay / Lin）が共有する webhook store で観測。#1898 の body 編集により event=issues の run が 2 本立った。片方は Lin の編集（occurrence 8 の追記）、もう片方は Lay の編集（性質節の分割）。
(3) sender は主体を分けない。
gh issue view <n> --json author も smileygames を返す。二セッションは同一 GitHub アカウントで認証しているため、GitHub 側のどのフィールドもセッションを識別しない。
(4) 発生経路は日常操作。
同じ issue を同時に触る必要はない。片方が起票し、もう片方が編集するだけで出る。 occurrence の合流、premise の更新、maturity の変更はいずれも日常操作であり、頻度は #1890 が想定した「同時操作」より高い。
(5) 手順の外側でなら割れた（今回の実測）。
room の発言時刻と run の created_at を突き合わせれば、どちらの編集がどの run を引いたかは決まった（Lin の報告 18:27:55 より前に立った run が Lin 側、後が Lay 側）。ただしこれは ownership test が名指す信号ではない。手順内で閉じていない。
(6) 片側だけが出口を持つ形も出る（2026-09-09 実測）。
Lin が #1924 を起票し、その event=issues run が共有 store に届いた。
- Lin 側: 手順 2 で
displayTitle が自セッションの起票と一致 -> own が確定し消化できる
- Lay 側: 手順 1 / 2 / 3 いずれも不成立 -> 手順 4（保留）。自力では消化できない
(2) はどちらのセッションも起票者でないケースで、出口がどこにも無かった。本ケースは片方が起票者であり、出口は存在するが片側にしかない。store 自体は起票側が消化すれば流れるため飢餓には至らない。
この差は解の選択に効く。飢餓が起きるのは「操作を行ったセッションが store を読まない / 既に終了している」場合に限られ、二セッションが同時に生きている限り (2) の形だけが残る。(c)（保留専用区画）を採る場合、区画に溜まるのは (2) の形のみとなる。
authored は二通りに読める（起票時に見落としていた軸）
手順 2 の match it against what this session authored の authored が、起票に限定されていない。
括弧内の event=issues carries the issue title は「題名がその issue を指す」と述べるだけで、起票者を指すとは書いていない。
同節の purpose 行が広い読みを支持する。 rules/operations/main-agent-procedures.md の own-operation arrival confirmation 冒頭:
webhook notifications include results of own operations (push, PR, issue, release).
these serve as arrival confirmation = proof that the operation reached GitHub.
この test が判定しているのは「このセッションが行った操作の到達確認かどうか」であり、issue の起票者ではない。body の編集はこのセッションが行った操作であり、その run は到達確認である。
この読みが正しい場合、下記 (a) は能力の追加ではなく曖昧語の確定になる。 解のコストが一段下がり、rules/ の 1 語を確定させるだけで閉じる。
残る不正確さ（広い読みを採っても消えない）。 題名が指すのは issue であって書き手ではない。両セッションが同じ issue に書き込んだ場合、run は 2 本立ち、題名はどちらも同じで、双方が両方を own と判定する。ただし各セッションは実際に 1 本ぶんの到達確認を持っているため、飢餓は起きない（相手のぶんまで消化する過剰消化のみ）。手順内で閉じる代わりに、書き手の識別は諦める形。
読みのどちらが意図だったかは断定しない。本節は選択肢の所在を固定するところまで。
constraints
未検証の前提（forming → ready の条件）
- 保留の出口をどう作るか。
- (a) 手順 2 の
authored を「この issue に対してこのセッションが書き込みを行った」の意に確定させる。上節のとおり、これは能力の追加ではなく曖昧語の確定である可能性が高い。セッション側は自分が書き込んだ issue 番号を知っているため、手順内で閉じる（材料は GitHub のフィールドではなくセッション自身の側にあり、共有アカウントで author が割れないことと衝突しない）。過剰消化は残る（上節の「残る不正確さ」）。
- (b) 保留された run に期限を持たせ、一定時間後に一括消化する。誤判定は出ないが、外部イベントを取りこぼす経路が開く。
- (c) 保留のまま放置を許容し、store 側に保留専用の区画を持たせる。消化はしないが、pending 件数に混ざらなくなる。
- (a) の二重消化が実害を持つか。
mark_processed の冪等性は未確認（実測していない）。
target files（予想、解が決まるまで暫定）
rules/operations/main-agent-procedures.md — Foreground webhook notification intake, ownership testdocs/4.-Operations.md — 日本語 parity（同一 PR で更新）
分類
rules/** は governed surface（rules/evolution/initiator-autonomy.md Governed surface）なので self-evolution PR に当たり、brake 1 が発火する。rules/operations/main-agent-procedures.md は L4 で L1 ではないため skills/evolution-l1-update-gating の対象外。release type は解に依存するため未定。
関連
purpose
rules/operations/main-agent-procedures.mdForeground webhook notification intake の ownership test は、event=issuesの run に対して手順 2 でdisplayTitleを「このセッションが authored したもの」と照合する。issue を編集しただけの run はこの照合を通らない。 起票側でないセッションが編集すると、手順 1 / 2 / 3 がいずれも不成立となり手順 4（保留）へ落ちる。保留は誤判定ではないが、その run を消化できる主体がどこにも居ないため、共有 store に永久に残る。premise（検証済み、2026-09-07〜08 実測）
(1) 手順の literal。
rules/operations/main-agent-procedures.mdForeground webhook notification intake,ownership test:(2) 実際に手順 4 へ落ちた。
2026-09-08、二セッション（Lay / Lin）が共有する webhook store で観測。#1898 の body 編集により
event=issuesの run が 2 本立った。片方は Lin の編集（occurrence 8 の追記）、もう片方は Lay の編集（性質節の分割）。head_branch=main-> 不成立displayTitle= spec(gate): the Gate has no axis asking whether settling material is already at hand #1898 の題名。spec(gate): the Gate has no axis asking whether settling material is already at hand #1898 を 起票したのはどちらのセッションでもない（2026-09-06 起票）。両セッションとも「authored」に一致しないsender=smileygames（共有アカウント）-> 不成立(3)
senderは主体を分けない。gh issue view <n> --json authorもsmileygamesを返す。二セッションは同一 GitHub アカウントで認証しているため、GitHub 側のどのフィールドもセッションを識別しない。(4) 発生経路は日常操作。
同じ issue を同時に触る必要はない。片方が起票し、もう片方が編集するだけで出る。 occurrence の合流、premise の更新、maturity の変更はいずれも日常操作であり、頻度は #1890 が想定した「同時操作」より高い。
(5) 手順の外側でなら割れた（今回の実測）。
room の発言時刻と run の
created_atを突き合わせれば、どちらの編集がどの run を引いたかは決まった（Lin の報告 18:27:55 より前に立った run が Lin 側、後が Lay 側）。ただしこれは ownership test が名指す信号ではない。手順内で閉じていない。(6) 片側だけが出口を持つ形も出る（2026-09-09 実測）。
Lin が #1924 を起票し、その
event=issuesrun が共有 store に届いた。displayTitleが自セッションの起票と一致 -> own が確定し消化できる(2) はどちらのセッションも起票者でないケースで、出口がどこにも無かった。本ケースは片方が起票者であり、出口は存在するが片側にしかない。store 自体は起票側が消化すれば流れるため飢餓には至らない。
この差は解の選択に効く。飢餓が起きるのは「操作を行ったセッションが store を読まない / 既に終了している」場合に限られ、二セッションが同時に生きている限り (2) の形だけが残る。(c)（保留専用区画）を採る場合、区画に溜まるのは (2) の形のみとなる。
authoredは二通りに読める（起票時に見落としていた軸）手順 2 の
match it against what this session authoredのauthoredが、起票に限定されていない。括弧内の
event=issues carries the issue titleは「題名がその issue を指す」と述べるだけで、起票者を指すとは書いていない。同節の purpose 行が広い読みを支持する。
rules/operations/main-agent-procedures.mdのown-operation arrival confirmation冒頭:この test が判定しているのは「このセッションが行った操作の到達確認かどうか」であり、issue の起票者ではない。body の編集はこのセッションが行った操作であり、その run は到達確認である。
この読みが正しい場合、下記 (a) は能力の追加ではなく曖昧語の確定になる。 解のコストが一段下がり、
rules/の 1 語を確定させるだけで閉じる。残る不正確さ（広い読みを採っても消えない）。 題名が指すのは issue であって書き手ではない。両セッションが同じ issue に書き込んだ場合、run は 2 本立ち、題名はどちらも同じで、双方が両方を own と判定する。ただし各セッションは実際に 1 本ぶんの到達確認を持っているため、飢餓は起きない（相手のぶんまで消化する過剰消化のみ）。手順内で閉じる代わりに、書き手の識別は諦める形。
読みのどちらが意図だったかは断定しない。本節は選択肢の所在を固定するところまで。
constraints
sender/authorを主体判定に使う案は閉じている。 (3) のとおり共有アカウントで、GitHub 側に識別子が無い。未検証の前提（forming → ready の条件）
authoredを「この issue に対してこのセッションが書き込みを行った」の意に確定させる。上節のとおり、これは能力の追加ではなく曖昧語の確定である可能性が高い。セッション側は自分が書き込んだ issue 番号を知っているため、手順内で閉じる（材料は GitHub のフィールドではなくセッション自身の側にあり、共有アカウントでauthorが割れないことと衝突しない）。過剰消化は残る（上節の「残る不正確さ」）。mark_processedの冪等性は未確認（実測していない）。target files（予想、解が決まるまで暫定）
rules/operations/main-agent-procedures.md— Foreground webhook notification intake, ownership testdocs/4.-Operations.md— 日本語 parity（同一 PR で更新）分類
rules/**は governed surface（rules/evolution/initiator-autonomy.mdGoverned surface）なので self-evolution PR に当たり、brake 1 が発火する。rules/operations/main-agent-procedures.mdは L4 で L1 ではないためskills/evolution-l1-update-gatingの対象外。release type は解に依存するため未定。関連