v0.2.14

2026-09-12 18:12:13 +02:00
parent 18306bdc8c
commit 57ae671f88
27 changed files with 2060 additions and 623 deletions
--- a/000-README.md
+++ b/000-README.md
@@ -1,4 +1,4 @@
-# Bible Saselang 0.2.12
+# Bible Saselang 0.2.14
 > **Statut : pré-spécification normative de Saselang V1.**
 >
@@ -7,7 +7,7 @@
 >
 > La V2 visera principalement la réécriture/self-hosting de la toolchain V1 en Saselang lui-même. Les extensions majeures de cibles et d'écosystème sont prévues à partir de V3+.
 >
-> **Révision 0.2.12 :** première distribution multifichier ; fixation de la distinction `is` / `instanceof`, formalisation initiale des casts/downcasts et de la surface de conversion numérique Core, introduction de l'annexe exhaustive des conversions et du modèle de livraison `full` + deltas SemVer.
+> **Révision 0.2.14 :** fermeture du socle générique V1 (contraintes, invariance, const generics, récursivité), formalisation de la complétude/layout des types et des imports explicites non séquentiels, stabilisation supplémentaire des conversions numériques (`NaN`, `NumericConversionError`, réduction anti-doublon) et hiérarchie initiale des capabilities par propriétaire.
 ## Organisation de cette distribution
--- a/001-SUMMARY.md
+++ b/001-SUMMARY.md
@@ -1,4 +1,4 @@
-# Sommaire — Bible Saselang 0.2.12
+# Sommaire — Bible Saselang 0.2.14
 ## Chapitres
--- a/003-CHANGELOG.md
+++ b/003-CHANGELOG.md
@@ -1,4 +1,33 @@
-# Changelog documentaire — 0.2.12
+# Changelog documentaire — 0.2.14
 ## 0.2.14
 - fermeture du socle generics V1 : syntaxe, inférence d'appel, contraintes nominales, invariance, absence de CTAD/wildcards/spécialisation ;
 - `Numeric` retenu comme vraie abstraction Core utilisable dans les contraintes génériques ;
 - const generics V1 limités aux types de paramètres `bool`, `char`, `uint8..uint256` et enums simples sans payload ;
 - arguments const generic volontairement boring : aucune callable directement dans `<...>` ; calcul complexe matérialisé d'abord dans une `const` ;
 - inférence const generic structurelle uniquement, sans solveur algébrique ;
 - récursivité générique régulière autorisée ; auto-référence transformante et polymorphic recursion interdites V1 ;
 - toute récursivité by-value interdite, y compris via une instanciation de taille théoriquement nulle ;
 - cycles d'héritage interdits, diamants non cycliques autorisés ;
 - classes récursives autorisées via leurs références d'objet ;
 - distinction nominalement connu / sémantiquement complet / layout-complet et suppression du besoin de forward declarations utilisateur ;
 - imports explicites requis même entre deux types du même namespace ; les imports sont déclaratifs, non exécutables, et leurs cycles sont autorisés ;
 - `NaN`, infinities et zéros signés stabilisés pour `float -> float` ;
 - `NumericConversionError` stabilisé conceptuellement autour de `NotFinite`, `NotIntegral`, `OutOfRange`, `Inexact` ;
 - matrice `float -> integer` réduite par paire selon la règle anti-doublon ;
 - conversions fondamentales Core obligatoires pour toute paire de types supportés, avec émulation logicielle lorsque raisonnable ;
 - nomenclature de capabilities organisée par propriétaires `language.*`, `core.*`, `target.*`, `platform.*`, `sdk.*` ;
 - V1/V2 explicitement positionnées comme bases/POC, V3 comme première baseline publique de stabilité.
 ## 0.2.13
 - règle générale de composition Core figée : aucune méthode combinée lorsqu'une chaîne d'opérations existantes exprime exactement la même sémantique ;
 - suppression conceptuelle des alias `tryFloorTo...`, `tryCeilTo...`, `tryRoundTo...` et `tryTruncateTo...` ;
 - `float -> integer` réduit aux familles `tryTo...`, `trySaturateTo...` et `tryWrapTo...`, composables avec `floor()`, `ceil()`, `round()` et `truncate()` ;
 - maintien des méthodes combinées uniquement lorsqu'une composition changerait le contrat ou perdrait l'information nécessaire ;
 - `saturatingRoundToFloatXX()` reste justifié pour les conversions flottantes où arrondi et saturation ne peuvent pas être séparés sans changer la sémantique.
 ## 0.2.12
--- a/MANIFEST.toml
+++ b/MANIFEST.toml
@@ -1,461 +1,109 @@
 format = 1
-version = "0.2.12"
+version = "0.2.14"
-distribution = "full"
+distribution = "delta"
-base_version = ""
+base_version = "0.2.13"
 documentation_layout = "multifile"
-[[files]]
+[[modified]]
 path = "000-README.md"
-sha256 = "54178a0e9d920766859335ae851b5424fe0721344089e926e3df1904e80bb2d5"
+sha256 = "4ca46426ce93e412b82ce1473202763a9b75dca7a9a76e85f6c7f3afa27245b0"
-[[files]]
+[[modified]]
 path = "001-SUMMARY.md"
-sha256 = "231083968ba2895084386113e1337cd5c63315413eb91151327ba588b8c881b9"
+sha256 = "a15df88415cfc941907ee03d2d851dbeb12a18ad3c2933fede66e263fd4c95af"
-[[files]]
+[[modified]]
 path = "002-DOCUMENTATION-MODEL.md"
 sha256 = "f939efa7d1379ed263a14a125ca8343ff4f182cda956955b5903f2da99df0a18"
 [[files]]
 path = "003-CHANGELOG.md"
-sha256 = "4048bddd42f8d8102735716e8c1378fc254d2cdc08368e69da683b3ebc205cf3"
+sha256 = "e7c56000d0f64d9109e398d19bac6219a0435db0f52fb0548e354364d5eebb8a"
-[[files]]
+[[modified]]
 path = "annexes/A-numeric-conversions.md"
-sha256 = "b2e8d0d1f7fd2773ad4ba5308e41a0c51f48b23b77983759ef8b44b5c6aa70ba"
+sha256 = "7e67ab02a99b7ebbb0d5ac0a16bdc89f70fdfdad0620a3927e3f07a13c722743"
-[[files]]
+[[modified]]
 path = "chapters/000-statuts-normatifs.md"
 sha256 = "adad2d9969de674e74b27456088c8ab8287706add7b9b9f4ef25acdb47f98abc"
 [[files]]
 path = "chapters/001-trajectoire-dimplementation.md"
-sha256 = "aec24baf0839bcc421b6d3bb1f4362e967655520250e93b63eee9a0b1c6c1ee4"
+sha256 = "9f0205305e77f3474091795e897743c4e2012fc94a04a954509a7a6c3f3f43ed"
-[[files]]
+[[modified]]
 path = "chapters/002-principes-generaux-du-langage.md"
 sha256 = "375357d732445b3c781121628cc9cabfa01ed1f27bc673143eedc3adbb0db0a1"
 [[files]]
 path = "chapters/003-architecture-de-compilation.md"
 sha256 = "aa8289a8f12124215d050f655a63952d11d158e814cf0e92f7ada7f875c18ed1"
 [[files]]
 path = "chapters/004-couches-de-lecosysteme-v1.md"
 sha256 = "fbdcfb41f140dc94ed068bbfec7f4740b0c9723128e59959127b38275578e286"
 [[files]]
 path = "chapters/005-types-primitifs.md"
-sha256 = "9b313a1adce6f6a12fe2015613603f1e33727e043d56c429afdbf8c60854a792"
+sha256 = "c723a1fde76ee90badae1d08deab9e7b8e59da6622979c3f89f3da495efe8157"
-[[files]]
+[[modified]]
 path = "chapters/006-types-variables-constantes-et-scopes.md"
 sha256 = "a3f4ea068f5273d64842bc8cbf25cecc36aaa73d166cedd74f85af52fa345d67"
 [[files]]
 path = "chapters/007-types-nominaux-et-fichiers-saseltype.md"
-sha256 = "200e87df7e530f58a7bc8d193a857891a56c3594fa7750bf3ae430e2f1af9c7b"
+sha256 = "1b853fb1160d397565988e3a8dbb9b52b8c5cfbca0c2428948221955728f715c"
-[[files]]
+[[modified]]
 path = "chapters/008-classes-et-object.md"
 sha256 = "442c0b0beeb41d9329400b90edb5c8c510b815f319059b8802120c9532e2fe82"
 [[files]]
 path = "chapters/009-structs.md"
 sha256 = "d23b0b4055de2ed32eaef76f534f245a51b7f9fb1030bf73ac2231f3ef858ab3"
 [[files]]
 path = "chapters/010-enums-algebriques.md"
 sha256 = "5743f854fba3a0cd7a539ed97686978ff05e0d84bef0cf446307d3583e0c0fe1"
 [[files]]
 path = "chapters/011-tuples.md"
 sha256 = "19692031e4ac96b4d15dde240033b92cd4051acce58de17e4969b6a5ac2a06fd"
 [[files]]
 path = "chapters/012-unions.md"
 sha256 = "2ba425792989386546f8176cf5937d9256ecbcb5950ec0841989b2888afdeeb6"
 [[files]]
 path = "chapters/013-interfaces.md"
 sha256 = "3787c491751256940deddff1e507988ad028b6cb5aa4f3d48e2c88f75dee9517"
 [[files]]
 path = "chapters/014-generics.md"
-sha256 = "10507bacab272ec59b3f43f018942e7055b9135335e3748698afc3d4a1cf7331"
+sha256 = "c827e50f5efd51480e0fc250a3e92d75f40eaadc5d47b42078ae16b4c6c5f14a"
-[[files]]
+[[modified]]
 path = "chapters/015-fonctions-methodes-et-clsmethod.md"
 sha256 = "930b4ce52bf59c372bc2c068d13f2c3b55b4b1409a93438a00aff0fed9e6b3b1"
 [[files]]
 path = "chapters/016-dispatch-override-et-modificateurs.md"
 sha256 = "c3072282a152c471e726d485a228e19dc1f34cebb2092fc83354d8ac562b881f"
 [[files]]
 path = "chapters/017-construction-et-destruction.md"
 sha256 = "78808a62bd115245fa56908b742fa38d2125a941a41e0b66d10fcfdca71e8ccc"
 [[files]]
 path = "chapters/018-result-erreurs-et-exceptions.md"
 sha256 = "a3737a880d01f08cd81146f9b9b8c9079c7c22fdec09a207a6bdbc9479c9a7ed"
 [[files]]
 path = "chapters/019-controle-de-flux.md"
 sha256 = "7dd4a4df448145f98f1f3f5adf1727639ebb6f0f62c0167e93d14852fe2e2c1b"
 [[files]]
 path = "chapters/020-operateurs.md"
 sha256 = "c01b09d2274650d8de35cb2a859cf5a313babec355f79474780324126f2713a6"
 [[files]]
 path = "chapters/021-strings-unicode-et-encodages.md"
 sha256 = "a10a2a5afbe0b95353ef9e56a33b329563b0530e3a1ce9dc0fbb1525e472547b"
 [[files]]
 path = "chapters/022-collections-et-iteration.md"
 sha256 = "644c88d2e90a204de64ce8cf941ba876aaac0a35710cbb56a2ff46db09417a6c"
 [[files]]
 path = "chapters/023-optiont-et-nullablet.md"
 sha256 = "237f9c31419a9426965ac9a0ca520dcea116138c588579abc1a40628edfd8db8"
 [[files]]
 path = "chapters/024-casts-et-conversions.md"
-sha256 = "91672400a7681386b71b3ea1d090527a8609637e7b056450af05c993ce6c0f9a"
+sha256 = "d625afcee310a5c2eee2342ea96c86cd24f7185a91919849e05641b50ac47b58"
-[[files]]
+[[modified]]
 path = "chapters/025-lambdas-closures-callables-et-generators.md"
 sha256 = "62faff3388b0238cdfbb6ff3fafacf7daaf582fa5e5b40723307425e8b081686"
 [[files]]
 path = "chapters/026-async-et-concurrence.md"
 sha256 = "36f936c6af6012d04906c6d6792de589e4d15cbcc28ed45b0538b6a8aabec4ee"
 [[files]]
 path = "chapters/027-memoire-references-et-unsafe.md"
 sha256 = "4dafe27ae8243d38013b3c48ea5abe7e987cecdb4b94d193a0ed318452b16242"
 [[files]]
 path = "chapters/028-defer-et-nettoyage.md"
 sha256 = "0e7bbdf8cd57652fdaa1bbaef734c561910d5bb99a6d4ec216220a2ab3b38a15"
 [[files]]
 path = "chapters/029-ffi-et-abi.md"
 sha256 = "fc395a15a4d5404bd982105fb043a3cac639147cccaf7722fe640aaad17b573c"
 [[files]]
 path = "chapters/030-reflexion-metadonnees-et-tests.md"
 sha256 = "818bf11cbafa7b0708dbff2d474abce0abf6e533603d593dcd519c49796d8d8f"
 [[files]]
 path = "chapters/031-fichiers-source-v1.md"
 sha256 = "0d978fa1a4e30d71e2bf6634c67ac54194c48640861fbb3e5d3c337aa366fd83"
 [[files]]
 path = "chapters/032-source-root-modules-et-namespaces.md"
 sha256 = "ce5077f0475a161221919aa7f15f1c4bc0585e627070e07b99aeabcedf3a683d"
 [[files]]
 path = "chapters/033-imports-et-resolution-des-noms.md"
