界面与集成 FAQ
dsh-filesnap 是带 Web UI 的 DeepSeek Harness 回退与 redo 插件。 它在已完成的 assistant 轮次旁提供回退控件，联动对话分支与已跟踪文件恢复，并提供会话级 redo 和 status 操作。独立的 Rust 包 filesnap 负责存储引擎。
我们是 dsh-filesnap 的维护者。核查日期 2026-09-10，依据 dsh-filesnap 0.2.2 源码和下方注明的证据。本文区分实际能力、配置中的检查，以及仍需测量才能成立的结论。
dsh-filesnap 有 Web UI 吗？#
有。 0.2.2 的客户端在 DSH 的 conversation.chat.assistant-actions 插槽注册每轮回退控件，在 conversation.session.header.actions 注册 redo/status 操作。发布 manifest 也声明了浏览器集成及客户端服务依赖。
浏览器操作会让 DSH 在选定的对话边界 fork，调用文件恢复，再打开相应子会话。手动命令的导航路径不同：返回子会话 ID，必要时由用户打开。把文件存储放进 Rust 引擎，不会让这些界面能力消失。
来源：0.2.2 客户端注册与会话导航、发布 manifest。
FileSnap 理解 DSH 对话与轮次吗？#
dsh-filesnap 插件负责连接 DSH 轮次、对话和文件恢复。 它在 agent/pre-step 捕获状态，观察文件系统写入/编辑意图，把恢复点映射到对话边界，并协调 fork、restore 和 redo。用户直接选择 DSH 恢复点，无需手工把外部备份时间戳与对话对齐。
独立的 filesnap 引擎负责文件内容、manifest 和恢复操作；TypeScript 编写的 DSH 集成负责宿主事件、命令、浏览器控件和会话导航。这是产品内部的职责分工，不能据此把两个插件分成“一个有对话集成，一个没有”。宿主接入源码、架构说明。
能直接在 DSH 聊天界面回退吗？#
能：在 DSH 对话界面点击回退控件即可操作。 操作仍在 DSH 应用内完成，处理逻辑会创建并打开子会话，原会话保留。“界面内直接操作”和“保持同一个 session ID”是两件事；当前实现支持前者，并通过分支保留原对话。
原地回退意味着集成更深入吗？#
原地回退与 fork 回退描述的是继续操作的位置，不是集成深度的评分。 SiriLee 的 dsh-rewind-plugin 提供原地回退和消息回填；FileSnap 保留原对话，在子会话继续，并提供 /redo。
两者都有 DSH 对话与界面集成。FileSnap 的两个会话共用一个物理工作区。应比较实际交互和恢复边界，而不是根据是否 fork 推断有没有应用层能力。固定版本比较。
FileSnap 是磁盘级或块级去重工具吗？#
FileSnap 引擎使用应用层的整文件内容寻址。 它用完整文件字节的 SHA-256 标识内容对象，快照引用这些对象；不是对存储设备做块级去重，也不是全盘镜像。
DSH 插件提供对话与轮次关联；内容存储可以跨路径、非相邻版本、会话，以及同一数据目录下的工作区复用仍被保留的相同内容。轮次集成和内容复用承担不同职责；“按轮次记录”本身不能证明去重更有效。见 七组存储实验，其中包含平局和负载边界。
哪些 DSH 兼容性有具体依据？#
| 证据 | 准确范围 |
|---|---|
| 已有截图与演示 | 插件 0.2.2；录制示例使用 DSH 0.1.2-rc.1 Web UI |
| 仓库 CI 配置 | 固定检出 dsh-v0.1.2-rc.1，配置了类型检查、测试、宿主构建与客户端构建 |
| 本次核查 | 源码和文档核查；没有重新运行 DSH 兼容性测试或采集 CI run 结果 |
| 其他宿主版本，包括 0.1.3 | 本次没有验证；宣称支持前应给出明确版本和成功运行记录 |
固定版本 CI workflow能说明配置中的目标，不能代替成功运行记录。版本号多、发版频繁，也不能单独证明兼容哪些宿主变化。
卸载插件不会删除对话记录或工作区文件；含插件记录的会话目前需要重装插件后重新打开。源码启动还可能遇到事件注册问题，见 排障指南。
精选收录和可信发布能证明社区更活跃吗？#
它们回答的是不同问题。 目录收录证明存在发现入口，发布来源证明关注产物来自哪里；社区活跃度则需要比较同一时间窗口的独立贡献者、问题响应和真实使用反馈。不能用其中一个替代全部结论。
0xsline 的生态列表已经把 FileSnap 描述为联动回退对话与工作区，并支持 fork/redo。被某个列表收录，或维护者在上游 Discussions 发帖，本身不等于官方背书或比较排名。
FileSnap 也有 release workflow：固定宿主构建、构建浏览器 bundle，并声明发布所用的 OIDC 权限；manifest定义了发布前检查。这些来源说明已配置的流程；本次未独立验证 npm 发布者设置、每次发布的 attestation，也未给双方社区活跃度排名。
这套设计在 DSH 之外有哪些应用？#
快照设计源自我们已发布的 codex-rewind；独立引擎现已用于 dsh-filesnap 和 Pi 的 pi-better-rewind-redo。Codex 保留同源内置实现，DSH 与 Pi 使用不同版本的引擎。这些是具体的接入与发布经历。公开版本、源码关系与验证范围。