Changelog

Release notes for dsh-acp-interactive. 中文版见 CHANGELOG.zh.md.

1.3.2

Version 1.3.2 moves the default JSONL sessions root from ./.sessions, which resolved against the server process's working directory at startup, to acp-sessions in the dsh home ($DSH_HOME, or the current user's default .dsh directory). Logs were already partitioned by each session's own cwd beneath the root, so the process directory only decided which sessions a process could see: a client that served several workspaces from one server process, or restarted the server from another workspace, could no longer list or load the sessions it had written, and every launch directory gained a .sessions folder. DSH_ACP_SESSIONS_ROOT still overrides the root, and a blank value now counts as unset.

Existing sessions are not moved. To keep using a previous location, set DSH_ACP_SESSIONS_ROOT to it; to carry old history over, move the project directories under an old .sessions into the new root, since the layout beneath the root is unchanged. See the Home Sessions Root Agent Note.

1.3.1

Version 1.3.1 moves the composed DeepSeek Harness baseline from 0.1.5-rc.1 to 0.1.5-rc.3. The advertised ACP surface and runtime behaviors remain unchanged: the ACP SDK pin stays at 1.4.0, and all twelve official ACP specs remain byte-for-byte identical to 0.1.5-rc.1.

Upstream changes between 0.1.5-rc.1 and 0.1.5-rc.3 were confined to web deliverables, feedback dialog refinements, and monorepo vendor dependency pinning (workspace:^ to workspace:* for packages like schemastery and cordis). The agent loop, session persistence format (v3), tools, subagents, and prompt engines have zero breaking changes or behavioral shifts. See the Upstream 0.1.5-rc.3 Baseline Agent Note.

1.3.0

Version 1.3.0 adds in-process subagents. The composed profile now mounts the published @deepseek-ai/dsh-subagent registry with its spawn and fork backends and two delegation tools, subagent and subagent_fork: the model delegates a self-contained or conversation-seeded task and receives the child's final answer as the tool result, exactly as upstream defines it. In Zed a delegation is one tool card. The card takes the delegation's description as its title once the child is published, the child's own tool calls, replies, nested delegations, and settlement are folded into a bounded transcript inside the card while it runs, and the parent's own tool result settles the card with that transcript kept ahead of the result. The card's _meta.dsh_subagent names the child session, so its log can be found under the sessions root.

Every delegation waits in the foreground inside the parent's turn, so session/cancel, session/close, and connection teardown stop the children before the parent reports idle; a cancelled delegation settles as a failed card whose transcript ends with Subagent aborted, and no child event can reach a card after its call has settled. Children inherit the parent's sandbox mode with approval pinned to never and lose ask_user_question, so a child never raises an ACP permission request or question; escalation stays with the parent. Child sessions are not editor sessions: session/list omits them and session/load and session/resume refuse them. Background jobs, continuable children, and the out-of-process backends stay deferred. See the In-Process Subagents Agent Note.

1.2.0

Version 1.2.0 moves the composed DeepSeek Harness baseline from 0.1.2-rc.1 to 0.1.5-rc.1. The advertised ACP surface is unchanged: the ACP SDK pin stays at 1.4.0, and initialize answers exactly as before.

Upstream's session format is now v3. It embeds each model attempt's provider stream in one durable settlement and no longer writes per-token events, so live text and reasoning now reach the editor from the harness's process-local agent/assistant-stream frames while the assembled message stays the replay source; message ids are unchanged between live output and session/load. A log-only failed or retried attempt is never shown as a message. Sessions written by 1.1.0 and earlier are migrated on first read into a sibling session.v3.jsonl.zstd file — the original stays intact, so session/list and session/load keep working and a rollback still reads the old file. The profile's system-prompt persona follows an upstream rename (persona → personaPrefix) that would otherwise have been dropped silently, and check:profile, whose official reference file had moved before 0.1.2-rc.1, runs again and records the resulting drift. See the Upstream 0.1.5-rc.1 Baseline Agent Note.

1.1.0

Version 1.1.0 moves the composed DeepSeek Harness baseline from 0.1.1-rc.2 to 0.1.2-rc.1. The advertised ACP surface is unchanged.

Upstream deleted the @deepseek-ai/dsh-agent-spine-demo example package, which this deployment used to mount as one profile row, and replaced it with a launcher-resolved bundle patch layer. This release keeps config/cordis.yml a single flat, fully auditable composition instead: the spine's former children are now 25 explicit plugin rows with the same set and configuration, so the shipped composition stays comparable against its review manifest. Adapting to that release also required following three upstream contract changes — Session.snapshotEvents() replacing the removed events accessor, permission presets reading their state through the session projection registry, and user questions moving from provider registration to a scope-filtered answerer waterfall.

