yoi/work-items/open/20260605-210704-workspace-orchestration-panel-design/item.md

id	slug	title	status	kind	priority	labels	created_at	updated_at	assignee	legacy_ticket
20260605-210704-workspace-orchestration-panel-design	workspace-orchestration-panel-design	Workspace orchestration panel design	open	task	P1	tui design orchestration panel	2026-06-05T21:07:04Z	2026-06-05T21:32:54Z	null	null

Background

The next TUI should not be another small : command extension. The desired feature is a workspace-scoped orchestration panel with explicit Companion/Intake composer targets, background Orchestrator lifecycle, Intake handoff, and a user-action-oriented model.

Requirements

Produce a design artifact that fixes:

• panel entrypoint and relation to current --multi;
• Companion lifecycle and identity;
• workspace Orchestrator lifecycle and naming rule (<dir-name>-orchestrator);
• composer target model:
  • Companion;
  • Ticket Intake;
• how Intake launch avoids writing the user request into the Companion/current Pod history;
• how Intake receives Orchestrator notification/handoff target;
• action model priorities:
  • user response required;
  • Intake draft ready;
  • Ticket ready for Go;
  • blocked/action-required;
  • review/close/preflight decisions;
  • active background work;
  • informational Pod status;
• Go semantics for a fixed Ticket;
• relationship to existing :ticket ... command fallback;
• failure/diagnostic behavior;
• implementation sequence.

Non-goals

• Code implementation.
• Generic scheduler/lease/queue.
• Automatic implementation without Go/authorization.
• Replacing Ticket workflows.

Acceptance criteria

• A design artifact exists under this Ticket's artifacts/ directory.
• The artifact defines the state/action model and responsibility boundaries clearly enough to implement child tickets.
• The artifact defines a UI intermediate representation between runtime/domain state and rendering.
• The artifact specifies that the concrete visual design follows existing TUI conventions/components rather than inventing a separate dashboard style.
• The artifact explicitly preserves history/context rules: dynamic messages are committed to the destination Pod history, not injected into hidden context.
• Reviewer or parent approves the design before implementation child tickets proceed.