dsh-find-simplifications

查找 DeepSeek Harness 的简化机会

找出能够减少维护义务的变更：API、表示形式、生命周期状态、配置路径、依赖项、测试或文档。优先选择少数证据充分的候选项，而不是追求删除数量。这是指导，而非检查清单；请遵循用户划定的范围，并区分调查与实施建议的许可。

明确范围和约束

阅读 AGENTS.md、架构文档（评估软件包前先阅读）、防御性模式和测试政策。查阅相关的有效 Agent Notes，了解有意作出的决策；新增记录时遵循说明规则。已归档的说明仅供了解历史示例，不是当前依据：切勿检查、验证或修复其中的外链。

两个 LLM 适配器是有意保留的。JSONL 是唯一的一方 Session 持久化提供方，而与后端无关的 Service Definition 支持外部提供方。除非用户明确推翻此约束，否则不要建议删除任一 LLM 同类项或持久化分层。受保护设计中未使用的成员仍是候选项，前提是删除后不影响其设计目的。

对于范围较广的请求，请将不同领域分配给多个子 Agent：循环与持久化；模型/工具组装；Host、Client 和 SDK；子进程与执行提供方；组合、脚本、测试和文档。为每个 Agent 划定明确领域，并要求其提供使用方证据和被否决的替代方案。除明显未使用的符号外，还要检查重要的生产机制；不要在发现第一个有希望的删除项后就停止。

查找可移除的义务

用以下问题指导探索。被审查代码引入的要求、检查和 Agent 说明都是需要评估的设计选择，并非其区分确有必要的独立证据。若某个候选项需要校准，请阅读历史模式中的相关部分；其中的示例用于说明决策，而非列出当前可删除项。

• 已声明的功能是否有完整的效果路径？ 追踪生产者、转换、提供方或端点支持，以及可观察到的结果。一个字段即使被复制到各处，也可能没有设置器、读取方，或只有会拒绝它的实现。对于 CLI 和配置透传，沿着权威读取和优先级追踪，找出在使用前就被遮蔽的转发值。除调用方外，也要搜索构造函数和判别值的发出位置。
• 哪些区分会改变使用方的操作？ 首先判断这个区分、字段或适配器本身是否必要。添加特定于传输方式的标记之前，应先追踪现有源字段和判别值经过其发出方及授权或能力检查的情况；宽泛的封装类别未必具有源字段的含义。可分别考虑删除某个区分和迁移其声明，并说明每种方案允许哪些输入或能力。多个内部状态可能只需映射为一个面向模型的状态或一个可用标识符。保留必要的授权、驻留、持久性和所有权行为；删除只会引导用户选择不可用选项的公开区分。
• 更小、更明确的行为能否移除整个子系统？ 固定间隔、由调用方提供时区，或报告激活失败，都可能免去通用日历、持久化默认值或自动回滚。明确说明放弃了哪些能力，以及删除了哪些机制。生产调用方的存在意味着这属于行为决策，而非自动否决；实现必须始终符合用户授权。
• 使用方能否在需要时读取权威值？ 查找复制的历史记录、晋升台账、失效事件后续读取，以及与共享投影流并存的功能缓存。推导或复用数据可能同时删除订阅、保留数据、过期响应处理和恢复路径。应先确定所需的观察时机。
• 是否把组合方式误当成策略？ 可选服务是否存在、提供方方法或同级工具，都可以表达可用性，而不必决定部署行为。显式配置或表达调用方意图的操作，可能免去注册表和依赖检查。若操作的所有权或完成时机不同，则应保留其区别。
• 谁承担完整的维护成本？ 追踪重复的应用目录、产品使用的演示启动器、仅用于解析器的工作区，以及拥有独立升级周期的安装辅助工具。对于必需行为，应将现有生产者／使用方扩展点（包括声明合并）与对远端核心或共享类型声明的修改进行比较，参见所有权规则。比较完整的移除系统与替代方案，包括残留的衔接代码；将不必要的概念移到更接近其所有者的位置，或添加一道门禁以维持重复定义一致，都无法消除其维护成本。

证明可达性并权衡取舍

