From e418560a12f31299bad02ce594fc1d13043b62dc Mon Sep 17 00:00:00 2001 From: Hare Date: Sun, 7 Jun 2026 19:17:33 +0900 Subject: [PATCH] ticket: preflight companion pod lifecycle --- .../item.md | 11 ++-- .../thread.md | 58 +++++++++++++++++++ 2 files changed, 65 insertions(+), 4 deletions(-) diff --git a/.yoi/tickets/open/20260607-001651-workspace-panel-companion-pod-lifecycle/item.md b/.yoi/tickets/open/20260607-001651-workspace-panel-companion-pod-lifecycle/item.md index ccb1c835..6b1d5020 100644 --- a/.yoi/tickets/open/20260607-001651-workspace-panel-companion-pod-lifecycle/item.md +++ b/.yoi/tickets/open/20260607-001651-workspace-panel-companion-pod-lifecycle/item.md @@ -6,9 +6,9 @@ status: open kind: task priority: P2 labels: [tui, panel, companion, pod] -workflow_state: intake +workflow_state: ready created_at: 2026-06-07T00:16:51Z -updated_at: 2026-06-07T01:21:43Z +updated_at: 2026-06-07T10:17:33Z assignee: null legacy_ticket: null --- @@ -26,8 +26,11 @@ Restore or spawn a workspace-named Companion Pod when `yoi panel` opens, and rou ## Requirements - Define the Companion Pod naming rule. - - It should be based on the workspace name/path, consistent with existing default Pod naming where practical. - - Avoid colliding with the workspace Orchestrator name. + - Use the workspace directory basename as the Companion Pod id/name. + - For this repository, the Companion Pod id/name is `yoi`. + - Do not add a `-companion` suffix or introduce a separate companion-specific id for the normal workspace Companion. + - This intentionally lets `yoi panel` treat an existing default workspace Pod named `yoi` as the Companion when it is live/restorable. + - Avoid colliding with the workspace Orchestrator name, which remains distinct (for example `yoi-orchestrator`). - On `yoi panel` open: - if Companion is live, use it; - if restorable, restore it; diff --git a/.yoi/tickets/open/20260607-001651-workspace-panel-companion-pod-lifecycle/thread.md b/.yoi/tickets/open/20260607-001651-workspace-panel-companion-pod-lifecycle/thread.md index bacff5c2..8df72e30 100644 --- a/.yoi/tickets/open/20260607-001651-workspace-panel-companion-pod-lifecycle/thread.md +++ b/.yoi/tickets/open/20260607-001651-workspace-panel-companion-pod-lifecycle/thread.md @@ -16,4 +16,62 @@ Companion lifecycle should remain separate from Ticket/role Pod claim authority. The Companion may eventually read/display this derived status, but it should not own the registry or gain mutation authority by default. +--- + + + +## Plan + +## Preflight / implementation intent + +Decision: +- The workspace Companion Pod id/name is the workspace directory basename. +- For this repository, that id/name is `yoi`. +- Do not introduce a separate `yoi-companion` identity for the normal workspace Companion. +- `yoi panel` should treat an existing live/restorable default workspace Pod named `yoi` as the Companion. +- The workspace Orchestrator remains a distinct identity such as `yoi-orchestrator`. + +Readiness: +- This ticket is implementation-ready after `workspace-orchestrator-spawn-diagnostic-persistence` landed. +- Orchestrator scope conflict diagnostics are now persistent enough to distinguish expected scope conflicts from plain missing state during panel dogfooding. + +Current code map: +- `crates/tui/src/multi_pod.rs` + - owns panel load/reload, `MultiPodApp`, composer target dispatch, pending reloads, and current Orchestrator lifecycle glue. + - current Companion composer target is not backed by a real Companion lifecycle and should be connected here or through a small helper module. +- `crates/tui/src/workspace_panel.rs` + - owns panel model/header rows/composer target model and diagnostics. +- `crates/tui/src/pod_list.rs` + - Pod list/read/restore/open helpers may be useful for determining live/restorable Companion presence. +- `crates/client/src/ticket_role.rs` + - Ticket role launcher is separate; Companion is not a Ticket role and should not be implemented as one. +- `crates/client/src/runtime_command.rs` and existing Pod spawn/restore client helpers + - likely source for typed runtime command and one-shot socket interaction. + +Implementation intent: +- Add a workspace Companion lifecycle alongside, but not inside, the Ticket Orchestrator lifecycle. +- On `yoi panel` open, resolve the Companion Pod name from the workspace directory basename (`yoi` here). +- If that Pod is live, use it; if restorable, restore it; if missing, spawn it with the configured/default Companion profile path as appropriate. +- Panel close must not stop it. +- Route the panel `Companion` composer target to this Companion Pod's user history. +- Preserve Ticket Intake as a separate target; Intake text must not be appended to Companion history. +- Keep no-Ticket workspaces functional: Companion management chat plus Pod inspect/open should work without `.yoi/ticket.config.toml`. +- Do not reintroduce selected-Pod direct send, `--multi`, or `:ticket`. + +Risks / boundaries: +- Companion should not be treated as a Ticket role and should not claim Ticket role session authority. +- Existing live `yoi` Pod may already own workspace write scope; the panel should reuse/attach/route to it rather than trying to spawn another `yoi` and failing with a scope conflict. +- If `yoi` is live but busy, message send behavior should follow existing Pod client semantics and report bounded diagnostics rather than inventing queueing in this ticket. +- Avoid broad UI restructuring; keep lifecycle state and diagnostics explicit and testable. +- If nonblocking spawn/restore requires more work, keep the implementation compatible with `workspace-panel-nonblocking-transitions` rather than solving that entire ticket here. + +Validation expected: +- Focused TUI tests for Companion naming (`yoi` from repo dir), live/restorable/missing lifecycle decisions, no-Ticket availability, and composer routing separation from Ticket Intake. +- Existing panel/Orchestrator tests still pass. +- `cargo test -p tui ... --lib` for affected tests. +- `cargo fmt --check`. +- `git diff --check`. +- `target/debug/yoi ticket doctor`. + + ---