-sha256 = "9b8a4cef4101d35b06235345865f5f7179a8e8219c6e363fedd839251c6eb70e"
+sha256 = "9e392a4d7adf6c3569f50f6664709a64d3398ded98a6f5365eff5175a9f2a8b5"
-[[files]]
+[[modified]]
 path = "chapters/034-packages-identite-et-collisions-de-namespaces.md"
 sha256 = "e2c69dca0f46e1cc88d47531d2b605f5ffe04a5151a7a73e6e75e6f3e67ff050"
 [[files]]
 path = "chapters/035-manifests-et-workspaces.md"
 sha256 = "ddf32952d72bcaf592324295e6c69c0e43f85547e392d1ef22a67cc7aa763463"
 [[files]]
 path = "chapters/036-semver-et-politique-de-releases.md"
 sha256 = "d96c4df73e59e76510369a15032c4e1994ebc259309177c36548449ea62112be"
 [[files]]
 path = "chapters/037-dependances-et-scopes.md"
 sha256 = "a65d4e69b5a92ca9d04e2f2f83f856c4b9b12790f5b8ea64d2c7b3d21bdb68d4"
 [[files]]
 path = "chapters/038-resolver-et-lockfile.md"
 sha256 = "b1312987120a5b25e774af5ae353f112730c68ae81610a818711a12886c3a4f9"
 [[files]]
 path = "chapters/039-features-module-saselmod-et-compilation-conditionnelle.md"
 sha256 = "ab3298e8a5402844c61c283fd46c57f1727e2e6a19af7d2d89c70549742f1032"
 [[files]]
 path = "chapters/040-targets-plateformes-architectures-abi-distributions-et-capabilities.md"
-sha256 = "a07c118f3ed3dff0fd643e3bcd2334facb22740075100dff2c71384188dcb062"
+sha256 = "626fb71b95a930cf44ab3ae41f059a12df369063563bde60cb33e7876e045f3f"
-[[files]]
+[[modified]]
 path = "chapters/041-artifacts-exports-profils-et-reservation-des-formats-futurs.md"
 sha256 = "9dd1096b0488d176da8cf48dedb121427c1acf3313509f0da13d8988ae520b87"
 [[files]]
 path = "chapters/042-main-et-exitcode.md"
 sha256 = "57499c713a618e5ff52a3186072b3694c1e1144a577589becb8a9a80fae7b88f"
 [[files]]
 path = "chapters/043-documentation-et-tests-de-conformite.md"
 sha256 = "8c522c7c6ded5d39dc649c1217dd625ba482a25ec301663e1867857d9b4b1fc5"
 [[files]]
 path = "chapters/044-browser-futur-v3.md"
 sha256 = "cf9f95b7c07b2c78c86f07bf6093641645e11e67526311f13a21638ca3f47b8d"
 [[files]]
 path = "chapters/045-autres-backends-cibles-futur-v3.md"
 sha256 = "c7ff453312bf0b6db2375c98461f6c722286ab3816512d67509b85bc665cd87e"
 [[files]]
 path = "chapters/046-quantique-futur-lointain-reserve.md"
 sha256 = "b538c8e32e3376386e802de174f4a50ff14ca4262969ab065a89bbcb4b40fbe5"
 [[files]]
 path = "chapters/047-concepts-rejetes-ou-deconseilles.md"
 sha256 = "eb037983de591edeff740513d98285511bdc60da8dae38f28031dc04902cab1f"
 [[files]]
 path = "chapters/048-inventaire-des-points-v1-encore-ouverts.md"
-sha256 = "81234f81aeefa33993b37437ba9fefe83dd6f0286aa527b71a475fab55f294ce"
+sha256 = "a559b1de74ede0e5b5a209d4fe451e00a5a9d9dfcc1357ef07e376780495545c"
-[[files]]
+[[modified]]
 path = "chapters/049-elements-v1-reserves-mais-non-obligatoires-a-implementer-immediatement.md"
-sha256 = "6451dbf71d2d53e1642c9a33cf1dd109351df926ee2b7f4859c8151058c8222a"
+sha256 = "1995d1fc3229f3df6456548bec38b2e1adbc29958cef7c8397d137283d0ed243"
-[[files]]
+[[modified]]
 path = "chapters/050-elements-futurs-v3-identifies.md"
 sha256 = "69f6efc022b684d8401f0ae69ce70530d4bc607eed155182961db74ebbd102e8"
 [[files]]
 path = "chapters/051-invariants-de-conception.md"
-sha256 = "7c4ba9a3982e37630926666be3a4d4f450fb8c6508605e73a44c0d4a6ac8330e"
+sha256 = "b02f60468fe292bcfac773a98cf14b865d0fc1936bf353a299d02fec37579a19"
-[[files]]
+[[modified]]
 path = "chapters/052-priorite-de-specification-apres-0-2-9.md"
-sha256 = "c25d105588e2a0ab6dc272887dfd1c7e8fc6ca279c72e72661f140d65aea6406"
+sha256 = "b8b47f694ea42489e0e83237cbb8c956a716227428e15d8f14c9237266e332a9"
-[[files]]
+[[modified]]
 path = "examples/000-statuts-normatifs-examples.md"
 sha256 = "603326859af5152e7b5097b85acf14b464d8f6e44dd61ee97da1dbfda5ff19c3"
 [[files]]
 path = "examples/001-trajectoire-dimplementation-examples.md"
-sha256 = "dc9c9dae4d680d9142688cb9c1f6471f294f3837f69eae287f6cc76c192b8d93"
+sha256 = "b66c40c7bfc9d76fe80e15f90fcef9c3ab8eabcdbec134fb3f660cfc2b79b5f9"
-[[files]]
+[[modified]]
 path = "examples/002-principes-generaux-du-langage-examples.md"
 sha256 = "0b8662b49f5cec5a396339fb7955b5c94e5f9d3e8ae378a7d7f4bdba1cc5d141"
 [[files]]
 path = "examples/003-architecture-de-compilation-examples.md"
 sha256 = "d2a5578e5786ae43dc6f5aa8a2991bf0722a387eb1bbf8edb753d0dece9efef0"
 [[files]]
 path = "examples/004-couches-de-lecosysteme-v1-examples.md"
 sha256 = "d77a0dec5925d52eda92ff096eea9c89e17344f954fc873b2748e96159f11304"
 [[files]]
 path = "examples/005-types-primitifs-examples.md"
-sha256 = "7f76514d40634957c012225d1505e4f3897e4dc740d2f4bc10faaa9cfe74da91"
+sha256 = "9d131cd3874606d92988c2fc9ac24dc04c1349893f2be6678618cf13673a94ab"
-[[files]]
+[[modified]]
 path = "examples/006-types-variables-constantes-et-scopes-examples.md"
 sha256 = "aafae93d041b6ff7a1904b38fdf32edd108d8f3e2a4448938789acee22cead95"
 [[files]]
 path = "examples/007-types-nominaux-et-fichiers-saseltype-examples.md"
-sha256 = "68f231240b8b2aba706af1c4f31f0ee03031f077808fcc7dce106377cecacf24"
+sha256 = "a5e4dd8a36a63ea4aba31945379905ed76686b5849bbfb7f7690e5e8c3856ebd"
-[[files]]
+[[modified]]
 path = "examples/008-classes-et-object-examples.md"
 sha256 = "911176c0a75bfe34087d910777b5584b4a2a297ea55d967d47c2c2ce2ee31f28"
 [[files]]
 path = "examples/009-structs-examples.md"
 sha256 = "166489ef32db9faf73e490671664c785c700bc945ee13208d29ee54481172d02"
 [[files]]
 path = "examples/010-enums-algebriques-examples.md"
 sha256 = "315d85a96f31809ce5a600e262d3719ecfb735ac47603cccd6c7f7af2cdde79b"
 [[files]]
 path = "examples/011-tuples-examples.md"
 sha256 = "254dab32d5e9a21f4a9849894bac2d7f946a1c113e76f3c40388fe35dd87229f"
 [[files]]
 path = "examples/012-unions-examples.md"
 sha256 = "68bf56ae82d3a82d4c306c44d8be979c3d96342e1d0d6c6d6a864a7dee7a7110"
 [[files]]
 path = "examples/013-interfaces-examples.md"
 sha256 = "eaa95dd7a8e4a6d48e132a2e092d8919c70810678adfc4adfcb0144a2ee8fd82"
 [[files]]
 path = "examples/014-generics-examples.md"
-sha256 = "31e091f9e765ddf75ed4317871814dd516447d37f96332de4190117e24acdc2d"
+sha256 = "c1912b3657b0633e9d143e069bd75eb079486d1f2de8e6cd67f374aa7edcd78b"
-[[files]]
+[[modified]]
 path = "examples/015-fonctions-methodes-et-clsmethod-examples.md"
 sha256 = "d200b80b6aa44592fc402e31905d2fad39c6a2c8af72141b62bd50d18327d85d"
 [[files]]
 path = "examples/016-dispatch-override-et-modificateurs-examples.md"
 sha256 = "1b0692a23aea7f987413ab9e1b28b47319b5b0bc3b4bbc01da6427e626a0ab6e"
 [[files]]
 path = "examples/017-construction-et-destruction-examples.md"
 sha256 = "b5007805d0f49736b0ede122549bc25ccc8324152e391781694daa692df1b1a4"
 [[files]]
 path = "examples/018-result-erreurs-et-exceptions-examples.md"
 sha256 = "07ccc65d0f0da12df0b3693931355791a8f10f92b35ff7513f54fd8fa948b9c2"
 [[files]]
 path = "examples/019-controle-de-flux-examples.md"
 sha256 = "1932134c40c28ccfc8e412737fa41a3bf7b62230dfaf19b1f8ba9c874897e215"
 [[files]]
 path = "examples/020-operateurs-examples.md"
 sha256 = "d3dfdb43d3b22ea49f26d86605a37ebe63bdfd03c1ca281f40b113e50bc7dc47"
 [[files]]
 path = "examples/021-strings-unicode-et-encodages-examples.md"
 sha256 = "789523370776c97890bfec3969c04e203ec27580778f169eb78fc00503e51ff3"
 [[files]]
 path = "examples/022-collections-et-iteration-examples.md"
 sha256 = "264f10c49cc8743d99709ff6449d7fc1b0ed89825972acbd7619e99167278a13"
 [[files]]
 path = "examples/023-optiont-et-nullablet-examples.md"
 sha256 = "4de6187045e9159fd5300219632b79ecdaa558d2c001ff40dac131e31e2d3e19"
 [[files]]
 path = "examples/024-casts-et-conversions-examples.md"
-sha256 = "669d64eecfb93484c44d37a4e7ea9089fec6f5369ecd0f51bcdd0e42d478f5ee"
+sha256 = "5e402ca2584d2272b88a656d335ea8360224de937d75cab3b5c9f83efbf608af"
-[[files]]
+[[modified]]
 path = "examples/025-lambdas-closures-callables-et-generators-examples.md"
 sha256 = "e423a0e4f204187ec7e4082d16ad1c69178009b213730764da3a79318e338b32"
 [[files]]
 path = "examples/026-async-et-concurrence-examples.md"
 sha256 = "879445bf8779a0b895fa1e6014a1ac404c1b9c94138edeab8dfc3eeff08e6197"
 [[files]]
 path = "examples/027-memoire-references-et-unsafe-examples.md"
 sha256 = "9ae88eb5f6392411da9c1a60b5c1026342c2c73e2e57516a37535f46562fcf8c"
 [[files]]
 path = "examples/028-defer-et-nettoyage-examples.md"
 sha256 = "1f9d7ee762391b7cd49811cefe550825ff086160d53a268f37f9eccbb40c1acd"
 [[files]]
 path = "examples/029-ffi-et-abi-examples.md"
 sha256 = "32dc3da8d95ab38f5c4beaba7d86a316856f0c18ddf867d915a80a004eced7fc"
 [[files]]
 path = "examples/030-reflexion-metadonnees-et-tests-examples.md"
 sha256 = "44fb73994d7d26d67ad9cc1274c8f3ef526b1516696807c59776ad0a9444d33d"
 [[files]]
 path = "examples/031-fichiers-source-v1-examples.md"
 sha256 = "9741c8a0dc0e998e006e09b01d4b215e0b61a24282d334bf6a422c78a59c01fd"
 [[files]]
 path = "examples/032-source-root-modules-et-namespaces-examples.md"
 sha256 = "b998d3b625c15b9481c2f983c5e7577d32f95b441d839663f1d3e586dc774722"
 [[files]]
 path = "examples/033-imports-et-resolution-des-noms-examples.md"
-sha256 = "8c2e4f9777d2fd051bb739a9aa34ab6ba7bbc0fee7f9beef739d98d2c7bc6bde"
+sha256 = "2932904dce7683d2da856a6be78ba09f57ef1dd4d95c3df8c4280685d28c9003"
-[[files]]
+[[modified]]
 path = "examples/034-packages-identite-et-collisions-de-namespaces-examples.md"
 sha256 = "825e5375e64e3e395d7d5dd3409b2bbcca17a54eef49474aa5041f2374902f6b"
 [[files]]
 path = "examples/035-manifests-et-workspaces-examples.md"
 sha256 = "7541fa0ce1a82bb7f3911f7e4c63d45c1b018f58e5e5a1d05a1d0bcc7231e8a2"
 [[files]]
 path = "examples/036-semver-et-politique-de-releases-examples.md"
 sha256 = "fc7ced4d0441b0a3ace89da6476dad95ae88a922e4258e239ef207f96296bfe0"
 [[files]]
 path = "examples/037-dependances-et-scopes-examples.md"
 sha256 = "fbb49ee7ab46c36494846fb5de6f031a924ef130dcbe3fa8a146061220234a07"
 [[files]]
 path = "examples/038-resolver-et-lockfile-examples.md"
 sha256 = "538c464ebf90fe62caa293bed81db33c0c2a83ad5212d2376f13c68d01bcac0c"
 [[files]]
 path = "examples/039-features-module-saselmod-et-compilation-conditionnelle-examples.md"
 sha256 = "b94143a8a166341c5b9d7a4d5d1f3d4e30d4246dace2996b04ba5168edde2069"
 [[files]]
 path = "examples/040-targets-plateformes-architectures-abi-distributions-et-capabilities-examples.md"
