## Created Created by LocalTicketBackend create. --- ## Decision Decision from user discussion: The panel should not provide direct messaging to arbitrary selected Pods. The existing `Companion` composer target is currently a misleading label for selected-Pod direct send and should be replaced by a real workspace Companion Pod. Target model: - default panel composer talks to a workspace-named Companion Pod; - Companion is a foreground management chat for the human; - Ticket Intake remains a separate target for new requests; - selected Pod direct send is removed; - Pod attach/open remains available for inspection; - Companion should be status-aware but not directly write/mutate project state; - Companion prompt/tool policy should focus on situational awareness and human support, with direct writes/Ticket mutations/implementation spawning prohibited by default. Split child tickets were created for direct-send removal, Companion lifecycle, and Companion prompt/tool policy. --- ## Decision ## Local role/session overlay split The Companion/panel redesign should not store Ticket↔local Pod assignment in git-tracked Ticket metadata. Local Pod names, runtime/session identity, socket/restorable state, and current claims are per-machine runtime concerns. A new child ticket `workspace-panel-local-role-session-registry` covers the local overlay model: - Ticket project records keep workflow state and auditable summaries only. - A Ticket may have at most one active local Pod claim at a time. - A Pod/session may relate to zero or more Tickets. - Intake is not 1:1 with Ticket: pre-Ticket Intake may have no Ticket yet, and one Intake session may materialize/split into multiple Tickets. - Existing `ticket-*` Pod visibility in the panel is acceptable as an interim access path until the registry UI/model exists. - The panel should not poll and automatically start Intake for newly-created `workflow_state = intake` Tickets; starting/claiming remains an explicit action. --- ## Decision ## Orchestrator automation follow-up Created `workspace-panel-orchestrator-queue-automation` to cover the missing end-to-end route from Panel Intake/Queue into Orchestrator-managed work. This follow-up fixes the intended `queued` semantics: - `queued` means the human authorized Orchestrator routing; - the Orchestrator should inspect Ticket/workspace state and start if unblocked; - conflicts, dependency blockers, preflight gaps, and capacity constraints are Orchestrator decisions, not reasons for the panel to stay passive forever. This remains separate from Companion lifecycle and local role/session registry work, but may consume the registry once available to avoid duplicate ownership. --- ## Decision ## Priority adjustment Companion work is useful but not required for near-term panel operation. The panel can still be used by manually attaching/opening Pods, and the direct selected-Pod send path has already been removed. Decision: downgrade Companion-related follow-up priority to P2 so near-term focus can stay on Ticket role config strictness/init, Orchestrator queue automation, and workflow/compaction reliability. --- ## State changed Ticket を closed にしました。 --- ## 完了 Closed as completed by child Tickets. The original Workspace Panel Companion interface plan has been implemented through more specific work: - direct selected-Pod send was removed from the Panel composer path; - Panel composer routing now targets the workspace Companion and Ticket Intake explicitly; - workspace Companion Pod lifecycle restore/spawn/observe behavior is implemented; - local role/session registry and Ticket claim handling were added for Panel-launched role sessions; - project role Profile feature defaults limit Companion authority and keep Ticket orchestration / Pods / Task disabled for Companion by default. The remaining work in this area should be tracked as targeted follow-up Tickets rather than keeping this umbrella planning Ticket open. ---