Hare
d7ff25b6a7
レビュー指摘の通り、次の session-grouping-introduce で新 SessionId が
入る前に名称衝突を避けるため取り残しを掃除。
- PodError::Session{Empty,ScopeMissing} → Segment{Empty,ScopeMissing}
- ScopeLockError::SessionConflict → SegmentConflict
- Pod.session_state / SegmentState.set_session_id 系
- source_session_id / prev_session_id / ensure_session_head / short_session
- pod_cli の "Session ID:" 表示
- fs_store の sessions ローカル変数
2.6 KiB
2.6 KiB
session-store: SessionId → SegmentId へのリネーム
背景
永続化層の現 SessionId は、append-only log の物理的 / 復元上の単位を指している（compaction や fork で新 ID が発行される）。一方ユーザー視点では「同じ会話の継続」が compaction / fork を跨いで成立しており、ここにユーザー視点の会話の家系 = Session と 物理 append-only 単位 = Segment の 2 階層を導入したい。
本チケットは 2 階層導入のうち、先に物理単位側のリネームだけを機械的に済ませる。新 SessionId（grouping 概念）は次チケットで導入する。
要件
crates/session-store/内のSessionId型・関連関数 (SessionLogWriter/Store::append/fork/fork_at等) をSegmentIdに統一。- 同様に
pod/pod-registry/pod-cli/llm-worker関連の呼び出し元の参照をSegmentIdに追従。 SessionLogWriter/SessionStart/SessionOrigin等のSessionプレフィックス型のうち、segment レベルを指しているものは同時にSegmentプレフィックスへ変える。- 線引きの基準: そのデータが「fork / compaction で新規生成される log 1 本」に紐づくなら
Segment。会話の家系全体に紐づく概念は何も無いはずなので（次チケットで初めて出てくる）、本チケット内では全て Segment 系に倒す。
- 線引きの基準: そのデータが「fork / compaction で新規生成される log 1 本」に紐づくなら
- crate 名 (
session-store) の rename 要否は本チケットでは扱わず保留。中身が Segment 中心になった事実のみで判断材料を残す。 --session <UUID>系 CLI 引数は内部実装としてはSegmentIdを受けるが、外部表記は変更しない（ユーザー向け ID 体系の整理はsession-grouping-introduceで扱う）。
完了条件
SessionId型がコードベースに残らない（後続の Session grouping で導入する新SessionIdは無関係）。cargo check --workspaceおよび全テストが通る。- 既存 session の JSONL を Segment 中心の API で読み書きできる。
範囲外
- 新
SessionId(Segment 群の grouping) の導入（次チケットsession-grouping-introduce）。 - session-store crate 名の rename。
- 外部公開 CLI 引数の rename。
関連
tickets/entry-hash-abolish.md(前提)tickets/session-grouping-introduce.md(後続)crates/session-store/crates/pod/src/pod.rs
Review
- 状態: Approve with follow-up
- レビュー詳細: ./segment-rename.review.md
- 日付: 2026-05-20