@nodefony/drizzle 10.0.0-alpha.1

package/dist/types/nodefony/command/migrateShared.d.ts

@@ -0,0 +1,137 @@
+import { Command, type CliKernel } from "nodefony";
+import type { IDrizzleConfig } from "../interfaces/IDrizzleConfig.js";
+import type { DrizzleMigrator } from "../src/migrator/DrizzleMigrator.js";
+import { MigrationVerdictError } from "../src/migrator/types.js";
+import type { IMigrationAction } from "../src/migrator/types.js";
+import { type IMigrationReport, type IStyle } from "../src/migrator/explain.js";
+import type { IMigrationPlan } from "../src/migrator/types.js";
+import { type IConnectorResolution } from "../src/migrator/resolve.js";
+import { type CommandFailureCode, type IDiscoveryFacts } from "../src/migrator/refusals.js";
+export type { ICommandFailure } from "../src/migrator/refusals.js";
+/** Options communes à toutes les commandes de migration. */
+export interface IMigrateSharedOptions {
+    connector?: string;
+    json?: boolean;
+}
+/**
+ * Classe de base des commandes `orm:*`.
+ *
+ * Elle n'impose rien du verbe : chaque commande écrit son `generate`. Elle
+ * impose la FORME de ce qui sort, parce que c'est cette forme qui fait la
+ * différence entre un outil qu'on sait utiliser et un outil qu'on subit.
+ */
+export declare abstract class OrmMigrateCommand extends Command {
+    /**
+     * Faut-il colorer la sortie ?
+     *
+     * 🔴 La question n'est PAS « est-ce un terminal ? », et la confondre avec ça
+     * a deux conséquences que personne ne signale :
+     *
+     * - **`NO_COLOR` est ignoré.** C'est une convention publique
+     *   (no-color.org) qu'un utilisateur pose une fois pour toutes ses commandes ;
+     *   la manquer rend une sortie illisible sur un terminal à palette
+     *   inhabituelle, et le framework passe pour cassé.
+     * - **`FORCE_COLOR` est ignoré.** Sans lui, aucune sortie colorée n'est
+     *   CAPTURABLE : ni dans un fichier, ni dans une passe d'intégration continue
+     *   qui sait rendre les couleurs, ni dans un rapport de validation. On ne peut
+     *   alors pas relire ce que l'exploitant voit vraiment.
+     *
+     * La règle vit au CŒUR (`resolveColorEnabled`), qui sert déjà les journaux :
+     * la réécrire ici en ferait une SECONDE implémentation, et les deux
+     * divergeraient — le journal obéirait à `NO_COLOR`, la commande non.
+     */
+    protected get tty(): boolean;
+    /** Mise en forme, neutralisée hors terminal. */
+    protected get style(): IStyle;
+    /**
+     * Configuration validée du module qui porte les connecteurs SQL.
+     *
+     * @returns la configuration, ou `null` si le module n'est pas chargé.
+     */
+    protected drizzleConfig(): IDrizzleConfig | null;
+    /**
+     * Écrit une charge utile sur la sortie standard et pose le code de sortie.
+     *
+     * `process.exitCode` et jamais `process.exit()` : couper le processus laisse
+     * la sortie standard non vidée, et un `| jq` reçoit alors un objet tronqué —
+     * un échec qui ressemble à un défaut de la commande.
+     *
+     * @param payload - l'objet, en mode machine.
+     * @param human - le texte, en mode humain.
+     * @param exitCode - `0`, `1` ou `2`.
+     * @param json - la commande a-t-elle reçu `--json` ?
+     */
+    protected respond(payload: unknown, human: string, exitCode: number, json: boolean | undefined): void;
+    /**
+     * Arrête la commande en disant le fait, la cause et le geste.
+     *
+     * @param connector - connecteur concerné (ou le nom demandé).
+     * @param code - code d'arrêt stable, lu par les machines.
+     * @param summary - le fait, en français.
+     * @param meaning - ce que ça veut dire.
+     * @param actions - les commandes exactes à copier.
+     * @param json - la commande a-t-elle reçu `--json` ?
+     * @param exitCode - `2` par défaut : la commande n'a pas pu travailler.
+     * @param discovery - ce que la découverte des entités a vu, quand le refus
+     *   peut avoir pour cause un schéma déclaré amputé.
+     */
+    protected fail(connector: string, code: CommandFailureCode | MigrationVerdictError["verdict"]["code"], summary: string, meaning: string, actions: IMigrationAction[], json: boolean | undefined, exitCode?: 1 | 2, discovery?: IDiscoveryFacts): void;
+    /**
+     * Résout le connecteur demandé, ou ARRÊTE la commande en le disant.
+     *
+     * Les **trois** réponses sont un contrat public, et elles restent distinctes :
+     * un connecteur inconnu, un connecteur porté par un ORM sans migrations, un
+     * connecteur prêt. Le jour où un second ORM apporte ses propres migrations,
+     * seule la deuxième cesse de sortir pour ses connecteurs — répondre « ne
+     * porte pas de migrations » à un connecteur qui en porte serait un message
+     * FAUX, et un message faux publié est appris par les scripts qui le lisent.
+     *
+     * @param opts - options de la commande (connecteur, mode machine).
+     * @param allowMigrateUrl - la commande honore-t-elle {@link MIGRATE_URL_ENV} ?
+     * @returns le connecteur prêt, ou `null` si la commande est déjà arrêtée.
+     */
+    protected resolveOrFail(opts: IMigrateSharedOptions, allowMigrateUrl: boolean): {
+        resolution: Extract<IConnectorResolution, {
+            kind: "ready";
+        }>;
+        config: IDrizzleConfig;
+    } | null;
+    /**
+     * Construit l'applicateur d'un connecteur résolu.
+     *
+     * @param resolution - connecteur prêt.
+     * @param config - configuration validée.
+     * @returns l'applicateur, sources chargées.
+     */
+    protected migrator(resolution: Extract<IConnectorResolution, {
+        kind: "ready";
+    }>, config: IDrizzleConfig): Promise<DrizzleMigrator>;
+    /**
+     * Compose la charge utile d'un état.
+     *
+     * L'assemblage lui-même vit dans `migrator/status.ts` : le plan
+     * d'administration publie le MÊME objet, et deux assemblages divergeaient
+     * d'un champ à l'autre sans qu'aucun test ne le voie.
+     *
+     * @param plan - plan calculé par l'applicateur, en lecture seule.
+     * @param resolution - connecteur prêt (porte le mode de schéma effectif).
+     * @param config - configuration validée du module.
+     * @returns la charge utile, prête pour `--json` comme pour l'écran.
+     */
+    protected report(plan: IMigrationPlan, resolution: Extract<IConnectorResolution, {
+        kind: "ready";
+    }>, config: IDrizzleConfig): Promise<IMigrationReport>;
+    protected failFrom(e: unknown, connector: string, json: boolean | undefined, ddl?: string): void;
+    /**
+     * Écrit un état lu et pose son code de sortie.
+     *
+     * @param report - charge utile complète.
+     * @param human - rendu humain déjà composé.
+     * @param json - la commande a-t-elle reçu `--json` ?
+     */
+    protected emitReport(report: IMigrationReport, human: string, json: boolean | undefined): void;
+    /** Déclare les deux options que toutes les commandes de migration portent. */
+    protected addSharedOptions(): void;
+    /** Le CLI courant, typé — utilisé pour les réglages de boot silencieux. */
+    protected get cliKernel(): CliKernel;
+}

