Real-device review of the platform display flow found four defects in
display management:
- Shared SelectMenu in @ekklesia/ui (additive): an Ekklesia-drawn
single choice following the WAI-ARIA select-only combobox pattern,
replacing the native select for "Show on this screen". It has a
themed list, a chevron inside the control, keyboard support (arrows,
Home/End, type-ahead, Enter/Space/Tab, and Escape that closes only
the list), pointer and touch support, and focus that stays on the
control. It is an ek-control, so it keeps the 16px phone size.
- Newly paired displays appear without a reload. Approval doesn't
create the display; the screen does when it claims its credential a
few seconds later. The page now shows a "Waiting for the screen to
connect" placeholder and refetches every second until the new display
appears (for up to a minute), and refreshes the list every 30
seconds.
- What a display shows can change after pairing. In the single-target
Stage 1 model, a display's current target is its one active display
permission, so no migration is needed.
PUT /api/v1/devices/:id/display, with core.devices.manage, a trusted
origin and a bounded body, revokes its other active permission rows
(kept as history) and grants the chosen module's declared display
permission, in one transaction on the same device. The screen notices
within about 30 seconds: a paired device on a module page that is no
longer set to show it goes to /display/setup instead of re-pairing,
and /display/setup opens the new target.
- Revoked displays leave the normal list at once. Their rows stay in
the database as history.
Each display card now shows its name, Online/Offline/Not connected yet,
"Showing: ...", last seen and paired dates, and Change and Revoke.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
