dsh exits 0 when a profile names a bundle that is not installed (0.2.1-alpha.2: boot and --dump-config exit 0, --dump-config-schema exits 1)

[antst]

When dsh.profile.bundles names a package that cannot be resolved, DSH 0.2.1-alpha.2 skips it with one stderr line and carries on. A profile boot and --dump-config then exit 0; --dump-config-schema exits 1 for the same profile. Item B of #7850 reported the --dump-config case on 0.1.7-rc.2; this adds the boot path, the current alpha and the code locations.

Environment

@deepseek-ai/dsh@0.2.1-alpha.2 installed from the npm registry as a project dependency (pnpm 12.11.2), Linux x64 (Ubuntu 24.04), Node 25.9.0, a fresh DSH_HOME, stock CLI. The --help case is also asserted in hosted CI on Ubuntu 24.04 with Node 22.23.3: https://github.com/sessionbus/sessionbus-dsh/actions/runs/38156213539/job/114519621989 (script .github/scripts/prove-native-peer-policy.mjs).

Steps (dsh and pnpm on PATH)

export DSH_HOME="$(mktemp -d)"
dsh plugin --profile headless list     # creates the stock headless profile
node -e '
const fs = require("fs"), f = process.env.DSH_HOME + "/profiles/headless/package.json";
const m = JSON.parse(fs.readFileSync(f, "utf8"));
m.dsh.profile.bundles.push("@example/not-installed");
fs.writeFileSync(f, JSON.stringify(m, null, 2) + "\n");'
dsh --profile headless --help >/dev/null;               echo "exit=$?"
dsh --profile headless --dump-config >/dev/null;        echo "exit=$?"
dsh --profile headless --dump-config-schema >/dev/null; echo "exit=$?"

Observed

Each of the three commands prints this line on stderr:

dsh: skipping profile bundle "@example/not-installed": Error: dsh: cannot resolve profile bundle "@example/not-installed" from the dsh installation or <DSH_HOME>/profiles/headless; run 'dsh plugin --profile headless install' if its dependency is not installed

command	exit status
dsh --profile headless --help	0
dsh --profile headless --dump-config	0, and the dump is printed without the bundle
dsh --profile headless --dump-config-schema	1, with a second stderr line: dsh: error: Selected profile bundle "@example/not-installed" could not be loaded; repair or remove its bundle selection.

--help after --profile is handled by the booted app, so the first command does boot the profile, and the headless usage text is printed as usual.

Where (published 0.2.1-alpha.2 packages)

• @deepseek-ai/dsh-app-boot lib/index.js:1006-1026: loadProfileDirectory catches every per-bundle error, including the resolution error thrown at :986, and records it in skippedBundles.
• @deepseek-ai/dsh lib/profile-boot-BZ2ZjNWi.js:185-191: prepareProfile prints the skipped bundles (reportSkippedBundles, :188) and carries on. Boot and --dump-config (lib/dump-config-BEDI-dNY.js:25) both go through it, and neither changes its exit status.
• --dump-config-schema is the exception: @deepseek-ai/dsh-app-boot lib/index.js:3318-3321 turns each skipped bundle into an error diagnostic, :3069 then marks the document incomplete, and @deepseek-ai/dsh lib/dump-config-schema-DhhNOaro.js:38 sets exit code 1.
• @deepseek-ai/dsh-app-boot@0.1.5-rc.2 lib/index.js:849-860 has no catch around the same resolution, so the error propagated there. We read that from the package and did not run it; it agrees with the exit 1 that 0.1.7 起两个静默升级缺口：`plugin add` 只补「本次新加」的 layer 行；`--dump-config` 对坏树恒返回 exit 0 #7850 reports for 0.1.5-rc.1.

Expected

A way for non-interactive callers to detect a partial composition from the exit status: a non-zero exit, or an opt-in strict mode.

Impact

Scripts, CI jobs and supervisors that gate on the exit status accept a profile whose declared bundle did not load. An installer that failed to install a bundle goes unnoticed until the feature is missing at run time.

Suggestion

--dump-config could reuse the error diagnostic that --dump-config-schema already produces and exit 1. For boot, a launcher flag or environment variable (for example --strict) that turns a skipped bundle into a startup failure would keep today's degraded boot as the default for interactive use.

We did not run a model turn or a long-lived surface such as web with a missing bundle.

Related: #7850 (item B), #6539 (asks for a boot preflight that exits 0 or 1).

