@mostajs/kind-catalog 0.1.0

package/docs/14-PROMPT-IMAGE-KIND-CATALOG.md

@@ -0,0 +1,88 @@
+# Prompt d'image — le RÉSULTAT de `@mostajs/kind-catalog`
+
+**Livrable #14** (DEVRULES §9) · **Auteur** : Dr Hamid MADANI <drmdh@msn.com> · **Date** : 2026-09-02
+**Version illustrée** : 0.1.0
+
+> Le **#3.bis** montrait la cible **planifiée**, validée avant le code. Celui-ci montre ce qui est
+> **réellement livré**. Les deux se comparent : l'écart est la mesure honnête de ce qui a dérivé.
+
+---
+
+## 1 · L'écart avec l'image de l'objectif — à lire d'abord
+
+| ce que le #3.bis annonçait | ce qui est livré | écart |
+|---|---|---|
+| quatre stations : incident → fiche → projection → applications | **identique** | — |
+| flèche de retour « écart tracé » | **identique** (`instantiate` + `emplois`) | — |
+| bande de domaines, quatre pleines et cinq en contour | **dix domaines**, quatre pleins et **six** en contour | +1 : `apiculture`, demandée le 02/09 |
+| deux boîtes grisées : `ro-pla`, `skill-library` | **identiques** | — |
+| — | **une case « provenance » sur la fiche** | **AJOUT** — la règle « aucune fiche avant un cas réel » a été corrigée en cours de route |
+| — | **un compteur : 12 fiches · 39 erreurs · 50 % éprouvé** | **AJOUT** — le chiffre qui engage |
+
+**Le seul écart de fond est la provenance.** Le plan initial interdisait toute fiche sans incident
+maison ; cela aurait laissé le catalogue vide dans six métiers où le savoir existe depuis des
+décennies. La règle a été déplacée : elle porte sur le **galon** (`eprouve`), plus sur l'entrée.
+L'image du résultat doit le montrer — c'est la décision la plus importante du cycle.
+
+## 2 · Ce que l'image doit faire comprendre
+
+1. Une fiche **naît d'une source déclarée** — incident, terrain, **ou corpus établi**.
+2. Le **verdict** dit ce qu'elle a traversé ; il ne se décerne pas.
+3. Elle **descend dans le plan de test** du projet.
+4. Ce que le terrain lui fait dire **remonte**.
+5. Le module **ne calcule rien et ne range rien**.
+
+## 3 · Le prompt
+
+```
+Schéma technique 16:9, fond blanc cassé, style diagramme d'architecture logicielle sobre,
+traits fins, palette restreinte : gris ardoise, un bleu profond pour le flux principal,
+un rouge sombre réservé aux erreurs, un vert sourd réservé au verdict éprouvé.
+Typographie sans-serif, étiquettes courtes.
+
+Flux horizontal de gauche à droite en quatre stations reliées par des flèches pleines :
+
+(1) TROIS sources empilées, chacune sur une ligne, avec sa pastille :
+    « corpus établi » (norme, guide) — pastille creuse ;
+    « terrain » (praticien nommé) — pastille demi-pleine ;
+    « incident » (défaut constaté, daté) — pastille pleine, liseré rouge sombre.
+    Légende : « toute fiche déclare d'où elle vient ».
+
+(2) une carte-document aux cases visibles — énoncé, besoins, succès,
+    ERREURS (case plus haute, bordée de rouge sombre, portant « + conséquence »),
+    épreuve, PROVENANCE, VERDICT (petit galon vert sourd « éprouvé »).
+    Légende : « KIND — écrite une fois ».
+    Note discrète sous la carte : « éprouvé exige un fait — on ne se décerne pas l'expérience ».
+
+(3) la carte se dédouble en deux blocs étiquetés « exigences » et « essais »,
+    marqués « mostajs-devtest/1 », légende « lue par l'outil de suivi, sans rien lui apprendre ».
+    Un petit fanion « draft » sur les exigences issues de fiches seulement proposées.
+
+(4) trois fenêtres d'application alignées, la troisième vide et marquée « le prochain »,
+    recevant chacune la même carte. Légende « réutilisée ».
+
+Flèche de retour fine, en pointillés, de (4) vers (2), étiquetée
+« l'écart tracé — ce que cette application a affiné, et pourquoi ».
+
+Bande inférieure de pastilles de domaines : quatre PLEINES
+(accès, données, apprentissage, décision) puis six en CONTOUR SEUL
+(BTP, alimentaire, élevage, apiculture, agronomie, électronique).
+
+Encart chiffré en bas à droite, discret, en trois lignes :
+« 12 fiches · 39 erreurs cataloguées · 50 % éprouvé ».
+
+Marge droite, hors du flux, deux boîtes grisées reliées par des traits fins :
+« ro-pla — les moteurs » et « skill-library — l'efficacité mesurée »,
+sous-titre « composés, pas réécrits ».
+
+Pas de cylindre de base de données, pas d'engrenage, pas de flèche circulaire autour du
+module, pas d'arbre de classement, pas de logo, pas de visage, pas de métaphore.
+```
+
+## 4 · Critère d'acceptation
+
+Mêmes trois questions que le #3.bis, plus une quatrième propre au résultat :
+
+4. *Une fiche tirée d'une norme a-t-elle sa place au catalogue ?* → **oui, en `propose`**.
+
+Si la réponse est « non », l'image reproduit la règle **abandonnée**, et elle est refaite.

