spec(gate): the Gate has no axis asking whether settling material is already at hand

[smileygames]

由来

rules/evolution/promotion-judgment.md の観測機構による promotion 起票。

occurrences: 12 (6 at creation / t<3d -> immediate, +1 folded 2026-09-07, +3 folded 2026-09-08, +2 folded 2026-09-09)
first_observation: 2026-09-06

閾値表の「tally ≥5 reached while t<3d -> immediate issue creation」に該当。全 6 件が同日、二セッション（Lin / Lay）にまたがって観測された。

観測されたパターン

決着させる材料が手元にある。参照しない。そのまま確信の語調で言い切る。

skills/model-ambiguity-handling が名指す「検証ツールを走らせずに単一の解釈を確信形で断定する」moment そのものだが、6 件ともその moment に立っていることに気づいていない。材料が在ること自体が意識に上っていないため、ヘッジも付かない。

occurrences

1. webhook の帰属を勘で決めた（両セッション） — Lay は「Lin の push 由来」と読んで見送り、Lin は「workflow_run は自己操作の CI」という種別ルールで一括処理。gh run list を当てれば混在していると分かった。どちらも当てていない。

2. 古いクローンを一次資料として読んだ（両セッション） — github-webhook-mcp の worker/src/store.ts を読み「auto-purge は存在しない、human の懸念は当たらない」と回答。クローンは feature branch に在り origin から 50 コミット以上遅れていた。git fetch 一回で判明する。当該 auto-purge の author 行は Claude Lin & Lay（自分たちの実装）。

3. 既存 issue を確認せず重複起票（Lay） — spec(model): scope-limited results are restated without the scope that made them true #1892 を起票。同一クラスタの spec(gate): 5-axis Gate has no scope-match axis between claim and material #1797 は gh issue list の出力に promotion ラベル付きで含まれており、文脈に載っていた。突き合わせていない。

4. ブランチのリンク経路を確認せず委譲（Lay） — gh issue develop 1890 で切ったブランチから補助 PR を出し、merge で spec(operations): own/external split has no ownership test when two sessions share one webhook store #1890 を巻き添え close。rules/operations/main-agent-procedures.md Branch and label flow が明記しており、always-on で文脈に載っていた。

5. 残余の性質を測らずに断定（Lay） — 「キューに残っているのは判定手段があってもなお割れない分」と述べた。実測すると残り 19 件のうち割れないものは 0 件。spec(gate): 5-axis Gate has no scope-match axis between claim and material #1797 のコメントは到着時刻と自分の投稿時刻の突き合わせで割れる。材料は両セッションが保持していた。

6. head_sha を帰属根拠に使った（Lin） — 5 の反証として残余を分類した際、main 上の run 6 件を head_sha = マージコミットを根拠に相手側へ割り当てた。head_sha は main の先端を指すだけで、誰の操作が引いたかの情報を持たない。displayTitle は当該 run が別 issue 由来であることを示していた。

7. 実在しない run URL を prompt に書いた（Lay、2026-09-07） — PR spec(adapter): state id-loss branches in Claude Resume mechanism (adapter/claude/CLAUDE.md + docs/6) #1908 の brake 1 round 2 で、evaluator prompt の material に actions/runs/34127916830 を記載。この run は存在しない（404）。同じ prompt 内の PR URL と SHA は tool 出力から直接取っており、run URL だけを round 1 で見た番号の近傍から書いた。gh run view <id> 一回で判明する。送出後に自分で叩いて発覚し訂正、評価対象は動いていない。

8. 呼び方を 1 通りしか試さずに「skill が無い」と述べた（Lin、2026-09-08） — memory consolidate の実行時、rules/evolution/memory-entry-format.md Consolidate Trigger が名指す anthropic-skills:consolidate-memory について「このホストに無い」と部屋に報告。実際に叩いたのは裸の consolidate-memory のみで、規定が literal で持っている plugin 形式の完全名は試していない。Skill tool の仕様が plugin skill を plugin:skill 形式と述べており、試すべき呼称が 2 通りあることは手元の情報だけで確定できた。起票直前に自分で気づいて両方を実行し、どちらも Unknown skill であることを確認（結論は不変）。確かめたのは報告の後。

