ticket: record pod identity boundary decision

.yoi/tickets/open/20260607-235442-remove-profile-derived-pod-names/item.md

@@ -6,11 +6,13 @@ status: 'open'
 kind: 'task'
 priority: 'P1'
 labels: ['profile', 'pod', 'identity', 'manifest', 'bug']
-workflow_state: 'intake'
+workflow_state: 'queued'
 created_at: '2026-06-07T23:54:42Z'
-updated_at: '2026-06-08T00:05:23Z'
+updated_at: '2026-06-08T00:52:41Z'
 assignee: null
 legacy_ticket: null
+queued_by: 'workspace-panel'
+queued_at: '2026-06-08T00:32:56Z'
 ---
 
 ## Background

.yoi/tickets/open/20260607-235442-remove-profile-derived-pod-names/thread.md

@@ -37,3 +37,138 @@ Implementation requirements:
 - Add regression coverage for the previous failure mode: project profile `project:companion` must not create Pod `companion` when the runtime requested workspace Pod name is `yoi` or another workspace basename.
 
 ---
+
+<!-- event: intake_summary author: intake at: 2026-06-08T00:14:28Z -->
+
+## Intake summary
+
+Existing Ticket refined rather than duplicated. Request is clear enough for Orchestrator routing: remove every Profile-derived Pod identity path, make `--pod <name>`/runtime policy the sole Pod identity source while `--profile <selector>` remains recipe selection, remove or deprecate `--profile-pod-name`, update spawn/profile callers to pass explicit runtime names, and add regression tests proving project profile slugs such as `project:companion` do not create Pods named `companion`. Readiness: implementation_ready. Needs preflight: true because this touches profile/manifest boundaries, Pod identity/startup semantics, CLI surface, and runtime caller behavior. Risk flags: profile-boundary, manifest-boundary, pod-identity, cli-startup, backward-compatibility.
+
+---
+
+<!-- event: state_changed author: intake at: 2026-06-08T00:14:28Z from: intake to: ready reason: intake_ready field: workflow_state -->
+
+## State changed
+
+Intake judged the existing Ticket complete enough for Orchestrator routing. It should be queued by the user before implementation starts; Orchestrator should consider a preflight because profile/manifest and Pod startup identity boundaries are affected.
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-08T00:32:56Z from: ready to: queued reason: queued field: workflow_state -->
+
+## State changed
+
+Ticket queued for Orchestrator routing.
+
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-08T00:33:13Z -->
+
+## Decision
+
+Routing decision: preflight_needed
+
+Reason:
+- The Ticket is clear and important, but it changes Profile/manifest identity boundaries, runtime Pod startup semantics, and CLI naming surface.
+- Intake explicitly recorded `needs_preflight: true` because the work touches profile-boundary, manifest-boundary, pod-identity, CLI startup, and compatibility concerns.
+- The thread contains a binding human direction to remove the `resume_by_pod_name` / `--profile-pod-name` split, but no preflight note yet maps that decision to concrete startup modes, caller changes, diagnostics, and tests.
+- This Ticket is tightly coordinated with runtime workspace context and default workspace-basename naming Tickets; implementation should not start before the split of responsibilities is recorded.
+
+Evidence checked:
+- Ticket body: background, goal, requirements, and acceptance criteria.
+- Thread: human decision update, intake summary, `ready -> queued` event.
+- Workspace state: `develop` has Ticket-record edits for this and related queued Tickets; no matching branch or worktree exists for this slug.
+- Visible Pods: Intake peers for this and related Tickets are live; no coder/reviewer implementation Pods are active.
+
+Next action:
+- Run `ticket-preflight-workflow` for this Ticket before implementation delegation.
+- Preflight should produce a concise binding note covering: removal/replacement of `resume_by_pod_name`, normal `--pod <name> --profile <selector>` startup semantics, fate of `--profile-pod-name`, which caller paths must supply runtime Pod identity, diagnostics for forbidden Profile identity fields, regression tests for `project:companion`, and boundaries with `introduce-runtime-workspace-root-context` / `use-workspace-basename-for-default-pod-name`.
+- Leave this Ticket queued for now; do not transition `queued -> inprogress`, create `.worktree/remove-profile-derived-pod-names`, or spawn coder/reviewer Pods until preflight records implementation readiness.
+
+Escalate if:
+- Removing `--profile-pod-name` requires a public compatibility policy beyond this Ticket.
+- Fresh/create versus restore startup behavior needs a new explicit startup-mode model.
+- Runtime workspace-root work must land first to provide the default naming source.
+
+---
+
+<!-- event: decision author: hare at: 2026-06-08T00:46:13Z -->
+
+## Decision
+
+## Shared Pod identity / workspace boundary decision
+
+This decision is shared across these related Tickets:
+
+- `introduce-runtime-workspace-root-context`
+- `remove-profile-derived-pod-names`
+- `use-workspace-basename-for-default-pod-name`
+
+The three Tickets should be treated as a coordinated cleanup bundle, not as three unrelated design unknowns requiring separate heavy preflight. This decision supplies the binding boundary needed for Orchestrator routing; remaining uncertainty should be treated as coder implementation investigation unless it hits an escalation condition below.
+
+Binding decisions:
+
+- `--workspace <path>` represents the runtime workspace root.
+- `--pod <name>` represents the runtime Pod identity for both restore and fresh create.
+- `--profile <selector>` represents reusable Profile recipe selection only.
+- Lua Profile fields, Profile slug, Profile source, and registry entry names must not define or imply `pod.name`.
+- Default Pod name derives from the runtime workspace basename, not from product name, Profile slug/source, `.yoi` project-record marker, or memory root detection.
+- This repository's normal default Pod name is `yoi` only because the workspace directory basename is `yoi`.
+- Workspace Orchestrator remains a distinct runtime identity such as `<workspace>-orchestrator`.
+- Ticket role / task Pods should continue to use explicit role/task-derived names supplied by the launcher/orchestrator, not profile fallback names.
+- `.yoi` project records root, `.yoi/memory` memory root, and runtime workspace root are separate concepts.
+- Memory root behavior from `memory-root-uses-yoi-memory-marker` must be preserved: explicit `memory.workspace_root` wins; otherwise nearest `.yoi/memory`; `.yoi` alone is not a memory root marker.
+- `resume_by_pod_name` / `--profile-pod-name` are cleanup targets. Prefer collapsing startup around explicit `--pod <name> --profile <selector>` plus runtime workspace context. If an explicit startup-mode enum is needed, it should model restore/create policy directly rather than hide it behind a boolean named `resume_by_pod_name`.
+- Existing Pod metadata migration/renaming and archive/fresh-start behavior are out of scope for this implementation bundle unless explicitly required by tests; `add-pod-archive-fresh-start-path` covers archive/fresh-start UX.
+
+Implementation latitude:
+
+- The coder may discover exact call sites, structure names, helper placement, and test organization during implementation.
+- The coder may split changes across the three Tickets if needed, but should preserve the above boundaries and avoid adding compatibility layers just to preserve profile-derived identity.
+- Tests should include non-`yoi` workspace names so dogfooding does not hide hardcoded/default-name bugs.
+
+Escalate if:
+
+- Removing `--profile-pod-name` requires a public compatibility policy beyond internal cleanup.
+- Existing Pod metadata needs automatic migration or destructive modification.
+- A caller genuinely cannot supply runtime workspace root or Pod identity without reintroducing profile-derived naming.
+- The implementation would make `.yoi` alone a memory root marker again.
+- The implementation would weaken explicit `--pod` precedence or make Profile selection influence Pod identity.
+
+With this decision recorded, this Ticket can proceed as implementation-ready if Orchestrator can write a bounded IntentPacket from the Ticket body and this shared decision. A separate heavy preflight is not required unless one of the escalation conditions is reached.
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-08T00:52:41Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- The shared preflight decision now fixes the missing authority boundary: Profile selection is a recipe only and must not determine runtime Pod identity.
+- This Ticket can be implemented as part of the coordinated runtime workspace / Pod identity cleanup bundle with `introduce-runtime-workspace-root-context` as the primary intent packet.
+
+Evidence checked:
+- Ticket body and thread, including the new shared boundary decision.
+- Primary routing/IntentPacket recorded on `introduce-runtime-workspace-root-context`.
+- Code map: `crates/manifest/src/profile.rs`, `crates/client/src/spawn.rs`, `crates/pod/src/entrypoint.rs`, `crates/tui/src/spawn.rs`, `crates/tui/src/multi_pod.rs`, and `crates/client/src/ticket_role.rs`.
+
+Next action:
+- Implement in the same coordinated branch as `introduce-runtime-workspace-root-context` and `use-workspace-basename-for-default-pod-name`.
+- Before any implementation side effects, transition this Ticket and the bundle peers from `queued` to `inprogress` together.
+
+Binding points for this Ticket:
+- Remove Profile-derived Pod name fallback.
+- Preserve explicit `--pod <name>` precedence.
+- Treat `--profile <selector>` as recipe selection only.
+- Remove or collapse `resume_by_pod_name` / `--profile-pod-name` split unless a real explicit startup-mode model is required.
+- Add regression coverage proving `project:companion` does not imply Pod name `companion`.
+
+Escalate if:
+- Removing `--profile-pod-name` requires a public compatibility policy.
+- Any startup path cannot provide runtime Pod identity without falling back to Profile slug/source.
+- Implementation tries to preserve old Profile-derived names for compatibility rather than removing the design problem.
+
+---

