Remove Pod-ID

crates/pod/README.md

@@ -7,7 +7,6 @@
 ### コア
 
 - `Pod<C, St>` — LLM ワーカーセッション + マニフェスト + スコープのラッパー（`run()`, `resume()`, `from_manifest()`）
-- `PodId` — UUID v7 による Pod 識別子
 - `PodRunResult` — 実行結果（`Finished`, `Paused`）
 - `PodError` — エラー型
 

tickets/remove-pod-id.md

@@ -1,18 +0,0 @@
-# PodId (UUID) の削除
-
-## 背景
-
-Pod は一時的なプロセス的存在であり、永続的アイデンティティは Session が持つ。現在 `PodId = uuid::Uuid` が `Pod` 構造体に存在するが、ファイルシステム・プロトコル・外部発見はすべて `pod_name` ベースで動いており、PodId を使って何かを引くコードがない。
-
-## やること
-
-- `PodId` 型、`new_pod_id()`、`Pod.id` フィールド、`Pod::id()` getter を削除
-- `Pod::restore` から `id: PodId` 引数を削除
-- `pod` クレートの `uuid` 依存を削除（`SessionId` は llm-worker-persistence 側なので影響なし）
-- Pod の識別は `pod_name`（マニフェスト由来）に統一
-
-## 判断根拠
-
-- 「どの Pod か」→ name で十分（同名 Pod は存在しない前提）
-- 「どの実行か」→ SessionId が担当済み
-- 再接続フロー: name でランタイムディレクトリを発見 → status.json の session_id で Session を復元。PodId の出番がない

tickets/session-entry-hash.md

@@ -0,0 +1,26 @@
+# セッションエントリのハッシュチェーン
+
+## 背景
+
+複数の Pod が同じ Session を読み込んで作業を進めるケースがある。現状の設計では、同一セッションファイルへの同時書き込みがコンフリクトを起こす。また `fork_at` のエントリ指定が `usize`（インデックス）であるため、元セッションにエントリが追加されると同じインデックスが別の内容を指してしまう。
+
+## やること
+
+- 各 `LogEntry` に `prev_hash: Option<EntryHash>` を追加（先頭エントリは `None`）
+- `EntryHash` は `sha256(prev_hash + serialized_content)` で算出
+- `Session` がロード時に head hash（末尾エントリのハッシュ）を保持
+- `Session::append` 時にファイル末尾のハッシュと保持している head hash を比較
+  - 一致 → 通常 append、head hash を更新
+  - 不一致 → auto-fork（新 SessionId で分岐）
+- `fork_at` の引数を `usize` → `EntryHash` に変更
+
+## アドレッシング
+
+- **SessionId (UUID v7)** → どのセッション（ファイル）か
+- **EntryHash** → そのセッション内のどの時点か
+
+## 判断根拠
+
+- ファイルサイズやエントリ数による変更検知は同じ長さの別内容を区別できず信頼性が低い
+- ハッシュチェーンなら暗号的に一意であり、ログの整合性検証も副産物として得られる
+- ストレージレイアウト（JSONL）は変更不要。LogEntry の構造変更だけで済む