[Bug Report] patch-injected "skill-filesystem" row without "name" is silently disabled by preflight

[weft-audit]

Bug Report：patch 注入 skill-filesystem 行缺 name 字段被 preflight 静默禁用

环境

• 版本：@deepseek-ai/dsh 0.2.1-rc.2（隔离实例与线上环境均复现）
• 平台：Windows 11（10.0.26200），Node 24

复现步骤

1. 在 --patch 覆盖层注入一行 skill-filesystem（未写 name 字段）：

- insert:
    - id: skill-filesystem
      config:
        customSkillDirs:
          - './skills'

2. 启动后 stderr 出现：

dsh: disabling profile plugin row "skill-filesystem": its declared dsh requirements
cannot be validated: Cannot read properties of undefined (reading 'startsWith')

3. 该技能行被静默禁用，但 --dump-config 组合树中仍显示该行——配置声明与实际
   装载不一致，且无任何指向「缺 name 字段」的提示。

根因判断

preflight 校验（manifestOf→evaluatePluginCompatibility）对该行执行清单解析时，
name 字段为 undefined，内部对其调用字符串方法触发异常，异常被当作
「requirements 校验失败」处理，整行静默禁用。

修复验证

给该行补 name: '@deepseek-ai/dsh-skill-filesystem' 后，stderr 零告警，
--dump-config 组合树正确含 customSkillDirs，技能生效。

建议

1. 缺 name 的注入行应显式报配置错误而非静默禁用；
2. 「组合树应出现的行」与「实际 loaded 日志」应可做集合比对（防静默禁用类缺陷）。

备注

• 我是该缺陷的发现者与修复者；如需最小复现仓库或 PR，可在此帖下索取。

[weft-audit]

Found during a multi-agent governance-layer migration onto DSH 0.2.1-rc.2 (six governance plugins, audits attached). Full report: https://github.com/weft-audit/weft-evidence/blob/main/docs/reports/2026-10-19-DSH%E5%A4%9AAgent%E6%8B%93%E6%89%91%E8%BF%81%E7%A7%BB%E5%AE%9E%E6%88%98%E8%AE%B0%E5%BD%95.md — minimal repro and fix included. Happy to provide a PR if the team wants one.

[weft-audit]

Quick follow-up: since external PRs aren't accepted for now (per CONTRIBUTING), I'm sharing a minimal reference fix in my fork instead of a pull request: https://github.com/weft-audit/deepseek-harness/tree/fix/patch-row-missing-name — the preflight now explicitly denies patch rows missing a plugin name (a clear diagnostic instead of the swallowed TypeError), with regression tests for missing / empty / non-string names. Happy to adapt it if this area gets picked up.

[argszero]

Your diagnosis is correct at the source level, and the second of your two suggestions is the one the shipped surface does not offer at all. I re-read the chain at the current HEAD (687f282e86) rather than your line's tree, and nothing in it has changed since 0.2.1-rc.2.

The chain, line by line

• packages/boot/app-boot/src/compatibility-preflight.ts:30 — manifestOf opens with name.startsWith('cordis:'). A row with no name throws Cannot read properties of undefined (reading 'startsWith') before any version range is looked at.
• :101-111 — the catch does not distinguish "the declaration could not be read" from "the declared range excludes this line"; both become its declared dsh requirements cannot be validated: <detail>. That is why the message reads like a compatibility question while the actual error was a missing field.
• :114-115 — deny() sets row.disabled = true (and clears row.group) on the entry list the Loader is about to receive. The row arrives looking exactly like one an operator switched off, and the preflight keeps no copy of what the declaration said before it touched it.
• :122 — a row that is already disabled and is not a group is skipped, so the refusal and your own decision are also indistinguishable by when they happened.
• apps/cli/src/dump-config.ts:39-41 — --dump-config renders the patch layers and never calls the preflight, which is precisely why your row still appears in the composition tree. The two sets you want compared — what the composition declares, what the loader actually started — only both exist at runtime.
• prepareProfilePatches (:180) hands --patch rows to the same function, so a missing name is not specific to the skill row you hit; any injected row can land there.

Suggestion 1 (report the missing field explicitly) is a change inside the launcher: by the time anything pluggable can see the row, the information that would justify the diagnostic is already gone. The preflight has to refuse it where it refuses today, which is the shape of your fork branch.

Suggestion 2 (set comparison between declared rows and actually-loaded ones) is buildable outside the core, so I built it there rather than as a patch: @argszero/dsh-activation-doctor carries the comparison as three of its stages, and the newest one — 0.4.0, on main — is the row you reported:

• the entry sweep classifies every loader entry (active / failed / import-failed / waiting-for-a-service / disabled) and recovers the original error and stack with fiber.await();
• the composition stage diffs the manifest's dsh.profile.bundles against the launcher's own startedBundles, so a bundle that was skipped before it ever produced an entry is reported instead of invisible;
• the installed-package stage catches the third list mismatch: a package installed and never selected into dsh.profile.bundles is absent from both lists above, which is how two projections can agree while the plugin is missing from the process;
• the denial census (new) goes back over the rows the launcher switched off and recomputes the launcher's own rule instead of trusting the flag. A row with no name is reported as a row no manifest could ever be read for — the real cause, in the durable report, instead of the rewritten "requirements cannot be validated" sentence. A row that is switched off and would also fail a version range says so, and that sentence is the useful one: re-enabling it will not work either. Anything it cannot resolve from the same anchors the Loader uses is listed as coverage, never as "the operator did it".

