Tianyi Cui
d5e894edf4
Keep DeepSeekHarness.run() reusable, but make ownership of its lazy runtime process explicit. Document the context-manager/close contract and update every construction example to use a context manager so repeated runs remain valid without encouraging leaked subprocesses. Contain notification predicate failures at the subscription boundary. Remove only the subscriber whose callback raised, deliver that exception through its queue, and continue dispatching to healthy subscribers so arbitrary callback code cannot terminate the shared reader thread or strand later requests. Enforce one in-flight prompt per server session with an atomic activePrompt guard. Route overlap through the existing -32603 handler-error response and clear the guard in finally, preserving parallel prompts across sessions and sequential reuse without changing JSON-RPC request or notification shapes. Use StringDecoder for line framing so a UTF-8 code point split across Buffer chunks is not corrupted. Add a queued-write flush barrier, and make memoized shutdown await it before disposal and exit while retaining exactly-once cleanup when shutdown calls race or flushing fails. Cover callback isolation, same-session exclusion, cross-session concurrency, split multibyte input, delayed writes, racing shutdown, and flush failure with deterministic tests.
ui/ — editor/client integration surfaces
Integrations that expose the agent to an external editor or client. These are product packages: a real surface a user drives the harness through.
| Package | Role | ctx key |
|---|---|---|
acp/ |
Agent Client Protocol bridge: serves the agent to an ACP editor (Zed) over JSON-RPC stdio | (drives ctx.agents/ctx.sessions) |
user-approval/ |
One-shot user-approval mechanism, closed outcome vocabulary, audit events, and per-session approval policy | ctx.approval |
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) |
stdio-agent/ |
Terminal stdio chat APP: the agent-core spine + console logger + readline UI + a pre-created main agent, with a bin |
(composition + bin) |
acp-agent/ |
ACP server APP: the agent-core spine + JSONL persistence + the acp bridge (no stdout logger), with a bin |
(composition + bin) |
jsonrpc/ |
Stdio JSON-RPC SDK server plugin: serves HarnessSdkServer to out-of-process SDK clients (the Python SDK) on the process stdio |
(drives ctx.agents) |
jsonrpc-agent/ |
JSON-RPC SDK server APP: a bin-only boot of an external cordis.yml whose jsonrpc entry is the serving face; the single-exe runtime entrypoint |
(bin only) |
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 and not a capability seam: it consumes the existing agent/* event taxonomy and the dsh-agent factory. The jsonrpc plugin is the SDK-client sibling of the acp bridge (a JSON-RPC server over ctx.agents for out-of-process SDK clients rather than editors). The readline UI is the unstructured analogue of the acp bridge and lives INSIDE the stdio app (the stdio-chat module of stdio-agent/): it is scaffolding for that one front door, not an independently swappable integration, so it carries no package boundary of its own.
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 their UI channel owners. user-interaction remains provider-neutral (ctx.userInteraction), while tool-ask-user is its model-facing consumer and the app/bridge packages provide concrete providers.
stdio-agent and acp-agent are the two composing app packages: each composes the core/agent-core spine with its coupled front-door cluster (and owns the boot bin), so a leaf cordis.yml is the swappable backends plus one app entry plus any optional product tools. jsonrpc-agent is the third app but bin-only — no composition plugin, because the SDK runtime's hard semantic is that the external cordis.yml composes everything, the serving jsonrpc entry included. They live in ui/ because each IS a user-facing front door; the stdout-purity coupling (logger vs. no logger) becomes a property of the artifact rather than a leaf convention.