Zayin/Ekklesia
3
0
Fork 0
Code Issues 1 Pull Requests 3 Actions Packages Projects Releases 8 Wiki Activity

feat: expose core identity transport
CI / verify (pull_request) Successful in 27s
Details
CI / infrastructure-smoke (pull_request) Successful in 19s
Details
CI / migration-smoke (pull_request) Successful in 26s
Details

Browse Source
This commit is contained in:
ekklesia
2026-07-21 19:15:14 -05:00
parent 82fe338a8d
commit 91d8f5946f
33 changed files with 2672 additions and 224 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture/platform-architecture.md
+19 -8
View File
@@ -78,18 +78,29 @@ definition entrypoints, which the module contract requires to be side-effect-fre
imports or starts module server entrypoints. It does not apply migrations or modify PostgreSQL, and
it honestly skips object storage because no production Core storage service exists yet.
Phase 4A adds the Core identity foundation. Core owns a Better Auth-backed identity schema
Phase 4A added the Core identity foundation. Core owns a Better Auth-backed identity schema
(`ekklesia_core_user`, `ekklesia_core_session`, `ekklesia_core_account`,
`ekklesia_core_verification`) reachable only through Ekklesia-owned contracts and an explicit
Core-owned Better Auth construction boundary; modules never import Better Auth or receive a raw
database client. That schema ships as a first-class Core-owned migration source that reuses the
exact migration format, checksum rule, planner, and transactional runner Phase 3 already
established, ordered before module migrations in the same aggregate. See
[ADR 0010](decisions/0010-core-identity-and-better-auth-adoption.md) and
[the identity development guide](../development/identity.md). Phase 4A does not mount an HTTP
handler or expose a sign-in endpoint; no user can authenticate yet.
[ADR 0010](decisions/0010-core-identity-and-better-auth-adoption.md).
The next architectural phase is identity HTTP transport and an explicit enrollment policy. Other
target architecture not yet implemented includes production approval-provider composition,
permission enforcement, physical storage-bucket provisioning, Surface SDK, richer public resource
and action contracts, API server, dashboard, Builder, and reference feature modules.
Phase 4B adds identity HTTP transport: a minimal Hono-based `apps/api` composition root mounts
Better Auth at `/api/auth/*` and exposes one Ekklesia-owned route, `GET /api/v1/principal`, behind
Core's own Fetch-compatible identity runtime (`@ekklesia/core/identity`) — Core still does not
depend on Hono. Public email/password registration is intentional; every account receives
identical lowest-privilege baseline status, and signup order never grants elevation. See
[ADR 0011](decisions/0011-identity-http-transport-and-public-enrollment.md) and
[the API guide](../development/api.md), and
[the identity development guide](../development/identity.md) for the underlying schema and
contracts. It is now possible to publicly register, sign in, resolve a principal, and sign out; it
is not yet possible to verify an email, recover a password, reach a Dashboard, or hold any role or
permission.
The next architectural phase is Phase 4C: Core authorization (public / authenticated-baseline /
relationship-derived / grants / platform-owner) and an explicit, auditable platform-owner bootstrap
command. Other target architecture not yet implemented includes production approval-provider
composition, physical storage-bucket provisioning, Surface SDK, richer public resource and action
contracts, dashboard, Builder, and reference feature modules.