@nodefony/drizzle 10.0.0-alpha.4 → 10.0.0-alpha.6

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

@@ -0,0 +1,41 @@
+/**
+ * Répare la recopie d'une recréation de table SQLite.
+ *
+ * 🔴 Le défaut que ce module ferme, mesuré sur deux applications fraîches :
+ * quand une migration doit à la fois MODIFIER une colonne et en AJOUTER une,
+ * SQLite ne sait pas altérer sur place — l'outil de génération produit alors la
+ * ronde connue (créer `__new_x`, y recopier les lignes de `x`, supprimer `x`,
+ * renommer). Sa recopie liste les colonnes de la table d'ARRIVÉE, la colonne
+ * neuve comprise, et va donc la LIRE dans la table de départ, où elle n'existe
+ * pas encore. La migration échoue sur `no such column` et laisse un marqueur
+ * qui bloque tous les passages suivants — l'utilisateur se retrouve devant
+ * trois commandes qui refusent, et la seule issue apparente est de détruire la
+ * base.
+ *
+ * La réparation est déterministe et sans jugement : une colonne que la table de
+ * départ ne porte pas ne peut pas être recopiée, donc elle sort des DEUX
+ * listes. Elle recevra ce que son `CREATE TABLE` lui donne — un défaut, ou
+ * `NULL`. C'est exactement ce qu'aurait fait un `ADD COLUMN`.
+ *
+ * ⚠️ On ne touche à RIEN dès qu'un élément de la recopie n'est pas une simple
+ * colonne citée — une expression, un appel de fonction, un alias — ni quand les
+ * colonnes de la table de départ sont inconnues. Réécrire ce qu'on n'a pas
+ * compris coûterait plus cher que le défaut qu'on répare.
+ */
+/** Ce que la réparation a changé, pour pouvoir le DIRE plutôt que le taire. */
+export interface IRebuildCopyRepair {
+    /** Le SQL, réparé si besoin ; identique à l'entrée sinon. */
+    readonly sql: string;
+    /** Les colonnes retirées de la recopie, en `table.colonne`. */
+    readonly dropped: readonly string[];
+}
+/**
+ * Retire de la recopie les colonnes que la table de départ ne porte pas.
+ *
+ * @param sql - le SQL de la migration, tel que l'outil vient de l'écrire.
+ * @param columnsOf - les colonnes d'une table AVANT cette migration ; `null`
+ *   quand on ne les connaît pas — auquel cas rien n'est touché, car on ne
+ *   réécrit jamais sur une supposition.
+ * @returns le SQL réparé et la liste de ce qui a été retiré.
+ */
+export declare function repairRebuildCopy(sql: string, columnsOf: (table: string) => readonly string[] | null): IRebuildCopyRepair;

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

@@ -17,6 +17,8 @@ export type CommandFailureCode =
  | "NF_MIGRATE_UNAVAILABLE"
 /** Confirmation requise et non donnée. */
  | "NF_MIGRATE_CONFIRM_REQUIRED"
+/** La base porte des comptes : `--yes` ne suffit pas à les effacer. */
+ | "NF_MIGRATE_RESET_HAS_ACCOUNTS"
 /** Des migrations en attente SUPPRIMENT des données, hors développement. */
  | "NF_MIGRATE_DESTRUCTIVE"
 /** Adopter TOUT graverait une affirmation fausse : la base ne suit pas. */
@@ -33,6 +35,12 @@ export type CommandFailureCode =
  | "NF_GENERATE_DATABASE_BEHIND"
 /** L'outil qui ÉCRIT les migrations n'est pas installé. */
  | "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"
+/** 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é. */
+ | "NF_INTROSPECT_FAILED"
 /** Le schéma initial serait écrit sur une base qui porte DÉJÀ ces tables. */
  | "NF_GENERATE_DATABASE_NOT_ADOPTED"
 /** L'adoption par lecture de la base, demandée alors qu'il existe déjà des migrations. */
