@nodefony/drizzle 10.0.0-alpha.8 → 10.0.0-beta.1

package/dist/types/nodefony/src/migrator/explain.d.ts

@@ -108,15 +108,15 @@ export interface IMigrationEntryReport {
     /** Où en est cette migration pour CE connecteur. */
     status: "applied" | "pending" | "failed" | "drifted" | "missing";
     /** Début de l'application, en millisecondes — absent si jamais appliquée. */
-    appliedAt?: number;
+    appliedAt?: number | undefined;
     /** Durée de l'application, en millisecondes. */
-    durationMs?: number;
+    durationMs?: number | undefined;
     /** Ce qui l'a appliquée, tel que l'historique l'a retenu. */
-    appliedBy?: string;
+    appliedBy?: string | undefined;
     /** Déploiement qui l'a portée — groupe les migrations d'un même passage. */
-    runId?: string;
+    runId?: string | undefined;
     /** Motif de l'échec, quand elle a échoué. */
-    error?: string;
+    error?: string | undefined;
 }
 /**
  * La charge utile figée — cœur NEUTRE au premier niveau, spécifique du pilote
@@ -155,7 +155,7 @@ export interface IMigrationReport {
      * Son ABSENCE est un fait, pas un oubli : sur une base conforme, il n'y a
      * rien à nommer.
      */
-    divergence?: ISchemaComparison;
+    divergence?: ISchemaComparison | undefined;
     /**
      * Ce que le passage a DÉTRUIT, nommé — présent au seul run réel qui a
      * appliqué une migration destructive, absent partout ailleurs.
@@ -166,7 +166,7 @@ export interface IMigrationReport {
      * octet de ce qu'il relit ne la mentionne. Son absence est un fait : rien
      * n'a été détruit.
      */
-    destructive?: IDestructiveFinding[];
+    destructive?: IDestructiveFinding[] | undefined;
     /** Tout ce qui est propre au pilote SQL vit ici, et nulle part ailleurs. */
     driver: {
         kind: "sql";
@@ -174,9 +174,9 @@ export interface IMigrationReport {
         ddl: string;
         historyTable: string;
         /** La base visée, sans identifiant ni mot de passe. */
-        target?: string;
+        target?: string | undefined;
         /** `true` quand la cible vient de `NF_MIGRATE_DATABASE_URL`. */
-        fromMigrateUrl?: boolean;
+        fromMigrateUrl?: boolean | undefined;
     };
 }
 /** Grille des codes de sortie — **figée, jamais réaffectée**. */

package/dist/types/nodefony/src/migrator/kit.d.ts

@@ -129,6 +129,21 @@ export declare function auditMigrationSql(sql: string, dialect: SqlDialect): IMi
  * @returns `true` si l'échec vient d'une question restée sans terminal.
  */
 export declare function isInteractivePromptFailure(output: string): boolean;
+/**
+ * Reconnaît le refus de l'outil devant un `await` de premier niveau.
+ *
+ * C'est l'esbuild de `drizzle-kit` qui le détecte, en transpilant le fichier en
+ * CommonJS : sa ligne d'erreur nomme le fichier et la position. On la lit plutôt
+ * que d'analyser nous-mêmes les sources — l'outil qui refuse est aussi celui qui
+ * sait exactement où, sans faux positif. Fonction PURE, éprouvée sans process.
+ *
+ * @param output - sortie complète de l'outil.
+ * @returns le fichier et la ligne, ou `null` si l'échec est d'une autre nature.
+ */
+export declare function topLevelAwaitFailure(output: string): {
+    file: string;
+    line: number;
+} | null;
 /**
  * Pose le marqueur de format en tête des `.sql` d'un dossier qui ne l'ont pas.
  *

package/dist/types/nodefony/src/migrator/name.d.ts

@@ -34,7 +34,7 @@ export type MigrationNameCheck = {
      * geste qui échoue est pire que ne rien proposer, parce qu'il fait perdre
      * un aller-retour ET la confiance dans les autres suggestions.
      */
-    suggestion?: string;
+    suggestion?: string | undefined;
 };
 /**
  * Dérive un nom acceptable d'une saisie qui ne l'est pas.

package/dist/types/nodefony/src/migrator/paths.d.ts

@@ -12,6 +12,37 @@ export declare const FRAMEWORK_RANK = 0;
  * celles des modules ; l'inverse n'arrive jamais.
  */
 export declare const APP_RANK = 1000000;
