桌面端的Cordis 創造模式無法加載技能 BUG

[Bryan-cmf]

标题：桌面端 Creator（cordis）模式下技能目录被静默抑制：customSkillDirs 解析到 app.asar 包内路径，chokidar 无法 watch

环境

• @deepseek-ai/dsh-desktop 0.2.0-rc.2（macOS arm64，Electron 44.0.0）
• 桌面 App（app.asar 内置 runtime）；同一台机器上 ~/.dsh/runtime 的 web host 表现正常

现象

在桌面 App 中分别实测四种官方 preset（以会话 transcript 中是否出现技能目录注入消息为准，即 <available_skills> 对应的 user message，而非模型口头回答）：

模式	技能目录注入
Standard	✅
PTC	✅
Minimal	❌（符合设计：preset 无 skill 行，纯终端模式）
Creator（cordis）	❌ （异常）

Creator 模式下 skill 工具存在且可调用，但 <available_skills> 目录从不注入——模型完全不知道有哪些技能。同样的 Creator 模式在 web host 上正常（能看到完整目录）。

根因分析

dsh-web-app/presets/cordis.patch.yml 中 skill-filesystem 的配置：

- id: skill-filesystem
  name: '@deepseek-ai/dsh-skill-filesystem'
  config:
    customSkillDirs:
      - !!js process.getBuiltinModule('node:path').join(process.getBuiltinModule('node:path').dirname(process.getBuiltinModule('node:module').createRequire(baseUrl).resolve('@deepseek-ai/dsh-agent-preset/package.json')), 'skills')

该表达式在桌面端把 customSkillDirs 解析到 app.asar 包内部的 dsh/node_modules/@deepseek-ai/dsh-agent-preset/skills：

1. Electron 的 fs 补丁可以 stat/readdir asar 内部路径，provider 构造成功；
2. 但 chokidar 无法对压缩包内部的"目录"建立 watch，observeRoots() 启动即抛错；
3. FileSystemSkillProvider.list() 捕获后置 complete: false；
4. dsh-tool-skill 的 agent/pre-step 钩子按 if (!snapshot.complete) return decision 静默跳过目录注入——无任何日志。

web 端不受影响的原因：~/.dsh/runtime 下 @deepseek-ai/dsh-agent-preset/skills 路径不存在，按"目录缺失"被宽容处理，includeDefaultRoots: true（默认值）的默认技能根照常提供完整目录。

复现步骤

1. 桌面 App 新建会话，模式选 Creator；
2. 问"列出你 available_skills 里的前几个技能"→ 回答没有目录；
3. 同问题换 Standard/PTC 模式 → 目录正常；
4. web host（同一 profile 语义）上 Creator 模式 → 目录正常。

修复建议

1. 直接修法：cordis preset 的 customSkillDirs 不应指向 asar 内部路径——将该 skills 目录随包解包到真实文件系统（app.asar.unpacked 或运行时目录），或改用运行时可解析的真实路径；
2. 健壮性：单个 root 的 watch 失败不应把整个快照拖成 complete: false（尤其当默认 roots 完全可用时），建议按 root 降级并在目录中标注；
3. 可观测性：目录因 complete === false 或工具身份检查失败而被抑制时，至少输出一条 warn 日志。排查期间还观察到另一现象佐证此点：某次 host 启动时 watcher 一次性失败后 complete: false 会持续整个 host 生命周期且无重试、无日志，直到重启才恢复——这类故障目前对用户完全不可见，仅表现为"模型不知道有技能"。

[argszero]

I checked the mechanics against master (d743267388) and your chain is correct end to end. Two details in the diagnosis are worth correcting, because they change what the fix has to be — and one of them makes the defect sharper than "a watch failed".

What is confirmed

