ticket: use base32 project record ids

This commit is contained in:
2026-06-09 22:10:47 +09:00
parent 0803bc3725
commit 4203988d74
798 changed files with 477 additions and 105 deletions
+68
View File
@@ -0,0 +1,68 @@
---
title: "Pod: 任意ターンからの Fork(複数ターン巻き戻し)"
state: "planning"
created_at: "2026-05-27T00:00:09Z"
updated_at: "2026-05-27T00:00:09Z"
---
## Migration reference
- legacy_ticket: tickets/pod-session-fork.md
- migrated_from: TODO.md / tickets directory migration on 2026-05-27
# Pod: 任意ターンからの Fork(複数ターン巻き戻し)
## 背景
`tickets/pod-empty-turn-rollback.md` は「直近 Submit が AI 応答ゼロのまま中断された」極めて狭いケースだけを自動で巻き戻す簡易フォーム。それを超える「3 ターン前から別の方針でやり直したい」「ある分岐は捨てて別ルートを試したい」といった **複数ターン巻き戻し** は、過去ターン境界からの Fork として実装する。
session_store には既に primitive が揃っている:
- `session::fork(state)` — 現状から新 session_id へ分岐(`crates/session-store/src/session.rs:400`
- `session::fork_at(source_id, at_hash)` — 既存セッションログ上の任意 entry hash から分岐(同 :424
- `SessionOrigin { session_id, at_hash }``SessionStart.forked_from` に出自を記録
未着手なのは Pod / protocol / クライアントへの露出と、ターン境界 ↔ entry hash の対応付け。
## 要件
- Pod に「現セッションから Fork して新セッションへ切り替える」操作を追加。Fork 起点はターン境界で指定する:
- protocol に新 Method(仮: `Method::Fork { from: ForkPoint }`)を追加
- `ForkPoint` は最低限「ターン番号」「entry hash」のいずれかで起点を指す
- ターン番号 → entry hash の解決は Pod / session_store 側で行う(`save_turn_end` のログ entry を境界として使うのが自然)
- Fork 後の Pod 状態:
- 新 session_id を active に切り替え、worker.history を fork 起点までの内容で再構築
- 元セッションは破壊されない(後から switch back 可能な前提を残す)
- 走行中(Running / Paused)状態での Fork は拒否し、Idle 限定
- Fork ツリーが追跡可能であること:
- `forked_from` chain が session_store のログから辿れる(既存挙動の確認込み)
- クライアントから「このセッションの祖先 / 子孫」を引ける API(最低限、`SessionOrigin` を読める形)
- pod_cli / TUI からの呼び出しインターフェースの設計:
- 本チケットで protocol 上の Method は確定させる
- pod_cli の引数仕様もここに含める(最低限 `pod fork --turn N` 程度)
- TUI 側の UX(ターンを選択して fork する操作)は別チケット
- セッション切り替え後の `runtime_dir` の扱いを decide:
- 1 つの runtime に対して active session が切り替わる形
- セッションごとに別 runtime を持つ形
- のどちらが今の構成と整合するか調査の上で決定
## 完了条件
- `Method::Fork` で過去ターン起点の新セッションが作成され、そこから `Method::Run` で続行できる
- 元セッションが fork 後も独立に存在し、別 Pod プロセスから resume できる(破壊されていない)
- Fork ツリーが session_store のログから機械的に辿れる
- pod_cli から fork → 新セッションでの run まで通せる
- `pod-empty-turn-rollback` の自動巻き戻しと共存(自動巻き戻しは本機能を使わずに従来通りの直接 truncate 方式で良い、と決めるならその根拠も明記)
## 範囲外
- Fork ツリーの可視化 UI(TUI / GUI)— 別チケット
- TUI 上での「ターンを選んで fork」UX — 別チケット
- 異なる Fork 間でのマージ
- 過去ターンの物理削除型リベース(fork は常に非破壊)
- 自動 GC / 古い fork の整理
## 依存 / 関連
- `tickets/pod-empty-turn-rollback.md`(直近 Submit のみの自動巻き戻し。本チケットは汎用 fork)
- session_store の既存 `fork` / `fork_at` を流用
+7
View File
@@ -0,0 +1,7 @@
<!-- event: migration author: tickets.sh-migration at: 2026-05-27T00:00:09Z -->
## Migrated
Migrated from tickets/pod-session-fork.md. No legacy review file was present at migration time.
---