package/dist/types/nodefony/command/orm-generate.d.ts

@@ -0,0 +1,53 @@
+import { type CliKernel } from "nodefony";
+import { OrmMigrateCommand, type IMigrateSharedOptions } from "./migrateShared.js";
+/** Options propres à `orm:generate`. */
+interface IGenerateOptions extends IMigrateSharedOptions {
+    name?: string;
+    custom?: boolean;
+    allowDestructive?: boolean;
+}
+/**
+ * `nodefony orm:generate` — écrit la migration qui fera passer la base au
+ * schéma que décrivent les entités de l'application.
+ *
+ * ## Ce que l'utilisateur n'a pas à connaître
+ *
+ * Rien de `drizzle-kit`. Ni son installation, ni sa configuration par dialecte,
+ * ni la notion de « schéma matérialisé », ni son dossier de sortie, ni le format
+ * de son journal. Il tape un verbe et un nom. La commande découvre les fichiers
+ * d'entités par la convention du générateur, écrit ce qu'il faut dans un dossier
+ * de travail qu'elle efface ensuite, et pilote l'outil — dont elle EXIGE la
+ * preuve qu'il a travaillé, parce qu'il rend 0 même quand il échoue.
+ *
+ * ## Ce qu'elle refuse, et pourquoi elle le refuse plutôt que de continuer
+ *
+ * Une migration est **immuable une fois appliquée**. Une migration amputée n'est
+ * pas un désagrément qu'on rattrape à la génération suivante : elle grave dans
+ * l'historique une table qui n'existera jamais, et toute base qui l'a reçue
+ * restera incomplète. Trois situations valent donc un arrêt qui NOMME :
+ *
+ * - un fichier d'entité qui ne s'importe pas (le schéma serait incomplet) ;
+ * - une entité enregistrée qu'aucun fichier ne fournit (idem, et c'est le
+ *   contrôle que le registre est le seul à pouvoir faire) ;
+ * - un fichier de l'application qui fournit une table du FRAMEWORK — la
+ *   migration porterait un second `CREATE TABLE` de cette table, qui échoue sur
+ *   toute base déjà migrée, c'est-à-dire en production et nulle part ailleurs.
+ *
+ * @example Le cas courant
+ * ```bash
+ * nodefony orm:generate --name ajout_du_titre
+ * nodefony orm:migrate        # ou : le travail de déploiement
+ * ```
+ *
+ * @example Ce que le modèle déclaratif ne peut pas déduire
+ * ```bash
+ * nodefony orm:generate --custom --name vue_des_ventes
+ * # → un fichier SQL vide, déjà inscrit au journal : à écrire à la main.
+ * ```
+ */
+declare class OrmGenerate extends OrmMigrateCommand {
+    #private;
+    constructor(cli: CliKernel);
+    generate(opts?: IGenerateOptions): Promise<this>;
+}
+export default OrmGenerate;

