Zayin/Ekklesia
3
0
Fork 0
Code Issues 6 Pull Requests 2 Actions 1 Packages Projects Releases 9 Wiki Activity

Pair displays at the platform's own /display/setup, with or without modules
CI / verify (pull_request) Successful in 1m12s
Details
CI / infrastructure-smoke (pull_request) Successful in 45s
Details
CI / package-release (pull_request) Successful in 50s
Details
CI / migration-smoke (pull_request) Successful in 2m34s
Details
CI / image-build (pull_request) Successful in 1m8s
Details
CI / deploy-smoke (same-origin) (pull_request) Successful in 51s
Details
CI / package-publication (pull_request) Successful in 57s
Details
CI / deploy-smoke (split) (pull_request) Successful in 3m52s
Details

Browse Source 
Displays are platform-owned, but a screen could only start pairing on a
module's display page: every pairing request named a module, so an
installation with no module that uses displays could not set one up.

- /display/setup is the platform's own display page, served whenever
  the deployment has device support, whatever is installed. It pairs a
  platform display with no module. Once paired, it opens the module it
  is set to show; with none set, it shows its name and waits, rechecking
  so it stays alive and notices revocation. "setup" is now a reserved
  module id.
- Migration core:0009_platform_display_pairing lets a pairing request
  name no module. It relaxes module_id and permission_id and adds a
  both-or-neither check. It is additive and destroys nothing.
- POST /api/v1/device-pairing/requests accepts {} for a platform
  display. Approval accepts an optional moduleId, so the administrator
  can choose an installed display module and the device gets that
  module's declared permission. A module display's own request can't be
  redirected.
- GET /api/v1/device-pairing/self lets a paired device describe itself:
  its name and the module displays it may show. It renews the device's
  cookie.
- GET /api/v1/devices/setup is replaced by
  GET /api/v1/devices/display-modules: the modules a display can be set
  to show.
- Settings -> Displays always offers the /display/setup address, Copy
  setup link and Add display. Add display has an optional "Show on this
  screen" choice, and each paired display says what it shows.
- /display/<module-id> is unchanged, so released Signage 0.1.5 works as
  before.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
ekklesia
2026-10-16 16:43:02 -05:00
co-authored by Claude Opus 5.5
parent 906c015ca8
commit 300d9eab51
44 changed files with 3169 additions and 396 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CLAUDE.md
+3 -2
View File
@@ -54,8 +54,9 @@ Rules from those documents that every change here must respect:
(`@ekklesia/design-tokens`, ADR 0039) — never a hard-coded colour.
- **No browser-native dialogs.** `window.alert`, `window.confirm`, and `window.prompt` are prohibited
in product UI. Destructive actions use in-product confirmation proportional to their impact.
- **Displays are platform-owned.** Display pairing lives in **Settings → Displays** (ADR 0064); the
sidebar is navigation only. Signage's own display roster is still a transitional implementation
- **Displays are platform-owned.** A screen starts at the platform's own `/display/setup`, whatever
modules are installed, and is paired in **Settings → Displays** (ADR 0064, ADR 0065); the sidebar
is navigation only. Signage's own display roster is still a transitional implementation
that Stage 1 replaces with the platform's displays. Keep existing paired displays working across
any change, and do not build a module installer, theme editor, or display features beyond what a
task asks for early.