ticket: add pod naming cleanup tasks

.yoi/tickets/open/20260607-234530-add-pod-archive-fresh-start-path/item.md

@@ -0,0 +1,60 @@
+---
+id: 20260607-234530-add-pod-archive-fresh-start-path
+slug: add-pod-archive-fresh-start-path
+title: Add Pod archive and fresh-start path
+status: open
+kind: task
+priority: P2
+labels: [pod, panel, cli, lifecycle, metadata]
+workflow_state: intake
+created_at: 2026-06-07T23:45:30Z
+updated_at: 2026-06-07T23:45:30Z
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+Panel Companion and Orchestrator lifecycle currently restore restorable Pods by name before spawning a missing Pod. This is correct for normal continuity, but after updating workflows/profiles/system guidance, a user may want to intentionally start a fresh same-name Pod instead of restoring old Pod metadata/history.
+
+Currently there is no explicit Panel/CLI path to archive or reset a restorable Pod name before fresh creation. The practical workaround is to manually rename/archive the Pod metadata directory under the user data dir, e.g. `~/.yoi/pods/<pod-name>/`, which is unsafe and not discoverable.
+
+Example:
+
+- Workspace Companion name is `yoi`.
+- `yoi panel` sees `yoi` as restorable and restores it.
+- User wants a fresh `yoi` Companion after workflow/profile changes.
+- There is no `fresh` / `archive` action in Panel or CLI, so manual metadata directory surgery is the only apparent route.
+
+## Goal
+
+Provide an explicit, safe Pod archive/reset/fresh-start path for same-name Pods so users do not need to manually edit `~/.yoi/pods` metadata.
+
+## Requirements
+
+- Add a user-facing way to archive or reset a stopped/restorable Pod name so the next same-name launch is fresh.
+- Refuse to archive/reset a live reachable Pod unless it is explicitly stopped first.
+- Preserve old metadata/history by default; prefer archive/rename over destructive delete.
+- Make the archive location/name deterministic and collision-safe.
+- Surface what will happen clearly:
+  - archived Pod metadata will no longer be restored by name;
+  - session logs/history are preserved where applicable;
+  - next launch with the same name will create a fresh Pod.
+- Support the Panel Companion use case where the workspace Companion name is fixed to the workspace basename, e.g. `yoi`.
+- Consider both CLI and Panel/TUI surfaces.
+  - CLI examples could be `yoi pod archive <name>` or `yoi pod reset <name>`.
+  - Panel could expose a bounded action/diagnostic path for `fresh Companion` if appropriate.
+- Keep normal lifecycle behavior unchanged: live -> use, restorable -> restore, missing -> spawn.
+- Do not silently bypass restore just because profiles/workflows changed; fresh must be explicit.
+- Avoid manual modification of `~/.yoi/pods` in docs except as an emergency/debug note.
+
+## Acceptance criteria
+
+- A stopped/restorable Pod can be archived via an official command/action.
+- After archive, the same Pod name is treated as missing for attach/panel lifecycle and can be spawned fresh.
+- Live Pods are protected from archive/reset without an explicit stop path.
+- Archive preserves enough metadata/history for later inspection or manual recovery.
+- Panel Companion `yoi` can be refreshed without hand-renaming data-dir metadata.
+- Tests cover archive refusal for live Pods, archive success for stopped/restorable Pods, and fresh same-name spawn after archive.
+- Relevant docs/help text are updated.
+- `cargo test` focused suites, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

.yoi/tickets/open/20260607-234530-add-pod-archive-fresh-start-path/thread.md

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-07T23:45:30Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---

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

