Tianyi Cui
b5e8e4e9c1
Model responses, replayed session data, tool presenter output, question metadata, configuration, and diagnostics all cross into ANSI-aware pi-tui renderers. Passing their C0 or C1 controls through unchanged lets an otherwise ordinary transcript emit OSC, CSI, cursor, or title operations in the user terminal. Introduce one displayText boundary that preserves line-feed layout but renders every other C0/C1 control as visible \\xNN text before application styling is applied. Route transcript blocks, streaming output, tool cards, diffs, plans, dialogs, headers, cwd/title data, notices, errors, and pre-mount startup failures through that boundary while leaving pi-tui and the theme responsible for legitimate terminal control sequences. Pin the contract at three levels: a settled headless-terminal golden spans the main untrusted display sources, unit coverage checks the pre-fullscreen failure path, and the real Loader/PTY conversation streams hostile OSC, cursor, and C1 probes and proves only their inert textual forms reach the terminal stream.
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 |
permission/ |
User-facing permission presets (workspace-write/danger-full-access): one product-level select bundling the sandbox-mode and approval-policy knobs, written through to their session events |
ctx.permission |
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/ |
Line-oriented terminal channel for pipes and automation; drives ctx.agents, renders session/event, and answers ctx.userInteraction |
(drives ctx.agents) |
tui/ |
Interactive pi-tui terminal channel for TTY sessions; renders session/event, tool presentation intents, and answers ctx.userInteraction |
(drives ctx.agents) |
jsonrpc/ |
Stdio JSON-RPC server for out-of-process SDK clients | (drives ctx.agents) |
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 stdio and tui plugins are the two terminal front doors: one is line-oriented for pipes, the other is interactive for TTYs. App bundles and SDK projects compose the appropriate channel explicitly with the services and tools their product profile selects.
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.
The runnable app bundles that bake these bridges into boot bins — the terminal chat app, the ACP server app, and the JSON-RPC SDK-runtime bin — live in examples/ (stdio-demo, acp-demo, jsonrpc-demo), each composed over the agent-spine-demo bundle. ui/ keeps the reusable bridge/channel plugins and the app-boot glue; each front door owns its stdout policy, and a leaf cordis.yml supplies backends and optional tools.