@osolmaz/pi-workflows 0.16.2 → 0.16.3

package/dist/workflows/types.d.ts

@@ -78,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>);
@@ -808,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.

package/docs/2026-09-04-workflow-run-state-plan.md

@@ -63,7 +63,7 @@ Cancellation and terminal-message creation currently share a transaction path. I
 
 The compiler assigns complete node paths. The engine uses those paths to identify logical work. Child workflows can receive a local view of inputs and outputs, but that local view cannot replace the compiled identity.
 
-The host state store owns every durable transition. Host orchestration code asks the store to start, pause, finish, cancel, or recover work. It does not update lifecycle tables directly.
+The host state store owns every durable transition. Server orchestration code asks the store to start, pause, finish, cancel, or recover work. It does not update lifecycle tables directly.
 
 The worker receives one explicit command and executes it. It does not infer the command from nullable fields.
 
@@ -210,13 +210,13 @@ Update authoring docs and all built-in workflows in the same change. Keep no ali
 
 ### Make worker commands explicit
 
-Add the tagged run command to `src/host/worker-protocol.ts`, the host bootstrap response, and `src/host/worker-entry.ts`.
+Add the tagged run command to `src/server/workflow-runner-protocol.ts`, the host bootstrap response, and `src/server/workflow-runner-entry.ts`.
 
 Replace the `initialized` and `parentRunId` dispatch heuristic with an exhaustive command switch. Add the engine path for a fresh restart and keep checkpoint continuation separate. Remove the superseded dispatch code.
 
 ### Centralize durable transitions
 
-Move direct lifecycle SQL from `src/host/runner.ts` into typed store operations in the state and workflow-store modules. Replace ambiguous boolean returns used by run failure and cancellation with typed results.
+Move direct lifecycle SQL from `src/server/runner.ts` into typed store operations in the state and workflow-store modules. Replace ambiguous boolean returns used by run failure and cancellation with typed results.
 
 Keep claim fencing and revision checks in each state transaction. The runner handles process supervision and protocol routing only.
 
@@ -256,7 +256,7 @@ Do not keep feature flags or fallback behavior.
 
 ### Update documentation
 
-Update `WORKFLOW_HOST.md`, `SQLITE_STATE.md`, and `workflows.md` after implementation so they describe the shipped interfaces and recovery behavior. Keep this plan as the decision and implementation record.
+Update `WORKFLOW_SERVER.md`, `SQLITE_STATE.md`, and `workflows.md` after implementation so they describe the shipped interfaces and recovery behavior. Keep this plan as the decision and implementation record.
 
 ## Tests
 
@@ -284,7 +284,7 @@ Update `WORKFLOW_HOST.md`, `SQLITE_STATE.md`, and `workflows.md` after implement
 - A later reconciliation creates the missing terminal message once.
 - Terminalization ends open turns and pending interactions in the same state transaction.
 
-### Worker recovery
+### Runner recovery
 
 - A worker crash after a newer durable revision resumes safely.
 - A worker crash at the same revision parks once and does not relaunch.
@@ -316,7 +316,7 @@ Automated tests use temporary directories and deterministic providers. They do n
 - A terminal run has no open workflow turn.
 - Later ordinary Pi turns cannot attach to terminal workflow work.
 - No raw SQLite uniqueness or media-type error reaches normal recovery paths.
-- Host, extension, widget, CLI, Herdr, and `piw` agree on run activity.
+- Server, extension, widget, CLI, Herdr, and `piw` agree on run activity.
 - Pi core and private Pi APIs remain unchanged. Pi session schemas also remain unchanged.
 - One host and one database remain. The system keeps one client protocol and one production runtime.
 

package/docs/DEFERRED_TURNS.md

@@ -1,6 +1,6 @@
 # Terminal workflow messages
 
