pi-roundtable 0.7.19 → 0.9.0

package/docs/plugins.md

@@ -67,7 +67,7 @@ Use the kit's building blocks for a plugin that runs Pi itself, such as a coding
 - Tools: `textToolsExtension`, `requiredString`, `stringList` (with `toolText` and `toolError`) for tools that return text.
 - Mirroring a built-in tool in a worker that cannot reach the host: `SCHEDULE_TOOLS`, `scheduleToolSpecs({ locale, timeZone })`, `isScheduleTool`, `callScheduleTool`, `DELEGATE_TOOL` and `DELEGATE_TOOL_SPEC`.
   The specs take the locale and time zone for their descriptions, so the worker needs no process-wide setting.
-- Compaction: `CompactionTiers` gives a session the core's compaction tiers (`settings()` for Pi's `SettingsManager`, `wrapCompactor(factory, onBypass)` to hold a compaction extension back past the ceiling, `latest()`), with `SOFT_COMPACT_TOKENS` (300,000), `HARD_COMPACT_TOKENS` (500,000), `COMPACT_HEADROOM_TOKENS` (50,000), `compactionEngine(details, engine)` and the types `CompactionEngine`, `CompactionHistory` and `LatestCompaction`.
+- Compaction: `CompactionTiers` gives a session the core's compaction tiers (`settings()` for Pi's `SettingsManager`, `wrapCompactor(factory, onBypass, prepare?)` to hold a compaction extension back past the ceiling and change what it is given first, `latest()`), with `SOFT_COMPACT_TOKENS` (300,000), `HARD_COMPACT_TOKENS` (500,000), `COMPACT_HEADROOM_TOKENS` (50,000), `compactionEngine(details, engine)` and the types `CompactionEngine`, `CompactionHistory` and `LatestCompaction`. `summaryProjection(messages, history?)` is what a shared conversation's compaction may summarize, without anyone's private memory, prompt states, or reasoning, and `privateCompaction(preparation, additionalMessages?)` sets a `session_before_compact` preparation to it. Optional surrounding history pairs calls/results split across summary, prefix and kept context. Independent shared sessions use `memoryProjection(messages, view)` on requests and `hidesPrivateExchange(messages, view)` for raw replay guards (`MemoryView`: `shared` and `reader`; legacy attribution is internal to the bridge guard, not a projection option). `recordMemoryTurn(manager, reader, privateMemory)` appends `MEMORY_TURN_ENTRY` (`roundtable-memory-turn`) before prompting and returns a marker for memory first used later in that turn; `carriesMemory(message)` recognizes built-in memory calls/results and custom `privateTo` results, including immediate failures and unanswered calls. `bridgeHistoryHidesMemory(rawBranch, reader)` checks those records and raw exchanges across compaction; SYSTEM is a reader of its own there, and the core's SYSTEM-as-primary-owner attribution and its pre-scope legacy attribution stay inside the core.
 - Jev compaction: `jevCompact(input, options)` compacts through Jev (pi-jev-compaction 1.0.0) and returns `{ compaction }` or `{ skipped, detail? }` (a `JevSkipReason`: pi-jev-compaction's fallbacks `no_key`, `aborted`, `nothing_to_compact`, `no_candidates`, `cannot_fit`, `jev_error`, `reduction_too_small`, or `previous_summary_too_large`), for Pi's own summary to run instead.
   Its summary carries the previous summary once, as the transcript's `[previous compaction]` message, with `estimatedTokensAfter` measured on the final text; a previous summary over `previousSummaryLimitTokens` (default `JEV_PREVIOUS_SUMMARY_LIMIT_TOKENS`, 60,000) skips without calling Jev, so Pi's summary condenses the chain.
   Jev judges with `goal` (default `JEV_GOAL`: keep the tool results that set rules still in force, drop stale lookups, listings and finished edits), and the summary ends with a `## Rules loaded before this compaction` section naming each rule load among the summarized messages (tool name and JSON arguments cut at 200 characters) for the agent to load again; `ruleLoad(tool, args)` picks them (default `isRuleLoad`: tools ending in `invoke-skill` or `get-system-prompt`, and tools ending in `read` whose `path` is a `SKILL.md`, an `AGENTS.md` or under `.agents/skills/`).
@@ -97,6 +97,7 @@ definePlugin({
 	providers: {},             // optional: replaces a part the core runs on
 	provides: [],              // optional: keys of the services setup provides to other plugins
 	replaces: [],              // optional: keys of built-in services this plugin takes over
+	identities: [],            // optional: identities the plugin's own credentials stand for
 	preflight() {},            // optional: a check that runs before anything starts
 	setup(context) {           // required: returns the parts the plugin adds
 		return { /* parts */ };
@@ -109,6 +110,16 @@ Errors point to the plugin definition.
 
 A plugin whose `setup` returns `{}` and has no migrations, providers, or hooks stops startup (see [Errors](#errors-and-their-fixes)).
 
+`identities` is for a plugin that serves a credential of its own, such as the bearer token of an endpoint, and runs turns for whoever holds it.
+Each entry is a `PluginIdentity`, `{ identity, principal? }`: the identity written `token:<subject>`, such as `token:remote-mcp`, and the id of the principal it stands for, by default the primary owner (the first of `access.owners`).
+Only the `token` provider is accepted. A surface's identity, such as `discord:<user id>` or `oidc:…`, is a person's own account: declaring it would make whoever holds it the principal the plugin binds it to, owner included, and unlink it when the plugin stops declaring it. Link those in `access.owners` or with `roundtable principal link`.
+At every start the `identity` plugin links each one to its principal as the plugin's (`roundtable principal list` shows `plugin <name>`), moves one whose principal changed since the last start, and unlinks one no plugin declares any more.
+The start stops with a `ConfigError` for an identity that does not parse or is not a `token:` identity, one two plugins declare, the system principal, a principal that does not exist, and an identity linked to someone else by the configuration, the CLI, or a first contact; the message names what to change.
+A declared identity is never admitted or claimed as someone new, and linking it leaves the principal's 0.8 claim alone: a plugin's credential is not the person's own identity.
+Nor does its link tell who a configured owner is: an owner in `access.owners` that also lists a declared identity is known by its `principal` or its other identities, and the start stops when that is not the principal the plugin binds the identity to on that start (its `principal`, or else the primary owner), or when nothing else tells who the owner is. Whom the identity was bound to at an earlier start does not matter: once the plugin is bound to that owner in its options, the next start moves the identity to them.
+Read whom it stands for with `IDENTITY.principalOf(identity)`, and start the turn with `IDENTITY.speakerFor(principalId)`.
+A plugin that replaces `IDENTITY` replaces this too: the declarations are the built-in `identity` plugin's to link.
+
 ### The context
 
 `setup` receives a `PluginContext`:
@@ -126,9 +137,10 @@ A plugin whose `setup` returns `{}` and has no migrations, providers, or hooks s
 | `services` | The services plugins provide to each other, read by key: `services.get(SCHEDULES)`; see [services](#services-what-plugins-provide-to-each-other) |
 | `surfaces` | Every contributed [chat surface](#surfaces-a-chat-network-of-your-own), chosen by the prefix of a channel key: `of`, `sendReply`, `startTyping`, `showStop`, `react`, `unreact`, `prompts` |
 | `turns` | Runs one turn of a conversation your claim owns, over the runtime and the surfaces: [`turns.run`](#personas-and-contextturns-conversations-of-a-kind-of-your-own) |
-| `sessions()`, `conversations`, `surfaces`, `turns`, `dashboard()` | Linked once every plugin has been set up; calling them during `setup` throws `NotLinkedError` |
+| `directChannels` | Every plugin's [direct channels](#directchannels-reaching-a-person-on-their-own): `providers()`, `reach(principalId)`, `known(principalId)`, and `notify(principalId, text)` |
+| `sessions()`, `conversations`, `surfaces`, `directChannels`, `turns`, `dashboard()` | Linked once every plugin has been set up; calling them during `setup` throws `NotLinkedError` |
 
-`sessions()`, `conversations`, `surfaces`, `turns`, and `dashboard()` are available from a service's `start`, an event handler, or a claim's turn.
+`sessions()`, `conversations`, `surfaces`, `directChannels`, `turns`, and `dashboard()` are available from a service's `start`, an event handler, a session tool, or a claim's turn.
 
 Use `QueuePort` from the main entry for `context.queue`; the kit's `ChannelQueue` is also type-only.
 
@@ -139,7 +151,10 @@ Use `QueuePort` from the main entry for `context.queue`; the kit's `ChannelQueue
 `context.logger` is a child of the host's logger and adds `plugin: <your plugin's name>` to each line in the journal.
 `Logger` has five levels and `child(fields)`; you can pass an existing pino logger as `DefineOverrides.logger`.
 
-With `defineRoundtable`, the host's logger sends every `error` and `fatal` line to the ops agent named by `config.ops.agent`, which reports it in its channel.
+With `defineRoundtable`, the host's logger sends every `error` and `fatal` line to the ops agent named by `config.ops.agent`, which reports it in its channel, or, with `config.ops.conversation`, to that conversation as a visible message and a report turn its claim answers.
+The report turn is the host's own background turn of the `owner` target: it runs as the system principal (`SYSTEM_PRINCIPAL`) at the owner tier, as in 0.8, and so does the report turn of an outside Discord webhook's post in an agent's channel, whose text is untrusted input; neither can set up a schedule or delegate a task. The host does not start, with a `ConfigError` naming `config ops.conversation` and the reason, when no chat surface serves the key, no plugin's claim owns it, no plugin contributes the `owner` background target, the claim that owns it takes no background turns (has no `background`), or that claim says `takesSystemReports: false`, since its conversations are each private to their person and refuse the system principal's turns; a report is then never only logged. A claim like that is answered at startup, not by a warning at each report.
+The core contributes `PERSONAL_TARGET` (`"owner"`) with or without Discord; `ops.conversation` still needs a surface and a claim that accepts system report turns.
+Webchat accepts personal background turns but declares `takesSystemReports: false`, so `web:<id>` fails at startup; name a shared conversation of another surface, or an agent with Discord.
 It then calls `DefineOverrides.errorSink(entry)` if you supply one; this function must not throw.
 A logger you supply reaches the ops agent and `errorSink` only if it forwards its error lines there.
 The report names the plugin next to `app` and `module`; the same error is reported at most once an hour, regardless of which plugin wrote it.
@@ -172,11 +187,14 @@ The built-in plugins provide these, from the main entry:
 
 | Key | Port | Provided by | What it is |
 |---|---|---|---|
-| `AGENTS` | `AgentServer` | `agent-server` | The `team` (`AgentTeam`), the read-only `directory` (`AgentDirectory`), the `runtime` every agent turn runs on, `approvals` (whether the owner's reply approves held actions), and `avatars` (`AvatarStudio`) |
+| `IDENTITY` | `IdentityService` | `identity` | Who the host serves, read-only: `resolve(facts, { conversation }?)` gives the `Speaker` with its `principalId` behind a surface's `ActorFacts`, or undefined; `principal(id)`, `list()`, `identities(principalId)`, `roles(principalId)`, `tierOf(principalId)` (the lasting roles' tier), `speakerFor(principalId, tier?)` for a turn on someone's behalf, `owners()`, and `principalOf(identity)`, the principal an identity written `<provider>:<subject>` is linked to, such as one a plugin declares in `identities`. Principals are written only by the configuration and `roundtable principal`. `SYSTEM_PRINCIPAL` is the host's own, which no plugin speaks as |
+| `CONVERSATIONS` | `ConversationRegistry` | `conversations` | The conversations run through `context.turns`: `register`, `get(key)`, `list({ principal }?)`, `setTitle(key, title)`, and `adopt(key, principalId)` only for migrating a conversation recorded before 0.9; each a `ConversationRecord` of `key`, `surface`, `kind`, `visibility` (`"private"` or `"shared"`), `principalId?`, `title?`, `createdAt`, `lastActiveAt` |
+| `RUNTIME` | `AgentRuntime` | `runtime` | The runtime every conversation turn runs on, the agent server's and `context.turns`': the `runtime` slot's when a plugin fills it, Pi's otherwise |
+| `AGENTS` | `AgentServer` | `agent-server` | The `team` (`AgentTeam`), the read-only `directory` (`AgentDirectory`), the `runtime` every agent turn runs on (the same one `RUNTIME` provides), `approvals` (whether the owner's reply approves held actions), and `avatars` (`AvatarStudio`) |
 | `SKILLS` | `SkillRegistry` | `skills` (an addon) | What agents carry: `carried`, `carriedNames`, `describeCarried`, `catalog`, `list`, `linkedFrom`, `checkRegistered`, `link`, `attach` |
-| `SCHEDULES` | `ScheduleStore` | `schedule-store` | The stored schedules: `create`, `get`, `forChannel`, `all`, `update`, `remove`, `due`, `claim`, `recordStatus` |
+| `SCHEDULES` | `ScheduleStore` | `schedule-store` | The stored schedules: `create`, `createWithin`, `get`, `forChannel`, `all`, `update`, `remove`, `due`, `claim`, `recordStatus` |
 | `PRECHECKS` | `PrecheckRegistry` | `prechecks` | The host's named [prechecks](#prechecks-wake-a-schedule-only-when-it-has-work): `register`, `get`, `list`; and the runner of agents' precheck scripts: `useScriptRunner`, `scriptRunner` |
-| `MEMORY` | `MemoryStore` | `memory` (an addon) | `forSpeaker(id)` gives that speaker's `SpeakerMemory`: `list`, `forPrompt`, `add`, `search`, `update`, `removeById`, `remove`; `MEMORY_KINDS` is `core`, `note`, `event` |
+| `MEMORY` | `MemoryStore` | `memory` (an addon) | `forSpeaker(principalId)` gives that principal's `SpeakerMemory`: `list`, `forPrompt`, `add`, `search`, `update`, `removeById`, `remove`; `MEMORY_KINDS` is `core`, `note`, `event` |
 | `BACKGROUND_TURNS` | `BackgroundTurns` | `modules` | Turns nobody wrote: `runScheduled`, `runDelegated`, `runErrorReport` |
 | `DELEGATION` | `Delegator` | `modules` | `start(request)` a background task, `runningChannels()`, `idle()` |
 
@@ -322,9 +340,9 @@ You can switch them off in the configuration.
 
 | Addon | Plugin | Switch in `roundtable.config.ts` | What it adds | When it is off |
 |---|---|---|---|---|
-| Memory | `memory` (provides `MEMORY`) | `memory: false` | The memory table, the `memory_add`, `memory_search` and `memory_remove` tools, and the memory block of every system prompt | No memory tools and no block; the table is left as it is |
+| Memory | `memory` (provides `MEMORY`) | `memory: false` | The memory table, keyed by principal, the `memory_add`, `memory_search` and `memory_remove` tools, and the memory block of every system prompt but a `memory: "none"` persona's | No memory tools and no block; the table is left as it is |
 | Skills | `skills` (provides `SKILLS`) | `skills: false` | The skill tables, the skill tools of agent sessions (`skill_list`, `skill_link`, `skill_create`, `agent_skills`, and the rest), and the skills every agent carries, `writing-skills` included | No skill tools and no skills in any session; `agent_get` has no skills line; `agent_create` leaves out its `skills` parameter and refuses a call that passes some with `Skills are off on this host`; the tables are left as they are |
-| Discord administration | `discord-admin` | `discord: { admin: false }` | The `discord_*` tools that read and manage the server, for the owner | No `discord_*` tools; the channel executor that remote MCP uses is the connection's, so it stays |
+| Discord administration | `discord-admin` | `discord: { admin: false }` | The `discord_*` tools that read and manage the server, for the owner; they check what the primary owner may do on the server, whichever owner's turn calls them | No `discord_*` tools; the channel executor that remote MCP uses is the connection's, so it stays |
 
 Switching an addon off leaves its tables and rows unchanged, ready for when you turn it on again.
 `skills` also takes the two directories (`skills: { builtinDir, reposDir }`) when it is on.
@@ -339,11 +357,166 @@ service roundtable.memory is not provided. The memory addon is switched off (con
 `serviceKey(id, { absent })` lets your own keys say the same.
 Switching an addon off and adding a plugin of yours that provides the same key is equivalent to `replaces`.
 
+##### Memory in the agents' channels
+
+By default every speaker an agent's channel admits reads their own memory there, as in any shared conversation.
+`discord: { agentMemory: "owners" }` (or the same key in `discord({ ... })`; `AgentServerOptions.memory`, which the agent server hands the runtime as `AgentSessions.memory`) limits that to the owners: a turn of a speaker below the owner tier has no memory block in its prompt and no memory tools, and its worker tasks load none either, while an owner's turns in the same channel are unchanged.
+A guest's turn then records no private memory, so it never makes a `claude-bridge` model refuse the owner afterwards (see the [bridge guard](migration-0.9.md#claude-bridge-guard)).
+It does not make the guest's turn safe to run after the owner's: once the owner's turn has loaded memory, the guest's bridge turns are refused, as they are without the option, until the conversation starts fresh.
+It applies to the agents' channels and groups only; other conversations keep deciding by their persona.
+The default `"everyone"` is the 0.8 and 0.9 behavior.
+
+## Principals and access
+
+A principal is the person the host serves; an identity is an account or credential linked to that person.
+`Speaker.id` identifies the external actor, while required `Speaker.principalId` keys memory, private conversations, schedule authors, notifications, and per-person limits.
+Link Discord and web accounts with `roundtable principal link <principal> <identity>` to make them one person rather than two memories.
+A 0.8 person's principal retains their old speaker id; new admitted people get opaque `p_<ulid>` ids.
+
+Configure top-level `access.owners`, `admins`, and `members`.
+Identities are `<provider>:<subject>` (OIDC uses `oidc:<base64url issuer>:<subject>`), and roles are `<surface>:role:<name>`.
+`everyone: ["web"]` admits that surface only; `everyone: true` admits all surfaces and deserves particular care on a host with several adapters.
+The primary owner is the first owner, with an explicit `principal` and, on Discord, a Discord identity; Discord administration still acts with that person's permissions.
+Owner is granted only through configuration or the principal CLI, never an IdP role.
+`provisioning: "admitted"` is the default; `"linked"` admits only already linked identities.
+A disabled principal is refused, and CLI changes reach a running host within the identity cache's 30 seconds.
+
+Surfaces report verified `ActorFacts`, not authority.
+The router resolves them through `IDENTITY` before admission and overwrites a surface's own `message.speaker`.
+A claim must ignore a message without a resolved speaker and run an admitted message as that speaker, rather than reconstructing one at an assumed tier.
+Old author fields are a warned fallback until 1.0.
+A plugin initiating a turn on someone's behalf uses `IDENTITY.speakerFor(principalId)` and passes the speaker explicitly; `runTurn` without one is refused.
+A plugin's own credential bindings accept only `token:` (see [the plugin object](#the-plugin-object)), never a surface's account.
+
+The example below reads only the current principal, so two linked actors ask about the same person and owner tier alone cannot invent a missing principal.
+Put its `access` in the host configuration and its plugin in `plugins`.
+
+<!-- example: examples/principals.ts -->
+```ts
+import {
+	type AccessConfig,
+	definePlugin,
+	defineTool,
+	IDENTITY,
+	ToolRefusal,
+} from "pi-roundtable";
+import { Type } from "typebox";
+
+/** One person may have several identities; surface roles never make an owner. */
+export const access = {
+	owners: [
+		{
+			principal: "operator",
+			name: "Ada",
+			identities: ["discord:966666600000000001", "token:remote-mcp"],
+		},
+	],
+	members: { roles: ["web:role:App.User"] },
+	provisioning: "admitted",
+} satisfies AccessConfig;
+
+/** Ask about the current principal, not the external actor or the primary owner. */
+export const principals = definePlugin({
+	name: "principals",
+	requires: [IDENTITY],
+	setup: ({ services }) => {
+		const identity = services.get(IDENTITY);
+		return {
+			tools: [
+				defineTool({
+					name: "principal_who",
+					description: "Show who this turn is for.",
+					parameters: Type.Object({}),
+					minTier: "member",
+					run: async (_args, turn) => {
+						if (!turn.speaker)
+							throw new ToolRefusal("No speaker for this turn.");
+						const person = await identity.principal(turn.speaker.principalId);
+						if (!person || person.disabled)
+							throw new ToolRefusal("This principal is not available.");
+						return `${person.displayName} (${person.id})`;
+					},
+				}),
+			],
+		};
+	},
+});
+```
+<!-- /example -->
+
+<!-- example: examples/principals.test.ts -->
+```ts
+import { expect, test } from "bun:test";
+import { IDENTITY, type Speaker } from "pi-roundtable";
+import { servicePair, testPlugin } from "pi-roundtable/testing";
+import { access, principals } from "./principals.ts";
+
+test("two actor identities of one principal ask about the same person", async () => {
+	const lookedUp: string[] = [];
+	const harness = await testPlugin(principals, {
+		services: [
+			servicePair(IDENTITY, {
+				principal: async (id) => {
+					lookedUp.push(id);
+					return { id, displayName: "Mo", disabled: false };
+				},
+			}),
+		],
+	});
+	try {
+		for (const id of ["discord-actor", "web-actor"]) {
+			const speaker: Speaker = {
+				id,
+				name: "Mo",
+				principalId: "p_mo",
+				tier: "member",
+			};
+			expect(await harness.runTool("principal_who", {}, { speaker })).toBe(
+				"Mo (p_mo)",
+			);
+		}
+		expect(lookedUp).toEqual(["p_mo", "p_mo"]);
+	} finally {
+		await harness.stop();
+	}
+});
+
+test("an unavailable principal is refused even at owner tier", async () => {
+	const harness = await testPlugin(principals, {
+		services: [servicePair(IDENTITY, { principal: async () => undefined })],
+	});
+	try {
+		expect(
+			await harness.runTool(
+				"principal_who",
+				{},
+				{
+					speaker: {
+						id: "actor",
+						name: "Ada",
+						principalId: "operator",
+						tier: "owner",
+					},
+				},
+			),
+		).toContain("This principal is not available.");
+		expect(access.owners[0]?.principal).toBe("operator");
+		expect(access.members.roles).toEqual(["web:role:App.User"]);
+	} finally {
+		await harness.stop();
+	}
+});
+```
+<!-- /example -->
+
+For existing hosts and compatibility aliases, read [Migrating to 0.9](migration-0.9.md).
+
 ## Tiers: who may use what
 
 Every turn has a speaker with a tier: `owner`, `admin`, or `member`, from most to least trusted.
-By default, only the owner speaks.
-The operator can open the bot to others by listing them under `speakers` in `roundtable.config.ts` and is responsible for that setup.
+By default, only the configured owner speaks.
+The operator can open admission through `access` and is responsible for that setup.
+A turn's `kind` chooses a persona, never a tier.
 
 Each tool names the lowest tier that may call it.
 The bot offers the tool in turns whose speaker is at that tier or above; the operator's `toolTiers` setting can override the plugin's choice.
@@ -511,7 +684,7 @@ export const cleanup = definePlugin({
 
 A rule whose verdict depends on the input, such as one that holds only a `delete` action, can also answer `mayHold(tool)`: whether it may hold some call of that tool.
 It is asked when the input is not known yet, as for a [precheck script](#precheck-scripts-prechecks-the-agent-writes)'s call whose arguments are computed when it runs; a rule without it is judged by `describe` with an empty input.
-A rule whose held call stands for others can answer `approvalTier(tool, input, context)`: the lowest tier that may approve it when higher than the tool's own. The held call keeps it as `minTier`, and both its card and a confirming message require it.
+A rule whose held call stands for others can answer `approvalTier(tool, input, context)`: the lowest tier that may approve it when higher than the tool's own. The held call keeps it as `minTier`, and both its card and a confirming message require it. A card is answered, and a confirming message accepted, from the speaker whose turn held the call, when their tier is at least `minTier`, and from the owners where the conversation is shared ([who answers a prompt](#who-answers-a-prompt-promptscope)); nobody else in the channel may approve it. The held call records that speaker as `PendingConfirmation.speakerId` and their principal as `principalId`, so a confirming message from another identity of theirs counts after a restart too; a call held without them is the owners' to approve, and one held before 0.9, without a principal, is matched by `speakerId`.
 
 #### The shell rule
 
@@ -596,7 +769,7 @@ test("the section names the agent, and the speaker when there is one", async ()
 	expect(
 		section?.build({
 			agent,
-			speaker: { id: "1", name: "Ada", tier: "member" },
+			speaker: { id: "1", name: "Ada", tier: "member", principalId: "1" },
 			scope,
 		}),
 	).toContain("You are talking with Ada.");
@@ -642,6 +815,7 @@ export const library = definePlugin({
 | `serviceStarted(event)` | A service's `startInBackground` ended: `event` is `{ plugin, service, outcome }`, and `outcome` is `"ready"` or `"failed"`; the rest of the process runs either way |
 | `turnStarted(turn)` | An agent's turn began, or a turn run through `context.turns` |
 | `turnEnded(turn)` | The turn ended; `turn.result` is `"ok"`, `"failed"`, or `"stopped"` |
+| `turnProgress(event)` | A turn run through `context.turns` wrote text or ran a tool, between its start and its end: `event` is the turn's fields and `progress`, a `TurnProgress` (see the surface's `progress` below); a runtime without live progress reports none |
 | `changed()` | The team changed: an agent or group was created, edited, arranged, archived, or started over |
 | `shutdown(left)` | The shutdown drain ended, before any service stops; `left` lists the work it gave up on |
 
@@ -849,8 +1023,9 @@ The core stores the script with the schedule and decides with it exactly as with
 pi-roundtable-sandbox's `precheckScriptRunner` runs each script in a sealed container whose only way out is the MCP tools the host grants for that schedule; see its README.
 
 - `schedule_create` and `schedule_update` take `precheck_script`, a JavaScript module of at most `PRECHECK_SCRIPT_CHARS` (8,000) characters with a default export; it is parsed, never run, when it is set. A schedule has a `precheck` or a `precheck_script`; setting one removes the other, and `null` removes either.
-- The runner's `run(script, context)` gets the `PrecheckScriptContext`: the schedule, `firedAt`, `signal`, the host's `timeZone`, and `today`, the date there. Its answer is checked like a named precheck's, and its finding is named `script`.
-- `describe({ channel, target, tier })` (a `PrecheckScope`) tells the model how to write one and what it may call there; `schedule_list` shows it, waiting at most 10 seconds. `tier` is the asker's there and the script's creator's when it runs, so a runner may grant lower tiers less.
+- The runner's `run(script, context)` gets the `PrecheckScriptContext`: the schedule, `firedAt`, `tier`, `signal`, the host's `timeZone`, and `today`, the date there. `tier` is the tier the run is for: the schedule's, capped at what its creator holds now, as its turn would run. Its answer is checked like a named precheck's, and its finding is named `script`.
+- `describe({ channel, target, tier })` (a `PrecheckScope`) tells the model how to write one and what it may call there; `schedule_list` shows it, waiting at most 10 seconds. `tier` is the asker's there and the run's `tier` when it runs, so a runner may grant lower tiers less.
+- Before a schedule's precheck, named or a script, the scheduler checks who its turn would run as, as `ConversationPort.runsAs` does: a creator who may not run it now, such as one disabled, runs no precheck, and the run is recorded `skipped:` with the reason.
 - When the host stops, the scheduler aborts running scripts and waits up to 15 seconds for the runner to clean up; a precheck that ends then starts no turn.
 - Without a runner, the tools neither take nor mention `precheck_script`, a script is refused with the registered names, and a schedule that already has one wakes with `### Precheck failed: script`, never a silent skip.
 
@@ -996,7 +1171,7 @@ An unknown or misspelled slot stops startup with an error listing the valid name
 |---|---|---|
 | `judge` | Asks the configured model small questions: does this reply approve the held actions, how hard is this turn, which agents does this group message concern | An object with `askYesNo`, `askChoice`, and `askScore` |
 | `images` | No drawing; each agent gets an avatar generated from its display name | `async (prompt, references) => bytes` returning PNG bytes |
-| `runtime` | None: the agent server builds the Pi runtime itself | `(deps) => runtime`, an [`AgentRuntime`](#the-runtime-slot-replace-pi) that runs every conversation |
+| `runtime` | None: the runtime plugin builds the Pi runtime itself | `(deps) => runtime`, an [`AgentRuntime`](#the-runtime-slot-replace-pi) that runs every conversation |
 
 When no `images` provider is configured, `agent_create` has no `avatar_prompt` parameter and `agent_avatar` is unavailable.
 The owner's profile panel reports the missing provider and offers no redraw option.
@@ -1030,16 +1205,17 @@ export const pixelAvatars = definePlugin({
 
 The runtime handles the agent server's conversations and those of every claim that runs turns through `context.turns`.
 It keeps one persistent conversation per channel key, with its turns, held actions, and history.
-By default, the agent server builds the Pi runtime.
+By default, the host's `runtime` plugin builds the Pi runtime and provides it as `RUNTIME`; the agent server and `context.turns` both run on it, and a host without the agent server has it too.
 Filling the `runtime` slot replaces it for agent turns, the owner's conversations, steering, held actions, and transcripts; the host skips building Pi.
-The slot's default factory refuses calls, so check `providers.filled.has("runtime")` before calling `providers.runtime`.
-The agent server does this for you.
+The slot's default factory refuses calls: read the running runtime with `services.get(RUNTIME)` instead of calling `providers.runtime`.
 
-The slot is a `RuntimeFactory`: `(deps: RuntimeDeps) => AgentRuntime`, called once when the agent server sets up.
+The slot is a `RuntimeFactory`: `(deps: RuntimeDeps) => AgentRuntime`, called once when the runtime plugin sets up, before the agent server.
 `deps` provides `logger`, `env`, `owner`, `toolTiers`, and the host's `judge`.
 Its `sessions()` gives you linked hold rules, packages, session tools, and personas from preflight onwards; call it in a turn, when those parts are available.
-`prompts(conversation, speaker)` gives you the owner's approval and question cards on the conversation's surface, or `undefined`.
-`agents` holds the agent server's per-agent settings: `workDir`, `scratchDir` (the agents' shell's `TMPDIR`), `skills(name)`, `modelOf(name)`, and `turnChannel(scope)`.
+`prompts(conversation, scope)` gives you the approval and question prompts on the conversation's surface for a turn's `PromptScope`, made with `promptScope(speaker, visibility)` from the turn's speaker and `TurnRequest.conversation`, or `undefined`; see [who answers a prompt](#who-answers-a-prompt-promptscope).
+Given a `Speaker`, the 0.8 form, it reads them as the speaker of a shared conversation and the host warns once that the form goes away in 1.0.
+`agents` holds the agent server's per-agent settings: `workDir`, `scratchDir` (the agents' shell's `TMPDIR`), `skills(name)`, `modelOf(name)`, `turnChannel(scope)`, and `memory` (`"everyone"`, the default, or `"owners"`; see [memory in the agents' channels](#memory-in-the-agents-channels)).
+The agent server sets up after the runtime is built, so read `agents` when a turn runs; it is `undefined` on a host without the agent server, where no agent turn runs.
 `confirmations` stores held actions across restarts.
 
 An `AgentRuntime` has these methods:
@@ -1050,13 +1226,13 @@ An `AgentRuntime` has these methods:
 | `steer(conversation, text, attachments, speakerId?)` | Adds a message to the conversation's running steerable turn; `false` when the message must wait for its own turn |
 | `stop(conversation)` | Aborts the conversation's running turn; `false` when none runs |
 | `startFresh(conversation)`, `deleteConversation(conversation)` | Archive the conversation, or remove it for good; called between turns |
-| `pendingConfirmation(conversation)`, `heldActions(conversation)` | The held actions known in memory, and those restored from the store after a restart: the agent server reads `heldActions` to show an approval card again after a restart. A `PendingConfirmation` carries the `selectionId` of the `TurnSelection` whose turn held the calls, an opaque string that the caller resolves again when the owner confirms; the core stores it and never reads it |
-| `recentTranscript(conversation, limit)` | The latest messages, for the owner's and the dashboard's views of a conversation |
+| `pendingConfirmation(conversation)`, `heldActions(conversation)` | The held actions known in memory, and those restored from the store after a restart: the agent server reads `heldActions` to show an approval card again after a restart. After a restart `pendingConfirmation` knows a conversation's held actions only once `heldActions` or `recentTranscript` has restored them, so a host that decides an approval asks one of them first. A `PendingConfirmation` carries the `selectionId` of the `TurnSelection` whose turn held the calls, an opaque string that the caller resolves again when the owner confirms; the core stores it and never reads it |
+| `recentTranscript(conversation, limit)` | The latest messages, for the owner's and the dashboard's views of a conversation; the built-in runtime gives none of a history recorded, or a session opened, for someone else than the conversation serves now |
 | `contextUsage?(conversation)` | How full the conversation's context is, `{ tokens, contextWindow }`; leave it out and the team status shows no context bar |
 | `preflight?()` | Runs in the host's preflight, before anything starts; a throw stops the boot |
-| `dispose?()` | Runs when the host stops the agent server's runtime service |
+| `dispose?()` | Runs when the host stops the runtime plugin's `runtime` service |
 
-A request has the turn's `channel`, `selection` (its tools), `text`, `attachments`, `speaker`, flags (`steerable`, `interactive`, `confirmed`), and `interim`, where the turn may post the text it writes before its final answer ([interim text](#interim-text-what-a-turn-writes-before-its-final-answer)).
+A request has the turn's `channel`, `selection` (its tools), `text`, `attachments`, `speaker` (required: the person the turn is for, at whose tier it runs; the built-in runtime refuses a request without one with an `AgentRunError` before asking the model, and a plugin that starts a turn on someone's behalf gets theirs from `IDENTITY.speakerFor`), `conversation` (`TurnConversation`: `private` to a `principalId`, or `shared`, as `context.turns` records it; shared when absent), flags (`steerable`, `interactive`, `confirmed`), and `interim`, where the turn may post the text it writes before its final answer ([interim text](#interim-text-what-a-turn-writes-before-its-final-answer)).
 An agent's turn also has `agent`, the agent's scope, whose `session` is the conversation's key.
 Other turns use `kind` to name the conversation's persona, defaulting to `"owner"` when absent.
 
@@ -1162,7 +1338,7 @@ export const createEchoRuntime: RuntimeFactory = (deps) => {
 
 /**
  * A plugin fills the `runtime` slot to replace the whole conversation runtime; without one the
- * agent server builds the Pi runtime. One plugin may fill it.
+ * runtime plugin builds the Pi runtime. One plugin may fill it.
  */
 export const echoRuntime = definePlugin({
 	name: "echo-runtime",
@@ -1237,6 +1413,7 @@ test("an agent's turn carries its scope, and its conversation is the scope's ses
 		channel: "fake:agent-room",
 		selection: { id: "agent", tools: [], groups: [] },
 		text: "status?",
+		speaker: OWNER_SPEAKER,
 		agent: {
 			name: "infra",
 			session: "fake:agent-room",
@@ -1348,9 +1525,12 @@ Call `commands.add` from `setup`; after preflight it throws `commands can be add
 Use `services.find(DISCORD)` if your plugin can work without Discord.
 When the service is absent, the rest of your plugin can run without commands.
 
-Build a feature's part of the root command with `ownerCommandModule(guard, handlers)` from `pi-roundtable/discord`; it is owner-only, defers interactions, and supplies a failure panel.
+Build a feature's part of the root command with `ownerCommandModule(guard, handlers)` from `pi-roundtable/discord`; only the owners may use it, it defers interactions, and supplies a failure panel.
 That entry also exports `groupOption` for subcommand groups, the panel helpers (`ownerPanel`, `ownerPanels`, `ephemeralPanel`, `replyWithPanels`, `plain`, `OwnerFacingError`), and `agentPanel({ guard, agents })` for an agent's profile panel.
-`DISCORD.guard` is the `CommandGuard`; its `isOwner(actor)` accepts an interaction or anything with `user.id`, so a test needs no cast.
+`DISCORD.guard` is the `CommandGuard`; `await guard.allows(actor)` is whether the actor is an owner now: the primary owner by user id, and every other owner principal by their Discord identity, checked through `IDENTITY` each time, so an owner granted or revoked with the CLI is seen at once and a stranger is never resolved. It accepts an interaction or anything with `user.id` (a `DiscordActor`), so a test needs no cast.
+`guard.isOwner(actor)` is deprecated until 1.0: it is the primary owner only, by user id, so a component handler that still asks it refuses the other owners.
+`commandGuard({ ownerId, identity?, root, logger, refusalHint? })` makes one; without `identity` the primary owner is the only owner.
+The connection's `ownerChannel()` and `notifyOwner(text)` are deprecated until 1.0: they reach the primary owner alone. Reach a person through `context.directChannels` instead, where the Discord plugin's provider finds their direct messages by a Discord identity of theirs.
 `DiscordOptions.refusalHint` (`discord.refusalHint` in the configuration) is appended unchanged to the refusal a non-owner gets.
 
 <!-- example: examples/interactions.ts -->
@@ -1391,7 +1571,7 @@ A test gives the plugin `fakeDiscord()` from `pi-roundtable/testing`: `testPlugi
 ### `http`: routes on the bot's listener
 
 The configuration's `http` block opens a listener named `public`, which serves the agents' avatars.
-`http.publicUrl` is its internet address.
+`http.publicUrl` is its internet address, required with Discord; a host without Discord may leave `http` out and opens no listener.
 A route names the listener, a path (`{ exact }` or `{ prefix }`), optionally the methods, and a handler that gets a `Request` and returns a `Response`.
 Two routes that could take the same request are refused, so a route cannot shadow the avatars.
 This listener is reachable from the internet, so check a secret in the handler before taking action.
@@ -1404,6 +1584,20 @@ The socket file's permission bits are `http.socketMode`, `0o660` by default: onl
 Widen it (`0o666`) only when the proxy runs as a user outside that group.
 More listeners than `public` come from `defineRoundtable`'s `listeners` override, each `{ id, socketPath, mode? }` or `{ id, port, hostname? }`, and a route attaches to one by its `id`.
 
+A route that also declares `websocket` takes WebSocket upgrades on its path; every other request still reaches `handle`, and its `methods`, when listed, must include `GET`.
+An upgrade is a `GET` with `Upgrade: websocket`; one without `Sec-WebSocket-Key` or with a `Sec-WebSocket-Version` other than `13` gets `400`, and any other method goes to `handle` as usual.
+An upgrade request first passes the Origin check: `origins` lists the `scheme://host[:port]` values a browser may connect from, exactly as a browser sends them, such as `https://chat.example.com` or `chrome-extension://<id>` (a lowercase scheme and no path, trailing slash, query, fragment, or user; another form, and `"null"`, is refused at startup), and a request with another Origin, or none, gets `403` without reaching the route. `"any"` skips the check, for clients that are not browsers.
+A route holds at most `maxConnections` sockets at once (256 by default), counting upgrades still in `accept`; one more gets `503` before `accept` runs.
+Then `accept` authenticates and authorizes the request before any socket opens: it returns `{ data }`, which every handler reads as `socket.data`, or a `Response` such as `401` or `403` that refuses the upgrade. An `accept` that throws answers `500` like a failing `handle`.
+Browsers cannot set headers on a WebSocket, so a browser client proves itself with a ticket: one-time and short-lived in the query, so a ticket that leaks from a log or the history opens nothing, or carried in `Sec-WebSocket-Protocol`, which `accept` answers by returning the chosen protocol in `headers`.
+Never combine `origins: "any"` with cookie authentication: the browser sends the cookie from any site, so any page its user opens could take over their socket (cross-site WebSocket hijacking).
+Each message reaches `message` as it arrives. A message over `maxMessageBytes` (64 KiB by default) closes the socket with `1009`, and more than `rate.messages` in `rate.perMs` (120 a minute by default) closes it with `1008`.
+`socket.send` answers `"sent"`, `"queued"` when the client reads slower than the route sends, or `"dropped"`. `maxBufferedBytes` (1 MiB by default) is checked before each `send`: once that many bytes wait for a client that stopped reading, the next `send` answers `"dropped"` and the host cuts the socket without a close frame, so the client and the route's `close` both see `1006`. A `send` that finds fewer waiting goes out whole, so a single message larger than the limit still reaches a client that reads, and the bytes waiting can reach the limit plus one message. A `send` on a closed socket answers `"dropped"` too, and an empty message is `"sent"`.
+Every limit (`maxMessageBytes`, `maxBufferedBytes`, `maxConnections`, `rate.messages`, `rate.perMs`) must be a positive integer; another value is refused at startup with an error naming the route and field.
+The handlers' return values are ignored and a returned promise is awaited, so `message: (socket, message) => socket.send(message)` is a complete echo.
+A handler that throws or rejects closes only its own socket, with `1011`, and logs the route and listener like a failing `handle`.
+When the host shuts down, every open socket is closed with `1001`, and the shutdown waits up to five seconds for the routes' `close` handlers before it stops the services.
+
 <!-- example: examples/http.ts -->
 ```ts
 import { definePlugin } from "pi-roundtable";
@@ -1423,6 +1617,45 @@ export const health = definePlugin({
 		],
 	}),
 });
+
+/**
+ * A route with `websocket` also takes upgrades. The Origin check and `accept` run before any
+ * socket opens, so a browser on another site, or a client without a ticket, never connects.
+ * A ticket opens one socket: `accept` spends it, so one that leaks from a log or the browser's
+ * history opens nothing. Whoever issues the tickets should also let them expire within seconds.
+ */
+export const echo = (tickets: Set<string>) =>
+	definePlugin({
+		name: "echo",
+		setup: () => ({
+			http: [
+				{
+					name: "echo",
+					listener: "public",
+					path: { exact: "/echo" },
+					methods: ["GET"],
+					handle: () => new Response("Upgrade Required", { status: 426 }),
+					websocket: {
+						origins: ["https://chat.example.com"],
+						accept: (request) => {
+							const ticket = URL.parse(request.url)?.searchParams.get("ticket");
+							return ticket && tickets.delete(ticket)
+								? { data: { since: Date.now() } }
+								: new Response("Unauthorized", { status: 401 });
+						},
+						maxMessageBytes: 4096,
+						rate: { messages: 20, perMs: 10_000 },
+						maxBufferedBytes: 64 * 1024,
+						maxConnections: 50,
+						message: (socket, message) => {
+							// "dropped" means the client stopped reading and the host cut it; an echo has nothing to resend.
+							socket.send(message);
+						},
+					},
+				},
+			],
+		}),
+	});
 ```
 <!-- /example -->
 
@@ -1524,9 +1757,18 @@ The built-in addons use it: each declares the tiers of its own tools.
 
 A session tool is a Pi extension placed in every conversation session by its phase: `tools`, `compaction`, or `mcp`.
 Use it for tools that `defineTool` cannot express, such as a set that changes while the process runs (bump `revision`) or a tool that depends on the session.
-Each extension needs a unique name; the core reserves `read-attachment`, `confirmation-gate`, `ask-user`, `self-compact-guard`, and `active-tools`.
+Each extension needs a unique name; the core reserves `read-attachment`, `confirmation-gate`, `ask-user`, `self-compact-guard`, `private-memory`, and `active-tools`.
 A runtime of your own pins the active tools the way the core does: `activeToolsExtension(() => tools)` from `pi-roundtable/kit` is the extension the core places last, so its handler runs after every other extension's.
 At most one plugin may add a `compaction` extension, and it must name the `engine` its compactions record.
+In a shared conversation the core's wrapper hands it the history to summarize as `summaryProjection` gives it, without anyone's private memory, the prompt states, or the turns' reasoning, and Pi's own summary reads the same, since a summary outlives the turns it covers and every later speaker reads it. A compactor that reads the history otherwise, outside `session.compaction.wrap` or in a runtime of your own, must summarize a shared conversation's history the same way: call `privateCompaction(event.preparation, branchMessages)` from `pi-roundtable/kit` before reading it, passing the message entries of `event.branchEntries` so exchanges split across the kept boundary are paired too.
+
+The factory gets the session's `SessionContext`, fixed when the session is made:
+- `kind`, `homeChannel`, `turnChannel`, and `agent` say what the session is for and where its turns run.
+- `conversation` (`SessionConversation`) says whom it serves: `{ visibility: "private", principalId, principal? }` for one person's conversation, with their name and pronouns when the host has a record of them, or `{ visibility: "shared" }`. An agent's session is always shared. Otherwise it is as the turn's `TurnRequest.conversation` names it, else as the conversation registry recorded it, else shared; it is never the owner's by default. The runtime reads this again at every turn, the registry included, falling back to whom the open session or its recorded history served when nothing names the conversation, and refuses a turn of someone else in a conversation private to its person before the session is touched. A session's history records whom it served: when the conversation serves someone else, another principal or the other visibility, the session is made anew with nothing held for it, and its earlier history is archived rather than replayed, after a restart too; a history from before 0.9, which records no one, carries on. Changed session tools or skills rebuild a session with its history.
+- `addressee` is whom tool descriptions should name: the primary owner exactly as configured in their own private conversation, another person by their name and pronouns (their name alone when they gave none), and `THE_SPEAKER` in a shared conversation, or a private one of someone the host knows by no name yet.
+- `memory` is `"none"` for a persona that declares it, and `"speaker"` otherwise; a memory tool of your own loads nothing for `"none"`. A task the session runs with `runTask` keeps its conversation's `memory`.
+- `speaker()` is the running turn's speaker, undefined between turns; a tool reads it when it runs, never when the session is made, since a session outlives the turn it is built in.
+
 The core's Jev compactor is one such extension:
 
 ```ts
@@ -1602,6 +1844,13 @@ It leaves those other channels silent for the owner's notes, preventing other cl
 Your Discord claim won't receive messages from that guild at any priority below 100, including `priority: 10`.
 Claims on other surfaces, such as the example's `echo:` keys, don't compete with the agent server.
 
+Before a claim's `admit` sees a message, the router resolves its author through `IDENTITY` and sets `message.speaker`: their `id` on the surface, `name`, `tier`, and `principalId`, the principal whose memory, schedules, and conversations are theirs.
+It is undefined when the access rules serve no one by them, and for bots and integrations, which are not resolved; a `speaker` the surface set is dropped.
+A claim that serves only the people the host serves answers only when `speaker` is set.
+The router records the author, such as linking them at their first contact, only once a claim admits the message, so messages no claim takes link or make no one.
+One exception: an author already linked whom the access rules now refuse is recorded as seen at no tier when the message is resolved, whether or not a claim takes it, at most once every few minutes, so their background turns stop with them.
+When that record finds the author someone else than the claim admitted, such as linked to another principal meanwhile or refused now, or cannot be made, the router drops the message: a turn admission's optional `dropped()` is called instead of `run`, so the claim frees what it holds for it, and a background admission's `unanswered` hears it skipped.
+
 A claim may have `stop(channel)`, which stops the channel's running turn and returns whether one was running; the Stop button, `conversations.stop`, and every other stop go through it.
 The router calls only the owning claim's `stop`, returning `false` when that method is absent.
 Give `stop` to a claim whose conversations run turns that can be interrupted.
@@ -1647,7 +1896,8 @@ export const echo = definePlugin({
 
 A conversation has a kind: the string its claim returns from `startFresh`, such as `"owner"` or `"study"`.
 Your plugin names its claims' kinds; the host treats them as opaque strings.
-A `Persona` supplies the system prompt for every non-agent conversation of one kind: `{ kind, prompt() }`.
+A `Persona` supplies the system prompt for every non-agent conversation of one kind: `{ kind, prompt(), memory? }`.
+`memory: "none"` leaves memory out of its conversations: no memory tools and no memory in the prompt; `"speaker"`, the default, reads as the next list says.
 The runtime reads `prompt()` when it creates the conversation's session, so message catalog text uses the host's language.
 
 - A plugin contributes `personas` with the kinds it owns; `sessions().persona(kind)` is the linked lookup a runtime uses.
@@ -1658,14 +1908,34 @@ The runtime reads `prompt()` when it creates the conversation's session, so mess
   The host merges every plugin's list and keeps each name once.
 - A turn whose kind has no persona is refused with an error naming `personas`.
   The Pi runtime refuses when it makes the session; a runtime of your own does the same, as the example's does.
-- With the memory addon on, a turn's `speaker` decides whose memory the system prompt carries and the memory tools change: a member's or an admin's own, and the owner's for a speaker of the owner tier.
+- With the memory addon on, the conversation decides whose memory the system prompt carries and the memory tools change, by principal and never by tier: a private conversation's person's, whoever speaks in it; in a shared conversation, each turn's speaker's (`speaker.principalId`), so a second owner reads their own and not the primary owner's; and no one's in the host's own turns (`SYSTEM_PRINCIPAL`) in a shared conversation.
+  The primary owner's memory keeps its 0.8 heading and rows: their principal is 0.8's owner id.
+- A shared conversation's history never hands one person's memory to another. Each memory tool's result records whose memory it holds (`details: { privateTo: <principalId> }`), and before every model request the Pi runtime shows a result of someone other than the turn's reader, the host's own turns included, as `(another person's private memory, hidden)`, and a memory result that does not say whose as a placeholder too, one recorded before results said whose or a failed call's, such as one whose arguments were refused (a memory tool whose store fails still records whose memory the call was for, so its person reads their own failed exchange); the call that result answers, matched by its id, keeps its id and name but reads its arguments as `{ hidden: <the same placeholder> }`, so what the model copied from that memory into the call is not sent either; the prompt states Pi recorded in the history collapse into the current prompt alone, so an earlier speaker's memory section is not sent either, and the answers of earlier turns go without their reasoning (thinking, encrypted reasoning, tool calls' thought signatures, and the thought signature Gemini puts on an answer's text; OpenAI's signature of an answer's message, which names its id and phase, is no reasoning, but the message and call item ids OpenAI's Responses paired with the removed reasoning go with it, while each call keeps the id its result answers and each message its phase), which may restate the memory their turn read; the running turn keeps its own. What people wrote, and the assistant's replies, stay shared. A tool of your own whose result holds someone's private data returns the same `details.privateTo` principal id, including an error that repeats private input: both its arguments and result are hidden, regardless of the tool name.
+  A hidden result also drops private payload in its `details` and nested-call records, retaining only its ownership marker.
+  A host building an independent shared Pi session applies `memoryProjection` on `context_with_system` and `privateCompaction` before summarizing; the optional surrounding-history arguments of `summaryProjection` and `privateCompaction` preserve redaction across split exchanges. In the opt-in sandbox Pi protocol, return `PiToolResponse.privateTo` and pass the admitted `author.principalId`; the worker records `details.privateTo` and applies those projections itself. The runtime does it for you when the tool's `session.runTask` worker loaded the reader's memory: that call's result, and those of the calls it runs within (the outer call of a nested call, the call whose worker's task started it), record the reader as whose it is, while a call merely running beside it keeps its result public. The runtime knows which call started a task from the call its session tools' `execute` runs within; a task started from outside every tool call, such as an event handler's, cannot say, so every call running then records the reader. The guarantee, then, covers memory exchanges: a memory tool's call and result, and a call whose worker loaded the reader's memory and its result, each pair hidden from every other speaker and from compaction summaries, and the reasoning of earlier turns. Anything else the model writes, into another tool's arguments or into its reply, is public, and whatever it repeats there of someone's memory reaches everyone in the conversation. This holds for the requests the core sends; a provider that replays history of its own bypasses it. Each turn records its actual reader and whether its request carried private prompt memory, a memory exchange, or a memory-loaded worker. Before any provider call and on agent model switches too, claude-bridge checks the raw branch, including compacted reader records, and refuses a turn whose history carried another reader's private memory or an inaccessible explicit exchange. This refuses reasoning replay across readers even without memory tool calls. A recorded turn without private memory never blocks another reader merely for speaking; malformed, truncated and unanswered memory calls belong to their recorded turn reader, so its own reader can continue. For this core check only SYSTEM counts as primary owner, including modern exchanges/reasoning; SYSTEM can read that raw owner memory and repeat it publicly, despite per-request projection loading no personal memory for SYSTEM. Pre-0.9 untagged memory results before the first scope record retain owner attribution; later unowned exchanges without reader records fail closed. Disabling future memory does not bypass recorded private history. In Pi sandbox mode, party-wide prompt blocks must explicitly set `memory.visibility: "shared"` (default private), and the worker capability handshake fails private turns closed on an old image. Admission of other principals warns at startup and in doctor rather than failing boot. Public replies, untagged custom tools and old summaries remain possible disclosure paths: see the [bridge guard](migration-0.9.md#claude-bridge-guard).
+- A conversation 0.8 recorded through `context.turns` without `conversation` stays shared: whether such a room was one person's cannot be told, and adopting it for someone would refuse everyone else's turns. Its memory is each speaker's, as before, and its tools name the speaker. A plugin whose 0.8 conversations were one person's adopts them with `CONVERSATIONS.adopt`, as remote-mcp does.
 
 Call `context.turns.run(input)` inside your claim's queue task to run a turn in a conversation it owns.
 It shows typing and the stop control on the channel's surface, runs the turn, and emits `turnStarted` and `turnEnded` with the turn's `kind`.
 It catches runtime errors as failed results and posts the answer, failure notice, or stopped notice through the surface.
 Supply `reply(result)` to handle the reply yourself.
-`input` has `channel`, `kind`, `text`, `speaker`, and optionally `attachments`, `selection` (by default the plugins' `agentSelection`), `steerable`, `interactive`, `confirmed`, and `reply`.
-It rejects with `NotLinkedError` during `setup`, and with a `PluginError` on a host whose agent server has not provided a runtime.
+`input` has `channel`, `kind`, `text`, `speaker`, and optionally `attachments`, `selection` (by default the plugins' `agentSelection`), `steerable`, `interactive`, `confirmed`, `reply`, and `conversation`.
+It rejects with `NotLinkedError` during `setup`, and with a `PluginError` on a host whose runtime plugin has not provided a runtime.
+
+Before each turn runs, `context.turns.run` records its conversation in the host's registry, `CONVERSATIONS`: at the first turn its key, surface, kind, visibility, owner, and title, and at every later turn only that it was active.
+`conversation: { visibility: "private" }` records it as the speaker's own (its `principalId` is `speaker.principalId`); without it the conversation is `shared`.
+Only its person speaks in a private conversation: a turn whose speaker is another principal is refused before it starts, except the host's own turns (`SYSTEM_PRINCIPAL`), such as a report's.
+Neither a later turn nor another plugin changes what the first turn recorded, with one exception for data from before 0.9: `adopt(key, principalId)` makes a conversation recorded `shared` with no principal, as 0.8 recorded every turn run without `conversation`, private to that principal.
+It is for a plugin migrating what its own 0.8 version left, such as remote-mcp giving each session 0.8 opened to the primary owner; it never changes a private conversation or one with a principal, and repeating or racing it is safe.
+Adopting a conversation that 0.9 or later recorded is outside its contract: a shared conversation recorded since then is shared on purpose, and a later version may refuse to adopt it.
+`conversation.title` names it at its first turn; `setTitle(key, title)` renames it later.
+The runtime is told who the conversation belongs to as the registry keeps it, in `TurnRequest.conversation`, so a private conversation's prompts stay its person's at every later turn; a host without the registry passes the turn's own `conversation`, if it gives one.
+A turn whose conversation cannot be recorded does not run, and the call rejects.
+The registry records and never refuses: who may speak in a conversation stays your claim's decision, which may read `get(key)` to check the owner.
+`list({ principal })` gives one principal's conversations and `list()` every one, the most recently active first; the web console lists them too.
+A conversation from before the registry is recorded at its next turn.
+Register a private conversation before the first direct runtime call, transcript reads included, rather than relying on a current speaker to define the session.
+Never change visibility to reuse history: when the effective private principal or visibility changes, the runtime archives history, drops held actions, and starts isolated, after a restart too.
 
 <!-- example: examples/study-room.ts -->
 ```ts
@@ -1696,25 +1966,22 @@ export const studyRoom = definePlugin({
 				priority: 10,
 				// The id of a room starts with `study-`, on whichever surface carries it.
 				owns: (channel) => parseChannelKey(channel).id.startsWith("study-"),
-				admit: (message) =>
-					message.authorIsBot
-						? undefined
-						: {
-								kind: "turn",
-								run: async () => {
-									await turns.run({
-										channel: message.channel,
-										kind: STUDY,
-										text: message.text,
-										speaker: {
-											id: message.authorId,
-											name: message.authorName,
-											tier: "member",
-										},
-									});
-								},
-								failure: "a study turn failed",
-							},
+				admit: (message) => {
+					const speaker = message.speaker;
+					if (message.authorIsBot || !speaker) return undefined;
+					return {
+						kind: "turn",
+						run: async () => {
+							await turns.run({
+								channel: message.channel,
+								kind: STUDY,
+								text: message.text,
+								speaker,
+							});
+						},
+						failure: "a study turn failed",
+					};
+				},
 				// What the conversation was, so a host picks the right persona when it starts over.
 				startFresh: async () => STUDY,
 			},
@@ -1729,7 +1996,8 @@ The test uses the fake surface and echo runtime from [the runtime slot](#the-run
 <!-- example: examples/study-room.test.ts -->
 ```ts
 import { expect, test } from "bun:test";
-import { testPlugin } from "pi-roundtable/testing";
+import { IDENTITY } from "pi-roundtable";
+import { servicePair, testPlugin } from "pi-roundtable/testing";
 import { createEchoRuntime } from "./echo-runtime.ts";
 import { FakeSurface } from "./fake-surface.ts";
 import { studyRoom } from "./study-room.ts";
@@ -1740,6 +2008,16 @@ async function studying() {
 	const harness = await testPlugin(studyRoom, {
 		surfaces: [surface],
 		providers: { runtime: createEchoRuntime },
+		services: [
+			servicePair(IDENTITY, {
+				resolve: async (facts) => ({
+					id: facts.subject,
+					name: facts.name,
+					principalId: "student",
+					tier: "member",
+				}),
+			}),
+		],
 	});
 	return { surface, harness };
 }
@@ -1769,6 +2047,7 @@ test("a message in a study room runs as a turn of the study kind, with the tutor
 	expect(started?.turn).toMatchObject({
 		kind: "study",
 		channel: "fake:study-algebra",
+		speaker: { principalId: "student", tier: "member" },
 	});
 	expect(started?.turn?.agent).toBeUndefined();
 	await harness.stop();
@@ -1790,6 +2069,22 @@ test("starting a room over says it was a study conversation", async () => {
 	await harness.stop();
 });
 
+test("an author with no resolved tier never starts a study turn", async () => {
+	const surface = new FakeSurface();
+	const harness = await testPlugin(studyRoom, {
+		surfaces: [surface],
+		providers: { runtime: createEchoRuntime },
+	});
+	try {
+		surface.say("fake:study-algebra", "hello");
+		await Bun.sleep(30);
+		expect(surface.replies).toEqual([]);
+		expect(harness.events).toEqual([]);
+	} finally {
+		await harness.stop();
+	}
+});
+
 test("the persona is the plugin's and belongs to the study kind only", async () => {
 	const { harness } = await studying();
 	const [persona] = harness.contribution.personas ?? [];
@@ -1800,18 +2095,136 @@ test("the persona is the plugin's and belongs to the study kind only", async ()
 ```
 <!-- /example -->
 
+### Channel context: what was said around an addressed message
+
+In a Discord server channel, people talk among themselves and address the assistant now and then.
+Channel context lets the turn for an addressed message also read what was posted there since the assistant last posted, mentions or not.
+The agent server reads it for every turn in an agent's channel; a group's round does not, since it already carries what was said since the group's last turn.
+A plugin's claim opts in by calling `DISCORD.channelContext(message, options?)` from `pi-roundtable/discord` inside its turn's `run`, and appending the result with `withChannelContext(text, context)`, as `withReference` adds the replied-to message.
+
+It reads Discord, not the host's history, so it survives restarts:
+
+- It fetches the `fetch` messages before the addressed one (default 50, at most 100) and keeps those after the assistant's latest post there: its bot user's, or one of its application's webhooks, such as an agent's voice. Any post of the assistant ends the window, including a notice that a conversation started over; the core posts no marker of its own, so a fresh-start reply must be a public post, not an ephemeral one, to cut the window.
+- It leaves out the assistant's own posts, the addressed message, empty messages, and every message it handed over before or that addressed it before in that channel, remembered in memory per channel, so a restart can repeat at most what came since the assistant's last post.
+- Other bots and integrations are kept and marked as bots; the host's owners (the primary owner and every other owner's Discord identities) are marked as owners.
+- Consecutive messages of one author at least `similarity` alike (default 0.8, by their longest common run of text) count as one, the later kept.
+- It keeps the newest `keep` (default 15), oldest first. Mentions read as names, and stickers and files as text with their names and links; nothing is downloaded or shown to the model as an image. A message is cut at `messageChars` (default 500), another bot's at `botMessageChars` (default 80).
+- It never fails the turn over Discord: a Discord error, such as a channel the bot cannot read, is logged and the turn runs without context.
+
+`DISCORD.channelContext` resolves undefined in a direct message, on another surface, when nothing new was said, and when the host's `discord.channelContext` is `false`, which turns it off for the agent server and every claim.
+The configuration's values are the host's defaults, and a call's `options` override them for that call.
+Call it once per answered message: what it returns is remembered as handed over.
+A call's `options` are validated like the configuration (`fetch`, `keep`, `messageChars` and `botMessageChars` positive integers, `similarity` from 0 to 1); an invalid one makes the call reject, a programming error, so `keep: 0` is not "none" (skip the call for that).
+It remembers what it handed over and what addressed the assistant, not every message that ran a turn: a post a claim answered some other way, such as a webhook report turn or a steered message, can also come in the context of a later turn if the assistant has not posted since.
+
+What it returns is public channel text, visible to everyone in the channel; it is not private memory, carries no `privateTo`, and goes into the turn's text, so it lives in the conversation's history, not in the system prompt.
+The turn's reader stays the person who addressed the assistant.
+People the access rules give no tier are included as channel text, as everyone there sees them, but they do not become speakers: they are not resolved, linked, or recorded, and the turn does not run as them.
+Only server channels are read, never direct messages, and only messages the bot can read.
+
+The window ends at the assistant's last public post, so a conversation started over must end it too, and the owner's reply to the command is ephemeral.
+When any claim's conversation is started over in a server channel or thread, through `conversations.startFresh` (the agent server's channels, a plugin's claim such as a party, an owner channel), the core posts one short divider there as the bot, after the claim's `startFresh` succeeded, and the next turn reads nothing from before it.
+It is not posted in a direct message or on another surface, and a failed post is logged as a warning: the restart still counts and the ephemeral reply still goes out.
+The text is `discord.freshMarker` (default `─── new conversation ───`); `false` posts none.
+A surface a plugin contributes may implement the optional `ChatSurface.markFresh(channel)` for the same job.
+
+The block gives each author as a name, their Discord id and a role (`owner`, `bot` or `member`) in separate attributes, and says the messages were not addressed to the assistant. A name loses the characters `"`, `'`, `=`, `<`, `>`, `(`, `)` and `,`, so it cannot imitate another author, an attribute or a role, and every `<` (also the full-width `＜`) in a message's text is replaced by `‹`, so a message can neither close the block nor open a message of its own.
+`ChannelContext` is `{ messages, text }`: `messages` are `ChannelContextMessage`s (`id`, `authorId`, `authorName`, `bot`, `owner`, `text`, `at`), oldest first, and `text` is the block.
+`ChannelContextOptions` holds the options above, and `CHANNEL_CONTEXT_DEFAULTS` their defaults.
+In a test, `fakeDiscord({ channelContext })` answers `DISCORD.channelContext` as the test says; by default with no context.
+
+<!-- example: examples/channel-context.ts -->
+```ts
+import { definePlugin, parseChannelKey } from "pi-roundtable";
+import { DISCORD, withChannelContext } from "pi-roundtable/discord";
+
+/** The kind of the tavern's conversations. */
+const TAVERN = "tavern";
+
+/**
+ * A claim that opts in to channel context: in the Discord channels it owns it answers only the
+ * messages that mention the assistant or reply to it, and each turn also reads what the others
+ * said there since the assistant last posted. The context is public channel text appended to the
+ * turn's text; the people who wrote it do not become speakers.
+ */
+export function tavern(channelIds: readonly string[]) {
+	return definePlugin({
+		name: "tavern",
+		setup: ({ turns, services }) => {
+			const discord = services.get(DISCORD);
+			return {
+				personas: [
+					{
+						kind: TAVERN,
+						prompt: () =>
+							"You keep the tavern's table. Answer the person who addressed you.",
+					},
+				],
+				channels: [
+					{
+						name: "tavern",
+						priority: 10,
+						owns: (channel) => {
+							const { surface, id } = parseChannelKey(channel);
+							return surface === "discord" && channelIds.includes(id);
+						},
+						admit: (message) => {
+							const { speaker } = message;
+							if (message.authorIsBot || !speaker) return undefined;
+							if (!message.mentionsBot && !message.repliesToBot)
+								return undefined;
+							return {
+								kind: "turn",
+								run: async () => {
+									// Once per answered message, inside `run`: what it returns is not returned again.
+									const around = await discord.channelContext(message, {
+										keep: 20,
+									});
+									await turns.run({
+										channel: message.channel,
+										kind: TAVERN,
+										text: withChannelContext(message.text, around),
+										speaker,
+									});
+								},
+								failure: "a tavern turn failed",
+							};
+						},
+						startFresh: async () => TAVERN,
+					},
+				],
+			};
+		},
+	});
+}
+```
+<!-- /example -->
+
 ### `backgroundTargets`: whose turn a schedule or delegated task is
 
 Schedules and delegated tasks return later as turns without a new message in the channel.
 A `BackgroundTarget` says whose turn that is: a `name` that the schedule or job stores, a `label(locale)` that lists such as `/<root> schedule` show, and the limits that apply to it.
-`schedules` (`perChannel`, `promptChars`, `aheadDays`) bounds what `schedule_create` accepts, and `delegation` (`maxRunning`) bounds how many delegated tasks may run in one channel; a target without one of them may not schedule or delegate at all.
+`schedules` (`perChannel`, `promptChars`, `aheadDays`, and optionally `perPrincipal`) bounds what `schedule_create` accepts, and `delegation` (`maxRunning`, and optionally `maxRunningPerPrincipal`) bounds how many delegated tasks may run in one channel; a target without one of them may not schedule or delegate at all. `perPrincipal` and `maxRunningPerPrincipal` hold each person to that many of the target's schedules, or running tasks, across all their conversations. A schedule store counts a person's schedules for `perPrincipal` in `createWithin`, which must count and store as one step for that person, so creates at once in several conversations stay within the limit; the built-in store does it in one transaction under a lock on the creator.
 The claim that answers the target serves it in its `background(turn)`, where `turn.target` is the name, and skips every target it does not serve.
 A channel's claim runs turns only for its own target, keeping the owner's tools out of channels open to many people.
 
+A turn is someone's: `turn.author.principalId` is the principal who set up the work, `turn.author.id` and `name` how they are shown, and `turn.tier` the tier it asks for, all required.
+The router checks the author as the turn starts, in its place in the channel's queue, and hands the claim `turn.speaker`, the speaker to run it as: the principal at the lower of `turn.tier` and their tier now.
+It skips the turn, with the reason, when the principal does not exist, is disabled, holds no tier, or holds one only from what a surface reports and was last seen more than `access.backgroundStaleDays` ago, and when the turn names no principal or tier; it never runs one as the owner's by default.
+A turn naming the system principal (`SYSTEM_PRINCIPAL`) runs only when the host itself started it.
+A schedule stores its creator's principal as `createdById` and runs as them; a delegated task's report runs as the person whose turn delegated it.
+In a turn nobody is named for, the schedule and delegation tools refuse.
+
 - Contribute `backgroundTargets` alongside the claim that serves them; read one with `context.conversations.target(name)` from a service or handler.
 - Two targets with the same name are refused, naming both plugins.
-- The agent server contributes `OWNER_TARGET` (name `"owner"`, exported from the main entry) for the owner's and agents' conversations.
-  Its claim answers that target and skips all others, so a turn for another target never runs with the owner's tools.
+- The core's `modules` plugin contributes `PERSONAL_TARGET` (name `"owner"`, exported from the main entry; `OWNER_TARGET` is a deprecated alias) on every host, for every person's conversations whose claim answers background turns, such as the agents' and an app's owner conversation.
+  The agent server's claim answers that target and skips all others, so a turn for another target never runs with the owner's tools.
+  Its limits are 0.8's, and it holds no one to a number of schedules or running tasks across their conversations unless the host's configuration says so: `background: { perPrincipal: { schedules: 20, delegations: 2 } }` sets its `perPrincipal` and `maxRunningPerPrincipal`. A host that serves many people sets both.
+- The built-in schedule and delegation tools make `PERSONAL_TARGET` work, and a session has them only where it can run: when the claim that owns its conversation has `background`, or, for a conversation no chat surface carries, when its creator has a direct channel, as a provider knows without the network.
+  Such a conversation has the tools only when the registry records it private: its person is whom the work runs for. One recorded shared, or not recorded, has neither tool, whoever speaks in it, because a session outlives the turn it is built in.
+  A plugin that calls the runtime directly records its no-surface conversation as private before the session is built.
+  Creation reaches the speaker's own direct channel and checks that its claim takes background turns, refusing when either is absent; it never falls back to the primary owner's messages.
+  In a private conversation, as the host's conversation registry records it, `schedule_list`, `schedule_update`, and `schedule_cancel` see only the speaker's own schedules.
 - A turn for a target no plugin contributes is skipped with the reason `no plugin contributes the background target "<name>"`.
   It never falls back to the owner's target; a recurring schedule keeps the reason as its last status and runs again once a plugin contributes the target.
   A one-time schedule is spent when it fires.
@@ -1862,6 +2275,42 @@ export const supportDesk = definePlugin({
 ```
 <!-- /example -->
 
+### `directChannels`: reaching a person on their own
+
+A plugin whose chat network gives each person a conversation of their own, such as direct messages or a web inbox, contributes a `DirectChannelProvider` for it:
+
+```ts
+setup: ({ services }) => ({
+	directChannels: [
+		{
+			name: "inbox",
+			label: "a notice in the web chat's inbox",
+			reaches: async (principalId) => inboxOf(principalId),
+			deliver: async (principalId, text) => postNotice(principalId, text),
+		},
+	],
+}),
+```
+
+| Field | What it is |
+|---|---|
+| `name` | Unique across every plugin; a second provider of one name is a `PluginError` naming both plugins |
+| `label` | How the `notify` tool names a notice sent through it, completing "Send Ada …", such as `a direct message on Discord` |
+| `reaches(principalId)` | The person's own conversation here, as a channel key, or `undefined` when they have none here. It may reach the network and throw |
+| `knows(principalId)` | Optional: whether the person has a conversation here, from the host's own records such as their linked identities, without the network. A session asks it when it decides whether to offer `notify` or the schedule and delegation tools, so an outage then does not take them away; without it the host asks `reaches` |
+| `deliver(principalId, text)` | Optional: sends the notice itself. Without it the host posts the text in the channel `reaches` names, through the surface that serves it |
+
+The host reaches a person through the first provider, in contribution order, that reaches them.
+`context.directChannels.reach(principalId)` resolves that provider and channel, or `undefined`; `known(principalId)` resolves the first provider that knows the person without the network; `notify(principalId, text)` sends a notice there and resolves `false` when no provider reaches the person.
+The Discord plugin contributes one named `discord`: it finds a principal's Discord identities through `IDENTITY` and reaches the first one's direct messages, the primary owner's configured identity first, so a single owner is reached in the same direct messages as in 0.8.
+
+The `notify` tool, 0.8's `notify_owner`, sends such a notice. A session has it only when a provider is contributed, and a private conversation only when a provider knows its person; the channel itself is reached when a notice is sent.
+It notifies the conversation's person in a private conversation and the turn's speaker in a shared one, and refuses when no provider reaches them or when the speaker is not the private conversation's person; the host's own turns, such as a report's, notify the conversation's person in a private conversation and the primary owner elsewhere, as `notify_owner` did.
+Its description names the channels that can reach the person, so a host with only Discord reads `Send Ada a direct message on Discord. …` as 0.8 did.
+In a shared conversation it names the primary owner while only they can receive a notice (the host has no other owner, and only owners may use it), and "the speaker" otherwise; this is checked again before each turn, so an open session follows an owner granted or revoked meanwhile.
+Until 1.0 the name `notify_owner` still selects it in a selection or a profile and names it in a task's `exclude` and a plugin's `requiredTools`, and an operator's or a plugin's `toolTiers` entry for `notify_owner` applies to `notify` unless `notify` has its own.
+Using the old name logs a deprecation warning once per logger, whether in a selection or in `toolTiers`.
+
 ### `surfaces`: a chat network of your own
 
 A chat surface connects the host to one chat network: it reports what people write, and it posts what the conversations answer.
@@ -1882,8 +2331,12 @@ The agent server claims only `discord:` keys, so claims on your surface's channe
 | `startTyping(channel)` | Shows a typing indicator until the returned function is called | none is shown |
 | `showStop(channel)` | Shows the owner a stop control until the returned function is called; using it calls `conversations.stop(channel)` | none is shown |
 | `react`, `unreact` | Adds or removes the bot's reaction on a message | no marks on queued or steered messages |
-| `prompts(channel, speaker?)` | The owner's way to approve a held action or answer `ask_user` inside a running turn, as `OwnerPrompts`: `confirm` and `ask` | the action is held until the owner's next message |
+| `prompts(channel, scope?)` | How those the turn's `PromptScope` names approve a held action or answer `ask_user` inside a running turn, as `Prompts`: `confirm` and `ask`; without a scope, the owners | the action is held until a message approves it |
 | `interim(channel)` | Where a running turn posts the text it writes before its final answer, as `InterimPosts`: `post(text)` sends one message of at most 2000 characters and resolves to an `InterimMessage` whose `edit(text)` changes it in place | only the final reply is posted |
+| `progress(channel, event)` | Shows a turn run through `context.turns` as it goes, such as a live preview in a web chat. `event` is a `TurnProgress`: `{ type: "text", delta }` (the reply's text, joined over 250 ms and always sent before a tool event, never the thinking), `{ type: "tool_start", id, tool, preview? }` (a one-line preview of the arguments, at most 80 characters, never their full text), or `{ type: "tool_end", id, tool, ok }`. The final reply still comes through `sendReply`; a rejection is logged and the turn goes on | only the final reply is shown |
+
+Each message a surface delivers says who wrote it in `actor`, the `ActorFacts` the identity service resolves: `provider` and `subject`, such as `discord` and the user id, `name`, `roles` written `<surface>:role:<name>` (left out where the surface does not know them, such as a Discord DM, which is not the same as none), and `legacyId`, the speaker id 0.8 gave the person, so someone carried over keeps their principal.
+A surface that leaves `actor` out has it read from `authorId`, `authorName`, and `authorRoleIds` with its prefix as the provider, and the host warns once that this goes away in 1.0.
 
 The host starts each surface as `surface:<prefix>` at the contributing plugin's place in the order, before that plugin's own services.
 It stops surfaces in reverse order, like other services.
@@ -1891,9 +2344,25 @@ The host logs and drops messages whose prefix differs from the delivering surfac
 `context.surfaces` picks the surface by the key's prefix.
 Its `sendReply` rejects with a `PluginError` naming the prefix when no surface serves it.
 `startTyping`, `showStop`, `react`, and `unreact` do nothing when a channel has no surface or its surface omits those methods.
-If `prompts` is unavailable, it returns `undefined` and held actions wait for the owner's next message.
+If `prompts` is unavailable, it returns `undefined` and held actions wait for a message that approves them.
 `of(channel)` returns the surface, or `undefined`.
-The agent server asks the owner for approvals through `context.surfaces.prompts`, so a surface that gives `prompts` gets them in its own channels.
+The runtime asks for approvals through `context.surfaces.prompts`, so a surface that gives `prompts` gets them in its own channels.
+
+#### Who answers a prompt: `PromptScope`
+
+The runtime makes each interactive turn's `PromptScope` from its speaker and its conversation: `principalId` and `speakerId` (the speaker's principal and the identity that spoke), `tier`, and `escalate`.
+A conversation `context.turns` records as `private` gives `escalate: "none"`; a shared one, and a turn that names no conversation, `"owners"`.
+A surface's prompts keep these rules:
+
+- The speaker's principal answers their own question on any of their identities the surface knows, and approves a call when their tier is at least its `minTier` (the owner tier when absent) and, for an owner-tier call, the principal is an owner; a surface that can check their tier again when they answer does.
+- Where the scope escalates to the owners, every owner may answer too, and an approval above the speaker's tier is the owners' alone.
+- Where it escalates to no one, nobody else answers, and an approval above the speaker's tier resolves `expired` at once, shown to no one: the call stays held.
+- Anyone else is refused, even at the same tier as the speaker.
+- Without a scope, as for a turn with no speaker, the prompts are the owners'.
+
+On Discord the owners are every owner with a Discord identity, and the primary owner always; a card in a thread mentions the identity that spoke when it is theirs and one of the principal's Discord identities, every Discord identity of the principal when the speaker is none of them, and the owners when it goes to them, so a single owner's cards read as they did in 0.8.
+A principal with no Discord identity, such as the reporter of a background report, answers nothing there, so their card goes to the owners; so does an owner-tier call of a turn whose tier defaulted to owner when its principal is not an owner.
+The web chat shows prompts to the conversation's person only: its owners are not on it, so an approval above that person's tier expires at once whatever the scope says.
 
 #### Interim text: what a turn writes before its final answer
 
@@ -1919,15 +2388,26 @@ Its plugin adds a claim that answers through `context.surfaces`:
 <!-- example: examples/fake-surface.ts -->
 ```ts
 import {
+	type Approval,
 	type ChannelKey,
 	type ChatSurface,
 	definePlugin,
 	type InboundMessage,
 	type OutboundReply,
-	type OwnerPrompts,
+	type PromptScope,
+	type Prompts,
 	parseChannelKey,
+	TIERS,
 } from "pi-roundtable";
 
+/** A prompt the surface showed, open until someone it is for answers it. */
+interface Asked {
+	id: string;
+	channel: ChannelKey;
+	title: string;
+	open: boolean;
+}
+
 /**
  * A chat surface connects the host to one chat network. This one is an in-memory chat: its
  * channels are the keys that start with `fake:`, and it records what the host asks of it. A real
@@ -1939,7 +2419,12 @@ export class FakeSurface implements ChatSurface {
 	readonly replies: { channel: ChannelKey; reply: OutboundReply }[] = [];
 	readonly typing: string[] = [];
 	readonly stops: string[] = [];
-	readonly asked: string[] = [];
+	readonly asked: Asked[] = [];
+	/** Who may answer each open prompt, and how it settles. */
+	readonly #answering = new Map<
+		string,
+		{ principalId?: string; owners: boolean; settle(answer: Approval): void }
+	>();
 	#deliver: ((message: InboundMessage) => void) | undefined;
 
 	/** The host hands over its router; every message the network reports goes to it. */
@@ -1981,16 +2466,66 @@ export class FakeSurface implements ChatSurface {
 		return () => void this.stops.push(`hide ${channel}`);
 	}
 
-	/** How the owner would approve a held action or answer a question in a turn. */
-	prompts(channel: ChannelKey): OwnerPrompts {
+	/**
+	 * How a turn asks to approve a held action or answers a question. The scope names who may
+	 * answer: its speaker when their tier holds the call, and the owners unless the conversation
+	 * is private, where a call above the speaker's tier goes to no one and expires at once.
+	 */
+	prompts(channel: ChannelKey, scope?: PromptScope): Prompts {
 		return {
-			confirm: async (title) => {
-				this.asked.push(`${channel}: ${title}`);
-				return "approved";
+			confirm: async (title, _message, signal, minTier = "owner") => {
+				const theirs =
+					scope !== undefined &&
+					TIERS.indexOf(scope.tier) >= TIERS.indexOf(minTier);
+				const owners = scope?.escalate !== "none";
+				if (!theirs && !owners) return "expired";
+				return this.#ask(channel, title, signal, {
+					...(theirs ? { principalId: scope.principalId } : {}),
+					owners,
+				});
 			},
 			ask: async () => undefined,
 		};
 	}
+
+	/** Someone answers an open prompt; it settles only when it is theirs to answer. */
+	answer(
+		id: string,
+		who: { principalId: string; owner?: boolean },
+		approved: boolean,
+	): void {
+		const open = this.#answering.get(id);
+		if (!open) return;
+		const theirs = open.principalId === who.principalId;
+		if (theirs || (who.owner && open.owners))
+			open.settle(approved ? "approved" : "declined");
+	}
+
+	#ask(
+		channel: ChannelKey,
+		title: string,
+		signal: AbortSignal | undefined,
+		audience: { principalId?: string; owners: boolean },
+	): Promise<Approval> {
+		const asked = {
+			id: `q${this.asked.length + 1}`,
+			channel,
+			title,
+			open: true,
+		};
+		this.asked.push(asked);
+		return new Promise((resolve) => {
+			const settle = (answer: Approval) => {
+				this.#answering.delete(asked.id);
+				asked.open = false;
+				resolve(answer);
+			};
+			this.#answering.set(asked.id, { ...audience, settle });
+			signal?.addEventListener("abort", () => settle("cancelled"), {
+				once: true,
+			});
+		});
+	}
 }
 
 /**
@@ -2032,6 +2567,155 @@ export function fakeChat(surface: FakeSurface) {
 
 A test boots a host with the plugin, writes through the surface, and reads what came out (`examples/fake-surface.test.ts` does this with `Roundtable` and `silentLogger`, and also covers the refusals above).
 
+### `adapters`: the chat networks the host talks through
+
+`adapters` lists the chat networks the host talks through, each made by its adapter's factory.
+In 0.8 the one adapter is Discord: `discord()` from `pi-roundtable/discord` takes the same settings as the top-level `discord`, and a host configured either way assembles the same plugins in the same order.
+The top-level `discord` stays the form `roundtable init` writes; configure Discord once, in one place or the other.
+A chat network that comes as a plugin, such as pi-roundtable-webchat's `webChat()`, stays in `plugins`.
+
+<!-- example: examples/discord-adapter.ts -->
+```ts
+import type { RoundtableConfig } from "pi-roundtable";
+import { discord } from "pi-roundtable/discord";
+
+/**
+ * Discord as an adapter: `discord()` takes the same settings as the top-level `discord`, and the
+ * host assembles the same plugins in the same order. Configure Discord in one place, not both.
+ */
+export function withDiscordAdapter(
+	env: (name: string) => string,
+	dataDir: string,
+): RoundtableConfig {
+	return {
+		owner: { id: env("OWNER_ID"), name: env("OWNER_NAME") },
+		adapters: [
+			discord({
+				token: env("DISCORD_TOKEN"),
+				guild: env("DISCORD_GUILD_ID"),
+				entryChannel: env("DISCORD_ENTRY_CHANNEL_ID"),
+			}),
+		],
+		database: { url: env("DATABASE_URL") },
+		dataDir,
+		model: env("MODEL"),
+		http: { publicUrl: env("PUBLIC_URL") },
+	};
+}
+```
+<!-- /example -->
+
+`examples/discord-adapter.test.ts` checks that both forms assemble the same plugins.
+`roundtable doctor` reads a Discord adapter's settings as it reads the top-level `discord`.
+The types are `AdapterConfig` and `DiscordConfig` from `pi-roundtable`, and `DiscordAdapterConfig` from `pi-roundtable/discord`.
+
+### A host without Discord
+
+Leave `discord` out of `roundtable.config.ts` and the host runs without it: no Discord plugin, no agent server, no agents, and no skills.
+The runtime plugin still builds the runtime, so every claim that runs turns through `context.turns` works, over the surfaces your plugins bring.
+`http` is optional too; without it the host opens no listener, and a route then names a listener that is not configured.
+
+What needs Discord is refused or left out rather than failing later:
+
+- `agents`, `skills` (anything but `false`), and `ops.agent` are configuration errors. `ops: { conversation: "<surface>:<id>" }` needs a chat surface that serves it and a claim that owns it and takes background turns, or the host does not start. Webchat declares `takesSystemReports: false` and takes no system error reports.
+- `notify` is not registered unless a plugin contributes a [direct channel](#directchannels-reaching-a-person-on-their-own), since there is nowhere to send a notice.
+- `schedule_*` and `delegate_task` are registered only in a conversation whose claim takes background turns: their runs are turns of the [background target](#backgroundtargets-whose-turn-a-schedule-or-delegated-task-is) `PERSONAL_TARGET`, named `owner`, which the core contributes on every host. A conversation of a claim without `background` has neither; a no-surface conversation needs a registered private principal known to a direct channel, as [background targets](#backgroundtargets-whose-turn-a-schedule-or-delegated-task-is) describes.
+- `roundtable doctor` skips the Discord checks.
+
+Pi's runtime still needs the `compact_session` tool in every session, from the Pi package pi-self-compact: load it from a plugin with `piPackages: ["pi-self-compact"]`, as the `plugins/self-compact.ts` of a project `roundtable init` creates does, or the preflight stops the start and says so.
+`roundtable init --adapter web` creates a host without Discord around the [web chat](#web-chat-pi-roundtable-webchat).
+A host that keeps Discord may write it as an adapter instead, as [`adapters`](#adapters-the-chat-networks-the-host-talks-through) describes.
+
+<!-- example: examples/headless.ts -->
+```ts
+import { definePlugin, type RoundtableConfig } from "pi-roundtable";
+import type { FakeSurface } from "./fake-surface.ts";
+import { studyRoom } from "./study-room.ts";
+
+/** A plugin that brings a chat network and nothing else; the study room's claim answers its rooms. */
+export function chatNetwork(surface: FakeSurface) {
+	return definePlugin({
+		name: "chat-network",
+		setup: () => ({ surfaces: [surface] }),
+	});
+}
+
+/**
+ * A host without Discord: no `discord` key, so no Discord plugin, no agent server, no agents and
+ * no skills; and no `http`, so no listener opens until a plugin needs one. Conversations come
+ * through the plugins' own chat surfaces, and `context.turns` runs them on the host's runtime,
+ * Pi's unless a plugin fills the `runtime` slot.
+ */
+export function studyHall(
+	surface: FakeSurface,
+	where: { databaseUrl: string; dataDir: string },
+): RoundtableConfig {
+	return {
+		name: "Study Hall",
+		access: {
+			owners: [{ principal: "owner", name: "Ada" }],
+			// Admit the fake surface's authors explicitly, not in the claim.
+			members: { everyone: ["fake"] },
+		},
+		database: { url: where.databaseUrl },
+		dataDir: where.dataDir,
+		model: "anthropic/claude-sonnet-5-5",
+		plugins: [chatNetwork(surface), studyRoom],
+	};
+}
+```
+<!-- /example -->
+
+`examples/headless.test.ts` boots this configuration over PostgreSQL with the echo runtime in place of Pi, and a study room answers through the fake surface.
+`testHost({ discord: false })` boots the same kind of host for a plugin's tests.
+
+### Web chat: pi-roundtable-webchat
+
+[pi-roundtable-webchat][webchat-package] is a chat network that comes as a plugin.
+`webChat({ verifier, personas, origins })` adds a chat surface whose conversations have keys `web:<conversation>`, the claim that runs each message as a turn of its conversation's persona through `context.turns`, and a REST API and a WebSocket under `/chat` on the host's `public` listener.
+People an OpenID Connect provider signs in open private conversations, see each turn's text and tools as it runs, and answer its approval cards.
+It needs no Discord: a host whose configuration has no `discord` and lists `webChat(...)` in `plugins` is a web-only assistant.
+
+#### `roundtable init --adapter web`
+
+`roundtable init --adapter web` writes a project without Discord around it: no `agents.ts` and no shared persona, a `roundtable.config.ts` that lists `webChat(...)` with an `oidcJwtVerifier`, an access map whose members and admins come from the token's roles, in top-level `access`, and one persona, `assistant`, whose prompt is `persona/assistant.md`.
+The persona's `selection` names its tools (the hello plugin's), so tools a later plugin adds, such as pi-web-access's, stay out until you add them by name.
+`package.json` pins pi-roundtable-webchat at the core's version and pi-self-compact, and `.env.example` asks for `OWNER_NAME`, `DATABASE_URL`, `MODEL`, `OIDC_ISSUER`, `OIDC_AUDIENCE`, `OIDC_JWKS_URL`, `CHAT_MEMBER_ROLES`, and `CHAT_ORIGINS`, with no Discord variable.
+The host listens on `127.0.0.1:3000`; serve it over HTTPS through a reverse proxy.
+`--adapter discord` is the default and writes the Discord project.
+
+#### Protocol
+
+A browser asks for a one-time ticket with `POST /chat/tickets` and `Authorization: Bearer <token>`, then opens `/chat/socket` offering the subprotocols `roundtable.webchat.v1` and `ticket.<ticket>`; another client sends the bearer token on the upgrade.
+The token never travels in a URL.
+Each WebSocket message is one JSON object with a `type`: the client sends `send`, `stop`, `approval`, `answer`, and `auth`; the server answers with `ready`, `accepted`, `typing`, `stoppable`, `progress`, `reply`, `failed`, `prompt`, `prompt_closed`, `notice`, `reauth`, and `error`.
+`progress` carries the turn's [`TurnProgress`](#surfaces-a-chat-network-of-your-own) events, never the thinking and never a tool's full arguments; `reply` carries the answer in full markdown.
+The REST API lists a person's conversations, opens one, reads its messages, and lists and acknowledges private inbox notices from `notify`.
+Tickets, quotas, connections, and approvals follow `principalId`; refreshing a token to another principal closes the socket with 4403.
+The package README documents every frame, error code, close code, and limit.
+
+#### Security model
+
+- A conversation belongs to the person who opened it: the claim checks the [conversation registry](#services-what-plugins-provide-to-each-other) inside the conversation's queue before every turn, and only that person may list, read, write in, stop, or answer it.
+- Tokens are checked on every REST call, every upgrade, and every `auth` frame. By default only a person's access token passes: a token without a scope or app roles, or an app-only token, is refused. A socket closes when its token expires.
+- `origins` is required, and checked on every upgrade and every browser request.
+- Each person has bounded sockets, tickets, conversations opened per hour, and turns running or queued at once; frames are bounded in size and rate.
+- An approval card goes to the conversation's person only, at the tier the held call needs.
+- No token claim makes anyone the owner; list their linked identity in top-level `access.owners` or grant a lasting role through the CLI.
+- The old webchat `access` option is removed; prefix roles as `<surface>:role:<name>` and scope old `everyone: true` to `everyone: ["<surface>"]`.
+
+#### Provider settings
+
+The verifier is generic; what makes it safe is how it is pointed at your provider.
+The README's [provider settings][webchat-provider-settings] explain, with Microsoft Entra ID as the example, why to name people by a claim that stays the same across app registrations (`subjectClaim`), pin the tenant in `check`, accept access tokens only, refuse app-only tokens, merge issuers of one tenant only (`speakerIssuer`), and mind the guests `everyone` admits.
+
+The web chat takes no attachments or system error reports (`takesSystemReports: false`), so `ops.conversation` cannot name it.
+It accepts `PERSONAL_TARGET` background turns only for the private conversation's principal; include `schedule_*`, `delegate_task`, and `notify` in a persona's selection only deliberately, adjusting their tiers if needed.
+Leave out `web_search` and `fetch_content` unless people may make the host fetch any address, internal ones included.
+
+[webchat-package]: https://github.com/wayne930242/pi-roundtable/blob/master/packages/webchat/README.md
+[webchat-provider-settings]: https://github.com/wayne930242/pi-roundtable/blob/master/packages/webchat/README.md#provider-settings
+
 ### What plugins do not extend
 
 A plugin adds slash commands through the Discord plugin's registrar and never receives the composed commands (see [slash commands](#slash-commands-commandsadd)).
@@ -2058,10 +2742,9 @@ Inspect the ready-made implementations in the [codex-images][codex-images-templa
 
 The [pi-roundtable-mcp][mcp-package] workspace, published separately on npm, adds two more plugins, `mcpConnectors` and `remoteMcp`.
 The first lets the owner add MCP servers such as Notion or a calendar from Discord and gives your code the list; the second lets an agent outside Discord reach your agent.
-Install it with `bun add pi-roundtable-mcp` after the next lockstep release publishes the migrated package.
-Until then, npm's MCP 0.4.1 requires core below 0.6.0 and is not compatible with core 0.7.x.
+Install it with `bun add pi-roundtable-mcp`.
 
-Five official packages live in this repository as Bun workspaces and publish as separate npm packages, versioned in lockstep with the core.
+Six official packages live in this repository as Bun workspaces and publish as separate npm packages, versioned in lockstep with the core.
 The [site guide source files][package-guides] describe installation, requirements, configuration, and security considerations:
 
 - [pi-roundtable-drawing][drawing-package]: [site guide source][drawing-guide] · local relationship maps, magic circles, sigils, sacred geometry, and card spreads.
@@ -2069,6 +2752,7 @@ The [site guide source files][package-guides] describe installation, requirement
 - [pi-roundtable-web][web-package]: [site guide source][web-guide] · an owner-only console for conversations, transcripts, and memory notes with live updates.
 - [pi-roundtable-sandbox][sandbox-package]: [site guide source][sandbox-guide] · sealed guest channels on native Linux Docker with a host-only credential broker and allow-listed tools.
 - [pi-roundtable-mcp][mcp-package]: [site guide source][mcp-guide] · MCP connectors through a gateway and remote MCP endpoints for agent turns and owner-granted Discord channel tools.
+- [pi-roundtable-webchat][webchat-package]: [site guide source][webchat-guide] · a WebSocket chat for people an OpenID Connect provider signs in, with private conversations, live progress, and approval cards; see [web chat](#web-chat-pi-roundtable-webchat).
 
 [drawing-package]: https://github.com/wayne930242/pi-roundtable/blob/master/packages/drawing/README.md
 [coding-package]: https://github.com/wayne930242/pi-roundtable/blob/master/packages/coding/README.md
@@ -2081,6 +2765,7 @@ The [site guide source files][package-guides] describe installation, requirement
 [web-guide]: https://github.com/wayne930242/pi-roundtable/blob/master/site/src/content/docs/plugins/web-package.mdx
 [sandbox-guide]: https://github.com/wayne930242/pi-roundtable/blob/master/site/src/content/docs/plugins/sandbox-package.mdx
 [mcp-guide]: https://github.com/wayne930242/pi-roundtable/blob/master/site/src/content/docs/plugins/mcp-package.mdx
+[webchat-guide]: https://github.com/wayne930242/pi-roundtable/blob/master/site/src/content/docs/plugins/webchat-package.mdx
 [coding-source]: https://github.com/wayne930242/pi-roundtable/tree/master/packages/coding
 [sandbox-source]: https://github.com/wayne930242/pi-roundtable/tree/master/packages/sandbox
 [web-source]: https://github.com/wayne930242/pi-roundtable/tree/master/packages/web
@@ -2141,6 +2826,8 @@ Use `testPlugin(plugin, options?)` for most tests; it sets up one plugin against
 Use [`testHost`](#testhost-the-built-in-plugins-and-yours-over-postgresql) for tests that depend on built-in plugins or the host's setup order; it boots them alongside yours over PostgreSQL.
 
 `testPlugin` sets one plugin up against a fake context and starts its services, with no Discord and no PostgreSQL unless you pass `{ database }`.
+It resolves only its default owner unless you inject `servicePair(IDENTITY, { resolve })` for your test's actors; do not invent a speaker in a claim to bypass admission.
+The [principals example](#principals-and-access) injects only the read method it exercises, and the study-room example tests router-resolved attribution and refusal.
 It returns:
 
 | Field | What it is |
@@ -2170,7 +2857,7 @@ After setup, `conversations` routes to the plugin's claims, `surfaces` contains
 | `database` | A Bun `SQL` for `context.database()`; without one it throws `no database is configured` |
 | `providers` | Provider slots filled as if another plugin filled them |
 | `surfaces` | Chat surfaces besides the plugin's own, such as the fake surface of `examples/fake-surface.ts`: they are in `context.surfaces`, start after the plugin's services with the harness routing their messages to `conversations`, and stop with `stop()` |
-| `services` | What the plugin reads from `context.services`: one `servicePair(KEY, { ... })` for each service, with the members you give it. `servicePair(AGENTS, { runtime })` is the runtime `context.turns` runs on. Reading a member you did not give throws a `PluginError` that names the option to add; a service you did not give reads as absent to `find`, and `get` says to give it, except for the ones below |
+| `services` | What the plugin reads from `context.services`: one `servicePair(KEY, { ... })` for each service, with the members you give it. `servicePair(RUNTIME, runtime)` is the runtime `context.turns` runs on, given whole; `servicePair(AGENTS, { runtime })` also works when no `RUNTIME` is given. Reading a member you did not give throws a `PluginError` that names the option to add; a service you did not give reads as absent to `find`, and `get` says to give it, except for the ones below |
 | `conversations` | Methods that replace the router's, such as `stop`, for a plugin that calls them |
 | `turns` | A `ConversationTurns` that replaces the default one |
 | `apiKeys` | The credentials `context.apiKey(provider)` returns, by provider name: `{ "openai-codex": "key" }`. A provider not listed reads as having none, as on a host that is not logged in |
@@ -2200,7 +2887,12 @@ import { notes } from "./tools.ts";
 
 test("note_add saves a note for the speaker and refuses an empty one", async () => {
 	const harness = await testPlugin(notes);
-	const ada: Speaker = { id: "1", name: "Ada", tier: "member" };
+	const ada: Speaker = {
+		id: "1",
+		name: "Ada",
+		tier: "member",
+		principalId: "1",
+	};
 	expect(harness.tools).toEqual(["note_add"]);
 	expect(harness.tiers.minTier("note_add")).toBe("member");
 	expect(
@@ -2232,14 +2924,14 @@ Use `partial<Port>({ ... })` to stand in for a port your code takes as an argume
 It provides the members you give it and throws an error naming any missing member you read, so the test needs no `as unknown as Port` cast.
 `fakePrecheck(name, answer, { description?, timeoutMs? })` is a precheck that answers `answer` (a `PrecheckResult`, an `Error` it throws, or a function of its context) and records each context in `calls`; `fakePrechecks(...prechecks)` is a real in-memory `PrecheckRegistry` with them registered, which a test gives a plugin as `servicePair(PRECHECKS, registry)` and reads back with `registry.get(name)`.
 `fakeScriptRunner(answer, { describe?, timeoutMs? })` is a `PrecheckScriptRunner` that runs nothing and answers `answer` (a result, an `Error` it throws, or a function of the script and its context), recording each call in `calls`; give it to `registry.useScriptRunner`.
-`fakeDiscord({ ownerId?, rootCommand? })` is the `DISCORD` service for a plugin that adds slash commands: give it as `services: [discord.service]`, read what the plugin added with `discord.added()`, and compose the tree Discord would get with `discord.compose()`.
+`fakeDiscord({ ownerId?, rootCommand?, channelContext? })` is the `DISCORD` service for a plugin that adds slash commands or reads channel context: give it as `services: [discord.service]`, read what the plugin added with `discord.added()`, and compose the tree Discord would get with `discord.compose()`; `channelContext` answers `DISCORD.channelContext`, by default with no context.
 Only `commands` and `guard` are given; a plugin that reads another member of `DISCORD` in a test gives its own with `servicePair(DISCORD, { ... })`.
 
 ### `testHost`: the built-in plugins and yours, over PostgreSQL
 
 `testPlugin` sets up your plugin alone.
 For tests that need the agent server, modules, stores, or the host's session-tool setup order, use `testHost(options?)`.
-It boots `defineRoundtable` over `ROUNDTABLE_TEST_DATABASE_URL`, with stand-ins for Discord and the runtime; gate the suite with `describeDb`:
+It boots `defineRoundtable` over `ROUNDTABLE_TEST_DATABASE_URL`, with stand-ins for Discord and the runtime, or without Discord; gate the suite with `describeDb`:
 
 | Option | What it gives the host |
 |---|---|
@@ -2247,7 +2939,7 @@ It boots `defineRoundtable` over `ROUNDTABLE_TEST_DATABASE_URL`, with stand-ins
 | `plugins` | Your plugins, placed after the built-in ones as `defineRoundtable` places them |
 | `runtime` | The runtime every turn runs on; by default one that answers `""` and builds no Pi session |
 | `apiKeys` | The credentials `context.apiKey(provider)` returns, by provider name; a provider not listed reads as having none, whatever login the machine holds |
-| `discord` | What the stand-in Discord hands out: `agentChannels(guildId)` and `ownerChannel()` |
+| `discord` | What the stand-in Discord hands out: `agentChannels(guildId)` and `ownerChannel()`; `false` boots a [host without Discord](#a-host-without-discord), with no `discord`, `http`, or `agents` in the test configuration |
 
 It returns:
 
@@ -2266,6 +2958,15 @@ It returns:
 
 `holdChain(rules)` is in `pi-roundtable/kit`: the chain the host links from every plugin's hold rules, to test a rule set without a harness.
 
+### `describeSurfaceContract`: what every chat surface keeps
+
+A plugin that contributes a `ChatSurface` can test it against the contract every surface keeps.
+`describeSurfaceContract(name, make)` registers one test per check, each on a fresh `SurfaceContractSubject` from `make`: the `surface`, a `channel` of it, and one person on its network, who can `write(text)`, whose `observations()` list what they have seen (`SurfaceObservation`: a reply's text and file names, typing and stop controls going on and off, progress, and prompts opening and closing), and who may `answer(prompt, approved)` an approval; `speaker` is who they are to `surface.prompts`, given as `promptScope(speaker, visibility)`, an owner by default, and every approval the contract asks for needs exactly their tier. `stranger`, when given, is someone else on the network, another principal and not an owner, who knows the id of the person's open approval and may `join()` and `answer(prompt, approved)` it; `owner`, when given, is an owner on the network, another principal than the person, who does the same in the person's private conversation. Both are `SurfaceContractAnswerer`s.
+The contract starts the surface, calls the subject's `join()`, and stops the surface after the subject's `close()`.
+It checks that the surface names a prefix and owns its channel, delivers what the person writes, and shows every chunk of a reply; and, for the parts the surface offers, that it delivers files when `supportsFiles` is set, ends typing and stop controls idempotently, shows progress, and resolves an approval as the person approves or declines it, or `cancelled` when the turn stops, with a `stranger`, that the stranger's answer leaves the person's approval open, and with an `owner`, that an owner's answer leaves it open in a private conversation; and, for a speaker below the owner tier, that a private conversation's approval above their tier resolves `expired` at once and is not shown.
+A check for a part the surface does not offer passes.
+`checkSurfaceContract(make)` runs the same checks and returns the ones that failed, as `SurfaceContractFailure`s.
+
 ## What happens when the bot starts and stops
 
 `roundtable start` checks Bun, `.env`, the configuration, the plugins, the model login, and the public URL without using the network.
@@ -2274,10 +2975,10 @@ The host's `run()` handles startup:
 
 1. Each plugin's `replaces` is applied: the plugin that provided a replaced service is dropped, and the replacement stands where it stood.
    Providers are then resolved: each slot from the plugin that fills it, or the core's default.
-   The agent server builds its runtime later, in its own setup: from the `runtime` slot when a plugin fills it, else the Pi runtime.
+   The runtime plugin builds the runtime later, in its own setup: from the `runtime` slot when a plugin fills it, else the Pi runtime.
 2. The database is opened and every plugin's migrations run, in plugin order.
 3. Every plugin's `setup` runs, in plugin order.
-   The order is the built-ins (`memory`, `schedule-store`, `discord`, `modules`, `discord-admin`, `skills`, `agent-server`, `seeds`; an addon that is switched off is not there), then yours in the order of `plugins` in `roundtable.config.ts`, then the built-in `schedules`, so a due schedule fires only once everything it can reach is running.
+   The order is the built-ins (`memory`, `schedule-store`, `prechecks`, `discord`, `modules`, `discord-admin`, `skills`, `conversations`, `runtime`, `agent-server`, `seeds`; an addon that is switched off is not there, and without Discord neither are `discord`, `discord-admin`, `skills`, `agent-server`, or `seeds`), then yours in the order of `plugins` in `roundtable.config.ts`, then the built-in `schedules`, so a due schedule fires only once everything it can reach is running.
 4. The contributions are linked: tool tiers, hold rules, the session plan, the channel router, and the events.
    From here `sessions()`, `conversations`, `surfaces`, `turns`, and `dashboard()` work.
 5. Every plugin's `preflight` runs, in plugin order.
@@ -2324,7 +3025,7 @@ These are the messages as the code writes them, with `<...>` where your names go
 | `plugin <name>: setup is missing. Give the function that returns what the plugin adds.` | Add `setup` |
 | `plugin <name> adds nothing. Give it a part (tools, services, channels, and so on), a migration, or a provider, or remove it.` | Return a part from `setup`, or remove the plugin from `roundtable.config.ts` |
 | `plugin <name>: setup must return an object of the parts it adds; return {} to add none.` | Return an object, not `undefined` |
-| `plugin <name>: setup returned an unknown part "<key>". Did you mean "<closest>"? The parts are services, events, http, holdRules, piPackages, sessionTools, channels, surfaces, personas, backgroundTargets, dashboard, tools, seeds, prompt, agentSelection, requiredTools.` | Fix the key; `migrations`, `providers`, and `preflight` belong on the plugin, not in what `setup` returns |
+| `plugin <name>: setup returned an unknown part "<key>". Did you mean "<closest>"? The parts are services, events, http, holdRules, piPackages, sessionTools, channels, surfaces, personas, backgroundTargets, directChannels, dashboard, tools, seeds, prompt, agentSelection, requiredTools.` | Fix the key; `migrations`, `providers`, and `preflight` belong on the plugin, not in what `setup` returns |
 
 ### Tools
 
@@ -2357,9 +3058,9 @@ These are the messages as the code writes them, with `<...>` where your names go
 | `plugin <b>: background target "<name>" is already registered by plugin <a>. Keep one target per name.` | Give each background target one plugin, or rename one of them |
 | `no plugin contributes the background target "<name>"` (a schedule's last status, or a skipped turn) | Contribute the target from the plugin whose claim serves it, or cancel the schedule |
 | `no persona is registered for the conversation kind "<kind>". A plugin adds one with personas: [...], or its claim must start conversations of a kind that has one.` (a failed turn) | Contribute a persona of that kind, or run the turn with a kind that has one |
-| `no runtime provider is configured: the agent server builds the Pi runtime when no plugin fills the runtime slot` | Only a plugin that calls `providers.runtime` without `providers.filled.has("runtime")` sees it; check `filled` first |
+| `no runtime provider is configured: the runtime plugin builds the Pi runtime when no plugin fills the runtime slot; read the running one from services.get(RUNTIME)` | Only a plugin that calls `providers.runtime` without `providers.filled.has("runtime")` sees it; read `services.get(RUNTIME)` instead |
 | `session tool <name> takes a core extension name. Rename it.` | Pick a name other than the core's |
-| `two plugins are named <name>.` (from `roundtable doctor`) | Rename yours; the built-in plugins are `memory`, `schedule-store`, `discord`, `modules`, `discord-admin`, `skills`, `agent-server`, `seeds`, and `schedules` |
+| `two plugins are named <name>.` (from `roundtable doctor`) | Rename yours; the built-in plugins are `memory`, `schedule-store`, `prechecks`, `discord`, `modules`, `discord-admin`, `skills`, `conversations`, `runtime`, `agent-server`, `seeds`, and `schedules` |
 | `migration <plugin>/<name> is declared twice` | A plugin declares two migrations with one name: rename one (the same name in two plugins is fine) |
 | `/<root> <name> is added twice`, `/<name> is registered twice` | Give each slash command and subcommand its own name |
 | `route <name> is registered twice`, `routes <a> and <b> overlap on listener <id>` | Give each route its own name and a path no other route can take |
@@ -2405,6 +3106,9 @@ Migrations are idempotent, so start again once the cause is fixed.
 | `config model: expected <provider>/<id>, got "<value>". Write it like anthropic/claude-sonnet-5-5.` | Write the model as `<provider>/<id>` |
 | `config locale: expected a locale, en or zh-TW, got "<value>". Fix the value in roundtable.config.ts.` | Use `en` or `zh-TW` |
 | `config <key>: cannot read <path>: <reason>. Create the file or fix the path.` | Create the prompt file, or fix the path in `prompts` |
+| `config adapters[<n>]: unknown adapter "<name>". The adapters are discord; …` | Use `discord()` from `pi-roundtable/discord`; a chat network that comes as a plugin, such as `webChat()`, belongs in `plugins` |
+| `config adapters[<n>]: Discord is configured twice, …` | Keep the top-level `discord` or the Discord adapter, not both |
+| `required tools are not registered: compact_session. compact_session comes from the Pi package pi-self-compact: …` | `bun add pi-self-compact`, and load it from a plugin with `piPackages: ["pi-self-compact"]`, as a project `roundtable init` creates does in `plugins/self-compact.ts` |
 
 ### Missing settings
 
@@ -2484,10 +3188,18 @@ Import from the entries listed below; source area files are internal.
 
 | Name | Entry | Kind |
 |---|---|---|
+| `AccessConfig` | `pi-roundtable` | type |
+| `AccessOwner` | `pi-roundtable` | type |
+| `AccessOwnerConfig` | `pi-roundtable` | type |
+| `AccessRules` | `pi-roundtable` | type |
+| `AccessTier` | `pi-roundtable` | type |
+| `AccessTierConfig` | `pi-roundtable` | type |
+| `ActorFacts` | `pi-roundtable` | type |
 | `AGENTS` | `pi-roundtable` | value |
 | `AGENT_SERVER_PLUGIN` | `pi-roundtable` | value |
 | `AGENT_SERVER_PRIORITY` | `pi-roundtable` | value |
 | `AGENT_TEAM_SERVICE` | `pi-roundtable` | value |
+| `AdapterConfig` | `pi-roundtable` | type |
 | `Admission` | `pi-roundtable` | type |
 | `Agent` | `pi-roundtable` | type |
 | `AgentChange` | `pi-roundtable` | type |
@@ -2508,6 +3220,9 @@ Import from the entries listed below; source area files are internal.
 | `AvatarMode` | `pi-roundtable` | type |
 | `AvatarStudio` | `pi-roundtable` | type |
 | `BACKGROUND_TURNS` | `pi-roundtable` | value |
+| `CONVERSATIONS` | `pi-roundtable` | value |
+| `BackgroundConfig` | `pi-roundtable` | type |
+| `BackgroundRunsAs` | `pi-roundtable` | type |
 | `BackgroundTarget` | `pi-roundtable` | type |
 | `BackgroundTurn` | `pi-roundtable` | type |
 | `BackgroundTurns` | `pi-roundtable` | type |
@@ -2519,16 +3234,24 @@ Import from the entries listed below; source area files are internal.
 | `Contribution` | `pi-roundtable` | type |
 | `ConversationKind` | `pi-roundtable` | type |
 | `ConversationPort` | `pi-roundtable` | type |
+| `ConversationRecord` | `pi-roundtable` | type |
+| `ConversationRegistration` | `pi-roundtable` | type |
+| `ConversationRegistry` | `pi-roundtable` | type |
+| `ConversationVisibility` | `pi-roundtable` | type |
 | `ConversationTurnInput` | `pi-roundtable` | type |
 | `ConversationTurns` | `pi-roundtable` | type |
 | `DELEGATION` | `pi-roundtable` | value |
 | `DefineOverrides` | `pi-roundtable` | type |
+| `DirectChannelProvider` | `pi-roundtable` | type |
+| `DirectChannels` | `pi-roundtable` | type |
+| `DirectReach` | `pi-roundtable` | type |
 | `DefinedRoundtable` | `pi-roundtable` | type |
 | `DelegationError` | `pi-roundtable` | value |
 | `DelegationJob` | `pi-roundtable` | type |
 | `DelegationOutcome` | `pi-roundtable` | type |
 | `DelegationRequest` | `pi-roundtable` | type |
 | `Delegator` | `pi-roundtable` | type |
+| `DiscordConfig` | `pi-roundtable` | type |
 | `DrainOptions` | `pi-roundtable` | type |
 | `EventHandlers` | `pi-roundtable` | type |
 | `EventSink` | `pi-roundtable` | type |
@@ -2541,6 +3264,11 @@ Import from the entries listed below; source area files are internal.
 | `HostEnv` | `pi-roundtable` | type |
 | `HostEnvironment` | `pi-roundtable` | type |
 | `HttpRoute` | `pi-roundtable` | type |
+| `IDENTITY` | `pi-roundtable` | value |
+| `IdentityError` | `pi-roundtable` | value |
+| `IdentityLink` | `pi-roundtable` | type |
+| `IdentityRef` | `pi-roundtable` | type |
+| `IdentityService` | `pi-roundtable` | type |
 | `ImageDrawer` | `pi-roundtable` | type |
 | `InboundMessage` | `pi-roundtable` | type |
 | `InterimMessage` | `pi-roundtable` | type |
@@ -2550,6 +3278,7 @@ Import from the entries listed below; source area files are internal.
 | `JudgeError` | `pi-roundtable` | value |
 | `JudgeModel` | `pi-roundtable` | type |
 | `LinkedSessions` | `pi-roundtable` | type |
+| `LinkSource` | `pi-roundtable` | type |
 | `ListenerAddress` | `pi-roundtable` | type |
 | `ListenerConfig` | `pi-roundtable` | type |
 | `LoadedSkill` | `pi-roundtable` | type |
@@ -2571,17 +3300,23 @@ Import from the entries listed below; source area files are internal.
 | `NewSchedule` | `pi-roundtable` | type |
 | `NotLinkedError` | `pi-roundtable` | value |
 | `OWNER_TARGET` | `pi-roundtable` | value |
+| `PERSONAL_TARGET` | `pi-roundtable` | value |
 | `OutboundReply` | `pi-roundtable` | type |
 | `OwnerAnswer` | `pi-roundtable` | type |
 | `OwnerPrompts` | `pi-roundtable` | type |
 | `OwnerQuestion` | `pi-roundtable` | type |
 | `PendingConfirmation` | `pi-roundtable` | type |
+| `PerPrincipalLimits` | `pi-roundtable` | type |
 | `Persona` | `pi-roundtable` | type |
 | `PluginContext` | `pi-roundtable` | type |
+| `PluginIdentity` | `pi-roundtable` | type |
 | `PluginError` | `pi-roundtable` | value |
+| `Principal` | `pi-roundtable` | type |
 | `PromptMemory` | `pi-roundtable` | type |
+| `PromptScope` | `pi-roundtable` | type |
 | `PromptSection` | `pi-roundtable` | type |
 | `PromptTurn` | `pi-roundtable` | type |
+| `Prompts` | `pi-roundtable` | type |
 | `Pronouns` | `pi-roundtable` | type |
 | `ProviderError` | `pi-roundtable` | value |
 | `Providers` | `pi-roundtable` | type |
@@ -2590,6 +3325,8 @@ Import from the entries listed below; source area files are internal.
 | `ReferenceImage` | `pi-roundtable` | type |
 | `ResolvedProviders` | `pi-roundtable` | type |
 | `ResolvedSkill` | `pi-roundtable` | type |
+| `RoleGrant` | `pi-roundtable` | type |
+| `RoleSource` | `pi-roundtable` | type |
 | `Roundtable` | `pi-roundtable` | value |
 | `ReplyFile` | `pi-roundtable` | type |
 | `ReplyFileError` | `pi-roundtable` | value |
@@ -2597,10 +3334,12 @@ Import from the entries listed below; source area files are internal.
 | `RoundtableConfig` | `pi-roundtable` | type |
 | `RoundtableOptions` | `pi-roundtable` | type |
 | `RoundtablePlugin` | `pi-roundtable` | type |
+| `RouteSocket` | `pi-roundtable` | type |
 | `RuntimeDeps` | `pi-roundtable` | type |
 | `RuntimeFactory` | `pi-roundtable` | type |
 | `SCHEDULES` | `pi-roundtable` | value |
 | `PRECHECKS` | `pi-roundtable` | value |
+| `RUNTIME` | `pi-roundtable` | value |
 | `PRECHECK_TIMEOUT_MS` | `pi-roundtable` | value |
 | `Precheck` | `pi-roundtable` | type |
 | `PrecheckContext` | `pi-roundtable` | type |
@@ -2624,6 +3363,7 @@ Import from the entries listed below; source area files are internal.
 | `ServiceStartedEvent` | `pi-roundtable` | type |
 | `Services` | `pi-roundtable` | type |
 | `SessionContext` | `pi-roundtable` | type |
+| `SessionConversation` | `pi-roundtable` | type |
 | `SessionPlan` | `pi-roundtable` | type |
 | `SessionTool` | `pi-roundtable` | type |
 | `SessionToolSnapshot` | `pi-roundtable` | type |
@@ -2635,6 +3375,7 @@ Import from the entries listed below; source area files are internal.
 | `SpeakerMemory` | `pi-roundtable` | type |
 | `StoredAttachment` | `pi-roundtable` | type |
 | `SurfacePort` | `pi-roundtable` | type |
+| `SYSTEM_PRINCIPAL` | `pi-roundtable` | value |
 | `THE_SPEAKER` | `pi-roundtable` | value |
 | `TIERS` | `pi-roundtable` | value |
 | `TeamAgentStatus` | `pi-roundtable` | type |
@@ -2653,13 +3394,20 @@ Import from the entries listed below; source area files are internal.
 | `TranscriptEntry` | `pi-roundtable` | type |
 | `TransientTask` | `pi-roundtable` | type |
 | `TurnAttachments` | `pi-roundtable` | type |
+| `TurnConversation` | `pi-roundtable` | type |
 | `TurnEndEvent` | `pi-roundtable` | type |
+| `TurnProgress` | `pi-roundtable` | type |
+| `TurnProgressEvent` | `pi-roundtable` | type |
 | `TurnEvent` | `pi-roundtable` | type |
 | `TurnRequest` | `pi-roundtable` | type |
 | `TurnResult` | `pi-roundtable` | type |
 | `TurnSelection` | `pi-roundtable` | type |
+| `WebSocketAccept` | `pi-roundtable` | type |
+| `WebSocketRoute` | `pi-roundtable` | type |
+| `WebSocketSendResult` | `pi-roundtable` | type |
 | `Weekday` | `pi-roundtable` | type |
 | `attachReplyFile` | `pi-roundtable` | value |
+| `promptScope` | `pi-roundtable` | value |
 | `withReplyFiles` | `pi-roundtable` | value |
 | `prepareImageBytes` | `pi-roundtable/kit` | value |
 | `ImagePreparationError` | `pi-roundtable/kit` | value |
@@ -2676,6 +3424,7 @@ Import from the entries listed below; source area files are internal.
 | `OWNER_SPEAKER` | `pi-roundtable/testing` | value |
 | `RecordedEvent` | `pi-roundtable/testing` | type |
 | `ServicePair` | `pi-roundtable/testing` | type |
+| `SurfaceContractAnswerer` | `pi-roundtable/testing` | type |
 | `TEST_GUILD` | `pi-roundtable/testing` | value |
 | `TestHost` | `pi-roundtable/testing` | type |
 | `TestHostOptions` | `pi-roundtable/testing` | type |
@@ -2684,6 +3433,11 @@ Import from the entries listed below; source area files are internal.
 | `TestPluginResult` | `pi-roundtable/testing` | type |
 | `TestStore` | `pi-roundtable/testing` | type |
 | `describeDb` | `pi-roundtable/testing` | value |
+| `describeSurfaceContract` | `pi-roundtable/testing` | value |
+| `checkSurfaceContract` | `pi-roundtable/testing` | value |
+| `SurfaceContractFailure` | `pi-roundtable/testing` | type |
+| `SurfaceContractSubject` | `pi-roundtable/testing` | type |
+| `SurfaceObservation` | `pi-roundtable/testing` | type |
 | `eagerText` | `pi-roundtable/testing` | value |
 | `fakeDiscord` | `pi-roundtable/testing` | value |
 | `fakePrecheck` | `pi-roundtable/testing` | value |
@@ -2738,6 +3492,7 @@ Import from the entries listed below; source area files are internal.
 | `McpEndpoint` | `pi-roundtable/kit` | type |
 | `ModelRef` | `pi-roundtable/kit` | type |
 | `OwnerIdentity` | `pi-roundtable/kit` | type |
+| `Notifier` | `pi-roundtable/kit` | type |
 | `OwnerNotifier` | `pi-roundtable/kit` | type |
 | `PreviousTurn` | `pi-roundtable/kit` | type |
 | `PromptSlot` | `pi-roundtable/kit` | type |
@@ -2780,6 +3535,15 @@ Import from the entries listed below; source area files are internal.
 | `compactionEngine` | `pi-roundtable/kit` | value |
 | `HARD_COMPACT_TOKENS` | `pi-roundtable/kit` | value |
 | `SOFT_COMPACT_TOKENS` | `pi-roundtable/kit` | value |
+| `summaryProjection` | `pi-roundtable/kit` | value |
+| `privateCompaction` | `pi-roundtable/kit` | value |
+| `memoryProjection` | `pi-roundtable/kit` | value |
+| `hidesPrivateExchange` | `pi-roundtable/kit` | value |
+| `MemoryView` | `pi-roundtable/kit` | type |
+| `MEMORY_TURN_ENTRY` | `pi-roundtable/kit` | value |
+| `recordMemoryTurn` | `pi-roundtable/kit` | value |
+| `carriesMemory` | `pi-roundtable/kit` | value |
+| `bridgeHistoryHidesMemory` | `pi-roundtable/kit` | value |
 | `CompactionEngine` | `pi-roundtable/kit` | type |
 | `CompactionHistory` | `pi-roundtable/kit` | type |
 | `LatestCompaction` | `pi-roundtable/kit` | type |
@@ -2830,8 +3594,12 @@ Import from the entries listed below; source area files are internal.
 | `AgentPanel` | `pi-roundtable/discord` | type |
 | `AgentPanelMessage` | `pi-roundtable/discord` | type |
 | `AgentPanelOptions` | `pi-roundtable/discord` | type |
+| `CHANNEL_CONTEXT_DEFAULTS` | `pi-roundtable/discord` | value |
 | `CHANNEL_OPERATIONS` | `pi-roundtable/discord` | value |
 | `CHANNEL_TOOLS` | `pi-roundtable/discord` | value |
+| `ChannelContext` | `pi-roundtable/discord` | type |
+| `ChannelContextMessage` | `pi-roundtable/discord` | type |
+| `ChannelContextOptions` | `pi-roundtable/discord` | type |
 | `ChannelExecutor` | `pi-roundtable/discord` | type |
 | `ChannelInfo` | `pi-roundtable/discord` | type |
 | `ChannelOperation` | `pi-roundtable/discord` | type |
@@ -2844,6 +3612,8 @@ Import from the entries listed below; source area files are internal.
 | `ComposedCommands` | `pi-roundtable/discord` | type |
 | `DISCORD` | `pi-roundtable/discord` | value |
 | `DISCORD_ADMIN_TOOLS` | `pi-roundtable/discord` | value |
+| `DiscordActor` | `pi-roundtable/discord` | type |
+| `DiscordAdapterConfig` | `pi-roundtable/discord` | type |
 | `DiscordConnection` | `pi-roundtable/discord` | type |
 | `DiscordServices` | `pi-roundtable/discord` | type |
 | `InteractionContribution` | `pi-roundtable/discord` | type |
@@ -2858,6 +3628,7 @@ Import from the entries listed below; source area files are internal.
 | `agentPanel` | `pi-roundtable/discord` | value |
 | `commandGuard` | `pi-roundtable/discord` | value |
 | `composeCommands` | `pi-roundtable/discord` | value |
+| `discord` | `pi-roundtable/discord` | value |
 | `ephemeralPanel` | `pi-roundtable/discord` | value |
 | `fetchManagedChannel` | `pi-roundtable/discord` | value |
 | `groupOption` | `pi-roundtable/discord` | value |
@@ -2870,3 +3641,4 @@ Import from the entries listed below; source area files are internal.
 | `parseChannelTool` | `pi-roundtable/discord` | value |
 | `plain` | `pi-roundtable/discord` | value |
 | `replyWithPanels` | `pi-roundtable/discord` | value |
+| `withChannelContext` | `pi-roundtable/discord` | value |