Second alignment step for #2248: document-level drag intake behind the new
DropOverlay atom, lightbox close icon and shared dialog mask, DeepSeek Chat
thumbnail rules (single 240px long edge with ratio clamp, 64px tiles, merged
consecutive assistant images), image limits raised to 20/10MiB/100MiB and
published to clients as the imageLimits projection, whole-batch intake
pre-check with product-copy banners, and attachment-error reasons mapped to
localized copy.
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.
Re-record the sidebar regions that the redesign intentionally changed:
group session counts are gone, search is a collapsed header action, and
grouping lives in the View options menu. Session rows also follow the new
recency ordering, so their tree order updates with the counts.
The sidebar redesign removed group session counts, collapsed search into a
header action, and moved grouping into the View options menu. Update the
browser scenarios that waited on the old surfaces:
- Wait on the Ungrouped bucket row instead of the removed session-count text.
- Expand the collapsed search control before filling the renamed input.
- Open the View options menu instead of the removed Group by button.
- Assert the persisted grouping under the new dsh.workspace.view.v4 key.
- built-boot: assert the fixture workspace group row instead of its count.
The Gateway and the carrier each compiled both halves under one tsconfig, so
the Host aggregate built their browser faces — including the face that owns
`ctx.remote`, the most likely future consumer of a generated `/remote`
contribution. Both packages now expose a host and a client face, and each
aggregate references only its own; three modules the halves share appear in
both file lists, as api/remotes already does.
The two apps/web specs in the Host aggregate restate the conversation engine's
Context key format instead of importing the Client runtime for it. A drift
makes the key miss its rendered node, so the assertion fails loudly.
The Host aggregate now reaches one Client project, the carrier's host face,
which the Gateway's own dispatch face needs; no generated contribution is
reachable from it.
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.
CI captured `- text: Loading history…` where the golden holds the grandchild's
first message. The only wait before that capture is the offline banner, which
renders from the descriptor and says nothing about the transcript below it,
and `captureStableAria` calls two identical polls stable — two of which can
both be the loading placeholder on a loaded machine.
Waiting for the message the golden asserts makes the precondition match the
assertion. The race is not observable here (the history is already loaded when
the banner appears, so the wait returns in ~1ms), so this is reasoned from the
CI log and the helper's semantics rather than from a local reproduction; if
the history instead never arrives on CI, the lane now times out on the missing
message rather than committing a loading placeholder to the diff.
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.
