Tianyi Cui
d8dbb8235c
Replace the standalone @deepseek-ai/dsh-acp-demo application with dsh --profile acp plus ordered example patches. The shipped acp-app bundle owns only the protocol bridge; every example overlay now targets shared dsh-base rows instead of copying a complete application tree. Move launcher responsibilities into the ACP snapshot harness: it materializes profile patches, links required packages, reserves stdout for JSON-RPC, observes spawn and drain failures, and escalates process teardown deterministically. The relocated control-surface fixture and the ACP/subagent integration tests now exercise the real CLI/profile path. This commit contains authored runtime, configuration, and test changes only. Generated transcript and projection churn is deliberately left for the next commit so reviewers can inspect the migration logic without hundreds of expected-output edits.
@deepseek-ai/dsh-acp-app
English | 中文
The automation-only ACP stdio application as a dsh profile bundle over dsh-base. Its patch sets the coding-agent persona and default model route, disables module HMR, mounts an app-owned zero-option command provider, and starts dsh-acp only after that provider accepts the invocation. dsh --profile acp --help therefore writes help and exits without claiming stdin or stdout.
The startup provider binds stdin EOF to the launcher's bounded successful shutdown. ACP connection close, SIGINT, and SIGTERM drain the bridge-owned agents and the root profile tree before exit. Stdout is reserved for newline-delimited ACP JSON-RPC frames. The bundle disables model-generated session titles because ACP exposes no title surface; deterministic fallback titles remain durable without an auxiliary model request. A deployment selects a different complete composition through profile bundles and patch files, not another app bin.
The shipped row creates sessions with deepseek-official and deepseek-v4-flash; a later patch can replace that row's complete config. The base profile owns adapters, tools, persistence, policy, settings, credentials, and the per-session workspace supplied by the ACP client.
Standard automation workflow
An ACP v1 SDK client initializes dsh --profile acp, creates a session with an absolute cwd and optional standard stdio/HTTP MCP declarations, chooses an advertised model or reasoning_effort, prompts while observing standard semantic updates, then calls session/close. Another process can use session/list and session/resume against the same profile persistence root; resume reconnects the MCP declarations supplied by that request and does not replay history.
The complete supported method matrix, MCP trust model, update mapping, and stop reasons live in the dsh-acp protocol contract. This profile adds no private method, capability, _meta, environment variable, or transport field. The keyless control-surface conformance test drives the real profile through the public ACP SDK.
Model Experience
ACP coding-agent persona
What the model sees
The profile supplies You are a coding agent powered by the {{model}} model. Your working directory is {{cwd}}. before the base tool and context contributions. The ACP row's route and each session/new cwd resolve the placeholders.
Token effect
One short stable persona plus the data-dependent base prompt sections and selected tool schemas.
KV Cache effect
Stable for a fixed profile, provider, model, and tool roster. Profile changes take effect on the next process because the shipped ACP profile uses startup-only patches.
Known Limitations and Deferred Work
- A profile can omit the ACP bridge — a custom ACP launch profile must retain this bundle or another
dsh-acprow; otherwise no peer answers the client. - User plugins can violate stdout purity — profile and per-launch patches are trusted application composition. The shipped bundle writes no non-protocol stdout, but it cannot contain an arbitrary inserted plugin.
- Configuration changes require restart — the shipped
acpprofile usespatchReload: startupso one stdio connection never observes a replacement bridge or Agent dependency.