refactor: rename llm worker crate to engine

2026-06-25 22:46:26 +09:00
parent 22598710fd
commit 292fc4ea5d
202 changed files with 1129 additions and 1125 deletions
@@ -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

@@ -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.

@@ -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.
@@ -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.

@@ -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.