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

docs: correct module authorization comments
CI / verify (pull_request) Successful in 26s
Details
CI / infrastructure-smoke (pull_request) Successful in 20s
Details
CI / migration-smoke (pull_request) Successful in 27s
Details

Browse Source
This commit is contained in:
ekklesia
2026-07-24 17:59:48 -05:00
parent 9fa051be61
commit 510d76f7c2
4 changed files with 27 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
core/src/authorization/permissions.ts
+10 -8
View File
@@ -46,9 +46,10 @@ export class PermissionRegistryError extends Error {
* Builds an immutable permission registry from a fixed list of declarations, rejecting any
* duplicate permission id outright at composition time. Deliberately the smallest mechanism that
* distinguishes "registered" from "well-formed": no module discovery, no dynamic registration, no
* network or filesystem I/O — a future module registration mechanism can merge its own
* declarations into a combined list and still call this same constructor, inheriting duplicate
* detection for free instead of reimplementing it.
* network or filesystem I/O. The module integration layer's composer
* (`composePlatformPermissionRegistry`, `core/src/modules/permissions.ts`) merges Core's own
* declarations with every discovered module's into one combined list and calls this same
* constructor, inheriting duplicate detection for free rather than reimplementing it.
*/
export function createPermissionRegistry(
declarations: readonly PermissionDeclaration[],
@@ -98,11 +99,12 @@ export const CORE_PERMISSION_DECLARATIONS: readonly PermissionDeclaration[] = Ob
]);
/**
* Core's own permission registry — the trusted source of truth `apps/api`'s authorization
* enforcement consults so an HTTP route can never supply its own baseline. Contains exactly the
* one Core-owned permission this slice needs; a future module registration mechanism is
* deliberately out of scope here and will compose its own declarations through
* `createPermissionRegistry` rather than through this constant.
* Core's own permission registry, containing exactly the Core-owned permissions declared above.
* Production `apps/api` does not consult this constant directly: it enforces requests against the
* composed platform registry (`composePlatformPermissionRegistry`,
* `core/src/modules/permissions.ts`), which merges these same declarations with every installed
* module's. `CORE_PERMISSION_REGISTRY` remains for Core-only callers and tests that need Core's
* permissions in isolation, without composing in any module.
*/
export const CORE_PERMISSION_REGISTRY: PermissionRegistry = createPermissionRegistry(
CORE_PERMISSION_DECLARATIONS,