ticket: add pod naming cleanup tasks

2026-06-08 09:07:29 +09:00
parent 6903eea686
commit c6afb5004b
12 changed files with 343 additions and 0 deletions
@@ -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.
@@ -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.
+
+---