前言¶

DeepSeek Harness（DSH）的对话记录默认落在本机 ~/.dsh/sessions。换机、磁盘故障或误删时，这些会话往往没有第二份副本；即便你自己拷了一份文件夹，也很难证明拷贝是否完整、是否被改过。用 Git 管会话日志既别扭又容易把敏感内容推出去；再装一套 age、rsync 之类的外部工具，部署和权限又多了负担。

dsh-history-keeper（维护者 leoainc-ops）面向同一类问题：把 DSH 会话做成加密快照，用哈希链做完整性校验，并在需要时按字节级还原布局。插件归类为「记忆」；仓库当前星标为 0。README 标明状态为 pre-alpha（0.1.0 进行中）：snapshot、verify、restore 已在真实 DSH 日志上跑通，并在 8 个会话上做过逐字节校验；与 DSH 宿主深度集成、实时同步属于后续里程碑。

这是什么¶

一句话：dsh-history-keeper 是 DeepSeek Harness 的加密、可验证历史保管插件——快照、校验、恢复会话，不依赖 git，也不依赖额外二进制。

数据在离开本机前加密；元数据（含文件名、大小）同样加密，没有密钥时存储区对外不透明。没有服务端、没有账号。设计强调「失败即关闭」：没有密钥不同步；冲突不写；加密不会降级为明文；恢复只创建文件，不覆盖、不删除已有且内容不同的日志。

核心能力（以当前资料为准）¶

里程碑¶

三条主路径¶

1. snapshot：捕获当前 DSH 会话字节并写入 vault（保管库）。
2. verify：检查每个对象、哈希与链；可读报告，便于自行审计。
3. restore：在目标目录下复现宿主布局（sessions/ 等），校验每个哈希；不会覆盖已存在且不同的日志。

对象不可变、按内容命名；块链支持在无密钥情况下审计完整性（仍无法读明文）。传输层只搬运 blob，由文件夹或任意同步方式承载，不负责解析或合并。

在 DSH 内 vs 仅 CLI¶

对话内提供 /keeper status、/keeper snapshot、/keeper verify、/keeper help。
restore 故意不在 DSH 内暴露：它会写入 live 会话存储，运行中的宿主不会感知；恢复应在关闭 DSH 后用 CLI 完成——这是恢复类工具的定位。

安装与启用¶

README 写明：尚未正式发布。0.1 发布后计划使用：

dsh plugin --profile web add dsh-history-keeper

安装前请自行查看 GitHub 仓库 源码与 MIT 许可证。插件在 DSH 进程权限下运行，vault 路径与口令环境变量会接触本机会话数据，启用前应确认信任维护者与版本。

兼容性（资料原文）：针对 DeepSeek Harness 0.2.0-rc.2 开发；package.json 中 engines.dsh 为 >=0.1.0-rc.6 <0.3.0，不兼容宿主应拒绝加载。Node 要求 ^22.19.0 || >=24.0.0。当前包版本为 0.1.0-rc.7。

典型用法¶

口令¶

口令不会写入 profile patch。使用前导出环境变量，或通过 passphraseFile 指定（README 提及，具体字段以 cordis.patch.yml / 文档为准）：

export KEEPER_PASSPHRASE='a passphrase of at least 8 characters'

仅用 CLI（无需 DSH、git 或外部二进制）¶

适合先验证引擎，或做离线恢复。下面在 checkout 目录中执行（README「Try it now」）：

export KEEPER_PASSPHRASE='a passphrase of at least 8 characters'

node bin/keeper.js init     --store ./vault
node bin/keeper.js snapshot --store ./vault --home ~/.dsh
node bin/keeper.js verify   --store ./vault
node bin/keeper.js restore  --store ./vault --home /tmp/restored-home

init 初始化 vault；snapshot 从 --home 下的 DSH 目录抓取；verify 全库校验；restore 将内容写到 --home 指定路径下的布局。

接入 DSH profile¶

安装 bundle 后，在 profile patch 中插入插件行并指向 vault（示例来自 README，路径按本机修改）：

- insert:
    - id: history-keeper
      name: dsh-history-keeper
      config:
        store: C:\Users\you\keeper-vault        # required
        sessionsRoot: C:\Users\you\.dsh\sessions # optional; defaults to ~/.dsh/sessions
        autoSnapshotOnFlush: true               # capture after each closed turn
        debounceMs: 2000

最小配置：config 可全部省略。此时插件默认在 ~/.dsh/history-keeper 查找 store，从 ~/.dsh/sessions 读会话；若 store 不存在会提示如何创建。时间戳以 UTC 存储，展示时按本地时区并带偏移。

会话中：

/keeper status     what the vault holds, what is pending, what this machine is missing
/keeper snapshot   capture new session bytes now
/keeper verify     check every object, hash and chain
/keeper help

适用场景与注意¶

适合谁

• 需要在单机或多机之间同步 DSH 会话副本，但不想用 git 或额外 CLI 工具链。
• 希望在拷贝或同步后能用 verify 自证完整性，而不是「相信文件夹看起来没问题」。
• 接受 pre-alpha：宿主集成与 live sync 仍在路线图上，当前以共享目录 + 手动/半自动 snapshot 为主。

使用注意

1. 插件与 DSH 同权限，vault 与 KEEPER_PASSPHRASE 等同于会话数据的钥匙；丢失口令无法解密，泄露口令则 vault 内容可被还原。
2. 恢复务必在 DSH 关闭后用 CLI restore，避免与运行中会话目录冲突。
3. 共享文件夹（网盘、Syncthing 等）只当 dumb transport；每台设备各自维护副本，设计原则明确反对「共享可变文件」。
4. 正式安装命令以 README 为准；在「Not published yet」阶段，可从仓库 checkout 用 node bin/keeper.js 试用。

结尾¶

dsh-history-keeper 把 DSH 会话从「单机目录、难以自证」推进到「加密快照 + 可校验链 + 不覆盖式恢复」，且只依赖 Node 内置能力。若你正在搭建 DSH 的长期记忆与灾备，可先按 CLI 流程在测试 vault 上跑通 snapshot / verify / restore，再等 0.1 发布后用 profile 接入。

• 社区目录页：https://www.skillhub.cn/plugins/leoainc-ops/dsh-history-keeper
• 源码与文档：https://github.com/leoainc-ops/dsh-history-keeper