.yoi/tickets/open/20260607-235505-use-workspace-basename-for-default-pod-name/item.md

@@ -6,11 +6,13 @@ status: 'open'
 kind: 'task'
 priority: 'P1'
 labels: ['pod', 'identity', 'workspace', 'cli', 'panel']
-workflow_state: 'intake'
+workflow_state: 'queued'
 created_at: '2026-06-07T23:55:05Z'
-updated_at: '2026-06-07T23:55:05Z'
+updated_at: '2026-06-08T00:52:41Z'
 assignee: null
 legacy_ticket: null
+queued_by: 'workspace-panel'
+queued_at: '2026-06-08T00:33:01Z'
 ---
 
 ## Background

.yoi/tickets/open/20260607-235505-use-workspace-basename-for-default-pod-name/thread.md

@@ -5,3 +5,139 @@
 Created by LocalTicketBackend create.
 
 ---
+
+<!-- event: intake_summary author: intake at: 2026-06-08T00:14:37Z -->
+
+## Intake summary
+
+Existing Ticket refined enough for Orchestrator routing. The request is to remove product-name-specific default Pod identity (`"yoi"`/`DEFAULT_POD_NAME`) and unify fresh default Pod naming on the sanitized workspace/current-directory basename, while preserving explicit `--pod` precedence, keeping Orchestrator/role Pods distinct and explicit, and ensuring Profile selection never determines Pod identity. Readiness: implementation_ready. Needs preflight: true, because this touches Pod identity, CLI/TUI/Panel launch behavior, Profile/runtime boundary, and Pod metadata/restore expectations. Risk flags: pod-identity, profile-boundary, cli-tui-panel-consistency, persistence. Related work: coordinate with `remove-profile-derived-pod-names`; keep `add-pod-archive-fresh-start-path` out of scope.
+
+---
+
+<!-- event: state_changed author: intake at: 2026-06-08T00:14:37Z from: intake to: ready reason: intake_ready field: workflow_state -->
+
+## State changed
+
+Intake completed for existing Ticket; ready for human queueing and Orchestrator routing. Implementation must not start until the panel/user moves ready -> queued and Orchestrator records queued -> inprogress.
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-08T00:33:01Z from: ready to: queued reason: queued field: workflow_state -->
+
+## State changed
+
+Ticket queued for Orchestrator routing.
+
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-08T00:33:29Z -->
+
+## Decision
+
+Routing decision: preflight_needed
+
+Reason:
+- The Ticket is clear enough to route, but it changes runtime Pod identity defaults across CLI, TUI, Panel, and helper launch paths.
+- Intake explicitly recorded `needs_preflight: true` because this touches Pod identity, Profile/runtime separation, CLI/TUI/Panel consistency, and persistence/restore expectations.
+- This Ticket must be coordinated with `remove-profile-derived-pod-names` and `introduce-runtime-workspace-root-context` so the default workspace basename policy, explicit `--pod` precedence, Profile non-influence, and Orchestrator/role Pod naming split are binding before coder delegation.
+- No preflight/design note is present yet that fixes the exact default naming policy and the caller/test boundaries.
+
+Evidence checked:
+- Ticket body: background, goal, requirements, non-goals, and acceptance criteria.
+- Thread: intake summary and `ready -> queued` event.
+- Workspace state: `develop` has Ticket-record edits for this and related queued Tickets; no matching branch or worktree exists for this slug.
+- Visible Pods: Intake peers for this and related Tickets are live; no coder/reviewer implementation Pods are active.
+
+Next action:
+- Run `ticket-preflight-workflow` for this Ticket before implementation delegation.
+- Preflight should record: sanitized workspace/current-directory basename rules, generic fallback behavior, explicit `--pod` precedence, Orchestrator/role Pod naming invariants, Panel Companion expectations, relationship to Profile-derived-name removal, non-goals around existing metadata/archive behavior, and test/validation targets using a non-`yoi` workspace.
+- Leave this Ticket queued for now; do not transition `queued -> inprogress`, create `.worktree/use-workspace-basename-for-default-pod-name`, or spawn coder/reviewer Pods until preflight records implementation readiness.
+
+Escalate if:
+- Default naming requires a metadata migration for existing Pods.
+- Workspace-root context must be introduced first to compute defaults consistently.
+- Any caller still requires Profile slug/source as an identity fallback.
+
+---
+
+<!-- event: decision author: hare at: 2026-06-08T00:46:34Z -->
+
+## Decision
+
+## Shared Pod identity / workspace boundary decision
+
+This decision is shared across these related Tickets:
+
+- `introduce-runtime-workspace-root-context`
+- `remove-profile-derived-pod-names`
+- `use-workspace-basename-for-default-pod-name`
+
+The three Tickets should be treated as a coordinated cleanup bundle, not as three unrelated design unknowns requiring separate heavy preflight. This decision supplies the binding boundary needed for Orchestrator routing; remaining uncertainty should be treated as coder implementation investigation unless it hits an escalation condition below.
+
+Binding decisions:
+
+- `--workspace <path>` represents the runtime workspace root.
+- `--pod <name>` represents the runtime Pod identity for both restore and fresh create.
+- `--profile <selector>` represents reusable Profile recipe selection only.
+- Lua Profile fields, Profile slug, Profile source, and registry entry names must not define or imply `pod.name`.
+- Default Pod name derives from the runtime workspace basename, not from product name, Profile slug/source, `.yoi` project-record marker, or memory root detection.
+- This repository's normal default Pod name is `yoi` only because the workspace directory basename is `yoi`.
+- Workspace Orchestrator remains a distinct runtime identity such as `<workspace>-orchestrator`.
+- Ticket role / task Pods should continue to use explicit role/task-derived names supplied by the launcher/orchestrator, not profile fallback names.
+- `.yoi` project records root, `.yoi/memory` memory root, and runtime workspace root are separate concepts.
+- Memory root behavior from `memory-root-uses-yoi-memory-marker` must be preserved: explicit `memory.workspace_root` wins; otherwise nearest `.yoi/memory`; `.yoi` alone is not a memory root marker.
+- `resume_by_pod_name` / `--profile-pod-name` are cleanup targets. Prefer collapsing startup around explicit `--pod <name> --profile <selector>` plus runtime workspace context. If an explicit startup-mode enum is needed, it should model restore/create policy directly rather than hide it behind a boolean named `resume_by_pod_name`.
+- Existing Pod metadata migration/renaming and archive/fresh-start behavior are out of scope for this implementation bundle unless explicitly required by tests; `add-pod-archive-fresh-start-path` covers archive/fresh-start UX.
+
+Implementation latitude:
+
+- The coder may discover exact call sites, structure names, helper placement, and test organization during implementation.
+- The coder may split changes across the three Tickets if needed, but should preserve the above boundaries and avoid adding compatibility layers just to preserve profile-derived identity.
+- Tests should include non-`yoi` workspace names so dogfooding does not hide hardcoded/default-name bugs.
+
+Escalate if:
+
+- Removing `--profile-pod-name` requires a public compatibility policy beyond internal cleanup.
+- Existing Pod metadata needs automatic migration or destructive modification.
+- A caller genuinely cannot supply runtime workspace root or Pod identity without reintroducing profile-derived naming.
+- The implementation would make `.yoi` alone a memory root marker again.
+- The implementation would weaken explicit `--pod` precedence or make Profile selection influence Pod identity.
+
+With this decision recorded, this Ticket can proceed as implementation-ready if Orchestrator can write a bounded IntentPacket from the Ticket body and this shared decision. A separate heavy preflight is not required unless one of the escalation conditions is reached.
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-08T00:52:41Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- The shared preflight decision now fixes the default identity policy: default Pod identity derives from runtime workspace basename, while Profile selector/source never influences identity and explicit `--pod` always wins.
+- This Ticket can be implemented as part of the coordinated runtime workspace / Pod identity cleanup bundle with `introduce-runtime-workspace-root-context` as the primary intent packet.
+
+Evidence checked:
+- Ticket body and thread, including the new shared boundary decision.
+- Primary routing/IntentPacket recorded on `introduce-runtime-workspace-root-context`.
+- Code map: hardcoded/default name paths in `crates/manifest/src/profile.rs`, TUI/Panel companion lifecycle, client spawn helper, Pod entrypoint, and Ticket role launch paths.
+
+Next action:
+- Implement in the same coordinated branch as `introduce-runtime-workspace-root-context` and `remove-profile-derived-pod-names`.
+- Before any implementation side effects, transition this Ticket and the bundle peers from `queued` to `inprogress` together.
+
+Binding points for this Ticket:
+- Fresh default Pod name is sanitized runtime workspace/current-directory basename.
+- Use a generic fallback such as `pod` only when no useful basename exists.
+- This repository defaults to `yoi` only because the workspace basename is `yoi`.
+- Panel Companion uses the workspace basename Pod, while Orchestrator remains distinct such as `<workspace>-orchestrator`.
+- Ticket role Pods keep explicit role/task-derived names.
+- Tests must include a non-`yoi` workspace and explicit `--pod` precedence.
+
+Escalate if:
+- Existing Pod metadata would need automatic rename/migration.
+- Workspace-root context is insufficient to compute defaults consistently.
+- Any caller still requires Profile slug/source as an identity fallback.
+
+---

