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

package/dist/types/nodefony/entity/userTable.d.ts

@@ -1,16 +1,59 @@
-import type { SQLiteTable } from "drizzle-orm/sqlite-core";
+import type { AnySQLiteColumn, SQLiteTable } from "drizzle-orm/sqlite-core";
+import type { AnyPgColumn, PgTable } from "drizzle-orm/pg-core";
+import type { AnyMySqlColumn, MySqlTable } from "drizzle-orm/mysql-core";
 import type { IEntity } from "@nodefony/orm-core";
 import type { SqlDialect } from "../interfaces/IDrizzleConfig.js";
+/**
+ * Factory de la table `User` — comme {@link FrameworkTableFactory}, mais sa clé
+ * primaire reste ATTEIGNABLE au type.
+ *
+ * 🔴 Sans cela, une application ne peut pas RÉFÉRENCER l'utilisateur, et c'est
+ * la première relation que quiconque écrit : `create entity Message
+ * "author:ref(User)"` rend `.references(() => userTable.id)`, qui ne compilait
+ * pas (`TS2339: Property 'id' does not exist on type 'SQLiteTable<TableConfig>'`).
+ * La table est bâtie depuis une spec dont les colonnes sont calculées
+ * (`Object.fromEntries`) : l'inférence les perd, et le type rendu ne porte plus
+ * aucune colonne — alors qu'elles existent toutes à l'exécution.
+ *
+ * Cette précision reste LOCALE à `User`, et n'est pas remontée dans le colKit :
+ * les tables du framework n'ont pas toutes une colonne `id` (`session` et
+ * `idempotency_key` portent une autre clé), donc l'y déclarer mentirait sur
+ * elles. `tests/unit/userTableReference.test.ts` garde le fait — par sa
+ * COMPILATION, qu'un cas d'exécution ne pourrait pas prouver.
+ */
+export interface UserTableFactory {
+    (dialect: "sqlite"): SQLiteTable & {
+        readonly id: AnySQLiteColumn;
+    };
+    (dialect: "postgres"): PgTable & {
+        readonly id: AnyPgColumn;
+    };
+    (dialect: "mysql"): MySqlTable & {
+        readonly id: AnyMySqlColumn;
+    };
+    (dialect?: SqlDialect): (SQLiteTable & {
+        readonly id: AnySQLiteColumn;
+    }) | (PgTable & {
+        readonly id: AnyPgColumn;
+    }) | (MySqlTable & {
+        readonly id: AnyMySqlColumn;
+    });
+}
 /**
  * Factory de la table `User` pour un dialecte donné (mémoïsée — une instance
  * par dialecte). Les trois dialectes sont portés (`sqlite` par défaut).
  */
-export declare const createUserTable: import("./colKit.js").FrameworkTableFactory;
+export declare const createUserTable: UserTableFactory;
 /**
  * Variante SQLite de la table `User` (dialecte par défaut) — export conservé
  * pour l'usage direct/banc-test (ex. module mediasoup).
+ *
+ * Son type n'est PAS réécrit en `SQLiteTable` : l'annoter ainsi effaçait la
+ * clé primaire que la factory vient d'exposer, et c'était la moitié du défaut.
  */
-export declare const userTable: SQLiteTable;
+export declare const userTable: SQLiteTable<import("drizzle-orm/sqlite-core").TableConfig> & {
+    readonly id: AnySQLiteColumn;
+};
 /**
  * Forme plate d'une ligne `User` renvoyée par le repository de base — le contrat
  * `IUserRow` de `@nodefony/user`, ré-exporté sous son nom historique.

package/dist/types/nodefony/registerStores.d.ts

@@ -1,3 +1,4 @@
+import { FRAMEWORK_CONNECTOR } from "./src/frameworkConnector.js";
 import type { SqlDialect } from "./config/config.js";
 /**
  * AUTO-ENREGISTREMENT des backends framework portés par Drizzle — « charger le
@@ -20,10 +21,10 @@ import type { SqlDialect } from "./config/config.js";
  * boot (« store inconnu ») — jamais de table fantôme ni d'erreur SQL différée.
  */
 /**
- * Connecteur conventionnel qui héberge le schéma framework (même convention que
- * `SESSION_CONNECTOR` : `"default"` pour Drizzle, `"nodefony"` pour Mongoose).
+ * Connecteur conventionnel qui héberge le schéma framework — défini dans
+ * `src/frameworkConnector.ts`, que les migrations lisent aussi.
  */
