dsh-plugin-dev-kb 1.0.0

package/kb/site/en/develop/cordis-tutorial/04-events.md

@@ -0,0 +1,144 @@
+---
+editSource: "docs/cordis-tutorial/04-events.md"
+---
+
+# 4. Events
+
+Services support direct calls; **events** let a plugin announce something without knowing which plugins listen. The harness uses events for interactions such as tool results, model requests, and approval decisions.
+
+## Declare, emit, listen
+
+Create `stats.ts` in `tmp/cordis-tutorial` — a service that counts things and announces each change:
+
+```ts
+import { Service, type Context } from '@deepseek-ai/cordis'
+
+declare module '@deepseek-ai/cordis' {
+  interface Context {
+    stats: StatsService
+  }
+  interface Events {
+    'stats/report'(name: string, count: number): void
+  }
+}
+
+export class StatsService extends Service {
+  private counts = new Map<string, number>()
+
+  constructor(ctx: Context) {
+    super(ctx, 'stats')
+  }
+
+  bump(name: string) {
+    const next = (this.counts.get(name) ?? 0) + 1
+    this.counts.set(name, next)
+    this.ctx.emit('stats/report', name, next)
+  }
+}
+
+export const name = 'stats'
+
+export function apply(ctx: Context) {
+  ctx.plugin(StatsService)
+}
+```
+
+The `interface Events` merge is the event-system twin of the `interface Context` merge from chapter 3: it declares the event name and its listener signature, so `ctx.emit` and `ctx.on` are fully typed. The `namespace/action` naming convention keeps the flat event namespace readable.
+
+Create `reporter.ts`:
+
+```ts ignore-check
+import type { Context } from '@deepseek-ai/cordis'
+import type {} from './stats.ts'
+
+export const name = 'reporter'
+export const inject = ['stats']
+
+export function apply(ctx: Context) {
+  ctx.on('stats/report', (name, count) => {
+    console.log(`[stats] ${name} -> ${count}`)
+  })
+  ctx.stats.bump('tool_call')
+  ctx.stats.bump('tool_call')
+  ctx.stats.bump('prompt')
+}
+```
+
+The `import type {} from './stats.ts'` line imports nothing at runtime; it exists so TypeScript sees the declaration merges. Compose and run:
+
+```yaml
+- name: './stats.ts'
+- name: './reporter.ts'
+```
+
+```
+[stats] tool_call -> 1
+[stats] tool_call -> 2
+[stats] prompt -> 1
+```
+
+Because `ctx.on()` is an effect, the listener disappears with the plugin — no manual `removeListener` bookkeeping, ever.
+
+## Dispatch modes
+
+`emit` is one of five dispatch modes. Which one an event uses is part of its contract — it decides whether listeners can return values, run concurrently, or short-circuit each other:
+
+| Mode | Call | Semantics |
+|---|---|---|
+| emit | `ctx.emit(name, ...args)` | Synchronous broadcast; returned promises and values are not awaited or collected. |
+| parallel | `await ctx.parallel(name, ...args)` | All listeners run concurrently; awaited together. |
+| serial | `await ctx.serial(name, ...args)` | Listeners run in order, awaited; the first non-`null`/`false`/`undefined` return wins and stops the rest. |
+| bail | `ctx.bail(name, ...args)` | Synchronous version of serial. |
+| waterfall | `ctx.waterfall(name, ...args, next)` | Around-middleware; see below. |
+
+Every harness event documents its mode in the generated reference on its owning [subsystem page](../../reference/subsystems/core.md).
+
+## Waterfall: transform or short-circuit
+
+Waterfall is the mode that powers interception. Each listener receives the arguments plus a `next()` continuation; it can transform what `next()` returns, or return without calling `next()` and short-circuit the rest of the chain — what the Cordis docs call the veto. Create `waterfall-demo.ts`:
+
+```ts
+import type { Context } from '@deepseek-ai/cordis'
+
+declare module '@deepseek-ai/cordis' {
+  interface Events {
+    'demo/transform'(input: string, next: () => Promise<string>): Promise<string>
+  }
+}
+
+export const name = 'waterfall-demo'
+
+export function apply(ctx: Context) {
+  // Listener 1: wrap the downstream result.
+  ctx.on('demo/transform', async (input, next) => {
+    const downstream = await next()
+    return downstream.toUpperCase()
+  })
+
+  // Listener 2: short-circuit when it owns the decision.
+  ctx.on('demo/transform', async (input, next) => {
+    if (input.includes('blocked')) return '** blocked **'
+    return next()
+  })
+
+  void (async () => {
+    console.log(await ctx.waterfall('demo/transform', 'hello', async () => 'hello'))
+    console.log(await ctx.waterfall('demo/transform', 'blocked words', async () => 'blocked words'))
+  })()
+}
+```
+
+Point `cordis.yml` at just this file and run:
+
+```
+HELLO
+** BLOCKED **
+```
+
+Walk through the second line: listener 1 runs first, calls `next()`, which invokes listener 2; listener 2 sees `blocked` and returns without calling `next()` — the innermost default (the function passed to `ctx.waterfall`) never runs — and listener 1 uppercases the replacement message on the way out.
+
+The discipline that follows: **a waterfall listener that only observes or annotates must call `next()`**; returning without it is a deliberate short-circuit. Forgetting `next()` in a logging listener silently swallows the default behavior for everyone downstream. It is a standing rule of this repository ([waterfall semantics](../../reference/cordis-primer.md#cordis-waterfall-semantics)).
+
+The harness uses waterfalls for decisions that cooperating plugins may wrap or answer: [`agent/request`](../../reference/subsystems/core.md#agentrequest--waterfall) lets a plugin replace the model-call config, and [`approval/request`](../../reference/subsystems/approval.md#approvalrequest--waterfall) lets a policy answer instead of the user.
+
+Next: [Configuration](./05-config.md) — plugin options from `cordis.yml`.

package/kb/site/en/develop/cordis-tutorial/05-config.md

@@ -0,0 +1,84 @@
+---
+editSource: "docs/cordis-tutorial/05-config.md"
+---
+
+# 5. Configuration
+
+Each `cordis.yml` entry can carry a `config` block, and the plugin declares a schema that validates it before `apply` runs. Bad config fails the load with a precise error — the plugin never starts half-configured.
+
+## A configurable plugin
+
+Create `config-demo.ts` in `tmp/cordis-tutorial`:
+
+```ts
+import type { Context } from '@deepseek-ai/cordis'
+import Schema from '@deepseek-ai/schemastery'
+
+export const name = 'config-demo'
+
+export interface Config {
+  greeting: string
+  targets: string[]
+}
+
+export const Config: Schema<Config> = Schema.object({
+  greeting: Schema.string().default('Hello'),
+  targets: Schema.array(String).default(['world']),
+})
+
+export function apply(ctx: Context, config: Config) {
+  for (const target of config.targets) {
+    console.log(`${config.greeting}, ${target}!`)
+  }
+}
+```
+
+The exported `Config` is both a TypeScript interface and a runtime schema with the same name — consumers get the type, Cordis gets the validator. This repo uses [Schemastery](https://github.com/shigma/schemastery) for schemas; Cordis itself accepts any [Standard Schema](https://standardschema.dev/) validator, so a plain object exported as `Config` will not work.
+
+Configure it:
+
+```yaml
+- name: './config-demo.ts'
+  config:
+    targets: ['alpha', 'beta']
+```
+
+Run:
+
+```
+Hello, alpha!
+Hello, beta!
+```
+
+`greeting` was omitted, so the schema default filled it in — `apply` always receives complete, validated config.
+
+## Fail loud
+
+Now feed it something invalid:
+
+```yaml
+- name: './config-demo.ts'
+  config:
+    targets: 'not-an-array'
+```
+
+```
+ValidationError: invalid config:
+  - $.targets expected array but got not-an-array (at targets)
+```
+
+The plugin's fiber goes to FAILED, and this tutorial's launcher exits with status 1 after printing the error. A plugin should also reject schema-valid config that names an unavailable resource or provider as soon as it can resolve that reference.
+
+## Computed config values
+
+The loader used in this repo supports a `!!js` tag for config values that must be computed at load time:
+
+```yaml
+- name: './config-demo.ts'
+  config:
+    greeting: !!js process.env.DEMO_GREETING ?? 'Hello'
+```
+
+`!!js` works only inside `config` and in an entry's `disabled` field. `disabled: !!js ...` evaluates against the loader context at every mount decision (this repo's extension), so a row can gate itself on platform or environment; the other metadata (`name`, `id`, `inject`, ...) stays static, where an expression is ordinary truthy data. See [loader configuration](../../reference/cordis-primer.md#loader-configuration).
+
+Next: [Composition and HMR](./06-composition-and-hmr.md) — treating `cordis.yml` as the application.

package/kb/site/en/develop/cordis-tutorial/06-composition-and-hmr.md

@@ -0,0 +1,113 @@
+---
+editSource: "docs/cordis-tutorial/06-composition-and-hmr.md"
+---
+
+# 6. Composition and HMR
+
+Every capability built so far is a plugin, and `cordis.yml` selects the application's plugin tree. This chapter changes that composition, hot-reloads a plugin, and diagnoses a plugin that never loads.
+
+## Entries are more than a name
+
+A config entry accepts metadata beyond `name` and `config`:
+
+```yaml
+- id: greeter          # stable identity for this entry
+  name: './greeter.ts'
+- id: consumer
+  name: './consumer.ts'
+  disabled: true       # keep the entry, skip mounting it
+```
+
+`id` gives the entry a stable identity so the loader can tell an edit to an existing entry apart from a removal plus an addition. `disabled: true` unmounts a plugin without deleting its entry — flip it back and the plugin (and everything PENDING on its services) loads again.
+
+Groups nest a sub-list of entries that load and unload as one unit, and `isolate` gives a group its own instance of a service name — two groups can each see a differently configured `shell` provider without affecting each other. The [Cordis primer](../../reference/cordis-primer.md) and the [service isolation example](../framework/service.md#service-isolation) cover the details.
+
+## Hot module replacement
+
+Because unloading releases effects ([chapter 2](./02-lifecycle-and-effects.md)) and loading follows dependencies ([chapter 3](./03-services.md)), HMR can replace a running plugin by unloading and loading it. The `@deepseek-ai/cordis-plugin-hmr` plugin watches your files and does exactly that on save.
+
+In `tmp/cordis-tutorial`, write `cordis.yml`:
+
+```yaml
+- id: logger
+  name: '@deepseek-ai/cordis-plugin-logger-console'
+- id: timer
+  name: '@deepseek-ai/cordis-plugin-timer'
+- id: hmr
+  name: '@deepseek-ai/cordis-plugin-hmr'
+  config:
+    root: ['.']
+- id: hello
+  name: './hello.ts'
+```
+
+Two support plugins joined the list: HMR logs through the Cordis logger service, so without a console exporter you would not see its messages, and it `inject`s the `timer` service for debouncing — without `@deepseek-ai/cordis-plugin-timer` it sits in PENDING forever, silently. That silence is the subject of the next section.
+
+HMR reads Node's loader internals through the Loader's native helper. Run Cordis under tsx:
+
+```sh
+node --import tsx ../../vendor/cordis/bin.js
+```
+
+Now edit `hello.ts` — change the log message — and save:
+
+```
+hello from my first plugin
+2026-07-22 15:44:36 [I] hmr watching [ '.' ]
+2026-07-22 15:44:39 [I] hmr reload plugin at hello.ts
+hello from my EDITED plugin
+```
+
+The old instance unloaded (all its effects unwound), the new code loaded, `apply` ran again. Stop the process with Ctrl-C. Editing `cordis.yml` itself is also picked up: the loader diffs entries by `id` and mounts, unmounts, or reconfigures only what changed. This is why the entries above carry explicit `id`s — an entry without one gets a generated id on every read, so after any config-file edit it counts as removed-plus-added and remounts even if its own lines did not change.
+
+## Diagnosing a plugin that never loads
+
+The flip side of dependency-driven loading: a plugin whose `inject` names a service nobody provides waits forever, printing nothing. No error — PENDING is a legitimate state, since the provider may be mounted later.
+
+You can see the states directly. Every context can enumerate the plugin registry; create `diagnose.ts`:
+
+```ts
+import { FiberState, type Context } from '@deepseek-ai/cordis'
+
+export const name = 'diagnose'
+
+export function apply(ctx: Context) {
+  setTimeout(() => {
+    for (const runtime of ctx.registry.values()) {
+      for (const fiber of runtime.fibers) {
+        if (fiber.state === FiberState.PENDING) {
+          console.log(`${fiber.name} is PENDING — a required service is missing`)
+        }
+      }
+    }
+  }, 500)
+}
+```
+
+And a plugin with an unsatisfiable dependency, `needs-timer.ts`:
+
+```ts
+import type { Context } from '@deepseek-ai/cordis'
+
+export const name = 'needs-timer'
+export const inject = ['timer']
+
+export function apply(ctx: Context) {
+  console.log('needs-timer loaded')
+}
+```
+
+```yaml
+- name: './needs-timer.ts'
+- name: './diagnose.ts'
+```
+
+Run it (plain `node --import tsx ../../vendor/cordis/bin.js`; stop with Ctrl-C):
+
+```
+needs-timer is PENDING — a required service is missing
+```
+
+`inject: ['timer']` has no provider. Add `- name: '@deepseek-ai/cordis-plugin-timer'` to the list and the plugin loads. When a plugin does nothing and reports nothing, inspect its fiber state. Iterating without the PENDING filter also shows the loader's own plugins (Loader, Include) as ACTIVE fibers because plugins mount the config file itself.
+
+Next: [Into the harness](./07-into-the-harness.md) — the same patterns against real harness services.

package/kb/site/en/develop/cordis-tutorial/07-into-the-harness.md

@@ -0,0 +1,107 @@
+---
+editSource: "docs/cordis-tutorial/07-into-the-harness.md"
+---
+
+# 7. Into the harness
+
+This chapter registers a model-callable tool with the harness's `tools` service, executes it through the harness tool pipeline, and observes the result event. It remains keyless and does not call a model.
+
+## A tool plugin
+
+Create `greet-tool.ts` in `tmp/cordis-tutorial`:
+
+```ts
+import type { Context } from '@deepseek-ai/cordis'
+import { defineTool } from '@deepseek-ai/dsh-tools'
+import { CallId } from '@deepseek-ai/dsh-llm'
+
+export const name = 'greet-tool'
+export const inject = ['tools']
+
+export function apply(ctx: Context) {
+  ctx.tools.register(defineTool({
+    name: 'greet',
+    description: 'Greet the named person.',
+    parameters: {
+      name: { type: 'string', required: true, description: 'Who to greet' },
+    },
+    output: {
+      schema: { type: 'string' },
+      render: (_args, value) => [{ type: 'text', text: value }],
+    },
+    async execute(args) {
+      return `Hello, ${args.name}!`
+    },
+  }))
+
+  // Drive one call through the real execution pipeline, standing in for
+  // the model. CallId brands the correlation id a provider would issue.
+  void (async () => {
+    const result = await ctx.tools.execute({
+      callId: CallId('demo-1'),
+      name: 'greet',
+      arguments: { name: 'Cordis' },
+      signal: new AbortController().signal,
+    })
+    console.log('tool replied:', JSON.stringify(result.content))
+  })()
+}
+```
+
+Every pattern here is from the earlier chapters: `inject: ['tools']` ([chapter 3](./03-services.md)) holds the plugin until the tool registry exists; `ctx.tools.register(...)` attaches the registration disposer to the plugin ([chapter 2](./02-lifecycle-and-effects.md)), so unloading unregisters the tool. `defineTool` converts the `parameters` spec to the JSON Schema shown to the model, infers the type of `args`, and validates model-supplied arguments before `execute` runs. The tool returns the canonical value declared by `output.schema`; `output.render` separately produces the Native and durable result content.
+
+## An observer plugin
+
+Create `tool-logger.ts` — a separate plugin that watches every tool call in the app through the harness's `tools/result` event:
+
+```ts
+import type { Context } from '@deepseek-ai/cordis'
+import type {} from '@deepseek-ai/dsh-tools'
+
+export const name = 'tool-logger'
+export const inject = ['tools']
+
+export function apply(ctx: Context) {
+  ctx.on('tools/result', (exec, result) => {
+    const text = result.content
+      .map(block => (block.type === 'text' ? block.text : ''))
+      .join('')
+    console.log(`[tool-logger] ${exec.name} -> ${text}`)
+  })
+}
+```
+
+The `import type {} from '@deepseek-ai/dsh-tools'` line pulls in the package's declaration merges so `'tools/result'` and its payload are typed — the same move as chapter 4's `stats.ts` import, at package scale.
+
+## Compose and run
+
+```yaml
+- name: '@deepseek-ai/dsh-system-prompt'
+- name: '@deepseek-ai/dsh-tools'
+- name: './tool-logger.ts'
+- name: './greet-tool.ts'
+```
+
+`@deepseek-ai/dsh-tools` injects the `systemPrompt` service because tools contribute schemas to the system prompt, so the composition lists its provider too. Without it, the tools plugin remains PENDING as described in [chapter 6](./06-composition-and-hmr.md).
+
+```sh
+node --import tsx ../../vendor/cordis/bin.js
+```
+
+```
+[tool-logger] greet -> Hello, Cordis!
+tool replied: [{"type":"text","text":"Hello, Cordis!"}]
+```
+
+The logger fired first: `tools/result` is emitted as part of result materialization, before `execute`'s promise resolves to the caller. Neither of your plugins knows the other exists — the registry service and the event connect them.
+
+## From here to a full agent
+
+A real agent is this composition plus more plugins: an LLM adapter, the agent loop, persistence, an entry point. Compare [examples/headless-agent/cordis.yml](https://github.com/deepseek-ai/deepseek-harness/blob/master/examples/headless-agent/cordis.yml) — you can read every entry in it now. Add your `greet-tool.ts` to a copy of that file.
+
+Where to go next:
+
+- [Build a tool](../basic/tool.md) — more of `defineTool`, including presentation and richer schemas.
+- [Three-layer capability design](../practice/index.md) — how the harness structures replaceable capabilities.
+- The generated `cordis-surface` regions on the [subsystem pages](../../reference/subsystems/core.md) — everything you can inject and listen to, each on its owning page.
+- [Architecture](../../reference/index.md) — the system map these plugins live in.

package/kb/site/en/develop/cordis-tutorial/index.md

@@ -0,0 +1,60 @@
+---
+editSource: "docs/cordis-tutorial/index.md"
+---
+
+# Cordis tutorial
+
+Cordis is the plugin framework underneath DeepSeek Harness: a small runtime where every capability — tools, LLM adapters, file access, the agent loop itself — is a plugin mounted into a shared context. This tutorial teaches Cordis hands-on: each chapter is a runnable example you build in a scratch directory inside this repository, ending with a plugin wired into real harness services.
+
+The audience is agent developers. You do not need deep TypeScript experience; the [TypeScript notes](#typescript-notes) below explain the syntax that may be unfamiliar, and every chapter shows the exact commands and expected output.
+
+If you want the condensed concept reference instead of a walkthrough, read the [Cordis primer](../../reference/cordis-primer.md). The exhaustive API reference lives in the generated `cordis-surface` regions on the [subsystem pages](../../reference/subsystems/core.md) and the [Cordis core API](../../reference/cordis-api/context.md) pages.
+
+To write plugins for the harness itself — loaded from a `cordis.yml` and driven from the Web UI rather than the launcher below — start from [your first Harness plugin](../basic/index.md).
+
+## Setup
+
+You need a clone of this repository with dependencies installed; the [development guide](https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/development.md#setup-tutorial) lists the prerequisites. No API key is needed for this tutorial; every example runs keylessly.
+
+```sh
+git clone https://github.com/deepseek-ai/deepseek-harness.git
+cd deepseek-harness
+pnpm install
+```
+
+Create the scratch directory the chapters work in. `tmp/` is gitignored, so nothing you write there touches version control:
+
+```sh
+mkdir -p tmp/cordis-tutorial
+cd tmp/cordis-tutorial
+```
+
+Every chapter runs the same command from this directory:
+
+```sh
+node --import tsx ../../vendor/cordis/bin.js
+```
+
+That one-file launcher (see [vendor/cordis/bin.js](https://github.com/deepseek-ai/deepseek-harness/blob/master/vendor/cordis/bin.js)) creates a root `Context`, mounts the Loader plugin, and tells it to load `./cordis.yml` from the current directory. Everything else — which plugins exist, how they are configured — comes from that YAML file, which you will write in a moment. The `--import tsx` flag lets Node run the TypeScript files the config points at without a build step.
+
+## Chapters
+
+1. [Your first plugin](./01-first-plugin.md) — a plugin is a function; the loader mounts it.
+2. [Lifecycle and effects](./02-lifecycle-and-effects.md) — Cordis-managed registrations are undone when their plugin unloads.
+3. [Services](./03-services.md) — expose a capability on `ctx` and depend on it with `inject`.
+4. [Events](./04-events.md) — typed events, broadcast dispatch, and the waterfall short-circuit.
+5. [Configuration](./05-config.md) — validated config from `cordis.yml`, failing loud on bad input.
+6. [Composition and HMR](./06-composition-and-hmr.md) — the config file as a plugin tree, hot reload, and diagnosing a plugin that never loads.
+7. [Into the harness](./07-into-the-harness.md) — register a model-callable tool against real harness services.
+
+<a id="typescript-notes"></a>
+
+## TypeScript notes
+
+The examples use three TypeScript features beyond ordinary modern JavaScript:
+
+- **Type annotations** describe values without changing runtime behavior: `ctx: Context` says that `ctx` has the Cordis context API, `who: string` accepts text, and `string[]` means an array of strings.
+- **`import type { Context } from '@deepseek-ai/cordis'`** imports only type information. It vanishes at runtime, so a plugin file that needs `Context` solely for annotations adds no runtime dependency.
+- **Declaration merging** (`declare module '@deepseek-ai/cordis' { ... }`) adds your entries to interfaces that Cordis already declares — for example the type of a new `ctx.greeter` property or event name. It generates no runtime wiring; the plugin separately provides the service or emits the event. Chapter 3 shows the pattern in full.
+
+Chapter 5 also uses an `interface` to describe a configuration object's fields and a generic type such as `Schema<Config>` to say which object fields a schema validates. You can copy those declarations as shown; the surrounding text explains what each one connects.

package/kb/site/en/develop/framework/events.md

@@ -0,0 +1,145 @@
+---
+editSource: "docs/user/develop/framework/events.md"
+---
+
+# Event system
+
+Events are the core communication mechanism between Cordis plugins. Harness uses them extensively for loosely coupled extension points.
+
+## Basic use
+
+### Listen for an event
+
+```ts ignore-check
+ctx.on('event-name', (payload) => {
+  // Handle the event.
+})
+```
+
+### Emit an event
+
+```ts ignore-check
+ctx.emit('event-name', payload)
+```
+
+## Event modes
+
+Cordis provides several event modes for different interaction contracts.
+
+### emit — broadcast
+
+Every listener runs synchronously and return values are ignored:
+
+```ts ignore-check
+// Emit
+ctx.emit('my-plugin/ready', { id: 'worker-1' })
+
+// Listen
+ctx.on('my-plugin/ready', ({ id }) => {
+  console.log(`${id} is ready`)
+})
+```
+
+### bail — short circuit
+
+Listeners run in order; the first result other than `null`, `false`, or `undefined` becomes the final result:
+
+```ts ignore-check
+// Dispatch
+const result = ctx.bail('some-check', input)
+
+// Listen: a returned value stops later listeners.
+ctx.on('some-check', (input) => {
+  if (shouldBlock(input)) return 'blocked'
+  // Return null, false, or undefined to continue to the next listener.
+})
+```
+
+### serial — ordered execution
+
+Listeners run in registration order and asynchronous results are awaited. The first result other than `null`, `false`, or `undefined` stops further execution:
+
+```ts ignore-check
+await ctx.serial('setup-phase', context)
+```
+
+### waterfall — pipeline
+
+Each listener may wrap the downstream result to form a processing chain. A listener **must call `next()` to delegate downstream**; omitting the call short-circuits the pipeline:
+
+```ts ignore-check
+// Dispatch
+const output = await ctx.waterfall('my-plugin/transform', input, async () => input)
+
+// Listen: next() is mandatory.
+ctx.on('my-plugin/transform', async (_input, next) => {
+  const downstream = await next()
+  return downstream.trim()
+})
+```
+
+::: warning
+A waterfall listener **must call `next()`**. Omitting it short-circuits the pipeline by design, enabling interception and gateway behavior.
+:::
+
+## Typed events
+
+Harness uses TypeScript declaration merging for type-safe events:
+
+```ts
+import '@deepseek-ai/cordis'
+
+declare module '@deepseek-ai/cordis' {
+  interface Events {
+    'my-plugin/ready': (payload: { id: string }) => void
+    'my-plugin/check': (input: string) => boolean | undefined
+    'my-plugin/transform': (input: string, next: () => Promise<string>) => Promise<string>
+  }
+}
+
+// ctx.on('my-plugin/ready', ...) and ctx.emit('my-plugin/ready', ...)
+// are now inferred correctly.
+```
+
+## Cordis events and session records
+
+Harness Cordis events use `namespace/action` names, including `agent/step`, `agent/request`, `agent/request-error`, `tools/result`, and `session/event`. The generated `cordis-surface` regions on the [subsystem pages](../../reference/subsystems/core.md) record complete signatures and modes.
+
+`turn/*`, `step/*`, `tool/call`, `tool/result`, and `compaction/*` are durable session-event types, not same-named Cordis events. To observe them, listen to `session/event` and inspect `event.type`.
+
+## Event listeners are effects
+
+A listener registered with `ctx.on()` is removed automatically when its plugin unloads:
+
+```ts ignore-check
+export function apply(ctx: Context) {
+  // This listener is removed when the plugin disposes.
+  ctx.on('tools/result', handler)
+}
+```
+
+## Example: logging plugin
+
+This plugin logs tool calls and results:
+
+```ts
+import type { Context } from '@deepseek-ai/cordis'
+import '@deepseek-ai/dsh-tools'
+
+export const name = 'tool-logger'
+
+export function apply(ctx: Context) {
+  ctx.on('tools/result', (exec, result) => {
+    console.log(`[tool] ${exec.name}(${JSON.stringify(exec.arguments)})`)
+    const text = result.content
+      .map(block => block.type === 'text' ? block.text : '')
+      .join('')
+    console.log(`[tool result] ${text.slice(0, 100)}`)
+  })
+}
+```
+
+## Next steps
+
+- [Capability layering](../practice/index.md) — understand events within capability interfaces
+- [LLM adapters](../practice/llm-adapter.md) — implement a complete LLM backend