UI shell: two-column navigation, repo list, boxes [1]-[3], details #8

New issue

deadstyle · 2026-10-01T21:55:16-05:00

deadstyle commented

2026-10-01 21:55:16 -05:00

Problem

The core interaction model needs to exist as a working program: two columns, the repo list on the left, numbered boxes previewed on the right, l/1–5 to move into the boxes, details on the right, l to focus the details pane, h to go back, with a breadcrumb, status-bar hints and help. This is the foundation every other UI ticket builds on, and it sets the UI code patterns.

Goal

One thin, complete path before breadth (plan-review build order, #17): connect → list repos → open a PR → confirm merge → see the result. The read-only shell below is the first half of that path; #9's merge completes it. Build the minimum of each step end to end before widening any of them.

Plan

internal/ui:

Root model routing between levels: host picker, repos, boxes, details.
The repo list (★ Renovate entry pinned, stubbed until the ★ Renovate ticket), sorted by activity.
Boxes [1] Pull requests, [2] Issues, [3] Actions (shown only when the adapter supports runs), with the focused box growing as in the mockup.
The details pane with the Overview tab for each item kind; [/] tab switching wired up.
A single keymap (bubbles/key) that drives both the help overlay (?) and the status-bar hints. A breadcrumb header.
Styles in internal/ui/style. Layout derived from tea.WindowSizeMsg; must work at 80×24.
Read-only: no actions in this ticket.
Demo mode (lazyforge --demo): the full UI running on built-in fake data (the forgetest fake, seeded to look like the mockup). It lets UI work start before the gitea adapter exists, lets actions be tried without touching real repos, and gives agents a deterministic way to verify UI changes: drive the app in tmux (send-keys / capture-pane) and capture screenshots with VHS for the MR body. Demo data lives in forgetest; cmd/lazyforge wires it up behind the flag.

Tests: Update driven by messages against the forgetest fake. Whether to adopt a golden-file View testing library is decided by Opus here.

Context

docs/design.md → Navigation model, Boxes, Keymap. docs/mockup.html is the visual reference.
go-development → Bubble Tea rules.
Open product questions affect details here (j at a box edge, whether the focused box grows). Build to the mockup's behavior unless the PM decides otherwise first.
Depends on the core cache/refresh ticket.
Onboarding and Settings screens are in #5; this ticket builds the browsing UI they hand off to.

PM decisions (2026-10-02, #13)

j stops at the bottom of a box. The focused box grows.
Background refresh every five minutes, plus r. The timer lives in the UI and re-issues core fetches (ADR 0007).

## Problem The core interaction model needs to exist as a working program: two columns, the repo list on the left, numbered boxes previewed on the right, `l`/`1`–`5` to move into the boxes, details on the right, `l` to focus the details pane, `h` to go back, with a breadcrumb, status-bar hints and help. This is the foundation every other UI ticket builds on, and it sets the UI code patterns. ## Goal One thin, complete path before breadth (plan-review build order, #17): connect → list repos → open a PR → confirm merge → see the result. The read-only shell below is the first half of that path; #9's merge completes it. Build the minimum of each step end to end before widening any of them. ## Plan `internal/ui`: 1. Root model routing between levels: host picker, repos, boxes, details. 2. The repo list (★ Renovate entry pinned, stubbed until the ★ Renovate ticket), sorted by activity. 3. Boxes `[1]` Pull requests, `[2]` Issues, `[3]` Actions (shown only when the adapter supports runs), with the focused box growing as in the mockup. 4. The details pane with the Overview tab for each item kind; `[`/`]` tab switching wired up. 5. A single keymap (`bubbles/key`) that drives both the help overlay (`?`) and the status-bar hints. A breadcrumb header. 6. Styles in `internal/ui/style`. Layout derived from `tea.WindowSizeMsg`; must work at 80×24. 7. Read-only: no actions in this ticket. 8. **Demo mode** (`lazyforge --demo`): the full UI running on built-in fake data (the `forgetest` fake, seeded to look like the mockup). It lets UI work start before the gitea adapter exists, lets actions be tried without touching real repos, and gives agents a deterministic way to verify UI changes: drive the app in tmux (`send-keys` / `capture-pane`) and capture screenshots with VHS for the MR body. Demo data lives in `forgetest`; `cmd/lazyforge` wires it up behind the flag. Tests: `Update` driven by messages against the `forgetest` fake. Whether to adopt a golden-file `View` testing library is decided by Opus here. ## Context - `docs/design.md` → Navigation model, Boxes, Keymap. `docs/mockup.html` is the visual reference. - `go-development` → Bubble Tea rules. - Open product questions affect details here (`j` at a box edge, whether the focused box grows). Build to the mockup's behavior unless the PM decides otherwise first. - Depends on the core cache/refresh ticket. - Onboarding and Settings screens are in #5; this ticket builds the browsing UI they hand off to. ## PM decisions (2026-10-02, #13) - `j` stops at the bottom of a box. The focused box grows. - Background refresh every five minutes, plus `r`. The timer lives in the UI and re-issues core fetches (ADR 0007).

deadstyle added the

feature

opus

labels

2026-10-01 21:55:25 -05:00

deadstyle commented

2026-10-01 22:08:47 -05:00

Added to scope (Opus): a demo mode, lazyforge --demo. It runs the full UI on built-in fake data (the forgetest fake, seeded to look like the mockup), so that:

UI work can start before the gitea adapter exists;
m, x and other actions can be tried without touching real repos;
agents can verify UI changes deterministically by driving the app in tmux (send-keys / capture-pane) and capturing screenshots with VHS. Screenshots or GIFs of UI changes go in the MR body.

Demo data lives with the fake in forgetest, not in production packages; cmd/lazyforge wires it up behind the flag.

Added to scope (Opus): a **demo mode**, `lazyforge --demo`. It runs the full UI on built-in fake data (the `forgetest` fake, seeded to look like the mockup), so that: - UI work can start before the gitea adapter exists; - `m`, `x` and other actions can be tried without touching real repos; - agents can verify UI changes deterministically by driving the app in tmux (`send-keys` / `capture-pane`) and capturing screenshots with VHS. Screenshots or GIFs of UI changes go in the MR body. Demo data lives with the fake in `forgetest`, not in production packages; `cmd/lazyforge` wires it up behind the flag.

deadstyle referenced this issue

2026-10-01 22:09:10 -05:00

docs: onboarding, Settings screen, TOML config (ADR 0004) #15

deadstyle referenced this issue

2026-10-01 22:22:37 -05:00

Fold plan-review findings into tickets and docs #17

deadstyle referenced this issue

2026-10-02 10:29:48 -05:00

Fold plan-review findings into tickets and docs #17

deadstyle referenced this issue

2026-10-02 11:44:22 -05:00

Product decisions needed for v1 #13

deadstyle referenced this issue

2026-10-02 11:46:15 -05:00

docs: plan review, fold-in of its findings, and v1 product decisions #18

deadstyle referenced this issue

2026-10-02 12:01:03 -05:00

Onboarding, Settings screen and host picker #24

deadstyle referenced this issue

2026-10-02 12:01:19 -05:00

Config: TOML config and state, token resolution, host selection #5

deadstyle referenced this issue

2026-10-02 12:35:41 -05:00

Core: cache, background refresh and stale-result protection #7

deadstyle commented

2026-10-02 12:45:30 -05:00

🤖 Plan approved (engineering lead). Three parts: (1) the UI itself (repo list with ★ Renovate pinned, boxes [1] Pull requests, [2] Issues, [3] Actions when the forge has them, the details pane with Overview, one keymap driving help and the status-bar hints, layout down to 80×24); (2) demo data for lazyforge --demo; (3) startup wiring and docs. Read-only: actions come in #9. Box titles and tabs follow design.md: only working tabs are shown, so Overview for now. q and ctrl+c quit, as in the mockup. Branch: feature/8-ui-shell.

🤖 Plan approved (engineering lead). Three parts: (1) the UI itself (repo list with ★ Renovate pinned, boxes [1] Pull requests, [2] Issues, [3] Actions when the forge has them, the details pane with Overview, one keymap driving help and the status-bar hints, layout down to 80×24); (2) demo data for `lazyforge --demo`; (3) startup wiring and docs. Read-only: actions come in #9. Box titles and tabs follow design.md: only working tabs are shown, so Overview for now. `q` and `ctrl+c` quit, as in the mockup. Branch: feature/8-ui-shell.

deadstyle referenced this issue from a pull request that will close it,

2026-10-02 13:27:14 -05:00

feat(ui): UI shell with repo list, boxes [1]-[3], details and demo mode #30