pi-roundtable 0.21.0 → 0.22.1

package/CHANGELOG.md

@@ -5,6 +5,20 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [0.22.1] - 2026-10-21
+
+### Changed
+
+- A turn that reaches its time limit asks before it ends (`pi-roundtable`). When the built-in runtime's 10-minute budget or 30-minute cap fires on a turn that can show the owner a card, the turn keeps working and a card names the limit, the work time, what the turn is doing (the running tool and for how long, waiting on the model, or compacting) and the tools so far, with **Continue** (another full budget from the answer; at the cap the cap moves too) and **Cancel**. No answer within 5 minutes aborts the turn; a turn that finishes first closes the card and replies as usual. A turn that cannot show a card is aborted as before. An aborted turn now fails with `TurnTimeoutError` (an `AgentRunError`, with the reason as `TurnTimeout`: its `TurnLimit`, work time, running tools, tools so far and `TurnTimeoutEnd`), its log warning carries the same fields, and the posted failure says why instead of the generic notice. `ApprovalOptions` gains `wording` (`ApprovalWording`: the buttons' labels and the footers) for a card that is not an approval; the Discord cards honour it. `PiAgentRuntimeOptions` gains `turnTimeoutCardMs`, the card's grace period; the runtime plugin still passes none of the limits, so they stay fixed. See [the turn limits](docs/plugins.md#what-happens-when-the-bot-starts-and-stops).
+
+## [0.22.0] - 2026-10-21
+
+### Added
+
+- Worker sessions for plugins (`pi-roundtable`). A new built-in plugin, `worker-sessions` (after `modules`), provides `WORKER_SESSIONS`, a `WorkerSessions`: `run(request)` runs a `WorkerSessionRequest` (`task`, `signal`, `prompt`, `extensions`, `toolNames`, and optionally `model`, `thinking` and `aborted`) in a fresh, unsaved Pi session on the host's model login and resolves to the worker's final answer, rejecting with an `AgentRunError` when it ends without one and with the signal's reason when it is aborted; the session is disposed either way. The session has no built-in tool, skill, context file, memory or agent tool, and only the tools its `extensions` register and `toolNames` names are active, even if an extension activates another. `model` and `thinking` default to the host's `delegation` settings, shown as `WorkerSessions.delegation`. The delegation worker for web research now runs on the same code. It is a separate plugin, not part of `modules`, so a host that replaces `BACKGROUND_TURNS` and `DELEGATION` still replaces that plugin whole. The built-in plugin names gain `worker-sessions`, so a plugin of that name is now refused. See [Workers of your own](docs/plugins.md#workers-of-your-own).
+- `pi-roundtable-browser`, a new official workspace package published in lockstep (not yet on npm; see `.github/PACKAGE-RELEASES.md`): `browserAgent(options)` adds the owner-tier tool `browser_task({ task, url? })`, which runs a fresh worker session that drives a real browser through a `BrowserDriver` and returns its report, attaching the screenshots it kept to the agent's reply. The default driver runs agent-browser and Chromium in a Docker container started per task and removed after it, with no network but a unix socket to a host-side proxy that refuses every destination that is not a public address. See the package README and `site/src/content/docs/plugins/browser-package.mdx`.
+- Skills from an npm package (`pi-roundtable`, `pi-roundtable-web`). `skills: { packages: ["pi-workflow-skills"] }` (the new type `SkillsConfig`) names packages the host installed; at startup the registry reads each package's `pi.skills` folders and offers every skill found as a fourth kind, `package` (`SkillSource` gains `{ kind: "package"; package }`; `SkillCatalogEntry.source` and the web console's skill list show the package). A package skill is read-only, named by its frontmatter and resolved to the installed file on every read, so upgrading the package changes the skill with no database write. Agents carry package skills and groups include them exactly like linked or written ones (`agent_skills`, `agent_create`, `skill_group_set`, `repo_task`); `skill_unlink`, `skill_update` and `skill_delete` refuse a package skill with a message saying it comes from the package, and `skill_link` and `skill_create` refuse a name a package skill holds. A package that is not installed, a package without `pi.skills`, two packages offering one name, or a package skill named like a built-in, linked or written skill stops startup with a `PluginError` naming the fix. A carried package skill that an upgrade removed is reported missing and skipped, as a vanished linked skill is.
+
 ## [0.21.0] - 2026-10-20
 
 ### Added

package/docs/plugins.md

@@ -50,6 +50,29 @@ Their exported names are grouped by area in the source, with one entry for each;
 The [changelog](../CHANGELOG.md) lists every exported name, including type-only contracts.
 Import fixtures and fake threads from `pi-roundtable/testing` for tests.
 
