ticket: move local storage to .yoi/tickets
This commit is contained in:
+118
@@ -0,0 +1,118 @@
|
||||
# Workspace orchestration panel UI design draft
|
||||
|
||||
## Position
|
||||
|
||||
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.
|
||||
|
||||
## UI shape
|
||||
|
||||
```text
|
||||
Workspace Orchestration Panel
|
||||
├─ header: workspace, orchestrator state, companion state
|
||||
├─ primary list: user-action-required Tickets / Intakes / Reviews
|
||||
├─ detail pane: selected Ticket plan, current phase, related Pods, latest reports
|
||||
├─ optional timeline/plan view: umbrella/child dependency lanes and phase progress
|
||||
└─ composer: explicit target selector
|
||||
```
|
||||
|
||||
The main list must not be a raw Pod list. It should sort by user decision priority:
|
||||
|
||||
1. Intake needs clarification or approval.
|
||||
2. Ticket is ready for human Go.
|
||||
3. Review or close decision is required.
|
||||
4. Ticket is blocked by an explicit human/project decision.
|
||||
5. Active implementation/review work.
|
||||
6. Informational Pod status and restorable historical sessions.
|
||||
|
||||
## Relationship to `--multi` and normal TUI
|
||||
|
||||
Reuse the useful `--multi` behaviors:
|
||||
|
||||
- discover visible live/restorable Pods;
|
||||
- show live/stopped/working state;
|
||||
- choose a send/attach target;
|
||||
- attach to a Pod/session and return to the workspace panel;
|
||||
- keep background Pods alive when the panel exits.
|
||||
|
||||
Do not embed the normal single-Pod UI as a permanent second pane. The panel should drill into a selected Pod/session only when the user explicitly attaches. This avoids maintaining two simultaneous chat surfaces and keeps normal Pod history ownership unchanged.
|
||||
|
||||
## Composer target model
|
||||
|
||||
The composer has an explicit target selector:
|
||||
|
||||
- `Companion`: management chat for this workspace panel session.
|
||||
- `New Intake`: send the composer body as the initial user input of a new Ticket Intake Pod.
|
||||
- `Selected Ticket`: record a comment/decision/Go/review-style action against the selected Ticket, usually via Ticket tools or an Orchestrator notification.
|
||||
- `Selected Pod`: advanced/direct send or attach path, not the main workflow.
|
||||
|
||||
Dynamic user text must be committed to the destination authority:
|
||||
|
||||
- Companion text goes to Companion history.
|
||||
- New Intake text goes to the Intake Pod initial user input/history.
|
||||
- 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
|
||||
|
||||
Each visible Ticket row should be backed by a plain data entry, not by direct render-time Pod inspection:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
## Timeline / Gantt-like view
|
||||
|
||||
A useful first version is a phase/dependency timeline rather than a date-based scheduler:
|
||||
|
||||
```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
|
||||
|
||||
workspace-orchestration-panel
|
||||
├─ ○ workspace-orchestration-panel-design
|
||||
├─ ○ workspace-panel-orchestrator-lifecycle
|
||||
├─ ○ workspace-panel-composer-targets
|
||||
├─ ○ ticket-intake-orchestrator-handoff
|
||||
└─ ○ workspace-panel-action-model
|
||||
```
|
||||
|
||||
Per-ticket phase lanes can show progress without pretending the system has reliable time estimates:
|
||||
|
||||
```text
|
||||
Ticket Intake Preflight Implement Review Close
|
||||
backend cfg ✓ ✓ ▶ ○ ○
|
||||
storage move ✓ ○ ○ ○ ○
|
||||
panel design ▶ ○ ○ ○ ○
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
## Orchestrator lifecycle
|
||||
|
||||
When the workspace panel opens, restore or spawn a workspace Orchestrator named from the workspace directory, e.g. `<dir-name>-orchestrator`. The panel should display its state but should not own its lifetime; closing the panel leaves the Orchestrator running.
|
||||
|
||||
Intake Pods receive the Orchestrator handoff/notification target at launch so they can report clarified Ticket readiness without automatically starting implementation. The Orchestrator may prepare routing/preflight, but human Go remains an explicit action.
|
||||
|
||||
## Initial implementation boundary
|
||||
|
||||
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.
|
||||
|
||||
The existing `:ticket ...` commands remain as low-level fallback and debugging affordances, not the primary UX.
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
id: 20260605-210704-workspace-orchestration-panel-design
|
||||
slug: workspace-orchestration-panel-design
|
||||
title: Workspace orchestration panel design
|
||||
status: open
|
||||
kind: task
|
||||
priority: P1
|
||||
labels: [tui, design, orchestration, panel]
|
||||
created_at: 2026-06-05T21:07:04Z
|
||||
updated_at: 2026-06-05T21:22:49Z
|
||||
assignee: null
|
||||
legacy_ticket: 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 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.
|
||||
@@ -0,0 +1,24 @@
|
||||
<!-- event: create author: yoi ticket at: 2026-06-05T21:07:04Z -->
|
||||
|
||||
## Created
|
||||
|
||||
Created by LocalTicketBackend create.
|
||||
|
||||
---
|
||||
|
||||
<!-- event: plan author: hare at: 2026-06-05T21:22:49Z -->
|
||||
|
||||
## Plan
|
||||
|
||||
Recorded an initial UI design draft from the panel discussion in `artifacts/workspace-panel-ui-design.md`.
|
||||
|
||||
Key direction:
|
||||
- make the workspace panel a successor to `--multi`, not a permanent split with the normal single-Pod UI;
|
||||
- use Ticket/action state as the default unit and attach to Pod/session details only on demand;
|
||||
- provide an explicit composer target selector for Companion / New Intake / Selected Ticket / advanced Selected Pod;
|
||||
- add a Gantt-like phase/dependency timeline based on Ticket gates and umbrella/child ordering rather than date estimates.
|
||||
|
||||
This is a design draft for review/iteration, not implementation approval for the child panel tickets yet.
|
||||
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user