package/docs/15-REVUE-SECURITE-KIND-CATALOG.md

@@ -0,0 +1,98 @@
+# Revue de sécurité & abus — `@mostajs/kind-catalog`
+
+**Livrable #15** (DEVRULES §9, §11.2 — **informatif**) · **Auteur** : Dr Hamid MADANI <drmdh@msn.com>
+**Date** : 2026-09-02 · **Version** : 0.1.0
+
+---
+
+## 1 · Surface d'attaque — ce qui existe vraiment
+
+| surface | présente ? | note |
+|---|---|---|
+| port réseau, serveur | **non** | le module n'écoute rien |
+| base de données, dépôt | **non** | il ne stocke rien |
+| appel sortant (HTTP, DNS) | **non** | aucune dépendance de production |
+| secret, clé, jeton | **non** | il n'en manipule aucun |
+| exécution de code | **OUI** | `loadCatalogue()` **importe des modules** |
+| entrée utilisateur | oui, indirecte | les fiches, et les données passées à `instantiate` |
+| sortie vers un tiers | oui | le plan projeté part vers **qatrax** |
+
+## 2 · ⚠️ LE RISQUE PRINCIPAL — le corpus est du CODE, pas de la donnée
+
+`loadCatalogue(dir)` fait un `import()` dynamique de chaque `*.kind.mjs`. **Charger un corpus, c'est
+exécuter du code**, avec tous les droits du processus appelant.
+
+| acteur | scénario | conséquence |
+|---|---|---|
+| qui peut écrire dans `kinds/` | dépose un `.kind.mjs` malveillant | **exécution arbitraire** au premier `loadCatalogue()` — lecture de secrets, exfiltration, tout |
+| un contributeur du dépôt | glisse un effet de bord dans une fiche | idem, revu comme un « document » alors que c'est du code |
+| une chaîne d'intégration | charge un corpus tiers non audité | idem, sur la machine de build |
+
+**Ce n'est pas un défaut du module : c'est la conséquence du choix « fiches = fichiers versionnés ».**
+Le même choix donne l'historique, la relecture et la discussion — il faut en payer le prix.
+
+### Mesures
+
+| mesure | état |
+|---|---|
+| **une fiche se revoit comme du code**, pas comme un document — revue obligatoire en PR | **règle, à tenir** |
+| **ne jamais charger un corpus dont on ne contrôle pas l'écriture** (téléversement, dossier partagé, dépendance non épinglée) | **règle, à tenir** |
+| `T-KC-12` interdit déjà `require(`, `writeFile`, `createConnection` **dans `src/`** | ✔ automatisé |
+| ⚠️ **aucun contrôle équivalent sur `kinds/`** — une fiche PEUT faire ce qu'elle veut | **ouvert** |
+| corpus **déclaratif** (JSON/YAML) plutôt qu'exécutable | **écarté en 0.1.0** — perdrait `defineKind()` et sa validation au montage. **À rouvrir** si un corpus tiers devient un cas d'usage |
+
+**Recommandation pour 0.2.0** : étendre le contrôle de `T-KC-12` aux fichiers de `kinds/` (aucun
+`import` autre que `defineKind`, aucun appel de fonction hors `defineKind`). Cela ne supprime pas le
+risque — un fichier importé s'exécute — mais il le rend visible en revue et en CI.
+
+## 3 · Ce que la validation NE vérifie PAS
+
+**La provenance est déclarative.** `validateKind` contrôle la **forme** d'une origine — un `type`
+connu, une `source` non vide — **jamais sa vérité**. Rien n'empêche d'écrire :
+
+```js
+origine: [{ type: 'incident', source: 'inventé de toutes pièces', date: '2026-09-02' }]
+verdict: 'eprouve'
+```
+
+**Le module ne peut pas le détecter, et ne le prétend pas.** C'est une garantie **de procédure**,
+pas de technique : la revue de la fiche, et l'exigence que l'`origine` d'un incident cite un
+fichier et une date **vérifiables dans le dépôt**.
+
+> C'est la limite honnête du dispositif, et elle doit être dite au client comme à l'investisseur :
+> le taux éprouvé mesure une **discipline**, pas une preuve cryptographique.
+
+## 4 · Autres scénarios d'abus
+
+| scénario | conséquence | parade |
+|---|---|---|
+| une fiche injecte du contenu dans `description` (le plan projeté part chez qatrax) | contenu arbitraire affiché dans l'outil de suivi | qatrax échappe ses sorties ; **la vraie parade est la revue de la fiche** |
+| deux applications choisissent le même `prefix` | leurs exigences collisionnent dans un même qatrax | **non détecté par le module** — convention d'organisation ; `T-KC-7` prouve seulement que des préfixes distincts isolent |
+| `ref` réutilisée après un `ecarte` | on cite une fiche pour une autre | `auditCatalogue` détecte le doublon **dans un même corpus**, pas dans le temps |
+| déni de service par corpus géant | `loadCatalogue` charge tout en mémoire | usage hors ligne, en CI ; **non traité**, et assumé |
+
+## 5 · §11.2 — OWASP LLM : NON APPLICABLE, et voici pourquoi
+
+Aucun modèle de langage n'est employé : ni invite, ni sortie de modèle, ni outil à effet de bord.
+**Aucune injection d'invite n'est possible faute d'invite.**
+
+Cette absence est une **conséquence**, pas un oubli. Le jour où une reformulation en langue
+naturelle serait ajoutée — par exemple pour rédiger une fiche à partir d'un récit d'incident —
+cette porte devra être franchie, et cette section réécrite.
+
+## 6 · Effets de bord — le contrôle qui tient
+
+`T-KC-12` exerce toute la surface publique contre un dépôt **piégé** et compte les touches : zéro.
+Il relit aussi les sources pour interdire `require(`, l'import de `ro-pla`, `writeFile` et
+`createConnection` hors de `catalogue.js`.
+
+**Une garantie tenue par la seule intention se perd à la version suivante.** Celle-ci est comptée.
+
+## 7 · Synthèse
+
+| | |
+|---|---|
+| risque **élevé** | **le corpus est du code exécutable** — §2 |
+| risque **moyen** | provenance déclarative, non vérifiable — §3 |
+| risque **faible** | collision de préfixes, contenu injecté dans le plan — §4 |
+| **hors sujet** | secrets, réseau, stockage, LLM |