-export declare const FRAMEWORK_CONNECTOR = "default";
+export { FRAMEWORK_CONNECTOR };
 /** Bilan de l'auto-enregistrement (loggé par le module — jamais silencieux). */
 export interface IFrameworkStoresReport {
     /** Entités déclarées par l'auto-register (tables créées au connect). */

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

@@ -47,6 +47,12 @@ export declare class DrizzleAuditStore implements IAuditStore {
      * — lu par `readStoreLocation`. `undefined` = backend réseau ou `:memory:`.
      */
     get location(): string | undefined;
+    /**
+     * Connecteur ORM qui porte ce store, lu par `readStoreConnector` pour le
+     * registre des stores : la console rattache la brique à SON connecteur au
+     * lieu de le déduire. `undefined` pour un store construit sans ORM (bancs).
+     */
+    get connector(): string | undefined;
     /**
      * Construit le store depuis un {@link DrizzleOrm}. Le handle est résolu **lazy**
      * (gardé par `isConnected()` → `null` tant que l'ORM n'est pas/plus connecté).

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

@@ -73,8 +73,9 @@ export declare class DrizzleIdempotencyStore implements IIdempotencyStore {
      *   base ({@link DrizzleOrm.location}) pour Studio. Lazy (comme `resolveDb`) car
      *   le store est fabriqué AVANT le connect de l'ORM → l'emplacement n'est lisible
      *   qu'une fois l'ORM enregistré (lu au `onReady`, pas à la construction).
+     * @param connector - connecteur ORM qui porte la table, publié au registre des stores.
      */
-    constructor(resolveDb: () => DrizzleDb | null, now?: () => number, leaseMs?: number, ttlMs?: number, table?: DrizzleTable, resolveLocation?: () => string | undefined);
+    constructor(resolveDb: () => DrizzleDb | null, now?: () => number, leaseMs?: number, ttlMs?: number, table?: DrizzleTable, resolveLocation?: () => string | undefined, connector?: string);
     /**
      * Emplacement physique de la base (fichier SQLite) pour l'écran Studio « Stores »
      * — lu par `readStoreLocation`. Résolu **lazy** (l'ORM n'existe pas à la
@@ -82,6 +83,12 @@ export declare class DrizzleIdempotencyStore implements IIdempotencyStore {
      * ou sur un backend réseau (pg/mysql → voir l'infra déclarée).
      */
     get location(): string | undefined;
+    /**
+     * Connecteur ORM qui porte ce store, lu par `readStoreConnector` pour le
+     * registre des stores : la console rattache la brique à SON connecteur au
+     * lieu de le déduire. `undefined` pour un store construit sans ORM (bancs).
+     */
+    get connector(): string | undefined;
     /**
      * Construit le store depuis un {@link DrizzleOrm}. Le handle est résolu **lazy**
      * (gardé par `isConnected()` → `null` tant que l'ORM n'est pas/plus connecté).

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

@@ -46,6 +46,12 @@ export declare class DrizzleTokenStore implements ITokenStore {
      * — lu par `readStoreLocation`. `undefined` = backend réseau ou `:memory:`.
      */
     get location(): string | undefined;
+    /**
+     * Connecteur ORM qui porte ce store, lu par `readStoreConnector` pour le
+     * registre des stores : la console rattache la brique à SON connecteur au
+     * lieu de le déduire. `undefined` pour un store construit sans ORM (bancs).
+     */
+    get connector(): string | undefined;
     /**
      * Construit le store depuis un {@link DrizzleOrm} connecté. Les entités
      * (`registerTokenEntities`) doivent avoir été enregistrées **avant**

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

@@ -35,6 +35,12 @@ export declare class DrizzleTotpSecretStore implements ITotpSecretStore {
      * — lu par `readStoreLocation`. `undefined` = backend réseau ou `:memory:`.
      */
     get location(): string | undefined;
+    /**
+     * Connecteur ORM qui porte ce store, lu par `readStoreConnector` pour le
+     * registre des stores : la console rattache la brique à SON connecteur au
+     * lieu de le déduire. `undefined` pour un store construit sans ORM (bancs).
+     */
+    get connector(): string | undefined;
     /**
      * Construit le store depuis un {@link DrizzleOrm} connecté. L'entité
      * (`registerTotpSecretEntity`) doit avoir été enregistrée **avant** `orm.connect()`.

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

@@ -34,6 +34,12 @@ export declare class DrizzleWebAuthnCredentialStore implements IWebAuthnCredenti
      * — lu par `readStoreLocation`. `undefined` = backend réseau ou `:memory:`.
      */
     get location(): string | undefined;
+    /**
+     * Connecteur ORM qui porte ce store, lu par `readStoreConnector` pour le
+     * registre des stores : la console rattache la brique à SON connecteur au
+     * lieu de le déduire. `undefined` pour un store construit sans ORM (bancs).
+     */
+    get connector(): string | undefined;
     /**
      * Construit le store depuis un {@link DrizzleOrm} connecté. L'entité
      * (`registerWebAuthnCredentialEntity`) doit avoir été enregistrée **avant**

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

@@ -51,6 +51,12 @@ export declare class DrizzleWebhookStore implements IWebhookStore {
      * — lu par `readStoreLocation`. `undefined` = backend réseau ou `:memory:`.
      */
     get location(): string | undefined;
+    /**
+     * Connecteur ORM qui porte ce store, lu par `readStoreConnector` pour le
+     * registre des stores : la console rattache la brique à SON connecteur au
+     * lieu de le déduire. `undefined` pour un store construit sans ORM (bancs).
+     */
+    get connector(): string | undefined;
     /**
      * Construit le store depuis un {@link DrizzleOrm} connecté. L'entité
      * (`registerWebhookEndpointEntity`) doit avoir été enregistrée **avant**

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

@@ -31,6 +31,12 @@ declare class SessionStorage implements ISessionStorage {
      * DÉFENSIVE (getter `location` optionnel) — l'ORM base `IOrm` ne l'expose pas.
      */
     get location(): string | undefined;
+    /**
+     * Connecteur ORM qui porte les sessions — lu par `readStoreConnector` pour le
+     * registre des stores. `undefined` tant que l'ORM de ce connecteur n'est pas
+     * enregistré : on ne publie pas un rattachement que rien ne porte.
+     */
+    get connector(): string | undefined;
     read(id: string): Promise<ISerializedSession>;
     start(id: string): Promise<ISerializedSession>;
     write(id: string, data: ISerializedSession): Promise<ISerializedSession>;

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

@@ -0,0 +1,24 @@
+/**
+ * Connecteur conventionnel qui héberge le schéma framework (même convention que
+ * `SESSION_CONNECTOR` : `"default"` pour Drizzle, `"nodefony"` pour Mongoose).
+ *
+ * Vit dans ce fichier sans dépendance parce que DEUX familles le lisent : le
+ * registre des stores (où résoudre les briques du framework) et les migrations
+ * (qui les reçoit). Une copie du littéral de chaque côté dériverait en silence.
+ */
+export declare const FRAMEWORK_CONNECTOR = "default";
+/**
+ * Ce connecteur possède-t-il les migrations du framework et de l'application ?
+ *
+ * **Seul le connecteur du framework les possède.** Le dossier des migrations de
+ * l'application (`migrations/<dialect>`) ne porte aucune notion de connecteur :
+ * il décrit UNE base, celle où vivent les briques du framework et les entités
+ * de l'application. Les attribuer à tout connecteur faisait qu'une base
+ * secondaire (analyse, base d'un module) en mode `migrate` y créait des tables
+ * qui ne lui appartiennent pas, et qu'en mode `auto` elle annonçait à chaque
+ * démarrage des migrations qui ne la concernent pas.
+ *
+ * @param connector - nom du connecteur (clé de `connectors`).
+ * @returns `true` pour le connecteur du framework, `false` pour tout autre.
+ */
+export declare function ownsSharedMigrations(connector: string): boolean;

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/explain.d.ts

@@ -422,3 +422,22 @@ export declare function refusalInMode(code: IMigrationVerdict["code"], ddl: stri
     meaning: string;
     actions: IMigrationAction[];
 } | null;
+/**
+ * L'échec vient-il de ce que la base est DÉJÀ dans l'état que la migration vise ?
+ *
+ * Le cas est fréquent et sa sortie n'était nommée nulle part : le message de
+ * reprise proposait de corriger le fichier ou de travailler sur une base
+ * d'essai, deux voies qui ne mènent à rien quand le fichier est juste et la
+ * base déjà conforme. Un agent placé devant ce refus tourne alors en rond
+ * — `repair` lève le marqueur, `migrate` rejoue, le moteur redit la même
+ * chose — puis finit par recréer la base, ce qui emporte les données.
+ *
+ * Constaté sur un agent tiers : un `DROP INDEX messages_content_unique` sur une
+ * base dont l'unicité avait été posée INLINE par le DDL de démarrage, donc sans
+ * index nommé. Trente-cinq minutes, deux bases détruites, la boucle brisée à la
+ * main.
+ *
+ * @param message - le message d'erreur rendu par le moteur.
+ * @returns `true` si l'échec dit « c'est déjà ainsi ».
+ */
+export declare function alreadyInTargetState(message: string): boolean;

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

@@ -50,6 +50,25 @@ export declare function readMigrationEnv(kernel: Kernel | null): IMigrationEnv;
  * @returns `true` si `orm:reset` est recevable.
  */
 export declare function resetAllowed(env: IMigrationEnv): boolean;
+/**
+ * `orm:generate --apply` est-il recevable dans cet environnement ?
+ *
+ * Écrire une migration et l'appliquer dans le même souffle suppose qu'on relit
+ * le SQL produit entre les deux — ce que personne ne fait sur un serveur.
+ * Ailleurs qu'en développement, la migration a été écrite, relue et versionnée
+ * en amont : `orm:migrate` l'applique, et lui seul. Aucun drapeau ne lève ce
+ * refus, pour la même raison que {@link resetAllowed} n'en a pas.
+ *
+ * Même forme que `resetAllowed`, et c'est voulu : les deux disent « geste de
+ * développement », et deux rédactions de la même condition finiraient par
+ * diverger sans que rien ne le signale.
+ *
+ * @param env - environnement constaté.
+ * @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.
  *
@@ -62,11 +81,70 @@ export declare function resetAllowed(env: IMigrationEnv): boolean;
  * - tout le reste → `none` : personne ne touche au schéma au démarrage, un
  *   travail externe applique les migrations avant que le trafic n'arrive.
  *
+ * 🔴 **Une application qui VERSIONNE des migrations bascule en `migrate`, même
+ * en développement.** Deux fabricants du même schéma ne s'accordent pas, et
+ * rien ne le signale tant qu'on ne les fait pas se rencontrer : le DDL dérivé
+ * pose une contrainte d'unicité INLINE et anonyme (`content text NOT NULL
+ * UNIQUE`), là où le générateur de migrations raisonne sur un index NOMMÉ
+ * (`messages_content_unique`). La migration suivante émet alors un
+ * `DROP INDEX` d'un index qui n'a jamais existé, échoue sur `no such index`,
+ * inscrit son marqueur — et la réparation ne peut rien y faire, puisque le
+ * fichier est inapplicable. Vécu sur un agent tiers : trente-cinq minutes de
+ * `repair`/`baseline`/`reset`, deux bases détruites, la boucle brisée à la main.
+ * La condition est délibérément « l'application EN A », pas « elle en a en
+ * attente » : dès la première migration écrite, le schéma leur appartient.
+ * Elle est bornée au développement RÉEL, jamais à `NODE_ENV=test` : une suite
+ * lance un exemplaire par worker, et appliquer des migrations depuis plusieurs
+ * processus au démarrage est précisément ce que la règle ci-dessus refuse.
+ * Un `ddl` écrit dans la configuration gagne toujours — c'est un choix, pas une
+ * déduction.
+ *
  * @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): DdlMode;
+export declare function resolveDdlMode(explicit: DdlMode | undefined, env: IMigrationEnv, appHasMigrations?: boolean, volatile?: boolean): DdlMode;
+/**
+ * L'application versionne-t-elle au moins une migration ?
+ *
+ * Lecture SYNCHRONE et bornée à un `readdirSync` par connecteur au démarrage —
+ * hors de tout chemin de requête. Elle doit l'être : le mode de schéma se
+ * décide avant la connexion, et le rendre asynchrone propagerait un `await`
+ * dans toute la chaîne de résolution pour une réponse qui ne change jamais
+ * pendant la vie du processus.
+ *
+ * Un dossier absent, illisible ou vide répond `false` — l'application n'a alors
+ * rien à appliquer, et `auto` reste le bon défaut de démarrage rapide.
+ *
+ * @param dir - dossier de migrations de l'application ({@link appMigrationsDir}).
+ * @returns `true` si au moins un fichier `.sql` y est versionné, à un niveau
+ *   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.
  *
@@ -80,6 +158,24 @@ export declare function resolveDdlMode(explicit: DdlMode | undefined, env: IMigr
  * @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 ?
      *