Yichen Jiang
eab0aeb9db
The task registry has run every background bash, pwsh, pty-send, and one-shot subagent since it landed, but only the model could read it: a human at the Web client could not see that a build was running, tell a finished task from a stuck one, or find its outcome anywhere but the `run_in_background` tool card that printed an id and never updated. Task state now reaches the browser as one whole-snapshot `session/tasks` mux frame per session, pushed at every registry commit that changes what that session can see. `TaskService` gains `onTasksChanged`, which is owner-granular because owner-disposal removal is a change no per-task record can express. The carrier reads the exact owner the listener hands it, so a push stays correct while that scope tears down, and reads the baseline through the non-resuming `ctx.agents.get` so listing never revives a cold session. The client keeps a last-wins mirror on `SessionListState`, and a new `dsh-client-ui-task` package renders it beside the subagent catalog — rendering nothing at all until the session has a task, so an ordinary conversation grows no new chrome. Streamed per-task output and human-initiated cancellation are separate phases; the note records why neither has to undo this channel, and why no Web path may call the consuming `ctx.tasks.read()`.
@deepseek-ai/dsh-web-app
English | 中文
The dsh browser-surface bundle. cordis.patch.yml rides over dsh-base: it sets the coding persona, inserts the Web host rows (webserver, API gateway, workspace, projection cache, storage) and the browser plugin roster, and mounts this package's own web-runtime glue plugin (config {mode, printUrl, surfaceContext, lanAddresses}). That plugin owns what used to be launcher code: it resolves the built frontend dist through @deepseek-ai/dsh-frontend's exports (workspace knowledge of this bundle, never user config), mounts the frontend-static fallback owner over it, registers the web-surface prompt section and the bash-visible DSH_WEB_URL/DSH_WEB_MODE runtime variables when surfaceContext is true, and prints the dsh web: URL line when printUrl is true. The dsh web launcher alias patches mode/lanAddresses and the flag family over these rows; dsh-headless layers on top, silences the URL line, and disables the surface context.
Model Experience
Web-surface prompt section and bash runtime variables
What the model sees
When surfaceContext is true, the app:web-surface global section (order −98) orients the model to the GUI: the canonical local URL, the "this page" referent, the HMR/rebuild update contract for the active mode, and the instruction not to start replacement servers. DSH_WEB_URL and DSH_WEB_MODE additionally appear in the managed bash environment with their descriptions, resolved per invocation from the live server. When it is false, neither the section nor the variables are registered.
Token effect
One prompt paragraph per session plus two managed-environment variable lines; constant per process.
KV Cache effect
The prompt section sits near the system prompt's head and is stable for the life of the process (port and mode are boot facts), so it does not invalidate the cache across turns.
Known Limitations and Deferred Work
- The frontend dist must be built —
require.resolveof the dist fails loud at activation with a build hint; there is no source-serving fallback. lanAddressesis a boot-time snapshot — interface changes after boot are not re-advertised; the printed LAN URL always matches the configured trust fence.