Files
deepseek-harness/packages/bundle/acp-app/README.md
T
Tianyi Cui fd814589fb refactor(profiles): make module HMR opt-in
Move the shared module-reload policy into dsh-base by inserting its HMR row disabled, then remove the redundant disabled overrides from Web, headless, SDK, and ACP. No shipped profile enables server module reload; live profile patch watching continues through the launcher-owned config-only fallback, and browser client HMR remains a separate mechanism.

A later profile layer can opt into source-module reload explicitly with disabled: false while retaining the base root configuration. Composition tests cover every shipped mode and the explicit enable path, and the bundle references plus launcher Agent Notes document the resulting ownership and safety rationale.
2026-08-23 10:59:01 +08:00

3.4 KiB

@deepseek-ai/dsh-acp-app

English | 中文

The automation-only ACP stdio application as a dsh profile bundle over dsh-base. It inherits the base's disabled module-HMR policy; its patch sets the coding-agent persona and default model route, 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-acp row; 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 acp profile uses patchReload: startup so one stdio connection never observes a replacement bridge or Agent dependency.