diff --git a/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/artifacts/workspace-panel-ui-design.md b/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/artifacts/workspace-panel-ui-design.md index 05de7783..0a3cb51d 100644 --- a/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/artifacts/workspace-panel-ui-design.md +++ b/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/artifacts/workspace-panel-ui-design.md @@ -4,6 +4,8 @@ The workspace panel should be a successor to the current `--multi` surface, not a two-pane composition of `--multi` plus the normal single-Pod UI. The default unit should be Ticket/action state; Pods are execution/detail resources that the user can attach to on demand. +The panel is not only a Ticket status dashboard. It is a workspace cockpit for reading Ticket state, handling human decision points, launching Intake/Orchestrator actions, and drilling into related Pods when needed. + ## UI shape ```text @@ -24,26 +26,68 @@ The main list must not be a raw Pod list. It should sort by user decision priori 5. Active implementation/review work. 6. Informational Pod status and restorable historical sessions. -## Visual design and render boundary +## Visual design -The concrete look-and-feel should follow the existing TUI design language rather than inventing a second product surface. Reuse the current terminal UI conventions for borders, list selection, status/action bars, composer placement, key-hint style, transient notices, color/status semantics, and attach/return behavior where possible. +The concrete look-and-feel should follow the existing TUI design language rather than inventing a second product surface. Reuse current terminal UI conventions for borders, list selection, status/action bars, composer placement, key-hint style, transient notices, color/status semantics, and attach/return behavior where possible. The panel should feel like a more capable `--multi` workspace view, not a new unrelated dashboard. Any new visual treatment for Ticket/action rows or timeline lanes should be a small extension of existing list/detail components, so the single-Pod UI, current multi-Pod view, and workspace panel remain visually coherent. -Rendering must go through a UI-oriented intermediate representation. Runtime/domain state should be normalized into plain view data first, and widgets should render that data without directly querying Ticket backends, Pod sockets, session logs, or role-launch internals. +## State sources and socket boundary + +Unlike the normal single-Pod TUI, the panel should not treat a Pod socket transcript as its primary state. The default display can be built from local project records plus lightweight Pod state: + +- `.yoi/tickets/` is authoritative for Ticket records, status, thread events, plans, implementation reports, reviews, closures, and umbrella/child relationships. +- Pod metadata/session state is used to show related live/restorable role Pods. +- Visible Pod/client operations are used at action boundaries: restore/spawn Orchestrator, launch Intake, notify/send to a Pod, or attach to a selected Pod. + +So the panel itself is local-file-first and does not need to own a long-lived socket as its main state source. It still uses client/socket APIs for operations that actually target live Pods or attach to a transcript. + +## UI intermediate representation + +Use a thin UI-oriented intermediate representation. It is a render/action-dispatch contract, not a new Ticket backend, scheduler, or state machine. ```text WorkspacePanelViewModel - header: workspace label, companion state, orchestrator state, diagnostics -- action_rows: ordered user-action-required entries -- ticket_rows: Ticket-oriented progress entries -- pod_rows: secondary related Pod/session entries +- rows: ordered display rows for user actions, Tickets, and secondary Pod/session entries - detail: selected item detail blocks - timeline: optional dependency/phase lanes - composer: current target, placeholder, send eligibility, hints ``` -This view model is a render contract, not an authority layer. Ticket files, Pod metadata/session logs, and destination Pod histories remain authoritative; the view model is rebuilt from those sources and carries only display-ready fields plus stable IDs for follow-up actions. +Rows should carry only display-ready fields plus stable IDs for follow-up actions: + +```text +PanelRow +- key: stable selection/action key +- kind: intake | ticket | review | blocked | pod | diagnostic +- title / subtitle +- status marker and priority +- next user action, if any +- related Ticket id/slug, if any +- related Pod names, if any +- disabled reason / key hints +``` + +Ticket-specific rows can be backed by a compact entry: + +```text +TicketPanelEntry +- id / slug / title / status +- current phase: intake | preflight | implementing | reviewing | close_ready | blocked | closed +- next user action: clarify | go | review | close | wait | none +- parent/child relationship +- related role Pods and their live/restorable state +- latest plan / implementation report / review summary excerpts +- diagnostics and blocked reason +``` + +Keep this intentionally thin: + +- Do not duplicate the Ticket backend state machine in the UI. +- Do not load full Markdown thread bodies into the default view model. +- Do not let render functions perform Ticket/Pod I/O. +- Do not execute mutations from stale view-model data alone; action dispatch should re-check the relevant Ticket/Pod authority before mutating. ## Relationship to `--multi` and normal TUI @@ -73,24 +117,18 @@ Dynamic user text must be committed to the destination authority: - Ticket decisions/comments go to Ticket records and/or the Pod that receives the actual message. - Nothing should be injected only into hidden context. -## Ticket-centric detail model +## Action dispatcher boundary -Each visible Ticket row should be backed by a UI-ready data entry, not by direct render-time Pod inspection: +The view model tells the UI what can be displayed and which actions appear available. It should not be the mutation authority. When a user triggers an action, the dispatcher should use the selected stable key to re-read or re-check the relevant authority before acting: ```text -TicketPanelEntry -- stable selection/action key -- id / slug / title / status -- current phase: intake | preflight | implementing | reviewing | close_ready | blocked | closed -- next user action: clarify | go | review | close | wait | none -- parent/child relationship -- related role Pods and their live/restorable state -- latest plan / implementation report / review summary excerpts -- diagnostics and blocked reason -- display affordances: icon/status marker, priority, key hints, disabled reason +selection key + action intent +→ re-check Ticket / Pod authority +→ run Ticket tool, client method, restore/spawn, send, or attach +→ rebuild view model from local files and Pod state ``` -This model should be assembled from the Ticket backend, Ticket thread entries, known role launches, visible Pod metadata, and Orchestrator/Intake handoff records before rendering. Widgets should consume `TicketPanelEntry` / `WorkspacePanelViewModel` only, so later views can be added without coupling rendering to Pod internals. +This keeps the panel responsive while avoiding stale UI state becoming a hidden source of truth. ## Timeline / Gantt-like view @@ -99,12 +137,12 @@ A useful first version is a phase/dependency timeline rather than a date-based s ```text yoi-local-ticket-backend-migration ├─ ✓ yoi-ticket-cli-parity -├─ ▶ builtin-yoi-local-ticket-backend-config -├─ ○ migrate-ticket-storage-to-yoi-tickets -└─ ○ remove-tickets-sh +├─ ✓ builtin-yoi-local-ticket-backend-config +├─ ✓ migrate-ticket-storage-to-yoi-tickets +└─ ✓ remove-tickets-sh workspace-orchestration-panel -├─ ○ workspace-orchestration-panel-design +├─ ▶ workspace-orchestration-panel-design ├─ ○ workspace-panel-orchestrator-lifecycle ├─ ○ workspace-panel-composer-targets ├─ ○ ticket-intake-orchestrator-handoff @@ -115,9 +153,9 @@ Per-ticket phase lanes can show progress without pretending the system has relia ```text Ticket Intake Preflight Implement Review Close -backend cfg ✓ ✓ ▶ ○ ○ -storage move ✓ ○ ○ ○ ○ panel design ▶ ○ ○ ○ ○ +composer ○ ○ ○ ○ ○ +action model ○ ○ ○ ○ ○ ``` This captures what currently matters most: dependency order, gate state, responsible Pods, and human decision points. Duration/ETA scheduling can be added later if the backend starts recording enough authoritative timing data. @@ -132,12 +170,13 @@ Intake Pods receive the Orchestrator handoff/notification target at launch so th Implement in this order: -1. Define the UI intermediate representation (`WorkspacePanelViewModel`, `TicketPanelEntry`, `UserActionEntry`, composer target/view state, timeline lane rows) separately from runtime/domain state. -2. Add an adapter that builds the view model from Ticket backend records, role-launch state, visible Pod metadata, and diagnostics. +1. Define the thin UI intermediate representation (`WorkspacePanelViewModel`, `PanelRow`, `TicketPanelEntry`, composer target/view state, timeline lane rows). +2. Add a local-file-first adapter that builds the view model from `.yoi/tickets/`, role-launch state, visible Pod metadata, and diagnostics. 3. Render the workspace panel using existing TUI visual conventions/components as much as possible. 4. Make the existing multi-Pod panel path consume enough of that model to show action-prioritized Ticket rows. 5. Add composer target selection for Companion vs New Intake. -6. Add attach/drill-down and return behavior for related Pods. -7. Add the phase/dependency timeline view. +6. Add action dispatch with re-checks against Ticket/Pod authority before mutation. +7. Add attach/drill-down and return behavior for related Pods. +8. Add the phase/dependency timeline view. The existing `:ticket ...` commands remain as low-level fallback and debugging affordances, not the primary UX. diff --git a/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/item.md b/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/item.md index 92d05cf5..cfd0e541 100644 --- a/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/item.md +++ b/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/item.md @@ -7,7 +7,7 @@ kind: task priority: P1 labels: [tui, design, orchestration, panel] created_at: 2026-06-05T21:07:04Z -updated_at: 2026-06-05T21:32:54Z +updated_at: 2026-06-05T22:29:53Z assignee: null legacy_ticket: null --- @@ -52,7 +52,8 @@ Produce a design artifact that fixes: - 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 defines a thin UI intermediate representation between runtime/domain state and rendering, without turning it into a second Ticket backend or scheduler. +- The artifact states that the panel is local-file-first for display, using `.yoi/tickets/` as the Ticket authority and Pod/client sockets only for live operations such as spawn/restore/send/attach. - 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. diff --git a/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/thread.md b/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/thread.md index 1d65c034..e02ebdc8 100644 --- a/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/thread.md +++ b/.yoi/tickets/open/20260605-210704-workspace-orchestration-panel-design/thread.md @@ -36,4 +36,19 @@ Updated the workspace panel design draft per UI direction: The design ticket acceptance criteria now explicitly require both the UI intermediate representation and existing-TUI visual convention constraints. +--- + + + +## Decision + +Updated the workspace panel design to keep the UI intermediate representation intentionally thin. + +Direction recorded: +- the panel is local-file-first for display: `.yoi/tickets/` is the Ticket authority, with Pod metadata/session state only for related live/restorable status; +- sockets/client APIs are used at operation boundaries such as spawn/restore/send/attach, not as the panel's primary state source; +- the intermediate representation is a render/action-dispatch contract (`WorkspacePanelViewModel`, rows, compact Ticket entries), not a second Ticket backend, scheduler, or UI-owned state machine; +- the panel is not display-only: it is a Ticket-centric workspace cockpit for status, decision points, Intake/Orchestrator actions, and Pod drill-down. + + ---