@osolmaz/pi-workflows 0.16.2 → 0.16.4

package/docs/plans/2026-08-05-always-on-workflows-plan.md

@@ -10,7 +10,7 @@ status: implemented
 
 pi-workflows should feel the same whether the user watches a run or walks away from it. In the user's words: "I might start a workflow locally in Pi then I wait for it to complete. All the while I am looking at the screen and I'm not closing the Pi window. When the workflow ends I just want to be able to continue the same Pi session like normal with a session up to date with what happened in the workflow." And: "I just want to interact by starting a workflow, closing it, and then coming back and then still being able to continue it when I open it up. It's syncing continuously or something."
 
-These are not two modes. The user asked for "both in a single unified system." This plan makes the Pi window irrelevant to execution: closing or opening the window is a change in observation, not in the run. The work stays on one machine, uses the merged controller runtime as its foundation, and does not modify Pi core.
+These are not two modes. The user asked for "both in a single unified system." This plan makes the Pi window irrelevant to execution: closing or opening the window is a change in observation, not in the run. The work stays on one machine, uses the merged resource manager runtime as its foundation, and does not modify Pi core.
 
 This revision incorporates an external design review of the first draft. The review confirmed the three design rules and found five structural gaps in the details. The Decisions section resolves each one before implementation starts.
 
@@ -23,7 +23,7 @@ Four rules define the system:
 3. **The session is always a view.** It attaches to a run's event stream and renders it. An open window sees a live tail; a reopened window catches up from the same stream. Interaction such as approvals uses durable waiting states, never prompts tied to the window's lifetime.
 4. **Claims arbitrate every lifecycle decision.** Only the current claim holder may resume, interrupt, or write a terminal event for a run. Recovery code that finds an abandoned run goes through the queue instead of writing to the bundle directly.
 
-The controller runtime already provides most of the machinery: a deduplicated queue with expiring claims, a structured event table, crash recovery through the trace tail, and guarded effect records. This plan extends that treatment to runs the user starts interactively and adds the view layer.
+The resource manager runtime already provides most of the machinery: a deduplicated queue with expiring claims, a structured event table, crash recovery through the trace tail, and guarded effect records. This plan extends that treatment to runs the user starts interactively and adds the view layer.
 
 ## Decisions
 
@@ -31,8 +31,8 @@ These points were open in the first draft. External review showed each one is lo
 
 1. **Write fencing on bundles.** Every claim records a runner ID, a token, and a lease expiry in the store. Every bundle write verifies the token inside the run lock before appending and fails the runner fast when the token no longer matches. Expiring claims alone do not stop a stalled runner from writing; fencing does.
 2. **Explicit resume protocol.** Resume is a named operation, not a restart. It truncates a torn trace tail to the last complete line, rebuilds run state from the trace, seeds the trace sequence from the tail, accounts for already-executed steps against the step limit, and records a resume boundary event before continuing.
-3. **Resume scope.** User-started runs get node-level resume. Controller child runs keep their current new-attempt semantics, because attempt immutability and parent-side retry already work and are tested. Both behaviors are explicit; nothing mixes silently.
-4. **A dedicated run queue.** Interactive runs do not fit the controller queue, which is keyed to controller resources. A new `workflow_run_queue` table shares the claim, lease, and fencing pattern and adds runner affinity fields. Runs stay out of `/controller list`.
+3. **Resume scope.** User-started runs get node-level resume. ResourceManager child runs keep their current new-attempt semantics, because attempt immutability and parent-side retry already work and are tested. Both behaviors are explicit; nothing mixes silently.
+4. **A dedicated run queue.** Interactive runs do not fit the controller queue, which is keyed to managed resources. A new `workflow_run_queue` table shares the claim, lease, and fencing pattern and adds runner affinity fields. Runs stay out of `/resource-manager list`.
 5. **Origin affinity.** An interactively started run is inserted and claimed in one transaction, so the session that started it owns it from birth. The standalone host takes over only when that claim is released or expires. This guarantees a watched run's conversation happens in the watching session.
 6. **Close-to-park shutdown.** `session_shutdown` stops writing a terminal cancel event for queued runs. It aborts in-flight work without a terminal event and releases the claim, leaving a resumable bundle. A clean close releases claims explicitly; a crash relies on lease expiry.
 7. **Per-attempt capture.** Session capture becomes segmented per attempt, keyed by attempt ID, so a run handed off to the host or a new session starts a fresh capture segment instead of failing integrity checks.