@@ -0,0 +1,55 @@
+---
+id: '20260607-235442-remove-profile-derived-pod-names'
+slug: 'remove-profile-derived-pod-names'
+title: 'Remove Profile-derived Pod names'
+status: 'open'
+kind: 'task'
+priority: 'P1'
+labels: ['profile', 'pod', 'identity', 'manifest', 'bug']
+workflow_state: 'intake'
+created_at: '2026-06-07T23:54:42Z'
+updated_at: '2026-06-08T00:05:23Z'
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+Profiles are intended to be reusable role/config recipes: model, worker behavior, tools, scope intent, memory/web/compaction, prompts/skills, etc. Pod identity is runtime state and should not be authored by a Profile.
+
+The current Profile resolver still has a fallback that derives `pod.name` from the Profile `slug` or source name when no runtime Pod name override is supplied:
+
+```rust
+let pod_name = options
+    .pod_name
+    .unwrap_or_else(|| derive_pod_name(&source, profile.slug.as_deref()));
+```
+
+This caused a real bug in the workspace panel: the panel intended to spawn the workspace Companion as `yoi`, but because no explicit Pod name was passed to the child profile startup path, the project default profile `project:companion` resolved to Pod name `companion` from its slug.
+
+The Lua Profile surface should not be able to define or imply Pod identity. Even if `pod.name` is not directly accepted inside the Lua Profile schema, `slug -> pod.name` fallback is still a profile-derived identity path and should be removed.
+
+## Goal
+
+Remove Profile-derived Pod naming. Pod name must come from runtime identity selection, not from Lua Profile fields, Profile slug, Profile source name, or registry entry name.
+
+## Requirements
+
+- Remove `profile.slug` / Profile source / registry entry fallback as a `pod.name` derivation path.
+- Profile resolution should require an explicit runtime Pod name input, or a caller-provided default Pod name policy outside Profile resolution.
+- Lua Profiles must remain reusable recipes and must not define Pod identity.
+- Keep `slug` only as profile metadata/selection identity if still useful; it must not become `pod.name`.
+- Reject any direct Lua Profile `pod.name` / manifest-shaped identity field as today, and update diagnostics/tests to make the boundary clear.
+- Update callers that currently rely on implicit Profile-derived names to supply a runtime Pod name explicitly.
+- Ensure workspace project profiles such as `project:companion`, `project:coder`, etc. do not create Pods named `companion` / `coder` merely because of their slug.
+- Revisit or remove `--profile-pod-name` if it exists only to compensate for Profile-derived naming. Prefer a clearer API where `--pod <name>` is the Pod identity and `--profile <selector>` is the recipe selection, if compatible with the CLI model.
+- Add tests with non-`yoi` workspace names so dogfooding does not mask profile-derived naming bugs.
+
+## Acceptance criteria
+
+- Resolving `project:companion` without a runtime Pod name no longer yields `pod.name = companion`.
+- All fresh Pod creation paths supply Pod identity from runtime policy, not Profile slug/source.
+- Existing `SpawnPod` / Ticket role / Panel lifecycle paths still pass explicit names and continue working.
+- Profile metadata still records profile slug/source for diagnostics, but does not affect Pod identity.
+- Tests cover project profile slug not becoming Pod name.
+- `cargo test -p manifest profile --lib`, relevant TUI/client/pod tests, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

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

@@ -0,0 +1,39 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-07T23:54:42Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---
+
+<!-- event: decision author: hare at: 2026-06-08T00:05:23Z -->
+
+## Decision
+
+## Decision update: remove `resume_by_pod_name` / `--profile-pod-name` split
+
+While removing Profile-derived Pod names, also remove the confusing startup split that led to this boundary problem.
+
+Current issue:
+
+- `SpawnConfig::resume_by_pod_name` does not mean "inherit only the name while resuming"; it means "pass `--pod <pod_name>` to the child process so name-keyed restore/create happens".
+- When `resume_by_pod_name = false`, `spawn_pod` may omit `--pod <pod_name>`, allowing profile resolution to derive Pod identity from profile slug/source.
+- `--profile-pod-name` exists as a workaround for profile startup needing a Pod name without using `--pod`, but this preserves the false separation between profile selection and runtime identity.
+
+Desired direction:
+
+- `--pod <name>` is the runtime Pod identity for both restore and fresh create.
+- `--profile <selector>` is only the Profile recipe selection.
+- `--workspace <path>` / runtime workspace context supplies the workspace root.
+- Profile slug/source must never supply `pod.name`.
+
+Implementation requirements:
+
+- Remove `resume_by_pod_name` from `SpawnConfig` or replace it with a clearer startup-mode enum only if a distinct mode is truly needed.
+- Make spawn helpers pass explicit Pod identity for all fresh/restore paths instead of conditionally omitting `--pod`.
+- Remove `--profile-pod-name` from the public/runtime argument surface if possible; otherwise mark it internal/deprecated with a follow-up to remove it.
+- Support `--pod <name> --profile <selector>` as the normal way to start a named Pod with a selected Profile.
+- If restore/create semantics need to be controlled, model that explicitly as startup policy rather than a boolean named `resume_by_pod_name`.
+- 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.
+
+---

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

