Repository navigation
[BUG] 0.4.1 在 DSH 0.2.1-rc.2 (Windows) 上不发布 ops_discover_tools，且全程无日志 #346
Description
环境
- DSH Desktop
0.2.1-rc.2（Windows 11 x64） - dsh-ops
0.4.1（npm 安装，profile 的 node_modules 下） - 呈现：Native（装配里没有非空
tools:ptc-only段） - profile：多 bundle（含若干第三方插件）
现象
- 会话从一开始就没有
ops_discover_tools；tools.schemas(agent)里只有ops_read_files和ops_bash - 提示词里
dsh-ops:discovery-tools段存在，但长度为 0 - 高级能力（glob / grep / stat / diff / write_file 等）始终不可用
- 全程没有任何 warn / error：
discovery publication unavailable; tools remain withdrawn.从未出现，日志目录里也没有 dsh-ops 的行
已排除
- 配置：bundle 默认
enabled: true, maxResults: 3, alwaysLoaded: []。另外在 profile patch 里显式加了一行dsh-ops-discovery（enabled: true+alwaysLoaded: [glob]），确认热重载生效后仍然不发布 - 安装完整性：与 npm 上 0.4.1 的 tarball 逐文件比对，178 个文件全部一致（仅 3 处本地
order常量改动，不参与发布路径） - Native 判定：在
agent/pre-step里调用prompt.assemble({ scope: agent })能正常返回 24 个段，其中没有tools:ptc-only→isNativePresentation为 true - 作用域：
scopeOf(行)= 根；scopeChainOf(agent)长度为 2；ownership.owns(agent)对 18 个活跃 agent 全部为 true - 权限：
sandboxPolicy.resolve()=danger-full-access，permitted()为 true
插桩结果（本地副本加日志，事后已还原）
给 reconcile() 和 own() 加落盘日志后：
- 第一次对账：
entries = 18, ready = 0，逐条entry.ctx === false（此时agent.ctx.plugin挂上去的子插件还没 apply） - 几秒后再对账：
entries = 18, ready = 18，ctx、owns、permitted、native四个条件逐条为 true own()被调用 18 次，registerNativeProvider(...)18 次全部 resolve，随后entry.owned.add('ops_discover_tools')执行- 但
tools.schemas(agent)里依然没有ops_discover_tools（18 个 agent 全部如此，工具数 41–52 不等），nativeProviders(ctx, agent)里也没有它（只有ops_read_files） - 对照组：用完全相同的方式（
agent.ctx.plugin({ inject: ['tools'] })→registerNativeProvider(scoped, [reg], t => scoped.tools.register(t), { inheritable: false, priority: 10 })）注册一个自定义工具，它正常出现在tools.schemas(agent)和nativeProviders里 → 注册路径本身可用 - 互斥量会卡死：
reconcile()开头if (stopped || mutating) return chain;之后连续数百次命中、再没放行过 —— 说明某次对账没有走到finally，此后所有发布尝试被静默跳过，且不产生任何日志
版本关系
dsh-ops@0.4.1 声明 peerDependencies["@deepseek-ai/dsh"] = "^0.2.0-rc.2"，本机宿主是 0.2.1-rc.2。用 semver 实测：0.2.1-rc.2 不满足 ^0.2.0-rc.2（0.2.0-rc.2 满足）。
想确认的点
0.2.1-rc.2是否在支持范围内？若不在，文档能否注明支持的宿主版本区间？- 第 3、4 条——注册 resolve 了，但既不进
schemas()也不进nativeProviders()——是不是对宿主 tools 作用域 API 的假设发生了变化？ - 第 6 条
mutating卡死是否已知？这条会让后续所有 reconcile 静默失效，很难排查。
需要的话我可以补上插桩的 diff 与日志格式（不含路径与主机信息）。
Reacted by EnchantedCrystalSword
Activity
winlin926 commentedon Oct 21, 2026
我这边也复现了，症状和你写的一模一样：升到 0.4.1 之后工具列表里只有
ops_read_files和ops_bash，ops_discover_tools不存在，其余文件工具一个都不发布，而且全程没有任何日志。查了一下可能有点线索。0.4.1 的 dsh-plugin.json 声明了 7 个组件（ptc / shell / file / discovery / panel / tui / hide-official），但 profile 的 loader 配置里只有 4 个（shell / file / background / ptc），缺的正好是 discovery。问题是这个配置现在改不了——我往 cordis.yml 里加了一条
dsh-ops-discovery，重启后整个文件被重写成了[]，只剩一行注释说树是由 bundles 和 cordis.patch.yml 叠出来的，还特意写了 "Edit cordis.patch.yml, not this file"。更麻烦的是 desktop 这个 profile 由 Electron 独占管理，命令行想看看组合结果都不行：
dsh --profile desktop --dump-config直接返回error: profile "desktop" is managed exclusively by the Electron application。所以现在从外部既看不到组合后的树、也没法安全地插组件。如果我哪里理解错了麻烦指正——特别是 cordis.patch.yml 里要新插一个组件到底该用什么写法，文档只提了 "insert lists"，但没给例子。
Haoming9527 commentedon Oct 24, 2026
I am adding a scoped troubleshooting guide for missing discovery rows and host compatibility checks, linked to the metadata and lifecycle fixes. It will distinguish stale profile composition from an actual runtime stall and will not claim unobserved Desktop recovery.
Haoming9527 commentedon Oct 24, 2026
The missing-discovery report has two distinct paths, now covered by reviewable changes:
cordis.patch.yml, including the Desktop-owned profile boundary. Editing generatedcordis.ymlis not a durable insertion mechanism. fix(metadata): declare tested hosts and export component icons #395 validates the public host patch/composition contract and declares the tested host versions.These changes do not claim that the original reporter's Desktop environment was restarted or recovered here. The configuration guidance is ready in #400; the isolated-probe fix has its own CI in #405. This issue remains linked to those concrete PRs pending review and the reporter's environment check.