From 92da1b4489fbd8f7cd386e3440fe8bef314509c0 Mon Sep 17 00:00:00 2001 From: Hare Date: Sat, 6 Jun 2026 06:32:54 +0900 Subject: [PATCH] ticket: refine workspace panel tui design --- .../artifacts/workspace-panel-ui-design.md | 39 +++++++++++++++---- .../item.md | 4 +- .../thread.md | 15 +++++++ 3 files changed, 50 insertions(+), 8 deletions(-) diff --git a/work-items/open/20260605-210704-workspace-orchestration-panel-design/artifacts/workspace-panel-ui-design.md b/work-items/open/20260605-210704-workspace-orchestration-panel-design/artifacts/workspace-panel-ui-design.md index 257ec7e9..05de7783 100644 --- a/work-items/open/20260605-210704-workspace-orchestration-panel-design/artifacts/workspace-panel-ui-design.md +++ b/work-items/open/20260605-210704-workspace-orchestration-panel-design/artifacts/workspace-panel-ui-design.md @@ -24,6 +24,27 @@ 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 + +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 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. + +```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 +- 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. + ## Relationship to `--multi` and normal TUI Reuse the useful `--multi` behaviors: @@ -54,10 +75,11 @@ Dynamic user text must be committed to the destination authority: ## Ticket-centric detail model -Each visible Ticket row should be backed by a plain data entry, not by direct render-time Pod inspection: +Each visible Ticket row should be backed by a UI-ready data entry, not by direct render-time Pod inspection: ```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 @@ -65,9 +87,10 @@ TicketPanelEntry - 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 ``` -This model should be assembled from the Ticket backend, Ticket thread entries, known role launches, visible Pod metadata, and Orchestrator/Intake handoff records. The UI should consume this plain model so later views can be added without coupling rendering to Pod internals. +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. ## Timeline / Gantt-like view @@ -109,10 +132,12 @@ Intake Pods receive the Orchestrator handoff/notification target at launch so th Implement in this order: -1. Build the plain `WorkspacePanelModel` / `TicketPanelEntry` / `UserActionEntry` model. -2. Make the existing multi-Pod panel consume enough of that model to show action-prioritized Ticket rows. -3. Add composer target selection for Companion vs New Intake. -4. Add attach/drill-down and return behavior for related Pods. -5. Add the phase/dependency timeline view. +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. +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. The existing `:ticket ...` commands remain as low-level fallback and debugging affordances, not the primary UX. diff --git a/work-items/open/20260605-210704-workspace-orchestration-panel-design/item.md b/work-items/open/20260605-210704-workspace-orchestration-panel-design/item.md index 6539a463..92d05cf5 100644 --- a/work-items/open/20260605-210704-workspace-orchestration-panel-design/item.md +++ b/work-items/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:22:49Z +updated_at: 2026-06-05T21:32:54Z assignee: null legacy_ticket: null --- @@ -52,5 +52,7 @@ 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 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/work-items/open/20260605-210704-workspace-orchestration-panel-design/thread.md b/work-items/open/20260605-210704-workspace-orchestration-panel-design/thread.md index bae1773f..1d65c034 100644 --- a/work-items/open/20260605-210704-workspace-orchestration-panel-design/thread.md +++ b/work-items/open/20260605-210704-workspace-orchestration-panel-design/thread.md @@ -21,4 +21,19 @@ Key direction: This is a design draft for review/iteration, not implementation approval for the child panel tickets yet. +--- + + + +## Decision + +Updated the workspace panel design draft per UI direction: + +- concrete look-and-feel should follow the existing TUI design language/components rather than introducing a separate dashboard style; +- the panel should remain a `--multi` successor with attach/drill-down, not a permanent split with the normal single-Pod UI; +- rendering should go through a UI intermediate representation (`WorkspacePanelViewModel`, `TicketPanelEntry`, action rows, composer view state, timeline lanes) built from Ticket/Pod/runtime sources before widgets render. + +The design ticket acceptance criteria now explicitly require both the UI intermediate representation and existing-TUI visual convention constraints. + + ---