@@ -40,7 +40,7 @@ These points were open in the first draft. External review showed each one is lo
 9. **Source pinning.** The manifest stores a content hash of the workflow source at run start. Resume refuses to continue against changed source unless forced, and a forced resume records the mismatch in the trace.
 10. **Snapshot catch-up.** Notifications are idempotent snapshots of run state as of a store sequence number, recomputed from the store, not a stream of one-off messages. The watermark persists per session before sending. A skipped incremental notification is subsumed by the next snapshot.
 11. **A run-level event feed.** Run lifecycle transitions write rows into a store table, so one watermark covers both controller and run events. Tailing `trace.ndjson` is reserved for the single actively watched run.
-12. **Store-error backoff.** Worker loops treat store errors such as `SQLITE_BUSY` as transient and back off instead of letting a worker die silently. The host's advisory lock guards host-versus-host only; the embedded runner does not take it, and a second host refuses to start.
+12. **Store-error backoff.** Runner loops treat store errors such as `SQLITE_BUSY` as transient and back off instead of letting a worker die silently. The host's advisory lock guards host-versus-host only; the embedded runner does not take it, and a second host refuses to start.
 13. **Orphan reaping.** The host spawns `pi --mode rpc` children in their own process group, records child PIDs in the bundle, and reaps known orphans on startup. Consequential actions stay behind guarded effects regardless.
 
 ## Requirements
@@ -55,11 +55,11 @@ These points were open in the first draft. External review showed each one is lo
 ## Work items
 
 1. **Run queue and fencing.** Add the `workflow_run_queue` table with claim tokens, lease expiry, and runner affinity. Gate every bundle write on the token inside the run lock. Insert-and-claim interactive starts in one transaction.
-2. **Node-level resume.** Implement the explicit resume protocol from Decision 2, with source pinning from Decision 9. User-started runs resume at the interrupted node; controller child runs are untouched.
+2. **Node-level resume.** Implement the explicit resume protocol from Decision 2, with source pinning from Decision 9. User-started runs resume at the interrupted node; resource manager child runs are untouched.
 3. **Close-to-park and capture segments.** Change `session_shutdown` to abort-without-terminal plus claim release for queued runs. Split session capture into per-attempt segments the integrity checker understands.
 4. **Continuation runs.** Chain an answered checkpoint to a new run ID with a parent link and carried-forward outputs. Render the chain as one logical run in views.
 5. **Session sync.** Add the run-level event feed, per-session watermarks, snapshot catch-up on `session_start`, and noteworthy-event messages. Live watching tails `trace.ndjson` from a remembered byte offset with `fs.watch`, reusing the TUI viewer's file-tail path.
-6. **Standalone host.** A `pi-workflows` CLI subcommand loads controller definitions, opens the project store, and runs claiming in a loop with store-error backoff. Conversation child nodes run in spawned headless `pi --mode rpc` sessions with orphan reaping. The host takes an advisory lock against other hosts, drains on SIGTERM, and recovers on restart. It is a foreground process the user runs in a terminal; it is not a service.
+6. **Standalone host.** A `pi-workflows` CLI subcommand loads resource manager definitions, opens the project store, and runs claiming in a loop with store-error backoff. Conversation child nodes run in spawned headless `pi --mode rpc` sessions with orphan reaping. The host takes an advisory lock against other hosts, drains on SIGTERM, and recovers on restart. It is a foreground process the user runs in a terminal; it is not a service.
 
 ## Non-goals
 
@@ -89,7 +89,7 @@ The implementation matches the decisions above with these refinements:
 - Graph validation now allows outgoing edges from checkpoint nodes. The old
   rejection encoded terminal-forever checkpoints; continuations make those
   edges live. This is a deliberate contract change for workflow authors.
-- The host command is `pi-workflows host`, chosen over `run` because the
+- The host command is `pi-workflows server`, chosen over `run` because the
   viewer CLI's vocabulary already uses runs for bundles.
 - The first capture stays flat at `session/`; only binds from the second
   recorder onward write segments under `session/segments/`. This keeps the