@@ -0,0 +1,59 @@
+---
+id: '20260607-235505-use-workspace-basename-for-default-pod-name'
+slug: 'use-workspace-basename-for-default-pod-name'
+title: 'Use workspace basename for default Pod name'
+status: 'open'
+kind: 'task'
+priority: 'P1'
+labels: ['pod', 'identity', 'workspace', 'cli', 'panel']
+workflow_state: 'intake'
+created_at: '2026-06-07T23:55:05Z'
+updated_at: '2026-06-07T23:55:05Z'
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+Dogfooding happens in a repository whose directory name is `yoi`, which masked hardcoded/default Pod naming problems. Some runtime paths still use `DEFAULT_POD_NAME = "yoi"` or otherwise derive a default identity that is product-name-specific rather than workspace-specific.
+
+At the same time, other paths already default Pod names from the current workspace directory basename. The intended behavior is to unify on workspace-based runtime naming:
+
+- normal workspace Companion/default Pod name is the workspace directory basename;
+- this repository's name happens to be `yoi`, but that should be an outcome of basename derivation, not a hardcoded default;
+- Orchestrator and role/task Pods can derive distinct names from the workspace/task/role, but should be explicit runtime names;
+- Profile selection must not determine Pod identity.
+
+## Goal
+
+Unify default Pod naming around the workspace/current-directory basename and remove product-name-specific hardcoded defaults such as `"yoi"` from runtime identity selection.
+
+## Requirements
+
+- Audit Pod naming paths and identify every use of hardcoded `"yoi"` / `DEFAULT_POD_NAME` as runtime identity.
+- Replace default fresh Pod naming with sanitized workspace/current-directory basename where appropriate.
+- Keep a generic fallback such as `"pod"` only when no useful workspace basename is available.
+- Ensure top-level fresh startup, TUI spawn form defaults, Panel Companion lifecycle, and CLI/runtime helper paths use consistent naming policy.
+- Preserve explicit `--pod <name>` behavior: explicit names always win.
+- Keep workspace Orchestrator distinct from Companion/default Pod, e.g. `<workspace>-orchestrator`.
+- Ensure Ticket role Pods continue to use explicit role/task-derived names and do not fall back to the generic workspace Companion name unless intended.
+- Add tests using a non-`yoi` workspace directory to prove the default Pod name is the directory basename.
+- Coordinate with `remove-profile-derived-pod-names`: Profile slug/source must not influence the default Pod name.
+- Update docs/help text if they imply the default Pod name is `yoi`.
+
+## Non-goals
+
+- Do not rename historical existing Pod metadata automatically.
+- Do not change explicit Pod names already stored in existing metadata.
+- Do not implement archive/fresh-start behavior here; that is covered by `add-pod-archive-fresh-start-path`.
+- Do not redesign product/repository naming beyond removing hardcoded runtime identity defaults.
+
+## Acceptance criteria
+
+- In a workspace directory named `example-project`, fresh default startup creates/uses Pod name `example-project` unless an explicit name is provided.
+- In this repository, the default remains `yoi` only because the directory basename is `yoi`.
+- No runtime fresh-start path relies on `DEFAULT_POD_NAME = "yoi"` as the normal identity default.
+- Panel Companion missing spawn requests and verifies the workspace basename Pod name.
+- Orchestrator remains `<workspace>-orchestrator` or equivalent distinct runtime name.
+- Tests cover non-`yoi` workspace naming and explicit `--pod` precedence.
+- Relevant `cargo test` suites, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

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

@@ -0,0 +1,7 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-07T23:55:05Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---

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

