Zayin/Ekklesia

Fork 0

Files

T

History

ekklesiaandClaude Opus 5 baa689b2a7

CI / verify (pull_request) Successful in 35s

Details

CI / infrastructure-smoke (pull_request) Successful in 21s

Details

CI / migration-smoke (pull_request) Successful in 46s

Details

feat: add the module configuration and secrets contract

Modules had no way to be told anything. Announcements — the first real
product Ekklesia will absorb — has zero environment variables and compiles
a LAN IP address into its source, so this is the contract standing between
it and the module system.

- A module declares what it needs in its manifest, using six bounded types
  (string, integer, boolean, enum, url, secret) with no nesting and no
  regular expressions. Static declaration is what lets the platform validate
  configuration *before* deciding whether a module may start: an enabled
  module missing a required value is reported `blocked ·
  configuration_missing · <key>` rather than taking startup down from inside
  its own `start` hook, and Doctor reports the same while still importing no
  module code. That forces `manifestVersion: 5`, a hard cutover.
- Ordinary values persist in one Core table (migration 0005), one row per
  (module_id, key), stored as text until validated against the declaring
  module's current manifest. Nothing is coerced; an invalid stored value
  blocks the module rather than falling back to the default. A key the
  manifest no longer declares is retained and ignored.
- Secrets are never persisted. There is no encryption at rest in this
  repository, so a `secret` key is deployment-supplied and mapped in by the
  host under a name the module never sees. A secret declaration has no
  `default` field, the write API refuses secret material, and the HTTP view
  has no `value` field for one — absent by construction, not filtered.
- Modules receive a frozen `context.config` on the registration, runtime,
  and HTTP handler contexts: the same object identity, per module, beside
  `services` rather than inside it (services is deliberately one shared
  instance). No environment access, no database reference, no way to reach
  another module's values.
- Configuration decides eligibility through ADR 0028's existing resolver:
  three new blocked reasons, each with a distinct operator fix, propagating
  to required dependents through the same mechanism as a disabled module.
- Changes take effect at the next restart; both resources report
  restartRequired. New restricted permission
  `core.modules.configuration.manage`, separate from lifecycle, at the
  sibling prefix `/api/v1/module-configuration`.
- Migration participation stays independent of configuration validity.
  Endpoints and credentials for shared infrastructure stay platform
  concerns; a module declares which bucket it needs, not an S3 endpoint.

See ADR 0029.

Co-Authored-By: Claude Opus 5 <[email protected]>

2026-08-22 21:44:43 -05:00

drizzle

feat: add module migration contracts and validation

2026-07-21 08:09:30 -05:00

src

feat: add the module configuration and secrets contract

2026-08-22 21:44:43 -05:00

tests

feat: add the module configuration and secrets contract

2026-08-22 21:44:43 -05:00

drizzle.config.ts

feat: add module migration contracts and validation

2026-07-21 08:09:30 -05:00

ekklesia.module.json

feat: add the module configuration and secrets contract

2026-08-22 21:44:43 -05:00

package.json

feat: build module UI into its declared browser artifact

2026-08-21 21:24:18 -05:00

README.md

feat: build module UI into its declared browser artifact

2026-08-21 21:24:18 -05:00

tsconfig.build.json

feat: add module contracts and discovery

2026-07-12 22:14:01 -05:00

tsconfig.json

feat: build module UI into its declared browser artifact

2026-08-21 21:24:18 -05:00

tsconfig.ui-test.json

feat: build module UI into its declared browser artifact

2026-08-21 21:24:18 -05:00

tsconfig.ui.json

feat: build module UI into its declared browser artifact

2026-08-21 21:24:18 -05:00

README.md

Ekklesia module template

This is the smallest supported backend-only Ekklesia module. It proves the static manifest, compiled runtime and schema entrypoints, capability registration, a module-owned Drizzle table, a generated module-owned migration, logical storage-bucket declarations, and one permissioned HTTP route (GET /records, declared in register) that reads that table through context.services.database — the platform-provided ModuleDatabase facade, never a module-constructed Drizzle instance or a raw pg client. Migration execution and storage provisioning are intentionally not included.

It also ships an optional React UI (src/ui/), compiled to the entrypoints.ui artifact its manifest declares by pnpm build (ADR 0023). UI is a choice, not a requirement: to keep a module backend-only, delete src/ui/, tsconfig.ui.json, tsconfig.ui-test.json, tests/module-ui.test.ts, the ui entrypoint from the manifest, and the React and module-UI dependencies. Everything else keeps working, and ekklesia-build-module-ui simply reports that there is nothing to build.

No host mounts a module UI yet — the Dashboard shell does not exist. tests/module-ui.test.ts builds the artifact from source, validates it with parseModuleUiExport, mounts it into a real DOM, and unmounts it, which is what proves the pipeline today. See Declaring a UI entrypoint.

To create a module inside this repository:

Copy this directory to modules/<module-id>.
Rename the package in package.json and remove private when it is ready for publication.
Update the ID, name, version, namespaces, compatibility ranges, and bucket requests in ekklesia.module.json.
Keep the manifest capability versions and dependency ranges aligned with the contracts the module actually implements and consumes.
Replace src/server/index.ts with backend behavior only. Its defineModuleRuntime ID and version must match the manifest; do not duplicate the rest of the manifest in TypeScript. Declare HTTP routes only in register, against a permission the manifest already declares; start, stop, and every route handler — never register — receive context.services.database, a typed ModuleDatabase view over the platform's one PostgreSQL pool.
Replace the pure Drizzle declarations in src/schema/tables.ts and keep its table prefix aligned with the module ID. Keep the defineModuleSchema ownership wrapper in src/schema/index.ts aligned too, and never import another module's schema.
Update drizzle.config.ts, generate forward migrations with pnpm migration:generate --name=lowercase_name from the module directory, and review the SQL. Keep each generated tag in drizzle/meta/_ekklesia.json, classify it as none or approval-required, and change that file's moduleId when renaming the template.
Run pnpm install, pnpm build, pnpm modules:validate, pnpm migrations:validate, and pnpm verify from the repository root. The declared production entrypoint is the compiled dist/server/index.js, not source TypeScript; the schema entrypoint is likewise compiled to dist/schema/index.js.

Do not add UI components, styles, renderers, navigation, or layouts. Those belong to surfaces. Keep imports side-effect-free, register capabilities in register, acquire resources in start, and release them in stop. Never construct a Drizzle instance, read DATABASE_URL, or reach for a raw pg client — context.services.database is the only supported way to query this module's own tables, and it is never available during register.

The migration directory uses the pinned stable Drizzle Kit 0.31.10 PostgreSQL journal and snapshot format. Migrations are forward-only and may modify only this module's objects. Offline validation treats SQL as opaque bytes, calculates SHA-256 from the exact contents, and never opens a database or executes SQL. Destructive declarations are review metadata, not automatic SQL classification or approval.