@osolmaz/pi-workflows 0.16.1 → 0.16.3

package/dist/workflows/types.d.ts

@@ -44,9 +44,7 @@ export type WorkflowEffectRecovery = "idempotent" | "manual";
 export type WorkflowManagedEffect = {
     /** Stable external effect category, for example `github.comment`. */
     type: string;
-    /** Stable key. Idempotent adapters must pass this key to the external system. */
-    idempotencyKey: string | ((context: WorkflowNodeContext) => MaybePromise<string>);
-    /** Canonical request data used to reject key reuse with another operation. */
+    /** Canonical request data used to reject engine-owned key reuse with another operation. */
     request: unknown | ((context: WorkflowNodeContext) => MaybePromise<unknown>);
     /** `manual` never retries after an uncertain child exit. */
     recovery: WorkflowEffectRecovery;
@@ -80,7 +78,7 @@ export type WorkflowProgressData = {
 export type WorkflowNodeCommon = {
     /**
      * Per-node active-execution timeout or a callback that derives it from the run context.
-     * Waiting, paused, disconnected, and host-down origin-session time does not count.
+     * Waiting, paused, disconnected, and server-down origin-session time does not count.
      * Null disables the deadline. Omission falls back to the engine default (15 minutes).
      */
     timeoutMs?: number | null | ((context: WorkflowNodeContext) => MaybePromise<number | null>);
@@ -810,7 +808,7 @@ export type WorkflowEngineOptions = {
     notificationSink?: WorkflowNotificationSink;
     /** Canonical SQLite database. Defaults to `~/.pi/agent/workflows/state.sqlite`. */
     databasePath?: string;
-    /** Durable execution store. Workers use a host-backed implementation. */
+    /** Durable execution store. Runners use a server-backed implementation. */
     store?: import("./store.js").WorkflowExecutionStore;
     /**
      * Awaited after `run_started` is persisted, before any node executes.

package/docs/2026-08-20-durable-workflow-launch-plan.md

@@ -18,7 +18,7 @@ If startup then fails, pi-workflows must save the failure and start one new mode
 actionable error. The model can correct the request and call `workflow start` again. A failed launch
 must release the session reservation so the corrected run can start.
 
-This change stays inside pi-workflows. It uses the existing project-scoped SQLite controller store
+This change stays inside pi-workflows. It uses the existing project-scoped SQLite resource manager store
 and documented Pi extension APIs. It does not change Pi, add a service, or add another database.
 
 ## Current failure
@@ -81,12 +81,12 @@ pi-workflows is in alpha. Change the current storage and tool contracts in place
 - Change the SQLite table definitions and TypeScript types directly.
 - Remove the superseded status values and launch path in the same change.
 
-An existing controller store with the old alpha table layout is incompatible. On open, pi-workflows
+An existing resource manager store with the old alpha table layout is incompatible. On open, pi-workflows
 must verify the required table columns and status contract. If the layout is old, it must stop with a
-clear instruction to preserve any needed run evidence and reset the project-scoped controller store.
+clear instruction to preserve any needed run evidence and reset the project-scoped resource manager store.
 It must not silently reinterpret or delete old state.
 
-Run bundles remain separate evidence. Resetting an incompatible controller queue must not delete run
+Run bundles remain separate evidence. Resetting an incompatible resource manager queue must not delete run
 bundle directories.
 
 ## Public behavior
@@ -118,7 +118,7 @@ includes:
 - Workflow resolution and definition validation.
 - Declared input validation.
 - Parent checkpoint and source checks for continuations.
-- Controller-store access.
+- ResourceManager-store access.
 - Existing active or queued session reservation.
 - Pending final presentation conflicts.
 
@@ -217,7 +217,7 @@ bundle owns input after the engine starts.
 
 Keep `workflow_notifications` limited to passive `progress` and `final` reports. A launch failure creates an eligible row in `workflow_turn_intents`; it does not add a run-level notification kind.
 
-The project-scoped controller store remains private local state. Tests must verify restrictive file
+The project-scoped resource manager store remains private local state. Tests must verify restrictive file
 and directory permissions.
 
 ## State transitions
@@ -273,9 +273,9 @@ can correct it without including secret values.
 
 ## Implementation plan
 
-### 1. Replace the alpha controller-store layout
+### 1. Replace the alpha resource manager store layout
 
-Update `src/controllers/sqlite.ts` and its exported queue and notification types.
+Update `src/resource-managers/sqlite.ts` and its exported queue and notification types.
 
 - Keep `CONTROLLER_STORE_SCHEMA` at `pi-workflows.controller-store.v1`.
 - Change `SCHEMA_SQL` directly.
@@ -316,8 +316,8 @@ Preparation owns resolution, validation, run ID allocation, immutable source ide
 digest, and reservation. Activation owns claims, engine construction, recorder setup, `activeRun`,
 running state, and executor release.
 
-Controller child workflows remain on their controller scheduler path. Share pure workflow-resolution
-helpers where useful, but do not make controller children wait for an interactive agent boundary.
+Resource manager child workflows remain on their resource manager scheduler path. Share pure workflow-resolution
+helpers where useful, but do not make resource manager children wait for an interactive agent boundary.
 
 ### 4. Change the start tool
 
@@ -361,7 +361,7 @@ surface.
 ### 8. Update documentation
 
 Update `docs/workflows.md` with the queued start contract, run ID, status, cancellation, failure
-follow-up, and model retry behavior. Update controller-store documentation with the alpha reset rule.
+follow-up, and model retry behavior. Update resource manager store documentation with the alpha reset rule.
 Do not document a v2 schema or migration path.
 
 ## Tests
@@ -438,7 +438,7 @@ copy as the implementation source.
 
 - Do not change Pi or propose a new Pi API.
 - Do not add a service, daemon, remote queue, telemetry endpoint, or second database.
-- Do not preserve old alpha controller-store layouts.
+- Do not preserve old alpha resource manager store layouts.
 - Do not add a migration or v2 schema.
 - Do not add blind automatic workflow retries.
 - Do not change built-in workflow behavior except for test fixtures needed to verify startup.

package/docs/2026-08-25-workflow-follow-ups.md

@@ -32,7 +32,7 @@ Remove an unsent prompt with:
 }
 ```
 
-A model can remove only a prompt added by the same session tool source. A controller can remove only its own prompt. A verified human can remove any unsent prompt in the owned run.
+A model can remove only a prompt added by the same session tool source. A resource manager can remove only its own prompt. A verified human can remove any unsent prompt in the owned run.
 
 Direct commands are also available:
 
@@ -57,7 +57,7 @@ await ctx.workflows.removeFollowUp({
 });
 ```
 
-The host creates the actor and stable request identity. Prompt data cannot claim human or controller authority.
+The server creates the actor and stable request identity. Prompt data cannot claim human or resource manager authority.
 
 ## Ordering and run states
 
@@ -65,25 +65,25 @@ Prompts keep database acceptance order. Several requests can add several prompts
 
 - Running, paused, parked, and waiting workflows accept new prompts.
 - Pause and park keep prompts queued.
-- A checkpoint continuation keeps queued prompt rows attached to the chain member that accepted them. The host walks the continuation chain to determine their final source outcome; it does not rewrite the rows.
+- A checkpoint continuation keeps queued prompt rows attached to the chain member that accepted them. The server walks the continuation chain to determine their final source outcome; it does not rewrite the rows.
 - Successful completion records the terminal run and terminal workflow message before a follow-up can send.
 - Failed, timed-out, and cancelled workflows cancel every unsent prompt.
 - A terminal workflow rejects new prompts. Repeating an earlier request ID can still return its first result.
 
 A repeated request ID with the same prompt returns the first result. Reusing that ID with different content fails.
 
-Each accepted prompt creates its `workflow_follow_ups` source record and one `followUp` workflow message in one transaction. The message points to its source through `sourceId`; the source row stores no message pointer. The host derives eligibility from saved domain facts. A follow-up is eligible only after the source continuation chain completes successfully, its terminal message turn ends, every earlier accepted follow-up is settled or cancelled, and no nonterminal run, including one waiting for a checkpoint or protected decision, reserves the origin session.
+Each accepted prompt creates its `workflow_follow_ups` source record and one `followUp` workflow message in one transaction. The message points to its source through `sourceId`; the source row stores no message pointer. The server derives eligibility from saved domain facts. A follow-up is eligible only after the source continuation chain completes successfully, its terminal message turn ends, every earlier accepted follow-up is settled or cancelled, and no nonterminal run, including one waiting for a checkpoint or protected decision, reserves the origin session.
 
 ## One message path
 
 The shared `WorkflowMessageCoordinator` handles follow-ups. There is no follow-up sender.
 
 1. Wait for the terminal outcome, sent terminal workflow message, and matching model-turn end.
-2. After every host connection, wait for the complete origin-session view and report the active branch.
-3. Wait until the host view names this `followUp` as the next eligible pending message, Pi is idle, and no earlier workflow message is active.
+2. After every server connection, wait for the complete origin-session view and report the active branch.
+3. Wait until the server view names this `followUp` as the next eligible pending message, Pi is idle, and no earlier workflow message is active.
 4. Keep its ID in the coordinator's in-memory queued map and report a matching active-branch entry when one already exists.
 5. Otherwise, recheck synchronously that Pi is idle, has no pending input, the message is absent, and the connection still owns the active coordinator epoch. Call documented `pi.sendMessage()` with the follow-up prompt and `triggerTurn: true` without an `await` between the check and call.
-6. Report the active branch so the host saves the observed Pi entry ID and marks the message `sent`.
+6. Report the active branch so the server saves the observed Pi entry ID and marks the message `sent`.
 7. Wait for that turn and any workflow it starts to finish before the next follow-up becomes eligible.
 
 The follow-up custom message starts normal conversation work and can use a user-style renderer. Its internal workflow message ID stays in custom details and does not enter provider-facing content. It can ask the model to start another workflow, but it cannot resume or reactivate the completed workflow. Text that starts with `/` remains plain model input; a custom message cannot dispatch a Pi slash command or expand a prompt template. A `restart` chosen from the terminal turn creates a separate immutable workflow run.

package/docs/2026-08-25-workflow-settings.md

@@ -108,7 +108,7 @@ await ctx.workflows.changeSettings({
 });
 ```
 
-Each request has a stable host-issued ID. Repeating the same ID and content returns the first result. Reusing an ID with different content fails. When one model response emits several workflow tool calls, the extension applies them in source order so a settings change cannot race past a later step submission.
+Each request has a stable server-issued ID. Repeating the same ID and content returns the first result. Reusing an ID with different content fails. When one model response emits several workflow tool calls, the extension applies them in source order so a settings change cannot race past a later step submission.
 
 `expectedChangeNumber` protects the complete settings value. A JSON Patch `test` operation can protect one field. When no expected number is supplied, the patch applies to the latest saved value in database acceptance order.
 
@@ -127,11 +127,11 @@ The permissions mean:
 
 `read` is not a privacy filter. Workflow code in that scope receives the complete typed settings value.
 
-The host records the actor outside the patch:
+The server records the actor outside the patch:
 
 - `session` for a model workflow-tool call;
 - `human` for a direct command or verified human decision;
-- `controller` for a controller request;
+- `controller` for a resource manager request; this internal version-1 actor value is retained;
 - `policy` only for existing saved policy code.
 
 Patch data cannot claim another actor type.

package/docs/2026-08-30-out-of-process-workflow-host-plan.md

@@ -12,7 +12,7 @@ A live workflow lost its lease while it was still working. The workflow engine k
 
 This plan fixes that failure first, then removes its root architectural cause. One user-level host will own workflow state. Each active run will execute in a supervised child process. Pi will become a client that starts work, presents interactive requests, and submits answers through documented extension APIs.
 
-[Workflow host](WORKFLOW_HOST.md) defines the complete target process, protocol, state, recovery, and Pi integration contracts. This plan gives the implementation order and acceptance checks.
+[Workflow server](WORKFLOW_SERVER.md) defines the complete target process, protocol, state, recovery, and Pi integration contracts. This plan gives the implementation order and acceptance checks.
 
 ## Goals
 
@@ -273,7 +273,7 @@ The host protocol and worker runtime may exist under tests before the final swit
 - Recover a resumable expired run.
 - Stop an uncertain effect for manual review.
 
-### Host and child isolation
+### Server and child isolation
 
 - Block a child event loop longer than the run lease and prove the host keeps ownership.
 - Kill Pi while a run computes.
@@ -333,7 +333,7 @@ Run Pi Reviewer against `main` until no P0 or P1 findings remain. Check pull-req
 - Expired running rows can be resumed or cancelled safely.
 - Pi restart does not lose or falsely fail pending work.
 - An unanswered interactive request keeps its original node deadline, follows its timeout route, and cannot hold a stale session reservation forever.
-- Host restart recovers durable work without duplicate transitions.
+- Server restart recovers durable work without duplicate transitions.
 - Interactive steps still use the origin Pi session.
 - Duplicate commands and submissions return stored receipts.
 - A submission is not accepted until supervised workflow validation succeeds.

package/docs/2026-09-01-restore-session-delivery-controls-plan.md

@@ -10,9 +10,9 @@ date: 2026-09-01
 
 This repair restored the widget, Escape pause, and the first shared sender. Version 0.16.0 still has a model-turn status bug and did not preserve all earlier session features. The approved [workflow-message restoration plan](2026-09-02-unify-workflow-messages-plan.md) replaces separate send records with one workflow-message contract and restores the remaining behavior.
 
-The out-of-process workflow host removed the Pi workflow widget and Escape-to-pause behavior. A later delivery safety fix also caused normal polling to report `Interactive request presentation claim conflict`. This plan restores those features and fixes delivery without bringing back the embedded workflow runtime.
+The out-of-process workflow server removed the Pi workflow widget and Escape-to-pause behavior. A later delivery safety fix also caused normal polling to report `Interactive request presentation claim conflict`. This plan restores those features and fixes delivery without bringing back the embedded workflow runtime.
 
-[Workflow host](WORKFLOW_HOST.md) remains the process and state specification. [Workflow step messages](WORKFLOW_STEP_MESSAGES.md) remains the session message specification. This plan records the cause, scope, implementation order, and acceptance checks for the repair.
+[Workflow server](WORKFLOW_SERVER.md) remains the process and state specification. [Workflow step messages](WORKFLOW_STEP_MESSAGES.md) remains the session message specification. This plan records the cause, scope, implementation order, and acceptance checks for the repair.
 
 ## Observed problems
 
@@ -34,7 +34,7 @@ The coordinator also removes its local queued guard before durable settlement fi
 ## Requirements
 
 - Keep one global host as the normal workflow state writer.
-- Keep workflow and controller code in supervised child processes.
+- Keep workflow and resource manager code in supervised child processes.
 - Use documented Pi extension APIs only.
 - Preserve one ordered session delivery path for steps, decisions, notifications, and final results.
 - Never send through an expired claim.
@@ -92,7 +92,7 @@ The change may update:
 - host pause and resume handling for parked interactions;
 - existing version-1 interaction response fields;
 - focused unit, integration, and live Pi tests;
-- the workflow host and authoring documentation.
+- the workflow server and authoring documentation.
 
 ## Non-goals
 
@@ -125,7 +125,7 @@ The change may update:
 - A paused interaction rejects `update` and `submit`.
 - Resume keeps the same request and allows submission without another prompt.
 - Non-aborted turns and unrelated sessions do not pause the workflow.
-- The extension and host execute no workflow or controller code in their own event loops.
+- The extension and host execute no workflow or resource manager code in their own event loops.
 
 ## Verification
 

package/docs/2026-09-01-unified-workflow-client-plan.md

@@ -37,7 +37,7 @@ These are not independent display defects. The extension, Herdr integration, and
 
 ## Root cause
 
-`WorkflowHostClient` is the authority for commands, but it is not the authority for live views.
+`WorkflowClient` is the authority for commands, but it is not the authority for live views.
 
 The Pi extension opens SQLite twice during one refresh. It first finds the origin session reservation and then loads the run from a second database snapshot. It maps durable workflow state directly to a widget label. The host cannot add exact origin-session model activity to that result.
 
@@ -200,7 +200,7 @@ The widget shows the Herdr hint only when the documented Herdr capability check
 
 ### One live `piw` source
 
-Local `piw` connects to the package-owned host, subscribes to run views, and fetches pages through `pi-workflows.client.v1`. When the socket is absent, Rust may start the host only by executing the installed `pi-workflows host start` command. Rust does not reimplement host launch, locking, epochs, or readiness. If that command is unavailable or fails, `piw` stops with the direct install or startup instruction.
+Local `piw` connects to the package-owned host, subscribes to run views, and fetches pages through `pi-workflows.client.v1`. When the socket is absent, Rust may start the host only by executing the installed `pi-workflows server start` command. Rust does not reimplement host launch, locking, epochs, or readiness. If that command is unavailable or fails, `piw` stops with the direct install or startup instruction.
 
 `piw serve` stops reading SQLite. It becomes a loopback-only WebSocket relay for the same logical protocol. Remote clients continue to use an SSH tunnel. The relay opens one host socket connection for each WebSocket connection and couples their lifecycles one to one. It carries frames only. It does not multiplex clients, translate run state, keep another projection, or retain activity after either side closes.
 
@@ -237,7 +237,7 @@ No migration, compatibility reader, dual protocol, bridge period, or feature fla
 
 ### 2. Make the host the only live database reader
 
-**Location:** `src/host/`, `src/state/`, controller stores, and state maintenance commands.
+**Location:** `src/server/`, `src/state/`, resource manager stores, and state maintenance commands.
 
 **Change:** Add host handlers for atomic origin-session view lookup, run-list and run-view snapshots, revision subscriptions, bounded pages, and active database maintenance. Keep projection reads and writes in the host. A view read must resolve the session reservation, run, durable display facts, and presentation revision from one consistent read boundary. Persist generated large view values in the run-scoped content table under their digest and media type before advertising their references. Do not reuse general state blobs or allow another run to read the content. Store the complete original workflow definition, not its escaped projection. Externalize large replay checkpoints and make both clients resolve them. Route state-changing Pi extension commands through the durable retry path. Give the CLI one stable client identity and one fresh key for each backup or applied prune invocation. Reuse that key only for the invocation's automatic reconnect retry, with a new request ID. Keep an in-flight maintenance operation alive after disconnect, store its accepted or rejected command receipt before response, wait for it during host shutdown, and adopt an exact retry. Wait for socket drain before sending another snapshot, and remove every subscription kind explicitly when its client unsubscribes.
 
@@ -245,7 +245,7 @@ No migration, compatibility reader, dual protocol, bridge period, or feature fla
 
 ### 3. Add the host status reducer and activity overlay
 
-**Location:** a host-owned view module under `src/host/` or `src/viewer/`, with no Pi import.
+**Location:** a host-owned view module under `src/server/` or `src/viewer/`, with no Pi import.
 
 **Change:** Build the `display` object from durable facts and the validated activity overlay. Add connection-scoped activity leases and monotonic sequences. Apply the documented status precedence and allowed-control rules in one function.
 
@@ -255,7 +255,7 @@ No migration, compatibility reader, dual protocol, bridge period, or feature fla
 
 **Location:** `src/extension/session-view.ts`, `src/extension/index.ts`, and the delivery coordinator.
 
-**Change:** Remove all extension imports and construction of `HostStateStore`, `SqliteControllerStore`, `WorkflowRunStore`, and the active state path. Replace `waitForInteractionSubmission`, `pendingInteractionForSession`, `pendingDecision`, `interactionPresentationClaimIsLive`, `hasClaimableNotification`, `hasClaimableTurn`, `terminalRunState`, `sessionRun`, and the widget's two-read refresh with `WorkflowClient` requests or the one origin-session subscription. The `interaction.submit` response supplies the final validation outcome. Report exact delivery activity from documented Pi events and the coordinator's delivery map. Render only the host `display` object. Keep Escape pause tied to the exact active workflow delivery.
+**Change:** Remove all extension imports and construction of `ServerStateStore`, `SqliteResourceManagerStore`, `WorkflowRunStore`, and the active state path. Replace `waitForInteractionSubmission`, `pendingInteractionForSession`, `pendingDecision`, `interactionPresentationClaimIsLive`, `hasClaimableNotification`, `hasClaimableTurn`, `terminalRunState`, `sessionRun`, and the widget's two-read refresh with `WorkflowClient` requests or the one origin-session subscription. The `interaction.submit` response supplies the final validation outcome. Report exact delivery activity from documented Pi events and the coordinator's delivery map. Render only the host `display` object. Keep Escape pause tied to the exact active workflow delivery.
 
 **Verification:** Hold Pi busy longer than both the poll interval and activity lease. The widget stays `running` while refreshed exact activity is live, falls back to `waiting` after activity ends without submission, and shows `paused` only after the host accepts pause. The controlled run produces one visible delivery and one model turn without claiming a universal exactly-once guarantee.
 
@@ -277,7 +277,7 @@ No migration, compatibility reader, dual protocol, bridge period, or feature fla
 
 ### 7. Remove split paths and update documentation
 
-**Location:** old host/replay protocol code, obsolete viewer readers, `docs/WORKFLOW_HOST.md`, `docs/SQLITE_STATE.md`, `docs/live-replay-protocol.md`, README usage, and package contents.
+**Location:** old host/replay protocol code, obsolete viewer readers, `docs/WORKFLOW_SERVER.md`, `docs/SQLITE_STATE.md`, `docs/live-replay-protocol.md`, README usage, and package contents.
 
 **Change:** Delete the superseded request/response and replay contracts, direct live readers, duplicated status reducers, and fallback flags. Update all user commands and architecture diagrams to show the one client stack. Keep inactive backup verification explicitly separate.
 

package/docs/2026-09-02-installed-live-e2e-plan.md

@@ -46,7 +46,7 @@ Each run will use:
 
 Pi will start with `--no-skills`, `--no-themes`, `--no-prompt-templates`, `--no-context-files`, and `--no-builtin-tools`. The runner must not use `--no-extensions`, because that would also disable Pi Workflows.
 
-After startup, the runner will call RPC `get_commands`. The `workflow`, `controller`, and `piw` commands must come from the packed Pi Workflows package. Any other user or project extension is a failure. Base Pi's own inline commands are allowed.
+After startup, the runner will call RPC `get_commands`. The `workflow`, `resource-manager`, and `piw` commands must come from the packed Pi Workflows package. Any other user or project extension is a failure. Base Pi's own inline commands are allowed.
 
 ## Installed package test
 
@@ -96,7 +96,7 @@ The runner will start it through Pi RPC and check the following sequence:
 2. RPC emits `setWidget` and `setStatus` for the `pi-workflows` key with `running` state.
 3. `/workflow pause` is accepted.
 4. The widget and status change to `paused`.
-5. Host status reports one parked run and no active workflow worker.
+5. Server status reports one parked run and no active workflow runner.
 6. `/workflow resume` is accepted.
 7. The widget and status return to `running`.
 8. The workflow completes with the fixed output.
@@ -170,7 +170,7 @@ A real-model run requires explicit provider and model arguments. `--runtime-only
 The standalone runner will own one temporary root and remove it in a `finally` path. It will:
 
 - close the Pi RPC process;
-- stop the workflow host through the installed client;
+- stop the workflow server through the installed client;
 - wait for the host endpoint to disappear;
 - stop child workers started for the smoke workflows;
 - remove the npm consumer installation, sessions, workflow state, and fixture project.

package/docs/2026-09-02-unify-workflow-messages-plan.md

@@ -15,7 +15,7 @@ This change gives the host one saved list of workflow messages that Pi must add
 
 The same change restores the user features removed during the host cut. It keeps one global host, one client protocol, one database, and one production runtime.
 
-[Workflow host](WORKFLOW_HOST.md) remains the process and state specification. [Workflow messages in Pi](WORKFLOW_STEP_MESSAGES.md) remains the Pi message specification. This plan changes both contracts in place.
+[Workflow server](WORKFLOW_SERVER.md) remains the process and state specification. [Workflow messages in Pi](WORKFLOW_STEP_MESSAGES.md) remains the Pi message specification. This plan changes both contracts in place.
 
 ## Current problems
 
@@ -70,9 +70,9 @@ Several reference pages still describe reminders, follow-ups, live settings cont
 
 - Do not restore the embedded workflow executor.
 - Do not let the extension, CLI, or `piw` open live SQLite state.
-- Do not restore per-project hosts or `/controller start` and `/controller stop`.
+- Do not restore per-project hosts or `/resource-manager start` and `/resource-manager stop`.
 - Do not send a workflow prompt into an active model turn.
-- Do not run workflow or controller code in the host event loop.
+- Do not run workflow or resource manager code in the host event loop.
 - Do not change Pi core, private Pi APIs, Pi session files, or Pi session schemas.
 - Do not add another database, service, runtime, compatibility reader, fallback, or feature flag.
 - Do not claim exactly-once model execution.
@@ -227,7 +227,7 @@ The host applies the end and its workflow consequence in one transaction:
 
 The transaction stores one immutable end event, updates activity, and creates or cancels messages together. Repeating the same report adopts that result. A stale or different turn ID cannot end newer activity.
 
-The host clears process-local activity when the client disconnects. Host startup does not close a Pi turn because the host cannot know whether Pi is still working. On `session_start`, the extension reports the active branch before new sends. If Pi is still busy, it reports `started` again with the retained turn ID. Only an idle-session branch report can close an open sent message with synthetic `stopReason: "lost"`. A lost step follows the normal unproductive-turn rule. A lost terminal or follow-up closes without reopening the completed workflow.
+The host clears process-local activity when the client disconnects. Server startup does not close a Pi turn because the host cannot know whether Pi is still working. On `session_start`, the extension reports the active branch before new sends. If Pi is still busy, it reports `started` again with the retained turn ID. Only an idle-session branch report can close an open sent message with synthetic `stopReason: "lost"`. A lost step follows the normal unproductive-turn rule. A lost terminal or follow-up closes without reopening the completed workflow.
 
 ### Display rule
 
@@ -270,7 +270,7 @@ This applies to:
 - cancelled runs;
 - launch failures;
 - claim loss when safe handoff is impossible and the host commits a terminal result;
-- controller interruption.
+- resource manager interruption.
 
 An ordinary claim transfer remains a handoff and creates no terminal message. A stale owner cannot create one.
 
@@ -391,7 +391,7 @@ Restore TypeScript viewer step scrubbing and its one-second elapsed-time redraw.
 - Escape pauses only the exact matching workflow turn.
 - Pause, cancel, answer, update, and submit remain durable host commands.
 - A pending interaction on a paused run rejects update and submit until resume.
-- Workflow and controller code remain in supervised children.
+- Workflow and resource manager code remain in supervised children.
 - Side effects remain idempotent or explicitly ambiguous.
 - `/piw`, `Ctrl+Shift+R`, Herdr placement, and widget scrolling remain available.
 - Local and remote `piw` use the same client protocol and exact run view.
@@ -455,7 +455,7 @@ The later status work binds only to `workflow_messages`. Do not implement a temp
 
 ### Update reference documentation
 
-Update [Workflow host](WORKFLOW_HOST.md), [Workflow messages in Pi](WORKFLOW_STEP_MESSAGES.md), [SQLite state](SQLITE_STATE.md), [Live client protocol](live-replay-protocol.md), [Deferred workflow turns](DEFERRED_TURNS.md), [workflow follow-ups](2026-08-25-workflow-follow-ups.md), [workflow settings](2026-08-25-workflow-settings.md), [Human decisions](HUMAN_DECISIONS.md), [Human decision presentations](HUMAN_DECISION_PRESENTATIONS.md), [Session event journal](session-event-journal.md), [Rust TUI viewer](tui-viewer.md), the earlier host plans, the authoring reference, and README to match the implementation.
+Update [Workflow server](WORKFLOW_SERVER.md), [Workflow messages in Pi](WORKFLOW_STEP_MESSAGES.md), [SQLite state](SQLITE_STATE.md), [Live client protocol](live-replay-protocol.md), [Deferred workflow turns](DEFERRED_TURNS.md), [workflow follow-ups](2026-08-25-workflow-follow-ups.md), [workflow settings](2026-08-25-workflow-settings.md), [Human decisions](HUMAN_DECISIONS.md), [Human decision presentations](HUMAN_DECISION_PRESENTATIONS.md), [Session event journal](session-event-journal.md), [Rust TUI viewer](tui-viewer.md), the earlier host plans, the authoring reference, and README to match the implementation.
 
 Remove temporary current-version warnings only after live checks pass.
 
@@ -498,7 +498,7 @@ Remove temporary current-version warnings only after live checks pass.
 - Pause and resume a presented step and receive one step message with reason `resumed`.
 - Prove initial, reminder, and resumed prompts use the same message kind, contract, attempt identity, eligibility, and recovery path.
 - Prove the partial unique index allows at most one pending step message per request for every reason.
-- Complete, fail, time out, cancel, fail launch without recoverable handoff, and interrupt through a controller; receive one terminal turn in each case.
+- Complete, fail, time out, cancel, fail launch without recoverable handoff, and interrupt through a resource manager; receive one terminal turn in each case.
 - Settle a checkpoint parent through a continuation and prove only the final chain leaf gets a terminal turn.
 - Restart safely, reject a fourth restart, and reject a repeated terminal fingerprint.
 - Queue and remove follow-ups, then send remaining prompts once in order without pointer deadlock.