ekklesia
df2af0a3e0
Two related fail-closed gaps let a well-formed but never-declared permission id slip through: - POST /api/v1/grants created explicit grants for any well-formed PermissionId without checking the injected permission registry, allowing dormant grants for invented identifiers that could become effective the moment those identifiers were registered later. - createAuthorizationEvaluator validated the permission id only inside the restricted-baseline branch, so a malformed permission combined with the public or authenticated baseline could still return allowed. Both now fail closed: the grants route checks the target permission against the trusted registry before calling store.createGrant (sanitized 403, no store or audit write), and the evaluator validates permission shape before any baseline is allowed to return an allowed decision, without adding a registry dependency to the evaluator itself. The live integration lifecycle test switched from an unregistered calendar.events.read to the registered core.authorization.grants.manage permission, since module permission registration does not exist yet.
Architecture decision records
ADRs capture durable choices that affect more than one package or phase.
- Filenames use a four-digit sequence followed by a short kebab-case title.
- Status is
Proposed,Accepted,Superseded, orRejected. - Accepted ADRs are immutable except for status and cross-reference corrections.
- A changed decision receives a new ADR that links to and supersedes the old one.
Index
- 0001: Four-layer platform boundary — Accepted
- 0002: pnpm workspace and strict TypeScript — Accepted
- 0003: Development infrastructure — Accepted
- 0004: Replace unmaintained MinIO baseline — Accepted
- 0005: Static module manifests and atomic discovery — Superseded
- 0006: Versioned capabilities and compiled module runtime — Accepted
- 0007: Module-owned Drizzle schemas and table isolation — Accepted
- 0008: Module-owned migration contracts and offline validation — Accepted
- 0009: Transactional module migration execution — Accepted
- 0010: Core identity architecture and Better Auth adoption — Accepted
- 0011: Identity HTTP transport and public enrollment policy — Accepted
- 0012: Production-equivalent identity origin/CSRF protection under test — Accepted
- 0013: Core authorization, permission registry, and platform-owner bootstrap — Accepted