fix: update remaining active worker wording

docs/design/compaction.md

@@ -1,6 +1,6 @@
 # Compaction
 
-Compaction exists because long-running Pods need durable continuity without sending the entire transcript forever.
+Compaction exists because long-running Workers need durable continuity without sending the entire transcript forever.
 
 ## Pruning vs compaction
 

docs/design/memory-knowledge.md

@@ -6,7 +6,7 @@ The authoritative record for work is still code, git history, work item files, t
 
 ## Record types
 
-- `summary.md` is resident background context for normal Pods.
+- `summary.md` is resident background context for normal Workers.
 - `decisions/` stores durable decisions that are useful across turns.
 - `requests/` stores durable user requests and preferences.
 - `.yoi/knowledge/` stores curated Knowledge records when available.

docs/design/plugin-packages.md

@@ -99,7 +99,7 @@ Collision handling:
 
 Discovery is a read-only inventory operation. It may report package metadata, validation errors, source, canonical store path, and deterministic digest. It must not initialize any runtime contribution.
 
-Enablement is a resolved runtime plan. It should come from Profile/manifest configuration or another explicit local policy layer, then be recorded into the resolved Manifest/session metadata used to start the Worker. Restored Pods should use that resolved enabled-plugin plan instead of silently re-running fresh discovery and picking newer packages. Fresh discovery must not silently upgrade a restored Worker.
+Enablement is a resolved runtime plan. It should come from Profile/manifest configuration or another explicit local policy layer, then be recorded into the resolved Manifest/session metadata used to start the Worker. Restored Workers should use that resolved enabled-plugin plan instead of silently re-running fresh discovery and picking newer packages. Fresh discovery must not silently upgrade a restored Worker.
 
 A minimal implemented enablement record is shaped like this. `version` is an exact package-version requirement; richer range constraints are deferred. `digest` is optional in authoring config, but fresh startup records the resolved digest into runtime metadata.
 

docs/design/tool-permissions-scope.md

@@ -22,7 +22,7 @@ Directory traversal tools should not follow symlink directories as a way around
 
 ## Delegation
 
-Child Pods receive an explicit subset of the parent's scope. Delegation is a capability loan, not a copy of all parent authority.
+Child Workers receive an explicit subset of the parent's scope. Delegation is a capability loan, not a copy of all parent authority.
 
 When a child stops, shuts down, or is pruned as unreachable, delegated write permissions must be reclaimed. Explicit base denies remain in force.
 

docs/development/environment.md

@@ -4,7 +4,7 @@ Environment variables are a minimized runtime boundary. Prefer explicit profile/
 
 ## Why minimize environment variables
 
-Ambient environment is hard to audit: it can differ between shells, services, spawned Pods, tests, and restored processes. If important runtime behavior depends on it, reproducing a session becomes harder.
+Ambient environment is hard to audit: it can differ between shells, services, spawned Workers, tests, and restored processes. If important runtime behavior depends on it, reproducing a session becomes harder.
 
 Yoi keeps environment variables for narrow bootstrap and development cases, while normal provider credentials and runtime configuration should be explicit records.
 

docs/development/work-items.md

@@ -24,14 +24,14 @@ Use the highest-level interface that matches the work:
 
 - Use `yoi panel` for the Ticket/Intake/Orchestrator workspace Dashboard and role-launch actions.
 - Use `yoi objective ...` for lightweight medium-term Objective records and their non-blocking canonical Ticket links.
-- Inside Pods, use typed Ticket tools to create, inspect, comment, review, and close Tickets.
+- Inside Workers, use typed Ticket tools to create, inspect, comment, review, and close Tickets.
 - For multi-step work, follow the Ticket Intake, Orchestrator Routing, planning/requirements-sync, and Multi-agent workflows.
 
 Maintainers can inspect the local `.yoi/tickets/` files directly when debugging storage, but normal user instructions should go through `yoi panel`, Ticket tools, or `yoi ticket ...`.
 
-## Ticket tools inside Pods
+## Ticket tools inside Workers
 
-Pods with the Ticket built-in feature can use typed Ticket tools:
+Workers with the Ticket built-in feature can use typed Ticket tools:
 
 - `TicketCreate`
 - `TicketList` — lightweight bounded overview for selecting ids; it returns short summaries only and must not be used as body/thread/artifact authority.
@@ -195,7 +195,7 @@ Intake should:
 - draft background, requirements, acceptance criteria, binding decisions/invariants, implementation latitude, readiness, risk flags, and validation;
 - create or update the Ticket only after user agreement.
 
-Intake should not schedule implementation, spawn coder/reviewer Pods, create worktrees, merge, or close Tickets.
+Intake should not schedule implementation, spawn coder/reviewer Workers, create worktrees, merge, or close Tickets.
 
 ### 2. Orchestrator routing
 
@@ -226,7 +226,7 @@ Planning sync should resolve or record:
 - critical risks and failure modes;
 - implementation-ready vs requirements-sync/spike/blocked classification.
 
