Decide the boundary: what we build, what the community builds

The project's scope is currently implicit, which makes two questions hard to answer: what should we spend our time on, and what should a maintainer say no to.

The proposed rule is that **we build the core and the modules that are infrastructure, and the community builds the domains.** Our job is to make the second possible, not to do it.

## Three tiers

### Core: nobody else can add it

A capability belongs in the core when a module physically cannot provide it, because it has to be understood by the validator, the admin editor and the delivery projection at once, or enforced in the same place as the existing permission checks.

- The content model and its field types, including references, filtering and record ownership (#135)
- Authentication, RBAC, field sensitivity
- Multi-tenancy and tenant resolution
- Workflow
- The public delivery API
- The module contract itself

The test: if a module tried to add it, would it have to re-implement the published, public and sensitivity rules? If yes, it is core, because the first module that got one of those wrong would leak data.

### Official modules: infrastructure many domains need, or security-sensitive

We maintain these because everyone needs them, or because getting them wrong is dangerous.

Already built: Files and S3 storage, Email via Resend, ExternalAuth, DeviceTrust, FeatureFlags, Diagnostics, Analytics, Portability, Import, AI semantic search, Pwa.

Worth adding, in rough priority:

| Module | Why it is ours rather than theirs |
|---|---|
| **SMTP email** (#125) | Email is not optional and one commercial provider is not a choice |
| **Notifications** | In-app, email and webhook fan-out is infrastructure every domain reuses. A dating app, a helpdesk and a store all need "tell this person something happened" and none of them should write it |
| **Forms** (#110) | The most common single requirement of any client site, and the clearest paid-versus-free win |
| **Upload scanning** | A CMS that accepts files and does not scan them is a liability. Security-sensitive, so ours |
| **Search** (#101) | Sits close enough to delivery that a module doing its own querying would have to re-implement the safety rules |

### Community territory: domains

Events, ticketing, dating, POS, inventory, online store, CRM, LMS, bookings, job boards, classifieds, forums, real estate, fleet tracking.

We should not build these. Each one is somebody's business logic, each has opinions we do not hold, and every one we adopt is one we then maintain forever. The marketplace exists so they do not need our permission.

## The honest exception

**Accounting is a domain module and it is ours.** A double-entry ledger is business logic by any reading. It exists because it was needed, and it is kept because it is the proof that a domain module needs no core changes, which is the argument the whole marketplace rests on.

Worth keeping, worth being honest that it sits on the wrong side of the line we are drawing.

## What has to be true before the community can build

This is the part that makes the strategy real rather than aspirational. Each is already filed:

1. **The three core gaps** (#135). References, filtering and ownership. Without these, most domains cannot be modelled at all, so no module can rescue them.
2. **A module authoring guide** (#132). Today the guidance is "implement `IBarakoModule`" with no example.
3. **A `dotnet new` template** (#84), so the conventions and the discovery tag come for free.
4. **A stated module contract.** Currently whatever `IBarakoModule` happens to expose. An author deciding whether to spend a weekend needs to know which parts survive the next release. Not yet filed separately.
5. **The marketplace.** Done. Any package with the `barakocms-module` tag is listed with no submission step.

## What this issue is asking for

Agreement on the rule, so it can go in CONTRIBUTING and be the thing pointed at when someone proposes a commerce module for the core. The tiers above are a proposal, not a decision.