# Contributing

Ekklesia is being built in verified, reviewable phases. Changes should preserve the dependency
boundaries described in [repository-boundaries.md](docs/architecture/repository-boundaries.md).

Before opening a change, run:

```bash
pnpm verify
```

Migration-runner changes also require the disposable live PostgreSQL suite:

```bash
pnpm test:migrations:integration
```

See the [testing guide](docs/development/testing.md) for the distinction between unit and live
evidence and for credential-safe troubleshooting.

When adding or changing a module manifest, also run `pnpm modules:validate` directly for focused,
path-aware discovery errors. It is included in `pnpm verify`.

If Docker is available, also validate the development infrastructure:

```bash
pnpm infrastructure:config
```

## Package rules

- Use strict TypeScript for production packages.
- Expose supported entry points through package `exports`; do not import another package's
  private source paths.
- Use `workspace:` ranges for internal package dependencies.
- Module packages cannot contain React, mobile, stylesheet, or other UI source files, and
  `pnpm boundaries` enforces this. ADR 0021 establishes that a module may own its own UI, but the
  authoring model — and therefore which parts of that rule change — is a later Phase 6 decision.
  Until it lands, a module's optional `entrypoints.ui` artifact must be framework-neutral compiled
  output, and nothing hosts it yet.
- The containing application shell, navigation, global theme, and platform policy belong to Core and
  the host application, never to a module.
- Add or update tests when changing a contract or architectural rule.
- Record major architectural changes in an ADR rather than burying them in an implementation.

Runtime registries and aggregate schemas will be produced by later phases. Do not add a manually
maintained feature-module registry; discovery starts from validated `ekklesia.module.json` files.