Ekklesia/CLAUDE.md

CLAUDE.md

Guidance for Claude Code (and other coding agents) working in this repository. This file is intentionally short and durable — it points at authoritative sources instead of restating their contents, because restated details drift.

What this repository is

Ekklesia is a modular, self-hosted church platform built as a strictly layered pnpm/TypeScript monorepo:

• Core (core/) owns platform infrastructure: identity, database connectivity, migration execution, module discovery/lifecycle, and other feature-agnostic services. Core never imports a feature module, a surface, or an app.
• Modules (modules/*, template at templates/module) are backend-only capability packages. They own their own data and migrations, declare capabilities/permissions through @ekklesia/contracts and @ekklesia/module-sdk, and must never contain UI or import Core, another module, or a surface directly.
• Surfaces (future surfaces/*) own all UI and presentation. They consume public API/client contracts only, never Core or module internals directly.

These boundaries are enforced by pnpm boundaries (scripts/check-boundaries.ts), not just documented. Read docs/architecture/repository-boundaries.md and docs/architecture/platform-architecture.md before proposing any change that crosses a layer.

ADRs are authoritative

docs/architecture/decisions/ records durable architectural decisions. Accepted ADRs are immutable except for status and cross-reference corrections — do not edit their content to fit a new change. A changed decision gets a new ADR that supersedes the old one. Read the full ADR index (docs/architecture/decisions/README.md) and every ADR relevant to the area you are touching before designing a change; do not assume this file's summary of any decision is complete or current.

Read before you design

At minimum, read the current versions of:

• docs/architecture/decisions/README.md and every ADR relevant to your change
• docs/architecture/platform-architecture.md and docs/architecture/repository-boundaries.md
• README.md (current platform status — what is and is not implemented)
• docs/development/repository-workflow.md and docs/development/testing.md
• CONTRIBUTING.md

These files change as the platform evolves. Inspect the actual current repository state (source, tests, package.json scripts, CI workflow) before relying on anything in this file or in your own memory of a prior session — treat stale assumptions as a bug to catch, not a shortcut.

Working conventions

• Work on a clean branch off an up-to-date main; never commit or push directly to main; never change branch-protection settings.
• Keep PRs focused on one bounded slice. Record major architectural changes in an ADR rather than burying them in an implementation.
• Add or update tests when you change a contract or architectural rule. New behavior needs new test coverage, not just a passing existing suite.
• Errors that reach a user, log, CLI, or pnpm doctor output must be sanitized: never expose secrets, connection strings, raw SQL, raw driver/exception messages, stack traces, causes, or machine-specific paths. Match the sanitization pattern already used by core/src/migrations/runner.ts and core/src/diagnostics/doctor.ts rather than inventing a new one.
• Never run a database migration automatically (on import, on startup, in a test that isn't explicitly a migration test, or as a side effect of an unrelated command). Migrations are always an explicit, operator-invoked action.

Canonical verification commands

Run from the repository root; package.json is the source of truth if this list and the file ever disagree:

• pnpm verify — the full code-only gate (format, lint, boundaries, typecheck, tests, module and migration validation, identity schema drift check, build). Docker-free; never touches a live database.
• pnpm test:migrations:integration — live, disposable-PostgreSQL migration evidence. Requires Docker. Run this for any change touching migration discovery, planning, or execution.
• pnpm doctor — read-only local readiness report. Never treat it as a substitute for pnpm verify or the integration suite.
• pnpm migrations:plan / pnpm migrations:apply — read-only planning vs. mutating execution against DATABASE_URL. Never run migrations:apply without the user's explicit intent.

When you're unsure

If a task would require weakening an existing ADR's guarantee, introducing a second mechanism where one already exists (a second migration runner, a second discovery path, a second config system), or exposing something the boundary checker currently blocks, stop and surface the conflict instead of working around it.