webhook arrival clearing requires confirmation - Liplus-Project/liplus-language GitHub Wiki
webhook 到着通知の消去は確認を伴う
Question
自己操作の webhook 到着通知は、溜まったら消してよいか。
Current resolution
消してよくない。mark_processed は確認済みの印であり、確認していないものに付けてはならない。
mark_processed は削除ではないが、削除までの時計を始動させる。github-webhook-mcp の worker/src/store.ts は mark_processed 実行時に DELETE FROM events WHERE processed = 1 AND received_at < ? を走らせ、保持期間の既定は 3 日（PURGE_AFTER_DAYS = "3"、#241 で 7 日から短縮）。未処理側は DO Alarm による掃引で既定 90 日、非対称は意図的。
したがって「溜まっているから掃除する」は無害な衛生ではない。確認を経ずに印を付ければ、確認は一度も行われないまま 3 日で消える。
確認の中身
workflow_run の場合、確認とは conclusion を読み、それが期待どおりであることを照合すること。以下は確認ではない。
- URL を見た
- 件数を数えた
conclusion: successが並んでいるのを眺めた（どの run がどの操作に対応するかを知らないまま）
この基準なら 1 件あたりのコストはほぼゼロであり、かつ事後に「確認した」が真だったかを検証できる。
Edges
- depends on —
github-webhook-mcpの auto-purge 実装（#235）と保持期間 3 日（#241）。この前提が変われば本判断は再評価対象。 - conflicts with — なし
- supersedes — なし
Background
2026-09-06、滞留 75 件を掃除した際、消去の可否が論点になった。AI 側は当初「到着時に自己操作分を自動処理する」案を提示したが、human が「自己操作項目の auto 削除は結局自分の操作履歴をなくすことになるから本来の目的を失う」と指摘した。
AI 側は二セッション（Lin / Lay）とも、workspace 上の github-webhook-mcp クローンを読んで「実装は UPDATE events SET processed = 1 であり削除ではない、よって懸念は当たらない」と回答した。これは誤りだった。 クローンは feature branch に置かれ origin から 50 コミット以上遅れており、auto-purge はその先で導入されていた。当該 auto-purge の author 行は Claude Lin & Lay であり、自分たちの実装を忘れたまま古い写しを一次資料として読んでいた。
human の指摘は、実際の削除挙動の面でも、条項の目的の面でも成立していた。
Constraints
条項（rules/operations/main-agent-procedures.md Foreground webhook notification intake）は到着通知の目的をこう定めている。
these serve as arrival confirmation = proof that the operation reached GitHub.
目的は保管ではなく確認という行為である。行がストレージに残ることは、確認が行われたことを意味しない。到着した瞬間に自動処理すれば、仕組みは在って何もしていない状態になる。この一点だけで human の指摘は成立し、実際の削除挙動を経由する必要はない。
Conclusion
採用 — 確認を行った上で mark_processed する。確認の定義は conclusion の照合。
棄却 — 到着時の自動処理（種別ルールによる一括処理を含む）。確認の空洞化と、3 日後の無言の削除を同時に招く。
未解決として残る軸 — 二セッションが一つの store を共有するとき、誰が確認の担当者かが決まっていない（#1890）。本判断は「何をもって確認とするか」を確定するが、「誰が確認するか」は確定しない。