The cordis preset loses every filesystem skill in Desktop, because its only skill provider points inside app.asar

[l33tdawg]

The cordis preset loses every filesystem skill in Desktop, because its only skill provider points inside app.asar

Component: skill/skill-filesystem, bundle/web-app/cordis.patch.yml, host file service
Version: 0.2.0-rc.2 · Platform: macOS, Desktop app

Summary

With the cordis agent preset selected, skill cannot load the four skills the preset ships, and it
cannot load skills the user wrote either. Skills served by @deepseek-ai/dsh-skill-office still
load, so the registry and the tool work. What fails is the only filesystem provider an agent has.

The provider configuration is the problem. bundle/web-app/cordis.patch.yml disables the host
skill-filesystem row on purpose, because presets own local discovery. The cordis preset then
mounts its own copy with customSkillDirs pointing at @deepseek-ai/dsh-agent-preset/skills, which
in the Desktop app lives inside app.asar. The host file service fails on that path with
TypeError: Cannot mix BigInt and other types, use explicit conversions, and discoverRoot treats a
failing root as a failing provider:

1. The host row is disabled, so the preset's row is the only provider for local skills.
2. That row's only custom directory is inside app.asar.
3. The file service cannot read inside the archive, and the error is a TypeError rather than an
   absence, so it is not classified as one.
4. discoverRoot awaits each root without a guard, so this one rejection ends the provider's whole
   list(). The custom directory is scanned before the default roots, so the project's
   .dsh/skills, ~/.dsh/skills and ~/.agents/skills are lost with it.
5. SkillRegistry answers a throwing provider by skipping it and keeping the others. That is the
   right call for one bad provider, but nothing reaches the user, and the catalog merely looks small.

cordis-plugin-development/SKILL.md already describes the constraint this path runs into:

In Desktop the directory sits inside app.asar, which only the Host process's own file reads can
open; shell commands (ls, cat, cp, cmp), the glob and search tools (they run a native
ripgrep process), node, and pnpm all fail on it.

Host file reads are what the skill provider uses, and they fail here.

Reproduction

1. Choose cordis in General settings, then agent preset. Start a new session: a preset is fixed at
   session start.
2. Ask that session to load a bundled skill, then a user skill, then a skill from another provider:

skill("cordis-plugin-development")    -> skill "cordis-plugin-development" is unknown or no longer available
skill("agent-experience")             -> same
skill("cordis-composition-reference") -> same
skill("editing-cordis-compositions")  -> same
skill("find-skills")                  -> same   (~/.agents/skills/find-skills, valid front matter)
skill("human-writing")                -> same   (~/.agents/skills/human-writing)
skill("technical-writing")            -> same   (~/.agents/skills/technical-writing)
skill("office-docx")                  -> loads  (different provider)

3. Confirm the preset mounted. The session's request/header tool list holds exactly three tools
   more than a standard session: 70 against 67, with cordis_inspect_list,
   cordis_inspect_query and plugin_manager added, and nothing lost. Both introspection tools
   return live data.

4. Confirm the host row is off and the preset's row is the only one. This comes from the plugin
   manager's plugin list, which reads the live Loader tree:

{"entryId":"include:skill-filesystem","moduleName":"@deepseek-ai/dsh-skill-filesystem",
 "enabled":false,"fiberPhase":null,"patchId":"skill-filesystem"}
{"entryId":"include:tool-skill","moduleName":"@deepseek-ai/dsh-tool-skill",
 "enabled":false,"fiberPhase":null,"patchId":"tool-skill"}

include:skill itself is active. The preset mounts tool-skill and skill-filesystem in its own
tree, which is why the skill tool still works.

Evidence

The file service cannot read inside the archive. Each row was run from the affected session through
the harness's own read path.