+#### Workers of your own
+
+A plugin that gives a model its own small set of tools, such as a worker that drives a browser, asks the host for a worker session instead of building one from Pi's parts:
+
+```ts
+const sessions = context.services.get(WORKER_SESSIONS);
+const report = await sessions.run({
+	task: "What the worker is asked to do.",
+	signal: turn.signal,
+	prompt: "You are a ... worker. Report in the task's language.",
+	extensions: [registersTheWorkersTools],
+	toolNames: ["my_tool"],
+});
+```
+
+`run` starts a fresh session that is never saved, on the host's model login (the same credentials and refreshes the agents use), with the `model` and `thinking` of the host's `delegation` settings unless the request names its own (`model` is `<provider>/<id>`; `sessions.delegation` shows the defaults).
+The session has no built-in tool, no skills, no context files, no memory and none of the agents' tools: only the tools the `extensions` register with `pi.registerTool` and `toolNames` lists are active, and an extension that activates another tool is undone.
+`prompt` is added to its system prompt, so the standing rules and any instructions the worker should follow, such as a tool's usage guide, go there.
+`run` resolves to the worker's final answer, rejects with an `AgentRunError` when it ends without one, and rejects when `signal` aborts (`aborted` is the message of that rejection, default "the worker ran out of time"); the session is disposed either way.
+The tools are the plugin's to bound: the worker has no tier, no hold and no conversation, so a tool checks what the worker asks for, limits its work, and cleans up in a `finally` around `run`.
+A file a tool produces reaches the person only through the tool that called `run`: collect it and call `turn.attachFile` after `run` returns, as the [browser package source][browser-source] does with screenshots.
+The `worker-sessions` plugin provides the service on every host.
+
 #### Helpers for a Pi session of your own
 
 Use the kit's building blocks for a plugin that runs Pi itself, such as a coding worker:
@@ -218,6 +241,7 @@ The built-in plugins provide these, from the main entry:
 | `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()` |
+| `WORKER_SESSIONS` | `WorkerSessions` | `worker-sessions` | Fresh Pi sessions for a plugin's own workers, on the host's model login: `delegation` is the host's delegation `model` and `thinking`, and `run({ task, signal, prompt, extensions, toolNames, model?, thinking?, aborted? })` runs the task in a session that has only the tools `extensions` register and `toolNames` names (no built-in tool, skill, context file, memory or agent tool) and returns the worker's final answer; see [Workers of your own](#workers-of-your-own) |
 
 The data types the ports use (`Schedule`, `NewSchedule`, `Agent`, `AgentGroup`, `TeamStatus`, `Memory`, `SkillSet`, `DelegationJob`, and so on) are in the main entry too.
 Your plugins run after the built-ins, so they can read every key above.
@@ -366,7 +390,16 @@ You can switch them off in the configuration.
 | 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.
+`skills` also takes the two directories and the skill packages (`skills: { builtinDir, reposDir, packages }`) when it is on.
+
+`skills.packages` lists npm packages the host installed, for example `["pi-workflow-skills"]`.
+At startup the registry reads each package's `pi.skills` folders (Pi's package manifest) and offers every skill it finds there as a fourth kind, `package`, beside the built-in, linked and written ones.
+A package skill is named by its frontmatter and resolved to the installed file on every read, so upgrading the package changes the skill and nothing is written to the database.
+Agents carry package skills and groups include them exactly like the others: `agent_skills`, `agent_create`'s `skills` field, `skill_group_set` and `repo_task` accept their names.
+`skill_unlink`, `skill_update` and `skill_delete` refuse a package skill, naming the package, and `skill_link` and `skill_create` refuse a name a package skill already holds.
+`SkillCatalogEntry.source` is `{ kind: "package", package }` for them, and the web console's skill list shows the package.
+A package that is not installed, a package with no `pi.skills` (or none that holds a `SKILL.md`), two packages offering one name, a package skill with the name of a built-in, linked or written skill: each stops startup with a `PluginError` naming the fix.
+A carried package skill that an upgrade removed is reported missing and skipped, as a linked skill whose file vanished is.
 
 Use `find` for an optional addon service; it returns `undefined` while the addon is off.
 Use `get` if your plugin needs the addon; it fails with a message naming the switch:
@@ -3162,7 +3195,7 @@ The [pi-roundtable-mcp][mcp-package] workspace, published separately on npm, add
 The first lets the owner add MCP servers such as Notion or a calendar from Discord and gives your code the list; the second lets an agent outside Discord reach your agent.
 Install it with `bun add pi-roundtable-mcp`.
 
-Six official packages live in this repository as Bun workspaces and publish as separate npm packages, versioned in lockstep with the core.
+Seven official packages live in this repository as Bun workspaces and publish as separate npm packages, versioned in lockstep with the core.
 The [site guide source files][package-guides] describe installation, requirements, configuration, and security considerations:
 
 - [pi-roundtable-drawing][drawing-package]: [site guide source][drawing-guide] · local relationship maps, magic circles, sigils, sacred geometry, and card spreads.