-This specification defines the final Pi message for an interactive workflow. It replaces the separate deferred-turn and `workflow_turn_intents` design. Terminal messages use the same host state, client operations, and extension coordinator as all other [workflow messages](WORKFLOW_STEP_MESSAGES.md).
+This specification defines the final Pi message for an interactive workflow. It replaces the separate deferred-turn and `workflow_turn_intents` design. Terminal messages use the same server state, client operations, and extension coordinator as all other [workflow messages](WORKFLOW_STEP_MESSAGES.md).
 
 The earlier [deferred-turn plan](plans/2026-08-21-deferred-turn-intents-plan.md) and [terminal restart plan](plans/2026-08-27-workflow-terminal-restart-plan.md) remain historical design records. This document is the current contract.
 
@@ -14,7 +14,7 @@ The earlier [deferred-turn plan](plans/2026-08-21-deferred-turn-intents-plan.md)
 
 ## Core rule
 
-The host creates one `terminal` workflow message in the same transaction that records the final terminal outcome. Only the final run in a continuation chain creates this message. A parent settled by a continuation does not create one.
+The server creates one `terminal` workflow message in the same transaction that records the final terminal outcome. Only the final run in a continuation chain creates this message. A parent settled by a continuation does not create one.
 
 The terminal message uses the same `workflow_messages` table and `WorkflowMessageCoordinator` as steps, decisions, notifications, and follow-ups. Initial, reminder, and resumed prompts are one step-message kind. There is no `workflow_turn_intents` table, deferred-turn sender, terminal sender, or second send path.
 
@@ -28,9 +28,9 @@ A terminal message can report:
 - workflow failure;
 - timeout with no recovery edge;
 - cancellation;
-- launch or worker failure that became the final run outcome.
+- launch or runner failure that became the final run outcome.
 
-Pause, Escape, a waiting checkpoint, a nonfinal continuation parent, user hold, and normal host shutdown do not create a terminal message.
+Pause, Escape, a waiting checkpoint, a nonfinal continuation parent, user hold, and normal server shutdown do not create a terminal message.
 
 A claim loss is a handoff. It creates no terminal outcome or terminal message unless later recovery proves that the run itself failed.
 
@@ -48,15 +48,15 @@ A terminal workflow message is open only until its first model turn ends. The ex
 
 The end report includes `stopReason: "completed"`, `"aborted"`, or `"error"`. Response-entry evidence comes from `ctx.sessionManager.getBranch()` after `agent_end` and can be null. A repeated report adopts the stored result. A stale turn ID cannot end a newer turn.
 
-If Pi restarts after a terminal message was sent but before its end was reported, the extension's idle-session active-branch report records a synthetic end with `stopReason: "lost"`. Host restart alone does not close the turn. The terminal result remains durable and visible, but the host does not pretend that the model turn completed.
+If Pi restarts after a terminal message was sent but before its end was reported, the extension's idle-session active-branch report records a synthetic end with `stopReason: "lost"`. Server restart alone does not close the turn. The terminal result remains durable and visible, but the server does not pretend that the model turn completed.
 
 ## Sending and recovery
 
-After every host connection, the coordinator waits for the complete origin-session view and reports the active branch before it sends a workflow message or reports a model turn. The host gives the next eligible pending message only to the active coordinator epoch for that session. A replacement connection fences the old one.
+After every server connection, the coordinator waits for the complete origin-session view and reports the active branch before it sends a workflow message or reports a model turn. The server gives the next eligible pending message only to the active coordinator epoch for that session. A replacement connection fences the old one.
 
 The coordinator waits until Pi is idle and has no pending messages. It keeps the terminal workflow message ID in its in-memory queued map, checks the active branch, and reports a matching entry before any send. Otherwise, it performs one final synchronous check that Pi is idle, has no pending input, the message is absent, and its connection still owns the active epoch. It calls documented `pi.sendMessage()` without an `await` between that check and the call.
 
-A matching hidden workflow message ID in the active branch proves that Pi accepted the message. The host records the matching Pi entry ID and changes the message to `sent`, even if its source cancelled it after the send. If the extension reloads, it reports the active branch and adopts that entry before another send.
+A matching hidden workflow message ID in the active branch proves that Pi accepted the message. The server records the matching Pi entry ID and changes the message to `sent`, even if its source cancelled it after the send. If the extension reloads, it reports the active branch and adopts that entry before another send.
 
 Absence is usable only when all three facts are true:
 

package/docs/DESIGN_PHILOSOPHY.md