package/docs/16-DPIA-CONFORMITE-KIND-CATALOG.md

@@ -0,0 +1,100 @@
+# DPIA & conformité — `@mostajs/kind-catalog`
+
+**Livrable #16** (DEVRULES §9, §11.3 — **informatif**) · **Auteur** : Dr Hamid MADANI <drmdh@msn.com>
+**Date** : 2026-09-02 · **Version** : 0.1.0
+
+---
+
+## 1 · Le module traite-t-il des données personnelles ?
+
+**Réponse courte : pas dans son fonctionnement — mais son CORPUS peut en contenir.**
+
+| ce que le module manipule | donnée personnelle ? |
+|---|---|
+| l'énoncé, les besoins, les critères de succès d'une fiche | non |
+| les erreurs connues et leurs conséquences | non |
+| le plan projeté (`mostajs-devtest/1`) | non |
+| **le champ `origine`** | **OUI, potentiellement** |
+
+## 2 · ⚠️ Le point à traiter : `origine.type = 'terrain'`
+
+La définition retenue est : *« le dire d'un praticien, **nommé et daté** »*. Nommer un praticien,
+c'est traiter une donnée personnelle — et le fichier est **versionné, publié sur npm, et poussé sur
+GitHub**. Autrement dit : **public, indexable et pratiquement indélébile**.
+
+Trois traitements distincts, à ne pas confondre :
+
+| cas | donnée | risque |
+|---|---|---|
+| `type: 'reference'` | un titre, un auteur d'ouvrage, une norme | **aucun** — donnée bibliographique publique |
+| `type: 'incident'` | un fichier, une date, une application | **aucun** en principe — sauf si le chemin ou le message contient un nom |
+| **`type: 'terrain'`** | **le nom d'une personne physique** | **réel** — publication, durée illimitée, hors de son contrôle |
+
+### La règle retenue
+
+> **Un `terrain` se cite par son RÔLE et son organisation, jamais par son nom** — sauf accord
+> écrit de l'intéressé, mentionné dans la source.
+>
+> `source: 'chef de culture, exploitation X, entretien du 12/09/2026'` ✔
+> `source: 'M. Untel'` ✘
+
+**Motif** : la valeur documentaire est identique — ce qui compte est la **qualité** de celui qui
+parle, pas son identité — et le risque disparaît. Un nom n'ajoute rien à la fiche ; il ajoute une
+obligation à vie.
+
+⚠️ **Cette règle n'est PAS contrôlée par le code en 0.1.0.** `validateKind` vérifie que `source`
+n'est pas vide, pas qu'elle est anonymisée. C'est une **règle de revue**, et elle doit figurer dans
+la revue de toute fiche `terrain`.
+
+## 3 · Les autres traitements
+
+**Chemins de fichiers et messages d'incident.** Une origine `incident` cite un fichier et une date.
+Un chemin peut contenir un nom d'utilisateur (`/home/prenom/…`). **À normaliser à la racine du
+dépôt** avant publication — le corpus livré aujourd'hui n'en contient aucun, vérifiable.
+
+**Aucun transfert.** Le module n'émet aucune requête. Le plan projeté est poussé vers **qatrax**,
+instance de l'éditeur — pas de tiers, pas de sous-traitant hors périmètre.
+
+**Aucune conservation.** Le module ne stocke rien : il n'y a ni durée de conservation, ni purge à
+définir. Ce qui se conserve, ce sont les **fichiers** du dépôt, avec l'historique git.
+
+## 4 · Souveraineté
+
+| | |
+|---|---|
+| hébergement du corpus | dépôt de l'éditeur + npm (registre public) |
+| dépendances de production | **aucune** — donc aucune chaîne d'approvisionnement à auditer côté runtime |
+| appels sortants | **aucun** |
+| licence | **AGPL-3.0-or-later** — le code reste ouvert et vérifiable |
+
+## 5 · Droits des personnes — la difficulté propre à un corpus versionné
+
+Si une fiche `terrain` nommait une personne et que celle-ci demandait l'effacement :
+
+- **retirer la mention** de la fiche : faisable, immédiat ;
+- **effacer l'historique git** : possible mais lourd (réécriture, `--force-with-lease`, coordination
+  des clones) ;
+- **effacer les versions npm déjà publiées** : **impossible en pratique** — dépublier est
+  déconseillé et les copies existent.
+
+> **C'est précisément pourquoi la règle du §2 est préventive et non curative.** On n'écrit pas un
+> nom qu'on ne pourra pas retirer.
+
+## 6 · Recommandations
+
+| # | recommandation | échéance |
+|---|---|---|
+| 1 | citer les `terrain` par **rôle + organisation + date**, jamais par nom | **immédiat**, règle de revue |
+| 2 | normaliser les chemins de fichiers à la racine du dépôt dans les `incident` | immédiat |
+| 3 | ajouter un contrôle automatique : refuser une `source` qui ressemble à un nom propre isolé | **0.2.0** — imparfait par nature, mais il attrape l'étourderie |
+| 4 | mentionner cette section dans le gabarit de revue d'une fiche `terrain` | immédiat |
+
+## 7 · Verdict
+
+**Traitement de données personnelles : marginal et évitable.** Aucun DPIA complet n'est requis pour
+le module lui-même. La seule exposition réelle est le champ `origine.terrain`, et elle se referme
+par une **règle d'écriture** — pas par une mesure technique.
+
+⚠️ Ce document couvre **le module**. Une application qui l'emploie traite, elle, des données
+personnelles (élèves, clients, exploitants) : son propre DPIA reste entier et ne s'appuie pas sur
+celui-ci.