-sha256 = "7d06abcbbdad7bda07bf490f5a8847ad7cfb8634d9479c9b1302f173e2366793"
+sha256 = "c42e68657c168e6bab2e1d6d4050530f34f649a2be785e66efd64a310e082f3e"
-[[files]]
+[[modified]]
 path = "examples/041-artifacts-exports-profils-et-reservation-des-formats-futurs-examples.md"
 sha256 = "65b85a25d9caed6955864a85dff17cdedfdef56cb27f77dbe133837738850999"
 [[files]]
 path = "examples/042-main-et-exitcode-examples.md"
 sha256 = "5e863daae3593ba7e39da2fbee6b1721988d8edf82f5abdb1a0ca14520d54e69"
 [[files]]
 path = "examples/043-documentation-et-tests-de-conformite-examples.md"
 sha256 = "a0b99ab645787b6b0bbb2e83041888cfe2782fae0a9064fa2bfa5907b817b819"
 [[files]]
 path = "examples/044-browser-futur-v3-examples.md"
 sha256 = "b1b63def42c8abebe943c89f618e16bcabd56e050bee760c9ba3b063dcf951d8"
 [[files]]
 path = "examples/045-autres-backends-cibles-futur-v3-examples.md"
 sha256 = "92a6269861d51d9364eb76d4533cecf8ea36e8111f257b96f916d6fd63d91dbd"
 [[files]]
 path = "examples/046-quantique-futur-lointain-reserve-examples.md"
 sha256 = "da2b95b3adf5431e4c32dcd631fd380a04b4173c98b2c638cad2e5f4564e131b"
 [[files]]
 path = "examples/047-concepts-rejetes-ou-deconseilles-examples.md"
 sha256 = "0c347c9c622096fe026a76671c88258e37896b4e735b33fac2d5b01cc9a73fed"
 [[files]]
 path = "examples/048-inventaire-des-points-v1-encore-ouverts-examples.md"
-sha256 = "6b9ce1377041b4bfd40a48eab0bb6a40b852e8c1c7cedde89a6329b6c495c192"
+sha256 = "0fe4bab707d7ec4a01e33dbf3ed65d146fa4b33b495da20f8cbe89b89113e5d3"
-[[files]]
+[[modified]]
 path = "examples/049-elements-v1-reserves-mais-non-obligatoires-a-implementer-immediatement-examples.md"
-sha256 = "0fde247c9612c8ab74260c948c6d0d9a1648388dbfa5794fb7040a7ecaf7184e"
+sha256 = "85cb6954c4fc2f5dcb3be207d936a412f1633b81d704ad34c8d63c02cb5b4c5e"
-[[files]]
+[[modified]]
 path = "examples/050-elements-futurs-v3-identifies-examples.md"
 sha256 = "49fa7b31de952d996fa8384ce1addc22a12f9d7a05f46d651e1eb2cf055d1c55"
 [[files]]
 path = "examples/051-invariants-de-conception-examples.md"
-sha256 = "491525c8e45c5ef71f4bcc0420d3757ac004f5da47b5a21a29c5088f539bff68"
+sha256 = "bcf646572abee78a42bdb4e2452b2db53ea38c799cd6c131ec108be0bf6b76c2"
-[[files]]
+[[modified]]
 path = "examples/052-priorite-de-specification-apres-0-2-9-examples.md"
-sha256 = "a663bdf02646d77ed5d870a0a8c24c477f4067ccc163e1c6ac55d46b368f539d"
+sha256 = "9990f270f36c071dbd471e6955e40156164b8b75baa073668dc8e5e9c258d935"
 [[files]]
 path = "profiles/language-compiler.md"
 sha256 = "705758ab8d40838bd9dc119e90183e69013258c028467d66df2678d676f915f1"
 [[files]]
 path = "profiles/language-core.md"
 sha256 = "42f503a3ed5fa77e88c218c46523e4ef1b72e4104a2f8471597b4b900d492567"
 [[files]]
 path = "profiles/platform.md"
 sha256 = "19440a7628f2e26d15fa8d33a4f0e5b8e5c936b3e23e293a9a27f16d2ff34322"
--- a/annexes/A-numeric-conversions.md
+++ b/annexes/A-numeric-conversions.md
@@ -49,6 +49,13 @@ wrapToInt32()
 En revanche, pour `int32 -> int8`, `tryToInt8()`, `saturateToInt8()` et `wrapToInt8()` ont trois contrats différents et peuvent coexister.
 Une règle de composition complète cette non-redondance :
 > Deux opérations ne sont fusionnées dans un même nom que si leur séparation en opérations Core successives modifierait la sémantique, perdrait de l'information ou empêcherait d'exprimer le même contrat.
 Ainsi `value::floor()::tryToInt32()` rend inutile un alias `tryFloorToInt32()` si les deux formes sont strictement équivalentes.
 ## A.3. Nomenclature générale
 | Code | Famille | Contrat |
@@ -125,16 +132,16 @@ Légende :
 |---|---|---|---|---|
 | int8 | T | T | T | T |
 | int16 | E+R | T | T | T |
-| int32 | E+TR+S | E+R | T | T |
+| int32 | E+TR+SR | E+R | T | T |
-| int64 | E+TR+S | E+R | E+R | T |
+| int64 | E+TR+SR | E+R | E+R | T |
-| int128 | E+TR+S | E+R | E+R | E+R |
+| int128 | E+TR+SR | E+R | E+R | E+R |
-| int256 | E+TR+S | E+TR+S | E+R | E+R |
+| int256 | E+TR+SR | E+TR+SR | E+R | E+R |
 | uint8 | T | T | T | T |
-| uint16 | E+TR+S | T | T | T |
+| uint16 | E+TR+SR | T | T | T |
-| uint32 | E+TR+S | E+R | T | T |
+| uint32 | E+TR+SR | E+R | T | T |
-| uint64 | E+TR+S | E+R | E+R | T |
+| uint64 | E+TR+SR | E+R | E+R | T |
-| uint128 | E+TR+S | E+TR+S | E+R | E+R |
+| uint128 | E+TR+SR | E+TR+SR | E+R | E+R |
-| uint256 | E+TR+S | E+TR+S | E+R | E+R |
+| uint256 | E+TR+SR | E+TR+SR | E+R | E+R |
 Contrats :
@@ -166,88 +173,128 @@ Légende :
 | Source \ Destination | float16 | float32 | float64 | float128 |
 |---|---|---|---|---|
 | float16 | — | T | T | T |
-| float32 | E+TR+S | — | T | T |
+| float32 | E+TR+SR | — | T | T |
-| float64 | E+TR+S | E+TR+S | — | T |
+| float64 | E+TR+SR | E+TR+SR | — | T |
-| float128 | E+TR+S | E+TR+S | E+TR+S | — |
+| float128 | E+TR+SR | E+TR+SR | E+TR+SR | — |
 Règles :
 - l'élargissement de format est exact au niveau de la valeur IEEE et utilise uniquement `toFloatXX()` ;
 - la réduction de format propose `tryToFloatXX()` pour exiger l'exactitude, `tryRoundToFloatXX()` pour accepter la perte de précision mais pas le débordement fini, et `saturatingRoundToFloatXX()` pour obtenir une opération totale sur le domaine flottant ;
 - `NaN`, `+Infinity`, `-Infinity`, `+0` et `-0` restent des catégories IEEE valides dans la destination ;
 - pour `NaN`, seule la propriété sémantique `isNaN(destination) == true` est garantie ; payload, signe et quiet/signaling bit ne sont pas garantis par une conversion de valeur ;
 - `tryToFloatXX()` accepte `NaN` et les infinities lorsque la destination est un type flottant Saselang, car ces catégories y sont représentables ;
 - `saturatingRoundToFloatXX()` ne transforme pas une infinité en valeur finie puisque l'infinité est elle-même représentable dans le format destination ; la saturation explicite concerne les valeurs **finies** hors du domaine fini destination ;
- la conservation exacte du payload binaire d'un `NaN` n'est pas garantie par une conversion de valeur ; elle relève d'un éventuel contrat binaire distinct et de `bitcast` lorsque les tailles sont compatibles.
+- la conservation exacte d'une représentation binaire relève d'un contrat binaire distinct et de `bitcast` lorsque ses propres contraintes sont compatibles.
-## A.8. Flottant -> entier : inventaire des politiques
+## A.8. Flottant -> entier : composition des politiques
 Il n'existe jamais de simple `toIntXX()` ou `toUintXX()` depuis un flottant.
-La conversion doit annoncer à la fois la politique de passage du réel à l'entier et, lorsque cela est pertinent, la politique de dépassement de domaine.
+La conversion stricte canonique est :
-### A.8.1. Politique mathématique
+```text
-
+tryToIntXX()
-| Famille | Sens |
+tryToUintXX()
 |---|---|
 | `Exact` | Accepte uniquement une valeur flottante finie déjà mathématiquement entière. |
 | `Floor` | Plus grand entier mathématique inférieur ou égal. |
 | `Ceil` | Plus petit entier mathématique supérieur ou égal. |
 | `Round` | Nearest, ties to even. |
 | `Truncate` | Suppression de la partie fractionnaire, donc direction zéro. |
 ### A.8.2. Politique de domaine destination
 | Politique | Forme | Comportement |
 |---|---|---|
 | Checked | `try<Policy>ToTarget()` | `Err` sur `NaN`, infinité ou résultat hors plage. |
 | Saturating | `trySaturating<Policy>ToTarget()` | `Err` sur `NaN`; les infinités et résultats hors plage saturent aux bornes destination. |
 | Wrapping | `tryWrapping<Policy>ToTarget()` | `Err` sur `NaN` et infinité; les résultats entiers finis sont réduits modulo `2^N`. |
 La famille complète potentiellement distincte pour une destination entière donnée est donc :
 ```saselang
 value::tryExactToInt32()
 value::tryFloorToInt32()
 value::tryCeilToInt32()
 value::tryRoundToInt32()
 value::tryTruncateToInt32()
 value::trySaturatingExactToInt32()
 value::trySaturatingFloorToInt32()
 value::trySaturatingCeilToInt32()
 value::trySaturatingRoundToInt32()
 value::trySaturatingTruncateToInt32()
 value::tryWrappingExactToInt32()
 value::tryWrappingFloorToInt32()
 value::tryWrappingCeilToInt32()
 value::tryWrappingRoundToInt32()
 value::tryWrappingTruncateToInt32()
 ```
-La même famille est applicable aux douze destinations entières `int8..int256` / `uint8..uint256` et aux quatre sources flottantes.
+Elle réussit uniquement si la valeur flottante est finie, mathématiquement entière, dans le domaine de la destination et exactement représentable comme entier destination. Sinon elle retourne `Err(NumericConversionError(...))`.
-Cette section est volontairement exhaustive : lors de la stabilisation Core, certaines combinaisons pourront être supprimées si elles n'apportent aucune valeur pratique ou si une composition Core unique est préférée. Elles ne devront en revanche jamais être remplacées par une opération ambiguë.
+### A.8.1. Politiques mathématiques séparées
-### A.8.3. Matrice flottant -> entier
+Les opérations Core :
-Toutes les paires source/destination partagent actuellement le même ensemble de politiques candidates ; la table sert à garantir qu'aucun type n'est oublié.
+```text
 floor()
 ceil()
 round()
 truncate()
 ```
 restent des opérations sur le flottant et définissent chacune une politique mathématique unique.
 Elles se composent ensuite avec les conversions :
 ```saselang
 value::floor()::tryToInt32()
 value::ceil()::tryToInt32()
 value::round()::tryToInt32()
 value::truncate()::tryToInt32()
 ```
 Cette composition remplace les alias redondants `tryFloorTo...`, `tryCeilTo...`, `tryRoundTo...` et `tryTruncateTo...`.
 `round()` utilise la règle canonique **nearest, ties to even**.
 ### A.8.2. Dépassement de domaine
 Les politiques de dépassement restent séparées de la politique mathématique.
 Pour chaque destination entière, le Core peut exposer :
 ```text
 tryToTarget()
 trySaturateToTarget()
 tryWrapToTarget()
 ```
 avec les contrats suivants :
 | Opération | Préconditions non liées à la plage | Politique de plage |
 |---|---|---|
 | `tryToTarget()` | valeur finie et mathématiquement entière | `Err` si hors plage |
 | `trySaturateToTarget()` | valeur finie et mathématiquement entière | borne à `Target::Min` / `Target::Max` |
 | `tryWrapToTarget()` | valeur finie et mathématiquement entière | modulo `2^N` selon le type entier destination |
 Les politiques se composent :
 ```saselang
 value::floor()::trySaturateToInt32()
 value::round()::trySaturateToUint16()
 value::truncate()::tryWrapToInt8()
 value::ceil()::tryWrapToUint64()
 ```
 Il n'existe pas de variantes combinées telles que `trySaturatingFloorToInt32()` ou `tryWrappingRoundToInt32()` lorsque la composition ci-dessus possède exactement la même sémantique.
 ### A.8.3. Matrice flottant -> entier après élimination des doublons
 Pour chaque paire, la matrice conserve uniquement les politiques dont le résultat peut réellement différer sur une valeur source admissible.
 Légende :
 ```text
 C
    tryToTarget() uniquement
 CSW
    tryToTarget()
    trySaturateToTarget()
    tryWrapToTarget()
 ```
 | Source \ Destination | int8 | int16 | int32 | int64 | int128 | int256 | uint8 | uint16 | uint32 | uint64 | uint128 | uint256 |
 |---|---|---|---|---|---|---|---|---|---|---|---|---|
-| float16 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 |
+| float16 | CSW | CSW | C | C | C | C | CSW | CSW | CSW | CSW | CSW | CSW |
-| float32 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 |
+| float32 | CSW | CSW | CSW | CSW | CSW | C | CSW | CSW | CSW | CSW | CSW | CSW |
-| float64 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 |
+| float64 | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW |
-| float128 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 | F15 |
+| float128 | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW | CSW |
-`F15` désigne les 15 opérations candidates listées en A.8.2 : 5 politiques mathématiques × 3 politiques de domaine.
+Justification :
 - toutes les valeurs finies et mathématiquement entières de `float16` tiennent dans `int32` et les entiers signés plus larges ; saturation et wrapping n'apportent donc rien pour ces paires ;
 - toutes les valeurs finies et mathématiquement entières de `float32` tiennent dans `int256`, mais pas dans `int128` ou plus petit ;
 - pour toute destination non signée, les valeurs négatives rendent checked, saturation et wrapping distincts, même lorsque toute magnitude positive finie tient dans la destination ;
 - `float64` et `float128` disposent de valeurs finies dépassant le domaine de tous les entiers Saselang V1.
 Cas particuliers :
- `+0` et `-0` produisent l'entier zéro lorsque l'opération choisie réussit ;
+- `+0` et `-0` donnent l'entier zéro ;
- `NaN` n'a jamais de conversion entière implicite ni de valeur saturée/wrappée arbitraire ;
+- `NaN`, `+Infinity` et `-Infinity` échouent dans ces familles car ils ne satisfont pas la précondition de valeur finie et mathématiquement entière ;
- le wrapping est défini sur le résultat entier mathématique fini après application de `Exact/Floor/Ceil/Round/Truncate` ;
+- pour une destination non signée, la saturation d'une valeur négative entière donne `0` ;
- pour une destination non signée, la saturation d'une valeur négative aboutit à `0` ;
+- pour une destination signée, la saturation utilise `Target::Min` / `Target::Max` ;
- pour une destination signée, la saturation utilise `Target::Min` / `Target::Max`.
+- le wrapping est appliqué au résultat entier mathématique fini selon modulo `2^N`.
 ## A.9. `bitcast` reste hors de cette matrice
@@ -271,13 +318,15 @@ int32 c = small::toInt32();     // OK
 Les membres de conversion appartiennent au Core des primitives. Le compilateur doit pouvoir reconnaître leur contrat via les métadonnées/Core intrinsics nécessaires sans transformer chaque membre en syntaxe spéciale.
-Une opération Core peut être :
+Pour les conversions fondamentales de cette matrice :
- universelle dans le profil Core minimal ;
+> si les types source et destination sont supportés par le target, les opérations non redondantes définies par la matrice sont Core-required.
 - disponible par émulation logicielle même sans instruction machine native ;
 - ou conditionnée par une capacité target lorsqu'elle dépend réellement d'une plateforme/backend.
-Une optimisation matérielle ne constitue pas, à elle seule, une raison de rendre une opération absente : une implémentation logicielle conforme est préférable lorsqu'elle est raisonnable.
+L'absence d'une instruction matérielle native ne rend pas l'opération optionnelle lorsqu'une émulation logicielle conforme est raisonnablement possible.
 Un target réduit peut ne pas exposer un type fondamental donné. Dans ce cas, l'indisponibilité doit porter sur le type/capacité fondamentale, pas sur une sélection arbitraire de ses conversions.
 La nomenclature générale des capabilities et leurs niveaux sont définis au chapitre 40.
 ## A.12. Hiérarchie documentaire cible
@@ -294,15 +343,40 @@ Saselang Platform Documentation
    langage + Core + SDKs + extensions de plateforme
 ```
