@mostajs/kind-catalog 0.1.0

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

@@ -0,0 +1,186 @@
+# Plan de développement — `@mostajs/kind-catalog`
+
+**Livrable #3** (DEVRULES §9) · **Auteur** : Dr Hamid MADANI <drmdh@msn.com> · **Date** : 2026-09-02
+**Couche** : N1 · **Pile** : `mosta-optimization-stack` · **Licence** : AGPL-3.0-or-later
+
+Amont : `00-ETAPE-INAUGURALE`, `ETUDE-ETAT-ART-…`, `AUDIT-EXISTANT-…`.
+
+---
+
+## 1 · Périmètre
+
+**Le module décrit, valide et projette. Il n'exécute rien et ne stocke rien.**
+
+| dans le périmètre | hors périmètre, et où cela vit |
+|---|---|
+| la **fiche** `kind` et sa validation | l'exécution d'un solveur → `@mostajs/ro-pla` |
+| la **projection** en `mostajs-devtest/1` | la validation de ce plan → `@mostajs/qa-engine` |
+| l'**instanciation tracée** dans une application | l'activation sous condition → `@mostajs/assistant-pilote` |
+| l'**index** du corpus (qui emploie quoi) | l'efficacité et le retour d'usage → `@mostajs/skill-library` |
+| — | la **persistance** : les fiches sont des **fichiers versionnés** (§3) |
+
+## 2 · Architecture
+
+```
+kinds/*.kind.mjs        ← LE CORPUS : une fiche = un fichier versionné
+   │  defineKind()
+   ▼
+src/kind.js             cœur PUR — définir, valider
+src/projection.js       fiche(s) ──► mostajs-devtest/1   (lu par qa-engine, importé par qatrax)
+src/instance.js         fiche + application ──► instance TRACÉE (ce qui a été affiné)
+src/catalogue.js        charger le corpus, chercher, indexer les emplois
+src/index.js            surface publique
+```
+
+**Aucune I/O dans le cœur.** `catalogue.js` est le seul à lire des fichiers, et il reçoit son
+chemin — il ne le devine pas.
+
+## 3 · La décision de stockage, et son motif
+
+**Les fiches sont des FICHIERS VERSIONNÉS. Les données d'usage vont en base — ailleurs.**
+
+| | la fiche | les données d'usage |
+|---|---|---|
+| nature | document éditorial | journal qui s'accumule |
+| durée de vie | se relit six mois plus tard | s'entasse et se purge |
+| ce qui l'écrit | un humain, en discutant | l'exécution |
+| support | **fichier versionné** (le modèle ADR) | **dépôt injecté** — `skill-library`, journal `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**.
+> Mettre les fiches en base leur ferait perdre l'historique de discussion qui fait leur valeur ;
+> mettre le journal en fichiers le rendrait ingérable au premier millier de lignes.
+
+## 4 · La surface publique (contrat 0.1.0)
+
+```js
+// — définir et valider —
+defineKind(fiche) -> Kind (gelé)          // refuse au montage, en NOMMANT ce qui manque
+validateKind(fiche) -> string[]           // la liste complète, pour corriger d'un coup
+VERDICTS = ['propose','eprouve','retenu','ecarte']
+
+// — projeter, sans inventer de format —
+toDevtest(kinds, { project, prefix }) -> plan mostajs-devtest/1
+
+// — réutiliser ou AFFINER, en traçant —
+instantiate(kind, { app, prefix, affine? }) -> Instance   // porte kind, kindVersion, affinages
+diffInstance(instance) -> string[]         // ce que cette application a changé, et pourquoi
+
+// — le corpus —
+loadCatalogue(dir) -> Kind[]               // seule I/O du module
+findKinds(kinds, { domaine?, texte?, verdict? }) -> Kind[]
+```
+
+### Les champs de la fiche
+
+| champ | requis | motif |
+|---|---|---|
+| `ref` (`KIND-…`) | ✔ | l'identité, stable entre applications |
+| `enonce` | ✔ | la question, **dans les mots du métier** |
+| `domaine` | — | vocabulaire OUVERT, tenu au §5.bis |
+| `version` | — | ce qui permet à une instance de dire **contre quoi** elle a été écrite |
+| `besoins` | — | la **forme** de données exigée — jamais la donnée |
+| `utilisation` | — | quand, et par qui |
+| `succes` | **✔** | sans critère écrit, **tout résultat paraît bon** |
+| `erreurs` | **✔** | `{titre, consequence}` — une fiche sans façon connue de se tromper n'apprend rien, et c'est la seule raison de reprendre une fiche |
+| `test` | — | `{action, attendu}` — projeté en essais |
+| `efficacite` | — | renvoi vers `skill-library`, jamais recalculé ici |
+| `evaluation` | — | idem |
+| `verdict` | — | `propose` \| `eprouve` \| `retenu` \| **`ecarte`** — une fiche écartée **reste**, avec son motif |
+| `origine` | — | d'où la fiche a été tirée : l'incident qui l'a fait naître |
+
+⚠️ **`succes` et `erreurs` sont les deux seuls champs exigés en plus de l'énoncé.** C'est délibéré :
+ce sont ceux qu'on omet, et ce sont ceux qui servent.
+
+⚠️ **Chaque erreur porte sa CONSÉQUENCE.** « Ne pas oublier le périmètre » ne se retient pas ;
+« sans lui, tout parent lit le dossier de tous les élèves » se retient. Leçon de CWE et d'OWASP.
+
+## 5 · Jalons
+
+| version | contenu | porte de sortie |
+|---|---|---|
+| **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 |
+
+### Le corpus initial de 0.1.0 — **des incidents réels, pas des suppositions**
+
+| fiche | tirée de | domaine |
+|---|---|---|
+| `KIND-PERIMETRE-01` — une permission ouvre une capacité, jamais un périmètre | ATC (3 emplois), RestoTrax | `acces` |
+| `KIND-ECRITURE-HORS-SCHEMA-01` — écrire un champ non déclaré le fait disparaître en base | ATC frais, `coaching` | `donnees` |
+| `KIND-MAJ-PARTIELLE-01` — écrire `undefined` écrase la valeur existante | `@mostajs/coaching` | `donnees` |
+| `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` |
+
+## 5.bis · Les DOMAINES du catalogue
+
+Un `domaine` regroupe les fiches d'un même métier. Le vocabulaire est **ouvert** — un domaine
+s'ajoute quand une fiche l'exige, jamais « au cas où ».
+
+### Domaines TRANSVERSES — ceux du corpus 0.1.0
+
+| domaine | ce qu'il porte | état |
+|---|---|---|
+| `acces` | capacité vs périmètre, cumul de rôles, gardes d'instance | **éprouvé** — 3 emplois |
+| `donnees` | écriture hors schéma, mise à jour partielle, divergence mémoire/base | **éprouvé** |
+| `apprentissage` | acquis, progression, avancement | **éprouvé** |
+| `decision` | refuser sur données insuffisantes, chiffrer ce qui manque · l'écriture gardée | **éprouvé** |
+| `integration` | fournisseurs externes : classes d'échec, repli, diagnostic | **éprouvé** — ajouté le 02/09/2026 depuis le CRM/TRADING |
+
+### Domaines MÉTIER — déclarés, à instruire
+
+⚠️ **Aucune fiche n'y sera écrite avant d'avoir un cas réel.** C'est la règle tirée d'ATT&CK et de
+CWE (état de l'art §3.bis d) : *un catalogue nourri d'idées grossit vite et ne sert jamais*. Les
+questions ci-dessous sont des **pistes**, en `verdict: propose`, et le seront tant qu'un incident
+ou un exploitant ne les aura pas confirmées.
+
+| domaine | catalogue métier existant | pistes de questions | familles `ro-pla` |
+|---|---|---|---|
+| **`btp`** — Bâtiment et Travaux Publics | DTU, CCTG/CCTP, Eurocodes | planning de chantier sous ressources · affectation équipes/engins · rotation des coffrages · approvisionnement et évacuation · arbitrage coût/délai/pénalités · chemin critique et marges | `scheduling`, `assignment`, `flow`, `multiobjective` |
+| **`alimentaire`** | **HACCP**, paquet hygiène, traçabilité amont/aval | formulation au moindre coût sous contraintes nutritionnelles · ordonnancement avec temps de changement de série · DLC et rotation des lots · prévision de la demande · maîtrise des pertes | `lp`, `scheduling`, `simulation`, `milp` |
+| **`elevage`** | plans de rationnement, protocoles de prophylaxie | **ration au moindre coût** sous contraintes nutritionnelles · allotement des animaux · calendrier de mises bas et de prophylaxie · appariement de reproduction · suivi de croissance | `lp`, `scheduling`, `assignment`, `simulation` |
+| **`agronomie`** | itinéraires techniques | affectation parcelle → culture · rotation pluriannuelle · calendrier de travaux sous fenêtres météo · irrigation sous débit · arbitrage rendement/eau/intrants | `assignment`, `csp`, `scheduling`, `flow`, `multiobjective` |
+| **`apiculture`** — ruches et production de miel | guides de bonnes pratiques apicoles, réglementation sanitaire, traçabilité des lots | **transhumance** : quelles ruches vers quel emplacement · calendrier des miellées sous fenêtres de floraison · dimensionnement du cheptel et des hausses · suivi sanitaire (varroa) et états de colonie · prévision de récolte · **assemblage de lots** de miel sous contraintes | `assignment`, `scheduling`, `markov`, `simulation`, `lp` |
+| **`electronique`** | *design rules*, *application notes* | placement et routage sous contraintes · ordonnancement de tests de cartes · diagnostic de panne · tolérancement et rendement de série | `scheduling`, `decision`, `markov`, `simulation` |
+
+⚠️ **Deux avertissements que ces domaines imposent, et qu'aucun domaine transverse ne posait :**
+
+- **La saisonnalité n'a pas la même échelle selon le domaine.** En restauration, deux saisons
+  complètes font deux semaines ; en grande culture, **deux ans**. La fiche
+  `KIND-DONNEE-INSUFFISANTE-01` devra porter son seuil **en nombre de cycles**, jamais en jours —
+  sinon elle mentira dans quatre domaines sur six.
+
+- **⚠️ `apiculture` est le cas EXTRÊME, et c'est pour cela qu'il est précieux.** Une miellée dure
+  quelques jours par an : la fenêtre d'observation n'est pas seulement annuelle, elle est
+  **ponctuelle**. Un apiculteur qui exploite depuis dix ans dispose de **dix points**, et aucun
+  n'est comparable à l'autre — floraison, météo, état du cheptel changent tout. Aucune prévision
+  statistique n'y tient, et **le dire est plus utile que le calculer**. Ce domaine est donc le
+  meilleur banc d'essai de `KIND-DONNEE-INSUFFISANTE-01` : s'il refuse proprement en apiculture, il
+  refusera partout. À l'inverse, une fiche qui conseillerait sur dix points **sans le signaler**
+  serait démasquée là d'abord.
+- **`electronique` et `btp` posent leurs questions LÀ OÙ LE MODULE NE TOURNE PAS** — sur
+  l'embarqué, sur le chantier. La fiche devra distinguer **où la question se pose** de **où elle se
+  calcule** : c'est un champ que le corpus transverse n'a jamais eu besoin d'avoir.
+
+> **La ration au moindre coût** (`elevage`) et **la formulation** (`alimentaire`) sont le même
+> problème que le *diet problem* de Stigler — l'un des premiers problèmes résolus par le simplexe,
+> en 1945. `ro-pla` le porte déjà (`simplex`, kind `lp`). C'est le meilleur candidat pour la
+> première fiche métier : le moteur existe, la question est ancienne, et les erreurs sont connues.
+
+---
+
+## 6 · Risques
+
+| risque | effet | parade |
+|---|---|---|
+| **Le catalogue reste vide** | on retombe sur le copier-coller entre projets | 0.1.0 part avec **5 fiches d'incidents réels** ; une fiche naît d'un défaut trouvé, jamais d'une idée |
+| **Le catalogue devient exhaustif** | plus personne ne le lit (leçon OWASP) | `verdict: ecarte` conservé **avec motif** ; `findKinds` par domaine |
+| **La fiche diverge du code** | le catalogue a raison contre les faits | la projection est **rejouée** dans le plan DEVTEST de l'application : les trois trous qatrax la surveillent comme le reste |
+| **L'affinage se dégrade en recopie** | on revient à l'état actuel | `instantiate` **exige** de nommer ce qui est affiné ; `diffInstance` le rend lisible |
+| **Deux formats de plan** | qatrax devrait apprendre | **aucun format nouveau** — projection en `mostajs-devtest/1`, validée par `qa-engine` |
+
+## 7 · Dépendances
+
+- **runtime** : aucune. Le cœur est pur.
+- **développement** : `@mostajs/mjs-unit` (§11.1.bis) ; `@mostajs/qa-engine` pour **éprouver** que
+  ce qui est projeté est accepté par le parseur officiel — dépendance d'essai, pas de production.

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

@@ -0,0 +1,80 @@
+# Plan de publication — `@mostajs/kind-catalog`
+
+**Livrable #9** (DEVRULES §9) · **Auteur** : Dr Hamid MADANI <drmdh@msn.com> · **Date** : 2026-09-02
+
+---
+
+## 1 · Coordonnées
+
+| | |
+|---|---|
+| npm | `@mostajs/kind-catalog` — **nom vérifié libre le 02/09/2026** · accès `public` |
+| GitHub | `apolocine/mosta-kind-catalog` |
+| Licence | AGPL-3.0-or-later |
+| Version | **0.1.0** — première publication |
+| Pile | `mostajs/mosta-optimization-stack/`, aux côtés de `ro-pla` |
+| Couche | **N1** — ne dépend que de `qa-engine` (N1), en développement seulement |
+
+## 2 · Ce qui part dans le paquet
+
+`src/` · `kinds/` · `docs/` · `llms.txt` · `README.md` · `CHANGELOG.md`
+
+⚠️ **`kinds/` EST le produit.** Un catalogue publié sans son corpus n'est qu'un validateur. C'est
+la raison pour laquelle `files` le porte explicitement.
+
+⚠️ **`@mostajs/qa-engine` reste une dépendance de DÉVELOPPEMENT.** Le module produit la forme du
+plan ; il n'a pas besoin du parseur pour fonctionner — seulement pour **prouver** que ce qu'il
+produit est accepté. En faire une dépendance de production imposerait le moteur QA à tout
+consommateur.
+
+## 3 · Contrôles avant publication (bloquants)
+
+| # | contrôle | commande |
+|---|---|---|
+| 1 | essais verts | `npm test` → 21/21 |
+| 2 | corpus valide | `T-CORP-1` (dans la suite) |
+| 3 | projection acceptée par le parseur officiel | `T-KC-5`, `T-CORP-3` |
+| 4 | plan DEVTEST valide, **trois trous à zéro** | `parseDevtestPlan` + correspondance |
+| 5 | `llms.txt` à jour de la surface réelle | relecture |
+| 6 | manifeste `version` = `package.json` | — |
+| 7 | **sources de l'état de l'art vérifiées** | ⚠️ **RESTE À FAIRE** — le #1 est écrit hors ligne |
+
+⚠️ **Le contrôle 7 est ouvert, et il bloque la publication de l'article #8**, pas celle du paquet :
+l'article cite Withall, EARS, CWE, Stigler, Aamodt & Plaza par titre et année, sans URL ni page.
+
+| 8 | **provenance du contenu** — corpus employés, conditions, attributions | `docs/09bis-MATRICE-SOURCING-KIND-CATALOG.md` |
+
+⚠️ **Le contrôle 8 ne bloque pas le paquet non plus** : les 12 fiches sont issues de nos incidents
+ou adossées à des faits, et **aucune ne reprend de texte**. Il bloque en revanche l'emploi de
+nouveaux corpus comme matière — voir la matrice, §6.
+
+## 4 · Séquence
+
+```
+1. npm test                                   # 21/21
+2. relire CHANGELOG et llms.txt
+3. npm publish --access public
+4. attendre la propagation du registre        # elle a pris plusieurs minutes le 01/09
+5. vérifier :  npm view @mostajs/kind-catalog version
+6. git tag v0.1.0 && git push --tags
+7. pousser le plan DEVTEST vers qatrax
+```
+
+⚠️ **La propagation npm n'est pas immédiate.** Le 01/09/2026, une publication a rendu
+`+ @mostajs/coaching@0.2.0` puis est restée invisible plusieurs minutes, avec un `409 Cannot
+publish over previously staged version` à la reprise. **Attendre, ne pas republier.**
+
+## 5 · Après la publication
+
+| quand | quoi |
+|---|---|
+| aussitôt | instancier `KIND-PERIMETRE-01` dans **ATC** — la fiche est née là, elle doit y retourner |
+| aussitôt | instancier `KIND-DONNEE-INSUFFISANTE-01` dans **RestoTrax** |
+| ces deux instances | donnent le premier chiffre d'**emplois par fiche**, le KPI du #5 |
+| ensuite | premier `terrain` agricole → faire passer `KIND-ROTATION-CULTURALE-01` de `propose` à `eprouve` |
+
+## 6 · Versions suivantes (rappel du #3)
+
+- **0.2.0** — index inverse des emplois exposé, premières fiches issues du terrain métier.
+- **0.3.0** — pont `assistant-pilote` : une fiche déclare son `kind` `ro-pla` et devient une
+  question activable sous condition de données.

package/docs/PLAN-SUIVI-MONITORING.md

@@ -0,0 +1,66 @@
+# Plan de suivi — `@mostajs/kind-catalog`
+
+**Livrable #5** (DEVRULES §9) · **Auteur** : Dr Hamid MADANI <drmdh@msn.com> · **Date** : 2026-09-02
+
+---
+
+## 1 · Ce qu'on mesure, et pourquoi ce n'est PAS le volume
+
+Un catalogue se vante naturellement de sa taille. **Le volume ne prouve rien** : CWE compte plus de
+mille entrées et ce que les équipes lisent, c'est l'OWASP Top 10.
+
+Les indicateurs ci-dessous sont choisis pour être **réfutables** : chacun peut se dégrader, et sa
+dégradation dit quelque chose de vrai.
+
+## 2 · Les indicateurs produit
+
+| KPI | définition | seuil d'alerte | ce que sa dégradation signifie |
+|---|---|---|---|
+| **Taux éprouvé** | fiches `eprouve`+`retenu` / total | **< 30 %** ou **> 90 %** | trop bas : le catalogue est une bibliothèque d'intentions. Trop haut : on se décerne l'expérience, ou l'on a cessé d'explorer |
+| **Erreurs par fiche** | `erreursCataloguees` / total | **< 2** | les fiches deviennent des titres — c'est le champ qui porte la valeur, et le premier à s'atrophier |
+| **Emplois par fiche** | instances / fiches | **< 1,5** après 3 applications | les fiches ne sont pas reprises : soit illisibles, soit trop spécifiques |
+| **Taux d'affinage** | instances portant ≥ 1 affinage / instances | **> 70 %** | la fiche canonique ne décrit plus la réalité : elle doit être révisée, pas contournée |
+| **Fiches jamais employées** | fiches à zéro instance après 2 applications | **> 40 %** | on écrit pour écrire |
+| **Défauts attrapés** | essais projetés qui ont ÉCHOUÉ au moins une fois | — | **le seul indicateur de valeur** : une fiche qui n'a jamais rien attrapé n'a jamais servi |
+| **Domaines peuplés** | domaines avec ≥ 1 fiche / domaines déclarés | **< 80 %** | un domaine déclaré et vide est une promesse non tenue |
+
+⚠️ **Le KPI qui compte est « défauts attrapés ».** Les autres décrivent l'hygiène du catalogue ;
+celui-là dit s'il sert. Il ne se lit pas dans le module — il se lit dans **qatrax**, sur les essais
+issus de la projection.
+
+## 3 · Où chaque chiffre se lit
+
+| chiffre | source | commande |
+|---|---|---|
+| taux éprouvé, erreurs, domaines, provenances | `statsCatalogue()` | `node -e "…"` ou l'outil de rapport |
+| emplois, taux d'affinage | `emplois(instances)` | l'application déclare ses instances |
+| défauts attrapés | **qatrax** — exécutions des essais projetés | `qatrax.amia.fr/runs` |
+| cohérence du corpus | `auditCatalogue()` | joué à chaque exécution des essais (`T-CORP-1`) |
+
+## 4 · Observabilité — ce que le module N'A PAS
+
+**Aucun runtime, donc aucune alerte runtime.** Le module n'écoute aucun port, n'ouvre aucune
+connexion, ne journalise rien. Il n'y a ni latence, ni taux d'erreur, ni saturation à surveiller.
+
+Ce qui se surveille, ce sont **deux portes**, et elles sont déjà dans l'intégration continue :
+
+1. `auditCatalogue()` non vide → **le corpus est cassé**, la projection de toutes les fiches l'est
+   aussi. Bloquant.
+2. la projection refusée par `parseDevtestPlan` → **un plan invalide partirait chez qatrax**.
+   Bloquant.
+
+## 5 · La revue périodique — trimestrielle
+
+Une fiche vieillit sans que rien ne le signale : c'est le risque propre à un corpus éditorial, et
+aucun indicateur automatique ne le voit. La revue est donc **humaine**, et courte :
+
+| on regarde | on décide |
+|---|---|
+| les fiches à **taux d'affinage élevé** | réviser la fiche canonique — le terrain a parlé |
+| les fiches **jamais employées** après deux applications | `ecarte`, **avec motif** — jamais supprimer |
+| les fiches `propose` **anciennes** | trouver un `terrain` ou un `incident`, ou assumer qu'elles restent proposées |
+| les **domaines déclarés et vides** | peupler ou retirer la déclaration |
+| les **erreurs nouvellement rencontrées** en production | les ajouter à la fiche existante plutôt que d'en créer une |
+
+⚠️ **Rien ne se supprime.** Une fiche écartée reste, avec son motif : celle qui disparaît sera
+réinventée, avec les mêmes espoirs et le même échec.

package/docs/PLAN-TESTS.md

@@ -0,0 +1,79 @@
+# Plan de test — `@mostajs/kind-catalog`
+
+**Livrable #4** (DEVRULES §9) · **Auteur** : Dr Hamid MADANI <drmdh@msn.com> · **Date** : 2026-09-02
+**Cadre** : `@mostajs/mjs-unit` (§11.1.bis) · **Plan qatrax** : `docs/DEVTEST-PLAN.kind-catalog.json`
+
+---
+
+## 1 · Ce que ces essais doivent tenir — et ce qu'ils ne peuvent pas
+
+Un catalogue de fiches n'a **aucun comportement à l'exécution**. Les essais ne peuvent donc pas
+prouver qu'une fiche est *juste* — cela se prouve en l'appliquant, dans l'application, et c'est le
+plan DEVTEST de cette application qui le fait.
+
+**Ce que ces essais tiennent, c'est ce qui rendrait le catalogue NUISIBLE :**
+
+| risque | pourquoi il est pire que l'absence de catalogue |
+|---|---|
+| une fiche **sans critère de succès** entre au corpus | elle donne un cadre à des réponses qu'on ne peut pas juger — **tout résultat paraît bon**, avec l'autorité d'une fiche |
+| une fiche **sans erreur connue** entre au corpus | on la reprend en croyant hériter d'une expérience, et l'on hérite d'un titre |
+| une erreur **sans conséquence** | « ne pas oublier X » ne se retient pas ; le lecteur passe |
+| la **projection produit un plan invalide** | le plan part chez qatrax, y est refusé ou — pire — accepté et faux |
+| l'**affinage n'est pas tracé** | « réutiliser » se dégrade en « recopier », et l'on revient à l'état d'avant le module |
+| deux fiches portent la **même `ref`** | mille projets citent la même chose : l'identité doit être unique, comme `CWE-79` |
+
+## 2 · La matrice de couverture
+
+| exigence | ce qu'elle garantit | essais |
+|---|---|---|
+| **SPEC-KC-01** — une fiche inutilisable est refusée AU MONTAGE, en nommant tout ce qui manque | on ne découvre pas le manque à la projection, quand le plan part | T-KC-1 · T-KC-2 · T-KC-3 |
+| **SPEC-KC-02** — chaque erreur porte sa CONSÉQUENCE | un avertissement sans conséquence ne se retient pas (leçon CWE/OWASP) | T-KC-4 |
+| **SPEC-KC-03** — la projection produit un plan `mostajs-devtest/1` que le parseur OFFICIEL accepte | qatrax lit sans rien apprendre ; aucun second format | T-KC-5 · T-KC-6 · T-KC-7 |
+| **SPEC-KC-04** — instancier EXIGE de nommer ce qui est affiné, et le trace | l'écart tracé est ce qui fait vivre un catalogue | T-KC-8 · T-KC-9 |
+| **SPEC-KC-05** — le corpus est cohérent : `ref` uniques, verdicts connus, domaines déclarés | l'identité et la lisibilité du corpus | T-KC-10 · T-KC-11 |
+| **SPEC-KC-06** — le module N'EXÉCUTE RIEN et NE STOCKE RIEN | c'est le produit, pas une prudence de première version | T-KC-12 |
+
+## 3 · Les cas de test
+
+| réf | intitulé | action | attendu |
+|---|---|---|---|
+| **T-KC-1** | une fiche sans `succes` est refusée | définir sans critère de succès | refus nommant `succes` — *sans critère écrit, tout résultat paraît bon* |
+| **T-KC-2** | une fiche sans `erreurs` est refusée | définir sans erreur connue | refus nommant `erreurs` — *une fiche qui n'apprend rien n'a pas de raison d'être reprise* |
+| **T-KC-3** | le refus liste TOUT ce qui manque, d'un coup | définir une fiche vide | tous les manques dans un seul message — corriger un manque pour en découvrir un autre fait abandonner |
+| **T-KC-4** | une erreur sans `consequence` est refusée | erreur réduite à un titre | refus nommant l'index et le champ |
+| **T-KC-5** | la projection est acceptée par `parseDevtestPlan` | projeter le corpus, le passer au **parseur officiel** de `@mostajs/qa-engine` | `ok: true`, zéro erreur — *c'est le seul juge qui compte : celui de qatrax* |
+| **T-KC-6** | chaque `test` de la fiche devient un essai relié à son exigence | projeter une fiche à deux épreuves | deux `tests`, `specRef` pointant l'exigence, `steps` portant action et attendu |
+| **T-KC-7** | le préfixe d'application isole les références | projeter pour `ATC` puis pour `RESTO` | aucune collision de `ref` entre les deux plans |
+| **T-KC-8** | instancier SANS rien affiner est permis, et se voit | instancier tel quel | instance avec `affinages: []` — la réutilisation à l'identique est le cas normal |
+| **T-KC-9** | un affinage NON DÉCLARÉ est refusé | instancier en changeant un champ hors `affine` | refus — *sinon « réutiliser » se dégrade en « recopier »* |
+| **T-KC-10** | deux fiches ne peuvent pas partager une `ref` | charger un corpus avec doublon | refus nommant la `ref` et les deux fichiers |
+| **T-KC-11** | un `verdict` inconnu est refusé ; `ecarte` est CONSERVÉ | verdict fantaisiste, puis `ecarte` | refus du premier ; le second reste au corpus **avec son motif** — une fiche écartée qui disparaît sera réinventée |
+| **T-KC-12** | le module n'écrit RIEN et n'appelle AUCUN solveur | exercer toute la surface avec un dépôt et un solveur **piégés** | zéro touche — *une garantie tenue par la seule intention se perd à la version suivante* |
+
+## 4 · Les essais du CORPUS lui-même
+
+Le corpus n'est pas du code, mais il se contrôle — et ces contrôles valent pour toute fiche
+ajoutée plus tard, y compris dans les domaines métier.
+
+| réf | contrôle | motif |
+|---|---|---|
+| **T-CORP-1** | chaque fiche du corpus passe `validateKind` sans reproche | une fiche livrée cassée casse la projection de toutes |
+| **T-CORP-2** | chaque fiche `eprouve` ou `retenu` porte au moins une `origine` | *l'alimentation se fait par incidents, jamais par idées* (état de l'art §3.bis d) — une fiche éprouvée sans origine est une idée déguisée |
+| **T-CORP-3** | le corpus entier se projette en un plan valide | le corpus est livrable en bloc |
+| **T-CORP-4** | tout `domaine` employé figure au §5.bis du plan de développement | un domaine surgi sans déclaration échappe à la revue |
+
+## 5 · Ce qui n'est PAS testé ici, et où cela l'est
+
+| non testé ici | où |
+|---|---|
+| qu'une fiche décrive une exigence **juste** | dans l'application qui l'instancie — son plan DEVTEST |
+| qu'un moteur réponde bien à la question | `@mostajs/ro-pla` (59 essais) |
+| que l'efficacité mesurée soit correcte | `@mostajs/skill-library` |
+| qu'une question soit activable au bon moment | `@mostajs/assistant-pilote` (13 essais) |
+
+## 6 · Portes de sortie (§11.1)
+
+- essais **verts**, exécutés par `test-scripts/run-tests.sh` via `@mostajs/mjs-unit` ;
+- plan `docs/DEVTEST-PLAN.kind-catalog.json` **valide** au sens de `parseDevtestPlan` ;
+- les **trois trous qatrax à zéro** : `unmatched`, `notRun`, `withoutAutoRef` ;
+- chaque nom d'essai porte sa **référence en tête**.

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

@@ -0,0 +1,46 @@
+# Mots-clés & sites — `@mostajs/kind-catalog`
+
+**Livrable #8** (part 1/2) · **Auteur** : Dr Hamid MADANI <drmdh@msn.com> · **Date** : 2026-09-02
+
+> ⚠️ **Aucun volume de recherche n'est chiffré ici.** Ce document est écrit hors ligne : avancer un
+> nombre de requêtes mensuelles serait exactement le « chiffre plausible tiré de rien » que ce
+> module combat. Les intentions ci-dessous sont raisonnées, à confirmer par un outil avant campagne.
+
+## 1 · Intentions de recherche visées
+
+| intention | expression probable | notre réponse |
+|---|---|---|
+| **réutiliser des exigences** | *reusable requirement patterns*, *catalogue d'exigences réutilisables* | la fiche `kind` et sa projection |
+| **ne pas refaire les mêmes erreurs** | *known failure modes software*, *catalogue de modes de défaillance* | le champ `erreurs`, avec conséquence |
+| **relier exigences et tests** | *requirements to test traceability*, *traçabilité exigence essai* | projection en `mostajs-devtest/1`, lue par qatrax |
+| **aide à la décision métier** | *optimisation agricole*, *aide à la décision élevage*, *ordonnancement chantier* | les fiches métier + `ro-pla` |
+| **savoir quand ne PAS conclure** | *insufficient data forecasting*, *combien de données pour prévoir* | `KIND-DONNEE-INSUFFISANTE-01` |
+
+## 2 · Mots-clés
+
+**Cœur** : catalogue d'exigences · fiche d'exigence réutilisable · modes de défaillance connus ·
+traçabilité exigence → test · plan Dev+Test · réutilisation d'exigences entre projets.
+
+**Métier** : optimisation agricole · rotation culturale · ration au moindre coût · formulation
+alimentaire · ordonnancement de chantier · traçabilité de lot HACCP · transhumance apicole ·
+diagnostic séquentiel de panne.
+
+**Longue traîne — c'est là que se trouve le lecteur qualifié** :
+« combien de saisons avant de prévoir un rendement » · « pourquoi ma prévision est fausse avec peu
+de données » · « comment réutiliser les exigences d'un projet à l'autre » · « catalogue d'erreurs
+de conception logicielle » · « un rôle ne doit pas ouvrir tout le périmètre ».
+
+## 3 · Où publier
+
+| support | angle |
+|---|---|
+| site MostaJS — page module | technique, avec la projection en exemple |
+| dev.to / Medium | « Ce que CWE nous apprend sur les exigences » |
+| LinkedIn | l'angle métier : refuser de conclure est un argument de vente |
+| npm README | la surface, en dix lignes |
+| revues professionnelles agricoles | `KIND-ROTATION-CULTURALE-01` et `KIND-FORMULATION-MOINDRE-COUT-01` |
+
+## 4 · Ce qu'on ne fera PAS
+
+Aucune promesse de « intelligence artificielle » : le module ne calcule rien, et un mot-clé qui
+attire un lecteur déçu coûte plus qu'il ne rapporte.