feat: transition module packages to database ABI v1
CI / verify (pull_request) Successful in 1m1s
CI / infrastructure-smoke (pull_request) Successful in 36s
CI / migration-smoke (pull_request) Successful in 1m54s
CI / image-build (pull_request) Successful in 31s
CI / deploy-smoke (same-origin) (pull_request) Successful in 52s
CI / deploy-smoke (split) (pull_request) Successful in 1m32s

This commit is contained in:
ekklesia
2026-10-07 18:00:04 -05:00
parent 20ad1ae208
commit 70854d234c
20 changed files with 274 additions and 115 deletions
+11 -9
View File
@@ -4,9 +4,10 @@ This is the smallest supported Ekklesia module product. It proves the static man
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.
`@ekklesia/module-database/drizzle` over the platform-provided ABI-v1 executor. Drizzle stays a
module-side implementation detail; Core receives SQL and bound values, never the module's ORM
objects, a raw `pg` client, or connection configuration. Migration execution and storage provisioning
are intentionally not included.
It also ships two independently optional React roles: a primary/management UI at `src/ui/index.tsx`
and a full-viewport display at `src/display/index.tsx`. One invocation of `pnpm build` compiles each
@@ -40,10 +41,11 @@ To create a module inside this repository:
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.
Module Database ABI-v1 executor. Adapt it with `moduleDrizzle`; do not pass ORM objects to Core.
6. 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.
with the module ID. Keep `moduleDrizzleSchemaMetadata` in `src/schema/index.ts` aligned too; it
exports plain ownership and foreign-key metadata, never ORM objects. Never import another
module's schema.
7. 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
@@ -72,9 +74,9 @@ surfaces and Core. A module UI asks its host for relative API paths and realtime
hardcodes Ekklesia routes. The display permission is enforced by the host before it serves the page
or descriptor; `context.permissions` remains a presentation-only hint.
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`.
and release them in `stop`. Construct Drizzle only through the module-side ABI adapter; never read
`DATABASE_URL` or reach for a raw `pg` client. `context.services.database` is the only supported
executor for 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