Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

ticket: preflight remove direct pod send

Browse Source
This commit is contained in:
Keisuke Hirata 2026-06-07 10:32:22 +09:00
parent 1b7de88a59
commit 9717d64458
No known key found for this signature in database
2 changed files with 63 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.yoi/tickets/open/20260607-001651-workspace-panel-remove-direct-pod-send/item.md
View File

@ -6,9 +6,9 @@ status: open
kind: task
priority: P1
labels: [tui, panel, companion, cleanup]
workflow_state: intake
workflow_state: ready
created_at: 2026-06-07T00:16:51Z
updated_at: 2026-06-07T00:16:51Z
updated_at: 2026-06-07T01:32:18Z
assignee: null
legacy_ticket: null
---

61
.yoi/tickets/open/20260607-001651-workspace-panel-remove-direct-pod-send/thread.md
View File

@ -4,4 +4,65 @@
Created by LocalTicketBackend create.
---
<!-- event: plan author: hare at: 2026-06-07T01:32:12Z -->
## Plan
## Preflight / implementation intent
Classification: implementation-ready.
Intent:
- Remove the workspace panel path that treats `Companion` composer input as a direct `Method::Run` send to the selected Pod.
- Keep Pod open/attach, Ticket Intake launch, Orchestrator lifecycle, Queue/Ticket actions, and Pod discovery intact.
- Until the real Companion Pod lifecycle exists, Companion composer submit should produce a bounded diagnostic instead of falling back to selected-Pod direct send.
Requirements:
- `Enter` on non-empty Companion composer input must not send to `selected_pod.socket_path`.
- UI/status/key hints must stop advertising selected-Pod direct send.
- Pod rows should advertise/open attach behavior, not direct-send behavior.
- Ticket Intake target must still build and launch Intake requests.
- Existing no-Ticket panel remains useful for discovering and opening Pods.
Invariants / boundaries:
- Do not implement real Companion Pod lifecycle here; that belongs to `workspace-panel-companion-pod-lifecycle`.
- Do not change Companion tool/profile policy here; that belongs to `companion-status-context-tool-policy`.
- Do not remove Pod attach/open.
- Do not reintroduce single-Pod `:ticket` or old `--multi` semantics.
- Do not change Ticket workflow-state semantics.
Current code map:
- `crates/tui/src/multi_pod.rs`: `MultiPodApp::prepare_send`, `send_run_and_confirm`, Enter handling, status/help text, and tests currently embody selected-Pod direct send.
- `crates/tui/src/workspace_panel.rs`: `NextUserAction::SendToPod`, `pod_row`, and key hints currently advertise direct-send behavior for Pod rows.
- `crates/tui/src/multi_pod.rs`: `prepare_intake_launch` / `launch_intake_with_handoff` must remain intact for Ticket Intake.
Critical risks:
- Accidentally removing/weakening open/attach while deleting send behavior.
- Leaving stale status-bar/help text that still claims Enter sends to selected Pods.
- Conflating this cleanup with real Companion lifecycle and creating a fake/partial Companion implementation.
- Breaking Ticket Intake Enter behavior while removing Companion direct send.
Validation:
- Update focused `tui` unit tests that currently assert direct-send eligibility and non-empty Enter direct-send behavior.
- Run focused tests around `multi_pod` and `workspace_panel`, plus formatting/checks as appropriate for the diff.
---
<!-- event: intake_summary author: INSOMNIA at: 2026-06-07T01:32:18Z -->
## Intake summary
Implementation intent is clear: remove selected-Pod direct send from the workspace panel, keep Pod open/attach and Ticket Intake, and show a bounded diagnostic for Companion composer submit until the real Companion Pod lifecycle is implemented.
---
<!-- event: state_changed author: INSOMNIA at: 2026-06-07T01:32:18Z from: intake to: ready reason: intake_ready field: workflow_state -->
## State changed
Ticket intake complete; workflow_state intake -> ready.
---