-À partir de `1.0.0-alpha`, la Bible sera distribuée sous forme d'une archive ZIP structurée avec sommaire, chapitres séparés, exemples/DO-DON'T par chapitre et annexes référencées.
+Depuis `0.2.12`, la Bible est distribuée sous forme d'une archive multifichier structurée avec sommaire, chapitres séparés, exemples/DO-DON'T par chapitre et annexes référencées.
-## A.13. Points encore à valider
+## A.13. `NumericConversionError`
-Les points suivants restent volontairement ouverts avant de rendre cette annexe normative :
+`NumericConversionError` est le nom de travail du `ResultError` Core des conversions récupérables.
-1. confirmer la nomenclature exacte des formes composées `trySaturating...` et `tryWrapping...` pour `float -> integer` ;
+Les codes sémantiques V1 sont :
 2. décider si les 15 opérations `float -> integer` doivent réellement être exposées directement ou si certaines doivent être obtenues par composition d'opérations Core sans créer d'alias sémantique ;
 3. préciser le contrat observable des payloads NaN lors des conversions `float -> float` ;
 4. définir les codes et informations minimales de `NumericConversionError` ;
 5. classer explicitement les capacités numériques en Core minimal obligatoire ou capacité conditionnelle de target.
 ```text
 NotFinite
 NotIntegral
 OutOfRange
 Inexact
 ```
 L'erreur reste minimale et ne transporte pas automatiquement la valeur source, les types source/destination, le backend, un timestamp ou un mode d'arrondi.
 ## A.14. État de l'annexe
 Les principes sémantiques de la matrice sont désormais largement figés :
 ```text
 non-redondance par paire
 composition plutôt qu'alias combinés
 règles float -> integer
 règles NaN / infinities / signed zero
 NumericConversionError
 disponibilité Core pour les types supportés
 émulation logicielle lorsque raisonnable
 ```
 Restent principalement à auditer lors de l'implémentation Core :
 1. le listing mécanique exhaustif des membres concrets exposés par chaque primitive ;
 2. les noms définitifs des constantes/membres Core associés ;
 3. la représentation interne exacte des codes `NumericConversionError` ;
 4. les tests de conformité couvrant toutes les cellules de la matrice.
--- a/chapters/001-trajectoire-dimplementation.md
+++ b/chapters/001-trajectoire-dimplementation.md
@@ -2,7 +2,7 @@
 ## 1.1 V1 — V1 REQUIS — FIGÉ
-La V1 constitue le premier environnement réellement utilisable de Saselang.
+V1 constitue la première implémentation cohérente et réellement utilisable de Saselang, mais reste avant tout une **base/POC d'implémentation et de validation**. Elle n'est pas la baseline publique de compatibilité durable.
 Objectifs :
@@ -15,7 +15,7 @@ analyse sémantique
 HIR
 Sase IR
 interpréteur
-a backend LLVM
+backend LLVM
 Core V1
 SDK initial
 manifests et workspaces
@@ -29,6 +29,8 @@ LLVM est le premier backend compilé de V1.
 La conception de Saselang ne doit cependant pas faire de LLVM une dépendance sémantique du frontend.
 V1 doit être suffisamment complète pour révéler les erreurs de conception réelles du langage. Des corrections incompatibles restent possibles avant la baseline publique V3 lorsqu'elles sont motivées, documentées et répercutées de façon cohérente dans la Bible, le Core et la toolchain.
 ## 1.2 Couverture LLVM — V1 REQUIS — FIGÉ EN PRINCIPE
 Le backend natif V1 doit rester suffisamment générique pour exploiter les architectures, formats objet et capacités que LLVM peut représenter.
@@ -42,12 +44,11 @@ représentable par le backend
 mais non officiellement supportée par la toolchain Saselang
 ```
-## 1.3 V2 — SELF-HOSTING
+## 1.3 V2 — SELF-HOSTING / SECOND POC
-La V2 reste également une génération interne. Elle a pour objectif principal la réécriture/self-hosting du compilateur, de l'interpréteur et des outils en Saselang. Des corrections architecturales incompatibles avec V1 restent acceptables si elles sont nécessaires et documentées.
+V2 est principalement la génération de self-hosting et le second POC structurel du langage.
-
+Elle a pour objectif de réécrire progressivement en Saselang les composants réalisés en V1 :
 La V2 a pour objectif principal de réécrire progressivement en Saselang les composants réalisés en V1 :
 ```text
 compiler frontend
@@ -59,14 +60,32 @@ package/build tooling
 Core/SDK lorsque pertinent
 ```
-La V2 est d'abord une étape de validation du langage par lui-même, pas une excuse pour redéfinir arbitrairement la sémantique V1.
+Le self-hosting doit révéler les contraintes réelles d'un grand programme Saselang écrit en Saselang lui-même.
-## 1.4 V3+ — FUTUR V3+
+Des corrections architecturales incompatibles avec V1 restent acceptables lorsqu'un besoin concret les justifie. V2 n'est cependant pas une excuse pour ajouter des mécanismes spéculatifs ou redéfinir arbitrairement la sémantique.
-La première distribution générale du compilateur et de l'écosystème Saselang est envisagée à partir de V3 ou d'une génération ultérieure. C'est à partir de cette baseline publique que la compatibilité source, binaire et de tooling devra être protégée beaucoup plus strictement.
+Une fonctionnalité future peut être réservée avant son implémentation uniquement lorsqu'un besoin réel est déjà identifié et qu'il est utile de protéger son espace syntaxique ou sémantique. Saselang ne réserve pas des mécanismes purement hypothétiques « au cas où ».
 ## 1.4 V3+ — BASELINE PUBLIQUE
-À partir de V3+, les efforts pourront se concentrer sur les autres environnements et backends :
+V3 est envisagée comme la première génération réellement déterminante pour la stabilité publique du langage et de son écosystème.
 À partir de cette baseline, la compatibilité :
 ```text
 source
 Core
 tooling
 packages
 artifacts
 et, lorsque défini, ABI/binaire
 ```
 doit être protégée beaucoup plus strictement.
 Les changements incompatibles deviennent alors des décisions exceptionnelles, versionnées et explicitement justifiées.
 À partir de V3+, les efforts pourront également se concentrer sur les autres environnements et backends :
 ```text
 browser runtime / extension
--- a/chapters/005-types-primitifs.md
+++ b/chapters/005-types-primitifs.md
@@ -116,7 +116,7 @@ Le modulo euclidien sera une opération explicite du Core/SDK.
 La sémantique flottante suit IEEE pour les représentations et opérations applicables. Les littéraux sont arrondis vers le type flottant cible selon les règles IEEE normales ; Saselang n'exige pas qu'un littéral décimal soit représentable exactement.
-Le tableau exact des cas particuliers, conversions, NaN, infinities, division par zéro et comportement de `%` flottant doit être normatif avant implémentation finale.
+Les règles de conversion, `NaN`, infinities et zéros signés déjà figées sont détaillées au chapitre 24 et dans l'annexe `A-numeric-conversions.md`. Les règles restantes des opérations flottantes, notamment division par zéro et comportement de `%`, doivent encore être fermées avant implémentation finale.
 ## 5.7 Littéraux numériques — V1 REQUIS — FIGÉ EN PRINCIPE
@@ -215,4 +215,20 @@ bitcast<float16>(value)
 qui réinterprète les bits selon les règles de `bitcast`. Les règles de plage et d'échec des conversions sont différées au groupe casts/conversions.
 ## 5.8 Abstraction Core `Numeric` — V1 REQUIS — DIRECTION FIGÉE
 Le Core doit fournir une véritable abstraction nominale `Numeric`.
 `Numeric` n'est pas une catégorie syntaxique spéciale du compilateur et ne remplace pas les types primitifs. Elle sert à exprimer des contrats génériques réels :
 ```text
 where T implements Numeric
 ```
 Les primitives numériques Saselang satisfont le contrat `Numeric` via le Core.
 Les types utilisateurs pourront satisfaire `Numeric` uniquement en implémentant explicitement son contrat lorsque celui-ci sera définitivement spécifié. La présence de méthodes ressemblant à des opérations numériques ne suffit jamais par duck typing.
 La hiérarchie exacte de `Numeric`, ses membres et ses relations éventuelles avec `Comparable<T>` et les interfaces `Op...` restent à fermer lors de la définition exhaustive du Core.
 ---
--- a/chapters/007-types-nominaux-et-fichiers-saseltype.md
+++ b/chapters/007-types-nominaux-et-fichiers-saseltype.md
@@ -16,8 +16,137 @@ enum
 union
 ```
-Le nom du fichier doit correspondre au nom du type.
+Le nom du fichier doit correspondre exactement au nom du type.
 Le fichier ne contient pas d'autres types top-level ni de fonctions auxiliaires top-level.
 ## 7.3 Ordre source et découverte nominale — V1 REQUIS — FIGÉ
 L'ordre textuel des fichiers ou des déclarations n'a pas de signification sémantique pour la résolution des types.
 Le frontend doit d'abord construire un index des déclarations nominales accessibles avant de finaliser leurs dépendances sémantiques.
 Saselang n'expose pas de syntaxe utilisateur de forward declaration telle que :
 ```text
 class Foo;
 struct Bar;
 ```
 Une forward declaration manuelle serait redondante avec la collecte nominale du compilateur et réintroduirait des problèmes de cohérence inutiles.
 ## 7.4 États conceptuels de complétude — V1 REQUIS — FIGÉ EN PRINCIPE
 La spécification distingue conceptuellement :
 ```text
 nominalement connu
    identité du type, kind et paramètres génériques connus
 sémantiquement complet
    déclaration, héritage, interfaces et contrats résolus
 layout-complet
    représentation by-value, taille et alignement calculables lorsque nécessaires
 ```
 Ces états décrivent le travail du compilateur ; le programmeur n'a pas à gérer explicitement des « types incomplets » comme en C/C++.
 Une déclaration générique peut être sémantiquement complète sans posséder un layout concret unique avant instanciation.
 ## 7.5 Dépendances de layout by-value — V1 REQUIS — FIGÉ
 Toute dépendance récursive **par valeur** est interdite, même lorsqu'une instanciation particulière pourrait théoriquement avoir une taille nulle.
 Exemples interdits :
 ```text
 struct A {
    A value;
 }
 ```
 ```text
 struct A {
    B b;
 }
 struct B {
    A a;
 }
 ```
 ```text
 struct A {
    StaticArray<A, 0> values;
 }
 ```
 La longueur nulle ne crée aucune exception à la règle.
 Les tuples, payloads d'enums algébriques, structs et autres composants réellement stockés inline participent au graphe de layout. `StaticArray<T,N>` participe également à ce graphe quel que soit `N`.
 Le compilateur doit détecter les cycles directs et indirects du graphe by-value.
 ## 7.6 Classes et références — V1 REQUIS — FIGÉ EN PRINCIPE
 Une valeur de type classe représente une référence d'objet et non une copie inline de l'objet complet.
 Ainsi :
 ```text
 class A {
    B b;
 }
 class B {
    A a;
 }
 ```
 ne crée pas un cycle de layout by-value.
 Une classe peut néanmoins contenir des champs réellement by-value, par exemple un struct ; le layout de ces champs reste soumis aux règles normales du graphe de layout.
 Le modèle mémoire exact des références sera détaillé au chapitre mémoire sans modifier cette propriété sémantique.
 ## 7.7 Interfaces et stockage — V1 REQUIS — FIGÉ
 Une interface est un contrat et ne possède pas d'état d'instance propre.
 Le fait qu'une classe, un struct ou un autre type admissible implémente une interface ne change jamais implicitement son modèle de stockage, son identité ou son mode d'indirection.
 Un struct qui implémente une interface reste donc soumis exactement aux mêmes interdictions de récursivité by-value qu'un autre struct.
 ## 7.8 Héritage cyclique — V1 REQUIS — FIGÉ
 Le graphe `extends` doit être acyclique.
 Sont interdits :
 ```text
 class A extends B
 class B extends A
 ```
 et :
 ```text
 interface A extends B
 interface B extends A
 ```
 ainsi que tout cycle indirect.
 Les diamants non cycliques restent autorisés pour les interfaces. Le fait d'atteindre un ancêtre commun par plusieurs chemins ne constitue pas un cycle.
 Les diagnostics doivent identifier le graphe réellement fautif, par exemple :
 ```text
 cyclic inheritance
 recursive by-value layout
 ```
 et non produire un message générique de « circular dependency ».
 ---
--- a/chapters/014-generics.md
+++ b/chapters/014-generics.md
@@ -1,6 +1,6 @@
 # 14. Generics
-## 14.1 Disponibilité — V1 REQUIS — FIGÉ
+## 14.1 Disponibilité et syntaxe — V1 REQUIS — FIGÉ
 Les generics font partie de V1.
@@ -12,23 +12,554 @@ Result<T,E>
 OpAdd<Lhs,Rhs,Out>
 ```
