fix(ui): a session's port chip says when a port is waiting on you #117

Merged

lz merged 1 commit from fix/pending-ports-chip into main

2026-09-04 17:49:49 +02:00

lz commented

2026-09-04 17:45:58 +02:00

Owner

notify-preview lands a port as pending and forwards nothing until the operator approves it — but the sidebar chip counted pending and approved together and painted both in the same accent. A session with a dead port looked exactly like one whose ports work.

The chip now goes amber and says so: 2 ports · 1 pending. Same vocabulary as the Ports panel's own pending / approve, and the same signal the command palette's "Needs you" group already surfaced from pendingPreviews. The sidebar was the one surface of the three staying silent.

A second gap found while looking

The workspace shell row had no ports chip at all. /workspace's previews belong to the shell's session row (see previewsForWorker), so a port registered from the workspace shell — pending included — was invisible in the sidebar entirely. Both rows now render one shared snippet rather than two copies that could drift.

Notes

pendingPortCount is a loop rather than pendingPreviews().filter(...) for the same reason portCount beside it is one: it runs per row per render.

.chip.wrn is written for a label, so it carries neither the fill nor the pointer that make .chip.acc read as a control — this chip is a button in both states and needed both restored for the amber one.

Verification

Browser, against a seeded instance covering all three cases, measured off the live DOM:

row	chip	colour
workspace shell (1 pending)	`1 port · 1 pending`	`rgb(255,179,71)` amber
feat/mounts (2 approved)	`2 ports`	`rgb(205,220,57)` accent
fix/tabs (1 approved + 1 pending)	`2 ports · 1 pending`	amber

The per-session guard is negative-controlled: dropping the session test from the filter fails the new test with expected 1 to be +0. A guard that cannot fail is worse than none.

Gates: typecheck 0 errors, lint clean, 121 files / 1202 tests.

`notify-preview` lands a port as `pending` and **forwards nothing** until the operator approves it — but the sidebar chip counted pending and approved together and painted both in the same accent. A session with a dead port looked exactly like one whose ports work. The chip now goes amber and says so: `2 ports · 1 pending`. Same vocabulary as the Ports panel's own `pending` / `approve`, and the same signal the command palette's **"Needs you"** group already surfaced from `pendingPreviews`. The sidebar was the one surface of the three staying silent. ## A second gap found while looking **The workspace shell row had no ports chip at all.** `/workspace`'s previews belong to the shell's session row (see `previewsForWorker`), so a port registered from the workspace shell — pending included — was invisible in the sidebar entirely. Both rows now render one shared snippet rather than two copies that could drift. ## Notes `pendingPortCount` is a loop rather than `pendingPreviews().filter(...)` for the same reason `portCount` beside it is one: it runs per row per render. `.chip.wrn` is written for a *label*, so it carries neither the fill nor the pointer that make `.chip.acc` read as a control — this chip is a button in both states and needed both restored for the amber one. ## Verification Browser, against a seeded instance covering all three cases, measured off the live DOM: | row | chip | colour | |---|---|---| | workspace shell (1 pending) | `1 port · 1 pending` | `rgb(255,179,71)` amber | | feat/mounts (2 approved) | `2 ports` | `rgb(205,220,57)` accent | | fix/tabs (1 approved + 1 pending) | `2 ports · 1 pending` | amber | The per-session guard is **negative-controlled**: dropping the session test from the filter fails the new test with `expected 1 to be +0`. A guard that cannot fail is worse than none. Gates: typecheck 0 errors, lint clean, 121 files / 1202 tests.

lz added this to the Sidebar declutter, startup visibility & the target menu (#96) milestone

2026-09-04 17:45:58 +02:00

lz added 1 commit

2026-09-04 17:45:58 +02:00

fix(ui): a session's port chip says when a port is waiting on you

ci / nexus (pull_request) Has been cancelled

Details

ci / images (pull_request) Has been cancelled

Details

bad62c594a

`notify-preview` lands a port as `pending` and forwards NOTHING until the
operator approves it, but the sidebar chip counted pending and approved
together and painted both in the same accent. A session with a dead port looked
exactly like one whose ports work.

The chip now goes amber and says so — `2 ports · 1 pending` — using the same
vocabulary as the Ports panel's own `pending` / `approve`, and matching the
"Needs you" group the command palette already surfaces from `pendingPreviews`.
The sidebar was the one surface of the three that stayed silent.

Also gives the WORKSPACE SHELL row a ports chip, which it never had.
`/workspace`'s previews belong to the shell's session row (see
previewsForWorker), so a port registered from the workspace shell — pending
included — was invisible in the sidebar entirely. Both rows now render one
shared snippet rather than two copies that could drift.

`pendingPortCount` is a loop rather than `pendingPreviews().filter(...)` for the
same reason `portCount` beside it is one: it runs per row per render.

`.chip.wrn` is written for a label, so it carries neither the fill nor the
pointer that make `.chip.acc` read as a control — this chip is a button in both
states and needed both restored for the amber one.

Verified in a browser against a seeded instance covering all three cases,
measured off the live DOM: 2 approved → `2 ports` in accent; 1 approved + 1
pending → `2 ports · 1 pending` in amber; shell with 1 pending → `1 port · 1
pending` where there was previously no chip at all. The per-session guard is
negative-controlled — dropping the session test from the filter fails it.

lz force-pushed fix/pending-ports-chip from bad62c594a

ci / nexus (pull_request) Has been cancelled

Details

ci / images (pull_request) Has been cancelled

Details

to d74e0c99dc

ci / nexus (pull_request) Successful in 12m24s

Details

pr-image-cleanup / delete-pr-images (pull_request) Successful in 9s

Details

ci / images (pull_request) Successful in 14m53s

Details