c6ba5f1d26
Conflict resolution beyond line merges: the ACP bridge's mode/set re-notify moved inside master's new containment finally (a throwing presenter must not desync the picker), and session/new keeps the modes advertisement beside master's plain object return. dsh-mode's boundary flush moved off the session/event feed onto the loop's interception seams (agent/prompt-submit / agent/turn-continuation): master's scoped dispatch made post-commit session observers observe-only — an append from one re-enters the publishing append — while the two waterfalls fire outside any log emit and bracket the same boundaries; mode.spec's boundary helper now dispatches those seams via agentEvents, and the containment tests stub only the mode/set append. Catalogs, doc graphs, and the module graph regenerated.
@deepseek-ai/dsh-tool-cordis
The self-referential cordis toolset: three model-facing tools over the live runtime the agent runs inside. Design home — sandbox semantics, mount lifecycle, cross-mount composition, the generated API catalog, standing decisions: the toolset RFC.
What it does
cordis_inspect— read-only report over the runtime: services, the loaded-plugin list, registered tools, the dynamic-mount table, and the catalog-backedapi/eventsreferences.cordis_mount— evaluates model-written JavaScript (the body of an async function) in anode:vmsandbox; the code mustreturna cordis plugin, which is mounted under thecordis-dynamicgroup fiber and tracked asdyn-<n>.cordis_unmount— disposes one mount by id, returning only after quiescence.
Exact model-facing schemas: the generated tool catalog.
Trust stance
The sandbox isolates the global context only — it is not a security boundary. No Node API is provided: require, the timers, and fetch are callable traps that throw a redirect to the cordis alternative (ctx.fs / ctx.web / ctx.bash / inject: ['timer'] + ctx.setTimeout); process and Buffer are undefined; globalThis writes stay inside. These traps steer honest code onto the cordis services; they do not contain a mount that goes looking — the host-realm helpers on the sandbox global (harness, console, btoa) are reachable functions, so mount code can reach the host realm and Node through one of them, which is fine because ctx is fully privileged anyway. The ctx a mounted plugin's apply receives is a whitelist façade — register tools, observe events, provide/consume services, use timers; framework internals (ctx.root, ctx.fiber, ctx.extend, ctx.plugin, …) are withheld — but the capabilities it does expose reach the real runtime, so load this plugin as deliberately as you would grant a bash tool.
Config
| Field | Default | Meaning |
|---|---|---|
vmTimeoutMs |
5000 |
Bound on the SYNCHRONOUS portion of mount-code evaluation; an async body escapes it |
The generated API catalog
src/api-catalog.ts is generated by scripts/gen-cordis-api.ts from the same AST walk as docs/cordis-catalog and freshness-gated by pnpm run verify-cordis-api (in doc-sync) — never edit it by hand. cordis_inspect intersects it with the live service store at call time.
Rendering
All three tools render generic cards (read / execute / delete); cordis_mount carries the mount code as rawInput. Presenters are pure functions of the args; results keep the default text rendering.
Export shape
Namespace plugin: named exports name / inject / Config / apply, no default export (docs/postmortem/0001).