Files
deepseek-harness/examples/cordis-agent
imccyu e51e58e993 chore: register the cordis group across repo gates and docs
Everything outside the package and example that a new top-level group and a
new demo touch: GROUP_ORDER in gen-module-graph and gen-doc-graphs (plus the
tools-service consumers list, the APP_EXAMPLES entry, and the graph-atlas
label/mode rows), the knip e2e entries, the packages/README group row, the
AGENTS.md layout and demo lines, and the regenerated module-graph /
config-catalog / graph-atlas / capability-seams / composition artifacts.
AGENTS.md and examples/AGENTS.md word-budget ceilings rise to current+5%
(1802 / 653): the new group and demo rows are genuine additions to both docs,
not condensable restatements.
2026-07-09 13:57:03 +08:00
..

cordis-agent

The self-referential harness demo: the coding-agent spine (DeepSeek V4 + local bash on the stdio chat app) plus @deepseek-ai/dsh-tool-cordis, which hands the model three tools over the live cordis runtime it is running inside — inspect it, mount new plugins into it, and dispose them again. The design (sandbox semantics, mount lifecycle, cross-mount composition, caveats) lives in the toolset RFC.

Run it

# repo root .env (gitignored) or exported env:
#   DEEPSEEK_API_KEY=sk-…
#   DEEPSEEK_BASE_URL=https://…   # optional; defaults to the public API
pnpm run demo:cordis

The intended demo is staged — verify the listener link first, then let the agent extend itself:

> Mount a plugin that listens to the 'agent/status' event and logs every status change, then run `echo hi` with bash.
  [tool call] cordis_mount({"code": "return { name: 'status-logger', apply(ctx) { ctx.on('agent/status', (agent, status) => console.log('status →', status)) } }"})
  [tool result] mounted dyn-1 (plugin "status-logger", state: active)
  [tool call] bash({"command": "echo hi"})
[cordis:dyn-1] status → …            ← the mounted listener firing, live
> Now give yourself a reverse_text tool and use it on "harness".
  [tool call] cordis_mount({"code": "return { name: 'reverse-text', inject: ['tools'], apply(ctx) { ctx.tools.register(harness.defineTool({ name: 'reverse_text', … })) } }"})
  [tool call] reverse_text({"text": "harness"})   ← a tool the agent built for itself, one step earlier
> Unmount both.
  [tool call] cordis_unmount({"id": "dyn-1"})

Ask for cordis_inspect with what: "api" or what: "events" to see the generated service/event reference the agent writes plugin code against, and try two cooperating mounts (ctx.provide in one, inject in the other) to watch cordis park and revive the consumer.

End-to-end tests

tests/keyless-smoke.e2e.ts boots the real cordis.yml through the Loader with a dummy key and asserts the banner + clean EOF exit (the export-shape / real-load-path guard, now across the package-name resolution). tests/cordis-tools.e2e.ts is the with-key smoke: a real model mounts a status listener (asserting the tagged console line actually fires — the world, not the agent's claim), builds itself a reverse_text tool and uses it, and composes two mounts via provide/inject. The tool logic itself is unit-tested in packages/cordis/tool-cordis under the per-file 100% coverage gate.