-Do not send Tickets with unresolved concrete missing decisions/information directly to coder Pods. If no concrete missing item remains after bounded checks, risky-but-specified Tickets should proceed with an IntentPacket plus escalation conditions and reviewer focus.
+Do not send Tickets with unresolved concrete missing decisions/information directly to coder Workers. If no concrete missing item remains after bounded checks, risky-but-specified Tickets should proceed with an IntentPacket plus escalation conditions and reviewer focus.
 
 ### 4. Implementation assignment
 

docs/development/workflows.md

@@ -17,7 +17,7 @@ Current workflow themes include:
 - sibling coder/reviewer Worker orchestration
 - human-gated maintenance and merge readiness
 
-## Child Pods
+## Child Workers
 
 Spawned Workers are useful for scoped implementation, review, or exploration. They are not independent project authorities.
 
@@ -35,7 +35,7 @@ Notifications are hints to inspect state. They are not proof of completion.
 
 Unless explicitly authorized otherwise, final merge, cleanup, design-boundary decisions, and ticket closure remain the orchestrator/human responsibility.
 
-Child Pods may commit in delegated worktrees when the workflow allows it, but the merge-ready dossier should make the final decision auditable from repository records.
+Child Workers may commit in delegated worktrees when the workflow allows it, but the merge-ready dossier should make the final decision auditable from repository records.
 
 ## Public and dogfood workflow split
 

tests/e2e/tests/panel.rs

@@ -40,10 +40,10 @@ fn rendered_ticket_row(
     }
 }
 
-fn rendered_pod_row(name: &str) -> RenderedPanelRow {
+fn rendered_worker_row(name: &str) -> RenderedPanelRow {
     RenderedPanelRow {
         key: PanelRowKey {
-            kind: "pod".to_string(),
+            kind: "worker".to_string(),
             id: name.to_string(),
         },
         title: name.to_string(),
@@ -74,7 +74,7 @@ fn ready_snapshot(rows: Vec<RenderedPanelRow>) -> DashboardContentReady {
                 orchestrator: Some(DashboardOrchestratorState {
                     worker_name: "workspace-orchestrator".to_string(),
                     status: "unavailable".to_string(),
-                    detail: Some("fixture blocks host Pod launch".to_string()),
+                    detail: Some("fixture blocks host Worker launch".to_string()),
                 }),
                 diagnostics: vec![],
             },
@@ -106,7 +106,7 @@ fn panel_fixture_ticket_row_matcher_rejects_absent_fixture_data() {
     );
     let wrong_kind = RenderedPanelRow {
         key: PanelRowKey {
-            kind: "pod".to_string(),
+            kind: "worker".to_string(),
             id: "0000000000000".to_string(),
         },
         title: "Ready E2E Ticket".to_string(),
@@ -171,7 +171,7 @@ fn dashboard_snapshot_rejects_missing_row_wrong_state_missing_overlay_and_missin
                 Some("planning"),
                 None,
             ),
-            rendered_pod_row("workspace"),
+            rendered_worker_row("workspace"),
         ]
     };
     assert_eq!(
@@ -189,7 +189,7 @@ fn dashboard_snapshot_rejects_missing_row_wrong_state_missing_overlay_and_missin
             Some("ready"),
             Some("inprogress"),
         ),
-        rendered_pod_row("workspace"),
+        rendered_worker_row("workspace"),
     ]);
     assert_ne!(
         missing_row.snapshot_for_expected(&expected),
@@ -354,7 +354,7 @@ fn panel_dashboard_content_ready_has_startup_budget() -> yoi_e2e::Result<()> {
             && source_breakdown.has_source("ticket_scan_parse")
             && source_breakdown.has_source("orchestration_overlay_validation_read_git")
             && source_breakdown.has_source("workspace_panel.build.total"),
-        "dashboard source breakdown should include pod metadata/status, ticket scan/parse, overlay validation/read/git, local claim scan, and panel-build sources; got {:?}; artifacts at {}",
+        "dashboard source breakdown should include worker metadata/status, ticket scan/parse, overlay validation/read/git, local claim scan, and panel-build sources; got {:?}; artifacts at {}",
         source_breakdown,
         panel.artifacts().dir.display()
     );
@@ -623,7 +623,7 @@ fn assert_no_runtime_or_host_pod_leak(
     ] {
         assert!(
             !rendered.contains(marker),
-            "host/fixture runtime Pod marker {marker:?} leaked into panel rows; artifacts at {artifacts}\n{rendered}"
+            "host/fixture runtime Worker marker {marker:?} leaked into panel rows; artifacts at {artifacts}\n{rendered}"
         );
     }
     if let Some(host_runtime) = std::env::var_os("XDG_RUNTIME_DIR") {

tests/e2e/tests/rewind.rs

@@ -55,7 +55,7 @@ fn single_pod_rewind_picker_applies_without_escape_and_suppresses_duplicate_ente
     let status = tui.expect_exit_within(PanelHarness::default_exit_wait())?;
     assert!(
         status.success(),
-        "single-pod rewind fixture should exit cleanly"
+        "single-worker rewind fixture should exit cleanly"
     );
     drop(tui);
     let cleanup = fixture.cleanup()?;