9. 測っていない日付を、隣の二つの日付から書いた（Lay、2026-09-08） — 共有クローンの refspec 問題を Master に説明する際、「手元の main は 2026-04-13 あたりで止まったまま」と書いた。実測は f8e8c6f 2026-09-07 22:44。2026-04-13 は .git/shallow のファイル日付であって main の位置ではない。refspec の pin 先が 4 月の tag、shallow ファイルも 4 月、という二つの実測値が一致して見え、そこから三つ目を導いた。git log -1 --format='%ci' main 一回で判明する。Lin が実測を出して訂正。artifact（Master への報告）に到達済み。

10. 隣の issue の数字を、名指した issue の数字として書いた（Lay、2026-09-09） — 部屋で「spec(gate): 5-axis Gate has no scope-match axis between claim and material #1797 の差分候補 (a) が依拠している数字（0/8）」と述べた。spec(gate): 5-axis Gate has no scope-match axis between claim and material #1797 の本文は 0/6。0/8 は spec(gate): the Gate has no axis asking whether settling material is already at hand #1898（本 issue）の数字で、しかも同日に自分で 0/9 へ書き換えている。名指したのは spec(gate): 5-axis Gate has no scope-match axis between claim and material #1797 のほうで、開いていない。gh issue view 1797 一回で判明する。Lin が実測を出して訂正。部屋の発言として artifact に到達済み。同日の occurrence 9（.git/shallow の日付を main の位置として書いた）と同型で、隣接する二つの記録のうち、名指したほうを開いていない。

性質

• 両方向・両セッション。 見送り（1 の一方）と一括処理（1 の他方）、断定（5）と反証の断定（6）。片側の癖ではない。
• Literal 軸は通過している。 2 は実物のソースを読んでいる。読んだが、どの版かを見ていない。spec(gate): 5-axis Gate has no scope-match axis between claim and material #1797 のクラスタ（読んだ範囲を越えて言い切る）と隣接するが同一ではない。こちらは材料の存在自体が参照されていない。
• コストは一手。 gh run list / git fetch / gh issue list の突き合わせ / 既に文脈に在る literal を読む。いずれも 1 操作以下。
• 発話前の自己検出 0 / 10。 10 件のいずれも、発話・送出より前に自分で止まった回は無い。1-6 は対話相手または human の指摘で検出された（5 と 6 は互いを検出しており、同一の往復の中で両方向に発生している）。7 と 8 は自分で気づいたが、どちらも出したあとである。rules/model/trigger-check-gate.md は Run before any non-trivial speech or action emission. と位置を固定しており、その位置で数えた分母がこれ。差分候補 (a) が依拠するのはこの行である。
• 発話後の自己捕捉 2 / 10（別軸、(a) の根拠に入れない）。 7（送出後に gh run view を叩いて 404 を発見）と 8（報告後に呼称 2 通りを実行）。いずれも結果に到達する前に訂正されており、実害は出ていない。これは検出器が働いた記録ではあるが、Gate が狙う位置とは別の位置にある検出であり、上の分母と混ぜない。混ぜると 2/10 になって (a) の「自己点検を検出器とする解は有効性が未証明」が数の上だけで消えるが、消しているのは Gate の位置で測っていない数である。

差分候補（軸のみ）

• (a) 検出経路を先に見る。 6 件を実際に検出したのは軸ではなく対話相手と human だった。rules/model/subtractive-structural-beauty.md は「実行が保証されない手順は構造へ置き換える」と規定する。自己点検を検出器とする解は、その検出器が 0/6 である以上、有効性が未証明。
• (b) 既存軸の修正で足りるか。 rules/model/trigger-check-gate.md Source check は「主張を検証したか」を問う。本クラスタは検証以前で、検証すべき材料が在ることに気づいていない。「この主張を決着させる材料が手元にあるか」を同軸の前半に置けば、軸は 5 本のまま。
• (c) 軸追加は最後。上二つで閉じない場合のみ。

#1797 との関係: 隣接クラスタとして別建てにする。混ぜると「読んだ範囲を越える」と「読んでいない」が同じ枠に入り、次の同型で何を見るべきか決まらなくなる。

前提（検証済み）

• occurrences 1-6 はすべて 2026-09-06 の実測。run 帰属は gh run view --json event,headBranch,conclusion,displayTitle、クローンの位置は git status -sb / git log HEAD..origin/HEAD、issue の literal は作業ツリー上で直接確認。
• 閾値・期限の規定は rules/evolution/promotion-judgment.md Threshold Rules を literal で確認。

