@mostajs/kind-catalog 0.2.0 → 0.4.0

package/docs/EPREUVE-02-LABTRAX-06092026.md

@@ -0,0 +1,152 @@
+# Épreuve rétrospective n° 2 — LabTrax
+
+**Auteur** : Dr Hamid MADANI <drmdh@msn.com>
+**Date** : 06/09/2026 · **Objet** : `@mostajs/kind-catalog` 0.4.0 · **Statut** : essai, la règle n'est **pas** adoptée
+
+> Deuxième passage de la moulinette prévue au §5.bis de
+> [`PROPOSITION-REGLE-RELIRE-LE-PLAN.md`](PROPOSITION-REGLE-RELIRE-LE-PLAN.md). L'essai n° 1
+> ([RestoTrax](EPREUVE-01-RESTOTRAX-06092026.md)) a buté sur un défaut d'objet : le plan jugé était
+> déjà l'état final, il n'y avait donc **aucun écart** à mesurer. Celui-ci en a un.
+
+---
+
+## 1. L'objet — et pourquoi il vaut mieux que le premier
+
+| | |
+|---|---|
+| plan initial | `docs/DEVTEST-PLAN.labtrax.json`, commit `4571c7a` du **27/07/2026** — « parcours réglementaire, arrêté 1275 » |
+| plan atteint | même fichier aujourd'hui, après six semaines de travail |
+| **écart** | **16 exigences → 49** · 24 essais → 85 · 16 réalisations → 59 |
+
+**33 exigences ont été ajoutées après le plan initial.** C'est la seule chose qui rende l'épreuve
+possible : ces 33 exigences sont ce que le projet a **découvert en le faisant**, et donc exactement
+ce qu'une relecture du plan initial aurait eu la chance — ou non — de signaler d'avance.
+
+---
+
+## 2. La double borne — 11 fiches sur 21 sont interdites
+
+Corpus complet : 21 fiches. **Retenues : 10. Écartées : 11.**
+
+| motif d'exclusion | fiches |
+|---|---|
+| **origine dans le projet jugé** (9) | `PERIMETRE`, `CHIFFRE-SANS-SOURCE`, `REFUS-LISIBLE`, `DONNEE-INSUFFISANTE`, `FORMULAIRE-ROUTE`, `CONSIGNER-APRES-SUCCES`, `DEPENDANCE-DISTANTE`, `SUPPRESSION-DATEE` |
+| **postérieure au plan** (3) | `ACQUIS` (01/09), `MAJ-PARTIELLE` (01/09), `ECRITURE-HORS-APPLICATION` (02/09) |
+
+Sur les 10 retenues, **6 sont métier** — élevage, apiculture, BTP, alimentaire, agronomie,
+électronique — et n'ont aucun rapport avec une application universitaire. **L'outil disposait donc
+de quatre fiches transverses**, portant 18 erreurs connues, et de rien d'autre.
+
+> ### ⚠️ Le fait le plus instructif de cet essai est dans le tableau ci-dessus
+>
+> Les fiches qui auraient **touché** sont précisément celles que la borne interdit. Six des neuf
+> fiches nées de LabTrax retombent, mot pour mot, sur des exigences que LabTrax a dû écrire :
+>
+> | fiche écartée (née de LabTrax) | exigence ajoutée par LabTrax |
+> |---|---|
+> | `PERIMETRE-01` — une permission ouvre une capacité, jamais un périmètre | **SPEC-APP-31** — faire dériver la lecture d'une séance du **mandat**, comme le vote |
+> | `REFUS-LISIBLE-01` — un refus nomme sa cause et offre une issue | **SPEC-APP-35** — dire la **vraie raison** d'un refus, et offrir une issue |
+> | `FORMULAIRE-ROUTE-01` — le formulaire rendu et sa route s'accordent | **SPEC-APP-33** — vérifier l'IHM **telle qu'elle est servie** |
+> | `CONSIGNER-APRES-SUCCES-01` — on ne date qu'après le succès | **SPEC-APP-38** — ne dater qu'**après** l'envoi ; `notifyDecision` n'enregistrait qu'une date |
+> | `SUPPRESSION-DATEE-01` — retirer, c'est dater | **SPEC-APP-26** — pierre tombale **datée, attribuée et motivée** |
+> | `DONNEE-INSUFFISANTE-01` — un calcul insuffisant refuse et chiffre son manque | **SPEC-APP-41** — désigner ce qui bloque **réellement** *(rapprochement plausible, non exact)* |
+>
+> Ce n'est **pas** une mesure de l'outil : ces fiches ont été écrites **depuis** ces exigences,
+> l'ordre causal est inversé. C'est la démonstration que la borne fait son travail — sans elle,
+> j'aurais publié un taux de réussite de 18 % au lieu de 9 %, et il aurait été faux.
+
+---
+
+## 3. Ce que l'outil aurait dit le 27/07/2026
+
+**11 erreurs connues sur 4 règles.** Classement selon les quatre classes du protocole — il n'y a
+**pas de classe « faux »** : l'écart entre un avertissement et ce qu'a fait le projet n'est ni bon
+ni mauvais, le besoin du commanditaire est le seul arbitre.
+
+| # | avertissement | classe | ce qu'a fait LabTrax |
+|---|---|---|---|
+| 1 | *l'aperçu écrit déjà quelque chose* | **divergent** | **SPEC-APP-25** exige le décompte et le quorum **visibles avant** l'action — même territoire, autre forme : l'**inertie** de l'aperçu n'est écrite nulle part (`aperçu` : 0 occurrence dans le plan final) |
+| 2 | *la garde est posée dans la VUE* | **anticipé** | **SPEC-APP-31** fait dériver la garde du mandat ; **SPEC-APP-32** fait déclarer le catalogue par les modules. Le plan initial ne posait la garde sur la séance que pour le pointage (SPEC-APP-07) |
+| 3 | *seuls les succès sont audités* | **divergent** | 50 occurrences de « refus » dans le plan final, **toutes** du côté de l'écran (SPEC-APP-24, SPEC-APP-35). Aucune ne **compte** les refus. Pour une université, le refus lisible primait le refus dénombrable — et l'avertissement reste ouvert |
+| 4 | *l'action exécutée n'est pas celle prévisualisée* | **sans objet** | LabTrax n'a jamais construit de couple aperçu/appliquer |
+| 5 | *l'essai tourne en mémoire, la production sur schéma* | **anticipé** | **SPEC-APP-33**, écrite après le correctif `da228ce` du 27/07 : « *un test qui fabrique lui-même sa requête ne teste pas l'écran — il teste l'idée qu'on s'en fait* ». L'IHM postait `identifier`, la route lisait `email` |
+| 6 | *le champ est ajouté au code sans l'être au schéma* | **anticipé** | **SPEC-APP-27** — le numéro d'inscription saisi à la candidature **doit être conservé** dans un champ déclaré (`User.externalRef`) |
+| 7 | *la migration n'ALTÈRE pas une table existante* | **sans objet** | aucune migration au plan (`migration` : 0 occurrence) |
+| 8 | *on fait confiance au texte produit* | **sans objet** | aucune sortie générative — le « Service IA » de la commission est un service **humain** |
+| 9 | *clé valide sans crédit confondue avec clé invalide* | **divergent** | **SPEC-APP-38** répond à la même racine — le résultat du fournisseur doit gouverner ce qu'on écrit — par « dater après l'envoi » et « pouvoir renvoyer ». Le **classement** des échecs n'a jamais été écrit |
+| 10 | *un quota temporaire traité comme une panne définitive* | **sans objet** | `quota` : 0 occurrence |
+| 11 | *l'ordre de repli est figé dans la configuration* | **sans objet** | `repli` : 0 occurrence |
+
+### Le couple
+
+| mesure | valeur | lecture |
+|---|---|---|
+| **rappel utile** | **3 / 33** = **9 %** | trois des 33 exigences ajoutées étaient signalées d'avance |
+| **coût de lecture** | **11 lignes, dont 5 sans objet** | moins d'une minute de lecture, 45 % de bruit |
+| divergents | 3 | à consigner : ils désignent trois besoins réels que LabTrax a servis autrement |
+| contredits | **0** | aucune fiche n'a été prise en défaut |
+
+**9 % est un chiffre faible, et il faut le dire tel quel.** Sa cause est mesurable et n'est pas
+dans le rapprochement : le corpus admissible au 27/07/2026 comptait **quatre** fiches transverses.
+Un rappel de 3 sur 33 avec quatre fiches, c'est **0,75 exigence gagnée par fiche disponible** —
+c'est ce ratio-là, et non le pourcentage, qui se projette.
+
+---
+
+## 4. La mesure du CORPUS — à ne pas confondre avec la précédente
+
+Le même plan initial, passé au corpus d'**aujourd'hui** (21 fiches, borne levée) :
+**42 erreurs sur 14 règles** au lieu de 11 sur 4.
+
+Ce chiffre ne mesure **pas** l'outil au 27/07 — il est circulaire pour les neuf fiches nées de
+LabTrax. Il mesure deux autres choses, et deux seulement :
+
+1. **la visée** — les fiches nées de LabTrax retombent sur les exigences qui les ont engendrées, et
+   nulle part ailleurs. C'est une vérification de justesse du rapprochement, pas de prédiction ;
+2. **une prédiction, falsifiable** — un projet frère qui démarrerait aujourd'hui recevrait 14 règles
+   et 42 erreurs, dont sept correspondent à des exigences que LabTrax a payées de six semaines de
+   découverte. **Cette prédiction ne vaut rien tant qu'elle n'a pas été vérifiée sur un projet qui
+   n'a pas nourri le catalogue.** C'est l'essai n° 3, et il ne peut pas être fait sur l'existant.
+
+---
+
+## 5. Ce que l'essai a corrigé dans l'outil
+
+Le faux positif relevé par l'essai n° 1 — `SUPPRESSION-DATEE-01` signalée 5 fois sur 5 alors que
+`PIL-14`/`TPIL-14` la portaient explicitement — a été poursuivi jusqu'au bout. Trois causes
+distinctes, trouvées dans cet ordre :
+
+| correctif | cause | RestoTrax | la règle |
+|---|---|---|---|
+| départ | — | 35 erreurs | 5/5 |
+| **couverture sur le TITRE seul** | la `consequence` est **notre** prose ; un plan n'a aucune raison de la contenir, et l'inclure pénalisait les erreurs **bien expliquées** | **27** | 3/5 |
+| **synonymes au RADICAL** | écrits en mots entiers, ils demandaient d'énumérer toutes les flexions du français — la liste tenait neuf mots pour un groupe et laissait passer `supprimée` | **26** | 2/5 |
+| **seuil des mots-clés à 4 lettres** | `date`, `note`, `vote`, `lieu`, `taux` étaient écartés — et avec eux **le mot qui distingue** : « le retrait est un simple drapeau, sans **date** » ne retenait que `retrait`, `simple`, `drapeau` | **23** | **1/5** |
+
+La seule erreur qui subsiste — *« la restauration recrée un objet neuf »* — est un **vrai manque** :
+le plan de RestoTrax ne dit rien d'une restauration. LabTrax reste à 11 erreurs après les trois
+correctifs : **le seuil à 4 lettres n'a ajouté aucun bruit**.
+
+Six essais gardent ces décisions : `T-KC-22` (la conséquence hors couverture), `T-KC-23` (les
+radicaux), `T-KC-24` (un groupe d'un mot ne relie rien), `T-KC-25` (un radical de moins de quatre
+lettres est écarté), `T-KC-26` (les mots de quatre lettres portent le sens).
+
+---
+
+## 6. Verdict provisoire — deux essais sur sept
+
+**La règle n'est toujours pas adoptable, et l'essai dit maintenant pourquoi.**
+
+Ce qui est acquis :
+- la **double borne** fonctionne, et elle est indispensable : elle divise le résultat par deux ;
+- l'outil ne s'est fait **contredire par aucun** des deux projets — 0 contredit sur 37 erreurs signalées ;
+- le **coût de lecture est négligeable** : une minute, pour un plan de 16 à 49 exigences ;
+- la porte **informative** est le bon choix : sur 11 avertissements, 5 étaient sans objet. Une porte
+  bloquante aurait arrêté un projet juste pour parler de quotas d'API à une université.
+
+Ce qui manque :
+- **cinq projets** — ATC, CollabTrax, qatrax, SofTrax, CRM/TRADING ;
+- surtout, **un projet qui n'a pas nourri le catalogue**. Les deux essais faits mesurent un catalogue
+  écrit en grande partie *depuis* les projets qu'il juge. Tant que ce troisième essai n'existe pas,
+  le seul chiffre honnête reste **0,75 exigence gagnée par fiche transverse disponible**, et il
+  n'autorise aucune promesse.

