v0.1.0-pre.062

RULES_SPECIFIC_KHADHROONY.md

@@ -235,3 +235,11 @@ Les `program_id` connus doivent être définis une seule fois dans `kb-program-i
 - `kb-store` ne dépend pas de `kb-config`. La frontière applicative transforme une configuration résolue en options de store explicitement validées.
 - Les adaptateurs concrets implémentent les mêmes traits neutres et ne font pas fuiter leurs types de connexion dans les contrats.
 - Seul `kb-app-demo-desktop` est conservé comme binaire pendant la migration initiale.
+
+## Nomenclature des identités et opérations persistées
+
+- Les identités runtime, `processor_name`, `protocol_code`, `surface_code`, `operation_code` et `event_code` sont des contrats persistés et utilisent des segments hiérarchiques séparés par `.`.
+- Chaque segment utilise `snake_case`; un underscore ne remplace jamais un niveau hiérarchique. Exemples : `solana.core.system.transfer`, `spl.memo.v4.add_memo`, `spl.token_2022.transfer_checked`.
+- Les anciennes formes préfixées par `solana_core`, `solana_native`, `spl_memo`, `spl_token`, `spl_token_2022`, `spl_associated_token_account` ou `metadata_metaplex_token_metadata` sont interdites pour ces valeurs contractuelles.
+- Toute nouvelle surface ou opération doit respecter `docs/OPERATION_NAMING_CONVENTION.md` et être ajoutée à `test-fixtures/contract-matrices/OPERATION_NAMING_MATRIX.json` avant son premier remplissage persistant.
+- Un renommage de ces valeurs après remplissage d’une base est une migration de données et exige une migration SQL ou une reconstruction explicite des tables dérivées.