package/docs/plans/2026-08-10-agent-managed-monitor-workflows-plan.md

@@ -118,7 +118,7 @@ The report nodes write a normal assistant message and then submit an acknowledge
 
 The sleep node uses the existing pi-workflows shell action to launch the current Node executable with a timer. Set the node timeout above the largest supported interval because the engine default is 15 minutes. Set the shell execution timeout above the requested wait by a small fixed margin. Cancellation aborts the timer process immediately.
 
-If the Pi TUI or standalone workflow host stops during sleep, pi-workflows parks the run and kills the shell child. Resuming the run starts that sleep node again from the beginning. This is existing workflow behavior and is acceptable for this feature. No special timer persistence is added.
+If the Pi TUI or standalone workflow server stops during sleep, pi-workflows parks the run and kills the shell child. Resuming the run starts that sleep node again from the beginning. This is existing workflow behavior and is acceptable for this feature. No special timer persistence is added.
 
 The workflow uses a high but finite `maxSteps` value as a second safety guard. Check and report values have explicit size limits so a long run cannot grow its bundle without bound.
 
@@ -145,7 +145,7 @@ After the upstream change is complete, update the pinned pi-workflows commit in
 
 ## Non-goals
 
-This work does not add cron expressions, calendar schedules, a background service, controller resources, OS notifications, concurrent workflows in one session, resumable shell processes, or guaranteed wall-clock wake times across runner shutdowns. It does not let headless child agents recursively start workflows.
+This work does not add cron expressions, calendar schedules, a background service, managed resources, OS notifications, concurrent workflows in one session, resumable shell processes, or guaranteed wall-clock wake times across runner shutdowns. It does not let headless child agents recursively start workflows.
 
 ## Acceptance criteria
 

package/docs/plans/2026-08-13-session-addressed-workflow-notifications-plan.md

@@ -23,7 +23,7 @@ pi-workflows must not send one workflow's report into an unrelated conversation.
 
 ## Data model
 
-Queue records gain an optional `origin_session_id`. Interactive runs set it from `ctx.sessionManager.getSessionId()`. Controller-created detached runs leave it empty. A session runner can claim a record only when the origin is empty or matches its current session. The standalone host can claim either form.
+Queue records gain an optional `origin_session_id`. Interactive runs set it from `ctx.sessionManager.getSessionId()`. ResourceManager-created detached runs leave it empty. A session runner can claim a record only when the origin is empty or matches its current session. The standalone host can claim either form.
 
 A `workflow_notifications` table is the durable outbox:
 

package/docs/plans/2026-08-16-workflow-updates-plan.md

@@ -108,9 +108,9 @@ New interactive agent-step instructions become `pi-workflows-agent-step` custom
 
 Existing user-message entries remain readable and are not rewritten. No private Pi entry type, Pi schema change, or separate persistent store is introduced.
 
-### Controller storage
+### ResourceManager storage
 
-The controller database schema does not change for the first implementation. Controllers publish only through a claimed workflow run. Controller-native status remains in controller resources.
+The controller database schema does not change for the first implementation. Controllers publish only through a claimed workflow run. ResourceManager-native status remains in managed resources.
 
 ## Public API impact
 
@@ -177,7 +177,7 @@ Files expected to change:
 - `src/workflows/shell.ts`
 - `src/extension/workflow-tool.ts`
 - `src/extension/index.ts`
-- `src/host/rpc-executor.ts`
+- `src/server/rpc-executor.ts`
 - `test/extension.test.ts`
 - `test/workflow-args.test.ts`
 - `test/e2e/workflow.e2e.test.ts`
@@ -282,7 +282,7 @@ Files expected to change:
 - `src/extension/executor.ts`
 - `src/extension/index.ts`
 - `src/extension/` message-renderer module
-- `src/host/rpc-executor.ts`
+- `src/server/rpc-executor.ts`
 - `test/executor.test.ts`
 - `test/extension.test.ts`
 - `test/e2e/workflow.e2e.test.ts`
