112 Commits

Include renames

Author	SHA1	Message	Date
ekklesia	4be046c8d0	fix: support native package verifier scratch	2026-10-09 18:05:04 -05:00
ekklesiaandClaude Opus 5.5	98d93cc12d	docs: accept ADR 0052, whose supplement mechanism is fully implemented ... Every decision in ADR 0052 is implemented and tested in @ekklesia/module-pack: - package material first, and a supplement only adds to it; - reviewed, generic supplement data, checked in with the packager; - an exact name, version, and content-digest match, failing closed on any mismatch; - the documented, host-independent digest; - a deterministic, labelled merge; - no licence override, with a consistency check; - no network during packaging; - packageFormat 1. The libvips 1.3.3 and 1.3.4 supplements are curated and shipped. The source-obligation determination it deferred is now decided by ADR 0055. Only the status line and the index entry change; the decision text is untouched. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 23:24:16 -05:00
ekklesiaandClaude Opus 5.5	e083c44e05	feat: corresponding-source artifacts for native packages that redistribute copyleft code (ADR 0055) ... Ekklesia may publicly distribute a native Module Package containing LGPL or MPL components only beside a version-specific corresponding-source artifact. The artifact carries the exact source, patches, build definitions, and rebuild and relink instructions for those components. ADR 0055 (Accepted) records the policy: project compliance policy, not legal certification. It decides the item ADR 0052 deferred, and extends ADR 0049's distributable-release gate. Module Package v1, packageFormat 1, and both libvips supplements are unchanged. The mechanism is generic and lives in @ekklesia/module-pack: - Source recipes: reviewed data under corresponding-sources/<package>/<version>/. recipe.json names the exact package (name, version, content digest) and the exact supplement it was prepared with, and lists every component with its role, licence, licence material, and relationship to the binary. Every source file and patch is recorded by origin, size, and SHA-256; documents are hashed too, and every exclusion has a reason. Loading is strict and refuses anything unlisted. - Acquisition (the only network step) fetches each recorded file once into a cache keyed by SHA-256. It uses node:https with exact headers and no decoding, retries transient failures, and stores only bytes that match. - Construction is offline. From a built package it finds the covered native dependencies (by declared licence, or by a supplement component's licence), verifies every byte, and writes four sibling artifacts: the deterministic <package>-corresponding-source.tar.gz and its .sha256; <package>.redistribution.json, linking package, dependencies, supplement, recipe, and source by digest; and <package>.source-notice.txt, the release notice. - The public-distribution gate (verifyRedistribution, `ekklesia-corresponding-source verify`) approves only when the recipe, supplement, canonical archive, manifest, and metadata identify exactly these files. It refuses bundled copyleft code, and approves packages with no covered native code without an artifact. packModule is untouched. First complete proof: @img/[email protected] (sharp 0.35.5), from the reviewed supplement and provenance. - 383 components and 387 source files, about 208 MB: the sharp-libvips v1.3.4 build definitions, the 27 library archives, the five build-time patches, the 353 crates librsvg's resolved Cargo.lock records, and rust-src for nightly-2026-09-27 (rustc 75a75c3e0), which vendors std's dependencies. - BUILDING.md and two helpers point sharp-libvips's unchanged build logic at those files. - Followed in a Rocky Linux 8 container with networking disabled, they rebuilt libvips-cpp.so.8.18.7, byte-identically across two builds. Swapped into a verified, extracted native package, the rebuilt library was the one loaded, and sharp ran. - The native proof's source artifact, native-proof-0.1.0-linux-x64-glibc-corresponding-source.tar.gz, is 207242785 bytes, sha256 cc405492032b04a5391ab84e64f0e5e50f78e571ef7818204782c25a03eb50b7. It is byte-identical from unrelated directories and from a cache acquired fresh from upstream. Tests: - corresponding-source.test.ts runs in CI: synthetic inputs, every negative case, acquisition with retries and refusal, and determinism. - corresponding-source-native.test.ts checks the real recipe everywhere. With a verified cache (`pnpm test:corresponding-source`, which acquires once) it builds the real artifact twice, gates it, fails it closed, and runs sharp from the package. Docs: the module guide's distribution section, the README and architecture notes, and an ADR 0052 cross-reference. No Signage change, version bump, publication, or tag. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 23:17:35 -05:00
ekklesiaandClaude Opus 5.5	afaf3a853c	feat: reviewed libvips 1.3.4 supplement, and the native proof on sharp 0.35.5 ... sharp 0.35.4 carries a production-relevant librsvg advisory (GHSA-wq5f-xc86-pv6w). Its fix, sharp 0.35.5, loads @img/sharp-libvips-linux-x64 1.3.4, which ships no licence material either. This adds the reviewed supplement for that exact package (ADR 0052) and moves the packager's native proof to sharp 0.35.5, so a later 0.2.1 release can package it on linux-x64-glibc. Nothing in module-pack's code changes: supplement selection is already by exact name, version, and content digest. - Supplement: license-supplements/@img/sharp-libvips-linux-x64/1.3.4/ - content digest ekklesia-content-v1:sha256:2927fe11493461fa34847191d0b9b1c6441007c3e99f306e5708cb07fb0a5e59; - 190 components and 146 hashed texts; - assembled with the same method as 1.3.3's, from sharp-libvips v1.3.4's own inputs. That method reproduces the 1.3.3 supplement byte for byte. - PROVENANCE.md records: - the 27 upstream archives and five build-time patches, by sha256; - the librsvg 2.63.2 crate reproduction (cargo 1.99.0; Cargo.lock 5723e14c…); - rustc 75a75c3e…; - every change from 1.3.3. - Notable: sharp-libvips v1.3.4 now states cairo is used under MPL 1.1, not MPL 2.0. cairo ships that text itself, so the standard MPL 2.0 text is no longer added for cairo; selectors still carries it. - No legal conclusion: the LGPL and MPL source-availability determination stays open, as for 1.3.3. - The 1.3.3 supplement is unchanged, and still proven: module-pack keeps sharp 0.35.4 as a test-only devDependency alias (`sharp-0.35.4`). Each supplement is pinned against its real installed libvips, and each matches only its own. - Native proof fixture: sharp 0.35.4 → 0.35.5. The closure has the same shape: sharp, @img/colour, detect-libc, semver, and @img/sharp-linux-x64 0.35.5 with @img/sharp-libvips-linux-x64 1.3.4. The runtime read from the binaries is unchanged: Node-API 9, glibc >= 2.28, x86-64. - Docs: the module guide's note on available supplements. No version bump, no publication, no tag. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 21:34:35 -05:00
ekklesiaandClaude Opus 5.5	1caffc5f26	fix: hand npm the release artifact's absolute path, so publishing finds it ... The first real 0.2.0 publish failed on its first package with ENOENT: "Publishing ekklesia-contracts-0.2.0.tgz failed: npm error code ENOENT". The publish workflow passes a relative release path, --release "$(find package-train …)", which is package-train/ekklesia-packages-0.2.0. The tool validated the artifacts relative to the job's working directory, but ran npm in its own temporary home (cwd /tmp/ekklesia-publish-XXXXXX) with the same relative path, package-train/ekklesia-packages-0.2.0/ekklesia-contracts-0.2.0.tgz, which there names nothing. The disposable-registry suite always passed an absolute path, so it never saw this. - loadReleaseTrain resolves the release directory once; every artifact path is absolute from validation on, and npm is given only that exact file's absolute path (anything else is refused at the npm boundary). - Just before each upload the file is checked against the validated bytes once more; the tool logs the absolute path it publishes, and a failure names it with npm's path/syscall lines (npm's temporary home masked, the token never shown). - Regression tests: unit tests with a recording npm (relative nested release from another cwd; npm's argv, cwd, and the file's existence; a changed artifact refused before npm runs), which fail on the previous tool; and a disposable-Gitea test that runs the CLI exactly as the workflow does, from the Actions artifact layout, round-tripping all nine packages byte for byte. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 17:51:22 -05:00
ekklesiaandClaude Opus 5.5	98e59d4ba0	chore(release): prepare 0.2.0 ... Every platform workspace package and every public @ekklesia/* package declares 0.2.0, and the deploy README's image build example names it. templates/module keeps its own version. 0.2.0, not 0.1.3: before 1.0 a minor version is the breaking one (docs/development/releases.md, ADR 0054), and since 0.1.2 main has broken modules, module authors, and operators: - #64 (ADR 0048): one generic image; installed modules live outside it; - #66, #72 (ADR 0049, 0050): modules install as Module Package v1, and move to the Module Database ABI; - #71: the manifest v8 cutover; v7 manifests are refused; - #79 (ADR 0053): the curated SDK drops defineModuleSchema and the legacy ModuleDatabase type; plus #67 (AGPL), #74, #77 (licensing, native targets), and the public package train (#80, #81). It is also the first package train to publish: 0.1.2 never will be. Because 0.2.0 is outside ^0.1.0, the same change moves to ^0.2.0: - the standalone fixture's @ekklesia ranges and its exact module-pack pin; - the compatibility ranges of the modules built for this release: the template, the standalone fixture, and the native proof module; - the test fixtures that model a module of the current release, or the current platform's versions; - the module-development guide's examples, and the release guide, which now names what a minor bump moves. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 17:26:13 -05:00
ekklesiaandClaude Opus 5.5	486356a01e	docs: ADR 0054, Ekklesia's module-development packages are publicly readable before launch ... ADR 0053 was accepted assuming a private package phase before launch. The project owner has decided otherwise: Ekklesia is not secret, its source is already public, and only publication must be restricted. ADR 0054 supersedes ADR 0053 only where it describes that phase as private or requires authenticated package reads. Packages may be read anonymously, which is neither a launch nor an API stability promise beyond pre-1.0 SemVer; publication stays authenticated and restricted; published versions stay immutable; the River_of_Glory_Church Gitea namespace is an acceptable host; a public launch remains a separate decision. Every other ADR 0053 decision is unchanged. ADR 0053 gets only a cross-reference line. The ADR index, the release and module-development guides, the README status, and the publish workflow's comment now point at ADR 0054. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 10:24:17 -05:00
ekklesiaandClaude Opus 5.5	d3c62e63bf	feat: publish the exact @ekklesia package train to the npm registry (ADR 0053) ... Publishes one package release train to the Gitea npm registry under River_of_Glory_Church, whose packages are publicly readable on purpose: exactly the .tgz files the package-release gate proved, and nothing else. Nothing is published by this change. - scripts/publish-package-train.ts validates the whole local train before any request (gate manifest hash, version, revision, unmodified source, the nine packages, every artifact's size, SHA-256, integrity, SHA256SUMS line, and inner package.json), then publishes in dependency order with `npm publish <file.tgz>` under a staging tag. Each package is reconciled first (absent: publish; same bytes: accept; other bytes: hard stop, version burned), then read back: metadata (name, version, integrity, dependency maps, normalized bin, tarball on the registry) and the tarball itself, byte for byte, also anonymously. `latest` moves only after all nine verify; reruns converge and never delete anything. It writes a publication record. The token comes from EKKLESIA_PACKAGES_PUBLISH_TOKEN only, through a temporary npm config that refers to the variable. - scripts/test-package-publication.sh proves it against a disposable Gitea 1.27.2 with public owners, a publisher team and an outsider: anonymous reads, refused unauthorized publishing, byte-identical round trips, the registry's own 409, partial-train recovery, the burned version hard stop, and dist-tag retry convergence. - CI: package-release keeps its proven release and hands it on as an artifact with its manifest hash; the new package-publication job publishes exactly that artifact to the disposable Gitea. Artifact actions v3 (node20): v4 refuses any server other than github.com. - .github/workflows/publish-packages.yml publishes to the real registry only by manual dispatch on main, after its own gate run, with the secret in the publish step alone. - docs: the public-read model, the workflow, the record, credentials, immutability policy, provider moves, and the first-publication steps. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 09:49:27 -05:00
ekklesiaandClaude Opus 5.5	4f1b1d68c7	fix: keep pnpm's package store out of the release builder's clean-source check ... The package-release job failed its clean-tree assertion in CI. Reproduced as root in a container with a bind-mounted checkout, as the Gitea runner does: after checkout the tree is clean; `pnpm install --frozen-lockfile` then creates `.pnpm-store/` (17,272 untracked files) at the checkout's root, because pnpm keeps its store on the node_modules file system and the checkout is its own mount; `pnpm build` changes nothing. No tracked file is ever modified. - `.pnpm-store/` is ignored, like node_modules: a package cache, never source. The clean-commit requirement is unchanged for every tracked file and every untracked file Git does not ignore. - The clean-tree failure now lists `git status --short` and `git diff --stat`. - Nothing is built before the clean-source assertion: the gate no longer runs a global `pnpm build` first. The builder asserts a clean tree, builds, then fails if its build changed the tree, before packing. Core's verifier is built after both releases, for the consumer proof only. - Every secondary offline install (the second worktree, the consumer module) uses the workspace install's own store explicitly, since pnpm picks a store per file system and those directories are on another. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 08:43:19 -05:00
ekklesiaandClaude Opus 5.5	9debe4e891	feat: the public @ekklesia package release train, built, reproduced, and proven (ADR 0053) ... Produces the exact public package tarballs of a platform release, validates them, and proves a standalone module consumes those artifacts end to end. Nothing is published and no credential is configured. - scripts/package-release.ts (pnpm packages:release) is the canonical release builder: from a clean commit it rebuilds the nine public packages from clean output, packs each, inspects every tarball, checks the release set and coordinated versions, and only then writes ekklesia-packages-<version>/ with the tarballs, SHA256SUMS, and a provider-neutral manifest (ekklesia-package-train.json: version, revision, and each package's file, size, SHA-256, npm integrity). - Packing uses a pack-only pnpm beforePacking hook (passed with --config.pnpmfile, never the workspace's install settings). pnpm inserts rewritten workspace: dependencies in async completion order, so two checkouts of one commit packed module-pack's package.json with keys in a different order; the hook restores the source key order (and the inspection enforces it). It also drops devDependencies, which named private packages outside the train. - scripts/test-package-release.sh (pnpm test:package-release, the CI package-release gate) builds the train twice, the second time from a separate worktree, requires byte-identical release directories, then runs the standalone consumer proof on the release: manifest checked, offline install from the tarballs only, lockfile integrity equal to the manifest's, frozen-lockfile reinstall, no Drizzle, one React, contracts only transitive, every @ekklesia package and module-pack at the release version, skipLibCheck: false, UI build, pack, and Core verification. - docs/development/releases.md documents the release order, the train, the artifacts, and the reproducibility findings; registry publication remains unimplemented. - ADR 0053 is Accepted: everything it decides that does not need a registry is now proven, and registry provisioning is on its own Deferred list. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 08:02:41 -05:00
ekklesiaandClaude Opus 5.5	aaa7ebfd84	fix: keep Drizzle out of every published declaration (ADR 0053) ... @ekklesia/contracts still emitted a type-only import of drizzle-orm/node-postgres for the legacy ModuleDatabase facade, so a standalone module type-checked only because skipLibCheck hid it. - ModuleDatabase, LegacyModuleRuntimeServices and AnyModuleRuntimeServices move to core/src/modules/database.ts, beside the facade Core builds; the facade itself is unchanged. - contracts' runtime, route, and services generics no longer name an ORM: the database type is a plain parameter defaulting to the ABI v1 executor, and the legacy definition's database is opaque until Core specializes it. Core and apps/api name the legacy types from Core. - contracts drops its drizzle-orm optional peer and devDependency; Drizzle stays public only through @ekklesia/module-database/drizzle. - The facade's type-level test moves from contracts to Core. - Regression proof: the standalone fixture type-checks with skipLibCheck: false against the packed tarballs, with no drizzle-orm installed (the smoke asserts both). Against the previous contracts tarball the same check fails with TS2307 on drizzle-orm/node-postgres. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 07:40:43 -05:00
ekklesiaandClaude Opus 5.5	89d5d0f2da	feat: standalone module-build readiness for the public @ekklesia packages (ADR 0053) ... Makes the public module-development package set usable from a module repository outside the monorepo. Nothing is published. - Curated @ekklesia/module-sdk: an explicit author API, no contracts barrel, no identity/authorization internals, no Drizzle and no legacy ModuleDatabase type. defineModuleRuntime returns the SDK's own named interfaces so a module's emitted declarations never reach into @ekklesia/contracts. defineModuleSchema is gone; createModuleTable and defineModuleSchemaMetadata live in @ekklesia/module-database. - Drizzle: no longer a dependency of module-sdk or contracts. Core keeps the legacy Drizzle schema validator (moved to core/src/modules) and its legacy runtime support; drizzle-orm is an optional peer only. - React is a peer (plus devDependency) of @ekklesia/ui; the boundary checker allows exactly that consumer-selected peer. - @ekklesia/typescript-config is publishable; module-ui-host is private. Every public package carries "ekklesia.distribution": "module-development" and no monorepo-root prepack. - module-pack reads the Node.js range from the module's own engines.node and recognizes Ekklesia packages by name plus that marker, so registry-installed packages are incorporated, SDK-compatibility checked, and never credited as third-party. - scripts/pack-public-packages.ts (pnpm packages:pack) rebuilds, packs and inspects the nine public tarballs; scripts/test-standalone-module.sh (pnpm test:standalone-module, new CI job) installs them into a fixture module outside the repository and proves it typechecks, builds, packages, and verifies. - Public-package boundary tests and module-development docs. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 07:28:54 -05:00
ekklesiaandClaude Opus 5.5	47e64c6f39	docs: propose ADR 0053, standalone module builds from Ekklesia packages over the npm registry protocol ... Defines the external module-development and package-distribution contract that ADR 0049 deferred. - Protocol, not provider: packages are distributed over the standard npm registry protocol. Gitea may host the private phase. Host-neutral lockfiles and an Ekklesia proxy are not required; a registry move may need one configuration change and a lockfile regeneration, while integrity hashes keep verifying content. - Public set: - Author API: module-sdk, module-database, module-ui-sdk, design-tokens. - Tooling: module-ui-build, module-pack, typescript-config. - ui as a pre-1.0 component API. - contracts only as a transitive implementation dependency. - Core, apps, module-ui-host, and module-template stay unpublished. - Curated SDK before first publication: no full contracts barrel, no forced Drizzle at the SDK root, and no legacy Drizzle database contract in the standalone surface. Drizzle support lives in module-database's adapter. - Dependency rules: React/ReactDOM are peers of the public UI packages (bundling per ADR 0023 is unchanged); Drizzle is an optional peer only where the adapter needs it; modules put runtime packages in dependencies and tooling/config in devDependencies. - Versioning: one coordinated 0.x release version equal to the platform version, with no mixed trains. Ranges go in source and exact artifacts in lockfiles; module-pack is pinned exactly; independent versions deferred. - Standalone packaging: no monorepo checkout. The module declares its own Node range (engines.node). The packager recognizes Ekklesia packages by identity and metadata, not path. No monorepo-root commands at install time. - Supply chain: immutable versions, frozen-lockfile integrity, and a pre-publication smoke that installs the packed tarballs into a clean standalone fixture and proves build, package, and verify. Signing deferred. - Private phase: no committed secrets; credentials come from the environment; verify actual read access before the first publication. Status Proposed. ADR 0047 (still proposed) must be revised against this. No code, registry, credential, or Signage changes. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 20:46:32 -05:00
ekklesiaandClaude Opus 5.5	44d385cd7f	feat: native linux-x64-glibc module packages and reviewed license supplements (ADR 0049, ADR 0052) ... Implements ADR 0049's deferred native target and ADR 0052's reviewed license supplements. The proof case is a real module using sharp. packageFormat stays 1, and `any` is unchanged. Packager (@ekklesia/module-pack): - --target linux-x64-glibc. Native or platform-specific packages, found by the same generic rule that refuses them in `any`, stay outside the bundle. - Each native package's production closure is walked through its own dependencies, installed optionalDependencies that match the target, and required peers. It is copied as real files flat under node_modules/<name>, with no links, dev dependencies, declarations, source maps, or other platforms' packages. Missing or foreign-platform required dependencies, version conflicts, links, foreign machines, and Node.js range conflicts fail closed. - runtime.nodeApi, nodeAbi, and libcVersion are read from the binaries by a small ELF reader: the addon's node_api_module_get_api_version_v1 and the newest GLIBC_ symbol version needed. No shelling out. A native target with no addon is refused. - ADR 0052 supplements: package-provided material stays primary. An exact match on name, version, and ekklesia-content-v1 digest (sorted normalized paths with each file's size and SHA-256; no metadata) adds labelled material after the package's own. Any mismatch, a declared-licence conflict, or a malformed or unreviewed supplement file fails. Missing material with no supplement still fails. Supplement for @img/[email protected]: - 184 components and 143 unique texts, assembled from the exact upstream sources sharp-libvips v1.3.3 builds linux-x64 from: 27 C/C++ libraries, glib's gvdb, librsvg's Rust crates (reproduced with cargo tree), the Rust standard library at the rustc commit recorded in the binary, plus the LGPL-3.0, GPL-3.0, and MPL-2.0 texts. Each source is recorded with its SHA-256 in PROVENANCE.md. - It pins digest ekklesia-content-v1:sha256:50647b0b…, which is identical from the installed copy and from the registry tarball. - LGPL/MPL source-availability determinations stay open, as ADR 0052 states. Nothing claims they are met. Verifier (Core): - linux-x64-glibc is accepted only on a host whose platform, arch, glibc family and version, and Node-API version (from Node itself) match. - Every ELF file must be x86-64; every .node must be an ELF object. - `any` packages now also refuse node_modules/ and ELF files. - Contract: native metadata must state nodeApi or nodeAbi, and Linux targets libcVersion (ADR 0049). Proof: - A checked-in AGPL native fixture packs byte-identically from unrelated copies (8.86 MB) and verifies with Core's verifier. - Extracted elsewhere, it runs a sharp resize and PNG round trip in an empty-environment process. Every resolution stays in the package, and only the package's addon and libvips plus host system libraries load. Signage is untouched. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 20:16:53 -05:00
ekklesiaandClaude Opus 5.5	951453c735	docs: ADR 0052, what supplement review is, and what the match digest covers ... Two wording clarifications; no decision changes. - Repository review of a supplement is project and code review of a build input. It is not legal review, and not proof that redistribution obligations are satisfied. - The exact-match digest is deterministic over normalized redistributed relative paths and file bytes. It excludes host filesystem metadata, timestamps, ownership, permissions, and extraction or listing order. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 19:39:52 -05:00
ekklesiaandClaude Opus 5.5	99f145a80c	docs: propose ADR 0052, reviewed license supplements for redistributed dependencies ... When a redistributed dependency's own package omits licence material that redistribution requires, the canonical packager may use a checked-in, reviewed supplement. The motivating case is @img/[email protected]: LGPL-3.0-or-later, and its shared library contains about 29 libraries, but it ships no licence text or notice for any of them. ADR 0052 decides: - package-provided material stays the preferred source and is never replaced; - a supplement matches exact package name, version, and a packager-computed content integrity; any mismatch fails closed, with no fallback; - supplements are immutable, reviewed build inputs with no network access during packaging; - they may carry licence texts, copyright and attribution notices, provenance, corresponding-source information, and other accompanying material; - merging is deterministic, and supplement material is labelled; - a supplement never overrides a dependency's declared licence; a disagreement fails packaging; - the mechanism is generic, with no package-specific code; - missing material with no exact supplement still fails packaging; - packageFormat stays 1. It extends ADR 0049 only in the collection rule that ADR delegated to the implementation. Legal and source-obligation determinations for LGPL, MPL, and similar binaries are explicitly deferred: no written offer, URL, or mirror is asserted to satisfy any licence. Status Proposed. No implementation, no libvips supplement, and no Signage change. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 19:37:11 -05:00
ekklesiaandClaude Opus 5.5	85fae9e07e	feat: Module Package v1 carries the module's own license (ADR 0051) ... Every Module Package v1 now declares the module's license and carries its text. packageFormat stays 1; pre-ADR-0051 metadata fails closed. - Contracts: ekklesia.package.json requires an SPDX `license` expression, validated with spdx-expression-parse, with UNLICENSED and non-expressions refused. The `files` list must hold exactly one non-empty root LICENSE. The package contracts move to the @ekklesia/contracts/module-package subpath, so the SPDX parser and its data (spdx-exceptions and spdx-license-ids ship no licence files) never reach a module bundle through the SDK's re-export of the contracts root. - Packager: reads the source package.json's string SPDX declaration and never invents one. It requires an explicit --license-file (a non-empty regular file, no symlink, no parent search, no download) and copies its bytes unchanged to LICENSE, listed with size and SHA-256 and covered by the archive digest. THIRD_PARTY_NOTICES stays third-party only, and bundled Ekklesia code stays in `incorporates`. - Verifier: rejects missing or invalid license metadata, and a missing, unlisted, duplicated, or corrupted LICENSE, through the schema and the existing strict inventory. - Template: packaged as AGPL-3.0-or-later with the repository's canonical LICENSE, passed explicitly (Dockerfile, smoke, docs). Packing it twice gives byte-identical archives. Started by Codex; reviewed and completed in Claude Code (empty license-text refusal, schema non-empty LICENSE, symlink and empty-file tests). ADR 0051 is Accepted. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 18:51:03 -05:00
ekklesia	1c7755d320	docs: propose ADR 0051 module package licensing	2026-10-07 18:21:51 -05:00
ekklesia	70854d234c	feat: transition module packages to database ABI v1	2026-10-07 18:00:04 -05:00
ekklesia	49b4d4165d	feat: deliver module database ABI by manifest	2026-10-07 17:29:32 -05:00
ekklesia	859675c3c7	feat: add module database ABI v1 adapters	2026-10-07 16:44:28 -05:00
ekklesiaandClaude Opus 5.5	317a4ce410	fix: ADR 0050 callback-error precedence, and the honest limits of transaction control ... Narrow contract and implementation adjustments from review. No SDK, manifest, packaging, or Signage work. Callback-error precedence: - A transaction or savepoint callback that rejects keeps its own error, even while sibling work it started is still settling (one failed half of a Promise.all). Core drains that work, rolls back, and never commits or releases. - A callback that resolves with work outstanding (a forgotten await) still fails with MODULE_DATABASE_SCOPE_WORK_OUTSTANDING and rolls back. Transaction-control SQL: - ADR 0050 forbids it through query() as a conformance rule for trusted code, not a security guarantee. Core does not parse SQL, so PostgreSQL has run the statement before Core sees it. Core detects the violation from the command tag or the transaction status, and claims nothing it cannot do: a module's own COMMIT has committed. - After a violation, the transaction's scopes refuse every later statement without sending it (it would otherwise autocommit). Core never commits the transaction itself, and the connection is destroyed rather than reused, for top-level violations too. - The commit and rollback guarantees apply to conforming use. Duplicate object-mode columns: documented as found only after execution, so a mutation can have taken effect; atomicity needs an ABI transaction. Tests prove each of these against PostgreSQL: Promise.all failures in a transaction and a savepoint keep 23505; a forgotten await still rolls back; a module COMMIT's prior work is committed while nothing after it runs; a backend PID changes after every violation; duplicate RETURNING columns persist at the top level and roll back in a transaction. ADR 0050 stays Accepted: the executor conforms to the revised text. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 16:12:01 -05:00
ekklesiaandClaude Opus 5.5	6db50516b7	feat: Core's Module Database ABI v1 executor, proven against PostgreSQL (ADR 0050) ... Implements the first ADR 0050 slice: Core's ORM-neutral executor and its PostgreSQL evidence. Nothing is wired to modules yet; manifest v8, SDK adapters, schema metadata, packaging, and Signage are later slices. The legacy ModuleDatabase facade is unchanged. Contracts (@ekklesia/contracts, no imports at all): - ABI version 1; query { text, values, rowMode } returning { command, rowCount, rows, fields: [{ name, typeOid }] }; - executor, transaction, and savepoint types with exactly the ABI's members; parameter and result value types; - ModuleDatabaseError { code, sqlState? }: eight stable codes, and a SQLSTATE only when PostgreSQL supplied one; static messages, no cause, frozen; isModuleDatabaseError recognises it by shape. Core (createModuleDatabaseExecutor over the API's existing pool): - one statement per query, enforced by forcing the extended query protocol so PostgreSQL itself refuses a second statement (42601); no SQL parsing; - parameters: null, boolean, number, bigint, string, Uint8Array, and rectangular arrays of them; everything else refused before sending; - a Core-owned decoding table that never consults pg's global parser registry: int8, numeric, temporal, and JSON as exact text; bytea as a plain Uint8Array; built-in arrays element by element; - every operation pins TimeZone, DateStyle, IntervalStyle, bytea_output, and extra_float_digits, then resets with DISCARD ALL before returning the connection, or destroys it when it cannot be reset cleanly; - callback-scoped transactions with explicit isolation and access mode; a COMMIT that PostgreSQL answers with ROLLBACK is reported as failed; - savepoints named by Core; only the innermost scope is active; scopes are revoked when their callback settles; - a callback that settles with work outstanding is rolled back, never committed or released; - transaction-control statements sent through query are refused by command tag and transaction status, and fail the transaction; - the module ID is carried for Core's attribution only. Tests: - 83 integration tests on a database with hostile defaults: queries, the one-statement rule, parameters, decoding, errors, transactions, savepoints, forgotten awaits, pool safety after every failure class, and session state; - unit tests for encoding, decoding, options, sanitization, and scope bookkeeping; - type-level and source checks that no ORM or driver object crosses the boundary. ADR 0050 is Accepted. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 16:01:46 -05:00
ekklesiaandClaude Opus 5.5	11e2495484	docs: ADR 0050, tighten transaction scope, single-statement, and error rules ... Three narrow clarifications to the proposed contract. No other decision changes. - Outstanding work: module code awaits every operation before its transaction or savepoint callback returns. A callback that settles with work outstanding is a scope-usage error and never commits. Core may let started operations settle before rolling back and releasing the connection, but waiting never turns into a commit. Executors stay revoked once their scope has finished. - One statement per query() call: a correctness and API rule, not a security boundary. It is upheld by a reliable driver or protocol mechanism, never a home-grown SQL parser. An implementation that cannot uphold it stops and reports instead of weakening the ADR. - Errors: `code` is a stable Ekklesia-owned category and always present. `sqlState` is optional, present only when PostgreSQL supplied one. ABI-detected failures (closed scope, invalid parameter, invalid option) carry a code and no SQLSTATE. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 15:27:29 -05:00
ekklesiaandClaude Opus 5.5	759872834d	docs: propose ADR 0050, Module Database ABI v1 ... Core and modules exchange PostgreSQL SQL text, bound parameters, result rows with field metadata, and Core-owned transaction scopes. Never ORM objects. A module may use Drizzle, Kysely, raw SQL, or another module-side builder. Core's own ORM becomes an implementation detail. ADR 0050 decides: - an explicit correctness/compatibility boundary, not a security sandbox: no claim for SQL parsing, execution-time prefix checks, SET ROLE, or PostgreSQL roles; - opt-in through manifest version 8 `database.abi: 1`, a hard cutover like every manifest version; a version 8 module without `database` keeps the legacy ModuleDatabase facade during the deprecation window; - the executor: query({ text, values, rowMode }) returning { command, rowCount, rows, fields }, one executor per module; - a small parameter set (no Date, no implicit JSON, no identifiers); - a Core-owned decoding table that loses no precision and does not depend on time zones (int8, numeric, temporal, and JSON as text; bytea as Uint8Array); - a sanitized ModuleDatabaseError { code, sqlState? }, recognised structurally; - callback-scoped transactions and Core-named savepoints, revoked when their callback settles; - module-side adapters (Drizzle via pg-proxy, raw SQL, later Kysely); - plain schema metadata for ABI v1 modules instead of Drizzle objects; - migrations unchanged; packageFormat stays 1; ABI v1 packages omit transitional.databaseRuntime. It partly supersedes ADR 0016 and amends ADR 0007 for ABI v1 modules, and extends ADR 0049. Status Proposed. Accepted ADRs are unchanged. No runtime, SDK, manifest, packaging, migration, or Signage changes. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 15:18:59 -05:00
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	35ef31df9f	feat: Ekklesia Module Package v1, the canonical packager and verifier (ADR 0049) ... A separately versioned module is now distributed as one deterministic .tar.gz and its SHA-256, produced by an Ekklesia-owned packager and checked by Core before anything is installed. This slice implements the portable `any` target, with the module template as the end-to-end proof. ADR 0049 is accepted. @ekklesia/contracts: the Module Package v1 contract. The strict ekklesia.package.json schema (packageFormat 1, identity, target, runtime, provenance, incorporated Ekklesia packages, strict transitional facts, an exact byte-wise-sorted file list with size and SHA-256), target names, and the generated runtime package.json. @ekklesia/module-pack (new, tooling): `ekklesia-pack-module --module <dir> --target any --out <dir> --source-revision <commit>`. - Bundles server, schema, and jobs with esbuild, SDK, contracts, and Drizzle included; only Node built-ins remain imports. Any warning, unresolved import, external dependency, or native or platform-specific package fails. - Copies browser artifacts as built, after proving them current, and the migrations; generates package.json and ekklesia.package.json; never ships src, tests, declarations, source maps, or workspace ranges. - THIRD_PARTY_NOTICES: every third-party package traced from the bundles' own inputs, credited once with its declared licence and every licence, copying, copyright, and notice file it ships. A missing licence fails; a missing text fails unless its standard text is complete without copyright lines (Apache-2.0, vendored, needed by drizzle-orm). - Deterministic ustar and gzip: sorted paths, uid/gid 0, empty names, mtime 0, 0755/0644, no links. Byte-identical across runs and machines. - Writes only the archive and its .sha256; never deploys, links, or installs, so the workspace's install state is untouched. Core: verifyModulePackage and `verify-module-package.js <archive> [--sha256 | --sha256-file] [--extract-to <new dir>]`. Reads the archive in memory and refuses links, special entries, setuid/setgid/sticky modes, unsafe or escaping paths, and a second top-level directory; checks metadata, every file, identity, target, Node.js range, SDK, and the transitional Drizzle agreement; runs the platform's module and migration discovery; loads the backend once in a forked process with an empty environment; only then extracts, with normalized modes, into a new directory. Errors are sanitized. @ekklesia/module-ui-build: analyzeModuleUi reports each artifact's inputs and whether the built file is current. The nested stylesheet build now works from the module directory, so artifacts no longer depend on the caller's working directory. The split deploy smoke builds the package with the canonical packager (scripts/lib/build-module-package.Dockerfile replaces the test-only pnpm deploy packaging), verifies it with the same generic image, installs the verified tree, removes it, and reinstalls the exact same archive. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 12:44:54 -05:00
ekklesiaandClaude Opus 5.5	1119cc5fdf	docs: propose ADR 0049, Ekklesia Module Package v1 ... A separately versioned module is distributed as one immutable, self-contained, deterministic .tar.gz with a separately distributed SHA-256. The package contract is independent of hosting, registry, transport, and marketplace. ADR 0049 extends ADR 0048 with: - the package layout: one top-level module directory with a generated runtime package.json, the unchanged manifest, ekklesia.package.json, bundled backend entrypoints, built browser artifacts, migrations, THIRD_PARTY_NOTICES, and node_modules only for native dependencies; - backend bundling of all pure-JavaScript dependencies, with externals decided and validated by the canonical packager, never by module authors; - targets: `any`, or <platform>-<arch>[-<libc>] (linux-x64-glibc for Signage); - ekklesia.package.json (packageFormat 1): id, version, target, runtime needs, provenance, incorporated SDK versions, a `transitional` Drizzle requirement explicitly not the Module Database ABI, and per-file size and SHA-256; - archive safety: no links of any kind, no absolute or `..` paths, no special files or setuid/setgid; extraction normalizes ownership and modes; - the intended installation lifecycle and its rollback limit: code-only rollback only before new migrations apply, a backup restore after; - integrity, not authenticity; signing and trust roots deferred; - pnpm deploy explicitly not the packaging mechanism. Status Proposed, following the repository's usual lifecycle. ADR 0047 gains a cross-reference to consume canonical packages. The module development guide no longer recommends running pnpm deploy in a workspace, which corrupts that workspace's install state. No runtime, tooling, Docker, CI, Signage, or instance changes. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 10:13:34 -05:00
ekklesiaandClaude Opus 5.5	e36b70d8d4	feat: one generic image, with installed modules in installation-owned storage (ADR 0048) ... The production image now contains zero feature modules and is the same for every installation. Installed modules live in module storage that one Core resolver selects from EKKLESIA_MODULES_DIR: the checkout's modules/ when unset, an absolute path that must exist when set (/var/lib/ekklesia/modules in the image). A relative, blank, missing, or unreadable configured directory fails closed with a sanitized error that never contains the value. - Host configuration reads EKKLESIA_MODULES_DIR. The API, migration plan, apply and validate, module validation, module enablement, and Doctor all resolve it the same way; the test-only API override still takes precedence. - Doctor receives Core's migrations directory explicitly instead of deriving it from the modules directory's parent. - The migration runner retains and reports the applied history of a module that is not installed, and plans and applies Core's and present modules' migrations around it. Core's history and every installed module's history stay strict: a missing or changed applied migration, or a downgrade, still fails. No down migrations, no data deletion. - deploy/Dockerfile copies no module and installs nothing for the module template; .dockerignore excludes modules/ and the build refuses a context that contains it; the runtime has an empty root-owned /var/lib/ekklesia/modules and sets EKKLESIA_MODULES_DIR. - deploy/compose.yaml bind-mounts EKKLESIA_MODULES_HOST_DIR read-only into api and migrate, with create_host_path disabled. - scripts/check-image.sh proves the image holds no modules and that a populated modules/ directory leaves its runtime file system identical; CI runs it. - The split deploy smoke now uses the same generic image: it boots with no modules, installs a self-contained test module packaged from the template (test-only), migrates and restarts, removes it (Core runs, planning reports the retained history, data survives), and restores it with its data. Docs: deploy README (module storage, install/update/remove/restore, the runtime modules target), .env.example, API configuration, module development guide, testing, workflow, security, and the architecture overview. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 08:38:14 -05:00
ekklesiaandClaude Opus 5.5	cefdde36a2	docs: accept ADR 0048, one generic image with installed modules outside it ... Ekklesia produces one platform image with zero feature modules. Installed modules live in installation-owned storage selected by EKKLESIA_MODULES_DIR (/var/lib/ekklesia/modules in the image, <repo>/modules in development), mounted read-only and discovered only at a controlled restart. An installed module directory is self-contained; the platform lends it no dependencies. Uninstall is distinct from disable and purge: removing module code keeps its data and stored state, and applied migration history of an absent module is retained and reported instead of blocking planning. Present modules and Core stay strictly validated. Supersedes in part ADR 0044 (composition from pinned sources) and ADR 0009 (rejection of history absent from the inventory); amends ADR 0006; extends ADR 0028 and ADR 0030. ADR 0047 gains a cross-reference saying it must be revised before acceptance, and deploy/README.md notes that its composition model is being replaced. No code, Dockerfile, Compose, CI, or test changes. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 07:45:21 -05:00
ekklesiaandClaude Opus 5.5	0ec1755279	docs: the server runs Gitea 1.27.2, not 1.24.2; say what it actually honours ... The CI documentation, the workflow header, the README, ADR 0047 and the sweep's comment all said the server was Gitea 1.24.2, which ignores `permissions`, `concurrency` and `timeout-minutes`. The server reports 1.27.2 (GET /api/v1/version). Each claim is now stated from what is verified on this server: - `concurrency` is honoured, observed: Ekklesia runs 133 and 135 were cancelled when a newer run started for the same pull request; - `permissions` is supported by 1.27 with Gitea's own scopes, but the token's actual authority is not visible through the API and not yet proven, so nothing claims the job token is read-only; - `timeout-minutes` is no longer listed as unsupported, but is not verified, and teardown still relies on the stack sweep and a reaper. Requirement 1 for executing untrusted contributions (upgrade to the 1.26 line or later) is marked done; items 2 and 3, configuring and proving token authority, remain. ADR 0047 (still Proposed) restates its "docker run, not a reusable workflow" reasons for 1.27, where private sources are supported. The reasons still hold without the 1.24 argument. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-05 22:11:00 -05:00
ekklesiaandClaude Opus 5.5	62951975da	fix(ci): nothing a CI job starts outlives it, even when the runner kills the job ... A migration-smoke stack (PostgreSQL and SeaweedFS) ran on the shared runner for two days. Every CI script removes its stack in an EXIT trap, but a trap never runs when the runner kills the job container: a cancelled job, or the runner's own time limit (Gitea 1.24 ignores timeout-minutes). Reproduced: SIGKILL of the infrastructure smoke mid-run leaves exactly that stack running. Cleanup now has three layers: - the script's own trap, unchanged; - a final `if: always()` step in every job that starts stacks (infrastructure-smoke, migration-smoke, image-build, deploy-smoke) runs `scripts/ci-sweep.sh --job`, which removes everything that job started at any age; - a first step in each of those jobs runs `scripts/ci-sweep.sh --stale`, which removes CI stacks older than three hours: what a killed job left before it could clean up. How stacks are found is defined once, in scripts/lib/ci-project.sh: - every CI Compose project is named `ekklesia-ci-<run>-<attempt>-<job key>-<kind>-<unique>`, and Compose labels its containers, networks and volumes with that name; - the deploy smoke labels everything it starts outside Compose: browser, kiosk and driver containers, the kiosk volume, built images; - images also record when CI built them. An image's own creation time can be its base's (BuildKit, metadata-only builds), and the sweep removed a brand-new image as "old" until it stopped trusting that. The job key is per matrix leg, so one topology's cleanup cannot remove the other's running stack. The sweep never touches anything outside the ekklesia-ci- prefix, disconnects rather than removes a job container attached to a stack's network, and refuses --job outside CI. Network creation times are read as RFC 3339; Docker's default form was unparseable. scripts/test-ci-sweep.sh proves all of that against real Docker, and CI runs it before relying on it. security.md and testing.md document the rule, and that it complements, not replaces, a runner-side reaper. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-06 02:01:01 +00:00
ekklesiaandClaude Opus 5.5	3a2f5d68f6	docs: ADR 0047, nothing the harness starts outlives its job ... A job the runner kills never runs its own cleanup trap, and the platform's CI leaked a whole migration stack that way. The harness follows the platform's three-layer rule: - everything it starts is named and labeled as a CI stack; - it cleans up in a trap; - the template workflow sweeps stale CI stacks before running it, and removes its own in a final if: always() step. The sweep ships in the harness image. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-05 20:54:38 -05:00
ekklesiaandClaude Opus 5.5	3827841205	docs: propose ADR 0047, a published harness every module runs in CI ... Signage reached production with three defects that appear only inside Ekklesia in a real browser, and no CI that ran it there. The ADR proposes: - a versioned harness image, ekklesia-module-harness:<platform version>, built and pushed by the platform's release CI; - what the harness does: assemble a module into that platform, validate and build it, migrate a disposable database, start the split reference deployment, and mount every declared UI surface in headless Chromium; - what fails it: console errors, unexpected 4xx/5xx, unhandled rejections, a display soak, and generic no-dead-ends injections; - testing at the lowest and newest platform versions of a module's range; - extra smoke steps in ekklesia.harness.json, beside the manifest rather than in it; - a later data-access and egress check against declarations; - a short template workflow that calls the harness by digest with one `docker run`. Not a reusable workflow: thinly supported on Gitea 1.24, and private sources only arrive in 1.26. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-06 01:50:06 +00:00
ekklesiaandClaude Opus 5.5	f63f80f2f0	feat: support split Dashboard and API origins (ADR 0045) ... An installation can now serve the Dashboard and the API on sibling hostnames (dash./api.) beside the default same-origin topology, from one image and with configuration alone. - The Dashboard learns its API origin at run time: the built page carries one empty <meta name="ekklesia-api-origin">, which the API fills with its identity base URL's origin at startup, before computing the page's ETag. The shell accepts only a canonical http(s) origin and otherwise fails closed without making a request. The build-time EKKLESIA_API_BASE_URL is gone from the bundle; the development server injects the same element. - The display host stays on the API's origin, so its device cookies, requests, and offline cache are unchanged. - The API trusts its own origin (trusted origins plus the identity base URL), as Better Auth already does, so the display page's mutations pass the origin check without operators listing it. - Doctor validates EKKLESIA_DASHBOARD_ORIGIN exactly as the API's startup does (it previously skipped it), reports the topology without printing hostnames, and warns when split hostnames are not siblings. - The module UI contract states the CORS header limit (safelisted headers plus Content-Type, safelisted response headers only). - Reference deployment: Caddyfile.split.example (Dashboard hostname serves / and its script; API hostname serves /api/*, /display/*, and the display script; each refuses the other's paths) and EKKLESIA_DASHBOARD_HOSTNAME in the proxy overlay and env examples. - The deploy smoke test runs either topology (CI runs both). The split run installs the module template as a test-only module, checks per-hostname routing and exact CORS, then drives a digest-pinned headless Chromium over the DevTools protocol, with no added dependency: sign-in on the Dashboard hostname, the session cookie host-only on the API hostname, the module UI imported cross-origin and its credentialed request succeeding, the display and its service worker on the API hostname, and sign-out. ADR 0045 is marked Accepted. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-03 14:47:36 -05:00
ekklesiaandClaude Opus 5.5	8ea4d4d2e4	docs: propose ADR 0046, installation-owned branding ... Records a core principle: Ekklesia's branding is never forced on an installation. Anything a member, visitor, or volunteer can see (titles, sign-in and auth screens, emails, display and offline screens, error messages, app names and icons, attribution) is configurable and removable entirely. With no name configured, wording is neutral, so the default names nothing and the rule is testable. Internal identifiers, operator tooling, and developer diagnostics are exempt. Modules follow the same rule. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-03 13:29:11 -05:00
ekklesiaandClaude Opus 5.5	55accd0e65	docs: state exactly what ADR 0045's browser smoke proves ... Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-03 13:29:11 -05:00
ekklesiaandClaude Opus 5.5	a56a853319	docs: propose ADR 0045, split Dashboard and API origins ... Records how an installation runs the Dashboard and the API on sibling hostnames (dash./api.) beside the default same-origin topology, from one image: the API origin reaches the Dashboard at run time in a meta element, the display host stays on the API's origin (device cookies and the offline code cache depend on it), the API trusts its own origin as Better Auth already does, cookies stay host-only, CORS stays narrow and becomes part of the module UI contract, the reference proxy gains per-hostname routing, and the deploy smoke test proves both topologies, the split one in a real browser. Amends ADR 0034 and extends ADR 0044. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-03 13:29:11 -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.5	167b4c4f14	feat(deploy): add the reference deployment Compose project ... Implement ADR 0044's reference deployment as a base Compose file plus overlays, so an installation that already runs a proxy can use the base alone. - compose.yaml: api, postgres, object-storage, and the operator-only migrate (profile ops, plan by default). No published port. api and migrate run init, read-only, tmpfs /tmp, cap_drop ALL, no-new-privileges. postgres is only on the internal data network. - TLS everywhere from one installation-private CA: PostgreSQL TLS 1.3 only, with pg_hba rejecting every non-TLS connection, and the API on verify-full via EKKLESIA_DATABASE_CA (PEM text). SeaweedFS serves S3 over HTTPS (ADR 0030 requires https in production), trusted by the API through NODE_EXTRA_CA_CERTS. No Core change. - compose.proxy.yaml + Caddyfile.example: Caddy pinned by digest, ACME HTTP-01 (DNS-01 documented), routes /, /api/*, /display/*, /assets/* to api and refuses everything else; the storage hostname preserves Host. The API trusts exactly the proxy's fixed /32 on an edge network whose dynamic range excludes the fixed addresses; Caddy overwrites X-Forwarded-For and strips caller-supplied forwarding headers. - compose.tunnel.yaml: cloudflared pinned by digest, token from its own env file; Caddy honors CF-Connecting-IP only from its fixed address. - Four per-service root-owned env files, examples with no values; scripts/init-tls.sh (idempotent, never overwrites a key) and scripts/gen-secrets.sh (prints only). - CI: pnpm deploy:config in ci:verify for all three combinations, and a deploy-smoke job (scripts/smoke-deploy.sh) proving readiness, the Dashboard, signed storage delivery, the client-address chain, initial owner sign-in/out, verify-full database TLS, and Doctor through the proxy, against disposable services. tests/deploy.test.ts pins the structural guarantees. - ADR 0044 (still Proposed) amended to match: API-to-storage HTTPS, DNS-01 needs a custom Caddy build and tunnel-only needs DNS-01, the tunnel's origin TLS settings live in the Cloudflare dashboard, port 80 serves HTTP-01, and secrets are one env file per service. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-01 20:59:38 -05:00
ekklesiaandClaude Opus 5.5	756e9b821c	feat(deploy): add the production container image ... Add deploy/Dockerfile and .dockerignore (ADR 0044): one image for the api service and every operator-run CLI, built from an already-assembled workspace (the platform plus whatever modules/<id> the context holds). - node:24.18.0-trixie-slim pinned by index digest; pnpm via Corepack at the root packageManager version. - Build stage: frozen install, modules:validate, migrations:validate, build. Runtime: production-only node_modules plus every dist/, core migrations, and each module directory, in the repository layout the API and CLIs resolve paths from; root-owned, run as node. - NODE_ENV=production and EKKLESIA_API_HOST=0.0.0.0 inside the image only; the platform default stays 127.0.0.1. Configuration comes only from the environment; no .env enters the context or any layer. - HEALTHCHECK on /api/v1/health/ready with Node's fetch; OCI labels for source, revision, and version. - CI builds the image without modules: build only, no credentials, no push. - deploy/README.md documents the image, the read-only production posture (verified), init: true, and the exact CLI commands. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-01 20:00:43 -05:00
ekklesiaandClaude Opus 5.5	fc422b6d8d	fix(packages): declare runtime imports as production dependencies ... @ekklesia/module-sdk imports drizzle-orm at run time but declared it only as a peer and a development dependency. A workspace package is linked into its consumers as a directory, so its imports resolve from its own node_modules, where a consumer never satisfies a peer; a production install omits development dependencies. In the production image this made every module with a schema fail: the API exited at startup and Doctor reported NOT READY. - Move drizzle-orm to module-sdk's dependencies, keeping the peer. - Move react to @ekklesia/ui's dependencies, keeping the peer. The new guard flags it the same way; it is bundled at build time today, so it was not a live failure. Both lockfile entries keep the identical resolution, so nothing new is installed and the shell bundles still contain one React. - Add the boundary rule runtime-imports-are-production-dependencies: code a package ships (src/, bin/, excluding tests and .d.ts) must declare every runtime import in dependencies or optionalDependencies. Type-only imports are exempt; .tsx/.jsx implies react (automatic JSX runtime). Fixtures cover peer-only, dev-only, JSX, undeclared, and the accepted cases. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-01 19:29:35 -05:00
ekklesiaandClaude Opus 5.5	a12cbe9600	feat(api): serve the built Dashboard from the API origin ... Serve surfaces/shell's built Dashboard from apps/api on the same origin as /api (ADR 0044), exactly as the display host is served: a closed set of files read once at startup, never a static directory, never a path built from request input. - The shell exports @ekklesia/shell/dashboard-assets (the exact built index.html and script URLs), emits the script at assets/ekklesia-dashboard/app.js, and index.html names that absolute path so dev and production serve the same URLs. - GET / and GET /assets/ekklesia-dashboard/app.js answer from a frozen snapshot: no-cache with a strong ETag and 304 on match. Source maps are never served; every other path is the ordinary sanitized 404. - The page sets nosniff, X-Frame-Options: DENY, Content-Security-Policy: frame-ancestors 'none' (that directive only), and Referrer-Policy: no-referrer, on 200 and 304 alike. - A missing or empty shell build fails startup with a fixed DashboardHostAssetError before any module code is imported. - The If-None-Match comparison moves to conditional-request.ts, shared with the display host routes. - The emailed-link token stripping moves from browser/main.tsx into consumeAuthLanding (location and history injected) so it is tested; behavior is unchanged. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-01 17:54:55 -05:00
ekklesiaandClaude Opus 5.5	aaec9789c4	feat(api): add unauthenticated health endpoints ... Add GET /api/v1/health/live and GET /api/v1/health/ready per ADR 0044. - live returns a fixed 200 {"status":"live"} whenever the process serves. - ready returns 200 {"status":"ready"} only when module startup has completed (and shutdown has not begun) and a database ping succeeds within 2s; otherwise a fixed 503 {"code":"NOT_READY"}. - The ping runs on the shared pool as one simple-protocol message with a transaction-local statement_timeout, so PostgreSQL cancels a stalled statement; the pool discards the connection on failure. - At most one ping is ever unsettled: probes share its outcome and, once its deadline passes, answer 503 immediately until it settles. - Both routes set Cache-Control: no-store, accept GET only (405 with Allow: GET otherwise, HEAD included), never resolve a principal, and are mounted in app.ts beside, never inside, /api/v1/modules/. - createApiApp gains a required `health` option; startApi supplies it and clears module readiness when shutdown begins. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-01 16:47:01 -05:00
ekklesiaandClaude Opus 5.5	06e55cebd5	docs: propose ADR 0044 reference deployment; fix manifest version ... Add ADR 0044 (Status: Proposed), the single self-hosted reference deployment composed from pinned sources, and list it in the ADR index. Correct CLAUDE.md, which described manifest v6; the contracts accept only manifestVersion 7 (MODULE_MANIFEST_VERSION in packages/contracts/src/module-manifest.ts). No code changes. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-01 16:08:44 -05:00
ekklesiaandClaude Opus 5	20d5128bad	docs: record the five Phase 8 prerequisites, and report contributions ... Bring the living documentation in line with what the five passes actually shipped, and correct the claims they superseded rather than leaving them to mislead: the module UI context is six members, not five; module styling is compiled CSS, not inline objects only; the strict manifest is version 7. Also close a silent failure the new contribution mechanism introduces. A contribution whose target capability nobody provides — or whose provider moved outside its declared range — is not published, and the manifest is valid and the artifact exists, so an operator sees a screen that renders nothing with no error anywhere. `pnpm modules:validate` now lists each declared contribution with its capability and range and says whether a compatible provider is installed, and Doctor's discovery check reports the same per module. Both derive from the publication registry the API serves from, so neither can disagree with what a running platform would actually publish. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-27 16:16:01 -05:00
ekklesiaandClaude Opus 5	ca3f37d5f9	feat: let a display survive its network — as code, not as authorization ... A display is the one surface expected to outlive its network: a television on a wall in a building whose uplink is a consumer router, with nobody standing in front of it. When that uplink drops and the screen reboots, the browser shows its own error page — not the display shell, not an Ekklesia message, nothing that recovers on its own, because there is no Ekklesia code left running to recover. Cache the shell and the declared code, in a service worker scoped to `/display/`: the page, the host script, the module's display artifact, and every contributed renderer that display actually mounted. All of them are code whose bytes already confer no authority, and all of them are addressed by a URL carrying an exact version. Cache nothing else, ever. Not the descriptor, not `/api/v1/principal`, not a module or platform API response, not the realtime stream, not a pairing exchange, and not any cross-origin request — which is what a signed object-delivery URL is. It is an allowlist rather than a deny list, so the cost of forgetting a new endpoint is that code goes uncached rather than that a permission decision gets stored. The consequence is stated rather than papered over: a display cannot render module content while offline. Mounting needs a descriptor, a descriptor is authorization-bearing, and it is never cached — so a revoked device stays revoked and cached code can never manufacture current authorization. What the cache buys is that a kiosk rebooting mid-outage boots into Ekklesia's own offline state and keeps retrying, that reconnecting mounts with nothing left to download, and that a hiccup fetching 600 KB of artifact after the tiny descriptor already resolved falls back to identical bytes instead of failing the display. Network-first everywhere, so a screen picks up new code the moment the server returns and can never be trapped on an obsolete build — the failure mode a cache-first worker produces on a screen nobody visits. Only a complete same-origin 200 is stored. Cache names carry a policy version and superseded generations are deleted; artifacts are pruned to the current version per module, keeping every artifact belonging to that version because a display artifact and its contributed renderers share one. The worker never caches itself. The page gets a small signal built from two sources, because either alone lies: `navigator.onLine` is optimistic behind a captive portal, and only the worker knows it actually served from cache. A display shows a quiet corner indicator rather than blanking a lobby wall, and resolves its descriptor again by itself when the network returns — nobody presses Retry on a lobby TV. Every caching decision lives in a module that touches no global, so the behaviour is exercised directly rather than through a worker a test runner cannot host. Registration is an enhancement: no service workers, plain HTTP, or a refusing policy all leave a display that works exactly as before. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-27 16:08:34 -05:00
ekklesiaandClaude Opus 5	e36485bf99	feat: let a module route stream an image-sized upload, explicitly and bounded ... ADR 0017 capped a module route at 1 MiB and said large media belonged to a future storage design. That design arrived — ADR 0030 gave modules a bucket, ADR 0031 took Ekklesia out of the read path — and it did not solve the write path: signed write URLs were deliberately declined, so the only way bytes reach a bucket is a module's own route, and a photograph is not 1 MiB. Extend the route contract rather than adding a second HTTP system. A route declares `bodyMode`: `buffered` (the default, and what every existing route already meant) keeps the 1 MiB ceiling and materializes the body before the handler runs; `streamed` raises the ceiling to 32 MiB and counts bytes as the handler consumes them, holding nothing. The mode is explicit rather than inferred from the size, because inferring it would mean an author who raised a limit silently changed how their own handler receives its body and when a 413 can reach their own code. 32 MiB holds one 25 MiB image plus bounded overhead and is also the platform's absolute ceiling: no route in any mode may declare more, and no unbounded option exists in the contract. The unit is one file per request — twenty images are twenty individually bounded requests, and nothing here can express a 500 MiB aggregate whose failure would waste everything already sent. Replace the buffering dependency with the platform's own limiter. A declared Content-Length over the limit is refused synchronously, before authorization and before a byte is read. Buffered mode now counts what actually arrives rather than trusting the header, which closes a gap the previous implementation had. Streamed mode wraps the body in a counting transform; on overflow the stream errors, the source is cancelled, and the response is replaced with the same sanitized 413 even if the handler swallowed the error — a limit a handler can swallow is not a limit. An unread body is cancelled so an abandoned upload releases its socket, and an abort stays an ordinary failed request rather than becoming a 413. Ordering is unchanged and now strictly better: in streamed mode no byte is read until the handler reads it, and the handler runs only after authorization succeeds, so an unauthorized caller cannot push an upload through at all. The live suite uploads a real 25 MiB body over a real socket end to end. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-27 15:57:44 -05:00
ekklesiaandClaude Opus 5	c444ff570b	feat: let one module contribute a browser renderer to another's capability ... The platform has had a complete story for one module using another's *backend* since ADR 0006 — capabilities, versioned ranges, provider registration. It has had none at all for one module using another's *browser* code, and every workaround is wrong in a way that matters: a consumer cannot import a peer module, it cannot re-implement a renderer for a domain it does not own, and a second `entrypoints` role would put the platform in charge of deciding when a slot inside someone else's screen should be filled. Add a generic browser contribution. `manifestVersion: 7` declares one: namespaced id, its own version, a target capability, a compatible range, and one artifact. That is the complete list, and the omissions are the decision — no payload schema, slot, ordering, or rendering hint exists anywhere, so Core cannot learn what a slide is because the declaration cannot express it. Discovery resolves a contribution artifact through the *identical* loop every other compiled entrypoint uses, inheriting the path, containment, symlink, extension, and file-kind checks rather than getting a weaker copy of them. The registry publishes one only when another eligible module provides the target capability within the declared range; otherwise it is absent rather than mounted and broken. `apps/api` serves it as a sibling of the artifact and display routes, with the same policy: three lookup keys, one exact match, one already-validated path, and one indistinguishable 404 for unknown, undeclared, stale, and incompatible alike. A consumer discovers through the host, never through a URL. Its descriptor carries identity, version, and capability; the URL stays server-side and is resolved exactly as `api.request("records")` is. A module can only ever see contributions aimed at a capability it itself provides, and cannot name its way to anything else — a mount for a withheld id fails without fetching. The consumer owns the domain contract entirely. Input is opaque JSON, checked structurally so a Date, a function, a cycle, or `undefined` fails at the boundary rather than vanishing somewhere far from the mistake, and checked for nothing else. A contributed renderer receives its own id and that input: no API client, realtime, principal, configuration, database, storage, or credential. Loading one grants its module nothing. The contribution ABI is versioned separately from the module UI ABI, because the two have different shapes and lifecycles and coupling them would force every module to rebuild whenever either moved. It supports asynchronous readiness, update-without-remount (a screen that remounted per tick would restart animations and reload media), deterministic cleanup in a `finally`, and sanitized failure that never carries the consumer's domain data. Each renderer mounts in its own isolated root with its own stylesheet. The template now declares a contribution, so `pnpm build` exercises the whole authoring path, and the shell suite drives the full relationship — one module discovering, mounting, updating, and unmounting another's React renderer with neither importing the other. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-27 07:47:10 -05:00