ticket: simplify workspace panel view model
This commit is contained in:
parent
a8b012f9e7
commit
018d01e90e
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- event: decision author: hare at: 2026-06-05T22:29:53Z -->
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
---
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user