-## 14.2 Points restant à fermer — V1 REQUIS — À FINALISER
+Déclarations :
 Doivent encore être spécifiés précisément :
 ```text
-syntaxe des contraintes
+class Box<T> {
-variance ou absence de variance
+    ...
-contraintes multiples
+}
-specialization éventuelle
+
-monomorphisation vs représentation partagée
+struct Pair<A, B> {
-contraintes sur types primitifs
+    ...
-const generics pour StaticArray<T,N>
+}
-generic methods
+
-inférence éventuelle des arguments génériques à l'appel
+interface Comparable<T> {
-wildcards/existentials éventuels
+    ...
 }
 func identity<T>(T value) -> T {
    return value;
 }
 ```
-Le type de retour ne doit pas devenir un moyen de résoudre une surcharge ambiguë.
+Les paramètres génériques sont toujours déclarés explicitement. Un identifiant inconnu n'est jamais transformé implicitement en paramètre générique.
 Les noms de paramètres de type suivent la règle des noms de types et commencent donc par une lettre ASCII majuscule.
 ## 14.2 Instanciation explicite et absence de raw type — V1 REQUIS — FIGÉ
 Un type générique doit être instancié avec ses arguments :
 ```text
 Box<int32>
 Pair<String, uint64>
 Result<Data, ParseError>
 ```
 La forme brute d'un type générique est invalide :
 ```text
 Box
 Result
 ```
 Il n'existe pas en V1 de déduction du type nominal à la construction comparable à la class template argument deduction de C++.
 L'identité du type générique construit doit être explicite :
 ```text
 Box<int32> box = Box<int32>(42);
 ```
 ## 14.3 Inférence à l'appel — V1 REQUIS — FIGÉ
 L'inférence des paramètres génériques est autorisée pour un appel de fonction ou de méthode lorsque les arguments fournis déterminent directement et sans ambiguïté les paramètres.
 ```text
 func first<T>(T left, T right) -> T;
 int32 a = ...;
 int32 b = ...;
 int32 c = first(a, b);
 ```
 L'inférence :
 - utilise les types des arguments d'appel ;
 - n'utilise jamais le type de destination ou le type de retour attendu ;
 - n'effectue aucune conversion implicite pour rechercher un « meilleur » type ;
 - reste une commodité locale d'appel et ne déduit jamais l'identité d'un type nominal construit.
 Exemple interdit :
 ```text
 func create<T>() -> T;
 String value = create(); // ERROR
 ```
 Il faut écrire :
 ```text
 String value = create<String>();
 ```
 Exemple sans promotion implicite :
 ```text
 func same<T>(T a, T b) -> bool;
 int16 a = ...;
 int32 b = ...;
 same(a, b); // ERROR
 same<int32>(a::toInt32(), b); // OK
 ```
 ## 14.4 Contraintes nominales — V1 REQUIS — FIGÉ
 V1 utilise deux formes nominales de contraintes :
 ```text
 where T extends SomeClass
 where T implements SomeInterface
 ```
 Une ligne `where` porte une contrainte.
 Pour un même paramètre de type :
 - au maximum une contrainte `extends` ;
 - plusieurs contraintes `implements` sont autorisées ;
 - toutes les contraintes sont cumulatives.
 Exemple :
 ```text
 func process<T>(T value) -> Void
 where T extends Entity
 where T implements Serializable
 where T implements Comparable<T>
 {
    ...
 }
 ```
 L'ordre textuel des contraintes n'a pas de sémantique. Le formatter peut choisir un ordre canonique, notamment `extends` avant `implements`.
 ## 14.5 Contraintes dépendantes et récursives — V1 REQUIS — FIGÉ
 Un paramètre générique peut apparaître dans le contrat portant sur un autre paramètre :
 ```text
 func compare<A, B>(A left, B right) -> Ordering
 where A implements Comparable<B>
 {
    ...
 }
 ```
 Les contraintes F-bounded sont autorisées :
 ```text
 where T implements Comparable<T>
 ```
 La satisfaction des contraintes est statique et nominale. Il n'existe pas de duck typing.
 ## 14.6 `Numeric` et absence de catégories syntaxiques — V1 REQUIS — FIGÉ EN PRINCIPE
 V1 n'introduit pas de contraintes syntaxiques telles que :
 ```text
 where T is numeric
 where T is primitive
 where T is struct
 where T is class
 ```
 Lorsqu'une propriété correspond à une vraie abstraction réutilisable, elle doit être représentée par un contrat Core réel.
 Exemple :
 ```text
 where T implements Numeric
 ```
 `Numeric` est une abstraction Core nominale ; elle n'est pas un prédicat spécial du compilateur.
 Des contraintes intrinsèques peuvent exister dans certaines définitions compiler/Core-known sans devenir automatiquement de nouvelles constructions de la syntaxe utilisateur.
 ## 14.7 Contraintes redondantes et héritées — V1 REQUIS — FIGÉ
 Une contrainte nominalement redondante est interdite.
 Si :
 ```text
 interface B extends A {
 }
 ```
 alors :
 ```text
 where T implements B
 where T implements A
 ```
 est une erreur de déclaration redondante.
 Lorsqu'un type générique hérite d'un parent générique contraint, les contraintes nécessaires doivent être répétées explicitement dans le contrat du type enfant.
 ```text
 open class Base<T>
 where T implements Serializable
 {
 }
 class Child<T> extends Base<T>
 where T implements Serializable
 {
 }
 ```
 Le compilateur ne rend pas silencieusement le contrat local plus contraint en important des `where` invisibles depuis le parent.
 Lorsqu'un enfant ferme le paramètre sur un type concret, il suffit que ce type concret satisfasse les contraintes du parent.
 ## 14.8 Héritage et interfaces génériques — V1 REQUIS — FIGÉ
 Les arguments génériques d'un parent ou d'une interface sont toujours explicites :
 ```text
 class Box<T> implements Iterable<T> {
    ...
 }
 class StringList implements Iterable<String> {
    ...
 }
 class StringContainer extends Container<String> {
    ...
 }
 ```
 Une transformation finie des paramètres est autorisée lorsqu'elle ne constitue pas une récursivité générique interdite :
 ```text
 class PairBox<T> implements Container<Pair<T, T>> {
    ...
 }
 ```
 Après substitution, les règles normales de signature et de contrat s'appliquent.
 Une même interface générique peut être atteinte avec plusieurs spécialisations lorsque les contrats résultants sont compatibles.
 ```text
 Consumer<String>
 Consumer<Array<uint8>>
 ```
 peuvent par exemple produire deux signatures distinctes.
 Lorsque plusieurs chemins atteignent exactement la même spécialisation depuis la même origine, ils représentent une seule obligation :
 > même contrat provenant de la même origine = une seule obligation, pas de faux conflit.
 ## 14.9 Overrides génériques — V1 REQUIS — FIGÉ
 Une implémentation ou un override générique doit conserver une structure générique contractuellement équivalente :
 ```text
 même nombre de paramètres génériques
 même nature type/const de chaque paramètre
 mêmes relations de contraintes
 même contrat callable après substitution
 ```
 Les noms des paramètres génériques peuvent être alpha-renommés.
 Une implémentation ne peut pas ajouter une contrainte qui réduirait l'ensemble des appels autorisés par le contrat parent, ni supprimer une contrainte si cela modifie ce contrat.
 ## 14.10 Variance — V1 REQUIS — FIGÉ
 Tous les paramètres génériques sont invariants en V1.
 Même si :
 ```text
 Dog extends Animal
 ```
 cela n'implique pas :
 ```text
 Container<Dog> -> Container<Animal>
 ```
 V1 n'introduit pas :
 ```text
 in T
 out T
 +T
 -T
 wildcards Java
 ```
 La variance déclarative pourra être réévaluée après le self-hosting ou pour V3 uniquement si un besoin concret est démontré. Elle n'est pas réservée « au cas où ».
 ## 14.11 Spécialisation et stratégie d'implémentation — V1 REQUIS — FIGÉ
 V1 n'offre aucune spécialisation sémantique des generics.
 Une définition générique possède une seule sémantique visible.
 Le backend reste libre d'utiliser :
 ```text
 monomorphisation
 code partagé avec metadata
 stratégie hybride
 ```
 tant que le comportement observable Saselang reste identique.
 La stratégie peut varier entre LLVM, interpréteur, JVM, WASM ou futurs backends.
 ## 14.12 Const generics — V1 REQUIS — FIGÉ
 Syntaxe :
 ```text
 struct StaticArray<T, const uint64 N> {
    ...
 }
 struct Matrix<T, const uint64 Rows, const uint64 Columns> {
    ...
 }
 ```
 Les types admissibles d'un **paramètre const generic V1** sont uniquement :
 ```text
 bool
 char
 uint8
 uint16
 uint32
 uint64
 uint128
 uint256
 enum simple sans payload
 ```
 Les `int*` restent naturellement utilisables dans les expressions constantes générales du langage, mais ne sont pas nécessaires comme types de paramètres const generic V1.
 Ne sont notamment pas admis comme types de paramètres const generic V1 :
 ```text
 int8..int256
 float16..float128
 String
 class
 struct arbitraire
 tuple
 enum avec payload
 ```
 Cette liste pourra évoluer en V2/V3 uniquement à partir de besoins concrets.
 ## 14.13 Expressions d'arguments const generic — V1 REQUIS — FIGÉ
 Un argument const generic doit être entièrement déterminable à la compilation et produire exactement le type attendu après contextualisation normale des littéraux.
 Sont admissibles directement :
 ```text
 littéraux
 const nommées déjà résolues
 paramètres const generic
 parenthèses
 opérateurs primitifs purs autorisés sur ces valeurs
 ```
 Exemples :
 ```text
 StaticArray<uint8, 32>
 StaticArray<uint8, PAGE_SIZE>
 StaticArray<uint8, PAGE_SIZE * 2>
 StaticArray<uint8, 1u64 << 12>
 ```
 Aucun appel de callable n'est admis directement dans `<...>` :
 ```text
 StaticArray<uint8, computeSize()>      // ERROR
 StaticArray<uint8, value::toUint64()> // ERROR
 ```
 Sont également interdits directement dans l'argument const generic :
 ```text
 fonction
 méthode
 constructeur
 allocation
 I/O
 état runtime
 exception
 appel d'intrinsic exposé comme callable
 ```
 S'il faut calculer une valeur par un mécanisme plus élaboré, elle doit d'abord être matérialisée dans une `const` nommée d'un type admissible, selon les règles séparées d'initialisation compile-time :
 ```text
 const uint64 SIZE = ...;
 StaticArray<uint8, SIZE>
 ```
 La validité de l'expression qui initialise `SIZE` relève des règles des `const`, pas des const generics.
 Overflow, division par zéro, shift invalide ou autre faute statiquement prouvable restent des erreurs de compilation ordinaires. Aucun wrapping, saturation ou changement de règle n'est implicite dans un contexte const generic.
 ## 14.14 Identité et inférence des const generics — V1 REQUIS — FIGÉ
 L'identité d'une instanciation utilise la valeur constante résultante et son type, pas le texte source.
 Ainsi :
 ```text
 StaticArray<T, 2 + 2>
 StaticArray<T, 4>
 ```
 désignent la même instanciation lorsque le paramètre attendu est le même.
 L'inférence d'un const generic est uniquement **structurelle**.
 ```text
 func length<T, const uint64 N>(StaticArray<T, N> array) -> uint64
 ```
 peut inférer `T` et `N` depuis un argument `StaticArray<int32, 32>`.
 Le compilateur ne résout pas d'équation algébrique pour déduire un paramètre :
 ```text
 func strange<const uint64 N>(StaticArray<int32, N * 2> value)
 ```
 ne demande pas au compilateur de résoudre `N * 2 = 10`.
 ## 14.15 Contraintes de valeurs sur const generics — V1 REQUIS — FIGÉ
 V1 n'introduit pas :
 ```text
 where N > 0
 where N <= 1024
 ```
 `where` reste réservé aux relations nominales de types.
 Les contraintes de valeur nécessaires à un type Core/compiler-known sont vérifiées par le contrat de ce type sans créer en V1 un système général de preuve ou de contraintes arithmétiques.
 ## 14.16 Récursivité générique régulière — V1 REQUIS — FIGÉ
 Une déclaration générique peut se référencer récursivement avec exactement les mêmes arguments :
 ```text
 class Node<T> {
    Nullable<Node<T>> next;
 }
 ```
 ```text
 class BufferNode<T, const uint64 N> {
    Nullable<BufferNode<T, N>> next;
 }
 ```
 La récursivité reste naturellement soumise aux règles générales de layout : une récursivité by-value reste interdite.
 ## 14.17 Récursivité générique transformante — V1 REQUIS — FIGÉ
 Une auto-référence à la même déclaration générique avec des arguments transformés est interdite immédiatement en V1 :
 ```text
 class Node<T> {
    Nullable<Node<Array<T>>> next; // ERROR
 }
 ```
 ```text
 class BufferNode<T, const uint64 N> {
    Nullable<BufferNode<T, N + 1>> next; // ERROR
 }
 ```
 Pour les cycles indirects, le compilateur rejette le cycle lorsqu'une même déclaration générique est réatteinte avec des arguments différents.
 Valide :
 ```text
 class A<T> {
    Nullable<B<T>> b;
 }
 class B<T> {
    Nullable<A<T>> a;
 }
 ```
 Invalide :
 ```text
 class A<T> {
    Nullable<B<Array<T>>> b;
 }
 class B<T> {
    Nullable<A<T>> a;
 }
 ```
 V1 ne tente pas de prouver qu'une transformation particulière finirait éventuellement par se stabiliser.
 ## 14.18 Récursivité des callables génériques — V1 REQUIS — FIGÉ
 La récursivité normale des fonctions et méthodes est autorisée et le compilateur ne cherche pas à prouver leur terminaison générale.
 Une callable générique récursive doit cependant rappeler la même instanciation générique.
 ```text
 func recurse<T>(T value) -> Void {
    recurse<T>(value); // OK
 }
 ```
 La polymorphic recursion transformante est interdite en V1 :
 ```text
 func recurse<T>(T value) -> Void {
    recurse<Array<T>>(...); // ERROR
 }
 ```
 La même règle s'applique aux cycles mutuellement récursifs de callables génériques.
 ## 14.19 Parameter packs et mécanismes différés — V1 REQUIS — FIGÉ
 V1 n'introduit pas :
 ```text
 <T...>
 <const uint64... N>
 generic parameter packs
 wildcards
 specialization
 variance déclarative
 contraintes négatives
 ```
 Ces mécanismes ne sont pas réservés sans besoin démontré.
 ---
