282 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Joey	186668915b	Merge pull request 'Stage 1: module navigation contract — manifest v9, module routes, return-to-origin' (#110) from feat/module-navigation-contract into main ... Reviewed-on: #110 Reviewed-by: Joey <[email protected]>	2026-10-15 14:32:49 +00:00
ekklesiaandClaude Opus 5.5	c78f1318b4	Make the module navigation capability an optional context member ... ModuleUiHostContext.navigation is now `navigation?: ModuleUiNavigation | undefined`, so the public context change is source-compatible: a context built before navigation existed (without the member) still compiles unchanged, as 0.x patch releases require. The Dashboard supplies navigation; hosts without addressable pages, including the display host, omit the member; modules feature-detect it. Existing hosts' tests are restored to their pre-PR shape, and a module-ui-sdk test proves a pre-navigation context still satisfies ModuleUiHostContext (and fails if the member is ever made required). Runtime behaviour, manifest v8/v9 compatibility, and security rules are unchanged. ADR 0063 and the module development guide say so. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-15 09:13:03 -05:00
ekklesiaandClaude Opus 5.5	ae360ef318	Keep module pages indented beneath their module in the sidebar ... Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-15 08:23:53 -05:00
ekklesiaandClaude Opus 5.5	4671622b9d	Add the module navigation contract: manifest v9, module routes, return-to-origin ... Stage 1 PR 7 (ADR 0063). A module becomes a first-class part of the Dashboard. - Manifest v9 = v8 plus optional `navigation`: a Lucide icon from the curated MODULE_NAVIGATION_ICONS set, and up to 12 primary pages (stable id, safe label, kebab-case path relative to the module root; no traversal, schemes, queries, duplicates, or nesting). Validated before activation. - Version 8 stays accepted beside version 9, each read strictly as itself (discriminated union); no released manifest is rewritten. The template moves to v9; the released Signage 0.1.5 manifest is a test fixture. - Real module routes: /<id> is the landing view, /<id>/<page> a declared page, anything beneath a page a module-owned detail route; anything else is not-found and mounts nothing. api/assets/display are never pages. - Sidebar: declared icons, pages nested under an open module, one aria-current, collapsed and drawer behaviour; v8 modules unchanged. - module-ui-sdk: ModuleUiHostContext.navigation (location, subscribe, navigate, link, settings), refusing anything outside the module's routes; undefined on the display host. Mount ABI unchanged. - Return-to-origin: one `?return=` carrier on Settings URLs, validated by parseReturnTarget and against running modules' declared routes; Settings Back returns to exactly the originating module page, across refreshes. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-15 08:21:50 -05:00
Joey	7447381c8f	Merge pull request 'Stage 1: account area and account-synced Appearance preferences' (#109) from feat/account-appearance into main ... Reviewed-on: #109 Reviewed-by: Joey <[email protected]>	2026-10-15 11:50:48 +00: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
Zayin_Admin	8571e6854c	Merge pull request 'feat(shell): Settings hierarchy, Discover, and /settings/<module-id> (Stage 1, ADR 0061)' (#108) from feat/settings-shell into main ... Reviewed-on: #108 Reviewed-by: Zayin_Admin <[email protected]>	2026-10-15 03:43:00 +00:00
ekklesiaandClaude Opus 5.5	89ef4b5ff6	feat(shell): Settings hierarchy, Discover, and /settings/<module-id> ... The Settings foundation (ADR 0061): - URL model. /settings is a real landing page. The platform sections are /settings/general, /branding, /displays, and /system. Module lifecycle is Discover: /settings/discover/browse, /installed, and /updates. /settings/discover is respelled in place to Browse's one canonical address. A module's settings are /settings/<module-id>, never nested under Discover. Deeper Settings addresses are reserved. "Modules" stays the user-facing word: "Discover modules", "Installed modules", "Module updates". - Collisions. Core's one reserved list gains the Settings section names (branding, discover, displays, general, system) as a second documented group, so no module id can shadow a section; `modules` is an ordinary id. apps/api tests hold it equal to the shell's sections. - Navigation. One Settings item in the same sidebar expands in place into Platform and Modules (and Discover's three views) while in Settings, and the phone drawer has the same hierarchy. The rest of the navigation stays. - Permissions. GET /api/v1/dashboard/settings evaluates, through Core's evaluator, which destinations the viewer may see: - Displays: core.devices.manage - Discover: core.modules.lifecycle.manage - a module's settings: core.modules.configuration.manage, for each module that declares configuration (ADR 0029) - General, Branding, System: the platform owner, until each has its own permission These are presentation hints; every data route keeps its own enforcement. With nothing visible, there is no Settings link. - Pages are honest placeholders with Back to Settings. A disabled module's settings say it is turned off; a section or module the person cannot see says so without detail; an unknown name is not found; a failed load withholds the link and offers Retry. - The deploy smoke opens Settings by deep link, refreshes a section, enters Discover, opens the module's settings, uses the phone drawer, and returns to the Dashboard. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-14 22:22:50 -05:00
Zayin_Admin	34692ac05f	Merge pull request 'feat(theme): Light/Dark/System, reduced motion, and one radius scale (Stage 1, ADR 0060)' (#107) from feat/theme-foundation into main ... Reviewed-on: #107 Reviewed-by: Zayin_Admin <[email protected]>	2026-10-15 01:22:01 +00:00
ekklesiaandClaude Opus 5.5	d42b64a093	feat(theme): Light/Dark/System, reduced motion, and one radius scale ... The theme foundation DESIGN.md requires (ADR 0060): - A design token may carry a `dark` value and a `reduced` value. The token stylesheet selects them in CSS alone: dark under prefers-color-scheme unless the host chose light, or when it chose dark; motion durations zero under prefers-reduced-motion unless it allowed motion, or when it chose reduce. `color-scheme` travels with the tokens. System is live, an explicit choice wins, and every module root follows through custom-property inheritance, with no module contract change. - @ekklesia/design-tokens adds a small appearance API: system/light/dark and system/reduce/allow, parsers for untrusted stored values, resolvers, and a controller that applies the attributes immediately. The shell applies it before React renders. That is the hook the account preferences work will feed; nothing is persisted. The Dashboard page declares `color-scheme: light dark` so a dark system never flashes white. Displays stay light. - A designed dark theme: teal-tinted charcoal, never pure black or white, the same teal accent. - WCAG AA contrast is tested for 41 element pairings in both schemes. Two light pairings failed and are fixed visibly: text.muted darkens, and form controls get a new border.control (3:1). background.placeholder keeps skeletons visible in dark. - Motion tokens (duration-short, duration-ambient) replace literal durations and every per-element reduced-motion rule. radius.scale multiplies sm/md/lg, unchanged at its default of 1. - The sign-in card and module loading/error text move from literal colours to tokens. Guards keep raw colours and literal radii out of Dashboard product source and @ekklesia/ui. - Fixes ConfirmationDialog's phrase input, which used a class that does not exist (`ek-input`) and so was unstyled. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-14 20:00:39 -05:00
Zayin_Admin	e3e2a901a7	Merge pull request 'feat(ui): shared confirmation, toasts, error, skeleton, and Back primitives (Stage 1, ADR 0059)' (#106) from feat/ui-state-primitives into main ... Reviewed-on: #106 Reviewed-by: Zayin_Admin <[email protected]>	2026-10-15 00:43:53 +00:00
ekklesiaandClaude Opus 5.5	5a7d44781b	feat(ui): shared confirmation, toasts, error, skeleton, and Back primitives ... Stage 1's later screens and modules need the interactions DESIGN.md fixes once for the product (ADR 0059). @ekklesia/ui gains them, additively: - ConfirmationDialog: simple, destructive, or typed-phrase confirmation, with severity chosen by the caller. Destructive is marked by symbol and frame, not colour alone, and starts on Cancel. A required phrase must match exactly (forgiving only surrounding whitespace and NFC). While busy, Cancel and Escape are disabled. - ToastProvider / useToasts: a top-center toast system per React tree, never a package singleton (ADR 0040). Live regions are mounted before any toast arrives; errors are assertive and persist until dismissed; routine toasts last at least three seconds and longer for longer text. Timers pause on hover and focus; duplicates refresh; errors are never displaced; every timer is cleared on unmount. - ErrorState: recovery actions, plus collapsed technical details and a reference, rendered as bounded inert text. - Skeleton / SkeletonGroup: an aria-busy region labelled once, with every animation stopped under prefers-reduced-motion. - PageHeader `back` (link or button) above the page's one h1. - Dialog: the focus trap ADR 0039 deferred, plus focus restoration and an accessible description. Escape is now handled on the dialog itself, so a drawer it was opened from stays open. The shell validates Back targets (parseReturnTarget, dashboardBack): only a canonical Dashboard page on this origin is accepted, otherwise Back goes to the page's parent. It never uses history.back(). Biome's scope-aware suspicious/noAlert is now an error in the root biome.json. tests/native-dialogs.test.ts proves it catches real dialogs and not lookalikes, and scans for the forms the rule misses. It supersedes the shell-only regex test. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-14 18:24:07 -05:00
Zayin_Admin	651efa8829	Merge pull request 'feat(shell): collapsible sidebar, account menu, and phone drawer (Stage 1, ADR 0058)' (#104) from feat/dashboard-shell-navigation into main ... Reviewed-on: #104 Reviewed-by: Zayin_Admin <[email protected]>	2026-10-14 23:05:29 +00:00
ekklesiaandClaude Opus 5.5	cf2f847c8c	test(core): pin the shell's one use of browser storage, not ban it ... CI failed in `identity-verification-boundaries.test.ts`: its guard that a reset token never reaches browser storage was a blanket ban on the word `localStorage` anywhere in the shell. The sidebar preference (ADR 0058) legitimately reads it in the entry point. The guarantee is unchanged: the reset token stays in React state for the life of one form. The guard is now precise: - `localStorage` appears only in `main.tsx`, only to hand it to the sidebar preference; - the shell's only storage write is the sidebar's own key and a validated mode; - the files that ever hold the token (`auth-protocol.ts`, `ResetPasswordForm.tsx`, `HostApp.tsx`) touch no storage API at all; - `sessionStorage` and `document.cookie` stay banned everywhere. A planted `localStorage.setItem("t", token)` in `auth-protocol.ts` fails it. The runtime reset-token test in `auth-recovery.test.tsx` now runs with the production localStorage-backed preference and asserts storage holds nothing but the sidebar key. It passed locally only because Turbo restored `@ekklesia/core:test` from cache: that test reads shell source that Core's task hash does not include. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-14 17:55:07 -05:00
ekklesiaandClaude Opus 5.5	af31724cb4	feat(shell): collapsible sidebar, account menu, and phone drawer ... The Dashboard's shell now follows DESIGN.md §4 (ADR 0058): - A collapsible left sidebar replaces the header-and-column layout. It is icons and labels when expanded and icons only when collapsed; each collapsed item keeps its name, visually hidden, and shows a tooltip on hover and on keyboard focus (WCAG 2.2 §1.4.13). The Overview comes first, then the server's groups and modules. There is no top bar. - The expanded/collapsed choice is remembered in this browser's localStorage, behind a SidebarPreference interface that a synced store can replace later. - An account menu at the bottom of the sidebar follows the WAI-ARIA menu button pattern and offers only Sign out, which now lives there rather than in the header. - On phones (below 48em) the same navigation opens in a modal drawer: the page behind it is inert and focus is trapped inside it. Escape, its close button, and the backdrop close it and return focus to the menu button. Choosing a page closes it and focuses the page. Changing layout keeps the route, the desktop mode, and the mounted module. - Lucide (lucide-react 1.48.0, shell only) is Ekklesia's icon vocabulary. Every module shows one generic icon until manifest v9 lets modules declare their own; there is no per-module icon map. - The identity slot is a neutral placeholder with no inputs, waiting for branding (#101). The tooltip, menu, and drawer stay shell-local until a second consumer needs them (ADR 0039). The deploy smoke now signs out through the account menu, and drives the drawer at phone size in a real browser. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-14 17:49:56 -05:00
Joey	f3b7e19651	Merge pull request 'feat(shell): give every Dashboard page a real URL, with modules at /<module-id> (Stage 1, ADR 0057)' (#103) from feat/dashboard-url-routing into main ... Reviewed-on: #103 Reviewed-by: Joey <[email protected]>	2026-10-14 22:07:20 +00:00
ekklesiaandClaude Opus 5.5	ba60f70835	feat(shell): make module pages first-class top-level routes ... Module pages move from `/modules/<id>` to `/<module-id>` (`/signage`), beside `/settings` and `/account`, so the implementation concept "module" never appears in a user-facing address. ADR 0057 is rewritten to match. - Core reserves the top-level names the platform actually serves today (`account`, `api`, `assets`, `display`, `settings`), and discovery refuses a module that declares one with `MODULE_ID_RESERVED`. That covers startup, `modules:validate`, and package verification. Tests in `apps/api` hold the set to every top-level route the API registers and every page the shell interprets. - The API serves the Dashboard page at `/<module-id>` and below only for modules discovered with a Dashboard UI, enabled or not: a disabled module's bookmark still opens the Dashboard, which says it is unavailable. An arbitrary root path such as `/definitely-not-a-real-module` stays the sanitized 404. - Both reference proxies forward every top-level path shaped like a module id and let the API decide; the split Dashboard hostname still refuses `/api`, `/display`, and `/assets`. Installing a module needs no proxy change. - `/<module-id>/<page>` is already served and forwarded, so a later module sub-page contract needs no routing or deployment change; the shell shows "Page not found" there until it exists. - The deploy smoke checks a module's address before install, while installed, while disabled, after removal, and after reinstall, plus unknown names and the old `/modules/…` form through the real proxy. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-14 08:42:34 -05:00
ekklesiaandClaude Opus 5.5	9afe9376c4	feat(shell): give every Dashboard page a real URL ... The Dashboard had one address. The API served the page only at `/`, both reference proxies forwarded only `/`, and the open module lived in React state, so a refresh went back to the first module, nothing could be bookmarked, and Back left the Dashboard (DESIGN.md §2.7). ADR 0057 makes the address bar the source of truth: - `/` is a host-owned Overview, now the landing page; `/modules/<id>` mounts that module. An id the server's navigation does not list shows "This page isn't available" and loads nothing; any other Dashboard address is a host-owned "Page not found". - `/modules`, `/settings`, and `/account` are reserved whole, from one list (`@ekklesia/shell/dashboard-routes`) that the shell's router and the API's page routes both read. The API serves the same frozen page, ETag, and security headers anywhere inside them; look-alikes and other methods stay the sanitized 404. - A small host-owned history replaces the selected-module state, built in the entry point so it stays the only file touching `window`. Navigation items are real links; modified clicks are left to the browser. Focus moves to the page after an in-place change, and the tab is named after the page. - Sign-in still happens in place with no return value (ADR 0034), so a deep link opens its own page after sign-in. - Both reference Caddyfiles forward the new paths; the deploy smoke now reloads a module's address through the real proxy and requires it to mount again. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-14 08:11:02 -05:00
Zayin_Admin	44430b5d59	Merge pull request 'test(api): let a shutdown's closed connections leave pg_stat_activity' (#100) from fix/flaky-shutdown-connection-check into main ... Reviewed-on: #100 Reviewed-by: Zayin_Admin <[email protected]>	2026-10-14 04:41:38 +00:00
Zayin_Admin	bef516796e	Merge branch 'main' into fix/flaky-shutdown-connection-check	2026-10-14 04:23:11 +00:00
Zayin_Admin	9bef1d9ef2	Merge pull request 'docs(claude): file an issue for what you find outside the task' (#99) from docs/claude-md-report-findings into main ... Reviewed-on: #99 Reviewed-by: Zayin_Admin <[email protected]>	2026-10-14 04:23:04 +00:00
ekklesiaandClaude Opus 5.5	f2fc069e66	test(api): let a shutdown's closed connections leave pg_stat_activity ... Four integration tests shut the API down and immediately count the database's rows in pg_stat_activity, expecting zero. PostgreSQL ends a backend asynchronously: pool.end() resolves once the client side has closed, and the server can still list that backend for a moment. On a loaded runner an immediate count saw one, failing migration-smoke on a docs-only PR (Ekklesia CI run #238, module-database.integration.ts:764, "expected 1 to be +0"). Reproduced against postgres:18.4-alpine3.24 limited to 0.05 CPU: after pool.end() resolved, the backend was still listed in 7 of 300 trials, and gone about a millisecond later. The checks now wait up to 3 s for the count to reach zero. A connection that is genuinely left open is still caught: an idle pooled client stays listed for pg-pool's 10 s idle timeout, far past the deadline. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-13 23:13:21 -05:00
ekklesiaandClaude Opus 5.5	0552442c7c	docs(claude): file an issue for what you find outside the task ... Findings that only live in a chat reply get lost. Agents now open a descriptive issue in the repository a problem belongs to (after searching for an existing one), mark it found-by-claude, leave it unassigned, and list what they filed when they report back. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-13 22:58:17 -05:00
Zayin_Admin	63fda0f8d6	Merge pull request 'fix(ci): confine the sweep self-test to its own run' (#96) from fix/ci-sweep-self-test-scope into main ... Reviewed-on: #96 Reviewed-by: Zayin_Admin <[email protected]>	2026-10-14 03:55:35 +00:00
ekklesiaandClaude Opus 5.5	94fa7a17a8	fix(ci): confine the sweep self-test to its own run ... scripts/test-ci-sweep.sh proves the stale sweep by running `ci-sweep.sh --stale --max-age-seconds 0` on the runner's shared Docker daemon. With a zero threshold that removes every `ekklesia-ci-` stack on the daemon, not just the test's own: any job running at that moment loses its containers, networks, and volumes. It reported "CI sweep checks passed" while doing it. Core's infrastructure-smoke job runs the self-test on every run, and twice tore down Signage's integration stack mid-scenario (Zayin/Signage run 288: its first attempt, and the second one during connectivity-blip). `ci-sweep.sh --stale` now takes `--prefix P`, which narrows the sweep to stacks whose names begin with P and must itself begin with the CI prefix, so it can only narrow a sweep, never widen one. The self-test confines every stale sweep to its own fake run and proves that another run's stack survives even the zero threshold. The workflow's own sweeps are unchanged. Regression: a bystander stack from another run in the self-test, and a Docker-free guard that every stale sweep in the self-test is confined and the workflow's keep the default threshold. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-13 22:46:38 -05:00
Zayin_Admin	437720f228	Merge pull request 'chore(release): prepare 0.2.5' (#95) from chore/release-0.2.5 into main ... Reviewed-on: #95 Reviewed-by: Zayin_Admin <[email protected]> v0.2.5	2026-10-14 03:37:04 +00:00
ekklesiaandClaude Opus 5.5	d3148d45f7	chore(release): prepare 0.2.5 ... Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-13 22:28:08 -05:00
Zayin_Admin	303d455315	Merge pull request 'chore: publish packages to the registry's current Zayin location' (#93) from chore/zayin-package-registry into main ... Reviewed-on: #93 Reviewed-by: Zayin_Admin <[email protected]>	2026-10-14 03:19:45 +00:00
Zayin_Admin	39f48dc7c9	Merge branch 'main' into chore/zayin-package-registry	2026-10-14 03:09:53 +00:00
Zayin_Admin	9d515cd56f	Merge pull request 'fix(devices): keep an in-use display paired by renewing its credential (ADR 0056)' (#94) from fix/device-credential-renewal into main ... Reviewed-on: #94 Reviewed-by: Zayin_Admin <[email protected]>	2026-10-14 03:08:17 +00:00
Zayin_Admin	b8a826f8be	Merge branch 'main' into fix/device-credential-renewal	2026-10-14 02:07:43 +00:00
Zayin_Admin	0c9b8f7af9	Merge pull request 'fix(display): Stage 0 display continuity, revocation, and kiosk recovery' (#92) from stage0/display-runtime-continuity into main ... Reviewed-on: #92 Reviewed-by: Zayin_Admin <[email protected]>	2026-10-14 02:06:01 +00:00
ekklesiaandClaude Opus 5.5	5e9433d96b	docs(deploy): describe the in-use credential renewal in the kiosk guide ... ADR 0056 (Zayin/Ekklesia#94) replaces the fixed 180 days from pairing with 180 days from last use, renewed while the screen is in use; the guide no longer tells operators to track pairing dates. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-12 22:30:17 -05:00
ekklesiaandClaude Opus 5.5	650932a170	fix(devices): keep an in-use display paired, renewing its credential instead of expiring it ... A device credential was accepted for a fixed 180 days from pairing, so every working screen dropped to a pairing code on the anniversary of its pairing, and screens paired together failed together. Measure the 180 days from when the device was last seen instead, and have the display descriptor - which every screen requests on start, on reconnect, and periodically - re-issue the cookie that authenticated it with a fresh lifetime. The value is not rotated, so a renewal lost in transit cannot strand a screen. Revoked, expired, and unknown credentials are never renewed, a person never receives a device cookie, and an abandoned screen still stops being an identity 180 days after it was last seen. No migration: lastSeenAt already slides with use. ADR 0056 supersedes the session-lifetime section of ADR 0036. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-12 22:27:27 -05:00
ekklesiaandClaude Opus 5.5	2d861c6bf0	chore: publish and document packages at the registry's current Zayin location ... The package registry moved with the repositories to git.zayin.net/api/packages/Zayin/npm/; the old River_of_Glory_Church address now answers 502, so the next manual Publish packages run would have failed. Point the workflow, the release and module-development docs, and the disposable-Gitea publication proof's owner at Zayin. The CI Docker label keys keep their names: they are identifiers the sweep matches on, not hosts. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-12 22:23:52 -05:00
ekklesiaandClaude Opus 5.5	bae4ff3c6a	test(deploy): re-pair the kiosk after the revoke scenario ... The revoke scenario left the kiosk revoked, so any display check after it - the post-recreation restart check in particular - failed by construction. That is why Signage could never run it. Finish the scenario the way the roadmap states the requirement: a revoked screen shows a fresh code, is paired again, resumes without a reload, and for Signage keeps its existing roster entry rather than appearing as a new screen. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-12 22:02:35 -05:00
ekklesiaandClaude Opus 5.5	9331a8f7df	fix(display): retry a display that could not start, and re-resolve a running one periodically ... A kiosk that booted before its server, as after a power cut, stopped on 'This display could not be reached' until someone pressed Retry: with the network up, no online event ever came. It now retries on its own, from two seconds doubling to a minute. A running display also re-resolves its descriptor every five minutes in the background, so a module upgraded on the server is picked up without a reload, and the same answer disturbs nothing. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-12 21:45:37 -05:00
ekklesiaandClaude Opus 5.5	8f90871be0	docs(deploy): document how to set up an unattended display kiosk ... Stage 0 requires that kiosk setup can be reproduced from documentation, and there was none. Cover the address, a single-launcher Chromium command with a persistent profile, a systemd user unit, pairing and the fixed 180-day device credential, what the screen does through each kind of outage, the known offline cold-start limit, and why a second launcher produces duplicate windows. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-12 21:45:37 -05:00
ekklesiaandClaude Opus 5.5	85b1377fd3	fix(devices): confirm before revoking a display ... Revoke acted on a single click, yet it strands the screen until someone re-pairs it in person. Explain the consequence in the shared in-product Dialog first (DESIGN 21.4), with an obvious Cancel. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-12 21:31:36 -05:00
ekklesiaandClaude Opus 5.5	4bcdb578e6	fix(display): keep a live display across reconnects, and return a revoked one to pairing ... Every browser 'online' event reset the display host to its loading state and mounted the module again: a fresh viewer session, a fresh stage, and every cached object URL released, on each Wi-Fi blip. And a device revoked while its display was open never noticed; it kept playing cached content and polling 403s until someone reloaded the page. The host now re-resolves its descriptor in the background (ADR 0043) and only replaces the frame when the answer actually changed: a new version or principal remounts, a refusal returns the screen to pairing (ADR 0036), and any other failure keeps the running display. A module request refused with 401/403 prompts the same revalidation, throttled, so revocation is noticed within one heartbeat. The offline indicator waits ten seconds before appearing, so a momentary blip shows nothing, and no longer names the platform on a lobby wall. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-12 21:31:36 -05:00
ekklesiaandClaude Opus 5.5	06bad2fe36	docs: bring CLAUDE.md in line with the current repositories and product rules ... Core's agent guidance still described modules living in this monorepo and manifest v7, and said nothing about the product rules that now govern every change. Record that first-party modules live in their own Zayin repositories and install as Module Packages, that the parent ROADMAP.md and DESIGN.md are authoritative for product direction, the ownership, branding, token, dark-mode and no-native-dialog rules, that display pairing is transitional until Stage 1, and the branch-per-PR, no-push-to-main, and no-release-tag workflow. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-12 21:31:36 -05:00
The_River	ae976ca229	Merge pull request 'chore(release): prepare 0.2.4' (#91) from chore/release-0.2.4 into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/91 Reviewed-by: The_River <[email protected]> v0.2.4	2026-10-10 17:09:10 +00:00
ekklesia	f9585cc7ec	chore(release): prepare 0.2.4	2026-10-10 11:54:00 -05:00
The_River	6dae29412f	Merge pull request 'test(deploy): exercise external module packages' (#90) from test/external-module-deploy-smoke into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/90 Reviewed-by: The_River <[email protected]>	2026-10-10 16:32:32 +00:00
ekklesia	40ef0ff802	fix(deploy): bound object storage allocation size	2026-10-10 11:07:53 -05:00
ekklesia	a0e9948820	fix(storage): recognize errors across module packages	2026-10-10 10:54:13 -05:00
ekklesia	6e64b3c5f9	test(deploy): allow slower display uploads	2026-10-09 22:37:18 -05:00
ekklesia	fa27603133	test(deploy): exercise external module packages	2026-10-09 22:18:04 -05:00
The_River	9e01679fcb	Merge pull request 'chore(release): prepare 0.2.3' (#89) from chore/release-0.2.3 into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/89 Reviewed-by: The_River <[email protected]> v0.2.3	2026-10-10 00:01:54 +00:00
ekklesia	227c92e35d	chore(release): prepare 0.2.3	2026-10-09 18:38:22 -05:00