deepseek-harness 工作区删除语义只删注册、保留目录与 Session 记录的落地方案【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness本指南以 deepseek-harness 仓库中已实现的 Agent Note《Workspace Registration Deletion》为骨架讲解 Harness 中“删除一个 Workspace”这一操作被明确界定为“仅删除注册记录”的设计决策它不触碰文件系统、不级联删除 Session并通过pendingMutation持久化标记、Host 增量流与客户端 tombstone 机制保证崩溃恢复与多端收敛。读完本文你将理解ctx.workspaceRegistry.delete(id)的完整调用链、workspace-not-found错误映射、删除确认弹窗的交互约定以及仓库中对应源码与端到端测试的落点。问题一行注册记录的删除边界在哪里在 deepseek-harness 中Workspace 是一层“登记簿”它把一个已有的代码目录注册进系统让 GUI 可以为其命名、并对其下的 Session 进行排序与分组。关键约束在于——这条注册记录并不表明 Harness 创建或拥有了该目录而 Session 日志又是完全独立的持久化对象。因此如果把 Workspace 行上的 Delete 动作理解为“递归删除源码目录”或“删除其下所有 Session”就会越过记录自身的所有权边界销毁注册记录本不该拥有的数据。这是设计上必须回答的第一性问题也是 关联 Agent Note 的出发点。同时此前的行菜单只是“视觉存在”删除语义在以下场景中全部悬而未决持久化的 Workspace 顺序durable order如何更新workspaces表如何变化Host 端增量流如何通知已连接的浏览器标签页多个并发浏览器标签页如何收敛断线重连后的基线baseline如何校准一次列表请求与删除变更竞态时如何处理。下文的分层设计正是为了同时解决这些跨层一致性问题。决策删除只作用于注册本身核心决策可以浓缩为一条 API 契约ctx.workspaceRegistry.delete(id)只删除 Workspace 注册。具体效果是该 id 从持久化的workspaceIds顺序中消失workspaces表中的对应行被删除实体缓存entity-cache中的对应条目随之消失该 Workspace 记录中排序过的sessionIds账户随行一起消失。它从不调用文件系统删除从不调用SessionPersistence。目录、用户的每一个文件、每一个仍在线的 Session、每一条已持久化的 Session 日志全部原样保留。由于侧边栏分组是“所有现存 Workspace 账户的补集”这些 Session 会立即出现在Ungrouped未分组之下——包括当前正在使用的 Session。这段逻辑在源码中可以直接验证packages/workspace/workspace/src/index.ts 的deleteKnown实现private async deleteKnown(id: WorkspaceId): Promiseboolean { const entity this.entities.get(id) if (entity undefined) return false const state this.requireState() const nextState { initialized: true, workspaceIds: state.workspaceIds.filter(workspaceId workspaceId ! id), archivedSessionIds: state.archivedSessionIds, } await this.setState({ ...nextState, pendingMutation: { operation: delete, workspaceId: id } }) this.entities.delete(id) // ...随后删除表行表写入失败则恢复缓存与旧顺序 return true }可以看到先更新持久化顺序去掉该 id再删除实体缓存最后删除表行整个过程中没有任何fs操作、没有任何对 Session 持久化的触碰。delete的公开入口则通过enqueueOperation与创建、排序等其他注册表写入串行化同文件 L648-L657确保check-then-write不会被并发请求交错。领域契约与 Remote 错误映射在领域层未知 id 返回false这是一个幂等的 no-op供领域调用方直接使用。而在 Remote API 层packages/api/workspace-controller/src/commands.ts 的delete命令把这一区分映射为稳定的协议错误码delete(request: WorkspaceDeleteRequest): PromiseWorkspaceDeleteValue { return this.enqueue(async () { if (!await this.ctx.workspaceRegistry.delete(WorkspaceId(request.workspaceId))) { throw workspaceNotFound(request.workspaceId) } return { deleted: true } }) }未知 id →workspace-not-found由workspaceNotFound辅助函数构造TypertRemoteFailure同文件 L178-L184成功 → 返回{ deleted: true }。Remote 命名空间的注册在 packages/api/workspace-controller/src/index.ts 中完成WorkspaceController继承TypertRemoteService以Remote(delete)暴露该命令。删除后的行内容WorkspaceView由 feed.ts 的 workspaceView 投影其中sessionIds是拷贝保证发给消费者的值不会随实体变动而漂移。另外workspace.list始终保持“重连基线”的地位删除后的注册表状态永远可以通过一次完整的list重新获得这是后续所有收敛与修复路径的兜底。持久化提交pendingMutation 与提交点设计删除不是一次写操作而是“顺序写 实体缓存移除 表行删除”三步。要让这三步在崩溃、写失败面前仍然自洽仓库采用了两个关键机制1. 操作串行化。注册表的所有写操作create、delete、insertBefore、archiveSession都经过enqueueOperation排队执行index.ts L648-L657从根上杜绝两个删除/创建交错执行。2. 持久化的pendingMutation标记。create 与 delete 在“记录/顺序”这对数据可能发生分歧之前先写入一个持久化的pendingMutation标记内容为{ operation, workspaceId }。启动时recoverPendingMutation 只完成该标记点名的那个操作并清除它private async recoverPendingMutation(): Promisevoid { const state this.requireState() const pending state.pendingMutation if (pending undefined) return if (state.workspaceIds.includes(pending.workspaceId)) { throw new Error(workspace domain is inconsistent: pending ${pending.operation} workspace ...) } await this.requireTable().delete(pending.workspaceId) await this.setState({ ... }) // 清除标记 }一个孤立的表行无法单独判断是哪次操作被打断因此未打标记的 order/table 分歧仍会保留注册表“fail-loud”的损坏检测行为——由 validateStoredState 在启动时直接抛错绝不静默丢弃数据。删除的具体提交顺序是写入不带该 id 的workspaceIds顺序同时携带pendingMutation标记从实体缓存中移除该实体此后缓存不再对外发布该实体删除workspaces表行——这是删除的“通知提交点”包不变量package invariant只在缓存停止发布该实体后接受这次删除Host 也只从这次已提交的表删除中向外发布移除帧若表写入失败则恢复缓存与先前的持久化顺序并且不发布任何移除帧——用户视角表现为“这次删除没有发生”若表删除已提交但标记清理失败操作仍报告成功目标状态与移除帧都已提交下一次启动会幂等地清除该标记。创建侧的回滚同理createCanonicalL285-L356表写入失败会删除实体缓存并恢复原状态顺序写失败则会回滚表行与状态。整套机制保证了“要么注册记录完整存在要么彻底不存在”不存在中间态。Host 增量流只在提交点发布移除Host 端由 WorkspaceFeed 负责监听存储域domain/changed并向所有 follower 推送增量帧。删除相关的关键逻辑在changed方法中对workspaces表的deleted操作先检查该 id 是否在自己的“已提交 id 集合”knownIds中L120-L124只有此前已经通过全局顺序写而“已知”的 id删除时才会发布{ type: remove, workspaceId }帧由此create 的回滚不会发出任何虚假移除帧而每个已连接的标签页恰好收到它所需的那个 id用于删除自己的本地投影该 id 只有在表删除提交点发生时才从knownIds中移除全局顺序写阶段不会提前移除。整个流的入口是Remote({ mode: stream }) followindex.ts L117-L120每个订阅者先收到一次完整baseline{ items, archivedSessionIds }随后持续收到upsert/remove/order/archived有序增量WorkspaceFollowerL141-L184。客户端收敛增量重放、tombstone 与 unary echo客户端一侧Gateway 把这条流包装为可重连的“快照流”snapshot stream增量帧被分发到ClientWorkspaceModelpackages/api/workspace-controller/src/client/index.tsupsert→upsertViewremove→removeVieworder→replaceOrderarchived→replaceArchivedbaseline→replaceBaseline。对应 Agent Note 中 “WorkspaceManager把host/workspace-changed与host/workspace-removed都当作有序增量、在途workspace.list响应之上重放” 的描述当前实现为 model.ts 的 ClientWorkspaceModel其收敛策略包括Unary 直接回显一次成功的delete调用成功后立即从本地投影移除该行L112-L116而不是等待流回显stream echo删除幂等removedIds作为进程内 tombstoneL66对永不复用的 Workspace id 拒绝迟到的 changed 帧或过期的基线行installViews与upsert都会先检查 tombstone重连基线修复连接断开后replaceBaseline整体替换投影Session 状态绝不会被 Workspace 增量裁剪竞态防护orderRequestGeneration/orderFrameGeneration双代计数保证远端提交的排序帧优先于本地乐观排序的回显。UI 侧的确认闭环则保证了“下一个 Workspace 手势”不会观察到过期的列表帧删除确认一直挂起直到 React Workspace 投影真正提交了被删除的 id 才关闭WorkspaceBrowser.tsx 的 deleteCommittedId 效应。确认交互Modal 中的三种后果删除的确认交互延续了既有行菜单的结构。用户从 Workspace 行的菜单选择 Delete 后会打开共享的Modal与浏览器自身对话框同一设计体系见 WorkspacePicker.module.css。弹窗文案明确陈述全部三种后果其 i18n 文案定义在 locales.ts“This removes ‘{name}’ from the workspace list. The folder and session logs will be kept. Its sessions will appear under Ungrouped.”即Workspace 离开列表、文件夹与会话日志保留、其 Session 归入未分组。交互细节同样有约束WorkspaceBrowser.tsx L1053-L1066请求进行中Confirm 与 Cancel 按钮都被禁用重复确认被忽略请求进行中Escape 与 Close 都无法解散操作失败时 Modal 保持打开并展示错误提交前触发 Cancel、Escape 或 Close 都不会删除任何数据。菜单、Modal 与按钮保留既有结构与设计令牌design tokens不引入新的视觉体系。文档同时明确Session 删除仍是“视觉级”能力不在本次决策范围内其完整生命周期运行中检查、后代语义、显式 UI需要单独设计。备选方案与取舍Agent Note 记录了五条被否决的备选路径理解它们能更清楚地看到最终方案的边界备选方案否决理由级联删除 SessionCascade-deleteWorkspace 注册不拥有 Session 持久化产品需求是在 Ungrouped 下保留历史。Session 删除需要自己的生命周期、运行中检查、后代语义与显式 UI把目录移入回收站Trash注册记录无法证明目录所有权未来任何破坏性文件系统操作都必须单独命名、单独确认、并有明确的安全边界先删表行、之后再修顺序崩溃或写失败会留下“已初始化但顺序与表不一致”的注册表必须在一个串行化操作内同时更新两者并在表失败时恢复旧顺序启动时删除所有无引用行同样的形态也可能来自无法解释的顺序损坏静默丢弃可能丢失 Workspace 元数据与 Session 账户信息恢复必须依赖写入方留下的显式 pending 标记成功后重新拉取两份列表已提交的移除帧 立即 unary 回显已经足够还能保留当前 Session 对象并避免把一次本地变更放大成两次列表请求重连基线始终是修复路径验证从领域单测到浏览器端到端该决策的验证覆盖了仓库中从底层到 UI 的每一层均可在源码中直接核对Workspace 包测试workspace.spec.ts、invariant.spec.ts锁定成功时的“纯元数据删除”、同路径重新注册、未知 id 的幂等性、表写入失败回滚、显式标记的启动恢复、无标记损坏的拒绝以及缓存/表不变量行为Apiproxy 与 carrier 测试workspace-controller.host.spec.ts、transport.client.spec.ts锁定协议 schema、handler、workspace-not-found、Session/文件夹保留、全新 id 重新注册以及已提交的remove帧客户端测试锁定 unary 直接回显、重复移除、迟到的 changed 帧、删除与在途基线竞态组件测试锁定确认弹窗、投影落定后的关闭、成功帧先于 unary 到达时的排序、失败、Cancel、Escape、Close 各分支浏览器端到端场景workspace-management.e2e.ts注册一个临时项目目录、计入一条持久化 Session 并使其成为当前 Session、在 Chromium 中确认删除、验证 Workspace 分组消失而 Ungrouped 保留当前 Session删除前后分别检查用户文件与 JSONL 日志并在页面重载后再次断言 UI、目录与日志。其中 e2e 测试显式检查了folder and session logs will be kept与sessions will appear under Ungrouped的弹窗文案L247-L248并在删除后stat(logLocation.path)确认 JSONL 日志仍然存在L264。另一个场景则复用已删除的标题注册一个不同的新目录期间观察所有瞬态 alert、slot 错误、console 错误与页面错误确保删除过程不产生任何残留报错。后果有意的可逆与明确让渡的“一键清理”删除一个 Workspace 是有意可逆的用新 id 重新注册同一目录即可恢复虽然其先前的手动 Session 顺序已随行消失重新注册在 bootstrap 之后也不会自动重新收编既有 Session。也就是说该设计以“放弃一键清理 Session 历史或源码目录”为代价换来了一条与记录实际所有权边界严格一致的删除边界——这是整个决策的最终落点也是 Harness “Everything is a Plugin” 架构下数据所有权与 UI 操作解耦的一个具体体现。【免费下载链接】deepseek-harnessDeepSeek Harness: Everything is a Plugin.项目地址: https://gitcode.com/gh_mirrors/de/deepseek-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考