package/dist/types/nodefony/command/orm-migrate-baseline.d.ts

@@ -0,0 +1,87 @@
+import type { CliKernel } from "nodefony";
+import { MIGRATION_FORMAT_VERSION, action } from "../src/migrator/explain.js";
+import { OrmMigrateCommand, type IMigrateSharedOptions } from "./migrateShared.js";
+/** Options propres à l'adoption d'une base existante. */
+interface IBaselineOptions extends IMigrateSharedOptions {
+    upTo?: string;
+    fromDatabase?: boolean;
+    name?: string;
+}
+/**
+ * `nodefony orm:migrate:baseline` — déclare une base existante « à niveau »,
+ * SANS exécuter une seule instruction de schéma.
+ *
+ * ## Quand on en a besoin
+ *
+ * La base contient déjà les tables — parce qu'on branche Nodefony sur une base
+ * qui existait avant, ou parce que le schéma a été créé autrement (mode `auto`
+ * en développement) — mais aucune migration n'y est enregistrée. Appliquer les
+ * migrations dans cet état exécuterait des créations de tables qui existent
+ * déjà, et échouerait.
+ *
+ * ## Pourquoi ce n'est PAS automatique
+ *
+ * Adopter tout seul retirerait le filet qui protège de la pire erreur : se
+ * tromper de base. Une adresse de base héritée d'un autre environnement, et
+ * l'outil déclarerait « à niveau » une base qui n'a rien à voir — puis
+ * appliquerait dessus les migrations suivantes. La documentation de Flyway
+ * elle-même met en garde contre son propre mode automatique pour cette raison.
+ *
+ * **Vérifie que c'est la bonne base avant de taper cette commande.** Elle ne
+ * modifie pas le schéma, mais elle change ce que le framework CROIT du schéma —
+ * et tout le reste en découle.
+ *
+ * ## Ce qu'elle fait exactement
+ *
+ * Elle inscrit dans l'historique, comme appliquées avec succès et une durée
+ * nulle, les migrations qui n'y sont pas encore. Rejouée, elle n'inscrit que ce
+ * qui manque : elle est donc sûre à relancer.
+ *
+ * ## Ce qu'elle REFUSE
+ *
+ * Adopter, c'est affirmer que la base est à l'état que décrivent ces
+ * migrations. Quand la base s'écarte du schéma déclaré, l'affirmation serait
+ * fausse — et une affirmation fausse gravée dans l'historique n'est rattrapable
+ * par aucune commande. La commande constate donc la base AVANT d'écrire, et
+ * refuse (`NF_MIGRATE_BASELINE_AMBIGUOUS`) en nommant ce qui manque.
+ *
+ * Trois cas y échappent, et pour la même raison — la garde n'a plus rien à
+ * deviner : `--up-to`, qui borne l'adoption explicitement ; `--from-database`,
+ * dont la référence DÉCRIT la base et rend donc l'affirmation vraie par
+ * construction ; et une cible détournée par `NF_MIGRATE_DATABASE_URL`, où la
+ * comparaison porterait sur la base de la configuration et non sur celle qu'on
+ * migre.
+ *
+ * ## Une base qui n'a JAMAIS eu de migrations — `--from-database`
+ *
+ * Adopter suppose des fichiers à inscrire. Une application passée du mode
+ * dérivé, où le démarrage fabrique le schéma, au mode de production n'en a
+ * aucun : sa base porte tout, son dossier de migrations est vide. Sans
+ * référence, la première génération décrirait ce que le CODE déclare — un
+ * schéma que cette base n'a peut-être jamais eu, si quelqu'un vient de changer
+ * une entité — et l'inscrire graverait une affirmation fausse.
+ *
+ * `--from-database` LIT le schéma de la base et en écrit la migration de
+ * référence, puis l'inscrit. Rien n'est exécuté sur la base. La suite redevient
+ * ordinaire : le champ ajouté produit un `ALTER TABLE`.
+ *
+ * @example Adopter jusqu'à une migration précise
+ * ```bash
+ * nodefony orm:migrate:baseline --up-to 0003_audit_severity
+ * nodefony orm:migrate            # applique la suite normalement
+ * ```
+ *
+ * @example Reprendre une base qui existait avant toute migration
+ * ```bash
+ * nodefony orm:migrate:baseline --from-database   # la référence est LUE sur la base
+ * nodefony orm:generate --name ajout_du_slug      # produit un ALTER, plus un CREATE
+ * nodefony orm:migrate                            # applique
+ * ```
+ */
+declare class OrmMigrateBaseline extends OrmMigrateCommand {
+    #private;
+    constructor(cli: CliKernel);
+    generate(opts?: IBaselineOptions): Promise<this>;
+}
+export default OrmMigrateBaseline;
+export { MIGRATION_FORMAT_VERSION, action };

