Session Shield（dsh-session-shield）
DeepSeek Harness 插件：让会话日志永远不会因为一次畸形 tool call（空 id / 空 name / 非法 arguments）而打不开。
坏调用自动修复，正常调用原样通过，最多当轮报错，历史永远可加载。装上即用，零配置、零依赖、无需客户端改动。
解决什么问题
一次真实事故的链条：
- 模型输出了
id:"" / name:"" 的 tool call（正文里还混着 <tool_call> 与 <invoke 两套调用语法）；
- DSH 运行期校验不检查这两个字段 → 事件照常写进
session.v4.jsonl.zstd；
- 解码期要求 tool call id 非空（
tool call id requires a nonempty string）→
这个会话从此加载不出来，侧边栏只剩 stored session ... is corrupt。
写入端宽松、读取端严格：坏事件一旦落盘就不可逆，只能手工修复日志。
本插件把这个口子堵在落盘之前。
怎么做
挂在 DSH 官方的 llm/stream waterfall（dsh-llm："the chunk stream, possibly wrapped by
llm/stream listeners"），prepareCall 预绑定路径同样回到这里，所以一个钩子覆盖全部模型调用：
| 情况 | 处理 |
|---|
block-end 里 tool-call 的 id 为空 / 本次流内被别的 index 复用 | 换成 call-guard-<token>-<index> |
block-end 里 tool-call 的 name 为空 | 换成 guard_malformed_tool_call |
tool-call-delta 的 id / name 为空 | 同样补齐（装配器在缺 block-end 时会用 delta 拼装） |
arguments 不是字符串 | 转成 JSON 字符串，保证 message 块与随后的 tool/call 事件逐字一致 |
| 正常 tool call | 原样透传，一个字节不动 |
空 name 换成占位工具名后走 Harness 已有的 unknown tool "..." 错误结果：模型收到反馈可以自行重试，
日志保持合法，会话照常可打开。
环境要求
- DeepSeek Harness 0.1.x（Web 端）
- 无额外依赖、无客户端代码、不写任何文件
安装
以下任一方式（插件管理器 install_bundle，或 设置 → 插件 的安装入口）：
- 安装包（推荐分发）：直接给出本
.tgz 的绝对路径
- 源码目录：解压源码 zip 后给出目录绝对路径
- registry 包名 / git 地址：发布后用包名或仓库地址安装
安装成功后即在当前 profile 生效，重启 DSH 后插件层开始拦截。
配置
profile cordis.patch.yml 中本插件行的 config：
| 字段 | 说明 | 默认 |
|---|
enabled | 设为 false 整体停用（或直接注释掉 insert 行） | true |
验证是否生效
dsh --profile <profile> --dump-config 的输出里应有 # == dsh-session-shield 层与
- id: session-shield 行；- 启动日志不应出现
skipping profile bundle "dsh-session-shield"；
- 启动审计
warning: N entry did not activate 里不应列出 session-shield；
- 设置 → 插件页里该条目状态为 active。
注：Harness 启动成功时不会把插件的 ctx.logger 输出打印到 manager.log
（cordis logger 默认只进内存 buffer），所以看不到 "armed" 日志是正常现象，不代表未加载。
License
MIT
