DeepSeek Harness 启动诊断中的 pending 插件可能正在等待必需服务；应先追踪服务提供方及其原始错误，而不是把每个等待中的消费者都当成独立故障。
DeepSeek Harness：报告中的状态分别说明什么？
CLI 参考说明，必需插件激活失败时，启动器先列出失败插件及原始堆栈，再列出 pending 插件和缺失服务；必需插件排在 pending 列表前面。写完报告和标准错误输出后，进程显式以退出码 1 结束，即使插件仍有未关闭的句柄。只有可选插件激活警告时，仍按普通警告输出，不会因此创建该报告。
Cordis 的一个插件实例由 fiber 跟踪生命周期、依赖、已验证配置和副作用。Fiber 参考把 fiber.state 定义为当前生命周期状态，fiber.store 是加载期间必需服务实现的快照。依赖不存在可能让消费者无法激活；一个提供方失败也可能影响多个消费者。必须根据报告验证这种关系，不能只凭列表顺序断定根因。
| 线索 | 可以得出的信息 | 尚不能确定的事 |
|---|---|---|
| 失败插件及原始堆栈 | 记录了一次激活错误 | 是否还有其他错误 |
| pending 插件 | 该实例尚未激活 | 缺失服务为何不可用 |
| 缺失服务 | 消费者所需依赖不可用 | 提供方为何没有提供它 |
| 仅有可选插件警告 | 出现了警告 | 不会仅因此生成必需失败报告 |
DeepSeek Harness：完整诊断在哪里？
在标准错误输出中找 Full diagnostics:。写入成功后，它给出 $DSH_HOME/logs/ 下唯一的 startup-<timestamp>-<uuid>.log，默认目录是 ~/.dsh/logs/。旧报告不会被覆盖或自动删除。只有文件写入成功才打印路径；如果无法写目录或文件，标准错误会包含写入错误和完整报告，退出码仍为 1。
报告记录 DSH 和 Node 版本、平台、profile、根配置路径、所有未激活插件的模块与状态、原始错误以及启动警告和错误参数。没有 fiber 的导入错误也会被收集，所以不能因为找不到 fiber 就认为没有错误。收集过程包含异步失败清理，直到启动稳定为止。它不会独立收集环境变量或配置内容，但插件自己记录的错误可能包含其中的值。
收集器保留嵌套原因、聚合错误成员、循环引用、不可枚举属性和 Symbol 属性；自定义检查器被禁用，访问器只描述而不求值。这有助于保留简短控制台消息遗漏的线索，却不等于报告已经脱敏。
DeepSeek Harness：怎样沿缺失服务定位？
- 记录失败插件、原始堆栈与嵌套原因。原始报告没有自动脱敏，先保留在私有位置。
- 逐项记录 pending 插件和对应的缺失服务，区分必需项与其他等待项；列表顺序本身不是完整依赖图。
- 找出当前组合中预期提供该服务的插件。Cordis 入门说明插件通过
inject声明必需服务，并等待服务出现。 - 对照实际错误和配置，区分提供方激活失败、未包含在所选 profile 中，或在消费者作用域中不可用。单独的“缺失”标签不能决定是哪一种。
- 修复有证据支持的原因，按当前组合要求重启或重载，再比较相同插件和服务条目。最后实际使用目标能力，不要只看一行消息是否消失。
例如，消费者依赖某服务，而提供方堆栈显示配置校验失败，应先调查该校验错误；修改仅在等待服务的消费者不能解决已观察到的提供方故障。反过来，如果提供方根本不在选中 profile 中，也不能凭空断定它启动失败。报告和实际组合需要一起看。
DeepSeek Harness：配置与生命周期如何影响判断？
Profile 是插件组合，而不仅是目录名称。CLI 依次应用 bundle、profile、home 和命令行指定的补丁，后面的补丁替换目标行的完整配置。同名插件在不同组合中可能收到不同输入；一个 profile 的修改不一定解释另一个 profile 的失败。可参考配置层与补丁优先级追踪来源。
Fiber 参考说明 fiber.await() 等待当前生命周期工作，并重新抛出配置校验或插件启动错误。对开发者来说，激活失败与等待依赖是两种不同观察。导入失败可能发生在 fiber 创建之前，因此既要检查未激活实例，也要检查报告中的原始错误。不要从 pending 一词推断未记录的状态转换或重试策略。
对比多次尝试时，记录相同的 profile、版本及相关配置层。安装内容或补丁变化可能改变服务提供方。每次有目的地修改后，保存修改前后的现象；启动成功只能说明这次组合启动了，不能证明每个可选插件和用户工作流都正常。
DeepSeek Harness：分享和排查有哪些边界？
原始报告不应直接公开。CLI 明确提示插件错误可能包含配置或凭据值，且不会自动脱敏。本地文件权限也不能保证复制、上传或截图适合公开。检查嵌套错误、路径和警告参数，替换敏感内容时保留失败提供方与等待消费者之间的关系。具体步骤见启动诊断脱敏指南。
不要看到缺失服务就随意安装插件。先确认预期提供方，以及它的原始错误是否解释了缺失。插件列表或启动成功都不是安全评估。如果没有找到能对应缺失服务的原始失败，应在脱敏后的复现信息中说明这一点。
怎样利用写入失败时的输出？
如果没有看到报告路径，不要立即假设没有诊断。CLI 只有在文件写入成功后才打印路径；写入失败时，它会在标准错误中给出写入错误和完整报告。先确认保存的是完整标准错误，而不是只截取了末尾几行。写入错误本身与插件激活错误是两个不同线索：前者解释报告为何没有落盘，后者解释启动为何失败。两者都要检查，也都可能带有不适合公开的本地路径。
如果多次启动生成了不同报告，按本次启动的输出所指路径对应，不要只凭文件名猜测哪份报告属于哪次尝试。保留第一次失败和修改后的结果，可以比较失败插件是否变化、等待的服务是否减少，以及是否出现了新的原始错误。不要把多个报告直接合并成一段堆栈，否则很难知道某条警告属于哪次运行。
如何避免把下游现象当成根因？
一个消费者等待服务，不代表它自身配置完全正确；在提供方恢复后，它可能继续暴露另一个错误。因此修复提供方后要重新检查完整启动结果。相反，多个消费者同时等待同一个服务，也不意味着必须分别修改每一个消费者。先按服务归类，再从原始失败和当前组合寻找证据，是更容易复现的排查顺序。
DeepSeek Harness：相关术语是什么？
- 插件：可以提供或消费服务的行为单元。
- 服务：由提供方实现、通过上下文键访问的能力。
- 依赖注入：声明所需服务并据此协调激活。
- Fiber：跟踪单个插件实例的生命周期和副作用。
- Pending：报告中尚未激活的等待项，需要结合其他证据解释。
相关阅读
本文首发于 DSH Plugin 社区（dsh-plugin.com），版权归属 DSH Plugin 社区。
原文地址：https://dsh-plugin.com/zh/blog/pending-plugins-missing-services-diagnostics