Path	Result
.../app.asar/dsh/node_modules/pako/package.json	Error: Cannot mix BigInt and other types, use explicit conversions
.../app.asar.unpacked/dsh/node_modules/pako/package.json, the same file	reads normally
.../app.asar/dsh/node_modules/@deepseek-ai/dsh-agent-preset/skills/agent-experience/SKILL.md	same TypeError
.../app.asar/dsh/node_modules/@deepseek-ai/dsh-agent-preset/skills, the configured root	same TypeError
~/.dsh/profiles/desktop/package.json	reads normally
~/.dsh/skills/definitely-missing/SKILL.md	clean not found

Three of those rows are controls. A real path outside the workspace reads, a missing real path is
reported as absent instead of throwing, and the identical file under the unpacked mirror reads
normally. The failure follows the archive, not the file.

Walking the entries the archive's directory declares puts the skills at
dsh/node_modules/@deepseek-ai/dsh-agent-preset/skills: four skills, 17 files, 75,371 bytes. A walk
of the app bundle, ~/.dsh and the project trees found no unpacked mirror of that package, and one
unrelated copy in this workspace's own node_modules, installed as a dependency of
@deepseek-ai/dsh.

The shipped preset sets the path, and the web app layer disables the host row:

# bundle/web-app/presets/cordis.patch.yml
- id: skill-filesystem
  name: '@deepseek-ai/dsh-skill-filesystem'
  config:
    customSkillDirs:
      - !!js ...createRequire(baseUrl).resolve('@deepseek-ai/dsh-agent-preset/package.json')... + '/skills'

# bundle/web-app/cordis.patch.yml
# ... Only the per-agent rows move behind presets: the base host `skill-filesystem` row is
# disabled here (presets own local discovery), and `tool-skill` is what a preset mounts ...
- id: skill-filesystem
  disabled: true
- id: tool-skill
  disabled: true

Neither end of the failure path has a guard. In skill-filesystem, roots() pushes
customSkillDirs ahead of the user and bundled roots, and discoverRoot awaits each root without a
try, so one rejection ends list(). In SkillRegistry.listLayerCandidates, a provider that
throws is dropped for that read:

try {
	output = await waitWithAbort(provider.list(options), options.signal);
} catch (error) {
	if (options.signal?.aborted === true) throw toError(options.signal.reason);
	cacheable = false;
	this.ctx.logger.warn(`skill provider "${provider.name}" skipped: ${errorMessage(error)}`);
}

An observation marked incomplete still contributes its candidates, so the existing incomplete
channel is enough to keep the readable roots. Only a thrown provider contributes nothing.

That warning is the only trace, and it does not reach the user. This is the same shape as #8633
("Host plugin failures are invisible in dsh web"). The skill tool's description tells the model
that a session skill catalog exists and that names come from it, so a shrunken catalog produces
nothing but "unknown or no longer available".

Impact

Any Desktop install on this version that selects the preset. The preset and the path both ship with
the app, and the Desktop archive layout is what the bundled skill's own text describes. The loss
reaches past the row that causes it: user skills in the standard roots stop resolving too.

Proposed fix

1. Guard the roots instead of the provider. In discoverRoot, skip a root that cannot be read, mark
   the observation incomplete and keep the readable roots. A provider observation already carries a
   complete flag, and today only a watcher failure sets it. As written, one bad entry in
   customSkillDirs costs a user every local skill.
2. Stop handing out a path the same file service cannot open. Either teach the host file service the
   archive read that the shipped skill documentation assumes, or resolve the preset's bundled skills
   directory to something readable, such as the unpacked mirror or a directory the installer writes.
3. Surface the skip. A provider dropped from a read should appear somewhere a user will see it, in
   the session or on the plugin status surface, rather than in one host log line.

Verification

Verified in the affected session on macOS, Desktop 0.2.0-rc.2, preset cordis: every skill call
above; every file read above with its controls; the archive walk; the live plugin listing that shows
the host row disabled; the preset declaration, the disabling patch and the code paths quoted. All
were read from the installed bundle or run in that session.

Three things were not verified.

