Signage no longer needs an Ekklesia checkout. A clean clone installs with
`pnpm install --frozen-lockfile` and runs lint, typecheck, test, build, and validate by itself, taking
Ekklesia's module-development packages from Ekklesia's public registry (ADRs 0053 and 0054).
- Dependencies: every `workspace:*` becomes `^0.2.0`. @ekklesia/module-pack is added as a
devDependency pinned exactly to 0.2.0, as ADR 0053 requires; it is not invoked yet. No
@ekklesia/contracts dependency. drizzle-orm stays a direct dependency, satisfying the adapter's
optional peer.
- .npmrc points the @ekklesia scope at
https://git.riverofglorymn.org/api/packages/River_of_Glory_Church/npm/ with no credential, because
reading needs none.
- pnpm-workspace.yaml holds this repository's pnpm settings only:
- `allowBuilds: esbuild: true`, as the platform's standalone fixture does;
- exact-version minimumReleaseAgeExclude entries for the 0.2.0 train, which pnpm 11 otherwise holds
back on its release day;
- the platform's narrowly scoped override for GHSA-67mh-4wv8-2f99 (esbuild via drizzle-kit), which
Signage inherited while it built inside Ekklesia's workspace.
- engines.node `>=24.11.0 <25` and packageManager `[email protected].0`, both from Ekklesia 0.2.0. Node
24.18.0 goes in .node-version for CI, as in Ekklesia.
- biome.json carries the platform's Biome configuration, which `biome lint` used to pick up from the
workspace root, so lint rules are unchanged.
- pnpm-lock.yaml is Signage's own: registry tarballs with integrity hashes, and no workspace or file
links.
- `prepack` runs this package's own build instead of the workspace root's turbo.
- `pnpm validate` (scripts/validate-module.mjs) checks the built package and its migrations with the
published SDK parsers only:
- the manifest, its identity, and its entrypoints;
- that the built runtime's id, version, and database ABI match the manifest;
- that the built schema metadata is plain, namespaced, and has module-internal foreign keys;
- the SDK compatibility range;
- that the migration journal and policy agree.
Core's own `modules:validate` and `migrations:validate` are not published. What only an Ekklesia
installation can check is named in the script.
Removed: ci/assemble.sh, ci/platform.env, ci/pnpm-lock.yaml, ci/update-lock.sh. The lint, typecheck,
test, and build jobs check out only this repository; build also runs `pnpm validate`. The integration
job stays disabled. Its first step is now an explicit placeholder rather than the deleted assembly,
and its explanation says it returns when Signage is a canonical linux-x64-glibc Module Package
installed into Ekklesia's generic image.
No source, behaviour, schema, or version change: Signage stays 0.1.2.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The platform's rule (its ci-sweep.sh, docs/development/security.md),
applied to the one Signage job that starts Docker stacks:
- it has its own EKKLESIA_CI_JOB_KEY;
- it sweeps stale CI stacks from the runner before it starts;
- it removes its own stacks in a final `if: always()` step, which
tolerates a failed assembly, since nothing was started then;
- the image ci/integration.sh builds is named and labeled as a CI stack
of this run and job, with the time CI built it, so the sweep finds it.
ci/platform.env moves to the platform commit that adds the sweep
(Ekklesia #60). The assembled lockfile is unchanged, and still passes a
frozen install.
Verified: SIGKILL of the integration script's whole process group
mid-run left 11 resources (2 containers, 4 networks, 4 volumes and the
image). `ci-sweep.sh --job` removed exactly those 11. A normal run
passes, and the job sweep after it finds nothing.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Signage had no CI. Its tests passed while three defects shipped that
appear only inside Ekklesia, in a real browser. Every job now assembles
Signage into a pinned platform commit, as an instance does, and
installs that workspace with --frozen-lockfile:
- lint, typecheck, test: Signage's own checks;
- build: the platform's gates against exactly this module set (boundary
rules, module manifest, migrations), then the build;
- integration: the deployment image from the platform's Dockerfile,
then the platform's split-topology smoke. It pairs a kiosk display,
restarts it on the same profile, and runs the scenarios in
ci/display-scenarios.
The supporting files:
- ci/platform.env pins one platform commit. ci/assemble.sh fetches the
platform's main and refuses a pinned commit that is not on it, so CI
only runs reviewed platform code.
- ci/pnpm-lock.yaml is the assembled workspace's lockfile, regenerated
with ci/update-lock.sh.
Same trust rules as the platform: actions pinned by SHA,
persist-credentials false, no secrets, no pull_request_target.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
ekklesia