yoi/.yoi/tickets/00001KTJ855EG/item.md

title	state	created_at	updated_at	queued_by	queued_at
Remove Profile-derived Pod names	closed	2026-06-07T23:54:42Z	2026-06-08T02:00:18Z	workspace-panel	2026-06-08T00:32:56Z

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:

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.