v0.4.7-pre.003

docs/rules/RULES_SPECIFIC_KHADHROONY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_SPECIFIC_KHADHROONY.md -->
-<!-- version: 7 -->
+<!-- version: 8 -->
 
 # Règles spécifiques à `khadhroony-bot3`
 
@@ -56,11 +56,15 @@ Toute divergence avec une règle générale doit être explicitement documentée
 
 ### Couverture des exécuteurs
 
-- Pour chaque programme Solana, les exécuteurs doivent couvrir maximalement toutes les opérations officiellement constructibles ou appelables qui ne sont ni obsolètes ni remplacées par une variante canonique imposée.
+- Pour chaque programme Solana, les exécuteurs doivent couvrir maximalement toutes les opérations officiellement constructibles ou appelables, y compris les opérations obsolètes qui restent techniquement constructibles.
 - Cette obligation couvre les opérations courantes, récentes, expérimentales, en développement et publiées avant leur déploiement généralisé dès lors que leur wire, leurs comptes, leurs signers et leurs garde-fous exacts sont prouvés.
-- Une opération ne peut pas être exclue parce qu'elle n'a pas été arbitrairement retenue pour une version. Chaque opération officiellement connue doit recevoir un statut déterministe : `Supported`, `Unsupported(reason)`, `DecodeOnlyHistorical`, `DecodeOnlyObsolete`, `DecodeOnlyReplaced` ou frontière de programme explicitement documentée.
+- Lorsqu'une chaîne de versions a été remplacée, seule la dernière version canonique de remplacement reçoit un builder public courant. Toutes les versions intermédiaires remplacées restent décodables et matérialisables, déclarent leur remplacement canonique final et ne reçoivent pas de builder public distinct.
+- Une opération obsolète sans remplacement canonique final doit rester exécutable lorsqu'elle est encore officiellement constructible. Son API Rust publique doit être marquée avec `#[deprecated]`, sa matrice doit la déclarer `ExecutableDeprecated` et la surface runtime doit l’identifier explicitement comme dépréciée, et son exécution doit exiger une approbation opérateur explicite en plus des confirmations destructives ou sensibles éventuellement requises.
+- Une opération obsolète devenue techniquement impossible à construire peut rester decode-only, mais cette exception doit indiquer l'impossibilité contractuelle exacte et les sources qui la prouvent.
+- Une opération ne peut pas être exclue parce qu'elle n'a pas été arbitrairement retenue pour une version. Chaque opération officiellement connue doit recevoir un statut déterministe : `Supported`, `ExecutableDeprecated`, `Unsupported(reason)`, `DecodeOnlyHistorical`, `DecodeOnlyReplaced` ou frontière de programme explicitement documentée.
 - `Unsupported(reason)` est réservé à une impossibilité technique ou contractuelle précise et vérifiable. Il ne doit jamais masquer un travail non réalisé, un choix de priorité ou une absence d'inventaire.
-- Les opérations historiques, dépréciées, obsolètes ou remplacées restent décodables et matérialisables lorsqu'elles prouvent des faits, mais ne doivent pas être exposées à l'exécution lorsque la variante n'est plus légitime à construire.
+- Le marquage Rust `#[deprecated]` avertit le développeur à la compilation ; l'approbation opérateur protège l'exécution au runtime. L'un ne remplace jamais l'autre.
+- Les opérations historiques ou remplacées restent décodables et matérialisables lorsqu'elles prouvent des faits. Elles ne sont pas exposées à l'exécution lorsqu'un remplacement canonique final existe, sauf surface de compatibilité historique explicitement isolée, justifiée et elle-même dépréciée.
 - Le déploiement sur un cluster, la disponibilité d'une fixture, la simulation réseau et l'autorisation d'envoi sont des niveaux de preuve distincts ; leur absence ne supprime pas un builder universel officiellement constructible.
 - Toute exclusion d'exécution doit être explicite dans la matrice contractuelle, les capacités runtime et la documentation publique de la surface.