[argszero]

Thanks — the three-command table plus the file/line pointers made this quick to check against origin/master (d743267388), and your reading of the boot path is exact. Three things worth adding, all read from the shipped source.

1. The skip is a documented contract; the exit status is the only part that is missing. packages/boot/app-boot/README.md states it outright:

Bundle resolution, manifest, and patch-loading failures skip that bundle without changing its selection; the loaded profile lists each skip in skippedBundles, and the launcher prints them once per start with reportSkippedBundles. … Skipping a bundle does not guarantee that the remaining composition can provide the required services.

So there are two separate questions — should a partial composition boot (today: yes, by design, and item B of #7850 assumes the same), and how does a non-interactive caller learn — and only the second one is open. Your report is the sharpest statement of it I have seen.

2. The single stderr line is also not durable anywhere a GUI user can see. Both sinks are closed for a boot that exits 0:

• $DSH_HOME/logs/startup-*.log is written by reportStartupFailure (apps/cli/src/startup-diagnostics.ts), which has exactly one caller: the StartupError handler in apps/cli/src/bin.ts. A skipped bundle never raises StartupError, so no report file is created for this case.
• In the desktop shell the Host child's stderr is accumulated into an in-memory string bounded to 64 KiB (apps/desktop/src/host-process.ts: MAX_HOST_DIAGNOSTIC_CHARS = 64 * 1024, child.stderr.on('data', …)) and surfaces only as a suffix on a failure message. A boot that exits 0 never produces that message, so the desktop user gets no signal at all, while the terminal user gets one line that scrolls away.

That is why I read this as a sink problem rather than only an exit-status problem, and it is probably why the --dump-config case keeps resurfacing since #7850.

3. The machinery your --dump-config-schema row exercises already exists; the ask is one more consumer of it. As your own reading of the packages shows, that command turns each skipped bundle into an error diagnostic, marks the document incomplete and exits 1. Your suggestion 1 is therefore the cheapest consistent rule rather than a new policy: a skipped bundle is already an error for the schema dump, and treating it as one for the config dump applies the same judgement to the second reader of the same composition. A --strict for boot would need the launcher, and one implementation fact is worth recording for whoever considers routing it through a plugin instead: auditStartupEntries (packages/boot/app-boot/src/index.ts) marks an entry required only when its id is in the built-in set or it is the bootstrap include, so a third-party entry id can never be in that set and a third-party failure takes the warn branch — the application still starts, and no plugin can turn that into an exit status.

[argszero]

Follow-up to the analysis above: this gap now has a plugin form.

@argszero/dsh-activation-doctor@0.2.0 — https://www.npmjs.com/package/@argszero/dsh-activation-doctor

dsh plugin --profile <name> add @argszero/dsh-activation-doctor

It already filed the activation report the harness composes but never writes. 0.2.0 adds the stage this thread is about: the profile manifest's dsh.profile.bundles are diffed against the launcher's own ctx.profileContext.startedBundles, and for every declared name that contributed no layer the skip reason is recovered from loadProfileDirectory(...).skippedBundles.

For the case in this thread the durable report carries:

profileBundles: 2 declared, 1 started, 1 did not start
...
profile composition
@acme/dsh-missing-plugin
  Error: dsh: cannot resolve profile bundle "@acme/dsh-missing-plugin" from ...
reasons: recovered from @deepseek-ai/dsh-app-boot (the launcher's own profile loader)

Three things worth stating plainly, because they are why this is a plugin rather than a patch:

• It cannot turn a partial composition into an exit status. auditStartupEntries marks only built-in ids and the bootstrap include as required, and that policy lives in the launcher. The report is where an operator can see a partial composition; a --strict flag would still have to be yours.
• It declares no dependency on app-boot. @deepseek-ai/dsh-app-boot is imported at runtime, in the one situation where it resolves. Where it does not, the finding stands and the report says reasons: unavailable — <error> rather than dropping the bundle.
• It is a detector, not a repairer. It does not revive the bundle, rewrite the manifest, or touch the marketplace row. loadProfileDirectory can itself write <profile>/package.json through its dropRetiredBundles step, so the read is guarded to the case where the manifest already disagrees with the running process — named here rather than hidden.

A plain cordis host has no profileContext, so the section is skipped and the plugin mounts anywhere. The report is a private 0600 file under $DSH_HOME/logs, and its first line warns that raw plugin errors can carry configuration or credential values.