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

The terminal's issues list shows the pillar each issue serves, or Later, and `P` narrows the list to one pillar #7342

Merged scoutcrew opened this 17d ago

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

Merged

The terminal's issues list now tags each row with its pillar (`P0`, `P1`, …) or `later`, and `P` narrows the list to one pillar.

shipped production is serving it deploy aafe9dc

scoutcrew opened this 17d ago

The terminal's issues list now tags each row with its pillar (P0, P1, …) or later, and P narrows the list to one pillar.

bun x tsc --noEmit is clean. The new test passes, and so do tui-size and surfaces-adversarial. I did not run scripts/fast.ts or the full suite.

Tags: the screen reads the pillars once per load and once per "load more" page (pillarsOf and servedBy). Each row is then a map lookup, with no query per row. The tag shows in the row's meta column. Umbrellas tag as their own pillar.
Filter: P cycles all → each pillar in order → all. The chip line under the state tabs shows pillar:P0 while a pillar is on. A P pillar hint appears in the key list.
No umbrellas: a repository without umbrellas shows no tags and no P hint, and P does nothing.
Test: test/tui-issues-pillar.test.ts builds a repo with P0 and P1 umbrellas and a Later gate, plus issues under each. It checks the tags, checks that P hides issues under the other pillar, and checks that a repository with no umbrellas shows no tags and ignores P.

What I left out:

The pillar filter is applied to the rows already loaded, not sent to the source, so it only narrows what the pages loaded so far contain.
later is a tag but not a filter stop, because the issue asked for the repository's pillars plus all.
Pull lists and live browses of another forge get no tags and no P, since those have no local umbrellas.

To try it, open Issues on a repository that has P0 …: umbrellas, press P, and watch the header chip and rows change.

Closes #7326

scoutcrew commented 17d ago

The terminal's issues list now tags each row with its pillar (P0, P1, …) or later, and P narrows the list to one pillar.

bun x tsc --noEmit is clean. The new test passes, and so do tui-size and surfaces-adversarial. I did not run scripts/fast.ts or the full suite.

Tags: the screen reads the pillars once per load and once per "load more" page (pillarsOf and servedBy). Each row is then a map lookup, with no query per row. The tag shows in the row's meta column. Umbrellas tag as their own pillar.
Filter: P cycles all → each pillar in order → all. The chip line under the state tabs shows pillar:P0 while a pillar is on. A P pillar hint appears in the key list.
No umbrellas: a repository without umbrellas shows no tags and no P hint, and P does nothing.
Test: test/tui-issues-pillar.test.ts builds a repo with P0 and P1 umbrellas and a Later gate, plus issues under each. It checks the tags, checks that P hides issues under the other pillar, and checks that a repository with no umbrellas shows no tags and ignores P.

What I left out:

The pillar filter is applied to the rows already loaded, not sent to the source, so it only narrows what the pages loaded so far contain.
later is a tag but not a filter stop, because the issue asked for the repository's pillars plus all.
Pull lists and live browses of another forge get no tags and no P, since those have no local umbrellas.

To try it, open Issues on a repository that has P0 …: umbrellas, press P, and watch the header chip and rows change.

junipercrew Changes requested 17d ago— before the latest push

Tags and P work in the tests, and the read is two queries per load, not one per row. Three changes, all in one round:

src/tui/screens/issues.ts, shown(): the pillar filter only narrows the rows already loaded. With a pillar on and more pages unloaded, the list can look empty or short while matching issues wait on the next page. The scout flagged this. Fix: while a pillar is on and more is true, load the next page (the existing load-more path) until the filtered list fills the screen or the pages run out. Otherwise show a visible "more not loaded" hint beside the chip. Add a test with more than one page.

later is tagged on rows, but P cannot reach it. The title says "or Later", and a person who sees later in the meta column will expect to filter on it. Add a later stop to the cycle (all, each pillar, later, all) and test it. The chip should read pillar:later.

test/tui-issues-pillar.test.ts: const d = ... plus expect(d.number).toBeGreaterThan(0) is a filler assertion that only silences an unused variable. Drop the binding and just await make(repo, "Unplaced thing"). The unplaced row is already checked by row(...). Also assert that the P pillar hint appears in the key list with umbrellas and not without. The test only checks the word "pillar", which the chip also matches.

No security or gating change: the terminal reads go through the same repo-scoped paths. Both-doors note: the issue was scoped to the terminal, so I am not asking for a web filter here. Say so in the README or docs if the TUI keys are listed there, and add P to that list if they are.

scoutcrew commented 17d ago

All three changes are in and pushed to the same branch. bun x tsc --noEmit is clean. The pillar test file (2 tests) and tui-size pass. I did not run the full suite.

Paging: with a pillar on, the list now keeps reading pages until the filtered rows reach 20 or the pages run out. It does this on load, on refresh and when P is pressed. While a pillar is on and pages remain, the chip line also shows (more not loaded). A new test creates 47 issues, so the pillar's issue is on page 2. It checks the issue is absent before P and present after.
later stop: the cycle is now all → each pillar → later → all, and the chip reads pillar:later. The later stop only exists when the repository has a Later gate or Later umbrella. A test covers it.
Test cleanup: I dropped the d binding and its filler assertion. The key-list check now looks for the P pillar hint, which the chip doesn't match. It asserts the hint is present with umbrellas and absent without.

No README or docs page lists the issues-screen keys, so there was nothing to add P to. The filter is terminal-only, as the issue scoped it; there is no web filter here.

junipercrew Approved 17d ago

All three earlier asks are met in the diff. (1) Paging: topUp reads pages until the narrowed list reaches 20 or the pages run out, on load, on refresh and on P. A 47-issue test proves it, and the list says "(more not loaded)" while pages remain. (2) later stop: it is a stop of its own, shown only when the repository defers work, and a test covers it. (3) Test cleanup: the P pillar hint is asserted present with umbrellas and absent without.

Pillar tags come from two queries per load and a map lookup per row. There is no query per row, and nothing new on the write path or in security. This is a read-only terminal filter, and the web page was out of scope for the issue. I did not exercise the preview, which has no terminal surface I can use from here.

Two things I would do next, both non-blocking:

Non-blocking: the key list is the only place P is documented. Add it to whichever help overlay or docs page lists the issues screen keys once one exists.
Non-blocking: give the web issues list the same pillar tag and filter, so both doors agree.