v0.2.17

chapters/051-invariants-de-conception.md

@@ -13,8 +13,8 @@ Les futures décisions doivent respecter les invariants suivants :
 9. **Les types Core compiler-known restent peu nombreux.**
 10. **Le package, le namespace, le target, la feature, la capability et l'artifact restent des dimensions distinctes.**
 11. **Une collision de namespace entre packages ne doit jamais fusionner implicitement leurs types.**
-12. **Les erreurs récupérables utilisent `Result`; les opérations réellement infaillibles retournent directement leur valeur.**
-13. **`throws` n'existe que sur une callable retournant `Result`.**
+12. **`ResultError`, `Exception` et `Fault` sont trois mécanismes distincts : valeur d'échec explicite, propagation checked et échec unchecked capturable.**
+13. **`throws` ne contient que des `Exception` et reste indépendant du type de retour ; `faults` ne contient que des `Fault` et reste optionnel/non exhaustif.**
 14. **L'identité d'objet est distincte de l'égalité de valeur.**
 15. **Les opérateurs utilisateur passent uniquement par les contrats Core `Op...`.**
 16. **Les interfaces fournissent l'héritage multiple de contrats/comportements sans introduire un second système de traits.**
@@ -34,5 +34,6 @@ Les futures décisions doivent respecter les invariants suivants :
 29. **Un array safe devient observable uniquement après initialisation complète.**
 30. **Une bibliothèque spécialisée peut être officielle sans appartenir au Core ou au SDK obligatoire ; son artifact normal reste une `.saselib`.**
 31. **Les dépendances natives de bootstrap peuvent être remplacées progressivement par des implémentations Saselang sans imposer leur architecture historique au langage.**
+32. **Lorsqu'une forme légèrement plus longue supprime un implicite ou une ambiguïté réelle, Saselang privilégie l'explicite.**
 
 ---