Tianyi Cui
e68496fd79
The snapshot tier was built single-session: dsh-llm-replay served calls from one global positional cursor, and the harness harvested one session log. A subagent runs as a second agent with its own session, so a parent→child scenario could neither replay deterministically nor harvest the child's log. This resolves the TODO(subagent-snapshots) deferral from the subagent RFC. - Stamp the calling session id onto the model request: GenerateOptions.sessionId (typed Branded<'SessionId'> to avoid the dsh-llm↔dsh-session cycle), set by the agent loop from agent.session.id. Adapters ignore it; an llm/stream listener routes by it. - Key replay per session: dsh-llm-replay loads the parent log plus one per child (childFiles / $DSH_SNAPSHOT_CHILD_FILES), derives a script per recorded session, and binds each live (freshly-random) session to a recorded script by first-call order — parent first (earliest createdAt, first to stream). Keys by WHO calls, so it survives a future concurrent/backgrounded subagent; a global cursor would not. An unrecorded extra session fails loud. - Harvest every log: the harness collects all .jsonl across cwd buckets, ordered primary-first (top-level, then children by createdAt), and RunResult exposes the plural sessionLogs. The spec writes each back on record (session.jsonl + session.<n>.jsonl) and diffs each against its fixture on replay. - Wire the subagent seam + spawn + fork + tool into the acp-agent example (both cordis configs) and add two nested scenarios recorded against the real API: subagent-spawn (parent + 1 child) and subagent-multi (parent + 2 children, 3 sessions). Both replay keyless in the default gate. A new RFC documents the design (docs/rfc/implemented/testing/). Single-session replay is unchanged (a call with no sessionId is one anonymous primary session). TODO follow-up: a dedicated branded-ids package could own the SessionId brand and dissolve the cross-package cycle note; out of scope for this testing PR.
Examples
Runnable demos (not workspaces) that showcase how the harness is wired. Each example is now a thin leaf: a cordis.yml that picks the swappable backends (an LLM adapter, a bash executor) and loads ONE app package, plus any demo-only mocks. The composition — the spine, the front-door cluster, and the boot glue — lives in the app packages (@deepseek-ai/dsh-stdio-agent, @deepseek-ai/dsh-acp-agent) and the @deepseek-ai/dsh-agent-core bundle they share. There is no start.ts; the demo:* scripts invoke each app package's bin.
echo-agent
A mock model + echo tool on the stdio chat app — the all-mock skeleton. The leaf swaps dsh-stdio-agent's LLM backend to a local mock-echo adapter and adds a local echo tool. Demonstrates:
- A thin leaf
cordis.ymlloading the@deepseek-ai/dsh-stdio-agentapp - Registering a mock
LlmAdapter(streaming scripted responses) - Registering a tool via
ctx.tools.register() - "Swap the backend, keep the app" — the only difference from
coding-agentis the adapter
Run with: pnpm run demo:echo. When prompted, type "echo " to trigger a tool call round-trip.
coding-agent
The real thing: DeepSeek V4 + the bash tool suite on the same @deepseek-ai/dsh-stdio-agent app. Where echo-agent proves the skeleton with mocks, this is a usable coding assistant.
Run with: pnpm run demo:coding (needs DEEPSEEK_API_KEY in the environment or a gitignored repo-root .env). See coding-agent/README.md for details.
acp-agent
The same coding agent exposed as an Agent Client Protocol (ACP) server over JSON-RPC stdio, via the @deepseek-ai/dsh-acp-agent app — drive it from Zed or any other ACP client. Also the home of the keyless snapshot tests.
Run with: pnpm run demo:acp (needs DEEPSEEK_API_KEY). See acp-agent/README.md for the Zed setup and the snapshot-test design.