--- a/chapters/024-casts-et-conversions.md
+++ b/chapters/024-casts-et-conversions.md
@@ -87,31 +87,168 @@ Une forme n'existe que si elle apporte une sémantique observable différente d'
 Ainsi, lorsqu'un `toTarget()` exact et total existe, les variantes `tryToTarget()`, `saturateToTarget()` ou `wrapToTarget()` qui produiraient exactement le même résultat pour tout le domaine source sont absentes.
 Règle de composition : deux opérations Core ne sont fusionnées dans un même nom que si leur séparation en opérations successives modifierait la sémantique, perdrait de l'information ou empêcherait d'exprimer le même contrat.
 Lorsqu'une composition existante est strictement équivalente, aucun alias combiné n'est ajouté au Core.
 ## 24.6 `float -> integer` — V1 REQUIS — DIRECTION FIGÉE
 Un flottant ne possède jamais un simple `toIntXX()` ou `toUintXX()`.
-La politique de passage du réel à l'entier doit être explicite, par exemple :
+La conversion exacte stricte utilise :
 ```text
-tryExactToInt32()
+tryToIntXX()
-tryFloorToInt32()
+tryToUintXX()
 tryCeilToInt32()
 tryRoundToInt32()
 tryTruncateToInt32()
 ```
-Les variantes saturantes ou wrapping, lorsqu'elles sont retenues, doivent également annoncer explicitement la politique mathématique appliquée.
+Elle réussit uniquement si la valeur source est finie, mathématiquement entière et représentable exactement dans le type destination. Sinon elle retourne `Result::Err(NumericConversionError(...))`.
 Les politiques mathématiques de traitement de la partie fractionnaire restent des opérations Core séparées :
 ```text
 floor()
 ceil()
 round()
 truncate()
 ```
 Elles se composent avec la conversion :
 ```text
 value::floor()::tryToInt32()
 value::ceil()::tryToInt32()
 value::round()::tryToInt32()
 value::truncate()::tryToInt32()
 ```
 Saselang n'introduit donc pas les alias redondants `tryFloorToInt32()`, `tryCeilToInt32()`, `tryRoundToInt32()` ou `tryTruncateToInt32()` lorsque ces compositions possèdent exactement la même sémantique.
 Les politiques de dépassement de domaine suivent la même règle :
 ```text
 value::floor()::trySaturateToInt32()
 value::round()::tryWrapToInt32()
 ```
 `trySaturateToIntXX()` exige une valeur finie et mathématiquement entière, puis sature aux bornes du type destination. Les échecs qui ne relèvent pas de la plage, par exemple `NaN`, une infinité ou une valeur fractionnaire, restent des `NumericConversionError`.
 `tryWrapToIntXX()` exige également une valeur finie et mathématiquement entière, puis applique le wrapping entier modulo `2^N` défini par Saselang.
 Une méthode combinée reste admise lorsqu'une décomposition changerait le contrat ou perdrait l'information nécessaire. C'est notamment le cas de `saturatingRoundToFloat32()` pour certains narrowings flottants : un `roundToFloat32()` séparé pourrait échouer avant que la saturation ne puisse être appliquée.
 Aucun comportement de conversion ne dépend d'un profil, d'un linter ou d'un backend.
-## 24.7 `NumericConversionError` — V1 REQUIS — NOM DE TRAVAIL
+## 24.7 `float -> float`, valeurs IEEE spéciales — V1 REQUIS — FIGÉ
 Toute conversion de valeur flottante préserve les catégories sémantiques suivantes lorsque la destination est un type flottant Saselang :
 ```text
 NaN       -> NaN
 +Infinity -> +Infinity
 -Infinity -> -Infinity
 +0        -> +0
 -0        -> -0
 ```
 Pour `NaN`, la conversion garantit uniquement que la destination reste `NaN`.
 Elle ne garantit pas lors d'une conversion de valeur :
 ```text
 payload NaN
 quiet/signaling bit
 signe du NaN
 représentation binaire exacte
 ```
 Ces propriétés relèvent d'un éventuel contrat binaire distinct ; `bitcast<T>` ne peut les préserver que lorsque ses propres contraintes, notamment de taille, sont satisfaites.
 `tryToFloatXX()` traite `NaN` et les infinités comme des valeurs sémantiques représentables du type flottant destination. Le mot « exact » désigne ici l'exactitude de la valeur sémantique Saselang, pas l'identité bit-à-bit d'un payload NaN.
 Pour une valeur finie :
 ```text
 tryToFloatXX()
    exige une représentation exacte
 tryRoundToFloatXX()
    accepte l'arrondi canonique
    refuse une valeur finie hors domaine fini destination
 saturatingRoundToFloatXX()
    accepte l'arrondi canonique
    sature une valeur finie hors domaine vers +/-Target::Max
 ```
 Les infinités ne sont pas saturées puisqu'elles sont déjà des valeurs représentables du format flottant destination.
 ## 24.8 `NumericConversionError` — V1 REQUIS — NOM DE TRAVAIL / CODES FIGÉS
 `NumericConversionError` est retenu comme nom de travail du `ResultError` Core utilisé par les conversions numériques récupérables.
-Son nom définitif, ses codes et son état minimal pourront encore être ajustés lors de la finalisation du Core sans modifier les principes de conversion de ce chapitre.
+Les catégories sémantiques V1 sont :
-## 24.8 Matrice exhaustive — ANNEXE NORMATIVE EN COURS DE GEL
+```text
 NotFinite
 NotIntegral
 OutOfRange
 Inexact
 ```
 Sens :
 ```text
 NotFinite
    NaN ou +/-Infinity lorsqu'une valeur finie est requise
 NotIntegral
    float -> integer alors que la valeur n'est pas mathématiquement entière
 OutOfRange
    valeur mathématique hors du domaine de la destination
 Inexact
    valeur dans le domaine destination mais non représentable exactement
    alors que l'opération exige l'exactitude
 ```
 `NumericConversionError` reste volontairement généraliste et minimal. Il n'ajoute pas automatiquement :
 ```text
 sourceType
 targetType
 sourceValue
 timestamp
 backend
 roundingMode
 ```
 au-delà de l'état commun fourni par `ResultError`.
 Le nom concret et la représentation numérique interne des codes pourront encore être ajustés avant stabilisation publique, mais les catégories sémantiques ci-dessus font partie du contrat V1.
 ## 24.9 Réduction anti-doublon par paire — V1 REQUIS — FIGÉ
 La matrice examine chaque paire `Source -> Target` et n'expose que les opérations dont le comportement peut réellement être distingué sur le domaine source.
 Ainsi, pour une paire `float -> integer` dont toutes les valeurs finies mathématiquement entières sont déjà dans le domaine signé destination, `trySaturateToTarget()` et `tryWrapToTarget()` seraient des doublons de `tryToTarget()` et n'existent pas.
 Pour une destination non signée, les valeurs négatives suffisent généralement à rendre les politiques checked, saturating et wrapping distinctes.
 La matrice exhaustive en annexe est normative sur ce point.
 ## 24.10 Disponibilité Core et target — V1 REQUIS — FIGÉ EN PRINCIPE
 Les conversions fondamentales de la matrice sont des capacités Core obligatoires dès lors que les types source et destination sont supportés par le target.
 L'absence d'une instruction matérielle native ne justifie pas l'absence d'une conversion si une émulation logicielle conforme est raisonnablement possible.
 Un target réduit peut ne pas supporter un type fondamental donné. Dans ce cas l'indisponibilité porte sur le type/capacité fondamentale, pas sur une sélection arbitraire de ses méthodes de conversion.
 Voir également le chapitre 40.
 ## 24.11 Matrice exhaustive — ANNEXE NORMATIVE EN COURS DE GEL
 L'inventaire source → destination des opérations de conversion est maintenu séparément afin d'éviter les oublis, doublons et incohérences.
--- a/chapters/033-imports-et-resolution-des-noms.md
+++ b/chapters/033-imports-et-resolution-des-noms.md
@@ -2,7 +2,7 @@
 ## 33.1 Imports — V1 REQUIS — FIGÉ
-Imports file-level uniquement, après `namespace` lorsque celui-ci existe.
+Les imports sont file-level uniquement, après `namespace` lorsque celui-ci existe.
 Pas de wildcard `*`.
@@ -45,19 +45,99 @@ Les alias locaux doivent être uniques dans le fichier.
 Pas d'alias de module.
-## 33.3 Utilisation sans import — V1 REQUIS — FIGÉ
+## 33.3 Import explicite même dans le même namespace — V1 REQUIS — FIGÉ
-L'utilisation d'un chemin qualifié complet sans `import` est autorisée uniquement pour les symboles appartenant au **package courant**.
+Appartenir au même namespace ne rend pas automatiquement les symboles visibles entre fichiers.
 Avec :
 ```text
-saselang.compiler.lexer.Token
+src/foo/A.saseltype
-saselang.compiler.lexer::tokenize(...)
+src/foo/B.saseltype
 ```
-`.` qualifie le chemin ; `::` accède au symbole contenu.
+si `B.saseltype` utilise `A`, il doit contenir :
-Un symbole provenant d'une dépendance externe ne peut pas être référencé directement par un chemin complet dans une expression ou une déclaration. Il doit d'abord être importé explicitement avec une clause `from "vendor/package@requirement"`.
+```text
 import type foo.A;
 ```
-Cette règle évite d'introduire la syntaxe de coordonnées package (`/`, `@`, contraintes SemVer) dans la grammaire générale des expressions et garantit qu'un fichier énonce explicitement toutes ses provenances externes.
+même si les deux fichiers déclarent :
 ```text
 namespace foo;
 ```
 La même règle s'applique aux autres kinds importables.
 Un symbole top-level défini dans un autre fichier ne peut pas contourner cette règle en étant référencé directement par son chemin qualifié complet dans une expression ou une déclaration.
 Le chemin pleinement qualifié sert notamment à identifier le symbole dans la clause `import`, pas à créer une seconde forme d'utilisation sans import.
 Cette règle rend toutes les dépendances de fichier visibles localement et évite que la portée d'un namespace agisse comme un import implicite.
 ## 33.4 Dépendances externes — V1 REQUIS — FIGÉ EN PRINCIPE
 Un symbole provenant d'une dépendance externe doit être importé explicitement avec une clause `from "vendor/package@requirement"` selon la grammaire de package à finaliser.
 Les coordonnées de package (`/`, `@`, contrainte SemVer) restent confinées à la syntaxe d'import/dépendance et ne deviennent pas une syntaxe générale de qualification dans les expressions.
 ## 33.5 Imports déclaratifs et cycles — V1 REQUIS — FIGÉ
 Un `import` Saselang est une déclaration de résolution de symbole.
 Il ne signifie jamais :
 ```text
 charger le fichier immédiatement
 exécuter le fichier
 initialiser le fichier
 compiler ce fichier avant le fichier courant
 ```
 Les cycles d'import sont donc autorisés :
 ```text
 A imports B
 B imports A
 ```
 ou :
 ```text
 A imports B
 B imports C
 C imports A
 ```
 Un cycle d'import n'est pas en lui-même une erreur.
 Le compilateur doit ensuite analyser les graphes sémantiques réellement concernés.
 Exemples :
 ```text
 cycle de références de classes
    autorisé
 cycle d'appels
    autorisé
 cycle d'héritage
    ERROR
 cycle de layout by-value
    ERROR
 ```
 Le diagnostic doit identifier la violation réelle et ne pas utiliser un générique `circular import` lorsque les imports eux-mêmes sont valides.
 ## 33.6 Ordre de résolution — V1 REQUIS — FIGÉ EN PRINCIPE
 Les fichiers et imports organisent le source mais ne définissent pas un ordre sémantique de compilation.
 Le frontend collecte les déclarations nominales accessibles avant de finaliser les relations d'héritage, contrats, layouts et corps.
 Cela permet notamment à deux classes placées dans deux `.saseltype` distincts de se référencer mutuellement sans dépendre d'un ordre de chargement de fichiers.
 ---
--- a/chapters/040-targets-plateformes-architectures-abi-distributions-et-capabilities.md
+++ b/chapters/040-targets-plateformes-architectures-abi-distributions-et-capabilities.md
@@ -189,7 +189,76 @@ Le modèle doit aussi permettre de décrire les capacités atomiques pertinentes
 Une capability statique signifie que l'environnement fournit la capacité ; elle ne garantit pas qu'une opération runtime particulière réussira.
