dsh-session-surgeon
左侧会话 ⋯ → 复制会话 ID，贴进新对话，让新会话接着学旧会话。这是 Codex 那种「拿线程 ID 继续聊」的用法；官方菜单只有重命名 / 分叉 / 归档，没有复制 ID。
同时能修好打不开的 DeepSeek Harness 会话（seq gap / torn zstd / 末帧之后整段 0 字节的崩溃残渣 #9372：崩溃落在 write() 与 fsync() 之间，文件长度落盘而帧数据没落盘，官方扫描器在第一个零字节处判坏魔数、整条拒载，其实已提交的帧帧完好 —— 我们点出边界并丢掉那串 0 / 孤立代理字符 / 消息缺 ID）。崩溃恢复插进来的短闭包如果撞上还活着的写者（#1586），会丢掉那几条合成闭包、保住后面的真内容，而不是一刀切到第一个缺口。packed 行只重叠已经提交的前缀、后面连续时（#5151），会接上尚未提交的后缀。文件已经 seq gap 时 compact 会拒绝，先停写者再 repair。Alpha 把 sourceEventSeqs 压成区间（#5160）时：0.1.2-rc.1 起官方读盘就会展开，surgeon 不再改文件；更旧的 rc.2 仍打不开，repair 才会把 [start,end] 无损展开成密集整数。Alpha 写入、rc.2 不认识的 model/selection 会在结构校验通过后保留原事件，只补 ignorable: true；任意未知插件事件绝不套用。inspect 还会警告悬空 tool/call（没有对应 tool/result，下次模型请求永久 400；0.1.7 上 v3→v4 的 restore 与读一份已存的 v4 日志都会因此拒收整条会话，而结果只能补在还开着的 step 里）以及空的 tool_calls[].id（#5182，下次请求 id cannot be empty），但不会编假结果或假 callId。inspect 也会报告「turn/end 之后同一回合的 step 还在继续」这类失衡（#7824）：官方关系校验（v1→v2 对转换后的工件跑 v0→v1 的 assertReleasedArtifactRelationships）会整份拒读，报 <类型> does not match an open turn and step；合并还是拆分这个回合在工件里没有唯一答案，拆分还要重编号后面所有 seq，所以只报告、不改文件。同一步里重复通告的 callId（#5909）在 0.1.3 的 v0→v1 迁移会拒读；本机已是 v1+ 时 repair 只给后面的 id 加 #n。0.1.3 起还会扫 session.vN.jsonl.zstd；本机装 0.1.7-rc.2（或 rc.1）时格式已是 v4（桌面端内置的 0.2.0-rc.2 同代际、同 SESSION_FORMAT_VERSION = 4，本文引用的闸门在两版发布包里逐行一致），v0–v4 各代 header 都能 inspect / repair（改代际的迁移仍由官方负责）。升级到 0.1.5 后老会话打不开（#6151/#6175/#6189/#6194：权限事件多 origin、子代理描述 version 2、插件消息来源 summary/form 不配、分块溯源断档）时，本机已是 v1+ 的 repair 会按官方冻结清单无损归一这些形状，已用官方 0.1.5-rc.1 转换器逐条验证；未知类型（如 session/imported）迁移连 ignorable 都拒，我们只报告不删。官方以后修加载器，也救不回已经坏掉的日志文件。#6559 里那两类「官方自己写过、迁移不认」的形状在 0.1.7-rc.1 / rc.2 上依然存在，处理方式相同：退役的 source.kind（instruction-hint，已不在 v2→v3 SOURCE_KINDS 里）只改名成键集相同的 plugin；agent/inbox/spliced 的 inserted[] 消息缺 id/role 时补 id 与官方校验器自己写死的 user 角色。成员超出 released 形状的一律只报告、不猜。
最常用：复制会话 ID
- 左侧某条会话点 ⋯ → 复制会话 ID
- 开一个新聊天，把 ID 贴进去，例如：
接着 session-1e66cda9-a046-4893-8f4b-b817080acbea 继续。
需要旧上下文时去读那份会话。
如果新会话已经装了本插件的 agent 工具：
session_inspect id=session-1e66cda9-a046-4893-8f4b-b817080acbea
从上次停的地方继续。
有 session- 前缀和没有前缀是同一种会话，只是 ID 写法不同。分叉会复制一份文件；复制 ID 是让新会话引用旧会话。
安装
DSH 桌面端（2026-09-29 起本仓库的对齐目标）：打开「插件」页，添加 git 包 github:xiaoshenming/dsh-session-surgeon#main。profile 在 ~/.dsh/profiles/desktop，pnpm 会把 #main 解析成某个 commit 的 tarball。
CLI 装法等价：
dsh plugin --profile desktop add "github:xiaoshenming/dsh-session-surgeon#main"
装好后：
- 会话 ⋯ 菜单：复制会话 ID（日常就用这个）/ 检查 / 预览修复
- 左侧「会话医生」：看对话、复制 ID、预览修复、应用修复、导出
更新＝在「插件」页对这个插件点更新（pnpm 重新解析 #main 到新 commit），或在 profile 里：
cd ~/.dsh/profiles/desktop && pnpm update dsh-session-surgeon
不用重启 dsh web，也不用重新 add：装出来的是 pnpm 解出的一份普通拷贝，本身没有 .git，所以先推到 main，再更新。
本地开发请使用项目锁定的 dsh 版本和 pnpm 锁文件（Node.js 24）：
pnpm install --frozen-lockfile
export DSH_HOME="$HOME/.dsh-surgeon-dev"
./node_modules/.bin/dsh plugin --profile web add "link:$(pwd)"
./node_modules/.bin/dsh web
DSH_HOME 将开发会话与日常会话隔离；面板和 CLI 按 $DSH_SESSION_ROOT → $DSH_HOME/sessions → ~/.dsh/sessions 找会话，面板的「会话根」下拉会自动列出机器上所有 DSH home（按 home 形态识别，也可手输任意路径），另一个 home 里的会话一步就能切过去。不要用 npm 重装此开发环境：当前 DSH 的工具调度器依赖单一 @deepseek-ai/dsh-tools 模块实例，npm 的重复实体副本可能让工具调用报 reading 'prepare'。
在能加载本仓库技能的对话里，说一句 更新（或 更新插件）即可：扫官方 Discussions、吸收对口反馈、改代码、写 CHANGELOG、回复、用 px 推 main。技能正文：skills/dsh-session-surgeon-update/SKILL.md。如果 agent 的技能目录里没列出它，就直接让它读这份文件 —— 纯 markdown 流程，不需要注册。
DSH 的技能索引只扫 /.dsh/skills、/.agents/skills、$DSH_HOME/skills、~/.agents/skills，不扫已装插件包内的 skills/。想让桌面端的技能目录列出它，把它链进用户技能根（以后插件更新会自动跟着）:
mkdir -p ~/.dsh/skills
ln -sfn ~/.dsh/profiles/desktop/node_modules/dsh-session-surgeon/skills/dsh-session-surgeon-update \
~/.dsh/skills/dsh-session-surgeon-update
命令行
npx --yes github:xiaoshenming/dsh-session-surgeon scan
npx --yes github:xiaoshenming/dsh-session-surgeon inspect
npx --yes github:xiaoshenming/dsh-session-surgeon repair # 默认 dry-run
npx --yes github:xiaoshenming/dsh-session-surgeon repair --apply # 先写 .bak.（Windows 上备份文件只读 fsync 的 EPERM 不再中止 apply）
DSH 没有 Codex 那种任务 ID。能 resume 的是 session。复制会话 ID 是日常最接近的做法。详见 docs/LEARNING-TASKS.md。