@@ -38,7 +38,7 @@ Reading shared state never gives mutation authority. Every durable write checks
 
 ## Boundaries
 
-The workflow engine stays independent of Pi. The Pi extension hosts the engine and connects it to a conversation. Controllers manage durable external resources. Viewers read recorded state without changing it.
+The workflow engine stays independent of Pi. The Pi extension servers the engine and connects it to a conversation. Controllers manage durable external resources. Viewers read recorded state without changing it.
 
 Keep these layers separate and connect them through small public interfaces.
 

package/docs/HUMAN_DECISIONS.md

@@ -168,7 +168,7 @@ The accepted human sources are:
 - the Pi interactive decision view; and
 - a configured external decision channel such as Telegram.
 
-The host assigns the source. A workflow or model cannot claim that an answer came from a person. Pi non-interactive modes can wait for Telegram, but they cannot manufacture a Pi UI answer.
+The server assigns the source. A workflow or model cannot claim that an answer came from a person. Pi non-interactive modes can wait for Telegram, but they cannot manufacture a Pi UI answer.
 
 ## Audiences and channel profiles
 
@@ -199,7 +199,7 @@ Private configuration maps the audience to channels:
 }
 ```
 
-The workflow never receives a bot token, user ID, chat ID, Telegram message ID, or Pi session detail. Channel profiles are private host configuration and are excluded from run presentation.
+The workflow never receives a bot token, user ID, chat ID, Telegram message ID, or Pi session detail. Channel profiles are private server configuration and are excluded from run presentation.
 
 pi-workflows keeps credential references in a separate private file. A Telegram credential points to an existing absolute mode-`0600` token file:
 
@@ -222,7 +222,7 @@ The same Unix account can read a local credential file. This design prevents acc
 
 ## Channel interface
 
-The host owns decision state and launches each external channel adapter as a supervised child process. The private child protocol has these message kinds:
+The server owns decision state and launches each external channel adapter as a supervised child process. The private child protocol has these message kinds:
 
 - `channel.ready`;
 - `channel.present`;
@@ -230,15 +230,15 @@ The host owns decision state and launches each external channel adapter as a sup
 - `channel.settle`; and
 - `channel.exiting`.
 
-Each message names the adapter epoch, channel profile, saved request or settlement record, expected revision, and stable attempt ID. The host validates and saves every state change. The child never opens SQLite, loads workflow code, changes a run directly, receives the canonical decision subject, or receives another channel's credentials.
+Each message names the adapter epoch, channel profile, saved request or settlement record, expected revision, and stable attempt ID. The server validates and saves every state change. The child never opens SQLite, loads workflow code, changes a run directly, receives the canonical decision subject, or receives another channel's credentials.
 
 Channel handling is independent from workflow routing. A failed Telegram send leaves the decision available in Pi. Audience policy decides whether one successful channel is enough or whether all configured channels must receive the request.
 
 ### Pi channel
 
-The host creates one `decision` workflow message for the origin session. The shared extension coordinator shows it through documented `pi.sendMessage()` with no model turn. The message lists the request ID, choices, input rule, and deadline. It uses no blocking Pi dialog and no private Pi API.
+The server creates one `decision` workflow message for the origin session. The shared extension coordinator shows it through documented `pi.sendMessage()` with no model turn. The message lists the request ID, choices, input rule, and deadline. It uses no blocking Pi dialog and no private Pi API.
 
-A verified operator answers with `/workflow answer` or the matching `piw` control. The host validates the choice and optional text, records the Pi channel as the source, and accepts only the first valid winner. Closing or reloading Pi cannot lose the request. On `session_start` or `session_tree`, the extension adopts an existing decision message or creates one new `decision` message when the pending request has no entry on the active branch.
+A verified operator answers with `/workflow answer` or the matching `piw` control. The server validates the choice and optional text, records the Pi channel as the source, and accepts only the first valid winner. Closing or reloading Pi cannot lose the request. On `session_start` or `session_tree`, the extension adopts an existing decision message or creates one new `decision` message when the pending request has no entry on the active branch.
 
 ### Telegram channel
 
@@ -252,11 +252,11 @@ A choice without input submits from its button. A text choice such as `replan` w
 4. the adapter verifies the numeric user ID, chat ID, reply message ID, decision ID, and request digest; and
 5. the exact received text becomes `input.instructions`.
 
-The adapter does not infer a choice from ordinary chat text. Callback payloads contain short opaque IDs because Telegram limits callback data. The host's channel records map each opaque ID to the validated decision request. Credentials remain outside the database and reach only the matching supervised adapter child.
+The adapter does not infer a choice from ordinary chat text. Callback payloads contain short opaque IDs because Telegram limits callback data. The server's channel records map each opaque ID to the validated decision request. Credentials remain outside the database and reach only the matching supervised adapter child.
 
-Telegram permits one long-polling consumer for a bot profile. The global host starts at most one adapter child for that profile and keeps the package-owned on-demand host process alive while an external decision is pending. No Pi process or adapter child owns a SQLite lease. If the host stops, the next Pi, CLI, or `piw` client starts it and the host recovers the saved channel state before it starts another adapter child. This design installs no operating-system service.
+Telegram permits one long-polling consumer for a bot profile. The global server starts at most one adapter child for that profile and keeps the package-owned on-demand server process alive while an external decision is pending. No Pi process or adapter child owns a SQLite lease. If the server stops, the next Pi, CLI, or `piw` client starts it and the server recovers the saved channel state before it starts another adapter child. This design installs no operating-system service.
 
-The Bot API does not provide an idempotency key for `sendMessage`. Before it tells the adapter to send or settle a message, the host records the exact attempt in `effects` and `effect_attempts`. A confirmed Telegram message ID settles the effect and remains in its result. A timed-out, disconnected, or interrupted exact attempt with no proof becomes `ambiguous` and is not retried automatically. Pi remains available while the operator checks Telegram and explicitly confirms or retries the operation. This prevents blind duplicate sends without claiming exactly-once Telegram behavior.
+The Bot API does not provide an idempotency key for `sendMessage`. Before it tells the adapter to send or settle a message, the server records the exact attempt in `effects` and `effect_attempts`. A confirmed Telegram message ID settles the effect and remains in its result. A timed-out, disconnected, or interrupted exact attempt with no proof becomes `ambiguous` and is not retried automatically. Pi remains available while the operator checks Telegram and explicitly confirms or retries the operation. This prevents blind duplicate sends without claiming exactly-once Telegram behavior.
 
 ## Durable decision records
 
@@ -328,7 +328,7 @@ Adoption does not change the lease, claim generation, queue state, timestamps, o
 
 This alpha change updates the current request, accepted-result, receipt, resolution, continuation, and snapshot contracts in place. Old active runs refuse resume through normal source and definition identity checks. There is no compatibility reader, migration, dual path, or new schema generation. The continuation startup fix uses existing queue and lease records. It adds no field, table, migration, or schema version. Existing compatible prepared or initialized continuations are adopted. Updated viewers label a human decision as a checkpoint, show its deadline and automatic action when present, and keep the canonical subject separate. Private channel configuration and transport identifiers remain hidden.
 
-The engine remains independent from Pi and Telegram. Core code owns decision contracts and validation. The host owns durable acceptance, continuation, workflow messages, and channel-child supervision. The Pi extension owns documented session presentation and controls. The Telegram adapter child owns Bot API translation. Workflow definitions own only the question, choices, audience, and routes.
+The engine remains independent from Pi and Telegram. Core code owns decision contracts and validation. The server owns durable acceptance, continuation, workflow messages, and channel-child supervision. The Pi extension owns documented session presentation and controls. The Telegram adapter child owns Bot API translation. Workflow definitions own only the question, choices, audience, and routes.
 
 ## Contract impact
 
@@ -360,7 +360,7 @@ The implementation must test:
 - identical and conflicting retries;
 - crashes before and after answer acceptance and continuation creation;
 - ambiguous Telegram sends;
-- one supervised long-poll adapter per profile and host-restart recovery;
+- one supervised long-poll adapter per profile and server-restart recovery;
 - decision cancellation and expiry;
 - included `plan-approval` routes and bounded replan loops;
 - viewer redaction; and