package/dist/types/nodefony/command/orm-migrate-repair.d.ts

@@ -0,0 +1,66 @@
+import type { CliKernel } from "nodefony";
+import { OrmMigrateCommand, type IMigrateSharedOptions } from "./migrateShared.js";
+/** Options propres à la réparation de l'historique. */
+interface IRepairOptions extends IMigrateSharedOptions {
+    source?: string;
+    updateHashes?: boolean;
+    forget?: string[];
+}
+/**
+ * `nodefony orm:migrate:repair` — lève les marqueurs d'échec, **après**
+ * inspection humaine.
+ *
+ * ## Ce que « réparer » veut dire ici, et ce que ça ne veut pas dire
+ *
+ * Cette commande **ne répare pas la base**. Elle efface la trace d'une
+ * migration qui n'a pas abouti, pour que l'applicateur accepte de reprendre.
+ * C'est une déclaration : « j'ai regardé la base, elle est dans l'état que je
+ * crois ».
+ *
+ * Pourquoi ce n'est pas automatique : quand une migration s'arrête en cours de
+ * route, l'état laissé dépend de la base. PostgreSQL et SQLite annulent la
+ * migration fautive entière — l'état est net. MySQL valide chaque instruction
+ * de schéma au fur et à mesure, sans retour possible : la moitié des
+ * changements peut être en place. Aucun programme ne peut décider à la place
+ * d'un humain si cette moitié est acceptable.
+ *
+ * **L'ordre des gestes, et il ne s'inverse pas :**
+ *
+ * 1. `nodefony orm:migrate:status --json` — voir ce qui a échoué et pourquoi ;
+ * 2. regarder la base elle-même, et la remettre d'aplomb si besoin ;
+ * 3. `nodefony orm:migrate:repair` — lever le marqueur ;
+ * 4. `nodefony orm:migrate` — reprendre.
+ *
+ * ## `--update-hashes` : à ne taper que sur instruction d'un message
+ *
+ * Ré-aligner les empreintes déclare que les fichiers modifiés APRÈS avoir été
+ * appliqués sont réputés conformes. C'est presque toujours faux : les autres
+ * bases ont reçu l'ancienne version et ne recevront jamais la nouvelle. Le
+ * geste normal face à un fichier modifié est de le restaurer
+ * (`git checkout -- migrations/`) et d'écrire une NOUVELLE migration.
+ *
+ * L'option existe pour le cas où l'on sait que la modification était sans effet
+ * — une reformulation, un commentaire. Elle ne touche jamais la base.
+ *
+ * ## `--forget <source>/<tag>` : l'issue d'un historique qui MENT
+ *
+ * Il existait un état dont aucune commande ne sortait : une migration inscrite
+ * comme réussie que personne n'a jamais exécutée — une adoption mal bornée, ou
+ * une base héritée d'une version antérieure aux gardes. La base ne porte pas
+ * les tables, l'historique affirme le contraire, et rien n'est « en attente ».
+ * Le générateur disait alors « c'est l'historique qu'il faut reprendre » et
+ * renvoyait ici ; mais cette commande ne savait lever que des marqueurs
+ * d'ÉCHEC, et répondait « rien à réparer ». Trois messages vrais, aucun geste
+ * — et le seul chemin restant était de détruire la base.
+ *
+ * `--forget` désinscrit UNE entrée nommée, pour qu'elle soit rejouée au
+ * passage suivant. Bornée par construction : il faut la nommer
+ * (`--forget app/0003_ajout_facture`), il n'y a ni motif ni lot. La base n'est
+ * pas touchée — si la migration avait réellement été appliquée, son rejeu
+ * échouera, bruyamment, ce qui est le comportement voulu.
+ */
+declare class OrmMigrateRepair extends OrmMigrateCommand {
+    constructor(cli: CliKernel);
+    generate(opts?: IRepairOptions): Promise<this>;
+}
+export default OrmMigrateRepair;

