WorkBuddy 会话分叉

先说清楚要解决的问题

长对话里最常见的两个困境：一是聊岔了，想回到上一轮的结论重新推，却只能复制粘贴碎片再重写上下文；二是同一主题想开几条平行线做对比讨论，粗暴重启对话则要重新加载所有背景。

session-fork 的思路是把工作流当成版本管理：不是在原会话上"撤销"，而是在指定节点切出一条独立分支。原对话继续往前，分支停在截断点，二者互不污染。

它是怎么工作的

核心机制是存储级复制，而非建立链接：

• 从 ~/.workbuddy/projects/<slug>/*.jsonl 读取源会话，按截断点截取前缀（第 1 行到目标行）；
• 顶层 sessionId 替换为新 UUID，并且对整行 JSON 做字符串级旧 id → 新 id 替换，覆盖 output.text、providerData.toolResult.content、reasoning 等嵌套字段——只改顶层会导致分支继续"引用"旧会话的工具结果；
• 在 ~/.workbuddy/workbuddy.db 的 sessions 表插入新行（新 id、新标题、status=terminated）；
• 写入后立即把文件锁为只读（0444），防止 WorkBuddy 主进程继续向分支追加消息。

截断点有三种定位方式，按精度从低到高：

• 默认模式：用户只说"打分支"时，自动截到上一轮完整 assistant 回复末尾；
• --match "文本"：截到最后一条包含指定文本的 assistant 回复；
• --line N 或 --request-id abc123：前者按行号，后者直接匹配 conversationRequestId，是唯一标识一条回复、不会误匹配的精确方式。

脚本内置备份（jsonl + db 到 ~/.workbuddy/backups/）、完整校验（行数、解析、sessionId 一致性、末条完整性），并支持 --dry-run 先确认断点再执行。

边界与注意点

• 复制发生在读取时刻，原会话之后的新消息不会进入分支——这是快照语义，不是丢数据；
• 用户明确提到断点时必须走 --match/--line，不能图省事用默认模式，否则分支会包含截断点之后的多余对话；
• 配套的 tool-results/ 目录是运行时缓存，function_call_result 已内嵌在 jsonl 中，分支不需要复制；
• 仅适用于 WorkBuddy 的会话存储格式，其他平台不通用；分支是否删除由用户决定。