- Added bilingual notes for the new session feature, detailing the transition to an empty state upon session creation.
- Updated `SessionsService` to include a `clear()` method that resets the current selection and persists the empty state.
- Enhanced the `EmptyState` component to reflect the new design, including workspace selection and input handling.
- Modified CSS styles for improved layout and visual consistency in the empty state.
- Updated tests to cover the new session clearing functionality and its effects on the UI.
- Added TrajectoryCell, TrajectoryGroupHeader, and TrajectoryTurn components for rendering trajectory steps and groups.
- Introduced bilingual support with English and Chinese translations for trajectory notes.
- Updated conversation session models to include timestamps for various message types.
- Enhanced layout logic to handle expanded assistant blocks and tool results with duration metrics.
- Added CSS styles for new components to ensure proper display and alignment.
pi-ai is the library-backed twin adapter the tui-agent README already
points at ("swap one line to @deepseek-ai/dsh-llm-pi-ai"), and the
supported entry point for third-party providers (Anthropic, Google,
OpenRouter) mounted through the personal overlay under ~/.dsh. Making
it a declared workspace dep of the examples umbrella means
`pnpm install` resolves the symlink upstream so users configuring a
third-party provider via `~/.dsh/config.yaml` don't have to patch
`examples/package.json` locally (which their next git checkout would
wipe).
Placement matches the sibling llm-* cluster; workspace:* to match the
other adapters. No cordis.yml or README changes: mounting pi-ai
remains explicit and opt-in per the provider-routed-llm-adapters
Agent Note.
The session-title snapshot exposed a real activation race: ui-trajectory
and ui-question register into conversation-declared slots but only
injected 'slots', so nothing ordered their applies after ui-conversation's
— register() into the undeclared slot threw and the entry FAILED. Both now
inject 'conversation' as an ordering edge (documented as such; specs stub
the service where the bench declares the slot itself).
Review-bot findings, all three applied: the module loader's load sink
cross-checks the handoff id against the arriving row (a mis-stamped bundle
can no longer register under another entry's identity); the default
execute seam removes the inline script node right after its synchronous
execution (repeated HMR rebuilds no longer accumulate dead nodes); a
throwing onRebuilt subscriber is contained per-listener and routed to
onError instead of escaping the fs.watchFile callback.
The loading-chain RFC (2026-07-23-client-plugin-loading-model, en/zh)
states the shipped model in its final form: two package kinds (dshClient
means plugin), one module system + one plugin governor, the end-to-end
loading flow, and hot reload with its support boundary — written for a
first-time reader, no intermediate-design narration. The two 2026-07-19
GUI RFCs defer their loading-chain sections to it and drop stale
vocabulary. config-catalog regenerated for the package rename; pairing
manifest tracks the renamed pair.
ui-question landed on master as a full dshClient plugin package (composer
question flow); it enters the flat roster, apps/cli deps/refs, and the
smoke graph. Restore the workspace-context and user-interaction host deps
the conflict resolution had dropped.
client-hmr is a normal plugin package composed into dev graphs only. It
listens on /plugins/events and reloads one plugin per rebuilt frame,
serialized: invalidate, prefetch (fresh factory registers while the old
fiber still serves), registry.delete before touching the fiber, drain
disposers, drop owned style tags, entry.refresh(), fiber.await() loud.
Dependency cascade costs zero client code — fiber activation epochs
re-load dependents through cordis itself. Reload is coarse by design;
no rollback in v1; self-reload works with a frame gap the next rebuild
heals.
scripts/dev-web.ts (pnpm run dev:web) is the convenience watch-build:
it discovers its package list by scanning packages/*/*/package.json for
dshClient platform "web" at startup — no hardcoded roster — and talks
no protocol to the host. Gate bookkeeping rides along: knip entries for
the new packages, README model-experience allowlist rows.
The registry scans mounted Loader entries' dshClient declarations and
composes __DSH_BOOT__ {rev, entries} — inject edges and the immediately
mark come from manifests, never hand-copied; malformed fields fail loud
at load. The composing app owns one flat roster plus the --dev switch
(hmr row and bundle watching are dev-graph decisions).
The rebuild signal is the webserver's own observation: in dev mode the
registry stat-polls each scanned bundle (fs.watchFile; polling because
network mounts deliver no inotify), re-hashes on change, and broadcasts
a rebuilt frame on the /plugins/events SSE channel only when the rev
actually changed. Watch membership follows the table across rescans;
dispose drops all watches; a torn read self-heals on the next tick.
The POST /plugins/rebuilt endpoint is gone — builders and the host
share zero protocol. dsh web --dev logs the watched bundle list and
each rebuilt id with its rev transition.
Every client plugin package carries dshClient ({platform, inject,
immediately?}) and emits lib/client.js through the shared clientBundle
preset; exports["./client"] points at the bundle. The infrastructure
tier (connection, runtime, ui-theme, i18n, hmr) declares immediately: true
in its manifest — absent means lazy. The bundle purity gate covers all
nine packages: platform modules stay external, INLINE_SAFE wire layers
inline, any other cross-plugin value import is a build error. Migrations
that rule forced: scopeOf became a SessionsService method and
transportError moved into dsh-host-apiproxy's wire layer; the store
engine stays in runtime under a documented temporary exemption
(TODO(webload/store-rehome)).
The module system moves out of dsh-client-runtime (./loader retired) into
its own package: a lazy CJS table where executing a bundle only registers
its factory and materialization happens at first require, memoized, with
recursive requires self-ordering. ClientModuleSystem is a class; index.ts
keeps the types and a thin factory. Boot is two-phase: phase one prefetches
the immediately tier in parallel (registration only, failures deferred to
phase two's loud import); phase two mounts the vendored Loader with the
module system as internal, creates one entry per graph row plus the
app-shell pseudo-row the kernel appends itself, and settles on an
all-ACTIVE sweep. The shell kernel is self-sufficient: hand-rolled
loader-status stores, no plugin value imports, platform seed list single-
sourced in platform.ts.