package/dist/types/nodefony/command/orm-migrate-status.d.ts

@@ -0,0 +1,38 @@
+import type { CliKernel } from "nodefony";
+import { OrmMigrateCommand, type IMigrateSharedOptions } from "./migrateShared.js";
+/**
+ * `nodefony orm:migrate:status` — dit ce que la base a reçu, ce qui reste, et
+ * ce qu'il faut taper.
+ *
+ * **Lecture seule et sans verrou.** Elle n'écrit rien, pas même la table
+ * d'historique : un état qui se consulte ne doit pas modifier ce qu'il
+ * observe — et une sonde qui écrit dans la base n'est plus une sonde.
+ *
+ * ## Son autre métier : barrière d'intégration continue
+ *
+ * Le code de sortie porte le verdict, et il ne changera jamais de sens :
+ *
+ * | Code | Ce que ça veut dire                                                |
+ * | ---- | ------------------------------------------------------------------ |
+ * | `0`  | à jour — rien à faire                                              |
+ * | `1`  | une action humaine est requise (migrations en attente, écart, échec) |
+ * | `2`  | la commande n'a pas pu travailler (base injoignable, verrou, usage) |
+ *
+ * Une passe de déploiement peut donc s'arrêter dessus sans lire un mot :
+ *
+ * ```bash
+ * nodefony orm:migrate:status --json || exit 1
+ * ```
+ *
+ * @example Ce qu'un agent lit
+ * ```bash
+ * nodefony orm:migrate:status --json | jq -r '.verdict, .nextActions[0].command'
+ * # pending
+ * # nodefony orm:migrate
+ * ```
+ */
+declare class OrmMigrateStatus extends OrmMigrateCommand {
+    constructor(cli: CliKernel);
+    generate(opts?: IMigrateSharedOptions): Promise<this>;
+}
+export default OrmMigrateStatus;

package/dist/types/nodefony/command/orm-migrate.d.ts

