12 Commits

Include renames

Author	SHA1	Message	Date
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	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	5abc8be167	chore(release): prepare 0.1.2 ... Every workspace package declares 0.1.2, as the 0.1.1 release did for itself, and the deploy README's build example names it. The tag v0.1.2 created on 12dca3e carries package.json 0.1.1, which the instance's assemble.sh refuses ("its tag and package.json disagree"), and the running platform would report 0.1.1. 0.1.2 carries what the first production deployment found: - #57: Doctor checks the client-address configuration the API runs; - #58: storage over HTTP/1.1 (repeat image loads no longer fail with ERR_HTTP2_PROTOCOL_ERROR), and storage CORS owned by the proxy; - #60: CI stacks never outlive their job; - #56: display-device smoke scenarios; - #59, #61: ADR 0047 proposed, and the CI documentation corrected for Gitea 1.27.2. templates/module keeps its own version. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-05 22:56:35 -05:00
ekklesiaandClaude Opus 5.5	e1ac1da416	fix(deploy): reach storage over HTTP/1.1, and own storage CORS in the proxy ... Every reload of a cached files. image failed in the browser with ERR_HTTP2_PROTOCOL_ERROR. A browser revalidates a cached signed URL with If-None-Match. Caddy reached SeaweedFS over HTTP/2, and there SeaweedFS answers with a 304 declaring content-type: application/xml and content-length: 327 while sending no body. Caddy then logged "aborting with incomplete response ... unexpected EOF" and reset the stream. Over HTTP/1.1 SeaweedFS's 304 is clean. Measured layer by layer: DevTools, curl through Caddy, and curl direct over HTTP/1.1 and HTTP/2. The storage upstream is now HTTP/1.1 only (`versions 1.1`). Browsers still reach the proxy over HTTP/2 and HTTP/3. Delivery-layer CORS is the deployment's, so it no longer depends on which S3 backend is behind it. SeaweedFS's default reflected any origin and advertised PUT, POST and DELETE. Now the proxy: - grants CORS only to the origins that read objects with fetch(): the Ekklesia origin, or, when split, the API origin (displays) and the Dashboard origin (a module's preview caches images through fetch()); - allows GET and HEAD only, with Vary: Origin; - answers preflights itself, so they never reach storage; - strips the object store's own CORS headers. The deploy README documents the policy, its reasons, and what a self-run proxy must do. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-06 01:19:17 +00:00
ekklesiaandClaude Opus 5.5	f1d6501239	fix(deploy): give migrate the API's client-address settings, and say what Doctor checked ... Doctor checks the client-address configuration of the process it runs in, and operators run it as `migrate`. The proxy overlay set trusted-proxy mode on `api` only, so Doctor reported "Direct client-address mode" for an installation that trusts its proxy. - compose.proxy.yaml defines the three variables once, as a YAML anchor, and applies it to both `api` and `migrate`. Rendered with `docker compose config`, `api` is unchanged and `migrate` now matches it, keeping NODE_EXTRA_CA_CERTS from the base. - The example deploy/.env sets COMPOSE_FILE=compose.yaml:compose.proxy.yaml, as the instance already does. Plain `docker compose run --rm migrate ...` in the README then runs with the overlay; it used to read compose.yaml alone. - Every client-address check in Doctor now says it checked the environment Doctor runs with, and how to read the running API's own value (`docker compose exec api printenv EKKLESIA_CLIENT_ADDRESS_MODE`, confirmed to work in the image). - The deploy README explains why operator commands need the same files as the stack. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-06 00:42:38 +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	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	e12ef10a65	docs(deploy): explain the warm-cache image size variance ... Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-01 20:06:08 -05:00
ekklesiaandClaude Opus 5.5	4468335e8f	build(deploy): run pnpm boundaries in the image build stage ... A module that imports a package at run time without declaring it a production dependency now fails the image build instead of the API's startup, since the runtime receives production dependencies only. Co-Authored-By: Claude Opus 5.5 <[email protected]>	2026-10-01 20:01:02 -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