The skill provider "filesystem" skipped: line was never observed. The Desktop app does not show
host logger output to the user or the agent. That this provider throws on its single configured root
follows from the file service measurements and the unguarded discoverRoot; the skip itself is read
from SkillRegistry.

No source checkout was tested, so whether this reproduces where the preset resolves to a real
directory is unknown. The bundled skill's text implies it does not.

Whether the previous preset was affected is also unknown. A preset is fixed at session start, and no
session log records the catalog, so the failure cannot be re-queried after the fact.

[l33tdawg]

Confirming this one and adding a second symptom from the same root. The provider does not only lose every skill: it also switches off the model-facing skill catalog entirely, so a cordis agent is not told that any skill exists. The two failures need separate fixes, and the second one survives a workaround that repairs the first.

The presets differ only in that row

Both presets mount skill-filesystem and tool-skill. standard mounts the row bare, so its roots are the real defaults:

# presets/standard.patch.yml
          - id: skill-filesystem
            name: '@deepseek-ai/dsh-skill-filesystem'
          - id: tool-skill
            name: '@deepseek-ai/dsh-tool-skill'

cordis adds the archive-relative custom directory this report names:

# presets/cordis.patch.yml
          - id: skill-filesystem
            name: '@deepseek-ai/dsh-skill-filesystem'
            config:
              customSkillDirs:
                - !!js ...resolve('@deepseek-ai/dsh-agent-preset/package.json')... + '/skills'

Why the catalog disappears

The watchdog, not the skill read, is what marks the observation incomplete, and its first step cannot see inside the archive:

1. @deepseek-ai/dsh-fs-local watch() begins with const directory = (await this.stat(target, signal))?.type === 'directory'. On this machine stat on the configured path throws ENOTDIR, because app.asar is a 121 MB file: statSync → ENOTDIR, lstatSync → ENOTDIR, readdirSync → ENOTDIR.
2. That rejection reaches skill-filesystem lib/index.js:97, await this.watchManager.observeRoots(roots), which sits in a try whose catch sets complete = false for the provider's whole observation. The watcher is on by default (enabled: config.watch ?? true, :494) and covers every root, customSkillDirs included.
3. :104 then returns { candidates, complete: false } instead of an array. dsh-skill listLayerCandidates treats an incomplete observation, and a thrown provider, the same way: cacheable = false on both paths (:353 for the throw, :358 for the incomplete observation).
4. dsh-skill snapshot() maps that to { skills, complete: false } and caches nothing.
5. dsh-tool-skill:216 refuses to publish while the snapshot is incomplete (if (!snapshot.complete) return decision), and :227 keeps it silent (if (!history.published && skills.length === 0) return decision).

A watcher exists to invalidate a cache. As written it decides whether the discovery result may be published at all, so a directory that cannot be watched is indistinguishable from a directory that cannot be read. chokidar itself accepts this path without error, which is what points at the stat in front of it rather than at the watcher library.

The measurement

Every session log on this install carries at most one catalog message, and its presence tracks the preset exactly. Logs were decoded from ~/.dsh/sessions (the .jsonl.zstd files hold many concatenated frames; zlib.zstdDecompressSync returns only the first, so each frame is decompressed separately).

Preset	Sessions	With a catalog message
standard	42	42
cordis	5	0

The version and preset are the same for all of them, so the only variable left is the row. A fresh cordis session created after the archive-relative root was replaced by a readable directory still received no catalog, while skill calls in that session resolved every bundled skill and every skill under ~/.agents/skills. Callability and visibility are independent here, and fixing the first does not fix the second.

Completeness is merged across the scope chain

snapshot() merges the global layer with the viewing agent's preset layer, and one non-cacheable layer makes the whole observation non-cacheable. A provider failure inside a preset therefore suppresses the catalog for every agent viewing that preset, including skills registered by providers that are working. In this install the global layer held a readable provider for those same four skills and the catalog still never appeared.

Proposed fix