+/**
+ * Noms qui ne peuvent PAS désigner le dossier d'un connecteur secondaire : ce
+ * sont ceux des dossiers de dialecte (et du journal) que le connecteur du
+ * framework range déjà sous `migrations/`. Un connecteur `postgres` y lirait les
+ * migrations de `default` comme les siennes.
+ */
+export declare const RESERVED_MIGRATION_DIRS: readonly string[];
+/**
+ * Le nom de ce connecteur collisionne-t-il avec un dossier de dialecte ?
+ *
+ * @param connector - nom du connecteur (clé de `connectors`).
+ * @returns `true` pour un connecteur SECONDAIRE nommé comme un dossier réservé.
+ */
+export declare function isReservedConnectorName(connector: string): boolean;
+/**
+ * Dossier des migrations PROPRES à un connecteur — la seule règle qui dit où
+ * elles vivent.
+ *
+ * Le connecteur du framework garde la racine (`migrations/<dialecte>`) : ses
+ * migrations décrivent la base du framework et des entités de l'application.
+ * Un connecteur secondaire reçoit son sous-dossier (`migrations/<connecteur>/
+ * <dialecte>`) : sa base ne reçoit que ce qui y est écrit, et celle du
+ * framework n'en voit rien — le dossier de dialecte qu'elle lit n'est pas le
+ * même.
+ *
+ * @param appDir - dossier de migrations de l'application (`appMigrationsDir`).
+ * @param connector - nom du connecteur.
+ * @returns le dossier parent des sous-dossiers de dialecte, ou `undefined` sans
+ *   racine d'application, ou pour un nom réservé ({@link isReservedConnectorName}).
+ */
+export declare function connectorMigrationsDir(appDir: string | undefined, connector: string): string | undefined;
 /**
  * Dossier des migrations livrées par ce paquet.
  *
@@ -47,8 +78,12 @@ export declare function frameworkMigrationsDir(): Promise<string>;
  *
  * @param appDir - dossier de migrations de l'application, s'il y en a un.
  * @param options.framework - `false` quand le module est data-only.
+ * @param options.connector - connecteur visé ; un connecteur secondaire ne
+ *   reçoit que SES migrations ({@link connectorMigrationsDir}), jamais celles
+ *   du framework. Omis : le registre complet (usage direct).
  * @returns le registre, prêt pour l'applicateur.
  */
 export declare function defaultMigrationSources(appDir?: string, options?: {
     framework?: boolean;
+    connector?: string;
 }): Promise<IMigrationSource[]>;

package/dist/types/nodefony/src/migrator/refusals.d.ts

@@ -37,6 +37,8 @@ export type CommandFailureCode =
  | "NF_GENERATE_TOOL_MISSING"
 /** L'outil de génération pose une question, et il n'y a pas de terminal. */
  | "NF_GENERATE_NEEDS_ANSWER"
+/** Un fichier d'entité porte un `await` de premier niveau, que l'outil ne sait pas lire. */
+ | "NF_GENERATE_TOP_LEVEL_AWAIT"
 /** L'outil de génération s'est arrêté ; ce qu'il a dit est remonté tel quel. */
  | "NF_GENERATE_TOOL_FAILED"
 /** La lecture du schéma d'une base existante a échoué. */
@@ -46,7 +48,9 @@ export type CommandFailureCode =
 /** L'adoption par lecture de la base, demandée alors qu'il existe déjà des migrations. */
  | "NF_MIGRATE_BASELINE_NOT_EMPTY"
 /** La table d'historique existe, mais ce n'est pas celle du framework. */
- | "NF_MIGRATE_HISTORY_FOREIGN";
+ | "NF_MIGRATE_HISTORY_FOREIGN"
+/** Écrire une migration pour un connecteur secondaire au nom réservé (`postgres`…). */
+ | "NF_MIGRATE_SECONDARY_CONNECTOR";
 /**
  * Ce que la découverte des entités a VU, au moment où la commande a refusé.
  *
@@ -157,6 +161,22 @@ export declare function formatToolOutput(output: string, maxLines?: number): str
  * @returns le refus, prêt pour la ligne de commande comme pour l'écran.
  */
 export declare function generationNeedsAnswer(label: string, replay: string): IResolutionRefusal;
+/**
+ * Un fichier lu par l'outil de génération porte un `await` de premier niveau.
+ *
+ * Nodefony est ESM, et l'application démarre très bien avec ce fichier. Mais
+ * l'outil qui écrit les migrations (`drizzle-kit`) relit les fichiers de schéma
+ * HORS de la chaîne de l'application, en les transpilant en CommonJS — où un
+ * `await` de premier niveau n'existe pas. Sans ce refus, l'utilisateur recevait
+ * une pile d'appels d'esbuild qui ne nomme ni l'outil ni le remède.
+ *
+ * @param label - ce qui était généré, tel qu'on le cite à l'utilisateur.
+ * @param file - fichier fautif, tel que l'outil l'a nommé.
+ * @param line - ligne de l'`await`.
+ * @param replay - la commande à relancer une fois le fichier corrigé.
+ * @returns le refus, prêt pour la ligne de commande comme pour l'écran.
+ */
+export declare function generationTopLevelAwait(label: string, file: string, line: number, replay: string): IResolutionRefusal;
 /**
  * L'outil de génération s'est arrêté, et ce qu'il a dit est remonté TEL QUEL.
  *
@@ -218,6 +238,21 @@ export declare function moduleAbsent(): IResolutionRefusal;
  * @returns le refus, prêt pour la ligne de commande comme pour l'écran.
  */
 export declare function notConfigured(connector: string, driver: string): IResolutionRefusal;