@@ -491,4 +491,4 @@ Before any run publishes an update, rollback is an exact dependency pin to `0.5.
 
 ## Follow-up boundary
 
-A truly indefinite monitor belongs in the controller runtime. This plan keeps the finite workflow safety ceiling and does not hide it behind a huge number or automatic restart. A later controller resource may use the same update and progress contracts alongside the notification and viewer contracts.
+A truly indefinite monitor belongs in the resource manager runtime. This plan keeps the finite workflow safety ceiling and does not hide it behind a huge number or automatic restart. A later managed resource may use the same update and progress contracts alongside the notification and viewer contracts.

package/docs/plans/2026-08-19-human-decision-gates-plan.md

@@ -60,7 +60,7 @@ Pi and Telegram implement one channel interface. Workflows address a named audie
 - Reject stale responses by decision ID and canonical request digest.
 - Rebuild the pending-decision index from immutable records.
 
-### Host and channels
+### Server and channels
 
 - Add a `HumanDecisionChannel` interface outside the engine layer.
 - Add a Pi channel using documented TUI APIs.

package/docs/plans/2026-08-20-bounded-command-batches-plan.md

@@ -63,7 +63,7 @@ The helper does not interpret repository, review, CI, or test results. Autoimple
 
 ## Cancellation and interruption
 
-The workflow action passes its abort signal to the helper. An abort stops active process groups through the existing `runShellAction` SIGTERM and bounded SIGKILL path. Workers do not start queued items after the abort.
+The workflow action passes its abort signal to the helper. An abort stops active process groups through the existing `runShellAction` SIGTERM and bounded SIGKILL path. Runners do not start queued items after the abort.
 
 Accepted batch outputs use the existing run trace and artifact files. Large strings use normal artifact externalization.
 

package/docs/plans/2026-08-21-deferred-turn-intents-plan.md

@@ -62,7 +62,7 @@ Fallback eligibility is separate from pending state. An intent can remain pendin
 | Terminal workflow failure after an active turn abort         | Yes              | No                                | Terminal handling updates the existing intent and makes it eligible.                                      |
 | Workflow reports started, then crashes asynchronously        | Yes              | Yes, after durable failure        | Covers failures before the first workflow prompt, including invalid runtime input discovered after start. |
 | Queued launch activation fails                               | Yes              | Yes, after durable launch failure | Replaces the `launch_failure` notification trigger.                                                       |
-| Controller stops an active workflow agent turn               | Yes              | No                                | Terminal or handoff policy decides eligibility.                                                           |
+| ResourceManager stops an active workflow agent turn          | Yes              | No                                | Terminal or handoff policy decides eligibility.                                                           |
 | Queue claim is lost during an active agent turn              | Yes              | No                                | Treat as ownership transfer, not failure.                                                                 |
 | Completed or waiting run has a presentation                  | No new intent    | Not applicable                    | The presentation resolves an existing intent when present.                                                |
 | Direct `/workflow cancel`                                    | No               | Not applicable                    | The user explicitly requested control and no automatic model turn.                                        |
@@ -74,7 +74,7 @@ A later distinct event can create a new intent. Repeated handling of the same so
 
 ## Storage
 
-Add `workflow_turn_intents` to the existing `SqliteControllerStore` database. Keep the database path and `pi-workflows.controller-store.v1` schema identifier.
+Add `workflow_turn_intents` to the existing `SqliteResourceManagerStore` database. Keep the database path and `pi-workflows.controller-store.v1` schema identifier.
 
 The existing `workflow_notifications` table remains a passive outbox for workflow-authored `progress` and `final` reports. It cannot represent this lifecycle clearly because it has one delivery transition and identifies node notification output. Adding natural resolution, fallback eligibility, and competing claims to that table would mix two different contracts.
 
@@ -316,7 +316,7 @@ Do not publish a package or create a release without separate authorization.
 ## Contract impact
 
 - **Session state:** internal workflow messages gain an optional `turnIntentId`; fallback uses `pi-workflows-deferred-turn`.
-- **Controller storage:** add `workflow_turn_intents`; restrict workflow notifications to passive `progress` and `final` kinds.
+- **ResourceManager storage:** add `workflow_turn_intents`; restrict workflow notifications to passive `progress` and `final` kinds.
 - **Run bundles:** unchanged.
 - **Workflow engine:** unchanged.
 - **Workflow author API:** unchanged.

package/docs/plans/2026-08-21-sanity-check-plan.md

@@ -138,7 +138,7 @@ Children receive only the built-in read-only tool instances requested by Sanity
 Children receive no:
 
 - `workflow` tool;
-- `/workflow`, `/piw`, `/controller`, or workflow-channel command;
+- `/workflow`, `/piw`, `/resource-manager`, or workflow-channel command;
 - run, node, or attempt identifier;
 - workflow update, answer, submit, pause, resume, or cancel callback;
 - child workflow run or parent workflow handle.
@@ -239,7 +239,7 @@ Unit and integration tests must cover:
 - serial two-session and parallel five-session behavior;
 - existing progress keys, model labels, throttling, and rendering;
 - interactive Pi with normal extensions enabled and the local mock provider;
-- standalone `WorkflowHost` through the same private runtime path;
+- standalone `WorkflowServer` through the same private runtime path;
 - no child session files or child workflow runs;
 - built-in revision 4 and historical terminal run reading;
 - one full detailed assistant response followed by one short plain-language assistant response;

package/docs/plans/2026-08-23-assistant-agent-completion-plan.md

@@ -300,13 +300,13 @@ Add an executor capability that distinguishes:
 
 The interactive Pi executor supports assistant completion.
 
-A detached WorkflowHost must not run such a node in an invisible RPC child. It must:
+A detached WorkflowServer must not run such a node in an invisible RPC child. It must:
 
 - park the run before the node;
 - leave it claimable by the origin Pi session;
 - resume when that session is available.
 
-A controller child or detached run with no origin session must fail clearly before prompting:
+A resource manager child or detached run with no origin session must fail clearly before prompting:
 
 > Assistant completion requires an origin Pi session.
 
@@ -318,9 +318,9 @@ Direct RPC clients can support assistant completion because RPC exposes `message
 
 - `src/workflows/types.ts`
 - `src/workflows/engine.ts`
