6 Commits

Include renames

Author	SHA1	Message	Date
ekklesiaandClaude Opus 5.5	52a665502f	chore: license Ekklesia under AGPL-3.0-or-later instead of AGPL-3.0-only ... The project decision is the GNU Affero General Public License, version 3 or (at your option) any later version. - "license": "AGPL-3.0-or-later" in all 14 Ekklesia-owned package.json files. - README: the License section states AGPL v3 or any later version (SPDX AGPL-3.0-or-later) and carries the FSF's standard grant: "either version 3 of the License, or (at your option) any later version", with its warranty disclaimer and pointer to the license. - Module template README and module development guide: AGPL-3.0-or-later for Ekklesia and official modules. LICENSE is unchanged: it remains the canonical AGPLv3 text. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 13:53:56 -05:00
ekklesiaandClaude Opus 5.5	9a328f647e	chore: license Ekklesia under AGPL-3.0-only ... Ekklesia is open source under the GNU Affero General Public License, version 3 only. Module Package v1 (#66) bundles Ekklesia's SDK and contracts into distributable module packages, so the platform needs an explicit license before such artifacts are distributed. - LICENSE: the GNU AGPL v3 text, verbatim from https://www.gnu.org/licenses/agpl-3.0.txt (sha256 0d96a4ff68ad6d4b6f1f30f713b18d5184912ba8dd389f86aa7710db079abcb0). - "license": "AGPL-3.0-only" in the root package.json and every Ekklesia workspace package (13 packages), the module template included. Nothing else in any manifest changed. - README: a License section replacing the "no license selected yet" placeholder: AGPL v3 only, source available under its terms, section 13's network-use obligation, and the policy that official Ekklesia modules use AGPL-3.0-only. - Module template README and module development guide: the template declares the license; Module Package v1 does not yet record a module's own license, which needs a format change under ADR 0049. AGPL-3.0-only, not -or-later: the decision is AGPL-3.0, and nothing in the repository grants later versions. No runtime, ADR, package-format, Signage, or instance change. The packaged template is byte-identical before and after. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 13:38:33 -05:00
ekklesiaandClaude Opus 5.5	5abc8be167	chore(release): prepare 0.1.2 ... Every workspace package declares 0.1.2, as the 0.1.1 release did for itself, and the deploy README's build example names it. The tag v0.1.2 created on 12dca3e carries package.json 0.1.1, which the instance's assemble.sh refuses ("its tag and package.json disagree"), and the running platform would report 0.1.1. 0.1.2 carries what the first production deployment found: - #57: Doctor checks the client-address configuration the API runs; - #58: storage over HTTP/1.1 (repeat image loads no longer fail with ERR_HTTP2_PROTOCOL_ERROR), and storage CORS owned by the proxy; - #60: CI stacks never outlive their job; - #56: display-device smoke scenarios; - #59, #61: ADR 0047 proposed, and the CI documentation corrected for Gitea 1.27.2. templates/module keeps its own version. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-05 22:56:35 -05:00
ekklesiaandClaude Opus 5.5	7cbe4e1b2c	chore(release): prepare 0.1.1 and accept ADR 0044 ... Bump the root and every platform workspace package from 0.1.0 to 0.1.1, so the platform reports the version the v0.1.1 tag will carry. Module discovery checks compatibility.platform against the root version and compatibility.moduleSdk against @ekklesia/module-sdk; both stay inside every existing ^0.1.0 range, so no module needs a new range. Everything since v0.1.0 is additive (health endpoints, Dashboard serving, production dependency declarations, the deployment image and Compose project). templates/module keeps 0.1.0: it is a module, versioned on its own, and its manifest, source, and tests carry its own product version. Mark ADR 0044 Accepted. Slices 1-4 are implemented and proven by CI's image build and deploy smoke; slice 6 (scheduled backups and the restore procedure) remains its open item. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-03 10:03:33 -05:00
ekklesiaandClaude Opus 5	44e676f0df	feat: close the browser boundary and add the generic UI host loader ... Two gaps stood between the module UI contract and a host that could use it. ADR 0023 recorded the first honestly but never diagnosed it: a module UI file compiled with `"types": []` could still typecheck `process.env`. The second was simply missing — nothing imported a compiled artifact, checked its identity, mounted it, or tore it down. The leak was one type-only import, bisected against the real type graph rather than guessed. `@ekklesia/module-ui-sdk` imported `type { EkklesiaPrincipal } from "@ekklesia/contracts"`. Importing contracts/identity alone is clean and importing Zod alone is clean, but contracts exposes a single barrel entry, so that one import reached module-database, whose Drizzle types re-introduce Node's globals. The runtime was never affected — the import was erased and host-context.js is `export {}` — but a type-graph leak is still a real boundary failure, because it silently permits code that cannot run in its target environment. The fix is not a narrower import path. The SDK now has no dependencies at all, so there is no graph to leak through and no future contracts change can reopen this. It owns `ModuleUiPrincipal`: the same shape ADR 0022 chose, with the Zod brand dropped. That brand encodes a server-side parsing guarantee a browser cannot produce, and it is the same reason `permissions.has` already took a plain string. An Ekklesia host still passes its own `EkklesiaPrincipal` straight through — a branded string is assignable to `string` — while a standalone host builds the literal. Proven the way an author experiences it: two fixtures compiled under the exact project a module uses, one supported and one deliberately reaching for `process`, with the second required to fail on that specific name. `@ekklesia/module-ui-host` is the generic loader, in its own package because the SDK is bundled into every module artifact and host-only loader code has no business shipping there. The boundary checker enforces both directions: modules may not depend on the loader, and the loader may depend only on the SDK plus dev-time tooling. The distinction that shaped the design: Core resolves `entrypoints.ui` to an absolute path on the server's disk, and a browser needs a URL. A loader that accepted the path would test green on a server and fail in every real host, and would quietly own asset publication. So the loader takes a browser-loadable URL and knows nothing about how one is obtained. Ekklesia has no route that publishes installed artifacts, so this is precisely: loader complete, publication deferred. Nothing can mount an installed module UI yet, and the docs say so rather than implying otherwise. Dynamic import is `(url) => import(url)` with a non-analyzable specifier, kept as a runtime import so a host does not statically bundle every installed module or need a hardcoded registry. It is injectable for bundlers needing their own escape hatch, and deliberately not `eval` or `new Function`, which would cost a host `unsafe-eval` in its CSP. Identity is validated through the SDK's existing parser before `mount` runs, so a stale or mismatched bundle never renders. Contract violations propagate unwrapped; the loader adds only import and mount failure codes, sanitized, with the cause attached. Unmount is idempotent, safe when a module returned no cleanup, and marks an instance unmounted before running cleanup so a throwing cleanup surfaces once and never re-runs. A failed mount registers no cleanup. Each instance owns its own state, so two mounts coexist. The loader never mutates the host's container — not on success, failure, or unmount. Tests prove all of it against real module URLs (`data:`, which both browsers and Node import natively) rather than filesystem paths, including one artifact built by the canonical Pass 2 pipeline and run under both an Ekklesia-shaped and a standalone-shaped context. Core, apps/api, and the contracts package are untouched; discovery remains inert. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-21 21:44:42 -05:00
ekklesiaandClaude Opus 5	8d651c427d	feat: define the module UI authoring model and host contract ... ADR 0021 established that a module may own UI and added a statically validated, never-executed `entrypoints.ui` path, but deliberately left five questions open: what the artifact exports, what a host provides, how one artifact runs under both Ekklesia and a standalone host, what the browser-side trust model is, and how module UI avoids being welded to a Dashboard that does not exist. This answers them. React and TypeScript are the supported module UI authoring model. The repository already leaned this way: `packages/typescript-config` ships a `browser.json` preset and a `react-native.json` preset with `"jsx": "react-jsx"`, and ADR 0002 names browser and React Native configurations. One framework is supported; every other stays rejected. React is deliberately not part of the contract. A module's compiled artifact default-exports `defineModuleUi({ id, version, mount })`, and `mount(container, context)` takes a DOM element and returns an unmount function. `id` and `version` are build-artifact identity markers a host verifies against the manifest, mirroring `defineModuleRuntime` exactly. A host needs an element and a context, never a matching rendering library, so a module's framework, a host's framework, and the platform boundary between them stay independent. The contract lives in a new `@ekklesia/module-ui-sdk` rather than in `@ekklesia/module-sdk`, for a concrete reason: that package re-exports all of `@ekklesia/contracts`, so routing module UI through it would drag Zod, Drizzle, and semver into every browser bundle. The new package has no runtime dependencies, and its one dependency on contracts is type-only — the emitted `host-context.js` is `export {};`, and a test pins that so it cannot regress. The host context is four members: `moduleId`, `api`, `principal`, and `permissions`. Navigation, theme, module configuration, organization context, and diagnostics are deliberately absent; each needs a design that does not exist. Module UI reaches its backend through `api.request(path)` with a path relative to its own API root and never constructs `/api/v1/modules/<id>/...`, which is Ekklesia's private deployment detail — a module that builds that URL is silently unhostable anywhere else. One fixture artifact is mounted under two hosts with different origins and URL shapes to prove it. Client-side permission hints are presentation only, and both the docs and a test say so plainly: a denied hint does not stop the module from calling its API, because server-side `requirePermission` is the only authority. Module UI is trusted code in the host's own browser realm — no iframe, no sandbox — which matches the backend model rather than overstating it, since a module's server half already holds the API's database authority. The boundary guard is narrowed precisely, not removed: `.tsx`, `react`, and `react-dom` are un-denied and modules may depend on the new `module-ui-sdk` role. `.jsx`, `.css`, every other framework, `react-router-dom`, `react-native`, and `@vitejs/plugin-react` stay denied, layer rules are untouched, and an unsupported framework aliased behind an allowed name (`"react": "npm:vue@3"`) is resolved and rejected by its real target. Fixtures prove each case, including that module UI source still cannot import Core. Core, apps/api, and the manifest contract are untouched. Discovery still validates the `entrypoints.ui` path and never evaluates it; hosts perform their own dynamic import and validate the result with `parseModuleUiExport`. No Dashboard shell, UI runtime, navigation, grouping, standalone host, build or styling pipeline, installer, hot-loading, or feature module is added. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-21 20:52:47 -05:00