2 Commits

Include renames

Author	SHA1	Message	Date
ekklesiaandClaude Opus 5.5	300d9eab51	Pair displays at the platform's own /display/setup, with or without modules ... 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]>	2026-10-16 16:43:02 -05:00
ekklesiaandClaude Opus 5.5	cd0287537e	Add the account area and account-synced Appearance preferences ... Stage 1 PR 6 (ADR 0062). /account shows who is signed in; /account/appearance chooses System, Light, or Dark and reduced motion (System, Reduce, Allow). - Core: ekklesia_core_user_preference, one typed, CHECK-constrained, nullable column per preference (null = never chosen), migration 0008_user_preferences (additive), @ekklesia/core/account store, and the authenticated-baseline permission core.account.self.manage. - API: GET /api/v1/account (name, email, preferences) and partial PATCH /api/v1/account/preferences, self-only by construction: no user id is accepted anywhere; trusted Origin and body limit on the mutation. - Shell: the account control shows name, email, and initials (never the unvetted image URL) and offers Account, Appearance, Sign out; native radio groups apply a choice at once through the ADR 0060 controller and save it; the server's answer wins and a failed save reverts. - First paint: a classic, same-origin, render-blocking appearance.js in <head> applies a two-word localStorage cache before paint (no inline script, CSP unchanged). The account replaces the cache on every load, sign-out clears it, and other tabs follow via the storage event. - Deploy smoke: real-Chromium checks for light/dark, OS emulation, overrides, reload persistence, pre-paint, Shadow DOM modules, reduced motion, the display staying light, and phone width; the browser container gets a 512 MiB /dev/shm so a long session no longer fails requests with ERR_INSUFFICIENT_RESOURCES. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-14 23:56:50 -05:00