refactor: rename llm worker crate to engine

docs/design/context-history.md

@@ -28,7 +28,7 @@ Forbidden examples:
 - Rewriting old messages to include new facts.
 - Letting UI/controller-only state become model-visible without a committed record.
 
-If new information should affect the model, append it to history and commit it. `history.json` / session persistence follows from the Worker history path.
+If new information should affect the model, append it to history and commit it. `history.json` / session persistence follows from the Engine history path.
 
 ## Prompt cache implications
 

docs/design/overview.md

@@ -7,8 +7,8 @@ That rule shapes the crate split. The runtime can restart, attach, compact, or d
 ## Core layers
 
 - `yoi` owns the product CLI and top-level command shape. It is the façade that wires profile selection, memory linting, and normal TUI launch.
-- `pod` turns a `Worker` into a named runtime entity with scope, session persistence, protocol handling, tools, and Pod metadata integration.
-- `llm-worker` owns model-facing turns: history append, retries, continuation, pruning/compaction mechanics, tool loops, and provider-independent callbacks.
+- `pod` turns a `Engine` into a named runtime entity with scope, session persistence, protocol handling, tools, and Pod metadata integration.
+- `llm-engine` owns model-facing turns: history append, retries, continuation, pruning/compaction mechanics, tool loops, and provider-independent callbacks.
 - `session-store` owns replayable append-only conversation/session logs.
 - `pod-store` owns current Pod metadata keyed by Pod name.
 - `protocol` defines the socket message boundary between clients and Pods.
@@ -21,9 +21,9 @@ That rule shapes the crate split. The runtime can restart, attach, compact, or d
 
 ## Why these boundaries exist
 
-The Worker should not know process identity, Pod names, live sockets, spawned children, or UI state. It should know how to run an LLM turn over committed history and tools.
+The Engine should not know process identity, Pod names, live sockets, spawned children, or UI state. It should know how to run an LLM turn over committed history and tools.
 
-The Pod should not make provider-specific wire decisions. It coordinates runtime identity, persistence, scope, and protocol delivery around a Worker.
+The Pod should not make provider-specific wire decisions. It coordinates runtime identity, persistence, scope, and protocol delivery around a Engine.
 
 The TUI should not be an alternate source of truth. It may queue local input, show optimistic affordances, and render snapshots, but durable state comes from Pod/session records.
 

docs/design/plugin-component-model.md

@@ -68,7 +68,7 @@ Adopting the Component Model must not change Yoi's authority model:
 - Explicit enablement is required before any Tool surface is registered.
 - Plugin grants are required before runtime execution and before `https` / `fs` / future host API calls.
 - Component imports are not authority by themselves; host-side grant checks remain authoritative.
-- Tool calls and Tool results continue through the ordinary ToolRegistry and Worker history path.
+- Tool calls and Tool results continue through the ordinary ToolRegistry and Engine history path.
 - No hidden context injection is introduced by component imports, resources, prompts, or SDK helpers.
 - Plugin SDKs and templates are authoring aids, not trust boundaries.
 
@@ -120,7 +120,7 @@ The component runtime uses `wasmtime::component` and expects the exported world
 `yoi:plugin/tool@1.0.0` with a `call(tool-name: string, input-json: string) ->
 string` export. The returned string is the normal ToolOutput JSON, so
 registration and execution still flow through the existing ToolRegistry and
-Worker Tool-result history path.
+Engine Tool-result history path.
 
 Host imports are stable names under `yoi:host/*@1.0.0`; the repository WIT files
 live in `resources/plugin/wit/`. Importing `yoi:host/request@1.0.0` or
@@ -164,7 +164,7 @@ authority model.
 Important boundaries:
 
 - Tool calls still enter through `ToolRegistry` and return ordinary `ToolOutput`
-  that is visible in the Worker history path.
+  that is visible in the Engine history path.
 - Service and Ingress grants are separate from Tool grants. Sharing an instance
   does not authorize a surface that lacks its own `surface.*` and per-surface
   permission/grant.

docs/design/plugin-packages.md

@@ -173,7 +173,7 @@ Diagnostics should be safe, bounded, and attributable:
 
 ## Runtime notes
 
-Declarative hooks are data contributions. Loading a declarative hook still requires explicit package enablement. Hook text should enter the system through the normal Hook/Worker paths, preserving the rule that model-affecting inputs are committed to history before they affect context when applicable.
+Declarative hooks are data contributions. Loading a declarative hook still requires explicit package enablement. Hook text should enter the system through the normal Hook/Engine paths, preserving the rule that model-affecting inputs are committed to history before they affect context when applicable.
 
 WASM packages should initialize only from the digest-keyed cache after enablement and grant resolution. The host should use a narrow ABI, bounded memory, fuel/time limits, bounded output, and explicit host functions. A WASM module must not inherit filesystem, network, tool, secret, process, or MCP authority from the package store path.
 

docs/design/provider-model-boundary.md

@@ -1,10 +1,10 @@
 # Provider and model boundary
 
-The Worker should be provider-independent. Provider-specific wire formats, auth mechanisms, model catalogs, reasoning knobs, and terminal error shapes belong below or beside it, not inside ordinary turn orchestration.
+The Engine should be provider-independent. Provider-specific wire formats, auth mechanisms, model catalogs, reasoning knobs, and terminal error shapes belong below or beside it, not inside ordinary turn orchestration.
 
-## Worker responsibility
+## Engine responsibility
 
-`llm-worker` owns turn lifecycle:
+`llm-engine` owns turn lifecycle:
 
 - committed history append
 - tool loops
@@ -42,4 +42,4 @@ Event trace sidecars are optional parsed lifecycle traces. They are not complete
 
 ## Why this boundary exists
 
-Provider APIs drift. If provider details leak into Worker logic, every new model behavior risks changing core orchestration. Keeping the boundary explicit lets Yoi adapt provider integrations while preserving stable turn semantics.
+Provider APIs drift. If provider details leak into Engine logic, every new model behavior risks changing core orchestration. Keeping the boundary explicit lets Yoi adapt provider integrations while preserving stable turn semantics.

docs/development/plugin-development.md

@@ -9,7 +9,7 @@ Yoi Plugins are intentionally explicit. The Plugin system is designed around the
 - Plugin grants must allow each surface and host API before registration or execution can use it;
 - Plugin code runs only through the configured sandbox runtime;
 - Plugin packages do not inherit Pod workspace filesystem, network, environment, or Ticket authority;
-- Tool calls and Tool results use the ordinary Yoi Tool/Worker history path;
+- Tool calls and Tool results use the ordinary Yoi Tool/Engine history path;
 - Plugin metadata, output, and diagnostics are untrusted unless Yoi host policy says otherwise.
 
 ## Design intent