• The preset expression is packages/bundle/web-app/presets/cordis.patch.yml:161-163 — createRequire(baseUrl).resolve('@deepseek-ai/dsh-agent-preset/package.json'), joined with skills. On the desktop that resolves inside app.asar, so stat/readdir succeed (Electron's fs patch) and the root is discovered.
• The watch is chokidar.watch(anchor, { persistent: true, depth: 1, … }) (packages/skill/skill-filesystem/src/index.ts:491-503). Watching a directory inside an asar archive cannot be established, so observeRoots() rejects.
• list() then returns { candidates, complete: false } (skill-filesystem/src/index.ts:186-201) — and the candidates are still there. Nothing readably failed.
• @deepseek-ai/dsh-tool-skill discards the whole observation on that flag (packages/skill/tool-skill/src/index.ts:225: if (!snapshot.complete) return decision), with no log. So your "the model is never told about any skill" is exactly right.

Correction 1 — it is not "no retry"; the retry is deliberate and cannot succeed

packages/skill/skill/src/index.ts:475-477 states the contract outright:

Incomplete observations are never cached, allowing consumers to retain last-good state and retry on their next request boundary.

So an incomplete observation is recomputed on every snapshot(), and tool-skill calls snapshot() on every agent/pre-step. The provider re-enters the watch path each time too (skill-filesystem/src/index.ts:357-365 → :380-395, with the in-flight promise cleared on both settle paths). The state is not stuck because nobody retries — it is stuck because the retry is structurally impossible inside an asar. That matters for the remedy: "retry more" or "reset the flag" would not fix it, and neither would a longer deadline.

Correction 2 — the flag is whole-observation, the failure is per-root

list() sets one complete for the entire provider (:187-193), and observeRoots() is a single await Promise.all(pending) over every retained root (:301-334). One root whose watch cannot be created therefore marks the union incomplete — while the other roots (including the bundled default root, :255-259, and includeDefaultRoots defaulting to true at :78) were read fine and their candidates are in the array.

That is the sharpest form of the bug, and it is your suggestion 2: in this environment the catalogue is materially complete and is thrown away anyway. A per-root watch failure should degrade that root, not the observation.

On "无日志" — there is one, and where it is missing matters

replaceWatcher does log (skill-filesystem/src/index.ts:432): skill-filesystem: failed to watch <path>: <error>. So the invisibility is not that nothing is emitted; it is that (a) the desktop shell does not surface engine logger output, as you noted in #9615, and (b) the model-facing silence is total and unattributable — tool-skill:225 returns without any trace, and SkillCatalogSnapshot is { skills, complete } with no reason field, so even a consumer that wanted to report why cannot name the failed root. Your suggestion 3 is right, and the flag carrying no reason is the part that makes it unimplementable from outside.

A third consumer goes dark on the same flag

Worth knowing for fix 2: it is not only tool-skill. Our own @argszero/dsh-skill-residency does the same thing at its read site (if (!snapshot.complete) return undefined). Any consumer that honours the contract as written loses the catalogue; the flag is the single point where "one unwatchable root" becomes "the model knows nothing". That is an argument for fixing it at the observation rather than downstream, as you propose — a per-consumer fix would have to be made in every consumer.

What we will do

We maintain the skill-facing plugin above, and this report is the second time the skill catalogue has gone silently dark (see #9375). Extending it to 0.2.0 with two arms, since the flag is the one seam a plugin can see:

1. stop treating complete: false as "publish nothing, say nothing" — publish what was readable, labelled as possibly incomplete, and emit a rate-limited named warning, so the invisibility is at least visible;
2. when the step carries no catalogue message and the observation is degraded, re-publish the readable catalogue itself (entry marker source.kind === 'skill-catalog', tool-skill/src/index.ts:271-275, so absence is detectable against a published type rather than by re-parsing the <available_skills> prose), under that same honest framing.

This is a mitigation, not a substitute for the two upstream fixes: the preset should not point customSkillDirs at a path inside app.asar, and a per-root watch failure should not invalidate the union.

Source: this discussion (#9608); the earlier skill-catalogue invisibility report is #9375.