Say Remove for displays, and make the default accent purple (#210050)
CI / verify (pull_request) Successful in 1m14s
CI / infrastructure-smoke (pull_request) Successful in 42s
CI / package-release (pull_request) Successful in 49s
CI / migration-smoke (pull_request) Successful in 2m30s
CI / image-build (pull_request) Successful in 1m8s
CI / deploy-smoke (same-origin) (pull_request) Successful in 45s
CI / package-publication (pull_request) Successful in 56s
CI / deploy-smoke (split) (pull_request) Successful in 8m55s

Administrators now remove a display: the card's Remove, "Remove display?",
and "Display removed". The platform still revokes the device's credential;
the endpoint, fields, and security history keep revoke/revoked (ADR 0065).

The default accent is a deep purple anchored on #210050, set in the shared
design tokens only (ADR 0066, superseding ADR 0060's teal in part). The
anchor is the light primary action with white on it; the light accent text,
focus ring, and selection, and the dark theme's lavender accent, are
variants on its hue chosen for contrast. The teal-tinted neutrals move to a
faint violet-grey at the same lightness, so every contrast pairing holds.
The contrast test gains six pairings the accent depends on, and pins the
anchor.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
ekklesia
2026-10-16 19:14:46 -05:00
co-authored by Claude Opus 5.5
parent d9dafcb0f7
commit 0009f62fbd
10 changed files with 261 additions and 97 deletions
@@ -147,11 +147,17 @@ and a `role="listbox"` of options).
### The normal list shows active displays, current as they change
The Paired displays list shows **active** displays only. A revoked display leaves it at once — the
page asks for the list again right after revoking — and the page says so, with focus on that notice
because the display's own card is gone. The revoked device row and its permission rows stay in the
The Paired displays list shows **active** displays only. A removed display leaves it at once — the
page asks for the list again right after removing it — and the page says so, with focus on that
notice because the display's own card is gone. The device row and its permission rows stay in the
database, marked revoked, as security history; a history view can show them later.
**Administrators remove a display; the platform revokes its credential.** The interface says
*Remove*, *Remove display?*, and *Display removed*, and never shows "revoked". The domain does not
change for presentation: the device and its permissions are revoked, the endpoint is still
`POST /api/v1/devices/:id/revoke`, the fields are still `revoked`/`revokedAt`, and security and audit
history still describe a credential revocation.
A newly paired display appears without a reload. Approval does not create the display: the screen
does, when it collects its credential on its next poll, a few seconds later (ADR 0036). So after
approving, the page shows a "Waiting for the screen to connect…" placeholder and asks for the list
@@ -166,7 +172,7 @@ Each active display shows:
purpose: last-seen is recorded at most every 15 minutes;
- **Showing:** a module, or *Nothing yet*;
- last seen and paired dates;
- **Change** and **Revoke**.
- **Change** and **Remove**.
### Changing what a display shows: one target, the active display permission