-- `src/host/runner.ts`
-- `src/host/rpc-executor.ts`
-- `src/host/rpc-bridge.ts` only if the bridge needs completion metadata
+- `src/server/runner.ts`
+- `src/server/rpc-executor.ts`
+- `src/server/rpc-bridge.ts` only if the bridge needs completion metadata
 - Queue and host tests
 
 ### Verification

package/docs/plans/2026-08-23-sqlite-state-plan.md

@@ -19,7 +19,7 @@ This database becomes the only live source of workflow state. It stores workflow
 
 The replacement must also fix the broader ownership problem. Finding shared state never grants permission to change it. Every write checks the actor, current owner when ownership is required, ownership generation, expected resource revision, and requested state transition in the same transaction.
 
-The current formats are specified in [Run bundle format](../SQLITE_STATE.md), [Human decisions](../HUMAN_DECISIONS.md), and [Controller runtime specification](../CONTROLLERS.md). This plan replaces their storage sections. Workflow authoring behavior stays the same unless this plan names a required contract change.
+The current formats are specified in [Run bundle format](../SQLITE_STATE.md), [Human decisions](../HUMAN_DECISIONS.md), and [ResourceManager runtime specification](../RESOURCE_MANAGERS.md). This plan replaces their storage sections. Workflow authoring behavior stays the same unless this plan names a required contract change.
 
 ## Boundaries
 
@@ -43,7 +43,7 @@ Use one SQLite database per user installation. Projects and runs share that data
 
 Use four shared records:
 
-- A **resource** is one mutable item, such as a run, decision, controller resource, effect, or channel.
+- A **resource** is one mutable item, such as a run, decision, managed resource, effect, or channel.
 - A **lease** says which process currently owns a resource. Every ownership change increases a durable generation number.
 - An **event** is the immutable audit record for one accepted resource change.
 - An **effect** is follow-up work created by a resource change, such as creating a continuation, delivering a notification, or closing a decision presentation.
@@ -452,26 +452,26 @@ This table records all human answer attempts without granting them authority.
 
 `(trigger_type, trigger_id)` is unique.
 
-## Controller schema
+## ResourceManager schema
 
 ### `controller_resources`
 
