> ## Documentation Index
> Fetch the complete documentation index at: https://api-documentation.kare-app.fr/llms.txt
> Use this file to discover all available pages before exploring further.

# Seed — vue d'ensemble

> Comment le seeder produit des comptes cohérents, et ses deux sources de données

Le seeder construit un **blueprint** puis le **rejoue à travers le domaine** : chaque événement
passe par les mêmes `db-access` que les routes HTTP, donc les statuts, les échéances et
l'historisation sont calculés par le code métier, jamais écrits en dur.

```bash theme={null}
cd apps/api && yarn db:seed --help
# ou depuis la racine
yarn workspace @kare/api db:seed --help
```

## Trois usages, un moteur

| Usage         | Besoin                                                        | Source                                             |
| ------------- | ------------------------------------------------------------- | -------------------------------------------------- |
| **Démo**      | un compte parfait, identique à chaque fois, remettable à zéro | blueprint écrit à la main + PDF réels              |
| **Dev local** | un compte crédible en une minute, reproductible               | blueprint généré (`archétype × taille × seed`)     |
| **E2E**       | un état connu et déterministe, tous les enums présents        | blueprint généré + overlay de couverture (`--e2e`) |

## Les trois commandes

| Commande   | Effet                                                                                                  |
| ---------- | ------------------------------------------------------------------------------------------------------ |
| `account`  | crée une **nouvelle** organisation avec un propriétaire capable de se connecter, puis rejoue la source |
| `reset`    | **vide** une organisation existante et rejoue la source dedans                                         |
| `bo-admin` | crée ou confirme un opérateur backoffice (idempotent)                                                  |

`account` et `reset` prennent la **même source** : soit `--blueprint=<dossier>`, soit
`--archetype=<clé> --size=s|m|l`.

## Les deux sources

**Blueprint écrit à la main** — un dossier avec un `blueprint.ts` typé et ses `documents/*.pdf`.
C'est la source du compte de démonstration : tout est décidé, les rapports sont de vrais PDF, et
deux runs produisent exactement le même compte. Un fichier sans `path` devient un PDF de
remplacement généré, ce qui permet de mélanger corpus réel et pièces encore absentes.

**Blueprint généré** — `archétype × taille × seed`. Six archétypes :
`hotel`, `centre_commercial`, `ehpad`, `logistique`, `bureaux`, `etablissement_scolaire`.
Trois tailles : `s` (1 établissement), `m` (3), `l` (8). Le contenu vient d'un **catalogue métier**
(installations techniques françaises, règles avec leur périodicité, anomalies typées, prestataires
par spécialité, professions et diplômes) ; le tirage choisit *quelles* entrées, jamais *quoi* écrire.

## Les garanties

<Note>
  Chaque run se termine par une **vérification d'invariants** sur l'organisation seedée. Un statut qui
  contredit ses dates, un rapport sans intervention, une anomalie hors du périmètre de son rapport, un
  type de label manquant ou un mot anglais dans un champ visible fait échouer le run.
</Note>

* **Dates ancrées sur `--as-of`** en UTC : un blueprint rejoué demain produit le même compte décalé
  d'un jour, et jamais un compte qui dépend du fuseau de l'opérateur.
* **`--seed` reproduit le contenu généré** à l'identique, blueprint et lignes comprises.
* Un `reset` prend un **verrou d'avis Postgres** par organisation : deux runs sur le même tenant
  attendent au lieu de s'écraser.
* Le `reset` est **interdit en production** et exige l'UUID exact de l'organisation.

## Choisir sa page

<CardGroup cols={2}>
  <Card title="En local" href="/onboarding/seed/local">
    Compte de dev, compte de démo, remise à zéro
  </Card>

  <Card title="Sur staging" href="/onboarding/seed/staging">
    Le workflow GitHub Actions
  </Card>

  <Card title="Référence des paramètres" href="/onboarding/seed/reference">
    Tous les flags et leur équivalent workflow
  </Card>

  <Card title="Maintenance" href="/onboarding/seed/reference#maintenance">
    Ajouter un archétype, une règle, un événement
  </Card>
</CardGroup>