Moving `web-agent-presets` to the built lane took its coverage with it, and the
per-file gate named what it had been the only reach for: the session header's
`agentPreset` type check, and the preset subtree's `write()` override. Neither
belonged to a real-composition boot — a header validation case and a subtree
behaviour are package-level facts.
The `write()` test states why the override exists: the inherited method
persists the tree whenever the Loader thinks the config moved, and disposing an
agent disposes its subtree, so inheriting it truncates the shipped preset to
`[]` the first time a session ends.
`apps/cli/config/base.cordis.yml` and `web.cordis.yml` no longer exist — the
bundle split replaced them with `packages/bundle/{base,web-app}/cordis.patch.yml`
— so this file booted a path that was deleted under it and every CI run since
the merge failed at `ENOENT`.
It now boots what `dsh web` boots: an empty preset root with the two bundle
patches over it. That root sits outside the workspace, so bare plugin names
cannot resolve by Node's upward walk and the flat module fallback the preset
boot maintains is what makes them resolvable — the same mechanism, not a
test-only shim. That fallback links each package's PUBLISHED entry, so this
file now consumes the artifact plane and moves to the lane that builds first
(`.e2e.ts`, beside `built-bin.e2e.ts`), rather than the coverage lane, which
installs and runs on a clean tree.
Six review findings on the select surface, all reachable from the wire:
**Resume read the header, not the log.** The switch was recorded as
`agent-preset/selected` and every projection resolved from it, but `agentFor`
still composed from `inspected.meta.agentPreset` — the value written once at
creation. A blank session that switched and then ran turns came back after a
restart under the ORIGINAL preset, restoring that history under the tool set it
was not produced with, which is the mismatch this feature exists to prevent.
`inspected` already carries the events.
**Cold summaries dropped the preset entirely.** `summarizeCold` hand-copied
three header fields and omitted the fourth, so a restored session reported no
preset and the picker showed the deployment default. It now uses the same
projection the attached path does.
**`select` had no gate.** Two concurrent selects both passed the blank check;
the second `unmountPresetFor` then found no record, because the first had
already removed it, and both mounts installed into one agent layer. Selects on
one session now queue, and the blank check is re-read inside the queue. This is
not turn admission — a `session.prompt` racing a switch is the agent loop's to
reserve — but it closes the select-versus-select tear-down.
**A same-id restore was skipped.** The roster is a live directory, so "the same
inputs that worked a moment ago" does not hold: a changed file is exactly how a
same-id reselect fails, and skipping the restore left the agent with no
composition at all.
**`writable` was dead state**, initialized true and never set, so the row could
never disable. It now carries `settings.describe`'s bit — a browser that may
not write settings sees the current default and no control, rather than one
whose write answers `settings-not-exposed`.
**`list` was documented as id-ordered.** It is root-precedence order with each
root's own presets sorted, first root to supply an id winning.
Copying is already its own action, offered on the row being copied, so the two
routes now arrive at the same editor by whichever one the author chose. **New
preset** starting from some preset nobody named put a composition in the editor
that the author had to recognise as unwanted before deleting it — and the
preset it copied was the deployment default, which is the one least likely to
be what someone reaching for "new" wanted.
A blank draft has no source, so it names none and makes no read: the editor's
"copied from" line and header clause appear only when there is a source.
Authoring writes a FILE, not a settings field, so nothing on the wire announces
it — `settings/changed` covers the default moving, never the directory. The
chip therefore kept the roster it read when it first mounted, and a preset
authored to be used was missing from the one screen that starts sessions.
The page that changes the directory now says so, and every surface reading the
same roster re-reads it. The chip subscribes rather than being reached from the
outer scope, because it is registered later, under `conversation`/`sessions`.
The General row and the preset page already re-read on `settings/changed`, but
the hero chip did not — so changing the default and starting a session without
reloading composed the previous default. That is the one session the setting
claims to govern ("对此后新建的会话生效"), and the chip is what decides it.
A staged pick still wins: `load()` prefers the stage over the refreshed
fallback, so a refresh never overwrites a choice the user just made.
The preference row rendered `option.id` while every other surface — the
new-session chip, the session header label, the preset cards — renders the
metadata name. So the same roster read `标准模式` on one screen and `standard`
on the next, and the id is addressing, not a label. A preset that names itself
nothing still falls back to its id, which is then all there is to say about it.
The row's Chinese copy also still ended on the English word: the section is
`Agent 预设`, so the sentence about a running session keeping its composition
says 预设 too.
`ui-question`'s node half called `ctx.tools.register` on the host context.
`ScopedLayers.merge()` combines the global layer with the agent's exact-scope
layer, and an unscoped registration lands in the global one — so the tool
reached every agent no matter which preset composed it. `core-web`, sold as a
two-tool benchmark surface, really presented three.
Rendering a question is a host UI capability; having the tool is an agent
capability, and only a preset decides that. The node half is now empty and the
`tool-ask-user` row moved into the preset that wants it. The TUI keeps its own
row, having no presets.
The composition tests now assert the global tool layer is EMPTY, which is the
invariant that would have caught this: any tool outside a preset reaches every
agent. The browser lane's composition, seeded-history, and hermetic-skill
assertions address their registries through a composed agent for the same
reason — those services are per session now, and the host cannot resolve an
`isolate` realm by name.
The bundle split emptied `apps/cli`'s plugin dependencies, and the flat module
fallback links only that manifest's closure — so a preset row naming
`@deepseek-ai/dsh-persona` resolved to nothing and every preset mount failed,
leaving each session with an agent that had no tools, persona, or token meter.
Which packages the shipped presets compose is not implied by any bundle: the
presets live beside this manifest, so this is where their closure is declared.
The hermetic skill test now addresses the registry through the composed agent,
the only shape that can see a preset's `isolate` realm.
Moving the agent plane behind per-session presets took five rows with it that
the host still owns, and the Web surface stopped booting: `host-apiproxy`
injects `subagents`, so with the registry disabled here the entry never
activated and `dsh web` died at plugin-tree load.
The criterion is injection, not subject matter. A host row that injects a
service resolves it before any session exists, so there is no agent to key by:
`bash-env` (which `apps/cli/src/web.ts` injects to publish `DSH_WEB_URL`), the
`subagents` registry and its spawn/fork backends (a process singleton whose
cross-session queries the api-proxy serves, and whose provider names are
globally unique), and `tool-subagent-report` (a continuable setup on that
singleton, registered once per live session by a list that is not scope-aware)
all stay host-plane. What a preset chooses is which delegation TOOLS it sees.
The browser lane needs the second half: skill roots now resolve inside a preset,
a subtree the lane's include patches cannot reach, so the row's documented
environment fallback is pinned for the whole scaffold lifetime — presets mount
when a session is created, not at boot. Without it a developer's real
~/.dsh/skills enters replay requests and goldens while CI sees none.
The shipped host composition moved: `base.cordis.yml` and `web.cordis.yml`
are the dsh-base and dsh-web-app patch layers now. The gate still opened the
old paths and crashed on ENOENT — a gate that cannot read its inputs proves
nothing, loudly or otherwise.
Retargeting it also surfaced what the move implies for ownership: the web
bundle carries the roster and its browser plugin rows now, so the bundle's own
manifest is what must declare them. The gate's existing bare-plugin check said
so as soon as it could parse the file again.
The shipped surface stopped being two yml files: `base.cordis.yml` and
`web.cordis.yml` are bundle patch layers now, applied over an empty preset
root. This test still opened the old paths, so it failed before asserting
anything. It composes the same two layers the profile boot composes, over the
same empty root, and heals the flat module fallback the way the boot does —
the root lives outside this workspace, so bare plugin names have no other way
to resolve.
The web bundle's runtime row is disabled beside the webserver: it injects
`httpServer`, so a disabled port leaves it pending forever. It owns dist
serving and the URL prompt line, neither of which decides an agent's
capabilities.
`apps/cli` declares the packages the shipped agent presets name again. The
bundle split emptied its plugin dependencies, and the flat fallback links only
the app's dependency closure — so a preset row naming `dsh-persona` resolved
to nothing, and every preset mount failed. Which packages the shipped
presets compose is not implied by any bundle: the presets live beside this
app's config, so this app is what has to declare them.