-| Field                    | Type      | Rules                                       |
-| ------------------------ | --------- | ------------------------------------------- |
-| `controller_resource_id` | `TEXT`    | Primary key                                 |
-| `resource_id`            | `TEXT`    | Unique foreign key to a controller resource |
-| `project_id`             | `TEXT`    | Foreign key to `projects`                   |
-| `controller_name`        | `TEXT`    | Controller definition name                  |
-| `resource_key`           | `TEXT`    | Key within controller and project           |
-| `resource_uid`           | `TEXT`    | Unique durable UID                          |
-| `spec_generation`        | `INTEGER` | Positive desired-state generation           |
-| `spec_hash`              | `BLOB`    | Spec JSON in `blobs`                        |
-| `status_hash`            | `BLOB`    | Status JSON in `blobs`                      |
-| `deletion_requested_at`  | `INTEGER` | Optional deletion time                      |
-| `created_at`             | `INTEGER` | Creation time                               |
-| `updated_at`             | `INTEGER` | Last accepted change                        |
-
-`(project_id, controller_name, resource_key)` is unique. `resources.revision` replaces the separate controller resource version.
+| Field                    | Type      | Rules                                    |
+| ------------------------ | --------- | ---------------------------------------- |
+| `controller_resource_id` | `TEXT`    | Primary key                              |
+| `resource_id`            | `TEXT`    | Unique foreign key to a managed resource |
+| `project_id`             | `TEXT`    | Foreign key to `projects`                |
+| `controller_name`        | `TEXT`    | ResourceManager definition name          |
+| `resource_key`           | `TEXT`    | Key within controller and project        |
+| `resource_uid`           | `TEXT`    | Unique durable UID                       |
+| `spec_generation`        | `INTEGER` | Positive desired-state generation        |
+| `spec_hash`              | `BLOB`    | Spec JSON in `blobs`                     |
+| `status_hash`            | `BLOB`    | Status JSON in `blobs`                   |
+| `deletion_requested_at`  | `INTEGER` | Optional deletion time                   |
+| `created_at`             | `INTEGER` | Creation time                            |
+| `updated_at`             | `INTEGER` | Last accepted change                     |
+
+`(project_id, controller_name, resource_key)` is unique. `resources.revision` replaces the separate managed resource version.
 
 ### `controller_finalizers`
 
@@ -494,7 +494,7 @@ The primary key is `(controller_resource_id, finalizer)`.
 | `created_at`             | `INTEGER` | Enqueue time                                       |
 | `updated_at`             | `INTEGER` | Last queue change                                  |
 
-Ownership uses the controller resource lease.
+Ownership uses the managed resource lease.
 
 ### `controller_workflows`
 
@@ -502,7 +502,7 @@ Ownership uses the controller resource lease.
 | ------------------------ | --------- | ------------------------------------------------------------------------ |
 | `request_id`             | `TEXT`    | Primary key                                                              |
 | `controller_resource_id` | `TEXT`    | Foreign key to `controller_resources`                                    |
-| `request_key`            | `TEXT`    | Stable key from controller code                                          |
+| `request_key`            | `TEXT`    | Stable key from resource manager code                                    |
 | `workflow_name`          | `TEXT`    | Requested workflow                                                       |
 | `input_fingerprint`      | `BLOB`    | 32-byte digest                                                           |
 | `reserved_run_id`        | `TEXT`    | Deterministic run ID before the run row exists                           |
@@ -786,7 +786,7 @@ Keep domain stores with their owners:
 ```text
 src/workflows/sqlite-store.ts
 src/workflows/human-decision.ts
-src/controllers/sqlite.ts
+src/resource-managers/sqlite.ts
 src/extension/decision-channels.ts
 ```
 
@@ -836,7 +836,7 @@ Verify all race orders, stale request digests, duplicate submissions, model-answ
 
 ### Move controllers
 
-Move the complete controller resource lifecycle into the canonical database, including queue work, finalizers, effects, events, and child workflows. Remove the project controller database path and schema.
+Move the complete managed resource lifecycle into the canonical database, including queue work, finalizers, effects, events, and child workflows. Remove the project controller database path and schema.
 
 Verify the complete controller lifecycle, including revision conflicts, generation changes, delayed work, effects, child workflows, deletion, and finalizers.
 