@@ -3170,6 +3203,7 @@ The [site guide source files][package-guides] describe installation, requirement
 - [pi-roundtable-web][web-package]: [site guide source][web-guide] · an owner-only console for conversations, transcripts, and memory notes with live updates.
 - [pi-roundtable-sandbox][sandbox-package]: [site guide source][sandbox-guide] · sealed guest channels on native Linux Docker with a host-only credential broker and allow-listed tools.
 - [pi-roundtable-mcp][mcp-package]: [site guide source][mcp-guide] · MCP connectors through a gateway and remote MCP endpoints for agent turns and owner-granted Discord channel tools.
+- [pi-roundtable-browser][browser-package]: [site guide source][browser-guide] · `browser_task`, a worker that drives agent-browser in a Docker container with no route to the host's private networks, and a `BrowserDriver` for another browser.
 - [pi-roundtable-webchat][webchat-package]: [site guide source][webchat-guide] · a WebSocket chat for people an OpenID Connect provider signs in, with private conversations, live progress, and approval cards; see [web chat](#web-chat-pi-roundtable-webchat).
 
 [drawing-package]: https://github.com/wayne930242/pi-roundtable/blob/master/packages/drawing/README.md
@@ -3177,17 +3211,20 @@ The [site guide source files][package-guides] describe installation, requirement
 [web-package]: https://github.com/wayne930242/pi-roundtable/blob/master/packages/web/README.md
 [sandbox-package]: https://github.com/wayne930242/pi-roundtable/blob/master/packages/sandbox/README.md
 [mcp-package]: https://github.com/wayne930242/pi-roundtable/blob/master/packages/mcp/README.md
+[browser-package]: https://github.com/wayne930242/pi-roundtable/blob/master/packages/browser/README.md
 [package-guides]: https://github.com/wayne930242/pi-roundtable/tree/master/site/src/content/docs/plugins/
 [drawing-guide]: https://github.com/wayne930242/pi-roundtable/blob/master/site/src/content/docs/plugins/drawing-package.mdx
 [coding-guide]: https://github.com/wayne930242/pi-roundtable/blob/master/site/src/content/docs/plugins/coding-package.mdx
 [web-guide]: https://github.com/wayne930242/pi-roundtable/blob/master/site/src/content/docs/plugins/web-package.mdx
 [sandbox-guide]: https://github.com/wayne930242/pi-roundtable/blob/master/site/src/content/docs/plugins/sandbox-package.mdx
 [mcp-guide]: https://github.com/wayne930242/pi-roundtable/blob/master/site/src/content/docs/plugins/mcp-package.mdx
+[browser-guide]: https://github.com/wayne930242/pi-roundtable/blob/master/site/src/content/docs/plugins/browser-package.mdx
 [webchat-guide]: https://github.com/wayne930242/pi-roundtable/blob/master/site/src/content/docs/plugins/webchat-package.mdx
 [coding-source]: https://github.com/wayne930242/pi-roundtable/tree/master/packages/coding
 [sandbox-source]: https://github.com/wayne930242/pi-roundtable/tree/master/packages/sandbox
 [web-source]: https://github.com/wayne930242/pi-roundtable/tree/master/packages/web
 [drawing-source]: https://github.com/wayne930242/pi-roundtable/tree/master/packages/drawing
+[browser-source]: https://github.com/wayne930242/pi-roundtable/tree/master/packages/browser
 [mcp-source]: https://github.com/wayne930242/pi-roundtable/tree/master/packages/mcp
 [codex-images-template]: https://github.com/wayne930242/pi-roundtable/blob/master/templates/official/codex-images/plugin.ts
 [dice-template]: https://github.com/wayne930242/pi-roundtable/blob/master/templates/official/dice/plugin.ts
@@ -3455,7 +3492,7 @@ The host's `run()` handles startup:
    The runtime plugin builds the runtime later, in its own setup: from the `runtime` slot when a plugin fills it, else the Pi runtime.
 2. The database is opened and every plugin's migrations run, in plugin order.
 3. Every plugin's `setup` runs, in plugin order.
-   The order is the built-ins (`memory`, `schedule-store`, `prechecks`, `discord`, `modules`, `discord-admin`, `skills`, `conversations`, `runtime`, `agent-server`, `seeds`; an addon that is switched off is not there, and without Discord neither are `discord`, `discord-admin`, `skills`, `agent-server`, or `seeds`), then yours in the order of `plugins` in `roundtable.config.ts`, then the built-in `schedules`, so a due schedule fires only once everything it can reach is running.
+   The order is the built-ins (`memory`, `schedule-store`, `prechecks`, `discord`, `modules`, `worker-sessions`, `discord-admin`, `skills`, `conversations`, `runtime`, `agent-server`, `seeds`; an addon that is switched off is not there, and without Discord neither are `discord`, `discord-admin`, `skills`, `agent-server`, or `seeds`), then yours in the order of `plugins` in `roundtable.config.ts`, then the built-in `schedules`, so a due schedule fires only once everything it can reach is running.
 4. The contributions are linked: tool tiers, hold rules, the session plan, the channel router, and the events.
    From here `sessions()`, `conversations`, `surfaces`, `turns`, and `dashboard()` work.
 5. Every plugin's `preflight` runs, in plugin order.
@@ -3489,7 +3526,10 @@ On `SIGTERM` or `SIGINT` the bot takes no new work at once, finishes what runs,
 `shutdown()` returns exit code `0`, or `1` if a listener, service, or pool failed to stop.
 Every call shares the same shutdown.
 Give the service manager a stop timeout longer than the drain limit plus about a minute for the steps after it, such as systemd's `TimeoutStopSec=5min` with the default three-minute drain; a shorter one has the manager kill the process in the middle of the drain.
-The built-in runtime aborts a turn that works 10 minutes, not counting time spent waiting on the owner's cards. Each message steered into the running turn gives it the full 10 minutes again from that moment, up to a cap of 30 minutes of work for the whole turn; once the cap is reached the turn takes no more steering, so a message waits for the next turn, and the turn is aborted as on its timeout. Both limits are fixed: the runtime plugin passes no option for them, so a host cannot change them, and a limit that waiting on an owner's card pushed back can fire up to a second late. The log says `steer renewed the turn's time budget` with `deadlineMs`, the work time left, and the timeout warning names the limit that fired (`limit: "turn"` or `"turnMax"`). Task workers (`task.timeoutMs`), coding workers (`workTimeout`) and sandbox guests (their own `turnTimeoutMs`) keep their own limits, which steering does not renew.
+The built-in runtime limits a turn to 10 minutes of work, not counting time spent waiting on the owner's cards. Each message steered into the running turn gives it the full 10 minutes again from that moment, up to a cap of 30 minutes of work for the whole turn; once the cap is reached the turn takes no more steering, so a message waits for the next turn.
+When a limit fires on a turn that can show a card (an owner's turn or a report turn on a surface with cards, the same turns that can ask with `ask_user` or an approval card), the turn is not aborted: it keeps working and a card asks the owner whether to go on. The card names the limit, how long the turn has worked, what it is doing now (the tool running and for how long, or waiting on the model, or compacting the conversation) and the tools it called so far, by name and count, never their inputs. **Continue** gives the turn another full 10 minutes from the answer; at the cap it moves the cap too, to 10 minutes from the answer, so the owner can keep going in steps. **Cancel** aborts the turn. With no answer within 5 minutes of wall time the turn is aborted. The time the card is open counts as work, unlike an `ask_user` or approval card, because the turn keeps working; while it is open the turn takes no steering. If the turn finishes first, the card closes saying so and the reply is posted as usual; a press after that gets the usual "no longer valid" reply. The card's buttons come from `ApprovalOptions.wording` on `Prompts.confirm`, with `supersede` closing it, so a surface that shows approvals shows it; one that ignores `wording` shows its own approve and decline labels.
+A turn that cannot show a card (a schedule's turn, a member's turn, a turn without a surface) is aborted at once, as before. Either way an aborted turn fails with a `TurnTimeoutError` (an `AgentRunError`) whose `timeout` (`TurnTimeout`) holds the limit, the work time, the running tools, whether it was compacting, the tools so far, and how it ended (`end`: `"timeout"`, `"cancelled"` by the owner, or `"unanswered"`); its message says the same in English, and the failure the conversation posts says it in the host's language instead of the generic failure notice.
+The limits are fixed: the runtime plugin passes no option for them, nor for the card's grace period (`turnTimeoutMs`, `turnMaxMs` and `turnTimeoutCardMs` of `PiAgentRuntimeOptions`, for a host that builds the runtime itself), and a limit that waiting on an owner's card pushed back can fire up to a second late. The log says `steer renewed the turn's time budget` with `deadlineMs`, the work time left; `turn reached its time limit; asking the owner` when the card is posted; `owner continued the turn past its time limit` on Continue; and the warning `turn timed out; aborting` names the limit that fired (`limit: "turn"` or `"turnMax"`) with `workedMs`, `running`, `compacting`, `tools` and `end`. Task workers (`task.timeoutMs`), coding workers (`workTimeout`) and sandbox guests (their own `turnTimeoutMs`) keep their own limits, which steering does not renew and which post no card.
 A turn whose model ignores its abort (a subprocess that does not exit) is given up on too: a turn that outlives its timeout, or is stopped, gets `turnAbortGraceMs` (15 seconds by default) to end, and then its session is disposed of and the turn is reported failed, so it cannot hold the queue.
 `listen()`, called by the command line and a host's own entry point, exits the process with that code.
 
@@ -3543,7 +3583,7 @@ These are the messages as the code writes them, with `<...>` where your names go
 | `no runtime provider is configured: the runtime plugin builds the Pi runtime when no plugin fills the runtime slot; read the running one from services.get(RUNTIME)` | Only a plugin that calls `providers.runtime` without `providers.filled.has("runtime")` sees it; read `services.get(RUNTIME)` instead |
 | `session tool <name> takes a core extension name. Rename it.` | Pick a name other than the core's |
 | `plugin <name>: setup failed: the database was queried during setup…` (from `Roundtable.check()`, `roundtable doctor` or `start`) | A plugin's `setup` ran a query. Take `database()` in setup and query from a service's `start` or from a handler |
-| `two plugins are named <name>.` (from `roundtable doctor`) | Rename yours; the built-in plugins are `memory`, `schedule-store`, `prechecks`, `discord`, `modules`, `discord-admin`, `skills`, `conversations`, `runtime`, `agent-server`, `seeds`, and `schedules` |
+| `two plugins are named <name>.` (from `roundtable doctor`) | Rename yours; the built-in plugins are `memory`, `schedule-store`, `prechecks`, `discord`, `modules`, `worker-sessions`, `discord-admin`, `skills`, `conversations`, `runtime`, `agent-server`, `seeds`, and `schedules` |
 | `migration <plugin>/<name> is declared twice` | A plugin declares two migrations with one name: rename one (the same name in two plugins is fine) |
 | `/<root> <name> is added twice`, `/<name> is registered twice` | Give each slash command and subcommand its own name |
 | `route <name> is registered twice`, `routes <a> and <b> overlap on listener <id>` | Give each route its own name and a path no other route can take |
@@ -3700,6 +3740,7 @@ Import from the entries listed below; source area files are internal.
 | `ApprovalDetails` | `pi-roundtable` | type |
 | `ApprovalFile` | `pi-roundtable` | type |
 | `ApprovalOptions` | `pi-roundtable` | type |
+| `ApprovalWording` | `pi-roundtable` | type |
 | `ApprovedBy` | `pi-roundtable` | type |
 | `AskOption` | `pi-roundtable` | type |
 | `AskSupport` | `pi-roundtable` | type |
@@ -3885,8 +3926,12 @@ Import from the entries listed below; source area files are internal.
 | `SessionToolSnapshot` | `pi-roundtable` | type |
 | `SkillCatalogEntry` | `pi-roundtable` | type |
 | `SkillRegistry` | `pi-roundtable` | type |
+| `WorkerSessions` | `pi-roundtable` | type |
+| `WorkerSessionRequest` | `pi-roundtable` | type |
+| `WORKER_SESSIONS` | `pi-roundtable` | value |
 | `SkillSet` | `pi-roundtable` | type |
 | `SkillSource` | `pi-roundtable` | type |
+| `SkillsConfig` | `pi-roundtable` | type |
 | `Speaker` | `pi-roundtable` | type |
 | `SpeakerMemory` | `pi-roundtable` | type |
 | `StoredAttachment` | `pi-roundtable` | type |
@@ -3922,6 +3967,10 @@ Import from the entries listed below; source area files are internal.
 | `TurnRequest` | `pi-roundtable` | type |
 | `TurnResult` | `pi-roundtable` | type |
 | `TurnSelection` | `pi-roundtable` | type |
+| `TurnLimit` | `pi-roundtable` | type |
+| `TurnTimeout` | `pi-roundtable` | type |
+| `TurnTimeoutEnd` | `pi-roundtable` | type |
+| `TurnTimeoutError` | `pi-roundtable` | value |
 | `WebSocketAccept` | `pi-roundtable` | type |
 | `WebSocketRoute` | `pi-roundtable` | type |
 | `WebSocketSendResult` | `pi-roundtable` | type |

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "pi-roundtable",
-	"version": "0.21.0",
+	"version": "0.22.1",
 	"description": "A plugin-driven Pi agent server for one owner, reached through Discord or the web",
 	"type": "module",
 	"license": "MIT",

package/src/core/agents/team-turns.ts

@@ -8,7 +8,7 @@ import type {
 import { AgentError } from "../domain/errors.ts";
 import type { InterimPosts } from "../domain/interim.ts";
 import type { AgentTurnScope } from "../domain/ports.ts";
-import { messages } from "../i18n/index.ts";
+import { failureNotice } from "../presentation/failure-notice.ts";
 import { splitReply } from "../presentation/reply-splitter.ts";
 import { thinkingLine } from "../presentation/thinking-line.ts";
 import { withReplyFiles } from "../reply-files.ts";
@@ -35,11 +35,6 @@ import {
 
 export { MAX_CHAIN_MESSAGES, type TeamTurnsOptions };
 
-/** What a failed turn posts: the stopped notice for a stop, the failure notice otherwise. */
-function noticeOf(result: { stopped?: true }): string {
-	return result.stopped ? messages().stoppedNotice : messages().failureNotice;
-}
-
 /**
  * The agent team's turns: owner messages, background turns, group rounds, and messages between
  * agents, each posted under the answering agent's name.
@@ -246,7 +241,7 @@ export class TeamTurns {
 					: undefined;
 			await this.#post(postTo, this.#current(agent), {
 				...(thinking ? { thinking } : {}),
-				chunks: result.ok ? splitReply(result.text) : [noticeOf(result)],
+				chunks: result.ok ? splitReply(result.text) : [failureNotice(result)],
 				...(result.ok && result.files?.length ? { files: result.files } : {}),
 			});
 		} catch (error) {

package/src/core/builtin/skills.ts

@@ -1,4 +1,5 @@
 import type { SQL } from "bun";
+import { discoverPackageSkills } from "../modules/skills/package-skills.ts";
 import { StoredSkillRegistry } from "../modules/skills/skill-registry.ts";
 import { SkillStore } from "../modules/skills/skill-store.ts";
 import {
@@ -19,6 +20,10 @@ export interface SkillsOptions {
 	reposDir: string;
 	writtenDir: string;
 	builtinDir: string;
+	/** npm packages whose `pi.skills` folders offer read-only skills; the host installed them. */
+	packages?: readonly string[];
+	/** Where a package is found; default the installed package's folder. */
+	packageDir?: (name: string) => string;
 }
 
 /** Admins manage skills; every speaker may look one up. */
@@ -47,11 +52,17 @@ export function skillsPlugin(
 		// The skills are read once every plugin is set up, so a plugin may still place some in setup.
 		preflight: () => registry?.init(),
 		setup: async ({ database, services, logger }) => {
+			// Read before the store opens, so a missing package stops startup at once.
+			const packageSkills = discoverPackageSkills(
+				options.packages ?? [],
+				options.packageDir,
+			);
 			const built = new StoredSkillRegistry({
 				store: await openStore(database(), options.guildId),
 				reposDir: options.reposDir,
 				writtenDir: options.writtenDir,
 				builtinDir: options.builtinDir,
+				packageSkills,
 				logger,
 			});
 			registry = built;

package/src/core/builtin/worker-sessions.ts

@@ -0,0 +1,44 @@
+import { join } from "node:path";
+import type { ModelRuntime } from "@earendil-works/pi-coding-agent";
+import {
+	formatModelRef,
+	type ModelRef,
+	type ThinkingLevel,
+} from "../models.ts";
+import { workerSessions } from "../modules/delegation/worker-session.ts";
+import type { RoundtablePlugin } from "../plugin.ts";
+import { WORKER_SESSIONS } from "../services.ts";
+
+export interface WorkerSessionsPluginOptions {
+	/** Shared with the rest of the host, so logins refresh in one place. */
+	modelRuntime: ModelRuntime;
+	agentDir: string;
+	dataDir: string;
+	/** The model and thinking level a worker session uses unless its request names its own. */
+	delegation: { model: ModelRef; thinking: ThinkingLevel };
+}
+
+/** Provides `WORKER_SESSIONS`: worker sessions on the host's model login, with its delegation settings as the defaults. */
+export function workerSessionsPlugin(
+	options: WorkerSessionsPluginOptions,
+): RoundtablePlugin {
+	return {
+		name: "worker-sessions",
+		provides: [WORKER_SESSIONS],
+		setup: ({ services }) => {
+			services.provide(
+				WORKER_SESSIONS,
+				workerSessions({
+					modelRuntime: options.modelRuntime,
+					agentDir: options.agentDir,
+					workDir: join(options.dataDir, "workers"),
+					delegation: {
+						model: formatModelRef(options.delegation.model),
+						thinking: options.delegation.thinking,
+					},
+				}),
+			);
+			return {};
+		},
+	};
+}

package/src/core/config/config.ts

@@ -36,11 +36,11 @@ import {
 	number,
 	oneOf,
 	optional,
-	orOff,
 	record,
 	shape,
 	text,
 } from "./schema.ts";
+import { type SkillsConfig, skillsField } from "./skills-config.ts";
 
 export type { DiscordConfig };
 
@@ -168,7 +168,7 @@ export interface RoundtableConfig {
 	 * the `skills` addon out: agents carry no skills, and no skill tools exist. Stored skills stay
 	 * in their tables. Without `discord` there are no agents, so the addon is off.
 	 */
-	skills?: false | { builtinDir?: string; reposDir?: string };
+	skills?: false | SkillsConfig;
 	/**
 	 * Whether each speaker's memory is kept and offered as tools; default true. `false` leaves the
 	 * `memory` addon out: no memory tools, no memory prompt block, and the table stays as it is.
@@ -284,9 +284,7 @@ const schema = shape({
 	avatar: optional(text),
 	workDir: optional(text),
 	scratchDir: optional(text),
-	skills: optional(
-		orOff(shape({ builtinDir: optional(text), reposDir: optional(text) })),
-	),
+	skills: optional(skillsField),
 	memory: optional(bool),
 	ops: optional(shape({ agent: optional(text), conversation: optional(text) })),
 	drainSeconds: optional(integer(1, 3_600)),
@@ -352,7 +350,7 @@ export interface ResolvedConfig {
 	workDir: string;
 	scratchDir: string;
 	/** `false` when the skills addon is off. */
-	skills: false | { builtinDir?: string; reposDir?: string };
+	skills: false | SkillsConfig;
 	memory: boolean;
 	ops?: { agent: string } | { conversation: ChannelKey };
 	drainMs: number;

package/src/core/config/skills-config.ts

@@ -0,0 +1,23 @@
+import { list, optional, orOff, shape, text } from "./schema.ts";
+
+/** The `skills` setting when the addon is on. */
+export interface SkillsConfig {
+	/** Where the registry reads the release's built-in skills. */
+	builtinDir?: string;
+	/** Where it keeps linked repositories; default `<dataDir>/repos`. */
+	reposDir?: string;
+	/**
+	 * npm packages the host installed. Every skill in their `pi.skills` folders is offered
+	 * read-only, and carried and grouped like any other. Startup fails, naming the fix, when a
+	 * package is not installed, ships no skills, or holds a skill whose name another skill has.
+	 */
+	packages?: string[];
+}
+
+export const skillsField = orOff(
+	shape({
+		builtinDir: optional(text),
+		reposDir: optional(text),
+		packages: optional(list(text)),
+	}),
+);

package/src/core/define-roundtable.ts

@@ -13,6 +13,7 @@ import {
 	precheckPlugin,
 	scheduleStorePlugin,
 } from "./builtin/stores.ts";
+import { workerSessionsPlugin } from "./builtin/worker-sessions.ts";
 import { warnDeprecations } from "./config/access.ts";
 import {
 	type ResolvedConfig,
@@ -187,6 +188,7 @@ function discordAssembly(
 						reposDir: config.skills.reposDir ?? join(config.dataDir, "repos"),
 						writtenDir: join(config.dataDir, "skills"),
 						builtinDir: config.skills.builtinDir ?? join(ASSETS, "skills"),
+						packages: config.skills.packages ?? [],
 					}),
 				]
 			: [],
@@ -321,6 +323,12 @@ export async function defineRoundtable(
 					? { errorReporter }
 					: {}),
 			}),
+			workerSessionsPlugin({
+				modelRuntime,
+				agentDir: config.agentDir,
+				dataDir: config.dataDir,
+				delegation: config.delegation,
+			}),
 			...(assembly?.admin ?? []),
 			...(assembly?.skills ?? []),
 			conversationsPlugin(),

package/src/core/discord/owner-card-rows.ts

@@ -123,23 +123,27 @@ export function answeredLine(answer: OwnerAnswer): string {
 	return messages().cardAnswered(parts);
 }
 
-/** An approval's controls: run, cancel, and, when the card offers a copy, a copy button that stays usable once it ended. */
+/**
+ * An approval's controls: run, cancel, or the labels its wording gives, and, when the card offers
+ * a copy, a copy button that stays usable once it ended.
+ */
 export function approvalRows(
 	id: string,
 	disabled: boolean,
 	copy: { label: string } | undefined,
+	labels?: { approve: string; decline: string },
 ): Rows {
 	return [
 		new ActionRowBuilder<ButtonBuilder>().addComponents(
 			new ButtonBuilder()
 				.setCustomId(`${CARD_PREFIX}${id}:yes`)
-				.setLabel(messages().cardRunLabel)
+				.setLabel(labels?.approve ?? messages().cardRunLabel)
 				.setEmoji("✅")
 				.setStyle(ButtonStyle.Success)
 				.setDisabled(disabled),
 			new ButtonBuilder()
 				.setCustomId(`${CARD_PREFIX}${id}:no`)
-				.setLabel(messages().cardCancelLabel)
+				.setLabel(labels?.decline ?? messages().cardCancelLabel)
 				.setEmoji("❌")
 				.setStyle(ButtonStyle.Secondary)
 				.setDisabled(disabled),

package/src/core/discord/owner-card-types.ts

@@ -83,6 +83,8 @@ export interface OpenCard {
 	mention?: boolean;
 	/** Who may answer, and what to tell someone else who presses it. */
 	audience: Audience;
+	/** An approval card's footers once approved or declined, where its wording gives them. */
+	outcomes?: { approved: string; declined: string };
 }
 
 /** What `#post` needs to post one card; `T` is what the card resolves with. */
@@ -101,6 +103,8 @@ export interface CardSpec<T> {
 	build?(id: string, footer: string, disabled: boolean): CardPayload;
 	rows?(id: string, disabled: boolean): Rows;
 	footer: string;
+	/** An approval card's footers once approved or declined, where its wording gives them. */
+	outcomes?: { approved: string; declined: string };
 	wait?: {
 		pending: T;
 		late(

package/src/core/discord/owner-cards.ts

@@ -175,8 +175,10 @@ export class OwnerCards implements InteractionModule {
 						sections: [message],
 						...(options?.supersede ? { supersede: options.supersede } : {}),
 						...(copy ? { copy: copy.text } : {}),
-						rows: (id, disabled) => approvalRows(id, disabled, copy),
-						footer: messages().cardApprovalFooter,
+						rows: (id, disabled) =>
+							approvalRows(id, disabled, copy, options?.wording),
+						footer: options?.wording?.footer ?? messages().cardApprovalFooter,
+						...(options?.wording ? { outcomes: options.wording } : {}),
 					},
 				);
 			},
@@ -296,6 +298,7 @@ export class OwnerCards implements InteractionModule {
 				...(card.question ? { question: card.question } : {}),
 				...(card.form ? { form: card.form } : {}),
 				...(card.previews ? { previews: card.previews } : {}),
+				...(card.outcomes ? { outcomes: card.outcomes } : {}),
 			};
 			this.#open.set(id, open);
 			this.#options
@@ -417,7 +420,11 @@ export class OwnerCards implements InteractionModule {
 				return true;
 			}
 			await interaction.update(
-				card.view(approved ? messages().cardApproved : messages().cardDeclined),
+				card.view(
+					approved
+						? (card.outcomes?.approved ?? messages().cardApproved)
+						: (card.outcomes?.declined ?? messages().cardDeclined),
+				),
 			);
 			return true;
 		}

package/src/core/domain/turn-timeout.ts

@@ -0,0 +1,38 @@
+import { AgentRunError } from "./errors.ts";
+
+/** Which limit a turn reached: its budget since the start or the last steer, or its cap. */
+export type TurnLimit = "turn" | "turnMax";
+
+/**
+ * How a timed-out turn ended: at its limit with no card to ask on (`timeout`), cancelled on the
+ * timeout card (`cancelled`), or with the card unanswered in its grace period (`unanswered`).
+ */
+export type TurnTimeoutEnd = "timeout" | "cancelled" | "unanswered";
+
+/** Why a turn hit a time limit, as data: which limit, how long it worked, and what it was doing. */
+export interface TurnTimeout {
+	limit: TurnLimit;
+	/** The limit's length: the budget, or the cap as the owner's Continues raised it. */
+	limitMs: number;
+	/** The turn's work so far, not counting time spent waiting on the owner's other cards. */
+	workedMs: number;
+	/** The tools running, the longest-running first, each with how long it has run. */
+	running: { tool: string; ms: number }[];
+	compacting: boolean;
+	/** Every tool called so far, by name, with how often. */
+	tools: [string, number][];
+	/** How long the timeout card waits for an answer. */
+	graceMs: number;
+	end: TurnTimeoutEnd;
+}
+
+/** A turn aborted at a time limit; `timeout` says why, and the message says it in English. */
+export class TurnTimeoutError extends AgentRunError {
+	override name = "TurnTimeoutError";
+	constructor(
+		readonly timeout: TurnTimeout,
+		message: string,
+	) {
+		super(message);
+	}
+}

package/src/core/i18n/en.ts

@@ -7,6 +7,7 @@ import { discordEn } from "./discord.ts";
 import { ownerEn } from "./owner.ts";
 import { schedulesEn } from "./schedules.ts";
 import { timeZonesEn } from "./time-zones.ts";
+import { turnTimeoutEn } from "./turn-timeout.ts";
 import type { CatalogContext } from "./types.ts";
 
 export type Messages = ReturnType<typeof createEn>;
@@ -23,5 +24,6 @@ export function createEn(ctx: CatalogContext) {
 		...dashboardEn(ctx),
 		...channelsEn(ctx),
 		...discordEn(ctx),
+		...turnTimeoutEn(),
 	};
 }