从 rg 开始，然后阅读匹配结果。搜索精确符号、属性的读取和写入、判别字段、事件和线路字符串、配置键、包名，以及 .method( 和 method( 两种形式。测试和声明可以展示契约，但不能证明已发布的生产者或消费者。

检查 packages/*/*/src、apps/、python/、运行时脚本、已发布的配置档案和覆盖项、包清单和导出、加载器解析逻辑、生成的运行时资源，以及已安装包的消费者。根据示例和测试夹具的实际入口点分类，而非目录名称。沿着生成的目录追踪其消费者：供模型编写的插件挂载使用的目录属于动态产品 API，而仅供文档使用的列表则不是固定调用方。即使仓库中调用点为零，公开的第三方扩展路径也可能是有意保留的。静态未使用代码检查器必须覆盖由清单驱动的加载、生成的输出和编译器接口，而不能维护一份与之平行、逐工作区列出的例外清单。

对每个候选项，记录当前所有者、实际生效的生产者／消费者路径、会消失的内容、会保留的内容、能力和兼容性影响，以及保留它的最有力理由。区分以下情况：

• 移除不可达或未读取的行为；
• 缩小公开或产品行为范围，并明确说明损失；
• 存在必须履行的义务或证据不足。

如果候选项会破坏仍需履行的义务、只是把相同复杂度转移到别处，或没有实质性减少，就应驳回。应针对所提议的改动本身来阅读驳回理由：过时的清单或混合提案中某项被驳回的行为，并不能决定其他独立项的去留。重新提案前，先更新证据。小型局部改进应根据紧急程度规则，写入可执行的 TODO／FIXME／XXX 注释，而不是单独建立设计文档。

保留所有权和故障语义

对于副本、冻结对象、验证器和回调捕获，说明值的来源、下一个所有者和信任边界。类型化的同进程调用通常只会借用只读值；解析器、配置加载器、队列、模型／工具 JSON、持久化文件、工作线程、进程和线路解码器则拥有或验证其输入。恶意 getter 或回调替换测试本身不能证明存在相应需求。根对象被冻结并不能证明其后代不可变；ID 相同也不能证明对象身份相同。

对于异步机制，梳理每个 Promise、标志、取消路径、释放函数和预留项的所有者及状态转换。只有在它们表达同一事实时，才合并机制。必要时保留同步发布与回滚、回调隔离、首个终态结果裁决、工作线程／进程所有权，以及释放后达到静止状态的保证。即使转录渲染器忽略了持久化的开始／结束标记，它们也可能记录真实事实；丢弃中断的工作属于能力损失，不是冗余日志清理。

只有实现净减负时才替换基础设施

遵循依赖策略。在引擎最低版本所支持的范围内，先搜索现有依赖和 Node 内置模块，再添加包。明确指出替代方案会删除的具体实现和专用测试、其维护成本与传递依赖成本，以及胶水代码仍必须保留的所有行为。

针对最可能导致替换方案失效的不匹配点进行测试：协议截断、取消和拆卸、配置边界、确定性的测试时钟、平台打包，以及源码入口与构建后入口。如果某个库能处理分帧，却仍需重新实现同一套分帧逻辑才能限制大小，那就不算简化。任何已接受的边界行为变更都应写入提案和相关测试。不要在遗漏测试特定于测试框架的封装代码的情况下，只重复证明依赖项的一般规范。

记录、整合并验证

当涉及正文内容时，使用 dsh-prose-standard。移除复述代码或由远程内容维护方负责的说明，同时保留本地行为、时序、归属和失败处理义务。通过相应的所有者变更，更新受影响的 README、JSDoc、面向模型的目录、配置、快照和生成文件。

重要提案必须采用强制说明模板：Problem、Proposal、Alternatives considered、Acceptance criteria 和 Risks。提供具体的使用方证据、所移除的维护成本、放弃的能力，以及可观察的验收条件。已实施的决策应改用已实施格式。如果决策相同，应更新现有说明的所有者；不要为了保留候选项数量而创建重复说明。

每条新说明都必须通过 dsh-archive-agent-notes 执行范围明确的替代检查。该工作流负责保留、整合、三联文件删除以及冻结归档机制。代码调查并不意味着要对整个仓库的说明进行审计。保留部分替代关系，以及当前仍有效的持久性、线协议、兼容性或已拒绝替代方案相关义务。

合并其他分支时，将其独立差异与目标基线进行比较，只移植有依据且不重叠的提案，并整合重叠的理由。关闭其他 PR 需要获得授权，或明确由你负责此项整理工作。

对于仅涉及文档的 Agent Note 工作，运行 pnpm run doc-sync、pnpm run lint 和 git diff --check；对于技能或注释编辑，还应运行适用的验证器。通过 dsh-pre-push-checks 选择其他检查。报告调查过的范围、有依据的候选项、有意义的拒绝或延期事项，以及新增、整合、保留或移除的说明和实际运行的命令。调查范围仍在扩展时，使用草稿 PR；不要将未经验证的搜索描述为穷尽式搜索。