v0.1.0-pre.062

idls/001.README.md

@@ -1,62 +1,39 @@
 <!-- file: idls/001.README.md -->
 <!-- version: 2 -->
 
-# IDL locales
+# Répertoire IDL v3
 
-Ce répertoire contient les IDL téléchargées depuis des sources officielles ou de référence et utilisées pour auditer les décodeurs, matérialiseurs et exécuteurs.
+Ce répertoire contient 91 fichiers IDL JSON issus exclusivement de `idls_v2.zip`.
+Le contenu brut des JSON n'a pas été modifié ; seuls les noms de fichiers ont été normalisés.
 
-## Règle d’admission
-
-Une IDL devient une source locale active lorsqu’un décodeur ou un exécuteur correspondant est développé. À ce moment-là, il faut :
-
-1. télécharger l’IDL utilisée ;
-2. vérifier son Program ID et sa provenance ;
-3. conserver son contenu JSON inchangé ;
-4. la renommer selon la convention canonique ;
-5. documenter sa version ou son commit lorsqu’ils sont connus ;
-6. ajouter des tests comparant, selon le périmètre disponible, l’IDL, le runtime, les builders et l’interface officielle.
-
-Les fichiers JSON ne doivent pas recevoir de commentaires ni être reformattés uniquement pour satisfaire la documentation.
-
-## Convention de nommage
-
-Forme principale :
+## Convention
 
 ```text
-<PROGRAM_ID>.<protocol_type>.<protocol_code>.json
+<famille-kb-lib>.<program-id>.<chemin-module>[.<génération-ou-sous-système>].V<version-idl>.from_<source>.json
 ```
 
-Exemple actif :
+- `famille-kb-lib` correspond au premier niveau fonctionnel de `kb-lib` : `solana`, `spl`,
+  `metadata`, `launchpad`, `fees`, `strategy`, etc.
+- `program-id` est l'identifiant canonique du programme.
+- `chemin-module` correspond au module fonctionnel cible sans les rôles `decoder` ou `executor`.
+- `v1`, `v3`, `v4` désignent une génération de programme ou de surface.
+- `V3_0_1` désigne la version déclarée par l'IDL.
+- `from_solscan` et `from_github_solana_program` indiquent la provenance.
 
-```text
-metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s.metadata.metaplex_token_metadata.json
-```
+## Documents
 
-Lorsqu’il faut conserver plusieurs versions réellement distinctes d’une même IDL :
+- `../docs/IDL_AUDIT.md` : inventaire, validation JSON, versions et empreintes.
+- `../docs/MISSING_PROGRAM_IDLS.md` : programmes connus sans IDL présente ou sans IDL officielle identifiée.
+- `../docs/IDL_TO_KB_LIB_NOMENCLATURE.md` : correspondance entre chaque IDL et le module `kb-lib`.
 
-```text
-<PROGRAM_ID>.<protocol_type>.<protocol_code>.<version>.json
-```
+## Décisions architecturales intégrées
 
-Suffixes admis, par ordre de préférence :
+- `admin/pump_fees` devient `fees/pump_fees`.
+- `admin/jupiter_lock` devient `vesting/jupiter_lock`.
+- `amm/metadao_futarchy_amm` devient `governance/metadao_futarchy`.
+- `amm/virtuals` devient `launchpad/virtuals`.
+- `router/jupiter_dca` devient `strategy/jupiter_dca`.
+- une famille `storage` est proposée pour `storage/solana_record`.
 
-```text
-v<semver>
-commit-<short_hash>
-slot-<deployment_slot>
-date-YYYY-MM-DD
-```
-
-La version ne doit jamais être inventée. Tant qu’une seule IDL est conservée pour un programme, le suffixe de version reste facultatif.
-
-## Classification
-
-- `protocol_type` représente la famille fonctionnelle stable, par exemple `metadata`, `launchpad`, `amm`, `clmm`, `lending`, `router`, `vault` ou `orderbook`.
-- `protocol_code` représente le protocole ou la surface exacte, par exemple `metaplex_token_metadata`.
-- La classification est validée lors de l’implémentation du décodeur ou de l’exécuteur ; les IDL de référence non encore utilisées ne doivent pas être renommées massivement sur une classification incertaine.
-
-## Intégrité
-
-Le renommage du fichier est autorisé. Le contenu de l’IDL doit rester identique à la source téléchargée.
-
-Les graphies externes telles que `token2022`, les noms de types Anchor et les identifiants publiés dans l’IDL ne doivent pas être adaptés à la nomenclature interne du workspace.
+Ces changements de modules ne sont pas appliqués au code Rust dans cette archive ; ils servent de cible
+pour la prochaine refactorisation de `kb-lib`.