@@ -124,6 +132,59 @@ export interface IResolutionRefusal {
  * @returns le refus, avec le geste qui répare.
  */
 export declare function generationToolMissing(): IResolutionRefusal;
+/**
+ * Sortie d'un outil tiers, prête à être citée dans une explication.
+ *
+ * Elle est indentée pour se distinguer de la prose qui l'entoure, et BORNÉE par
+ * la fin : une pile d'appels se termine par ce qui a cassé, jamais par ce qui a
+ * démarré. La troncature s'ANNONCE — une sortie coupée en silence fait chercher
+ * une cause dans la moitié qu'on n'a pas montrée.
+ *
+ * @param output - sortie complète de l'outil (standard puis erreur).
+ * @param maxLines - nombre de lignes conservées, depuis la fin.
+ * @returns le bloc cité, ou une phrase disant qu'il n'y avait rien.
+ */
+export declare function formatToolOutput(output: string, maxLines?: number): string;
+/**
+ * L'outil de génération pose une QUESTION, et aucun terminal n'y répond.
+ *
+ * C'est le cas d'une colonne qui disparaît pendant qu'une autre apparaît :
+ * renommage (les données suivent) ou suppression puis ajout (les données sont
+ * perdues) — l'outil ne peut pas le deviner, et il a raison de demander.
+ *
+ * @param label - ce qui était généré, tel qu'on le cite à l'utilisateur.
+ * @param replay - la commande à rejouer dans un terminal interactif.
+ * @returns le refus, prêt pour la ligne de commande comme pour l'écran.
+ */
+export declare function generationNeedsAnswer(label: string, replay: string): IResolutionRefusal;
+/**
+ * L'outil de génération s'est arrêté, et ce qu'il a dit est remonté TEL QUEL.
+ *
+ * 🔴 Ne JAMAIS remplacer sa sortie par une hypothèse. Le fourre-tout des
+ * commandes de migration explique tout par une base injoignable ou des droits
+ * manquants : sur un schéma qui retire une colonne, les deux sont FAUX, et ils
+ * envoient vérifier une base qui répond très bien pendant que la cause est dans
+ * le fichier d'entité qu'on vient d'éditer. Un message d'erreur est cru PARCE
+ * QU'il est précis.
+ *
+ * @param label - ce qui était généré, tel qu'on le cite à l'utilisateur.
+ * @param status - code de sortie observé (il vaut `0` même en échec).
+ * @param output - sortie complète de l'outil.
+ * @returns le refus, prêt pour la ligne de commande comme pour l'écran.
+ */
+export declare function generationFailed(label: string, status: number | null, output: string): IResolutionRefusal;
+/**
+ * La lecture du schéma d'une base existante a échoué.
+ *
+ * Contrairement à la génération, celle-ci INTERROGE la base : une base muette
+ * ou des droits insuffisants sont ici des explications légitimes.
+ *
+ * @param label - ce qui était lu, tel qu'on le cite à l'utilisateur.
+ * @param status - code de sortie observé.
+ * @param output - sortie complète de l'outil.
+ * @returns le refus, prêt pour la ligne de commande comme pour l'écran.
+ */
+export declare function introspectFailed(label: string, status: number | null, output: string): IResolutionRefusal;
 /**
  * Erreur portant un {@link IResolutionRefusal} déjà composé.
  *

package/docs/index.md

@@ -113,7 +113,7 @@ loin, et ces deux pas expliquent la taille de cette page.
 
 **1. Il porte le framework, pas seulement ton métier.** Les huit briques durables (session, users,
 jetons, passkeys, TOTP, audit, webhooks, idempotence) ont leurs tables **dans le module**, déclarées
-au démarrage par `registerDrizzleFrameworkStores()` (`registerStores.ts:149`). Aucune application
+au démarrage par `registerDrizzleFrameworkStores()` (`registerStores.ts:184`). Aucune application
 n'écrit de `registerXStore(...)`.
 
 **2. Il reconstruit la portabilité que Drizzle n'offre pas.** Drizzle est schema-as-code
@@ -417,7 +417,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:597` · `#connectMysql()`, `DrizzleOrm.ts:1200`).
+requête métier (`#connectPostgres()`, `DrizzleOrm.ts:998` · `#connectMysql()`, `DrizzleOrm.ts:1296`).
 
 ## Dialectes — une base par déploiement, un seul code
 
@@ -510,7 +510,7 @@ connexion**, donc leurs tables sont créées au moment où l'ORM s'ouvre.
 | `DrizzleTransaction`   | `BEGIN`/`COMMIT`/`ROLLBACK` pilotés à la main, sur les trois dialectes | `DrizzleTransaction.ts:70`                                   |
 | `buildFrameworkTable`  | une spécification logique → la table du dialecte demandé               | `colKit.ts:543`                                              |
 | `queryKit` (interne)   | le SQL brut des entités framework, émis **et exécuté** par dialecte    | `findUserIdBySocialProvider()` (`queryKit.ts:76`)            |
-| `registerStores`       | l'auto-enregistrement des huit briques                                 | `registerDrizzleFrameworkStores()` (`registerStores.ts:149`) |
+| `registerStores`       | l'auto-enregistrement des huit briques                                 | `registerDrizzleFrameworkStores()` (`registerStores.ts:184`) |
 
 ### Le DDL dérivé — comment les tables apparaissent
 
@@ -624,7 +624,7 @@ const rows = await db.all(sql`
 `);
 ```
 
-C'est l'**anti-blocage** du modèle Repository (`getNativeConnection()`, `DrizzleOrm.ts:1405`) : CTE,
+C'est l'**anti-blocage** du modèle Repository (`getNativeConnection()`, `DrizzleOrm.ts:1524`) : 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.
@@ -678,12 +678,12 @@ use("@nodefony/security", {
 > **Les TSDoc de deux fichiers du module décrivent une « approche B » où l'application câblerait
 > elle-même la fabrique et l'entité d'idempotence** (`DrizzleIdempotencyStore.ts:97` ·
 > `idempotencyEntity.ts:32`). Ce n'est plus le comportement : le module inscrit lui-même la fabrique
-> via `registerIdempotencyStore()` (`registerStores.ts:316`). **Le code exécuté fait autorité** —
+> via `registerIdempotencyStore()` (`registerStores.ts:356`). **Le code exécuté fait autorité** —
 > ces commentaires sont périmés.
 
 ### Le mécanisme, et comment garder la main
 
-`registerDrizzleFrameworkStores()` (`registerStores.ts:149`) est appelé à l'enregistrement du module,
+`registerDrizzleFrameworkStores()` (`registerStores.ts:184`) est appelé à l'enregistrement du module,
 avec le dialecte du connecteur `default`. Pour chaque brique, il déclare l'entité puis inscrit la
 fabrique du store dans le registre de son propriétaire (`http`, `security` ou `framework`). Deux
 garde-fous préservent ta liberté :
@@ -696,7 +696,7 @@ Et deux garde-fous protègent de l'incohérence :
 - une brique **non portée** sur le dialecte configuré n'est ni déclarée ni fabricable — la
   sélectionner échoue franchement au démarrage plutôt que de produire une table fantôme ;
 - la fabrique **capture le dialecte** de son enregistrement : elle refuse un ORM d'un autre dialecte
-  (`resolveConnectedOrm()`, `registerStores.ts:112`).
+  (`resolveConnectedOrm()`, `registerStores.ts:143`).
 
 Pour tout couper — module « données seulement », aucune entité ni fabrique framework :
 
@@ -831,7 +831,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:1495`) :
+La sonde d'un connecteur s'adapte au dialecte (`probe()`, `DrizzleOrm.ts:1614`) :
 
 - **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 +843,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:372`).
+l'emplacement **est** l'infra déclarée, déjà affichée ailleurs (`location`, `DrizzleOrm.ts:415`).
 
 ## ⚡ Performance & mémoire
 

package/docs/migrations.md

@@ -106,6 +106,9 @@ nodefony orm:migrate:repair
 
 # Développement seulement : supprime et recrée la base du connecteur.
 nodefony orm:reset
+
+# … et si la base porte des comptes, des passkeys ou des seconds facteurs :
+nodefony orm:reset --yes --drop-accounts
 ```
 
 Toutes acceptent `--connector <nom>` (défaut : `default`) et `--json`. Le flux `--json` est **pur** :
@@ -358,7 +361,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:345`) : `/readyz`
+  publié à la sonde de disponibilité (`#publishReadiness()`, `DrizzleService.ts:445`) : `/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
@@ -508,6 +511,23 @@ conforme, la clé est ABSENTE** (jamais un objet vide) : `.divergence == null` s
 L'écran lisible en dit autant : le résumé nomme les trois premières entrées de chaque famille, et la
 liste complète ne se déroule que lorsqu'elle ne tient plus dans la phrase.
 
+### Ce que `--yes` ne suffit pas à effacer
+
+`orm:reset` **refuse** sur une base qui porte de l'irremplaçable, et nomme ce qu'elle allait
+supprimer avec le nombre de lignes : des comptes au-delà de celui que votre semis repose, des
+passkeys (liées à l'appareil — personne ne peut les réémettre), des seconds facteurs. Il faut alors
+`--drop-accounts` en plus de `--yes` : le drapeau dit que vous avez vu la liste.
+
+Ce qui se reconstitue ne déclenche rien — une session et un jeton se refont par un login, une trace
+d'audit est une trace. Et **une application fraîche n'est pas gênée** : le compte d'administration
+que son semis repose à chaque démarrage ne compte pas comme une perte. Une garde qui se lève sur le
+cas normal s'apprend à être contournée avant le jour où elle a raison.
+
+Quand une migration a échoué et que son marqueur est posé, le refus nomme d'abord
+`orm:migrate:repair` — qui lève le marqueur **sans rien effacer**. C'est le seul moment où l'on sait
+que la voie non destructrice s'applique, et c'est exactement la situation où l'on est tenté de tout
+remettre à zéro.
+
 Les gestes proposés suivent **l'environnement** : `orm:reset` efface, elle n'est acceptée qu'en
 développement, et elle n'est donc proposée que là. Ailleurs, la sortie renvoie vers l'écriture d'une
 migration correctrice (`orm:generate --custom`) puis son application.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nodefony/drizzle",
-  "version": "10.0.0-alpha.4",
+  "version": "10.0.0-alpha.6",
   "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",
@@ -57,33 +57,33 @@
   "dependencies": {
     "drizzle-orm": "0.45.2",
     "tslib": "2.8.1",
-    "zod": "^4.4.3"
+    "zod": "^4.6.1"
   },
   "devDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.4",
-    "@nodefony/http": "^10.0.0-alpha.4",
-    "@nodefony/orm-core": "^10.0.0-alpha.4",
-    "@nodefony/security": "^10.0.0-alpha.4",
-    "@nodefony/user": "^10.0.0-alpha.4",
+    "@nodefony/framework": "^10.0.0-alpha.6",
+    "@nodefony/http": "^10.0.0-alpha.6",
+    "@nodefony/orm-core": "^10.0.0-alpha.6",
+    "@nodefony/security": "^10.0.0-alpha.6",
+    "@nodefony/user": "^10.0.0-alpha.6",
     "@types/better-sqlite3": "9.6.0",
-    "@types/node": "26.4.1",
+    "@types/node": "26.5.1",
     "@types/pg": "8.23.1",
     "better-sqlite3": "13.0.3",
     "drizzle-kit": "0.31.10",
     "mysql2": "3.24.4",
-    "nodefony": "^10.0.0-alpha.4",
+    "nodefony": "^10.0.0-alpha.6",
     "pg": "8.23.0",
     "rimraf": "6.1.3"
   },
   "peerDependencies": {
-    "@nodefony/framework": "^10.0.0-alpha.4",
-    "@nodefony/http": "^10.0.0-alpha.4",
-    "@nodefony/orm-core": "^10.0.0-alpha.4",
-    "@nodefony/security": "^10.0.0-alpha.4",
-    "@nodefony/user": "^10.0.0-alpha.4",
+    "@nodefony/framework": "^10.0.0-alpha.6",
+    "@nodefony/http": "^10.0.0-alpha.6",
+    "@nodefony/orm-core": "^10.0.0-alpha.6",
+    "@nodefony/security": "^10.0.0-alpha.6",
+    "@nodefony/user": "^10.0.0-alpha.6",
     "better-sqlite3": "^13.0.0",
     "mysql2": "^3.24.0",
-    "nodefony": "^10.0.0-alpha.4",
+    "nodefony": "^10.0.0-alpha.6",
     "pg": "^8.23.0"
   },
   "repository": {
@@ -91,11 +91,11 @@
     "url": "git+https://github.com/nodefony/nodefony-core.git",
     "directory": "src/packages/@nodefony/drizzle"
   },
-  "license": "CECILL-B",
+  "license": "Apache-2.0",
   "licenses": [
     {
-      "type": "CECILL-B",
-      "url": "http://www.cecill.info/licences/Licence_CeCILL-B_V1-en.html"
+      "type": "Apache-2.0",
+      "url": "https://www.apache.org/licenses/LICENSE-2.0"
     }
   ],
   "author": "Christophe CAMENSULI <ccamensuli@gmail.com>",