50 lines
3.2 KiB
Markdown
50 lines
3.2 KiB
Markdown
---
|
|
title: "Remove Profile-derived Pod names"
|
|
state: "closed"
|
|
created_at: "2026-06-07T23:54:42Z"
|
|
updated_at: "2026-06-08T02:00:18Z"
|
|
queued_by: "workspace-panel"
|
|
queued_at: "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:
|
|
|
|
```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.
|