chore: establish Ekklesia platform foundation

2026-07-12 20:28:19 -05:00
commit 192a6514cf
47 changed files with 2505 additions and 0 deletions
@@ -0,0 +1,34 @@
+# 0001: Four-layer platform boundary
+
+- Status: Accepted
+- Date: 2026-07-12
+
+## Context
+
+Ekklesia must remain understandable and independently extensible after many backend capabilities
+and user experiences have been added. A conventional feature monolith or UI-bearing plugin model
+would couple business behavior to a particular presentation framework.
+
+## Decision
+
+Adopt four explicit ownership layers: Core orchestration, backend Modules, presentation Surfaces,
+and declarative Surface Builder configuration. Begin as a modular monolith. Modules expose data
+and behavior only; every renderer and UI concern belongs to a surface.
+
+## Alternatives
+
+- A conventional feature monolith was rejected because boundaries degrade as features grow.
+- UI-bearing plugins were rejected because they bind capabilities to frameworks and visual design.
+- Initial microservices were rejected because distribution adds failure modes before contracts
+  have been proven.
+
+## Consequences
+
+Stable contracts, SDK ports, generated composition, and automated boundary checks are required.
+Some integrations take more deliberate service or event design, but modules and surfaces remain
+independently replaceable.
+
+## Migration implications
+
+Future boundary violations must move behind public contracts before the affected package can be
+treated as independently installable or upgradeable.