@@ -0,0 +1,91 @@
+---
+id: '20260608-000047-introduce-runtime-workspace-root-context'
+slug: 'introduce-runtime-workspace-root-context'
+title: 'Introduce runtime workspace root context'
+status: 'open'
+kind: 'task'
+priority: 'P1'
+labels: ['workspace', 'pod', 'profile', 'cli', 'panel', 'memory']
+workflow_state: 'intake'
+created_at: '2026-06-08T00:00:47Z'
+updated_at: '2026-06-08T00:05:33Z'
+assignee: null
+legacy_ticket: null
+---
+
+## Background
+
+Workspace/root concepts are currently inferred in multiple places from `current_dir()`, `.yoi` project records, `.yoi/memory`, profile resolution, Panel lifecycle, and Pod runtime startup. This has caused repeated boundary confusion:
+
+- profile slug/source can leak into Pod identity;
+- hardcoded `DEFAULT_POD_NAME = "yoi"` is masked by dogfooding in a repo named `yoi`;
+- Panel Companion intended to spawn workspace basename `yoi`, but a profile-derived name `companion` was created;
+- memory root detection was already corrected to use explicit `memory.workspace_root` or nearest `.yoi/memory`, not `.yoi` alone;
+- child worktrees may contain `.yoi` project records but should not inherit memory root or Pod identity from the parent unless explicitly intended.
+
+The system needs a single runtime workspace context decided at process/Pod startup and passed through the relevant resolution layers, rather than rediscovered ad hoc at each use site.
+
+## Goal
+
+Introduce an explicit runtime `workspace_root` launch context that is determined once at startup (defaulting to process cwd or an explicit CLI argument) and then passed to profile resolution, Pod naming, Panel lifecycle, Ticket/project record discovery, and memory resolution as appropriate.
+
+## Requirements
+
+### Runtime workspace context
+
+- Add a runtime launch context field such as `workspace_root: PathBuf` to the relevant startup/config structures.
+- Determine it at top-level startup:
+  - default to process cwd;
+  - support an explicit CLI option such as `--workspace <path>` if appropriate for both normal TUI/Pod and panel flows.
+- Pass the resolved workspace root explicitly to child/runtime Pod startup instead of relying on child process cwd where possible.
+- Persist/snapshot the resolved workspace root in Pod metadata/session state where needed for restore/debug visibility.
+
+### Boundary rules
+
+- `workspace_root` is runtime/user intent, not Profile-authored config.
+- Profile selection must not determine `workspace_root` or `pod.name`.
+- Default Pod naming should derive from `workspace_root.file_name()` via the separate Pod naming cleanup ticket.
+- Project records root (`.yoi/tickets`, `.yoi/workflow`, `.yoi/profiles.toml`) may be discovered from or relative to the runtime workspace, but must remain conceptually separate from memory root.
+- Memory root behavior remains:
+  - explicit `memory.workspace_root` wins;
+  - otherwise nearest ancestor with `.yoi/memory` from the runtime workspace/default root;
+  - `.yoi` alone is not a memory root marker.
+- Child worktrees should use their own runtime workspace root when launched there, even if memory/project records resolve to an ancestor.
+
+### CLI / process boundaries
+
+- Prefer a clear boundary:
+  - `--workspace <path>` = runtime workspace root;
+  - `--pod <name>` = Pod identity;
+  - `--profile <selector>` = Profile recipe.
+- Avoid `--profile-pod-name` as a long-term public surface; if still needed internally, document and plan removal/renaming.
+- Ensure Panel, Ticket role launcher, SpawnPod/client spawn helpers, and normal TUI startup pass the same workspace context consistently.
+
+### Tests / validation
+
+- Add tests using non-`yoi` workspace directory names to avoid dogfooding masking.
+- Add tests for child worktree cases where `.yoi` project records are present but `.yoi/memory` is absent.
+- Verify runtime workspace basename, project profile discovery, and memory root resolution do not collapse into the same concept.
+
+## Related tickets
+
+- `remove-profile-derived-pod-names`
+- `use-workspace-basename-for-default-pod-name`
+- `add-pod-archive-fresh-start-path`
+- `memory-root-uses-yoi-memory-marker` is already implemented and should be preserved.
+
+## Non-goals
+
+- Do not redesign memory root resolution beyond preserving the existing `.yoi/memory` marker behavior.
+- Do not rename existing Pod metadata automatically.
+- Do not implement profile-derived naming removal or default Pod naming cleanup here if those are handled by the related tickets; coordinate boundaries.
+
+## Acceptance criteria
+
+- There is a single explicit runtime workspace root available to startup, profile resolution, Panel lifecycle, and Pod runtime code.
+- Normal startup and `yoi panel` can be pointed at a workspace with `--workspace` or an equivalent explicit context.
+- Default Pod naming and Panel Companion naming can consume this runtime workspace root without re-detecting via `.yoi` or memory root.
+- Project records and memory root resolution remain separate and tested.
+- Non-`yoi` workspace tests prove runtime workspace identity does not fall back to hardcoded product names.
+- Relevant docs/help text are updated.
+- Focused tests, `cargo fmt --check`, `git diff --check`, and `target/debug/yoi ticket doctor` pass.

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

@@ -0,0 +1,25 @@
+<!-- event: create author: LocalTicketBackend at: 2026-06-08T00:00:47Z -->
+
+## Created
+
+Created by LocalTicketBackend create.
+
+---
+
+<!-- event: decision author: hare at: 2026-06-08T00:05:33Z -->
+
+## Decision
+
+## Coordination note: workspace context should pair with explicit Pod identity
+
+The runtime workspace context cleanup should align with `remove-profile-derived-pod-names` by making startup boundaries explicit:
+
+- `--workspace <path>`: runtime workspace root.
+- `--pod <name>`: runtime Pod identity for restore or fresh create.
+- `--profile <selector>`: reusable Profile recipe.
+
+Avoid preserving the old split where profile startup uses `--profile-pod-name` and non-profile startup uses `--pod`. That split allowed `SpawnConfig::resume_by_pod_name = false` to omit the runtime identity and let profile slug/source derive `pod.name`.
+
+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.
+
+---