1. Do not let the watcher gate discovery. observeRoots should not be able to mark a provider incomplete: call it after the candidates are collected, or contain its failure inside the watcher, so complete describes the read.
2. Do not let one provider suppress another's catalog. dsh-tool-skill can publish the model-invocable entries of an incomplete snapshot, the same way an incomplete provider observation already contributes its readable candidates (BUG-REPORT-asar-skill-roots.md, "An observation marked incomplete still contributes its candidates").
3. Keep the discoverRoot guard from item 1 of this report. It addresses the read path; this comment addresses the watch path.

Not verified

stat on the configured path was measured with Node's fs, in a shell rather than in the Desktop host process, so whether the host's file service wraps it differently is not established. Everything from observeRoots onward is read from the installed bundles for 0.2.0-rc.2. The skill provider "filesystem" skipped: line and the SkillWatchManager warning remain unobserved, for the reason this report gives: Desktop shows the user no host logger output.

[xiaoshenming]

补一条可以从包内直接核到的机制，帮你定位 YAML 那一侧：includeDefaultRoots: false（@deepseek-ai/dsh-skill-filesystem README 的配置表，桌面端 0.2.0-rc.2 里同版）一次性关掉项目根（<project>/.dsh/skills、<project>/.agents/skills：rank 100/200）、用户根（$DSH_HOME/skills、~/.agents/skills：400/500）以及 $DSH_BUNDLED_SKILL_DIR 默认值，剩下的只有 customSkillDirs（rank 300）和显式配置的 bundledSkillDir（rank 600）。

所以这个失败不是「app.asar 里读不到文件」这一条造成的，而是「先隔离到只剩一个根，再把那个根指向 app.asar」。两个推论：

• 如果那行没有写 includeDefaultRoots: false，~/.dsh/skills 和 ~/.agents/skills 本来还在扫描列表里；把技能软链过去就能被索引到（我们给插件做技能索引时用的就是这个落点）。现在它整份失效，基本可以判定那行写了 false。
• 不需要解包 app.asar：把 customSkillDirs 指向一个真实目录（或 bundledSkillDir 指到解出来的目录）即可。rank 300 在项目根之后、用户根之前，所以优先级行为也可预期。

第二条（目录整份不进模型视图）我们没复现，不猜；但如果它是「发现阶段就抛错 → 目录为空」，把根修好可能会一起好转。

[l33tdawg]

One correction to the YAML side, because it changes what the symptom can tell you: includeDefaultRoots is not written in that row, and the schema default is already true. So the failure does not establish that the row wrote false.

I pulled the shipped bundle out of app.asar and verified the extraction against the archive's own integrity.hash. The code the Desktop app runs for 0.2.0-rc.2 is byte-identical to node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-skill-filesystem/lib/index.js:

// lib/index.js:33
includeDefaultRoots: z.boolean().default(true),

// lib/index.js:76
this.includeDefaultRoots = config.includeDefaultRoots ?? true;

The cordis preset row writes neither the field nor a bundledSkillDir:

- id: skill-filesystem
  name: '@deepseek-ai/dsh-skill-filesystem'
  config:
    customSkillDirs:
      - !!js ...resolve('@deepseek-ai/dsh-agent-preset/package.json')... + '/skills'

standard ships the same row with no config block at all, and neither preset mentions includeDefaultRoots. Both were extracted from dsh-web-app/presets/ in the installed archive and hash-check clean.

That row therefore ran with includeDefaultRoots: true, and the project roots and user roots were in the returned list. Rank 300 is scanned, its read throws, and ranks 100, 200, 400 and 500 are never reached — the same mechanism the report already gives, and it is why ~/.agents/skills went missing while the row never asked for isolation. A row that writes nothing and a row that writes false produce the same silence here, so the observed symptom cannot separate them; only the code can, and it says true.

Two of your other points hold as written:

• bundledSkillDir adds its root at rank 600 independently of includeDefaultRoots (lib/index.js:181), so yes, it reaches a real directory without unpacking the archive.
• $DSH_BUNDLED_SKILL_DIR is the fallback that includeDefaultRoots: false removes: it is read only when bundledSkillDir is unset (lib/index.js:84).