+/**
+ * Écrire une migration pour un connecteur secondaire dont le NOM est celui d'un
+ * dossier de dialecte — refusé.
+ *
+ * Un connecteur secondaire range ses migrations sous `migrations/<connecteur>/`,
+ * à côté des dossiers de dialecte du connecteur du framework. Nommé `postgres`,
+ * son dossier SERAIT celui des migrations PostgreSQL du framework : il les
+ * lirait comme les siennes, et les siennes seraient appliquées à la base du
+ * framework. On le refuse en nommant la collision, plutôt que de le découvrir
+ * au premier déploiement.
+ *
+ * @param connector - connecteur demandé.
+ * @returns le refus, prêt pour la ligne de commande comme pour l'écran.
+ */
+export declare function reservedConnectorName(connector: string): IResolutionRefusal;
 /**
  * Traduit une résolution qui n'est PAS `ready` en refus lisible.
  *

package/dist/types/nodefony/src/migrator/resolve.d.ts

@@ -67,6 +67,8 @@ export declare function resetAllowed(env: IMigrationEnv): boolean;
  * @returns `true` si l'enchaînement est recevable.
  */
 export declare function generateApplyAllowed(env: IMigrationEnv): boolean;
+import { MEMORY_DATABASE } from "../memoryDatabase.js";
+export { MEMORY_DATABASE };
 /**
  * Le mode de schéma qui s'applique à un connecteur.
  *
@@ -99,10 +101,18 @@ export declare function generateApplyAllowed(env: IMigrationEnv): boolean;
  *
  * @param explicit - valeur écrite dans la configuration du connecteur, si elle l'est.
  * @param env - environnement constaté.
+ * 🔴 **Une base VOLATILE (`:memory:`) dérive toujours son schéma**, en
+ * production comprise. Rien d'autre ne peut la peupler : elle repart vide à
+ * chaque démarrage, et une migration appliquée ne survit pas au processus. En
+ * `none`, elle restait vide, le verdict de schéma tombait à `divergent` et la
+ * sonde de disponibilité retenait la mise en service (vécu en CI : le connecteur
+ * d'un module de banc, ouvert en production sous dérogation).
+ *
  * @param appHasMigrations - l'application versionne au moins une migration.
+ * @param volatile - la base est en mémoire (`:memory:`).
  * @returns le mode effectif.
  */
-export declare function resolveDdlMode(explicit: DdlMode | undefined, env: IMigrationEnv, appHasMigrations?: boolean): DdlMode;
+export declare function resolveDdlMode(explicit: DdlMode | undefined, env: IMigrationEnv, appHasMigrations?: boolean, volatile?: boolean): DdlMode;
 /**
  * L'application versionne-t-elle au moins une migration ?
  *
@@ -120,6 +130,21 @@ export declare function resolveDdlMode(explicit: DdlMode | undefined, env: IMigr
  *   ou sous un sous-dossier de dialecte (`migrations/postgres/0001_x.sql`).
  */
 export declare function appVersionsMigrations(dir: string | undefined): boolean;
+/**
+ * Des migrations versionnées CONCERNENT-elles ce connecteur ?
+ *
+ * C'est la question que pose la bascule `auto` → `migrate`, et elle n'est pas
+ * « l'application versionne-t-elle des migrations ? » : celles de la racine
+ * décrivent la base du framework. Posée telle quelle, elle faisait basculer en
+ * `migrate` un connecteur secondaire qui n'en recevra jamais une — sa base
+ * restait alors sans schéma, ni dérivé ni migré. On regarde donc le dossier
+ * DU connecteur ({@link connectorMigrationsDir}).
+ *
+ * @param connector - nom du connecteur.
+ * @param dir - dossier de migrations de l'application ({@link appMigrationsDir}).
+ * @returns `true` si le dossier propre au connecteur porte au moins un `.sql`.
+ */
+export declare function connectorVersionsMigrations(connector: string, dir: string | undefined): boolean;
 /**
  * La conduite de la sonde de disponibilité face à un schéma en retard.
  *
@@ -133,6 +158,24 @@ export declare function appVersionsMigrations(dir: string | undefined): boolean;
  * @returns la conduite effective.
  */
 export declare function resolveCheckMode(explicit: MigrationCheckMode | undefined, env: IMigrationEnv): MigrationCheckMode;