-## 40.9 Compatibilité target/dépendance — V1 REQUIS — FIGÉE EN PRINCIPE
+## 40.9 Propriétaires et identifiants de capabilities — V1 REQUIS — DIRECTION FIGÉE
 Les capabilities utilisent une nomenclature hiérarchique commune, ASCII, en minuscules, séparée par `.`.
 Le premier segment identifie le propriétaire sémantique :
 ```text
 language.*
 core.*
 target.*
 platform.*
 sdk.*
 ```
 Exemples conceptuels :
 ```text
 language.exceptions
 core.numeric.float128
 core.collections.array
 target.atomic.int64
 target.simd.float32
 platform.filesystem
 platform.network
 sdk.logging
 ```
 Cette organisation permet de regrouper les capacités par propriétaire et d'éviter un registre global plat.
 Les noms exacts et le registre exhaustif seront stabilisés avec le Core/SDK, mais un même concept ne doit pas recevoir des conventions concurrentes telles que `hasFloat128`, `supports_float128` et `numeric-f128`.
 Les packages utilisateurs ne doivent pas usurper les espaces de noms de capabilities réservés à la toolchain/Core/SDK.
 ## 40.10 Niveaux de capacité — V1 REQUIS — FIGÉ EN PRINCIPE
 Trois niveaux conceptuels sont distingués :
 ```text
 Language-required
    sémantique nécessaire à tout compilateur Saselang conforme
 Core-required-for-supported-type
    contrat Core obligatoire dès que le type/capacité fondamentale existe
    sur le target
 Core/target optional capability
    fonctionnalité réellement optionnelle ou spécifique d'un environnement
 ```
 Exemple : si un target supporte `float128`, les conversions Core fondamentales définies par la matrice numérique pour `float128` doivent être disponibles.
 Le target ne peut pas exposer `float128` tout en supprimant arbitrairement certaines conversions fondamentales simplement parce que le matériel n'offre pas une instruction native correspondante.
 ## 40.11 Émulation logicielle — V1 REQUIS — FIGÉ
 Lorsqu'une fonctionnalité fondamentale peut raisonnablement être émulée de façon conforme, l'absence d'un support matériel natif ne la rend pas indisponible.
 ```text
 instruction native disponible
    lowering/backend direct ou optimisé
 instruction native absente
    implémentation logicielle conforme
 ```
 La différence doit porter sur les performances, pas sur la sémantique visible.
 Un target réellement contraint peut ne pas fournir un type/capacité fondamentale entière. Dans ce cas, le diagnostic doit porter sur cette capacité ou ce type, plutôt que sur l'absence aléatoire d'une méthode secondaire.
 ## 40.12 Compatibilité target/dépendance — V1 REQUIS — FIGÉE EN PRINCIPE
 Un package ou une dépendance peut déclarer des contraintes de target/platform/ABI/capabilities.
--- a/chapters/048-inventaire-des-points-v1-encore-ouverts.md
+++ b/chapters/048-inventaire-des-points-v1-encore-ouverts.md
@@ -13,21 +13,18 @@ Restent à fermer :
 - matrice finale des préfixes de littéraux combinables (`i`, `r`, `b`, `c`, `u8/u16/u32`, `t`, etc.) et leur disponibilité V1/V2 ;
 - limite normative éventuelle du nombre de `#` des raw strings ;
 - grammaire syntaxique complète au-delà des blocs/statements déjà figés ;
 - syntaxe exacte des generics et contraintes ;
 - syntaxe exacte des annotations/métadonnées de code lorsqu'elles seront retenues.
 ## 48.2 Types
 - domaine exact des types admissibles à `Nullable<T>` avec le modèle mémoire/FFI ;
- finalisation de la matrice exhaustive des conversions numériques Core et de ses noms composés ;
+- audit mécanique final de la surface Core des conversions numériques à partir de la matrice désormais largement figée ;
- règles de sous-typage interface/class ;
+- règles de sous-typage interface/class au-delà des règles génériques déjà fixées ;
 - generics complets ;
 - const generics ;
 - callable/function types ;
 - lambdas/closures ;
 - variadiques (un seul variadique prévu) ;
 - String/index Unicode ;
- exact float semantics.
+- exact float semantics hors conversions déjà figées (opérations arithmétiques IEEE restantes, `%`, division par zéro, etc.).
 ## 48.3 Mémoire
--- a/chapters/049-elements-v1-reserves-mais-non-obligatoires-a-implementer-immediatement.md
+++ b/chapters/049-elements-v1-reserves-mais-non-obligatoires-a-implementer-immediatement.md
@@ -17,4 +17,8 @@ noms nécessaires pour éviter collisions futures
 Un élément réservé ne doit pas être réutilisé pour une fonctionnalité incompatible.
 Une réservation doit correspondre à un besoin déjà identifié ou à une compatibilité future concrètement anticipée. Saselang ne réserve pas de syntaxe, de types ou de mécanismes purement spéculatifs « au cas où ».
 V1 et V2 servent de bases/POC permettant encore de corriger les choix du langage avant la baseline publique V3.
 ---
--- a/chapters/051-invariants-de-conception.md
+++ b/chapters/051-invariants-de-conception.md
@@ -19,5 +19,9 @@ Les futures décisions doivent respecter les invariants suivants :
 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.**
 17. **Le modèle mémoire V1 doit fournir performances, sûreté et destruction déterministe sans imposer des lifetimes explicites partout.**
 18. **L'ordre des fichiers et des imports n'est pas un ordre d'exécution ou de résolution sémantique.**
 19. **Un cycle n'est interdit que par la règle du graphe concerné : héritage et layout by-value doivent être acycliques ; références de classes, imports et appels peuvent être cycliques.**
 20. **Une fonctionnalité n'est réservée que lorsqu'un besoin réel est identifié ; pas de réservation spéculative « au cas où ».**
 21. **Une opération Core combinée n'existe pas lorsqu'une composition d'opérations existantes exprime strictement la même sémantique.**
 ---
--- a/chapters/052-priorite-de-specification-apres-0-2-9.md
+++ b/chapters/052-priorite-de-specification-apres-0-2-9.md
@@ -1,23 +1,27 @@
-# 52. Priorité de spécification après 0.2.12
+# 52. Priorité de spécification après 0.2.14
-Pour transformer cette Bible en spécification V1 directement implémentable, l'ordre recommandé est :
+Pour transformer cette Bible en spécification V1 directement implémentable, l'ordre recommandé devient :
 ```text
-1. terminer casts/conversions numériques + matrice Core
+1. String/Unicode + collections + Range
-2. generics + contraintes + const generics
+2. lambdas/closures + callable model
-3. String/Unicode + collections + Range
+3. async/concurrency décision V1
-4. lambdas/closures + callable model
+4. modèle mémoire + allocator + pointers + unsafe
-5. async/concurrency décision V1
+5. fautes runtime + construction/destruction cleanup
-6. modèle mémoire + allocator + pointers + unsafe
+6. Core V1 exact : Numeric, collections, erreurs, TypeInfo et autres contrats
-7. fautes runtime + construction/destruction cleanup
+7. capacités target et registre canonique des capability identifiers
-8. Core V1 exact et capacités target
+8. SDK V1 initial et frontières Core/SDK
-9. SDK V1 initial et frontières Core/SDK
+9. FFI C exacte
-10. FFI C exacte
+10. reflection/metadata/tests/tooling
-11. reflection/metadata/tests/tooling
+11. grammaire syntaxique complète et audit lexical final
-12. grammaire syntaxique complète et audit lexical final
+12. audit mécanique des generics/const generics/récursivité et conversions
 13. audit complet de toutes les sections V1 REQUIS — À FINALISER
 14. consolidation examples / DO-DON'T / conformance tests
 15. plan d'implémentation du compilateur/interpréteur V1
 ```
 Les generics, const generics, règles principales de récursivité, casts/conversions et matrice numérique sont désormais suffisamment fermés pour quitter leur phase de conception principale. Ils devront naturellement être réaudités pendant l'implémentation et la préparation de la baseline publique V3.
 La Bible ne doit être déclarée « V1 specification complete » qu'après fermeture de tous les points V1 REQUIS — À FINALISER qui affectent la grammaire ou la sémantique observable.
 ---
--- a/examples/001-trajectoire-dimplementation-examples.md
+++ b/examples/001-trajectoire-dimplementation-examples.md
@@ -1,8 +1,8 @@
 # Exemples / DO-DON'T — Chapitre 1 — Trajectoire d'implémentation
-> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
+> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
-## Exemples actuellement présents dans le chapitre
+## Exemples extraits du chapitre
 ### Exemple 1
@@ -15,7 +15,7 @@ analyse sémantique
 HIR
 Sase IR
 interpréteur
-a backend LLVM
+backend LLVM
 Core V1
 SDK initial
 manifests et workspaces
@@ -44,6 +44,17 @@ Core/SDK lorsque pertinent
 ### Exemple 4
 ```text
 source
 Core
 tooling
 packages
 artifacts
 et, lorsque défini, ABI/binaire
 ```
 ### Exemple 5
 ```text
 browser runtime / extension
 browser chunks/bundling
@@ -60,4 +71,4 @@ cibles spécialisées
 ## DO / DON'T / WHY / compiler error / edge cases
-La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
+À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
--- a/examples/005-types-primitifs-examples.md
+++ b/examples/005-types-primitifs-examples.md
@@ -1,8 +1,8 @@
 # Exemples / DO-DON'T — Chapitre 5 — Types primitifs
-> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
+> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
-## Exemples actuellement présents dans le chapitre
+## Exemples extraits du chapitre
 ### Exemple 1
@@ -144,6 +144,12 @@ f16 f32 f64 f128
 bitcast<float16>(value)
 ```
 ### Exemple 18
 ```text
 where T implements Numeric
 ```
 ## DO / DON'T / WHY / compiler error / edge cases
-La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
+À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
--- a/examples/007-types-nominaux-et-fichiers-saseltype-examples.md
+++ b/examples/007-types-nominaux-et-fichiers-saseltype-examples.md
@@ -1,8 +1,8 @@
 # Exemples / DO-DON'T — Chapitre 7 — Types nominaux et fichiers `.saseltype`
-> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
+> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
-## Exemples actuellement présents dans le chapitre
+## Exemples extraits du chapitre
 ### Exemple 1
@@ -14,6 +14,87 @@ enum
 union
 ```
 ### Exemple 2
 ```text
 class Foo;
 struct Bar;
 ```
 ### Exemple 3
 ```text
 nominalement connu
    identité du type, kind et paramètres génériques connus
 sémantiquement complet
    déclaration, héritage, interfaces et contrats résolus
 layout-complet
    représentation by-value, taille et alignement calculables lorsque nécessaires
 ```
 ### Exemple 4
 ```text
 struct A {
    A value;
 }
 ```
 ### Exemple 5
 ```text
 struct A {
    B b;
 }
 struct B {
    A a;
 }
 ```
 ### Exemple 6
 ```text
 struct A {
    StaticArray<A, 0> values;
 }
 ```
 ### Exemple 7
 ```text
 class A {
    B b;
 }
 class B {
    A a;
 }
 ```
 ### Exemple 8
 ```text
 class A extends B
 class B extends A
 ```
 ### Exemple 9
 ```text
 interface A extends B
 interface B extends A
 ```
 ### Exemple 10
 ```text
 cyclic inheritance
 recursive by-value layout
 ```
 ## DO / DON'T / WHY / compiler error / edge cases
-La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
+À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
--- a/examples/014-generics-examples.md
+++ b/examples/014-generics-examples.md
@@ -1,8 +1,8 @@
 # Exemples / DO-DON'T — Chapitre 14 — Generics
-> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
+> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
-## Exemples actuellement présents dans le chapitre
+## Exemples extraits du chapitre
 ### Exemple 1
@@ -15,18 +15,424 @@ OpAdd<Lhs,Rhs,Out>
 ### Exemple 2
 ```text
