v0.4.0

Improvements

• The shared shell guidance is stated once. Each tool description keeps only its dialect facts (289 / 143 characters, down from 1299 / 2164); one tool:win-mb-bash section states what the family shares. Prompt payload per turn: 3933 → 2693 characters.
• The section follows the composition. Its text is resolved on every assembly from the tools actually mounted, so either tool alone, both, or neither each render exactly one correct copy — and with neither mounted it renders nothing at all. The escalation paragraph and the background sentence appear only while a mounted tool advertises sandbox_permissions / run_in_background. It now sorts between dsh's TOOL_BASH and TOOL_PWSH sections instead of ahead of the policy sections.
• Both tool rows are configurable in the Web Plugins page. Every knob is .volatile(), and a browser half (lib/client.js) registers a Configure page for each row: enableRunInBackground; cwd, timeoutMs, maxTimeoutMs, maxOutputBytes, maxSpillBytes, graceMs; bashPath (or wslPath / wslDistro); the sandbox stance; probeTimeoutMs; requireSandbox. The page is localized (en / zh), staged behind Save, and fenced by revision; writes go to the profile's Cordis patch, so there is no extra settings file, route or YAML editing. Changes apply to the next command, except enableRunInBackground and the escalation surface, which shape the tool schema and follow the row's next load.
• Three rows: the plugin's core row plus one per tool. The core row (win-mb-plugin, the package main) serves the browser half and owns the prompt section. dsh offers no way to mark a third-party row read-only, so switching that row off is arranged to be harmless — the tools keep working and carry the shared guidance in their own descriptions, and only the Configure pages disappear — and the page labels it as the core row (plugins.detail.badge / .section).
• The Plugins page's timeout hints state what they do not cover: timeoutMs / maxTimeoutMs apply to a foreground command only, never to a background job.

Compatibility

• The patch now inserts three rows, not two (0.3.0 / 0.3.1 shipped the two tool rows only). Hand-wired profiles: add the win-mb-plugin row, or re-run install.ps1 (its managed block is replaced by marker). A bundle-installed profile picks the new shape up on the next composition load. An un-migrated 0.3.1 profile keeps working: both tools load, and with no section owner each description carries the shared guidance itself.
• The tool rows no longer inject systemPrompt (they register no section of their own), so a composition without that service can still load them.
• Volatile fields resolve to live references: reading a resolved GitBashExecutor.Config(...) / WslBashExecutor.Config(...) field programmatically now needs .get(). Hand-written YAML is unchanged and still valid.
• New in the package: the ./client export with dsh.client (a Web Host serves the browser half under /plugins; a non-Web host is unaffected), install.ps1 / uninstall.ps1 in files, and .gitattributes pinning LF. The tarball is 22 files; smoke/ and this file are not shipped.

Verification

Verified on dsh 0.2.0-rc.2.

• smoke/audit.test.mjs: 224 checks, 0 failures (140 before this release), covering the prompt dedup and its five-state assembly matrix, the volatile config projection, the browser half's form contract, the row-switch fallback, and the repository records (bilingual hashes, LF, package files).
• npm test (smoke/run.ps1): git_bash, wsl_bash and the base bundle's own pwsh seat each ran a real command with shellSeatPresent: true, in both the schema-default and pinned-bashPath variants.
• The smoke composition cannot activate dsh-settings (no configEditor / profileContext), so that projection is pinned against the documented rule instead of booted; the page itself is verified in the running Web app.