package/docs/PLAN-DEV-KIND-CATALOG.md

@@ -100,7 +100,9 @@ ce sont ceux qu'on omet, et ce sont ceux qui servent.
 |---|---|---|
 | **0.1.0** | fiche + validation + projection + instanciation + corpus initial (5 fiches tirées d'incidents réels) | §11.1 : essais mjs-unit verts, plan DEVTEST à trois trous nuls |
 | 0.2.0 | index inverse des emplois (B5), `findKinds` enrichi, premières fiches **agronomie** et **électronique** | corpus ≥ 15 fiches, ≥ 2 applications instanciées |
-| 0.3.0 | pont `assistant-pilote` : une fiche déclare son `kind` ro-pla et devient une question activable | une question née d'une fiche, activée en production |
+| **0.3.0-a** | **AMÉLIORER** — `diagnostiquer(plan, kinds)` : rapproche les exigences d'une application des fiches, **propose** la correspondance, et NOMME les erreurs connues qu'aucune exigence ne mentionne | un audit rendu sur le plan d'une application tierce, sans toucher au code |
+| **0.3.0-b** | **BÂTIR** — `demarrer({ domaines, project, prefix })` : plan de départ complet, épreuves **manuelles** | un projet neuf démarre sur un plan qu'il n'a pas écrit |
+| 0.4.0 | pont `assistant-pilote` : une fiche déclare son `kind` ro-pla et devient une question activable | une question née d'une fiche, activée en production |
 
 ### Le corpus initial de 0.1.0 — **des incidents réels, pas des suppositions**
 
@@ -112,6 +114,55 @@ ce sont ceux qu'on omet, et ce sont ceux qui servent.
 | `KIND-ACQUIS-01` — consulter un acquis ne doit pas l'effacer | `@mostajs/elearning` | `apprentissage` |
 | `KIND-DONNEE-INSUFFISANTE-01` — un calcul sur trop peu de données doit REFUSER, en chiffrant ce qui manque | RestoTrax, ATC | `decision` |
 
+## 4.bis · L'OUTIL À DOUBLE TRANCHANT *(orientation produit, 03/09/2026)*
+
+Le critère « duplication au référentiel / occurrence à l'application » a séparé deux fonctions.
+Elles ne sont pas deux options techniques : ce sont **deux produits, pour deux marchés**.
+
+| | **BÂTIR** | **AMÉLIORER** |
+|---|---|---|
+| fonction | `toDevtest` | `enrichir` |
+| à qui | un projet qui **commence** | un projet qui **tourne** |
+| ce qu'il reçoit | ses exigences de départ, avec leurs épreuves | les erreurs connues, dans ses exigences à lui |
+| ce qu'il évite | écrire un plan de test depuis une page blanche | repayer un défaut qu'un autre a déjà payé |
+| valeur perçue | « on démarre juste » | **« vous avez six erreurs connues que votre plan ne mentionne nulle part »** |
+| marché | projets neufs | **le parc existant — bien plus vaste** |
+
+### Ce que chaque tranchant exige encore
+
+**BÂTIR — il manque la SÉLECTION.** Aujourd'hui l'application nomme ses fiches une par une. Un
+assistant de démarrage part du **domaine** : *« un logiciel de gestion d'élèves »* → les fiches
+`acces`, `donnees`, `decision`, plus le métier. `findKinds({ domaine })` existe ; ce qui manque est
+un `demarrer({ domaines, project, prefix })` qui rende un plan de départ complet, dont les épreuves
+sont **manuelles** — un travail à faire, honnêtement affiché, jamais un plan qui prétend être tenu.
+
+**AMÉLIORER — il manque le DIAGNOSTIC, et c'est le vrai produit.** Aujourd'hui l'humain déclare la
+correspondance (`occurrences: ['SPEC-POR-01', …]`). Ce qui a de la valeur, c'est l'inverse : **lire
+le plan d'une application et lui dire ce qui lui manque**.
+
+> *« Votre plan porte quatre exigences de périmètre. La fiche en connaît six erreurs. Trois ne sont
+> mentionnées nulle part chez vous — voici lesquelles, et ce qu'elles coûtent. »*
+
+C'est un audit livrable **en une heure**, sur un plan qu'on nous donne, sans toucher au code.
+
+### ⚠️ Le diagnostic PROPOSE, il n'applique pas
+
+Un rapprochement automatique entre les exigences d'une application et les fiches du catalogue **se
+trompera** : les intitulés varient, les métiers diffèrent, une ressemblance de mots n'est pas une
+identité de règle. Un outil qui appliquerait ses rapprochements tout seul poserait des blocs
+d'erreurs sur des exigences qui n'ont rien à voir, et ruinerait la confiance dans les blocs justes.
+
+**Il propose une correspondance ; l'humain confirme.** C'est `KIND-ECRITURE-GARDEE-01`, appliqué à
+l'outil lui-même — et c'est la meilleure démonstration possible du catalogue : il tient sa propre
+règle sur son propre produit.
+
+### Ce que cela change à la feuille de route
+
+Le jalon **0.3.0** devient double, et la partie « améliorer » passe devant : c'est elle qui se vend
+sans qu'un projet ait besoin de commencer.
+
+---
+
 ## 5.bis · Les DOMAINES du catalogue
 
 Un `domaine` regroupe les fiches d'un même métier. Le vocabulaire est **ouvert** — un domaine

package/docs/PROPOSITION-REGLE-RELIRE-LE-PLAN.md

@@ -0,0 +1,210 @@
+# Proposition de règle — faire relire le plan par l'outil, avant d'écrire le code
+
+**Statut : PROPOSITION, en attente de validation.** Ce document n'est pas une règle DEVRULES : il
+en propose une. Rien ne s'y applique tant qu'elle n'est pas validée.
+
+**Auteur** : Dr Hamid MADANI <drmdh@msn.com> · **Date** : 2026-09-05
+**À reprendre** : à la fin du développement et des essais d'`@mostajs/auto-pilot` en mode
+« assistant par catalogue éprouvé ».
+
+---
+
+## 1 · L'idée
+
+Une fois les trois outils développés — **`auto-pilot`** (la modélisation), **`assistant-pilote`**
+(la garde et le journal), **`kind-catalog`** (les fiches et le diagnostic) —, **leur invocation
+devient une étape de la méthode** :
+
+> **Après avoir écrit le plan de développement (#3) et le plan de test (#4), et AVANT d'écrire la
+> première ligne de code, on fait relire ces plans par l'outil** — pour y déceler les manques, les
+> erreurs et les pièges déjà payés ailleurs — **puis on itère** jusqu'à ce qu'il n'ait plus rien à
+> dire.
+
+La boucle se referme sur elle-même : les incidents produisent des fiches, les fiches diagnostiquent
+les plans, et les plans corrigés évitent les incidents suivants.
+
+## 2 · Pourquoi maintenant, et pas plus tôt
+
+Cette session en a fourni la preuve, deux fois, **contre l'auteur** :
+
+- le diagnostic d'ATC a trouvé **5 erreurs sur 5** non mentionnées pour `KIND-ECRITURE-GARDEE-01` —
+  sur une application dont le comportement est bon et le plan dense. *Le comportement était juste,
+  le raisonnement n'était pas consigné.*
+- l'instanciation dans ATC a révélé, **après** la poussée à qatrax, que la projection créait des
+  cas inexécutables. Un diagnostic du plan avant le code l'aurait dit.
+
+**Et ce chantier même en aurait profité** : le #3 du port `modeleur` a été écrit sans passer les
+fiches `KIND-ECRITURE-GARDEE-01`, `KIND-REFUS-LISIBLE-01` et `KIND-CHIFFRE-SANS-SOURCE-01` en
+revue. Elles y sont, mais parce que l'auteur les avait en tête — pas parce qu'un outil les a
+rappelées. **Ce qui dépend d'une mémoire attentive finit par échouer une fois** (§5.bis.4).
+
+## 3 · Sur quoi porte la relecture
+
+| lu | forme | déjà possible ? |
+|---|---|---|
+| le plan Dev+Test structuré | `mostajs-devtest/1` | **oui** — `diagnostiquer(plan, kinds)` le fait déjà |
+| le plan de développement (#3) | Markdown en prose | **non** — à instruire |
+| le plan de test (#4) | Markdown en prose | **non** — à instruire |
+
+⚠️ **Le lien existe déjà et il est documenté.** `@mostajs/qa-engine` décrit `mostajs-devtest/1`
+comme le *« jumeau structuré des livrables DEVRULES #3 et #4 »*. La relecture porte donc d'abord
+sur le jumeau — c'est le chemin court, et il ne demande rien de neuf. Lire la prose vient ensuite,
+pour ce qu'elle porte et que le jumeau ne porte pas : les **risques**, les **jalons**, les
+**portes de sortie**.
+
+## 4 · Les quatre gardes que cette règle exige
+
+Sans elles, la règle produirait exactement ce qu'elle prétend éviter.
+
+### a) L'outil PROPOSE un écart, il ne réécrit pas le plan
+
+`T-KC-20` l'impose déjà : *le diagnostic ne modifie pas le plan qu'il lit*. Un outil qui réécrirait
+son objet ferait perdre la distinction entre ce que l'auteur a pensé et ce que l'outil a suggéré —
+et le plan cesserait d'être une décision pour devenir une sortie.
+
+### b) L'itération doit CONVERGER, et se borner
+
+Un optimiseur qui propose sans fin ne termine jamais. Règle d'arrêt : **on s'arrête quand un
+passage n'apporte aucun manque nouveau**, avec un plafond de passages, et **chaque passage consigne
+ce qu'il a fait changer**. Sans le journal des passages, on ne saura pas si le plan s'est amélioré
+ou s'il a seulement absorbé les remarques.
+
+### c) L'AUTORITÉ d'un manque dépend de l'ORIGINE de la fiche
+
+⚠️ **C'est le point le moins évident, et le plus important.**
+
+Une fiche dont la seule origine est **le projet qu'on diagnostique** ne prouve rien : on se cite
+soi-même. Le rapport doit donc **distinguer** :
+
+| force du signal | condition |
+|---|---|
+| **fort** | la fiche porte des incidents de **plusieurs projets, dont pas celui-ci** — un autre a déjà payé |
+| moyen | la fiche est adossée à un corpus établi (`reference`) |
+| **faible** | l'unique origine de la fiche est ce projet même |
+
+**Un diagnostic est d'autant plus fort que ses fiches viennent d'ailleurs.** C'est mesurable, et
+cela doit figurer au rapport.
+
+### d) Un outil ne se certifie pas lui-même
+
+Diagnostiquer le plan de `kind-catalog` avec le corpus de `kind-catalog` est légitime — mais le
+rapport doit le **dire**. Une auto-certification silencieuse vaut moins que rien : elle donne à un
+lecteur pressé l'impression d'un contrôle indépendant.
+
+## 5 · Où cela s'insérerait dans les DEVRULES
+
+**Après #4, avant le code** — dans la §1 (procédure obligatoire), comme un point 5.bis :
+
+```
+4. Trancher parmi les trois cas (§2)
+5. Si proposer : produire les livrables §4 AVANT la première ligne de code
+5.bis  ⟵  FAIRE RELIRE #3 et #4 par le catalogue de kinds, et itérer jusqu'à convergence
+6. Ne jamais sauter cette procédure « pour gagner du temps »
+```
+
+**Porte bloquante ou informative ?** À trancher. L'argument pour la rendre **informative** : un
+manque signalé peut légitimement ne pas concerner le projet, et une porte bloquante pousserait à
+écrire des lignes d'exigence pour faire taire l'outil — ce qui dégraderait les plans au lieu de les
+améliorer. L'argument pour la rendre **bloquante** : ce qui n'est pas bloquant est sauté.
+
+**Tranché le 06/09/2026 : INFORMATIVE, mais le rapport est un LIVRABLE** — versionné à côté de #3
+et #4. On n'ignore pas ce qui est écrit dans le dépôt.
+
+### Le livrable est un TRIPTYQUE, et son dernier état porte une signature
+
+| état | ce qu'il est | qui l'écrit |
+|---|---|---|
+| **plan initial** | le #3 / #4 tels qu'écrits, avant toute relecture | l'auteur |
+| **plan amélioré** | ce que l'outil propose — manques, erreurs, pièges | **l'outil** |
+| **plan révisé et approuvé** | ce que l'humain retient, écarte, et pourquoi | **l'humain, nommément** |
+
+⚠️ **Les trois états sont CONSERVÉS, pas remplacés.** Un plan amélioré qui écraserait le plan
+initial rendrait la comparaison impossible — et c'est précisément la comparaison qui dira, dans six
+mois, si l'outil a servi. C'est la même raison qui fait conserver `#3.bis` (l'objectif) **et** `#14`
+(le résultat) : **l'écart entre les deux est la mesure honnête de ce qui a dérivé.**
+
+⚠️ **Le troisième état exige un nom.** Un plan « approuvé » sans approbateur n'est pas approuvé :
+c'est un plan que personne n'a refusé. L'état porte donc le nom de l'humain qui l'a arrêté, et la
+liste de ce qu'il a **écarté** — écarter est une décision, pas une omission.
+
+## 5.bis · ⚠️ AVANT toute intégration aux DEVRULES — l'épreuve rétrospective
+
+**Décision du 06/09/2026 : la règle ne s'intègre pas avant d'avoir été éprouvée sur les projets
+DÉJÀ RÉALISÉS.** On passe leurs plans à la moulinette, et l'on compare au résultat atteint.
+
+C'est la transposition de la paire `#3.bis` / `#14` des DEVRULES — l'objectif et le résultat —
+appliquée non à une image, mais à un plan.
+
+### La condition qui rend l'épreuve honnête, et sans laquelle elle est truquée
+
+⚠️ **Une fiche née d'un incident du projet X ne peut PAS servir à juger le plan initial du projet
+X.** Elle connaît la réponse : elle a été écrite depuis la réponse. L'employer produirait un score
+flatteur et faux — l'outil « prédirait » ce dont il est issu.
+
+**Le corpus doit donc être borné dans le TEMPS et par l'ORIGINE** :
+
+> Pour diagnostiquer le plan initial du projet X daté du J, on n'emploie que les fiches
+> **dont aucune origine ne vient de X**, et **dont les origines sont antérieures à J**.
+
+Sans cette double borne, l'épreuve ne mesure rien. Avec elle, elle mesure quelque chose de réel :
+*ce qu'un autre projet avait déjà payé, et que celui-ci allait payer à son tour.*
+
+### Le protocole, pour chaque projet réalisé
+
+| # | geste | source |
+|---|---|---|
+| 1 | retrouver le **plan initial** — première version du #3/#4, ou du plan Dev+Test | historique git |
+| 2 | borner le corpus (temps + origine, ci-dessus) | `kind-catalog` |
+| 3 | **diagnostiquer** ce plan initial | `diagnostiquer()` |
+| 4 | relever ce que le projet a **réellement** ajouté ensuite | exigences, essais et **bugs** sur qatrax |
+| 5 | **classer** chaque manque signalé | ci-dessous |
+
+### Le classement — et il ne comporte AUCUN « faux »
+
+⚠️ **C'est le point le plus important de tout ce document.** Un manque signalé que le projet n'a pas
+suivi **n'est pas une erreur de l'outil**. Le besoin du commanditaire est le seul arbitre, et il
+peut légitimement aller ailleurs.
+
+| classe | ce qu'elle dit | lecture |
+|---|---|---|
+| **anticipé** | le projet a ajouté plus tard, de lui-même, ce que l'outil signalait | **l'outil aurait fait gagner du temps** — c'est la mesure utile |
+| **divergent** | le projet est allé ailleurs | **ni faux ni bon** : le commanditaire avait un autre besoin. À consigner, pas à compter comme échec |
+| **sans objet** | jamais devenu pertinent | bruit. À compter honnêtement — c'est le coût de la relecture |
+| **contredit** | le projet a explicitement écarté le point, avec motif | **le plus instructif** : la fiche doit peut-être porter une exception, comme `KIND-REFUS-LISIBLE-01` porte la sienne |
+
+**La mesure retenue n'est donc pas un taux de justesse.** C'est un couple :
+
+- **combien de ce qui a fini par compter était signalé d'avance** (rappel utile) ;
+- **combien de bruit il a fallu écarter pour l'obtenir** (coût de lecture).
+
+Un outil qui signale tout a un rappel parfait et un coût insupportable. C'est ce couple qu'il faut
+publier, jamais un chiffre unique.
+
+### Les projets candidats à l'épreuve
+
+Ceux qui ont **un plan initial daté** et **un résultat mesuré sur qatrax** : ATC Smart Campus,
+RestoTrax, LabTrax, CollabTrax, qatrax lui-même, SofTrax, CRM/TRADING.
+
+⚠️ **Et l'épreuve dira peut-être que la règle ne vaut pas.** C'est une issue possible, et elle doit
+rester ouverte : si le rappel utile est faible et le bruit élevé sur sept projets, la règle est
+écartée — **avec son motif**, comme une fiche.
+
+---
+
+## 6 · Ce qu'il reste à faire pour que la règle soit applicable
+
+| # | à faire | où |
+|---|---|---|
+| 1 | lire un plan de dev **en prose** (risques, jalons, portes de sortie) | `kind-catalog` — extraction, à instruire |
+| 2 | pondérer un manque par l'**origine** de sa fiche (garde c) | `kind-catalog` — `diagnostiquer` |
+| 3 | consigner les **passages** d'itération et ce qu'ils ont changé | à décider : un journal, ou le dépôt git suffit-il ? |
+| 4 | signaler l'**auto-diagnostic** (garde d) | `kind-catalog` — `rapportDiagnostic` |
+| 5 | **borner un corpus dans le temps et par l'origine** (§5.bis) — sans quoi l'épreuve est truquée | `kind-catalog` — `diagnostiquer` |
+| 6 | conduire l'**épreuve rétrospective** sur les sept projets | une session dédiée |
+| 7 | proposer la règle §1 point 5.bis à la validation — **ou l'écarter avec son motif** | DEVRULES |
+
+## 7 · Le nom
+
+« Assistant par catalogue éprouvé » — c'est ainsi que l'idée a été formulée le 05/09/2026, et le
+nom dit l'essentiel : **l'assistant ne conseille pas depuis un modèle de langage, il conseille
+depuis un catalogue dont chaque entrée a été payée.**

package/kinds/chiffres.kind.mjs

@@ -16,6 +16,7 @@ export const kinds = [
       'chaque valeur affichée provient d’une source RÉELLEMENT interrogée',
       'chaque compteur est cliquable vers la liste qui le compose',
       'la fraîcheur de chaque valeur est visible, et au-delà du seuil la valeur bascule en « sans données »',
+      'un affichage périmé AVOUE SON ÂGE — « au 04/09 à 11h12 » — plutôt que de présenter un chiffre comme actuel',
       'trois états, et trois seulement : non branché · branché sans données · branché réel',
     ],
     erreurs: [
@@ -25,6 +26,10 @@ export const kinds = [
         consequence: 'zéro est un FAIT ; « je ne sais pas » n’en est pas un. On lit une chute d’activité là où il y a une panne de collecte' },
       { titre: 'la valeur périmée continue d’être servie',
         consequence: 'le tableau de bord affiche avec le même aplomb une mesure d’hier et une d’il y a six mois' },
+      { titre: 'la valeur périmée est présentée SANS SON ÂGE',
+        consequence: 'elle a l’air normale, donc personne ne la vérifie. **Un affichage périmé qui a l’air normal coûte plus cher qu’un affichage qui avoue son âge** — le second se corrige, le premier se propage en décision' },
+      { titre: 'la valeur périmée est simplement effacée au profit de « sans données »',
+        consequence: 'on perd la dernière valeur CONNUE, qui reste souvent utile — mieux vaut « au 04/09 à 11h12 » que rien du tout. Les deux remèdes ne se valent pas : DATER conserve l’information, BASCULER la jette' },
       { titre: 'le compteur ne mène nulle part',
         consequence: 'un chiffre qu’on ne peut pas ouvrir ne se conteste pas — donc il ne se corrige jamais' },
       { titre: 'un second tableau de suivi est tenu à la main à côté',
@@ -32,7 +37,7 @@ export const kinds = [
     ],
     test: [
       { action: 'couper une source, puis afficher', attendu: '« sans données », jamais zéro' },
-      { action: 'vieillir une valeur au-delà du seuil de fraîcheur', attendu: 'elle bascule en « sans données » et le dit' },
+      { action: 'vieillir une valeur au-delà du seuil de fraîcheur', attendu: 'son ÂGE est affiché — « au 04/09 à 11h12 » — ou elle bascule en « sans données » ; jamais présentée comme actuelle' },
       { action: 'chercher dans le rendu un nombre absent des sources', attendu: 'aucun' },
       { action: 'suivre un compteur', attendu: 'il ouvre la liste filtrée qui le compose' },
     ],
@@ -40,6 +45,8 @@ export const kinds = [
     origine: [
       { type: 'incident', source: 'CollabTrax — « N’afficher aucune valeur sans source interrogée : jamais de nombre en dur, jamais de valeur d’exemple » ; trois états ; fraîcheur ; compteur cliquable', date: '2026-08-03' },
       { type: 'incident', source: 'ATC — le pilotage compose @mostajs/reporting ; la vue ne recalcule aucun total (T-PIL-10)', date: '2026-09-01' },
+      { type: 'incident', source: 'TicketFlow 2.0 — la page affiche l’ÂGE de la donnée : « file au 04/09 à 11h12 » quand le site est déconnecté, et non un chiffre présenté comme actuel', date: '2026-09-04' },
+      { type: 'incident', source: '@mostajs/paiement-tpe — `sonder()` rend « inconnu », jamais `false`, qui ferait croire l’appareil en panne alors qu’on n’en sait rien', date: '2026-08-20' },
     ],
   }),
 

package/kinds/decision.kind.mjs

@@ -83,6 +83,7 @@ export const kinds = [
       { type: 'incident', source: 'CRM/TRADING — copilote : transitions et réassignations, aperçu sans --confirm puis exécution (CARNET motif #2)', date: '2026-06-13' },
       { type: 'incident', source: 'RestoTrax — l’assistant-pilote n’a que deux écritures, et ce sont des DÉCISIONS (TPIL-7)', date: '2026-08-30' },
       { type: 'incident', source: 'ATC — l’écran de l’assistant ne porte aucune action métier (T-ASS-9)', date: '2026-09-01' },
+      { type: 'incident', source: '@mostajs/auto-pilot — `propose()` rend un brouillon INERTE (« modèle + aperçu, rien n’est résolu/agi ») avant que `solve()` n’engage quoi que ce soit', date: '2026-08-10' },
     ],
   }),
 ];

package/kinds/integration.kind.mjs

@@ -78,6 +78,7 @@ export const kinds = [
       { type: 'incident', source: 'LabTrax — « Fonctionner central injoignable : la perte du lien n’empêche NI le pointage, NI la délibération »', date: '2026-08-31' },
       { type: 'incident', source: 'SofTrax — « La révocation est signée donc opposable hors ligne, et coupe l’activation »', date: '2026-08-20' },
       { type: 'incident', source: 'LabTraxAdmin — même exigence, côté central : la licence ne se demande pas depuis l’instance', date: '2026-08-25' },
+      { type: 'incident', source: 'TicketFlow 2.0 — site déconnecté : la page le DIT et date la donnée, au lieu de servir un chiffre d’allure normale', date: '2026-09-04' },
     ],
   }),
 ];

