複数 Pod 間の Scope 排他制御

背景

scope-redesign.md で Scope は「allow / deny の領域リスト + permission レベル」に再設計された。これにより複数 Pod が同じファイルツリーに対して異なる権限を宣言する状況が日常化する。

現状、複数 Pod が同じ pwd や重なる allow を持っても何のチェックも警告もない。両者が同じファイルに write を持っていた場合、ツール経由で同時に書き換えて内容を破壊しうる。Git のコミット粒度より細かい競合は履歴からも復元しづらい。

Pod を「並行作業の単位」として扱う以上、scope の重なりは設計時に検知・制御できる必要がある。

R1: write の重複を検出する 同じファイルが 2 つ以上の Pod から write 権限で見えている状態を作らせない。片方の Pod が起動中なら、もう片方の起動を拒否する（または昇格を拒否する）。
R2: read は共有可 read のみの重なりは許す。複数の閲覧者は問題ない。
R3: deny は重なりに影響しない deny で write が落とされている path は、その Pod にとって write を持たないとみなして他 Pod との重複判定を行う。
R4: 解放の確実性 Pod の異常終了で排他が永久に残らないこと。lock の所有者プロセスが死んだら自動解放されるか、stale lock として検知できる。
R5: 観測可能性 ユーザーが「今どの Pod がどこを write 占有しているか」を見られる。競合で起動が拒否されたとき、競合相手をエラーメッセージで示す。

選択肢:

おすすめは B。Pod の宣言と lock の単位が一致する方が説明しやすく、ユーザーが「この Pod は src を握っている」と理解しやすい。

選択肢:

おすすめは A。デーモンを増やしたくないし、Pod は短命〜中時間生存の想定なのでファイルロック (flock(2) / fcntl) で十分。stale lock 検知は PID 死活で行う。

選択肢:

おすすめは A。並行作業の単位として Pod を起動するなら、競合は意図しない状況であることが多い。明示エラーで気づける方が安全。--wait フラグや --read-only フラグで B / C を選べるようにするのは将来拡張で十分。

Pod::restore でも同じ scope が要求される。前回終了時に解放されているはずなので取得が成功するのが正常。失敗する場合は別 Pod が起動している = ユーザーが意図的に 2 つ動かそうとしている。fail-fast に乗せる。

実装時に詰める。現時点での見立て:

新規モジュール crates/pod/src/scope_lock.rs（または独立クレート scope-lock）
- lock の取得 / 解放
- stale lock 検知（PID 確認）
- 競合情報の収集（誰がどの allow を握っているか）
Pod::new / Pod::restore の前段で lock 取得
Pod の Drop / 明示解放で lock 返却
Controller 層でのエラー伝搬とユーザー向けメッセージ
CLI に「現在のロック一覧」を見るコマンド（観測性 R5）