248 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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	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
The_River	505c9e8c0a	Merge pull request 'Fix native package verification on hardened noexec /tmp' (#88) from fix/verifier-exec-scratch into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/88 Reviewed-by: The_River <[email protected]>	2026-10-09 23:36:11 +00:00
ekklesia	4be046c8d0	fix: support native package verifier scratch	2026-10-09 18:05:04 -05:00
The_River	c5a6cdaf6a	Merge pull request 'chore(release): prepare 0.2.2' (#87) from chore/release-0.2.2 into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/87 Reviewed-by: The_River <[email protected]> v0.2.2	2026-10-09 22:07:46 +00:00
ekklesia	c4fded6ecf	chore(release): prepare 0.2.2	2026-10-09 16:55:18 -05:00
The_River	9ad2d5b564	Merge pull request 'feat: corresponding-source artifacts for native packages that redistribute copyleft code (ADR 0055)' (#86) from feat/corresponding-source into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/86 Reviewed-by: The_River <[email protected]>	2026-10-09 04:34:50 +00: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
The_River	4919db6168	Merge pull request 'chore(release): prepare 0.2.1' (#85) from chore/release-0.2.1 into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/85 Reviewed-by: The_River <[email protected]> v0.2.1	2026-10-09 03:00:59 +00:00
ekklesiaandClaude Opus 5.5	6e76293620	chore(release): prepare 0.2.1 ... Every platform workspace package and every public @ekklesia/* package declares 0.2.1, and the deploy README's image build example names it. templates/module and the fixture modules keep their own versions. 0.2.1, a patch: since v0.2.0 (1788d17), main has one change, #84. It adds the reviewed supplement for @img/[email protected] and moves the packager's native proof to sharp 0.35.5. That is new packager data and test-only dependencies. No SDK, manifest, database ABI, packageFormat, or package API changed. The standalone fixture consumes exactly this release: its @ekklesia ranges become ^0.2.1 and its module-pack pin 0.2.1 (docs/development/releases.md, step 1). Module compatibility ranges stay ^0.2.0, as the release guide says a patch version requires. The template, the standalone fixture, the native proof module, and the test fixtures modelling the current platform are therefore unchanged. A module built for 0.2.0 remains compatible with 0.2.1. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 21:45:13 -05:00
The_River	3b54a7f023	Merge pull request 'feat: reviewed libvips 1.3.4 supplement, and the native proof on sharp 0.35.5' (#84) from feat/libvips-1.3.4-supplement into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/84 Reviewed-by: The_River <[email protected]>	2026-10-09 02:43:21 +00: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
The_River	1788d17f0a	Merge pull request 'fix: hand npm the release artifact's absolute path, so publishing finds it' (#83) from fix/publish-absolute-artifact-path into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/83 Reviewed-by: The_River <[email protected]> v0.2.0	2026-10-08 23:22:00 +00: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
The_River	debb8df3ce	Merge pull request 'chore(release): prepare 0.2.0' (#82) from chore/release-0.2.0 into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/82 Reviewed-by: The_River <[email protected]>	2026-10-08 22:36:19 +00: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
The_River	22404ea2d4	Merge pull request 'feat: publish the exact @ekklesia package train to the npm registry (ADR 0053)' (#81) from feat/package-train-publication into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/81 Reviewed-by: The_River <[email protected]>	2026-10-08 16:31:57 +00: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	1f30c86d4f	fix: hand the proven release train on from a directory the artifact actions upload ... The CI package-release gate passed, but the upload found no files: the artifact actions leave hidden files out, and .package-release starts with a dot. Keep the release in package-train instead, in both workflows, and test that no artifact path is hidden. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-08 09:56:06 -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
The_River	57df2e15f2	Merge pull request 'feat: the public @ekklesia package release train, built, reproduced, and proven (ADR 0053)' (#80) from feat/public-package-release-train into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/80 Reviewed-by: The_River <[email protected]>	2026-10-08 13:53:41 +00: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
The_River	7ea2d7883f	Merge pull request 'feat: standalone module-build readiness for the public @ekklesia packages (ADR 0053)' (#79) from feat/standalone-module-build into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/79 Reviewed-by: The_River <[email protected]>	2026-10-08 12:48:07 +00: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
The_River	9426c83109	Merge pull request 'docs: propose ADR 0053, standalone module builds from Ekklesia packages over the npm registry protocol' (#78) from docs/adr-0053-module-package-distribution into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/78 Reviewed-by: The_River <[email protected]>	2026-10-08 02:10:19 +00: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
The_River	5803757153	Merge pull request 'feat: native linux-x64-glibc module packages and reviewed license supplements (ADR 0049, ADR 0052)' (#77) from feat/native-targets-license-supplements into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/77 Reviewed-by: The_River <[email protected]>	2026-10-08 01:29:37 +00: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
The_River	f53506b3f0	Merge pull request 'docs: propose ADR 0052, reviewed license supplements for redistributed dependencies' (#76) from docs/adr-0052-license-supplements into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/76 Reviewed-by: The_River <[email protected]>	2026-10-08 00:47:12 +00: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
The_River	104a5145c8	Merge pull request 'test: give Core's import-safety tests a timeout that holds under full verify load' (#75) from test/import-safety-timeouts into main ... Reviewed-on: https://git.riverofglorymn.org/River_of_Glory_Church/Ekklesia/pulls/75 Reviewed-by: The_River <[email protected]>	2026-10-08 00:18:06 +00:00
ekklesiaandClaude Opus 5.5	796ad4f16e	test: give Core's import-safety tests a timeout that holds under full verify load ... Four Core tests prove that importing a module has no side effects. Each one does a cold dynamic import() of a large Core source graph inside its test body: - doctor-import - module-http-import - cli-bootstrap-platform-owner - cli-create-initial-owner (its first test) Vitest transforms and evaluates that graph on demand, so the CPU-bound cost counts against the default 5 s per-test timeout. Ordinary test files import at the top level, outside any test timeout. There is no subprocess, shared resource, or test bug. Measured on six cores: - alone: 0.7–1.2 s; - alongside five other packages' suites, as in a full pnpm verify: 3.0–5.4 s (doctor-import reached 5,400 ms). A shared IMPORT_SAFETY_TEST_TIMEOUT_MS of 30 s (core/tests/support/ import-safety.ts) now applies to exactly these four tests. That is about five times the slowest time measured under load, the same as the repository's integration-test timeout, and still bounded, so an import that genuinely hangs fails. Assertions, coverage, the global Vitest timeout, parallelism, and production code are unchanged; there are no retries. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-07 19:08:30 -05:00