Correct the reworked English wording in the CLI profile section, architecture map, and llm-streaming cross-reference, then bring every edited pair's Chinese side along and re-record the pairing hashes.
parseCmdline(ctx, program): void only adapts commander control flow to
the launcher: it parses the immutable cmdlineArgs snapshot and turns
help, version, parse errors, and action rejections into a ctx.appExit
request. App validation and the ctx.provide of the app-owned service
live in the program's own synchronous .action(), which commander runs
inside parse — program.error(...) there shares the exit path with a
grammar rejection. Deletes the CmdlinePlan export, its unread ctx
parameter, the type-unsound (() => ({}) as T) default, and the
T | undefined return with its per-caller publish guard.
Overlaps master on the preset e2e, the web scaffold, and the generated
config-catalog triplet; all merged textually, so the catalog is regenerated and
its pairing hashes re-recorded rather than trusted.
The browse and native backends were dual-face packages: a Node backend plus a
browser surface under one tsconfig that referenced Client packages. That put
Client projects — and through them the Client runtime — inside the Host
compiler aggregate, which builds before the generated Remote contributions
exist. Each browser half moves to its own Client package, and both backends
become Node-only.
The interaction is still one choice: the adaptive chooser mounts the backend
and its surface as a pair of Loader entries and tears both down in reverse, so
a resolved kind still swaps both faces. Compositions that pin an interaction
directly now pin the pair, and the chooser's runtime-string package list keeps
naming everything a composing app must resolve.
Drop the filler and factually loose comments added with the tool-pwsh rows:
the platform expressions self-explain, the web-app overlay comment repeats
the file header, and the spec comments now state only the platform-scoped
evaluation fact.
The new default's whole claim is that a launcher configuring nothing still
finds a person's presets, and nothing asserted it through a real composition —
`user-root.spec.ts` plugs the service directly, and every other lane pins
`includeUserRoot: false` so the machine's home cannot decide a golden.
This lane boots the real base and web-app bundles with only the shipped root
patched in, points `$DSH_HOME` at a temp home before boot (the derived root is
resolved when the plugin is constructed), and asserts a preset placed there is
listed as `user`, reported healthy, authorable, and mountable into an agent
whose tool catalog it decides.
The service moved its "is a roster composed" reads to the derived root set;
the invariant companion still read `config.roots`. In the shape this change
exists for — an app configures nothing and the roster is the harness home
alone — that made the advisory warning fire while the fail-loud invariant
stayed silent, so an agent could address a model against an empty global
layer unchecked.
Both now read one source: `roots` exposes the resolved set, and the invariant
asks it. That decides the behavior deliberately rather than by omission — a
composition that mounts the roster now fails an unjoined agent whether its
roots were configured or derived, and `includeUserRoot: false` with no
configured roots is how a deployment keeps its agents on the host plane. Both
shapes are pinned; the derived-only case fails against the old predicate.
Three pieces of prose went stale with the first commit: the web-app bundle
comment still called the writable root an assembly fact patched in by
AppCLIEntry (removed in the profile-plugin-bundles refactor — `composeProfile`
owns it now, and only for the shipped root), and the shipped skill and its
Agent Note still called both roots "configuration". The README gains the
resolved-roster reader and the discoverable-but-undeletable preset a second
writable root produces.
`Config.roots` defaulted to `[]`, so a deployment that did not patch both roots
in got a roster with none — `dsh run` once booted exactly that and failed
resolving `standard`. The user root never needed an app: `<dshHome>/.agent-presets`
is the same place in every deployment, resolvable here the way
`dsh-skill-local` resolves `<dshHome>/skills`.
The roster now derives that root itself unless `includeUserRoot` is false, and
`apps/cli` supplies only the SHIPPED root, whose path an installed app alone
can resolve. The derived root is appended after every configured root, so a
shipped id still shadows a home directory claiming it and `writableRoot()`
still prefers an explicitly configured `user` root; the set is resolved once at
construction, because a root set that changed between a `list()` and the
`copy()` acting on its answer would author into a directory the caller never
saw.
Every test that pins an exact roster now says `includeUserRoot: false` — the
machine's real harness home must not decide what a golden or an assertion
counts.
The web-app overlay now disables the host tool-pwsh row too, and the shipped
presets (standard/code/cordis) declare both shell tool rows with inverted
platform gates — tool-bash on POSIX, tool-pwsh on win32 — so the preset layer
exposes exactly one shell tool per host and a preset can drop or replace the
shell tool on either platform. windows-shell.spec pins both preset gates and
both host tool rows disabled in the web composition; the loader and Windows
pwsh notes are updated in place.
The previous pass over-corrected: presenting both roots as unknowable made the
guidance vaguer without making it truer. Every `dsh` launcher puts authored
presets under `$DSH_HOME/.agent-presets`, so the skill and persona state that
as the answer to "where do my presets live" and reserve the read-back for the
path an agent actually opens or edits, which `copy()` already reports.
Neither root is a property of the preset layer. `Config.roots` defaults to `[]`;
the two the shipped agent sees are patched in by the dsh CLI, whose user root is
`dshHomePath('.agent-presets')` and whose system root ships beside the install.
`writableRoot()` then takes the first `user` root from whatever configuration
supplied it.
The skill and the persona stated `${DSH_HOME:-$HOME/.dsh}/.agent-presets/<id>/`
as where authored presets live, which is only the default install's answer, and
no call reports either root: `authorable` says whether a writable one exists,
and `list()` cannot reveal a user root that is still empty. Both now keep that
path as what to tell a user asking where to look, and direct every path an agent
acts on to `list()` or `resolve()` — which is also what `copy()` already relies
on, since it chooses the writable root itself and reports the file it created.
Review found two errors in the first pass.
The skill quoted `service "<name>" has been registered at <Owner>` as the
rejection for a service published into the root realm. That message only
appears when the loose name collides with one the host already supplies. A
preset publishing its OWN new service name reaches the root realm successfully
and is rejected by the mount audit instead, with `row(s) published
process-global service(s) [...]` — which is the shape a forgotten realm
actually takes. Both messages are now listed, verified by mounting one preset
of each kind.
The Agent Note claimed every harness package publishes exactly three file
patterns. 139 do; 28 also publish `lib/client.js`, 22 publish
`lib/types/**/*.js`, and `dsh-message-feedback` publishes `src`. The note now
states only the fact it needs: no package's `files` includes its README.
Also from review: the copy step no longer repeats the display name it already
set, the id rule spells out `[a-z0-9][a-z0-9-]*`, and the sandbox step says
reads need no escalation.
Yichen Jiang
imccyu
imccyu
Tianyi Cui
fz
Turtle
xjt
Chinesezjc
Huanqi Cao