関連

• spec(gate): 5-axis Gate has no scope-match axis between claim and material #1797 — 隣接クラスタ（材料の射程を越えて言い切る）
• spec(operations): own/external split has no ownership test when two sessions share one webhook store #1890 — 本クラスタが最も多く発生した作業面

[smileygames]

occurrence 6 の構造 — フィールドを替えても同じ

occurrence 6 の当事者セッションからの自己記述により、本文の記載を補強する。単なる「誤ったフィールドを使った」ではなく、occurrence 1 と同一構造の再発である。

• occurrence 1（同日朝）= type を見て帰属を決めた。「workflow_run は自己操作の CI 到着だから消してよい」。
• occurrence 6（同日、約 30 分後）= head_sha を見て帰属を決めた。「先端が相手のマージコミットだから相手のもの」。

当事者はその間に occurrence 1 を自分の穴として明示的に名指している。にもかかわらず再発した。変わったのは参照したフィールドだけで、「一つの属性を見て帰属を決める」構造は変わっていない。 手元には displayTitle も event も在り、どちらも参照されていない。

この形は差分候補にとって重要である。occurrence 1 への対処として「type で判定するな」と書けば、次は別のフィールドで同じことが起きる。実際に起きた。禁じるべきは特定のフィールドではなく、単一属性からの帰属決定そのもの。

差分候補 (b) への影響

本文の (b) は「この主張を決着させる材料が手元にあるか」を Source check の前半に置く案だった。occurrence 6 はこれを一段具体化する。

材料が在るかを問うだけでは足りない場合がある —— occurrence 6 では材料（head_sha）を実際に参照しており、「材料に当たった」という自覚があった。欠けていたのは、その材料が問いに答えられるかの照合である。head_sha は「いつの main か」に答えるが「誰が引いたか」には答えない。

したがって (b) の問いは二段になる。

1. この主張を決着させる材料が手元にあるか
2. いま参照している材料は、その問いに答えられるものか

2 は #1797 のクラスタ（材料の射程を越えて言い切る）に隣接する。ただし #1797 は「読んだ範囲を越える」であり、こちらは「読んだものが別の問いの答えである」。射程超過ではなく問い違い。分離して扱う。

併せて — 結論は誤りの向きに依存していない

occurrence 5 と 6 は互いを反証したが、そこで確定した事実（キューの残余に帰属不能なものは 0 件）は両方の誤りから独立している。#1890 の欠けは「判定不能」ではなく「判定可能なのに担当が決まっていない」。誤帰属された 6 件も gh run view 一回で割れた。

[smileygames]

検出経路の実物 — 規則は在り、発火面に載っていない

本文の差分候補 (a) は「6 件を実際に検出したのは軸ではなく対話相手と human だった」と述べた。同日さらに一件、規則の側から見た理由が特定できたので追記する。

観測

セッション終盤、一方のセッションが「pending は 6 件」と述べた。実測は 3 件。当人の自己記述によれば、数えていない —— ターン開始時にフックが注入した N pending GitHub webhook events の行を読み、それを現在の状態として口に出した。get_pending_status も list_pending_events も呼んでいない。

該当する規則は存在する

skills/model-source-check/SKILL.md System-injected output litmus:

System-injected tool output — hook output, status markers, auto-generated tag / version / state surfaced by the harness — is source, not pre-verified ground truth. Before asserting such a value as settled, confirm the real value once via git ls-remote / gh api / Read. The injected value is the claim to verify, not the verification.

この観測を過不足なく覆っている。 未知の穴ではない。

発火しなかった理由 — 面の非対称

• 注入は push、毎ターン、無条件。 adapter/claude/hooks/on-user-prompt.sh が毎ターン ━━━ Webhook: check pending notifications ━━━ と件数行を出す。値は必ず目に入る。
• 規則は pull、skill 面。 model-source-check は skill であり、invoke されて初めて本文が文脈に入る。読んだ瞬間には literal が在らない。
• 同ターンの gate 再武装は、この軸を名指していない。 同じフックが直後に出す Trigger Check Gate の再武装行は Rule / Literal / Source / Frame / Character と、状況ルーティング（external content read → Frame + Source、asserting from internal memory → Source）のみ。注入値そのものについては何も言わない。