-syntaxe des contraintes
+class Box<T> {
-variance ou absence de variance
+    ...
-contraintes multiples
+}
-specialization éventuelle
+
-monomorphisation vs représentation partagée
+struct Pair<A, B> {
-contraintes sur types primitifs
+    ...
-const generics pour StaticArray<T,N>
+}
-generic methods
+
-inférence éventuelle des arguments génériques à l'appel
+interface Comparable<T> {
-wildcards/existentials éventuels
+    ...
 }
 func identity<T>(T value) -> T {
    return value;
 }
 ```
 ### Exemple 3
 ```text
 Box<int32>
 Pair<String, uint64>
 Result<Data, ParseError>
 ```
 ### Exemple 4
 ```text
 Box
 Result
 ```
 ### Exemple 5
 ```text
 Box<int32> box = Box<int32>(42);
 ```
 ### Exemple 6
 ```text
 func first<T>(T left, T right) -> T;
 int32 a = ...;
 int32 b = ...;
 int32 c = first(a, b);
 ```
 ### Exemple 7
 ```text
 func create<T>() -> T;
 String value = create(); // ERROR
 ```
 ### Exemple 8
 ```text
 String value = create<String>();
 ```
 ### Exemple 9
 ```text
 func same<T>(T a, T b) -> bool;
 int16 a = ...;
 int32 b = ...;
 same(a, b); // ERROR
 same<int32>(a::toInt32(), b); // OK
 ```
 ### Exemple 10
 ```text
 where T extends SomeClass
 where T implements SomeInterface
 ```
 ### Exemple 11
 ```text
 func process<T>(T value) -> Void
 where T extends Entity
 where T implements Serializable
 where T implements Comparable<T>
 {
    ...
 }
 ```
 ### Exemple 12
 ```text
 func compare<A, B>(A left, B right) -> Ordering
 where A implements Comparable<B>
 {
    ...
 }
 ```
 ### Exemple 13
 ```text
 where T implements Comparable<T>
 ```
 ### Exemple 14
 ```text
 where T is numeric
 where T is primitive
 where T is struct
 where T is class
 ```
 ### Exemple 15
 ```text
 where T implements Numeric
 ```
 ### Exemple 16
 ```text
 interface B extends A {
 }
 ```
 ### Exemple 17
 ```text
 where T implements B
 where T implements A
 ```
 ### Exemple 18
 ```text
 open class Base<T>
 where T implements Serializable
 {
 }
 class Child<T> extends Base<T>
 where T implements Serializable
 {
 }
 ```
 ### Exemple 19
 ```text
 class Box<T> implements Iterable<T> {
    ...
 }
 class StringList implements Iterable<String> {
    ...
 }
 class StringContainer extends Container<String> {
    ...
 }
 ```
 ### Exemple 20
 ```text
 class PairBox<T> implements Container<Pair<T, T>> {
    ...
 }
 ```
 ### Exemple 21
 ```text
 Consumer<String>
 Consumer<Array<uint8>>
 ```
 ### Exemple 22
 ```text
 même nombre de paramètres génériques
 même nature type/const de chaque paramètre
 mêmes relations de contraintes
 même contrat callable après substitution
 ```
 ### Exemple 23
 ```text
 Dog extends Animal
 ```
 ### Exemple 24
 ```text
 Container<Dog> -> Container<Animal>
 ```
 ### Exemple 25
 ```text
 in T
 out T
 +T
 -T
 wildcards Java
 ```
 ### Exemple 26
 ```text
 monomorphisation
 code partagé avec metadata
 stratégie hybride
 ```
 ### Exemple 27
 ```text
 struct StaticArray<T, const uint64 N> {
    ...
 }
 struct Matrix<T, const uint64 Rows, const uint64 Columns> {
    ...
 }
 ```
 ### Exemple 28
 ```text
 bool
 char
 uint8
 uint16
 uint32
 uint64
 uint128
 uint256
 enum simple sans payload
 ```
 ### Exemple 29
 ```text
 int8..int256
 float16..float128
 String
 class
 struct arbitraire
 tuple
 enum avec payload
 ```
 ### Exemple 30
 ```text
 littéraux
 const nommées déjà résolues
 paramètres const generic
 parenthèses
 opérateurs primitifs purs autorisés sur ces valeurs
 ```
 ### Exemple 31
 ```text
 StaticArray<uint8, 32>
 StaticArray<uint8, PAGE_SIZE>
 StaticArray<uint8, PAGE_SIZE * 2>
 StaticArray<uint8, 1u64 << 12>
 ```
 ### Exemple 32
 ```text
 StaticArray<uint8, computeSize()>      // ERROR
 StaticArray<uint8, value::toUint64()> // ERROR
 ```
 ### Exemple 33
 ```text
 fonction
 méthode
 constructeur
 allocation
 I/O
 état runtime
 exception
 appel d'intrinsic exposé comme callable
 ```
 ### Exemple 34
 ```text
 const uint64 SIZE = ...;
 StaticArray<uint8, SIZE>
 ```
 ### Exemple 35
 ```text
 StaticArray<T, 2 + 2>
 StaticArray<T, 4>
 ```
 ### Exemple 36
 ```text
 func length<T, const uint64 N>(StaticArray<T, N> array) -> uint64
 ```
 ### Exemple 37
 ```text
 func strange<const uint64 N>(StaticArray<int32, N * 2> value)
 ```
 ### Exemple 38
 ```text
 where N > 0
 where N <= 1024
 ```
 ### Exemple 39
 ```text
 class Node<T> {
    Nullable<Node<T>> next;
 }
 ```
 ### Exemple 40
 ```text
 class BufferNode<T, const uint64 N> {
    Nullable<BufferNode<T, N>> next;
 }
 ```
 ### Exemple 41
 ```text
 class Node<T> {
    Nullable<Node<Array<T>>> next; // ERROR
 }
 ```
 ### Exemple 42
 ```text
 class BufferNode<T, const uint64 N> {
    Nullable<BufferNode<T, N + 1>> next; // ERROR
 }
 ```
 ### Exemple 43
 ```text
 class A<T> {
    Nullable<B<T>> b;
 }
 class B<T> {
    Nullable<A<T>> a;
 }
 ```
 ### Exemple 44
 ```text
 class A<T> {
    Nullable<B<Array<T>>> b;
 }
 class B<T> {
    Nullable<A<T>> a;
 }
 ```
 ### Exemple 45
 ```text
 func recurse<T>(T value) -> Void {
    recurse<T>(value); // OK
 }
 ```
 ### Exemple 46
 ```text
 func recurse<T>(T value) -> Void {
    recurse<Array<T>>(...); // ERROR
 }
 ```
 ### Exemple 47
 ```text
 <T...>
 <const uint64... N>
 generic parameter packs
 wildcards
 specialization
 variance déclarative
 contraintes négatives
 ```
 ## DO / DON'T / WHY / compiler error / edge cases
-La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
+À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
--- a/examples/024-casts-et-conversions-examples.md
+++ b/examples/024-casts-et-conversions-examples.md
@@ -1,8 +1,8 @@
 # Exemples / DO-DON'T — Chapitre 24 — Casts et conversions
-> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
+> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
-## Exemples actuellement présents dans le chapitre
+## Exemples extraits du chapitre
 ### Exemple 1
@@ -66,19 +66,112 @@ wrapToTarget()
 ### Exemple 6
 ```text
-tryExactToInt32()
+tryToIntXX()
-tryFloorToInt32()
+tryToUintXX()
 tryCeilToInt32()
 tryRoundToInt32()
 tryTruncateToInt32()
 ```
 ### Exemple 7
 ```text
 floor()
 ceil()
 round()
 truncate()
 ```
 ### Exemple 8
 ```text
 value::floor()::tryToInt32()
 value::ceil()::tryToInt32()
 value::round()::tryToInt32()
 value::truncate()::tryToInt32()
 ```
 ### Exemple 9
 ```text
 value::floor()::trySaturateToInt32()
 value::round()::tryWrapToInt32()
 ```
 ### Exemple 10
 ```text
 NaN       -> NaN
 +Infinity -> +Infinity
 -Infinity -> -Infinity
 +0        -> +0
 -0        -> -0
 ```
 ### Exemple 11
 ```text
 payload NaN
 quiet/signaling bit
 signe du NaN
 représentation binaire exacte
 ```
 ### Exemple 12
 ```text
 tryToFloatXX()
    exige une représentation exacte
 tryRoundToFloatXX()
    accepte l'arrondi canonique
    refuse une valeur finie hors domaine fini destination
 saturatingRoundToFloatXX()
    accepte l'arrondi canonique
    sature une valeur finie hors domaine vers +/-Target::Max
 ```
 ### Exemple 13
 ```text
 NotFinite
 NotIntegral
 OutOfRange
 Inexact
 ```
 ### Exemple 14
 ```text
 NotFinite
    NaN ou +/-Infinity lorsqu'une valeur finie est requise
 NotIntegral
    float -> integer alors que la valeur n'est pas mathématiquement entière
 OutOfRange
    valeur mathématique hors du domaine de la destination
 Inexact
    valeur dans le domaine destination mais non représentable exactement
    alors que l'opération exige l'exactitude
 ```
 ### Exemple 15
 ```text
 sourceType
 targetType
 sourceValue
 timestamp
 backend
 roundingMode
 ```
 ### Exemple 16
 ```text
 annexes/A-numeric-conversions.md
 ```
 ## DO / DON'T / WHY / compiler error / edge cases
-La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
+À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
--- a/examples/033-imports-et-resolution-des-noms-examples.md
+++ b/examples/033-imports-et-resolution-des-noms-examples.md
@@ -1,8 +1,8 @@
 # Exemples / DO-DON'T — Chapitre 33 — Imports et résolution des noms
-> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
+> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
-## Exemples actuellement présents dans le chapitre
+## Exemples extraits du chapitre
 ### Exemple 1
@@ -38,10 +38,62 @@ import type foo.Token as FooToken;
 ### Exemple 5
 ```text
-saselang.compiler.lexer.Token
+src/foo/A.saseltype
-saselang.compiler.lexer::tokenize(...)
+src/foo/B.saseltype
 ```
 ### Exemple 6
 ```text
 import type foo.A;
 ```
 ### Exemple 7
 ```text
 namespace foo;
 ```
 ### Exemple 8
 ```text
 charger le fichier immédiatement
 exécuter le fichier
 initialiser le fichier
 compiler ce fichier avant le fichier courant
 ```
 ### Exemple 9
 ```text
 A imports B
 B imports A
 ```
 ### Exemple 10
 ```text
 A imports B
 B imports C
 C imports A
 ```
 ### Exemple 11
 ```text
 cycle de références de classes
    autorisé
 cycle d'appels
    autorisé
 cycle d'héritage
    ERROR
 cycle de layout by-value
    ERROR
 ```
 ## DO / DON'T / WHY / compiler error / edge cases
-La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
+À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
--- a/examples/040-targets-plateformes-architectures-abi-distributions-et-capabilities-examples.md
+++ b/examples/040-targets-plateformes-architectures-abi-distributions-et-capabilities-examples.md
@@ -1,8 +1,8 @@
 # Exemples / DO-DON'T — Chapitre 40 — Targets, plateformes, architectures, ABI, distributions et capabilities
-> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
+> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
-## Exemples actuellement présents dans le chapitre
+## Exemples extraits du chapitre
 ### Exemple 1
@@ -143,6 +143,53 @@ StandardError
 ### Exemple 13
 ```text
 language.*
 core.*
 target.*
 platform.*
 sdk.*
 ```
 ### Exemple 14
 ```text
 language.exceptions
 core.numeric.float128
 core.collections.array
 target.atomic.int64
 target.simd.float32
 platform.filesystem
 platform.network
 sdk.logging
 ```
 ### Exemple 15
 ```text
 Language-required
    sémantique nécessaire à tout compilateur Saselang conforme
 Core-required-for-supported-type
    contrat Core obligatoire dès que le type/capacité fondamentale existe
    sur le target
 Core/target optional capability
    fonctionnalité réellement optionnelle ou spécifique d'un environnement
 ```
 ### Exemple 16
 ```text
 instruction native disponible
    lowering/backend direct ou optimisé
 instruction native absente
    implémentation logicielle conforme
 ```
 ### Exemple 17
 ```text
 TargetFamily
 Platform
@@ -153,4 +200,4 @@ Distribution
 ## DO / DON'T / WHY / compiler error / edge cases
-La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
+À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
--- a/examples/048-inventaire-des-points-v1-encore-ouverts-examples.md
+++ b/examples/048-inventaire-des-points-v1-encore-ouverts-examples.md
@@ -1,11 +1,11 @@
 # Exemples / DO-DON'T — Chapitre 48 — Inventaire des points V1 encore OUVERTS
-> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
+> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
-## Exemples actuellement présents dans le chapitre
+## Exemples extraits du chapitre
-Aucun bloc d'exemple explicite n'est encore présent dans ce chapitre.
+Aucun bloc d'exemple explicite dans cette révision.
 ## DO / DON'T / WHY / compiler error / edge cases
-La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
+À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
--- a/examples/049-elements-v1-reserves-mais-non-obligatoires-a-implementer-immediatement-examples.md
+++ b/examples/049-elements-v1-reserves-mais-non-obligatoires-a-implementer-immediatement-examples.md
@@ -1,8 +1,8 @@
 # Exemples / DO-DON'T — Chapitre 49 — Éléments V1 RÉSERVÉS mais non obligatoires à implémenter immédiatement
-> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
+> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
-## Exemples actuellement présents dans le chapitre
+## Exemples extraits du chapitre
 ### Exemple 1
@@ -23,4 +23,4 @@ noms nécessaires pour éviter collisions futures
 ## DO / DON'T / WHY / compiler error / edge cases
-La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
+À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
--- a/examples/051-invariants-de-conception-examples.md
+++ b/examples/051-invariants-de-conception-examples.md
@@ -1,11 +1,11 @@
 # Exemples / DO-DON'T — Chapitre 51 — Invariants de conception
-> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
+> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
-## Exemples actuellement présents dans le chapitre
+## Exemples extraits du chapitre
-Aucun bloc d'exemple explicite n'est encore présent dans ce chapitre.
+Aucun bloc d'exemple explicite dans cette révision.
 ## DO / DON'T / WHY / compiler error / edge cases
-La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
+À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
--- a/examples/052-priorite-de-specification-apres-0-2-9-examples.md
+++ b/examples/052-priorite-de-specification-apres-0-2-9-examples.md
@@ -1,24 +1,24 @@
-# Exemples / DO-DON'T — Chapitre 52 — Priorité de spécification après 0.2.9
+# Exemples / DO-DON'T — Chapitre 52 — Priorité de spécification après 0.2.14
-> Document compagnon non normatif tant qu'une règle n'est pas explicitement référencée comme normative par le chapitre.
+> Document compagnon. Les exemples illustrent les règles du chapitre ; la formulation normative reste dans le chapitre lui-même.
-## Exemples actuellement présents dans le chapitre
+## Exemples extraits du chapitre
 ### Exemple 1
 ```text
-1. terminer casts/conversions numériques + matrice Core
+1. String/Unicode + collections + Range
-2. generics + contraintes + const generics
+2. lambdas/closures + callable model
-3. String/Unicode + collections + Range
+3. async/concurrency décision V1
-4. lambdas/closures + callable model
+4. modèle mémoire + allocator + pointers + unsafe
-5. async/concurrency décision V1
+5. fautes runtime + construction/destruction cleanup
-6. modèle mémoire + allocator + pointers + unsafe
+6. Core V1 exact : Numeric, collections, erreurs, TypeInfo et autres contrats
-7. fautes runtime + construction/destruction cleanup
+7. capacités target et registre canonique des capability identifiers
-8. Core V1 exact et capacités target
+8. SDK V1 initial et frontières Core/SDK
-9. SDK V1 initial et frontières Core/SDK
+9. FFI C exacte
-10. FFI C exacte
+10. reflection/metadata/tests/tooling
-11. reflection/metadata/tests/tooling
+11. grammaire syntaxique complète et audit lexical final
-12. grammaire syntaxique complète et audit lexical final
+12. audit mécanique des generics/const generics/récursivité et conversions
 13. audit complet de toutes les sections V1 REQUIS — À FINALISER
 14. consolidation examples / DO-DON'T / conformance tests
 15. plan d'implémentation du compilateur/interpréteur V1
@@ -26,4 +26,4 @@
 ## DO / DON'T / WHY / compiler error / edge cases
-La couverture structurée de cette section sera enrichie au fur et à mesure de la fermeture des règles du chapitre. La migration `0.2.12` conserve volontairement les exemples historiques dans le chapitre afin de ne perdre aucun contexte normatif.
+À consolider progressivement avant la baseline publique V3 et à transformer, lorsque pertinent, en tests de conformité de la toolchain.
`@@ -1,4 +1,4 @@`
	`# Sommaire — Bible Saselang 0.2.12`	`# Sommaire — Bible Saselang 0.2.14`

	`## Chapitres`	`## Chapitres`