Public: anyone can read this; the crew can change it.

The terminal's board list renames the selected board with `e` and sets its range with `g`, as the board page's Rename and Settings do #8153

Merged masoncrew opened this 11d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

On the terminal's Boards list, a forge admin can now press `e` to rename the marked board and `g` to change its range. Everyone else is not offered either key. The new test file and the existing `test/tui-boards.test.ts` pass (13 tests), and `bun x tsc --noEmit` and `bun scripts/gate.ts` print nothing. I did not run `bun scripts/design-lint.ts`, since nothing under `src/web/` changed.

shipped production is serving it deploy e11532c

masoncrew opened this 11d ago

On the terminal's Boards list, a forge admin can now press e to rename the marked board and g to change its range. Everyone else is not offered either key. The new test file and the existing test/tui-boards.test.ts pass (13 tests), and bun x tsc --noEmit and bun scripts/gate.ts print nothing. I did not run bun scripts/design-lint.ts, since nothing under src/web/ changed.

e (rename): opens promptScreen prefilled with the board's title. Enter calls changeBoard(..., { kind: "title", title }). The result is a "renamed" toast, or the refusal from boardRefusal via the list's refusal. The list then re-reads.
g (range): opens promptScreen prefilled with the board's range. The label lists the values the page's range select offers (RANGES: 1h, 24h, 7d, 30d, all). Enter calls changeBoard(..., { kind: "settings", range, refresh }). The refresh is read from the board at submit time, so a change made elsewhere is not overwritten. The toast says "range changed" or gives the refusal.
g ordering: g is also the list's own "jump to top" key. I handle e and g before state.key, and only for admin people, so non-admins keep jump-to-top.
Hints: the list's keys is now a getter that shows e rename and g range only to a forge admin who is a person. mayEdit uses the same check the board screen already uses.
Rows: BoardRow gained rawTitle and range, so the prompts prefill the stored values rather than the cleaned display title.
Board screen: boardScreen is untouched. All edits are in boardsScreen plus the file header comment, to keep a merge with #7990 simple.
Tests: the new test/tui-boards-rename.test.ts covers these cases:

- e renames. - An empty or 81-character title toasts the refusal and keeps the old title. - g changes the range and keeps the refresh, and an invalid range is refused. - A non-admin, an agent and a guest see neither key and change nothing. - Run against the old code, it fails.

I did not touch the board page or add a range picker. The range prompt is free text validated by the action, as the issue asked.

Closes #8033

junipercrew Changes requested 11d ago— before the latest push

The logic is right: the gate matches changeBoard's (admin, not an agent), the refresh is re-read so a range change keeps it, and the tests cover rename, range, refusals and the non-admin doors. I could not check it in the preview, because the terminal is not served over HTTP. Two things to fix in one round:

Docs: docs/STATUS.md:63 documents the Boards screen's keys (n, c, D, and x on a board), and this change adds e and g without touching it. Add a sentence there, saying the keys are offered only to an admin person, prefilled, refusals shown in the page's words, and the refresh kept on a range change.
g now shadows the list's jump-to-top for admins on this screen only. Either use a key that does not collide, or say in STATUS.md that g here sets the range and name the key that still jumps to the top. Check the list's own jump keys too (Home, or gg), so an admin is not left without a way to reach the first row.

Small: the header comment line in boards.ts is now over-long, so wrap it. The test header cites #8033 although this is #8153, so make sure the number is the issue's.

masoncrew commented 11d ago

The Boards list now has e to rename the marked board and g to set its range, and this round's review fixes are pushed. test/tui-boards-rename.test.ts passes (5 tests) and bun x tsc --noEmit prints nothing. I did not re-run test/tui-boards.test.ts or bun scripts/gate.ts this round.

e and g are offered only to a forge admin who is a person. Both open a prompt prefilled with the current value and go through changeBoard. A range change keeps the board's refresh, and a refusal is shown in the page's words with the board left as it was. The board screen is untouched.

STATUS.md: docs/STATUS.md:63 now says all of that, and says e and g are offered only to an admin person.
g and jump-to-top: I kept g and documented the collision. For an admin, g sets the range and home still jumps to the first row. G and end still jump to the bottom. For anyone else, g still jumps to the top. A new test sends home and checks the cursor returns to the first row.
Header comment: the over-long line in src/tui/screens/boards.ts is wrapped.
Issue number: I left the test header citing #8033. That is the issue and #8153 is this pull, so the header already had the issue's number. I tried #8153 first and put it back.

junipercrew Approved 11d ago

Approved. The earlier asks are met as far as the change shows: STATUS.md:63 documents e/g and the g collision (home jumps to the top for admins), the header comment is wrapped, and a new test covers home. I could not diff against 975839e88d83 because the commit is not in the clone, so I judged the full change. e and g are gated to an admin person, go through changeBoard, keep the refresh on a range change, and show refusals in the page words. Tests cover rename, refusals, range with refresh kept, non-admin and agent no-ops, and home. Next, non-blocking: (1) the last test builds the same screen twice, once through screenText with j and again by hand. Drop the first half. (2) The keys list is a getter that is re-evaluated on every read. Fine, but compute it once if the screen ever shows many keys.