package/kinds/traces.kind.mjs

@@ -8,6 +8,19 @@ export default defineKind({
   enonce: 'Retirer une chose, c’est la DATER — jamais la détruire.',
   utilisation: 'Toute entité qu’un utilisateur peut « supprimer » : dossier, projet, compte, rôle, activation, solveur.',
   besoins: [{ nom: 'champs de retrait', forme: '{ retireA, retirePar, motif }' }],
+  // ⚠️ DÉCLARÉS après l'épreuve rétrospective n° 1 (06/09/2026) : le plan de RestoTrax couvrait
+  // cette règle par « la désactivation est DATÉE, pas effacée » — et le diagnostic signalait
+  // 5 erreurs sur 5 comme absentes, faute de reconnaître « désactivation » dans « retrait ».
+  // Des RADICAUX, rapprochés par préfixe (voir `canonique` dans src/diagnostic.js) : c'est le
+  // vocabulaire du domaine, qu'aucun rapprochement lexical ne peut deviner, et il se déclare.
+  synonymes: [
+    ['retrait', 'retir', 'supprim', 'desactiv', 'archiv', 'effac'],
+    ['datee', 'date', 'horodat'],
+    ['conservee', 'conserv', 'survi', 'tombale', 'restaur'],
+    ['attribuee', 'attribu', 'nominat', 'auteur'],
+    ['ligne', 'entree', 'enregistr'],
+    ['motive', 'motif', 'raison', 'justifi'],
+  ],
   succes: [
     'la ligne SURVIT au retrait et porte sa date, son auteur et son motif',
     'ce qui est retiré n’apparaît plus dans les listes courantes',

package/llms.txt

@@ -9,14 +9,21 @@ EXPORTS
   toDevtest(kinds, { project, prefix }) -> plan mostajs-devtest/1 ; PLAN_VERSION
   instantiate(kind, { app, prefix, affine }) -> Instance ; diffInstance(i) ; emplois(instances) ; AFFINABLES
   loadCatalogue(dir) ; findKinds(kinds, {domaine,verdict,texte}) ; auditCatalogue(kinds) ; statsCatalogue(kinds)
+  diagnostiquer(plan, kinds, {minCommuns}) -> candidats ; rapportDiagnostic(...) ; TRANSVERSES
+  motsCles(texte) -> Set (mots de 4 lettres et plus, hors mots vides) ; normaliser(texte)
 CHAMPS DE LA FICHE
   ref (KIND-…) · enonce · domaine · version · besoins · utilisation · succes* · erreurs* · test
+  synonymes  groupes de RADICAUX du domaine, rapproches par prefixe (4 lettres mini, groupe de 2 mini)
   efficacite · evaluation · verdict · motif · origine* · seProsePose        (* = requis)
 VERDICTS  propose | eprouve | retenu | ecarte
 PROVENANCES  reference (norme, litterature) | terrain (praticien nomme) | incident (defaut constate)
 DOMAINES  acces donnees apprentissage decision integration · btp alimentaire elevage apiculture agronomie electronique
 PIÈGES
   - `succes` ET `erreurs` sont REQUIS : ce sont les champs qu'on omet, et ceux qui servent.
+  - La COUVERTURE se juge sur le `titre` d'une erreur, jamais sur sa `consequence` : la
+    consequence est NOTRE prose, un plan n'a aucune raison de la contenir.
+  - Sans `synonymes`, deux textes qui disent la meme chose avec d'autres mots ne se reconnaissent
+    PAS : « retrait » ne vaut pas « desactivation » pour une machine. Cela se declare.
   - Chaque erreur porte sa CONSEQUENCE : « ne pas oublier X » ne se retient pas (lecon CWE/OWASP).
   - `eprouve`/`retenu` EXIGENT une origine `incident` ou `terrain` : on ne se decerne pas
     l'experience. Une `reference` suffit pour ENTRER au catalogue en `propose` — la contrainte
@@ -35,4 +42,8 @@ PIÈGES
   - loadCatalogue() fait un import() : charger un corpus, c'est EXECUTER du code. Une fiche se revoit
     comme du code, jamais comme un document (docs/15-REVUE-SECURITE).
   - validateKind() applique les memes defauts que defineKind : on peut lui passer un objet BRUT.
+  - DIAGNOSTIC : les deux sorties sont DECOUPLEES. Occurrences = precision (seuil 5 ; a 2 il en proposait
+    27 pour une regle). Erreurs non couvertes = rappel, cherchees dans TOUT le plan, rendues meme sans
+    occurrence. Regle TRANSVERSE parle toujours ; regle METIER seulement si reconnue.
+  - Le diagnostic PROPOSE, il n'applique pas, et il ne modifie pas le plan qu'il lit.
 CORPUS LIVRE  21 fiches · 15 eprouvees (71 %) · 84 erreurs cataloguees · 35 incidents · 11 domaines.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mostajs/kind-catalog",
-  "version": "0.2.0",
+  "version": "0.4.0",
   "description": "Catalogue de KINDS — fiches d'exigence réutilisables, projetables en plan mostajs-devtest/1 lisible par qatrax. N'exécute rien, ne stocke rien.",
   "type": "module",
   "license": "AGPL-3.0-or-later",