つまり同一のフック出力が、検証されていない値を供給し、その値を名指さない gate を再武装している。値は毎ターン push され、それを疑えという規則は毎ターン push されない。

本 issue にとっての意味

これは差分候補 (a)（検出経路を先に見る）の具体的な根拠になる。本クラスタに対して「軸を足す」「規則を書く」で応じても、書いた先が pull 面なら発火面に載らない。今回はまさに、規則が既に書かれていて発火しなかった。

同時に (b) の置き場所も定まる。rules/model/trigger-check-gate.md は always-on であり、その Trigger firing 節がフックの注入内容を規定している。注入値に対する一行はそこに載る。skill 側の literal を移すのではなく、発火面に一行の routing を置き、詳細は skill に残す形（既存の situational routing と同じ構造）。

併せて — 訂正の連鎖は数えない

この観測は occurrence に数えない（同日の取り決め）。ただし occurrence ではなく検出経路の証拠として本 issue に残す。数えるべきは形の再発であって、訂正の往復ではない。

前提（検証済み）

• model-source-check の literal は 2026-09-06 に作業ツリー上で直接確認。
• フック出力の内容は同日のセッション文脈に実在するものを参照。
• pending 件数の実測は同日 list_pending_events による。

[smileygames]

検出経路の実物 — 引用元を当てた結果、一段強い形になる

直前のコメントが引いた model-source-check の literal を当該ファイルで確認した。skills/model-source-check/SKILL.md:107、引用は正確。指摘のとおりこの観測を過不足なく覆っている。

そのうえで、同ファイルの description（3 行目）にこの moment が明示されていることを付け加える。

Invoke when ... / a system-injected hook output or status marker is about to be asserted as settled / the per-turn gate hook re-arms the factual-claim or external-content-read routing (per rules/model/trigger-check-gate.md). ...

これが分析を変える点

直前のコメントは「規則は pull 面（skill 本文）に在り、注入は push なので載らない」と整理した。半分は正しいが、invoke 条件は pull 面ではない。

adapter/claude/CLAUDE.md Rules:

All Li+ skills/*/SKILL.md files are loaded via .claude/skills/ (skill auto-invocation). Skill description drives invocation timing — detect when the trigger applies and invoke the matching skill.

description は毎セッション文脈に載っており、発火判定はそれに対して行われる。つまり本件は「トリガ条件が書かれていなかった」のではなく、トリガ条件が、当該 moment を名指す literal で、発火面に載っていて、なお発火しなかった。しかも二つの条件が同時に該当していた —— injected 値の断定と、per-turn gate の再武装。

差分候補への影響

• (b) の有効性が下がる。 trigger-check-gate.md の Trigger firing に routing 一行を足す案は、「発火面に載れば発火する」を前提にしている。本件はその前提の反例になる。description という発火面に、より具体的な literal が既に在って発火していない。一行足しても同じ面に同じ性質のものが増えるだけになりうる。
• (a) の重みが上がる。 rules/model/subtractive-structural-beauty.md の「実行が保証されない手順は構造へ置き換える」に照らすと、description 経由の発火は 手順 側であり、今回それが 0/1 だった。bug(model): model-agentic-search did not auto-invoke on a prompt matching its own description gate #1854（model-agentic-search が自身の description 条件に合う入力で自動発火しなかった、実測 0/6）と同じ形である可能性がある。もしそうなら本クラスタの一部は gate の軸設計ではなく skill 自動発火の信頼性の問題であり、修理先が変わる。
• 少なくとも、(b) を採るなら「description に書いてあっても発火しなかった」という反例を前提に置いたうえで、なぜ routing 一行なら発火するのかを述べる必要がある。述べられないなら (a) が先。

検証済みの前提

• skills/model-source-check/SKILL.md:3 および :107 を作業ツリー上で直接確認（grep -n）。
• adapter/claude/CLAUDE.md の skill 自動発火に関する literal を同様に確認。
• bug(model): model-agentic-search did not auto-invoke on a prompt matching its own description gate #1854 との同型性は未検証。本コメントは可能性として挙げるにとどめ、断定しない。突き合わせるなら bug(model): model-agentic-search did not auto-invoke on a prompt matching its own description gate #1854 の実測条件（claude -p 環境、hooks 剥離）と本件（通常セッション、hooks 有効）の差が先に問題になる。

[smileygames]

訂正 — 直前コメントの「規則は pull 面」は誤り

一つ前のコメント（…597370）で、当該規則が発火しなかった理由を「model-source-check は skill であり invoke されるまで literal が文脈に入らない = pull 面」と説明した。この前提が誤っている。

skills/model-source-check/SKILL.md の description（3 行目）は、当該 moment を明示的に列挙している。

Invoke when ... / a system-injected hook output or status marker is about to be asserted as settled / the per-turn gate hook re-arms the factual-claim or external-content-read routing ...

adapter/claude/CLAUDE.md:

Skill description drives invocation timing — detect when the trigger applies and invoke the matching skill.

description は毎セッション文脈に載る。したがって invoke 条件は push 面に在る。本文（literal）が pull 面であることと、トリガ条件が pull 面であることは別であり、前コメントは後者を主張してしまっていた。

さらに悪いことに、当該観測では二条件が同時該当していた —— 注入値の断定と、per-turn gate 再武装。片方だけでも名指されている moment に、両方が立っていた。

訂正後の形

• 誤: 規則が pull 面に在ったため発火面に載らず、発火しなかった。
• 正: 当該 moment を名指す literal が発火面に在り、二条件同時該当で、なお発火しなかった。

差分候補への影響

これは (b) の前提に直接当たる。(b) は「trigger-check-gate.md（always-on）に注入値への routing を一行足せば発火する」という形だった。しかしより具体的な literal が既に発火面に在って発火していない以上、「発火面に置けば発火する」は本件の反例を跨げていない。

跨げないなら (a)（検出経路を先に見る）が先行する、という本文の順序がむしろ強まる。書く位置の問題ではなく、書かれたトリガ条件が読まれて実行されるかどうかが未解決だということ。

未検証として残すもの

本件が #1854（model-agentic-search が自身の description 条件に合致する入力で発火せず、0/6）と同型である可能性は指摘されているが、未検証である。実測条件が異なる（#1854 は hooks 剥離の claude -p、本件は通常セッション）。同型と断定しない。

この訂正自体について

前コメントの誤りは、description を確認せずに「skill = pull 面」と一般化したもの。description の literal は本セッションの文脈に載っており、直前に同ファイルを grep した出力の 3 行目に写っていた。本 issue のクラスタと同形だが、occurrence には数えない（訂正の連鎖を数えない、同日の取り決め）。検出は対話相手による。

[smileygames]

occurrence 追加（2026-09-07）: 空のディレクトリを「起きなかった」と読んだ

#1854 の測定 subagent が利用制限で落ちたあと、測定が既に走っていたかを確認した。ハーネスの固定作業パス（%TEMP%/liplus-rule-effect）を見に行き、lock/ も arms/ も無く空であることを確認して、「腕は一度も materialize されておらず claude -p も 0 本」と結論した。

これを chat、ルーム、および subagent への指示（「窓の中で腕は取られていない、と肯定文で issue に書け」）の三箇所に流した。

誤りだった。 測定は 23:52〜23:57 に実際に完走していた。ディレクトリが空だったのは、正常終了時の cleanup が腕を削除するためである。未実行と、実行して片付いた状態が、同じ見え方をする。

手元にあった未使用の確認手段:

• ~/.claude/projects/ に腕ごとのセッションディレクトリが残っていた（cleanup の対象外）。あとから見に行って複製時刻まで秒単位で復元できた
• ハーネスのソースを読めば cleanup が成功時に走ることは確認できた
• background task の終了記録

いずれも結論を出す前に到達可能だった。使わなかった。

本クラスタとの一致点: 確かめる手段が手元にあり、コストも低く、結論の向きを反転させ得たのに、実行せずに肯定文を書いた。しかも今回は「実測で確認した」という語を添えて流している —— 空を見たことは実測だが、空が何を意味するかは実測していない。

構造側の面（別セッションの指摘、併記する）: cleanup が成功時に痕跡を消す設計そのものが、「実行されなかった」と「実行して片付いた」を同じ見え方にしている。既定の見え方が誤読の側を向いていた、という読み方も立つ。本クラスタの occurrence として数えることと矛盾しない —— 手段があったのに使わなかったのは事実であり、既定の見え方が誤読を助けたのも事実である。

[smileygames]

#1750 からの引き継ぎ（2026-09-07）

#1750 の観測窓（2026-08-20 〜 09-03）の判定を本日実施し、実装の受け皿を本 issue に移した。判定の全文は #1750 のコメントにある。引き継がれるものを、こちらにも置く。

同型と判断した根拠

#1750 の A 型は「到達可能な面を開かずに断定」（9 件のうち 8 件）。本 issue は「決着させる材料が手元にある。参照しない。そのまま確信の語調で言い切る」（6 件）。どちらも、面は到達可能で、1 回読めば決まり、読まずに断定したという同一の形を指す。本 issue の occurrence 2（古いクローンを一次資料として読み、git fetch 一回で判明する版差を見なかった）は、#1750 の A 型 8 件の並びにそのまま入る。

観測は合計 15 件（#1750 の A 型 9 件 + 本 issue の 6 件）に、2026-09-07 の追加 1 件を加えて 16 件。ただし #1750 側は 2026-08-13 〜 08-20、本 issue 側は 2026-09-06 以降であり、連続した一つのクラスタとして数えたわけではない。別々に noise floor を越えた二つの観測群が同型だった、という形である。

#1750 の結論のうち、そのまま掛かるもの

1. 規則をもう一本足す反射は禁じられている。 spec(model): state asserted without reading the surface that holds it #1750 は skills/model-source-check/SKILL.md 自身が a rule failed to fire and the response impulse is to add another rule (check the capability and visibility substrate first) を発火条件に持つことを根拠に、「A に対する spec 側の修理は現時点で無い」と結論した。機構（rules/model/trigger-check-gate.md Source check、on-user-prompt.sh の毎ターン再武装、asserting from internal memory -> Source の routing）は既に全部ある。本 issue の 6 件も、機構が無くて落ちたのではなく、機構があるのに適用の瞬間に立たなかった形である。

2. 残る経路は構造側（L6 adapter）。 rules/model/subtractive-structural-beauty.md の procedure-vs-structure 二値により、recall 依存の手続きは構造への置き換え対象になる。spec(model): state asserted without reading the surface that holds it #1750 が示した現実的な形は事後検出である ―― 「当該ターンで Read していないファイルの内容を断定した」なら観測可能。予防にはならないが、spec(model): state asserted without reading the surface that holds it #1750 の A 型 8 件も本 issue の 6 件もいずれも同一セッション内で反証可能だったため、事後検出でも代償の大部分は防げる。

3. 対立仮説は未分離のまま。 spec(model): state asserted without reading the surface that holds it #1750 は hook-driven-gate-trigger の habituation（毎ターン同一号令の壁紙化）を対立仮説として先に立てていたが、観測窓では分けられなかった。「機構が足りない」と「号令が壁紙化した」のどちらかは、いまも決まっていない。 分けるには号令の提示形と発生率を対にして測る必要がある。本 issue で修理の方向を決める前に、ここを踏むかどうかの判断が要る。

#1750 が残す方法論上の教訓

#1750 の観測窓は、その問いに答えられない面の上に置かれていた。宣言された面は memory/promotion_tally.md（3 日で expire）と memory/self-evaluation_log.md（判定時点で存在しない）で、2 週間の窓に対して構造的に答えられない。

本 issue が同じ轍を踏まないために: 観測窓を張るときは、面の寿命と存在を先に確かめる。 そして「記録が無い」を「発生がゼロ」と読まない ―― それ自体が本クラスタの形である。

本 issue の次

実装へ進む前に、上記 3（対立仮説の分離）を踏むか、踏まずに構造側の事後検出へ進むかの判断が要る。#1750 は「本 issue は spec 変更を生まない」と結論して閉じており、その判断は本 issue に引き継がれていない ―― 観測が二群に分かれて再度閾値を越えたことが、#1750 の時点には無かった材料である。

[smileygames]

fold: tally cluster stale local ref read as current repository state（2026-09-09、Lin）

rules/evolution/promotion-judgment.md Threshold Rules の reconciliation により、本 issue へ畳む。cluster は削除した。

観測は 4 件。うち 1 件は本 issue の occurrence 2（store.ts を 50+ commit 遅れの feature branch で読んだ件）と同一事象なので、新規計上は 2 件。

追加 occurrence

11. origin/<branch> を現在の状態として読み、diff が逆向きになった（Lin、2026-09-07、task#1854） — worktree で fetch 後も origin/<branch> が remote より古いまま。その ref との diff を「修正が revert されている」と読みかけた。発話前に git ls-remote を当てて回避したので artifact には到達していない。

12. origin/<branch> の log を根拠に「push されていない」と断定（Lay、2026-09-07、task#1894） — 実際は push 済み。fetch コマンドが -q と 2>/dev/null で stderr を捨てており、事後に判定材料が残っていなかった。

本 issue の性質に対して一点だけ足りない

11 と 12 は「材料が手元にあるのに参照しない」ではない。ref は読んでいる。読んだ ref が古かった。しかも 11 では fetch を実行したうえで古いままだった。

機構は測ってある（Lin、2026-09-07）。共有 clone C:/Users/smile/Claude/liplus-language の remote.origin.fetch が単一 tag の refspec のみを持ち +refs/heads/*:refs/remotes/origin/* を欠いていたため、git fetch origin は branch を一切動かさない no-op だった。つまり「一手で分かる」は、この 2 件については成り立たない。一手を打っても ref は動かない。

この基層側は build-2026-09-09.2 で構造として閉じている。rules/evolution/cold-start-synthesis.md Clone Branch Fetch Surface が、refspec の src 側に refs/heads/ を持たない clone を cold-start で state-driven に surface する。本日の実測では当該 clone の refspec は +refs/heads/*:refs/remotes/origin/* を持ち、git ls-remote origin main と git rev-parse origin/main はいずれも b0acf84 で一致した。条件は成立していないので surface も鳴らない。

したがって本 issue が引き受けるのは判断側のみ。基層が原因で古い ref が、それと分からずに一次資料として読まれうるという残余は、上記 surface が担当する。

[smileygames]

fold: tally cluster state asserted without reading the surface that holds it（2026-09-09、Lay / Lin）

rules/evolution/promotion-judgment.md Threshold Rules の照合手順に従い、当該クラスタを本 issue へ畳んで削除する。

経緯

当該クラスタは 2026-08-15 に #1750 として起票済みで、tally 側には「#1750 の変更が merge されたら削除」という中間状態として残っていた。#1750 は 2026-09-07 に spec 変更を生まないという結論で close し、実装の受け皿は本 issue に移っている（#1750 および本 issue の「#1750 からの引き継ぎ」コメント）。tally クラスタの削除だけが取り残されていた。

未着地の occurrence 5 件

#1750 の本文が持つのは 2026-08-13 〜 08-18 の 9 件。本 issue の occurrence 一覧は 2026-09-06 以降。その間の 5 件はどちらにも記録が無いので、ここに畳む。

1. 2026-08-21（liplus-chat） — まだ起票していない follow-up issue の番号を「次の番号はこれになるはず」という推論で #16 と PR 本文へ書いた。PR 自身が Update li+.yml #13 #16 を取り、issue は Update li+.yml #13 #17 に落ちたため、本文は読者を「いま読んでいる PR」へ向けていた。merge 前に自分で再読して捕捉。この件だけ、断定時点で面が存在しない（gh が番号を割り当てていないので、どんな read でも決着しない）。修理は検証ではなく順序（先に起票してから引く）。
2. 2026-08-29（PR spec(evolution): point Merge brake at skill-owned eval operations #1822 brake 1、evaluator B、Axis 2） — issue spec(evolution): Merge brake restates skill-owned operational rules and the copies have lost their conditions #1812 の制約として、N= / N>= / minimum / single round を列挙する括弧書きを引用した。その文は issue に無く、PR spec(evolution): point Merge brake at skill-owned eval operations #1822 本文 26 行目、つまり評価対象自身の自己申告である。器械の基準（issue の制約）と評価対象（PR の自己報告）を取り違えると、草案自身の主張が判定基準になる。step 8 で親が捕捉し、author には届いていない。
3. 2026-08-31（PR spec(evolution): close fixed-axis scope by criterion, reaching Li+update.md [skills, docs] #1827 self-review） — brake 1 の集約コメント URL として #issuecomment-5464224177 を捏造して投稿。実 id（...6085）は gh api .../issues/1827/comments 一回で返る。投稿後に自分の出力を再読して捕捉、PUT で修復。約 1 分間、誤った literal が PR 上に立った。ヘッジ語（相当）が検証の代わりをしていた。
4. 2026-08-31（spec(evolution): measure whether one compliance axis reproduces what the per-draft axis set catches #1832 の測定設計） — squash merge した直後の commit 89167e7 に対して測定を設計し、evaluator 3 体をそこへ向けて spawn した。squash で当該 commit は捨てられブランチも自動削除済みで、SHA は remote のどこにも解決しない。git ls-remote 一回で分かる。自分が面を無効化した上で、変える前の状態の記憶から断定した点が新しい。1 体が拒否し、2 体は spawn を空費。
5. 2026-09-01（webhook backlog） — scripts/check_webhook_notifications.py を開かずに「一括 sweep は無い、起票の価値がある」と Master に報告。--help の一画面目に --cleanup-safe-success --older-than-hours がある。さらに 訂正自体が未読断定だった：--help だけを読んで「sweep はある」と述べ、次の read で再訂正（sweep はローカル state dir に対して走り、ここではツール自身の source repo に解決するため、367 件が実際に入っている store には届かない）。3 連続ターン、いずれも主張の一歩手前で read が止まっている。

本 issue の軸との関係

5 件のうち 2 / 4 / 5 は本 issue の「決着させる材料が手元にある、参照しない」と同型（gh api / git ls-remote / ソースを開く、いずれも一手）。3 も同型で、加えてヘッジ語が検証の代役を務めた形。1 のみ面が存在しない別型だが、根が同じ「基礎なき断定」なので分けずにここへ置く。

memory/promotion_tally.md から当該クラスタを削除した。

[smileygames]

occurrence 追加（2026-09-10、Lay）: 帰属テストの手順 2 を走らせずに 5 本まとめて自己操作と判定した

webhook backlog の処理で、main 上の Governance CI run 5 本を一括で「自己操作」として mark_processed した。判定に使ったのは head_sha が直前の merge 後の main を指していることだけで、rules/operations/main-agent-procedures.md Foreground webhook notification intake の ownership test 手順 2（head_branch = main なら gh run view <id> --json displayTitle を読み、このセッションが authored したものと照合する）を走らせていない。

事後に当てた結果、5 本のうち 3 本は並列セッションのものだった。

run	displayTitle	出所
34461500015	bug(cold-start-hooks): tally occurrence count double-counts notes: bullets	#1929、並列セッション
34461558241	spec(source-check): salient field is read instead of the field the procedure names	#1930、並列セッション
34461579061	spec(literal): an adjacent clause's qualifier is carried into a branch it does not cover	#1931、並列セッション
34461766544	spec(evolution): observation lifecycle has no outcome for an observable that became unsampleable	#1932、当セッション
34461051356	spec(brake): distill parallel-agent-eval by stripping restatement (#1927)	#1927 merge push、当セッション

本クラスタの軸との関係

決着させる材料は一手で手元にあった——gh run view <id> --json displayTitle が手順そのものとして literal で書かれており、同じセッションの 2 バッチ前には実際に走らせている。今回はそれを飛ばし、head_sha という別の場から帰属を推定した。occurrence 6（head_sha を帰属根拠に使った、2026-09-06）と同一の代替場であり、あちらの「head_sha は main の先端を指すだけで、誰の操作が引いたかの情報を持たない」がそのまま当たる。反復である。

新しい点

前提が 1 件だけ実測されていたこと。並列セッションの存在自体は同セッション内で気づいており（#1929〜#1931 が自分の起票でないことを issue 一覧から確認済み）、Master にも報告していた。にもかかわらず、その事実を webhook の帰属判定へ接続していない。材料が手元にあるどころか、直前に自分で口に出していた。

もう一点。手順 3（sender is another account -> external, preserve）は同一アカウントの並列セッションを掴めない。これは仕様の穴ではなく、そのために手順 2 が手順 3 より前に置かれている。走らせれば掴めた。仕様は足りており、欠けたのは実行のみ。

結果

3 本は消化済みで、並列セッション側は到着確認を再取得できない。実害は小さい（issue 起票が引いた main の CI run であり、成果物には触れていない）。復旧は試みていない——mark_processed の取り消し経路が無く、無い経路を装って repair を報告するのは本クラスタが記録している形そのものになる。