package/docs/ARTICLE-SEO-KIND-CATALOG.md

@@ -0,0 +1,96 @@
+# Ce que les catalogues d'erreurs nous apprennent sur les exigences
+
+**Livrable #8** (part 2/2) · **Auteur** : Dr Hamid MADANI <drmdh@msn.com> · **Date** : 2026-09-02
+
+---
+
+## Un défaut coûte deux fois : la première pour le trouver, la seconde pour le retrouver
+
+En une semaine, sur deux applications en production — une école de langues, un restaurant — nous
+avons trouvé cinq défauts. Aucun ne plantait. Tous étaient silencieux :
+
+- une note d'élève enregistrée **sans son niveau**, découverte douze écrans plus loin, quand le
+  certificat a répondu « aucun niveau atteint » sur un élève qui avait ses notes ;
+- un secrétariat porteur du droit de lire les dossiers familiaux, et dont **l'écran s'ouvrait sur
+  une liste vide** — la capacité sans le périmètre, c'est-à-dire rien ;
+- une leçon terminée qui **redevenait à faire** quand l'élève la relisait ;
+- un compte-rendu **écrasé** par la correction de la note qui l'accompagnait ;
+- une reprise de données qui annonçait « 2 lignes reprises » et dont le travail **avait disparu le
+  lendemain**, écrasé par l'application vivante.
+
+Cinq défauts, cinq domaines différents, une seule chose en commun : **aucun n'était nouveau**. Ils
+ont tous une littérature, un nom, parfois une norme. Et pourtant rien ne les attendait.
+
+## La sécurité a résolu ce problème il y a vingt ans
+
+Personne, en sécurité applicative, ne redécouvre l'injection SQL. Elle porte un numéro — `CWE-89` —
+et cette entrée porte sa description, **ses conséquences**, ses exemples et sa détection. Un
+scanner la connaît. Un développeur peut la citer. Elle désigne la même chose pour tout le monde
+depuis vingt ans.
+
+Trois choses font que ce catalogue marche, et elles ne sont pas évidentes :
+
+**1. Chaque entrée porte sa conséquence.** « Valider les entrées » ne se retient pas. « Sans
+validation, l'utilisateur choisit la requête » se retient. C'est la différence entre une consigne
+et un avertissement.
+
+**2. Il est nourri par des faits.** ATT&CK ne consigne que des techniques **observées**. Un
+catalogue nourri d'idées grossit vite et ne sert jamais.
+
+**3. Il est branché.** CWE alimente des scanners. C'est ce qui le rend appliqué plutôt que
+consulté.
+
+## L'exigence, elle, n'a jamais eu son CWE
+
+Il existe pourtant un catalogue de patrons d'exigences réutilisables — *Software Requirement
+Patterns*, Stephen Withall, 2007. Excellent, complet. **Et il est resté un livre**, parce qu'il
+n'était branché à rien.
+
+C'est l'écart que nous occupons : une fiche qui porte l'**énoncé**, les **critères de succès**, les
+**erreurs connues avec leur conséquence** et les **épreuves** — et qui **descend dans le plan de
+test du projet**. Pas dans un document parallèle : dans le plan que l'équipe exécute déjà.
+
+## Le champ qui change tout : « erreurs »
+
+Voici ce que porte notre fiche sur le périmètre d'accès, tirée mot pour mot de la production :
+
+> **la capacité est prise pour le périmètre** → *un enseignant pointe la séance d'un collègue, un
+> parent lit le dossier d'un autre enfant — avec exactement les mêmes droits, et l'écran ne montre
+> rien d'anormal.*
+>
+> **le cumul de rôles desserre la garde** → *ajouter un rôle ÉLARGIT le périmètre — c'est l'inverse
+> de ce qu'une garde doit faire.*
+>
+> **le champ porteur est vide** → *`undefined === undefined` vaut vrai : l'instance est donnée à
+> tout le monde, et seuls les enregistrements incomplets sont touchés.*
+
+Un développeur qui lit cela avant d'écrire ne perdra pas la semaine que nous avons perdue.
+
+## Ce que le métier nous a appris en retour
+
+Nous avons ouvert le catalogue à six métiers : BTP, alimentaire, élevage, apiculture, agronomie,
+électronique. Chacun a **son propre catalogue depuis des décennies** — DTU, HACCP, plans de
+rationnement, guides de bonnes pratiques, *design rules*. Et deux d'entre eux nous ont corrigés :
+
+**HACCP va plus loin que CWE.** Pour chaque danger, il exige non seulement la conséquence, mais
+**ce qu'on fait quand la limite est franchie**. Un catalogue d'erreurs *actionnable*.
+
+**L'apiculture nous a appris à refuser.** Une miellée dure quelques jours par an. Un apiculteur de
+dix ans d'expérience dispose de **dix points**, dont aucun n'est comparable à l'autre. Aucune
+prévision statistique n'y tient — et le dire vaut mieux que le calculer. Cela nous a fait corriger
+une fiche transverse : **un seuil de données s'exprime en cycles, jamais en jours.** Deux saisons
+font deux semaines en restauration, deux ans en grande culture.
+
+## Un outil qui sait refuser
+
+C'est peut-être le point le plus contre-intuitif. Un outil d'aide à la décision qui répond toujours
+inspire confiance jusqu'au premier chiffre invérifiable. Un outil qui dit *« il manque onze jours
+d'observation »* se corrige.
+
+« Pas disponible » n'apprend rien. « Il manque onze jours » se corrige. C'est toute la différence,
+et elle tient dans une phrase de la fiche.
+
+---
+
+**`@mostajs/kind-catalog`** — AGPL-3.0-or-later. 12 fiches, 39 erreurs cataloguées, 10 domaines.
+Le catalogue ne calcule rien : il décrit, valide, et projette dans le plan de test du projet.