@@ -0,0 +1,65 @@
+import type { CliKernel } from "nodefony";
+import { EXIT, action } from "../src/migrator/explain.js";
+import { OrmMigrateCommand, type IMigrateSharedOptions } from "./migrateShared.js";
+/**
+ * Options propres à l'application des migrations.
+ *
+ * Pas de `--source` ici, et c'est délibéré : l'applicateur applique l'ordre
+ * complet (le framework d'abord, l'application ensuite) et n'a pas de filtre
+ * par source. Déclarer l'option pour l'ignorer serait pire qu'un refus — un
+ * argument accepté puis jeté fait croire à un comportement qui n'existe pas.
+ */
+interface IMigrateOptions extends IMigrateSharedOptions {
+    dryRun?: boolean;
+    outOfOrder?: boolean;
+    ignoreMissing?: boolean;
+    allowDestructive?: boolean;
+}
+/**
+ * `nodefony orm:migrate` — applique les migrations restantes, sous verrou.
+ *
+ * ## Ce que la commande fait, dans cet ordre exact
+ *
+ * 1. **prend le verrou** de la base (verrou natif du serveur : il se libère
+ *    tout seul si le processus meurt — aucun verrou fantôme à débloquer à la
+ *    main) ;
+ * 2. **crée la table d'historique** si elle n'existe pas ;
+ * 3. **valide TOUT** — empreintes, ordre, échecs passés, fichiers manquants ;
+ * 4. **applique** les migrations une par une, chacune dans sa transaction là où
+ *    la base le permet.
+ *
+ * La validation précède toute écriture : **un refus laisse la base
+ * intacte**. C'est ce qui rend sûr de relancer la commande après un refus.
+ *
+ * ## Elle ne s'exécute jamais toute seule au démarrage — sauf si on le demande
+ *
+ * Appliquer des migrations au démarrage n'est pas un défaut, et ce n'est pas de
+ * la prudence : au démarrage, plusieurs exemplaires partent en même temps. Le
+ * mode `ddl: "migrate"` existe pour les déploiements à exemplaire unique et
+ * s'écrit à la main. En production orchestrée, c'est un travail séparé qui
+ * lance cette commande AVANT que les nouveaux exemplaires ne démarrent.
+ *
+ * ## Le compte qui migre n'est pas le compte qui sert
+ *
+ * `NF_MIGRATE_DATABASE_URL` remplace, pour cette commande seulement, la
+ * connexion du connecteur. C'est le véhicule du moindre privilège : le secret
+ * qui a le droit de modifier le schéma est monté dans le travail de migration,
+ * et nulle part ailleurs. Elle doit désigner une connexion **directe** — un
+ * répartiteur de connexions en mode transaction casse le verrou.
+ *
+ * @example Voir sans rien appliquer
+ * ```bash
+ * nodefony orm:migrate --dry-run
+ * ```
+ *
+ * @example Dans un travail de déploiement
+ * ```bash
+ * NF_MIGRATE_DATABASE_URL="postgres://migrator:…@db:5432/app" nodefony orm:migrate --json
+ * ```
+ */
+declare class OrmMigrate extends OrmMigrateCommand {
+    constructor(cli: CliKernel);
+    generate(opts?: IMigrateOptions): Promise<this>;
+}
+export default OrmMigrate;
+export { EXIT, action };

package/dist/types/nodefony/command/orm-reset.d.ts

@@ -0,0 +1,55 @@
+import type { CliKernel } from "nodefony";
+import { OrmMigrateCommand, type IMigrateSharedOptions } from "./migrateShared.js";
+/** Options propres à la remise à zéro d'une base de développement. */
+interface IResetOptions extends IMigrateSharedOptions {
+    yes?: boolean;
+}
+/**
+ * `nodefony orm:reset` — vide la base de DÉVELOPPEMENT et la laisse prête à
+ * être recréée.
+ *
+ * ## Le geste qu'elle remplace
+ *
+ * Jusqu'ici, le générateur d'applications disait « supprime ta base de dev, ou
+ * passe par une migration » : deux gestes manuels, aucun outil, et chacun s'en
+ * tirait comme il pouvait. Une seule commande à retenir pour toute l'équipe,
+ * au lieu d'un arbre de décision.
+ *
+ * ## Ce qu'elle fait exactement
+ *
+ * Elle supprime **toutes les tables du schéma courant** de la connexion —
+ * l'historique des migrations compris. Elle ne supprime NI la base, NI le
+ * fichier : supprimer une base demande des droits d'administration que le
+ * compte de l'application n'a pas, et supprimer un fichier ouvert échoue sous
+ * Windows. Le résultat est le même — une base vide — et il s'obtient partout de
+ * la même façon.
+ *
+ * Ensuite : en mode `auto` (le défaut en développement), le prochain démarrage
+ * recrée le schéma depuis le code. Dans les autres modes, la commande dit quoi
+ * lancer.
+ *
+ * ## Le refus est une LISTE BLANCHE, pas une liste noire
+ *
+ * Elle n'accepte de travailler que si l'environnement est `development`. Pas
+ * « refusée en production » : `staging`, `preprod`, `test` et tout
+ * environnement inconnu refusent aussi. La différence n'est pas théorique — une
+ * garde écrite « si production » laisse passer tout ce qu'on n'a pas pensé à
+ * nommer, et c'est exactement là que l'accident arrive.
+ *
+ * `NF_MIGRATE_DATABASE_URL` n'est **pas** lue par cette commande. Cette
+ * variable porte le compte qui a le droit de modifier le schéma en
+ * production : lui laisser désigner la cible d'un effacement serait offrir la
+ * seule combinaison qu'il ne faut jamais rendre possible.
+ *
+ * @example
+ * ```bash
+ * nodefony orm:reset            # demande confirmation en terminal
+ * nodefony orm:reset --yes      # sans question (script)
+ * ```
+ */
+declare class OrmReset extends OrmMigrateCommand {
+    #private;
+    constructor(cli: CliKernel);
+    generate(opts?: IResetOptions): Promise<this>;
+}
+export default OrmReset;

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