@@ -876,7 +876,7 @@ After code behavior matches this plan:
 
 - replace [Run bundle format](../SQLITE_STATE.md) with the SQLite state specification or retire it in favor of `SQLITE_STATE.md`
 - update [Human decisions](../HUMAN_DECISIONS.md)
-- update [Controller runtime specification](../CONTROLLERS.md)
+- update [ResourceManager runtime specification](../RESOURCE_MANAGERS.md)
 - update [Workflow authoring reference](../workflows.md)
 - update [Rust TUI viewer](../tui-viewer.md)
 - update [Development guide](../development.md)
@@ -930,7 +930,7 @@ Test run creation, node execution, looping, included workflows, progress updates
 
 Test human versus timeout, human versus cancellation, timeout versus cancellation, defaulted deadline, no-default deadline, stale digest, duplicate answer, late answer, repeated cancellation, owner-only policy, model-answer rejection, one continuation, parent projection, and stale presentation closure.
 
-### Controller tests
+### ResourceManager tests
 
 Test the complete controller lifecycle, including resource updates, generations, queue claims, delayed work, effect receipts, uncertain outcomes, child workflows, deletion, finalizers, and owner loss.
 

package/docs/plans/2026-08-25-live-workflow-settings-plan.md

@@ -314,7 +314,7 @@ The checkpoint continuation is a new stored run, but it is the same logical work
 - A final presentation must settle before the first prompt becomes ready.
 - Workflow failure, timeout, and user cancellation cancel every unsent prompt with a saved reason.
 - A terminal workflow accepts no new prompt, but a repeated request ID can still return its earlier result.
-- A prompt can be removed only before it is sent. A `session` actor can remove only a prompt added by the same session tool source. A verified `human` actor can remove any unsent prompt for that run. Controllers can remove only prompts they added with the same controller resource.
+- A prompt can be removed only before it is sent. A `session` actor can remove only a prompt added by the same session tool source. A verified `human` actor can remove any unsent prompt for that run. Controllers can remove only prompts they added with the same managed resource.
 
 ### Presentation and delivery
 
@@ -404,7 +404,7 @@ Add the three tables described above. Add atomic change, lookup, replay, and ins
 
 ### 5. Bind settings to node attempts
 
-Update `src/workflows/engine.ts`, `src/host/runner.ts`, and `src/host/rpc-executor.ts`. Save and expose one fixed settings value for every attempt.
+Update `src/workflows/engine.ts`, `src/server/runner.ts`, and `src/server/rpc-executor.ts`. Save and expose one fixed settings value for every attempt.
 
 ### 6. Add safe route changes
 
@@ -418,8 +418,8 @@ Update:
 - `src/extension/workflow-tool.ts`
 - `src/extension/index.ts`
 - `src/extension/step-message.ts`
-- `src/controllers/workflows.ts`
-- `src/controllers/types.ts`
+- `src/resource-managers/workflows.ts`
+- `src/resource-managers/types.ts`
 
 Add `change-settings`, `queue-follow-up`, and `remove-follow-up`. Keep source data outside model input. Use provider-compatible string action schemas.
 

package/docs/plans/2026-08-27-workflow-terminal-restart-plan.md

@@ -66,7 +66,7 @@ Unit tests must cover completed, failed, timed-out, maxSteps, cancelled, and blo
 
 - `finishRun` in `src/extension/index.ts`
 - `src/extension/deferred-turn-coordinator.ts`
-- Existing turn-intent state in `src/controllers/sqlite.ts`
+- Existing turn-intent state in `src/resource-managers/sqlite.ts`
 
 **Change**
 
@@ -77,7 +77,7 @@ Normal presentation and fallback delivery must compete for the same intent. The
 Do not create this turn for:
 
 - waiting checkpoints
-- controller child runs
+- resource manager child runs
 - internal helper runs that already report to an owner
 
 **Verification**
@@ -345,7 +345,7 @@ Add regression coverage for:
 3. Failed, timed-out, and maxSteps runs offer restart.
 4. Explicit cancellation is not restartable through the shortcut.
 5. Waiting checkpoints do not produce a terminal turn.
-6. Controller child runs do not produce competing turns.
+6. ResourceManager child runs do not produce competing turns.
 7. Presentation and fallback races produce one turn.
 8. Restart uses the exact workflow reference and input.
 9. Restart leaves the prior run unchanged.