package/docs/AUDIT-EXISTANT-KIND-CATALOG.md

@@ -0,0 +1,127 @@
+# Audit de l'existant — `@mostajs/kind-catalog`
+
+**Livrable #2** (DEVRULES §9) · application de la **règle d'or §0** · **cas C** (§2)
+
+**Auteur** : Dr Hamid MADANI <drmdh@msn.com> · **Date** : 2026-09-02
+**Emplacement retenu** : `mostajs/mosta-optimization-stack/` — aux côtés de `ro-pla`
+*(décision du 02/09/2026 : « sa place est avec les ro-pla »)*
+
+---
+
+## 4.1 · Le besoin
+
+**Directive du 02/09/2026** :
+
+> *le catalogue dans un module à part que qatrax pourra lire, et que les kinds soient réutilisés ou
+> affinés pour toute nouvelle utilisation dans les applications passées et futures.*
+
+Un **kind** est une **fiche d'exigence réutilisable** : une question qu'un métier se pose, avec ce
+qu'il faut pour y répondre, comment on l'éprouve, à quoi on reconnaît une bonne réponse, et **les
+façons connues de se tromper**. Aujourd'hui, cette matière existe — mais éparpillée et non
+réutilisable :
+
+| où elle vit aujourd'hui | ce qui s'y trouve | pourquoi c'est perdu |
+|---|---|---|
+| `docs/DEVTEST-PLAN.*.json` (une par application) | exigences, essais, refus attendus | **recopiés** d'un projet à l'autre, jamais reliés |
+| `llms.txt` (237 modules) | `RÔLE`, `PIÈGES` | lisibles par un humain, **pas projetables** |
+| `SOLVEURS` de RestoTrax, `solveursDe()` d'ATC | question, condition, seuils | **deux écritures du même raisonnement** |
+| têtes de fichiers, CHANGELOGs | les défauts trouvés et pourquoi | **jamais** relus par un autre projet |
+
+Le coût est mesurable dans cette seule session : quatre défauts trouvés en recette ATC
+(note sans niveau, capacité sans périmètre, page annonçant un incrément livré, écriture sqljs hors
+application) sont **génériques** — ils reparaîtront ailleurs, et rien ne les y attend.
+
+## 4.2 · Application de la règle d'or (§0)
+
+| module candidat | ce qu'il fait | pourquoi il ne suffit pas |
+|---|---|---|
+| **`@mostajs/qa-engine`** (`./devtest`) | lit, valide et importe un plan `mostajs-devtest/1` | il **valide un plan d'application**, il ne porte aucun **catalogue réutilisable** : rien n'y est partagé entre projets |
+| **`@mostajs/skill-library`** | mémorise des **recettes** de résolution par signature, avec indice d'efficacité | elle sait *comment bien résoudre*, pas *si la question mérite d'être posée ni ce qui la rend fausse*. **Complémentaire, pas substituable** |
+| **`@mostajs/ro-pla`** (`listSolvers`, `pickBest`) | registre de **dialectes** par `kind` technique | son `kind` est un type de problème mathématique, pas une **exigence métier** |
+| **`@mostajs/dialect-registry`** | sélection d'implémentation par nom | mécanisme de choix, sans contenu |
+| **`@mostajs/rules`**, **`@mostajs/intent-router`** | règles d'exécution, routage d'intention | décident **à l'exécution** ; une fiche `kind` se lit **avant** d'écrire du code |
+
+**Conclusion : cas C**, mais un cas C **mince**, qui compose `qa-engine` et voisine `skill-library`.
+
+## 4.3 · L'argumentation — les trois décisions structurantes
+
+### a) Un kind ne définit AUCUN format nouveau : il se PROJETTE en `mostajs-devtest/1`
+
+C'est la façon la plus sûre de rendre le catalogue lisible par qatrax : **ne rien lui apprendre**.
+Une fiche se projette en `specs` + `tests` du plan que qatrax parse déjà depuis toujours.
+
+> Inventer un second format aurait demandé un second validateur, un second import, un second
+> écran — et le jour où les deux divergent, c'est le catalogue qui aurait raison contre les faits.
+
+### b) Le catalogue est un CORPUS DE FICHIERS ; les instances vivent dans les applications
+
+Une fiche `kind` est un **document éditorial** : elle se lit, se discute, se relit six mois plus
+tard, et son historique est celui d'un fichier versionné. Elle ne va pas en base.
+
+Ce qui va en base, c'est ce que produit son **usage** — exécutions, indices d'efficacité, retours
+d'utilisateur — et cela appartient déjà à `skill-library` et au journal d'`assistant-pilote`.
+
+**Les deux ne se rangent pas au même endroit parce qu'ils n'ont pas la même durée de vie : la
+fiche se relit, le journal s'entasse.**
+
+### c) RÉUTILISER ou AFFINER — et l'affinage se TRACE
+
+Une application n'utilise pas une fiche : elle l'**instancie**. L'instance porte
+`kind`, `kindVersion`, ses `refs` propres, et **la liste de ce qu'elle a affiné**. C'est ce qui
+rend l'affinage sûr dans les deux sens :
+
+- **vers l'avant** — on sait quelles applications emploient un kind, donc qui prévenir quand il
+  change ;
+- **vers l'arrière** — une application ancienne dit ce qu'elle avait dû changer, et cet écart est
+  **la première matière** de la version suivante de la fiche.
+
+> Sans cette trace, « réutiliser » se dégrade en « recopier », et l'on revient à l'état actuel :
+> quatre plans DEVTEST qui se ressemblent sans jamais se parler.
+
+## 4.4 · Discussion du besoin — ce que le module NE fera PAS
+
+- **Il n'exécute rien.** Ni solveur, ni essai, ni règle. Il décrit et projette.
+- **Il ne stocke rien.** Aucun schéma, aucun dépôt, aucun `register` de persistance.
+- **Il ne remplace pas les plans d'application.** Un plan reste propre à son application ; le
+  catalogue lui fournit des exigences **déjà écrites et déjà éprouvées ailleurs**.
+- **Il ne classe pas les kinds par algorithme.** Un kind est une **question**, pas un dialecte :
+  `ro-pla` en propose 23 pour 12 familles, et plusieurs questions métier partagent le même moteur.
+
+## 4.5 · Documentation technique — la surface ENVISAGÉE
+
+> ⚠️ **Esquisse, pas contrat.** La surface définitive est fixée par le livrable **#3**
+> (`PLAN-DEV-KIND-CATALOG.md`) et éprouvée par le **#4** (`PLAN-TESTS.md`). Rien ne se code avant.
+
+```js
+import { defineKind, validateKind, toDevtest, instantiate, catalogue } from '@mostajs/kind-catalog';
+
+const k = defineKind({
+  ref: 'KIND-PERIMETRE-01',
+  enonce: 'Une permission ouvre une CAPACITÉ, jamais un PÉRIMÈTRE.',
+  domaine: 'acces',
+  besoins: [{ nom: 'lien d’appartenance', forme: '(agent, instance) => bool' }],
+  utilisation: 'Toute application où un rôle agit sur des instances qui ne sont pas toutes siennes.',
+  succes: ['le porteur agit sur les siennes', 'il est refusé sur celles d’autrui'],
+  erreurs: [
+    { titre: 'le cumul de rôles desserre la garde', consequence: 'ajouter un rôle ÉLARGIT le périmètre' },
+    { titre: 'le champ porteur est vide', consequence: '`undefined === undefined` donne l’instance à tout le monde' },
+  ],
+  test: [{ action: 'agir sur l’instance d’un autre', attendu: 'refus, sans nommer l’instance' }],
+  verdict: 'eprouve',
+});
+
+toDevtest([k], { project: { key: 'atc', name: 'ATC' }, prefix: 'ATC' });  // → mostajs-devtest/1
+instantiate(k, { prefix: 'ATC', affine: { succes: [...] } });             // → instance TRACÉE
+```
+
+- **Couche N1** (générique transverse) : dépend de `@mostajs/qa-engine` pour la **conformité** de
+  ce qu'il projette, et de rien d'autre.
+- **Aucune dépendance runtime lourde**, aucune UI, aucun stockage.
+
+## 5 · Verdict de l'audit
+
+**Cas C** — un module à créer, mais **mince** : quatre besoins précis (B1, B2, B4, B5 de l'étape
+inaugurale) et rien d'autre. Tout le reste est composé, sans extension d'aucun module existant.
+
+La suite du §9 s'applique dans l'ordre : **#3** plan de développement, **#3.bis** image de
+l'OBJECTIF, **#4** plan de test — **puis** le code.