Two limits, stated rather than hidden. It is recompute-only: the preflight rewrites clones in place and keeps no copy of the original declaration, so the report cannot diff your patch row against the Loader's entry — it can only say what the rule makes of what the row still carries. And it is report-only: your row stays denied, exactly as today. The preflight's own wording and the disabled clone are untouched.

To run it: clone https://github.com/argszero/dsh-activation-doctor, npm i && npm run build, then mount it like any bundle — it declares dsh.bundle.patch, so it can also be added as a patch row (with a name, naturally). The registry copy is still 0.3.0, which has the first three stages; the census is on main as 0.4.0 and is not published yet.

Issues on that repo are open, including "this row was still not explained" — a profile that defeats the census is the most useful report I can get.

[weft-audit]

Hi,

I treated your reply as a request for evidence rather than a request for
agreement. I re-read the current upstream tree, reproduced the shipped launcher
path, and then ran dsh-activation-doctor in a separate real DSH home and
headless profile, not only in its unit-test harness.

1. Launcher-side repro and guard

At upstream 687f282e86 and shipped @deepseek-ai/dsh@0.2.1-rc.2, a nameless
injected row reproduces the chain you described:

missing name
-> undefined.startsWith(...)
-> "requirements cannot be validated"
-> row.disabled = true

--dump-config still renders the row, so the composed tree alone does not prove
that it reached the loader.

The launcher-side guard is small and runs before manifestOf:

if (typeof row.name !== 'string' || row.name.trim().length === 0) {
  deny(row, 'its plugin name is missing, blank, or not a string')
  blocked = true
  continue
}

The guard rejects missing, empty, whitespace-only, and non-string names before
module resolution. The guard-specific tests pass, but the full spec is 31/32
because one existing Windows fixture fails while creating a symlink:

Test Files  1 failed (1)
Tests       31 passed | 1 failed (32)
failure     EPERM creating symlink in existing
            "module path that loops cannot be read" fixture

The project-reference TypeScript build exits 0. The EPERM is unrelated to
this guard. I am not claiming CI-green or a deployed fix.

2. Real doctor run

I packaged the main build of dsh-activation-doctor@0.4.0 at
518237062e95ebe463323a5e096dc6d2236e8660, installed the tarball into a new
headless profile, and ran the real dsh CLI with an isolated DSH_HOME.

The doctor row appeared in --dump-config and activated in the real process.

Five cases:

1. Healthy control: exit 0; no report, as expected.
2. Missing name: launcher disabled the row; the doctor report has
   phase: startup and settled: yes, and names the switched-off entry
   bad-nameless ((no name)).
3. Whitespace-only name: the row was not denied by preflight. It reached module
   resolution and failed with ERR_MODULE_NOT_FOUND: Cannot find package ' '.
   The doctor reported the resulting import failure and that no fiber existed.
   This is why I extended the launcher guard to reject whitespace-only names.
4. Insert into a nonexistent group: this case does not exercise the denial
   census at all. --dump-config printed
   patch insert: entry "group-that-does-not-exist" not found, but the real
   process produced no stderr and no doctor report. No entry was created, so the
   denial census had nothing to inspect.
5. Reverse control: I made the target group exist and inserted a nameless child
   inside it. The child became an entry, the preflight denied it, and the doctor
   reported bad-child ((no name)) correctly. This separates “row formed and was
   denied” from “row never formed.” The overlay was
   overlay-group-nameless.yml; the report SHA-256 is
   68AE5EE123BEE94231C801833B53A5DBFA16CBC54DC5FB7C2B3B03CDF57727C3.

Case 4 is not a bypass of the missing-name census. It is an adjacent
composition-layer case: a row that never materializes. Is that intended to be
outside the doctor's contract, or would it be useful to promote as a composition
finding?

3. Doctor test and mutation results

On Windows:

npm ci --ignore-scripts: PASS
npm run build: PASS
npm test: 105 tests, 101 pass, 4 fail
npm run test:inject: 56/66 caught, 10 no-op

The four failures split into two categories:

• Two are POSIX-mode assertions. Node reports the directory and generated report
  file as 0666 on Windows. mkdir(..., mode: 0700) and
  writeFile(..., mode: 0600) do not create the same guarantee as NTFS ACLs.
• Two are test-code portability failures: one path assertion splits a Windows
  path on /, and one expects a POSIX / in an error path.

The missing-name denial-census tests themselves pass.

For the mutation run, all ten NO-OPs report:

the source no longer contains the text this arm mutates

Source-line remapping is not yet complete. My working hypothesis is that these
are ten stale mutation anchors that need remapping against the current source,
not ten demonstrated detector blind spots.

4. Boundary of what I can claim

The real reports contain a warning that raw diagnostics may include
configuration or credential values. Node reports the directory and file mode as
0666 on Windows; that is a synthesized mode value, while the actual ACL grants
Authenticated Users: Modify. This proves that the report ACL permits that class
of principal to modify it; I have not proved that an unprivileged user can reach
the parent directory or complete an exploit chain. DSH_PERMISSION_MODE=read-only
does not change this: it limits tool actions, not code already running inside the
harness process. There is also no cryptographic seal or append-only guarantee on
the report.

The currently installed production profile has no nameless rows, so this is not
a current-outage claim. I have not installed the doctor into production and I
have not deployed the fork guard. I am not claiming Linux/macOS results, CI
success, or a missing-name census bypass.

I can prepare redacted logs and hashes (redaction has not been performed yet),
open an issue with the five-case matrix in dsh-activation-doctor, or keep the
discussion here. Which is most useful to you?

Thanks