# Seeds

A seed creates data for development by calling your app's own actions, so
validation, lifecycle and policy apply to it. Each seed is a file in
`database/seeds/`.

database/seeds/local_demo.jadpo:

```jadpo
/// A user with a few todos, for local development.
seed {
    var alice: User = attempt planning.register_user("alice@example.com")
    attempt planning.create_todo(alice.id, "Buy milk")
    attempt planning.create_todo(alice.id, "Book dentist")
}
```

A seed is named by its file: `seed { }` in `local_demo.jadpo` is
`local_demo`. It is checked like a test, and its calls run as a test's do
([Calls with no caller](/docs/acting-as-a-user.md#calls-with-no-caller)): one that
passes a caller runs as them, under policy, and one that passes none runs
without it, which is how a seed makes the first user who holds a role.

`jadpo seed <name>` runs one
([`jadpo seed`](/docs/commands-for-the-database-settings-and-translations.md#jadpo-seed)). It refuses a production
database: data production needs is a migration backfill. A production
database is any that isn't on this machine: every server the store's
address names must be a Unix socket, `localhost`, `127.0.0.1` or `::1`,
the ones [PostgreSQL over TLS](/docs/stores.md#postgresql-over-tls) also treats as this
machine. Nothing is run against any store until every store passes
(`seed.production_refused`).

A seed runs as a request does, at one time read from the clock and with
the machine's randomness, so each run makes new identities. Each action it
calls commits on its own, so a seed that stops at a failure or a fault
keeps what its earlier calls committed (`seed.failed`). Mail lands in the
dev inbox and provider calls are faked, as under `jadpo dev`, and what its
actions emit is delivered before the command ends.