The official compatibility gate is repaired and scoped. It previously copied a test path that no upstream release publishes, so it had been reporting fixture unavailable rather than running, and it read whichever revision a local checkout happened to have. It now extracts the official specs from the pinned git ref recorded in config/upstream-baseline.json. Because 0.1.2-rc.1 converged toward this server's design while remaining automation-only — it still implements no session/load, slash commands, skills, presentation cards, or elicitation — only the specs classified as aligned run verbatim, and every other official spec is recorded as an explicit divergence with a reason. The gate fails whenever the pinned ref adds, removes, or renames a spec, so the next upstream release is reviewed rather than silently skipped. See Zed Compatibility Matrix and the Upstream 0.1.2-rc.1 Baseline Agent Note.

1.0.9

Version 1.0.9 answers a session/prompt on the official DeepSeek route with auth_required while DEEPSEEK_API_KEY is not configured, regardless of other providers in the model directory. 1.0.7 deliberately stopped gating session/new for multi-provider deployments so those users could open a session and switch routes, but a prompt on the DeepSeek route then failed as an internal model-call error; clients such as Zed show the authentication action for auth_required from session/prompt too. Direct slash commands never reach the model and are not gated.

1.0.8

Version 1.0.8 makes the Configure DeepSeek API key action actually launch --setup in Zed. Zed's stable releases run terminal authentication only through the legacy _meta["terminal-auth"] object on the method (its handling of the stable type: "terminal" method sits behind a beta flag), and that object must name an executable itself; the method now carries it, pointing at the Node executable running the server and this package's own bin.js --setup, which holds for a global install, a Registry npx install, and a checkout alike, with DSH_HOME forwarded when the server was started with one. session/new also keeps re-reading an unconfigured key for one second before answering auth_required, so the retry Zed issues the instant the setup terminal exits sees the key the credential provider's watcher loads about 100 ms after the write. The launcher now also exits on its own when the client closes its stdin; previously the composition's file watchers kept the process alive until a signal arrived.

1.0.7

Version 1.0.7 narrows the auth_required gate to deployments whose model directory offers only the official DeepSeek provider. A user whose settings.yaml adds llm-pi-ai routes is no longer blocked from opening a session and switching to those routes when no DeepSeek key is stored; a missing DeepSeek key then fails only when the DeepSeek route is actually used. Fresh installations still see the Configure DeepSeek API key action before the first prompt.

1.0.6

Version 1.0.6 makes session/new return the ACP auth_required error while the composition's default route is the official DeepSeek provider and DEEPSEEK_API_KEY is not configured. Clients render authMethods only on that error, so 1.0.5's always-advertised method was still invisible in Zed until the first prompt failed; now the Configure DeepSeek API key action appears when a new thread is opened without a key, and the key stored by --setup is picked up by the next session/new. The check uses the credential store's describe() (configured state only, never the value) and applies only to the DeepSeek default route. See the Auth Method Fallback and Registry Id Agent Note.

1.0.5

Version 1.0.5 always advertises the deepseek-api-key authentication method: as a terminal method when the client declares terminal authentication, and otherwise as an agent-type method whose description points at --setup and DEEPSEEK_API_KEY, so clients that do not declare the capability (for example JetBrains IDEs, whose initialize carries no terminal-auth flag) still see how to configure the key instead of an empty list. agentInfo now reports the package version from package.json instead of a hardcoded string, and agentInfo.name matches the ACP Registry id dsh-acp-interactive, which the Registry entry now uses together with a description that states the community-maintained, unofficial status. See the Auth Method Fallback and Registry Id Agent Note.

1.0.4

Version 1.0.4 makes this English README the default document on GitHub and npm (the Chinese counterpart is README.zh.md), adds public cross-platform CI, a tag-driven release workflow with npm trusted publishing, and keeps the ACP Registry entry (registry/agent.json and icon.svg) in this repository, where the Registry's own validator scripts re-check it daily. See Verification and ACP Registry. The test suite and the packed-install verifier now pass on Linux and macOS as well as Windows; the fixes were confined to test fixtures and the verifier script. Runtime behavior is unchanged from 1.0.3, which recognizes both the stable ACP v1 terminal-auth capability and the ACP Registry validator's legacy _meta["terminal-auth"] compatibility flag; supporting clients configure an official DeepSeek API key through an isolated --setup process, and the ordinary ACP transport never handles or prints the secret.