+/**
+ * En schéma `auto`, faut-il ÉNONCER au démarrage les migrations enregistrées
+ * que personne n'a appliquées ?
+ *
+ * Oui en développement, sauf conduite `off` — c'est ce conseil qui évite de
+ * conclure à une base incohérente devant une colonne inconnue. Jamais sur une
+ * base `:memory:` : elle repart VIDE à chaque démarrage, son historique aussi,
+ * si bien que tout y paraît « à appliquer » à chaque fois — un avertissement
+ * permanent qui n'apprend rien (vécu : le connecteur de banc `mediasoup`,
+ * une fois déclaré, réclamait à chaque démarrage les migrations du framework
+ * et de l'application, qui ne le concernent pas).
+ *
+ * @param check - conduite résolue ({@link resolveCheckMode}).
+ * @param env - environnement constaté.
+ * @param filename - fichier sqlite du connecteur, s'il en a un.
+ * @returns `true` si le conseil doit être rendu.
+ */
+export declare function adviseMigrations(check: MigrationCheckMode, env: IMigrationEnv, filename: string | undefined): boolean;
 /** Ce qu'un connecteur est, du point de vue des migrations. */
 export type IConnectorResolution = {
     /** Le connecteur existe et son propriétaire sait migrer. */

package/dist/types/nodefony/src/migrator/types.d.ts

@@ -98,9 +98,9 @@ export interface IMigrationVerdict {
     /** Connecteur concerné. */
     connector: string;
     /** Source de migrations concernée, quand le refus en désigne une. */
-    source?: string;
+    source?: string | undefined;
     /** Tag concerné, quand le refus en désigne un. */
-    tag?: string;
+    tag?: string | undefined;
     /** Faits constatés, sans mise en forme — de quoi rendre la phrase. */
     facts: Record<string, string | number | boolean | readonly string[]>;
     /** Ce qu'il faut faire ensuite, du plus direct au plus assumé. */

package/dist/types/nodefony/src/orm-core/DrizzleOrm.d.ts

@@ -1,3 +1,4 @@
+import type { Container } from "nodefony";
 import { Orm } from "@nodefony/orm-core";
 import type { IOrmMigrationApplyReply, IOrmMigrationPlanReply, IOrmMigrationReply } from "@nodefony/orm-core";
 import { type ISchemaComparison } from "../migrator/schemaDiff.js";
@@ -12,12 +13,22 @@ export interface DrizzleOrmOptions {
      */
     dialect?: SqlDialect;
     /** Fichier SQLite (`":memory:"` par défaut) — dialecte `sqlite` uniquement. */
-    filename?: string;
+    filename?: string | undefined;
     /**
      * Chaîne de connexion (`postgres://…`, `mysql://…`) — dialectes `postgres`/
      * `mysql`. Requise pour ces dialectes.
      */
-    url?: string;
+    url?: string | undefined;
+    /**
+     * Container du service qui construit l'ORM — il porte le `syslog` du kernel.
+     *
+     * Sans lui, l'ORM se fabrique un container et un journal à lui, que rien ne
+     * relie à la sortie du serveur : « connexion perdue » et « connexion
+     * rétablie » partaient dans le vide, et l'exploitant ne voyait que les
+     * échecs des sondes, jamais le diagnostic de la reprise. Omis en usage
+     * direct (bancs de test) : l'ORM reste alors autonome, comme avant.
+     */
+    container?: Container | undefined;
     /**
      * Le schéma doit-il être DÉRIVÉ du code à la connexion ?
      *

package/dist/types/nodefony/src/orm-core/DrizzleRepository.d.ts

@@ -15,7 +15,7 @@ import type { Criteria, IRepository, ITransaction, RepositoryReadOptions, Update
  * La surface d'exécution native qui DIVERGE (`db.all` vs `db.execute().rows`)
  * est routée par le `queryKit` — jamais ici.
  */
-export type DrizzleDb = BetterSQLite3Database<Record<string, never>>;
+export type DrizzleDb = BetterSQLite3Database;
 /** Table Drizzle multi-dialecte (l'union honnête des variantes colKit). */
 export type DrizzleTable = SQLiteTable | PgTable | MySqlTable;
 /** Colonne Drizzle dialecte-agnostique (classe de base — acceptée par les

package/dist/types/nodefony/src/orm-core/ddlPlan.d.ts

@@ -24,9 +24,9 @@ export interface IResolvedForeignKey {
     /** Colonnes visées, dans le même ordre que {@link columns}. */
     readonly foreignColumns: readonly string[];
     /** Politique d'effacement du parent (`restrict`, `set null`, `cascade`…). */
-    readonly onDelete?: string;
+    readonly onDelete?: string | undefined;
     /** Politique de mise à jour de la clé du parent. */
-    readonly onUpdate?: string;
+    readonly onUpdate?: string | undefined;
 }
 /** Une table à créer, et les tables que ses clés étrangères désignent. */
 export interface ITableDependency {

package/dist/types/nodefony/src/queryKit.d.ts

@@ -66,11 +66,11 @@ export declare function reserveIdempotencyKeyMysql(db: DrizzleDb, args: {
 }): Promise<boolean>;
 /** Filtres du listing utilisateur (sous-ensemble non portable de `IUserListQuery`). */
 export interface UserListFilters {
-    role?: string;
-    enabled?: boolean;
-    locked?: boolean;
-    hasSocial?: boolean;
-    q?: string;
+    role?: string | undefined;
+    enabled?: boolean | undefined;
+    locked?: boolean | undefined;
+    hasSocial?: boolean | undefined;
+    q?: string | undefined;
 }
 /** Fenêtre + tri résolus (le défaut `identifier ASC` est posé par l'appelant). */
 export interface UserPageWindow {
@@ -91,10 +91,10 @@ export declare function listUserIdsPage(db: DrizzleDb, dialect: SqlDialect, filt
 }>;
 /** Filtres du listing d'endpoints (sous-ensemble non portable d'`IWebhookListQuery`). */
 export interface WebhookListFilters {
-    enabled?: boolean;
-    event?: string;
-    failing?: boolean;
-    q?: string;
+    enabled?: boolean | undefined;
+    event?: string | undefined;
+    failing?: boolean | undefined;
+    q?: string | undefined;
 }
 /**
  * Sélectionne les `id` d'une **page** d'endpoints webhook (filtres + tri +

package/dist/types/nodefony/src/safeTarget.d.ts

@@ -37,6 +37,6 @@ import type { SqlDialect } from "../config/config.js";
  */
 export declare function describeTargetSafely(target: {
     dialect: SqlDialect;
-    filename?: string;
-    url?: string;
+    filename?: string | undefined;
+    url?: string | undefined;
 }, cwd?: string, grammar?: typeof path): string;

package/docs/index.md

@@ -342,10 +342,10 @@ de drizzle qui sert de modèle. Deux fichiers, mêmes noms partout, aucune quest
 | `nodefony/config/config.ts`             | **le QUOI**    | schéma Zod commenté = source **unique** des défauts, matérialisés `parse({})` |
 | `nodefony/config/defineModuleConfig.ts` | **le COMMENT** | builder **pur** : parse → surcharge d'environnement → gel                     |
 
-Concrètement : `drizzleConfigSchema` (`config.ts:79`) porte chaque `.default()` et chaque
+Concrètement : `drizzleConfigSchema` (`config.ts:136`) porte chaque `.default()` et chaque
 `.describe()` — changer un défaut du module, c'est éditer **là et nulle part ailleurs**. Le builder
-`defineDrizzleConfig()` (`defineModuleConfig.ts:58`) ne retape jamais une valeur : il valide, applique
-l'environnement, gèle. Et `drizzleConfigJsonSchema()` (`defineModuleConfig.ts:69`) expose le tout en
+`defineDrizzleConfig()` (`defineModuleConfig.ts:81`) ne retape jamais une valeur : il valide, applique
+l'environnement, gèle. Et `drizzleConfigJsonSchema()` (`defineModuleConfig.ts:99`) expose le tout en
 JSON Schema pour l'écran de configuration de Studio.
 
 Le schéma reste **pur** : il ne lit ni `process.env` ni le kernel. C'est ce qui rend le module
@@ -361,11 +361,11 @@ importable et testable sans serveur.
 | `connectors.<n>.url`      | `string`                            | —                  | Chaîne de connexion `postgres://…` / `mysql://…`. **Porte un secret.** |
 | `frameworkEntities`       | `boolean`                           | `true`             | Déclare (ou non) le schéma des huit briques durables sur `default`.    |
 
-Table dérivée de `drizzleConfigSchema` (`config.ts:79`) et de `SQL_DIALECTS` (`config.ts:37`).
+Table dérivée de `drizzleConfigSchema` (`config.ts:136`) et de `SQL_DIALECTS` (`config.ts:37`).
 
 **`filename` est volontairement sans défaut.** Le chemin dépend du kernel, qui n'existe pas quand le
 schéma est évalué. Il est résolu **au démarrage** par `DrizzleService.#defaultFilename()`
-(`DrizzleService.ts:95`) vers `<app>/var/databases/nodefony-<connecteur>.db` — sous `var/`, le dossier
+(`DrizzleService.ts:230`) vers `<app>/var/databases/nodefony-<connecteur>.db` — sous `var/`, le dossier
 commun des données runtime : « où sont mes données ? » a une réponse unique, un seul chemin à
 sauvegarder et à ignorer dans git.
 
@@ -385,9 +385,12 @@ NF_DATABASE_URL=mysql://app:secret@db:3306/prod
 NF_DATABASE_URL=sqlite:/var/lib/app/prod.db
 ```
 
-`applyEnvOverrides()` (`defineModuleConfig.ts:20`) lit l'infra, en déduit le dialecte depuis le
-_scheme_, et pose `filename` ou `url` sur le connecteur primaire. Une URL `mongodb://` est **ignorée
-ici** : elle appartient alors à `@nodefony/mongoose`.
+`applyEnvOverrides()` (`defineModuleConfig.ts:32`) lit l'infra, en déduit le dialecte depuis le
+_scheme_, et pose `filename` ou `url` sur le connecteur primaire. Une URL `mongodb://` n'est **pas
+lue ici** : elle appartient à `@nodefony/mongoose`. Drizzle en tire aussi la conséquence — il ne crée
+**pas** le connecteur `default` que ses défauts posent, donc aucune base SQLite parallèle et aucun
+schéma du framework en double. Un `default` que l'application écrit elle-même dans
+`use("@nodefony/drizzle", { connectors: { default: … } })` est gardé, comme tout autre connecteur.
 
 **Situation 3 — plusieurs bases.** Un connecteur par base. Seul `default` porte le schéma du framework ;
 les autres sont à toi.
@@ -403,13 +406,13 @@ use("@nodefony/drizzle", {
 
 > [!WARNING]
 > Une URL de connexion **porte un mot de passe**. Le module ne la journalise jamais telle quelle :
-> `redactUrl()` (`DrizzleService.ts:68`) remplace le mot de passe par `***` avant tout log de
+> `redactUrl()` (`DrizzleService.ts:99`) remplace le mot de passe par `***` avant tout log de
 > démarrage, et la sonde d'administration applique la même règle.
 
 ### Quand la connexion échoue, le démarrage échoue
 
 Un connecteur **déclaré** qui ne se connecte pas lève une `BootConfigurationError`
-(`DrizzleService.ts:244`) — en développement **comme** en production. Ce n'est pas une sévérité
+(`DrizzleService.ts:368`) — en développement **comme** en production. Ce n'est pas une sévérité
 gratuite : une infrastructure déclarée mais injoignable ne se répare pas en continuant. Un serveur qui
 démarrerait « vivant » avec ses stores morts accepterait des requêtes pour échouer plus tard, la cause
 noyée dans un avertissement. Le message d'erreur nomme le connecteur, le dialecte, la cible rédigée et
@@ -417,7 +420,7 @@ la piste à vérifier.
 
 Pour les dialectes réseau, la connexion fait un **ping réel** au démarrage : les pools `pg` et `mysql2`
 sont paresseux, sans ce `SELECT 1` une base morte « se connecterait » et n'échouerait qu'à la première
-requête métier (`#connectPostgres()`, `DrizzleOrm.ts:998` · `#connectMysql()`, `DrizzleOrm.ts:1296`).
+requête métier (`#connectPostgres()`, `DrizzleOrm.ts:1193` · `#connectMysql()`, `DrizzleOrm.ts:1514`).
 
 ## Dialectes — une base par déploiement, un seul code
 
@@ -464,7 +467,7 @@ En MySQL, les verbes « qui rendent la ligne écrite » (`create`, `updateOne`,
 `findOneAndDelete`) se décomposent en sélection de la cible → mutation bornée par la clé primaire **avec
 le critère revérifié dans le `WHERE`** → relecture. Deux à trois allers-retours au lieu d'un : c'est le
 prix du dialecte, payé **uniquement** en MySQL. Une course perdue rend `null`, jamais une mutation hors
-critère (`#mysqlInsertReturning()`, `DrizzleRepository.ts:1138`).
+critère (`#mysqlInsertReturning()`, `DrizzleRepository.ts:1105`).
 
 Le SQL brut nécessaire aux entités du framework est lui aussi routé par dialecte, dans un seul fichier
 (`queryKit.ts`) : recherche dans une colonne JSON (`findUserIdBySocialProvider()`, `queryKit.ts:76`),
@@ -504,7 +507,7 @@ connexion**, donc leurs tables sont créées au moment où l'ORM s'ouvre.
 | Pièce                  | Rôle                                                                   | Ancre                                                        |
 | ---------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------ |
 | `Drizzle` (le module)  | valide la config, déclare le schéma framework, monte le data plane     | `index.ts` du module                                         |
-| `DrizzleService`       | ouvre un ORM par connecteur au boot, ferme tout à l'arrêt              | `connectAll()`, `DrizzleService.ts:148`                      |
+| `DrizzleService`       | ouvre un ORM par connecteur au boot, ferme tout à l'arrêt              | `connectAll()`, `DrizzleService.ts:214`                      |
 | `DrizzleOrm`           | la connexion : DDL dérivé, repositories, transactions, sonde           | `DrizzleOrm.ts:214`                                          |
 | `DrizzleRepository<T>` | le CRUD portable, les opérateurs riches, l'eager-load                  | `DrizzleRepository.ts:146`                                   |
 | `DrizzleTransaction`   | `BEGIN`/`COMMIT`/`ROLLBACK` pilotés à la main, sur les trois dialectes | `DrizzleTransaction.ts:70`                                   |
@@ -515,7 +518,7 @@ connexion**, donc leurs tables sont créées au moment où l'ORM s'ouvre.
 ### Le DDL dérivé — comment les tables apparaissent
 
 Drizzle ne « synchronise » pas un schéma. L'adapter dérive lui-même un `CREATE TABLE IF NOT EXISTS`
-depuis chaque table déclarée (`#buildCreateTable()`, `DrizzleOrm.ts:400`) et l'exécute à la connexion.
+depuis chaque table déclarée (`#buildCreateTable()`, `DrizzleOrm.ts:509`) et l'exécute à la connexion.
 Trois conséquences à connaître **avant** de dépendre de ce mécanisme :
 
 1. il **crée**, il ne **modifie** pas — aucun `ALTER` n'est émis ;
@@ -556,7 +559,7 @@ await posts.count({ views: { $gte: 10 } });
 
 Les opérateurs (`$eq $ne $gt $gte $lt $lte $in $nin $like`) sont **ceux d'orm-core**, identiques sur
 tous les drivers ; la traduction en `eq()`/`inArray()` se fait dans `#where()`
-(`DrizzleRepository.ts:420`). Leur référence complète est dans
+(`DrizzleRepository.ts:445`). Leur référence complète est dans
 [la page d'orm-core](../../orm-core/docs/index.md).
 
 `$like` est émis avec sa clause `ESCAPE '\'` (`likeSql.ts`), ce qui rend un `%` ou un `_` **littéral**
@@ -568,10 +571,10 @@ Deux points de comportement qui évitent des surprises :
 
 - **« au plus une ligne »** est garanti par construction pour `updateOne`/`deleteOne`/`increment` :
   la mutation est bornée par la clé primaire découverte de la table, jamais par un `LIMIT` sur un
-  `UPDATE` (`#pickOne()`, `DrizzleRepository.ts:259`). C'est ce qui rend ces verbes portables — MySQL
+  `UPDATE` (`#pickOne()`, `DrizzleRepository.ts:284`). C'est ce qui rend ces verbes portables — MySQL
   interdit la forme naïve.
 - **l'eager-load est manuel** : une requête `IN (…)` par relation déclarée, puis regroupement en
-  mémoire (`#populate()`, `DrizzleRepository.ts:683`). Choix assumé — pas de couche de relations à
+  mémoire (`#populate()`, `DrizzleRepository.ts:694`). Choix assumé — pas de couche de relations à
   déclarer une seconde fois, et le comportement est le même sur les trois dialectes.
 
 ### Transactions — une connexion dédiée, jamais le pool
@@ -600,7 +603,7 @@ Le mécanisme diffère par dialecte, sans que ton code le voie : en PostgreSQL/M
 emprunte une connexion **dédiée** au pool, rendue au commit — et **détruite** si celui-ci échoue,
 jamais recyclée dans un état inconnu. En SQLite la connexion est unique, donc c'est un pool de taille 1 :
 les transactions concurrentes sont **sérialisées par une file d'attente** (`#sqliteTxGate`,
-`DrizzleOrm.ts:267`), sinon deux requêtes HTTP simultanées émettraient deux `BEGIN` sur la même
+`DrizzleOrm.ts:360`), sinon deux requêtes HTTP simultanées émettraient deux `BEGIN` sur la même
 connexion et la seconde échouerait.
 
 Les points de sauvegarde sont disponibles (`savepoint()`, `DrizzleTransaction.ts:123`) ; le nom est
@@ -624,7 +627,7 @@ const rows = await db.all(sql`
 `);
 ```
 
-C'est l'**anti-blocage** du modèle Repository (`getNativeConnection()`, `DrizzleOrm.ts:1524`) : CTE,
+C'est l'**anti-blocage** du modèle Repository (`getNativeConnection()`, `DrizzleOrm.ts:1783`) : CTE,
 fonctions de fenêtre, sous-requêtes corrélées, jointures arbitraires. Deux contreparties assumées :
 ce SQL n'est plus portable entre dialectes, et il **ne passe pas** par la sonde de profilage des
 requêtes.
@@ -653,7 +656,7 @@ ou l'idempotence (`createIdempotencyTable`, `idempotencyEntity.ts:85`).
 ### Comment ça s'active — la réponse est : tout seul
 
 Chaque brique choisit son backend par une option `store`, dont le **défaut est `"auto"`**. La
-résolution automatique (`resolveAutoStore()`, `infra.ts:241`) applique cette préférence :
+résolution automatique (`resolveAutoStore()`, `infra.ts:297`) applique cette préférence :
 
 1. une infra `database` déclarée (`NF_DATABASE_URL`) → **`drizzle`** (ou `mongoose` si l'URL est Mongo) ;
 2. sinon, un backend local persistant réellement chargé → **`drizzle`**, c'est-à-dire SQLite ;
@@ -714,8 +717,8 @@ construction : ils la résolvent à chaque appel. C'est nécessaire parce que l'
 le framework résout ses stores avant que l'ORM ne soit connecté — et parce que l'ORM se **déconnecte à
 l'arrêt** avant que les serveurs HTTP n'aient fini de vider leurs requêtes en vol. Handle absent =
 dégradation annoncée, pas un plantage : le `SessionStorage` rend une session vide et ignore les
-écritures (`#repo()`, `SessionStorage.ts:65`), le store d'idempotence laisse passer la mutation sans
-dédup (`begin()`, `DrizzleIdempotencyStore.ts:200`).
+écritures (`#repo()`, `SessionStorage.ts:86`), le store d'idempotence laisse passer la mutation sans
+dédup (`begin()`, `DrizzleIdempotencyStore.ts:225`).
 
 **SQL n'a pas de TTL.** Contrairement à Redis, rien n'expire tout seul : chaque store expose un `gc()`
 applicatif qui supprime les lignes échues, déclenché par un minuteur hors du chemin chaud —
@@ -732,7 +735,7 @@ c'est ce qui interdit de conclure « nouvelle mutation » hors d'une réservatio
 en deux instructions au verdict non ambigu (`reserveIdempotencyKeyMysql()`, `queryKit.ts:152`).
 
 **Le journal d'audit** pagine par un curseur **composite auto-portant** `<horodatage>:<id>` sur un ordre
-total, plutôt que par un identifiant seul (`listPage()`, `DrizzleAuditStore.ts:154`). Deux gains : plus
+total, plutôt que par un identifiant seul (`listPage()`, `DrizzleAuditStore.ts:175`). Deux gains : plus
 d'aller-retour pour résoudre le curseur, et une pagination qui ne rembobine pas à la première page si
 l'événement de référence a été purgé entre deux appels.
 
@@ -772,8 +775,8 @@ entités que le DDL dérivé, et un banc vérifie sur les trois dialectes qu'une
 identique à une base **dérivée** — colonne par colonne, index compris. Sans cette preuve, les deux
 chemins divergeraient en silence.
 
-Les appliquer, les adopter, les réparer et surveiller leur état est le travail de cinq commandes
-`nodefony orm:migrate*` — avec leur verrou, leur historique et leur branchement sur la sonde de
+Les écrire, les appliquer, les adopter, les réparer, surveiller leur état et repartir d'une base
+vide est le travail de six commandes — `orm:generate`, les quatre `orm:migrate*` et `orm:reset` — avec leur verrou, leur historique et leur branchement sur la sonde de
 disponibilité. Tout est dans **[Migrations de schéma](migrations.md)**, qui porte aussi le patron de
 déploiement sans interruption et les droits du compte qui migre.
 
@@ -831,7 +834,7 @@ faire lui-même).
 Côté écrans : **Database**, **ORM (vue d'ensemble et par entité)** et **Stores** — ce dernier répond à
 la question « où sont écrites mes données ? » pour chaque brique.
 
-La sonde d'un connecteur s'adapte au dialecte (`probe()`, `DrizzleOrm.ts:1614`) :
+La sonde d'un connecteur s'adapte au dialecte (`probe()`, `DrizzleOrm.ts:1873`) :
 
 - **SQLite** → `storage` : taille du fichier, mode de journal, pages libres (lus par `PRAGMA`) ;
 - **PostgreSQL / MySQL** → `pool` : taille, connexions libres, empruntées, en attente — **compteurs en
@@ -843,12 +846,12 @@ que promettre en silence — c'est le principe « superviser sans peser sur la p
 
 Chaque store expose aussi son **emplacement physique** pour l'écran Stores : le chemin du fichier
 SQLite, relativisé (anti-fuite d'information), et `undefined` pour un backend réseau — dont
-l'emplacement **est** l'infra déclarée, déjà affichée ailleurs (`location`, `DrizzleOrm.ts:415`).
+l'emplacement **est** l'infra déclarée, déjà affichée ailleurs (`location`, `DrizzleOrm.ts:481`).
 
 ## ⚡ Performance & mémoire
 
 **La sonde de requêtes ne coûte rien quand elle est éteinte.** Chaque exécution passe par un point de
-mesure unique (`#prof()`, `DrizzleRepository.ts:330`) qui alimente deux consommateurs — le profileur
+mesure unique (`#prof()`, `DrizzleRepository.ts:355`) qui alimente deux consommateurs — le profileur
 par requête (barre de debug) et l'agrégat de flux. Les deux sont gardés par un drapeau : si aucun n'est
 actif, la fonction rend le constructeur de requête tel quel, sans allocation. Le flux est **désactivé
 en production** par défaut.