pi-roundtable 0.8.0 → 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.
 
@@ -140,9 +152,9 @@ Use `QueuePort` from the main entry for `context.queue`; the kit's `ChannelQueue
 `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, or, with `config.ops.conversation`, to that conversation as a visible message and a report turn its claim answers.
-The report turn is a background turn of the `owner` target, so 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, or the claim that owns it takes no background turns (has no `background`); a report is then never only logged.
-On a host without Discord no plugin contributes `owner` unless one of yours does, so `ops.conversation` needs such a plugin there.
-The web chat takes no error reports in 0.8: it posts only to a conversation a signed-in person opened, and its claim takes no background turns, so `web:<id>` fails at startup; name a conversation of another surface, or an agent with Discord.
+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.
@@ -175,13 +187,14 @@ The built-in plugins provide these, from the main entry:
 
 | Key | Port | Provided by | What it is |
 |---|---|---|---|
-| `CONVERSATIONS` | `ConversationRegistry` | `conversations` | The conversations run through `context.turns`: `register`, `get(key)`, `list({ principal }?)`, `setTitle(key, title)`; each a `ConversationRecord` of `key`, `surface`, `kind`, `visibility` (`"private"` or `"shared"`), `principalId?`, `title?`, `createdAt`, `lastActiveAt` |
+| `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()` |
 
@@ -327,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.
@@ -344,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.
@@ -516,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 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 owner; nobody else in the channel may approve it. The held call records that speaker as `PendingConfirmation.speakerId`; a call held without one is the owner's to approve.
+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
 
@@ -601,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.");
@@ -855,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.
 
@@ -1043,8 +1212,9 @@ The slot's default factory refuses calls: read the running runtime with `service
 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.
 
@@ -1056,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 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.
 
@@ -1243,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",
@@ -1354,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 -->
@@ -1583,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
@@ -1661,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.
@@ -1706,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.
@@ -1717,7 +1908,12 @@ 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`.
@@ -1727,12 +1923,19 @@ Supply `reply(result)` to handle the reply yourself.
 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 (`principalId` is `speaker.id`); without it the conversation is `shared`.
+`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.
-No session file moves, and a conversation from before the registry is recorded at its next turn.
+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
@@ -1763,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,
 			},
@@ -1796,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";
@@ -1807,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 };
 }
@@ -1836,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();
@@ -1857,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 ?? [];
@@ -1867,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.
@@ -1929,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.
@@ -1949,19 +2331,38 @@ 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.
 The host logs and drops messages whose prefix differs from the delivering surface's, since claims can't identify which surface they belong to.
 `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
 
@@ -1987,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
@@ -2007,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. */
@@ -2049,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,
+			});
+		});
+	}
 }
 
 /**
@@ -2150,10 +2617,9 @@ The runtime plugin still builds the runtime, so every claim that runs turns thro
 
 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, a claim that owns it and takes background turns, and a plugin that contributes the `owner` background target, or the host does not start; without Discord nothing contributes `owner` unless a plugin of yours does. The web chat takes no error reports in 0.8.
-- `notify_owner` is not registered, since there are no owner's messages to send to.
-- `schedule_*` and `delegate_task` are not registered: their runs are turns of the [background target](#backgroundtargets-whose-turn-a-schedule-or-delegated-task-is) named `owner`, which the agent server contributes, so without it none could start.
-  A plugin that contributes `owner`, and a claim that takes its background turns, bring them back; they then work in a conversation a chat surface carries, posting their runs there, and refuse elsewhere.
+- `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.
@@ -2186,7 +2652,11 @@ export function studyHall(
 ): RoundtableConfig {
 	return {
 		name: "Study Hall",
-		owner: { id: "owner", name: "Ada" },
+		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",
@@ -2202,13 +2672,13 @@ export function studyHall(
 ### Web chat: pi-roundtable-webchat
 
 [pi-roundtable-webchat][webchat-package] is a chat network that comes as a plugin.
-`webChat({ verifier, access, 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.
+`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, and one persona, `assistant`, whose prompt is `persona/assistant.md`.
+`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.
@@ -2218,9 +2688,10 @@ The host listens on `127.0.0.1:3000`; serve it over HTTPS through a reverse prox
 
 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`, `reauth`, and `error`.
+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, and reads its messages.
+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
@@ -2230,14 +2701,17 @@ The package README documents every frame, error code, close code, and limit.
 - `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; owners are listed by speaker id, `oidc:<base64url(issuer)>:<subject>`.
+- 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 and no background turns yet: leave `schedule_*` and `delegate_task` out of a web persona's `selection`, and `web_search` and `fetch_content` unless people may make the host fetch any address, internal ones included.
+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
@@ -2352,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 |
@@ -2411,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(
@@ -2443,7 +2924,7 @@ 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
@@ -2480,9 +2961,9 @@ It returns:
 ### `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`, an owner by default, and every approval the contract asks for needs exactly their tier. `stranger`, when given, is someone else on the network, not the owner, who knows the id of the person's open approval and may `join()` and `answer(prompt, approved)` it.
+`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, and, with a `stranger`, that the stranger's answer leaves the person's approval open.
+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.
 
@@ -2544,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
 
@@ -2707,6 +3188,13 @@ 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 |
@@ -2733,6 +3221,8 @@ Import from the entries listed below; source area files are internal.
 | `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 |
@@ -2752,6 +3242,9 @@ Import from the entries listed below; source area files are internal.
 | `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 |
@@ -2771,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 |
@@ -2780,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 |
@@ -2801,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 |
@@ -2820,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 |
@@ -2856,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 |
@@ -2867,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 |
@@ -2885,6 +3394,7 @@ 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 |
@@ -2897,6 +3407,7 @@ Import from the entries listed below; source area files are internal.
 | `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 |
@@ -2913,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 |
@@ -2980,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 |
@@ -3022,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 |
@@ -3072,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 |
@@ -3086,6 +3612,7 @@ 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 |
@@ -3114,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 |