.yoi/tickets/open/20260608-000047-introduce-runtime-workspace-root-context/item.md

@@ -6,11 +6,13 @@ status: 'open'
 kind: 'task'
 priority: 'P1'
 labels: ['workspace', 'pod', 'profile', 'cli', 'panel', 'memory']
-workflow_state: 'intake'
+workflow_state: 'queued'
 created_at: '2026-06-08T00:00:47Z'
-updated_at: '2026-06-08T00:05:33Z'
+updated_at: '2026-06-08T00:52:23Z'
 assignee: null
 legacy_ticket: null
+queued_by: 'workspace-panel'
+queued_at: '2026-06-08T00:14:09Z'
 ---
 
 ## Background

.yoi/tickets/open/20260608-000047-introduce-runtime-workspace-root-context/thread.md

@@ -23,3 +23,198 @@ Avoid preserving the old split where profile startup uses `--profile-pod-name` a
 The intended end state is that every Pod startup path has an explicit runtime workspace and explicit Pod identity before profile resolution runs. Profile resolution should consume those runtime values, not invent them.
 
 ---
+
+<!-- event: intake_summary author: intake at: 2026-06-08T00:13:41Z -->
+
+## Intake summary
+
+Existing Ticket refined and duplicate check completed. Scope is to introduce a single explicit runtime workspace_root decided at startup and threaded through profile resolution, Pod startup/identity boundaries, Panel lifecycle, Ticket/project record discovery, and memory resolution while preserving separation from Profile-authored config, Pod identity, project records, and memory root. Readiness: implementation_ready for orchestration, but needs_preflight: true because it crosses CLI/profile/Pod metadata/persistence/panel/memory boundaries. Risk flags: workspace-context, profile-boundary, pod-identity, persistence, panel, memory-root, cli. Related Tickets to coordinate: remove-profile-derived-pod-names, use-workspace-basename-for-default-pod-name, add-pod-archive-fresh-start-path, memory-root-uses-yoi-memory-marker.
+
+---
+
+<!-- event: state_changed author: intake at: 2026-06-08T00:13:41Z from: intake to: ready reason: intake_ready field: workflow_state -->
+
+## State changed
+
+Intake considers this Ticket ready for Orchestrator routing. Queueing remains a separate user/panel action; implementation must not start until queued and accepted by the Orchestrator.
+
+---
+
+<!-- event: state_changed author: workspace-panel at: 2026-06-08T00:14:09Z from: ready to: queued reason: queued field: workflow_state -->
+
+## State changed
+
+Ticket queued for Orchestrator routing.
+
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-08T00:14:32Z -->
+
+## Decision
+
+Routing decision: preflight_needed
+
+Reason:
+- The Ticket is implementation-oriented but crosses CLI startup, Profile resolution, Pod identity/startup, Pod metadata/session persistence, Panel lifecycle, Ticket/project record discovery, and memory-root resolution boundaries.
+- Intake explicitly recorded `needs_preflight: true` and risk flags for workspace context, profile boundary, pod identity, persistence, panel, memory-root, and CLI concerns.
+- The Ticket depends on coordination with related Tickets (`remove-profile-derived-pod-names`, `use-workspace-basename-for-default-pod-name`, `add-pod-archive-fresh-start-path`, and the completed memory-root marker behavior), so binding boundaries must be written before coder delegation.
+- No preflight/design note is present yet that fixes which structures carry `workspace_root`, how restore/debug metadata is persisted, how `--workspace` interacts with `--pod`/`--profile`, and what is explicitly out of scope for the related naming/archive tickets.
+
+Evidence checked:
+- Ticket body: background, runtime workspace context requirements, boundary rules, CLI/process requirements, tests/validation, related Tickets, non-goals, and acceptance criteria.
+- Thread: explicit human coordination note on pairing workspace context with explicit Pod identity, intake summary, `ready -> queued` event.
+- Workspace state: `develop` has Ticket-record edits for this and another queued Ticket; no matching branch or worktree exists for this slug.
+- Visible Pods: Intake peers are live for this and related naming Tickets; no coder/reviewer implementation Pods are active.
+
+Next action:
+- Run `ticket-preflight-workflow` for this Ticket before implementation delegation.
+- Preflight should produce a concise binding design note covering: the runtime launch context type and ownership, startup call paths that must receive it, metadata/session persistence expectations, CLI surface (`--workspace`, `--pod`, `--profile`) boundaries, Panel/Ticket role launcher propagation, memory/project-root separation, related-ticket split, and focused validation plan.
+- Leave this Ticket queued for now; do not transition `queued -> inprogress`, create `.worktree/introduce-runtime-workspace-root-context`, or spawn coder/reviewer Pods until preflight records implementation readiness.
+
+Escalate if:
+- A single `workspace_root` requires storage migration or compatibility policy for existing Pod metadata.
+- The CLI boundary requires removing/renaming public flags beyond this Ticket's intended scope.
+- Coordination with profile-derived naming/default Pod naming cannot be cleanly separated into the related Tickets.
+
+---
+
+<!-- event: decision author: hare at: 2026-06-08T00:45:54Z -->
+
+## Decision
+
+## Shared Pod identity / workspace boundary decision
+
+This decision is shared across these related Tickets:
+
+- `introduce-runtime-workspace-root-context`
+- `remove-profile-derived-pod-names`
+- `use-workspace-basename-for-default-pod-name`
+
+The three Tickets should be treated as a coordinated cleanup bundle, not as three unrelated design unknowns requiring separate heavy preflight. This decision supplies the binding boundary needed for Orchestrator routing; remaining uncertainty should be treated as coder implementation investigation unless it hits an escalation condition below.
+
+Binding decisions:
+
+- `--workspace <path>` represents the runtime workspace root.
+- `--pod <name>` represents the runtime Pod identity for both restore and fresh create.
+- `--profile <selector>` represents reusable Profile recipe selection only.
+- Lua Profile fields, Profile slug, Profile source, and registry entry names must not define or imply `pod.name`.
+- Default Pod name derives from the runtime workspace basename, not from product name, Profile slug/source, `.yoi` project-record marker, or memory root detection.
+- This repository's normal default Pod name is `yoi` only because the workspace directory basename is `yoi`.
+- Workspace Orchestrator remains a distinct runtime identity such as `<workspace>-orchestrator`.
+- Ticket role / task Pods should continue to use explicit role/task-derived names supplied by the launcher/orchestrator, not profile fallback names.
+- `.yoi` project records root, `.yoi/memory` memory root, and runtime workspace root are separate concepts.
+- Memory root behavior from `memory-root-uses-yoi-memory-marker` must be preserved: explicit `memory.workspace_root` wins; otherwise nearest `.yoi/memory`; `.yoi` alone is not a memory root marker.
+- `resume_by_pod_name` / `--profile-pod-name` are cleanup targets. Prefer collapsing startup around explicit `--pod <name> --profile <selector>` plus runtime workspace context. If an explicit startup-mode enum is needed, it should model restore/create policy directly rather than hide it behind a boolean named `resume_by_pod_name`.
+- Existing Pod metadata migration/renaming and archive/fresh-start behavior are out of scope for this implementation bundle unless explicitly required by tests; `add-pod-archive-fresh-start-path` covers archive/fresh-start UX.
+
+Implementation latitude:
+
+- The coder may discover exact call sites, structure names, helper placement, and test organization during implementation.
+- The coder may split changes across the three Tickets if needed, but should preserve the above boundaries and avoid adding compatibility layers just to preserve profile-derived identity.
+- Tests should include non-`yoi` workspace names so dogfooding does not hide hardcoded/default-name bugs.
+
+Escalate if:
+
+- Removing `--profile-pod-name` requires a public compatibility policy beyond internal cleanup.
+- Existing Pod metadata needs automatic migration or destructive modification.
+- A caller genuinely cannot supply runtime workspace root or Pod identity without reintroducing profile-derived naming.
+- The implementation would make `.yoi` alone a memory root marker again.
+- The implementation would weaken explicit `--pod` precedence or make Profile selection influence Pod identity.
+
+With this decision recorded, this Ticket can proceed as implementation-ready if Orchestrator can write a bounded IntentPacket from the Ticket body and this shared decision. A separate heavy preflight is not required unless one of the escalation conditions is reached.
+
+---
+
+<!-- event: decision author: orchestrator at: 2026-06-08T00:52:23Z -->
+
+## Decision
+
+Routing decision: implementation_ready
+
+Reason:
+- The shared human decision recorded on all three related Tickets supplies the missing preflight boundary: `--workspace` is runtime workspace root, `--pod` is runtime Pod identity, `--profile` is recipe selection only, and Profile slug/source/registry names must never imply `pod.name`.
+- Remaining uncertainty is now bounded implementation investigation: exact call sites, type placement, helper names, and test organization.
+- Current code map confirms the relevant surfaces are narrow enough for a coder IntentPacket: `crates/manifest/src/profile.rs` still derives Pod names from Profile source/slug and hardcoded `DEFAULT_POD_NAME`; `crates/client/src/spawn.rs`, `crates/tui/src/spawn.rs`, `crates/tui/src/multi_pod.rs`, `crates/pod/src/entrypoint.rs`, and `crates/client/src/ticket_role.rs` carry the spawn/profile identity split; Panel already has workspace companion/orchestrator name helpers that should be preserved/consumed.
+
+Evidence checked:
+- Ticket body and thread, including the new shared boundary decision.
+- Related Tickets: `remove-profile-derived-pod-names` and `use-workspace-basename-for-default-pod-name` now contain the same binding decision.
+- Workspace state: only Ticket/project-record files are dirty; no implementation branch/worktree exists yet.
+- Code map searches for `DEFAULT_POD_NAME`, `derive_pod_name`, `resume_by_pod_name`, `profile_pod_name`, `workspace_root`, `SpawnConfig`, Panel, and Ticket role launch paths.
+- Ticket doctor: 0 errors; existing warnings are unrelated legacy closed-Ticket diagnostics.
+
+IntentPacket:
+
+Intent:
+- Implement the coordinated runtime workspace / Pod identity cleanup bundle across this Ticket plus `remove-profile-derived-pod-names` and `use-workspace-basename-for-default-pod-name`.
+- Make startup identity explicit: runtime workspace root, runtime Pod name, and Profile selector are separate values.
+
+Binding decisions / invariants:
+- `--workspace <path>` represents runtime workspace root.
+- `--pod <name>` represents runtime Pod identity for both restore and fresh create.
+- `--profile <selector>` represents reusable Profile recipe selection only.
+- Profile fields, Profile slug/source, and registry entry names must not define or imply `pod.name`.
+- Default Pod name derives from the runtime workspace basename; this repo defaults to `yoi` only because the directory basename is `yoi`.
+- Workspace Orchestrator remains distinct, e.g. `<workspace>-orchestrator`.
+- Ticket role/task Pods keep explicit launcher/orchestrator-provided names.
+- `.yoi` project records root, `.yoi/memory` memory root, and runtime workspace root stay separate.
+- Preserve memory-root behavior: explicit `memory.workspace_root` wins; otherwise nearest `.yoi/memory`; `.yoi` alone is not a memory root marker.
+- Existing Pod metadata migration/renaming and archive/fresh-start UX are out of scope unless tests force a minimal non-destructive adjustment.
+
+Requirements / acceptance criteria:
+- Introduce/pass a single explicit runtime `workspace_root` through startup/profile/Panel/Pod runtime paths where needed.
+- Add or wire a clear CLI/process boundary for `--workspace`, `--pod`, and `--profile`.
+- Remove Profile-derived Pod name fallback in `crates/manifest/src/profile.rs`.
+- Remove or collapse the `resume_by_pod_name` / `--profile-pod-name` split unless a real explicit startup-mode enum is necessary.
+- Replace product-name-specific default identity with sanitized workspace basename and generic fallback only when no useful basename exists.
+- Keep explicit `--pod` precedence.
+- Preserve Panel Companion and Orchestrator lifecycle semantics while making Companion use workspace basename and Orchestrator use a distinct explicit name.
+- Add regression tests using non-`yoi` workspace names and Profile selectors such as `project:companion`.
+
+Implementation latitude:
+- Coder may choose exact type names, helper placement, call-site order, and test module organization.
+- Coder may implement the three Tickets as one coordinated branch if the diff remains coherent and each Ticket's acceptance criteria are addressed.
+- Coder may retain internal transitional plumbing only if it does not let Profile selection influence Pod identity and is reported clearly.
+
+Non-goals / constraints:
+- Do not migrate/rename existing Pod metadata automatically.
+- Do not implement archive/fresh-start UX; that belongs to `add-pod-archive-fresh-start-path`.
+- Do not make `.yoi` alone a memory-root marker again.
+- Do not edit main-workspace Ticket/workflow/docs records from the coder Pod.
+- Do not add compatibility layers solely to preserve Profile-derived identity.
+
+Escalate if:
+- Removing `--profile-pod-name` requires a public compatibility policy.
+- Existing Pod metadata needs automatic migration or destructive modification.
+- Any caller genuinely cannot supply runtime workspace root or Pod identity without reintroducing Profile-derived naming.
+- The implementation would weaken explicit `--pod` precedence or make Profile selection influence Pod identity.
+- The work expands into broad Pod archive/fresh-start behavior or memory-root redesign.
+
+Validation:
+- Focused tests around profile resolution and Pod naming, including non-`yoi` workspace cases.
+- Relevant client/tui/pod tests for spawn/profile/Ticket role/Panel lifecycle paths.
+- `cargo test -p manifest profile --lib` or corrected equivalent manifest profile test invocation.
+- `cargo fmt --check`.
+- `git diff --check`.
+- `target/debug/yoi ticket doctor`.
+- Because startup/profile/runtime resources are touched, final validation should include `nix build .#yoi` before completion unless explicitly waived.
+
+Current code map:
+- `crates/manifest/src/profile.rs`: `DEFAULT_POD_NAME`, `derive_pod_name`, profile resolution options/tests.
+- `crates/client/src/spawn.rs`: `SpawnConfig`, runtime command argument construction, profile/name behavior.
+- `crates/pod/src/entrypoint.rs`: `--profile-pod-name`, profile loading path, CLI tests.
+- `crates/tui/src/spawn.rs` and `crates/tui/src/multi_pod.rs`: TUI spawn form, workspace companion/orchestrator lifecycle, `resume_by_pod_name` call sites.
+- `crates/client/src/ticket_role.rs`: Ticket role launch naming/profile boundary.
+- `crates/tui/src/workspace_panel.rs`: workspace companion/orchestrator Pod name helpers.
+- Memory resolution code must be treated as invariant-preserving unless a focused test requires wiring runtime workspace root input.
+
+Critical risks / reviewer focus:
+- Profile selector must not influence Pod identity through any fallback path.
+- Explicit `--pod` must remain authoritative.
+- Non-`yoi` workspace tests must fail on the old behavior.
+- Panel Companion must not recreate the `companion`-named bug.
+- Ticket role and Orchestrator names must remain explicit and distinct from Companion defaults.
+- Memory root and project root must not be collapsed.
+
+---