@@ -0,0 +1,110 @@
+import { z } from "zod";
+/**
+ * @nodefony/drizzle — CONFIGURATION DU MODULE (schéma Zod = source unique).
+ *
+ * ⭐ TL;DR : CE SCHÉMA EST LA CONFIG. Chaque `.default(...)` = la valeur d'usine ;
+ * changer un défaut du module = ÉDITER ICI (et nulle part ailleurs). L'app, elle,
+ * surcharge via `use("@nodefony/...", { … })` dans SON `nodefony.config.ts`.
+ *
+ * RÈGLE D'OR (ADR-0006) : ce fichier porte le **schéma Zod commenté** (type +
+ * validation + défaut + doc) ET matérialise les défauts via `parse({})`. Aucune
+ * valeur n'est re-tapée ailleurs. Le builder (`defineDrizzleConfig`) et les types
+ * (`interfaces/IDrizzleConfig.ts`) importent le schéma D'ICI (nœud bas : ce fichier
+ * n'importe que `zod` → pas de cycle).
+ *
+ * Convention figée (cf `feedback_config_validation_zod` + audit config ORM
+ * 2026-06), alignée sur `@nodefony/mongoose`/`@nodefony/redis`/`@nodefony/realtime`.
+ *
+ * ⚠️ Le schéma reste **PUR** : `filename` est **optionnel SANS défaut** — le chemin
+ * SQLite par défaut dépend de `kernel.path` (indisponible à l'évaluation du schéma)
+ * et est résolu au boot par `DrizzleService`. Aucune lecture `process.env` ici
+ * (l'env est appliqué dans `defineDrizzleConfig`).
+ *
+ * SURCHARGE (précédence croissante — cf ADR-0006) :
+ *   • App (typé)         : `use("@nodefony/drizzle", { connectors: { … } })` ;
+ *   • Par environnement  : infra database `NF_DATABASE_URL`/`DATABASE_URL`
+ *     (dialecte déduit du scheme, appliqué dans `defineDrizzleConfig`) ;
+ *   • Déploiement/Docker : `NF__DRIZZLE__<CHEMIN>=valeur` (override env générique).
+ */
+/**
+ * Dialectes SQL supportés par l'adapter Drizzle. `sqlite` (better-sqlite3) est le
+ * défaut bootable ; `postgres` (pg) / `mysql` (mysql2) sont des drivers chargés en
+ * LAZY (`optionalDependencies` + `await import` au connect) — un framework doit
+ * porter ses entités sur les bases majeures (cf chantier portabilité multi-dialecte).
+ */
+export declare const SQL_DIALECTS: readonly ["sqlite", "postgres", "mysql"];
+/** Dialecte SQL d'un connecteur Drizzle. */
+export type SqlDialect = (typeof SQL_DIALECTS)[number];
+/**
+ * Stratégies de fabrication du schéma d'un connecteur.
+ *
+ * Trois valeurs, et pas une de plus : ce qui fait le schéma est soit le
+ * démarrage à partir du code (`auto`), soit le démarrage à partir des fichiers
+ * de migration (`migrate`), soit personne (`none`). Un quatrième mode serait un
+ * mélange, donc un comportement que personne ne saurait décrire dans un
+ * incident.
+ */
+export declare const DDL_MODES: readonly ["auto", "migrate", "none"];
+/** Stratégie de fabrication du schéma d'un connecteur. */
+export type DdlMode = (typeof DDL_MODES)[number];
+/**
+ * Conduites de la sonde de disponibilité quand le schéma est en retard.
+ *
+ * `fail` retient la mise en service (le processus ne reçoit pas de trafic),
+ * `warn` journalise et sert quand même, `off` ne regarde pas.
+ */
+export declare const MIGRATION_CHECK_MODES: readonly ["fail", "warn", "off"];
+/** Conduite de la sonde de disponibilité face à un schéma en retard. */
+export type MigrationCheckMode = (typeof MIGRATION_CHECK_MODES)[number];
+/**
+ * Conduites face à une base qui ne correspond plus au code alors que
+ * l'historique est complet.
+ *
+ * Le défaut est `report` — et il est structurel, pas prudent : une application
+ * qui écrit des migrations libres (vues, déclencheurs, colonnes ajoutées à une
+ * table d'entité) a une base légitimement différente du schéma déclaré, en
+ * permanence. Faire tomber sa mise en service dessus rendrait le constat
+ * inutilisable, donc mort. Superviser ne fait pas tomber un déploiement.
+ */
+export declare const DIVERGENCE_MODES: readonly ["report", "fail", "off"];
+/** Conduite face à une base qui a divergé du schéma déclaré. */
+export type DivergenceMode = (typeof DIVERGENCE_MODES)[number];
+export declare const drizzleConfigSchema: z.ZodObject<{
+    connectors: z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodObject<{
+        dialect: z.ZodDefault<z.ZodEnum<{
+            mysql: "mysql";
+            postgres: "postgres";
+            sqlite: "sqlite";
+        }>>;
+        filename: z.ZodOptional<z.ZodString>;
+        url: z.ZodOptional<z.ZodString>;
+        ddl: z.ZodOptional<z.ZodEnum<{
+            auto: "auto";
+            migrate: "migrate";
+            none: "none";
+        }>>;
+    }, z.core.$strict>>>;
+    migrations: z.ZodDefault<z.ZodObject<{
+        dir: z.ZodDefault<z.ZodString>;
+        check: z.ZodOptional<z.ZodEnum<{
+            fail: "fail";
+            off: "off";
+            warn: "warn";
+        }>>;
+        lockTimeoutMs: z.ZodDefault<z.ZodNumber>;
+        divergence: z.ZodDefault<z.ZodEnum<{
+            fail: "fail";
+            off: "off";
+            report: "report";
+        }>>;
+    }, z.core.$strict>>;
+    frameworkEntities: z.ZodDefault<z.ZodBoolean>;
+}, z.core.$strict>;
+/** Type de sortie (config normalisée + défauts appliqués). */
+export type DrizzleConfig = z.infer<typeof drizzleConfigSchema>;
+/**
+ * Défauts du module, matérialisés depuis le schéma (source unique). Toujours
+ * valides par construction ; passés au `super(..., config)` du Module class.
+ */
+declare const config: DrizzleConfig;
+export default config;