On "rank 300 sits after project roots and before user roots": that ordering holds with includeDefaultRoots: true, which is what this row has. Phrased that way it is another point for the default rather than for a written false.

One thing to be careful about for whoever reads this next: with includeDefaultRoots: false the only roots left are customSkillDirs at rank 300 and an explicitly configured bundledSkillDir at rank 600, as you describe. In the state we measured, rank 300 sits inside the archive and rank 600 is unset, so the row has exactly one root and that root is the unreadable one.

Agreed on the second symptom being worth keeping separate: a repaired root does not clear it, because the watcher's first stat rejects on the archive path before discovery runs, so the observation is incomplete and the publisher refuses. The chain is in the comment above.

For reproducing either side, the extraction detail worth checking: in this asar the file bodies begin at 16 + headerSize + 2, where headerSize is the UInt32LE at byte 12. The wrong constant is quiet at first, because a file extracted two bytes early still has exactly its recorded size and starts mid-JSON; the archive's per-file integrity.hash catches it, and all four files above match at + 2.

[xiaoshenming]

你说的对，我两处都要收回，其中第二处是我自己给的兜底也不成立。

1. includeDefaultRoots 确实没写在那一行。 我把 app.asar 里的 dsh-web-app/presets/cordis.patch.yml 抠出来看了：skill-filesystem 那行只有 customSkillDirs（createRequire(baseUrl).resolve('@deepseek-ai/dsh-agent-preset/package.json') + /skills），standard.patch.yml 那行连 config 都没有；整个 asar 里 includeDefaultRoots 只出现在 dsh-skill-filesystem 自己的包里。schema 默认 true，所以项目根和用户根确实在返回列表里。我那条「基本可以判定写了 false」的推论作废 —— 症状分不出这两种配置，只有代码能，代码说 true。

2. 更该收回的是我给的兜底：在这个配置下，把技能软链到 ~/.dsh/skills 没有用。顺着代码走了一遍：

• FileSystemSkillProvider.list() 是 for (const root of roots) for (const skill of await discoverRoot(root, …))，没有逐根 try/catch；
• discoverRoot → listSkillRootEntries* 里只有「路径不存在」这一类被吞掉（isAbsentSkillPathError：ENOENT/ENOTDIR/FS_NOT_FOUND/FS_NOT_DIRECTORY），别的错误照抛；
• 于是 rank 300 一抛，循环就断在那里，rank 400/500 根本走不到 —— 你的说法我复核后成立；
• 再上一层 SkillRegistry.listLayerCandidates 是 catch 住整个 provider 记一条 skill provider "filesystem" skipped: …，连 list() 里已经收好的 candidates 一起丢。

所以它不是「少几个技能」，是 provider 整份不贡献 —— 这也是为什么 ~/.agents/skills 会一起消失。对报告本身没影响，但对修复路径有影响：必须让 rank 300 那个根能被 host 文件服务解析（把 preset 的 skills 落到真实目录，或改用 bundledSkillDir），往用户根做软链救不了。

你第二条（目录整份不进模型视图、且修好第一条后仍在）我没有复现，也不打算猜 —— provider 被 skip 只能解释「目录为空」这一个方向，解释不了它在你绕过第一条之后仍然存在。

[l33tdawg]

Both retractions are right, and the second one holds for a reason other than the one you give. I checked both against the shipped bundle while checking my own claim, and my previous comment turns out to be unproven on exactly this point.

The absence list swallows ENOTDIR, so it cannot be the mechanism

The shipped code confirms your reading of the list:

// lib/index.js:573
return hasErrorCode(error, "ENOENT") || hasErrorCode(error, "ENOTDIR");

// lib/index.js:576
return isAbsentPathError(error) || hasErrorCode(error, "FS_NOT_FOUND") || hasErrorCode(error, "FS_NOT_DIRECTORY");

