fix: clean remaining worker rename references

AGENTS.md

@@ -11,12 +11,12 @@
 
 LLM に投げる context への割り込みは、大きく2種類に分かれる。**前者は許されるが、後者は禁止**。
 
-Podの状態から純粋に再現可能で、且つ揮発性の無い操作であることが望ましい。（pruning、tool result の content 切り詰め、prompt cache anchor の付与等）。
+Workerの状態から純粋に再現可能で、且つ揮発性の無い操作であることが望ましい。（pruning、tool result の content 切り詰め、prompt cache anchor の付与等）。
 原則として、コンテキストは積み重ねるものであり、一時的にメッセージを差し込むことや、過去のメッセージを改ざんすることはKVキャッシュのヒット率を下げる。
 
 **禁止**: ターンを跨ぐことができない情報に基づいて、history に記録せずに context だけにコンテンツを差し込むこと。これをやると LLM はそれに反応して生成を行う一方、次以降のターンでhistoryに残らないため、「自分がなぜその発言/tool call をしたか」の根拠が消えるうえ、prompt cache のヒット率も低下させることになる。
 
-新しい input を context に乗せたいなら、必ず先に `worker.history` に append して commit すること。`history.json` への永続化はそこから自動的についてくる。Notify / PodEvent / `<system-reminder>` 系はこの原則で扱う。
+新しい input を context に乗せたいなら、必ず先に `worker.history` に append して commit すること。`history.json` への永続化はそこから自動的についてくる。Notify / WorkerEvent / `<system-reminder>` 系はこの原則で扱う。
 また、キャッシュを破壊するタイミングは正確にコントロールされる必要があり、キャッシュ破壊とトークン消費のトレードオフに基づいて慎重に設計されるべきである。
 
 ---

crates/pod-registry/README.md

@@ -2,29 +2,29 @@
 
 ## Role
 
-`pod-registry` tracks live Pod process ownership and delegated scope locks at runtime.
+`pod-registry` is the legacy-named crate that tracks live Worker process ownership and delegated scope locks at runtime.
 
 ## Boundaries
 
 Owns:
 
-- machine-local live Pod registration
-- collision detection for running Pod names
+- machine-local live Worker registration
+- collision detection for running Worker names
 - delegated scope lock bookkeeping
 - registry cleanup hooks for stopped or unreachable children
 
 Does not own:
 
-- durable Pod metadata (`pod-store`)
+- durable Worker metadata (`pod-store`)
 - replayable session logs (`session-store`)
 - socket protocol definitions (`protocol`)
 - project work item state
 
 ## Design notes
 
-The registry is a runtime coordination mechanism. It can help decide whether a Pod is live or colliding, but durable visibility/restoration should be backed by Pod metadata when possible.
+The registry is a runtime coordination mechanism. It can help decide whether a Worker is live or colliding, but durable visibility/restoration should be backed by Worker metadata when possible.
 
 ## See also
 
-- [`../../docs/design/pod-session-state.md`](../../docs/design/pod-session-state.md)
+- [`../../docs/design/worker-session-state.md`](../../docs/design/worker-session-state.md)
 - [`../../docs/design/tool-permissions-scope.md`](../../docs/design/tool-permissions-scope.md)

crates/protocol/src/lib.rs

@@ -77,7 +77,7 @@ pub enum Method {
         kind: CompletionKind,
         prefix: String,
     },
-    /// List Pods visible to this Worker from durable Worker state and the spawned-child
+    /// List Workers visible to this Worker from durable Worker state and the spawned-child
     /// registry. This is not a host-wide Worker universe query.
     ListWorkers,
     /// Restore a visible stopped/restorable Worker, or report that it is already

crates/session-analytics/src/lib.rs

@@ -1592,12 +1592,17 @@ fn line_count(value: &str) -> usize {
 }
 
 fn tool_kind(name: &str) -> &'static str {
+    const LEGACY_SEND_TO_PEER_POD_TOOL: &str = "SendToPeerPod";
+
     match name {
         "Read" | "Write" | "Edit" | "Glob" | "Grep" => "filesystem",
         "Bash" => "shell",
         "WebFetch" | "WebSearch" => "web",
-        "SpawnWorker" | "SendToWorker" | "ReadWorkerOutput" | "ListWorkers" | "StopWorker"
-        | "RestoreWorker" | "SendToPeerPod" => "worker",
+        "SpawnWorker" | "SendToWorker" | "SendToPeerWorker" | "ReadWorkerOutput"
+        | "ListWorkers" | "StopWorker" | "RestoreWorker" => "worker",
+        // Legacy session logs used the pre-rename peer tool name; keep analytics classification only.
+        /* legacy session-log tool name only */
+        LEGACY_SEND_TO_PEER_POD_TOOL => "worker",
         name if name.starts_with("Memory") || name.starts_with("Knowledge") => "memory",
         name if name.starts_with("Ticket") => "ticket",
         name if name.starts_with("Task") => "task",

docs/development/work-items.md

@@ -247,7 +247,7 @@ Implementation normally happens in a child git worktree created by the Orchestra
 
 ### 5. Review
 
-Reviewer Pods should be sibling Pods, not children of coder Pods. They should read the Ticket, intent packet, diff, implementation report, and validation evidence.
+Reviewer Workers should be sibling Workers, not children of coder Workers. They should read the Ticket, intent packet, diff, implementation report, and validation evidence.
 
 Review results should be recorded with the `TicketReview` tool. Maintainers working directly with the local backend can use the `yoi ticket` CLI documented later.