package/dist/types/nodefony/config/defineModuleConfig.d.ts

@@ -0,0 +1,24 @@
+import type { IDrizzleConfig, IDrizzleConfigInput } from "../interfaces/IDrizzleConfig.js";
+/**
+ * Builder type-safe de la configuration de `@nodefony/drizzle`.
+ *
+ * ⭐ TL;DR : MACHINERIE DE BOOT — on n'édite (presque) jamais ce fichier. Même
+ * pattern que `nodefony.config.ts` ↔ `defineConfig()` du core : `config.ts` PORTE
+ * la config (schéma + défauts), `define<X>Config()` la VALIDE au boot (parse +
+ * env + freeze) et publie le JSON Schema Studio.
+ *
+ * Aligné sur `defineMongooseConfig` (l'autre driver ORM) : source unique
+ * (`./config.ts`), VALIDE + applique l'ENV + GÈLE. Le **chemin SQLite par défaut**
+ * (kernel-dépendant) n'est PAS résolu ici (schéma pur) mais dans `DrizzleService`
+ * au boot — cf audit config ORM 2026-06 §3.2.
+ *
+ * @param config - configuration brute (sections omises = défauts sûrs).
+ * @returns config validée, surchargée par l'env, et gelée.
+ * @throws ZodError si la config est invalide.
+ */
+export declare function defineDrizzleConfig(config?: IDrizzleConfigInput): IDrizzleConfig;
+/**
+ * JSON Schema introspectable de la config Drizzle — destiné au formulaire
+ * d'édition Studio (futur) et à la documentation générée.
+ */
+export declare function drizzleConfigJsonSchema(): unknown;