and both root-entry readers return [] on that class (:624 for the file-service path, :648 for the Node path). The file-service reader is the one this configuration uses, because a ctx.fs is present and the custom root is not marked trusted (:617).

From there the argument inverts. If the archive root rejected with a plain Node ENOTDIR, listSkillRootEntries would return an empty array, the loop at :103 would continue, and ranks 400 and 500 would be scanned. A symlink into ~/.dsh/skills would then be discovered. The retraction is still correct, because the failure that stops the read is a TypeError (Cannot mix BigInt and other types), which is not an absence and does propagate out of the loop. But the absence list is evidence against ENOTDIR being what kills it, not for it.

The two paths that can poison the observation are distinguishable

I had collapsed them, and they are not the same failure:

Where	Code	Effect
Watch	:97 await this.watchManager.observeRoots(roots) inside try/catch	catch sets complete = false; list() returns { candidates, complete: false } and the registry never sees a throw
Read	:103 for (const root of roots) for (const skill of await discoverRoot(...)), no per-root guard	rejection ends list() entirely and the provider is skipped

Only the second makes SkillRegistry log skill provider "filesystem" skipped: <error>, because the registry's catch sits around provider.list() (dsh-skill lib/index.js:349-356). A watcher failure marks the layer non-cacheable and produces no such line. observeRoots awaits Promise.all(pending) over every root (:236), so a single watcher rejection on the archive root would take the whole call down and land in the first row.

That matters for the fix path, and it is where my own comment was wrong. I wrote that the watcher's stat rejects on the archive path and that is what marks the observation incomplete. The code cannot tell those apart on its own, and the shipped read-path measurement - the host file service returning a TypeError, not an absence - points at the read row instead: rank 300 throws, the loop dies, the provider is skipped, complete is irrelevant because nothing is returned at all. I am not going to assert it either way now, because both paths lead to a provider that contributes nothing.

The line that discriminates, and one experiment

The report lists skill provider "filesystem" skipped: <error> under "not verified" because Desktop shows no host logger output. If you can see the devtools console, that line is decisive and its error text names the path: present, and the throw is the read loop; absent while the catalog is still missing, and the watcher is the one reporting incomplete.

You can also separate them without logs: mount skill-filesystem a second time with watch: false (schema default is true, :37; consumed at :494) and the same customSkillDirs. If the throw persists with watching off, the read path owns it. If it disappears, the watcher does. No capture needed, and it settles a question that neither of us can settle by reading.

On the second symptom

I agree with leaving it alone. One provider being skipped explains an empty directory and nothing more, and it cannot explain a catalog that stays missing after the first cause is bypassed. That is still open in the report, and it is the part a maintainer needs to answer rather than either of us.

[l33tdawg]

Answering my own open question from the last comment. The missing catalog is not a second, unrelated defect: one skipped provider explains it exactly. I got there by changing a single field and watching what happened.

The gate that blocks is the completeness check

dsh-tool-skill decides whether to publish on agent/pre-step, behind three conditions (lib/index.js in the 0.2.0-rc.2 bundle):

	Line	Condition
tool identity	:207	ctx.tools.get("skill", agent) === skillTool
completeness	:216	if (!snapshot.complete) return decision
first publication	:227	refuses while nothing has been published and the list is empty

The middle one is the gate, and it is the only one the intervention touches. I kept the preset, kept tool-skill, kept the tool's identity, and replaced just the archive path in the preset's own skill-filesystem row (dsh-web-app/presets/cordis.patch.yml:143-147) with a real directory holding the same four skills, extracted from the archive. The same change retired the second filesystem provider row I had added earlier as a workaround, so that directory is the only thing left that can serve them.

Before the change: zero catalogs in every recorded cordis session, across two days of them. The corpus grew from 5 sessions to 22 and the count stayed at zero, while standard held at 42 of 42.

