yoi/.yoi/tickets/00001KSQPWH3G/thread.md

Created

Created by tickets.sh create.

---

Closed

---

id: 20260528-163238-multi-pod-view-section-layout slug: multi-pod-view-section-layout title: Polish multi-Pod view section layout status: closed kind: task priority: P2 labels: [tui, pod, ux] created_at: 2026-05-28T16:32:38Z updated_at: 2026-05-28T16:49:25Z assignee: null legacy_ticket: null

Background

20260527-000023-multi-pod-view-ui implemented the initial tui --multi dashboard. The current layout should be polished before building more interaction on top of it.

The desired list shape is sectioned by Pod state rather than a flat row list. The list area should visually emphasize live work first and keep closed/stopped history compact.

Target shape:

--pending---
a
b
--working---
c
d



--closed--
# only a few rows

The blank area between working and closed is intentional: the live sections should occupy the available vertical space, while the closed section stays compact at the bottom.

There is also a visual defect where the input-area separator and the list-area separator produce two adjacent separators. The multi-Pod view should have a single clean boundary between the Pod list/dashboard and the composer/input area.

Requirements

• Change tui --multi list layout to explicit sections:
  • pending: live Pods that are idle/waiting and ready for input.
  • working: live Pods that are running/processing, plus paused Pods if a separate paused section is not introduced.
  • closed: stopped/restorable history entries.
• Render section headers even when a section is empty only if that makes the view easier to understand; otherwise empty sections may be hidden. The choice should be consistent and tested/snapshotted where practical.
• Allocate vertical space so that:
  • live sections (pending + working) take the main flexible area.
  • closed is pinned near the bottom of the list/dashboard area.
  • closed shows only a small fixed number of rows initially, with 3 visible rows as the target.
  • excess height appears as blank space above the closed section rather than expanding closed history.
• Keep selection/navigation sane across sections.
  • Selection should move through visible rows in display order.
  • Direct send eligibility remains based on the selected PodListEntry action state.
  • Hidden closed rows must not accidentally become selected unless scrolling/paging for closed entries is explicitly implemented.
• Fix the double-separator defect between the Pod list/dashboard and the composer/input area.
  • There should be one visual boundary, not two adjacent horizontal rules/borders.
  • Do not introduce the same double-border issue between section headers and rows.
• Preserve existing tui --multi behavior outside layout.
  • tui --multi CLI entrypoint and conflicts remain unchanged.
  • Composer contents are preserved across selection changes.
  • Direct send to selected idle live Pod remains supported.
  • running/paused/stopped targets remain safely disabled unless separately implemented.

Acceptance criteria

• tui --multi renders Pod rows grouped into pending, working, and compact closed sections.
• The closed section is limited to about 3 visible rows and is visually anchored below the flexible live area.
• The blank/flexible space is placed above closed, not below it and not by expanding closed history.
• The boundary between list/dashboard and composer has a single separator/border.
• Selection and direct-send target mapping still use the underlying PodListEntry and remain correct after sectioning.
• Focused tests cover section classification, closed-row limiting, selection over visible section rows, and composer separator layout state where practical.
• cargo fmt --check
• cargo test -p tui multi --no-default-features or equivalent focused tests.
• cargo check -p tui -p client -p pod

Out of scope

• Reopening the completed multi-pod-view-ui ticket.
• Adding per-section scrolling unless needed for a minimal correct implementation.
• Changing PodList discovery/visibility semantics.
• Changing direct-send delivery semantics.
• Adding new CLI flags.

---