Sortir la démonstration du chemin d'installation

Une instance neuve passait par le seed pour être utilisable. Or le seed installe
une fiction : « Maison Rivage », des salariés inventés, quatre semaines de
planning, des absences. Sur une instance de travail, ces noms se confondent avec
de vrais salariés dans l'annuaire et au registre du personnel.

Le trou qu'il bouchait était réel : après les migrations, une instance avait le
schéma et rien à quoi l'accrocher. Aucun type d'absence, donc aucune demande
saisissable. Aucune étiquette, donc aucun créneau nommé. Aucune convention, donc
un moteur de règles muet qui laisse passer une semaine de soixante heures sans
rien dire.

L'écran d'installation pose donc désormais les référentiels : les douze
étiquettes, cinq types d'absence, la convention d'amorce IDCC 1517 avec
l'origine de chacun de ses paramètres, les durées de conservation et les jours
fériés des deux prochaines années. Ce ne sont pas des exemples mais des minima,
tous modifiables ensuite depuis les réglages.

Trois choses restent délibérément absentes. Aucun dimanche du maire : la liste
vient d'un arrêté municipal, et en inventer rendrait opposable un quota que
personne n'a accordé. Aucun code Silae sur les types d'absence : la
correspondance appartient au dossier du client. Aucun salarié, aucun créneau,
aucune absence.

Le seed devient `prisma/seed-demo.ts`, réservé au harnais Playwright. `db:seed`
disparaît au profit de `db:seed:demo` : il n'y a plus rien à semer pour
démarrer, et un nom qui le dit vaut mieux qu'un commentaire qui l'explique.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/server/install/install.ts

@@ -13,19 +13,21 @@ import {
   type InstallationForm,
 } from '@/domain/install/rules';
 import { hashPassword } from '@/server/auth/session';
+import { installReferentials } from '@/server/install/referentials';
 
 /**
  * Contenu d'une instance neuve — PLAN.md §5.
  *
- * Le seed, lui, installe une démonstration : deux établissements, des salariés
- * fictifs, quatre semaines de planning. Il refuse de tourner en production, et
- * c'est bien ainsi. Il restait donc un trou : après les migrations, une
- * instance de production a le schéma et rien d'autre — pas de compte, pas
- * d'utilisateur, personne pour se connecter.
+ * Le seed, lui, installe une démonstration : des salariés fictifs, des
+ * plannings, des absences. Il refuse de tourner en production, et c'est bien
+ * ainsi. Il restait donc un trou : après les migrations, une instance de
+ * production a le schéma et rien d'autre — pas de compte, pas d'utilisateur,
+ * personne pour se connecter.
  *
- * Ce module comble ce trou, et **rien de plus** : le catalogue des capacités,
- * les rôles fournis, un compte, un établissement, un propriétaire. Aucune
- * donnée d'exemple.
+ * Ce module comble ce trou : catalogue des capacités, rôles fournis, compte,
+ * établissement, propriétaire, puis les **référentiels** sans lesquels rien ne
+ * s'accroche (voir `referentials.ts`). Aucune donnée d'exemple : pas un
+ * salarié, pas un créneau, pas une absence.
  */
 
 export interface InstalledInstance {
@@ -105,7 +107,7 @@ export async function installAccount(
     });
   }
 
-  await tx.location.create({
+  const location = await tx.location.create({
     data: {
       accountId: account.id,
       name: data.locationName,
@@ -113,6 +115,12 @@ export async function installAccount(
     },
   });
 
+  // Étiquettes, types d'absence, convention d'amorce, conservation et jours
+  // fériés. Ce ne sont pas des exemples : sans eux, l'instance a le schéma et
+  // rien à quoi l'accrocher — pas de demande d'absence saisissable, pas de
+  // créneau nommé, et un moteur de règles muet.
+  await installReferentials(tx, account.id, location.id);
+
   const user = await tx.user.create({
     data: {
       email: data.email,