After it: four cordis sessions carry a catalog, a count that is still moving as the other sessions take their next turn. Three of those were created hours before the change and had already taken turns without one. The catalog names eleven skills, the four bundled ones among them, and each of those four loads by name from the replacement directory. Nothing else can serve them now, so that is not an inference from the symptom; it is the only provider left in the tree.

One timing note, because it surprised me. The profile edit alone did not reach the running app: a cordis session took a turn 54 minutes after the write and still published nothing. The catalogs begin after the app was relaunched. Same shape as #8635: an edit to the profile while the app is running does not reach the preset composition.

What throws

// dsh-fs-local/lib/index.js:238
async function probe(absolutePath) {
  const info = await probeStats(absolutePath, (path) => stat(path, { bigint: true }));
  // ...
  mode: Number(info.mode & 511n),   // :243

Under Electron, fs.stat(archivePath, { bigint: true }) hands back Number stats, so & 511n throws Cannot mix BigInt and other types, use explicit conversions. It reproduces outside the app:

ELECTRON_RUN_AS_NODE=1 "/Applications/DeepSeek Harness.app/Contents/MacOS/DeepSeek Harness" -e '
  const fs = require("node:fs")
  console.log(fs.statSync("/Applications/DeepSeek Harness.app/Contents/Resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-agent-preset/package.json", { bigint: true }).mode & 511n)'

That prints the TypeError. typeof statSync(archivePath, { bigint: true }).mode is "number", the same expression on /etc/hosts prints 420n, and readdirSync inside the archive works. The archive is readable; the bigint contract is what breaks.

Why the watcher is not the cause

resolveRootWatchMode (dsh-skill-filesystem/lib/index.js:502) climbs from the root, swallows absence errors (:524-527, the isAbsentPathError class that includes ENOTDIR) and returns the nearest existing ancestor. For a path inside the archive that ancestor is Resources/, with app.asar as the next segment, and app.asar is a real file. Watching it succeeds. So observeRoots never throws, complete is still true when the read loop starts (:97-101), and the failure lands in the loop.

The chain, in order

1. discoverRoot on the archive root goes through the host file service, which throws the TypeError above.
2. The loop at dsh-skill-filesystem:103 (for (const root of roots) for (const skill of await discoverRoot(...))) has no per-root guard, so that one rejection ends list().
3. SkillRegistry catches it, sets cacheable = false, and logs skill provider "filesystem" skipped: <error> (dsh-skill:351-354).
4. snapshot() returns complete: collected.cacheable (dsh-skill:238), which is now false.
5. dsh-tool-skill:216 returns, so nothing is ever published, and :227 keeps it quiet because nothing was published before.

One skipped provider therefore costs both the skills and the catalog, and the catalog is the part that hurts. A skill the model has never been told about may as well not exist; it stays callable only for someone who already knows its name.

Two things that would have shortened this

The per-root guard the report already asks for, and a skipped provider that says so somewhere a user can see. Today the only trace is a logger.warn that Desktop never shows, which is why this arrived as "the whole preset has no skills" rather than "one root is unreadable".

My local repair is a profile patch, not a fix for the shipped preset. presets/cordis.patch.yml still points that root inside app.asar, so every Desktop install has this by default.

[xiaoshenming]

给你那条 complete 闸门补上前半截的代码位置（0.2.0-rc.2 包内）：

@deepseek-ai/dsh-skill 的 SkillRegistry.listLayerCandidates 是 catch 整个 provider —— catch (error) { if (signal.aborted) throw; cacheable = false; logger.warn('skill provider "…" skipped: …') }，list() 里已经收好的 candidates 一起丢；随后 collect() 把 cacheable 带成 snapshot.complete，也就是 dsh-tool-skill:216 判的那个 complete。另外 complete: false 的观测不会被缓存（if (result.cacheable) this.collectCache.set(…)），所以这个状态每次请求都会重新发现、重新打一条 warn —— 反过来也能当诊断信号：日志里同一条 skipped 反复出现，就说明 provider 还在抛。