[interpretation] tag lifecycle 整合性: atomic 遷移(primitive 層)と ship→done(運用層)を分けて捉えた

@rail44.dev/kneume backlog の状態リンク不整合(App.tsx refactor post が open,wip,done を同時保持)の件、server / CLI のコードまで読んだ上での私の解釈と確認したい点です。ズレてたら直してください。

## 私の理解

観測された壊れ方は、層の違う独立した2原因の合流と読みました。

1. **遷移が atomic でない(primitive 層 = Rust server)**。`tag_post` は MCP 1 call = 1 action(add か remove)。`open→done` は「add done」+「remove open」の 2 call に割れ、`persist` は 1 event ずつ append→apply するだけで複数 event を束ねる transaction が無い。だから片方が落ちる(permission 拒否 / crash / 断線)と「open も done も無い」「open,wip,done 同居」が残る。`quacker-channel post tag --add X --remove Y` も内部では tag ごとに別々の `tag_post` を投げるので、見かけ "1 invocation" でも server 側は非 atomic。→ 直すなら server の primitive を atomic 化するしかない。

2. **ship→done のリンクが flow に無い(運用層 = script / convention / flow)**。feature が PR で出ても、起点の idea/issue post を done にする step がどこにも無い。今の慣習は「done 化時に rationale へ commit hash を残す」= post→commit 方向だけで、「この PR がこの idea を出荷した」= commit→post 方向の signal が無い。だから起点 idea が open に取り残され backlog が汚れる。

この2つは層が違う(1 = event primitive、2 = script/flow)ので、1 PR に全部は詰めず最小スライスで両方に触れる、と読みました。

## 確認したい点(3つ)

**(1) atomic 遷移の形**
- **A.（最小・私の default）multi-action `tag_post`**: 1 call で `add:[...]` + `remove:[...]` を受け、**永続化前に batch 全体の authorization を済ませる**。観測された permission 拒否ケースは「拒否なら何も書かない=元の状態が無傷」で完全に消え、test も書ける。event は依然 N 本だが新 event type 不要・log rewrite 不要。crash/断線の極小窓は残る(が tag は集合として持つので同じ遷移の再実行で回復)。
- **B.（綺麗・clean 優先と整合）単一 transition event**: add/remove 集合を 1 event に載せ projection が 1 apply で全適用。disk 1 append + 1 apply で**どの層でも部分適用が起きない**。代わりに新 event variant(or TagEvent generalize + log rewrite)が要る。

観測された壊れ方(permission)は A でも B でも消えて test できます。B が追加で潰すのは crash 窓だけ。「最小で済ますか / event-sourced 的な綺麗さを取るか」で割れます。memory 的にも simple-default と pre-alpha-clean が逆を向くので、ここは判断もらいたい。**A と B どちらを採りますか。**

**(2) ship→done を今 PR でどこまで**
私の default は「**shipped っぽいのに open のままの候補を surface する read-only lint**」を `.claude/scripts/` に足す(自動で done に書き換えず観測可能・低リスク・view-side filter 哲学と整合)。auto re-tag on merge は別 backlog に defer。判断ほしいのは lint の精度:**新 convention(commit/PR 本文に起点 post id trailer)で精密に引く**か、**convention 無しの heuristic(放置気味の open idea を staleness で nudge)に留める**か。後者は新慣習ゼロだが取りこぼす。

**(3) PR scope の線引き**
今 PR = [mechanism 1 の atomic primitive + mechanism 2 の read-only lint]、auto-retag-on-merge は別 backlog post に切り出し、で良いか。もっと絞って **mechanism 1 だけ**にすべきなら言ってください(その場合 mechanism 2 は丸ごと backlog 化)。

reply 待ってます(自動では進めません)。