@nodefony/drizzle 10.0.0-alpha.8 → 10.0.0-alpha.9

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

@@ -0,0 +1,10 @@
+/**
+ * Nom de fichier d'une base SQLite en MÉMOIRE — volatile, elle repart vide à
+ * chaque démarrage.
+ *
+ * Module FEUILLE (aucun import) : l'adapter, le migrateur, les commandes et le
+ * service le consultent tous, et le placer dans l'un d'eux ferait importer le
+ * migrateur par l'adapter. Une seule écriture du littéral : c'est d'elle que
+ * dépend la règle « une base volatile dérive son schéma » (`resolveDdlMode`).
+ */
+export declare const MEMORY_DATABASE = ":memory:";

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

@@ -221,3 +221,28 @@ export declare function usurpedTables(tables: readonly IDiscoveredTable[], frame
  * @returns les entités et leur table, dans l'ordre du registre.
  */
 export declare function registeredTables(connector: string): IExpectedEntity[];
+/**
+ * Tables d'un connecteur parmi celles que les fichiers fournissent — le
+ * partage qui fait qu'une migration ne décrit que SA base.
+ *
+ * Une table appartient au connecteur de l'entité qui la déclare (le REGISTRE
+ * le sait, un fichier non). Une table qu'aucune entité ne réclame reste au
+ * connecteur du framework, comme avant que les connecteurs secondaires aient
+ * leurs migrations. Sans ce partage, la table d'une entité secondaire entrait
+ * AUSSI dans les migrations du framework : créée dans une base qui ne s'en sert
+ * jamais, et proposée à la suppression le jour où elle n'y figure plus.
+ *
+ * @param tables - tables fournies par les fichiers de l'application.
+ * @param connector - connecteur visé.
+ * @param owners - `table → connecteurs` qui la déclarent ; par défaut, le registre.
+ * @returns les tables de ce connecteur, dans l'ordre reçu.
+ */
+export declare function tablesOfConnector<T extends {
+    tableName: string;
+}>(tables: readonly T[], connector: string, owners?: ReadonlyMap<string, ReadonlySet<string>>): T[];
+/**
+ * Pour chaque table enregistrée, les connecteurs dont une entité la déclare.
+ *
+ * @returns la table de correspondance, lue dans le registre des entités.
+ */
+export declare function registeredOwners(): Map<string, Set<string>>;

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/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/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";
@@ -18,6 +19,16 @@ export interface DrizzleOrmOptions {
      * `mysql`. Requise pour ces dialectes.
      */
     url?: string;
+    /**
+     * 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;
     /**
      * Le schéma doit-il être DÉRIVÉ du code à la connexion ?
      *

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:202`) 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:86`) 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:340`) — 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:1504`).
 
 ## 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:1149`).
 
 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:186`                      |
 | `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 ;
@@ -571,7 +574,7 @@ Deux points de comportement qui évitent des surprises :
   `UPDATE` (`#pickOne()`, `DrizzleRepository.ts:259`). 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:1745`) : 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:220`).
 
 **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:169`). 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:1835`) :
 
 - **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,7 +846,7 @@ 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
 

package/docs/migrations.md

@@ -80,7 +80,7 @@ D'où **trois modes**, un par connecteur, réglés par la clé `ddl` :
 
 ## 🚀 Démarrage rapide
 
-Cinq verbes, et un seul à retenir pour le quotidien du développement.
+Six verbes, et un seul à retenir pour le quotidien du développement.
 
 ```bash
 # Ce que la base a reçu, ce qui reste, et ce qu'il faut taper. N'écrit rien.
@@ -117,6 +117,34 @@ Toutes acceptent `--connector <nom>` (défaut : `default`) et `--json`. Le flux
 Les migrations du **framework** sont livrées dans le paquet : vous n'avez pas à les produire. Celles
 de votre **application**, vous les écrivez avec `orm:generate` — voir la section suivante.
 
+Ces deux familles de migrations appartiennent au **seul connecteur `default`**, celui qui porte les
+briques du framework : le dossier `migrations/<dialecte>` décrit sa base, et aucune autre.
+
+Un **connecteur secondaire** (une base d'analyse, la base d'un module, un second PostgreSQL) a ses
+**propres** migrations, dans son sous-dossier :
+
+```text
+migrations/
+├── sqlite/                 ← connecteur « default » (framework + application)
+└── analytics/
+    └── postgres/           ← connecteur « analytics », et lui seul
+```
+
+```bash
+nodefony orm:generate --connector analytics --name init   # écrit sous migrations/analytics/<dialecte>
+nodefony orm:migrate  --connector analytics                # l'applique à la base d'« analytics »
+```
+
+Chaque base ne reçoit que son dossier : `default` ne voit pas les migrations d'`analytics`, et
+inversement. `orm:generate --connector analytics` ne décrit que les tables des entités déclarées sur
+ce connecteur (`@entity({ connector: "analytics" })`) ; une table qu'aucune entité ne réclame reste
+à `default`. Tant qu'un secondaire n'a rien versionné, rien ne change : en développement son schéma
+est dérivé du code. Dès son premier fichier, il bascule en `migrate` comme `default`.
+
+Un connecteur secondaire ne peut pas s'appeler `sqlite`, `postgres`, `mysql` ni `meta` : son dossier
+serait celui d'un dialecte de `default`. Les commandes qui écriraient une migration le refusent
+(`NF_MIGRATE_SECONDARY_CONNECTOR`) — renommez le connecteur, son nom ne sert qu'à le désigner.
+
 Côté configuration, il n'y a rien à écrire pour le cas courant : le mode se résout par
 environnement. Ne le déclarer que pour s'en écarter — un serveur unique qui migre au démarrage :
 
@@ -224,6 +252,14 @@ dépendances de développement (`--omit=dev`, une image de production). Le refus
 geste ; il ne parle pas de votre base, qui n'y est pour rien — appliquer des migrations, lui, ne
 réclame aucun outil tiers.
 
+Un cinquième tient à la forme d'un fichier d'entité : **un `await` de premier niveau**
+(`NF_GENERATE_TOP_LEVEL_AWAIT`). Votre application est ESM et démarre très bien avec lui, mais
+l'outil qui écrit les migrations relit les fichiers de schéma de son côté, en CommonJS, où cette
+construction n'existe pas. Le refus nomme le fichier et la ligne. Un fichier d'entité **déclare**
+une table : ce qui se décide à l'exécution — choisir une entité selon l'infrastructure, importer
+un module à la demande — se place dans l'`index.ts` du module, dont `@entities([...])` accepte une
+liste calculée.
+
 ### Une entité qui pointe vers une table du framework
 
 Déclarer une référence vers une table du framework (`session`, `audit_event`…) est légitime : ce
@@ -390,7 +426,7 @@ Trois propriétés en découlent, et elles valent d'être nommées :
 - **Rien n'est appliqué deux fois.** L'historique (`nodefony_migrations`, `types.ts:23`) est écrit
   dans la même transaction que le DDL, là où le moteur le permet.
 - **Un pod en retard ne reçoit pas de trafic.** En `none` comme en `migrate`, l'état du schéma est
-  publié à la sonde de disponibilité (`#publishReadiness()`, `DrizzleService.ts:445`) : `/readyz`
+  publié à la sonde de disponibilité (`#publishReadiness()`, `DrizzleService.ts:527`) : `/readyz`
   répond 503, l'orchestrateur sort l'exemplaire du répartiteur de charge, et l'ancien continue de
   servir. `/livez` n'est jamais touché — un schéma en retard n'est pas un processus malade, et le
   redémarrer ne réparerait rien. La vérification est rejouée toutes les 15 secondes : dès que le
@@ -454,7 +490,7 @@ qui la prend. Un outil qui prétendrait la préparer tout seul inviterait à ne
 Ce que l'outil fait à la place, et qui vaut mieux :
 
 - **il refuse d'appliquer sans que vous sachiez.** Le SQL en attente est examiné avant la moindre
-  écriture (`scanDestructive()`, `destructive.ts:184`) : une suppression de données est refusée hors
+  écriture (`scanDestructive()`, `destructive.ts:282`) : une suppression de données est refusée hors
   développement, en nommant l'instruction et ce qui disparaît. Il faut `--allow-destructive` pour
   passer outre, et **au démarrage il n'y a aucun drapeau pour lever le refus** — un exemplaire qui
   redémarre ne supprime jamais de colonne de lui-même, parce que personne ne regarde à ce

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nodefony/drizzle",
-  "version": "10.0.0-alpha.8",
+  "version": "10.0.0-alpha.9",
   "description": "Moteur SQL de Nodefony sur Drizzle ORM (SQLite, PostgreSQL, MySQL) : dépôts typés, migrations de schéma et adoption d'une base existante",
   "nodefony": {
     "storeKind": "durable",
@@ -28,8 +28,8 @@
   },
   "scripts": {
     "start": "node dist/index.js",
-    "build": "rimraf dist && rolldown -c rolldown.config.ts && tsgo -p tsconfig.declarations.json",
-    "clean": "rimraf dist",
+    "build": "rolldown -c rolldown.config.ts && tsgo -p tsconfig.declarations.json",
+    "clean": "node --eval \"require('node:fs').rmSync('dist',{recursive:true,force:true})\"",
     "generate:migrations": "tsx scripts/generate-migrations.ts",
     "check:migrations": "tsx scripts/check-migrations-drift.ts",
     "dev": "rolldown -c rolldown.config.ts --watch",
@@ -55,35 +55,34 @@
     "esm"
   ],
   "dependencies": {
-    "drizzle-orm": "0.45.2",
+    "drizzle-orm": "0.45.3",
     "tslib": "2.8.1",
     "zod": "^4.6.5"
   },
   "devDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.8",
-    "@nodefony/http": "^10.0.0-alpha.8",
-    "@nodefony/orm-core": "^10.0.0-alpha.8",
-    "@nodefony/security": "^10.0.0-alpha.8",
-    "@nodefony/user": "^10.0.0-alpha.8",
+    "@nodefony/framework": "^10.0.0-alpha.9",
+    "@nodefony/http": "^10.0.0-alpha.9",
+    "@nodefony/orm-core": "^10.0.0-alpha.9",
+    "@nodefony/security": "^10.0.0-alpha.9",
+    "@nodefony/user": "^10.0.0-alpha.9",
     "@types/better-sqlite3": "9.6.0",
     "@types/node": "26.6.2",
     "@types/pg": "8.23.1",
     "better-sqlite3": "13.0.3",
-    "drizzle-kit": "0.31.10",
+    "drizzle-kit": "0.31.11",
     "mysql2": "3.24.4",
-    "nodefony": "^10.0.0-alpha.8",
-    "pg": "8.23.0",
-    "rimraf": "6.1.3"
+    "nodefony": "^10.0.0-alpha.9",
+    "pg": "8.23.0"
   },
   "peerDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.8",
-    "@nodefony/http": "^10.0.0-alpha.8",
-    "@nodefony/orm-core": "^10.0.0-alpha.8",
-    "@nodefony/security": "^10.0.0-alpha.8",
-    "@nodefony/user": "^10.0.0-alpha.8",
+    "@nodefony/framework": "^10.0.0-alpha.9",
+    "@nodefony/http": "^10.0.0-alpha.9",
+    "@nodefony/orm-core": "^10.0.0-alpha.9",
+    "@nodefony/security": "^10.0.0-alpha.9",
+    "@nodefony/user": "^10.0.0-alpha.9",
     "better-sqlite3": "^13.0.0",
     "mysql2": "^3.24.0",
-    "nodefony": "^10.0.0-alpha.8",
+    "nodefony": "^10.0.0-alpha.9",
     "pg": "^8.23.0"
   },
   "repository": {