Yichen Jiang
8ddc53f7a0
$DSH_HOME/config.yaml was an implicit composition layer: if the file existed, every launch applied an arbitrary Loader patch graph over the shipped tree, kept live by a dedicated HMR watcher. Three costs came from the implicitness, not the capability. A patch replaces its target row's whole config, so a file written months ago pins that row to the field set it knew and every default the shipped tree later adds silently stops applying. It competed with the typed settings namespaces llm-deepseek and llm-pi-ai already register, so which one wins was a function of layer order rather than meaning. And the explicit escape hatch it was supposedly redundant with did not exist on every surface: dsh -p, dsh meta, and dsh upgrade all rejected --config, so for them the implicit file was the only composition route at all. Complete the explicit layer first: --config and --config-replace now work on every booting surface. A headless --config-replace tree must still mount a webserver row, because that surface reaches its own agent over the same HTTP gateway the browser uses; AppCLIEntry names that contract in the failure instead of reporting a bare missing service. Then delete the implicit one. PERSONAL_CONFIG_FILENAME, loadPersonalPatches, watchPersonalPatches, and the config-only HMR row mounted for it are gone; a file left at that path is inert, and --dump-config no longer reads the Harness home. --config therefore stops *replacing* the personal overlay and simply *is* the user overlay. No migration: a user who wants the old behavior names the same file (dsh --config ~/.dsh/config.yaml), which a shell alias makes permanent.
ui/ — human and SDK-client integration surfaces
English | 中文
Human-facing channels and the out-of-process SDK server. These are product packages: real interfaces that a person or SDK client drives.
| Package | Role | ctx key |
|---|---|---|
commands/ |
Human-command registry: shared discovery metadata, scoped shadowing, cancellation, and direct UI dispatch | ctx.commands |
user-approval/ |
One-shot user-approval mechanism, closed outcome vocabulary, audit events, and per-session approval policy | ctx.approval |
permission/ |
User-facing permission presets (workspace-write/danger-full-access): one product-level select bundling the sandbox-mode and approval-policy knobs, written through to their session events |
ctx.permission |
user-interaction/ |
Abstract human question/answer seam used by UI-backed confirmation tools | ctx.userInteraction |
tool-ask-user/ |
Model-facing ask_user_question tool over ctx.userInteraction |
(registers on ctx.tools) |
tui/ |
Interactive pi-tui terminal channel; renders session titles/events and tool intents, answers ctx.userInteraction, and hosts effect-owned plugin overlays |
ctx.tui (drives ctx.agents) |
jsonrpc/ |
Stdio JSON-RPC server for out-of-process SDK clients | (drives ctx.agents) |
app-boot/ |
Shared boot glue for the app bins: .env loading, fail-loud Loader guards, snapshot-aware config resolution, the settle-the-tree boot sequence |
(library for the bins) |
A UI integration is a client-driver plugin, not a loop change: it consumes the existing agent/* event taxonomy and the dsh-agent factory. tui is the interactive terminal front door and supplies the terminal-local ctx.tui extension service; jsonrpc serves out-of-process SDK clients, while non-interactive one-shot tasks use cli-demo. commands is the human-only discovery and dispatch plane consumed by TUI; command input and output do not become model messages.
user-approval, user-interaction, and tool-ask-user live here because asking a human is a UI-backed product affordance, not part of the providerless core spine. user-approval owns the one-shot ctx.approval decision mechanism and its policy tier; answerers remain with the channel or automation transport that owns the agent. user-interaction remains provider-neutral (ctx.userInteraction), while tool-ask-user is its model-facing consumer and interactive app packages provide concrete providers.
The runnable app bundles composed over agent-spine-demo live in examples/ (tui-demo, acp-demo, jsonrpc-demo). acp-demo and jsonrpc-demo own boot bins; the tui-demo bundle is booted by the product dsh CLI. ui/ keeps the reusable human/SDK channel plugins and shared app-boot glue; the automation-only ACP transport lives in acp/. Each front door owns its stdout policy, and a leaf cordis.yml supplies backends and optional tools.