Keep purchased aptitudes permanent and integrate Pause in beta.237

Require a site-issued SANC code when the server has app URL and API token configured, with replay-safe ledger binding and FR/EN UI including galactic code display.

Co-authored-by: Cursor <cursoragent@cursor.com>

AGENTS.md

@@ -11,6 +11,7 @@ La vision est dans `docs/vision.md` ; elle décrit aussi des fonctionnalités fu
 - Ne pas modifier un monde existant, régénérer des chunks, changer un format de sauvegarde ou activer une expansion sans contrat de migration explicite.
 - Garder les identifiants `sanctuary:*` stables et documenter toute évolution de la génération avec graine et version.
 - Ajouter les libellés FR/EN des nouvelles interfaces. Vérifier les dépendances pour la version Minecraft exacte ; aucune compatibilité supposée à partir du nom d'un mod.
+- Les tests graphiques Sanctuary ciblent uniquement Vulkan. OpenGL est abandonné comme cible de validation depuis le 18 septembre 2026 : ne plus lancer de suite OpenGL ni revendiquer sa prise en charge à partir des essais historiques.
 - Lancer `./gradlew check build` pour livrer du code, et `./gradlew assemblePack` si la distribution change. Ajouter seulement les tests utiles au comportement touché.
 - Pour chaque nouvelle livraison du mod, incrémenter le compteur `beta.xxx` (départ `beta.001`) dans `mod_version` et `pack_version` de `gradle.properties`, synchroniser `packwiz/pack.toml` et documenter le changement. Le tag reprend cette version exacte, sans préfixe `v` ; voir `docs/versioning.md`. Une simple modification documentaire n'incrémente pas les binaires.
 - Le pack Beta suit un canal packwiz stable et une seule instance Prism. Pour une mise à jour demandée, suivre `docs/packwiz.md` : publier un artefact vérifié et immuable, avancer le canal, puis synchroniser l'instance existante en conservant ses sauvegardes et réglages.

CHANGELOG.md

@@ -1,5 +1,239 @@
+# beta.172 — cartes de horde utilisables en jeu
+
+- Suppression de la restriction au cercle laboratoire : une carte peut ouvrir
+  une invasion à la position du joueur dans tout monde chargé.
+- Activation autorisée en Survie et en Créatif, avec consommation serveur et
+  synchronisation immédiate de l'inventaire dans les deux modes.
+- Les joueurs créatifs restent participants aux invasions de carte ; le socle
+  historique conserve ses anciennes règles d'inscription.
+- Les apparitions cherchent un sol sûr jusqu'à six blocs au-dessus ou en dessous
+  du point prévu, sans écrire de bloc ni charger de chunk supplémentaire.
+- [Contrat et vérifications](docs/horde-runtime-beta172.md).
+
+# beta.171 — familles de hordes dimensionnelles
+
+- Chaque carte possède une famille majoritaire stable : zombies, squelettes,
+  creepers, arthropodes, pillards, cauchemars, infernaux, piglins, flétris ou End.
+- La dimension de découverte favorise ses familles et espèces ; des créatures
+  locales aléatoires et de rares intrus interdimensionnels cassent la régularité.
+- Catalogue porté à 34 monstres terrestres ou volants, du zombie au blaze, au
+  ghast et au shulker ; les boss et créatures strictement aquatiques sont exclus.
+- Illustration divisée : file exacte des apparitions en haut, toutes les piles
+  de butin garanties en bas, avec chevauchement lorsque nécessaire.
+- Le vieux socle rejoint la carte native dans le langage de particules et
+  n'émet plus de messages Horde dans le chat ou la barre d'action.
+- [Contrat et vérifications](docs/horde-families-beta171.md).
+
+# beta.170 — carte de horde native et langage visuel
+
+- Nouvel objet `sanctuary:horde_trial_card` fondé sur la carte native 26.3,
+  visible dans l'onglet créatif Outils et utilitaires.
+- Chaque exemplaire vierge tenu en main découvre une identité unique et stable ;
+  les copies d'une carte découverte gardent son identité.
+- Révélation, activation, progression, refus et fin d'invasion passent par des
+  connexions et glyphes de particules, sans message Sanctuary dans le chat.
+- Compatibilité conservée avec les cartes remplies beta.168/beta.169.
+- [Contrat et vérifications](docs/horde-map-native-beta170.md).
+
+# beta.169 — invasion continue des cartes de horde
+
+- Les cartes sont inconnues avant leur prise en main et se révèlent durablement.
+- Remplace les trois vagues par 12, 18 ou 27 arrivées individuelles qui accélèrent.
+- Mélange jusqu’à dix espèces selon la difficulté ; dessin et butins suivent le roster réel.
+- Butins généreux propres aux monstres, rubis et saphirs inclus ; anciennes cartes préservées.
+- Runes SGA natives, combat spontané élargi et interruptions diagnostiquées.
+- [Contrat et vérifications](docs/horde-invasion-beta169.md).
+
+# beta.168 — cartes de horde (prototype local)
+
+- Trois cartes natives illustrées et consommables ; invocation immédiate sans socle.
+- Participation spontanée et butins physiques sur les zombies, ramassage libre.
+- Nouveau labo isolé beta.168 ; cercle beta.167 conservé pour les futurs donjons.
+- [Contrat et vérifications](docs/horde-cartes-beta168.md).
+
 # Changelog
 
+## beta.167 — Carte de horde et socle d'épreuve, prototype local
+
+- Arène circulaire dans un nouveau laboratoire, scène préservée aux redémarrages.
+- Carte réutilisable, inscriptions de 1 à 4 joueurs, préparation et lancement
+  explicites, trois vagues de zombies et résultat commun.
+- Nettoyage des monstres à l'interruption et reprise du labo au repos ; aucune
+  récompense économique, aucun changement de monde Sanctuary existant.
+- [Contrat et vérifications](docs/horde-lab-beta167.md).
+
+## beta.144 — Code d’accès à la création
+
+- Hello World demande le code `SANC-XXXX-XXXX` quand le serveur a l’URL et le jeton du site.
+- Le client ne contacte pas le site. Le serveur vérifie, puis consomme le code au moment de créer l’habitant.
+- Le lien Discord est enregistré à part. Une création interrompue après `redeemed` peut se terminer sans nouveau code si le compte est encore connu.
+- [Contrat](docs/access-code-beta144.md).
+
+## beta.110 — Atelier d’argile inclus
+
+- Une seule livraison réunit l’atelier d’argile, les statuaires et l’import GLB de beta.106 avec les œufs et la neige saisonnière de beta.107 à beta.109.
+- Fonctionnement, identifiants et formats conservés ; accumulation toujours plafonnée à deux blocs par défaut.
+- [Contrat et vérifications](docs/clay-workshop-integration-beta110.md).
+
+## beta.109 — Fonte saisonnière
+
+- Fonte par couches des dépôts météo suivis, de haut en bas, plus rapide en été.
+- Arrêt en hiver, dans les biomes froids, sous un profil neigeux ou en mode météo Vanilla.
+- Constructions et neige antérieure préservées ; suivi sauvegardé par chunk, retiré lors des modifications manuelles.
+- Gamerule `sanctuary:seasonal_snow_melt` active par défaut ; accumulation toujours limitée à deux blocs par défaut.
+- [Contrat et essais](docs/seasonal-snow-melt-beta109.md), sur la base beta.108, Statuaire beta.106 livré séparément.
+
+## beta.108 — Accumulation de neige
+
+- Chaque précipitation ajoute une couche ; la huitième forme un bloc de neige natif solide, puis le dépôt continue au-dessus.
+- Plafond de deux blocs par défaut, gamerule réglable (0 = arrêt, -1 = sans plafond particulier).
+- Collisions, supports, lumière et chaudrons natifs conservés ; accumulation seulement pendant la chute de neige.
+- [Contrat et essais](docs/snow-accumulation-beta108.md). Assemblage isolé sur beta.107, avec les œufs, sans le Statuaire beta.106 livré séparément.
+
+## beta.107 — Naissances en œufs
+
+- Reproduction : œuf natif au lieu d’un bébé vivant, variantes et caractéristiques héritées ; bébé garanti à l’éclosion.
+- Grenouille/têtard, tortue, sniffer, allay et villageois : chemins natifs particuliers pris en charge.
+- Générateur classique cassé en survie sans Toucher de soie : un œuf de son type.
+- Catalogue des 88 espèces : 35 voies couvertes et 53 propositions à valider, sans ajouter ces propositions au jeu.
+- [Contrat et contrôles](docs/spawn-eggs-acquisition-beta107.md), [catalogue](docs/spawn-eggs-catalogue-beta107.md).
+- Livraison isolée sur la base beta.105 ; le chantier Statuaire beta.106 est conservé séparément.
+
+## beta.106 — Atelier d’argile et modèles 3D
+
+- Dossier commun pour schémas et GLB ; sélection des modèles 3D dans Statues au Métabli.
+- Atelier d’argile : un bloc d’argile pour un statuaire 16³ à poser. Couleurs du modèle avec l’argile normale, couleur unie avec les seize argiles Sanctuary.
+- Modèle identifié et embarqué dans l’objet, sauvegarde serveur et rendu natif de la miniature dans le monde et l’inventaire.
+- Contrat d’import, de sauvegarde et limites : `docs/statuary-beta106.md`.
+
+## beta.105 — Saisons et chapeaux vivants
+
+- Molette pour les pages du fût ; panoramas avec les effets actifs du shader Sanctuary.
+- Prévisions saisonnières, neige continue ou averses de neige avec accumulation native.
+- Chapeaux réactifs : paratonnerre, briquet, spawner, fusée, cultures et aliments attirants.
+- Livre et plume : journal personnel selon le caractère et les caresses/blessures.
+- Les boules de neige activent les objets portés. Aucune Weather TNT.
+- [Contrat et vérifications](docs/living-hats-seasons-beta105.md).
+
+## beta.104 — Contraste des argiles
+
+- Gris soutenu et noir plus sombre, dessin vanilla plus contrasté.
+- Boules d’argile accordées aux blocs, autres textures intactes.
+- Rangement beta.103 conservé ; [détails](docs/clay-contrast-beta104.md).
+
+## beta.103 — Rangement créatif
+
+- Séries de 16 par type : briques, escaliers, dalles, argiles et leurs items.
+- Ordre des couleurs identique à l’onglet natif Minecraft 26.3.
+- [Détails](docs/colored-bricks-order-beta103.md).
+
+## beta.102 — Briques et argile de couleur
+
+- 16 familles : briques, dalles, escaliers, argile pastel, boules d’argile et briques en items.
+- Textures fournies intactes, recoloration pixel par pixel des trois textures vanilla.
+- Onglets natifs Couleurs/Ingrédients, recettes, cuisson, tailleur, butin et découvertes.
+- [Contrat et vérifications](docs/colored-bricks-beta102.md).
+
+## beta.101 — Atterrissage des familiers volants
+
+- Les profils volants ne subissent plus les dégâts et effets de chute de leur entité commune.
+- Les vrais coups et les chutes des familiers terrestres sont conservés.
+- [Reproduction et vérifications](docs/flying-landing-beta101.md).
+
+## beta.100 — Exploration et promenade des familiers
+
+- Statues limitées aux espèces rencontrées, vaincues ou ayant tué le joueur.
+- Catalogue et génération filtrés par une liste de découvertes fournie par le serveur.
+- Promenade avec destinations stables et pauses selon le tempérament, y compris en vol et en garde.
+- Import `.schem` : conversion native des anciennes palettes dont la version est connue, diagnostic du bloc incompatible.
+- [Contrat et vérifications](docs/exploration-familiers-beta100.md).
+
+## beta.099 — Catalogue, compétences et gestes K
+
+- Compétences avant les progrès ; arbre natif intégré et suivi par clic droit.
+- Fiches illustrées communes, trois plans récents terminés, infrastructures et décoration.
+- Palette de statue étendue aux blocs du registre, avec comparaison couleur et forme.
+- K bref : ancrer au point visé ou tourner au même point ; K maintenu : commandes.
+- Métabli préassemblé sur le piédestal des nouvelles salles souterraines.
+- Clé dorée en outil plat, texture vanilla provisoire en attente de celle du créateur.
+- [Contrat et vérifications](docs/catalogue-progression-beta099.md).
+
+## beta.098 — Construction créative
+
+- Bouton « Construire le plan… » dans K, visible uniquement en créatif.
+- Confirmation du plan complet à l’origine et dans l’orientation sélectionnées.
+- Statues, bâtiments et composants de machines ; assemblage multibloc à la clé.
+- [Détails et vérifications](docs/creative-construction-beta098.md).
+
+## beta.097 — Temples et aperçu texturé
+
+- Recherche de secours pour les temples des expéditions, avec pièces vanilla et fondation locale si nécessaire.
+- Conserve la première recherche et les emplacements déjà admissibles.
+- Aperçu des plans avec les modèles et textures des blocs, formes natives et nom du matériau visé.
+- [Contrat et vérifications](docs/temple-crash-beta097.md).
+
+## beta.096 — Métabli
+
+- Atelier de neuf établis avec les textures fournies, assemblage et dissociation à la clé.
+- Catalogue Statues, Machines, Bâtiments et Mes plans ; sélection unique à l’atelier.
+- K garde les commandes de placement, rotation, couches et matériaux.
+- Construction manuelle ; changer de projet ou l’abandonner exige de revenir à l’atelier.
+- [Détails et vérifications](docs/metabli-beta096.md).
+
+## beta.095 — Pilier des super pistons
+
+- Bois du centre de la grande plaque sur la tige, sans bordure ni étirement.
+- Découpage adapté aux segments courts du socle et de la tête.
+- [Détails et vérifications](docs/piston-shaft-beta095.md).
+
+## beta.094 — Feu du Fourneau
+
+- Braises dans les deux ouvertures, allumage commun lié à la chaleur.
+- Flammes et fumée alignées sur la façade dans les quatre orientations.
+- Pierre originale et fours isolés conservés.
+- [Détails et vérifications](docs/fourneau-allume-beta094.md).
+
+## beta.093 — Crash des infobulles pendant la recherche
+
+- Retire les accès à la police graphique lors de l’indexation asynchrone des
+  descriptions de familiers ; texte complet et mise en page visible conservés.
+- [Diagnostic et vérifications](docs/tooltip-crash-beta093.md).
+
+## beta.092 — Clic molette des super pistons
+
+- Socles, têtes et tiges renvoient le piston normal ou collant d’origine.
+- Pièces mobiles couvertes ; Ctrl + clic molette exclut les données techniques.
+- Sélection en survie et création en créatif selon les règles natives.
+- [Détails et vérifications](docs/multiblock-pick-beta092.md).
+
+## beta.091 — Interactions avec les animaux embarqués
+
+- Ciblage au clic gauche/droit des mobs assis dans le même bateau.
+- Coups, coffres portés et activation des distributeurs depuis les sièges.
+- Protection conservée pour les joueurs et animaux portés sur la tête.
+- [Détails et vérifications](docs/boat-passengers-beta091.md).
+
+## beta.090 — Minecraft Java 26.3 finale
+
+- Migration des quatre modules vers Minecraft 26.3 et Fabric API 0.160.5+26.3.
+- Fork JEI 30.32.0-sanctuary.3, cible et dépendances centralisées.
+- Édition beta.090 du pack de textures, format 97.1, images conservées.
+- Packs normal et Test reconstruits ; aucun monde personnel migré.
+- [Contrat et vérifications](docs/minecraft-26-3-beta090.md).
+
+## beta.061 — continuité musicale et montures colossales
+
+- La musique Minecraft commence au dévoilement du portail, après les lettres. Son flux est conservé
+  lors du passage sous le flash blanc au monde ; les autres sons sont nettoyés.
+- Le poids des familiers dépend de la taille stable de leur œuf, même avec un
+  modèle bébé. Les minuscules ne ralentissent pas, les petits légèrement,
+  puis le ralentissement augmente avec la taille.
+- Les colossaux deviennent des montures personnelles : Maj + clic droit à
+  main vide, déplacements et saut/vol/nage selon l’espèce, relâcher Maj puis
+  réappuyer pour descendre. La simulation et les collisions restent serveur.
+- Infobulles FR/EN pour le poids et le geste de monte. Aucun format de
+  sauvegarde ou paramètre de génération modifié.
+
 ## beta.060 — objets et blocs sur les mobs
 
 - Ajoute un emplacement de tête indépendant de l’armure native des mobs et

THIRD_PARTY_NOTICES.md

@@ -52,11 +52,11 @@ Les resource packs, shaders et mods communautaires envisagés dans la vision
 ne sont pas inclus automatiquement. Chaque ajout aura une version, une source,
 un hash et les crédits de sa distribution.
 
-Demeure est embarqué comme mod autonome, sous GPL-3.0-or-later. Son modèle
+Demeure est intégré au code de Sanctuary depuis beta.204, sous GPL-3.0-or-later. Son modèle
 provient des sources de KOKA99CAB dans `Structures/demeure`, référencées par
 l’inventaire 26.2, et a été adapté à Minecraft 26.3-pre-2. Voir
 `mods/demeure/PROVENANCE.md` pour les empreintes et les différences du port.
-Le JAR Demeure contient sa licence et ce document de provenance.
+Le JAR Sanctuary conserve sa licence GPL et `licenses/Demeure-PROVENANCE.md`.
 
 ## Inventaire beta.010
 
@@ -117,3 +117,29 @@ commit `62513191f6a3497447595c2215d466ad1d2bdb92`, sous Unlicense.
 Le comportement des contours et leurs coordonnées d’atlas suivent cette source ;
 l’intégration, la synchronisation et le calcul de capacité sont propres à Sanctuary.
 Texte de licence : [Unlicense amont](https://github.com/squeek502/AppleSkin/blob/62513191f6a3497447595c2215d466ad1d2bdb92/LICENSE).
+
+## Briques et argile beta.102
+
+Les seize textures de blocs de briques ont été fournies par le créateur de
+Sanctuary. Les variantes d’argile, de boule d’argile et de brique sont des
+recolorations des textures Minecraft 26.3 de Mojang/Microsoft. Les ressources
+de modèles, butin et états reprennent leurs équivalents natifs 26.3.
+`tools/generate-colored-bricks.py` documente cette transformation ;
+`tools/colored-bricks-palette.json` conserve couleurs et empreintes des PNG fournis.
+Ces ressources dérivées ne sont pas présentées comme des créations originales.
+
+## Clé dorée beta.121
+
+Le PNG 16 × 16 `golden_wrench.png` a été fourni par le créateur de Sanctuary
+le 17 septembre 2026. Il est conservé octet pour octet dans le mod, le pack
+intégré et le template personnel (SHA-256
+`a97570908db75caf8e6fc2f5ecabf12c54fd99bfea7be634df66c4310dca22af`).
+Le template regroupe les ressources client déjà distribuées par Sanctuary ;
+leurs crédits et conditions respectives restent applicables.
+
+MariaDB Connector/J 3.5.10 (`org.mariadb.jdbc:mariadb-java-client`),
+MariaDB Corporation et contributeurs : LGPL-2.1-or-later. Le JAR officiel est
+embarqué comme dépendance imbriquée, sans modification, pour le stockage
+communautaire optionnel. Sa licence est fournie dans `licenses/mariadb-connector-j-LGPL-2.1.txt` du JAR Sanctuary.
+Sources correspondantes : https://github.com/mariadb-corporation/mariadb-connector-j/tree/3.5.10
+(distribution Maven Central 3.5.10).

build.gradle

@@ -3,8 +3,8 @@ plugins {
     id 'net.fabricmc.fabric-loom' version "${loom_version}" apply false
 }
 
-tasks.named('build') { dependsOn(':sanctuary:build', ':demeure:build', ':jei:build', ':sanctuary-test:build') }
-tasks.named('check') { dependsOn(':sanctuary:check', ':demeure:check', ':jei:check', ':sanctuary-test:check', 'verifyPack') }
+tasks.named('build') { dependsOn(':sanctuary:build', ':jei:build', ':sanctuary-test:build') }
+tasks.named('check') { dependsOn(':sanctuary:check', ':jei:check', ':sanctuary-test:check', 'verifyPack') }
 
 tasks.register('verifyPack', Exec) {
     group = 'verification'
@@ -15,13 +15,52 @@ tasks.register('verifyPack', Exec) {
 tasks.register('assemblePack', Exec) {
     group = 'distribution'
     description = 'Assemble a local packwiz pack including the built Sanctuary mod.'
-    dependsOn(':sanctuary:build', 'verifyPack')
+    dependsOn(':sanctuary:build', 'verifyPack', 'assembleResourcePack', 'assembleResourceTemplate')
     commandLine('python3', 'scripts/pack.py', 'assemble')
 }
 
+tasks.register('verifyResourcePack', Exec) {
+    group = 'verification'
+    description = 'Verify the versioned Sanctuary texture sources and their release hashes.'
+    commandLine('python3', 'scripts/resource_pack.py')
+}
+tasks.named('check') { dependsOn('verifyResourcePack') }
+
+tasks.register('assembleResourcePack', Zip) {
+    group = 'distribution'
+    description = 'Export the same textures as the built-in resource pack for standalone use.'
+    dependsOn('verifyResourcePack')
+    from('ressources-pack/sanctuary') {
+        include 'assets/**', 'pack.mcmeta', 'pack.png'
+        exclude '**/.DS_Store'
+    }
+    destinationDirectory = layout.buildDirectory
+    archiveFileName = "Sanctuary-Resource-Pack-${resource_pack_version}.zip"
+    preserveFileTimestamps = false
+    reproducibleFileOrder = true
+}
+
 tasks.register('assembleTestPack', Exec) {
     group = 'distribution'
     description = 'Stage the separate flat-world Sanctuary Test profile.'
     dependsOn('assemblePack', ':sanctuary-test:build')
     commandLine('python3', 'scripts/test_pack.py')
 }
+
+tasks.register('assembleResourceTemplate', Zip) {
+    group = 'distribution'
+    description = 'Export all Sanctuary client assets as an editable personal resource pack.'
+    dependsOn(':sanctuary:processResources', 'verifyResourcePack')
+    def resources = project(':sanctuary').layout.buildDirectory.dir('resources/main')
+    // Same precedence as the native exporter: built-in textures override mod defaults.
+    duplicatesStrategy = DuplicatesStrategy.EXCLUDE
+    from(resources.map { it.dir('resourcepacks/textures/assets') }) { into 'assets' }
+    from(resources.map { it.dir('assets') }) { into 'assets' }
+    from(resources.map { it.dir('resourcepacks/template') })
+    from(resources.map { it.file('resourcepacks/textures/pack.png') })
+    exclude '**/.DS_Store'
+    destinationDirectory = layout.buildDirectory
+    archiveFileName = "Sanctuary-Template-${mod_version}.zip"
+    preserveFileTimestamps = false
+    reproducibleFileOrder = true
+}

docs/access-code-beta144.md

@@ -0,0 +1,61 @@
+# beta.144 — Code d’accès à la création
+
+Document historique de la PR de Chris. Le contrat de reprise ci-dessous est
+remplacé par [beta.166](inscription-web-beta166.md), notamment pour les codes
+consommés et les déconnexions.
+
+Le site accepte la candidature, whitelist le pseudo et envoie un code `SANC-XXXX-XXXX`.
+Hello World demande ce code avant de créer le personnage. Le client ne parle pas
+au site. Seul le serveur appelle l’API, avec le jeton `SANCTUARY_API_TOKEN`.
+
+Sans ces réglages, Hello World reste celui de beta.143 : biographie, couleur et
+familier, sans code. Dès que l’URL et le jeton sont présents, un nouveau
+personnage exige un code reconnu. Un habitant déjà enregistré entre sans écran.
+
+## Réglage serveur
+
+Variables d’environnement, ou fichier `config/sanctuary/access.json` si une
+variable manque :
+
+```json
+{"appUrl":"https://exemple.sanctuary","token":"..."}
+```
+
+`appUrl` est l’origine du site, sans barre finale. Le serveur appelle
+`POST {appUrl}/api/v1/access-codes/verify` puis `redeem`. Le jeton n’est pas
+écrit dans les logs, le client ou le pack. Une URL ou un jeton illisible ferme
+la création : aucun personnage n’est inventé hors ligne.
+
+## Parcours
+
+1. La whitelist laisse passer le pseudo. L’écran s’ouvre tant que l’UUID n’a pas
+   d’habitant.
+2. Le joueur saisit le code. L’affichage du champ et de l’exemple utilise
+   l’alphabet galactique standard (`minecraft:alt`, la police de la table
+   d’enchantement). La valeur envoyée reste le texte tapé. Un format complet
+   déclenche `verify`, pas chaque frappe. « Code reconnu » n’écrit rien.
+3. Confirmer envoie le code de la session, la biographie, la couleur et le
+   familier. Le pseudo envoyé au site est celui de la session.
+4. `redeem` répond `redeemed` avec `discord_id` : le lien est enregistré, puis
+   l’habitant est créé. Les connexions suivantes sautent l’écran.
+5. Erreur, site injoignable ou jeton refusé : le joueur reste sur Hello World.
+
+Une déconnexion avant `redeemed` ne consomme pas le code. Si le site a répondu
+`redeemed` et que l’écriture de l’habitant est interrompue, le lien Discord
+reste dans `data/sanctuary-access.json` (`pending`, schéma 1, graine du monde).
+La confirmation suivante termine le personnage sans rappeler `redeem`.
+
+Si le code est déjà consommé et que le site ne renvoie plus `discord_id`, le
+joueur reste bloqué avec un message de reprise. Le site doit alors renvoyer
+`minecraft_username` et `discord_id` pour le même pseudo. Le mod accepte cette
+réponse, que `valid` soit vrai ou faux, et finit la création.
+
+Le registre des habitants ne change pas. Le Discord est un fichier à part.
+Un fichier illisible est conservé et refuse l’accueil.
+
+## Limites
+
+Le gel dans le monde n’est pas ajouté : Hello World reste avant l’entrée, comme
+aujourd’hui. Inventaire, commandes et dimensions ne sont pas accessibles tant
+que l’habitant n’existe pas. La whitelist RCON reste celle du site. Un pseudo
+ajouté à la main, sans code, voit l’écran sans pouvoir le valider.

docs/actualisation-tests-beta165.md

@@ -0,0 +1,55 @@
+# Actualisation des tests — socle beta.165
+
+Suite à l’audit des 23 échecs. Changements limités aux GameTests et à leur
+préparation ; aucun changement des règles, des données de production ou de
+format de monde. Pas de nouvelle version binaire : le laboratoire reste beta.165.
+
+## Scénarios corrigés
+
+- Placement : joueur à portée réelle, sans occuper la cellule visée. Les compteurs,
+  événements, empreintes et les huit diamants de la tombe restent vérifiés.
+- Inventaires : données d’ouverture explicites pour l’atelier d’argile et le
+  multibloc, avec maintien de la boucle sur toutes les entrées du registre.
+- Familiers : achat de l’accès puis commande serveur de mode travail ; le helper
+  vérifie aussi que le mode combat n’accorde pas les anciens passifs. Les bonus,
+  consommation de ressources et annulations restent vérifiés.
+- Ancienne invulnérabilité : test des coups amicaux sans dégâts, du K.-O. sur
+  dégât létal et de la conservation de l’œuf. Le poisson terrestre utilise son
+  profil actuel et garde sa vérification de transition aquatique.
+- Permissions : accès public à l’introduction, restrictions opérateur sur names
+  et community admin. Catalogue recompte les 67 documents, 2042 recettes,
+  1780 items, 1374 blocs et 1937 identifiants distincts. Hauteur actuelle 640.
+- Dragon : cycle natif tickNonPassenger (commonTick + tick), compteur d’entité
+  contrôlé, déplacement/altitude/collision conservés.
+- Dalle/coffre : visée à portée du dessus réel, sans collision du joueur avec la
+  surface à bâtir. Les assertions de fusion, collisions et contenu restent.
+- Hydrologie : les ouvertures OUTLET doivent être des coupes sans source ni
+  sédiment, appartenant à un déversement terminal déclaré. Les autres cellules
+  conservent les contrôles de support naturel.
+
+## Diagnostics indépendants
+
+- [Construction](audit-construction-beta165.md)
+- [Dragon](audit-dragon-beta165.md)
+- [Berges](audit-berges-beta165.md)
+
+## Validation
+
+Premier rejeu ciblé : **81/81 tests obligatoires passent** en 1 min 45 s.
+Journal : `build/test-refresh-focused.log`.
+Groupes : inventory, inventoryflow, companions, refonte, accessories, graves,
+collections, progression, demeure. Ce rejeu valide notamment les nouvelles
+assertions atteintes et le déplacement du dragon. Construction et hydrologie
+sont réservées au rejeu complet suivant.
+
+`./gradlew check build --continue -PsanctuaryQuickTests=true` : **BUILD SUCCESSFUL**
+en 7 min 11 s. **252/252 GameTests obligatoires réussis**, zéro échec, puis
+les autres contrôles de `check` terminent avec succès.
+Journal : `build/test-refresh-full.log`.
+
+Les quatre cas analysés par les agents passent dans ce rejeu, sans modification
+production. Le patch supplémentaire de parois OUTLET proposé à titre conditionnel
+n’a pas été appliqué : aucune assertion correspondante n’a échoué.
+Ce résultat porte sur la suite configurée ci-dessus ; aucune stabilité statistique
+sur plusieurs graines, plateformes ou répétitions n’est revendiquée.
+

docs/adventure-ecology-beta180.md

@@ -0,0 +1,46 @@
+# WG-ECO-180 — grands bassins et donjon minier
+
+Suite du retour beta.179 : relief et écologie générale validés ; les petites
+mares répétées, l’absence de cerisiers et les mines rectilignes sont à corriger.
+Branche `codex/cave-dungeon-beta180`, nouveau preset de labo
+`sanctuary_test:adventure_ecology_v1`, profil `adventure`, graine 42.
+Aucune migration : uniquement un nouveau solo, vue 32, commandes activées.
+
+Cibles : grands bassins irréguliers réunis par débordements ; arrêt des petites
+mares et des cornichons hors de l’eau ; trois cerisiers sur l’île principale,
+un récif cherry et un récif automnal (autres récifs nus, relief conservé).
+Un donjon ramifié avec salles, boucles, dénivelés, spawners et wagonnets à butin,
+plus un éclairage ponctuel. La cabane et les habitats souterrains sont conservés.
+
+Implémentation : deux systèmes de grands bassins sur des sols de cavités,
+berges irrégulières préservant les reliefs émergents, fonds suivant la roche et
+bassins inférieurs quatre blocs plus bas. Les anciennes petites mares sont
+exclues de ce preset. Les trois cerisiers sont réservés et placés avec la
+fonction native ; les récifs 0 et 1 deviennent cherry et automne, les autres
+restent nus. La géométrie, les minerais et l’espace ISS sont conservés.
+
+Donjon : 13 salles, embranchements et boucles, cinq spawners natifs
+(squelettes et araignées des cavernes pour cette graine), quatre wagonnets-coffres.
+Butin différé natif, contenant diamants, émeraudes, `sanctuary:ruby` et
+`sanctuary:sapphire`, plus des provisions. Pas d’emblème : clarification du
+créateur, il parlait bien des gemmes dans le butin. Une lanterne tous les
+quatre portiques environ, éclairage sur tonneau dans les caches.
+
+Contrôle `solo180c`, graine 42 : trois vrais troncs de cerisiers vérifiés,
+deux surfaces d’eau connectées de 1 232 et 1 221 blocs, passages praticables,
+spawners et tirage des quatre gemmes vérifiés. La réouverture avec fluides
+actifs confirme les deux chutes d’eau ; chargements forcés retirés avant arrêt.
+Dernière correction ensuite : support des lanternes des caches. Contrôle
+final `solo180d` réussi, quatre wagonnets avec leur table de butin conservée
+en sauvegarde. Suite `check build assemblePack assembleTestPack` réussie
+(11 min 26 s, journal local `build/adventure180-check-build.log`).
+
+Points de visite : cerisiers près de (38,301,101), grand bassin vers
+(-192,198,32), donjon vers (120,145,48), récifs thématiques aux mêmes
+emplacements que les récifs précédents. Nouveau solo `visite180/adventure/42`,
+commandes activées, vue 32, simulation 12, créatif et difficulté normale.
+Les premières proportions restent à juger en jeu ; aucune ancienne sauvegarde
+ni distribution personnelle modifiée.
+
+Ouverture confirmée le 30 septembre à 00:28 : Vulkan sur Apple M1,
+KokaLab connecté, distance serveur 32 et simulation 12.

docs/aptitudes-beta236.md

@@ -0,0 +1,140 @@
+# APT-236 — aptitudes par thème et activation personnelle
+
+La règle de désactivation décrite ici correspond à la livraison beta.236.
+[Beta.237](aptitudes-beta237.md) la remplace : seuls World Map et Mob Names
+restent désactivables, les autres aptitudes sont acquises définitivement.
+Le chantier Pause beta.235 est intégré dans cette nouvelle livraison.
+
+Branche `codex/progression-aptitudes`, base beta.234 (`f9c2ce8`). Le travail
+parallèle du menu Pause occupe beta.235 ; ce lot réserve beta.236.
+
+## Contrat avant implémentation
+
+Progression regroupe les aptitudes en cinq thèmes : Survie (Swimming, Rest,
+Food Knowledge), Inventaire et fabrication (Inventory Sorting, Catalogue),
+Familiers (Active Bond, Familiar Study), Exploration (World Map, Mob Names,
+Zoom), Arts et métiers (Enchantement, Alchimie). Le minage et la forgerie
+restent hors de ce ticket.
+
+Enchantement et Alchimie coûtent chacun 4 niveaux, comme les aptitudes actuelles.
+L'usage personnel de la table d'enchantement et de l'alambic est verrouillé au
+départ dans les mondes avec progression Sanctuary. Les menus natifs sont
+refusés côté serveur tant que l'aptitude correspondante n'est pas acquise et
+active, y compris via les blocs fonctionnels portés sur la tête. Les enclumes,
+la table de forge, les équipements enchantés et les potions déjà obtenues
+restent inchangés. Les alambics partagés et leur automatisation continuent
+leur fonctionnement autonome : ce lot contrôle l'accès personnel au poste,
+sans attribuer de propriétaire à un bloc ni arrêter une préparation lancée.
+Les personnages existants avec progression Sanctuary doivent aussi acquérir
+ces deux nouvelles aptitudes ; aucune acquisition gratuite n'est ajoutée.
+
+Une aptitude achetée peut être activée ou désactivée sans coût et sans perdre
+son achat. Food Knowledge reste permanent après apprentissage. Les compétences,
+les prix et les découvertes ne changent pas. Les effets de gameplay sont
+contrôlés côté serveur ; les aides d'interface utilisent le choix serveur.
+Active Bond contrôle l'usage des pouvoirs de travail, pas les techniques de
+combat, les pouvoirs passifs ou l'équipement du familier. Une action déjà
+lancée se termine normalement ; les nouvelles activations sont refusées.
+
+## Persistance et compatibilité
+
+L'attachement additif `sanctuary:aptitude_preferences` conserve un entier de
+0 à 2047 : un bit par aptitude désactivée, dans l'ordre immuable names, atlas,
+sorting, swimming, resting, active_bond, familiar_study, catalogue, zoom,
+enchanting, alchemy.
+L'absence de cet attachement équivaut à zéro : toutes les aptitudes acquises
+gardent leur comportement actuel. Il est copié à la mort et conservé au New
+Game+. Deux attachements booléens additifs `sanctuary:enchanting_learned` et
+`sanctuary:alchemy_learned` conservent leurs nouveaux achats ; leur absence
+équivaut à false et ils sont copiés à la mort et conservés au New Game+.
+Aucun schéma ou contenu des achats existants n'est réécrit. Ce contrat
+est limité à cet attachement ; aucun monde personnel n'est ouvert ou modifié.
+
+Une requête transmet la cible, le choix et le masque attendu ; le serveur
+vérifie l'achat, la session, l'état du joueur et le masque courant. Un choix
+inconnu, Food Knowledge, une aptitude non acquise ou une requête périmée est
+refusé sans XP dépensée. Un état distinct est renvoyé avant le snapshot de
+progression. La capacité réseau `aptitude_preferences_v1` exige les versions
+compatibles sur client et serveur sans changer les paquets existants.
+
+Désactiver Swimming interrompt le sprint aquatique ; désactiver Rest arrête
+la récupération. World Map masque son entrée et refuse les nouvelles lectures
+personnelles ; les relevés continuent d'être conservés et l'outil opérateur
+reste disponible. Catalogue masque l'aide personnelle JEI et la consultation
+complète de Discovery, sans toucher aux recettes ni aux découvertes.
+
+Un ancien mod ignore ces trois nouveaux attachements et retrouve son ancien
+accès aux postes. Il peut perdre les attachements inconnus en sauvegardant :
+conserver une sauvegarde avant un retour arrière. Le schéma 9 de progression
+et les preuves des aptitudes antérieures restent identiques.
+
+## Vérifications
+
+```sh
+./gradlew check build assemblePack \
+  -PsanctuaryFocusedTests=aptitudes236,progression,movement,sorting,recipes,foodknowledge \
+  -PsanctuaryAtlasOnly=true
+./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true \
+  -PsanctuaryAptitudes236ClientTests=true -PsanctuaryClientGraphicsBackend=vulkan
+```
+
+Première passe serveur : `check build assemblePack` réussi en 3 min 13 s,
+**33 GameTests requis réussis**, dont cinq scénarios APT-236. Contrôles purs
+du dépôt réussis. Le banc Atlas existant évite le conflit de génération du
+chemin par défaut déjà documenté en beta.232. Monde de développement neuf.
+Log : `build/aptitudes236-check-build-pack.log`.
+
+- Onze choix indépendants, refus des requêtes inconnues, non acquises,
+  périmées et de Food Knowledge ; conservation exacte de l'XP et des preuves
+  d'achat. Achat à 3 niveaux refusé, à 4 accepté une seule fois.
+- Aller-retour des nouveaux attachements dans le NBT joueur natif, copie à
+  la mort, conservation lors de la remise à zéro des compétences du cycle.
+- Swimming arrête le sprint aquatique et interdit les flags de mouvement
+  directs ; Rest arrête la récupération ; tri falsifié et lectures Atlas
+  personnelles refusés. Réactivation du tri contrôlée avec la même requête.
+  Active Bond refuse une nouvelle activation avant toute planification.
+- Table d'enchantement native refusée avant acquisition, ouverte ensuite ;
+  **une épée diamant est réellement enchantée**. Désactiver ferme le menu,
+  refuse sa réutilisation et son bouton d'enchantement sans dépense d'XP.
+  Alambic natif refusé puis ouvert, fermeture et invalidation à la désactivation,
+  ingrédients partagés conservés et réouverture après réactivation.
+
+Parcours client final réussi en **52 s**, Minecraft 26.3, Vulkan confirmé par
+MoltenVK 1.4.2 / Apple M1. Log : `build/aptitudes236-client-vulkan.log`, marqueur
+`APTITUDES236_PASS` ; douze captures dans `build/aptitudes236-screenshots/`.
+
+- FR/EN, GUI 2/3/4, fenêtre 1280 × 960 : cinq thèmes dans l'ordre, les douze
+  aptitudes présentes, Food Knowledge permanent et sans interrupteur.
+- Achat des deux arts depuis les véritables boutons de Progression : huit
+  niveaux au total. **66 paires désactivation/réactivation** via les widgets
+  et le réseau, état serveur contrôlé, XP et progression finale identiques.
+- Libellés d'état entièrement contenus dans les boutons ; défilement et
+  position conservée au redimensionnement 1344 × 1008 ; Terminé revient à
+  Pause. Une première passe a trouvé le libellé permanent trop large en GUI 4 :
+  retour à la ligne ajouté. Les interrupteurs affichent un état court et
+  expliquent leur action gratuite dans l'infobulle.
+
+Les essais concernent les sauvegardes de développement. Pas de validation
+Windows ou multijoueur distant. L'automatisation des alambics et les pouvoirs
+déjà lancés restent les limites explicites du contrat ; la forgerie attend
+son prochain ticket.
+
+## Livraison locale
+
+Build final `check build assemblePack` réussi en **2 min 24 s**, 136 tâches,
+33/33 GameTests requis et contrôles purs réussis après les derniers réglages
+d’interface. Log : `build/aptitudes236-check-build-pack-final.log`.
+
+Versions du mod, du pack et du manifeste alignées sur **beta.236**.
+[MRpack local](../build/Sanctuary-beta.236.mrpack) vérifié : 12797046 octets,
+intégrité ZIP, Minecraft 26.3 / Fabric Loader 0.19.5, un seul JAR Sanctuary
+identique au build final, sans classe de test ni monde ni module de laboratoire.
+Les deux PNG fournis sont identiques octet pour octet aux originaux dans le JAR.
+Reçu : `build/aptitudes236-artifact.json`.
+
+- SHA-256 JAR : `21a4411ebed223a1d9f9d204dc9d7300af0d5b946416e39bb138f5c575bf5847`.
+- SHA-256 MRpack : `9d3eca559805d451e8c653cca1d59186ae46e3c6964147b9fc072b9da832f921`.
+
+La branche reste indépendante du chantier Pause beta.235 ; leur intégration
+reste à effectuer. Aucune publication distante, mise à jour du canal packwiz
+ou synchronisation d’instance personnelle.

docs/aptitudes-beta237.md

@@ -0,0 +1,99 @@
+# APT-237 — achats permanents et intégration du menu Pause
+
+Branche `codex/progression-aptitudes`. Intégration des commits beta.235
+`a7bdfe6` et `00d175c`, avec les aptitudes beta.236 `1c8e643`.
+
+## Contrat avant implémentation
+
+Seuls World Map et Mob Names disposent d'un interrupteur gratuit après achat.
+Swimming, Rest, Inventory Sorting, Catalogue, Active Bond, Familiar Study,
+Zoom, Enchantement, Alchimie et Food Knowledge restent acquis et utilisables
+sans désactivation. Les prix et les conditions d'achat restent identiques.
+Enchantement et Alchimie exigent toujours leur achat avant l'accès personnel
+au poste natif. Les achats, l'XP et les preuves existantes sont conservés.
+
+Le menu Pause reprend la disposition beta.235 : deux colonnes Aventure et
+Communauté avant World Map, une colonne à gauche avec la carte. Le choix
+personnel de masquer World Map suit aussi cette disposition.
+
+## Contrat de migration des préférences beta.236
+
+L'identifiant `sanctuary:aptitude_preferences`, son codec entier 0–2047 et
+l'ordre historique des onze bits restent stables. Les bits 0 (Mob Names) et
+1 (World Map) restent effectifs. Les bits 2 à 10 deviennent inertes et sont
+retirés de cet attachement lors de sa prochaine synchronisation serveur.
+Ainsi un ancien masque 2047 devient 3 : les deux aides restent masquées et
+les neuf autres aptitudes achetées retrouvent automatiquement leur usage.
+Le chargement accepte encore les anciennes valeurs ; les lectures et effets
+ignorent immédiatement leurs bits désormais inertes. Aucune preuve d'achat,
+aucun format de progression, aucun monde ou terrain n'est réécrit.
+
+Les requêtes de désactivation des aptitudes permanentes sont refusées même
+si elles proviennent d'un ancien client. Les paquets v1 restent inchangés ;
+une capacité additive `sanctuary:aptitude_permanent_v1` impose un client avec
+cette règle côté serveur. Les nouvelles interfaces sont traduites FR/EN.
+Le retour à une ancienne version nécessite comme auparavant une sauvegarde,
+car cette version ne peut restaurer les anciennes désactivations effacées.
+
+## Vérification et livraison
+
+```sh
+./gradlew check build assemblePack \
+  -PsanctuaryFocusedTests=aptitudes236,menus,progression,movement,sorting,recipes,foodknowledge \
+  -PsanctuaryAtlasOnly=true
+./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true \
+  -PsanctuaryAptitudes236ClientTests=true -PsanctuaryClientGraphicsBackend=vulkan
+```
+
+Les suites APT-236 sont actualisées pour vérifier la nouvelle règle et la
+migration ; leurs noms Gradle restent stables. `check build assemblePack`
+réussi en **2 min 34 s**, **37 GameTests requis réussis**, dont six scénarios
+aptitudes. Contrôles purs du dépôt réussis. Le banc Atlas évite le chemin de
+génération par défaut déjà documenté en beta.232. Log :
+`build/aptitudes237-check-build-pack.log`.
+
+- Les deux choix personnels sont gratuits ; refus des requêtes périmées,
+  inconnues, non acquises et des désactivations d'aptitudes permanentes.
+  Prix des nouveaux achats vérifié à trois/quatre niveaux, achat unique.
+- Ancien masque 2047 rechargé dans le NBT natif, interprété en 3 puis
+  normalisé sans changement d'XP ni de preuve d'achat. Conservation des
+  choix et des achats à la mort et au New Game+.
+- Avec d'anciens bits désactivés : sprint aquatique, Rest et tri restent
+  utilisables ; Active Bond suit son contrôle normal de familier équipé.
+  World Map conserve son contrôle d'accès et sa réactivation gratuite.
+- Enchantement et Alchimie refusés avant achat, puis disponibles lors des
+  visites suivantes. Une épée diamant est réellement enchantée. Une requête
+  de désactivation refusée ne ferme ni n'invalide les menus acquis ; ingrédients
+  partagés de l'alambic conservés. Accès vanilla hors progression conservé.
+
+Parcours client réussi en **32 s**, Minecraft 26.3, Vulkan / MoltenVK 1.4.2
+sur Apple M1. FR/EN, GUI 2/3/4, fenêtre 1280 × 960 : cinq thèmes, douze
+aptitudes, dix achats permanents, **12 paires désactivation/réactivation**
+réelles des deux aides. Deux achats des arts via les boutons natifs de
+Progression, huit niveaux au total. Libellés contenus dans leurs boutons,
+XP et preuves conservées, défilement conservé au redimensionnement et retour
+Terminé vers Pause.
+
+La même suite réutilise les assertions Pause du collègue : disposition,
+ordre clavier, marges, titres et libellés de navigation vérifiés après achat
+de World Map, avec son choix personnel désactivé puis activé. Les deux
+colonnes et la colonne près de la carte sont conservées. Les captures de
+Pause portent sur la disposition ; les relevés et fils commencent à charger.
+Log `build/aptitudes237-client-vulkan.log`, marqueur `APTITUDES237_PASS` ;
+**24 captures** dans `build/aptitudes237-screenshots/`. Inspection des captures
+Arts FR GUI 3, Pause sans carte FR GUI 4 et Pause avec carte EN GUI 3.
+
+Versions alignées sur **beta.237**. [MRpack local](../build/Sanctuary-beta.237.mrpack)
+vérifié : 12797901 octets, intégrité ZIP, Minecraft 26.3 / Fabric Loader 0.19.5,
+un seul JAR Sanctuary identique au build final, sans tests ni monde ni module
+de laboratoire. Les deux icônes fournies restent identiques octet pour octet
+aux originaux. Reçu `build/aptitudes237-artifact.json`.
+
+- SHA-256 JAR : `7ac741c6a15b8ab05a909cf0132c9d605b863723c0742a92d8b60c741fd760a6`.
+- SHA-256 MRpack : `7635e9e7a425cbd7a7f6d020f9bb2bcced8cc1287967093346295e4b4b2250e9`.
+
+Les anciens artefacts beta.236 sont conservés. Tests dans des mondes de
+développement neufs ; Windows et multijoueur distant non testés. Les
+alambics autonomes et pouvoirs déjà lancés gardent le contrat beta.236.
+La forgerie, les enclumes et la table de forge attendent leur prochain ticket.
+Aucune publication, avancée du canal ni synchronisation d'installation personnelle.

docs/arenas-beta073.md

@@ -0,0 +1,172 @@
+# ARENA-01 — duels publics, arènes et paris — beta.073
+
+Branche `codex/familiar-arenas-beta073`. Ticket du 15 septembre 2026.
+**Implémenté, client natif, compilation et archives locales vérifiés.**
+
+## Parcours en jeu
+
+**Pause → Progression → Duels et arènes** ouvre la liste publique. Le même
+accès figure dans le menu Duel historique. Aucune aptitude de familier ni
+prestige n'est requis pour organiser un combat entre joueurs.
+
+1. Créer un **duel** (deux inscrits) ou une **arène** (sans plafond de
+   participants), à l'emplacement de l'organisateur dans sa dimension.
+2. Choisir **familiers seuls**, **joueurs seuls**, ou **joueurs avec familiers**.
+   Choisir un rayon de 24, 48 ou 96 blocs, une durée de 3, 5 ou 10 minutes,
+   et l'autorisation de la nourriture, des potions et des perles. Les armes,
+   boucliers et munitions restent utilisables. Les familiers gardent leurs
+   statistiques, personnalités, ressources et recharges réelles.
+3. Choisir l'objet commun dans l'inventaire débloqué, et une mise d'entrée
+   de 0 à 64 objets. Zéro signifie gratuit. Par défaut, l'objet est l'émeraude.
+   Les composants natifs doivent correspondre : un objet renommé ou un
+   contenant rempli n'est pas équivalent à sa version vierge. La création
+   inscrit l'organisateur et prélève sa mise après validation serveur.
+4. Les autres joueurs consultent les règles, viennent dans le périmètre et
+   s'inscrivent. Chacun valide **Prêt**. Tout changement de la liste invalide
+   les validations. L'organisateur lance quand tous sont présents et prêts.
+5. **Dix secondes de préparation**, puis chacun pour soi. Les inscriptions
+   et les paris sont fermés dès le lancement de la préparation.
+
+La liste présente les coordonnées, la dimension, les inscrits, les pots et
+l'état du combat. Elle contient aussi les duels historiques à invitation,
+qui gardent leurs deux mises libres et leur double validation. Pour ces seuls
+duels historiques, le marché des spectateurs utilise des émeraudes ; les mises
+historiques des deux adversaires restent dans leur menu existant.
+
+Les annonces d'ouverture, de lancement et de résultat vont dans le chat du
+serveur. Les combats terminés restent affichés cinq minutes. Les mises dues
+restent disponibles aussi longtemps que nécessaire. La consultation se fait
+par pages de douze entrées ; la pagination ne limite pas les inscriptions.
+Il n'y a ni téléportation de spectateur, ni création automatique de terrain :
+la carte de playtest se prépare normalement à côté.
+
+## Combat et règles du monde
+
+- **Joueurs : morts réelles**, selon le choix du créateur. Aucune santé
+  artificielle à la fin, aucun inventaire restauré par l'arène. Inventaire,
+  perte d'expérience, règles de conservation et tête-tombe suivent Sanctuary
+  et les règles effectives du monde. La mort élimine après le chemin natif
+  de création de la tombe.
+- **Familiers : K.-O. existant**, santé persistante et récupération habituelle.
+  En mode mixte, le K.-O. du familier laisse son joueur combattre. La mort du
+  joueur élimine son camp. En mode familiers seuls, les propriétaires ne sont
+  pas des cibles et ne frappent pas directement les familiers adverses.
+- Le dernier camp encore en lice gagne. Abandon, déconnexion pendant le
+  combat, changement d'individu, rappel du familier, sortie du périmètre ou
+  passage en créatif/spectateur éliminent. Le rayon est une distance 3D au
+  centre annoncé : l'altitude compte également.
+- Une interruption du serveur, un rechargement du catalogue, l'expiration des
+  inscriptions ou une durée écoulée sans vainqueur rembourse les mises.
+  Un joueur déjà éliminé qui se déconnecte ne termine pas le combat des autres.
+- Avant départ, se désinscrire rembourse son entrée et les paris placés sur
+  soi. Les autres inscriptions restent ouvertes. Le départ de l'organisateur
+  annule l'événement entier. Les duels historiques gardent leur contrat
+  d'interruption/refund antérieur.
+- La permission PvP du combat ne vise que les adversaires inscrits en lice,
+  même si le PvP général est désactivé ou s'ils sont de la même faction.
+  Les dégâts directs ne franchissent pas cette frontière ; les familiers
+  hors combat n'apportent pas leur assistance aux combattants.
+- Pose, utilisation et casse de blocs par les combattants sont désactivées,
+  y compris les gestes de minage/construction groupés déjà commencés.
+  Cela ne transforme pas le périmètre en claim : les mécanismes du monde,
+  cosmétiques, pièges ou interventions d'opérateurs restent ceux de la map.
+
+## Paris en objets
+
+La mise d'inscription est identique pour tous ; son pot revient au vainqueur.
+Les spectateurs choisissent un inscrit et déposent une quantité libre de
+l'objet commun, jusqu'à 3 456 unités par geste et dans la limite de leur
+inventaire débloqué. Plusieurs gestes sont possibles avant le lancement.
+Il n'y a pas de commission.
+
+Le pot des spectateurs est partagé **au prorata des mises gagnantes**. Les
+unités indivisibles restantes sont réparties dans l'ordre stable des UUID.
+Exemple : 4 objets sur A, 2 autres sur A et 3 sur B ; si A gagne, les deux
+parieurs gagnants récupèrent respectivement 6 et 3 objets. Si personne n'avait
+misé sur le vainqueur, les paris sont remboursés.
+
+Un inscrit ne peut pas parier sur son combat. Un parieur ne peut plus s'y
+inscrire. Les boutons utilisent des identifiants et des révisions contrôlés
+par le serveur ; aucune pile fournie par le client ne sert de preuve de fonds.
+Les fonds sont pris uniquement dans les rangées réellement débloquées.
+
+Les gains se récupèrent dans **Duels et arènes**. Un inventaire plein conserve
+le solde dans le registre ; libérer même une partie d'une pile permet de le
+récupérer progressivement. Aucun paiement ne tombe au sol et un joueur mort
+ne peut pas encaisser dans l'inventaire en cours de remplacement.
+
+## Contrat de sauvegarde additif
+
+Aucun registre historique, identifiant d'objet, génération ou monde personnel
+n'est converti. Nouveau fichier séparé :
+`sanctuary/arena-stakes-v1.json`, schéma 1. Nouveau reçu joueur persistant et
+copié à la mort : `sanctuary:arena_receipt`.
+
+Chaque dépôt est écrit avant le débit, puis l'inventaire natif et son reçu sont
+sauvegardés ensemble dans `playerdata` et relus. Le journal confirme ensuite
+le débit. Chaque résultat répartit la totalité des fonds en une écriture
+atomique avant le paiement. Chaque paiement sauvegarde de même l'inventaire
+et son reçu avant de retirer la dette du journal. Une collecte partielle garde
+le reste et ne repaie pas une tranche déjà reçue.
+
+Au redémarrage, les combats vivants ne reprennent pas : les mises réellement
+débitées sont remboursées. Un résultat déjà réparti conserve ses destinataires.
+Les dépôts inachevés sont résolus à la reconnexion du payeur d'après son reçu,
+sans inventer de crédit. Une erreur disque, un schéma inconnu ou un journal
+invalide préserve les fichiers et suspend les transactions.
+
+Le journal a une borne de lecture/écriture de 32 Mio pour détecter les états
+anormaux. C'est une limite de stockage des opérations en attente, pas un nombre
+maximum de participants. Avant un retour à une ancienne version, terminer
+les événements et récupérer les soldes ; sinon restaurer une sauvegarde
+complète cohérente, jamais un seul registre ou un seul fichier joueur.
+
+## Vérifications et limites
+
+Minecraft **26.3-pre-2**, Java 25, Fabric API **0.160.0+26.3**.
+`Arena073ClientChecks` utilise un client intégré et des joueurs serveur
+synthétiques avec connexions natives, dans un monde plat de développement.
+Aucun serveur personnel ni EULA de serveur dédié n'est modifié.
+
+La validation couvre trois familiers en combat autonome, des joueurs avec
+morts réelles, le mode mixte, les permissions PvP, les paris, le partage exact,
+les remboursements, l'inventaire plein et les composants de contenants. Une
+arène de 25 inscrits vérifie la pagination sans plafond de participants.
+Les menus FR/EN et l'aller-retour réseau du bouton de création sont contrôlés.
+Résultat client : **réussi**, `ARENA073_PASS`, 1 min 52 s. Les tests
+`Duel054Checks` sont rejoués dans la même session : validation mutuelle, anciennes
+mises, projectiles natifs, K.-O., refus d’un projectile tardif et remboursements
+passent aussi. La mort pendant les inscriptions libère l’inscription sans
+annuler les autres. Le journal est éprouvé avant débit, après sauvegarde du
+débit, après sauvegarde du paiement et avec un schéma inconnu. Les essais
+conservent les quantités exactes et refusent le schéma inconnu sans réécriture.
+
+Journal client : `build/arena073-workspace/build/arena073-client.log`.
+Captures copiées dans `build/arena073-evidence/`.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit en **2 min 56 s**, 124 tâches (108 exécutées). Les GameTests serveur
+dédiés sont exclus conformément au refus d'accepter leur EULA ; les scénarios
+multijoueurs de ce ticket tournent dans le serveur intégré du client natif.
+
+Les **1 689 classes** compilées, les ressources et les sources Java correspondent
+aux archives. Par rapport à beta.072, seules les classes de ce ticket et les
+métadonnées de version évoluent ; les ressources existantes, les 88 profils et
+le resource pack beta.070 restent identiques. Les **79 nouvelles clés FR/EN**
+sont présentes dans les deux langues. Les archives beta.070 à beta.072 restent
+inchangées.
+
+- [Pack normal](../build/Sanctuary-beta.073.mrpack) : 9 592 283 octets.
+- [Pack Test, monde plat rapide](../build/Sanctuary-Test-beta.073.mrpack) :
+  9 611 218 octets.
+- [Reçu des artefacts et SHA-256](../build/arena073-artifact.json).
+
+La livraison a été construite dans `build/arena073-workspace`, copie isolée
+incluant la version beta.072 vérifiée, puis les seuls changements de ce ticket
+ont été réintégrés dans les sources partagées. Aucun canal distant, serveur
+personnel ou instance Prism n'est mis à jour.
+
+Ce ticket fournit un outil de playtest. Il ne constitue pas une validation
+exhaustive de l'équilibrage des 88 espèces, un benchmark de très grand serveur,
+ni une protection compétitive contre les complicités et abandons arrangés.
+Les tests de reprise ne simulent pas une panne physique du disque.

docs/arrival-mount-beta061.md

@@ -0,0 +1,79 @@
+# beta.061 — musique d'arrivée et taille des familiers portés
+
+Branche `codex/intro-familiar-mount-beta061`.
+
+Contrat : lancer la musique Minecraft au dévoilement du portail (23,5 s),
+puis conserver ce même morceau pendant le flash blanc et le passage au monde.
+Les lettres gardent leurs ambiances sans musique. Le menu est arrêté une fois
+à l'ouverture de l'introduction ; le gestionnaire attend le portail. Le lancement
+se fait une seule fois, y compris après un redimensionnement. Passer avant le
+portail ne force pas de morceau ; passer après conserve le morceau commencé.
+Les sons de la cinématique gardent leur propre nettoyage ; les volumes choisis par le joueur restent respectés.
+
+Le portage des familiers utilise la taille déjà enregistrée dans l'œuf :
+minuscule sans pénalité, petit avec une pénalité légère, ordinaire à 75 %
+de vitesse à la taille 1, puis de plus en plus lourd jusqu'à 25 % à la limite.
+Un colossal (taille ≥ 2,5) ne peut plus être porté. Maj + clic droit à main
+vide sur son familier colossal permet de monter dessus ; relâcher Maj puis
+appuyer à nouveau fait descendre. Les touches de déplacement le dirigent,
+Espace saute au sol ou monte en vol/nage ; regarder vers le bas en avançant
+permet de descendre en vol/nage. Les aquatiques restent lents hors de l'eau.
+
+Le propriétaire dirige sa monture côté serveur. Les commandes de combat
+autonomes ne détournent pas le déplacement tant qu'il est dessus. L'équipement
+sur la tête du mob conserve la priorité du geste (récupérer son chapeau avant
+de monter). Les animaux natifs bébés restent sans poids, les piles de joueurs
+et leur interaction avec Force gardent leurs règles.
+
+La monte occupe une place pour le propriétaire, sans autre passager porté.
+Les duels conservent leur combat autonome et font descendre le cavalier.
+
+Les relations de monture sont temporaires. Retrait de l'œuf, K.-O., déconnexion
+ou changement de dimension interrompent la monte. Aucun nouveau format de
+sauvegarde : `sanctuary:familiar_size` schéma 1 et tous les autres composants
+de l'œuf restent inchangés. Les œufs sans taille valide gardent le poids
+ordinaire et ne deviennent pas des montures. Aucun monde existant n'est modifié.
+
+## Vérifications
+
+`ArrivalMount061ClientChecks` passe sur le client natif Minecraft 26.3-pre-2,
+avec un monde plat de développement neuf et une vraie introduction complète :
+
+- absence de musique Minecraft pendant les lettres, lancement au portail,
+  même instance sonore active jusque deux secondes après la fin du flash ;
+- portage vache bébé / dragon miniature sur sept tailles, suppression du
+  ralentissement à la dépose, exemption conservée pour un bébé natif ;
+- Maj + clic droit réellement envoyé au serveur, monte d'une vache colossale,
+  déplacement par les touches du client et orientation du cavalier ;
+- maintien pendant le premier appui sur Maj, démontage après relâchement,
+  nouvelle monte puis retrait de l'œuf sans cavalier orphelin ;
+- allay colossal : montée, descente et collision du cavalier sous un plafond ;
+- morue colossale : mouvement lent à terre, puis vraie nage verticale dans
+  un bassin fermé ; arrêt sonore explicite encore fonctionnel hors arrivée.
+
+Journal : `build/arrival-mount061-client.log`, **1 min 32 s**.
+Marqueurs `ARRIVAL061_MUSIC_PASS` et `ARRIVAL_MOUNT061_PASS`.
+La capture de la vache montée est inspectée dans
+`build/arrival-mount061-evidence/`. Les mêmes règles et modèles natifs couvrent
+les autres espèces, mais leur placement visuel individuel n'a pas été vérifié
+pour chacune des 88 espèces. Les grands familiers ont besoin d'un espace libre
+adapté à leur volume. Aucun essai avec deux clients humains n'est revendiqué.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest
+-PsanctuaryClientTests=true -PsanctuaryArrivalMount061ClientTests=true
+-PsanctuaryQuickTests=true` réussit : **122 tâches**, **3 min 14 s**.
+Le parcours client est exécuté séparément par `:sanctuary:runClientGameTest`
+avec les mêmes propriétés. Aucun EULA de serveur dédié n'a été accepté.
+
+## Archives locales
+
+- [Pack normal](../build/Sanctuary-beta.061.mrpack), 5676845 octets.
+  SHA-256 : `c97424d94b2e2960c071795670cbc1300cf5a805c4dadbfa5dad33fccb79edbb`.
+- [Monde plat rapide](../build/Sanctuary-Test-beta.061.mrpack), 5695778 octets.
+  SHA-256 : `2c3a9c3cfa849a3f24c38ceaf112ef4a96f6b182faa99d1eb78f00f8f2293c63`.
+
+Les **1623 classes** du mod embarqué sont conformes au build. Le reçu
+`build/arrival-mount061-artifact.json` vérifie les ressources, les dépendances
+imbriquées, les différences ciblées avec beta.060 et la conservation des
+archives précédentes. JEI et les ressources de génération restent identiques.
+Aucun canal publié, instance personnelle ou monde existant n'est modifié.

docs/audit-berges-beta165.md

@@ -0,0 +1,137 @@
+# Audit du support naturel des berges — beta.165
+
+## Verdict
+
+L’échec initial est une **attente de test antérieure aux ouvertures de berges
+alpha.30**, avec une confiance très forte. La cellule signalée n’est pas une
+terrasse sèche avec sédiments : c’est la deuxième ouverture `Kind.OUTLET` du
+plan régional. Son absence de fondation est intentionnelle. Aucune modification
+de génération n’est recommandée pour faire passer cette assertion.
+
+Ce diagnostic ne démontre pas que le reste du test passe : celui-ci échoue dès
+la préparation, avant sa vérification des blocs après décoration et ticks.
+Aucun monde, chunk, fichier de production ou test partagé n’a été modifié pour
+cet audit. Aucun serveur ni JVM supplémentaire n’a été lancé.
+
+## Preuves et chaîne de traitement
+
+1. `build/beta165-check-build.log:962` signale, au tick 0 :
+   `Cell[x=-141, z=-86, waterY=-1, bedY=238, carveTop=241, material=STONE,
+   featureId=15307446929, sedimentDepth=0]`.
+2. `PopulationHydrologyRuntime.regionPlan` construit un plan classique admis,
+   puis applique `BankOutlets30.openBanks` pour les réglages `unified_5/10/20`.
+   La densité vient du même `finalDensity` et du même `RandomState` que le
+   diagnostic, via un mémo de signe. Les coordonnées locales sont translatées
+   avec l’origine régionale. Dans la région `(0,0)`, cette translation est nulle.
+3. `BankOutlets30.java:30–45` cherche le vide à 1–5 blocs d’un bassin et crée
+   des cellules sèches de profondeur de sédiments zéro, classées `OUTLET`.
+   Ces cellules n’ajoutent ni roche ni eau : elles décrivent la coupe de la berge.
+4. Recalcul indépendant des opérations entières 64 bits en Python, sans moteur
+   Minecraft : pour graine 0 et région `(0,0)`, la graine régionale non signée vaut
+   `12661893618221475390`; la base des identifiants de sorties vaut
+   `15307446928`. L’identifiant en échec vaut exactement base + 1, donc la
+   deuxième sortie (index 1). Ce calcul renforce l’identification par
+   `sedimentDepth=0`, au lieu de la supposer depuis le nom du test.
+5. `PopulationHydrologyRuntime.apply` exclut explicitement `plan.isOutletCell`
+   de la validation des deux couches de support. Sa boucle de sédiments ne fait
+   aucune écriture avec profondeur zéro ; la boucle de coupe supprime les blocs
+   entre `bedY+1` et `carveTop`. L’eau se propage ensuite par les ticks vanilla.
+6. `PopulationDiagnostics.checkOwnership:333–344` applique au contraire la
+   densité positive à **toutes** les cellules, donc impose ici une fondation à
+   Y237 et Y238. C’est précisément la contrainte absente du contrat des sorties.
+7. Le contrat publié dans `docs/generation-alpha30.md`, section Hydrologie,
+   autorise une chute dans le vide et précise l’absence de fondation ou de
+   colonne d’eau artificielle. `River30Smoke.java:23–24` vérifie déjà profondeur
+   zéro et absence de nouvelle source. Ce smoke a passé dans le journal beta.165
+   (lignes 453–454).
+
+La documentation Java de `PopulationHydrology.Cell:53` décrit encore seulement
+les cellules sédimentaires : elle mérite une clarification future pour le cas
+OUTLET, mais ne prévaut pas sur le contrat alpha.30 ni son implémentation dédiée.
+
+## Adaptation ciblée proposée
+
+Le patch préparé dans `build/audit-berges.patch` ne change que
+`PopulationDiagnostics.checkOwnership`. Il conserve les assertions de région
+et d’appartenance de toutes les cellules. Pour une cellule **explicitement
+classée OUTLET**, il exige :
+
+- aucune source d’eau, aucun sédiment, un intervalle de coupe positif ;
+- un déversement terminal déclaré avec le même identifiant.
+
+Les autres cellules conservent intégralement l’assertion de densité naturelle des
+sédiments et des deux couches de support. Ne pas remplacer ce contrôle par une
+exception générale pour toutes les cellules sèches ou de profondeur zéro.
+
+Le patch reste isolé et non appliqué pour intégration par l’agent principal.
+
+## Reproduction et validation minimales
+
+Le défaut de contrat se reproduit sans monde avec le témoin existant
+`River30Smoke` : la côte synthétique est solide à x≤4 ; la brèche atteint x=5,
+qui est du vide. Exiger un support positif sous cette cellule ferait échouer
+une ouverture intentionnelle que le smoke valide.
+
+Pour confirmer le témoin réel, rejouer le GameTest
+`UnifiedWorldGameTests.retainedHydrologySurvivesNativeDecoration` après application
+ciblée, dans le **monde jetable de tests**, graine 0, population 10, diamètre 724.
+Conserver les vérifications de blocs FULL, de sédiments, de coquille et de ticks.
+La commande et l’ordonnancement seront assurés par l’agent principal pour ne pas
+saturer les 8 Go du Mac. Aucun passage de ce test n’est revendiqué ici.
+
+## Points à surveiller après la première correction
+
+- `verifyFinishedShell:460` impose sédiments 3–5 à ses cellules sélectionnées.
+  La sélection normale porte sur lac/étang/terrasse et exclut les OUTLET ; son
+  fallback prend la première feature. Si une ouverture est sélectionnée à
+  l’avenir, elle nécessitera son propre contrôle de coupe, sans support imposé.
+- Le contrôle de paroi humide reconnaît `isSpillOpening`, qui ne contient que
+  la position terminale. Une ouverture de trois blocs de large peut également
+  créer une paroi ouverte avant ce point. Si cette assertion échoue ensuite,
+  vérifier le voxel contre une cellule OUTLET déclarée et son intervalle exact
+  de coupe ; ne pas désactiver le contrôle de toutes les parois.
+- Le test complet n’a pas encore atteint ses contrôles finaux avec ce patch.
+  Les éventuels nouveaux échecs doivent être diagnostiqués séparément.
+- Les plafonds historiques à Y384 restent présents dans certaines inspections
+  naturelles alors que la dimension atteint Y640. Ils ne causent pas l’échec
+  ici à Y237/238, et ne sont pas modifiés dans ce patch ciblé.
+
+## Fichiers examinés
+
+- `mods/sanctuary/src/main/java/fr/koka/sanctuary/worldgen/BankOutlets30.java`
+- `mods/sanctuary/src/main/java/fr/koka/sanctuary/worldgen/PopulationHydrology.java`
+- `mods/sanctuary/src/main/java/fr/koka/sanctuary/worldgen/PopulationHydrologyRuntime.java`
+- `mods/sanctuary/src/main/java/fr/koka/sanctuary/worldgen/PopulationIslandDensity.java`
+- `mods/sanctuary/src/main/java/fr/koka/sanctuary/worldgen/IslandCapacity.java`
+- `mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/PopulationDiagnostics.java`
+- `mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/River30WorldGameTests.java`
+- `mods/sanctuary/src/test/java/fr/koka/sanctuary/worldgen/River30Smoke.java`
+
+## Complément : contrôle précis de la paroi ouverte
+
+Un second patch non appliqué, `build/audit-berges-shell.patch`, est disponible
+**uniquement si l’exécution atteint un échec de paroi correspondant à une
+ouverture réelle**. Il ajoute un cas au contrôle des parois de
+`verifyFinishedShell`, après ses exceptions existantes pour l’eau planifiée et
+le voxel terminal du spill.
+
+Le voxel doit appartenir au plan de sa propre position X/Z, à une cellule
+explicitement `OUTLET`, sans eau planifiée ni sédiments, associée par son
+identifiant à un spill terminal. Son Y doit être **strictement supérieur à
+bedY et inférieur ou égal à carveTop**. Le bloc final doit alors être de l’air
+ou de l’eau vanilla ; un bloc solide ou de la lave fait toujours échouer le test.
+Les couches sous la coupe, les voisins latéraux hors emprise, les autres types
+de cellules et les voxels au-dessus de la coupe conservent leur contrôle normal.
+
+Le patch parcourt `cellsAt` plutôt que de se fier seulement à `cellAt(x,y,z)` :
+ce dernier inclut aussi les couches de support dans sa sélection, ce qui aurait
+créé une exception trop large. Les assertions sur les sédiments sélectionnés
+restent inchangées. La suite en cours doit décider si ce patch est nécessaire ;
+aucun résultat d’exécution n’est anticipé.
+
+## Résultat de l’intégration
+
+Le patch proposé a ensuite été intégré aux tests par l’agent principal.
+Le rejeu complet `build/test-refresh-full.log` termine avec 252/252 GameTests
+réussis et `check build` réussi. Aucun code de production ni monde existant modifié.
+Voir [la validation consolidée](actualisation-tests-beta165.md).

docs/audit-construction-beta165.md

@@ -0,0 +1,98 @@
+# Audit ciblé — construction groupée sur dalle et coffre
+
+Audit du 24 septembre 2026, sources beta.165. Aucun changement de production,
+aucun monde lancé ou modifié, aucune nouvelle exécution de GameTest dans cet audit.
+
+## Conclusion
+
+Les deux refus initiaux ont une explication commune de **fixture hors portée**, avec
+une confiance forte : le rayon de visée s’arrête à 3,5 blocs avant la surface réelle.
+Ils ne démontrent ni une fusion de dalle cassée, ni une altération du contenu du coffre.
+Les assertions suivantes restent à rejouer ; elles ne sont pas déclarées réussies.
+
+Le contrat beta.009 utilisait la portée native, tandis que le contrat actuel
+[beta.081](build-reach-beta081.md) fixe le rang 1 à 3,5 blocs. Le même point de vue
+atteint encore un cube plein, mais pas les surfaces plus basses.
+
+## Chaîne de refus
+
+- `Building009GameTests.java:107–113` : plan 3×3 de dalles basses ; joueur au rang 1 ;
+  `aim` place ses pieds en `(0,5 ; 1 ; −2,5)` par rapport à l’origine, puis vise
+  `(0,5 ; 0,5 ; 0,5)`.
+- `Building009GameTests.java:165–170` : coffre central et pierre autour ; même position,
+  mais `aim` conserve la cible d’un cube plein `(0,5 ; 1 ; 0,5)`.
+- `BuildReach.java:13–21` et `BuildingLimits.java:6` : portée 3,5 ; le contrôle préalable
+  de proximité utilise l’AABB du **bloc entier**, pas la forme de la dalle/coffre.
+- `BuildSelection.java:40–44` : `player.pick(3.5, 1, false)` doit réellement toucher
+  le bloc d’origine. Un MISS ou un autre bloc donne `null`.
+- `BuildingSession.java:26–30` : ce `null` empêche de créer la session, avant tout
+  placement, fusion ou usage du coffre.
+- Le journal existant `build/beta165-check-build.log:1105–1138` confirme les refus
+  à `start`, lignes 113 et 170 des tests, au tick 0.
+
+## Géométrie vérifiée
+
+Les constantes natives ont été inspectées par `javap -c -p` dans le JAR local exact
+Minecraft 26.3 : `Avatar` définit les yeux debout à 1,62 ; `SlabBlock` utilise
+`column(16,0,8)` pour la dalle basse ; `ChestBlock` utilise `column(14,0,14)` pour
+le coffre simple. Traces dans `build/audit-construction-avatar-bytecode.txt` et
+`build/audit-construction-native-bytecode.txt`. Aucun serveur/JVM Minecraft lancé.
+
+Les yeux sont donc en **E=(0,5 ; 2,62 ; −2,5)**. Calculs Python indépendants du jeu :
+
+| Surface et visée actuelle | Premier impact géométrique prévu | Distance yeux-impact |
+|---|---|---:|
+| Cube plein témoin | `(0,5 ; 1 ; 0,5)` | 3,409457 |
+| Dalle basse, visée corrigée sur son dessus | `(0,5 ; 0,5 ; 0,5)` | **3,673472** |
+| Coffre, visée restée au dessus d’un cube plein | `(0,5 ; 0,875 ; 0,731481)` | **3,672533** |
+
+Le coffre occupe horizontalement `[1/16 ; 15/16]`, donc ce point est bien dans son
+dessus. Les cubes de pierre voisins ne coupent pas ce rayon avant lui : à `y=1`,
+le rayon est déjà au centre de la cellule d’origine. Les autres dalles basses ne
+coupent pas davantage le rayon avant `y=0,5`. Le précontrôle AABB entier passe,
+avec une distance minimale de 2,978993 : il ne garantit pas que le rayon atteigne
+la forme réelle.
+
+L’écart d’environ 0,173 bloc dépasse largement les arrondis float de la direction
+et de la hauteur des yeux. Ces calculs expliquent le refus dans les deux fixtures ;
+une trace native reste utile pour confirmer explicitement le MISS en exécution.
+
+## Correction recommandée, limitée aux tests
+
+Patch proposé, **non appliqué** : `build/audit-construction.patch`.
+
+Le helper dédié `aimInsetTop` rapproche les pieds à `z=−1,5`, conserve `y=1` et
+vise le centre du dessus réel (`y=0,5` pour la dalle, `14/16` pour le coffre).
+Les distances deviennent respectivement **2,914515** et **2,654247** blocs.
+Le joueur reste hors du plan 3×3 (son bord proche est vers `z=−1,2`, le plan
+commence à `z=−1`) afin de ne pas exclure une pose par sa propre collision.
+Une assertion explicite vérifie que le rayon atteint la face UP avant le démarrage.
+
+Toutes les assertions métier existantes restent : neuf consommations/fusion,
+dalles de plafond, exclusion de la vache, trois diamants conservés, menu fermé,
+refus des objets à placement particulier. Aucun changement de portée de production,
+aucune suppression de test, aucun passage en créatif pour masquer le problème.
+
+## Protocole ciblé restant
+
+1. Relire/appliquer le patch de tests sur une branche de correction coordonnée.
+2. Rejouer la famille `building` dans un monde GameTest jetable, avec le filtre
+   du dépôt `-PsanctuaryFocusedTests=building`, après libération de la mémoire du
+   laboratoire. Ne pas exécuter en parallèle plusieurs serveurs sur le Mac 8 Go.
+3. Si un refus subsiste, tracer yeux, portée, `player.pick(...)`, bloc/face/distance,
+   `BuildSelection.aimed`, puis nombre de cibles : ne pas augmenter arbitrairement
+   la portée ou neutraliser une validation.
+4. Confirmer les assertions suivantes : une fois la première barrière levée, des
+   défauts secondaires peuvent devenir visibles. Garder un scénario séparé de refus
+   hors portée à la limite, sans le confondre avec fusion ou conservation d’objets.
+
+Risque du patch faible et limité à la géométrie de test. Risque de modifier la
+production maintenant inutilement élevé : cela modifierait le contrat de portée
+pour contourner un scénario préparé avec l’ancien contrat.
+
+## Résultat de l’intégration
+
+Le patch proposé a ensuite été intégré aux tests par l’agent principal.
+Le rejeu complet `build/test-refresh-full.log` termine avec 252/252 GameTests
+réussis et `check build` réussi. Aucun code de production ni monde existant modifié.
+Voir [la validation consolidée](actualisation-tests-beta165.md).

docs/audit-dragon-beta165.md

@@ -0,0 +1,79 @@
+# Audit dragon — beta.165
+
+## Verdict
+
+L’échec de `Companion019GameTests.creatureProfilesActuallyMove` est expliqué par
+une simulation incomplète du cycle natif de l’entité. Il ne démontre pas un
+blocage du dragon en jeu. Aucune correction de locomotion ne se justifie avant
+le rejeu du scénario avec son horloge d’entité effective.
+
+## Chaîne causale confirmée
+
+1. [Le test](../mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Companion019GameTests.java)
+   appelle `pet.tick()` 120 fois immédiatement, au tick GameTest 0. Le journal
+   `build/beta165-check-build.log` confirme l’assertion de déplacement échouée au tick 0.
+2. Dans Minecraft **26.3**, `ServerLevel.tickNonPassenger(Entity)` appelle
+   **`Entity.commonTick()` puis `Entity.tick()`**. L’incrément `tickCount++` se trouve
+   dans `commonTick`, avec la mise à jour des anciennes positions et du délai
+   d’invulnérabilité ; il ne se trouve pas dans `Entity.tick()` ou `baseTick()`.
+   Vérification directe du bytecode du JAR natif local par `javap -c -p` :
+   `build/audit-dragon-serverlevel.txt` (méthode `tickNonPassenger`),
+   `build/audit-dragon-entity.txt` (méthode `commonTick`).
+3. Au premier tick, [FamiliarEntity.configureMotion](../mods/sanctuary/src/main/java/fr/koka/sanctuary/cosmetics/FamiliarEntity.java)
+   choisit `FlyingPathNavigation`, `FlyingMoveControl`, désactive la gravité et
+   appelle `stopRoaming()`.
+4. [FamiliarRoam.reset](../mods/sanctuary/src/main/java/fr/koka/sanctuary/familiar/FamiliarRoam.java)
+   fixe `nextChoice = pet.tickCount + 20`. L’errance lit **pet.tickCount**, pas
+   `level.getGameTime()`. Les 120 appels directs laissent donc `now = 0` et
+   `nextChoice = 20`. La condition `if(now < nextChoice) return` interdit toute
+   première destination.
+5. Le familier apparaît déjà près du joueur, à environ +2 blocs en Y grâce à
+   `teleportNearOwner`. Il n’atteint pas le seuil de retour vers le propriétaire
+   qui pourrait contourner cette attente. Aucun déplacement vers une destination
+   n’est donc engagé dans ce scénario.
+
+L’hypothèse initiale d’une simple dépendance au temps du monde était trop vague :
+la cause directe est l’absence de **commonTick**, et donc le compteur d’entité figé.
+
+## Correction de test recommandée
+
+Pour ce test synchrone de locomotion, remplacer les appels de simulation par
+`h.getLevel().tickNonPassenger(pet)` ; cela reproduit le préambule natif complet,
+contrairement à un simple `pet.tickCount++`. Conserver les assertions sur le profil,
+le déplacement supérieur à un bloc, l’altitude et l’absence de collision.
+Ajouter une assertion du nombre de ticks réellement avancés afin d’éviter une
+régression de la fixture. Rejouer les vérifications Ghast et Wither, masquées
+jusqu’ici par l’échec dragon.
+
+Le correctif proposé est disponible dans `build/audit-dragon.patch`, sans avoir
+été appliqué aux sources par cet audit. Cette boucle reste synchrone : le temps
+du monde, les hooks serveur et le propriétaire ne progressent pas. Elle vérifie
+le cycle de locomotion de l’entité, pas une séance complète de suivi en jeu.
+
+Un scénario supplémentaire de suivi en ticks réels est utile si ce premier rejeu
+échoue : propriétaire déplacé sans dépasser le seuil de téléportation, personnage
+et graine d’errance fixés, trajet effectivement parcouru contrôlé. Il doit vivre
+dans un monde de test jetable, jamais dans la sauvegarde du laboratoire.
+
+## Aléa et limites
+
+Le tempérament provient du UUID du lien, créé aléatoirement. Les rayons d’errance
+sont 2,5 / 4 / 5 blocs et les pauses 100–139 / 25–64 / 50–89 ticks. Ces pauses
+sont intentionnelles : ne pas imposer un mouvement à chaque tick. Pour une
+reproduction déterministe, fixer la graine du générateur de l’entité et le
+tempérament dans les données du test, ou tester explicitement les trois.
+
+Les destinations nécessitent des chunks chargés, une autorisation de mouvement,
+un volume libre et un chemin accessible. Aucun de ces refus n’a été démontré
+ici : l’ancien scénario s’arrêtait **avant** leur évaluation.
+
+Audit statique et lecture du bytecode terminés. À ce stade, aucun serveur de test
+supplémentaire lancé, aucune source de jeu modifiée, aucune sauvegarde touchée.
+Le passage effectif du test corrigé reste à confirmer dans l’exécution coordonnée.
+
+## Résultat de l’intégration
+
+Le patch proposé a ensuite été intégré aux tests par l’agent principal.
+Le rejeu complet `build/test-refresh-full.log` termine avec 252/252 GameTests
+réussis et `check build` réussi. Aucun code de production ni monde existant modifié.
+Voir [la validation consolidée](actualisation-tests-beta165.md).

docs/audit-echecs-beta165.md

@@ -0,0 +1,100 @@
+# Audit des 23 échecs GameTest — socle beta.165
+
+Audit initial du 24 septembre 2026, code `dbb9e34` (tag beta.165).
+
+Suite : [actualisation des tests et validation](actualisation-tests-beta165.md).
+
+## Portée et méthode
+
+Lecture des 23 messages du dernier journal `build/beta165-check-build.log`, des
+méthodes de test et des chemins de production concernés. La liste a été comparée
+à beta.164 : mêmes 23 identifiants. Recompte local des JSON de collections.
+Aucun test désactivé, aucune correction de code, aucune modification du monde,
+aucun nouveau lancement Minecraft pendant cet audit. Le laboratoire reste disponible.
+
+Il s’agit d’un diagnostic statique étayé par l’exécution précédente, pas d’une
+preuve que les tests passeront après adaptation. Un échec à la première assertion
+masque potentiellement des problèmes dans la suite de la même méthode.
+
+## Conclusion
+
+**19 échecs ont une explication étayée dans le scénario de test ou un ancien
+contrat ; 4 nécessitent encore une reproduction ciblée.** Ce ne sont donc pas
+23 bugs joueurs démontrés. Inversement, la stabilité de la liste ne prouve pas
+l’absence de bugs. Les objectifs des tests restent majoritairement pertinents.
+
+| Famille | Nombre | Lecture principale |
+| --- | ---: | --- |
+| Placement simple / empreinte / tombe | 5 | Positions de test hors portée |
+| Menus d’inventaire | 3 | Constructeur incompatible avec les menus étendus |
+| Bonus de familiers | 6 | Mode travail absent des fixtures |
+| Invulnérabilité et poisson familier | 2 | Anciennes règles remplacées par le système de combat |
+| Collections, permissions, hauteur du monde | 3 | Attentes historiques à remettre à jour |
+| Construction dalle/coffre | 2 | Raycast et portée à instrumenter |
+| Déplacement du dragon | 1 | Ticks réels et navigation à reproduire |
+| Hydrologie | 1 | Contrat de support naturel à examiner |
+
+## Inventaire exhaustif
+
+| Test | Verdict | Preuve et limite | Suite pertinente |
+| --- | --- | --- | --- |
+| [BlockKnowledgeGameTests.placementCountsConfirmedStatesAndRejectsFailure](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/BlockKnowledgeGameTests.java:44) | Test mal positionné — forte confiance | Joueur en (5,5 ; 3 ; 5,5), support en (1 ; 1 ; 1) : la distance horizontale seule dépasse 5,65 blocs. Le mixin de placement applique la portée réelle (vanilla ou progression), avant les assertions métier. | Rapprocher le joueur et viser la face réelle ; conserver les assertions de compteurs, événements et empreinte. Ajouter/conserver un cas hors portée refusé. |
+| [BlockKnowledgeGameTests.listenersReceiveUpdatedProgressionAndStockChanges](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/BlockKnowledgeGameTests.java:220) | Test mal positionné — forte confiance | Joueur en (5,5 ; 3 ; 5,5), support en (1 ; 1 ; 1) : la distance horizontale seule dépasse 5,65 blocs. Le mixin de placement applique la portée réelle (vanilla ou progression), avant les assertions métier. | Rapprocher le joueur et viser la face réelle ; conserver les assertions de compteurs, événements et empreinte. Ajouter/conserver un cas hors portée refusé. |
+| [MaterialActivityGameTests.nativeActionsProduceDatedDeltasWhileObservationsProduceNone](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/MaterialActivityGameTests.java:39) | Test mal positionné — forte confiance | Joueur en (5,5 ; 3 ; 5,5), support en (1 ; 1 ; 1) : la distance horizontale seule dépasse 5,65 blocs. Le mixin de placement applique la portée réelle (vanilla ou progression), avant les assertions métier. | Rapprocher le joueur et viser la face réelle ; conserver les assertions de compteurs, événements et empreinte. Ajouter/conserver un cas hors portée refusé. |
+| [Demeure006GameTests.confirmedGesturesAndPersonalAtlasBoundary](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Demeure006GameTests.java:20) | Test mal positionné — forte confiance | Joueur en (5,5 ; 3 ; 5,5), support en (1 ; 1 ; 1) : la distance horizontale seule dépasse 5,65 blocs. Le mixin de placement applique la portée réelle (vanilla ou progression), avant les assertions métier. | Rapprocher le joueur et viser la face réelle ; conserver les assertions de compteurs, événements et empreinte. Ajouter/conserver un cas hors portée refusé. |
+| [GravesFood038GameTests.ordinaryPlacementAndCreativeBreakPreserveGrave](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/GravesFood038GameTests.java:120) | Test mal positionné — forte confiance | Joueur novice à 3 blocs horizontalement du clic, yeux au-dessus : distance supérieure aux 3 blocs de portée initiale. Le test échoue avant la conservation des composants et la casse créative. | Remettre le clic à portée, puis vérifier impérativement les 8 diamants après pose et casse ; le résultat actuel ne prouve aucune perte d’objets. |
+| [Inventory010GameTests.machineQuickMovesAndMounts](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Inventory010GameTests.java:77) | Initialisation de test incompatible — certaine | Boucle sur tout BuiltInRegistries.MENU et appel create(id, inventory). Des menus Sanctuary sont ExtendedMenuType et exigent des données supplémentaires ; exception avant les comparaisons. | Séparer menus vanilla et menus étendus ; fournir les données requises aux menus Sanctuary, garder les tests de conservation et de shift-clic. |
+| [Inventory010GameTests.everyNativeContainerKeepsItsIndices](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Inventory010GameTests.java:58) | Initialisation de test incompatible — certaine | Boucle sur tout BuiltInRegistries.MENU et appel create(id, inventory). Des menus Sanctuary sont ExtendedMenuType et exigent des données supplémentaires ; exception avant les comparaisons. | Séparer menus vanilla et menus étendus ; fournir les données requises aux menus Sanctuary, garder les tests de conservation et de shift-clic. |
+| [Inventory012GameTests.nativeAndExtraRowsHaveIdenticalMachinePriorities](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Inventory012GameTests.java:38) | Initialisation de test incompatible — certaine | Même boucle sur tous les menus et même constructeur sans données réseau. | Même adaptation commune ; comparer les destinations et reliquats des lignes natives et supplémentaires. |
+| [Companion019GameTests.switchingEggRemovesPassiveAndActive](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Companion019GameTests.java:45) | Contrat du scénario périmé — forte confiance | L’attribut de chute du chat n’est pas actif dans le mode de combat par défaut. Le helper equip règle l’attunement, mais FamiliarBattle.prepare initialise workMode=false ; CompanionService.passive renvoie alors null. | Préparer explicitement le mode travail par le chemin prévu, puis tester aussi l’absence de bonus en mode combat. Rejouer le reste du scénario : ses assertions suivantes restent non validées. |
+| [Companion019GameTests.poisonDurationAndMilkUseNativeHooks](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Companion019GameTests.java:53) | Contrat du scénario périmé — forte confiance | La réduction de poison est attendue sans sélectionner le mode travail. Le helper equip règle l’attunement, mais FamiliarBattle.prepare initialise workMode=false ; CompanionService.passive renvoie alors null. | Préparer explicitement le mode travail par le chemin prévu, puis tester aussi l’absence de bonus en mode combat. Rejouer le reste du scénario : ses assertions suivantes restent non validées. |
+| [Companion019GameTests.cropCyclesStopAfterOwnerLeaves](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Companion019GameTests.java:152) | Contrat du scénario périmé — forte confiance | La préparation BEE n’active pas le mode travail nécessaire au bonus de culture. Le helper equip règle l’attunement, mais FamiliarBattle.prepare initialise workMode=false ; CompanionService.passive renvoie alors null. | Préparer explicitement le mode travail par le chemin prévu, puis tester aussi l’absence de bonus en mode combat. Rejouer le reste du scénario : ses assertions suivantes restent non validées. |
+| [Companion019GameTests.furnaceBonusConsumesFuelAndKeepsOneOutput](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Companion019GameTests.java:163) | Contrat du scénario périmé — forte confiance | La préparation BLAZE n’active pas le mode travail nécessaire au bonus de cuisson. Le helper equip règle l’attunement, mais FamiliarBattle.prepare initialise workMode=false ; CompanionService.passive renvoie alors null. | Préparer explicitement le mode travail par le chemin prévu, puis tester aussi l’absence de bonus en mode combat. Rejouer le reste du scénario : ses assertions suivantes restent non validées. |
+| [Companion032GameTests.axolotlFoodDurationAndGolemKnockbackUseNativeHooks](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Companion032GameTests.java:77) | Contrat du scénario périmé — forte confiance | Le bonus de durée de consommation est attendu hors du mode autorisant les anciens passifs. Le helper equip règle l’attunement, mais FamiliarBattle.prepare initialise workMode=false ; CompanionService.passive renvoie alors null. | Préparer explicitement le mode travail par le chemin prévu, puis tester aussi l’absence de bonus en mode combat. Rejouer le reste du scénario : ses assertions suivantes restent non validées. |
+| [GravesFood038GameTests.familiarSaturationPreviewUsesActualServerPassive](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/GravesFood038GameTests.java:130) | Contrat du scénario périmé — forte confiance | L’assertion passive(p)==species échoue avant de comparer l’aperçu et la consommation. Le helper equip règle l’attunement, mais FamiliarBattle.prepare initialise workMode=false ; CompanionService.passive renvoie alors null. | Préparer explicitement le mode travail par le chemin prévu, puis tester aussi l’absence de bonus en mode combat. Rejouer le reste du scénario : ses assertions suivantes restent non validées. |
+| [Accessory018GameTests.familiarIsHarmlessAndEscapesWalls](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Accessory018GameTests.java:82) | Ancien contrat invulnérable — forte confiance | Le test exige que genericKill ne cause aucun dégât. hurtServer délègue désormais à FamiliarBattle.hurt ; le système possède santé et K.-O. depuis beta.054. | Remplacer l’invulnérabilité universelle par les règles actuelles : dégâts autorisés, coups amicaux, K.-O., œuf préservé. Conserver les vérifications de collisions, sortie de mur et non-duplication. |
+| [Companion019GameTests.aquaticPetFlopsAndThenSwims](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Companion019GameTests.java:113) | Ancien contrat de déplacement — forte confiance | Le test exige une vitesse ≤ 0,06 sur terre. configureMotion réserve le mode poisson ralenti aux familiers aquatiques sans profil de combat actif ; sinon la vitesse vient du profil. | Tester séparément le profil actuel sur terre et la transition dans l’eau. Ne pas rétablir automatiquement l’ancien poisson ralenti. |
+| [Companion019GameTests.creatureProfilesActuallyMove](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Companion019GameTests.java:104) | À isoler — navigation | Le profil aérien est reconnu ; c’est le déplacement > 1 et l’altitude > propriétaire + 0,5 qui échouent. Le test appelle pet.tick 120 fois sans faire avancer normalement le monde ; l’errance actuelle dépend de destinations sûres, du pathfinding et comporte des pauses. | Reproduire dans un monde de test avec ticks réels, graine/personnalité fixées, propriétaire déplacé, cible et chemin enregistrés. Si l’immobilité persiste, corriger la navigation. |
+| [Collections035GameTests.exhaustiveCatalogueMatchesLoadedVanilla](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Collections035GameTests.java:17) | Constantes périmées — certaine | Le dernier comptage attend 1658 items / 1286 blocs / 1815 identifiants distincts. Recompte des 67 JSON : 1780 / 1374 / 1937. Les 2042 recettes uniques sont toujours présentes ; le test a déjà passé les contrôles précédents des identifiants et recettes. | Comparer la couverture aux registres et au contrat de collections ; documenter les nombres actuels, éviter qu’un total historique soit l’unique preuve d’exhaustivité. |
+| [Progression003GameTests.serverCustomNameConfiguration](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Progression003GameTests.java:120) | Permission testée au mauvais niveau — certaine | Le test exige que toute la racine /sanctuary soit inaccessible aux joueurs. intro et community link sont maintenant publics ; names et community admin portent leur propre condition opérateur. | Tester un joueur ordinaire et un opérateur sur chaque sous-commande sensible. Vérifier names reload en particulier ; ne pas rebloquer toute la racine. |
+| [UnifiedWorldGameTests.populationTerrainAndNaturalSpawnRemainPresent](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/UnifiedWorldGameTests.java:56) | Hauteur historique périmée — certaine | Attend minY=0 et hauteur=384. La dimension Sanctuary actuelle déclare hauteur et logical_height=640, minY=0 ; le test client de création attend lui aussi 640. | Actualiser le contrat de hauteur, puis rejouer les assertions suivantes sur le spawn naturel. Ne pas modifier la dimension ni les mondes existants. |
+| [Building009GameTests.slabMergingCeilingAndEntityCollisions](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Building009GameTests.java:107) | À isoler — construction groupée | Échec au premier start (ligne 113), avant fusion des dalles. Le fixture vise le centre d’une dalle basse depuis une position conçue pour un cube plein ; la portée au rang 1 est 3,5 et le point visé sur la dalle est plus éloigné. | Journaliser hit réel, bloc touché, distance, portée et raison de refus ; reproduire à portée courte puis à la limite. Conserver fusion, plafond et exclusion des entités. |
+| [Building009GameTests.containerSupportsAndUnsupportedItems](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/Building009GameTests.java:165) | À isoler — construction groupée | Échec au premier start sur coffre (ligne 170), avant toute vérification du contenu. Le coffre n’a pas la collision d’un cube plein ; le raycast peut toucher le support voisin ou dépasser la portée. | Même diagnostic que la dalle ; vérifier que le coffre ne s’ouvre pas et garde ses 3 diamants. Ne pas assimiler l’échec à une corruption d’inventaire. |
+| [UnifiedWorldGameTests.retainedHydrologySurvivesNativeDecoration](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/UnifiedWorldGameTests.java:39) | À isoler — génération, priorité haute | Échec dans PopulationDiagnostics.checkOwnership sur la densité naturelle du support à x=-141, z=-86, bedY=238, sedimentDepth=0, waterY=-1 (terrasse sèche). Ce contrôle survient avant la vérification finale des blocs décorés ; son nom ne prouve donc pas une fuite d’eau en jeu. | Comparer l’admission de cette cellule et la densité réellement utilisée, puis les blocs finaux dans un monde jetable, graine 0 / 10 joueurs / diamètre 724. Le contrat Cell annonce un support naturel : ne pas supprimer cette assertion sans explication. |
+
+## Priorités proposées
+
+1. **Remettre les tests en mesure de vérifier leur sujet** : placements à portée,
+   construction correcte des menus, sous-commandes protégées, inventaire de
+   collections et hauteur 640. Changements de tests ciblés, sans affaiblir leurs
+   vérifications métier. Les tombes et transferts d’inventaire sont prioritaires
+   parce qu’ils protègent les objets des joueurs.
+2. **Isoler dalle/coffre et hydrologie** : les deux premiers concernent une action
+   courante ; le dernier touche la génération et exige un monde jetable, jamais
+   une régénération de la sauvegarde de test actuelle. Aucun changement de
+   génération n’est autorisé implicitement par cet audit.
+3. **Actualiser les scénarios familiers** selon le mode travail/combat, puis
+   reproduire le vol du dragon avec une horloge de monde réelle. Garder les
+   contrôles d’anti-duplication, de ressources consommées et d’annulation.
+4. Rejouer les familles corrigées, puis la suite complète. Toute nouvelle
+   assertion atteinte doit être réévaluée ; ne pas annoncer « 19 réglés » avant cela.
+
+La correction des fixtures et constantes paraît contenue. Les quatre cas à
+reproduire ne permettent pas encore une estimation fiable. Aucune suppression de
+fonctionnalité ni suppression de test n’est recommandée à ce stade.
+
+## Points d’entrée dans le code
+
+- [BlockPlacementReachMixin](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/main/java/fr/koka/sanctuary/mixin/BlockPlacementReachMixin.java:14)
+- [BuildingLimits](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/main/java/fr/koka/sanctuary/building/BuildingLimits.java:6)
+- [CompanionService](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/main/java/fr/koka/sanctuary/companion/CompanionService.java:71)
+- [FamiliarBattle](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/main/java/fr/koka/sanctuary/familiar/FamiliarBattle.java:125)
+- [FamiliarEntity](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/main/java/fr/koka/sanctuary/cosmetics/FamiliarEntity.java:262)
+- [FamiliarRoam](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/main/java/fr/koka/sanctuary/familiar/FamiliarRoam.java:16)
+- [Statuary](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/main/java/fr/koka/sanctuary/plans/Statuary.java:39)
+- [Multiblocks](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/main/java/fr/koka/sanctuary/multiblock/Multiblocks.java:36)
+- [ProgressionService](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/main/java/fr/koka/sanctuary/progression/ProgressionService.java:178)
+- [PopulationDiagnostics](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/gametest/java/fr/koka/sanctuary/gametest/PopulationDiagnostics.java:333)
+- [PopulationHydrology](/Users/koka/Documents/sanctuary/sanctuary-community-beta154/mods/sanctuary/src/main/java/fr/koka/sanctuary/worldgen/PopulationHydrology.java:56)
+
+Contrat fonctionnel des familiers : [beta.054](familiar-combat-beta054.md).

docs/backlog.md

@@ -1,5 +1,398 @@
 # Backlog Sanctuary
 
+## APT-237 — achats permanents et intégration Pause — livré localement
+
+Branche `codex/progression-aptitudes`, travaux beta.235 et beta.236 réunis.
+Cinq thèmes, douze aptitudes ; seuls World Map et Mob Names ont un interrupteur.
+Enchantement et Alchimie restent à acheter avant l'accès personnel au poste.
+[Contrat et migration](aptitudes-beta237.md) des préférences antérieures,
+avec conservation des achats et de l'XP. Build, 37 GameTests requis,
+Vulkan FR/EN GUI 2/3/4 et MRpack local vérifiés. La forgerie attend ses précisions.
+
+## PAUSE-235 — groupes côte à côte avant Atlas — essai livré localement
+
+Branche `codex/pause-columns-beta235`, base beta.234. Avant Atlas : Aventure à
+gauche, Communauté à droite et Game juste dessous, bloc centré. Avec Atlas :
+une colonne étroite à gauche dans l'ordre Communauté → Aventure → Game,
+carte centrale et fils à droite. [Contrat et vérifications](pause-columns-beta235.md),
+parcours Vulkan Pause et Story FR/EN GUI 2/3/4, build, quatre GameTests ciblés
+et MRpack local vérifiés ; rendu à apprécier.
+Commit de disposition `a7bdfe6` séparé des métadonnées pour permettre son retour.
+
+## STORY-234 — recueil personnel avec recherche — livré localement
+
+Branche `codex/story-beta234`, base beta.233. Story sous Progression dans
+Aventure ; 100 histoires inconnues, barre de recherche et filtre de découverte.
+Cadre commun avec Discovery, état de recherche et défilement conservés au
+redimensionnement, accès avant et après Atlas. [Résultat et vérifications](story-beta234.md) :
+build, quatre GameTests requis et parcours Vulkan FR/EN GUI 2/3/4 réussis.
+[Modèle Markdown](story/TEMPLATE.md) pour les textes de l'auteur.
+Les récits et leurs conditions de découverte restent des tickets suivants ;
+aucun moteur de quête, format persistant ou déploiement ajouté.
+
+## WG-RESTORE-191 — annuler les plateaux et leurs affleurements
+
+La visite beta.190 ne valide pas le relief corrigé. [Retour exact à la base
+beta.188](restore-relief-beta191.md), pour la densité et la géologie naturelle.
+Conserver les aménagements indépendants ; réserver les futures singularités
+de relief à quelques endroits. Nouveau profil `original` ; 134 480 densités
+comparées à l’identique, génération/réouverture et 265 GameTests réussis.
+
+## WG-NATURE-190 — revenir au relief organique
+
+Retour beta.189 : [contrat beta.190](natural-refinement-beta190.md). Relief local
+adouci, sortie d’étang large et proche, coffres de fer enchanté dans les ruines.
+Profil neuf de laboratoire ; génération, réouverture, 265 GameTests et assemblages
+validés. Solo Vulkan ouvert à 32 chunks.
+
+## Réserve d’expansion — grandes surfaces ciselées
+
+Conserver la variante de terrasses beta.189 comme piste pour une autre expansion :
+grands plateaux, falaises étagées, profondeurs et verticalité variables selon
+l’identité de l’île. Ne plus appliquer ces niveaux partout sur Sanctuary Island.
+Aucune expansion activée. Le portail à remplissage avec ressource renouvelable
+reste à concevoir ; les perles d’Ender sont une possibilité, pas une décision.
+
+## WG-ECO-177 — écologie liée au relief
+
+Branche `codex/relief-ecology-beta177`. Nouveau solo à 32 chunks demandé
+après la visite beta.176 : plateau forestier/fleuri, vallées automnales,
+hauteurs à cerisiers, cavités humides arborées, retrait de la neige et de
+la mangrove, pierres mêlant strates et gisements. Profil de labo distinct ;
+[contrat et vérifications](relief-ecology-beta177.md).
+
+## WG-ECO-176 — strates, biomes et mares locales
+
+Branche `codex/island-ecology-beta176`. Le créateur autorise la mise à
+l’essai des [retours de visite](worldgen-retours-beta175.md). Nouveau monde
+de labo, relief conservé ; géologie continue, larges régions automne et
+cerisiers, récifs humides et mares bornées. Aucun mineshaft ni village
+natif. Prototype jouable, mesures natives validées sur trois graines.
+[Contrat, résultats et réserve sur la suite générale](island-ecology-beta176.md).
+
+## WG-SKY-175 — récifs rares et ressources de l’île
+
+Suite du labo rapide : l’île principale est conservée, les anciennes masses
+flottantes sont remplacées et la bande 512–640 reste libre pour l’ISS. Le
+créateur demande des relevés scientifiques, puis précise la répartition
+des minerais et la présence de deepslate. Nouveau monde de labo uniquement.
+[Contrat et résultats](sky-fragments-beta175.md).
+
+## WG-LAB-174 — worldgen rapide en laboratoire
+
+**Priorité demandée pendant la séance du 29 septembre.** Profil de relief
+réservé aux nouveaux mondes de labo, sans plans d'hydrologie ni structures,
+avec une référence complète séparée et des mesures reproductibles. La
+génération normale reste inchangée. [Contrat et mesures](worldgen-lab-beta174.md).
+Ce lot précède les maquettes de halte du Storyquest : l'outil d'itération
+permet de reprendre d'abord les formes et la géographie de Sanctuary Island.
+
+**Livré localement en beta.174 :** profil relief, lanceur protégé, comparaison
+à froid/réouverture, graines 0/42/173 et client Vulkan vérifiés. `check build`
+et les deux assemblages réussis ; génération normale conservée. L'optimisation
+des algorithmes complets reste le travail suivant.
+
+## SQ-173 — Refonte Storyquest et géographies indépendantes
+
+**Direction actualisée le 29 septembre 2026.** Branche `codex/storyquest-beta173`,
+issue de beta.172 (`55c745a`), avec prototype local beta.173 livré depuis.
+Le [fil rouge courant](storyquest-fil-rouge.md) fait autorité pour les priorités ;
+le [cadrage général](storyquest-beta173.md) conserve les autres intentions.
+Le créateur abandonne le palais souterrain, ses accès et ses raccordements.
+La refonte concerne Sanctuary Island, l'île de départ.
+
+Ordre de travail proposé, à ajuster après chaque visite :
+
+1. Un parcours extérieur arrivée → halte → ancre, comparé dans deux ambiances.
+2. Une première conséquence territoriale réelle, sous contrat de nouveaux mondes.
+3. Une préparation utile au parcours : familier, produit ou plan constructible.
+4. Un premier accès vertical, puis la déclinaison des lieux qui fonctionnent.
+
+Chaque étape croise géographie, récit, retour d'information et ambiance. Les
+critères d'essai sont dans le fil rouge ; cet ordre n'est pas un verrouillage
+de progression joueur. Pas de nouveau code ni de carte de terrain livré par
+cette révision documentaire. Les autres sujets — menus, Friends, PNJ, cuisine,
+économie, ISS, créatures et communauté — restent dans la réserve de conception.
+
+## PALAIS-173 — prototype livré ; architecture abandonnée le 29 septembre
+
+Première implémentation dans un laboratoire neuf : un palais par seed, huit
+ancres extérieures, huit matériaux distincts et huit couleurs indépendantes
+sur le bloc originel. [Contrat, essai et validation](palais-prototype-beta173.md).
+Le code et le laboratoire sont conservés comme preuve technique. **Le placement
+du palais sous l'île n'est plus prévu.** Les mécaniques d'ancres et du bloc
+originel peuvent alimenter le nouveau parcours ; leur intégration indépendante
+et l'ouverture effective d'une expansion restent à réaliser.
+
+## HORDE-170 — Objet-carte natif et langage de particules
+
+[Contrat de la carte native](horde-map-native-beta170.md). L'objet créatif
+vierge découvre une identité stable et différente à sa première prise en main.
+Toutes les étapes des invasions par carte sont signalées visuellement, sans chat.
+La distribution en survie depuis les campements reste un ticket futur : aucune
+génération existante n'est modifiée dans cette livraison.
+
+## HORDE-169 — Cartes inconnues et invasion accélérée
+
+[Contrat de l'invasion](horde-invasion-beta169.md). La prise en main révèle la
+difficulté et le contenu. Les nouvelles cartes remplacent les vagues par un flux
+de 12, 18 ou 27 monstres de plus en plus rapide, avec jusqu'à dix espèces et des
+butins généreux correspondants. Les cartes beta.168 restent lisibles et jouables.
+
+## FAMILIERS-COMBAT — Refonte à définir après essai de horde
+
+Retour du créateur : les familiers ne lui semblent pas utiles au combat. Examiner
+leurs comportements réels et définir une contribution perceptible avant de modifier
+leurs statistiques. Tester avec joueurs sur une horde. Intention consignée, non implémentée.
+
+## HORDE-168 — Cartes consommables et participation spontanée
+
+Branche `codex/cartes-horde-beta168`. [Contrat du labo](horde-cartes-beta168.md).
+Trois cartes natives illustrées, invocation immédiate sans socle, vagues ouvertes
+et butins sur les monstres ramassables librement. L’ancien cercle est conservé
+pour les futurs donjons. Suite générale 254/254, puis validation ciblée serveur
+et client Vulkan des derniers ajustements réussies.
+
+## HORDE-167 — Premier essai de carte d'épreuve en laboratoire
+
+Branche `codex/communaute-economie-beta167`. [Contrat et vérifications](horde-lab-beta167.md).
+Prototype local vérifié sur son parcours serveur et client Vulkan : arène ronde, bloc central, carte réutilisable,
+inscriptions et trois vagues coopératives. Aucun gain d'XP ou de butin de récompense.
+La simplification du tableau, la BDD et les autres cartes restent à réaliser.
+La suite complète reste à 252/253 : un échec de déplacement des familiers,
+reproduit au rejeu ciblé, est signalé dans le contrat de livraison.
+
+## Direction de travail — communauté, économie et aventures
+
+[Cadrage du 25 septembre 2026](ecosysteme-communaute-economie.md) : décisions
+du créateur, état beta.166, propositions et questions ouvertes. Conception
+uniquement ; branche `codex/communaute-economie-beta167`, basée sur le dernier
+`main` beta.166. Le prototype beta.167 a été intégré sur `main` localement.
+
+Dernière orientation de conception : cartes de découverte, cartes d'épreuve,
+clés/reliques, avec une piste de cartes collectionnables générées. Imaginer une
+arène ronde de laboratoire et son nouveau bloc central pour une carte de horde
+de zombies par vagues. Le [prototype beta.167](horde-lab-beta167.md) fait maintenant
+l'objet d'une réalisation séparée ; les autres familles restent en conception.
+
+Ordre proposé : tableau à message général → statistiques existantes en BDD et
+premier rapport quotidien → première bounty physique jouable → navets et machine
+du dimanche avec suivi économique → huit structures et ancres d'expédition.
+Le contrat de ballast doit être livré avant les Backrooms ; site et Discord
+prolongent progressivement ces parcours. Aucun de ces nouveaux lots n'est livré.
+
+## COMM-154 — Communauté dans le menu pause et sur le site
+
+Branches `codex/community-beta154` (mod) et `codex/community-contract` (site).
+Résultat : Gazette, tableau et intendance avec lecture, publication, réponses,
+droits serveur et comptes liés ; fichier autonome ou MariaDB partagée.
+[Contrat](community-contract-v1.md), [livraison locale](community-beta154.md).
+
+## STAT-03 — Atelier d’argile et hotbar — beta.112
+
+Branche `codex/clay-workshop-hotbar-beta112`. [Contrat et vérifications](clay-workshop-hotbar-beta112.md).
+Onze cases : argile, résultat et hotbar active ; hauteur fixe et transferts
+limités aux neuf cases, même avec un inventaire agrandi.
+
+## STAT-02 — Atelier d’argile et orientation — beta.111
+
+Branche `codex/clay-workshop-ui-beta111`. [Contrat et vérifications](clay-workshop-ui-beta111.md).
+Cadre nine-slice fourni, inventaire intégré et pose selon le regard horizontal.
+Propriété `facing` additive ; les anciens statuaires gardent leur apparence.
+
+## STAT-01 — Atelier d’argile et modèles 3D — beta.106
+
+Branche `codex/statuary-import-beta106`. [Contrat et validation](statuary-beta106.md).
+Dossier commun, GLB au Métabli pour les statues en blocs, atelier d’argile
+pour les miniatures 16³ avec consommation native, teinte et identité du modèle.
+Cycle natif de fabrication/pose/récupération/rechargement vérifié, y compris
+sans fichier source. Build complet et archives normale/Test vérifiés localement.
+
+## BUILD-104 — Contraste des argiles
+
+Branche `codex/clay-contrast-beta104`. [Ticket](clay-contrast-beta104.md).
+Gris et noir plus distincts ; blocs et items accordés. Aperçu, contraste,
+transparence, build complet et archives normal/Test vérifiés.
+
+## BUILD-103 — Rangement créatif par séries
+
+Branche `codex/colored-bricks-order-beta103`. [Ticket](colored-bricks-order-beta103.md).
+Groupes de seize par type et ordre de couleurs natif. Build complet et
+archives normal/Test vérifiés ; ressources beta.102 inchangées.
+
+## BUILD-102 — Briques et argile de couleur
+
+Branche `codex/colored-bricks-beta102`. [Ticket](colored-bricks-beta102.md).
+Seize familles natives et textures recolorées à partir des originaux vanilla.
+Parcours natif, recettes, butin, modèles, sauvegarde/réouverture, build complet
+et archives normal/Test vérifiés.
+
+## SKY-077 — tourbillon au-dessus du vide
+
+Branche `codex/cloud-vortex-beta077`. [Ticket](cloud-vortex-beta077.md).
+Couche native à Y = 0, diamètre double de l’île, rotation et géométrie en cache.
+Livraison groupée avec les correctifs de menus beta.076. Tests natifs, cache,
+transparence Fabulous, build et archives normal/Test vérifiés.
+
+## UI-076 — navigation et pouvoirs sélectionnés
+
+Branche `codex/menu-navigation-beta076`. [Ticket](menu-navigation-beta076.md).
+Accès direct aux combats depuis Pause, parcours prestige/faction/historique,
+achats visibles et sélection du pouvoir utilitaire explicite. Parcours natif vérifié ;
+distribution regroupée avec beta.077.
+
+## PLAN-FIX-01 — retirer la recherche web (beta.075)
+
+Branche `codex/plans-library-beta075`. [Correctif](plans-library-beta075.md).
+Retirer le bouton Minecraft Schematics de K → Bibliothèque et ses libellés.
+Build, sources et archives normal/Test vérifiés ; anciens packs conservés.
+
+## FAMILIAR-05 — autonomie et ordres rapides (beta.074)
+
+Branche `codex/familiar-autonomy-beta074`. [Contrat](familiar-autonomy-beta074.md).
+Quatre règles de comportement distinctes, garde locale, sélection des menaces,
+retour après poursuite, gestion des cibles inaccessibles et H bref/maintenu.
+Parcours natif, régressions montures/arènes/duels et `check build` réussis.
+Archives normal/Test vérifiées ; textures beta.070 conservées.
+
+## PLAN-01 — statues et plans natifs (beta.072)
+
+Branche `codex/statues-plans-beta072`.
+[Contrat, formats et vérifications](statues-plans-beta072.md). Modèles et textures
+du jeu convertis en statues creuses ; bibliothèque compatible `.litematic`,
+`.schem` v2/v3 et `.nbt`, aperçu par couche, rotation, matériaux et collage
+créatif contrôlé côté serveur. En survie, construction manuelle native.
+Aucune dépendance Litematica/MaLiLib ajoutée.
+Capture native des 88 espèces, parcours creeper créatif/survie FR/EN,
+interopérabilité Litemapy, sept tests serveur et 130 tâches Gradle réussis.
+Archives normal/Test vérifiées ; anciennes `.schematic` à convertir en externe.
+
+## BUILD-02 — Métabli et menu de construction
+
+**Premier lot implémenté en beta.096**, branche `codex/metabli-beta096`.
+[Contrat et vérifications](metabli-beta096.md) ·
+[Conception et extension future du catalogue](metabli-construction.md).
+Neuf établis à plat ouvrent le catalogue ; choix d’un projet à l’atelier,
+placement et orientation avec K. Statues, quatre machines existantes, abri,
+passerelle et imports ; construction manuelle guidée, sans bouton pause ajouté.
+Changer/importer/abandonner exige le Métabli. Projet local à la session actuelle,
+exportable ; chantiers partagés persistants, catalogue serveur en datapack et
+fonctions commerciales restent à réaliser.
+
+## MB-01 — Reprendre le catalogue des multiblocs
+
+**Ticket local ouvert le 15 septembre 2026 ; premier lot implémenté en beta.084.**
+[Catalogue et décisions historiques](multiblocs-conception.md) ·
+[Ticket de cadrage et lots d'implémentation proposés](multiblocs-ticket.md).
+Branche documentaire réservée `codex/multiblocs-ticket`.
+
+Premier lot choisi le 16 septembre 2026 : **clé dorée, Fourneau et Fût**,
+implémenté en [beta.084](multiblocs-beta084.md) sur `codex/multiblocs-beta084`. Fermentation, présentoirs,
+méga-pistons, Trémie, Carillon et Métablit restent au catalogue.
+La clé dorée assemble volontairement et dissocie ; les composants restent
+indépendants à la pose. Le Fût à 729 cases avec recherche et pages est accepté.
+Les gestes et la chauffe du premier lot sont décrits dans sa livraison. La fusion de tout
+It's Alive dans Sanctuary est différée ; le Fourneau pourrait alors remplacer
+la cuisinière, selon le [cadrage corrigé](multiblocs-itsalive-contrat.md).
+Aucun nouveau multibloc ni binaire livré ici.
+Les huit candidats de la [recherche complémentaire](multiblocs-recherche.md)
+sont rejetés par le créateur, jugés sans intérêt ou contraires au contrat
+Minecraft Vanilla. Reprendre le catalogue antérieur pour la liste d'implémentation.
+
+## FAMILIAR-04 — personnalité et montures natives (beta.071)
+
+Branche de départ `codex/familiar-personality-beta071`.
+[Contrat et vérifications](familiar-personality-beta071.md). Quatre caractères
+stables avec tendances d’espèce ; priorité des ordres, poursuite plus vive et
+verrouillage de combat conservé. Escalade des deux araignées, Souffle du
+Nautilus pour les deux variantes colossales et surface de lave du Strider.
+Audit des 14 espèces montables natives, parcours client et 124 tâches Gradle
+réussis ; archives isolées de la beta.072 en cours, resource pack beta.070.
+
+## RP-02 — textures versionnées et actives par défaut (beta.070)
+
+Branche `codex/resourcepack-beta070`.
+[Contrat et vérifications](resourcepack-beta070.md). Import des dessins fournis,
+source et manifeste d’empreintes enregistrés dans Git ; pack natif activé par
+défaut et désactivable. Sept textures de faim/saturation mises à jour, respiration
+vanilla conservée. Client natif, build, deux MRpacks et ZIP autonome vérifiés.
+
+## FAMILIAR-FIX-02 — retour des ordres sur H (beta.069)
+
+Branche `codex/familiar-orders-h-beta069`.
+[Contrat et tests](familiar-orders-beta069.md). H pour les ordres, F pour
+l’échange des mains, G pour la technique. Conversion unique de l’ancien
+raccourci F en H ; suppression du filtrage de l’échange natif. Parcours
+client et compilation vérifiés, deux archives locales conformes.
+
+## LOAD-03 — animation discrète de l’attente (beta.068)
+
+Branche `codex/loading-animation-beta068`.
+[Résultat et vérifications](loading-animation-beta068.md) : neuf glyphes SGA
+avec une lumière mobile, animés par l’horloge de rendu ; étapes réelles et
+carte des chunks conservées. Huit captures natives comparées, FR/EN inspectés,
+compilation et archives normal/Test vérifiées. Introduction et cache inchangés.
+
+## FAMILIAR-FIX-01 — touche et vol du dragon (beta.067)
+
+Branche `codex/familiar-controls-beta067`.
+[Contrat et vérifications](familiar-controls-beta067.md) : ordres sur F,
+remappage unique de l'ancien H et prévention du double déclenchement de
+l'échange des mains ; orientation du dragon corrigée. Plané des petits
+vérifié, montée du grand porté avec Espace et monture colossale vérifiées.
+Compilation et deux archives validées localement.
+
+## HEAD-FIX-01 — modèles animés superposés (beta.066)
+
+Branche `codex/cosmetic-render-beta066`.
+[Résultat et tests](head-render-beta066.md). Doublon de coffre reproduit dans
+le collecteur natif puis corrigé ; une seule cloche animée avec son support.
+Ouvertures/fermetures, aliments, autres modèles et douze cas sur des mobs
+adultes ou bébés vérifiés. Build et archives validés localement.
+
+## BOAT-FIX-01 — collisions des coques (beta.065)
+
+Branche `codex/boat-collisions-beta065`.
+[Résultat et tests](boat-collisions-beta065.md) : coque entière couverte,
+virages contrôlés avant la translation, recul conservé. Passage au travers
+des murs reproduit puis corrigé ; 88 variantes et seize parcours pilotés
+vérifiés en client natif et serveur intégré. Build et deux archives validés
+localement ; pas de déploiement personnel.
+
+## LOAD-02 — cache et étapes réelles de préchargement (beta.064)
+
+Branche `codex/loading-cache-beta064`.
+[Contrat, mesures et vérifications](loading-cache-beta064.md). Plans dérivés
+mis en cache sur disque, validation des données et recalcul automatique si
+une entrée manque ou est corrompue. Réouverture mesurée à 2,1 s contre 58,7 s
+lors de l’audit beta.063 ; première création à 122 s, introduction complète.
+Étapes réelles du serveur, écran natif épuré sans portail du Nether. Pas de
+migration des chunks ou des journaux d’expansion. Build, récupération d’un cache
+corrompu, huit ouvertures classiques/plates et archives vérifiés localement.
+
+## RP-HUD-01 — base de textures modifiable
+
+**Préparée le 15 septembre 2026**, branche `codex/resourcepack-hud-base`.
+[Résultat et vérifications](resourcepack-hud-base.md) : 53 sprites vanilla
+de vie et de faim, manifeste 26.3-pre-2 et guide de retouche FR/EN dans le
+resource pack Sanctuary existant. Les dessins seront modifiés par le créateur.
+Ce lot graphique séparé ne livre pas de nouveau binaire du mod.
+
+## CAPE-01 — Des capes rares aux pouvoirs durables
+
+**Ticket préparé le 15 septembre 2026 ; à arbitrer puis à implémenter.**
+[Intention, premier lot proposé et critères d'acceptation](capes-gameplay.md).
+Branche documentaire réservée `codex/capes-ticket` ; branche d'implémentation
+prévue `codex/capes-gameplay`.
+
+Les capes apportent généralement un bonus passif permanent, proposé tant
+qu'elles sont portées. Des capes très puissantes restent possibles, avec rareté,
+contreparties ou périodes actives à éprouver selon leur impact. Le ticket
+prépare trois capes aux usages distincts, leur acquisition rare en survie et
+les essais de cumuls, de circulation et de progression. Catalogue, valeurs,
+malus et règles temporelles restent des propositions. Cape Zéro est actuellement
+visuelle ; aucun nouveau pouvoir ni changement de binaire livré par ce ticket.
+
 ## ANO-01 — Les doubles de Steve
 
 **Conception du 15 septembre 2026 ; non implémentée.**
@@ -1566,3 +1959,93 @@ secrets et traversées. Comparer les champs natifs 27, 30.1, 30.4 et 30.5 par
 coupes et cartes scientifiques, archivées avec leurs sources et leurs graines.
 Les expéditions anciennes et les îles supérieures ciblées restent à définir.
 Voir [la génération](generation-alpha30.5.md) et [l’atlas](terrain-atlas.md).
+
+## ARENA-01 — beta.073 — duels publics et arènes
+
+Livré et vérifié : trois modes de combat, inscriptions sans plafond pour les arènes,
+paris en objets, annonces et liste publique. Joueurs avec morts réelles.
+[Contrat et essais](arenas-beta073.md).
+
+## EXP-03 — Crash de recherche de temple
+
+Correctif local beta.097 sur `codex/expedition-temple-crash-beta097`.
+[Contrat et vérifications](temple-crash-beta097.md). Graine du rapport
+`-4700804240597771092` ; le créateur demande de garantir le temple plutôt que
+d’omettre le bâtiment ou de refuser la graine. Les plans de construction gagnent
+aussi leur aperçu texturé à sa demande pendant ce correctif.
+
+## CONSTRUCTION-098 — construction directe en créatif
+
+Branche `codex/creative-construction-beta098`.
+[Ticket](creative-construction-beta098.md) : bouton K créatif, confirmation et
+placement serveur du projet choisi au Métabli ; parcours manuel en survie.
+Essai client natif (statue, machine, bâtiment, annulation et contrôles créatif),
+build complet et archives normal/Test vérifiés.
+
+## CATALOGUE-099 — Progression et Métabli illustré
+
+Branche `codex/catalogue-progression-beta099`.
+[Contrat](catalogue-progression-beta099.md) : arbre des progrès intégré sous
+les compétences, catalogue partagé entre catégories avec aperçus et trois
+plans personnels terminés, palette étendue, K bref/maintenu et Métabli dans
+les nouvelles salles souterraines. Anciennes pièces sauvegardées préservées.
+
+## EXPLORATION-100 — Statues découvertes et promenade
+
+Branche `codex/exploration-familiers-beta100`.
+[Contrat](exploration-familiers-beta100.md) : catalogue de statues basé sur les
+rencontres et statistiques serveur ; promenade avec pauses selon le tempérament,
+sans orbite permanente ni concurrence avec les ordres et le combat.
+
+EXPLORATION-100 vérifié : douze promenades, régression autonomie/ordres, catalogue
+serveur, imports `.schem`, réouverture et deuxième monde ; build et archives
+normal/Test réussis. Incident Windows non reproduit sans son journal.
+
+## LANDING-101 — Atterrissage des familiers volants
+
+Branche `codex/flying-landing-beta101`.
+[Ticket](flying-landing-beta101.md) : supprimer le faux coup de chute des
+profils volants, conserver les attaques réelles et les chutes terrestres.
+
+LANDING-101 vérifié : reproduction native avant correctif, douze espèces
+volantes, contacts lents/rapides, vraies attaques et chute terrestre ;
+build complet et archives normal/Test contrôlés.
+
+## beta.105 — Saisons et chapeaux vivants
+
+Livré localement et vérifié en copie isolée : [contrat et contrôles](living-hats-seasons-beta105.md).
+
+## EGGS-107 — Acquisition des œufs
+
+Branche `codex/eggs-beta107`. [Contrat](spawn-eggs-acquisition-beta107.md) :
+naissances en œufs et œuf du générateur sans Toucher de soie.
+[Catalogue](spawn-eggs-catalogue-beta107.md) : 88 espèces, 35 voies couvertes,
+53 propositions en attente de validation du créateur. Les rangs et Anomaly
+restent hors de ce ticket. Les sources sont intégrées en préservant le chantier
+Statuaire ; la validation binaire est isolée sur la dernière base livrée beta.105.
+
+## SNOW-108 — Neige en volume
+
+Branche `codex/snow-accumulation-beta108`.
+[Contrat](snow-accumulation-beta108.md) : épaississement par précipitations,
+blocs pleins à huit couches et accumulation verticale. Limite serveur de deux
+blocs par défaut, réglable. Les blocs sont natifs, sans migration de terrain.
+Livraison locale vérifiée : essais natifs dans deux mondes neufs, build complet
+et archives normal/Test contrôlés ; assemblage isolé sur beta.107.
+
+## SNOW-109 — Fonte saisonnière
+
+Branche `codex/seasonal-snow-melt-beta109`.
+[Contrat](seasonal-snow-melt-beta109.md) : fonte progressive par saison,
+provenance des dépôts persistante par chunk, constructions préservées.
+Livraison locale vérifiée sur beta.108 : essais natifs, rechargement de
+chunk, build complet et archives normal/Test contrôlés.
+
+## INTEGRATE-110 — Atelier d’argile dans le pack complet
+
+Branche `codex/clay-workshop-integration-beta110`.
+[Ticket](clay-workshop-integration-beta110.md) : assemblage commun de
+beta.106 et beta.109, avec tous les systèmes intermédiaires. Essais natifs de
+l’atelier, des œufs et de la neige, build et archives réussis. Publication
+et synchronisation de l’instance Sanctuary Beta terminées ; 923 fichiers
+personnels et réglages suivis conservés, aucun monde ouvert.

docs/base-peaks-beta204.md

@@ -0,0 +1,103 @@
+# UNI-WG-204 — Sanctuary autonome et Nord Peaks
+
+Branche `codex/sanctuary-base-peaks-beta204`, depuis beta.203 (`454d9a5`).
+
+Demande : absorber Demeure dans Sanctuary, rendre le terrain validé du laboratoire
+accessible avec le mod normal seul, puis remplacer la nappe nordique par le
+générateur Peaks existant en conservant taïga géante, glaces et igloos.
+
+## Contrat
+
+- Demeure interne : même chemin `data/demeure/footprints-v1.json`, schéma 1,
+  mêmes règles serveur et attribution. Aucun transfert de données.
+- Nouveau preset public Sanctuary, trois tailles ; types vanilla conservés.
+  Introduction normale conservée ; diagnostics et raccourcis de labo facultatifs.
+- Codecs et ressources historiques `sanctuary:*` et `sanctuary_test:*` conservés.
+  Le transfert de module ne renomme pas ces identifiants.
+- Nouveau profil 204 uniquement pour le Nord Peaks, diamètre 1024. L'île de
+  départ reprend les paramètres 203 ; aucun terrain déjà créé régénéré.
+- Essais sur mondes de développement neufs et copies de développement seulement,
+  graines 0, 42 et 4736390610738281858 ; publication/installation non demandée.
+
+## Réalisation
+
+### Mod normal
+
+Demeure n'est plus un JAR Fabric imbriqué : ses quatre classes, son mixin de
+placement, ses tests et son attribution sont intégrés à Sanctuary. Le service
+s'enregistre une seule fois depuis l'initialisation principale. Un ancien JAR
+Demeure séparé est refusé pour éviter deux installations des mêmes hooks.
+
+Le terrain validé restait dans `sanctuary-test` ; le preset public du mod normal
+ne pointait donc pas vers ce terrain. Le runtime de l'île, ses ressources,
+ses mixins et son écran de taille sont désormais dans Sanctuary : biomes,
+grottes, minerais, bassins, mines, ruines, ancres, rosace, station et expansions.
+Les variantes historiques restent enregistrées pour lire leurs identifiants,
+mais une seule entrée Sanctuary apparaît dans le menu, à côté des types vanilla.
+Small/Medium/Large sélectionnent les nouveaux paramètres `sanctuary:island204_*`.
+
+Le module Test conserve uniquement ses outils : diagnostics, visites guidées de
+développement, monde plat, commandes et raccourcis d'essai. Il ne fournit plus
+de mixin ou de ressource indispensable au monde normal. Le nom du package Java
+`fr.koka.sanctuarytest` et les anciennes clés `sanctuary_test:*` restent inchangés
+dans le runtime déplacé afin de limiter la portée du transfert.
+
+### Nord
+
+Pour les nouveaux profils 204, le Nord 1024 utilise directement la densité Peaks
+du moteur d'expansion, avec son épaisseur et son amplitude verticales normales.
+La coque de plateaux `NorthShape203` n'intervient plus. L'écologie s'appuie sur
+des colonnes mesurées dans cette densité, mises en cache sur une grille de huit
+blocs : vallées, taïga, vieux épicéas, roche, neige, pics et glaciers dépendent
+du relief. Les épicéas géants 203 et les formations de glace vanilla sont repris.
+La glace des cavernes reste conditionnée à une couverture rocheuse suffisante.
+
+Les cinq igloos cherchent des épaules enneigées suffisamment soutenues, sans
+aplatir toute la montagne ; un seul possède le laboratoire de guérison. L'arrivée
+et le relais évitent les bâtiments. Les deux bassins imposés dans les anciens
+profils nordiques ne sont pas transposés : ils reformaient des plateformes dans
+le nouveau relief. Les autres directions et les profils 200–203 ne changent pas.
+
+## Vérifications — 4/5 octobre 2026
+
+- `./gradlew check build assemblePack assembleTestPack
+  -PsanctuaryFocusedTests=base204,demeure,menus,operator,realtime
+  -PsanctuaryAtlasOnly=true` : succès, tests de logique et 13 GameTests natifs
+  ciblés. Ces GameTests vérifient notamment l'absence de Test et de Demeure
+  séparé, les presets publics/historiques, les empreintes Demeure et l'amplitude
+  Peaks réservée au Nord 204. La suite native historique entière n'a pas été rejouée.
+- `:sanctuary:runClientGameTest -PsanctuaryClientTests=true
+  -PsanctuaryClientGraphicsBackend=vulkan -PsanctuaryShared196ClientTests=true` :
+  `SHARED196_CLIENT_PASS`, sans Test chargé. FR/EN, tailles, Annuler/Échap,
+  relecture des paramètres sauvegardés et éditeur Plat vanilla vérifiés.
+- Création sur le classpath de production sans Test, heap 2048 Mio : Small
+  graine 42, Medium graine 0 et Large graine 4736390610738281858. Les trois
+  serveurs atteignent l'état prêt et placent le spawn sur l'île. Journaux dans
+  `build/base204-standalone/`. Ce ne sont pas des mesures comparatives de performance.
+- Nord natif Small 42, profil 204 : offrande réelle, rejet des mauvaises offres
+  et doublons, interruption puis reprise du journal, arrivée/relais et cinq
+  igloos dont une cave vérifiés. Centre de l'expansion `(-128, -944)` ; arrivée
+  `(-112, 308, -1056)`. L'annonce SGA est émise après préparation.
+- Échantillonnage du Nord : sommets Y=103–455, épaisseur maximale 381 blocs ;
+  prairie, taïga, forêt ancienne, neige, pics, glacier et roche présents.
+  Dans les chunks inspectés autour de `(-256, 283, -848)`, le plus grand tronc
+  mesure 60 blocs. Glace et air vérifiés dans une caverne ; glacier vérifié
+  autour de `(-80, 303, -1120)`. Reçus `build/worldgen-lab/north204-a/small/42/`.
+- MRpack normal `Sanctuary-beta.204.mrpack` exporté et ZIP vérifié : Minecraft
+  26.3, Loader 0.19.5, Fabric API 0.160.5+26.3 ; ni JAR Test ni Demeure séparé.
+  SHA-256 : `8c90090a784bd7c799849e916be2e3e36214a3dbf6ce8b4925d31a9fca8c5086`.
+
+## Limites et livraison
+
+Les essais natifs du nouveau Nord couvrent la graine 42. Son aspect reste à
+évaluer en visite, et la recherche d'un village n'a pas été vérifiée sur toutes
+les graines. Ces résultats macOS/Vulkan ne constituent pas une validation Windows.
+L'hydrologie du Nord reste à reprendre sur son relief Peaks si l'on souhaite
+rétablir de grands lacs. Aucun ancien monde, chunk ou format de sauvegarde n'a
+été migré ; les nouvelles formes nécessitent un nouveau profil 204.
+
+Artefact local dans `build/` et copie dans `~/Downloads/`. Une copie indépendante
+du monde de test est ouverte pour la visite `north204-visit`, en créatif,
+commandes autorisées et vue 32 chunks (`NORTH204_VISIT_OPEN`, Vulkan confirmé).
+Aucun packwiz public, serveur personnel
+ou instance Prism n'a été mis à jour par ce chantier.

docs/boat-collisions-beta065.md

@@ -0,0 +1,100 @@
+# beta.065 — collisions des bateaux collectifs
+
+Branche `codex/boat-collisions-beta065`.
+
+## Problème et portée
+
+Les huit formes de bateaux et radeaux collectifs utilisent le déplacement natif
+côté serveur. Leurs anciennes limites étaient fondées sur une tuile carrée de
+1,375 bloc, alors que les modèles ont une longueur de 28 pixels par module.
+La coque visible dépassait donc sa collision dans le sens longitudinal. Un
+virage agrandissait aussi directement les limites sans vérifier le terrain ;
+après cette intrusion, le déplacement natif pouvait traverser le mur.
+
+Les limites couvrent désormais les coques complètes, et le volume balayé
+par chaque virage est contrôlé avant le déplacement. Le mouvement natif reste utilisé pour
+les translations, l’appui au sol et sur l’eau, les formes de blocs et les
+collisions avec les autres véhicules. Les sièges, les commandes partagées,
+les moteurs, les vitesses et les règles de chute des piles restent inchangés.
+
+Les modèles et les textures ne changent pas. Les bateaux simples Minecraft
+conservent leur comportement. Aucune modification de chunk, de recette, de
+journal ou de format de sauvegarde ; les identifiants existants restent stables.
+Les positions enregistrées des anciens bateaux ne sont pas déplacées par la
+mise à jour : seule leur collision utilise les dimensions corrigées.
+
+## Collision de la coque
+
+Les huit formes sont couvertes : 1 × 2, 2 × 1, 1 × 3, 3 × 1, 2 × 2,
+2 × 3, 3 × 2 et 3 × 3, sur les onze bois. Largeur et longueur de la coque :
+
+- Bois : `colonnes + 0,25` × `rangées × 1,75 + 0,25` blocs, rebords compris.
+- Bambou : `colonnes × 1,25` × `rangées × 1,75` blocs.
+
+Comme dans le moteur natif, la collision est une boîte alignée sur les axes ;
+elle englobe la coque orientée. Les rames animées restent décoratives. Un virage
+vérifie aussi les extrema entre ses deux orientations, pour qu’un coin ne
+traverse pas un mur avant de revenir dans une position libre. Au contact,
+l’inertie de rotation s’arrête ; le recul et le glissement le long du mur restent
+résolus par Minecraft. Les rotations de placement ou de téléportation ne sont
+pas remplacées par des tentatives de conduite.
+
+## Vérification
+
+Client Minecraft 26.3-pre-2 et serveur intégré de développement, monde plat
+neuf de graine `65`. Le test avant correction traverse effectivement le mur
+situé en X=8 : après quinze mouvements avec virage, le centre atteint X=12,55.
+Ce même cas passe après correction.
+
+- **88 variantes** : **3 168 déplacements** contre des murs dans les deux sens
+  de X et Z, huit orientations, diagonales et déplacements de vingt blocs en
+  un appel ; collision native détectée et recul libre de 1,5 bloc.
+- **440 virages** : contact et tentative de déplacement dans le mur, virages
+  libres, puis cas où les orientations de départ et d’arrivée sont libres
+  mais où le milieu du virage heurterait le mur. Ce dernier cas est refusé.
+- **128 passages** contre les formes natives minces des barrières et vitres,
+  sur bateaux et radeaux, sans traversée ni recouvrement des blocs.
+- **704 modèles orientés** : les sommets réels des fonds et rebords sont inclus
+  dans les collisions, côté client. Les rames sont explicitement exclues.
+- **16 parcours pilotés avec les vraies touches**, huit formes en chêne et en
+  bambou, répartis entre eau et vol avec Allay et les quatre directions :
+  avancer contre le mur, maintenir le virage, reculer. Les limites serveur et
+  client restent à l’intérieur des murs, le pilote reste assis et le recul
+  déplace effectivement le bateau. Deux captures de contact ont été relues.
+
+Journaux locaux : `build/boat065-before.log`,
+`build/boat065-control-before.log`, `build/boat065-fixed-probe.log`,
+`build/boat065-client.log`. Captures : `build/boat065-evidence/`.
+Le parcours complet passe en **1 min 59 s**.
+
+```sh
+./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryBoat065ClientTests=true \
+  -PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
+```
+
+Les essais utilisent le serveur intégré ; aucun serveur dédié ni EULA acceptée.
+Le test client couvre la synchronisation locale ; une session avec plusieurs
+clients distants et latence n’a pas été relancée pour ce correctif.
+
+## Livraison locale
+
+`./gradlew check build assemblePack assembleTestPack` réussi en **2 min 8 s**,
+**122 tâches**, avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
+-PsanctuaryQuickTests=true`. Les essais serveur intégrés ci-dessus remplacent
+les tests dédiés exclus conformément au refus antérieur d’accepter leur EULA.
+
+Les archives normal/Test sont vérifiées : **1 645 classes** conformes à la
+compilation, aucune classe de test embarquée, mêmes ressources et dépendances
+qu’en beta.064. Seule la source principale `CrewBoat` change, en plus des
+métadonnées de version. Modèles, textures, recettes, sièges, moteurs et autres
+systèmes restent conservés. Les anciennes archives beta.064 sont intactes.
+
+
+- [Pack normal beta.065](../build/Sanctuary-beta.065.mrpack), 5721084 octets.
+  SHA-256 : `71ff1736817e2953f88a8afda5858b2e7ae23c360efdb7e25f149cbff049d764`.
+- [Monde plat rapide beta.065](../build/Sanctuary-Test-beta.065.mrpack), 5740018 octets.
+  SHA-256 : `4c4931146a05d6f57e9abf2303b039ab7a7bc16471a0b864873b86bef297431d`.
+
+Reçu `build/boat065-artifact.json`, build `build/boat065-check.log`.
+Aucun canal publié, instance Prism ou monde personnel modifié.

docs/boat-passengers-beta091.md

@@ -0,0 +1,74 @@
+# beta.091 — Interagir avec les animaux embarqués
+
+Branche `codex/boat-passenger-interactions-beta091`, Minecraft 26.3.
+
+## Contrat
+
+Depuis un bateau, viser un mob directement installé sur un siège permet les
+interactions habituelles : clic gauche pour le frapper, clic droit pour utiliser
+son objet de tête ou son interaction native. Cela couvre les bateaux/radeaux
+Minecraft et tous les formats Sanctuary. Les coups sur les animaux ordinaires
+infligent leurs dégâts habituels ; les familiers conservent leur réaction sans
+blessure hors des combats prévus, avec déclenchement de leur équipement.
+
+Le ciblage natif excluait les entités partageant le véhicule racine du joueur.
+L'exception est limitée au curseur du joueur et aux mobs assis directement dans
+son bateau. Portée, obstacles et choix de la cible la plus proche restent ceux
+de Minecraft. Les collisions des projectiles ne sont pas modifiées.
+
+Le bateau limite aussi normalement le regard à ±105 degrés. Avec un mob à bord,
+les joueurs peuvent désormais regarder autour d’eux à 360 degrés, notamment
+vers le siège arrière. Les commandes de déplacement et la rotation du bateau
+restent indépendantes du regard ; les mobs gardent leur orientation native.
+
+La protection de portage des familiers distingue désormais un siège de bateau
+d'un familier porté sur la tête ou monté. Les protections entre joueurs portés
+restent en place. Les dégâts et interactions continuent à être validés côté
+serveur ; aucun nouveau paquet, inventaire, identifiant ou format de sauvegarde.
+Aucune modification des mondes existants ni de la génération.
+
+## Vérifications
+
+Le parcours `BoatPassengers091ClientChecks` crée un monde plat de développement,
+graine 42, et utilise le curseur natif et les vrais clics souris. Il teste un
+coffre porté puis un distributeur chargé sur une poule embarquée.
+
+Le parcours natif passe en **1 min 13 s** sur Minecraft 26.3/macOS :
+
+- 13 cas : bateau et radeau vanilla, les huit formats Sanctuary, radeau 3 × 3,
+  poule bébé et familier installé comme passager pour vérifier sa protection.
+- Vrai ciblage du corps depuis le siège, y compris vers l’arrière ; aucun
+  remplacement artificiel du résultat de visée dans le test.
+- Clic droit : ouverture du coffre natif contenant les sept diamants attendus.
+- Clic gauche : perte de vie de la poule, une flèche consommée et un projectile
+  réel créé par le distributeur, sans éjection de l’animal.
+- Familier : même tir au toucher, vie inchangée. Une fois porté sur la tête,
+  protection symétrique conservée et aucun nouveau déclenchement au toucher.
+
+```sh
+./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryBoatPassengers091ClientTests=true \
+  -PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
+```
+
+Journal : `build/boat091-client.log`, marqueur `BOAT091_PASS`.
+
+## Livraison
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+passe en **2 min 20 s**, 124 tâches. Journal : `build/boat091-check.log`.
+Les deux exports sont vérifiés contre les JAR et leurs sources. Les textures,
+modèles, données et JEI restent identiques à beta.090 ; ses archives sont intactes.
+Le reçu local est `build/boat091-artifact.json`.
+
+- [Pack normal](../build/Sanctuary-beta.091.mrpack), SHA-256
+  `0d0e847e5b8f22637b6e280d0694ab5a2cdb8cb01a47442d92c5103e3e3f53ac`.
+- [Pack Test](../build/Sanctuary-Test-beta.091.mrpack), SHA-256
+  `392773b8e5fc8948cdb5ea9cd7e8cc8cd97ed43bdc5fe413fef32b05758f8edc`.
+
+## Limites
+
+Les essais utilisent un client natif et son serveur intégré de développement ;
+pas de session LAN à deux clients pour cette livraison. Les tests dédiés restent
+exclus et aucune EULA n’est acceptée. Aucun déploiement dans une instance
+personnelle ni publication du canal packwiz.

docs/build-mining-beta080.md

@@ -0,0 +1,85 @@
+# beta.080 — portée de Construction et progression de Minage
+
+Branche `codex/build-mining-balance-beta080`, Minecraft 26.3-pre-2, textures beta.070.
+
+Construction augmente la distance de pose. Minage augmente indépendamment
+la distance et la vitesse de casse. Le départ est inférieur au vanilla ;
+les derniers paliers le dépassent modérément. Les coûts, sept achats par
+compétence et tailles des groupes restent ceux du système existant.
+
+| Rang | Vitesse de minage, référence vanilla | Portée de minage | Portée de pose |
+| --- | --- | --- | --- |
+| 0 | 75 % | 3 blocs | 3 blocs |
+| 1 | 85 % | 3,5 blocs | 3,5 blocs |
+| 2 | 95 % | 4 blocs | 4 blocs |
+| 3 | 100 % | 4,5 blocs | 4,5 blocs |
+| 4 | 107,5 % | 4,75 blocs | 4,75 blocs |
+| 5 | 115 % | 5 blocs | 5 blocs |
+| 6 | 122,5 % | 5,25 blocs | 5,25 blocs |
+| 7 | 130 % | 5,5 blocs | 5,5 blocs |
+
+Chaque colonne dépend de sa propre compétence. La vitesse s’applique via
+l’attribut natif de casse, avec les outils, enchantements et autres effets.
+Les portées préservent les bonus externes de l’attribut d’interaction ;
+les valeurs du tableau supposent cet attribut à sa valeur survival de base.
+Créatif, spectateur et joueurs sans progression Sanctuary conservent leur
+portée native. Les infobulles FR/EN affichent le palier actuel et le suivant.
+
+La visée peut sélectionner le plus éloigné des gestes disponibles ; les
+validations de chaque action appliquent ensuite sa propre portée. Ainsi,
+voir le contour d’un bloc n’accorde pas forcément la portée pour le miner
+ou y poser un bloc : le même contour sert aux interactions ordinaires.
+La portée des coffres, autres interactions et attaques n’augmente pas.
+Un coffre hors de portée native peut servir de support de construction,
+sans s’ouvrir à distance. La main gauche et les plantes aquatiques suivent
+la portée de Construction.
+
+Les deux sélections groupées vérifient leur ancre avec leur compétence.
+Le plan et la veine verrouillés conservent leur contrat : les cellules du
+groupe peuvent dépasser la portée de l’ancre. Les droits, protections,
+collisions, stock, conditions de pose et chunks chargés restent vérifiés.
+La validation réseau conserve la tolérance native de distance à l’entrée
+des paquets ; la pose vérifie aussi la distance du point cliqué côté serveur.
+
+Aucun identifiant, schéma de sauvegarde ni terrain modifié. Les anciens
+rangs reçoivent les nouvelles valeurs à leur application habituelle ; un
+reset ou prestige revient aux valeurs de départ.
+
+## Vérification
+
+`Balance080ClientChecks` réussit en **1 min 03 s**, dans un monde plat solo
+jetable, avec les gestes natifs et les paquets réels client/serveur :
+
+- Les huit rangs, vitesse native de casse d’un bloc et composition des bonus.
+- Pose proche au rang zéro, refus de la pose lointaine sans perte de stock.
+- Minage et pose au-delà de la portée vanilla ; indépendance des deux compétences.
+- Pose en main gauche et refus serveur d’un paquet visant trop loin.
+- Coffre lointain utilisable comme support sans ouvrir son inventaire ; un
+  briquet en main principale ne profite pas de la portée du bloc en main gauche.
+- Construction d’un plan complet de neuf blocs à la nouvelle portée.
+- Vein mining de neuf blocs à cette portée, regard détourné après verrouillage.
+- Pose d’un nénuphar, retour aux rangs zéro, créatif et joueur sans progression.
+
+Journal : `build/balance080-client.log`. Les interactions des blocs portés
+sur la tête ont également été relues : elles passent par leur contexte
+propre, sans la pose de bloc interceptée ici.
+
+`check build assemblePack assembleTestPack` réussit en **2 min 27 s**,
+124 tâches (104 exécutées, 20 à jour), avec `-x :sanctuary:runGameTest`.
+Journal : `build/balance080-check.log`.
+
+Les **1 700 classes** du JAR correspondent aux fichiers compilés. Les 17
+classes ajoutées ou modifiées par rapport à beta.079 concernent uniquement
+ce ticket ; quatre libellés évoluent par langue. Sources et ressources
+vérifiées, textures beta.070 identiques, même JAR intégré aux deux packs.
+Les archives beta.079 sont conservées à l’identique.
+Reçu : `build/balance080-artifact.json`. Aucun déploiement personnel.
+Le serveur dédié reste exclu conformément au refus de son EULA ; le test
+natif ci-dessus utilise le serveur intégré.
+
+## Archives
+
+- [Sanctuary-beta.080.mrpack](../build/Sanctuary-beta.080.mrpack).
+  SHA-256 : `feb20b882442149789ed6d90e32073aa6201314a57782105a0330394c76e796d`.
+- [Sanctuary-Test-beta.080.mrpack](../build/Sanctuary-Test-beta.080.mrpack).
+  SHA-256 : `fc277f081f160ae8ae835501cddddd572cdffe4749454e1652a080a117bfb941`.

docs/build-reach-beta081.md

@@ -0,0 +1,43 @@
+# beta.081 — portée de pose jusqu’à six blocs
+
+Branche `codex/build-reach-six-beta081`, Minecraft 26.3-pre-2, textures beta.070.
+
+À la demande du joueur, Construction atteint maintenant **six blocs**.
+Les portées des rangs 0 à 7 sont : **3 ; 3,5 ; 4 ; 4,5 ; 4,75 ; 5 ; 5,5 ; 6**.
+Le rang 6 est également ajusté pour terminer par deux gains d’un demi-bloc.
+La référence reste l’attribut d’interaction vanilla sans bonus externe.
+
+Le minage conserve sa portée maximale de 5,5 blocs et sa vitesse de 130 %.
+Le contrat client/serveur, la pose en main gauche, les plans groupés et les
+infobulles FR/EN utilisent déjà la même source des valeurs. Aucun changement
+des coûts, identifiants, sauvegardes ou mondes ; les archives beta.080 restent
+immuables.
+
+## Vérification
+
+Le scénario natif `Balance080ClientChecks`, ajusté à cette courbe, réussit
+en **1 min 21 s** dans un monde solo jetable : pose réelle à 5,75 blocs,
+refus serveur d’un clic à 6,25 blocs sans perte de stock, et régression des
+huit rangs, du minage indépendant, de la main gauche, des groupes, des
+nénuphars, du créatif et des bonus externes.
+Journal : `build/reach081-client.log`.
+
+`check build assemblePack assembleTestPack` réussit en **2 min 30 s**,
+124 tâches (103 exécutées, 21 à jour), avec `-x :sanctuary:runGameTest`.
+Journal : `build/reach081-check.log`.
+
+Les 1 700 classes et les sources correspondent aux fichiers compilés :
+seule `BuildingLimits` change par rapport à beta.080. Ressources et textures
+identiques, même JAR dans les deux packs, archives beta.080 préservées.
+Reçu : `build/reach081-artifact.json`.
+
+Le serveur dédié reste exclu
+conformément au refus de son EULA ; le test utilise le serveur intégré.
+Aucun déploiement personnel.
+
+## Archives
+
+- [Sanctuary-beta.081.mrpack](../build/Sanctuary-beta.081.mrpack).
+  SHA-256 : `7f789522eaa4a2574cc9bee4a4def7862a4893c8f462e88502ca858440c8ee02`.
+- [Sanctuary-Test-beta.081.mrpack](../build/Sanctuary-Test-beta.081.mrpack).
+  SHA-256 : `7811cdc47ab4a8af2fc6ccd530775eb4a239f18894965362a1c57a5e0f12ded5`.

docs/capes-gameplay.md

@@ -0,0 +1,205 @@
+# CAPE-01 — Des capes rares aux pouvoirs durables
+
+**Ticket local rédigé le 15 septembre 2026 — à arbitrer, puis à implémenter.**
+Cette livraison prépare le ticket ; les effets et l'acquisition décrits ci-dessous
+ne sont pas implémentés.
+
+- Branche documentaire réservée : `codex/capes-ticket`.
+- Branche d'implémentation prévue : `codex/capes-gameplay`.
+- Aucun numéro `beta.xxx` réservé pour cette préparation documentaire.
+
+## Ce que le joueur doit pouvoir faire
+
+Trouver une cape Sanctuary doit être un événement : un objet très rare,
+reconnaissable et désirable, que l'on a envie de porter pour son pouvoir.
+Les capes donnent généralement un **bonus passif permanent**. Certaines peuvent
+offrir un pouvoir exceptionnel, voire volontairement « cheaté », si son impact
+reste acceptable dans la partie collective.
+
+Un catalogue riche est souhaitable : il peut contenir beaucoup de modèles,
+y compris plusieurs capes très puissantes. La diversité du catalogue et le
+nombre d'exemplaires en circulation sont deux choix distincts.
+
+### Intentions exprimées par le créateur
+
+- Privilégier les bonus durables et l'envie d'utiliser les capes.
+- Faire des capes des objets très rares.
+- Garder ouverte la possibilité de malus ou de contreparties.
+- Accepter des pouvoirs très forts ; leur puissance seule ne les exclut pas.
+- Examiner leurs conséquences réelles sur le gameplay et les autres joueurs.
+- Envisager la rareté et des périodes de fonctionnement comme moyens
+  d'équilibrage, sans rendre toutes les capes temporaires.
+
+### Interprétation proposée de « permanent »
+
+Le pouvoir reste disponible **tant que la cape est équipée dans sa case dédiée**,
+sans renouveler une potion ou appuyer régulièrement sur une touche. Posséder
+la cape dans un coffre ou l'inventaire n'accorde rien. Le retrait arrête son
+effet ; découvrir plusieurs capes ne donne pas plusieurs bonus permanents au
+personnage. Cette interprétation reste à confirmer avant le code.
+
+Les exceptions temporaires sont annoncées cape par cape. Proposition : la cape
+reste un objet de collection après sa période active ; c'est son pouvoir qui
+s'endort. Une cape consommable ou détruite à l'expiration serait un autre choix,
+à expliciter, pas une conséquence implicite du mot « temporaire ».
+
+## État réel du socle
+
+La [beta.018](companions-cosmetics-beta018.md) a livré la case cape, les gestes
+d'équipement, la sauvegarde et le rendu partagé. Le code consulté contient une
+seule cape, `sanctuary:zero_cape`, disponible en créatif ou par `/give`.
+**Cape Zéro est actuellement visuelle : aucun bonus de gameplay n'est appliqué
+par son service.** Son apparence est provisoire. Le filtre d'équipement et le
+rendu reconnaissent explicitement cet objet ; un catalogue demande leur extension.
+
+Les [lootboxes de capes](vision.md#panneaux-et-lootboxes) appartiennent à la vision.
+Elles ne constituent pas une acquisition en survie déjà livrée. Les familiers,
+la progression, le portage, les bateaux et le temps réel existent et devront
+être pris en compte lors des essais des effets retenus.
+
+## Périmètre proposé pour un premier lot jouable
+
+Livrer **trois capes aux usages distincts**, leur description FR/EN, leur effet
+serveur et une première voie d'obtention rare effectivement jouable. Le choix
+des trois capes ci-dessous est une proposition de prototype, pas un catalogue
+approuvé. Les autres modèles pourront suivre par petits lots.
+
+| Piste FR / EN | Pouvoir envisagé | Point d'équilibrage à éprouver |
+| --- | --- | --- |
+| **Cape de la Brise / Breeze Cape** | Bonus permanent de vitesse de déplacement au sol. | Utilité quotidienne ; cumul avec Sprint, potions, familiers et ralentissement du portage. Un bonus simple peut rester sans malus. |
+| **Cape du Brasier / Ember Cape** | Forte augmentation des dégâts de mêlée ; réduction de la vie maximale comme contrepartie possible. | Gain offensif réellement sensible ; risque assumé et lisible. Vérifier si le malus influe sur les combats ou s'annule facilement par une combinaison. |
+| **Cape de l'Éclipse / Eclipse Cape** | Vol libre pendant une courte fenêtre récurrente, pouvoir volontairement exceptionnel. | Accès entre îles, exploration, transport et sortie de fenêtre en plein vol. Durée, fréquence et éventuelles restrictions à décider après essai. |
+
+Pour chaque cape sélectionnée, renseigner avant implémentation : nom FR/EN,
+identifiant stable, visuel et provenance, effet chiffré, conditions, éventuel
+malus, cumuls, acquisition, fréquence d'obtention et règle temporelle complète.
+Le devenir de Cape Zéro reste une décision distincte : ne pas attribuer
+automatiquement un nouveau pouvoir aux exemplaires existants.
+
+Ce lot réutilise la case existante. Il ne nécessite ni nouveau monde, ni nouvelle
+génération, ni économie complète, ni système général de quêtes ou de lootboxes.
+La source de récompense doit être choisie parmi les mécanismes effectivement
+disponibles au démarrage ; si elle exige un chantier autonome, la référencer
+comme dépendance. Un prototype accessible uniquement par `/give` valide les
+pouvoirs, mais ne clôt pas le résultat « trouver une cape rare en survie ».
+
+## Équilibrage : mesurer ce que la cape change
+
+**La rareté ne suffit pas à prouver l'équilibre.** Une cape obtenue une seule fois
+peut servir quotidiennement, être prêtée à tout un groupe ou aider son détenteur
+à en obtenir d'autres. Une faible probabilité répétable peut finir par produire
+beaucoup d'exemplaires. À l'inverse, une cape très forte dans un contexte précis
+peut créer un moment mémorable sans dominer toute la progression.
+
+L'objectif proposé est que plusieurs capes aient des usages désirables, tout en
+gardant un parcours intéressant sans cape. Les exceptions qui court-circuitent
+une étape doivent être identifiées et assumées dans leur fiche.
+
+| Axe | Essai à réaliser et décision à en tirer |
+| --- | --- |
+| **Exploration et vide** | Comparer un trajet entre îles sans cape, avec cape et avec moyens de transport existants. Identifier les risques supprimés, les accès anticipés et l'utilité restante des infrastructures. |
+| **Combat PvE et PvP** | Mesurer dégâts, survie et possibilité de réponse à équipement comparable, puis en combinaison forte. Décider explicitement du traitement PvP ; ne pas le désactiver par défaut dans la conception. |
+| **Progression et production** | Relever temps gagné, ressources et XP obtenues. Vérifier si une cape rend superflus une compétence, une potion, un familier ou une étape collective. |
+| **Cumuls et coopération** | Éprouver cape + familier + équipement + potions, portage et prêt entre joueurs. Une seule case cape ne limite pas les autres sources de bonus. |
+| **Rareté dans le temps** | Estimer les exemplaires et détenteurs après une semaine et un mois, pour un joueur occasionnel, un joueur intensif et un groupe qui mutualise les récompenses. |
+| **Plaisir et choix** | Observer si les joueurs veulent réellement porter chaque cape, changent selon l'activité ou choisissent toujours la même. Un malus qui conduit à tout laisser au coffre rate l'intention. |
+
+Ajuster en priorité le contexte d'utilité, les cumuls, l'acquisition ou la période
+active lorsqu'ils permettent de conserver un pouvoir spectaculaire. Réduire
+la puissance ou ajouter un malus reste possible, sans imposer une pénalité à
+chaque cape. Une cape maudite à malus seul reste une piste à arbitrer.
+
+### Rareté et circulation
+
+- Fixer la source, les joueurs éligibles, la fréquence des tentatives, le taux
+  ou quota éventuel et la possibilité de renouveler la récompense.
+- Distinguer rareté d'un modèle et rareté de l'ensemble : beaucoup de modèles
+  très rares peuvent rendre l'obtention d'une cape quelconque fréquente.
+- Examiner les prêts, échanges, doublons, récompenses rejouées et New Game+.
+  Liaison au joueur et exemplaire unique au serveur sont des options, pas des
+  règles acquises. Les nouveaux arrivants doivent être inclus dans l'essai.
+- Documenter les hypothèses de calcul et confronter la rareté attendue à des
+  essais. Un taux de butin bas, seul, n'est pas un critère d'acceptation suffisant.
+
+### Périodes d'activité des capes exceptionnelles
+
+Choisir, pour chaque cape concernée, **un modèle temporel explicite** : fenêtre
+commune récurrente, durée depuis l'obtention, ou budget de temps d'utilisation.
+Une période d'obtention limitée et une période d'effet limitée sont distinctes.
+
+Le contrat précise l'horloge utilisée, début, fin, fréquence, temps hors ligne,
+arrêts serveur et effet des changements de mode Vanilla/Real Time. Une fenêtre
+liée à une heure réelle doit aussi être essayée du point de vue des joueurs
+qui ne peuvent pas se connecter à cette heure.
+
+Le serveur fait autorité. Retirer, rééquiper, prêter, mourir, se reconnecter ou
+redémarrer ne doit pas réinitialiser involontairement une durée ou une recharge.
+L'interface indique l'état actif/dormant, le temps restant et la prochaine
+occasion lorsqu'elle est prévisible. Prévoir l'avertissement et la transition
+de fin : pour le vol, définir une sortie praticable, sans mort surprise ni
+prolongation illimitée par rééquipement.
+
+## Contrat technique à écrire avant le code
+
+- Une seule cape active par joueur ; effets et conditions calculés côté serveur.
+  Une préférence visuelle ne peut pas accorder ou prolonger un pouvoir.
+- Appliquer et retirer uniquement la contribution de la cape. Préserver un
+  effet identique venant d'une potion ou d'un familier ; préciser addition,
+  multiplication, priorité ou plafond pour chaque cumul pertinent.
+- Traiter changement de cape, mort, tombe, `keepInventory`, changement de
+  dimension, reconnexion et New Game+ avec les règles d'inventaire existantes.
+  Définir aussi le retrait d'un bonus de vie ou d'un malus de vie maximale,
+  sans soin gratuit par alternance de capes.
+- Conserver `sanctuary:zero_cape` et les emplacements existants. Tout ajout de
+  données persistantes, notamment temporelles, exige un contrat de migration
+  explicite et des essais sur des copies de sauvegardes de développement.
+- Décrire en FR/EN bonus, contrepartie, conditions et durée avant équipement.
+  Vérifier le rendu porté et les élytres sur la version Minecraft exacte du lot.
+
+## Critères d'acceptation de la future livraison
+
+- [ ] Les trois fiches sont complètes ; valeurs, obtention, cumuls et traitement
+  temporel sont fixés, avec les conséquences fortes assumées par la conception.
+- [ ] Un joueur peut obtenir une cape par la voie de survie retenue, l'équiper,
+  comprendre son pouvoir et constater son effet réel. Une récompense unique
+  ne peut pas être réclamée plusieurs fois par reconnexion.
+- [ ] Le bonus permanent reste actif au-delà de la durée d'une potion ordinaire
+  tant que la cape est portée. Stockage et retrait ne laissent aucun bonus indu.
+- [ ] Deux joueurs voient un équipement cohérent ; changement rapide de cape,
+  effet concurrent et prêt ne produisent ni cumul résiduel ni duplication.
+- [ ] Les limites de période fonctionnent avant, pendant et après la fenêtre,
+  y compris après arrêt/reprise et transfert ; la sortie d'un pouvoir dangereux
+  respecte la transition annoncée.
+- [ ] Mort/tombe, `keepInventory`, dimension, reconnexion, redémarrage et
+  New Game+ conservent les objets et durées selon le contrat de migration.
+- [ ] Un compte rendu compare sans cape, chaque cape seule et les combinaisons
+  les plus fortes, en début et en fin de progression, en solo et à 2–4 joueurs.
+  Il relève gains, abus possibles, circulation attendue et ajustements retenus.
+- [ ] Aucun pouvoir n'est déclaré équilibré sur la seule base de sa rareté ou
+  d'un build réussi ; les limites de l'essai sont documentées.
+- [ ] `./gradlew check build` passe avec les tests utiles aux effets retenus ;
+  `./gradlew assemblePack` vérifie la distribution. Versions et note de livraison
+  suivent [le compteur bêta](versioning.md). Parcours client FR/EN vérifié.
+
+## Décisions encore ouvertes
+
+1. Confirmer « permanent tant que porté » et le rôle des capes à malus seul.
+2. Choisir les trois premières capes, leurs valeurs et le devenir de Cape Zéro.
+3. Choisir la première acquisition jouable et la rareté visée, puis décider
+   des échanges et des éventuels quotas.
+4. Choisir la règle temporelle des exceptions, leurs cumuls, leur traitement
+   PvP et les étapes de progression qu'elles peuvent volontairement dépasser.
+
+## Références vérifiées pour cette préparation
+
+- [Vision : progression](vision.md#inventaire-prestige-et-déblocages) et
+  [récompenses](vision.md#panneaux-et-lootboxes).
+- [Service actuel des accessoires](../mods/sanctuary/src/main/java/fr/koka/sanctuary/cosmetics/AccessoryService.java),
+  [filtre et stockage](../mods/sanctuary/src/main/java/fr/koka/sanctuary/inventory/AccessoryContainer.java)
+  et [rendu](../mods/sanctuary/src/main/java/fr/koka/sanctuary/mixin/client/AccessoryAvatarRendererMixin.java).
+- [Catalogue des familiers beta.032](spawn-eggs-v2-catalogue-beta032.md), à
+  confronter au code courant lors des essais de cumul.
+
+Validation de ce ticket : lecture du socle, vérification des références locales
+et relecture du diff documentaire. Aucun essai de gameplay ni build exécuté
+pour cette rédaction ; les critères ci-dessus concernent la future implémentation.

docs/carried-flight-panic-beta114.md

@@ -0,0 +1,91 @@
+# CARRY-08 — Fuite des animaux volants portés — beta.114
+
+Contrat du 17 septembre 2026, branche `codex/carried-flight-panic-beta114`.
+
+Un coup reçu par un animal volant porté sur la tête déclenche une fuite de
+40 à 60 ticks : il entraîne son porteur vers le haut, dans une direction
+aléatoire, avec des embardées. Le serveur choisit le départ et la trajectoire,
+transmis au client pour la physique native. Les touches de déplacement et le
+regard ne pilotent pas cette brève fuite. La caméra reste libre. Un nouveau coup peut relancer la fuite avec un autre
+cap après dix ticks, sans cumuler les vitesses.
+
+Le porteur peut viser et frapper son animal volant. Les animaux ordinaires
+reçoivent les dégâts habituels ; le familier conserve son coup amical sans
+perte de santé. Les attaques extérieures acceptées déclenchent aussi la fuite.
+Les autres protections entre passagers et porteurs restent en place.
+Les espèces reprennent le groupe déjà utilisé pour planer, poule comprise.
+
+La vitesse reste bornée, les collisions sont natives et aucun bloc n’est
+traversé ni déplacé. Déposer l’animal (Maj + clic droit), le perdre, mourir,
+se déconnecter ou changer de dimension arrête la propulsion. Immersion,
+mode spectateur, vol créatif, élytres et porteur lui-même passager l’inhibent.
+La fin de fuite rend le contrôle au joueur et conserve le planeur existant
+si l’animal reste porté. Les montures colossales gardent leur pilotage actuel.
+
+L’état de fuite est temporaire, synchronisé et non sauvegardé. Aucun format
+persistant, identifiant existant ou monde personnel n’est modifié. Les nouveaux
+retours d’interface sont traduits FR/EN. Client et serveur utilisent beta.114.
+
+## Vérifications natives
+
+`CarryPanic114ClientChecks` passe en **56 secondes** avec un serveur intégré
+Minecraft 26.3 et un monde plat jetable de graine 114 :
+
+- Véritable ciblage du perroquet sur la tête et frappe avec la touche native,
+  perte de santé de l’animal ordinaire, décollage et déplacement du joueur.
+- Trajectoire synchronisée et priorité sur les touches avant/droite/saut et
+  le regard ; comparaison exacte avec la vitesse du tick de physique.
+- Expiration, suppression de l’état temporaire et retour au planeur normal.
+- 32 trajectoires tirées côté serveur couvrent les quatre quadrants, toutes
+  dans les bornes de durée et de vitesse ; Maj + clic droit natif interrompt.
+- Sept espèces ordinaires : poule, chauve-souris, abeille, allay, perroquet,
+  blaze et breeze. Une vache portée reste protégée et ne déclenche aucun vol.
+- Attaque extérieure, mort, activation du vol créatif et détachement arrêtent
+  ou déclenchent la réaction selon le contrat.
+- Plafond bas : aucune traversée ; le passager bloqué est déposé par les
+  contrôles de place existants et la propulsion s’interrompt.
+- Véritable coup amical sur un familier perroquet : lancement sans perte de
+  santé, puis arrêt immédiat lors du détachement.
+
+```sh
+./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryCarryPanic114ClientTests=true \
+  -PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true
+```
+
+Marqueurs `CARRY114_NATIVE_FLIGHT_PASS` et `CARRY114_PASS` dans
+`build/carry-panic114-client.log`. Capture en jeu relue dans
+`build/carry-panic114-evidence/`. Le GameTest dédié reste exclu conformément
+au refus antérieur de son EULA. Pas de test Windows, de réseau distant ou de
+latence simulée ; aucun monde personnel n’a été ouvert.
+
+## Livraison
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+passe en **2 min 22 s**, 125 tâches. Les sources JAR correspondent exactement
+aux sources du dépôt. Les classes et ressources hors de ce ticket restent
+identiques à beta.113, notamment les sculptures d’argile. Les deux packs
+contiennent le même JAR, sans monde, GLB ni classes de test.
+
+- Sanctuary-beta.114.mrpack : 10179428 octets, SHA-256
+  `92aac61c2c00a2206f3f5ac3d170ab058f6765526cf5a2a64c5336261db3f5bf`.
+- Sanctuary-Test-beta.114.mrpack : 10198350 octets, SHA-256
+  `5e8ec1f18e34ca51e09e2738f2b04f9a1bbac5d14c7a7c2d766218a4cff6021f`.
+- JAR Sanctuary : SHA-256
+  `18105b76f63008210c62d5728f999c7abc083a861ecc1de2c7ee87262dde5a40`.
+
+Reçu local : `build/carry-panic114-artifact.json`.
+
+## Publication et installation
+
+La [release beta.114](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.114)
+est publiée depuis `21845bd7367a260ee6a3d189417a8620aa5bf738`. Le tag exact
+et les artefacts sont immuables ; les téléchargements publics sont vérifiés.
+Le canal packwiz avance à `c26f3bb59491c9bb4bbdd27f59571ef84f417f7b`.
+
+Deux synchronisations isolées puis deux passages dans **Sanctuary Beta** ont
+réussi. Un seul JAR Sanctuary beta.114 est actif, et le second passage conserve
+les mêmes hashes. Les **923 fichiers personnels et réglages suivis** restent
+identiques. Aucun monde personnel n’a été ouvert. La sauvegarde ciblée est
+`sanctuary-backups/before-beta.114/` dans l’instance existante. Reçus locaux :
+`build/carry-panic114-isolated.json` et `build/carry-panic114-prism.json`.

docs/catalogue-progression-beta099.md

@@ -0,0 +1,127 @@
+# beta.099 — Progression, catalogue du Métabli et gestes K
+
+Contrat de réalisation, 16 septembre 2026. Branche `codex/catalogue-progression-beta099`.
+
+- Compétences en haut de la colonne gauche, arbre des progrès Minecraft intégré
+  dessous ; aptitudes à droite. Prestige et historique sous l’arbre.
+- Catalogue visuel natif : trois derniers plans terminés en accueil, statues,
+  machines, bâtiments, infrastructures, décoration et bibliothèque. Même format
+  de fiches (aperçu, nom, dimensions, description et sélection).
+- Historique personnel local de trois plans terminés, sans autorité sur le monde :
+  aucun choix de plan n’est compté comme construction et chaque placement reste
+  contrôlé par le serveur. Le stockage est distinct des sauvegardes Minecraft.
+- Palette de statue étendue aux blocs ayant un objet utilisable, échantillonnée
+  depuis le pack actif. Pas de blocs techniques sans objet ni de commandes.
+- Clé dorée : modèle plat d’outil Minecraft. Texture provisoire vanilla, à
+  remplacer par la texture que le créateur fournira ; aucune texture dessinée
+  à sa place.
+- K bref ancre au bloc visé ; rappuyer sur le même point tourne de 90 degrés.
+  K maintenu ouvre le cockpit. Viser le vide ne repositionne pas le projet.
+
+## Contrat de génération et de compatibilité
+
+Le module EXPANSION_HALL conserve sa géométrie, ses appuis, son piédestal et son
+identifiant. Les nouvelles pièces natives de la salle indépendante portent un
+champ optionnel `SanctuaryMetatable099=true` : neuf parties de Métabli assemblées
+sont posées au centre, un bloc au-dessus du piédestal. Une pièce enregistrée sans
+ce champ conserve son comportement ancien (aucun ajout), même si un de ses chunks
+n’était pas encore décoré. Le champ ne modifie ni le journal ni la graine ni les
+identifiants de génération. Aucune régénération ou écriture dans un monde
+personnel existant. Les nouvelles salles générées après cette version reçoivent
+l’exemple ; les salles déjà enregistrées ne sont pas modifiées.
+
+Une fois généré, le Métabli suit les règles normales : le casser le désassemble,
+et le reconstruire exige la clé dorée. Pas de réparation automatique au chargement.
+Vérification prévue sur nouvelles sauvegardes de développement et round-trip NBT
+avec et sans le champ optionnel, génération en plusieurs ordres de chunks.
+
+## Validation
+
+Deux essais natifs sur Minecraft **26.3 finale**, nouveaux mondes de développement :
+
+- `Catalogue099ClientChecks` : **réussi en 1 min 33 s**. Génération et construction
+  d’une statue de Creeper de 32 blocs (1 542 cellules) avec la palette étendue ;
+  construction des plans Fourneau et Abri, confirmation/annulation, retrait du
+  créatif pendant la confirmation et refus d’un envoi falsifié en survie. Pose
+  manuelle via le contrôleur Minecraft consommant exactement un bloc. Trois plans
+  terminés mémorisés, conservés au changement de monde, écrits sur disque et
+  décodés. Catalogue physique, catégories, aperçus, import/export, abandon et
+  destruction du Métabli ; K bref/rotation/visée vide/maintien. Arbre des progrès
+  sous les compétences, clic droit passant par l’écran et activant réellement le
+  suivi. Interfaces FR/EN, échelles 2 et 3, petite fenêtre et fenêtre 1280 × 800.
+- `Temple097ClientChecks`, étendu à la salle : **réussi en 4 min 48 s**, graine
+  **-4700804240597771092**, génération racine `sanctuary:island_v24`. Origine des
+  neuf parties du Métabli : **(-56, 169, -117)**, sur le piédestal de pierre lisse.
+  Les neuf états `part=0..8` sont présents après génération puis après sauvegarde
+  et réouverture du monde de développement. Aller-retour NBT du nouveau champ ;
+  ancien tag sans champ restant sans champ. Régression des deux temples natifs,
+  coffres, pièges et cache de planification réussie.
+
+Les captures d’interface vérifiées sont dans `build/catalog099-evidence/`.
+Journaux : `build/catalog099-client.log` et `build/catalog099-hall.log`.
+La capture de la salle prise immédiatement après téléportation précédait le
+rendu des chunks et n’est pas utilisée comme preuve visuelle ; les assertions
+sur les blocs, appuis et sauvegardes constituent la validation de sa génération.
+
+Les premiers passages ont détecté deux problèmes corrigés : les petits blocs
+(fleurs) favorisés par une comparaison de couleur seule, et la protection native
+des vestiges refusant l’ajout du Métabli hors de leur contexte de génération.
+Des clics automatisés immédiatement après redimensionnement donnaient aussi un
+rayon de caméra périmé : les interactions physiques répétées du test passent
+maintenant par le contrôleur client Minecraft et son protocole normal, avec
+contrôle serveur de la consommation et de l’ouverture. Les gestes K et le suivi
+des progrès restent testés par les événements d’entrée natifs.
+
+`check build assemblePack assembleTestPack` : **réussi en 3 min 7 s**, 124 tâches.
+Le GameTest sur serveur dédié est exclu ; les tests client natifs ci-dessus
+utilisent uniquement les mondes de développement.
+
+Les deux exports packwiz sont vérifiés : version, sources Java, contenu du JAR,
+absence des classes de test et conservation des archives beta.098. Reçu complet :
+`build/beta099-artifact.json`.
+
+| Archive | Octets | SHA-256 |
+| --- | ---: | --- |
+| `Sanctuary-beta.099.mrpack` | 9 908 941 | `9722e2410e18bba34cf5db835facec4bb29fc3bd7f071942e7c8321a60d955ed` |
+| `Sanctuary-Test-beta.099.mrpack` | 9 927 866 | `7ce02718c2e4c780197f9984b1ac7bc7a443f78eaa3e7d8ea248aa6b2e75745a` |
+
+Aucune publication du canal ni installation personnelle effectuée.
+
+## Détails du catalogue
+
+Les vignettes de plans utilisent les quads, UV et textures du pack actif.
+Les blocs rendus par un moteur spécial sans quads (certains conteneurs) ont une
+silhouette issue de leur forme. Les vignettes sont mises en cache (48 au maximum),
+invalidées lors d’un rechargement du pack. Les échantillons sont bornés à 64 × 64
+par texture et prennent la première image des textures animées.
+Les statues du catalogue affichent le modèle natif adulte ; le choix ouvre les
+réglages de hauteur et de palette avant génération. Sur les petites fenêtres,
+la description et les dimensions passent dans l’infobulle pour garder le choix
+visible sous la vignette.
+
+La palette « Tous les blocs » parcourt les blocs enregistrés ayant un objet,
+sans inclure les blocs techniques sans objet ou les blocs de commande. La
+comparaison de couleur utilise Oklab ; un coût de forme favorise les volumes
+pleins, et les blocs soumis à la gravité sont moins favorisés. Les feuilles
+utilisent leur état persistant, comme après une pose par un joueur. Les palettes
+mixte, laine et béton restent disponibles.
+
+L’historique `schematics/sanctuary/recent-completed.nbt` contient au maximum
+trois plans distincts, écrits atomiquement hors du fil de rendu. Il enregistre
+une transition d’incomplet à complet observée dans le monde, en créatif ou en
+survie. Sélectionner un plan, l’apercevoir ou l’envoyer au serveur ne suffit pas.
+Il s’agit d’un historique personnel de cette installation, pas d’un catalogue
+partagé par le serveur. Aucun inventaire ou entité n’est enregistré.
+
+K bref utilise un rayon de 96 blocs sur les blocs du monde. La case adjacente à
+la face visée sert de centre d’ancrage horizontal. Une seconde pression sur ce
+même point tourne autour de cet ancrage ; déplacer le regard vers un autre
+point déplace le plan. Le maintien de 10 ticks ouvre les commandes sans exécuter
+le geste bref à la relâche. Les raccourcis remappés utilisent la même logique.
+
+## Texture de la clé
+
+Le modèle est `minecraft:item/handheld` ; la texture provisoire est une copie
+de la pioche dorée vanilla. Le créateur pourra remplacer uniquement
+`mods/sanctuary/src/main/resources/assets/sanctuary/textures/item/golden_wrench.png`
+par son propre PNG. Aucune illustration personnalisée n’a été créée à sa place.

docs/clay-contrast-beta104.md

@@ -0,0 +1,40 @@
+# beta.104 — Contraste des argiles grise et noire
+
+Branche `codex/clay-contrast-beta104`, Minecraft 26.3.
+
+Le gris devient plus soutenu et le noir plus sombre, pour distinguer clairement
+les trois argiles gris clair/gris/noir. Les nuances du dessin vanilla sont
+renforcées : facteur 1,35 au lieu de 0,85. Le mélange conserve davantage de la
+couleur des briques fournies (80 % pour le gris, 90 % pour le noir).
+
+Les textures de bloc et de boule d’argile sont accordées, toujours en 16 × 16
+avec les silhouettes et transparences vanilla. La recoloration exacte par
+script reste la méthode choisie par le créateur. Les quatorze autres couleurs
+et toutes les briques restent identiques. Le rangement beta.103 est conservé.
+
+[Aperçu avant/après](../build/clay-contrast-beta104-preview.png).
+Le générateur écrit désormais son aperçu au nom de la version courante,
+pour préserver les aperçus historiques.
+
+## Validation et livraison
+
+`check build assemblePack assembleTestPack -x :sanctuary:runGameTest` réussi
+en 2 min 22 s (124 tâches). Comparaison visuelle avant/après effectuée.
+Pas de nouvelle session Minecraft pour cette modification de textures.
+
+La vérification des archives confirme exactement quatre textures modifiées :
+blocs et boules d’argile gris/noir. Toutes les classes Java, recettes, modèles,
+autres assets et anciennes archives beta.103 sont inchangés.
+Les images conservent leur taille 16 × 16 et leur transparence pixel par pixel.
+Le contraste mesuré augmente de plus de 40 % sur chacune des quatre textures.
+Luminance moyenne des blocs : gris clair 168,4 ; gris 118,0 ; noir 68,4.
+Sources, métadonnées et contenu des packs vérifiés ; `git diff --check` réussi.
+Reçu : `build/beta104-artifact.json`.
+
+- [Pack normal](../build/Sanctuary-beta.104.mrpack), SHA-256 :
+  `83f087cce41316eed620e9764ff0b643c3d5af40fa5b4cebdff5720740708631`.
+- [Pack de test](../build/Sanctuary-Test-beta.104.mrpack), SHA-256 :
+  `adbaad161550ab80dcbc88c27d760e2f735eef9a69ba3f9e2e69bbd25e895147`.
+
+Les GameTests dédiés restent exclus. Aucun monde, canal ou installation
+personnelle modifié ; archives locales uniquement.

docs/clay-sculpture-grid-beta113.md

@@ -0,0 +1,90 @@
+# STAT-04 — Sculptures d’argile et accroche au bord — beta.113
+
+Contrat du 17 septembre 2026, branche `codex/clay-sculpture-grid-beta113`.
+
+Les miniatures de l’atelier deviennent des « sculptures d’argile » / « Clay
+sculptures ». Le nom du modèle reste dans leur infobulle. Les statues en blocs
+du Métabli restent une catégorie distincte.
+
+À la pose, le bord horizontal le plus proche du point visé accueille la
+sculpture. L’autre axe est centré au pixel entier le plus proche, sur la grille
+de 1/16 de bloc. Sur une face latérale, elle touche le bord du bloc support.
+À égalité exacte entre deux bords, l’axe Z départage ; au centre exact,
+le bord côté joueur est retenu. L’orientation suit toujours le regard.
+Le bouton Tourner prépare le modèle avant fabrication. Les marges horizontales vides du modèle ne créent pas de décalage au bord.
+Tous les sommets restent
+sur la grille entière, même avec des dimensions impaires et après rotation.
+
+## Compatibilité préalable
+
+La propriété native additive `anchor` du bloc `sanctuary:statuary` mémorise
+`center`, `north`, `south`, `east` ou `west`. Un ancien état sans cette propriété
+prend `center` : il reste centré, avec la correction visuelle du demi-voxel.
+Le schéma 1, les voxels, noms de modèles et identifiants ne changent pas.
+Il n’y a aucun parcours ni réécriture de chunks existants. La sauvegarde native
+conserve l’accroche ; les rotations et miroirs de structures la transforment.
+Casser et reposer choisit une nouvelle accroche sans modifier le modèle.
+Les nouveaux objets emploient le nom traduit de leur type ; les noms déjà
+enregistrés et les noms personnalisés restent conservés. La collision cubique
+et la limite d’une sculpture par bloc restent inchangées. Client et serveur
+doivent utiliser ensemble beta.113.
+
+## Vérifications natives
+
+Le parcours `Statuary106ClientChecks`, étendu par `Sculpture113ClientChecks`,
+passe en **1 min 25 s**, sur Minecraft 26.3 et un monde plat jetable de graine 106 :
+
+- 5 120 combinaisons de largeur/profondeur, orientation et accroche : contrôle
+  de la géométrie émise, grille exacte de 1/16 et absence de dépassement du bloc.
+- Modèles avec marges transparentes, repères colorés pour vérifier le sens du
+  rendu et égalité de la géométrie centrée entre l’objet et le bloc.
+- Vrais clics de pose sur les quatre bords : orientation, bord côté serveur,
+  réception côté client, butin/repose et conservation après reconnexion.
+- Contextes natifs de pose sur les faces latérales et coordonnées négatives.
+- Rotation/miroir de chaque combinaison d’accroche et d’orientation ; lecture
+  des anciens états sans `anchor`, avec et sans `facing`.
+- Noms français/anglais des objets fabriqués, menu aux échelles 2 et 3,
+  fabrication payée, Maj-clic limité à la hotbar et régression Métabli.
+
+```sh
+./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryStatuary106ClientTests=true \
+  -PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true
+```
+
+Marqueurs `STATUARY113_PASS` et `SCULPTURE113_GEOMETRY_PASS` dans
+`build/clay-grid113-client.log`. Captures relues dans
+`build/clay-grid113-evidence/`. Le GameTest dédié reste exclu conformément au
+refus antérieur de son EULA ; ces essais utilisent le serveur intégré macOS.
+Pas de validation Windows ni depuis deux ordinateurs. Aucun monde personnel
+n’a été ouvert.
+
+## Livraison
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+passe en **3 min 11 s**, 125 tâches. Les sources JAR correspondent exactement
+aux sources du dépôt. Les classes et ressources hors du ticket sont identiques
+à beta.112. Les deux packs contiennent le même JAR, sans monde, GLB ni test.
+
+- Sanctuary-beta.113.mrpack : 10173807 octets, SHA-256
+  `ed082ff29a0e9a70fd6786bc024241b276cb516bc09fb5151d6cb324604429bb`.
+- Sanctuary-Test-beta.113.mrpack : 10192733 octets, SHA-256
+  `387f54dc77884a9c9bccdcc1904778ca7f0b2fbda126754fdc49b10a492e4602`.
+- JAR Sanctuary : SHA-256
+  `e242d9fd2edeede922a72a10e988e29c2b49dea52105cfc9fc8573154849ead3`.
+
+Reçu local : `build/clay-grid113-artifact.json`.
+
+## Publication et installation
+
+La [release beta.113](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.113)
+est publiée depuis `6166d0aa9eba3c3dd84b8b9f1501e3346231ac82`. Le tag exact
+et les artefacts sont immuables ; les téléchargements publics sont vérifiés.
+Le canal packwiz avance à `e4c16d517bfda4f2b688604cc61945a46a4513a9`.
+
+Deux synchronisations isolées puis deux passages dans **Sanctuary Beta** ont
+réussi. Un seul JAR Sanctuary beta.113 est actif, et le second passage conserve
+les mêmes hashes. Les **923 fichiers personnels et réglages suivis** restent
+identiques. Aucun monde personnel n’a été ouvert. La sauvegarde ciblée est
+`sanctuary-backups/before-beta.113/` dans l’instance existante. Reçus locaux :
+`build/clay-grid113-isolated.json` et `build/clay-grid113-prism.json`.

docs/clay-workshop-hotbar-beta112.md

@@ -0,0 +1,79 @@
+# STAT-03 — Atelier d’argile limité à la hotbar — beta.112
+
+Contrat du 17 septembre 2026, branche `codex/clay-workshop-hotbar-beta112`.
+
+Le menu utilise uniquement les neuf cases de la hotbar active du joueur,
+avec les deux emplacements de fabrication. Les rangées de réserve, y compris
+les extensions Sanctuary, ne sont ni ajoutées au menu ni utilisées par ses
+transferts. La rangée choisie avant l’ouverture reste la hotbar courante.
+La touche Tab retrouve la navigation des boutons dans ce menu.
+
+Le cadre nine-slice tient dans une hauteur fixe de 202 pixels d’interface.
+Il ne grandit plus avec la capacité de l’inventaire. Le Maj-clic du résultat
+cherche uniquement une place dans la hotbar ; sans place, il ne consomme pas
+d’argile. Les touches 1–9 restent utilisables, pas l’échange avec la seconde
+main. À la fermeture, la restitution native des objets restants est conservée.
+
+Les identifiants, sauvegardes, données de sculpture et orientations beta.111
+restent inchangés. Aucun monde existant n’est ouvert ou réécrit. Client et
+serveur doivent utiliser ensemble beta.112 pour les nouveaux indices du menu
+temporaire (11 cases au total).
+
+## Vérifications natives
+
+Le parcours `Statuary106ClientChecks`, étendu à beta.112, passe en **1 min 13 s**
+sur Minecraft 26.3 avec serveur intégré et monde plat jetable de graine 106 :
+
+- Menu FR/EN aux échelles 2 et 3 : hauteur fixe, neuf cases de hotbar native,
+  deux cases de fabrication et absence de panneau d’inventaire évolutif.
+- Fabrication par Maj-clic depuis la hotbar, avec de l’argile aussi présente
+  dans la réserve, l’extension et la seconde main : ces stocks restent intacts.
+- Rejet des indices de cases absents et de l’échange avec la seconde main.
+- Hotbar remplie de neuf piles : Maj-clic sans fabrication ni consommation.
+- Une seule place dans une pile de 63 statuaires : production d’un seul objet,
+  coût d’une argile, aucune statue transférée dans une case cachée.
+- Restitution de l’argile restante à la fermeture, seize teintes, quatre
+  orientations, butin/repose et sauvegarde/reconnexion sans fichier GLB.
+- Régression du Métabli et annulation d’import conservées.
+
+```sh
+./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryStatuary106ClientTests=true \
+  -PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true
+```
+
+Marqueur `STATUARY112_PASS` dans `build/clay-hotbar112-client.log` ; captures
+relues dans `build/clay-hotbar112-evidence/`. Le GameTest dédié reste exclu
+conformément au refus antérieur de son EULA. Pas de test Windows ni depuis
+deux ordinateurs ; aucun monde personnel n’a été ouvert.
+
+## Livraison vérifiée
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+passe en **3 min 6 s**, 125 tâches. Les sources JAR correspondent aux sources
+Java du dépôt. Les classes et ressources hors de ce ticket sont identiques
+à beta.111, notamment les données et le rendu orienté des statuaires.
+Les deux packs contiennent le même JAR, sans monde, GLB ni classes de tests.
+
+- Pack normal : 10 169 337 octets, SHA-256
+  `55723a5d7cb99e350ad8fe150e92e0567430b5261ca4685abd900be34068658f`.
+- Pack Test : 10 188 262 octets, SHA-256
+  `987818bf817ad80fd055b97e84bf4775fca54820d7c3055d6fd4089dc7a5a3c0`.
+- JAR : SHA-256
+  `9007a770bbe69db5846f93140d910514f10839cc34ec7c6315a9381d8850adaa`.
+
+Reçu local : `build/clay-hotbar112-artifact.json`.
+
+## Publication et installation
+
+La [release beta.112](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.112)
+est publiée depuis `1eaa976ecf328c6c20afe5e4eb67c48118f87f95`. Le tag exact
+et les artefacts sont immuables ; les téléchargements publics sont vérifiés.
+Le canal packwiz avance à `573c5b0d84fcb3e9fec7cc8a83981cf35eaa1ead`.
+
+Deux synchronisations isolées puis deux passages dans **Sanctuary Beta** ont
+réussi. Un seul JAR Sanctuary beta.112 est actif, et le second passage conserve
+les mêmes hashes. Les **923 fichiers personnels et réglages suivis** restent
+identiques. Aucun monde personnel n’a été ouvert. La sauvegarde ciblée est
+`sanctuary-backups/before-beta.112/` dans l’instance existante. Reçus locaux :
+`build/clay-hotbar112-isolated.json` et `build/clay-hotbar112-prism.json`.

docs/clay-workshop-integration-beta110.md

@@ -0,0 +1,128 @@
+# INTEGRATE-110 — Atelier d'argile dans la version complète
+
+Demande du 17 septembre 2026 : inclure le Clay Workshop dans la version avec
+la fonte saisonnière. Branche `codex/clay-workshop-integration-beta110`.
+État : version commune vérifiée, publiée et synchronisée dans Sanctuary Beta.
+
+## Périmètre et compatibilité
+
+La beta.110 réunit le Clay Workshop / atelier d'argile, le Statuaire et l'import
+GLB de beta.106 avec les œufs de beta.107, la neige en volume de beta.108 et
+la fonte saisonnière de beta.109. Aucune fonction retirée de ces livraisons.
+Le Métabli conserve son import de modèles 3D en plans de construction.
+
+Les sources du dossier principal correspondent déjà à cette union : les
+30 fichiers de production du Statuaire sont ceux de la livraison beta.106 ;
+les traductions FR/EN et listes de mixins sont la réunion exacte des deux bases,
+sans conflit de valeur ni doublon. Les autres sources restent celles de beta.109.
+Les fichiers Finder `.DS_Store` sont exclus par la configuration Gradle existante.
+
+Les identifiants et contrats de données restent ceux des tickets existants :
+[Statuaire](statuary-beta106.md), [œufs](spawn-eggs-acquisition-beta107.md),
+[accumulation](snow-accumulation-beta108.md),
+[fonte](seasonal-snow-melt-beta109.md). Aucun format changé, aucune migration,
+aucune génération ou expansion activée. Les tests créent des mondes de
+laboratoire et rouvrent seulement leurs propres sauvegardes jetables.
+
+Les compteurs `mod_version`, `pack_version` et le manifeste packwiz passent
+ensemble à beta.110. Les archives beta.106 à beta.109 restent immuables.
+Le créateur a ensuite demandé de tout mettre à jour : publication de la
+version vérifiée sur le canal stable puis synchronisation de l’instance
+Sanctuary Beta existante, après sauvegarde des fichiers gérés.
+
+## Validation exécutée
+
+Réutilisation des essais natifs de l'atelier (fabrication, rendu, Métabli et
+sauvegarde/rechargement), des œufs (reproduction, éclosion et générateurs), et
+de la neige (accumulation et fonte selon les saisons, provenance et rechargement)
+sur les mêmes sources réunies. Puis `check build assemblePack assembleTestPack`.
+Le GameTest dédié reste exclu conformément au refus antérieur de son EULA ;
+les tests natifs tournent avec le serveur intégré.
+
+## Contrat de mise à jour de l'instance existante
+
+Cible unique : `Sanctuary-0.1.0-alpha.1`, nom affiché **Sanctuary Beta**, déjà
+reliée au canal `sanctuary-beta/packwiz`. Les instances historiques 26.2 et les
+instances importées séparément restent hors de cette synchronisation.
+
+Minecraft 26.3-pre-2 passe à 26.3 finale, Fabric Loader reste en 0.19.5,
+Fabric API passe de 0.160.0+26.3 à 0.160.5+26.3 ; Java 25 est déjà configuré.
+L'installateur packwiz est chargé de remplacer les deux JAR suivis et d'ajuster
+les composants de lancement. Sauvegarde préalable des JAR gérés, du suivi
+packwiz, de `instance.cfg` et de `mmc-pack.json` hors de `mods/`.
+
+Aucun monde personnel ne sera ouvert, converti, régénéré ou exploré pendant
+l'opération. Les fichiers de sauvegarde, réglages, captures et packs personnels
+sont comparés par empreintes avant/après. Seuls les composants gérés du pack et
+la version du lanceur changent. Les anciennes règles de génération enregistrées
+dans les mondes restent intactes ; aucune promesse de migration automatique de
+sauvegarde entre versions Minecraft n'est déduite de la mise à jour des fichiers.
+Le canal est publié avec un artefact immuable et testé deux fois dans une
+installation isolée avant les deux synchronisations de l'instance existante.
+
+## Résultats de la version commune
+
+Tous les parcours sont exécutés sur les mêmes sources beta.110, sous Java 25,
+Minecraft 26.3 et Fabric API 0.160.5+26.3 :
+
+- Atelier d'argile : **1 min 6 s**, `STATUARY106_PASS` et import Khronos indépendant.
+  Fabrication payante, 16 argiles, placement, butin, Métabli et rechargement sans
+  le fichier source. Captures relues dans `build/integration110-evidence/`.
+- Œufs : **29 s**, `EGGS107_NATIVE_PASS` ; reproduction, variantes, œufs utilisés
+  et distribués, générateurs et monde sans règles Sanctuary.
+- Neige : **42 s**, `SNOW108_NATIVE_PASS` et `MELT109_NATIVE_PASS` ; limite de
+  deux blocs, saisons, protection des constructions et sauvegarde/rechargement.
+- `./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest` :
+  **2 min 20 s**, **125 tâches**, réussite.
+
+Le JAR est comparé à l'union exacte des classes et ressources des deux livraisons
+immuables beta.106 et beta.109. Les traductions et mixins réunissent tous les
+éléments, sans doublon. Les sources JAR correspondent aux fichiers Java locaux.
+Aucun GLB de test, classe de test, monde ou fichier Finder embarqué.
+
+[Pack normal](../build/Sanctuary-beta.110.mrpack) ·
+[Pack Test](../build/Sanctuary-Test-beta.110.mrpack).
+
+| Artefact | SHA-256 |
+| --- | --- |
+| Normal | `12a7b7279e831bf5d3489d033b875437ad9e8ba1e8cbecc6107a890d312e3029` |
+| Test | `ffed5e4fcd32ca32ac96186da8e987905cd7fc4de792afe61aca9ad064895e0b` |
+| JAR Sanctuary | `7cb121a6e208cdd184d80ebe61f8bc52b6703b1c1d7611eeeb700aa88d158b46` |
+
+Reçu : `build/integration110-artifact.json`, manifeste des sources :
+`build/integration110-source-manifest.json`. Journaux :
+`build/integration110-{statuary,eggs,snow,check-build}.log`.
+Les essais natifs sont macOS avec serveur intégré ; pas de test Windows ni
+connexion depuis un second ordinateur. La neige antérieure non suivie garde
+la limite de fonte documentée dans beta.109.
+
+Le script de publication a été corrigé pour autoriser uniquement `icon.png`
+en plus des manifestes TOML, après contrôle de l'index et comparaison à l'icône
+source. Les JAR restent exclusivement des pièces jointes de release. Cette
+correction de distribution ne change aucun binaire ni le tag source beta.110.
+
+## Publication et installation terminées
+
+[Release beta.110](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.110),
+tag source `468743bfe75087ecb0160b85a0864fa81bcdded5`. Les sources cumulatives
+depuis beta.092 sont enregistrées ; les anciens tags et artefacts sont conservés.
+Les corrections du script de distribution et ce reçu complètent la branche
+source sans déplacer ce tag ni remplacer les binaires.
+
+Canal packwiz : `828353a6e2bd747f4f473ae9fb9e965d38032419`. Chaque manifeste et
+l'icône publiés correspondent aux fichiers validés localement. JAR, archives
+normale/Test et ZIP d'amorçage Prism sont disponibles dans la release.
+
+Deux synchronisations de l'installateur packwiz dans un dossier neuf, puis deux
+dans la même instance **Sanctuary Beta**, ont réussi. Le second passage ne
+change aucun fichier géré. Un seul JAR Sanctuary beta.110 est actif, Fabric API
+0.160.5+26.3 est installé, Minecraft est réglé sur 26.3 et Loader sur 0.19.5.
+L'icône déclarée dans le pack est ajoutée. `instance.cfg` et les **923 fichiers
+personnels et réglages suivis** conservent leurs empreintes. Aucun monde ouvert,
+converti ou régénéré ; aucune autre instance ni serveur personnel modifié.
+
+Sauvegarde ciblée dans l'instance : `sanctuary-backups/before-beta.110/`.
+Reçus ignorés : `build/integration110-publication.json`,
+`build/integration110-isolated.json`, `build/integration110-prism.json`.
+Les journaux de chaque synchronisation et les listes d'empreintes avant/après
+sont conservés dans le dossier de développement et dans la sauvegarde ciblée.

docs/clay-workshop-ui-beta111.md

@@ -0,0 +1,99 @@
+# STAT-02 — Atelier d’argile et orientation — beta.111
+
+Contrat du 17 septembre 2026, branche `codex/clay-workshop-ui-beta111`.
+
+## Résultat attendu
+
+Le menu utilise le cadre `task_frame_unobtained.png` fourni par le créateur,
+sans retouche, comme sprite Sanctuary avec les métadonnées nine-slice natives
+de Minecraft. Les coins restent à leur taille d’origine. Catalogue, aperçu,
+fabrication, explications et inventaire évolutif tiennent dans ce cadre.
+La texture reste remplaçable par un pack de ressources.
+
+La pose d’un statuaire suit le regard horizontal du joueur, dans les quatre
+directions. Le bouton Tourner règle toujours l’orientation du modèle importé.
+Le placement ajoute ensuite l’orientation du bloc sans réécrire ses voxels.
+
+## Contrat de compatibilité préalable
+
+Ajout de la propriété native `facing` au bloc `sanctuary:statuary`, avec `south`
+par défaut : cette orientation correspond au rendu historique, sans rotation.
+Les anciens états sans propriété prennent cette valeur à la lecture et gardent
+leur apparence. Aucun parcours ni réécriture des anciens chunks n’est effectué.
+Le schéma 1 de la sculpture, ses voxels, ses identifiants et les données des
+objets restent identiques. Casser puis reposer utilise le nouveau regard,
+sans cumuler les orientations précédentes. Rotation et miroir de structures
+transforment l’état du bloc. La collision cubique reste celle déjà livrée.
+
+## Texture
+
+Le fichier fourni, 26 × 26 pixels, est conservé octet pour octet sous
+`assets/sanctuary/textures/gui/sprites/container/clay_workshop/frame.png`.
+Le fichier adjacent `.png.mcmeta` utilise le moteur `nine_slice` de Minecraft
+avec une bordure fixe de quatre pixels et un centre extensible. L’identifiant
+du sprite est `sanctuary:container/clay_workshop/frame` ; aucun sprite global
+Minecraft n’est remplacé. Les emplacements utilisent `minecraft:container/slot`.
+
+## Vérifications natives
+
+`Statuary106ClientChecks`, étendu aux cas beta.111, passe en **1 min 3 s** sur
+Minecraft 26.3, avec serveur intégré et monde plat jetable de graine 106 :
+
+- Fabrication payée, restitutions, Maj-clic et teintes des seize argiles.
+- Menu FR/EN aux échelles 2 et 3, cases et actions contenues dans le cadre.
+- Six rangées d’inventaire à l’échelle 3 : affichage borné et défilement.
+- Vrais clics de pose aux quatre points cardinaux : état côté serveur,
+  transmission au client et rotation du rendu alignés sur le regard.
+- Rotation et miroir de structures ; lecture d’un ancien état sans `facing`.
+- Butin d’une statue orientée au nord puis repose vers l’ouest : nouvelle
+  orientation, mêmes voxels. Sauvegarde/réouverture et transmission sans GLB.
+- Conversion au Métabli et annulation d’import conservées.
+
+Commande :
+
+```sh
+./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryStatuary106ClientTests=true \
+  -PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true
+```
+
+Marqueurs `STATUARY106_PASS`, `STATUARY106_INTEROP_PASS` et `STATUARY111_PASS`
+dans `build/clay-ui111-client.log`. Captures dans `build/clay-ui111-evidence/`,
+dont les menus français et anglais relus visuellement.
+
+Le GameTest dédié reste exclu conformément au refus antérieur de son EULA.
+Les essais tournent sur macOS avec serveur intégré ; pas de validation depuis
+deux ordinateurs ni sur Windows. Aucun monde personnel n’est ouvert.
+
+## Livraison vérifiée
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+passe en **2 min 33 s**, 125 tâches. Les sources JAR correspondent exactement
+aux fichiers Java du dépôt. Le contenu du mod hors classes et ressources de
+ce ticket est identique à beta.110 ; œufs, neige et fonte restent inclus.
+Les deux MRpack contiennent le même JAR vérifié, sans monde, GLB ni classe de test.
+
+- Pack normal : `build/Sanctuary-beta.111.mrpack`, 10 169 372 octets,
+  SHA-256 `f83098f80ac2edb8e32877bf8d5a362cd75f2fa9020593c2c7e4f9abe8b3e9f6`.
+- Pack Test : `build/Sanctuary-Test-beta.111.mrpack`, 10 188 298 octets,
+  SHA-256 `1234b10eb4685d99aa7421de46bc54fd114b791f1b4d63803a09afc926d2c9d9`.
+- JAR Sanctuary : SHA-256
+  `b3e967db7b336b970e4121981e3ef8140fe90f0ecc5850ce90a70caaf3772684`.
+
+Reçu local : `build/clay-ui111-artifact.json`.
+
+## Publication et installation
+
+La [release beta.111](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.111)
+est publiée depuis le commit source `289697becf19db4acf50d224b1dd3d753eff1153`.
+Le tag exact et les artefacts sont immuables ; leurs téléchargements publics
+ont été vérifiés. Le canal packwiz avance au commit
+`87c9f81761309316c601ed32fa922c1a5893952c`.
+
+Deux synchronisations isolées puis deux passages dans l’instance existante
+**Sanctuary Beta** ont réussi. Un seul JAR Sanctuary beta.111 est actif ; le
+second passage conserve les mêmes hashes. Les **923 fichiers personnels et
+réglages suivis** restent identiques. Aucun monde personnel n’a été ouvert.
+La sauvegarde ciblée est dans `sanctuary-backups/before-beta.111/` de cette
+instance. Reçus : `build/clay-ui111-isolated.json` et
+`build/clay-ui111-prism.json`.

docs/cloud-vortex-beta077.md

@@ -0,0 +1,49 @@
+# beta.077 — tourbillon de nuages au-dessus du vide
+
+Branche `codex/cloud-vortex-beta077`. Minecraft 26.3-pre-2, textures beta.070.
+
+La dernière précision du créateur fixe la couche à **Y = 0**, et non 64.
+Les nuages supérieurs restent présents. Un tourbillon continu tourne autour
+du centre de l’île de Sanctuary ; son diamètre vaut deux fois celui de l’île
+(1 448 blocs / environ 91 chunks pour l’île habituelle de 724 blocs).
+Une révolution dure 20 minutes de simulation. Le style garde les cellules de
+12 blocs, l’épaisseur de 4 blocs et l’éclairage des nuages Minecraft.
+
+Le serveur transmet uniquement le centre et le diamètre déjà définis par le
+générateur. Aucun chunk, bloc, sauvegarde ou génération n’est modifié. Les
+mondes classiques/plats et les autres dimensions ne reçoivent pas de couche.
+Les réglages de nuages désactivés/rapides/détaillés sont respectés.
+
+La géométrie est calculée une fois puis conservée sur le GPU. La rotation et
+la couleur passent par les uniforms natifs, sans remaillage à chaque mouvement
+de caméra. Les passes normales et de transparence Fabulous réutilisent les
+pipelines de nuages du jeu. Les buffers sont libérés à la déconnexion.
+
+Cette livraison inclut les [correctifs de menus beta.076](menu-navigation-beta076.md)
+et le retrait du lien web de la [bibliothèque beta.075](plans-library-beta075.md).
+
+## Vérifications
+
+Parcours client natif réussi en 1 min 8 s : formes connectées pour les îles de
+512, 724 et 1 024 blocs ; rendu rapide/détaillé/Fabulous (passages OIT réellement
+exécutés), rotation, vues au-dessus/dessous/dans la couche, désactivation et
+extension finie. Une seule construction de géométrie pendant les mouvements
+et changements de qualité. 5 888 cellules pour l’île habituelle.
+Captures : `build/cloud077-evidence/`.
+`check build assemblePack assembleTestPack` réussit en 3 min 22 s (124 tâches),
+avec le serveur dédié exclu conformément au refus de son EULA.
+Les 1 693 classes et les sources du JAR correspondent au build ; seuls les
+menus et le nouveau rendu changent depuis beta.075. Les textures, données de
+jeu et le resource pack restent identiques. Les onze libellés sont présents
+en FR/EN. Les deux packs sont vérifiés et 155 archives précédentes restent
+identiques. Reçu : `build/cloud077-artifact.json`.
+Pas de déploiement dans une installation personnelle ni de serveur dédié.
+Les shaders externes qui remplacent entièrement le rendu des nuages restent
+à vérifier séparément ; aucune compatibilité non testée n’est promise.
+
+## Archives
+
+- [Sanctuary-beta.077.mrpack](../build/Sanctuary-beta.077.mrpack), 9608669 octets.
+  SHA-256 : `1c3839f086e9545c920e4ebfc13f99a25d0684fa6f2dc8e1b2a842a8e7044045`.
+- [Sanctuary-Test-beta.077.mrpack](../build/Sanctuary-Test-beta.077.mrpack), 9627602 octets.
+  SHA-256 : `1b0c302b9d4d5f59d5e954adbecde4acbacd9409c8cd6a743ccbe116826d7c0a`.

docs/collections-minecraft.md

@@ -249,6 +249,15 @@ Identifiant proposé : `sanctuary:clay_and_bricks`. **10 recettes primaires.**
 
 **Précision :** Le vase décoré appartient à Archéologie ; la terre cuite à C11.
 
+**Extension Sanctuary beta.102 :** seize couleurs de briques, dalles, escaliers,
+argile pastel et leurs deux items, soit 192 recettes supplémentaires. Elles
+sont déclarées dans `scripts/data/collections-sanctuary.json`, sans changer
+le recensement vanilla ci-dessus.
+
+**Extension Sanctuary beta.106 :** atelier d’argile et statuaires importés. La
+recette de l’atelier rejoint C06 ; la fabrication d’une miniature utilise son
+menu et un bloc d’argile, avec le modèle choisi localement.
+
 [Recettes et inventaire exacts de C06](collections-minecraft-inventaire.md#c06).
 
 [Définition serveur beta.035](../mods/sanctuary/src/main/resources/data/sanctuary/sanctuary_recipe_collections/clay_and_bricks.json).

docs/colored-brick-walls-beta118.md

@@ -0,0 +1,83 @@
+# beta.118 — Murets en briques de couleur
+
+Ticket sur `codex/colored-brick-walls-beta118`, Minecraft 26.3.
+
+Les seize familles de briques reçoivent un muret natif `WallBlock`, sous
+l'identifiant `sanctuary:<couleur>_brick_wall`. Chaque muret réutilise la texture
+de briques fournie de sa couleur, sans nouvelle image ni recoloration.
+
+Les murets forment une série de seize dans **Blocs colorés**, après les dalles
+et avant les argiles, dans l'ordre des couleurs vanilla retenu en beta.103.
+Les libellés sont traduits FR/EN.
+
+Recettes : six briques de même couleur, en deux rangées de trois, donnent six
+murets ; le tailleur de pierre donne un muret par bloc de briques. Les deux
+recettes par couleur rejoignent la collection Argile et briques et leurs
+déblocages. Totaux des ajouts colorés : 80 blocs, 112 objets dont ces blocs,
+224 recettes. Les recettes et identifiants préexistants sont conservés.
+
+Piliers, raccords entre couleurs et aux murets vanilla, côtés hauts/bas,
+collisions et immersion dans l'eau viennent du jeu. Tags natifs `walls`
+pour blocs et objets, pioche et butin de la bonne couleur. États, modèles
+multipart et butins sont repris des ressources exactes Minecraft 26.3.
+
+La génération reste reproductible dans `tools/generate-colored-bricks.py` ;
+elle conserve les ajouts externes à ses briques, notamment la recette du
+Clay Workshop et les membres Sculpture/Atelier. Le compilateur des collections
+reste leur seul générateur. Aucun ajout au
+terrain, changement de format ou migration de sauvegarde. Les dépendances
+et le pack de textures intégré beta.090 restent inchangés.
+
+## Vérifications et livraison
+
+Le scénario natif `Bricks102ClientChecks`, complété par `Walls118Checks`,
+passe en **38 secondes** sur un nouveau monde plat de graine 102 avec serveur
+intégré Minecraft 26.3 :
+
+- Seize murets réellement posés, dont une seconde série dans l'eau.
+- Recette de six murets et tailleur de pierre pour chaque couleur ; les
+  anciennes recettes de briques, dalles, escaliers et argiles passent aussi.
+- Raccords entre couleurs et au muret vanilla, retrait des piliers intermédiaires,
+  côtés relevés sous un bloc plein, collisions identiques au muret vanilla.
+- Eau conservée, pioche, butin de la bonne couleur, collection et recettes
+  découvertes, recette du Clay Workshop toujours découverte, série créative
+  de seize dans l'ordre natif.
+- États et modèles de tous les blocs de la famille vérifiés, sans texture
+  manquante ; sauvegarde et reconnexion conservent les murets et leur eau.
+
+Log : `build/walls118-client.log`, marqueur `WALLS118_PASS`. Capture de la
+galerie relue dans `build/walls118-evidence/`. Aucun essai Windows ou LAN ;
+GameTest dédié exclu selon le refus antérieur de son EULA. Aucun monde personnel
+ouvert. La régénération finale conserve à l'identique 2 024 fichiers de
+ressources et métadonnées.
+
+`check build assemblePack assembleTestPack -x :sanctuary:runGameTest` réussit
+en **2 min 5 s**, 125 tâches dont 101 exécutées. Sources et JAR concordants,
+intégrité ZIP, versions, modèles natifs, recettes et empreintes vérifiés.
+La comparaison avec beta.117 limite les changements de classes à
+`ColoredBricks` et ses classes internes ; les sculptures et chapeaux restent
+identiques. Les textures existantes sont toutes conservées octet pour octet.
+
+- `Sanctuary-beta.118.mrpack` : 10216437 octets, SHA-256
+  `75bb04aad981644888690aaeda9a293a94c5d32f6439ca24613365a41aba1b6b`.
+- `Sanctuary-Test-beta.118.mrpack` : 10235359 octets, SHA-256
+  `f7f0a177b8472f0e8c34ad99a1ccef5d61396014017d260e934e910c4e6eb00f`.
+- JAR Sanctuary :
+  `fc6edf4046a8ace357d561ed942213a22c7a27164fa160cdb4316f72ec302575`.
+
+Reçu : `build/walls118-artifact.json`.
+
+## Publication et instance
+
+La [release beta.118](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.118)
+est publiée : JAR, MRpack normal/Test et amorçage Prism, téléchargements publics
+et empreintes vérifiés. Le tag immuable désigne
+`0a81b3c1471c43d705eec4e31a8f6f1820049ca8`. Le canal packwiz avance au commit
+`e6bab433bea9528f67d39af0d6c7bcb6443e4817`.
+
+Deux synchronisations isolées puis deux dans l'unique instance **Sanctuary
+Beta** réussissent, la seconde passe laissant les fichiers gérés identiques.
+Un seul JAR Sanctuary beta.118 est actif. Les 923 fichiers personnels et
+réglages suivis sont inchangés ; aucun monde personnel n'a été ouvert.
+Copie préalable des fichiers remplacés dans `sanctuary-backups/before-beta.118/`.
+Reçus : `build/walls118-isolated.json`, `build/walls118-prism.json`.

docs/colored-bricks-beta102.md

@@ -0,0 +1,73 @@
+# beta.102 — Briques et argile de couleur
+
+Branche `codex/colored-bricks-beta102`, Minecraft 26.3.
+
+## Contrat
+
+Les seize PNG de briques fournis sont présents. Ils sont intégrés sans altération.
+Par couleur : bloc de briques, dalle, escalier, bloc d’argile pastel, boule d’argile
+et brique (items). Les 64 blocs apparaissent dans l’onglet natif des blocs colorés,
+les 32 items dans les ingrédients. Les composants ont des identifiants stables
+`sanctuary:<couleur>_*` et des libellés français et anglais.
+
+La recoloration exacte par script a été choisie explicitement par le créateur.
+Les silhouettes, la transparence et les nuances des textures vanilla 16 × 16
+sont conservées ; les couleurs proviennent des PNG fournis. Aucun dessin IA.
+
+Recettes natives : teinture de l’argile et des briques, assemblage des blocs,
+cuisson de l’argile en briques, argile colorée en terre cuite vanilla de même
+couleur, fabrication des dalles/escaliers et tailleur de pierre. Les recettes
+rejoignent la collection existante argile/briques et les découvertes Sanctuary.
+Dalles doubles, escaliers connectés, orientation, eau, outils et butin utilisent
+les mécanismes natifs. Les blocs ne sont pas ajoutés à la génération du terrain.
+Aucune migration de sauvegarde et aucune modification d’un monde existant.
+
+## Génération reproductible
+
+`tools/generate-colored-bricks.py --minecraft-jar <minecraft-client.jar 26.3>`
+requiert Python avec Pillow. Les briques sources sont conservées dans les assets
+et les couleurs/empreintes sont consignées dans `tools/colored-bricks-palette.json`.
+Les extensions de collection sont compilées par `scripts/compile_collections.py`
+depuis `scripts/data/collections-sanctuary.json` ; le recensement vanilla reste intact.
+
+## Validation native
+
+`Bricks102ClientChecks` sur Minecraft 26.3, monde plat neuf avec serveur intégré :
+
+- 16 familles, 64 blocs et 96 entrées d’items (dont 64 BlockItems).
+- 192 recettes chargées ; fabrications, teintures, cuissons et tailleur exécutés.
+- Butin des briques et escaliers ; dalle simple/double ; argile normale et Toucher de soie.
+- Tags pioche/pelle et états immergés des dalles/escaliers.
+- Onglets natifs : 64 blocs colorés, 32 ingrédients.
+- Tous les états des 64 blocs possèdent des modèles cuits sans texture manquante.
+- Découverte de l’argile : la collection ajoute les nouvelles recettes.
+- Sauvegarde/réouverture du monde neuf : blocs et état de dalle haute conservés.
+
+Parcours final réussi en 41 s, `build/bricks102-client.log`.
+[Aperçu des textures](../build/colored-bricks-beta102-preview.png) ·
+[Capture Minecraft](../build/bricks102-game.png).
+
+La vérification du rendu utilise le client natif local. Aucun test multijoueur
+distant n’est revendiqué, aucune sauvegarde personnelle ni installation modifiée.
+
+
+## Livraison
+
+`check build assemblePack assembleTestPack -x :sanctuary:runGameTest` réussi
+en 2 min 19 s (124 tâches). Les GameTests du serveur dédié restent exclus ;
+le parcours client/serveur intégré décrit ci-dessus a été exécuté séparément.
+`git diff --check` et la régénération identique octet pour octet sont vérifiés.
+
+Les archives, sources, 192 recettes, 192 progrès de recettes, 96 libellés FR/EN,
+les seize PNG fournis et les transparences vanilla ont été contrôlés.
+La comparaison avec beta.101 ne trouve aucune autre classe de jeu modifiée
+que l’initialisation Sanctuary et les trois nouvelles classes ColoredBricks.
+Les archives beta.101 conservent leurs empreintes.
+Reçu : `build/beta102-artifact.json`.
+
+- [Pack normal](../build/Sanctuary-beta.102.mrpack), 10 052 986 octets.
+  SHA-256 : `f324db41e9992df0635d870a766ec9c486167d7fc2e1ed5080f05deaf824d3c4`.
+- [Pack de test](../build/Sanctuary-Test-beta.102.mrpack), 10 071 908 octets.
+  SHA-256 : `bf6b4a207f6b952295c01d59e788eb742d7dbee18ff5e0ad1e61ba78078348fb`.
+
+Livraison locale, sans publication de canal, tag ou déploiement Prism.

docs/colored-bricks-order-beta103.md

@@ -0,0 +1,33 @@
+# beta.103 — Rangement des blocs colorés
+
+Branche `codex/colored-bricks-order-beta103`, Minecraft 26.3.
+
+Dans Blocs colorés, les ajouts sont regroupés par type : les 16 blocs de briques,
+puis les 16 escaliers, les 16 dalles, les 16 blocs d’argile. Dans Ingrédients :
+les 16 boules d’argile, puis les 16 briques.
+
+Chaque série suit l’ordre de couleurs de l’onglet natif Minecraft 26.3,
+vérifié dans `CreativeModeTabs.bootstrap` : blanc, gris clair, gris, noir,
+marron, rouge, orange, jaune, vert clair, vert, cyan, bleu clair, bleu, violet,
+magenta, rose. L’ordre d’enregistrement des blocs/items reste stable.
+Les identifiants, recettes, textures et sauvegardes sont inchangés.
+
+## Validation et livraison
+
+`check build assemblePack assembleTestPack -x :sanctuary:runGameTest` réussi
+en 2 min 41 s, 124 tâches. `git diff --check` réussi. Pas de nouveau test
+ni de nouvelle session graphique pour ce changement limité au rangement.
+
+Les sources et les deux archives ont été vérifiées. Les textures, recettes,
+modèles et autres données sont identiques à beta.102, dont les archives sont
+conservées. Seul le comportement de `ColoredBricks` change ; la classe interne
+Stairs conserve exactement son code exécutable (seuls les numéros de lignes
+de débogage changent). Reçu : `build/beta103-artifact.json`.
+
+- [Pack normal](../build/Sanctuary-beta.103.mrpack), SHA-256 :
+  `5c0b475410c7586275a59a8b14ac1770648f8196983e62c85a98dcd0fa5a1207`.
+- [Pack de test](../build/Sanctuary-Test-beta.103.mrpack), SHA-256 :
+  `222765733711a08861e25db94ae12a4a6483bc11dbfdcaf54930786c10511d0e`.
+
+Les GameTests du serveur dédié restent exclus. Aucun monde personnel,
+aucune installation ni aucun canal de distribution modifié.

docs/colored-dynamic-beta140.md

@@ -0,0 +1,112 @@
+# LIGHT-140 — Lumières colorées portées et distance
+
+Socle beta.139 `c05c338`, branche `codex/colored-dynamic-beta140`.
+Minecraft 26.3 / Java 25. Livraison beta.140.
+
+## Contrat
+
+Relier les couleurs aux vraies sources de lumière dynamique : mains, tête,
+cosmétiques, objets au sol et feu, selon le système existant. Renforcer la
+teinte et activer les lumières colorées par défaut à 30 %. Ajouter une distance
+d'affichage de 8, 16, 32 ou 64 blocs (16 par défaut), indépendante de la portée
+native de chaque source. Augmenter la distance coûte davantage en mémoire et
+calcul ; aucun chargement forcé de chunk. Les choix sauvegardés sont conservés.
+
+Sources portées actualisées avec le système dynamique, sans reconstruire tout
+le champ statique à chaque mouvement. Aucun changement de monde ou de règle
+serveur. Vérifications natives OpenGL et Vulkan, puis construction et archives.
+
+## Couleurs et fondus
+
+Torches ordinaires : température native par défaut ; option « Torches chaudes »
+pour retrouver l'orangé. Glowstone jaune, lave jaune-rouge, redstone rouge saturé,
+cuivre vert (posé, en main ou sur la tête). Le cuivre est reconnu avant les
+familles génériques de torches et lanternes. Les palettes explicites restent
+indépendantes des packs ; le repli des autres matériaux suit leurs textures.
+
+Le rendu s'atténue sur le dernier quart de la distance choisie. Le champ précédent
+reste disponible pendant un fondu de 300 ms vers le nouveau champ ; l'activation
+et les sources dynamiques ont aussi un fondu. Le changement de distance est
+interpolé. Les sources mobiles utilisent la même sélection bornée et les mêmes
+intensités que la lumière dynamique existante, avec interpolation visuelle des
+positions et couleurs. Elles héritent de sa propagation radiale, y compris de
+ses limites d'occultation ; les blocs posés conservent leur propagation avec murs.
+
+Le volume varie réellement selon la distance (56, 72, 104 ou 168 blocs de côté,
+avec marge de propagation). Les grandes distances augmentent la mémoire et le
+délai de reconstruction ; la construction reste répartie entre les images.
+Deux champs coexistent brièvement pour le fondu. Seuls les chunks déjà chargés
+sont lus. La portée lumineuse native des torches n'est pas allongée.
+
+## Frontières de saturation
+
+Le stockage beta.139 tronquait les canaux faibles séparément en fin de portée :
+un bleu pouvait perdre son rouge avant son vert, puis devenir plus saturé sur
+une frontière visible. Le stockage logarithmique conserve maintenant une marge
+sous le niveau lumineux natif zéro. Le shader applique la coupure à l'énergie
+globale en conservant les rapports RGB. La réponse devient linéaire près du noir,
+sans amplification par racine quatrième des très faibles contributions.
+
+La transition des champs interpole le résultat colorimétrique rendu, pas une
+énergie ensuite amplifiée. Les sources mobiles ont une atténuation de fondu
+compensée pour la même réponse. Le test contrôle les rapports rouge/bleu et
+vert/bleu d'une torche des âmes de 1 à 9 blocs, jusqu'au bord de sa portée.
+
+## Vérifications natives
+
+Minecraft 26.3 / Java 25 sur Apple M1, mondes de test neufs de graine 122 :
+
+- OpenGL 4.1 Metal : **2 min 40 s**, `build/colored140-opengl.log`.
+- Vulkan / MoltenVK 1.4.2, profondeur 0–1 et transparence améliorée :
+  **2 min 26 s**, `build/colored140-vulkan.log`.
+
+Les deux exécutions passent `COLORED139_PASS` et `COLORED140_PASS` :
+propagation avec murs, sources hors champ, lampes allumées/éteintes, retrait,
+rechargement des ressources, cache, déplacement/retour de caméra, OFF/zéro,
+préférences et traductions FR/EN. Les nouveaux contrôles couvrent la teinte
+bleue jusqu'à neuf blocs, la torche native inchangée, l'option chaude, le cuivre
+vert et le rouge saturé, les deux mains et le cosmétique de tête, la position
+en troisième personne, les quatre distances et un fondu sans dépassement.
+
+Dans la même scène contrôlée, la somme d'écarts OFF/torche chaude à 30 % vaut
+3 926 093 / 3 926 092 sur OpenGL/Vulkan, contre 2 025 577 en beta.139 à 35 %.
+Cette mesure vérifie l'accentuation demandée, pas la performance. Le test fige
+uniquement le scintillement de la lightmap native ; cette sonde et les tests
+client ne sont pas distribués. Les captures finales sont conservées sous
+`build/colored140-opengl-screenshots/` et `build/colored140-vulkan-screenshots/`.
+Comparatif autonome : `build/Shader-beta.140-comparaison.html`.
+
+Pas de validation des pilotes Windows de l'utilisateur revendiquée. Les
+limites de beta.139 pour le rendu sous l'eau/lave et les panoramas restent
+ouvertes. Les sources dynamiques gardent l'occultation du système existant.
+Aucun monde personnel ouvert ni modifié.
+
+## Construction et archives
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit en **2 min 22 s**, 126 tâches. Le GameTest serveur dédié reste exclu
+conformément au refus EULA antérieur ; les tests clients ci-dessus sont exécutés
+séparément. Log : `build/shader140-build.log`.
+
+La comparaison avec beta.139 trouve **18 entrées de production modifiées**,
+limitées aux lumières dynamiques/colorées, options et aides FR/EN. Les sources
+des JAR correspondent aux fichiers du dépôt. Les archives normale/Test contiennent
+le même JAR Sanctuary ; la version, les dépendances exactes, les textures de
+gemmes et de la clé de Steve, l'absence de classes de test et le template complet
+sont vérifiés. Reçu : `build/shader140-artifact.json`.
+
+SHA-256 du JAR : `853284c1a61c7fce12edd2f7763717321eef56977290eb0e7c5db5e30bff442f`.
+
+- Sanctuary-beta.140.mrpack : `1b366746e4d6bebfbe0115c849524bdeb81c14eee89a2510f9dbe18808974d6a`.
+- Sanctuary-Test-beta.140.mrpack : `50c3cdf759117bb5286d41b4535fde15d9d84deaac833b7f8f61c4a0d29b72e7`.
+
+## Livraison
+
+[Release beta.140](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.140)
+publiée sur le commit source `6e1b3b71088437fe57cf2b9b979b6d62711628d3` ; canal stable
+`2c360a0759d4a164f82c89ac2bef04ff69d50875` vérifié après publication.
+Deux synchronisations isolées puis deux dans la même instance Sanctuary Beta
+réussissent. Les **923 fichiers personnels** suivis gardent leurs hashes.
+Sauvegarde préalable : `sanctuary-backups/before-beta.140/`. Aucun monde personnel
+ouvert. Reçus : `build/shader140-isolated.json` et `build/shader140-prism.json`.
+Archives normale/Test/template et comparaison copiées dans `sanctuary-beta/build/`.

docs/colored-lights-beta139.md

@@ -0,0 +1,107 @@
+# LIGHT-139 — Lumières colorées
+
+Socle beta.138 + vérification Vulkan `9d84a02`, Minecraft 26.3 / Java 25.
+Branche `codex/colored-lights-beta139`, livraison beta.139.
+
+## Contrat
+
+Option locale « Lumières colorées » avec intensité. Les vrais blocs émetteurs
+teintent discrètement leurs environs, y compris hors champ. Torches/lanternes,
+lave et feu chauds ; sources des âmes bleues ; redstone active rouge ;
+froglights par variante ; sources Sanctuary selon leur texture/matière.
+Les blocs éteints n'émettent pas. Le bloom et les inclusions émissives des
+minerais restent indépendants ; aucune lumière de gameplay n'est ajoutée.
+
+Propagation RGB dans un volume local de blocs chargés, obstacles et formes
+natives, construction répartie entre les images, cache des couleurs de
+matériaux. Aucun chargement forcé de chunk, accès aux mondes personnels,
+changement de sauvegarde, réseau ou règles serveur.
+
+## Réalisation
+
+Dans les options du shader : « Lumières colorées », désactivées initialement,
+et une intensité de 0 à 100 %, réglée à 35 %. Zéro ou OFF libère les ressources.
+Les préférences existantes sont conservées. Libellés et aides FR/EN.
+
+Les familles vanilla demandées ont une palette dédiée. Les autres émetteurs,
+y compris ceux de Sanctuary, utilisent la couleur des pixels lumineux de leurs
+textures de modèle, calculée puis mise en cache. Ce repli suit les packs de
+ressources ; les palettes dédiées vanilla restent constantes. Une texture
+illisible ou sans pixels exploitables utilise du blanc. Les blocs purement
+émissifs du bloom, sans émission lumineuse native, ne deviennent pas des lampes.
+
+Le champ couvre un cube de 64 blocs de côté autour de la caméra. Une marge de
+14 blocs réserve la propagation aux sources présentes dans le volume ; le rendu
+s'atténue progressivement sur 4 blocs à sa périphérie. C'est donc un effet de
+proximité, pas une illumination de tous les chunks visibles. Les formes et
+l'opacité natives règlent le passage de la lumière. Les canaux utilisent des
+maxima indépendants, sans addition illimitée des sources superposées.
+
+Le calcul CPU est réparti avec un budget visé de 2 ms par image, plus les
+allocations et chargements ponctuels de matériaux ; aucun chiffre de FPS n'est
+garanti. Un monde immobile réutilise son champ. Les changements rapides et les
+déplacements peuvent présenter un bref retard, le temps de publier un champ
+complet. Aucun chargement forcé de chunk. Une texture 512 × 512 contient le champ.
+La passe GPU teinte les surfaces visibles, atténue l'effet au soleil et dans le
+brouillard, puis laisse agir le SSGI et le bloom. Les sources tenues, entités,
+particules et le rendu sous l'eau/lave ne sont pas couverts par cette option.
+
+## Vérifications
+
+Essais client natifs réussis dans des mondes neufs (graine 122) sur Apple M1 :
+
+- OpenGL 4.1 Metal : **1 min 46 s**, `build/colored139-opengl.log`.
+- Vulkan / MoltenVK 1.4.2, profondeur 0–1 et transparence améliorée :
+  **1 min 30 s**, `build/colored139-vulkan.log`.
+
+Les deux journaux contiennent `COLORED139_PASS` et le backend réellement actif.
+Torche et torche des âmes hors champ, trois froglights, pierre lumineuse dont
+la couleur vient de sa texture, intensité 35/100, cache statique, déplacement
+et retour de caméra, mur fermé puis ouvert, lampe redstone allumée puis éteinte,
+retrait de source, rechargement des ressources et OFF/zéro vérifiés.
+Les préférences persistantes et les libellés FR/EN sont contrôlés ; une dernière
+capture active conjointement PBR, SSGI, bloom, ombres, highlights et rayons.
+
+Les sommes d'écart entre OFF et 35 % sont presque identiques entre backends :
+torche 2 025 577 / 2 025 576 ; âmes 964 200 / 964 201. Il s'agit de mesures
+sur les pixels de cette scène, pas d'un indice de performance.
+Comparatif autonome : `build/Shader-beta.139-comparaison.html`.
+Pas de validation du pilote Vulkan Windows de l'utilisateur revendiquée.
+Le test fige uniquement le scintillement vanilla des torches afin de comparer
+les images ; cette sonde est exclue du JAR distribué. Aucun monde personnel ouvert.
+
+## Diagnostic des essais
+
+La première comparaison de stabilité détectait le scintillement natif de la
+lightmap des torches, même avec un champ coloré inchangé. La sonde de test
+stabilise ce seul facteur ; aucune désactivation de scintillement en production.
+La pièce d'essai est désormais construite après le chargement de ses chunks,
+et l'absence de lumière du ciel est vérifiée avant les captures.
+
+## Construction et archives
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit en **2 min 22 s**, 126 tâches. Le serveur GameTest dédié reste exclu
+conformément au refus EULA antérieur. Log : `build/shader139-build.log`.
+La comparaison à beta.138 trouve **13 entrées de production** modifiées,
+limitées au shader, à son menu et aux aides FR/EN. Les sondes de test sont
+absentes du JAR distribué. Sources, archives normale/Test et template complets
+vérifiés ; textures des gemmes et clé de Steve conservées à l'identique.
+Reçu local : `build/shader139-artifact.json`.
+
+JAR SHA-256 : `7b958f6576adbabb2b1af589b866cb52b1a65600ea2fa505b05dd283f8d595df`.
+
+- `Sanctuary-beta.139.mrpack` : 10450317 octets ; SHA-256 `13f3a283c260876d28ce0c6504615b4a8f4d575906badfbb2b39558f312e9fbb`.
+- `Sanctuary-Test-beta.139.mrpack` : 10469244 octets ; SHA-256 `c1e0b684dc2650950a0925c4625ef5eb4b78fb5f1c5680f5e302550424fa6d81`.
+
+## Publication et instance
+
+[Release beta.139](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.139)
+publiée depuis `dc33ffa54697f61cd8f579235e7cebdbf0765f7c`, tag exact `beta.139`.
+Canal packwiz : `9f10167b6acfece9c045573580e186aa72bc91dc`.
+Deux synchronisations isolées puis deux synchronisations de la même instance
+Prism réussissent. Un seul JAR Sanctuary beta.139 actif, empreinte identique
+à l'archive vérifiée ; les **923 fichiers personnels suivis** conservent leurs
+empreintes. Sauvegarde des fichiers gérés dans
+`sanctuary-backups/before-beta.139/`. Aucun monde personnel ouvert.
+Reçus : `build/shader139-isolated.json`, `build/shader139-prism.json`.

docs/combat-beta078.md

@@ -0,0 +1,36 @@
+# beta.078 — Combats / Battles
+
+Branche `codex/battle-menu-beta078`. Minecraft 26.3-pre-2 ; textures beta.070.
+
+Le bouton et le titre « Duels et arènes » deviennent **Combats** en français
+et **Battles** en anglais. Le lien depuis les duels de familiers utilise
+également ce libellé. Les annonces d’inscription indiquent le menu pause,
+et les résultats renvoient au nouveau nom pour récupérer les gains.
+
+Le [plan des menus](menu-architecture.md) conserve cette appellation. Le reste
+de cette réorganisation reste une proposition ; l’économie est différée.
+Aucune règle de combat, sauvegarde ou transaction n’est modifiée.
+
+## Vérification
+
+`check build assemblePack assembleTestPack` réussi en 2 min 33 s, avec le
+serveur dédié exclu conformément au refus de son EULA. Après la précision
+du créateur sur le pluriel, les ressources et packs sont reconstruits en
+8 s ; vérification finale des quatre traductions par langue et de leurs
+paramètres de formatage.
+
+Les 1 693 classes du JAR sont identiques à beta.077. Les textures, données
+de jeu et le resource pack restent inchangés. Les deux archives embarquent
+le JAR vérifié ; les archives beta.077 sont conservées à l’identique.
+Reçu : `build/battle078-artifact.json`. Journaux : `build/battle078-check.log`
+et `build/battle078-assemble.log`.
+
+Pas de nouveau parcours client graphique pour ce changement de libellés.
+Aucun déploiement dans une installation personnelle.
+
+## Archives
+
+- [Sanctuary-beta.078.mrpack](../build/Sanctuary-beta.078.mrpack).
+  SHA-256 : `9adfa5b5b8d49ed10943121ac2a2561d880886925a5f76db5ba98f0377d8d7e3`.
+- [Sanctuary-Test-beta.078.mrpack](../build/Sanctuary-Test-beta.078.mrpack).
+  SHA-256 : `92bc1d59723546c31a6e7476dd9f53225c7957e5180091dfeaeade69ff265a86`.

docs/community-beta154.md

@@ -0,0 +1,115 @@
+# COMM-154 — Communauté et conversations, beta.154
+
+Livraison locale préparée sur `codex/community-beta154`, depuis beta.151
+`b97ec6c9e820bed7693e75f200a02b16af01cf89`. Le site est préparé sur
+`codex/community-contract`, depuis `4af93d1e42ba6084ecd654967ad6d8f317a5d3ef`.
+Contrat identique dans les deux dépôts : [communauté v1](community-contract-v1.md).
+
+## Résultat
+
+Gazette à gauche et tableau à droite du menu pause, intendance au-dessus ;
+accès compacts lorsque la largeur GUI ne permet pas trois colonnes.
+Lire, publier et répondre, modifier son texte, masquer et clôturer une annonce.
+Modération autorisée côté serveur et comptes Web liés par code confirmé en jeu.
+
+Les discussions montrent les visages Minecraft, le pseudo, la date et chaque
+message dans un bloc de conversation. Les actions secondaires sont regroupées
+sous « ⋯ » ; la réponse se saisit directement sous le fil. Même présentation
+sur le site, avec rendu des visages par UUID via son prestataire existant.
+
+Fichier JSON atomique par défaut ; MariaDB optionnelle partagée avec Laravel.
+Le serveur exécute la persistance hors du thread de jeu. Brouillons conservés
+en cas de refus ; aucun repli silencieux vers un fichier après une panne SQL.
+Aucun changement des shaders, de leurs réglages, de la génération ou des
+sauvegardes existantes. Le delta part exactement du shader beta.151.
+
+## Vérifications
+
+Environnement : macOS Apple M1, Java Temurin 25, Minecraft 26.3,
+Fabric Loader 0.19.5, Fabric API 0.160.5+26.3, Vulkan/MoltenVK 1.4.2.
+Site : PHP 8.5.10, Laravel 13.32.0, PHPUnit 12.5.35. MariaDB locale 12.3.3,
+Connector/J 3.5.10 imbriqué dans le mod.
+
+- Scénario de stockage commun réussi sur fichier et MariaDB : persistance,
+  redémarrage, exact retry, conflits de révision, auteurs, opérateurs,
+  fermeture/réouverture, masquage, pagination, texte Unicode et isolation.
+  Codes expirés, consommés et tentative de réattribution d’identité refusés.
+  `build/community-client-database-final.log`, marqueurs FILE_PASS et SQL_PASS.
+- Aller-retour réel Java → HTTP Laravel → Java réussi : article, création d’un
+  code Web, liaison côté Java, modification Web et réponse relues par Java.
+  `build/community-interop-{seed,claim,verify}.log` ; deux phases PHPUnit,
+  3 puis 6 assertions. Migration Laravel sur les tables déjà créées par le SQL
+  du mod réussie ; création depuis Laravel également testée par les tests HTTP.
+- Tests client Vulkan réussis en FR/EN, GUI 2/3 (panneaux et mode compact),
+  publication, réponse intégrée, clôture, actions contextuelles, visages,
+  brouillon refusé et réponse tardive après fermeture.
+  Fichier : `build/community-conversation-client.log`.
+  MariaDB : `build/community-conversation-database.log`, mode explicitement
+  vérifié par le client. Captures dans `mods/sanctuary/build/run/clientGameTest/screenshots/`.
+- Panne SQL testée avec une adresse locale sans service : erreur visible,
+  brouillon conservé, aucune création de fichier de repli.
+  `build/community-client-outage.log`, marqueur COMMUNITY154_OUTAGE_PASS.
+- Web : **12 tests / 60 assertions** communautaires réussis, comprenant
+  validation, identité non falsifiable, restrictions du staff, auteur,
+  XSS/texte échappé, formulaires, pagination, compte lié et rejet CSRF réel.
+  Pint réussi. Rendu des pages et visages vérifié dans le navigateur local,
+  navigation accueil → discussion et FR/EN. Aucune erreur console applicative ;
+  avertissement THREE.Clock hérité du panorama.
+- Suite Web complète : **55 réussites, 1 échec, 1 test optionnel ignoré** sur
+  57. L’échec existant de PlayerModerationTest attend « Nommer admin », alors
+  que ViewUser affiche déjà « Nommer staff » dans le commit de départ.
+- `./gradlew check build --continue` exécuté : **229/252 GameTests réussis**,
+  **23 échecs strictement identiques à beta.151** (comparaison des identifiants).
+  `build/community-check-build.log`, `build/community-server-failures.json`.
+  Ce passage a aussi rencontré un `ClassNotFoundException` temporaire dans
+  seasonal105Smoke pendant des compilations concurrentes de vérification.
+  Le contrôle final est relancé seul, avec la tâche GameTests exclue (les 252 cas ont été exécutés lors du premier passage).
+
+Le contrôle complet reste rouge : cette livraison ne prétend pas réparer les
+23 GameTests historiques ni l’ancienne assertion de libellé Web. Les parcours
+communautaires sont validés indépendamment.
+
+## Rejouer les tests ciblés
+
+```sh
+./gradlew :sanctuary:community154Smoke
+./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryQuickTests=true \
+  -PsanctuaryCommunity154ClientTests=true -PsanctuaryClientGraphicsBackend=vulkan
+```
+
+Pour le même scénario en base, préparer une MariaDB de développement vide
+avec `src/main/resources/community/schema-v1.sql`, puis définir
+`SANCTUARY_COMMUNITY_TEST_JDBC` (URL JDBC),
+`SANCTUARY_COMMUNITY_CLIENT_DATABASE=true` et
+`SANCTUARY_COMMUNITY_DB_PASSWORD`. Ces fixtures de développement utilisent
+`root` sans mot de passe, uniquement dans la MariaDB locale isolée de test.
+Ne jamais les lancer sur une base personnelle ou de production.
+
+L’aller-retour utilise une autre base isolée, également migrée par Laravel :
+`community154Interop -PcommunityInteropPhase=seed`, puis CommunityInteropTest
+avec `SANCTUARY_COMMUNITY_INTEROP_PHASE=link`, Java `claim`, PHP `write`, Java
+`verify`. Les deux programmes reçoivent le même chemin absolu
+`SANCTUARY_COMMUNITY_INTEROP_FILE` vers un JSON dans un dossier ignoré.
+Le test PHP reçoit les paramètres DB_CONNECTION/DB_HOST/DB_PORT/DB_DATABASE
+pointant exclusivement vers cette base. Sans cette variable, il est ignoré.
+
+## Limites de livraison
+
+Code et artefacts locaux ; aucun déploiement Web, serveur personnel, canal
+packwiz ou instance Prism. Validation Windows et connexion Discord réelle sur
+le domaine de production à faire lors du déploiement. Le compte Web utilisé
+dans les essais est fictif, la liaison passe cependant par le vrai stockage.
+Pas de pièces jointes, de notification poussée ou d’import fichier → base.
+Les anciens JAR encore présents sont conservés.
+
+## Artefacts vérifiés
+
+Export packwiz réussi. ZIP, versions Minecraft/Fabric, JAR unique, pilote JDBC
+imbriqué, licence, absence des tests et égalité octet pour octet des 29 fichiers
+shader avec beta.151 vérifiés. Reçu : `build/community-artifacts.json`.
+
+- `mods/sanctuary/build/libs/sanctuary-beta.154.jar` — SHA-256 `07e7419cb3e814d59a6b6f130a1b05b4f65c2407a0ffbd00b194ba97614923ad`.
+- `build/Sanctuary-beta.154.mrpack` — SHA-256 `fbc007fe59777b0c52b30b6e461b09fe0636fb0b86d254b9e98952856b7f6c8a`.
+
+Site : commit local `32d804a` sur `codex/community-contract`.

docs/community-cards-beta158.md

@@ -0,0 +1,98 @@
+# beta.158 — cartes communautaires et demandes suivies
+
+## Contrat v3 et migration
+
+Les règles de génération et les inventaires Minecraft ne changent pas. Les coffres
+sont des sélections descriptives : aucun objet n'est prélevé, réservé, livré ou
+créé. Les échanges et la répartition des récompenses sont organisés entre joueurs.
+Il n'y a ni gagnant automatique ni validation automatique d'une livraison.
+
+Une annonce peut porter `task` : position facultative (dimension, x/y/z), liste
+`materials` de 27 identifiants d'objets et quantités (1 à 999999), participation
+`shared` ou `single`, récompense `none`, `items` (27 sélections) ou `custom` (240
+caractères). Les catégories info/work/need/event gardent leurs identifiants.
+Le serveur Minecraft valide aussi les objets et dimensions contre son registre.
+Les données du site sont descriptives et restent lisibles si un objet manque côté
+client ; les identifiants inconnus ne créent jamais d'objet.
+
+Les abonnements sont authentifiés, idempotents, au plus 16 par joueur et 64 par
+annonce. Une annonce single accepte un seul abonné. L'auteur ne s'abonne pas à sa
+propre annonce. Fermeture et masquage retirent le suivi actif ; réouvrir autorise
+à nouveau l'abonnement. Les abonnements existants ne sont pas supprimés par la
+fermeture : un joueur peut se désabonner. Changer shared vers single est refusé
+si plusieurs abonnés sont présents. La liste côté HUD est issue du serveur ; les
+notifications affichent les trois suivis ouverts les plus récents, avec le lieu
+et un rappel des matériaux. La fermeture est annoncée, sans attribuer de gain.
+
+Fichier : ajout du champ task et de la collection followers ; lecture v1/v2 sans
+écriture. À la première écriture, backup exact `.v1.bak` ou `.v2.bak` sans
+écrasement puis écriture atomique en v3. Le plafond 64 Mio reste appliqué. Aucun
+monde personnel n'est migré pendant le développement. Retour arrière : serveur
+arrêté, restauration du backup et de la version logicielle correspondante.
+
+MariaDB : arrêter les écritures du mod et du site, sauvegarder, appliquer la
+migration v2→v3 (SQL livré ou Laravel), puis mettre à jour les deux applications.
+Colonne task nullable, tables followers et subscribers (verrous par joueur).
+Aucune migration automatique par le mod ; aucune suppression des anciens posts.
+Les anciens articles et annonces restent lisibles. Rollback uniquement par
+restauration explicite ; pas de suppression automatique des nouvelles données.
+
+La Gazette et le tableau utilisent une grille à deux colonnes. Les aperçus de
+photo sont bornés à 6 Kio binaires par carte ; les listes ne diffusent pas les
+photos complètes. L'intendance reste affichée dans l'en-tête, sans accès public
+à son historique ni à son éditeur ; sa gestion est réservée au panneau admin.
+Le panneau Web est complété par `/sanctuary community admin` côté jeu, réservé
+aux opérateurs par le serveur, notamment pour les installations en mode fichier.
+Les métadonnées de l’article (visage, nom, date) sont sur la rangée du bouton
+« … », juste sous l’encadré photo/texte. La galerie est plafonnée à 420 unités
+de largeur et 180 de hauteur ; l’aperçu du formulaire est limité à 160 × 72.
+Le bouton de liaison du compte Web disparaît des écrans communautaires en jeu.
+Les sondages restent une piste, sans fonctionnalité livrée dans cette version.
+
+## Vérifications
+
+Vérifications ciblées du 23 septembre 2026 :
+
+- Stockage fichier et MariaDB : métadonnées, inscription exclusive concurrente,
+  idempotence, limite de 16 suivis, fermeture/réouverture, désabonnement,
+  refus shared→single occupé, masquage et redémarrage. Migration v1/v2 avec
+  conservation exacte des backups.
+- Client natif Vulkan : français/anglais, échelles GUI 2/3/4, grilles de deux
+  colonnes, défilement et chargement des cartes suivantes sans retour en haut,
+  galerie compacte, photo obligatoire, publication, coffre de sélection,
+  position courante, récompense personnalisée, abonnement et HUD.
+- Vérification du déplacement visage/nom/date sous l’article, à côté de « … ».
+- Accès opérateur au panneau d’intendance en jeu : refus au joueur ordinaire,
+  ouverture et publication après activation des permissions natives.
+- Régression du menu pause : colonnes, boutons, carte, défilements indépendants,
+  longs articles/annonces et réponse, sous Vulkan en FR/EN et GUI 2/3/4.
+- Site : 23 tests / 131 assertions, dont droits, migrations v3 sans perte ni
+  rétrogradation, validation des matériaux et inscription exclusive.
+- Interopérabilité MariaDB réelle Java→PHP→Java : photo, édition, réponse,
+  identité vérifiée, demande et abonnement Web relus par le mod (18 assertions PHP).
+- Ressources de shaders : 29 fichiers identiques au JAR beta.157, qui conservait
+  le socle beta.151. Les anciens JAR et MRpack sont conservés.
+
+Suite générale : `./gradlew check build assemblePack` exécuté ; 252 GameTests,
+229 réussites et les mêmes 23 échecs identifiés dans la beta.157, aucun nouvel ID.
+Comparaison conservée dans `build/cards158-server-failures.json`. Les autres
+contrôles, le build et l’assemblage passent avec cette suite déjà vérifiée exclue :
+`./gradlew check build assemblePack :sanctuary:runClientGameTest -x :sanctuary:runGameTest`
+avec les propriétés client Cards158/Vulkan et la base MariaDB de développement.
+Le dernier parcours confirme aussi le refus des quantités invalides et la
+conservation des 17 bûches et 3 diamants réels après publication descriptive.
+
+Export packwiz réussi ; version interne beta.158 et JAR embarqué vérifiés.
+Captures finales : `build/cards158-database-screens/` ; captures fichier :
+`build/cards158-file-screens/`. Les grilles, la galerie et le pied d’article
+ont été inspectés visuellement. Journaux : `build/beta158-*.log`.
+
+Site local : commit `0dcab21` sur
+`codex/community-quests`. Aucun déploiement dans une installation personnelle,
+aucune publication du canal packwiz ni modification d’un monde existant.
+
+
+## Artefacts locaux
+
+- `mods/sanctuary/build/libs/sanctuary-beta.158.jar` — SHA-256 `0590320dcece7f94543ab17e99fb23ac37cc3e2578499aa6e80ad801212675e8`.
+- `build/Sanctuary-beta.158.mrpack` — SHA-256 `9c1e556ddce3094febf92631c8a1c8cc0ec56971b332cd9c2d7448f2f9931b89`.

docs/community-contract-v1.md

@@ -0,0 +1,240 @@
+# Communauté Sanctuary — contrat v1
+
+> Depuis beta.158, le schéma actif est la v3 : photos et demandes suivies.
+> Appliquer les migrations avant de connecter les deux applications.
+
+Ticket beta.154, branche `codex/community-beta154`, socle beta.151 `b97ec6c`.
+Ce contrat décrit le comportement cible et les échanges implémentés par ce ticket.
+La note de livraison indique séparément les vérifications effectivement réussies.
+Les shaders de beta.151 sont conservés sans modification.
+
+## Périmètre
+
+Gazette (`article`), tableau (`notice`), intendance (`bulletin`) et réponses
+(`reply`). Contenus texte brut : titre 120 caractères Unicode, corps 4 000,
+réponse 1 000. Aucune interprétation HTML, Markdown ou commande Minecraft.
+Catégories stables : `info`, `work`, `need`, `event`. Photos et pièces jointes
+sont hors de cette première livraison.
+
+La pause présente la Gazette à gauche, les actions natives au centre, le tableau
+à droite et l'intendance au-dessus. À faible largeur GUI, accès compacts vers
+les mêmes écrans. Publication et réponses disponibles dès cette version.
+
+## Autorité et identité
+
+Le client passe exclusivement par le serveur Minecraft. L'auteur vient de la
+session serveur, jamais d'un UUID fourni par le client. Chaque installation
+possède un `serverId` UUID stable, également configuré sur le site. Chaque
+requête SQL inclut ce serveur. Les sauvegardes du monde restent indépendantes.
+
+Tous les joueurs connectés peuvent publier et répondre. L'auteur peut modifier
+ou masquer son contenu et clôturer/réouvrir son annonce. Un opérateur Minecraft
+ou membre du staff Web disposant de `users.moderate` peut masquer des contenus, épingler les publications et
+publier l'intendance ; il ne réécrit pas le texte d'un autre auteur.
+Le site exige un compte connecté lié à l'UUID Minecraft : code aléatoire à usage
+unique créé sur le site, valable 10 minutes, confirmé en jeu. Seul le hash SHA-256
+est conservé. La confirmation nécessite un serveur authentifié (`online-mode`).
+Une identité déjà liée ne peut être réattribuée automatiquement.
+
+## Stockage
+
+`config/sanctuary-community.json` sélectionne `file` (défaut) ou `database`.
+Le fichier du monde `data/sanctuary-community.json` est remplacé atomiquement
+après synchronisation disque. Une corruption ou modification externe est une
+erreur : aucune réinitialisation silencieuse.
+
+En mode base, MariaDB utilise les tables `sanctuary_community_*`, utf8mb4,
+InnoDB. Les nouvelles tables sont additives. Le schéma SQL v1 livré peut être
+installé par l'administrateur ; Laravel possède la migration équivalente.
+Le mod vérifie la version et ne lance jamais de migration au démarrage.
+Une seule application du schéma suffit avant de démarrer les deux applications.
+Les évolutions futures auront une migration explicite commune.
+
+Aucun basculement automatique base → fichier lors d'une panne. Les lectures en
+cache restent signalées comme anciennes ; une écriture n'est confirmée qu'après
+commit. Les brouillons restent côté client durant la session. Les requêtes SQL
+s'exécutent hors du thread de jeu, avec délais et file d'attente bornés.
+Le passage fichier ↔ base nécessite un export/import explicite ; changer le mode
+ne migre ni ne fusionne les données. La v1 ne fournit pas cet importateur.
+
+## Enregistrements et concurrence
+
+Les entrées portent : serveur, UUID, parent éventuel, type, catégorie, UUID et nom
+d'auteur, titre, corps, état (`open`, `closed`, `hidden`), épingle, révision,
+date de création et date de modification (millisecondes Unix UTC).
+Une réponse a un parent article/annonce du même serveur ; pas de réponses imbriquées.
+Masquer un parent masque également sa discussion dans toutes les lectures.
+
+Chaque création utilise un UUID d'opération stable. La répétition exacte rend le
+même résultat ; une réutilisation avec d'autres données est un conflit. Chaque
+modification exige la révision courante. La transaction verrouille le parent
+avant de répondre, empêchant la course avec une clôture ou un masquage.
+Les listes sont paginées (10 entrées), épingles puis date/id décroissants ; les
+réponses sont ordonnées par date/id croissants. L'intendance montre le bulletin
+visible le plus récent. Les textes et le nombre de résultats sont bornés.
+
+## Vérification attendue
+
+Même scénario sur fichier et vraie MariaDB : publication, réponses, redémarrage,
+idempotence, conflits, droits, masquage, fermeture et isolation de deux serveurs.
+Aller-retour Java → PHP → Java sur les mêmes tables. Essais client Vulkan FR/EN,
+GUI 2/3, mode compact, publication/refus/brouillon et fermeture avant réponse.
+Tests HTTP du site : identité, CSRF (middleware), validation, permissions,
+échappement HTML, erreurs, pagination. `./gradlew check build` et `assemblePack`
+sont consignés avec leurs éventuels échecs hérités.
+
+## Mise en service
+
+### Serveur autonome (fichier, défaut)
+
+Installer le JAR ou le pack beta.154. La première ouverture d’un panneau crée
+`config/sanctuary-community.json` et son `serverId`. La première publication
+crée uniquement le fichier communautaire du monde. Aucun service externe requis.
+Les joueurs utilisent Échap → Gazette/Tableau → Publier, puis Répondre dans
+une discussion. Le mode fichier n’est pas partagé avec le site Web.
+
+Conserver le `serverId` et sauvegarder le fichier communautaire avec son monde.
+Ne pas éditer ce fichier pendant que le serveur tourne. La limite de la v1 est
+64 Mio par fichier communautaire ; une écriture qui la dépasse est refusée.
+
+### Même MariaDB pour Minecraft et Laravel
+
+1. Sauvegarder la base existante. Déployer le code Web puis appliquer sa migration
+   `php artisan migrate --force`. Elle ajoute quatre tables sans modifier les
+   données de jeu. Un schéma déjà installé par `schema-v1.sql` est reconnu.
+   À l’inverse, ne pas rejouer le SQL brut sur des tables déjà créées par Laravel.
+2. Dans le `.env` du site, garder ses paramètres MariaDB et définir
+   `SANCTUARY_COMMUNITY_SERVER_ID` avec le même UUID que le mod. Recharger
+   la configuration Laravel (`php artisan config:cache` en production).
+3. Arrêter Minecraft et éditer sa configuration :
+
+```json
+{
+  "mode": "database",
+  "serverId": "11111111-1111-4111-8111-111111111111",
+  "jdbcUrl": "jdbc:mariadb://db.example.net:3306/sanctuary?sslMode=verify-full",
+  "user": "sanctuary_game",
+  "passwordEnv": "SANCTUARY_COMMUNITY_DB_PASSWORD"
+}
+```
+
+L’UUID ci-dessus est un exemple : reprendre celui de votre installation.
+Définir `SANCTUARY_COMMUNITY_DB_PASSWORD` dans l’environnement du service Minecraft,
+puis le redémarrer. Utiliser un certificat TLS valide pour l’hôte de la base.
+Le compte de jeu a besoin de SELECT sur `sanctuary_community_schema`, SELECT,
+INSERT et UPDATE sur `sanctuary_community_entries`, SELECT et INSERT sur
+`sanctuary_community_identities`, SELECT et DELETE sur `sanctuary_community_links`.
+Il n’a besoin ni des tables de comptes Web, ni de droits de création de tables.
+Le compte Laravel conserve ses permissions habituelles et celles des migrations.
+
+4. Sur le site : se connecter avec Discord, ouvrir Gazette, demander un code de
+   liaison. En jeu : Gazette → Lier mon compte → saisir le code. La liaison
+   exige `online-mode=true`. Recharger le site après confirmation ; les boutons
+   Publier et Répondre deviennent accessibles.
+5. Modération : opérateur Minecraft ou staff Web autorisé à `users.moderate`,
+   avec compte lié. Les fonctions de lecture seule du staff ne donnent aucun
+   droit de masquage, épinglage ou publication officielle.
+
+L’accueil du site conserve sa version de téléchargement beta.151 tant que le
+pack public n’est pas mis à jour. Ce ticket ne publie pas le site, le canal
+packwiz ou une installation Prism.
+
+### Synchronisation et limites de la v1
+
+Le menu pause recharge ses aperçus toutes les 5 secondes. Les pages de lecture
+ont un bouton Actualiser. Le site charge les publications à chaque navigation.
+Les brouillons Minecraft restent en mémoire jusqu’à déconnexion ; le site garde
+ses brouillons dans le stockage local du navigateur, par compte et serveur.
+Aucune notification poussée ni import automatique d’archives ou de fichier vers
+MariaDB. Les anciennes publications d’exemple du site étaient du texte statique,
+pas des données à migrer. Les pièces jointes et la réattribution d’un compte lié
+restent hors périmètre.
+
+### Présentation des discussions et visages
+
+Les réponses se lisent en conversation : visage Minecraft, pseudo et date,
+texte dans un bloc distinct, actions compactes derrière « ⋯ ». Le formulaire
+reste sous la discussion. Les listes et les aperçus du menu pause affichent
+également les visages. En jeu, les profils sont résolus par les widgets natifs
+Minecraft, avec leur texture de repli tant que le skin n’est pas disponible.
+Sur le site, le rendu par UUID utilise le prestataire mc-api.io déjà employé
+par la page de compte ; chargement différé, sans référent, initiale locale en
+cas d’erreur. Aucune image ni URL arbitraire n’entre dans le contrat des posts.
+Documentation du rendu : https://mc-api.io/docs (GET `/render/{uuid}?size=64`).
+
+
+## Évolution v2 (beta.157)
+
+Le champ photo et sa migration explicite, avec conservation des anciens articles,
+sont décrits dans [Photos de Gazette](gazette-photos-beta157.md).
+Pour une nouvelle base partagée avec le site, utiliser les migrations Laravel.
+Pour une base autonome administrée par SQL, appliquer schema-v1.sql puis
+schema-v1-to-v2.sql avant de connecter le mod beta.157.
+
+
+## Évolution v3 — demandes suivies (beta.158)
+
+Annonce : `task` contient `location` nullable (`dimension`, `x`, `y`, `z`),
+`materials` et `rewards` (27 objets maximum, `item` namespacé de 100 caractères
+maximum, `count` de 1 à 999999), `audience` shared/single, `reward` none/items/custom
+et `customReward` (240 caractères). Les coffres sont descriptifs : échanges
+et partage des récompenses entre joueurs, sans transaction d'inventaire.
+
+Les tables `sanctuary_community_followers` et `sanctuary_community_subscribers`
+portent les abonnements et les verrous par joueur. Maximum 16 abonnements/joueur,
+64/annonce, un seul en mode single ; pas d'auto-abonnement de l'auteur.
+Le masquage supprime les abonnements ; la fermeture les conserve mais suspend
+le suivi actif. Un passage en single est refusé au-delà d'un abonné.
+
+Arrêter les écritures et sauvegarder avant migration. Installation SQL neuve :
+schema-v1.sql, schema-v1-to-v2.sql, puis schema-v2-to-v3.sql du mod. Sur le site,
+`php artisan migrate` applique l'équivalent et reconnaît les tables déjà créées.
+Le compte JDBC nécessite SELECT/INSERT/DELETE sur followers et SELECT/INSERT
+sur subscribers, en plus des permissions v2. Aucun DDL automatique par le mod.
+
+L'intendance se gère dans le panneau admin ; seul son dernier message reste
+public en en-tête. La liaison de compte se fait avec le code généré sur le site
+et `/sanctuary community link <code>` en jeu (serveur authentifié requis).
+Les anciens boutons de liaison et d'historique public de l'intendance disparaissent.
+
+En mode fichier, le panneau d’intendance en jeu s’ouvre avec
+`/sanctuary community admin` ; le serveur exige les permissions opérateur.
+
+## Évolution beta.159 — recherche et lecture de l’intendance
+
+Le schéma reste **v3** : aucune migration de données. Cette évolution remplace
+la restriction de lecture publique de beta.158 : les onglets Gazette, Tableau
+et Serveur permettent de lire leurs historiques. La publication et la gestion
+de l’intendance restent dans l’administration, sans réponse ni abonnement.
+
+`list` et `cards` acceptent une recherche facultative dans `Request.body` (120
+caractères maximum, vide par défaut). Le site utilise le paramètre GET `q`,
+conservé dans la pagination. Recherche littérale de sous-chaîne dans le nom de
+l’auteur, le titre **ou** le corps, sans distinction de casse, avant pagination.
+Les accents restent significatifs et `%` / `_` sont des caractères ordinaires.
+Le filtre reste limité au serveur et à la rubrique sélectionnés ; les contenus
+masqués restent exclus. Les épingles gardent leur priorité. Le client attend
+300 ms après la frappe et ignore les réponses correspondant à un ancien filtre.
+Les pages restent bornées à 10 publications ; aucune recherche dans les réponses.
+
+Les dates des publications affichent l’année (UTC). Le menu pause affiche la date
+complète dans la langue et le fuseau local du joueur. La galerie utilise la
+surface disponible du GUI, adapte ses colonnes et conserve ses pages de 24
+captures défilantes. Le clic ouvre un aperçu dans cette surface, en conservant
+les proportions et les boutons Retour / Assigner. Le formulaire conserve son
+aperçu compact. Les PNG sources ne sont pas modifiés.
+
+Les demandes suivies ouvertes qui ont une position affichent un `!` sur la carte
+de pause et le grand atlas, dans la dimension correspondante. Elles ne révèlent
+pas le terrain et ne chargent aucun chunk. L’infobulle montre titre, auteur,
+résumé, coordonnées, matériaux et récompense ; les listes longues sont abrégées
+pour rester dans le GUI. Le clic ouvre l’annonce. « Voir sur la carte » centre
+l’atlas sur son lieu dans la dimension courante, sans téléportation. Les repères
+suivent tous les abonnements, indépendamment des trois suivis visibles dans le
+HUD ; ils disparaissent au désabonnement, à la clôture ou au masquage. Un
+rafraîchissement des suivis reste actif lorsque la carte ou la pause est ouverte
+(période de cinq secondes, différée si une autre requête est en cours).
+
+Le message réseau `following` ajoute `summary`, extrait littéral du corps limité
+à 240 caractères Unicode plus une ellipse. Le texte intégral et les photos ne
+sont pas diffusés dans ce message. Aucun champ persistant supplémentaire.

docs/community-search-beta159.md

@@ -0,0 +1,81 @@
+# beta.159 — recherche communautaire et galerie adaptable
+
+Branche `codex/community-search-gallery-beta159`, socle beta.158.
+
+## Résultat
+
+Une barre de recherche filtre les publications par auteur, titre ou texte côté
+serveur, avant pagination. Le filtre accompagne les pages suivantes, conserve
+les épingles et se réinitialise en effaçant le champ. Les réponses aux anciennes
+recherches sont ignorées et le focus de saisie est conservé.
+
+Les trois onglets Gazette / Tableau / Serveur donnent accès aux publications de
+chaque rubrique. L’en-tête d’intendance de la pause ouvre aussi son historique.
+La lecture est publique ; la publication et la gestion des messages du serveur
+restent réservées au panneau administrateur, même pour un opérateur visitant
+l’écran public. Les messages du serveur n’acceptent ni réponses ni abonnements.
+
+L’année figure dans la date de pause et les métadonnées des publications. La
+galerie utilise l’espace disponible aux différentes échelles de GUI et tailles
+de fenêtre. Les captures restent paginées par 24 avec défilement. Cliquer une
+capture ouvre un grand aperçu avec les commandes de retour et d’assignation.
+La photo assignée reste compacte dans le formulaire et les brouillons sont
+conservés lors du retour. Aucune modification des PNG originaux.
+
+Les annonces suivies géolocalisées portent un « ! » sur les deux cartes.
+L’infobulle fournit titre, auteur, résumé, coordonnées, matériaux et récompense
+sans ouvrir la discussion ; le clic reste disponible. Un bouton dans l’annonce
+centre le grand atlas sur sa position, dans la dimension courante. Aucune
+téléportation ni révélation du terrain : seules les coordonnées publiées sont
+projetées. Les annonces fermées, masquées, sans lieu ou non suivies ne portent
+pas de repère. Les longues infobulles sont abrégées pour tenir dans le GUI.
+
+Le site suit le même contrat de recherche et de lecture. Schéma v3 inchangé,
+aucune migration de sauvegarde ni de base. Libellés français et anglais.
+
+## Vérifications
+
+- Stockage fichier et MariaDB : recherche par auteur et corps, casse et accents,
+  filtre avant pagination, épingles conservées, caractères `%` / `_` littéraux,
+  rubrique et serveur isolés, contenus masqués exclus, borne de 120 caractères.
+- Client natif Minecraft 26.3 / Java 25 / Vulkan : galerie et aperçu en FR/EN,
+  GUI 2/3/4 et fenêtres 1280×960 / 1920×1080 ; retour au brouillon, assignation,
+  publication, listes défilantes et chargement des pages suivantes.
+- Recherche en jeu au-delà de la première page, filtre par joueur, effacement,
+  conservation du focus et rejet d’une réponse correspondant à l’ancien filtre.
+- Lecture des messages serveur par un joueur ordinaire, aucun contrôle d’écriture
+  dans les pages publiques, y compris pour l’opérateur ; administration inchangée.
+- Carte : projection dans la dimension correspondante, titre/auteur/résumé,
+  matériaux et récompense au survol ; ouverture de la demande par clic sur les
+  deux cartes ; retrait immédiat du repère après désabonnement.
+- Date avec année en FR/EN, GUI 2/3/4, sans chevauchement de l’intendance.
+- Site : 24 tests / 157 assertions sur SQLite puis MariaDB de développement,
+  formatage Pint réussi. Commit local `e70e78d`, branche `codex/community-search`.
+
+La commande complète `./gradlew :sanctuary:runClientGameTest check build assemblePack`
+avec les propriétés client Cards158, QuickTests et Vulkan a exécuté 252 GameTests :
+229 réussites et les mêmes 23 échecs que beta.158. Aucun test serveur supprimé
+ou modifié. La comparaison est conservée dans `build/search159-server-failures.json`
+et le journal dans `build/beta159-check-build.log`.
+
+Les contrôles restants, la compilation et `assemblePack` passent avec la suite
+serveur déjà exécutée exclue (`-x :sanctuary:runGameTest`) : 133 tâches, journal
+`build/beta159-release.log`. Le parcours client final passe en mode MariaDB,
+puis en mode fichier (`build/beta159-file-client.log`). Les repères ont été
+vérifiés avec et sans terrain d’atlas débloqué ; les infobulles restent dans la
+fenêtre aux GUI 2/3/4. Captures représentatives inspectées :
+`build/search159-file-screens/` et `build/search159-database-screens/`.
+
+L’export packwiz est vérifié : intégrité ZIP, version beta.159, JAR embarqué
+identique au JAR de livraison. Les 29 ressources de shaders sont identiques à
+beta.158, qui conserve le socle beta.151. Les anciens JAR et MRpack beta.154 à
+beta.158 restent présents. Aucun monde personnel, déploiement de serveur, canal
+packwiz ou instance Prism n’est modifié.
+
+## Artefacts locaux
+
+
+
+- `mods/sanctuary/build/libs/sanctuary-beta.159.jar` — SHA-256 `c30d57a5f37e0a5c9dbb387ca831ce9e5c15a1dfe4cb55af0af20a376e862576`.
+
+- `build/Sanctuary-beta.159.mrpack` — SHA-256 `868932d88bc241bfb526a7c5e4054009e247658bd0784b7141d82017edcc2823`.

docs/creative-construction-beta098.md

@@ -0,0 +1,74 @@
+# beta.098 — Construire le plan en créatif
+
+Ticket CONSTRUCTION-098, branche `codex/creative-construction-beta098`.
+À la demande du créateur, le parcours manuel du Métabli est complété par une
+construction immédiate réservée au mode créatif.
+
+## Parcours
+
+Choisir une statue, une machine, un bâtiment ou un plan importé au Métabli.
+Positionner et orienter l’aperçu avec K. Le bouton **Construire le plan…**
+apparaît sous les coordonnées en créatif seulement. La confirmation indique
+le nombre de blocs, l’origine et le fait que le plan entier sera construit,
+même si une seule couche est affichée. Annuler revient aux réglages.
+
+Confirmer pose les blocs sans consommer de matériaux, via le protocole serveur
+existant. Le plan garde son origine, son orientation et son suivi d’avancement.
+Les machines reçoivent leurs composants natifs : la clé dorée reste nécessaire
+pour assembler le multibloc fonctionnel. Les inventaires et entités ne sont
+pas copiés depuis les fichiers de plans.
+
+Le bouton disparaît si le mode de jeu change. Une confirmation devenue périmée
+(changement de plan, position, monde ou perte du créatif) ne lance rien.
+L’envoi en cours désactive le bouton et ne peut pas être remplacé par un second.
+En survie, la construction reste manuelle et le serveur refuse toujours les
+envois fabriqués sans passer par l’interface.
+
+Les validations serveur existantes restent applicables : cases libres ou déjà
+conformes, zone chargée, hauteur et bordure du monde, distance de 192 blocs,
+absence d’entité à l’emplacement, permissions et interdiction des blocs
+techniques sans objet. Aucun changement de génération ni format de sauvegarde.
+
+## Vérifications
+
+Suite native `Plans072ClientChecks`, Minecraft 26.3, nouveau monde plat de
+développement, graine 72 : **réussie en 47 secondes**.
+
+- Bouton créatif visible et confirmation inspectés en capture native.
+- Annulation sans placement ; statue de Creeper de 32 blocs de haut, 1 542
+  cellules, construite avec vérification de chaque matériau côté serveur.
+- Fourneau et abri choisis dans le catalogue physique, rotation, filtre sur
+  une seule couche : le bouton construit bien toutes les couches du plan.
+- Perte du créatif pendant la confirmation : aucun bloc posé, bouton absent.
+- Envoi falsifié en survie refusé ; pose manuelle consommant exactement un bloc.
+- Régression des 88 modèles natifs, export, matériaux et interfaces FR/EN.
+
+Le premier passage enchaînait les plans en moins d’une seconde et rencontrait
+la limite d’envoi serveur existante. Le test attend désormais 25 ticks entre
+constructions ; aucun changement de cette limite n’a été nécessaire.
+Le test Métabli conserve son assertion d’absence de catalogue à distance,
+mais ne considère plus le nouveau bouton créatif comme interdit.
+
+Captures dans `build/creative098-evidence/`, journal
+`build/creative098-client.log`.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussi en **2 min 7 s**, 124 tâches. Les GameTests sur serveur dédié restent
+exclus conformément au refus antérieur d’accepter son EULA. Aucun serveur
+dédié lancé ; essais uniquement sur un nouveau monde client de développement.
+
+Les archives ont été vérifiées : version Minecraft 26.3 et compteur beta.098,
+JAR sources identiques aux fichiers de travail, aucun test embarqué. Par
+rapport à beta.097, seules les classes PlanClient/PlansScreen et trois libellés
+FR/EN changent dans Sanctuary. Textures, données, resource pack et archives
+beta.097 conservés. Reçu : `build/beta098-artifact.json`.
+
+## Livraison locale
+
+- `build/Sanctuary-beta.098.mrpack`, 9 880 395 octets ; SHA-256
+  `f06d0cc0256c6c55b1081019d0f00d2f9d29963cbf06d63b8cf1d9b303970f7a`.
+- `build/Sanctuary-Test-beta.098.mrpack`, 9 899 316 octets ; SHA-256
+  `f2424a39b6b96076bdff8ac2a93e74ce83d77f453aa9bfbdd18a5fa17444f573`.
+
+Aucun déploiement dans une instance personnelle, aucune sauvegarde personnelle
+ouverte ou modifiée, aucun avancement du canal packwiz.

docs/diagonal-caves-beta227.md

@@ -0,0 +1,114 @@
+# Diagonales : transitions, dessous et cavités — beta.227
+
+Retour R045 sur beta.226, 5 octobre 2026. Branche `codex/diagonal-caves-beta227`,
+base `5fb1407`. Anciennes générations conservées ; nouveaux profils 227 uniquement.
+
+- NE jardin pâle/marais : transitions d’étangs sans paliers brutaux, relief 3D
+  plus présent à l’intérieur, fragmentation prononcée du pourtour, petites
+  échappées d’eau admises mais pas de rideau d’eau massif.
+- SO : surface désert/savane appréciée ; retirer de l’épaisseur rocheuse inutile
+  sous le plateau sans refaire sa surface.
+- SE : mangroves et silhouette validées ; ajouter de grandes régions de lush
+  caves et dripstone caves dans les parties inférieures.
+- NO : grandes plaines validées ; commencer le grignotage 3D plus près du centre.
+
+Captures consultées dans le labo 226 : `2026-10-05_21.05.12.png` et
+`2026-10-05_21.07.21.png`. Elles montrent des fonds d’étangs à transitions nettes.
+La profondeur binaire et le masque de protection des bassins dans 226 sont
+remplacés par des transitions continues. La photo seule ne prouve pas un
+problème de frontière de chunk ; les contrôles ci-dessous portent sur les
+transitions du champ et la décoration native.
+
+## Réalisation
+
+Les champs 225/226 restent figés. 227 s’appuie sur le champ 226 pour conserver
+la surface méridionale et la forme des récifs de mangrove. Aucun changement
+de sauvegarde, de génération existante ou de dimension.
+
+NE : retrait du halo binaire autour des lacs ; profondeur interpolée, relief
+intérieur continu avant arrondi en blocs, rugosité 3D atténuée près de l’eau.
+La bordure entière peut être découpée, y compris les anciens abords protégés.
+L’eau n’est placée que sur les fonds encore présents ; pas de remplissage des
+grandes failles ouvertes. De petites échappées restent possibles. Il ne s’agit
+pas d’une simulation d’hydrologie ni d’un réseau de cascades.
+
+SO : amincissement variable, environ 40 à 64 blocs sous le toit avec irrégularité
+3D du dessous. Les 24 blocs supérieurs restent sur le champ accepté. Sur les
+grilles de sondage 0/42, environ 49 à 51 % du volume rocheux échantillonné est
+retiré ; ce n’est pas un recensement exhaustif de toute l’île.
+
+SE : densité et biomes de surface 226 conservés. Sous la surface, de larges
+régions de grottes luxuriantes et à concrétions reçoivent les features natives
+26.3 (mousse, lianes lumineuses, fleurs sporifères, argile, grandes concrétions,
+stalactites/stalagmites). Plages de placement adaptées à Y=40–320. Aucune
+nouvelle lave, forêt d’azalées de surface ou nouvelle distribution de minerais
+ajoutée par ces deux biomes de cavités. Les volumes existants servent de support,
+sans nouvelle excavation de la silhouette validée.
+
+NO : le masque peut maintenant agir jusqu’à 340 blocs de distance interne
+au bord (contre 180), sans modifier le noyau de plaines restant. Le champ
+supplémentaire ne fait que retirer de la matière.
+
+## Vérifications
+
+Six GameTests ciblés réussis : transitions NE et relief intérieur sur quatre
+graines, extension des découpes NO et centre conservé, surface SO intacte et
+volume réduit, champ SE identique et deux vastes biomes souterrains, trois
+presets publics, ordre des features, déterminisme après recompilation et
+anciens profils lisibles.
+
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch
+-PsanctuaryFocusedTests=base204,diagonal227 -PsanctuaryAtlasOnly=true` réussit
+en 4 min 2 s (`build/diagonal227-build.log`).
+
+Les premiers essais natifs 0/42 valident le NE, les arbres immergés et les
+décorations des deux types de caves au SE. Ils s’arrêtent sur un contrôle trop
+étroit des arbres de savane : un seul chunk de chaque biome, tous sans arbre
+complet. Lecture des chunks FULL sauvegardés : 11 troncs / 70 feuilles sur 0,
+24 troncs / 214 feuilles sur 42. L’instrumentation élargit désormais la recherche
+à d’autres chunks de savane, sans changer la production. Helper recompilé et
+exporté ; nouveaux essais isolés `diagonal227-final0` et `diagonal227-final42`
+réussis, processus terminés normalement. Les mondes du premier essai restent
+intacts. Le helper final est recompilé puis exécuté dans ces deux essais ;
+aucun changement de production après le build complet.
+
+Les quatre offres réelles, leur coût, le refus d’un double paiement, la reprise
+après interruption et les quatre relais utilisables sont vérifiés sur chaque
+graine. Chaque activation prépare 49 chunks FULL. Les arbres natifs sont
+présents dans les quatre expansions ; 3 et 7 troncs enracinés dans les marais
+peu profonds ont été observés. Les sondages des cavités SE trouvent respectivement
+120/171 blocs de décoration lush et 34/30 de pointed dripstone. Ces comptages
+prouvent la décoration native dans les chunks examinés, pas sa densité globale.
+Les cannes à sucre de l’île principale restent présentes : 42 pieds sur 0,
+94 sur 42. Rapports ignorés sous `build/worldgen-lab/diagonal227-final{0,42}`.
+
+## Distribution et visite
+
+MRpack normal : `build/Sanctuary-beta.227.mrpack`, copie dans Downloads.
+Minecraft 26.3, Fabric Loader 0.19.5. Archive contrôlée, JAR conforme au build,
+trois tailles présentes, aucun module Test ni monde inclus. Les 398 ressources
+historiques de worldgen comparées sont identiques à 226 ; seul l’alias public
+Sanctuary pointe désormais vers les nouveaux profils.
+
+- SHA-256 MRpack : `5ffa88d0a8d30b17276bda0e644e3406dd2a2bdc7727a27e546320a502adf547`.
+- SHA-256 JAR : `e759515e49cd254f41e9ab786478cba02613c560534f77d89b820f69ae384dee`.
+
+Nouvelle visite isolée `diagonal227-final-visit`, monde
+`Sanctuary-Diagonal-227-0` : copie du nouveau monde de vérification arrêté,
+graine 0, île principale Petit, quatre expansions de 1024 prêtes, créatif avec
+commandes, distance 32 chunks et simulation 5. Départ au-dessus du relais NE.
+Ouverture confirmée le 5 octobre à 21:33:59 : `DIAGONAL227_VISIT_OPEN`,
+position `848, 384, -496`, backend Vulkan confirmé dans
+`build/diagonal227-solo.log`. Aucune validation OpenGL.
+
+| Région | Relais X, Y, Z sur la graine 0 |
+| --- | --- |
+| NE jardin pâle/marais | 848, 336, -496 |
+| SE mangroves/cavités | 560, 377, 816 |
+| SO savane/désert | -832, 217, 512 |
+| NO plaines/taïga | -608, 238, -768 |
+
+Le rendu reste à apprécier par le joueur, notamment les berges très découpées
+et l’étendue visible des cavités. Pas de visite complète Moyen/Grand, de mesure
+de fluidité ni d’essai Windows revendiqués. Aucun ancien monde modifié, aucun
+canal packwiz avancé et aucune installation Prism synchronisée.

docs/diagonal-islands-beta225.md

@@ -0,0 +1,100 @@
+# Diagonales climatiques et cannes à sucre — beta.225
+
+## Contrat
+
+Demande du 5 octobre 2026 : cannes à sucre près de l’eau de Sanctuary Island,
+puis quatre expansions diagonales de **1024 blocs** (512 remplacé pendant
+le chantier à la demande du joueur). Nord froid, Sud chaud,
+Est humide, Ouest sec. Branche `codex/diagonal-islands-beta225`, base `1388d8a`.
+
+- Nord-Est : marais frais, jardin pâle, forêt sombre et taïga.
+- Nord-Ouest : meadow, prairies, taïga et bosquets froids.
+- Sud-Est : mangroves, jungle et bambou.
+- Sud-Ouest : désert, savane et prairies sèches.
+
+Première variante : surfaces étendues, collines, dessous flottant irrégulier,
+zones humides fermées dans les dépressions du terrain. Végétation et faune
+des biomes natifs 26.3. Relais de continuation conservé. Les quatre cardinales
+restent en 1024 avec leur génération validée. Pas de nouvelle structure ici.
+
+Nouveaux profils 225 seulement, dans les trois tailles Sanctuary. Les profils
+224 et antérieurs gardent leurs règles et leurs tailles d’expansion. Aucune migration ou régénération de sauvegarde.
+Les essais utilisent uniquement des mondes neufs de développement (42 et 0).
+Le message SGA et l’aide de visite réservée aux opérateurs sont conservés.
+
+## Implémentation
+
+Champ de relief déterministe, collines à grande échelle, bordure irrégulière et
+bruit 3D dans le dessous. Épaisseur variable, de neuf blocs sur les extrémités
+à 68 blocs à l’intérieur. Les dépressions humides ont un niveau commun Y=204,
+un fond protégé et une couronne de terrain ferme ; aucune simulation
+hydrologique supplémentaire. La sélection des biomes est continue dans les
+coordonnées du monde et utilise les végétations natives 26.3.
+
+Les offres des ancres diagonales demandent un diamètre 1024 et conservent
+l’éventail de placement existant. Préparation limitée à 49 chunks autour du
+relais ; le reste se génère à l’exploration. Relais simple de continuation pour
+cette première variante. Les monuments régionaux des cardinales sont conservés.
+
+Les cannes réutilisent le plan des berges de surface, après leur aménagement.
+Groupes de deux ou trois blocs, sur sol accepté par Minecraft et à côté d’une
+eau réellement présente. Écriture limitée au chunk décoré, sans dépendre de
+l’ordre de décoration des chunks voisins. Aucun nouveau bassin créé.
+
+## Vérifications
+
+Six GameTests ciblés (`base204,diagonal225`) réussis : trois tailles publiques
+sans Test, lecture des anciens profils, biomes et étanchéité sur quatre graines,
+reproductibilité aux limites des chunks, éventail directionnel et absence de
+collision, conservation des matériaux du volcan, règles de survie des cannes.
+
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch
+-PsanctuaryFocusedTests=base204,diagonal225 -PsanctuaryAtlasOnly=true`
+réussit en 3 min 57 s. Log : `build/diagonal225-build.log`.
+
+L’essai natif 42 passe les quatre offres, le paiement, l’interruption/reprise,
+les relais et la végétation des quatre directions. 94 pieds de canne observés
+sur les berges de l’île principale. Le premier essai 0 a révélé une erreur
+**du contrôle** : son premier échantillon de mangrove était sur la berge sèche,
+ce qui ne prouvait rien sur l’eau de la dépression. Le contrôle cherche désormais
+une colonne réellement immergée et vérifie son fluide natif. Le nouvel essai 0 passe aussi les quatre activations et les contrôles natifs ;
+43 pieds de canne observés. La correction ne touche que l’instrumentation du
+module Test, recompilée et réassemblée ensuite ; le terrain livré est identique.
+
+| Graine | Nord-Est X/Z | Sud-Est X/Z | Sud-Ouest X/Z | Nord-Ouest X/Z | Cannes |
+| --- | --- | --- | --- | --- | --- |
+| 42 | 544 / -816 | 816 / 544 | -816 / 512 | -704 / -736 | 94 |
+| 0 | 848 / -496 | 560 / 816 | -832 / 512 | -608 / -768 | 43 |
+
+Les huit expansions mesurent 1024 blocs et passent chacune par 49 chunks FULL
+préparés. Présence de bois/feuilles natifs dans les quatre directions, mangroves
+et bambou à l’Est, cactus dans le désert à l’Ouest. Ces relevés sont locaux,
+pas un inventaire exhaustif de chaque île. Reçus ignorés :
+`build/worldgen-lab/diagonal225-check42/small/42/{cold,warm}.json` et
+`build/worldgen-lab/diagonal225-wet-check0/small/0/{cold,warm}.json`.
+
+## Distribution et limites
+
+MRpack standard vérifié : archive intègre, JAR exact, dépendances 26.3/Loader
+0.19.5, trois tailles 225 et 382 ressources historiques de génération identiques
+à beta.224 (sauf alias public du preset). Aucun monde ni module Test inclus.
+SHA-256 : `b178c15d8a40a1627134c64b343d13d508f9e7c95f85d43a1a88c8769d8e8c0c`.
+
+Le rendu reste à apprécier en jeu. Pas de campagne graphique ou Windows,
+ni de nouvelle exploration complète Medium/Large. Pas de changement du canal
+packwiz ni de l’installation Prism personnelle. Les mondes de contrôle restent
+dans les dossiers de développement ignorés.
+
+
+## Visite du 5 octobre 2026
+
+À la demande du joueur, nouveau solo `Sanctuary-Diagonal-225-0`, graine 0,
+copie du serveur de contrôle arrêté. Les quatre diagonales sont déjà prêtes ;
+départ au Nord-Est en 848 / 254 / -496. Vulkan, rendu 32 chunks, simulation 5,
+créatif/vol et commandes autorisées. Le client confirme `DIAGONAL225_VISIT_OPEN`.
+
+Ajout du nom Diagonal-225 à la liste du lanceur de visites et à son aide client
+optionnelle, compilée avec `:sanctuary-test:exportDuoLaunch`. L’identité des
+sources du contrôle a été vérifiée avant ce seul changement de lanceur ;
+génération et ressources de production identiques. Les anciens mondes et le
+MRpack beta.225 livré restent inchangés. La visite est une copie neuve isolée.

docs/diagonal-lower-groves-beta230.md

@@ -0,0 +1,64 @@
+# Jardins pâles bas et roche jaune — beta.230
+
+Retour R048 sur beta.229, 5 octobre 2026. Base `55df522`, branche
+`codex/lower-groves-beta230`. Nouveaux profils uniquement, aucune migration
+ou régénération des anciennes cartes.
+
+NE : garder le relief validé et étendre les chênes pâles aux terrasses situées
+sous le niveau du plateau, y compris à ciel ouvert. Dripstone dans les parties
+inférieures ; marais et lucioles restent sur le plateau. Eau toujours
+facultative et conditionnée à une cuvette naturellement fermée.
+
+SO : mêler la roche jaune existante à la pierre normale en masses continues,
+en conservant les minerais natifs et les cavités soufre/dripstone.
+SE mangroves et NO plaines validés par le joueur, champs de relief conservés.
+
+Le seuil inférieur suit le plafond ondulé du terrain savane (Y=230 ± 18),
+avec une bande supérieure de 12 blocs laissée au marais. Il ne suit plus le
+sommet local de chaque colonne : une terrasse basse ouverte est désormais un
+sol de jardin pâle. Même support 2 × 2 et même dégagement pour les arbres.
+Les formations natives de dripstone sont ajoutées au biome pâle inférieur.
+Les buissons à lucioles restent exclusivement au-dessus de ce seuil.
+
+La roche jaune est répartie par un bruit volumique lent, sans changer la
+forme de la savane. La substitution après décoration ne vise que Stone ;
+elle conserve les blocs de minerai, leur voisinage immédiat dans le chunk,
+les autres roches, le soufre et le cinabre. Aucune variante de minerai jaune
+ajoutée et aucun changement des tags minéraux globaux.
+
+Neuf GameTests ciblés réussis : reliefs conservés, séparation des habitats,
+terrasses ouvertes et sols abrités, cuvettes fermées, cavités sèches SO,
+substitution réelle de pierre avec conservation des minerais, presets et
+ordre des features. Les grilles 0/42 trouvent 274/285 sites de chêne pâle,
+dont 216/245 ouverts ; ces chiffres ne sont pas un inventaire de l’île.
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch
+-PsanctuaryFocusedTests=base204,diagonal230 -PsanctuaryAtlasOnly=true` réussit
+en 2 min 38 s. Contrôles natifs réussis sur 0/42 : quatre activations réelles, paiements et
+refus des doubles offres, interruption/reprise, 49 chunks FULL par expansion,
+relais utilisables. Les nouveaux mondes de contrôle sont arrêtés normalement.
+
+Au NE, dans les chunks sondés : 38/32 blocs de tronc pâle, quatre colonnes
+de racine à ciel ouvert sur chaque graine (un tronc de 2 × 2), 103/76 blocs
+de pointed dripstone et 7/1 buissons à lucioles supérieurs. Au SO : les deux
+roches sont présentes (462/1711 blocs jaunes et 7180/2707 Stone dans les
+échantillons), avec pics de soufre et dripstone. Ces comptes attestent la
+présence, sans mesurer la proportion globale sur chaque île.
+Rendu à apprécier en jeu.
+
+MRpack normal vérifié, copie dans Downloads : Minecraft 26.3 / Fabric Loader
+0.19.5, trois tailles, JAR identique au build, aucun module Test ni monde.
+Les 432 ressources historiques de worldgen comparées à 229 sont identiques.
+SHA-256 pack : `b080b17d7e54427d3a6b89da2b009637e99a648752ba49068a274fa35499f8e4`.
+SHA-256 JAR : `c72cc0afea27e7d71c73d6f4edc4f874bc5fb665288eba243d7faafcba5e3276`.
+Reçu : `build/diagonal230-mrpack-receipt.json`.
+
+Aucune publication de canal ni synchronisation Prism, aucune validation
+Windows ou mesure de fluidité.
+
+
+Nouvelle visite isolée `diagonal230-visit`, monde `Sanctuary-Diagonal-230-0`,
+copiée depuis le contrôle graine 0 arrêté. Île principale Petit et quatre
+expansions 1024 prêtes. Créatif avec commandes, 32 chunks, simulation 5 ;
+départ au relais NE (856, 273, -496). Ouverture Vulkan confirmée à 22:45:00
+le 5 octobre 2026, `DIAGONAL230_VISIT_OPEN` dans `build/diagonal230-solo.log`.
+Le rendu reste à apprécier par le joueur ; anciennes visites conservées.

docs/diagonal-relief-beta226.md

@@ -0,0 +1,110 @@
+# Reliefs distincts des diagonales — beta.226
+
+Retour du 5 octobre 2026 sur beta.225. Biomes appréciés, silhouettes refusées :
+grands plateaux identiques, bords tranchés. Branche `codex/diagonal-relief-beta226`,
+base `e2b9ee7` et conservation des ajustements locaux du lanceur de visite 225.
+
+- Nord-Est : garder les bassins, davantage de hauts reliefs émergés sans excaver
+  leur intérieur ; marais moins profonds, arbres plus fréquents dans l’eau,
+  quelques grands lacs conservés.
+- Nord-Ouest : grandes plaines et végétation validées ; bords rongés fortement
+  en 3D, effet qui diminue en allant vers le centre, centre préservé.
+- Sud-Ouest : remplacer la base par un terrain flottant 3D natif, grandes
+  surfaces de sable et roche, plateaux de savane, léger rehaussement local.
+- Sud-Est : relief très fragmenté, hauts et bas, récifs verticaux, davantage
+  de mangroves ; boue, argile et calcite. Abandon de l’ambiance plate.
+
+Diamètre 1024, Est humide/Ouest sec. Nouveaux profils 226 seulement. Île
+principale, cannes à sucre et quatre cardinales conservées. Pas de migration
+des mondes 225 ou antérieurs ; nouvelles visites isolées pour les essais.
+
+## Réalisation
+
+La révision 225 reste figée. Trois nouveaux profils 226 réutilisent exactement
+la génération de Sanctuary Island ; seules les diagonales passent au nouveau
+champ. Les anciennes ressources et leurs identifiants restent lisibles.
+
+Le Nord-Ouest réemploie les colonnes et matériaux 225 à plus de 180 blocs de
+la bordure. À l’extérieur, deux échelles de bruit volumique découpent le bord
+et le dessous ; un masque continu réduit l’effet en approchant du centre.
+Le Nord-Est conserve les dépressions et leur enveloppe étanche, garde une
+partie des lacs profonds et relève les autres fonds à une ou deux couches
+d’eau. Des reliefs émergés ajoutés en 3D restent à distance des bassins. Les
+chênes de marais natifs reçoivent davantage de tentatives de plantation.
+
+Le Sud-Ouest repart du champ flottant `PopulationIslandDensity`, sans le
+plateau commun 225, avec une limite haute légèrement ondulée pour les savanes.
+Le Sud-Est étire verticalement ce champ, ajoute des fractures et des récifs
+volumiques, et favorise les mangroves natives. Les différentes corniches
+exposées reçoivent du sol, pas seulement le sommet de la colonne ; les veines
+cohérentes de calcite et d’argile traversent la roche. Le sable repose sur une
+base solide. Les biomes de végétation natifs restent ordonnés et compatibles.
+
+Les bassins 225 conservés concernent le Nord-Est. Le Sud-Est abandonne ses
+anciens bassins plats ; ses mangroves poussent sur les corniches de boue.
+
+La préparation d’une expansion reste limitée à 49 chunks autour du relais.
+Pas de passe d’hydrologie ou de simulation supplémentaire, ni de nouvelle
+structure. Relais cherché sur un support réel ; le petit socle 3 × 3 existant est conservé,
+sans grande terrasse artificielle.
+
+## Contrôles
+
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch
+-PsanctuaryFocusedTests=base204,diagonal226 -PsanctuaryAtlasOnly=true` réussit
+en 2 min 42 s (`build/diagonal226-build.log`). Six GameTests : trois profils
+publics et historiques, conservation du centre NO, bords rongés, bassins NE
+étanches et moins profonds sur quatre graines (0, 42, 2026, -9137), volumes
+natifs méridionaux, part des mangroves, déterminisme après recompilation,
+relais supportés, ordre des features et routage des cardinales validées.
+
+Sur la grille de contrôle des deux graines 0/42, le NO perd plus de la moitié
+de ses colonnes de bord à leur ancienne hauteur, avec un centre strictement
+conservé. Le NE conserve des lacs profonds et 56 à 84 % de colonnes humides
+peu profondes sur les quatre graines. Les reliefs ajoutés dépassent localement
+85 blocs. Au SE, la mangrove couvre 67 à 73 % des colonnes émergées échantillonnées
+sur les graines de champ 0/42 ; les surfaces vont localement de Y=63 à Y=439.
+Ce sont des sondages de champs, pas des mesures exhaustives des mondes.
+
+Deux mondes natifs neufs, graines **0 et 42**, passent les quatre offres réelles,
+le refus des paiements incorrects et doubles offres, l’interruption après
+réservation, la reprise, les relais utilisables et la décoration native.
+Chaque préparation reste à 49 chunks FULL. Trois troncs natifs enracinés
+sous le niveau de l’eau ont été constatés dans le marais de chaque monde
+(arrêt du contrôle dès trois arbres). Bois et feuilles présents sur les quatre
+îles, mangroves sur les corniches SE. Cannes de l’île principale : 42 pieds
+sur 0, 94 sur 42. Les relevés de plantes portent sur quelques chunks par biome ;
+un échantillon désert sans cactus ne constitue pas un inventaire de l’île.
+
+Reçus ignorés :
+`build/worldgen-lab/diagonal226-check0/small/0/{cold,warm}.json` et
+`build/worldgen-lab/diagonal226-check42/small/42/{cold,warm}.json`.
+
+## Distribution
+
+MRpack standard beta.226 dans `build/` et `~/Downloads/`, contrôlé après
+assemblage : archive intègre, JAR construit exact, Minecraft 26.3 / Loader
+0.19.5, trois nouveaux profils et 388 ressources historiques de génération
+identiques à beta.225 (hors alias public). Aucun monde ou module Test inclus.
+SHA-256 : `c1ce5fc71a3e0417194d591d1ddd04b00dcef46565dfdb34ccd7ee2a01217e02`.
+
+Pas de publication du canal packwiz, de push ou de modification de Prism.
+Les mondes existants restent sur leur révision. Rendu à apprécier par le joueur ;
+pas de campagne de screenshots, de validation Windows ou d’exploration complète
+Medium/Large. Les contrôles des trois tailles vérifient leurs registres et presets.
+
+## Visite
+
+Copie isolée du serveur 0 arrêté dans
+`build/worldgen-lab/diagonal226-visit/small/0/client/saves/Sanctuary-Diagonal-226-0`.
+Créatif, vol et commandes autorisés ; 32 chunks de rendu, simulation 5,
+mémoire 4 Gio. Départ NE à 848 / 270 / -496. Vulkan confirmé ; `DIAGONAL226_VISIT_OPEN` le 5 octobre à 20:32:59.
+Le joueur passe en Spectateur à 20:33:04.
+
+Points d’observation libres, téléportation possible :
+
+- NE : `/tp @s 848 270 -496`
+- SE : `/tp @s 560 425 816`
+- SO : `/tp @s -832 265 512`
+- NO : `/tp @s -608 286 -768`
+

docs/diagonal-shaping-beta228.md

@@ -0,0 +1,88 @@
+# Diagonales : abaisser et ciseler — beta.228
+
+Retour R046 sur beta.227, 5 octobre 2026. Base `70a34df`, branche
+`codex/diagonal-shaping-beta228`. Nouveaux profils uniquement.
+
+Le jardin pâle monte trop haut entre les étangs. Conserver son pourtour 3D,
+abaisser fortement le relief et rendre les lacs lisibles. Les mangroves et
+leurs cavités conviennent, mais leurs volumes demandent des arêtes moins
+rondes. Même finition sur les bordures des plaines NO, plateau général
+conservé. L’épaisseur et la surface désert/savane SO sont validées et figées.
+
+Captures consultées dans le labo 227 : `2026-10-05_21.36.56.png` et
+`2026-10-05_21.40.07.png` ; grandes buttes NE et découpe arrondie NO visibles.
+
+## Réalisation
+
+NE : comprimer les hauteurs émergées, réduire la surélévation et l’annuler sur
+les fonds aquatiques. SE/NO : fractures Voronoi à largeur modulée par du bruit
+3D ; calcul cellulaire mis en cache par colonne. Le noyau de plaines NO et le
+champ SO restent ceux de 227. Réutiliser les deux biomes de cavités 227 au SE.
+
+La partie émergée du NE est comprimée à 55 % de sa hauteur au-dessus de l’eau.
+Les deux surélévations passent de 120 + 100 à 12 + 8 blocs, avec une transition
+continue qui les annule sur les fonds aquatiques. Le masque 3D du bord reste
+celui de 227. L’eau garde son niveau Y=204, sans nouvelle simulation hydrologique.
+
+Le Voronoi SE/NO fournit la distance aux faces des cellules ; deux bruits 3D
+modulent la largeur des fractures à différentes échelles. Le calcul cellulaire
+est réutilisé sur la colonne entière. Au NO, l’action supplémentaire cesse
+à 280 blocs de distance interne au bord : le centre est exactement celui de
+227. Au SE, seules des découpes sont ajoutées ; les cavités existantes ne sont
+pas remplies. Les nouveaux rebords reçoivent les matériaux du terrain 226.
+
+## Vérifications
+
+Sept GameTests ciblés réussis (`build/diagonal228-tests.log`). Sur les grilles
+NE de quatre graines, dont les deux graines d’expansion réellement visitées :
+sommets entre Y=228 et 237, baisse moyenne intérieure de 30 à 39 blocs,
+2,4 à 2,6 fois plus de colonnes en eau qu’en 227. Plus de 95 % des anciens fonds
+aquatiques 225 du centre sont de nouveau en eau. Ce sont des échantillons,
+pas une mesure exhaustive de la superficie des lacs.
+
+Sur 0/42, environ 8–10 % de matière en moins au NO et 22 % au SE dans les
+grilles sondées ; centre NO conservé, deux biomes de caves présents, relais
+sur support, surfaces de mangrove préservées comme habitats. Le champ de
+densité et les matériaux SO sont identiques à 227 sur les échantillons.
+Déterminisme, trois presets publics et anciens identifiants contrôlés.
+
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch
+-PsanctuaryFocusedTests=base204,diagonal228 -PsanctuaryAtlasOnly=true` réussit
+en 2 min 43 s (`build/diagonal228-build.log`), avec les sept GameTests.
+
+Contrôles natifs réussis sur deux nouveaux mondes isolés, graines 0/42 :
+`diagonal228-check0` et `diagonal228-check42`. Paiements et refus des doubles
+offres, interruption/reprise, quatre expansions de 1024, 49 chunks FULL par
+activation et relais utilisables vérifiés. Les sondages trouvent des arbres
+dans chaque région, ainsi que des troncs enracinés dans l’eau au NE (3/7).
+Au SE, présence native des décorations lush (389/114 blocs échantillonnés) et
+pointed dripstone (38/76). Ces comptages ne mesurent pas leur abondance globale.
+Les deux processus se terminent normalement. Aucun ancien monde modifié.
+
+## Artefact local
+
+MRpack normal `build/Sanctuary-beta.228.mrpack`, copié dans Downloads.
+Archive et JAR vérifiés, Minecraft 26.3 / Fabric Loader 0.19.5, trois tailles,
+aucun module Test ni sauvegarde dans le pack. Les 415 ressources historiques
+de worldgen comparées à 227 sont identiques ; seul l’alias public est avancé.
+
+- SHA-256 MRpack : `5e808121a2b1e3e358c58a2bb4616592521a4bd54cb18fe25c3ab68b05a4ee9d`.
+- SHA-256 JAR : `4a62259e1d941079de44237ed3a342a5a5e7fbe443fce07826fda76be2dd2a58`.
+
+Nouvelle visite `diagonal228-visit`, monde `Sanctuary-Diagonal-228-0`, copiée
+depuis le nouveau monde de contrôle arrêté. Graine 0, île principale Petit,
+quatre expansions de 1024 prêtes, créatif avec commandes, 32 chunks et simulation
+5. Ouverture Vulkan confirmée le 5 octobre à 21:54:28 dans
+`build/diagonal228-solo.log` : `DIAGONAL228_VISIT_OPEN`, position 848, 267, -496.
+
+| Région | Relais X, Y, Z sur la graine 0 |
+| --- | --- |
+| NE jardin pâle/marais | 848, 219, -496 |
+| SE mangroves/cavités | 560, 377, 816 |
+| SO savane/désert | -832, 217, 512 |
+| NO plaines/taïga | -608, 238, -768 |
+
+Le rendu reste à apprécier par le joueur. Ces essais ne constituent pas une
+mesure de fluidité ni une visite exhaustive des tailles Moyen/Grand. Aucun
+essai Windows, aucune modification d’un ancien monde, aucune publication de
+canal packwiz ou synchronisation Prism dans ce chantier.

docs/diagonal-understory-beta231.md

@@ -0,0 +1,76 @@
+# Sous-bois pâles et visite des neuf îles — beta.231
+
+Retours R049–R050 du 5 octobre 2026. Base `42e42fe`, branche
+`codex/pale-understory-beta231`. Correctif livré ; nouvelle visite ouverte.
+
+Compléter les sols inférieurs du jardin pâle : herbes, fleurs natives
+(eyeblossoms), tapis et mousse suspendue sous les feuillages. Conserver les
+formes, arbres, dripstones, marais supérieurs et géologie de savane validés.
+L’eau reste facultative, seulement dans les cuvettes naturelles existantes.
+Nouvelle révision de génération, sans modifier les anciens profils ou mondes.
+
+Préparer une nouvelle visite isolée sur la graine 0 : Sanctuary Island Grand
+(1024 blocs), huit expansions de 1024, toutes activées. Le joueur a choisi ensuite une ouverture immédiate,
+avec chargement des zones restantes pendant l’exploration. Créatif, commandes, Vulkan, distance 32 chunks. Aucun changement
+à la génération normale du rythme d’ouverture des expansions. Pas de
+publication de canal, ni modification de l’instance Prism personnelle.
+
+Le correctif réutilise exactement le champ de terrain 230 et ses biomes.
+Une décoration supplémentaire parcourt les sols inférieurs réels du NE,
+à ciel ouvert ou abrités : herbe courte/haute, tapis de mousse pâle et fleurs
+fermées natives, avec leur transition jour/nuit. Petits rideaux de mousse
+sous le feuillage pâle. Les regroupements suivent des bruits lents ; aucune
+plante ne remplace eau, roche, tronc, dripstone ou végétation existante.
+
+Cinq GameTests passent, dont support réel des plantes, double hauteur,
+protection des obstacles et conservation du champ accepté sur 0/42.
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch
+-PsanctuaryFocusedTests=base204,diagonal231 -PsanctuaryAtlasOnly=true` passe
+en 2 min 34 s. MRpack normal vérifié (Minecraft 26.3 / Loader 0.19.5), trois
+tailles, JAR exact, sans Test ni monde ; 439 ressources historiques identiques.
+SHA-256 pack : `3a9763cb81e088a0beeb4e4044dd35586a590c75f6c2f9a035937c8df4dee14c`.
+SHA-256 JAR : `8ba7b19428094e01ac9f3b6b3f8054343bc7a3df60f786260f01b487ee2f675a`.
+Copie `Downloads/Sanctuary-beta.231.mrpack`, reçu
+`build/diagonal231-mrpack-receipt.json`.
+
+La préparation complète est explicite :
+`python3 scripts/worldgen_lab.py verify --run archipelago231-check0 --profile large
+--seed 0 --checks diagonal231 --all-islands --memory 2048`.
+Elle utilise les paiements natifs, conserve l’interruption/reprise du premier
+relais, puis charge les neuf emprises avec une limite de quatre chunks en
+cours. Chaque chunk doit atteindre FULL, tickets libérés au fur et à mesure.
+Rapport final et arrêt propre requis avant de copier la nouvelle visite.
+Sur la graine 0 en Grand, les quatre contrôles natifs des diagonales passent :
+NE, dans un chunk inférieur sondé, 75 blocs d’herbe, 24 fleurs, 37 tapis,
+8 mousses suspendues, 44 troncs pâles, 105 dripstones et 5 lucioles supérieures.
+Ces nombres attestent leur présence ; ils ne mesurent pas toute l’île.
+Savane : 7731 blocs jaunes et 101 de pierre dans les échantillons ; cavités
+soufre/dripstone présentes. Mangroves et plaines conservent leurs habitats.
+
+Les huit activations réelles aboutissent, relais présents, journal relu :
+neuf îles de diamètre 1024 en état `ready`, génération 231, graine racine 0.
+La prégénération intégrale visait 41 458 chunks ; le joueur choisit de lancer
+le solo immédiatement. Arrêt demandé à 23:06:09, sauvegarde normale achevée,
+dernier jalon 256/41 458 (en plus des zones d’arrivée et échantillons).
+Ce contrôle interrompu volontairement n’est **pas** une prégénération complète
+réussie ; les zones restantes se chargent pendant l’exploration.
+Reçu : `build/worldgen-lab/archipelago231-check0/large/0/visit-readiness.json`.
+Anciennes visites conservées, aucune validation Windows ou mesure de fluidité.
+
+
+Visite `archipelago231-visit/large/0`, monde `Sanctuary-Diagonal-231-0`,
+créée depuis le serveur arrêté et ouverte à 23:07:33 le 5 octobre 2026.
+Vulkan confirmé, marqueur `DIAGONAL231_VISIT_OPEN`, départ (0, 320, 0),
+créatif/vol/commandes, rendu 32 chunks, simulation 5. Les données du labo
+restent dans `build/` ignoré. Aucun ancien monde modifié.
+
+| Île | Centre X/Z | Commande de visite |
+| --- | --- | --- |
+| Nord | 32 / -1984 | `/sanctuary expansion visit r2yyuk27a85c8p` |
+| Nord-Est | 736 / -960 | `/sanctuary expansion visit r7vapqz7anv7c` |
+| Est | 1776 / -208 | `/sanctuary expansion visit r2zwcc9ktr14ds` |
+| Sud-Est | 960 / 736 | `/sanctuary expansion visit r3bswui5wc00kk` |
+| Sud | 0 / 1536 | `/sanctuary expansion visit r391kr4y3lwlzy` |
+| Sud-Ouest | -960 / 736 | `/sanctuary expansion visit rclt83rncgsv1` |
+| Ouest | -1792 / -192 | `/sanctuary expansion visit r3r7b6q184g2a1` |
+| Nord-Ouest | -736 / -960 | `/sanctuary expansion visit r81ebztggj346` |

docs/diagonal-wetland-beta229.md

@@ -0,0 +1,97 @@
+# Marais étagé et cavités sèches — beta.229
+
+Retour R047 sur beta.228, 5 octobre 2026. Base `b77d71b`, branche
+`codex/wetland-reset-beta229`. Nouveaux profils uniquement ; aucun ancien
+monde, chunk ou identifiant de génération migré.
+
+## Contrat
+
+Refaire entièrement le NE : même géométrie que la savane amincie validée,
+chênes pâles sur les sols abrités sous la roche, marais en haut. Lucioles
+uniquement dans le marais supérieur. Eau facultative, seulement quand le
+relief possède une dépression fermée ; abandon des lacs à niveau constant.
+SO : soufre et dripstone dans les parties inférieures, sans lush caves et
+sans changer la surface. SE mangrove entièrement validé ; NO conservé
+provisoirement malgré les réserves esthétiques, aucune retouche des deux.
+
+## Implémentation
+
+Le NE réutilise le champ de densité SO 228, avec la graine propre à cette
+expansion. Épaisseur variable et plateau restent ceux de ce champ ; seules
+les matières et les habitats changent. Sous les 12 derniers blocs du toit,
+biome jardin pâle ; en haut, biome marais. Plantation native des chênes pâles
+sur des sols naturels de 2 × 2 avec le dégagement nécessaire sous un surplomb.
+Les buissons à lucioles sont posés sur le sol supérieur réel, jamais sur des
+feuilles ni dans le jardin pâle inférieur.
+
+Aucune simulation hydrologique ni construction de cuvette : une recherche
+locale bornée accepte seulement des dépressions d’un bloc de profondeur,
+avec deux blocs de fond solide et des murs naturels continus. Si une paroi
+manque, toute la mise en eau est abandonnée. Ces mares peuvent être rares
+ou absentes suivant la graine. Les biomes NE n’ajoutent aucune source native.
+
+SO : régions de soufre/cinabre ou dripstone sous le plateau, dans les
+cavités du terrain existant. Formations natives de pics de soufre et de
+speleothèmes ; aucun creusement nouveau ni décor lush. Les deux autres
+champs et leurs décorations restent en révision 228.
+
+## Vérifications
+
+Huit GameTests ciblés passent (`build/diagonal229-tests.log`). Sur les graines
+0/42, identité du champ NE avec le SO 228, habitats séparés en hauteur,
+65/46 emplacements de chênes pâles sur les grilles sondées, mares toutes
+bordées de matière naturelle, déterminisme, cavités SO et conservation des
+champs SE/NO contrôlés. Les nombres d’emplacements ne représentent pas un
+inventaire exhaustif des arbres de l’île.
+
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch
+-PsanctuaryFocusedTests=base204,diagonal229 -PsanctuaryAtlasOnly=true` réussit
+en 2 min 38 s. Contrôles natifs 0/42 réussis, avec quatre offres réelles,
+refus des doubles offres, consommation correcte, interruption/reprise,
+49 chunks FULL par activation et relais utilisables.
+
+Dans les chunks sondés au NE : 40/44 blocs de tronc pâle et 9/4 buissons à
+lucioles supérieurs ; racines sous des surplombs et aucune luciole basse.
+Au SO : 32/37 pics de soufre et 9/76 pointed dripstone ; aucun décor lush
+trouvé dans les cavités inspectées. Ces chiffres attestent la présence,
+pas l’abondance globale. Les cavités lush/dripstone SE restent présentes.
+
+Lecture des deux sauvegardes arrêtées (`build/diagonal229-water-audit.json`) :
+52/51 chunks NE FULL, 36/12 colonnes de racines pâles, aucune cellule d’eau.
+Les rares mares du plan théorique n’étaient donc pas présentes dans cet
+échantillon natif ; leur fréquence visuelle reste à apprécier ailleurs.
+Aucun ancien monde n’a été modifié.
+
+## Artefact local
+
+MRpack normal `build/Sanctuary-beta.229.mrpack`, copie dans Downloads.
+Archive et JAR construits vérifiés, Minecraft 26.3 / Fabric Loader 0.19.5,
+trois tailles publiques, aucun module Test ni sauvegarde. Les 421 ressources
+historiques de worldgen comparées à 228 sont identiques ; seul l’alias public
+est avancé. Reçu : `build/diagonal229-mrpack-receipt.json`.
+
+- SHA-256 MRpack : `788b3aa5898f12aed4570224beb4dd44505eb9e5cae89cefdef9fe7549c85f8b`.
+- SHA-256 JAR : `50fd7d6c04c9060abf3eca89bbaf936b39c6e9e82051d2d6559f197f425fdda9`.
+
+Aucune validation Windows ni mesure de fluidité. Aucun ancien monde modifié,
+aucune publication du canal packwiz ni synchronisation Prism.
+
+
+## Visite
+
+Nouvelle visite isolée `diagonal229-visit`, monde `Sanctuary-Diagonal-229-0`,
+copiée depuis le nouveau contrôle graine 0 arrêté. Île principale Petit,
+quatre expansions de 1024 prêtes, créatif avec commandes, vue 32 chunks,
+simulation 5. Ouverture Vulkan confirmée à 22:23:49 le 5 octobre 2026 :
+`DIAGONAL229_VISIT_OPEN` dans `build/diagonal229-solo.log`. Rendu à apprécier
+par le joueur.
+
+| Région | Relais X, Y, Z sur la graine 0 |
+| --- | --- |
+| NE marais / jardin pâle inférieur | 856, 225, -496 |
+| SE mangroves / cavités | 560, 377, 816 |
+| SO savane / cavités sèches | -832, 217, 512 |
+| NO plaines / taïga | -608, 238, -768 |
+
+Exemple de pied de chêne pâle observé dans la sauvegarde : 475, 174, -541.
+Le joueur démarre au-dessus du relais NE. Anciennes visites conservées.

docs/directional-lights-beta141.md

@@ -0,0 +1,127 @@
+# LIGHT-141 — Direction locale pour les normales PBR
+
+Socle beta.140 `c9f5c56`, branche `codex/directional-lights-beta141`.
+Minecraft 26.3 / Java 25. Livraison beta.141.
+
+## Contrat
+
+Estimer une direction d'arrivée depuis les six voisins du champ lumineux,
+avec intensité et confiance. Conserver cette estimation dans une texture
+compacte reconstruite avec le champ, uniquement quand le PBR est actif.
+Les sources portées utilisent leurs positions déjà disponibles. Brancher ces
+directions sur les normales et reflets PBR existants, sans nouveau bouton.
+Les sources opposées doivent réduire la directionnalité, sans bascule brutale.
+Les champs précédent/courant gardent leur fondu et les obstacles restent pris
+en compte pour les blocs posés. Aucun changement de lumière de gameplay,
+de sauvegarde ou de génération ; aucune promesse de lancer de rayons exact.
+
+## Programme de vérification
+
+Contrôles natifs OpenGL/Vulkan : direction, sources opposées, murs, rendu de
+relief en intérieur, déplacement des sources, transitions et PBR OFF.
+Régression des lumières beta.139/140 puis check/build et assemblage. GameTest
+serveur dédié exclu selon le refus EULA antérieur. Aucun monde personnel ouvert.
+
+## Réalisation
+
+Le champ RGB conserve une texture directionnelle RGBA8 supplémentaire :
+les trois composantes codent la direction pondérée, l'alpha sa réponse lumineuse.
+Les voisins plus lumineux et accessibles contribuent à l'estimation ; les
+arrivées opposées s'annulent dans le vecteur, sans supprimer l'éclairage natif.
+Le shader interpole les moments pondérés avant normalisation, y compris entre
+les champs précédent et courant. La confiance réduit le relief quand aucune
+direction ne domine.
+
+Cette texture est préparée dans le budget de reconstruction existant, avec
+un maximum de six voisins par cellule éclairée et une table d'énergie réutilisée.
+Aucune recherche de sources ni rayons par pixel pour les blocs posés. La
+lecture GPU interpole huit cellules par champ ; les deux champs sont utilisés
+pendant le fondu. Les sources mobiles réutilisent les positions, intensités et
+transitions déjà collectées, dans la limite existante de 128 sources.
+
+Une texture directionnelle occupe environ 1,5 Mo à 16 blocs de distance et
+19 Mo à 64 blocs, par copie CPU/GPU ; deux champs coexistent lors des transitions.
+Le champ directionnel n'est construit que si PBR est actif avec une intensité
+non nulle. Sa désactivation libère les directions après la transition.
+Le coût est borné par ces réglages, sans garantie de FPS.
+
+La passe PBR applique la différence entre normale de base et normale perturbée,
+puis un reflet GGX local. Elle garde sa portée de 32 blocs et les réglages PBR
+existants ; Lumières colorées doit être actif. Le soleil et la lune continuent
+à fonctionner lorsque les lumières colorées sont coupées. Les aides FR/EN
+expliquent cette dépendance.
+
+C'est une direction dominante approximative : deux lumières colorées opposées
+ne produisent pas deux reflets indépendants. Les sources mobiles gardent la
+propagation radiale et les limites d'occultation existantes. Les normales PBR
+concernent les surfaces de blocs prises en charge, pas tous les modèles de mobs.
+Les exclusions existantes des panoramas et de l'immersion restent inchangées.
+
+## Premier essai ciblé
+
+L'essai natif OpenGL ciblé réussit en **1 min 12 s** : direction gauche/droite,
+annulation des sources opposées avec énergie conservée, occultation par un mur,
+relief sur la pierre en intérieur et avec une torche en main, stabilité au repos,
+libération des directions avec PBR OFF et maintien du chemin solaire avec
+Lumières colorées OFF. La somme d'écarts PBR OFF/ON sur la pierre vaut 878 114
+au réglage PBR 100 % ; c'est une comparaison de pixels, pas une mesure de FPS.
+Log : `build/directional141-focused.log`.
+
+Les essais de préparation ont révélé un conflit de nom de matrice GLSL, corrigé,
+puis des erreurs de fixture (angle 180° normalisé par Minecraft, suppression
+d'entités alors que la sélection était vide, commande d'heure déjà à minuit),
+corrigées sans changer le rendu.
+
+## Validation complète OpenGL
+
+La chaîne complète réussit en **3 min 1 s** sur OpenGL / Apple M1 :
+`COLORED139_PASS`, `COLORED140_PASS` et `DIRECTIONAL141_PASS`.
+Elle réunit les contrôles de couleurs, objets portés, caméra, occultation,
+rechargement des ressources, préférences, distances/fondus et directions PBR.
+Le test ciblé est reproductible avec `-PsanctuaryDirectional141Only=true` ;
+la chaîne complète utilise `-PsanctuaryDirectional141ClientTests=true` avec
+les deux suites de lumières existantes.
+Log : `build/directional141-opengl.log`. Captures natives conservées dans
+`build/directional141-opengl-screenshots/`. Comparaison autonome sans retraitement :
+`build/Shader-beta.141-comparaison.html`.
+
+## Validation complète Vulkan
+
+La même chaîne réussit en **2 min 56 s** sur Vulkan / Apple M1, MoltenVK 1.4.2,
+profondeur 0–1 et transparence améliorée. Les trois marqueurs de réussite sont
+présents dans `build/directional141-vulkan.log`. L'écart PBR local OFF/ON vaut
+878 107, contre 878 114 sous OpenGL dans cette scène. Les captures natives sont
+conservées dans `build/directional141-vulkan-screenshots/`.
+Les deux moteurs vérifient la compilation, les chemins actifs et désactivés,
+le cache, les murs, les sources opposées et portées, ainsi que les régressions
+beta.139/140. Pas de validation des pilotes Windows de l'utilisateur revendiquée.
+
+## Construction et archives
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit en **2 min 35 s**, 126 tâches. Le GameTest serveur dédié reste exclu
+selon le refus EULA antérieur. Les suites clientes ci-dessus ont été exécutées
+séparément. Log : `build/shader141-build.log`.
+
+Comparaison à beta.140 : **8 entrées de production modifiées**, limitées au
+champ lumineux, à sa préparation avant le PBR, au shader PBR et aux aides FR/EN.
+Les archives normale/Test contiennent le même JAR Sanctuary, sans classes
+de test. Version, dépendances exactes, sources des JAR, textures de gemmes et
+de la clé de Steve, et template complet sont vérifiés.
+Reçu : `build/shader141-artifact.json`.
+
+SHA-256 du JAR : `660f29c3fa77fee4de6a8db5673c61619985804494f70e961998da36f396d0f1`.
+
+- Sanctuary-beta.141.mrpack : `08df23dac9e98fbfa2935f747345c38244bddc3a3d9371c6416f251e85a7eb19`.
+- Sanctuary-Test-beta.141.mrpack : `a300ef5bfff7b6990c9f5c2760e9c3a23d7a27aeb10b8f04d29db9a7409fa0e1`.
+
+## Livraison
+
+[Release beta.141](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.141)
+publiée sur le commit source `93ed5574a4f77bd3a083b254498f4994efe31179` ; canal stable
+`7e6c84400f80db24bf5204cd21d628194ae9f0f7` vérifié après publication.
+Deux synchronisations isolées puis deux dans la même instance Sanctuary Beta
+réussissent. Les **923 fichiers personnels** suivis gardent leurs hashes.
+Sauvegarde préalable : `sanctuary-backups/before-beta.141/`. Aucun monde personnel
+ouvert. Reçus : `build/shader141-isolated.json` et `build/shader141-prism.json`.
+Archives normale/Test/template et comparaison copiées dans `sanctuary-beta/build/`.

docs/discord-beta130-160.md

@@ -0,0 +1,60 @@
+# Récap Discord — beta.130 à beta.160
+
+Brouillon à relire avant publication. Les captures sont des scènes de test,
+pas des photos d'un serveur public. Aucune annonce envoyée automatiquement.
+
+## Message 1 — l'image et la lumière
+
+**Sanctuary — retour sur les beta.130 à 160**
+
+On a d'abord beaucoup travaillé l'ambiance : bloom, minerais lumineux, rebonds
+de couleur, relief des matériaux, reflets, rayons du soleil et lumières portées.
+L'eau a reçu ses propres réglages, puis plusieurs passes de correction ont
+amélioré les transitions, les distances et les matières.
+
+La version du shader conservée est celle du socle beta.151. Elle reste gourmande,
+mais on garde ce travail ! En beta.160, le shader devient **désactivé par défaut
+sur une nouvelle configuration**, et peut être réactivé dans les options.
+
+Images : `01-minerais-bloom-beta130.png`, `02-eau-beta144.png`.
+
+## Message 2 — la vie du serveur
+
+Le chantier suivant rapproche Minecraft et le site Sanctuary : **Gazette,
+tableau d'affichage et intendance** partagent un contrat de publications.
+Le mod fonctionne avec des fichiers par défaut ; une base MariaDB permet de
+partager les données avec le site.
+
+Le menu pause a été réorganisé autour des systèmes Sanctuary, de la carte et
+des publications. La Gazette accepte les articles avec une capture obligatoire,
+les réponses, les épingles et la recherche par joueur ou contenu.
+
+Le tableau distingue les types d'annonces par couleur. Les demandes peuvent
+indiquer un lieu, des matériaux, une récompense et des participants. Ce sont
+des descriptions pour organiser les échanges entre joueurs : aucun coffre de
+dépôt ni paiement automatique. Une demande suivie apparaît avec un **! sur la
+carte**, et son résumé se lit au survol.
+
+Images : `03-menu-et-quete-beta159.png`, `04-materiaux-beta158.png`.
+
+## Message 3 — tester ensemble
+
+Avec la beta.160, on prépare nos séances de test en binôme sur Mac : un petit
+serveur local, un seul Minecraft à l'écran et des personnages de laboratoire.
+Le but : vérifier les échanges côté technique pendant que les vrais essais en
+jeu nous montrent ce qu'il faut simplifier dans l'interface.
+
+Des scènes courtes et des captures horodatées permettront de reprendre les
+moments où l'on hésite, cherche un bouton ou perd le fil. Le prochain chantier
+est l'ergonomie, dans le jeu comme sur le site.
+
+## Sources et pièces jointes
+
+Les images originales et leurs empreintes sont rassemblées dans
+`build/discord-beta130-160/` (ignoré par Git), avec `images.json` pour la provenance.
+Les captures anciennes illustrent leur version d'origine, sans revendiquer une
+nouvelle validation graphique. Les sondages restent une idée, pas une fonction livrée.
+
+Références : `shader-beta130.md` à `nether-pbr-beta151.md`,
+`community-beta154.md`, `pause-redesign-beta155.md`, `gazette-photos-beta157.md`,
+`community-cards-beta158.md`, `community-search-beta159.md`, `duo-lab-beta160.md`.

docs/duo-lab-beta160.md

@@ -0,0 +1,155 @@
+# DUO-160 — laboratoire Mac et tests en binôme
+
+Branche `codex/duo-lab-beta160`, base `beta.159`. Minecraft 26.3, Java 25,
+Fabric 0.19.5 ; mêmes dépendances. Validation graphique Vulkan uniquement.
+
+## Contrat
+
+Le shader natif est OFF quand sa préférence est absente. Un choix sauvegardé
+ON ou OFF reste respecté, ainsi que ses intensités. Aucun shader supprimé :
+les ressources beta.151 restent identiques. Le client du laboratoire reçoit
+explicitement `enabled:false`, indépendamment de l'installation personnelle.
+
+Tout le laboratoire réside dans `build/duo/`, ignoré par Git. Le monde plat
+`duo-flat-160`, graine 160, sert aux interfaces et aux échanges ; il ne valide
+pas le terrain Sanctuary. Aucun monde personnel ouvert ou modifié.
+Le module `sanctuary-test` fournit les personnages uniquement avec
+`-Dsanctuary.duo=true`. Il ne fait pas partie du pack normal.
+
+## Préparer et lancer
+
+```sh
+export JAVA_HOME=$(/usr/libexec/java_home -v 25)
+./gradlew :sanctuary-test:exportDuoLaunch --max-workers=1 -Dorg.gradle.jvmargs=-Xmx1G
+python3 scripts/duo_lab.py prepare
+python3 scripts/duo_lab.py server
+# Dans un autre terminal :
+python3 scripts/duo_lab.py client
+```
+
+L'export permet ensuite de lancer Java directement, sans conserver un processus
+Gradle pendant la séance. Préparer à nouveau ne remplace aucun fichier existant.
+Le client rejoint automatiquement `127.0.0.1:25575`. Au premier accès,
+choisir la couleur et le familier dans HELLO_WORLD puis entrer dans Sanctuary.
+Depuis la console serveur : `op KokaLab` donne les commandes au client de test.
+
+Le serveur écoute seulement sur loopback et utilise des identités hors ligne
+pour ce laboratoire. Ce profil ne doit pas être exposé sur le réseau. La liaison
+authentifiée d'un compte web exige toujours un vrai serveur en mode en ligne ;
+elle n'est pas contournée par les outils du laboratoire.
+
+Réglages de départ : serveur 256–768 Mio de heap, vue 4 chunks, simulation 3 ;
+client 512–2048 Mio, vue 6, simulation 4, 30 FPS, fenêtre 1280×720. La mémoire
+native, graphique et macOS s'ajoute au heap. Aucun engagement de tenir dans
+une consommation totale de 2,75 Gio. Ne pas exécuter la compilation en même
+temps qu'une séance. Augmenter seulement après mesure :
+
+```sh
+python3 scripts/duo_lab.py server --memory 1024
+python3 scripts/duo_lab.py client --memory 2560
+```
+
+Le mode fichier reste le défaut. Pour une préparation neuve avec le site local :
+
+```sh
+python3 scripts/duo_lab.py prepare --storage database --server-id UUID_DU_SERVEUR \
+  --jdbc jdbc:mariadb://127.0.0.1:33077/BASE_DE_TEST
+SANCTUARY_COMMUNITY_DB_PASSWORD='' python3 scripts/duo_lab.py server
+```
+
+La base doit déjà avoir le schéma communautaire v3. Le site doit utiliser le
+même identifiant de serveur. Aucun schéma ni sauvegarde n'est migré ici.
+
+## Personnages et séances
+
+```text
+/duo spawn Alice
+/duo spawn Bob
+/duo list
+/duo remove Alice
+/duo trace start
+/duo trace stop
+```
+
+Les personnages portent le préfixe `Lab_`, sont créatifs et apparaissent près
+de la source de commande. Limite de quatre, noms uniques de 1–12 caractères
+ASCII alphanumériques ou `_`. Ce sont des ServerPlayer sans transport réseau
+ni rendu, pas des IA et pas des clients réseau supplémentaires. On peut les
+cibler avec les commandes natives, par exemple `tp Lab_Bob ~2 ~ ~`.
+Ils ne valident pas seuls le protocole d'un deuxième client réel.
+
+La trace consigne noms de test, dimension, positions et angles toutes les deux
+secondes dans `build/duo/server/duo-sessions/`. Activation explicite, arrêt au
+bout de cinq minutes maximum ou à la fermeture du serveur. Pas de frappe clavier,
+mot de passe, navigateur ou audio enregistré.
+
+Pour la relecture visuelle, identifier la fenêtre Minecraft puis lancer :
+
+```sh
+python3 scripts/duo_lab.py windows
+python3 scripts/duo_lab.py record --window ID_FENETRE_MINECRAFT --seconds 120
+```
+
+Une séquence PNG horodatée toutes les deux secondes, un index HTML et une fiche
+de notes sont écrits dans `build/duo/sessions/`. Ctrl-C termine la capture ; limite
+de cinq minutes. macOS peut demander l'autorisation de capture. Cette version
+ne produit pas une vidéo continue et peut manquer une interaction très courte.
+On ne démarre une capture qu'au début d'une scène annoncée.
+
+## Trois premières scènes
+
+1. Ouvrir la Gazette, retrouver un auteur, lire un article et répondre. Vérifier
+   que l'autre interface retrouve la réponse, puis noter les hésitations.
+2. Créer une demande avec lieu et matériaux, la suivre, lire son infobulle sur
+   la carte, ouvrir la discussion puis arrêter le suivi.
+3. Afficher deux figurants, tester les interactions de proximité et comparer
+   la fluidité à un seul joueur. Garder un véritable second client pour une
+   vérification réseau ultérieure si nécessaire.
+
+Le récap Discord se trouve dans `discord-beta130-160.md` ; les originaux des
+quatre illustrations sont copiés avec provenance dans `build/discord-beta130-160/`.
+
+## Vérifications
+
+- `./gradlew check build assemblePack` : 252 GameTests, 229 réussites et les
+  mêmes 23 échecs que beta.159. Aucun échec ajouté ; comparaison dans
+  `build/duo160-server-failures.json`, log `build/beta160-check-build.log`.
+- Contrôles restants, compilation, pack et client natif Vulkan réussis avec la
+  suite serveur déjà exécutée exclue (`-x :sanctuary:runGameTest`) : 137 tâches,
+  `build/beta160-release.log`. Le test `ShaderDefaults160ClientChecks` vérifie
+  préférence absente, objet vide, ON explicite, OFF enregistré et réactivation,
+  avec intensité personnelle conservée. Marqueur `SHADER160_DEFAULTS_PASS`.
+- Module de test reconstruit après ajustement du transport sans réseau : build
+  réussi. L'export de lancement inclut les arguments fournis par Loom et élimine
+  son argfile imbriqué, que Java ne peut pas réinterpréter depuis un autre argfile.
+- Serveur réel à 768 Mio : démarrage sur loopback, monde plat neuf ; création de
+  quatre acteurs, doublon et cinquième refusés, retrait et acteur absent vérifiés.
+  Le journal produit 56 observations JSON valides puis s'arrête sur commande.
+- Client réel séparé, Vulkan, 2048 Mio, shader OFF : connexion jusqu'à l'écran
+  HELLO_WORLD vérifiée visuellement. La création du profil et le parcours en jeu
+  avec le joueur restent à faire ensemble ; aucune session ergonomique humaine
+  terminée ni validation d'un deuxième client réseau revendiquée.
+- Mesure ponctuelle avant l'entrée du joueur : serveur ~313 Mio de heap utilisé,
+  client au menu ~289 Mio. Ce ne sont ni des pics ni une mesure de RAM système
+  totale. Les figurants ne possèdent ni sockets ni fenêtre graphique.
+- Capture ciblée macOS essayée sur quatre secondes : séquence PNG, manifeste,
+  index HTML et fiche de notes créés. Aucun enregistrement continu ou micro.
+- Export MRpack : intégrité ZIP, version et JAR embarqué vérifiés. Les 29 ressources
+  de shaders sont inchangées depuis beta.159. JAR et packs beta.154–159 conservés.
+- Skill personnel `sanctuary-session-notes` installé et validé séparément dans
+  `~/.codex/skills/` pour classer les dictées en Markdown. Il ne change pas le
+  modèle du tour courant ; Luna/low peut être choisi dans une tâche dédiée.
+
+Le serveur local utilise la base de développement du site, schéma v3 déjà présent,
+sous le même scope. Aucune validation de liaison de comptes hors ligne : cette
+opération reste réservée au mode authentifié. Aucun déploiement public, canal
+packwiz, serveur personnel ou instance Prism modifié.
+
+## Artefacts locaux
+
+- `mods/sanctuary/build/libs/sanctuary-beta.160.jar` — SHA-256
+  `4c19e620e989050488c9a96aaddaf897a74115a9fb4c5099e5518ae32db5b2e8`.
+- `build/Sanctuary-beta.160.mrpack` — SHA-256
+  `272e3460f35c8d9a4de689d30e4d952c3121923ba5fe30a23c83b3e76bd23bac`.
+- `build/duo/Jouer.command` et `Serveur.command` : raccourcis locaux de séance.
+

docs/east-crater-beta224.md

@@ -0,0 +1,84 @@
+# Est — cratère strié et arbres enracinés, beta.224
+
+## Contrat du 5 octobre 2026
+
+Retour après visite beta.223 : relief général, arbres et ravins appréciés.
+Arbres de jungle observés sur d’autres arbres ; cratère jugé trop camouflage.
+Conserver la géométrie et retravailler ses matériaux : lignes concentriques
+du fond vers le sommet, stries verticales/hachures qui s’estompent en hauteur,
+plus d’obsidienne, magma à proximité, transitions légèrement bruitées.
+Captures évoquées sans chemin fourni : aucune capture inspectée.
+Branche `codex/east-crater-beta224`, base `9063e16`.
+
+## Portée
+
+Nouveaux profils 224 uniquement. Le champ de densité, les hauteurs, ravins,
+cavités, lave et emplacements de monuments reprennent exactement 223 pour une
+même graine d’expansion. Habillage minéral de la surface et des sept blocs sous-jacents du
+cratère uniquement, sans nouvelle simulation ni passe de relief.
+Les grandes jungles utilisent les mêmes arbres avec un filtre de sol avant
+plantation, absent du placement custom 223. Tables natives de bambou, pandas
+et autres arbres conservées. Île principale, Nord, Sud et Ouest conservés.
+Anciennes sauvegardes et profils intacts ; essai dans un nouveau laboratoire.
+
+## Vérifications ciblées
+
+Java 25, Minecraft 26.3, Fabric Loader 0.19.5 et API 0.160.5+26.3.
+Sept GameTests réussis (`base204,east223,east224`) :
+
+- Conservation exacte des hauteurs, densités, cavités et volumes de lave entre
+  223 et 224 sur quatre graines d’expansion ; aucun déplacement des monuments.
+- Matériaux hors du traitement du cratère inchangés ; obsidienne plus abondante
+  et magma présent sur la rive découverte, pas seulement sous la lave.
+- Admission du grand arbre refusée sur feuilles, troncs, air et pierre ;
+  admise sur herbe, terre et podzol. Le tag natif `minecraft:dirt` de 26.3
+  ne contient ni herbe ni podzol : le filtre utilise les sols explicites et
+  la règle native de survie du jeune arbre, testés depuis le registre chargé.
+- Profils de création et anciens profils chargés, anciens contrôles Est 223
+  et conservation de l’Ouest validé.
+
+Deux serveurs natifs isolés à 2 Gio passent la demande par ancre, le refus du
+mauvais paiement, l’interruption/reprise et la préparation de 62 chunks.
+Même position et graine d’expansion qu’en 223 ; diamètres 1024 :
+
+| Graine monde | Centre X/Z | Graine expansion | Tronc maximal | Pieds suspendus détectés |
+| --- | --- | --- | --- | --- |
+| 42 | 944 / 144 | 207124680538740498 | 41 blocs | 0 |
+| 0 | 944 / -144 | 118376680751547919 | 44 blocs | 0 |
+
+La recherche de pieds suspendus porte sur 24 chunks par graine (huit par
+ambiance de jungle) : terre située plus de cinq blocs au-dessus du terrain
+avec un tronc dessus. Ce contrôle et le filtre de placement corrigent le cas
+identifié ; ils ne constituent pas une inspection exhaustive de tous les arbres.
+Les mêmes relevés comptent respectivement 840/1 565 bûches, 2 883/4 646 feuilles
+et 2 748/2 094 bambous. Deux coffres à butin et deux distributeurs dans chaque
+temple, relais complet, 919/957 colonnes de lave et 39 464/38 928 contrôles
+de parois sans fuite.
+
+Reçus ignorés : `build/east224-gametest-passed.log` et
+`build/worldgen-lab/east224-checked{42,0}/small/{42,0}/{cold,warm}.json`.
+
+## Livraison
+
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch
+-PsanctuaryFocusedTests=base204,east223,east224 -PsanctuaryAtlasOnly=true`
+réussit en 5 min 25 s. Log : `build/east224-build.log`.
+
+MRpack normal vérifié et copié dans `~/Downloads` : archive intègre, JAR exact,
+trois tailles, filtre de plantation et 371 ressources de génération historiques
+strictement identiques à beta.223 (hors alias public du preset). Aucun monde ni
+module de test embarqué. Reçu : `build/east224-mrpack-receipt.json`.
+SHA-256 de `Sanctuary-beta.224.mrpack` :
+
+```text
+01aed4e6a0d9e2965ed8201372eef3aaecab3b0c6dce3fb84586895ed9076885
+```
+
+La visite neuve `Sanctuary-East-224-42` est ouverte le 5 octobre à 17:26:25,
+Vulkan natif, rendu 32 chunks, simulation 5, créatif/vol/commandes. Position
+initiale 547 / 351 / 144, face au volcan. Copie du serveur de contrôle arrêté,
+identité de sources vérifiée ; anciennes visites conservées.
+
+Le rendu des stries reste à apprécier par le joueur. Pas de nouvelle campagne graphique Windows,
+ni d’exploration complète Medium/Large. Aucune modification d’ancien monde,
+publication de canal ou mise à jour Prism.

docs/east-volcano-beta223.md

@@ -0,0 +1,85 @@
+# Est — volcan flottant et jungles, beta.223
+
+## Contrat du 5 octobre 2026
+
+Après la livraison des déclinaisons de roche jaune (beta.222), le joueur valide
+l’Ouest 221 et demande le laboratoire Est. Volcan actif, lave dans le cratère,
+jungle sur les flancs ; la silhouette historique est explicitement rejetée.
+Il faut un vrai cône volcanique flottant, un temple de jungle, du bambou,
+des pandas et des jungles clairsemées ou denses avec de très grands arbres.
+Diamètre de premier essai : 1024 blocs, dans la direction de l’ancre Est.
+Branche `codex/east-volcano-beta223`, base `2d656d9`.
+
+## Portée
+
+Nouveaux profils 223 Small/Medium/Large uniquement ; aucun profil 222 de
+terrain n’existe (222 ajoutait uniquement des blocs). Île principale, Nord,
+Sud et Ouest conservent leurs générateurs validés. Les mondes et journaux
+historiques sont conservés. Nouveau laboratoire et nouvelle activation ;
+aucune expansion ajoutée à une sauvegarde personnelle.
+
+Silhouette conique asymétrique, bouche décentrée et légèrement elliptique,
+ravines ramifiées par bruit cohérent, épaulement ancien et affaissement local
+du bord du cratère. Répartition des jungles par nappes de bruit, sans secteurs
+radiaux répétés. Couronne sommitale irrégulière et cuvette de lave
+fermée, dessous suspendu irrégulier. Roche volcanique au sommet, sol végétal
+sur les flancs. Biomes de jungle et bambou avec végétation native, dont une
+variante de grands arbres. Temple natif avec pièges et coffres, fondations
+locales. Relais sur le flanc extérieur, éloigné du cratère.
+Pas d’éruption animée ni de simulation géologique/hydrologique globale.
+
+## Vérifications
+
+Le 5 octobre 2026, Java 25, Minecraft 26.3 et Fabric Loader 0.19.5 :
+
+- `./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch
+  -PsanctuaryFocusedTests=base204,east223,rock222 -PsanctuaryAtlasOnly=true`
+  réussit en 3 min 34 s. Sept GameTests ciblés passent également lors du contrôle
+  préalable : profils historiques et actuels, roche jaune, forme et lave sur
+  quatre graines, direction Est, égalité du relief et des décors Ouest 221/223.
+- Deux serveurs natifs isolés, graines 42 et 0, mémoire 2 Gio : demande par ancre,
+  refus du mauvais paiement, interruption à 0/62 chunks et reprise persistée.
+  Les deux expansions deviennent disponibles avec 62 chunks préparés ; la suite
+  est générée à l’exploration.
+- La cuvette est contrôlée dans les chunks réels : 919/957 colonnes de lave et
+  39 464/38 928 vérifications de parois pour 42/0. Aucun débouché vers le vide
+  détecté dans ces contrôles.
+- Chaque temple contient deux coffres à table de butin et deux distributeurs
+  piégés ; 1 157 blocs de maçonnerie relevés. Le relais possède ses 2 069 blocs
+  attendus et une offre utilisable.
+- Sur 24 chunks par graine, huit de chaque ambiance de jungle : 1 501/1 446
+  bûches, 3 747/4 398 feuilles, 2 689/2 294 bambous ; tronc continu maximal de
+  44 blocs sur les deux graines. Les tables natives du biome bambou comprennent
+  les pandas ; leur nombre réel n’est pas une assertion de cette campagne.
+- MRpack vérifié : ZIP, JAR exact, versions, trois tailles, profils historiques,
+  biomes Est, tables de pandas, grands arbres, temple et déclinaisons de roche
+  jaune ; aucun monde ni module de laboratoire embarqué.
+
+Les logs et reçus ignorés sont `build/east223-build-final.log`,
+`build/east223-natural-gametest.log`, `build/east223-mrpack-receipt.json` et
+`build/worldgen-lab/east223-checked{42,0}/small/{42,0}/{cold,warm}.json`.
+
+| Graine du monde | Centre de l’expansion X/Z | Graine de l’expansion | Temple X/Y/Z |
+| --- | --- | --- | --- |
+| 42 | 944 / 144 | 207124680538740498 | 835 / 271 / 418 |
+| 0 | 944 / -144 | 118376680751547919 | 961 / 300 / 150 |
+
+## Livraison et visite
+
+`Sanctuary-beta.223.mrpack`, copié dans `~/Downloads`, SHA-256 :
+
+```text
+ac31ff8203dca95265c7d0af545bab231697ad295b48eade2ee115090a9597e6
+```
+
+La visite neuve `Sanctuary-East-223-42` est ouverte le 5 octobre à 17:09:45,
+Vulkan natif, rendu 32 chunks, simulation 5, créatif/vol/commandes. Position
+initiale 547 / 351 / 144, face au volcan. Copie du laboratoire arrêté,
+identité de sources vérifiée ; les anciennes visites sont conservées.
+La roche jaune, ses escaliers et dalles de beta.222 sont inclus.
+
+Le rendu naturel reste à apprécier par le joueur : les contrôles numériques
+ne constituent pas une validation esthétique. Essais natifs Small sur deux
+graines ; Medium/Large sont assemblés et leurs profils vérifiés, sans nouvelle
+campagne d’exploration complète. Aucun essai Windows ni simulation d’éruption.
+Pas de publication du canal packwiz ni de mise à jour de l’instance Prism.

docs/ecosysteme-communaute-economie.md

@@ -0,0 +1,319 @@
+# Communauté, économie et aventures — cadrage du 25 septembre 2026
+
+Statut : **cadrage de conception**. La réalisation du premier prototype d'arène
+autorisé ensuite est suivie séparément dans [beta.167](horde-lab-beta167.md) ;
+elle ne vaut pas livraison de l'ensemble des systèmes décrits ici. Cette note
+conserve la discussion du créateur et distingue ses décisions des propositions
+à éprouver. Base : dernier `origin/main` vérifié, beta.166 (`7979f33`).
+Le créateur demande finalement une branche dédiée, puis une intégration sur
+`main` à ne pas oublier. Branche : `codex/communaute-economie-beta167`.
+La prochaine livraison de code visée est **beta.167** ; ce numéro est désormais
+préparé dans les métadonnées du prototype, sans publication. On avance par petits résultats
+jouables, sans figer maintenant toute l'économie.
+
+## Ce que l'on cherche à produire
+
+Un serveur semi-anarchique dont l'État assure une administration forte, trace
+les événements, régule les prix du marché et pose des frontières. Les joueurs
+peuvent chercher leurs propres moyens de les franchir. Le système doit susciter
+la coopération, la multiplication, la fabrication, la destruction et la recherche.
+L'objectif est une émulation collective, avec des conséquences dans le monde.
+
+Minecraft, le site et Discord prolongent la même vie communautaire. La BDD doit
+permettre d'analyser les activités à la journée et d'en rendre compte sur le site.
+Le serveur Minecraft conserve l'autorité sur les actions et récompenses de jeu.
+
+## Décisions et intentions exprimées par le créateur
+
+### Tableau et Gazette
+
+- Le tableau propose **une seule sorte de message général**, sans les quatre
+  catégories obligatoires actuelles. Annonce, demande, besoin, information,
+  rendez-vous et découverte sont des usages de ce même message.
+- La Gazette accueille les récits, photos et discussions durables ; le tableau
+  sert aux messages immédiats et à l'organisation. Les références Facebook et
+  Twitter expriment ces usages, pas une demande de reproduire leurs fonctions.
+- Un message peut être associé à une quête donnant de l'XP aux autres joueurs.
+  Une découverte peut être publiée pour organiser son exploration ensemble.
+  Tout message n'a pas à devenir une quête.
+
+### Quêtes canoniques, coopération et récompenses de prestige
+
+- Les panneaux émeraude, rubis et saphir testés avec de vrais joueurs conviennent
+  au gain d'XP solo, mais tendent à isoler les participants. Conserver un intérêt
+  solo tout en développant des raisons concrètes de coopérer.
+- Le tableau accessible dans un menu et ses quêtes proposées pour une durée
+  limitée sont une piste appréciée par le créateur.
+- Prévoir des quêtes canoniques reconnaissables, par exemple **chasse aux
+  zombies**, avec XP selon les objectifs accomplis, quotas et paliers de
+  récompenses. La référence aux passes de progression de jeux comme Rocket
+  League concerne cette progression visible ; aucun modèle payant n'est demandé.
+- Des quêtes difficiles à obtenir ou à accomplir peuvent donner des **capes et
+  familiers exclusifs**, recherchés pour leur valeur cosmétique et intrinsèque.
+  Nature de l'exclusivité, disponibilité et capacités des familiers restent à
+  préciser ; ne pas conclure que tous les familiers sont purement cosmétiques.
+- La discussion retient les deux usages dans une même quête : avancer seul
+  pendant sa partie normale et rejoindre une horde collective déclenchée par
+  bounty. Les zombies remplacent les squelettes comme première piste liée à
+  l'île abandonnée ; aucun scénario d'ossuaire n'est retenu.
+
+### Familiers comme incubateurs d'XP
+
+Idée ajoutée par le créateur : les familiers **multiplient leur XP stockée au
+fil des blocs parcourus à pied, posés et cassés**. Ils servent d'**incubateurs
+d'XP**, avec une croissance modérée pour éviter un système trop puissant.
+Ce mécanisme peut donner un rôle aux familiers dans les quêtes.
+
+« Multiplier » décrit ici l'intention de faire fructifier la réserve ; aucune
+formule, croissance exponentielle par action, valeur de rendement ou limite
+n'est décidée. L'origine de l'XP déposée, sa récupération et les conditions de
+présence du familier restent à choisir, ainsi que la personne dont les actions
+comptent. Cette idée est à concevoir, pas une nouvelle capacité livrée.
+
+### État, navets et loterie
+
+- L'État joue à la fois un rôle d'arbitre et d'acteur du monde. Ses contraintes
+  doivent donner des occasions de jouer et de s'organiser.
+- Les navets s'achètent auprès d'un **PNJ le dimanche**. Ils se revendent pendant
+  la semaine et **pourrissent après une semaine s'ils ne sont pas vendus**.
+  Il ne s'agit pas d'une culture récoltée par les joueurs.
+- Des tickets trouvés ou achetés pendant la semaine servent à la loterie du
+  dimanche, avec de **vraies machines manipulant des stocks d'objets**.
+- Ces machines peuvent notamment dupliquer ou diviser un stock. Les propositions
+  précédentes de simples permis et réductions ne définissent pas ce mécanisme.
+  Les privilèges temporaires restent une idée initiale possible, sans catalogue
+  de récompenses approuvé.
+- Le rapport entre ces opérations et le **ballast des Backrooms** doit être
+  pensé dès leur conception.
+
+### Bounties, cartes et extensions
+
+- Les bounties sont des **objets collectionnables que l'on utilise quand on est
+  prêt**. Elles peuvent être offertes comme occasions d'aventure.
+- Réutiliser le système de cartes et en créer à la volée pour ces aventures.
+  La forme exacte de la carte et son geste d'activation restent à choisir.
+- Prévoir **huit structures** permettant d'étendre les huit extensions de l'île
+  principale, en lien avec un **bloc originel sur l'île**, puis des **ancres**
+  permettant de générer des structures d'aventure.
+- Les objectifs évoqués comprennent primes, objets clés à retrouver et
+  structures à détruire. L'ensemble doit aussi permettre la contrebande
+  organisée et les initiatives des joueurs.
+- L'ordre de déblocage entre structures, extensions et bloc originel n'est pas
+  encore fixé. Ne pas transformer cette intention en règle « huit sur huit ».
+
+### Familles d'objets retenues et prochaine scène du labo
+
+Le créateur retient le tableau fonctionnel suivant :
+
+| Famille | Fonction |
+| --- | --- |
+| **Carte de découverte** | Indiquer un lieu existant à explorer ; transmettre une information. |
+| **Carte d'épreuve** | Déclencher une activité à l'activation : horde, défense, recherche… |
+| **Clé ou relique** | Ouvrir un accès ou activer un mécanisme précis dans le monde. |
+
+Piste accessoire ajoutée : des **cartes collectionnables générées par le jeu**.
+Leur sujet, leur présentation, leur rareté et leur éventuel lien avec les cartes
+fonctionnelles restent ouverts. Ne pas leur attribuer automatiquement un pouvoir
+ou une récompense : collection et activation sont deux usages à distinguer.
+
+La prochaine scène à **imaginer dans le laboratoire** est une **arène ronde
+avec un nouveau bloc interactif au centre**. La carte de horde est la première
+carte d'épreuve envisagée : elle fait apparaître un groupe de monstres par vagues.
+Le nom, l'apparence, les dimensions et les règles du bloc restent à concevoir.
+Cette décision portait initialement sur la conception. Le créateur a ensuite
+autorisé un premier essai jouable ; son état réel est dans le
+[contrat du prototype](horde-lab-beta167.md).
+
+Parcours proposé pour ce prototype : présenter une carte au bloc → lire l'épreuve
+et ses récompenses → rejoindre le groupe → lancer explicitement → affronter les
+vagues → consulter le résultat. Une activation au clic droit, des apparitions
+réparties au bord du cercle et un état visuel du bloc sont des propositions.
+La consommation de carte, l'engagement des participants, les arrivées tardives,
+la défaite, la déconnexion et les récompenses seront précisés avant le code.
+
+Le laboratoire doit utiliser une scène de développement neuve et isolée ; ne pas
+réécrire le monde du labo déjà conservé ni une sauvegarde personnelle. La forme
+transportable d'une balise d'épreuve reste une possibilité ultérieure. Ce bloc
+d'arène n'est pas encore assimilé au bloc originel ou à une ancre d'expansion.
+
+### Données et liens entre les services
+
+- Intégrer les statistiques du jeu à la BDD quand elles sont disponibles et
+  raccorder progressivement les systèmes déjà en place.
+- Viser la traçabilité des échanges et événements, les analyses quotidiennes et
+  les comptes rendus sur le site.
+- Exploiter le lien d'identité Discord/site/Minecraft pour de futures interactions
+  personnelles, dont les notifications. Leur contenu et leur fréquence restent
+  à définir ; cette discussion n'autorise aucun envoi de message.
+
+## Ce qui existe réellement sur le socle beta.166
+
+| Socle vérifié dans les sources et contrats | Limite actuelle |
+| --- | --- |
+| Gazette, photos, réponses, tableau, abonnements et repères de demandes ; stockage fichier ou MariaDB partagé | Quatre catégories `info/work/need/event` ; matériaux et récompenses descriptifs, sans livraison ni XP automatique |
+| Compteurs serveur publiés en base toutes les 30 secondes | Dernier instantané : durée de fonctionnement, morts, joueurs connectés, état ; pas un historique individuel quotidien complet |
+| Activité matérielle locale datée du Blocodex : minage, pose, fabrication, ramassage et jet | Agrégats journaliers sans distinction par joueur ou dimension ; ne prouvent ni échange, ni stock, ni ballast |
+| Cartes au trésor physiques et import de leurs repères dans l'atlas | Destinations provenant de plans existants ; aucun moteur de bounty activable ni de génération d'aventure à la demande |
+| Génération d'expansions et quatre anciennes expéditions ouvertes | Les huit nouveaux déblocages, le bloc originel et les ancres restent à concevoir |
+| Inscription web et reprise des codes d'accès ; lien aux identités Discord | Pas de service de notifications personnelles livré par ce chantier ; le dernier contrat conserve une validation OAuth réelle à terminer |
+
+Références : [communauté](community-contract-v1.md),
+[compteurs beta.161](session-fixes-beta161.md),
+[activité datée](blocodex.md#relevés-datés--portée-de-lalpha23),
+[cartes beta.059](atlas-markers-beta059.md), [expansions](expansion.md),
+[inscription beta.166](inscription-web-beta166.md).
+Cet état décrit le dépôt, pas une vérification du déploiement public.
+
+## Propositions de fonctionnement à valider
+
+Pour les quêtes canoniques, la proposition discutée associe des **paliers
+personnels à un effort collectif**. Émeraude pourrait accueillir les contrats
+accessibles, rubis les opérations coordonnées, saphir les aventures rares et
+exigeantes. Cette répartition n'est pas une règle arrêtée.
+
+Premier essai désormais envisagé : une chasse aux zombies avec paliers d'XP
+personnels, à laquelle contribue aussi une horde collective activée par carte.
+Une jauge commune et des préparatifs restent des options, sans scénario imposé.
+Les nombres 10/30 cités pendant la discussion sont illustratifs. Participation
+au-delà du dernier coup et conditions de maîtrise pour les trophées restent à définir.
+Un carnet pourrait présenter les objectifs et gains ; l'échéance de l'offre et
+le moment d'activation d'une bounty obtenue seraient distincts.
+
+L'incubation d'XP pourrait accompagner ces parcours d'exploration, de construction
+et de minage. Avant tout essai, proposer puis mesurer un rendement et un plafond,
+en examinant les trajets répétitifs, les boucles pose/casse et le cumul de
+familiers. Ce sont des points d'équilibrage à décider, sans taux ni interdiction
+déjà validés. Toute future variation de réserve doit pouvoir être expliquée par
+les actions serveur enregistrées et rester cohérente avec les récompenses de quête.
+
+Le message général pourrait recevoir des éléments facultatifs : lieu, rendez-vous,
+objectif et récompense. Le tableau rassemble les participants ; la Gazette garde
+le récit. La bounty peut être liée à une publication sans que poster un message
+crée automatiquement une aventure.
+
+Parcours proposé : obtenir une carte → la conserver ou l'échanger → réunir un
+groupe → l'activer → accomplir l'objectif → recevoir la récompense. Conserver
+ensuite une carte souvenir portant le résultat et les participants est une option.
+Échangeabilité, perte, vol, copie et consommation de l'objet restent à décider.
+
+Deux usages possibles des cartes : révéler un lieu existant, ou préparer une
+nouvelle aventure à l'activation dans une ancre. Une copie cartographique pourrait
+partager les indications sans multiplier les droits à récompense. Ce n'est pas
+encore un contrat implémenté. Les Backrooms conservent leur intention spécifique
+de découverte sans coordonnées ni carte automatique.
+
+Exemple de machine, **sans valeur d'équilibrage approuvée** : un ticket et
+64 lingots engagés donnent 128 ou 32 lingots. Probabilités, stocks admissibles,
+fréquence, financement et comportement des objets uniques sont à définir.
+Conserver l'échéance d'origine des navets lors d'un transfert ou d'une duplication
+est proposé pour que ces opérations ne rajeunissent pas les lots.
+
+Pour le ballast, une perte pourrait laisser un dépôt, une duplication une trace
+architecturale ou une anomalie. Aucune équivalence quantitative n'est décidée.
+Le [contrat cosmologique](cosmologie.md#le-ballast-de-léconomie) reste ouvert sur
+matière retirée, empreinte ou combinaison des deux. Une trace ne donne pas à elle
+seule le droit de créer des objets récupérables.
+
+Boucle envisagée : **production et échanges → machine → ballast → lieu à
+explorer → bounty → expédition → trouvailles et nouveaux échanges**.
+Le lien automatique entre chaque étape est une proposition à éprouver.
+
+## Ordre de travail proposé
+
+**Dernière orientation : cadrer d'abord la scène d'arène ronde du labo et son
+bloc central**, pour rendre la carte d'épreuve concrète. Le tableau ci-dessous
+conserve les dépendances générales ; son ordre initial n'impose pas de terminer
+la BDD ou la simplification du tableau avant de concevoir cette scène.
+
+| Étape | Résultat concret à obtenir | Ce qui doit être précisé juste avant |
+| --- | --- | --- |
+| 1. Simplifier le tableau | Publier et lire un message général en jeu et sur le site, retrouver les anciennes annonces et leurs suivis | Présentation des champs facultatifs ; compatibilité des anciennes catégories sans effacer l'historique |
+| 2. Observer l'existant | Produire un premier compte rendu quotidien depuis des données serveur réelles en BDD | Périmètre des statistiques, unités, identité joueur/monde, jours, visibilité et reprise après panne |
+| 3. Jouer une première bounty | Obtenir une carte, la garder, l'activer et terminer un objectif vérifié par le serveur, avec une seule attribution de récompense | Un objectif simple, par exemple une livraison ; rôle du groupe, financement et nature de l'XP |
+| 4. Éprouver l'économie du dimanche | Un PNJ vend des navets qui vieillissent ; une machine engage un stock et rend son résultat, chaque opération étant tracée | Cours et revente, échéance exacte, tickets, hasard et conversion en ballast |
+| 5. Relier les aventures au territoire | Définir les huit structures, puis éprouver une première activation et une expédition par ancre avant de décliner les huit | Articulation avec les quatre anciennes régions, emplacement, coûts, graine/version et protection des terrains existants |
+| 6. Faire vivre les prolongements | Alimenter les nouvelles régions des Backrooms avec le ballast validé ; ouvrir les notifications choisies et les récits du site | Contrat de ballast livré avant BR-01 ; règles de publication et préférences Discord |
+
+Cet ordre est une proposition de départ, pas six grosses livraisons promises.
+Chaque étape peut être divisée selon les essais. Les rapports du site commencent
+à l'étape 2 ; les Backrooms et notifications sont des suites distinctes.
+Les nouveaux systèmes produisent leurs événements dès leur première livraison.
+Le premier parcours bounty peut utiliser un objectif existant sans attendre la
+génération des huit structures.
+
+## Points à trancher au fil de ces premières étapes
+
+1. **Récompenses** : quelle XP, payée par qui, attribuée à qui dans un groupe,
+   pour quelle preuve d'accomplissement ?
+2. **Bounties** : carte physique liée à l'atlas ou autre présentation ; échange,
+   copie, vol, perte, activation, abandon, échec et souvenir ?
+3. **Navets** : sept jours après achat ou échéance hebdomadaire commune ; horloge
+   pendant les arrêts, cours de revente et devenir des navets pourris ?
+4. **Machines et ballast** : quels stocks, probabilités et résultats ; quelle
+   part est une trace, une perte ou une matière récupérable ?
+5. **Territoire** : emplacement des huit structures, ordre d'ouverture et rôle
+   du bloc originel ; frontières franchissables par quels moyens de jeu ?
+6. **Information** : ce que l'administration technique enregistre, ce que l'État
+   sait dans la fiction, ce que le public voit et ce que Discord signale ?
+7. **Incubateurs d'XP** : dépôt initial, actions reconnues, croissance et plafond,
+   familier porté ou présent, cumul, transfert/retrait et articulation avec les
+   quêtes ? L'XP incubée et les récompenses directement attribuées doivent être
+   distinguées pour éviter un double compte.
+
+Ces distinctions doivent laisser exister secrets, découverte et contrebande.
+Un objet ramassé après un jet n'est pas automatiquement une vente. Les compteurs
+cumulés historiques ne permettent pas de reconstruire les journées antérieures.
+Une période non observée doit rester identifiable, sans inventer des zéros.
+
+## Conditions de réalisation
+
+Avant des écritures réelles : contrat de données additif, événements identifiés
+et datés, reprise sans double récompense ni double consommation, comportement
+explicite en cas de panne et séparation entre résultat tenté et résultat acquis.
+La BDD sert les analyses sans imposer des requêtes bloquantes au thread de jeu.
+Les frontières, prix, récompenses et pertes sont des règles serveur.
+
+Aucune modification de monde, migration, régénération ou activation d'expansion
+n'est autorisée par cette note. Leurs futurs contrats doivent préserver les
+sauvegardes et secteurs existants. L'évolution des anciens contenus communautaires
+devra également être explicitée avant de changer leur stockage.
+
+La première passe était documentaire. La réalisation autorisée ensuite porte
+uniquement sur le laboratoire de horde, selon son contrat propre. Les autres
+systèmes décrits comme futurs le restent.
+
+### Retour sur main et prochaine version
+
+- **À faire avant livraison : intégrer le travail validé sur `main`**, vérifier
+  le résultat après intégration et reprendre le travail depuis cette base.
+- Le premier périmètre proposé était la simplification du tableau. La discussion
+  se concentre maintenant sur la conception de l'arène du labo et du bloc central ;
+  le périmètre de code de beta.167 est maintenant le prototype de horde du labo.
+  L'ensemble de cette feuille
+  de route n'est pas promis dans une seule version.
+- À la première livraison de code, revérifier le compteur disponible, synchroniser
+  `mod_version`, `pack_version` et `packwiz/pack.toml`, puis exécuter les contrôles
+  requis. Le prototype prépare désormais ces trois valeurs à beta.167.
+- Aucun tag, push, artefact public, canal packwiz ou déploiement personnel n'est
+  effectué par cette prise de notes.
+
+## Ajustement du 26 septembre — cartes de horde
+
+La carte est consommable et invoque immédiatement des vagues là où on se trouve.
+Aucune inscription : on participe spontanément en arrivant sur le combat.
+Les monstres portent les butins spéciaux, ramassés librement par les joueurs.
+Chaque carte possède une illustration mappifiée (monstres, textures des butins),
+une identité et une difficulté lisible. Le décor circulaire reste une piste
+pour les futurs donjons. [Premier labo à trois cartes](horde-cartes-beta168.md).
+
+## Retour de combat du 26 septembre — familiers et horde
+
+Le créateur constate que les familiers ne sont pas utiles au combat : prévoir
+une refonte de leur contribution, à évaluer en combat réel contre une horde.
+Ce constat ne prouve pas une panne technique ; diagnostic des comportements,
+rôles et lisibilité encore à faire. Aucune refonte des familiers livrée dans ce lot.
+
+Les [cartes beta.169](horde-invasion-beta169.md) restent inconnues avant leur
+prise en main. Elles ouvrent une invasion continue de monstres variés, dont la
+cadence accélère, avec butins propres aux espèces, rubis et saphirs. Apparition et
+mort réelle utilisent les runes SGA et les particules natives Minecraft.

docs/eroded-massif-beta192.md

@@ -0,0 +1,85 @@
+# WG-ERODED-192 — couronnes et faces du massif
+
+Branche `codex/eroded-massif-beta192`, Minecraft 26.3, graine de visite 42.
+Profil `eroded`, preset neuf `sanctuary_test:eroded_massif_v1`.
+
+## Retour et résultat attendu
+
+Après la restauration beta.191, les captures du 30 septembre à 22:02–22:05
+montrent des marches de terre et d’herbe sur les sommets arrondis. Le créateur
+souhaite de vrais changements de forme : quelques dessus plus plats sous les
+arbres, des faces plus franches, des creux d’érosion et des pentes conservées.
+Ne pas reproduire les terrasses périodiques 189 ou simplement peindre la roche.
+
+## Variante
+
+Trois couronnes sont choisies dans les points hauts du massif existant. Leur
+altitude dépend du terrain original. Les trois cerisiers réservés occupent ces
+couronnes, avec exclusion des points de plantation encore trop raides. Une coupe légèrement inclinée rabote le
+sommet ; une face plus raide regarde son versant descendant. Les empreintes
+ont des limites adoucies et irrégulières ; les petites entailles entre couronnes
+s’appuient sur la distance aux deux centres de Voronoï les plus proches.
+Les coupes retirent au plus 24 blocs du plafond géométrique local. Une cavité
+préexistante découverte par la coupe peut donner un sol visible plus bas.
+
+C’est une érosion géométrique locale sur le bruit 3D existant, sans simulation
+physique. Pas de grille de niveaux Y, de remplissage des cavités ni de lissage
+global. Aucun changement de densité à Y≤240, dans les îlots aériens ou hors du
+massif central. Les formes originales restent la base sous le plafond sculpté.
+
+La couverture végétale du massif n’est posée que sur les surfaces capables de
+la porter : les fortes pentes gardent la géologie réelle (stone, gisements,
+strates). Le gradient est mesuré sur des colonnes du massif en coordonnées
+monde, traversant les limites des chunks et ignorant les îlots aériens. Les
+hauteurs et pentes sont mises en cache dans un domaine borné. Cette variante
+n’utilise pas le solveur d’hydrologie ; les étangs et déversoirs existants restent
+responsables de l’eau.
+
+Ancres, donjon, gemmes, soufre, ruines à coffres, galerie, rosace et palais sont
+conservés. La règle de roche historique garde son comportement lorsque son
+nouveau champ optionnel `slope` est absent. Les anciens presets gardent leurs
+paramètres ; aucun monde existant n’est modifié ou régénéré.
+
+## Vérifications et limites
+
+Génération native finale et réouverture réussies, graine 42 :
+`build/eroded192e-cold.json` et `build/eroded192e-warm.json`.
+Les hauteurs mesurées sont identiques après rechargement ; les trois troncs
+sont relus dans les chunks sauvegardés.
+
+- 1 008 colonnes modifiées dans le relevé espacé de deux blocs ; 392 échantillons
+  de sommet peu pentus. Trois couronnes et trois cerisiers contrôlés en blocs réels.
+- 39 366 densités profondes et aériennes identiques à la base ; comparaison
+  supplémentaire hors du massif. Aucun niveau Y périodique réintroduit.
+- 1 545 échantillons rocheux contre 8 de terre/herbe parmi les fortes pentes
+  contrôlées. Les plantations trouvent un sol de pente ≤0,75 dans leur chunk.
+- Ancres, 49 cartes/cadres, rosaces, galerie, quatre coffres de ruines, donjon,
+  gemmes, soufre et étangs contrôlés. Cascade large et absence d’arbres dans
+  les colonnes d’eau et de berge contrôlées conservées.
+
+Démarrage final : 12,126 s à froid et 0,613 s à chaud, zéro région d’hydrologie ;
+83,610 s à froid et 18,501 s à chaud avec
+l’ensemble des contrôles et le remplissage de l’atlas. Ces contrôles ne tournent
+pas au lancement du solo. Les mesures intermédiaires pendant la compilation
+concurrente ne servent pas de référence de performance.
+
+`./gradlew check build assemblePack assembleTestPack` réussi en 9 min 9 s,
+265 GameTests réussis. Après ajustement du placement des cerisiers et de son
+contrôle de réouverture, `:sanctuary-test:check :sanctuary-test:build` réussi et
+pack de test réassemblé : 175 classes et 121 ressources vérifiées dans le JAR,
+identique à sa copie distribuée (`build/eroded192-pack-receipt.json`).
+
+La validation technique ne vaut pas validation esthétique du créateur. Cette
+itération vise le massif central de la graine de visite ; elle ne remodèle pas
+les récifs aériens. Pas de publication ni de mise à jour de l’installation Prism.
+
+## Visite
+
+Nouveau solo `Sanctuary-Eroded-Massif-192-Solo`, run `visite192`, profil `eroded`,
+graine 42, vue 32 et simulation 12, spectateur et commandes autorisées.
+Position préparée (94,316,153), face au massif. Les 49 cartes et cadres ainsi
+que les huit ancres éteintes et l’origine sans relais ont été relus dans cette
+copie neuve. Options et shader repris du solo 191, fermé et sauvegardé à 22:14.
+Client Vulkan lancé et entrée dans le monde confirmée à 22:34 ; vue 32,
+simulation 12 et visibilité de l’ascension contrôlées dans
+`build/eroded192-solo.log`.

docs/expeditions-beta002.md

@@ -29,6 +29,11 @@ et ses règles restent versionnées pour éviter de déplacer un site au recharg
 
 ## Placement des temples
 
+**Évolution beta.097** : le refus bloquant décrit dans cette version historique
+est remplacé par une recherche de secours, puis un placement garanti des pièces
+vanilla avec fondation si nécessaire. Les sites historiques admissibles restent
+prioritaires. Voir le [contrat du correctif](temple-crash-beta097.md).
+
 Les candidats sont des chunks de l’intérieur de chaque île, à au moins 48 blocs
 de son centre, ordonnés par un tirage déterministe. La recherche filtre le type
 voulu, puis conserve les conditions natives de biome, de pente et de fondation.

docs/exploration-familiers-beta100.md

@@ -0,0 +1,85 @@
+# beta.100 — Statues découvertes et promenade des familiers
+
+Branche `codex/exploration-familiers-beta100`. Minecraft 26.3.
+
+## Contrat
+
+Le catalogue des statues et son sélecteur ne proposent que les espèces
+observées, tuées ou ayant tué le joueur. Le Métabli envoie une liste calculée
+par le serveur à partir des notes `seen_mobs` et des statistiques natives.
+Le champ d’identifiant et la capture de cible respectent aussi cette liste.
+Les plans déjà construits/importés restent des plans de blocs ordinaires.
+Aucun nouveau format de sauvegarde, aucune migration ni changement de terrain.
+
+Les familiers au repos choisissent une destination atteignable puis font une
+pause. Le tempérament existant règle leur rayon, leur allure et leurs pauses :
+curieux explorateur, joueur plus vif, calme plus posé. Les protecteurs restent
+près du point gardé. Les déplacements d’attaque, la fuite, les ordres, le portage
+et les montures gardent la priorité. Les volants ne suivent plus une orbite
+perpétuellement recalculée. Les chemins ratés sont abandonnés et les recherches
+restent bornées dans les chunks chargés. Les identités et caractères existants
+ne sont pas retirés au sort.
+
+## Validation
+
+`Exploration100ClientChecks` : **réussi en 4 min 37 s**. Nouveau monde plat
+avec serveur intégré, sans serveur dédié :
+
+- Une vache réellement visée débloque sa statue. Les statistiques natives
+  tué/par-qui-tué ajoutent zombie et squelette. Un œuf de cochon porté ne suffit
+  pas. Le client reçoit la liste du serveur ; une génération de cochon reste
+  refusée même en créatif. Capture du catalogue inspectée.
+- Douze promenades réelles : loup, poule, slime, chauve-souris, chacun calme,
+  curieux et joueur. Plusieurs cases traversées, pauses, maintien près du joueur.
+  Le tempérament calme est testé avec personnalité protectrice, les deux autres
+  avec pacifiste pour isoler le déplacement au repos.
+- Régression `Autonomy074ClientChecks` complète : quatre personnalités,
+  déplacements et dégâts réels, garde, cibles neutres, permissions, obstacles,
+  mode travail, ordres H bref/maintenu et touche reconfigurée.
+- `.schem` Sponge v2/v3 : renommage natif ancien `grass` vers `short_grass`,
+  conservation exacte du fichier source et refus explicite d’un bloc de mod absent.
+
+Journal : `build/exploration100-client.log`. Captures :
+`build/exploration100-evidence/`. La matrice ne constitue pas un nouveau playtest
+visuel de toutes les espèces, ni une validation à plusieurs clients distants.
+`Schematics100ClientChecks` : **réussi en 1 min 2 s**. Le client refuse un
+fichier incompatible dans le Métabli sans fermer le menu, affiche son identifiant
+fautif, puis importe un `.schem` valide. Fermeture, réouverture de la même
+sauvegarde et ouverture d’un deuxième monde passent, avec conservation de la
+structure et remise à zéro du plan/de la session d’atelier. Le fichier rejeté
+reste identique. Journal : `build/schematics100-client.log`.
+
+Ces essais macOS ne reproduisent pas le crash Windows rapporté ; ils ne
+constituent pas une correction démontrée de cet incident. `check build assemblePack assembleTestPack` réussit en **2 min 17 s**,
+124 tâches, avec `-x :sanctuary:runGameTest` (serveur dédié exclu conformément
+au refus de son EULA). Les deux packs sont vérifiés : même JAR testé, sources
+correspondantes, libellés FR/EN, textures et archives beta.099 conservées.
+Reçu : `build/beta100-artifact.json`. Aucun déploiement personnel ni publication
+du canal packwiz.
+
+## Import `.schem` et incident Windows signalé
+
+Les palettes Sponge v2/v3 utilisent maintenant le convertisseur natif
+`References.BLOCK_STATE` quand leur `DataVersion` est connue et antérieure.
+Seule une copie de palette en mémoire est convertie ; le fichier importé et
+les sauvegardes ne sont jamais réécrits par cette opération. Une version
+future, un bloc de mod absent ou une propriété réellement incompatible restent
+refusés. Sans version source, le parseur reste strict et ne devine pas une
+conversion. Le message d’import indique le bloc/état fautif.
+
+Le signalement Windows décrit un échec d’ouverture, un monde absent de la liste
+puis une fermeture du client lors du choix d’un autre monde. Aucun journal ni
+fichier précis n’est disponible. L’inspection ne trouve aucun accès de suppression
+des mondes dans l’importeur ; les plans actifs sont effacés en mémoire lors des
+changements de connexion. Cela ne prouve pas la cause du signalement : sa
+reproduction et le diagnostic Windows restent ouverts. Les fichiers utiles sont
+`logs/latest.log` et, s’il existe, le rapport daté de `crash-reports/` dans le
+dossier Minecraft de l’instance concernée. Ne pas supprimer ni convertir les
+sauvegardes pour tenter de résoudre cet incident.
+
+## Archives locales
+
+- [Sanctuary-beta.100.mrpack](../build/Sanctuary-beta.100.mrpack), 9914561 octets.
+  SHA-256 : `7e24ba5e77c7fbb88cfadb55b3e373ad7e998381fd1c56e431aa79b4619a8075`.
+- [Sanctuary-Test-beta.100.mrpack](../build/Sanctuary-Test-beta.100.mrpack), 9933483 octets.
+  SHA-256 : `a43bf61dc38c3c91f4cb09022040099ee1ca9274a6b00751178c80ee204dd944`.

docs/familiar-autonomy-beta074.md

@@ -0,0 +1,98 @@
+# beta.074 — autonomie et ordres des familiers
+
+Branche `codex/familiar-autonomy-beta074`. Implémentation et parcours client natif vérifiés.
+
+## Comportements
+
+| Personnalité | Décision autonome |
+| --- | --- |
+| Agressif | Engage les monstres qu’il voit à 12 blocs du joueur, accompagne ses attaques et riposte. |
+| Protecteur | Garde 6 blocs autour du joueur, intercepte en priorité les monstres qui le ciblent, défend le joueur et lui-même. Abandonne la poursuite au-delà de 10 blocs du point gardé. |
+| Passif | N’engage pas de combat spontanément ; défend le joueur attaqué et riposte s’il est frappé. |
+| Pacifiste | Évite le combat et s’écarte d’un agresseur. Attend un ordre d’attaque ou de garde. |
+
+La vue est celle du familier : son propriétaire n’a pas besoin de voir le
+monstre ou de le viser. Les animaux paisibles, les monstres neutres non engagés,
+les alliés et les autres joueurs ne sont pas attaqués par la détection de
+proximité. La riposte PvP et les ordres conservent les permissions du monde,
+les factions et les règles des duels/arènes.
+
+Un ordre d’attaque prime sur la personnalité et les autres menaces. « Protéger »
+ordonne explicitement de garder un allié visé, soi-même par défaut, ou le point
+visé en maintenant Maj. Même un pacifiste peut exécuter cette garde demandée.
+Pendant une poursuite spontanée, le protecteur peut changer de cible pour
+intercepter une menace qui commence à viser son joueur ou l’allié gardé.
+Une cible morte laisse place à une nouvelle décision, au plus tard lors du
+prochain balayage. Le protecteur revient près de son point de garde.
+Les espèces de soutien disposent du coup de défense lorsqu’elles s’engagent ;
+leurs signatures, leurs dégâts existants et leurs coûts en fournitures restent inchangés.
+
+## Commandes
+
+H bref : attaquer l’ennemi visé, ou revenir au suivi s’il n’y a pas de cible.
+H maintenu environ 0,4 seconde : ouvrir le menu d’ordres. La touche reste
+configurable ; F échange les mains, G déclenche la technique. Relâcher après
+l’ouverture du menu ne lance pas d’attaque. Les messages brefs confirment
+l’ordre. « Suivre » suspend les réactions spontanées pendant cinq secondes.
+
+## Exécution et conservation
+
+Une recherche d’entités chargées par seconde, décalée entre les familiers.
+Aucun chargement de chunk ; chemins demandés au maximum toutes les dix ticks.
+Une cible autonome perdue de vue cinq secondes, ou sans progression six
+secondes, est écartée temporairement pendant dix secondes. Les commandes
+explicites peuvent la désigner de nouveau. Les montures, familiers portés,
+œufs rappelés et mode travail n’entament pas de recherche autonome.
+
+Le tirage de personnalité, les UUID, les 88 profils, la santé, l’XP et les
+souvenirs sont conservés. Aucun format de sauvegarde, terrain ni journal de
+mise ne change. Les règles de combat des arènes restent prioritaires.
+Textures beta.070, Minecraft 26.3-pre-2 et dépendances identiques.
+
+## Vérifications
+
+Le parcours `Autonomy074ClientChecks` réussit en **1 min 44 s** avec un
+client et son serveur intégré, dans un nouveau monde plat de développement :
+
+- Les quatre personnalités : recherche à 12/6 blocs, attaque du propriétaire,
+  dégâts réellement reçus par le joueur et déplacement jusqu’à la cible.
+- Protecteur villageois : interruption d’une poursuite pour une menace visant
+  le joueur, dégâts sans bouclier, cible suivante et retour dans la zone.
+- Abeille neutre paisible puis agressive, garde explicitement demandée à un
+  pacifiste et priorité d’une cible ordonnée.
+- Vue propre au familier, obstacle opaque, cible enfermée, permissions,
+  mode travail, suspension puis reprise après Suivre.
+- Événements clavier natifs : H bref/maintenu, reconfiguration sur Y,
+  absence d’attaque au relâchement du menu, F natif ; fiches FR/EN.
+
+La régression `Familiar071ClientChecks` réussit en **1 min 50 s** :
+352 000 identités sur les 88 profils, réactions, dégâts, araignées montées,
+Strider sur lave et les deux Nautilus aux tailles 2 500 et 6 000 ‰.
+La fermeture/réouverture du monde conserve l’UUID et le caractère.
+
+Journaux : `build/autonomy074-client.log`, `build/autonomy074-mounts.log`.
+Captures de la fiche actuelle et des montures : `build/autonomy074-evidence/`.
+`Arena073ClientChecks` et la régression `Duel054Checks` passent en
+**1 min 10 s** : arènes de familiers/joueurs/mixtes, 25 inscrits simulés,
+consentement PvP, K.-O., morts réelles, mises, remboursements et récupération
+après interruption. Journal : `build/autonomy074-arenas.log`.
+`check build assemblePack assembleTestPack` réussit en **3 min 6 s**
+(124 tâches). Les deux exports packwiz sont vérifiés : **1 689 classes**
+comparées au JAR, sources testées identiques, huit libellés FR/EN mis à jour,
+ressources et textures beta.070 intactes. Seules les quatre classes sources
+prévues changent par rapport à beta.073. Les neuf archives précédentes
+beta.070 à beta.073 restent strictement identiques.
+Reçu : `build/autonomy074-artifact.json`.
+
+Ces essais couvrent l’IA commune ; ils ne constituent pas un nouveau playtest
+des 88 techniques ni un test à plusieurs clients distants. Le serveur dédié
+reste exclu (`-x :sanctuary:runGameTest`) conformément au refus d’accepter
+son EULA ; les essais natifs utilisent le serveur intégré.
+Aucun monde personnel ni déploiement Prism.
+
+## Archives locales
+
+- [Sanctuary-beta.074.mrpack](../build/Sanctuary-beta.074.mrpack), 9595113 octets.
+  SHA-256 : `cc73e93c2ae17d6b52b6c8dd53639771645c5e5becd848e2c76765e32c919c5d`.
+- [Sanctuary-Test-beta.074.mrpack](../build/Sanctuary-Test-beta.074.mrpack), 9614048 octets.
+  SHA-256 : `0851e10350788b76efa96ec1a50db951a74200213399e2a4216f8d5b1b8fafcb`.

docs/familiar-controls-beta067.md

@@ -0,0 +1,80 @@
+# beta.067 — touche du familier et dragon volant
+
+Branche `codex/familiar-controls-beta067`.
+
+## Contrat
+
+La touche des ordres du familier passe de H à F. La touche G de technique
+reste indépendante. Le réglage H hérité est déplacé une seule fois vers F
+au démarrage ; les autres touches personnalisées restent conservées. Un
+marqueur local `config/sanctuary-familiar-key-v1.txt` permet ensuite de choisir
+à nouveau H sans être remappé au démarrage suivant. L'action reste configurable.
+
+Pendant le jeu Sanctuary, ouvrir les ordres avec F ne déclenche plus l'échange
+des objets des deux mains. Le raccourci natif garde son comportement dans les
+inventaires et hors Sanctuary ; réassigner les ordres libère également F.
+
+Le modèle natif du dragon utilise un axe avant opposé aux modèles vivants
+ordinaires. Son historique de vol reçoit cette correction d'orientation ;
+la direction physique du familier et des attaques reste inchangée.
+
+Le petit dragon porté utilise le planeur existant : descente bornée à
+0,12 bloc par tick, distance de chute accumulée effacée. Le grand dragon porté
+(taille existante > 1 200 et < 2 500 millièmes) permet une montée maintenue avec
+la touche de saut, bornée à 0,18 bloc par tick. Relâcher reprend la descente
+planée. Le seuil colossal de 2 500 reste une monture sur laquelle le joueur
+s'assoit ; il ne peut pas être porté sur la tête. Seul le dragon reçoit la
+montée lorsqu'il est porté ; les autres petits animaux volants gardent leur
+plané et les montures colossales leur pilotage existant.
+
+La physique du joueur reste native avec collisions. Le serveur n'exempte du
+contrôle d'immobilité aérienne que la montée réellement soutenue par un grand
+dragon porté et la touche de saut reçue. Retrait du familier, immersion,
+déconnexion et perte du portage interrompent l'assistance. Les règles
+existantes de collision du passager s'appliquent au dragon sur la tête.
+
+Aucun changement du format des œufs, des sauvegardes ou de la génération.
+Les indications de montée dans l'infobulle utilisent la touche de saut
+configurée, avec libellés FR/EN.
+
+## Vérification
+
+`Familiar067ClientChecks` réussit en 55 secondes sur un monde plat de
+développement avec serveur intégré :
+
+- F ouvre réellement les ordres sans changer les objets des deux mains ; H
+  ne les ouvre plus. Réassigner sur K fonctionne et libère l'échange natif F.
+- La position de la tête dans le modèle de dragon soumis au rendu est devant
+  le corps pour quatre directions cardinales, pas derrière.
+- Dragons de tailles 350 et 650 : Maj + clic droit natif, passager synchronisé,
+  descente bornée côté client, distance de chute effacée des deux côtés ;
+  Espace ne permet pas de monter avec ces petits.
+- Taille 1 500 : montée de plus de huit blocs en maintenant Espace pendant
+  cent ticks, connexion maintenue, reprise du plané au relâchement, collision
+  au plafond sans traversée du joueur.
+- Taille 3 500 : le joueur monte sur le dragon, puis décolle avec Espace.
+
+Le plané des petits existait déjà : le parcours le confirme sur le dragon.
+Le nouveau comportement de montée concerne la catégorie « grand » portée.
+La transparence de proximité existante reste conservée.
+
+Journaux : `build/familiar067-client.log` et `build/familiar067-check.log`.
+L'attente initiale de tous les chunks du rayon échouait dans le parcours ;
+le test attend désormais la partie jouable et utilise sa zone de test locale.
+`./gradlew check build assemblePack assembleTestPack` réussit en 2 min 12 s
+avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
+-PsanctuaryQuickTests=true`. Le parcours natif est lancé séparément avec
+`-PsanctuaryFamiliar067ClientTests=true -PsanctuaryClientNoVsync=true`.
+
+Les deux MRpacks contiennent les 1 646 classes compilées et leurs ressources
+vérifiées. Les différences avec beta.066 se limitent aux cinq classes du
+correctif, au mixin enregistré, à l'indication FR/EN et aux versions des mods.
+JEI, les textures, les données de génération et les archives beta.066 restent
+identiques. Reçu : `build/familiar067-artifact.json`.
+
+[Pack normal](../build/Sanctuary-beta.067.mrpack) ·
+[Monde plat rapide](../build/Sanctuary-Test-beta.067.mrpack).
+
+Validation en client natif avec serveur intégré, sans serveur dédié ni essai
+à plusieurs clients distants. Aucun canal publié, instance personnelle ou
+monde existant modifié.

docs/familiar-orders-beta069.md

@@ -0,0 +1,55 @@
+# beta.069 — retour des ordres du familier sur H
+
+Branche `codex/familiar-orders-h-beta069`.
+
+Les ordres du familier reviennent sur **H**. **F** conserve l’échange natif des
+objets entre les mains ; **G** reste la technique du familier. Les touches
+restent configurables dans les options et les libellés FR/EN existants suivent
+le raccourci assigné.
+
+Le remplacement introduit en beta.067/.068 est annulé au premier démarrage :
+une ancienne affectation F des ordres devient H. Les autres touches
+personnalisées sont conservées. Le nouveau marqueur local
+`config/sanctuary-familiar-key-v2.txt` rend cette opération unique, même si le
+marqueur v1 existe déjà. Les modifications manuelles ultérieures ne sont pas
+réécrites. Le filtrage qui consommait les actions du raccourci d’échange des
+mains est supprimé. Aucun changement du serveur ou des sauvegardes.
+
+## Vérifications natives
+
+Le parcours `Familiar067ClientChecks`, actualisé pour le retour sur H, réussit
+en **1 min 7 s** : H ouvre les ordres sans échanger les mains ; F échange un
+diamant et un lingot d’or dans les deux sens sans ouvrir de menu ; G conserve
+son affectation par défaut ; une personnalisation des ordres sur K fonctionne.
+Le reste de ce parcours existant (orientation, plané et vol du dragon) passe
+également. Le test utilise un monde plat de développement et un serveur intégré.
+
+Après le parcours, les options enregistrées sont bien H/F/G et le marqueur v2
+contient beta.069 (`build/familiar069-controls.json`). Le lanceur réinitialise
+la configuration de test ; ce parcours ne prétend donc pas valider la mise à
+jour complète d’une ancienne installation. La conversion conditionnelle F→H
+et le garde par marqueur ont été vérifiés dans le code ; la configuration
+personnelle de Prism n’a pas été modifiée.
+
+Journal : `build/familiar069-client.log`. Le sélecteur de ce parcours reste
+`-PsanctuaryFamiliar067ClientTests=true`, avec `-PsanctuaryClientTests=true
+-PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true`.
+
+## Livraison locale
+
+`check build assemblePack assembleTestPack` réussi en **2 min 13 s**, 122 tâches,
+avec exclusion du serveur
+dédié (`-x :sanctuary:runGameTest`) et les profils client/test rapide.
+Voir `build/familiar069-check.log`. Aucun serveur dédié ni acceptation d’EULA.
+
+Les 1 647 classes du mod correspondent à la compilation. Seule la classe
+`FamiliarClient` change par rapport à beta.068 ; textures, traductions,
+chargement, dragon et JEI restent identiques. Les archives beta.068 gardent
+leurs empreintes. Reçu : `build/familiar069-artifact.json`.
+
+- [Pack normal](../build/Sanctuary-beta.069.mrpack), 5726225 octets.
+  SHA-256 : `1c923452ff4d5d186309390fac3306b8e05162143c852619b7519741002aa165`.
+- [Monde plat rapide](../build/Sanctuary-Test-beta.069.mrpack), 5745158 octets.
+  SHA-256 : `bed499fa29f4247a9e321207df503b3147b8b4fc8c8541d817cdfe2a2db9a945`.
+
+Aucune instance personnelle ni canal public modifié.

docs/familiar-personality-beta071.md

@@ -0,0 +1,169 @@
+# beta.071 — personnalité et engagement des familiers
+
+Branche `codex/familiar-personality-beta071`.
+
+## Comportement
+
+Chaque œuf individualisé possède une personnalité de combat, visible dans
+son infobulle et sa fiche de familier. Les ordres restent sur H, la technique
+sur G et l’échange des mains sur F.
+
+| Personnalité | Réaction spontanée | Poursuite | Cadence d’initiative |
+| --- | --- | --- | --- |
+| Agressif | Engage les monstres proches, accompagne les attaques et riposte | ×1,55 | délai ×0,90 |
+| Protecteur | Accompagne les attaques et défend le joueur, l’allié protégé et lui-même | ×1,45 | délai habituel |
+| Passif | Riposte seulement lorsqu’il est frappé | ×1,35 | délai ×1,05 |
+| Pacifiste | S’éloigne du danger, sans attaque automatique | ×1,35 sur ordre | délai habituel |
+
+**Tous obéissent à un ordre explicite d’attaque**, y compris le pacifiste.
+Une autre menace ne remplace pas une cible désignée tant qu’elle reste valide.
+Un Enderman ou un Piglin zombifié non engagé est laissé tranquille ; les
+familiers et les joueurs ne déclenchent pas cette recherche de proximité. Le PvP conserve ses règles et les
+duels leur consentement. Suivre suspend les réactions automatiques cinq
+secondes ; Rappeler ou le mode travail interrompent l’engagement spontané.
+
+Les vitesses sont des multiplicateurs de navigation : la poursuite utilisait
+auparavant ×1,15. L’approche gagne donc environ 17 à 35 % selon le caractère,
+sans changer la vitesse de promenade, celle des montures ni les dégâts.
+Les attaques à distance gardent leur distance utile. Les feintes au contact
+cessent suffisamment tôt pour entrer réellement à portée. Les préparations
+d’attaque restent lisibles : leurs durées ne sont pas raccourcies.
+
+Les espèces de soutien conservent leurs techniques signature. Un villageois
+agressif, ou un soutien explicitement envoyé attaquer, dispose d’un coup au
+contact (2 dégâts de base, préparation 0,25 s, intervalle 2 s), sans exiger un
+bouclier dans l’inventaire du joueur. Les techniques offensives natives des
+espèces restent utilisées.
+
+## Individus et tendances
+
+Le tirage utilise l’UUID déjà enregistré et l’identifiant d’espèce. Sa fonction
+et son sel sont figés dans `FamiliarPersonality`. Il ne dépend ni du nom, ni
+de la taille, ni de l’XP, ni du propriétaire ou de la reconnexion. Les anciens
+œufs identifiés reçoivent donc un caractère stable sans conversion de fichier.
+Un œuf sans identité le découvre à sa première individualisation habituelle.
+
+| Tendance d’espèce | Agressif | Protecteur | Passif | Pacifiste |
+| --- | --- | --- | --- | --- |
+| Vindicateur et espèces farouches listées dans le code | 70 % | 20 % | 7 % | 3 % |
+| Villageois et espèces paisibles listées dans le code | 5 % | 15 % | 25 % | 55 % |
+| Autres espèces et futurs profils sans règle spécifique | 25 % | 40 % | 25 % | 10 % |
+
+Toutes gardent des exceptions. Le tempérament historique hors combat
+(curieux, calme, joueur), les souvenirs, les identifiants, les 88 profils et
+les schémas de sauvegarde restent intacts. Changer ces seuils ultérieurement
+changerait le caractère d’œufs existants : cela demanderait un contrat de
+migration, pas une simple retouche d’équilibrage.
+
+## Araignées
+
+L’araignée et l’araignée venimeuse utilisent la navigation d’escalade native.
+En monture colossale, avancer contre une paroi les fait grimper à environ
+quatre blocs par seconde. Relâcher ou s’écarter permet de redescendre. La
+vérification porte sur le corps de l’araignée : un plafond touché par le joueur
+ne déclenche pas une ascension. Les collisions du corps et de la tête du
+cavalier restent actives. Un espace vide n’autorise aucune montée.
+
+L’éligibilité à la monte reste celle des familiers colossaux ; les petits
+familiers se portent selon les règles existantes.
+
+## Effets des montures natives
+
+Audit du code de Minecraft **26.3-pre-2** : `AbstractHorse` et ses variantes,
+`Camel`/`CamelHusk`, `Pig`, `Strider`, `HappyGhast` et
+`AbstractNautilus`/`Nautilus`/`ZombieNautilus`. Les sources de comparaison
+sont extraites du JAR utilisé par le build dans `build/native071-source/`.
+
+| Espèces natives pouvant recevoir un cavalier | Effet transmis au cavalier | Trait de déplacement |
+| --- | --- | --- |
+| Cheval, âne, mule, cheval squelette, cheval zombie | Aucun effet d’état natif | Déplacement et saut terrestres |
+| Lama, lama de marchand | Aucun | Montables, mais pas pilotables en vanilla |
+| Dromadaire, dromadaire momifié | Aucun | Déplacement terrestre ; dash natif distinct d’un effet d’état |
+| Cochon | Aucun | Direction à la carotte sur bâton en vanilla |
+| Strider | Aucun bonus de résistance au feu au joueur | Appui à la surface de la lave |
+| Ghast joyeux | Aucun | Vol |
+| Nautilus, Nautilus zombie | **Souffle du Nautilus** | Nage et dash natifs |
+
+Le Souffle du Nautilus est ajouté au moment de monter et entretenu tant que
+le joueur reste sur son Nautilus colossal. Il utilise l’effet Minecraft
+original : durée de 60 ticks, renouvellement toutes les 40 ticks, niveau zéro.
+L’air restant est figé sous l’eau, sans être rempli comme avec une potion.
+Après la descente, l’effet expire naturellement sous trois secondes ; il
+n’est pas supprimé brutalement au risque d’effacer une autre source.
+
+Il fonctionne pour les deux espèces, sur toute la plage colossale existante
+(2 500 à 6 000 ‰, y compris les plus grands « titans »), sans achat de
+technique ou condition de personnalité. Porter simplement l’œuf ou le petit
+familier sur sa tête ne donne pas cet effet de **cavalier**.
+
+Le Strider retrouve le support de collision de lave et la remontée natifs,
+avec une infobulle dédiée. Il maintient son cavalier au-dessus de la surface ;
+ce n’est pas une immunité personnelle à la lave après avoir sauté du Strider.
+
+Les autres espèces n’appliquent pas de potion native à leur cavalier : aucune
+n’a été inventée. Les commandes Sanctuary de ces montures restent communes,
+comme demandé lors de leur introduction. Cet audit des traits ne porte pas
+les selles, harnais, coffres d’équidés, sièges supplémentaires, charges de saut
+ou commandes de dash propres aux interfaces natives. Les pouvoirs familiers
+existants restent disponibles selon leurs règles.
+
+## Coût et validation
+
+La recherche agressive est locale, dans les entités déjà chargées à huit
+blocs du propriétaire, une fois par seconde, décalée entre familiers. Aucun
+chargement de chunk. La navigation reste limitée à une demande de chemin
+par dix ticks. Les décisions et les dégâts font autorité côté serveur.
+
+Le parcours `Familiar071ClientChecks` réussit en **2 min 23 s** dans un
+nouveau monde plat de développement, avec le client et son serveur intégré :
+
+- 352 000 UUID répartis entre les 88 espèces ; quatre caractères possibles,
+  tendances villageois/vindicateur, stabilité après changement d’XP et de souvenirs.
+- Quatre personnalités de loups : réactions aux événements, ordre explicite,
+  navigation jusqu’à la cible et dégâts réels. Verrouillage de combat maintenu
+  même pour un familier qui refuse l’engagement spontané.
+- Villageois agressif : initiative spontanée et dégâts sans bouclier ; la cible
+  manuelle garde sa priorité. Fiche FR/EN et nom du familier inspectés.
+- Araignée et araignée venimeuse colossales : touches natives, ascension du mur,
+  collision du cavalier avec le plafond et absence de montée dans l’espace vide.
+- Strider colossal : déplacement avec les touches natives à la surface d’un
+  bassin de lave, cavalier hors de la lave et sans potion de résistance au feu.
+- Nautilus et Nautilus zombie : tailles 2 500 et 6 000 ‰, cavalier effectivement
+  immergé, air figé à 40 pendant 90 ticks, renouvellement de l’effet, expiration
+  et reprise de la consommation après la descente. Équiper l’œuf seul ne le donne pas.
+- Fermeture puis réouverture réelle du monde : même UUID et même personnalité.
+
+Les captures sont dans `build/familiar071-evidence/`, le journal dans
+`build/familiar071-client.log`. La matrice de personnalité couvre les 88
+profils ; elle ne constitue pas un nouveau playtest de toutes leurs techniques.
+Pas de validation à deux clients distants ou sur serveur dédié dans cette passe.
+
+La construction de la distribution est effectuée dans
+`build/familiar071-workspace/` : les sources de la release beta.070, puis les
+changements ciblés de la 71. Cette copie évite de compiler les fichiers de
+statues de la beta.072 ajoutés simultanément dans le dossier partagé.
+`build/familiar071-source-snapshot.json` fixe les empreintes de cette copie.
+Les sources courantes du familier conservent les mêmes changements.
+
+`check build assemblePack assembleTestPack` réussit en **5 min 50 s**,
+124 tâches (108 exécutées, 16 à jour), dans cette copie isolée. Le serveur
+dédié `:sanctuary:runGameTest` reste exclu conformément au refus d’accepter
+son EULA ; le parcours natif utilise uniquement le serveur intégré du client.
+
+Les deux exports MRpack sont vérifiés : version exacte, dépendances figées,
+JAR comparé aux **1 651 classes compilées** et aux ressources traitées,
+égalité normal/Test sauf module de test, absence de classes de test dans le
+mod livré. Seuls les neuf fichiers Java prévus et douze libellés par langue
+changent par rapport à beta.070 ; les schémas, le catalogue, JEI, le code de
+Demeure et les 150 fichiers du resource pack restent identiques. Le manifeste
+de Demeure suit seulement le nouveau numéro du pack.
+
+Reçu et empreintes : `build/familiar071-artifact.json`.
+
+- [Pack normal](../build/Sanctuary-beta.071.mrpack), 9 462 323 octets.
+  SHA-256 : `1ab36663fe24313597c5328170a3eb2ca2e33bfdfc4c6fbc85c1f5c03102628c`.
+- [Monde plat rapide](../build/Sanctuary-Test-beta.071.mrpack), 9 481 258 octets.
+  SHA-256 : `06309f4cd382053fb42d80c3f131152932e07523ace799c50d1d899026029a92`.
+
+Le resource pack demeure beta.070, actif par défaut et désactivable. Aucun
+monde personnel, aucune instance Prism et aucun canal public ne sont modifiés.

docs/familiar-solo-beta079.md

@@ -0,0 +1,67 @@
+# beta.079 — ordres et défense des familiers en solo
+
+Branche `codex/familiar-solo-beta079`, Minecraft 26.3-pre-2, textures beta.070.
+
+Signalement : les familiers paraissent passifs en solo ; H ouvre le menu,
+mais les ordres ne semblent pas exécutés. Espèces citées : slime, loup, poule.
+
+## Causes reproduites
+
+L’ouverture du menu H envoie `refresh`. Cette lecture consommait la même
+limite de fréquence que les ordres : un clic immédiatement après l’ouverture
+était rejeté sans message. La mise à jour possède désormais sa propre limite,
+sans affaiblir celle des actions. Le test natif échouait sur Rappeler avant
+cette correction et réussit ce passage après séparation des requêtes.
+
+Suivre suspendait pendant cinq secondes toutes les réactions automatiques,
+y compris la défense du joueur attaqué. Le délai ne concerne désormais que
+les initiatives spontanées. Une personnalité qui défend son propriétaire
+ou riposte peut réagir immédiatement aux dégâts. Le pacifiste conserve son
+comportement ; l’ordre explicite de protection reste prioritaire.
+
+Les ordres du menu confirment leur réception : suivi, attaque, protection
+ou rappel. Une attaque sans familier disponible, sur une cible refusée ou
+avec un familier porté/monté donne une explication au lieu d’une confirmation
+d’attaque inexécutable. FR/EN disponibles. H bref et H maintenu sont conservés.
+
+Le mode utilitaire continue de suspendre les attaques autonomes. La santé,
+les UUID, les personnalités, les capacités et les sauvegardes sont conservés.
+Les nouveaux compteurs de requêtes sont temporaires côté serveur ; aucune
+migration ni modification d’un monde personnel.
+
+## Vérification
+
+Deux reproductions natives avant correction : rejet de Rappeler juste après
+l’ouverture de H ; absence de défense d’un loup passif juste après Suivre.
+Le scénario utilise un nouveau monde plat solo de développement, sans
+commandes, sans droits opérateur et sans achat du Lien actif.
+
+`Solo079ClientChecks` réussit en **1 min 53 s** : rappel immédiatement après
+l’ouverture de H, retour au suivi, garde du joueur, attaques ordonnées et
+défense immédiate après Suivre pour le loup, le slime et la poule. Les tests
+attendent le déplacement et la frappe, contrôlent la baisse de santé et
+identifient le familier comme auteur du dégât, pour exclure le soleil ou les
+autres dégâts environnementaux. Les confirmations sont reçues côté client.
+
+`Autonomy074ClientChecks` réussit en **1 min 58 s** : quatre personnalités,
+garde, vue et obstacles, cibles neutres, priorité des ordres, permissions,
+mode utilitaire, délai avant les poursuites spontanées, H bref/maintenu,
+touche reconfigurée et échange des mains avec F. Fiches FR/EN vérifiées.
+
+Journaux : `build/solo079-client-final.log`, `build/solo079-regression.log`.
+Captures : `build/solo079-evidence/`.
+`check build assemblePack assembleTestPack` réussit en **2 min 21 s**,
+124 tâches, avec `-x :sanctuary:runGameTest` conformément au refus du serveur
+dédié. Les 1 693 classes du JAR correspondent au build ; seules
+`FamiliarBattle` et son état temporaire changent par rapport à beta.078.
+Deux nouveaux libellés par langue, ressources et textures inchangées.
+Sources vérifiées, même JAR embarqué dans les deux packs ; archives beta.078
+conservées à l’identique. Reçu : `build/solo079-artifact.json`.
+Aucun déploiement personnel ; les essais utilisent le serveur intégré.
+
+## Archives
+
+- [Sanctuary-beta.079.mrpack](../build/Sanctuary-beta.079.mrpack).
+  SHA-256 : `7df042d720e2511310387183efcc432cafec4786623e530e5552fd2ba36ca7db`.
+- [Sanctuary-Test-beta.079.mrpack](../build/Sanctuary-Test-beta.079.mrpack).
+  SHA-256 : `0ca193b2918c7d650503c2ce2fa97d2b3c626fee5ddd99df0cf51ea05a2bb82e`.

docs/familiar-sunlight-beta062.md

@@ -0,0 +1,81 @@
+# beta.062 — soleil et chapeaux des familiers
+
+Branche `codex/familiar-sunlight-beta062`.
+
+Le familier reprend la sensibilité solaire du type natif de son œuf : tag
+`minecraft:burn_in_daylight`, avec respect de l'immunité native au feu. La
+vérification utilise le moteur Minecraft 26.3-pre-2 : lumière, ciel dégagé,
+eau/pluie/neige poudreuse et attribut environnemental `MONSTERS_BURN`.
+Les bébés familiers concernés brûlent aussi. Les autres espèces conservent
+leur comportement actuel.
+
+Tout objet équipé dans l'emplacement de tête Sanctuary protège des nouvelles
+inflammations solaires, sur un mob ordinaire comme sur un familier. Maj + clic
+droit avec un objet l'équipe ; Maj + clic droit à main vide le récupère.
+L'armure de tête native conserve sa protection et son usure habituelles quand
+aucun chapeau Sanctuary n'est équipé. Un chapeau ne rend pas résistant au feu :
+une flamme déjà allumée termine sa durée native, ou s'éteint dans l'eau.
+
+Les familiers sensibles perdent leur santé de combat en brûlant, jusqu'au K.-O.
+habituel, sans détruire l'œuf. Leur feu reste dangereux pendant un duel ; les
+attaques extérieures au duel restent exclues. Les flammes suivent la taille
+visible du compagnon. Une indication FR/EN sur les œufs concernés explique le
+besoin d'un chapeau, sans achat préalable d'une aptitude.
+
+Aucun identifiant ni format de sauvegarde ne change. Le chapeau utilise
+l'équipement existant : il est rendu au sol quand le familier disparaît et
+n'est pas stocké dans son œuf. Aucun monde existant ni canal n'est modifié.
+
+## Vérifications
+
+`Sunlight062ClientChecks` passe dans le client natif 26.3-pre-2, sur un monde
+plat de développement neuf :
+
+- 88 œufs exposés au moteur solaire natif : zombies, villageois zombies,
+  noyés, chevaux zombies, nautiles zombies, squelettes, vagabonds, embourbés
+  et phantoms brûlent ; les autres conservent leur immunité, dont le Wither
+  squelette naturellement résistant au feu ;
+- mob ordinaire avec pierre, diamant, bâton et torche en chapeau, protection
+  et usure du casque natif conservées, reprise du feu après retrait ;
+- vrai paquet Maj + clic droit pour équiper puis retirer un diamant de la
+  tête du familier, synchronisation de l'objet sur son modèle côté client ;
+- santé persistée qui baisse sur les vrais ticks de feu, feu déjà allumé qui
+  expire sous un chapeau, absence de nouvelle inflammation ;
+- toit, nuit, pluie et immersion ; l'eau éteint aussi les flammes existantes ;
+- K.-O. déclenché par un tick natif de brûlure, identité et œuf conservés ;
+- brûlure et fin normale d'un duel au K.-O., refus des coups directs d'un
+  joueur extérieur et des autres dégâts environnementaux pendant le duel ;
+- flammes synchronisées aux dimensions visibles du familier bébé, capture
+  inspectée dans `build/sun062-evidence/sunburn.png`, indication FR/EN.
+
+Journal `build/sun062-client.log` : **55 s**, marqueurs
+`SUNLIGHT062_SPECIES_PASS` et `SUNLIGHT062_PASS`. La première tentative de
+lancement a été arrêtée au blocage OpenGL de synchronisation verticale ;
+le parcours réussi utilise `-PsanctuaryClientNoVsync=true` et le réglage VSync
+uniquement dans le dossier du client de développement.
+
+L'essai de duel utilise deux entités serveur avec une connexion simulée pour
+la seconde ; aucun essai avec deux clients humains n'est revendiqué. La
+capture inspectée est celle du zombie bébé ; le rendu individuel des huit
+autres espèces sensibles n'a pas été revu visuellement.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest
+-PsanctuaryClientTests=true -PsanctuarySunlight062ClientTests=true
+-PsanctuaryQuickTests=true` réussit : **122 tâches**, **2 min 10 s**.
+Le parcours client est exécuté séparément par `:sanctuary:runClientGameTest`
+avec les mêmes propriétés et `-PsanctuaryClientNoVsync=true`.
+Aucun EULA de serveur dédié n'a été accepté.
+
+## Archives locales
+
+- [Pack normal](../build/Sanctuary-beta.062.mrpack), 5678508 octets.
+  SHA-256 : `3eb3729023bcb1f6931198d50694ecac1fee1c660aeb0cf1edc9776aebbfe2fa`.
+- [Monde plat rapide](../build/Sanctuary-Test-beta.062.mrpack), 5697441 octets.
+  SHA-256 : `f71dd47ef228d2acab99fe9b7b58e11d4f39234f926d7a313956bdd69e9cd2b6`.
+
+Les **1624 classes** embarquées correspondent au build. Le reçu
+`build/sun062-artifact.json` vérifie le contenu des archives, les différences
+ciblées avec beta.061, les dépendances imbriquées et la conservation des
+archives précédentes. JEI, la génération et les autres ressources du pack
+restent identiques. Aucun canal publié, instance personnelle ni monde
+existant n'est modifié.

docs/fine-stem-beta185.md

@@ -0,0 +1,83 @@
+# STEM-185 — ligne fine, portail de toiture et vitres reliées
+
+Ticket du 30 septembre 2026, branche `codex/fine-stem-beta185`.
+Le créateur valide la fleur et le palais beta.184, ainsi que la galerie inférieure.
+Il demande de supprimer l'escalier, les paliers et la grosse colonne : une ligne
+d'un bloc doit guider visuellement le bateau-poule vers le palais. Compléments
+pendant la réalisation : incruster le portail horizontal au sommet du dôme,
+libérer l'espace au-dessus de la carte, fermer le jour sous les vitres supérieures.
+
+## Contrat
+
+Nouveau profil de labo `stem`, preset `sanctuary_test:fine_stem_v1`, réglages
+`sanctuary_test:fine_stem_v1_10`, graine de visite **42**, version **beta.185**.
+La dimension 1600, le champ de bruit 640, l'île et les eaux retenues restent
+ceux de beta.184. Aucun changement de format, d'ancien preset ou de sauvegarde.
+La visite beta.184 a été arrêtée proprement à la demande du créateur ; une
+nouvelle sauvegarde est préparée pour la relance.
+
+## Résultat
+
+- Rosace et Bugrock toujours en (0,640,0), palette et huit axes conservés.
+- **Une seule colonne de calcite en (0,Y,0)** au-dessus du dôme inférieur,
+  de Y=652 jusqu'au départ de l'évasement à 1160. Pas de spirale, de marches,
+  de plateforme intermédiaire, de balustrade ou de pont d'escalier.
+- Les huit nervures s'élargissent progressivement près du sommet, en partant
+  du même bloc central. Fleur, balcon et pièce du palais à Y=1278 conservés.
+- Portail horizontal 7×7, ouverture 5×5, **incrusté à Y=1309 dans le dôme**.
+  Son cadre remplace les vitres sommitales et touche la toiture sur tout son
+  pourtour extérieur. Le passage central traverse la voûte ; plus de cadre
+  suspendu au milieu de la salle, au-dessus des 49 cartes au sol.
+- Un soubassement de calcite ferme le bloc d'air sous les panneaux de verre.
+  Les huit passages restent ouverts. Leur dégagement est vérifié avec les
+  collisions natives, pour une coque standard de 1,375 bloc et son pilote.
+- Les moteurs du bateau-poule existant ne comportent pas de plafond fixe à
+  640. Aucun changement de mécanique de vol ni de comportement de familier.
+
+La révélation de la couronne en montant reprend beta.184. La galerie inférieure,
+son portail 5×5, le soufre, les secteurs miniers, les étangs et le donjon restent
+ceux validés. Les portails restent des infrastructures, sans voyage dimensionnel.
+
+## Vérifications et visite
+
+Contrôle natif final `solo185c/stem/42` réussi : **508 tranches d'un seul bloc**,
+16 approches libres (huit par lieu, coque et pilote légèrement au-dessus des
+tapis de mousse), 104 colonnes vitrées appuyées sur calcite, 24 blocs de cadre
+reliés à la toiture. Les 16 868 entrées du plan correspondent aux blocs générés.
+La voûte hors de l'ouverture centrale reste identique à beta.184. Aucune marche
+ni palier dans cette variante. Reçu : `build/stem185-quick-result.json`.
+
+L'île conserve ses 567 échantillons de densité vérifiés, zéro région d'hydrologie,
+les trois cerisiers, cinq spawners, quatre wagonnets à butin, la galerie, le soufre
+et les trois secteurs de gemmes. Le serveur démarre en 5,2 s ; préparation avec
+sondages, atlas et contrôles en 42,3 s. Ce dernier temps inclut les tests.
+
+Lecture NBT du monde arrêté : 49 cartes complètes et figées, cadres horizontaux
+et identifiants uniques. Ancien cadre suspendu en air, nouveau cadre de toiture
+en obsidienne, tige centrale isolée et soubassement du vitrage confirmés.
+Reçus : `build/stem185-saved-atlas.json`, `build/stem185-saved-blocks.json`.
+
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch`
+réussi en **7 min 3 s**, **265/265 GameTests**. Journal :
+`build/stem185-check-build.log`. Le daemon de compilation a été arrêté pour
+libérer la mémoire avant le client Vulkan.
+
+Solo Vulkan ouvert le 30 septembre à **07:32:51**. Nouveau monde
+`visite185/stem/42`, `Sanctuary-Fine-Stem-185-Solo`, créatif, commandes et vol,
+vue 32 chunks et simulation 12. Départ préparé dans le palais supérieur.
+Entrée confirmée en (6.5,1280,8.5), vue 32 et simulation 12 dans le journal
+`build/stem185-solo.log`. Vérification native du frustum réussie à 07:32:53 :
+couronne cachée depuis le sol, révélée en arrivant à la rosace. Inspection de
+la fenêtre du jeu : carte au sol présente et vitrages reliés au soubassement.
+L'ancienne sauvegarde beta.184 reste conservée. Aucun canal public ou instance
+Prism modifié ; seuls les artefacts locaux et le laboratoire sont livrés.
+Les contrôles de passage ne
+remplacent pas un trajet intégral piloté en bateau-poule.
+
+| Lieu | Téléportation |
+| --- | --- |
+| Rosace du Bugrock | `/tp 0.5 639 5.5 180 -20` |
+| Palais et carte au sol | `/tp 6.5 1280 8.5 140 35` |
+| Portail dans la toiture | `/tp 0.5 1312 0.5 180 75` |
+| Liaison fine, vue extérieure | `/tp 24 920 24 135 -20` |
+| Portail inférieur | `/tp 0.5 177 7.5 180 30` |

docs/flying-landing-beta101.md

@@ -0,0 +1,58 @@
+# beta.101 — Atterrissage des familiers volants
+
+Branche `codex/flying-landing-beta101`, Minecraft 26.3.
+
+Le profil de vol du familier doit désactiver l’accumulation et le traitement des
+chutes de son entité commune. Une descente pilotée, autonome ou un contact avec
+le sol ne doit causer ni dégâts, ni animation/son de coup, ni entrée en combat.
+Les vraies attaques et les chutes des familiers terrestres gardent leurs règles.
+Aucun changement de navigation, de sauvegarde, de texture ou de terrain.
+
+## Cause et correction
+
+L’entité Sanctuary commune hérite de `PathfinderMob`. Son contrôle de vol et
+l’absence de gravité ne remplacent pas les méthodes natives de chute. Ces
+méthodes pouvaient appeler `FamiliarBattle.hurt`, produire son animation/son de
+coup, interrompre une technique et enregistrer du combat.
+
+`checkFallDamage` remet maintenant la distance à zéro pour les profils volants.
+`causeFallDamage` refuse aussi un appel avec une distance déjà calculée, avant
+les sons et les dégâts natifs. Les autres profils délèguent toujours au code
+Minecraft. Les sources de dégâts ordinaires ne sont pas filtrées.
+
+## Validation
+
+Reproduction native sur beta.100 : le perroquet accepte le callback de chute,
+et l’assertion « Flying familiar rejects native fall callback » échoue.
+Journal conservé : `build/landing101-before.log`.
+
+`Landing101ClientChecks` réussit après correction en **1 min 5 s**, dans un
+nouveau monde plat de développement avec le serveur intégré :
+
+- Les douze espèces du registre ayant un profil volant : perroquet,
+  chauve-souris, abeille, allay, Wither, breeze, phantom, vex, blaze, ghast,
+  ghast joyeux et dragon.
+- Callback natif de chute à sept blocs, descente à 0,25 bloc par tick jusqu’au
+  contact réel avec le sol, puis mouvement rapide vers le sol.
+- Santé inchangée, distance de chute nulle et absence de mise à jour de
+  `lastHurt`, donc pas de passage dans la branche qui diffuse le faux coup.
+- Une attaque de zombie reste acceptée et enlève de la santé pour chaque espèce.
+- Un loup terrestre conserve les dégâts de sa chute.
+
+Les descentes sont pilotées par le test via les collisions natives ; ce n’est
+pas un nouveau playtest de tous les trajets autonomes ou un essai multiclient.
+Journal : `build/landing101-client.log`. Aucun monde personnel n’est utilisé.
+`check build assemblePack assembleTestPack` réussit en **2 min 22 s**,
+124 tâches, avec le serveur dédié exclu (`-x :sanctuary:runGameTest`).
+Les archives normal/Test embarquent le même JAR vérifié et ses sources exactes.
+Seul `FamiliarEntity` et les numéros de ligne de deux classes internes changent
+par rapport à beta.100. Les ressources, textures et archives beta.100 sont
+conservées. Reçu : `build/beta101-artifact.json`. Aucun déploiement personnel
+ni publication du canal packwiz.
+
+## Archives
+
+- [Sanctuary-beta.101.mrpack](../build/Sanctuary-beta.101.mrpack), 9914792 octets.
+  SHA-256 : `3008127d2bb09556c4997c00350e82ff26af5402b69bc7c09c822b24ff4bfe74`.
+- [Sanctuary-Test-beta.101.mrpack](../build/Sanctuary-Test-beta.101.mrpack), 9933717 octets.
+  SHA-256 : `854a8b6a42ac7ca0236e0c19b9000808535df273911b9c6a72844097a49358a0`.

docs/four-islands-base224.md

@@ -0,0 +1,53 @@
+# Les quatre îles dans Sanctuary normal
+
+## Validation du 5 octobre 2026
+
+Le joueur valide le rendu beta.224 et demande que les quatre îles soient
+disponibles dans Sanctuary de base, sans Sanctuary Test.
+Branche de vérification : `codex/four-islands-base224`, base `4554ea1`.
+
+L’audit confirme que cette intégration est déjà effective dans le mod et le
+MRpack normal beta.224. Aucun transfert supplémentaire de code n’est nécessaire.
+Cette livraison documentaire ne change ni les binaires ni leur version.
+
+| Ancre | Expansion validée | Contenu principal |
+| --- | --- | --- |
+| Nord | Glaciale | Taïgas géantes, glace, améthyste, igloos et manoir |
+| Sud | Aride | Canyons colorés, forêts, sentiers et pyramide piégée |
+| Ouest | Océanique | Océan, monument, épaves et berges en roche jaune |
+| Est | Volcanique | Volcan actif, jungles, bambou et temple de jungle |
+
+Créer un **nouveau monde Sanctuary**, avec le choix Petit/Moyen/Grand.
+Les expansions de 1024 blocs sont débloquées par leurs ancres cardinales
+et leurs demandes de matériaux ; elles ne sont pas toutes prégénérées au départ.
+Les anciens mondes conservent leur génération enregistrée.
+
+## Contrôle de l’intégration
+
+- Le preset public `sanctuary:sanctuary` utilise `island224_medium`. Le sélecteur
+  du mod normal propose également les profils Small et Large de cette génération.
+- `SanctuaryMod` enregistre directement les générateurs, l’adaptateur d’expansion
+  et les interactions des ancres. Aucun de ces chemins ne dépend de l’activation
+  de `QuickTestMod`. Les anciens noms Java et identifiants `sanctuary_test:*`
+  sont conservés pour la compatibilité ; ils ne constituent pas une dépendance
+  au module optionnel.
+- Vérification du MRpack normal : générateurs, structures et biomes des quatre
+  directions présents pour les trois tailles ; un seul JAR Sanctuary, aucune
+  dépendance au module `sanctuary_test`, aucun monde ni JAR Sanctuary Test inclus.
+- La création conserve les types vanilla et une seule entrée publique Sanctuary.
+- Le build complet et les sept GameTests beta.224 ont déjà réussi, dont le
+  chargement des profils sans le module de labo. Ils ne sont pas relancés pour
+  cette modification documentaire. Les essais natifs des différentes îles sont
+  décrits dans leurs tickets ; cet audit ne revendique pas une nouvelle partie
+  complète avec les quatre îles simultanément.
+
+Reçu local : `build/four-islands-base224-receipt.json`.
+Artefact standard : `build/Sanctuary-beta.224.mrpack`, copie identique dans
+`~/Downloads/Sanctuary-beta.224.mrpack`, SHA-256 :
+
+```text
+01aed4e6a0d9e2965ed8201372eef3aaecab3b0c6dce3fb84586895ed9076885
+```
+
+Cette validation ne migre aucun monde et ne modifie pas le canal packwiz ou
+l’installation Prism personnelle.

docs/fourneau-allume-beta094.md

@@ -0,0 +1,79 @@
+# beta.094 — Foyers allumés du Fourneau
+
+La chaleur partagée allume toute la façade du Fourneau, y compris si la cuisson
+se déroule dans une case intérieure. Les deux ouvertures reçoivent des braises
+orange et jaunes. La pierre et les trois textures originales sont conservées.
+Quand la chaleur est épuisée, la façade reprend son aspect éteint.
+
+Les 27 sources de particules des fours composants sont remplacées par une seule
+animation de façade : une flamme et une fumée dans chacun des deux foyers.
+Leurs positions correspondent aux pixels des ouvertures, à 0,02 bloc devant la
+face, dans les quatre orientations. Un four isolé garde son animation native.
+La dissociation rétablit l'état lumineux individuel des fours.
+
+## Assets et rendu
+
+- Original inchangé : `assets/sanctuary/textures/block/fourneau/front.png`.
+- Variante de feu : `assets/sanctuary/textures/block/fourneau/front_on.png`.
+- `tools/fourneau-embers.json` délimite les bandes des ouvertures à illuminer.
+- `python3 tools/generate-fourneau-models.py` régénère les modèles éteints/allumés.
+
+La variante a été créée avec l'outil intégré **imagegen**, puis réduite en
+48 × 48 par échantillonnage au plus proche pour la densité native du modèle.
+La génération ayant aussi redessiné la pierre, le rendu prélève uniquement les
+pixels de feu dans les ouvertures ; tout le reste utilise l'image originale.
+Les fines faces de braises sont décalées de 0,002 pixel pour éviter le z-fighting.
+
+Prompt retenu : « Edit the provided 48 by 48 pixel Minecraft furnace facade
+texture. Create its LIT variant. Preserve the pixel-art grid, grey stone, mortar,
+arches, outer edges and dimensions. Change only the black/dark interiors of the
+two arched openings to Minecraft-style orange, red and yellow embers/fire pixels,
+bright yellow near the bottom, orange above. Flames stay inside the holes.
+No perspective, border, labels or new elements. »
+
+Le choix du modèle utilise l'état `LIT` natif. Les snapshots d'assemblage, leurs
+paquets réseau et le schéma de sauvegarde restent identiques. Aucun paquet de
+particules n'est envoyé par le serveur. Aucun monde personnel n'est modifié.
+Le pack de textures intégré reste à son édition beta.090 ; ces assets sont ceux
+du mod beta.094.
+
+## Vérifications
+
+Le test client natif avec serveur intégré est passé sur un nouveau monde plat de
+développement, graine 85 (`build/fourneau094-client.log`, 1 min 5 s) :
+
+- 27 composants synchronisés à cheval sur quatre chunks, quatre orientations.
+- Chauffe réelle depuis une case intérieure, façade entière allumée puis éteinte.
+- 800 émissions interceptées à la sortie de l'animation native : coordonnées
+  devant la façade, sur un pixel de feu situé dans une ouverture sombre originale.
+- Aucune nouvelle particule à froid ; particules natives d'un four isolé conservées.
+- Rechargement des ressources, départ/retour dans les chunks, dissociation,
+  reconstruction et destruction ; conservation du contenu d'origine.
+- Captures allumé/éteint inspectées dans `build/fourneau094-evidence/`.
+
+Commande du test :
+
+```sh
+./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryFourneau085ClientTests=true \
+  -PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
+```
+
+Les particules déjà émises finissent naturellement leur durée de vie après
+l'extinction, comme celles des fours Minecraft. Test natif macOS ; pas de test
+avec shaders tiers ni de session LAN à deux clients pour cette livraison.
+Le serveur dédié de GameTest est exclu, conformément au refus antérieur de son
+EULA. Aucun déploiement personnel ou changement de sauvegarde.
+
+`check build assemblePack assembleTestPack -x :sanctuary:runGameTest` : réussi
+en 2 min 31 s, 124 tâches (`build/fourneau094-check.log`). La régénération des
+216 modèles est reproductible. `git diff --check` passe.
+
+Les archives normal/Test ont été exportées et vérifiées : Minecraft 26.3,
+version beta.094, même JAR Sanctuary intégré aux deux packs, sondes de test
+absentes. Les assets existants, JEI et les archives beta.093 sont inchangés.
+Le reçu `build/fourneau094-artifact.json` conserve les empreintes SHA-256 ;
+`build/verify-fourneau094.py` reproduit ces contrôles.
+
+- [Pack normal](../build/Sanctuary-beta.094.mrpack).
+- [Pack de test plat](../build/Sanctuary-Test-beta.094.mrpack).

docs/fourneau-textures-beta085.md

@@ -0,0 +1,60 @@
+# beta.085 — textures du Fourneau
+
+Les trois images originales de 48 × 48 pixels fournies par le créateur sont
+conservées, octet pour octet, dans `assets/sanctuary/textures/block/fourneau/`.
+Chaque image couvre une face entière du cube de trois blocs de côté. Les UV
+des 27 composants prélèvent chacun un tiers de l'image, à la densité native
+de 16 pixels par bloc. Façade dans l'orientation choisie à l'assemblage ;
+côtés et arrière avec `side`, dessus et dessous avec `top`.
+
+## Contrat de compatibilité
+
+Aucun changement au schéma 1 de `sanctuary:multiblocks`, aux identifiants des
+blocs ou aux données de leurs inventaires. Les assemblages beta.084 utilisent
+leur orientation déjà enregistrée. Un four isolé garde le modèle de son pack
+de ressources. Les nouveaux modèles ne s'appliquent qu'aux fours assemblés.
+Dissocier ou casser un composant rétablit les modèles ordinaires ; cuisson,
+combustible et objets restent dans les BlockEntities vanilla.
+
+Le serveur transmet seulement l'apparence des machines dans les chunks
+suivis par le joueur : à l'envoi natif du chunk, à l'assemblage et à la
+dissociation. Aucun paquet par tick de cuisson. Le client invalide les
+sections concernées et utilise les modèles de blocs natifs via Fabric,
+avec éclairage, occultation des faces et destruction habituels. Il efface
+son cache au déchargement d'un chunk, au changement de monde et à la
+déconnexion. Les modèles sont rebâtis lors du rechargement des ressources.
+
+Les modèles JSON se régénèrent avec `python3 tools/generate-fourneau-models.py`.
+Les textures originales ne sont pas générées. Le pack intégré beta.070
+reste inchangé : ces nouveaux assets appartiennent au mod beta.085.
+
+## Limites visuelles
+
+Aucune variante allumée n'a été fournie : l'image reste celle du créateur,
+y compris pendant la cuisson. L'état lumineux natif du Fourneau est conservé.
+Le Fût conserve son apparence de barils dans cette livraison.
+
+## Vérifications et livraison
+
+- `check build assemblePack assembleTestPack` : tâches réussies dans
+  `build/fourneau085-check.log`. La première extension du test visuel de chauffe
+  surveillait par erreur la case de diamants, qui ne cuit pas ; son attente a
+  échoué après les tâches de construction. Le scénario a été corrigé pour
+  observer le compartiment contenant le minerai, sans changement du code livré.
+- `Fourneau085ClientChecks` relancé avec succès : nouveau monde plat intégré,
+  quatre orientations, 27 modèles répartis sur quatre chunks, état allumé,
+  rechargement des ressources, rejet d'un paquet d'une autre dimension,
+  déchargement réel puis retour, dissociation, casse et conservation des
+  17 diamants stockés. Journal final : `build/fourneau085-client-final.log`.
+- Contrôle des trois PNG à l'octet près, des 108 modèles et de leurs UV,
+  des sources embarquées, des archives et de la préservation des assets
+  antérieurs. Reçu : `build/fourneau085-artifact.json`.
+- Captures natives : `build/fourneau085-screenshots/`, dont
+  `0001_fourneau085-north.png` et `0006_fourneau085-lit.png`.
+
+Archives locales vérifiées : `build/Sanctuary-beta.085.mrpack` et
+`build/Sanctuary-Test-beta.085.mrpack`. Les archives beta.084 restent inchangées.
+Le canal packwiz et l'instance Prism n'ont pas été déployés. Aucun monde
+personnel modifié, aucune EULA acceptée, aucun serveur dédié lancé : le test
+utilise uniquement le serveur intégré au client. Le rendu avec deux clients
+LAN distincts et avec un moteur de shaders tiers reste à éprouver séparément.

docs/fourneau-transfers-beta115.md

@@ -0,0 +1,74 @@
+# beta.115 — Dépôts et chauffe du Fourneau
+
+Ticket sur `codex/fourneau-transfers-beta115`, après le signalement de piles
+qui se réalignent pendant les dépôts rapides avec Maj, dans Ingrédients et
+Combustibles, et d'une chauffe difficile à comprendre.
+
+## Diagnostic
+
+La méthode `mayPlace` de la case serveur utilisait `index`, masqué par le
+champ hérité `Slot.index` (position affichée). Elle validait donc successivement
+une entrée, un combustible et une sortie, au lieu des 27 entrées ou des
+27 combustibles. Le client acceptait le dépôt puis le serveur le refusait.
+Le test reproduit le refus d’un déplacement de la case 1 vers la case 23.
+Le correctif utilise explicitement `physicalIndex` pour la validation.
+
+## Comportement
+
+Les transferts Maj dans les vues complètes du Fourneau sont anticipés sur le
+client, avec les mêmes destinations et règles de combustible que le serveur.
+Les cases se remplissent dans l'ordre, après fusion des piles compatibles.
+Un dépôt manuel conserve la case choisie ; aucun tri périodique des ingrédients
+n'est ajouté. Les recherches masquent une partie du stock : leurs transferts
+entrants continuent d'attendre la réponse du serveur, qui connaît tout le stock.
+
+La chauffe emprunte du combustible à une autre case uniquement pendant le tick
+natif. La pile non brûlée retourne immédiatement à sa case d'origine, avec tous
+ses composants. Les restes natifs restent associés à leur cuisson : un seau de
+lave devient un seau, puis un seau d'eau avec une éponge mouillée.
+
+Les 27 entrées ont chacune une barre et une infobulle : cuisson en cours,
+manque de combustible avec progression conservée, résultat bloqué, absence de
+recette. Le panneau indique le nombre de cuissons et la réserve allumée en
+secondes de travail cumulées. Ce n'est pas une durée réelle restante : les
+cuissons parallèles se partagent la réserve. « Fonctionnement » explique les
+onglets, les gestes et le rendement normal du combustible en FR/EN.
+
+Les recettes, résultats, expérience et règles de trémies restent natifs.
+Aucun changement de format, de monde ou de génération ; les 27 fours physiques
+conservent l'unique copie des objets et de leurs temps de chauffe.
+
+## Vérifications
+
+Le test natif `Furnace115ClientChecks` passe avec un serveur intégré, sur un
+nouveau monde plat de graine 115 : vrai glisser avec Maj sur neuf piles nommées,
+remplissage consécutif, déplacement manuel vers la case 23 et répartition native
+sur six cases de colonnes différentes. Les 27 cases de chaque onglet valident
+leur rôle physique. Le combustible nommé conserve sa position et ses composants.
+
+La cuisson parallèle, ses états synchronisés, la progression conservée à court
+de combustible, les 27 cuissons ravitaillées, le seau de lave et l'éponge,
+l'extraction des résultats et la sauvegarde native passent. Captures FR/EN
+relues dans `build/furnace115-evidence/`. Marqueur `FURNACE115_PASS` dans
+`build/furnace115-client.log`.
+
+`check build assemblePack assembleTestPack -x :sanctuary:runGameTest` réussit
+en 2 min 29 s, 125 tâches. Le panneau d'aide reçoit ensuite une dernière
+vérification client et une reconstruction ; la livraison commune beta.116
+repasse les contrôles complets en 2 min 23 s et le scénario Fourneau en 42 s.
+
+Le GameTest dédié reste exclu conformément au refus antérieur de son EULA.
+Pas d'essai Windows ou de réseau distant avec latence simulée. Aucun monde
+personnel ouvert. Cette étape reste locale et rejoint la livraison commune
+avec les matériaux de sculpture : [beta.116](sculpture-materials-beta116.md).
+
+Archives locales vérifiées (même JAR Sanctuary, sources concordantes, aucune
+classe de test ni changement de production extérieur au ticket) :
+
+- `Sanctuary-beta.115.mrpack` : 10184430 octets, SHA-256
+  `8fcac63b1bf5a01f680fb46666924705db3a2675e102037278e9d650d04cbf22`.
+- `Sanctuary-Test-beta.115.mrpack` : 10203354 octets, SHA-256
+  `5b98fdb8842690158a20b422d6aa5496d74e572b3429498ffb25476d24e87f8a`.
+- JAR Sanctuary : `2066d3191d7ee27904927fab269d8160136f048742c3223713e8ed4fe90dd8f5`.
+
+Reçu : `build/furnace115-artifact.json`.

docs/fut-navigation-beta088.md

@@ -0,0 +1,60 @@
+# beta.088 — Navigation du Fût sans recentrage de souris
+
+Branche : `codex/fut-navigation-beta088`.
+
+## Problème et correction ciblée
+
+Changer de page ou appliquer une recherche remplaçait le menu serveur via
+`openMenu`. Minecraft envoyait d'abord une fermeture au client, puis une
+ouverture. Cette fermeture reprenait la souris pour le jeu et la recentrait,
+obligeant à revenir sur le bouton à chaque clic.
+
+La transition nettoie désormais l'ancien menu côté serveur avec
+`doCloseContainer`, sans envoyer l'écran de fermeture intermédiaire. Le
+nouveau menu est ensuite ouvert normalement : la souris reste libérée et
+conserve sa position. Cela concerne la pagination et la recherche du Fût,
+ainsi que les onglets du Fourneau qui utilisent la même navigation.
+
+Chaque page garde un nouvel identifiant de menu : les paquets de clics ou de
+navigation de la page précédente sont toujours rejetés. Les contrôles de
+portée, d'accès, de structure, d'objet porté au curseur et la limite de
+fréquence restent en place. La fermeture réelle du coffre reste native.
+Aucun changement de stockage, de sauvegarde, de textures ou de libellés.
+
+## Vérifications
+
+Le parcours natif existant a été étendu avec un contrôle des paquets réseau
+sur un second joueur de test : sans correction, la navigation envoie un
+`ClientboundContainerClosePacket` et le test échoue. Avec la correction,
+aucune fermeture intermédiaire, et une fermeture réelle envoie toujours
+son paquet. Ce contrôle reste valable si la fenêtre de test est inactive.
+
+Côté client, le test place réellement le curseur sur le bouton puis clique
+trois fois sur Suivant et deux fois sur Précédent sans le déplacer. Sa
+position est vérifiée après chaque page, après une recherche localisée en
+français et après chacun des trois onglets du Fourneau. Échap ferme le menu
+normalement côté client et côté serveur.
+
+Les essais existants passent également : 729 cases, deux joueurs utilisant
+le même stock, objets au curseur, identifiants périmés, transfert rapide,
+hoppers, démontage, casse, persistance et cuisson native partagée.
+Aucun serveur dédié lancé, aucune EULA acceptée, aucun monde personnel touché.
+
+Journaux : `build/fut088-before-client.log` (régression reproduite) et
+`build/fut088-client.log` (succès en 39 secondes). Le parcours reste activé
+par `-PsanctuaryMultiblocks084ClientTests=true` avec
+`-PsanctuaryClientTests=true -PsanctuaryQuickTests=true`.
+
+`check build assemblePack assembleTestPack` réussit en 2 min 23 s
+(124 tâches, 103 exécutées), avec le GameTest dédié explicitement exclu.
+Journal : `build/fut088-check.log`. Le reçu `build/fut088-artifact.json`
+vérifie les sources, le JAR, les archives normal/Test et la conservation de
+tous les assets beta.087. Seules `MultiblockMenu` et sa classe interne de
+transfert changent dans les classes compilées (décalage des lignes de debug
+pour cette dernière).
+
+Livraison locale : `build/Sanctuary-beta.088.mrpack` et
+`build/Sanctuary-Test-beta.088.mrpack`. Les archives beta.087 restent intactes.
+Aucun déploiement dans l'instance Prism ni sur le canal publié. Un essai LAN
+avec deux clients distincts reste à réaliser ; le test d'accès partagé utilise
+un second joueur serveur dans le client de développement.

docs/fut-textures-beta086.md

@@ -0,0 +1,51 @@
+# beta.086 — textures du Fût
+
+Le Fût assemblé reçoit les trois images originales de 48 × 48 pixels :
+côtés, dessus et dessous. Chacune couvre une face entière de trois blocs
+sur trois, avec 16 pixels par bloc et sans retouche de l'image.
+
+## Contrat avant implémentation
+
+Aucun changement de sauvegarde : les 27 barils et leurs 729 cases restent
+vanilla, avec le même registre d'appartenance et les mêmes données. Seul le
+modèle affiché change quand le Fût est assemblé. Les barils indépendants
+conservent le modèle du pack de ressources actif. Dissociation et casse
+rétablissent leur apparence. Les textures du Fourneau beta.085 sont conservées.
+
+Le Fût ajoute un paquet client `sanctuary:fut_appearance_v1` ; le paquet
+du Fourneau reste inchangé. Les deux utilisent la même mise en cache visuelle
+par chunk et le même rendu natif. Aucun paquet supplémentaire par tick,
+aucun stockage parallèle d'objets. Le pack intégré beta.070 reste inchangé ;
+les textures du Fût appartiennent aux assets du mod beta.086.
+
+## Rendu et vérifications
+
+Les modèles JSON se régénèrent avec `python3 tools/generate-fut-models.py`.
+Les PNG sources sont conservés dans `assets/sanctuary/textures/block/fut/`.
+Aucune variante ouverte n'a été fournie : le Fût conserve le même dessus
+pendant l'accès à son inventaire.
+
+`Fut086ClientChecks` a réussi dans un nouveau monde plat intégré : Fût et
+Fourneau voisins, modèles distincts, raccords des côtés/dessus/dessous,
+ouverture et prélèvement dans les 729 cases, rechargement des ressources,
+déchargement réel puis retour dans quatre chunks, dissociation et casse.
+Les objets conservés restent dans les mêmes barils physiques ; retirer la
+façade du Fût ne retire pas celle du Fourneau voisin.
+
+Journal du client : `build/fut086-client.log`. Captures natives :
+`build/fut086-screenshots/`, notamment `0001_fut086-top-side.png` et
+`0002_fut086-bottom-side.png`. Le Fût est suspendu dans cette scène de test
+pour que le dessous puisse être inspecté.
+
+`check build assemblePack assembleTestPack` a réussi en 2 min 36 s
+(124 tâches, 104 exécutées), sans serveur dédié ; journal
+`build/fut086-check.log`. Le reçu `build/fut086-artifact.json` vérifie
+l'identité des PNG, les 27 modèles, les sources embarquées et les archives,
+ainsi que la conservation de tous les assets beta.085 du Fourneau.
+
+Livraison locale : `build/Sanctuary-beta.086.mrpack` et
+`build/Sanctuary-Test-beta.086.mrpack`. Les archives beta.085 restent
+immuables. Aucun déploiement sur Prism ou sur le canal publié, aucun monde
+personnel modifié, aucune EULA acceptée. Les vérifications multijoueur
+avec deux clients distincts et avec un moteur de shaders tiers restent
+à effectuer séparément.

docs/gallery-generation-beta198.md

@@ -0,0 +1,101 @@
+# WG-GALLERY-198 — création Large interrompue par la galerie centrale
+
+Branche `codex/gallery-generation-beta198`, depuis beta.197. Minecraft 26.3,
+Fabric 0.19.5, Java 25. Retour R013 et journal `message-11.txt` fourni par le
+créateur : arrêt Windows à la création Large, graine `4736390610738281858`.
+
+## Cause et correction
+
+L'exception `No supported central gallery floor` dans `Cavern183.create`
+interrompt la décoration du premier chunk. Le repli beta.197 exige encore de
+la roche exactement en (0,0), sous la surface de cette même colonne. Sur cette
+graine, son sommet n'est qu'à Y=168 et presque toute la colonne traverse du
+vide, alors que les colonnes voisines possèdent des assises. L'erreur a été
+reproduite sur macOS avec la même graine avant modification. Ce journal ne
+montre pas une panne du pilote Vulkan ni un manque de mémoire.
+
+Les nouveaux profils beta.198 conservent d'abord toutes les recherches
+existantes. Un dernier repli ne s'exécute que lorsqu'elles échouent : il compare
+l'assise et la couverture sur l'emprise de la chambre, de Y=32 à Y=276, sans
+condition éliminatoire sur la seule colonne centrale. Au plus 12 250 sondes,
+une seule planification mise en cache par source de biomes. Même un puits
+entièrement vide conserve la salle et sa fondation locale existante, plutôt
+que d'annuler la création du monde. Dans ce cas limite, la chambre peut être
+ouverte sur le vide : ce correctif ne prétend pas créer une cavité fermée dans
+une roche absente.
+
+Le portail reste horizontal en X=0, Z=0. Les dimensions de la chambre,
+maçonnerie et règles du relief, de l’eau, des biomes et des minerais restent
+identiques.
+Aucun calcul régional d'hydrologie ajouté.
+
+## Sauvegardes et distribution
+
+`stable_gallery198` est un paramètre de codec additif, faux par défaut.
+Les trois nouveaux profils `shared_island198_{small,medium,large}` et le preset
+public Sanctuary l'activent. Les profils 196/197 restent présents et gardent
+leur comportement ; leur personnalisation conserve leur révision exacte.
+Les protections de spawn introduites en 197 restent actives en 197 et 198.
+
+Le pack de test est destiné à un **nouveau monde**. Une création interrompue
+beta.197 ne migre pas automatiquement en beta.198 : recréer un nouveau monde
+avec la même graine et la taille souhaitée. Aucun monde personnel modifié,
+aucun chunk régénéré, aucune publication du canal ni installation Prism.
+
+## Vérifications
+
+- Échec beta.197 reproduit dans `build/worldgen-lab/gallery198-baseline/`.
+- Tests synthétiques réussis : puits vide, appuis autour d'un centre vide,
+  fine couche haute, roche pleine, déterminisme et borne de calcul.
+- Matrice native réussie : Small/Medium/Large, graines 0, 17, 42,
+  `4736390610738281858` et `-9223372036854775808`. Plans répétés à l'identique ;
+  toutes les galeries admises par beta.197 conservent exactement leur plan.
+  Le nouveau repli s'active pour la graine du journal, dans les trois tailles.
+- Small, Medium et Large sur la graine fournie : création puis réouverture
+  réussies. Portail en `(0,183,0)`, trois salles accessibles, respectivement
+  1 927, 1 925 et 1 930 cellules accessibles ; géométrie et ornements identiques
+  après reprise. Démarrages serveur à froid : 18,4 / 24,2 / 21,1 secondes ;
+  ces mesures locales ne sont pas un temps de chargement garanti sous Windows.
+- Client intégré **Vulkan**, vue 8 chunks et mémoire Java 2 Gio : Large sur
+  la graine exacte, arrivée réelle en `(-15.5,254,-15.5)`, huit recherches
+  natives de spawn sur l’île. Parcours FR/EN des trois tailles, annulation,
+  aller-retour disque et maintien des révisions historiques 196 et 197.
+  Réussi en 1 min 2 s, trace `build/gallery198-client.log`.
+
+Commande du contrôle ciblé, rejouable dans un nouveau dossier :
+
+```sh
+python3 scripts/worldgen_lab.py verify --profile large \
+  --seed 4736390610738281858 --run galerie-regression-neuve \
+  --checks gallery198 --memory 2048
+```
+
+Les traces finales sont dans `build/worldgen-lab/gallery198-targeted/`.
+Le mode normal `--checks full` conserve toutes ses assertions. Son premier
+passage dans `gallery198-fixed/` a démarré correctement puis s'est arrêté sur
+un **autre contrôle de laboratoire** : le secteur émeraude contient 171 blocs,
+dont 120 exposés, contre le minimum attendu de 200. Ce seuil est uniquement
+vérifié par le banc de test, pas pendant une partie ordinaire. Ni l'assertion
+ni les minerais ne sont modifiés ici. La vérification complète de toutes les
+décorations sur cette graine reste donc ouverte ; seuls les contrôles ciblés
+explicitement indiqués sont déclarés réussis.
+
+Aucun essai effectué directement sous Windows ; le défaut du journal est
+reproduit avec le même générateur natif et la même graine sur cette machine.
+
+`./gradlew check build assemblePack assembleTestPack -PsanctuaryFocusedTests=menus`
+réussi en **4 min 27 s**, 139 tâches : contrôles purs dont le nouveau repli,
+quatre GameTests menus et assemblages. Journal : `build/gallery198-check-build.log`.
+Le parcours client utilise une instance de développement et ne produit pas de
+campagne de captures.
+
+Export local **Sanctuary-Test-beta.198.mrpack**, **12 282 084 octets**.
+SHA-256 : `647498a0da3330ce0483e65fe6510ec8d09b6975365261fe59a57d61f3ef0688`.
+Archive ZIP, versions, dépendances et classes de chaque JAR vérifiées contre
+le build. Toutes les anciennes ressources de données restent identiques à
+beta.197, sauf le preset public qui sélectionne maintenant Medium beta.198.
+Les nouvelles ressources activent explicitement le correctif ; les anciens
+profils ne le font pas. Les tests natifs finaux correspondent à l'empreinte
+finale des sources de génération. Reçu : `build/gallery198-artifact.json`.
+Copie et guide dans `Downloads/`, sans sauvegarde, réglage personnel ni journal
+inclus dans l'archive.

docs/gazette-photos-beta157.md

@@ -0,0 +1,96 @@
+# beta.157 — photo obligatoire et galerie de captures
+
+## Contrat de migration communautaire v2
+
+La génération, les chunks et les sauvegardes Minecraft ne changent pas.
+Seul le document communautaire évolue : champ `photo`, JPEG encodé en base64,
+48 Kio binaires maximum, dimensions de 1 × 1 à 960 × 540 pixels.
+Les captures originales ne sont jamais modifiées. Les copies destinées à la Gazette
+sont redimensionnées et réencodées, sans métadonnées, avant transmission.
+
+Les nouveaux articles exigent une photo valide. Les articles v1 restent lisibles ;
+leur prochaine modification exige une photo. Avis, intendance et réponses restent
+textuels. La modération ne nécessite pas d'ajouter une photo à un ancien article.
+La photo est enregistrée atomiquement avec le texte, auteur et révision ; pas de
+référence à un chemin local, d'URL distante ou de média orphelin persistant.
+
+Fichier : v1 est lu sans modification. À la première écriture réussie, une copie
+exacte `sanctuary-community.json.v1.bak` est créée sans écrasement, puis le document
+v2 est écrit atomiquement. Un backup différent bloque la migration. La limite de
+64 Mio du document reste appliquée, photos comprises. Un retour à beta.156 exige
+de restaurer la copie v1 et perd les changements communautaires postérieurs.
+Ne pas restaurer pendant que le serveur tourne.
+
+MariaDB : arrêter les écritures du site et du serveur, sauvegarder la base, exécuter
+explicitement `community/schema-v1-to-v2.sql` ou la migration Laravel équivalente,
+puis lancer les deux applications v2. Migration additive : colonne `photo` nullable,
+aucune suppression ni réécriture des articles existants. Le mod n'exécute aucune
+migration SQL au démarrage. Les applications v1 refusent le schéma v2. Pas de
+rollback automatique destructif ; restaurer la sauvegarde avec les deux logiciels
+v1 si nécessaire. Aucun changement n'est appliqué aux bases ou mondes personnels
+par la préparation de cette livraison.
+
+Réseau : canaux v1 conservés, action `photo` par fragments de 8 000 caractères,
+au plus 9 fragments et 65 536 caractères, accusés un par un. Une seule photo
+transitoire par joueur, liée à l'UUID de publication, expire après deux minutes ;
+limite globale de 128 transferts. Les listes ne transportent pas les photos ;
+seul le détail d'un article les contient. Le plafond des réponses
+passe à 262 144 caractères pour une photo et une discussion complète ; les
+clients et le serveur doivent être mis à jour ensemble vers beta.157. Les
+anciens clients ne peuvent plus créer d'article sans photo.
+
+Galerie : grille de 2 ou 3 colonnes selon la taille d'interface, molette et barre
+native, 24 captures par page parmi les 4 096 PNG les plus récents par nom, lecture
+en arrière-plan. Aperçu puis assignation explicite ; Annuler conserve le brouillon.
+Les captures illisibles restent visibles mais désactivées. Limites sources :
+32 Mio, 8 192 pixels par axe et 32 millions de pixels. Textures libérées à la
+fermeture. Le site accepte PNG/JPEG et nécessite PHP GD ; le mod propose les PNG
+du dossier `screenshots` de son instance.
+
+## Vérifications
+
+- Tests natifs Vulkan Minecraft 26.3 : galerie FR/EN aux échelles 2/3/4,
+  molette, pagination, aperçu, annulation avec brouillon conservé, bouton Publier
+  désactivé sans photo, envoi fragmenté, photo visible et relecture après
+  réouverture de l'adaptateur. Parcours réussi en fichier et MariaDB.
+- Tests métier : photo manquante/invalide, révision, auteur, conservation après
+  modification, reprise idempotente, redémarrage fichier/SQL, ancien article v1,
+  copie de migration exacte, fragments hors ordre/incomplets/expirés.
+- Site : 17 tests HTTP, 97 assertions réussies ; photo obligatoire, faux fichier,
+  dimensions refusées, réduction, lecture, isolement serveur, auteur, masquage,
+  anciennes publications et conservation après modification.
+- Échange réel Java/PHP sur une MariaDB isolée : création en jeu lue par le site,
+  modification et réponse Web relues en Java, article/photo du site décodés par
+  Java. Migration Laravel et alternative SQL testées sur bases de développement.
+- `./gradlew check build assemblePack` : 252 GameTests serveur terminés en
+  3,457 minutes, 229 réussis et les mêmes 23 échecs que la baseline beta.154/155
+  (liste comparée intégralement, aucun nouvel identifiant en échec). La commande
+  générale échoue donc après 6 min 59 s ; cette limite préexistante reste ouverte.
+- Régression native du menu pause : FR/EN, échelles 2/3/4, carte, défilements
+  indépendants, pagination, article et avis longs, réponse, options et reprise :
+  réussie avec les articles munis d'une photo.
+- Construction et assemblage séparés, sans relancer les 23 GameTests connus :
+  `check build assemblePack -x :sanctuary:runGameTest` réussit (avec le parcours
+  client natif du menu pause), 2 min 56 s.
+
+Les captures d'essai sont des mires générées dans une instance de développement,
+sans accès aux captures ou sauvegardes personnelles. Pas de déploiement sur le
+site public, serveur personnel, canal packwiz ou Prism. Les JAR beta.154–156
+restent présents ; JAR et MRpack beta.156 gardent leurs empreintes antérieures.
+
+
+Le site correspondant est sur `codex/community-photos`, commits `e3ae3eb` et
+`9626e95`, sans push ni publication. Logs de développement :
+`build/photos157-client-file.log`, `build/photos157-client-database.log`,
+`build/photos157-interop-*.log`, `build/photos157-check-build.log` et
+`build/photos157-final-build.log`.
+
+## Artefacts locaux
+
+JAR `mods/sanctuary/build/libs/sanctuary-beta.157.jar` et pack
+`build/Sanctuary-beta.157.mrpack`, versions et JAR embarqué vérifiés.
+Les 29 ressources de shaders sont identiques à beta.156 (socle beta.151).
+Reçu complet : `build/photos157-validation.json`.
+
+- SHA-256 mods/sanctuary/build/libs/sanctuary-beta.157.jar: `96ff6d22ab593eb113cde63239ff4839f6a75b9a165fbec93a0aaab3c09dee7c`.
+- SHA-256 build/Sanctuary-beta.157.mrpack: `b03da5f67a3dcf8051666641dccd379a52b8c3c09308e1654b00440a37693e96`.

docs/gazette-scene-beta165.md

@@ -0,0 +1,26 @@
+# beta.165 — Gazette en article et conversation
+
+Photo en tête, titre et description dessous dans le même conteneur sombre.
+Auteur, visage, date et actions sous le conteneur. Réponses à droite avec
+défilement indépendant et saisie fixe ; sur GUI étroit, réponses sous l’article.
+Retour et Actualiser restent en haut, comme pour le tableau.
+
+Interface cliente uniquement, sans changement de stockage ni de monde.
+Test client Vulkan réussi en FR/EN aux échelles GUI 2, 3 et 4 :
+position du panneau de réponses, repli sous l’article, défilement disponible,
+brouillon conservé après redimensionnement et réponse envoyée puis relue.
+Le scénario existant du tableau et celui du menu pause passent également.
+Captures conservées dans `build/qa-beta165/` (image synthétique de test).
+Inspection visuelle FR GUI 2 et GUI 4 effectuée.
+Journal : `build/beta165-client.log`.
+
+`check build assemblePack --continue` exécuté : mêmes 23 GameTests en échec
+qu’en beta.164, aucun nouvel échec. Comparaison enregistrée dans
+`build/session165-server-failures.json`. La vérification générale reste en échec.
+Assemblage séparé réussi avec `build assemblePack :sanctuary-test:exportDuoLaunch
+-x :sanctuary:check` après cette vérification.
+
+JAR local : `mods/sanctuary/build/libs/sanctuary-beta.165.jar`.
+SHA-256 : `03a954caf68089862b1d237dcf1ebaa501e3ce3cfedb1f5184e9412e73fd711d`.
+Anciens JAR conservés ; aucune publication distante.
+

docs/gems-beta126.md

@@ -0,0 +1,152 @@
+# GEM-01 — Gemmes, argile et découvertes — beta.126
+
+Contrat du 17 septembre 2026, branche `codex/gems-beta126`, Minecraft 26.3.
+
+Deux gemmes natives complètent l'émeraude : `sanctuary:ruby` et
+`sanctuary:sapphire`. Chaque famille comprend un bloc de stockage, un minerai
+ordinaire et un minerai des abîmes. Les huit PNG du créateur sont copiés à
+l'identique ; leurs empreintes figurent dans `tools/gems-textures-beta126.json`.
+Les noms des fichiers français `saphir` sont associés aux identifiants anglais
+stables `sapphire`, sans modifier les pixels. Les deux items utilisent les fichiers de remplacement
+`Desktop/ruby.png` et `Desktop/saphir.png` fournis en fin de livraison.
+
+L'ordre créatif est émeraude, rubis, saphir : ingrédients, blocs de stockage,
+minerais ordinaires et minerais des abîmes dans leurs onglets natifs respectifs.
+Minage à la pioche de fer ou mieux, résistance et expérience comme l'émeraude,
+Fortune, Toucher de soie, cuisson/four à fusion et conversion 9 gemmes ↔ 1 bloc.
+Les blocs peuvent former un socle de balise et les gemmes servir de paiement.
+Les recettes rejoignent la collection actuelle de l'émeraude, sans ajouter de
+transactions de villageois. Libellés français et anglais, tags communs `c:`.
+
+## Génération procédurale et contrat de compatibilité
+
+Profil initial **gemmes 1 / beta.126** : quatre tentatives par chunk et par
+gemme, filons natifs de taille 3, hauteur uniforme Y0–256, probabilité de rejet
+au contact de l'air de 0,25. Ces nombres sont un réglage initial à équilibrer
+lors de la future refonte ; aucun quota de gemmes par chunk n'est garanti.
+Les variantes ordinaires remplacent les roches du tag vanilla
+`stone_ore_replaceables`, les variantes des abîmes celles de
+`deepslate_ore_replaceables`.
+
+Les fichiers `worldgen/feature/ore_<gemme>.json`,
+`worldgen/placed_feature/ore_<gemme>.json` et les tags de biomes
+`has_ore/<gemme>` séparent les cibles, la forme, la fréquence, la hauteur et
+les régions. Un datapack peut les remplacer sans recompiler le mod. Le code
+réutilise `OreFeature` et le hasard natif issu de la graine ; il limite ces
+filons aux mondes utilisant `SanctuaryChunkGenerator`. Les biomes vanilla
+partagés avec Sanctuary restent compatibles sans ajouter les gemmes aux
+mondes vanilla, au Nether ou à l'End.
+
+Cette évolution additive est autorisée pour les **nouveaux chunks uniquement**.
+Aucun remplissage rétrospectif, aucune régénération, aucun remplacement de chunk
+sauvegardé ni activation d'expansion. Les codecs du relief, les dimensions et
+le format des sauvegardes restent inchangés. Les filons suivent les protections
+existantes de la décoration native. Les anciens profils expérimentaux précédant
+le générateur Sanctuary unifié ne sont pas étendus.
+
+## Argile spéciale dans le Clay Workshop
+
+Le bloc d'argile vanilla conserve les couleurs échantillonnées sur le modèle
+original, animal découvert ou import GLB. Les argiles colorées et les autres
+blocs continuent à transférer leur palette de texture. Une même règle est
+appliquée à l'aperçu client et au résultat serveur. Le changement de matériau
+invalide le résultat même si les deux palettes sont identiques. Le texte de
+l'atelier explique l'exception en français et en anglais.
+
+Une sculpture coûte toujours un bloc ; aucune recette, découverte, donnée de
+sculpture déjà fabriquée ni règle de placement n'est modifiée.
+
+## Commande de découverte commune
+
+`/sanctuary discovery all` découvre tous les blocs, objets et espèces enregistrés.
+Les variantes `blocks all`, `items all` et `mobs all` ciblent une catégorie ;
+`block <identifiant>`, `item <identifiant>` et `mob <identifiant>` ciblent une
+entrée avec la complétion native. Un sélecteur de joueurs en fin de commande
+est facultatif ; sans cible, elle s'applique au joueur qui l'exécute.
+
+Exemples :
+
+```mcfunction
+/sanctuary discovery all
+/sanctuary discovery mobs all
+/sanctuary discovery block minecraft:stone
+/sanctuary discovery item minecraft:diamond
+/sanctuary discovery mob minecraft:cow
+/sanctuary discovery all @a
+```
+
+La permission suit « Autoriser les commandes » en solo et les droits opérateur
+sur serveur. La console doit préciser la cible. Les identifiants invalides,
+l'air et les types d'entités sans espèce découvrable sont refusés.
+
+Les blocs passent par le registre de découvertes et son événement existant ;
+les objets passent par `RecipeService.discover`. Les collections et recettes
+sont ensuite recalculées normalement. Les espèces rejoignent `seen_mobs`,
+la même donnée que l'observation naturelle, consommée par les familiers,
+le Métabli et le Clay Workshop. Il n'existe aucun drapeau de déblocage parallèle.
+Les catalogues déjà ouverts sont à rouvrir après la commande.
+
+La commande conserve les quantités possédées et les compteurs de combat,
+minage, pose et fabrication. Elle ne donne pas d'objets, n'achète pas les skills
+et n'attribue pas d'advancements. Les recettes réservées aux opérateurs gardent
+leurs règles. Les historiques personnels sont enrichis sans changer leur
+schéma ; la commande refuse les données illisibles plutôt que les remplacer.
+
+## Vérifications
+
+Client natif Minecraft 26.3 / Java 25, `Gems126ClientChecks`, réussi en
+1 min 08 s. Les mondes sont jetables, sans sauvegarde personnelle ouverte :
+
+- Les huit items et six blocs sont présents, avec les huit textures exactes.
+  Quatre groupes créatifs respectent émeraude → rubis → saphir, sans doublons.
+- Douze recettes natives, découverte du bloc de stockage, outil fer minimum,
+  Fortune III, Toucher de soie et balises passent les contrôles serveur.
+- Graine **126**, profil gemmes 1, 81 chunks autour de l'origine : 7 rubis dans
+  la pierre et 8 dans la roche des abîmes ; 15 saphirs dans la pierre et 10 dans
+  la roche des abîmes. La génération est refusée dans le monde plat vanilla.
+  Les minerais persistent à la reconnexion, et un minerai retiré ne réapparaît pas.
+- L'argile conserve exactement les couleurs des voxels d'une vache et d'un GLB
+  texturé. Bois et argile colorée transfèrent toujours leur palette. Le retour
+  à l'argile, l'égalité aperçu/résultat et le coût d'un bloc en survie sont vérifiés.
+- La commande native respecte « Autoriser les commandes », accepte une cible
+  et la console, refuse les identifiants invalides et permet une espèce, un
+  bloc, un objet, toutes les espèces ou tout le contenu. Les recettes liées
+  sont recalculées. La répétition est idempotente et les découvertes survivent
+  à la reconnexion sans inventer de compteurs de combat ou de possession.
+
+Logs et captures dans `build/gems126-client.log` et
+`mods/sanctuary/build/run/clientGameTest/screenshots/`. Le GameTest dédié
+reste exclu conformément au refus antérieur de son EULA. Le build complet et
+les archives sont vérifiés séparément avant publication.
+
+
+Build final `./gradlew check build assemblePack assembleTestPack
+-x :sanctuary:runGameTest` réussi en **2 min 10 s**, 126 tâches. Les contrôles
+natifs de gameplay précèdent uniquement le remplacement final des deux PNG
+d'items ; les huit fichiers livrés sont vérifiés à l'octet près contre les
+sources, tous en 16 × 16. Les JAR de sources correspondent aux sources courantes.
+L'audit entre les binaires beta.125 et beta.126 ne trouve que les 112 entrées
+de production prévues. Les archives normal/Test contiennent le même mod et
+le template reproduit exactement ses ressources exportables.
+
+| Artefact | SHA-256 |
+| --- | --- |
+| `Sanctuary-beta.126.mrpack` | `716221ce24549781ab91f5437ad2310497b198a4b61c43c40c67a27984365ae5` |
+| `Sanctuary-Test-beta.126.mrpack` | `bbf22d7dd72e6746538b4ec28686f699225d4a59372304e5db42140a80e88bd1` |
+| `sanctuary-beta.126.jar` | `85dbe1b41d98751029bb62e87d259522f8609758896c797b1e02fa7656ec0342` |
+
+## Publication et synchronisation
+
+[Release beta.126](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.126)
+publiée depuis `99860af312a1737d938812f3515fcc4acb4291b2` ; artefacts
+immuables retéléchargés et vérifiés. Canal packwiz : `31749b95d21ce5bced6b9e5759499da6f8a67e6e`.
+Deux synchronisations isolées, puis deux synchronisations de l'instance existante
+**Sanctuary Beta** ont réussi. Un seul JAR Sanctuary beta.126, correspondant
+à l'empreinte ci-dessus. Les **923 fichiers personnels** suivis sont conservés,
+sauvegardes restées fermées ; copie préalable dans
+`sanctuary-backups/before-beta.126/`.
+
+Packs normal/Test et template copiés et vérifiés dans
+`sanctuary-beta/build/`. Reçus locaux : `build/gems126-artifact.json`,
+`build/gems126-isolated.json`, `build/gems126-prism.json` et
+`build/gems126-publication.log`.

docs/git-sync-beta061.md

@@ -0,0 +1,50 @@
+# Synchronisation Git jusqu’à beta.061
+
+Ticket du 15 septembre 2026, branche `codex/git-sync-beta061`.
+
+La livraison beta.061 s’est terminée pendant le
+[rattrapage Git beta.060](git-sync-beta060.md). Ses sources finales sont
+enregistrées dans un second commit, au-dessus du point de sauvegarde beta.060.
+Les tags `beta.060` et `beta.061` désignent ces deux états ; `main` rejoint
+beta.061 par avance directe, sans réécriture de l’historique.
+
+Le numéro reste celui de la livraison existante. Aucun changement de gameplay
+n’est ajouté par cette synchronisation. Les références courantes du README
+et de l’exemple d’export packwiz sont actualisées.
+
+## Validation des sources livrées
+
+Les sources et tests sont copiés après la fin de la tâche
+`codex/intro-familiar-mount-beta061`. Son
+[compte rendu de livraison](arrival-mount-beta061.md#vérifications), vérifié
+dans les journaux locaux, donne :
+
+- `check build assemblePack assembleTestPack` avec la sélection beta.061
+  et `-x :sanctuary:runGameTest` : réussite en 3 min 14 s, 122 tâches.
+- Parcours client natif `ArrivalMount061ClientChecks` : réussite en
+  1 min 32 s, marqueurs `ARRIVAL061_MUSIC_PASS` et `ARRIVAL_MOUNT061_PASS`.
+- Reçu `build/arrival-mount061-artifact.json` : 1 623 classes Sanctuary,
+  ressources, dépendances et conservation des archives beta.060 vérifiées.
+
+La copie destinée à Git est ensuite reconstruite dans le worktree isolé avec
+`assemblePack assembleTestPack`, en excluant les tâches `check` déjà exécutées
+sur les sources livrées. La comparaison des JAR contrôle que cette copie
+produit le même code que la livraison testée. La reconstruction réussit en
+**15 s**, avec **21 tâches** ; tous les contenus des entrées du JAR sont
+strictement identiques, y compris les 1 623 classes, les ressources, les
+métadonnées et les dépendances imbriquées.
+
+Reçus locaux : `build/git-sync-beta061-verification.json` et
+`build/git-sync-beta061-assemble.log`. Les empreintes des deux archives
+MRpack originales sont également conformes au reçu de livraison.
+
+La suite serveur générale a été exécutée sur beta.060 pendant ce rattrapage :
+**235 réussites sur 246**, avec [11 échecs consignés](git-sync-beta060.md#vérifications).
+Ces scénarios restent à trier ; le parcours ciblé beta.061 ne constitue pas
+une nouvelle exécution ni une réussite de cette suite générale.
+
+## Distribution
+
+Cette opération publie les sources et leurs tags sur le Git du projet.
+Les archives bêta restent locales, le canal packwiz reste sur alpha.30.7,
+et aucune instance Prism ou sauvegarde personnelle n’est modifiée.

docs/git-sync-beta092.md

@@ -0,0 +1,77 @@
+# Synchronisation Git jusqu’à beta.092
+
+Ticket du 16 septembre 2026, branche `codex/git-sync-beta092`.
+
+Le dépôt distant était resté sur [beta.061](git-sync-beta061.md). Cette
+synchronisation enregistre les sources, ressources, outils et comptes rendus
+locaux jusqu’à la livraison **beta.092**, pour **Minecraft 26.3**. Elle inclut
+le commit déjà local du resource pack beta.070. `main` avance directement et
+le tag exact `beta.092` désigne les sources de la livraison vérifiée.
+
+Le compteur reste à beta.092 : ce rattrapage n’ajoute aucun changement de jeu.
+Les documents de conception restent des intentions, selon leurs contrats.
+Les anciens tags et les posts de release existants sont conservés. Les versions
+intermédiaires ne reçoivent pas artificiellement un tag pointant sur beta.092.
+
+## Sources et vérifications
+
+Une copie des 2 636 fichiers sources non ignorés est figée dans un worktree
+isolé, sans modifier les fichiers de travail. Les JAR générés, archives ZIP,
+MRpack, sauvegardes et dépendances téléchargées restent ignorés ; seul le
+wrapper Gradle est versionné. Les références courantes des README sont mises
+à jour, avec ce compte rendu.
+
+Les journaux et le reçu de la [livraison beta.092](multiblock-pick-beta092.md)
+confirment :
+
+- `./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+  réussi en **3 min 1 s**, **124 tâches**.
+- Parcours client natif `Pick092ClientChecks` réussi en **1 min 19 s**, avec
+  `PICK092_PASS` : **864 états**, douze combinaisons normal/gluant et six
+  directions, vrais clics molette, inventaire de survie, parties mobiles et
+  Ctrl + clic sans données techniques.
+- Les empreintes des deux MRpack locaux correspondent au reçu de livraison.
+
+La copie destinée à Git est reconstruite sous Java 25 avec :
+
+```sh
+./gradlew assemblePack assembleTestPack \
+  -x :sanctuary:check -x :demeure:check \
+  -x :jei:check -x :sanctuary-test:check
+```
+
+Réussite en **48 s**, **23 tâches**. Les contrôles déjà réussis sur la livraison
+ne sont pas relancés pour cette copie. La vérification des manifestes packwiz
+et des ressources graphiques passe pendant l’assemblage. Les quatre JAR
+reconstruits sont **identiques octet pour octet** à ceux de la livraison :
+
+| JAR | Entrées | Classes |
+| --- | ---: | ---: |
+| Sanctuary beta.092 | 2 960 | 1 753 |
+| Demeure beta.092 | 24 | 14 |
+| Sanctuary Test beta.092 | 25 | 3 |
+| JEI 30.32.0-sanctuary.3 pour 26.3 | 1 378 | 1 101 |
+
+Les 811 fichiers Java des trois modules Sanctuary, Demeure et Test correspondent
+également aux archives de sources de la livraison. Les ressources, métadonnées
+et dépendances imbriquées sont incluses dans la comparaison des JAR.
+
+SHA-256 du JAR Sanctuary :
+`8eb91eb41d0236ac6d6d064e9638c99802d28a2d83b8aef5ff1291c9495bcc8c`.
+
+Reçus locaux ignorés : `build/git-sync-beta092-verification.json`,
+`build/git-sync-beta092-assemble.log`, `build/pick092-artifact.json`,
+`build/pick092-check.log` et `build/pick092-client.log`.
+
+## Limites et distribution
+
+Les essais beta.092 utilisent un client macOS et son serveur intégré ; pas de
+session LAN à deux clients. Le serveur GameTest dédié est exclu et aucune EULA
+n’est acceptée. La dernière exécution générale consignée dans le rattrapage
+[beta.060](git-sync-beta060.md#vérifications) comptait 235 réussites sur 246,
+avec 11 échecs à trier ; elle ne constitue pas une validation de beta.092.
+Cette synchronisation ne prétend pas résoudre ces échecs ni valider Windows/Linux.
+
+Les sources et leur tag sont publiés sur Git. Les archives bêta restent locales,
+le canal packwiz reste sur alpha.30.7 et aucune instance Prism, sauvegarde
+personnelle ou installation de serveur n’est modifiée.

docs/golden-wrench-beta120.md

@@ -0,0 +1,109 @@
+# TOOL-01 — Clé dorée et états de blocs — beta.120
+
+Contrat du 17 septembre 2026, branche `codex/golden-wrench-beta120`.
+Le créateur valide les gestes du debug stick : clic gauche choisit la propriété,
+clic droit parcourt ses valeurs, Maj inverse le parcours. L'orientation est
+proposée en premier, puis les propriétés de forme et les autres états natifs.
+La sélection est personnelle, par type de bloc, pour la session courante.
+Une indication dans la barre d'action affiche la propriété et sa valeur.
+La clé ne casse pas le bloc, y compris en créatif, et ne remplace pas son type.
+
+Les propriétés natives sont disponibles en survie avec la clé, sans condition
+opérateur, dans le respect des droits de construction, protections, portée et
+verrous de conteneurs. Comme avec le debug stick, les formes choisies restent
+en place immédiatement ; les mises à jour ultérieures du jeu peuvent recalculer
+les états dynamiques (redstone, connexions, cultures…).
+
+Les multiblocs assemblés gardent leurs commandes d'ouverture/dissociation et
+leurs propriétés techniques ne sont pas éditées individuellement. Un assemblage
+complet garde priorité au clic droit ; Maj permet de régler les composants
+non assemblés. Hors d'un assemblage complet, même un four, un baril, un piston
+ou un établi reçoit l'action générique.
+
+## Rotation de texture et contrat de stockage
+
+La terre n'a pas d'orientation dans son blockstate vanilla. Une propriété
+supplémentaire de la clé, « Rotation des textures », parcourt 0°, 90°, 180° et
+270° sur les faces des modèles de blocs. La géométrie, l'éclairage, les teintes,
+les ressources actives, le bloc, son inventaire et son butin restent natifs.
+Les rendus spéciaux d'entités de blocs ne sont pas transformés par ce réglage
+des faces ; leur orientation demeure modifiable par leurs états natifs.
+
+Nouvelle donnée facultative `sanctuary:wrench_textures_v1`, attachée au chunk :
+table immuable position entière → quart de tour (1 à 3). Une absence signifie
+0°. Elle n'est créée qu'après une action de clé ; revenir à 0° retire l'entrée,
+puis l'attachement s'il est vide. Aucun état vanilla ni format existant n'est
+modifié ; aucun parcours, conversion ou régénération des anciens mondes.
+Les modifications de blockstate du même type conservent la rotation. Casser,
+remplacer ou déplacer par piston retire la rotation à l'ancienne position ;
+les objets récupérés restent ordinaires. Les nouveaux clients la reçoivent
+après le chunk natif, par lots bornés de 1 024 entrées au maximum.
+Déconnexion, changement de dimension et déchargement libèrent le cache visuel.
+Revenir à une ancienne version du mod supprime seulement cet effet visuel ;
+les blocs conservent leurs identifiants, données et états natifs.
+
+## Vérifications et livraison
+
+Le parcours `Wrench120ClientChecks` passe en **47 s** sur Minecraft 26.3,
+client macOS et serveur intégré, dans un monde plat jetable de graine 120 :
+
+- **2 522 propriétés natives** parcourues, avec valeurs inverses et type conservé.
+- Vrais clics sur les escaliers : orientation, moitié supérieure et forme,
+  sans casser le bloc en créatif ; gestes inverses et sélection distincte.
+  Les doubles événements créatifs d'un même clic sont filtrés à la cadence
+  native de cinq ticks.
+- Terre en survie : rotation réelle des UV émis, positions des sommets et nombre
+  de faces identiques ; retour exact après quatre quarts de tour ou un inverse.
+- Rechargement des ressources conservant les UV tournés ; capture de terre relue.
+- Coffre tourné avec ses 23 diamants intacts, sans ouverture accidentelle.
+- Assemblage/dissociation par vrais clics des quatre familles : Métabli, Fût,
+  Fourneau et super piston. Un clic gauche sur un assemblage ne modifie pas
+  les numéros de composants ; barils et pistons isolés tournent normalement.
+- Refus en aventure, spectateur ou hors portée ; retrait des données visuelles
+  après remplacement, maintien lors d'un changement d'état du même bloc.
+- Sauvegarde/reconnexion : rotation de terre côté serveur et client, état
+  natif de l'escalier et inventaire du coffre conservés.
+
+```sh
+./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryWrench120ClientTests=true \
+  -PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true
+```
+
+Marqueurs `WRENCH120_PASS` et `WRENCH120_PROPERTIES 2522` dans
+`build/wrench120-client.log`, captures dans `build/wrench120-evidence/`.
+Aucun monde personnel ouvert ; pas de validation Windows ni depuis deux
+ordinateurs. Les rendus de faces natifs et le rechargement du pack sont vérifiés ;
+pas de validation spécifique d'un shader tiers.
+Le GameTest dédié reste exclu conformément au refus antérieur de son EULA.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+passe en **2 min 12 s**, 125 tâches. Les sources JAR correspondent exactement
+aux sources du dépôt. La comparaison avec beta.119 limite les différences de
+production aux classes de clé/assemblage, aux deux nouveaux hooks, au rendu
+et aux libellés prévus ; toutes les autres ressources sont identiques.
+Les packs normal/Test contiennent le même JAR Sanctuary et aucune sauvegarde
+ni fixture de test.
+
+- Sanctuary-beta.120.mrpack : 10237973 octets, SHA-256
+  `86b5e480a12ba20b5c1e308c77dbb54bdf8a56806915fb32ca2d16f9a72cc9c9`.
+- Sanctuary-Test-beta.120.mrpack : 10256895 octets, SHA-256
+  `2e3818483ba7dfa6e5652b97933e105a44e7cc4b269fc567116bf895d54bd8d9`.
+- JAR Sanctuary : SHA-256
+  `8e35ef0f134a46b7760604175ad768264946d31fdd0694982e049e7a928fde2a`.
+
+Reçu local : `build/wrench120-artifact.json`.
+
+## Publication et installation
+
+La [release beta.120](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.120)
+est publiée depuis `248dff47b7a0ebd11026230581fe69641dbde76d`. Le tag exact et les
+artefacts sont immuables ; leurs téléchargements publics sont vérifiés.
+Le canal packwiz avance à `e8060764a444a58b0a17318a3821dfeb1a0c33c6`.
+
+Deux synchronisations isolées puis deux dans **Sanctuary Beta** réussissent.
+Un seul JAR Sanctuary beta.120 est actif ; le second passage est identique.
+Les **923 fichiers personnels et réglages suivis** restent inchangés, sans
+ouvrir de monde personnel. Copie préalable dans
+`sanctuary-backups/before-beta.120/` de l'instance existante. Reçus locaux :
+`build/wrench120-isolated.json` et `build/wrench120-prism.json`.

docs/head-render-beta066.md

@@ -0,0 +1,65 @@
+# beta.066 — cosmétiques animés sans doublon
+
+Branche `codex/cosmetic-render-beta066`.
+
+## Contrat
+
+Un coffre porté n'affiche qu'un coffre : son couvercle s'ouvre et se ferme
+sans laisser un second coffre fermé dessous. Une cloche portée conserve
+son support et une seule cloche qui oscille. Le même correctif s'applique
+aux modèles partagés avec les mobs portant un cosmétique.
+
+Minecraft 26.3 distingue la géométrie du bloc posé de son modèle isolé.
+Ce dernier peut déjà inclure un coffre fermé, une cloche fixe ou un livre.
+Sanctuary dessinait ce modèle isolé puis le rendu animé de l'entité de bloc.
+Le rendu avec une entité de bloc utilise désormais la géométrie native du
+bloc posé pour ses parties fixes, avec les teintes et la lumière du bloc,
+puis l'entité de bloc pour les parties animées.
+
+Les panneaux conservent leur modèle isolé : Sanctuary soumet séparément
+leur texte, pas une deuxième planche. Les bannières et les têtes conservent
+leur rendu personnalisé ; les lits et portes gardent leurs deux moitiés.
+Le feu de camp conserve sa base et les aliments synchronisés. Aucun asset
+n'est remplacé. Aucun changement serveur, d'interaction, de stockage,
+de sauvegarde ou de génération.
+
+## Vérification
+
+Le parcours `Cosmetic066ClientChecks` crée un monde plat de développement,
+utilise les modèles et le collecteur de rendu natifs, et reçoit les événements
+du serveur intégré. Avant correction, le test reproduit deux soumissions
+`ChestModel` pour un seul cosmétique ouvert. Après correction, les
+contrôles n'en comptent plus qu'une.
+
+Le parcours client réussit en 40 secondes :
+
+- coffres normal, piégé, de l'Ender et Shulker : une seule représentation,
+  ouverture et fermeture issues des événements serveur ;
+- cloche : un seul modèle animé, un support fixe, oscillation puis arrêt ;
+- feu de camp : base conservée et aliment reçu du serveur visible ;
+- table d'enchantement : un seul livre sur sa base ; panneaux, bannière,
+  tête de joueur, lit complet, porte complète, four et étagère conservés ;
+- douze cas de coffres/cloches sur poules, vaches et zombies adultes ou bébés.
+
+Le test compte les soumissions réelles de modèles, pas seulement la présence
+d'un état d'animation. Les captures avant/après du coffre et celle de la cloche corrigée ont
+été relues dans `build/cosmetic066-evidence/`.
+
+Journaux : `build/cosmetic066-before.log`, `build/cosmetic066-client.log`.
+`./gradlew check build assemblePack assembleTestPack` réussit en 2 min 22 s
+avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
+-PsanctuaryQuickTests=true`. Le parcours client dédié utilise aussi
+`-PsanctuaryCosmetic066ClientTests=true -PsanctuaryClientNoVsync=true`.
+Les tests avec serveur dédié restent exclus ; la validation des animations
+utilise le serveur intégré du client.
+
+Les deux archives sont vérifiées contre les 1 645 classes et les ressources
+compilées. Seul `HeadCosmeticModels` change dans les sources principales
+par rapport à beta.065. Les textures, JEI et les archives beta.065 restent
+identiques. Le code de Demeure reste identique ; sa version suit le pack.
+Reçu : `build/cosmetic066-artifact.json` ; build : `build/cosmetic066-check.log`.
+
+[Pack normal](../build/Sanctuary-beta.066.mrpack) ·
+[Monde plat rapide](../build/Sanctuary-Test-beta.066.mrpack).
+Archives locales, sans publication du canal ni déploiement personnel.
+Une session avec plusieurs clients distants n'a pas été relancée.

docs/hidden-anchors-beta186.md

@@ -0,0 +1,125 @@
+# ANCHORS-186 — rosaces ornementées et huit refuges
+
+Ticket du 30 septembre 2026, branche `codex/hidden-anchors-beta186`.
+Retour sur beta.185 : retirer les barrières supérieures, conserver la silhouette,
+ajouter de fins liserés au verre et intégrer huit ancres dans le terrain de leur
+secteur de couleur, en surface, en grotte et sur les récifs.
+
+## Contrat
+
+Nouveau laboratoire `anchors`, preset `sanctuary_test:hidden_anchors_v1`,
+graine de visite 42, beta.186. Génération déterministe, recherche bornée dans
+le champ de densité existant et écritures limitées au chunk en décoration.
+Aucune régénération des visites précédentes ni modification des anciens presets.
+Les huit couleurs reprennent la palette du Bugrock, dans le même ordre
+que les rosaces. Les ancres conservent le bloc et ses propriétés existantes.
+
+Les dépôts distincts restent locaux à ce prototype : ils allument l'ancre et
+sa gemme sur le Bugrock ; ils ne génèrent pas encore d'expansion. Les coûts
+sont des matériaux accessibles sur l'île, sans or ni redstone.
+
+## Réalisation
+
+Le balcon supérieur perd ses murets. Deux liserés alternent calcite et cuivre
+patiné sur chaque dôme, en remplaçant une mince bande de verre. Huit petits
+losanges ponctuent les grandes verrières. Le volume, les couleurs dominantes,
+la tige d'un bloc, le Bugrock à Y=640, le portail de toiture et l'atlas restent
+ceux de beta.185. Les passages sur les huit axes restent dégagés.
+
+La recherche échantillonne une grille finie et les grands récifs existants.
+Elle exige une base rocheuse et un débouché naturel praticable. Deux secteurs
+aériens sont retenus lorsqu'ils disposent de récifs compatibles ; les autres
+privilégient alternativement une grotte ou la surface, avec repli sur un autre
+emplacement naturel admissible du même secteur. Le choix varie avec la graine.
+Le manque de site sûr fait échouer ce laboratoire explicitement plutôt que de
+fabriquer une ancre au-dessus du vide. Seule la graine de visite est certifiée.
+
+Les refuges sont de petites poches irrégulières : sol légèrement ondulé,
+reliefs dans la roche présente, accès court décalé, crêtes érodées, mousse,
+azalées et verre de couleur au piédestal. Certains reliefs cachent une source
+de lumière, d'autres restent sombres. Les réservations évitent la galerie,
+le donjon, le soufre et les bassins connus. Elles empêchent aussi la décoration
+d'un chunk voisin de reboucher les volumes, sans bloquer les actions des joueurs.
+Aucun calcul d'hydrologie régionale ni recherche par tick n'est ajouté.
+
+| Secteur | Couleur | Dépôt en main |
+| --- | --- | --- |
+| Nord | Bleu clair | 32 pierres |
+| Nord-est | Vert clair | 16 bûches de chêne |
+| Est | Vert | 16 blés |
+| Sud-est | Orange | 16 lingots de cuivre |
+| Sud | Rouge | 16 charbons |
+| Sud-ouest | Magenta | 8 éclats d'améthyste |
+| Ouest | Jaune | 8 lingots de fer |
+| Nord-ouest | Cyan | 16 verres |
+
+Clic droit sur l'ancre : le serveur valide le site, le matériau et la quantité.
+Un dépôt exact allume l'ancre et le bit de couleur associé au Bugrock. Les
+états restent dans les propriétés natives des blocs ; aucune nouvelle base de
+progression ou migration. Les textes FR/EN existants sont réutilisés. Le
+profil 173 et ses anciens coûts ne sont pas modifiés.
+
+## Vérification
+
+Premier contrôle natif réussi sur `solo186b/anchors/42` : huit ancres, deux
+récifs aériens, deux grottes et quatre surfaces/flancs. Plan déterministe de
+8 650 entrées dans 26 chunks, calculé en 2,3 s. Huit dépôts vérifiés dans un
+ordre non séquentiel ; tous les bits sont indépendants, les mauvais dépôts et
+les répétitions conservent les objets. Les états initiaux sont restaurés après
+ce test, avant la sauvegarde de visite.
+
+Palais : 144 murets retirés, 384 blocs de liserés/losanges incrustés,
+4 944 blocs de verre conservés, seize approches libres. Le volume et le cadre
+du portail restent inchangés. Les huit teintes existent dans les deux rosaces.
+
+La première réouverture a révélé un ancien contrôle de cerisiers basé sur un
+compteur de génération en mémoire. Le contrôle lit désormais les troncs déjà
+sauvegardés lorsqu'il n'y a pas de compteur ; aucun arbre n'est régénéré.
+Validation finale sur `solo186c/anchors/42` réussie à froid puis après
+réouverture : 567 échantillons de densité conservés et zéro région d'hydrologie.
+Démarrage serveur 6,9 s à froid / 0,66 s à chaud ; prêt avec l'ensemble des
+sondages et contrôles en 44,7 s / 6,4 s. Le plan des huit refuges prend 2,28 s
+à froid. Ces mesures incluent du travail de vérification et ne constituent pas
+une promesse de temps de chargement du client.
+
+Lecture de la sauvegarde arrêtée : huit ancres de secteurs 0 à 7, éteintes,
+Bugrock allumé avec masque de relais nul ; 49 cartes sauvegardées, complètes,
+figées, et cadres horizontaux uniques. Aucun dépôt de contrôle ne reste activé
+sur le monde proposé au créateur.
+
+Reçus ignorés : `build/anchors186-quick-result.json`,
+`build/anchors186-warm-result.json`, `build/anchors186-saved-blocks.json`,
+`build/anchors186-saved-atlas.json`.
+
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch`
+réussi en **6 min 49 s**, **265/265 GameTests**. Journal
+`build/anchors186-check-build.log`. Le daemon de compilation a été arrêté avant
+le client pour libérer la mémoire. Solo Vulkan ouvert le 30 septembre à **08:08:19**, vue 32 et simulation 12
+confirmées dans `build/anchors186-solo.log`. Contrôle de visibilité de la couronne
+réussi à 08:08:20. La fenêtre du jeu confirme le balcon sans murets et les
+vitrages reliés au soubassement. La visite est laissée au créateur sans téléportations d’inspection supplémentaires. L'aspect des huit
+refuges reste à apprécier ensemble en jeu. Aucun canal public ni instance
+Prism n'a été modifié.
+
+## Visite — graine 42
+
+Solo neuf `visite186/anchors/42`, `Sanctuary-Hidden-Anchors-186-Solo`,
+vue 32 chunks, simulation 12, créatif, vol et commandes ; départ dans le
+palais supérieur. Sauvegarde beta.185 conservée. Les emplacements suivants
+sont des raccourcis de test, pas des marqueurs visibles dans le jeu.
+
+| Secteur | Milieu | Lumière du refuge | Accès de visite |
+| --- | --- | --- | --- |
+
+
+
+| Nord | Surface / flanc | Lumineux | `/tp -71.5 243 -226.5 0 0` |
+| Nord-est | Surface / flanc | Sombre | `/tp 96.5 186 -82.5 0 0` |
+| Est | Récif aérien | Lumineux | `/tp 213.5 444 21.5 180 0` |
+| Sud-est | Surface / flanc | Sombre | `/tp 156.5 161 193.5 0 0` |
+| Sud | Grotte | Lumineux | `/tp -83.5 115 215.5 180 0` |
+| Sud-ouest | Surface / flanc | Sombre | `/tp -107.5 252 181.5 0 0` |
+| Ouest | Grotte | Lumineux | `/tp -96.5 223 24.5 90 0` |
+| Nord-ouest | Récif aérien | Sombre | `/tp -102.5 404 -171.5 90 0` |
+
+Palais : `/tp 6.5 1280 8.5 140 -15` ; Bugrock : `/tp 0.5 639 5.5 180 -20`.

docs/horde-cartes-beta168.md

@@ -0,0 +1,105 @@
+# beta.168 — laboratoire de trois cartes de horde
+
+**Actualisation beta.169 :** les [nouvelles cartes à invasion continue](horde-invasion-beta169.md)
+se révèlent en main, mélangent les espèces et accélèrent leurs apparitions. Les
+cartes beta.168 conservent les règles historiques décrites ci-dessous.
+
+Suite du [prototype beta.167](horde-lab-beta167.md), branche
+`codex/cartes-horde-beta168`. Minecraft 26.3, dépendances inchangées.
+
+## Décision de séance
+
+Le décor circulaire est conservé comme piste pour de futurs donjons. Le nouveau
+labo le reproduit **sans socle** : c'est la carte consommable qui invoque la horde
+à la position du joueur. Apparition immédiate, sans inscription, préparation,
+chef de groupe ni commande pour rejoindre. Les joueurs arrivent et combattent
+spontanément. Les récompenses sont des objets lâchés par les monstres : ramassage
+libre, sans attribution, partage automatique ni coffre final.
+
+## Essai jouable
+
+Trois cartes natives Minecraft, tenues à deux mains avec la main secondaire vide :
+
+| Carte | Vagues de zombies | Butins possibles |
+| --- | --- | --- |
+| Errants | 3 / 5 / 7 | Fer, émeraude |
+| Meute | 4 / 6 / 8 | Or, émeraude |
+| Légion | 6 / 9 / 12, un zombie sur deux casqué | Diamant, émeraude |
+
+Chaque exemplaire reçoit une graine et une illustration 128 × 128 persistante,
+verrouillée contre les mises à jour géographiques. Composition libre en palette de carte, sans cadre ni grille, à partir des
+visages texturés des zombies et des textures natives de butin. Positions continues,
+tailles et inclinaisons variées. Chaque visage correspond à **un monstre réel**
+sur les trois vagues : 15, 18 ou 27 visages ; les casques correspondent aux porteurs
+réels. Chaque icône de butin correspond aussi à un objet porté. La densité et les
+casques traduisent la difficulté. Ce rendu assemble des visages texturés, sans corps. Les trois familles ont des vagues fixes ; leur graine fait varier
+l'illustration, le choix des butins et leurs porteurs.
+
+Au moins un porteur de butin par vague ; les autres ont une chance sur quatre
+d'en porter. Chaque porteur laisse un seul objet, choisi à parts égales dans la
+paire annoncée. Les casques ne sont pas du butin. Pas d'XP économique ajoutée.
+Les butins déjà lâchés restent au sol si la horde est interrompue.
+
+Les joueurs dans les 15 blocs participent automatiquement ; partir ou mourir
+ne supprime pas la horde. Les nouveaux arrivants peuvent intervenir pendant
+n'importe quelle vague. Six secondes entre vagues, trois minutes maximum par
+vague ; disparition d'un monstre vivant ou sortie d'un monstre du périmètre
+interrompt et nettoie les survivants sans butin supplémentaire.
+
+L'emplacement des trois vagues est contrôlé avant consommation : chunks chargés,
+sol, collisions, absence de fluide et frontière. Une horde voisine bloque une
+nouvelle invocation. Les cartes copiées gardent la même identité : le registre
+serveur des identités consommées empêche une seconde invocation. Il utilise la
+sauvegarde native du monde ; aucune garantie transactionnelle supplémentaire en
+cas de coupure brutale avant sauvegarde n'est revendiquée dans ce labo.
+
+## Monde et lancement
+
+Nouveau dossier `build/horde-168/`, monde `horde-flat-168`, graine **168**, génération
+de scène **ready-v1**, port **127.0.0.1:25578**. L'ancien laboratoire beta.167 et ses
+sauvegardes sont conservés. Aucun monde existant n'est converti. L'ancien identifiant
+`sanctuary:trial_pedestal` et la carte beta.167 restent enregistrés.
+Les cartes beta.168 sont des cartes natives avec données `sanctuary_horde_v1` ;
+le nouveau SavedData `sanctuary:horde_spent_v1` ne concerne que leurs consommations.
+
+```sh
+export JAVA_HOME=$(/usr/libexec/java_home -v 25)
+./gradlew :sanctuary-test:exportDuoLaunch
+python3 scripts/horde_lab.py prepare
+python3 scripts/horde_lab.py server
+# Autre terminal
+python3 scripts/horde_lab.py client
+```
+
+Trois cartes, équipement et vision nocturne de test à la première connexion. Clic droit dans le vide avec une
+carte près du centre du cercle. `/horde cartes` redonne trois nouveaux exemplaires
+hors combat ; `/horde retour` ramène et soigne hors combat. Pour cet essai,
+l'invocation est volontairement limitée au centre du labo enregistré, et le rayon
+d'apparition est de neuf blocs autour de l'utilisateur. Aucun usage dans les
+mondes ordinaires, aucune recette ni distribution économique de ces cartes.
+
+## Vérifications
+
+- `check build assemblePack` et parcours client Vulkan réussis : **254/254**
+  GameTests dans `build/horde168-validation.log`. Cette passe précède les derniers
+  ajustements de composition libre et le verrouillage des anciennes commandes du socle.
+- Rejeu final sur ces ajustements : groupe `horde168`, deux tests serveur requis
+  réussis, parcours client Vulkan sur les trois cartes, puis assemblage du pack :
+  **BUILD SUCCESSFUL**, journal `build/horde168-final.log`. Le rejeu cible exclut
+  `:sanctuary:check`, déjà exécuté dans la passe complète.
+- Serveur : refus sans consommation sur terrain bloqué, consommation immédiate,
+  trois vagues de chaque difficulté, images déterministes par graine, copie épuisée
+  refusée, anciennes commandes du socle inopérantes sur les cartes, nombre exact
+  d'objets lâchés conforme à l'illustration, nettoyage sans butin en cas d'interruption.
+- Client réel : tenue native à deux mains, clic droit, consommation, arrivée/départ
+  spontanés sans annulation de la horde, retour sans inscription, trois victoires,
+  butins physiques. Marqueur `HORDE168_CLIENT_PASS` ; six captures dans
+  `build/horde168-evidence/`. Inspection visuelle des cartes sans cadre ajouté.
+- Préparation du script répétée sans modifier ses fichiers existants ; Python compilé,
+  libellés FR/EN et liens documentaires vérifiés. Nouveau serveur dédié démarré avec
+  marqueur `ready-v1` dans le monde beta.168 ; l'ancien monde beta.167 est préservé.
+
+L'équilibrage humain reste à essayer : le client automatisé est invulnérable.
+La suite générale a réussi lors de cette exécution ; cela ne constitue pas une
+correction du test de familier intermittent signalé en beta.167 (source inchangée).
+Pas de publication ni de mise à jour Prism pour cet essai.

docs/horde-families-beta171.md

@@ -0,0 +1,87 @@
+# beta.171 — familles dominantes et chaos dimensionnel
+
+> La beta.172 retire la restriction au laboratoire et permet de consommer ces
+> cartes directement en Survie ou en Créatif. Voir
+> [le contrat runtime beta.172](horde-runtime-beta172.md).
+
+Suite de la [carte native beta.170](horde-map-native-beta170.md), branche
+`codex/horde-families-beta171`. Minecraft 26.3, dépendances inchangées.
+
+## Profil mémorisé par la carte
+
+La première prise en main fixe, côté serveur, la dimension de découverte et une
+famille dominante. Cette identité rejoint la difficulté et la graine dans les
+données de l'objet (`loot_version=3`) : déplacer ou cloner ensuite la carte ne
+peut pas relancer son tirage.
+
+Les familles sont zombies, squelettes, creepers, arthropodes, pillards,
+cauchemars de surface, infernaux, piglins, flétris et créatures de l'End. Dans
+92 % des tirages, la famille appartient à la dimension de découverte ; une
+incursion complète étrangère reste donc exceptionnelle.
+
+Chaque carte conserve au minimum 10/12, 13/18 ou 17/27 positions de sa famille
+dominante. Les autres positions sont mélangées de façon déterministe : monstres
+différents mais natifs de la dimension, puis intrus interdimensionnels plus
+rares. Errants peut ne recevoir aucun intrus, Meute en reçoit un et Légion deux ;
+les 8 % d'incursions étrangères constituent l'exception spectaculaire.
+
+Le catalogue contient 34 créatures adaptées à une apparition dans le cercle :
+variantes de zombies et squelettes, creeper, slime, araignées, silverfish,
+sorcière, pillards, évocateur, ravageur, breeze, phantom, creaking, blaze,
+squelette Wither, cubes, piglins, hoglin, zoglin, ghast, enderman, endermite et
+shulker. Les boss et monstres strictement aquatiques ne sont volontairement pas
+invoqués : ils demanderaient un contrat d'arène différent. Piglins et hoglins
+de carte ne se transforment pas hors du Nether.
+
+## Carte et récompenses
+
+L'illustration 128 × 128 est divisée horizontalement. En haut, une piste en
+serpentin montre chaque monstre dans l'ordre exact où il jaillira. En bas, toutes
+les piles garanties sont affichées sans hiérarchie ; elles peuvent légèrement
+se chevaucher quand la récompense est dense.
+
+Chaque espèce apporte une ressource cohérente et généreuse : poudre pour les
+creepers, bâtons de blaze, larmes de ghast, perles de l'End, carapaces de shulker,
+or des piglins, émeraudes des pillards, etc. Rubis et saphirs Sanctuary restent
+garantis sur chaque carte. Les butins natifs peuvent encore s'ajouter.
+
+Les cartes beta.168 restent à trois vagues de zombies. Les cartes beta.169/170
+déjà découvertes gardent leur roster version 2. Seules les nouvelles cartes
+beta.171 emploient le profil dimensionnel version 3.
+
+## Communication et essai
+
+Aucun parcours Horde, y compris le socle beta.167, n'envoie désormais de texte
+dans le chat ou la barre d'action. Découverte, refus, brèche, arrivées,
+progression, morts et résultat passent par les connexions et glyphes de
+particules natifs décrits en beta.170.
+
+Importer `Sanctuary-Test-beta.171.mrpack` dans Prism et créer un **nouveau** monde
+nommé exactement `horde-flat-168`. Le profil construit le cercle et donne trois
+cartes. Pour un tirage neuf, prendre « Carte de horde inconnue » dans **Outils et
+utilitaires**, la tenir en main, revenir en survie puis l'utiliser dans le cercle.
+
+La distribution depuis les campements de survie reste un ticket futur. Ce
+chantier ne modifie aucune génération, aucun chunk, aucune sauvegarde, aucune
+instance Prism et aucun canal packwiz. L'objet suit le modèle des cartes
+d'exploration distinctes de Minecraft 26.3, dont la carte des campements
+abandonnés décrite dans les
+[notes officielles Minecraft Java 26.3](https://www.minecraft.net/en-us/article/minecraft-java-edition-26-3).
+
+## Vérifications
+
+- GameTests `horde171` : majorité garantie, pondération par dimension, intrus
+  possibles, large catalogue, profil versionné, image et récompenses exactes.
+- Régressions `horde167` à `horde170` : compatibilité des trois anciens contrats.
+- Parcours client Vulkan : découverte, trois cartes séparées, familles visibles,
+  accélération, particules, morts, victoire et butins physiques.
+- Matrice complète `./gradlew check build` : 259/259 GameTests requis et
+  compilation complète réussis.
+- Pack normal : `Sanctuary-beta.171.mrpack`, SHA-256
+  `8f2642adfbcf499330889070b7c05efed09a181b82115e93da7023cdd5aee554`.
+- Pack laboratoire : `Sanctuary-Test-beta.171.mrpack`, SHA-256
+  `2d64d6b046e265ccee4686aedc98d73d8ec8c012f5b5f6fd64e1a6180adfabbc`.
+- JAR Sanctuary embarqué dans les deux packs : SHA-256
+  `0622cbd45cb20c763e3db9f351ebf26ea4869a3065655f01f66f97cc9c45d5c1` ;
+  JAR laboratoire :
+  `9c646a95a106680d34f05a4c4d77a9893153c04ab9ad8683f636a99eabc74016`.

docs/horde-invasion-beta169.md

@@ -0,0 +1,114 @@
+# beta.169 — cartes de horde à invasion continue
+
+> La [beta.170](horde-map-native-beta170.md) remplace ces cartes remplies par un
+> objet-carte Sanctuary natif et remplace les messages par un langage de
+> particules. La compatibilité avec les exemplaires beta.168/beta.169 demeure.
+
+Suite du [laboratoire beta.168](horde-cartes-beta168.md), branche
+`codex/horde-interruption-beta169`. Minecraft 26.3, dépendances inchangées.
+
+## Résultat jouable
+
+Une nouvelle carte est **inconnue tant qu'un joueur ne la tient pas**. Son nom,
+sa difficulté, son contingent et son principe de butin se révèlent alors et
+restent attachés à cet exemplaire. Le dessin natif 128 × 128 existait déjà mais
+n'est visible en jeu qu'une fois la carte dépliée en main. Une copie non tenue
+reste inconnue ; toutes les copies gardent cependant la même identité de
+consommation.
+
+Le clic droit consomme la carte et ouvre une invasion à la position du joueur.
+Il n'y a plus de vague, de pause ni de compte à rebours : le premier monstre
+jaillit immédiatement, puis les suivants arrivent un par un, chaque fois plus
+vite. Une victoire est accordée seulement quand tout le contingent est apparu
+et que tous ses membres ont réellement été vaincus.
+
+| Carte révélée | Contingent | Espèces | Cadence d'arrivée |
+| --- | ---: | --- | --- |
+| Errants · accessible | 12 | zombie, zombie momifié | 2,9 s → 0,9 s |
+| Meute · périlleuse | 18 | précédents, noyé, squelette, araignée | 2,4 s → 0,5 s |
+| Légion · féroce | 27 | précédents, vagabond, embourbé, desséché, araignée venimeuse, sorcière, pillard | 2,1 s → 0,3 s |
+
+La graine de chaque carte décale l'ordre du roster et détermine les quantités de
+butin et les gemmes bonus. Le dessin montre un œuf pour **chaque monstre réel**
+et les objets garantis qu'il apportera. Sa densité et sa variété rendent la
+difficulté lisible après révélation.
+
+## Butin généreux et lié aux monstres
+
+Chaque ennemi porte au moins une pile garantie, en plus de ses éventuels butins
+Minecraft natifs : chair putréfiée, sable, cuivre, flèches, ficelle, glace
+compacte, champignons, os, yeux d'araignée, redstone/poudre lumineuse ou
+émeraudes selon son espèce. Les quantités sont volontairement généreuses.
+
+Le premier et le deuxième monstre garantissent respectivement un rubis et un
+saphir. Les suivants ont une chance sur cinq d'ajouter une gemme alternée. Les
+objets sont physiques, sans propriétaire : ils restent au sol, peuvent être
+ramassés par tous et les gains déjà obtenus survivent à une interruption.
+
+Chaque apparition conserve la spirale de glyphes SGA natifs et chaque mort réelle
+disperse les runes avec une impulsion de fumée. Un nettoyage technique ne produit
+ni rune de mort ni récompense supplémentaire.
+
+## Combat ouvert et sécurité
+
+Les joueurs vivants dans les 32 blocs et 16 blocs de hauteur participent
+automatiquement. Partir, mourir ou revenir n'annule pas l'invasion. Les monstres
+peuvent dépasser l'ancienne limite du socle sans être supprimés ni compter comme
+morts. Une disparition réelle d'entité, un chunk central déchargé, un délai total
+de six minutes ou un futur point d'arrivée devenu impraticable interrompent la
+session avec un motif distinct.
+
+Tous les emplacements prévus sont vérifiés avant consommation, sans chargement ni
+écriture de terrain. Au moment d'une arrivée, douze positions proches sont
+essayées afin qu'un joueur ou un autre monstre ne bloque pas artificiellement la
+brèche. Une horde voisine empêche toujours une seconde invocation.
+
+## Compatibilité et laboratoire
+
+Les cartes beta.168 sans `loot_version` restent en version 1 : trois vagues de
+zombies, dessin et récompenses historiques inchangés. Les nouvelles cartes sont
+en version 2 et utilisent l'invasion continue. Le registre sauvegardé
+`sanctuary:horde_spent_v1`, les identifiants et le monde
+`build/horde-168/server/horde-flat-168` sont conservés ; aucune conversion de
+monde ni régénération de chunk.
+
+```sh
+export JAVA_HOME=$(/usr/libexec/java_home -v 25)
+./gradlew :sanctuary-test:exportDuoLaunch
+python3 scripts/horde_lab.py prepare
+python3 scripts/horde_lab.py server
+# Autre terminal
+python3 scripts/horde_lab.py client
+```
+
+`/horde cartes` fournit trois cartes inconnues supplémentaires hors combat.
+`/horde retour` ramène et soigne hors combat. Le prototype reste limité au centre
+du labo : aucune recette ou distribution économique n'est encore ajoutée aux
+mondes ordinaires.
+
+Pour l'essai le plus simple, importer `Sanctuary-Test-beta.169.mrpack` dans Prism,
+puis créer un **nouveau** monde nommé exactement `horde-flat-168`. Le profil de
+test présélectionne **Sanctuary — Test rapide** et reconnaît ce nom pour construire
+une seule fois le cercle, remettre les cartes et placer le joueur. Un autre nom
+crée un monde de test plat ordinaire ; le MRpack normal n'active pas ce laboratoire.
+
+## Vérifications
+
+- `horde169` : 3/3 GameTests ciblés ; `horde167` et `horde168` restent verts
+  dans la matrice de compatibilité.
+- Parcours client Vulkan : PASS sur les trois cartes, avec révélation en main,
+  départ/retour, cadence accélérée, roster varié, victoire et butins physiques.
+- Matrice complète rejouée par l'assemblage : 256/256 GameTests requis, puis
+  `check`, `build`, `assemblePack` et `assembleTestPack` réussis. Une première
+  passe sous forte charge avait fait échouer le déplacement aérien historique
+  `companion019` ; ses 21 tests isolés puis la seconde matrice complète passent.
+- Pack normal : [Sanctuary-beta.169.mrpack](../build/Sanctuary-beta.169.mrpack),
+  SHA-256 `72fcf169004cc4dc7e1bb3caf72c1e66cc935c79ac16173de9db8ef86d66eaea`.
+- Pack laboratoire :
+  [Sanctuary-Test-beta.169.mrpack](../build/Sanctuary-Test-beta.169.mrpack),
+  SHA-256 `a162f7e9ce88a177ac99934d4c9a7061ac67be062a31a36965a191dd3eb0423a`.
+
+Les deux manifestes exportés déclarent `beta.169`, Minecraft 26.3 et Fabric
+Loader 0.19.5. Le pack laboratoire contient en plus
+`sanctuary-test-beta.169.jar` ; aucun canal packwiz ni aucune instance Prism n'a
+été modifié.

docs/horde-lab-beta167.md

@@ -0,0 +1,120 @@
+# beta.167 — prototype de carte de horde et socle d'épreuve
+
+Branche `codex/communaute-economie-beta167`, socle beta.166. Premier essai issu du
+[cadrage communautaire](ecosysteme-communaute-economie.md). Minecraft **26.3**,
+dépendances inchangées ; vérifications graphiques Vulkan uniquement.
+
+## Contrat de ce prototype
+
+Une arène ronde de laboratoire, diamètre extérieur 41 blocs, accueille un
+**socle d'épreuve** au centre (`sanctuary:trial_pedestal`). Une **carte d'épreuve ·
+Horde de zombies** (`sanctuary:horde_trial_card`) permet d'ouvrir les inscriptions.
+Ces identifiants sont nouveaux et stables. Le clic droit ouvre les contrôles.
+
+De un à quatre joueurs s'inscrivent volontairement, passent prêts, puis l'hôte
+lance. Cinq secondes précèdent la première vague ; six secondes séparent les
+suivantes. Trois vagues : 4, 6 et 8 zombies en solo ; deux zombies supplémentaires
+par coéquipier et par vague. Chaque vague dispose de trois minutes. L'effectif
+est fixé au départ, sans renfort tardif. Tous les zombies doivent être vaincus.
+
+Le socle passe du vert au bleu pendant l'attente, rouge pendant le combat, or
+après victoire, sombre après interruption. Un affichage indique la vague et les
+ennemis restants. La carte du prototype reste réutilisable : **aucun butin ni XP
+de récompense** n'est distribué. Les statistiques natives de combat continuent
+d'exister. Ni capes, ni familiers exclusifs, ni incubation d'XP ne sont livrés.
+
+Quitter le rayon de 15 blocs, mourir, se déconnecter ou passer en créatif/spectateur
+retire de l'épreuve. Les autres participants peuvent continuer. Le départ de
+l'hôte avant lancement annule les inscriptions. Un groupe vide, un délai écoulé,
+une difficulté Paisible ou la disparition d'un ennemi vivant interrompt l'épreuve.
+Un ennemi disparu n'est jamais compté comme une victoire. Les zombies de test ne
+brûlent pas au soleil, ne ramassent pas d'objets et ne frappent que les participants.
+Le laboratoire désactive le PvP et conserve l'inventaire à la mort.
+
+## Données, interruption et limites
+
+Les sessions sont volontairement éphémères. Un arrêt interrompt la partie ; les
+zombies de l'épreuve sont retirés. Après un crash, leurs tags permettent de retirer
+les survivants au chargement. Aucune dette, récompense différée ou carte consommée
+n'existe à récupérer. Le socle est réarmé à la réouverture du labo.
+
+Le socle et la carte n'ont pas de recette ni de génération naturelle. Un socle
+posé hors de la scène explicitement préparée ne lance rien. Le client ne peut
+ni installer une arène, ni choisir ses monstres, ni charger une région par paquet.
+Le serveur contrôle identité de session, révision, distance, inscription et état.
+
+Le seul nouveau marqueur de scène est `horde-lab-167.txt`, dans le nouveau monde
+de développement : préparation réservée avant construction, état prêt après.
+Une préparation incomplète ou un socle manquant est conservé et refusé au
+redémarrage. Le volume entier doit être vide avant la première pose. Aucune
+ancienne sauvegarde, aucun chunk Sanctuary ni format de données existant n'est
+converti. Ne pas installer les nouveaux blocs dans un monde destiné à être
+rouvert avec beta.166 ; conserver le nouveau labo pour ce prototype.
+
+Il reste à éprouver le rythme et la coopération avec des joueurs humains. Les
+cartes de découverte, clés/reliques, cartes collectionnables, quêtes quotidiennes,
+échanges, ballast et huit extensions restent de la conception.
+
+## Essayer le laboratoire
+
+```sh
+export JAVA_HOME=$(/usr/libexec/java_home -v 25)
+./gradlew :sanctuary-test:exportDuoLaunch
+python3 scripts/horde_lab.py prepare
+python3 scripts/horde_lab.py server
+# Dans un autre terminal :
+python3 scripts/horde_lab.py client
+```
+
+Dossier neuf `build/horde-167/`, monde `horde-flat-167`, graine **167**, port
+loopback **25576**. Le script reprend seulement les arguments de lancement exportés,
+pas les sauvegardes ni paramètres du labo duo. Chaque connexion rejoint le cercle
+en aventure ; un équipement initial et des capacités de combat 10 cœurs/10 icônes
+de faim sont fournis à ce personnage de test. Hors épreuve, `/horde retour` ramène
+et soigne. L'ancien `build/duo/` et les installations personnelles sont préservés.
+
+À l'accueil, créer son personnage si demandé. Au socle : **Présenter ma carte**,
+**Prêt**, puis **Lancer l'épreuve**. Les amis rejoignent et passent prêts depuis
+le même socle. Ce profil local hors ligne ne valide pas l'identité Discord et ne
+doit pas être exposé sur Internet.
+
+## Vérifications et livraison
+
+- `./gradlew check build assemblePack :sanctuary-test:exportDuoLaunch` exécuté :
+  **252/253 GameTests réussis**, dont le scénario de horde. Le contrôle général
+  échoue sur `Companion019GameTests.creatureProfilesActuallyMove` (déplacement
+  aérien attendu). Journal : `build/horde167-full.log`.
+- Rejeu `check build` avec les groupes `companions,horde167` : **21/22 tests**,
+  même échec de déplacement, horde réussie. Le code et le scénario de familier
+  sont inchangés par ce chantier ; aucune conclusion de non-régression complète
+  n'est revendiquée. L'[audit antérieur](audit-dragon-beta165.md) décrit notamment
+  l'aléa du scénario. Journal : `build/horde167-focused-client.log`.
+- Validation finale ciblée : `runGameTest runClientGameTest assemblePack
+  :sanctuary-test:exportDuoLaunch`, groupe `horde167`, client Horde167/Vulkan,
+  avec `-x :sanctuary:check` pour ne pas rejouer les contrôles précédents.
+  **BUILD SUCCESSFUL**, deux tests serveur requis réussis (dont le scénario
+  horde), puis parcours client complet. Cette exclusion ne transforme pas le
+  contrôle général précédent en réussite. Journal : `build/horde167-delivery.log`.
+- Serveur : deux personnages simulés, carte requise, consentement de chacun,
+  lancement réservé à l'hôte, double lancement refusé, trois vagues adaptées
+  à l'effectif, victoire, carte conservée, nettoyage à la sortie et interruption
+  sur disparition d'un ennemi vivant. Une scène existante est refusée sans
+  réécriture par le constructeur du labo.
+- Client natif Vulkan : clic droit réel sur le bloc, paquets d'inscription,
+  préparation et lancement, trois vagues avec dégâts serveur natifs, victoire
+  après 18 zombies en solo. Captures FR/EN, GUI 2/3 ; inspection visuelle de
+  l'arène, du socle, des contrôles, du combat et du résultat. Marqueur
+  `HORDE167_CLIENT_PASS`. Huit captures conservées dans `build/horde167-evidence/`.
+- Script Python compilé ; préparation répétée avec **cinq fichiers identiques**.
+  Libellés FR/EN et liens locaux vérifiés. Démarrage dédié réel sur loopback,
+  création de la nouvelle scène puis arrêt propre, journal
+  `build/horde167-lab-server.log`. Redémarrage dédié réussi avec le marqueur
+  `ready-v1` et le socle existant, sans reconstruire la scène ; journal
+  `build/horde167-lab-restart.log`.
+- Packwiz assemblé et vérifié ; JAR interne beta.167 avec classes et ressources
+  attendues. SHA-256 du JAR :
+  `4d6cb640177d7904043c3eefe693a75fbdc4f4df48407adaae04cc7d632057e6`.
+
+La coopération entre plusieurs clients humains et l'équilibrage restent à
+éprouver ; les personnages simulés ne les remplacent pas. Aucun artefact public,
+tag, canal packwiz ou instance Prism mis à jour. Prototype intégré localement sur `main`, conformément à la demande du créateur.

docs/horde-map-native-beta170.md

@@ -0,0 +1,102 @@
+# beta.170 — carte de horde native et langage de particules
+
+> La [beta.171](horde-families-beta171.md) ordonne les monstres et les butins sur
+> la carte, ajoute les familles dominantes et étend le silence visuel au socle.
+
+Suite de l'[invasion continue beta.169](horde-invasion-beta169.md), branche
+`codex/horde-map-native-beta170`. Minecraft 26.3, dépendances inchangées.
+
+## Objet et découverte
+
+`sanctuary:horde_trial_card` est désormais une sous-classe de la carte native
+Minecraft, au lieu d'un objet ordinaire ou d'une carte remplie renommée. Son
+identifiant reste stable. Un exemplaire vierge est disponible dans l'onglet
+créatif **Outils et utilitaires** sous le nom « Carte de horde inconnue ».
+
+Le premier passage en main lui attribue côté serveur :
+
+- un identifiant de carte natif distinct ;
+- une difficulté parmi Errants, Meute et Légion ;
+- une graine propre, donc un ordre de monstres et des butins propres ;
+- une illustration verrouillée 128 × 128 correspondant au contenu réel.
+
+Deux nouveaux exemplaires vierges découvrent deux identités différentes. Ranger
+puis reprendre le même exemplaire ne le relance jamais : son identité, son dessin
+et sa difficulté restent stables. Cette distinction évite de choisir sa
+difficulté en changeant simplement d'emplacement d'inventaire. Si plusieurs
+cartes créatives vierges sont empilées, seule celle tenue se découvre ; les
+autres retournent vierges dans l'inventaire et attendent leur propre prise en main.
+
+La carte appartient à `#minecraft:clonable_maps`. La recette native 26.3 avec
+des cartes vierges peut donc dupliquer un exemplaire déjà découvert ; les copies
+conservent volontairement la même identité et la même consommation, comme les
+cartes d'exploration natives. Les cartes remplies beta.168 et beta.169 restent
+reconnues et jouables.
+
+Cette approche s'inspire des cartes d'exploration devenues des objets distincts
+en 26.3, et notamment de la nouvelle carte des campements abandonnés. Sanctuary
+fait un choix différent sur un point : sa carte inconnue est volontairement
+accessible dans l'inventaire créatif pour le laboratoire. Voir les
+[notes officielles Minecraft Java 26.3](https://www.minecraft.net/en-us/article/minecraft-java-edition-26-3).
+
+## Langage visuel sans chat
+
+Le parcours des cartes de horde n'envoie plus de message Sanctuary dans le chat
+ni dans la barre d'action. Toute l'information immédiate est spatiale :
+
+| Moment | Signal visuel |
+| --- | --- |
+| Découverte | 1, 2 ou 3 connexions convergent vers la carte selon la difficulté, avec glyphes SGA |
+| Activation valide | un anneau de connexions converge vers la brèche centrale |
+| Arrivée | la brèche se relie au monstre qui jaillit, entouré de glyphes |
+| Invasion en cours | une pulsation relie chaque monstre vivant à la brèche toutes les secondes |
+| Mort réelle | les glyphes se dispersent avec une brève impulsion |
+| Victoire | douze connexions convergent avec une explosion de totems |
+| Interruption | les connexions se dispersent avec une fumée sombre |
+| Usage impossible | un filet de fumée descend de la carte vers le joueur |
+
+Les connexions utilisent la particule native `minecraft:vault_connection` ; les
+glyphes restent ceux de `minecraft:enchant`, donc l'alphabet SGA fourni par le
+jeu. Aucune texture, interface ou canal réseau de HUD propre à la carte n'est
+nécessaire.
+
+Les messages du vieux socle beta.167 sont conservés uniquement pour ce prototype
+historique. Ils ne font pas partie du parcours de la carte native.
+
+## Essai dans le laboratoire
+
+Importer `Sanctuary-Test-beta.170.mrpack` dans Prism, puis créer un **nouveau**
+monde nommé exactement `horde-flat-168`. Le profil de test construit le cercle
+et fournit les trois cartes déterministes de démonstration. Pour vérifier la
+découverte aléatoire, prendre « Carte de horde inconnue » dans **Outils et
+utilitaires**, la tenir en main, revenir en survie puis l'utiliser dans le cercle.
+
+Le MRpack normal contient le même objet, mais la distribution en survie depuis
+les campements n'est pas encore activée. Ce chantier adopte leur modèle d'objet
+et de découverte sans modifier la génération, les chunks ou les sauvegardes.
+
+## Vérifications
+
+- GameTests `horde170` : type natif, entrée créative vierge, découverte unique,
+  stabilité à la reprise, diversité entre deux exemplaires, illustration et
+  compatibilité avec la recette native de duplication.
+- Parcours client Vulkan : présence dans Outils et utilitaires, découverte en
+  main, trois difficultés, accélération continue, signaux de particules, victoire
+  et butins ; aucun message de jeu Sanctuary émis par les cartes.
+- Matrice complète : 257/257 GameTests requis, puis `check build` réussi.
+- `assemblePack assembleTestPack` réussi après cette matrice ; intégrité ZIP,
+  version `beta.170`, Minecraft 26.3, Fabric Loader 0.19.5 et JAR embarqués
+  vérifiés.
+- Pack normal : [Sanctuary-beta.170.mrpack](../build/Sanctuary-beta.170.mrpack),
+  SHA-256 `e96ad55115074e898e94c3eccff983bd76301b0aa577c83b8a5e3feca0a719f8`.
+- Pack laboratoire :
+  [Sanctuary-Test-beta.170.mrpack](../build/Sanctuary-Test-beta.170.mrpack),
+  SHA-256 `d84aa95c230b6484c9282534245401de0dcf069e9d4e5c9d5e7d6238bb2f84e0`.
+
+Le JAR Sanctuary embarqué correspond au build vérifié, SHA-256
+`c8cd436bdc65c8f97ea6383f6f4ae63836b4b6e7dbf35918b2be86152e38d344`.
+Le profil laboratoire contient en plus `sanctuary-test-beta.170.jar`, SHA-256
+`ddb1023285a39f47d4fccd8377aa4ec297f41b9750eab3f6fe2868abcb62da50`.
+
+Aucun canal packwiz, serveur personnel, monde existant ou instance Prism n'est
+modifié par cette livraison locale.

docs/horde-runtime-beta172.md

@@ -0,0 +1,46 @@
+# beta.172 — cartes de horde utilisables en jeu
+
+Suite du profil dimensionnel [beta.171](horde-families-beta171.md). Le contenu
+des cartes, leurs familles et leur format sauvegardé ne changent pas.
+
+## Contrat runtime
+
+Le clic droit sur une carte révélée tente d'ouvrir la brèche à la position
+actuelle du joueur. Aucun cercle, socle, monde de test ou enregistrement de
+laboratoire n'est requis. Le pouvoir fonctionne en Survie et en Créatif ; le
+mode Spectateur et la difficulté Paisible restent refusés.
+
+Après validation de toutes les apparitions, l'identité de carte est marquée
+comme dépensée et un exemplaire est retiré de la main côté serveur. L'inventaire
+est immédiatement resynchronisé, y compris en Créatif. Une copie de la même
+carte ne peut donc pas rejouer l'invasion. Si la préparation échoue, la carte
+reste intacte.
+
+L'invasion n'écrit aucun bloc. Chaque arrivée essaie plusieurs angles autour du
+joueur et cherche un sol libre entre six blocs sous et six blocs au-dessus de la
+hauteur d'activation. Aucun chunk supplémentaire n'est chargé. Une zone trop
+encombrée, liquide, sans sol ou hors frontière refuse proprement l'ouverture par
+le glyphe de particules existant.
+
+Les joueurs créatifs présents dans le rayon restent associés à l'invasion de
+carte. Leur invulnérabilité Vanilla n'est pas modifiée : la brèche demeure
+dangereuse pour les joueurs en Survie, les créatures et l'environnement alentour.
+Le vieux socle beta.167 conserve son inscription réservée aux joueurs en Survie.
+
+## Vérifications
+
+- GameTests `horde172` : activation et consommation hors laboratoire en Créatif
+  puis en Survie ; centre de session égal à la position du joueur.
+- Terrain étagé : préparation, consommation et première apparition à la hauteur
+  du sol local, sans plancher de laboratoire.
+- Régressions `horde167` à `horde172` : 10/10 GameTests requis.
+- Matrice complète `./gradlew check build` : 261/261 GameTests requis et
+  compilation complète réussis.
+- Pack normal `Sanctuary-beta.172.mrpack` : SHA-256
+  `9e0cc6f07195b094963c03bce52c971ad7072990ac7976dff34f7647be176d7e`.
+- Pack laboratoire `Sanctuary-Test-beta.172.mrpack` : SHA-256
+  `60565cd9bf28708f398a32da38f1fce05789a1d6bfc513aab94cfe90932d82df`.
+- JAR Sanctuary embarqué dans les deux packs : SHA-256
+  `fb72d4d3efcd50d3ba67b0899faf9ffca5c2451150c5f169e2a0d030c9b6d7ae` ;
+  JAR laboratoire :
+  `67a7399372f05e384a03461c45730edc0459cbe342cf57bcb280c5c849086620`.

docs/independent-distances-beta149.md

@@ -0,0 +1,68 @@
+# RENDER-149 — Distances PBR et SSR indépendantes
+
+Branche `codex/separate-reflection-distances-beta149`, socle beta.148 `6f87144`.
+
+- Deux réglages : Distance PBR et Distance SSR, chacun à 64 blocs par défaut.
+  Choix 16, 32, 64, 128, 256 blocs, enregistrés séparément.
+- Le PBR conserve son propre fondu et sa propre limite de portée. Le SSR
+  utilise sa distance pour les surfaces réfléchissantes et sa recherche de
+  paysage. Le maillage et la sélection des surfaces couvrent le maximum des
+  deux portées actives, afin que réduire l’une ne coupe pas l’autre.
+- Ancien défaut commun 32 migré une fois vers PBR 64 ; nouveau réglage SSR 64.
+  Les anciennes valeurs PBR différentes de 32 restent conservées. Après la
+  migration, un choix explicite 32 est conservé comme les autres valeurs.
+- Option nommée exactement « SSR » en français et en anglais, sans la mention
+  « expérimental ». Les autres options expérimentales du jeu sont inchangées.
+- Intensités PBR 50 % et SSR 20 %, rendu solaire diffus de beta.148 conservés.
+  SSR conserve sa dépendance au PBR et les limites du paysage visible/chargé
+  et du budget de maillage.
+
+- Les feuilles (et fibres de laine, même profil entièrement mat) ne reçoivent
+  plus de large éclat spéculaire blanc. Leur relief normal reste présent.
+  La pierre et le bois retrouvent exactement leur poids spéculaire précédent,
+  comme les surfaces polies, les métaux, l’eau et le verre. La suppression
+  concerne les profils non métalliques de rugosité 0,98, avec transition 0,90–0,98.
+
+## Vérifications
+
+Contrôles de persistance indépendante, valeurs par défaut et libellés FR/EN.
+Scènes graphiques avec PBR variable/SSR 256 puis PBR 256/SSR variable.
+- Suite PBR/préférences Vulkan réussie : deux défauts 64 et persistance
+  indépendante sur 16/32/64/128/256 ; libellés FR/EN et nom SSR vérifiés.
+  Journal : `build/beta149-pbr-vulkan.log`.
+- Suites SSR Vulkan et OpenGL réussies avec les portées dissociées, F5,
+  intersections, eau/verre/métal, soleil/lune, OFF/zéro et rechargement.
+  Journaux : `build/beta149-ssr-vulkan.log`, `build/beta149-ssr-opengl.log`.
+  Ces passes précèdent l’ajustement final du profil entièrement mat.
+- Suite PBR Vulkan finale avec feuillage réussie : 170 172 pixels de feuilles
+  contrôlés, saturation relative 1,00007, relief visible sur 63 236 pixels.
+  Journal : `build/beta149-foliage-vulkan.log` ; captures correspondantes
+  dans `build/evidence/beta149-foliage-vulkan/`.
+- Bois et briques après recentrage sur le feuillage : aucun pixel modifié
+  par rapport à la capture précédant l’ajustement, sur les zones de contrôle
+  de 26 304 et 40 896 pixels respectivement.
+- `./gradlew check build` exécuté dans l’instantané isolé : 252 tests serveur,
+  229 réussis et 23 échecs, mêmes identifiants qu’en beta.148. Aucun nouvel échec.
+  Journal : `build/beta149-check-build-isolated.log` ; comparaison :
+  `build/beta149-server-failures.json`. L’ajustement final du feuillage concerne
+  seulement le shader et son test client. Le contrôle global reste en échec.
+
+- Suite PBR OpenGL finale réussie également : 170 199 pixels de feuilles,
+  saturation relative 1,00001, relief visible sur 63 263 pixels.
+  Journal : `build/beta149-foliage-opengl.log` ; captures correspondantes
+  dans `build/evidence/beta149-foliage-opengl/`.
+- Assemblage final réussi : `./gradlew build assemblePack -x :sanctuary:check`,
+  sans répéter les contrôles purs/serveur exécutés dans l’instantané.
+  Journal : `build/beta149-build-pack.log`. Cette exclusion ne transforme
+  pas le contrôle complet en réussite.
+
+## Artefact
+
+[Sanctuary-beta.149.mrpack](../build/Sanctuary-beta.149.mrpack), copié aussi dans
+`sanctuary-beta/build/` avec les autres versions. Archive vérifiée, un seul JAR
+Sanctuary beta.149 identique au JAR construit, shaders identiques aux sources,
+libellés SSR et deux portées FR/EN vérifiés. Minecraft 26.3 / Loader 0.19.5.
+Taille : 10 520 465 octets. SHA-256 :
+`ef5519d9a0e2006b865b62371a6f8712db02ab138aa9698339d6fdb02fb4befa`.
+Reçu : `build/beta149-artifacts.json`. Aucune installation Prism ni publication.
+

docs/inscription-web-beta166.md

@@ -0,0 +1,120 @@
+# beta.166 — inscription web et reprise de l’accueil
+
+Intégration de la PR #1 de Chris (`8de569b`), avec son historique conservé par
+le merge `ad960ef`, sur beta.165 et ses 252 GameTests actualisés.
+
+## Parcours
+
+Le joueur ouvre son dossier `/candidature` sur le site, se connecte à Discord,
+dépose sa candidature et récupère le code après acceptation/parrainage. Le
+bouton **Récupérer mon code** de Hello World ouvre ce dossier, sur le site
+configuré par le serveur, avec la confirmation de lien native de Minecraft.
+Le code reste obligatoire avant la création du personnage. Gazette et tableau
+restent en consultation seule sur le site.
+
+Sans configuration d’accès, le mod autonome garde l’accueil sans code.
+Avec une configuration partielle/invalide, l’accueil reste fermé. Un habitant
+déjà arrivé n’a pas à présenter de code ni à connaître le nouveau payload d’accès.
+Les autres contrôles de compatibilité Sanctuary restent appliqués.
+
+## Contrat API de reprise
+
+Les POST authentifiés `/api/v1/access-codes/verify` et `/redeem` reçoivent :
+`code`, `minecraft_username` et `admission_id` (UUID). Le serveur calcule cette
+admission à partir d’un identifiant de monde persistant et de l’UUID du joueur ;
+le client ne la choisit jamais. Un autre joueur ou un autre monde possède une
+admission différente, même à graine identique.
+
+La consommation en base conserve `used_at` et `admission_id` dans la même
+transaction verrouillée. Une répétition de la même admission et du même pseudo
+retourne `valid: true, reason: resumed`, le pseudo, le Discord et l’admission.
+`verify` accepte aussi cette reprise ; le bouton de confirmation redevient
+accessible. Une autre admission retourne `already_used` sans identité. Un pseudo
+incorrect ou un code révoqué reste refusé. Les codes anciennement consommés sans
+reçu restent refusés ; leur récupération nécessite une réémission par le staff.
+
+Le mod exige une réponse positive portant son admission exacte. Il n’accepte
+plus `already_used` sur la seule présence d’un pseudo et d’un Discord. Une
+réponse positive arrivée après déconnexion est quand même enregistrée, mais ne
+crée pas le personnage hors connexion. Si la réponse est entièrement perdue,
+le même code est vérifiable et consommable à nouveau au prochain accueil.
+Le reçu local sauvegardé permet de terminer une création déjà autorisée.
+Les erreurs réseau et de jeton proposent une nouvelle vérification.
+
+## Migration et activation
+
+1. Sauvegarder la base web et les fichiers de progression du serveur.
+2. Appliquer la migration additive web `add_admission_receipt_to_access_codes_table`
+   (colonne UUID nullable, aucune donnée supprimée), puis déployer le service API.
+3. Installer beta.166 sur serveur et clients des nouveaux arrivants.
+4. Configurer `SANCTUARY_APP_URL` et `SANCTUARY_API_TOKEN`, ou
+   `config/sanctuary/access.json` (`appUrl`, `token`). Le jeton reste serveur.
+   Utiliser HTTPS hors du labo local et un serveur Minecraft en online-mode pour
+   authentifier les UUID ; le labo offline ne prouve pas l’identité d’un compte.
+
+Dans le monde, `data/sanctuary-admission-id` est créé atomiquement avant tout
+appel API et doit être sauvegardé avec `data/sanctuary-access.json`. Aucun code
+brut ni jeton n’est enregistré dans ces fichiers. Leur corruption ferme l’accès
+et conserve les preuves. Les formats habitants/starter et les chunks restent
+inchangés. Ne pas supprimer l’identifiant d’admission pour « réparer » un accès.
+
+Retour arrière : conserver la colonne web et les reçus, désactiver explicitement
+l’accès si l’on revient à un ancien mod (cela réouvre l’accueil sans code).
+Ne pas exécuter le rollback de migration après consommation : il supprimerait
+les reçus nécessaires à la reprise. Pas de déploiement public implicite.
+
+## Laboratoire
+
+Le monde beta.160 existant est conservé. La reprise de l’introduction utilise
+un nouveau monde de développement ; les réglages graphiques et anciens JAR sont
+conservés. `scripts/duo_lab.py server --intro` joue la vraie introduction sur le
+monde plat ; sans cette option, le profil de test continue de la sauter.
+
+## Vérifications
+
+- `check build assemblePack` réussit (10 min 12 s), avec **252/252 GameTests**.
+  Trace : `build/access166-full.log`.
+- Smoke du contrat et du ledger : reprise, mauvais compte, mauvais reçu, absence
+  de reçu, isolation entre mondes de même graine, persistance et corruption.
+- `access166Interop` réussit contre la vraie API PHP/MariaDB locale : réponse de
+  consommation ignorée, nouveau ledger, nouvelle vérification et confirmation,
+  refus d’un autre joueur et d’une autre admission (`build/access166-interop.log`).
+- Test client Vulkan : vrai handshake Hello World, endpoint HTTP contrôlé qui
+  consomme puis répond 503, nouvelle vérification, confirmation et un seul reçu
+  bound. Ce test n’utilise pas Discord et ne prétend pas vérifier OAuth.
+- Site : 12 tests inscription/candidature (68 assertions), puis 31 tests ciblés
+  inscription/redirection Discord/communauté (258 assertions), tous réussis.
+  Pint passe. Suite web entière : 74 réussis, 1 ignoré et 1 échec préexistant
+  `PlayerModerationTest::test_an_administrator_can_open_a_player_profile`
+  (ancien libellé « Nommer admin »). Reproduit dans un instantané de HEAD avant
+  modification ; pas une régression de l’inscription.
+- Base locale sauvegardée avant la migration, puis migration additive appliquée.
+  Le vrai OAuth Discord reste à valider avec les identifiants de l’application ;
+  aucun contournement d’authentification ou compte de démonstration pour le joueur
+  n’est installé. Un compte API jetable distinct sert uniquement à l’interop.
+- Aucun déploiement sur sanctuary-minecraft.net, aucun push/fusion distante,
+  aucune modification de l’ancienne sauvegarde du labo ni des JAR archivés.
+
+Après la passe complète, le retour immédiat de la vérification en cache a été
+ajusté pour qu’une nouvelle tentative ne reste pas sans réponse pendant la
+limite d’une seconde. Le scénario client exerce précisément cette reprise.
+`check build assemblePack` a ensuite réussi avec les 6 GameTests de progression
+ciblés (`build/access166-final.log`). La disposition compacte a été resserrée
+pour garder tous les contrôles dans un GUI de 240 pixels de haut ; ses captures
+FR/EN et assertions de limites sont vérifiées par le scénario client.
+
+Le correctif web est enregistré dans `f36cc36`. Les identifiants OAuth fournis
+par l’utilisateur sont chargés depuis le `.env` privé et la redirection réelle
+vers Discord fonctionne avec le callback local. Le retour authentifié reste
+à confirmer après la connexion/autorisation de l’utilisateur.
+
+La livraison finale et les captures compactes passent dans
+`build/access166-delivery.log` : scénario client Vulkan FR/EN et assemblage du
+pack. Cette dernière commande exclut `:sanctuary:check` pour éviter une troisième
+exécution générale après les deux contrôles réussis ci-dessus ; elle ne remplace
+pas ces résultats. La seule modification de jeu depuis le contrôle ciblé est
+la disposition compacte, couverte par ce dernier test client.
+
+Le labo reste arrêté, configuré pour `duo-registration-166`. L'ancien
+`duo-flat-160` n'est pas modifié. Lancement prévu après connexion au dossier web :
+`python3 scripts/duo_lab.py server --memory 768 --intro`, puis le client habituel.

docs/introduction-beta031.md

@@ -39,8 +39,9 @@ Le fond sonore combine l'ambiance de la vallée des âmes, le portail assourdi,
 une écoute lointaine et huit battements de Warden de plus en plus rapprochés,
 puis l’ouverture du portail de l’End. Les sons proviennent de Minecraft **26.3-pre-2**, déjà requis ; aucune
 nouvelle dépendance ou copie de fichier audio vanilla n'est ajoutée. Le mixage
-respecte les volumes **Général / Ambiance**. La musique est interrompue pendant
-la séquence, sans modifier les réglages. Les sons sont arrêtés à la sortie.
+respecte les volumes **Général / Ambiance**. Dans beta.031, la musique était interrompue pendant
+la séquence. [Beta.061](arrival-mount-beta061.md) déclenche désormais la musique
+à la révélation du portail, puis la conserve jusque dans le monde, sans modifier les réglages. Les ambiances de la cinématique sont arrêtées à la sortie.
 Le voile blanc est abandonné à une déconnexion ou à un écran d’erreur ;
 les menus ne sont pas masqués.
 

docs/island-discovery-beta183.md

@@ -0,0 +1,128 @@
+# DISCOVERY-183 — lieux et ressources de Sanctuary Island
+
+Ticket du 30 septembre 2026, branche `codex/island-discovery-beta183`.
+Le créateur a visité le solo beta.182 et valide la palette naturelle, la rosace,
+les étangs et la génération sous l'île. Il demande un portail **horizontal**,
+les secteurs miniers et le soufre manquants, l'ISS séparée et un exemple d'eau
+haute qui suit le dénivelé. Son complément relie les vitres de la rosace aux
+huit couleurs du Bugrock et à une géographie lisible, froide au nord, chaude au sud.
+
+## Contrat
+
+Nouveau preset facultatif `sanctuary_test:discovery_v1`, profil `discovery`.
+Graine de visite : **42**. Anciens presets, sauvegardes et chunks conservés.
+La source de biomes possède une option `discovery` absente/false pour les
+anciens profils : seule la nouvelle génération active la poche de soufre.
+Aucune migration, expansion, activation de portail ou progression ajoutée.
+Minecraft 26.3, blocs de soufre natifs et minerais Sanctuary existants.
+
+## Contenu
+
+- Galerie centrale agrandie, toujours taillée dans la roche, avec ses deux
+  annexes et passages en boucle. Cadre d'obsidienne de **5 × 5**, trou central
+  de **3 × 3**, fond un bloc plus bas, sec. Le gardien viendra ultérieurement.
+- Rosace : positions, nervures, passages et Bugrock à Y=320 conservés.
+  Seules les vitres changent. Ordre du dessin source, depuis le nord :
+  bleu clair, vert clair, vert, orange, rouge, magenta, jaune, cyan.
+  Le petit sommet blanc conserve le rappel du logo central blanc.
+  Cette rose colorée donne une convention géographique ; elle ne transforme
+  pas encore les biomes de l'île en huit régions ni n'allume les relais.
+- Trois secteurs de gemmes : saphir au nord (0,-176), émeraude à l'est
+  (176,0), rubis au sud (0,176), chacun de rayon 64 blocs autour des centres
+  de chunks. Petits amas sur les faces de grotte, entre Y=40 et 287,
+  toujours au moins 13 blocs sous la surface, au plus douze blocs par chunk
+  retenu. Les blocs exposés et stocks sont comptés dans
+  le monde effectivement généré. Diamants, cuivre, charbon, fer et lapis
+  gardent leur distribution précédente ; aucun or ni redstone ajouté.
+- Une caverne de soufre au sud-ouest, altitude choisie dans la roche,
+  soufre/cinabre/calcite, ouverture vers le jour et trois formations de soufre
+  enracinées à la surface pour la repérer. Pas de lave ni de nouveau mob.
+- Un lac supérieur supplémentaire et son bassin aval, reliés par un chenal
+  en marches sur quatre blocs de dénivelé. La partie aval s'ouvre au jour.
+  Les deux systèmes d'étangs beta.180 restent présents. Recherche locale
+  bornée et plan mémorisé ; aucune hydrologie régionale calculée.
+- ISS entre Y=575 et 591 : trois modules métalliques reliés et praticables,
+  quatre ailes solaires, poutre centrale, antenne, porche d'arrivée et
+  observation vitrée vers l'île. Architecture originale, sans schematic
+  externe. La salle nord contient une table de cartes dans des cadres lumineux
+  horizontaux. Le rayon du générateur détermine la mosaïque et la salle :
+  5 × 5 pour le petit format (512), 7 × 7 pour le moyen (724), 9 × 9 pour le
+  grand (1024). Ce profil de terrain reste au format moyen ; les autres
+  dimensions de station sont vérifiées géométriquement, sans ajouter de
+  nouveaux profils de terrain à cette livraison. Aucun familier spécial,
+  quête ou portail vers les hauteurs fonctionnel ajouté.
+
+Toutes les nouvelles écritures appartiennent au chunk en cours de décoration.
+Plans locaux calculés une fois, aucune reconstruction dans une sauvegarde
+ouverte. Les cartes sont des objets Minecraft natifs, persistés avec leurs
+cadres. Une file finie les prépare par tranches de quatre lignes avec un budget
+cible de 3 ms par tick. Projection topographique de la graine au pas de quatre
+blocs, palette réelle pour les chunks déjà chargés, biomes pour les autres :
+c'est une vue d'ensemble du terrain initial, pas une photographie détaillée
+de toutes les constructions. Aucun chargement de chunks éloignés demandé pour
+la carte. Les cartes terminées sont figées comme une trace de l'ancienne
+expédition, et ne sont ni recréées ni regagnées si un joueur retire un cadre.
+Une interruption reprend une carte inachevée avec son identifiant existant.
+
+## Vérifications et visite
+
+Monde neuf final `solo183e/discovery/42`, serveur arrêté et sauvegardé proprement :
+567 échantillons de densité conservés sous Y=216, zéro région d'hydrologie,
+trois cerisiers, les deux bassins antérieurs et les cinq spawners/quatre caches
+conservés. Galerie : 1 939 surfaces reliées sur 1 979 colonnes, cadre 5 × 5 et
+fosse sèche 3 × 3 vérifiés. Rosace : géométrie inchangée, huit couleurs présentes
+et huit approches libres.
+
+Stocks réellement comptés dans les trois districts : 235 saphirs (176 exposés),
+624 émeraudes (441 exposées), 576 rubis (402 exposés). Nouveau système d'eau :
+4 311 blocs d'eau reliés et débouché extérieur vérifié. La ventilation du soufre
+est ouverte jusqu'au terrain local du débouché, plutôt qu'à la hauteur plus
+basse du centre de la poche.
+
+ISS : 4 742 entrées de plan, trois modules reliés, quatre ailes solaires,
+49 cartes distinctes et supportées dans 49 cadres horizontaux. Les géométries
+5 × 5, 7 × 7 et 9 × 9 couvrent les rayons 288, 395 et 544 avec leurs marges de
+terrain. La mosaïque courante couvre 896 × 896 blocs. Calcul de son aperçu :
+2 039 ms au total ; aucun chargement de chunk distant dans ce calcul. Lecture
+NBT après arrêt : 49 cartes pleines et figées, 49 identifiants uniques, tous
+les cadres orientés vers le haut, centres jointifs et aucun marqueur de travail
+inachevé. Assemblage des pixels sauvegardés inspecté visuellement ; il ne s'agit
+pas d'une capture du jeu. Rapport local `build/discovery183-saved-atlas.json`.
+
+Démarrage serveur mesuré à 4,4 s ; préparation avec sondages, génération des
+zones visitées et contrôles terminée à 41,1 s. Ce dernier chiffre inclut les
+tests synchrones, ce n'est pas un temps de démarrage normal du solo.
+Rapport `build/discovery183-quick-result.json`.
+
+`./gradlew check build assemblePack assembleTestPack` réussi en 7 min 20 s,
+**265/265 GameTests** (`build/discovery183-check-build.log`). Après les deux
+retouches finales limitées au laboratoire (ventilation et lecture des couleurs
+réelles de la carte), compilation, contrôles du mod de labo, assemblages et
+export du lanceur ont été refaits ; les checks des trois modules inchangés,
+déjà réussis, n'ont pas été répétés dans cet assemblage final. Journal
+`build/discovery183-final-assembly.log`. Le monde `solo183e` vérifie ce code final.
+
+Solo neuf `visite183/discovery/42`, `Sanctuary-Discovery-183-Solo`, vue 32,
+simulation 12, créatif, vol et commandes. Départ préparé devant la table de
+l'ISS. Entrée en jeu confirmée dans le journal le 30 septembre à 03:11:11 :
+KokaLab en (4.5,580,-12.5), vue 32. Passage en spectateur à 03:11:48.
+Client Vulkan actif.
+Aucune sauvegarde antérieure ni instance Prism modifiée.
+
+| Lieu | Téléportation de visite |
+| --- | --- |
+| Salle des cartes ISS | `/tp 4.5 580 -12.5 140 35` |
+| Porche ISS | `/tp 0.5 577 28.5 180 0` |
+| Rosace | `/tp 0.5 319 5.5 180 0` |
+| Portail inférieur | `/tp 0.5 177 7.5 180 30` |
+| Poche de soufre | `/tp -152 180 152` |
+| Indice de soufre en surface | `/tp -158 281 149` |
+| Bassin supérieur | `/tp -96 254 -192` |
+| Saphirs | `/tp -62 236 -204` |
+| Émeraudes | `/tp 114 172 -30` |
+| Rubis | `/tp -60 192 146` |
+
+Graine 42 testée en génération native ; les autres graines restent à éprouver.
+Palette, volumes, positionnement des cartes et proportions de l'ISS à valider
+en visite. Les cartes sont une vue d'ensemble figée de l'île principale,
+pas encore un atlas vivant des expansions.

docs/island-ecology-beta176.md

@@ -0,0 +1,197 @@
+# WG-ECO-176 — strates, biomes et mares du laboratoire
+
+Branche `codex/island-ecology-beta176`, base de visite beta.175 conservée au
+commit `ba4cf19`. Le créateur autorise l'essai décrit dans
+[les retours de visite](worldgen-retours-beta175.md).
+
+## Contrat avant implémentation
+
+Nouveau preset `sanctuary_test:ecology_v1`, réglage `ecology_v1_10`, graine
+initiale 42 puis témoins 0 et 173, diamètre 724. Relief brut identique à
+`sky_v1` ; matériaux, biomes, décorations et petites excavations des mares
+peuvent différer. Limite du ciel réservé : aucun bloc généré de 512 à 639.
+Les presets historiques et la génération normale restent inchangés.
+
+- Géologie en couches ondulées de pierre, andésite, tuf, deepslate et touches
+  de calcite. Conserver le diamant profond et enfoui.
+- Grandes régions automnales et de cerisiers, lisières et prairie/forêt.
+- Trois récifs avec identité humide/tropicale ; deux fragments supérieurs
+  avec végétation courte. Le sélecteur sait dépasser l'ancienne limite 384.
+- Mares locales retenues, nombre d'essais borné, écriture dans le chunk
+  propriétaire, sans demande de plan hydrologique régional.
+- Biomes propres au labo avec décorations sélectionnées : pas de structures
+  natives, notamment mineshafts et villages. Aucun village Sanctuary créé
+  dans cet essai ; aucun nouveau contenu d'expansion.
+
+Aucune migration : nouveaux mondes de test seulement. La sauvegarde de
+visite beta.175 est conservée et ne doit pas être ouverte avec une autre
+empreinte de génération. Le nouveau monde peut être copié après arrêt
+propre vers un solo avec commandes et rendu 32 ; conserver l'original et
+les identifiants de génération. Aucun déploiement Prism ni publication.
+
+## Vérification prévue
+
+Compilation, `check build assemblePack assembleTestPack`, mesures natives
+sur trois graines, réouverture de 42, coupes géologiques et cartes de biomes
+à la surface réelle. Contrôler la stabilité des mares après ticks, l'absence
+de structures admissibles, le ciel vide et l'absence de plans hydrologiques.
+Le recensement exhaustif des minerais doit fonctionner avec mémoire bornée ;
+aucun petit échantillon ne sera présenté comme un total d'île.
+
+## Réalisation
+
+Le module optionnel `sanctuary-test` fournit trois composants natifs :
+`EcologyBiomes176` sélectionne les biomes, `EcologyStrata176` remplace les
+matériaux pendant leur génération, et `EcologyWater176` pose les mares avant
+les décorations. Le preset normal n'utilise aucun de ces composants.
+
+Les biomes propres au laboratoire réutilisent des décorations de Minecraft
+26.3 : forêt automnale, cerisiers, jungle clairsemée, mangrove, marais et
+cavernes. Les deux fragments les plus hauts reçoivent de la végétation courte.
+Les minerais natifs, sources, lacs et structures sont exclus de cette palette ;
+les dépôts du laboratoire beta.175 restent responsables des ressources.
+
+Une mare occupe un seul chunk, avec un rayon de 3 ou 4 blocs et deux niveaux
+d'eau. Le placement vérifie le fond et les parois avant toute écriture ; cinq
+essais au maximum, dans un tiers des chunks. Aucun calcul de bassin versant,
+chargement de voisin ni recherche hydrologique régionale. Les décorations
+natives peuvent ensuite ajouter des plantes ou de petites flaques de grotte.
+
+Le test d'eau compare les positions de **toutes** les sources dans le voisinage
+immédiat avant et après 240 ticks natifs, y compris les blocs gorgés d'eau.
+Il refuse tout écoulement et toute perte/apparition de source, et vérifie
+qu'il reste de l'eau dans chaque mare. Les flaques indépendantes produites
+par les groupes de stalagmites ne doivent pas être confondues avec une fuite.
+
+Le recensement exhaustif conserve une enveloppe finie de chunks jusqu'à la
+fin de la mesure. Il ne force plus des cycles d'expiration/sauvegarde durant
+`SERVER_STARTED`, qui dupliquaient les copies des chunks voisins en mémoire.
+Ce parcours est réservé au diagnostic `--whole-island`, jamais au lancement
+ordinaire du laboratoire.
+
+## Reproduction
+
+```sh
+./gradlew :sanctuary-test:exportDuoLaunch
+python3 scripts/worldgen_lab.py prepare --profile ecology --seed 42 --run nouvel-essai
+python3 scripts/worldgen_lab.py server --profile ecology --seed 42 --run nouvel-essai
+```
+
+Ajouter `--verify` pour les relevés et le contrôle des fluides. Pour un
+recensement complet, ajouter `--whole-island` à la préparation **et** au serveur.
+Le lanceur refuse de réutiliser un monde dont l'empreinte des sources a changé.
+Les fichiers `ecology-v1-cold/survey.json`, les coupes binaires et
+`worldgen-lab-metrics.json` sont écrits dans le dossier serveur du laboratoire.
+`scripts/ecology_atlas.py` produit l'atlas avec les dépendances de
+`scripts/sky-atlas-requirements.txt`.
+
+## Mesures natives du 29 septembre
+
+Série `science176d`, Java 25, Minecraft 26.3, heap serveur limité à 1 536 MiB.
+L'[archive des relevés](/Users/koka/Documents/sanctuary/retours-sessions/2026-09-29_1506-storyquest/releves-beta176/)
+conserve les JSON, coupes, journaux, figures et empreintes SHA-256.
+
+| Contrôle | Graine 42 | Graine 0 | Graine 173 |
+| --- | ---: | ---: | ---: |
+| Densités identiques à beta.175 | 50 000 / 50 000 | 50 000 / 50 000 | 50 000 / 50 000 |
+| Ensembles de structures natives admissibles | 0 | 0 | 0 |
+| Plans hydrologiques régionaux | 0 | 0 | 0 |
+| Mares témoins stables après 240 ticks | 8 / 8 | 8 / 8 | 8 / 8 |
+| Blocs d'air contrôlés en Y=512–639 | 1 474 560 | 1 474 560 | 1 474 560 |
+
+Les cinq récifs de chaque graine portent de la végétation. Les mares témoins
+comprennent de la surface, des grottes et des récifs hauts. Le contrôle du ciel
+porte sur neuf chunks autour de chacun des cinq récifs ; ce n'est pas un scan
+exhaustif de toutes les décorations possibles sur toutes les graines.
+
+Réouverture de 42 : cartes de biomes identiques, deux coupes de blocs identiques
+octet par octet, mêmes sources d'eau avant/après les 240 nouveaux ticks.
+
+### Ressources de toute l'île, graine 42
+
+Recensement des **2 000 chunks de l'enveloppe de l'île**, Y=0–639, après
+décoration ; aucune extrapolation des 81 chunks centraux. Durée du comptage :
+154,391 s, réservée au diagnostic. Les points de contrôle mémoire montrent
+341–607 MiB de heap utilisé ; cela ne mesure pas le pic total du processus.
+
+| Ressource | Blocs de minerai, variantes pierre + deepslate |
+| --- | ---: |
+| Cuivre | 193 771 |
+| Charbon | 138 998 |
+| Fer | 5 343 |
+| Lapis | 7 124 |
+| Diamant | **336** |
+| Or | 0 |
+| Redstone | 0 |
+
+Les 336 diamants sont en deepslate, sous Y=136, sans voisin d'air. L'améthyste
+comprend 5 578 blocs ordinaires, 1 422 blocs bourgeonnants et 219
+bourgeons/cristaux. Ces totaux décrivent ce monde enregistré ; les deux autres
+graines ont seulement un relevé minéral régional, pas un total d'île.
+
+Sur la carte de surface échantillonnée de 42, l'automne occupe 19,4 % des points
+et les cerisiers 25,5 %. Leurs plus grandes composantes regroupent respectivement
+642/646 et 846/850 points : il s'agit bien de grandes régions, avec quelques
+points isolés aux bords. Grille de 8 blocs, connexité à quatre voisins ; ces
+proportions ne sont pas des surfaces exactes au bloc près.
+
+### Durées et interprétation
+
+| Passage | Initialisation serveur hors bootstrap JVM | Processus → fin des diagnostics |
+| --- | ---: | ---: |
+| 42 neuve, comptage intégral | 6,403 s | 237,523 s |
+| 42 réouverte, relevé régional | 0,922 s | 36,606 s |
+| 0 neuve, relevé régional | 4,782 s | 86,856 s |
+| 173 neuve, relevé régional | 2,792 s | 86,125 s |
+
+La seconde colonne chronomètre les événements de démarrage du serveur, pas
+l'ouverture complète du client. La dernière inclut les cartes, chargements
+de chunks, coupes, minerais et 240 ticks de vérification. Ces parcours sont
+activés seulement par `--verify`/`--whole-island` et ne tournent pas pendant
+la visite solo. Aucun gain de FPS ni coût isolé de l'eau n'est déduit ici.
+
+## Livraison locale et limites
+
+Client solo ouvert le 29 septembre à 20:22 : backend Vulkan confirmé
+(MoltenVK 1.4.2, Apple M1), entrée de KokaLab à `(-8.5, 249, -13.5)`,
+serveur intégré et rendu passé à 32 chunks dans le journal. Les commandes
+sont autorisées dans la copie.
+
+`./gradlew check build assemblePack assembleTestPack` : contrôles statiques et
+smokes terminés, puis **264/265 GameTests réussis**. Le seul échec est
+`familiar029game_tests_carried_pair_and_invulnerability_still_apply`, assertion
+« Carrier fixture » au tick 0. Ce code de portage n'est pas modifié par ce lot
+et cette suite ne charge pas le module écologique `sanctuary-test`.
+
+Relance ciblée sans modification de code :
+`./gradlew :sanctuary:runGameTest -PsanctuaryFocusedTests=familiarhit -PsanctuaryExpansionReload=true`
+→ **7/7 réussis**, `BUILD SUCCESSFUL`. Cela indique un échec intermittent ou
+une interaction de suite à examiner ; cela ne transforme pas la première
+suite complète en passage réussi. Aucun correctif du portage n'est livré ici.
+
+Assemblage local **réussi** après ces contrôles, sans les relancer :
+`./gradlew build assemblePack assembleTestPack -x :check -x :sanctuary:check -x :sanctuary-test:check -x :demeure:check -x :jei:check`.
+`BUILD SUCCESSFUL` en 12 s ; packs générés dans `build/packwiz` et
+`build/packwiz-test`. Les journaux complets sont conservés dans l'archive des relevés. Aucun canal
+packwiz, serveur personnel ni instance Prism n'est mis à jour.
+
+La copie `Sanctuary-Ecology-176-Solo` provient du serveur `science176d/42`
+après arrêt et réouverture vérifiée. Commandes autorisées, mode créatif,
+réglages de visite repris de beta.175 avec rendu 32 chunks. L'ancien solo
+est conservé. Pour observer librement : `/gamemode spectator`.
+
+Repères de visite, graine 42, points d'observation au-dessus du terrain :
+
+| Zone | Téléportation en spectateur |
+| --- | --- |
+| Grande région automnale | `/tp @s -4 300 180` |
+| Grande région de cerisiers | `/tp @s 20 280 -180` |
+| Récif jungle | `/tp @s -116 390 160` |
+| Mare du récif mangrove | `/tp @s -105 425 -152` |
+| Récif marais | `/tp @s 219 470 22` |
+| Transition profonde près d'une mare en grotte | `/tp @s 41 166 -55` |
+
+Premier essai : les mares restent petites et arrondies ; leur forme, les
+proportions de pierres et les lisières doivent encore être jugées en visite.
+Les grands lacs, rivières et cascades, les villages Sanctuary, les donjons,
+les expansions et la station ISS ne sont pas implémentés par ce lot.

docs/living-caves-beta179.md

@@ -0,0 +1,40 @@
+# WG-ECO-179 — grottes vivantes et complexes souterrains
+
+Retour de visite beta.178 : automne validé ; trop de cerisiers bas, bordures
+rocheuses sur les pentes, grottes devenues trop sèches et trop dépouillées.
+Nouveau preset `sanctuary_test:living_ecology_v1`, profil `living`, graine 42,
+branche `codex/living-caves-beta179`, base `db6194c`. Nouveau monde uniquement.
+
+- Vallées automnales conservées. Sol végétal sur les pentes supérieures ; la
+  roche nue reste sur les flancs profonds sous Y=200.
+- Cerisiers à partir de Y=286, une tentative tous les quatre chunks du sommet
+  au lieu de dix arbres par chunk. Pas de forêt de cerisiers sur le plateau.
+- Poches lush avec bassins retenus à plusieurs niveaux, sous-bois de chênes
+  noirs, marais à lucioles, mycélium violet mêlé d’herbe et champignons géants.
+  Mooshrooms et grenouilles placées à la génération dans leurs habitats.
+- Trois réseaux miniers avec hall, ramifications, rails, passerelles et sorties
+  extérieures ; une cabane de sorcière dans une cavité marécageuse. Première
+  version procédurale, sans butin ni progression. Le retour actuel remplace
+  l’interdiction des mineshafts exprimée avant la visite beta.178.
+
+La couleur vient des biomes, du feuillage, de l’eau et du brouillard ; aucune
+nouvelle simulation de lumière colorée. Bruit du terrain, récifs, minerais et
+espace ISS conservés ; pas d’hydrologie régionale. Structures rendues par chunk
+selon un plan déterministe borné, aucune expansion activée ni migration.
+
+Compilation et contrôle natif `solo179c` réussis : 567 densités profondes
+inchangées, zéro région d’hydrologie, automne conservé (14 colonnes de contrôle),
+cerisiers uniquement au sommet et pentes supérieures végétalisées. Les témoins
+natifs contiennent eau, mousse, mycélium, buissons à lucioles, chênes noirs et
+champignons géants. Sauvegarde des habitants vérifiée : 6 mooshrooms,
+17 grenouilles, une sorcière et un chat dans les chunks chargés, sans prétendre
+recenser toute l’île. La suite `check build assemblePack assembleTestPack` a réussi
+en 36 min 7 s, après la visite.
+
+Visite préparée : `visite179/living/42`, `Sanctuary-Living-179-Solo`, créatif,
+commandes activées, difficulté normale pour conserver la sorcière, vue 32 et
+simulation 12. Points de visite (graine 42) : halls miniers (112,147,72),
+(-160,185,24), (-72,129,160) ; cabane (-192,114,96) ; mycélium vers
+(-216,201,48), marais vers (-216,113,96), lush vers (-216,161,120).
+Client Vulkan ouvert le 29 septembre à 23:16, KokaLab connecté ; distance
+serveur 32 et simulation 12 confirmées dans le journal.

docs/living-details-beta188.md

@@ -0,0 +1,78 @@
+# DETAILS-188 — fonds d'étangs, soufre vivant et palettes des ancres
+
+Ticket du 30 septembre 2026, branche `codex/living-details-beta188`.
+Le créateur valide l'orientation des ancres et les formes des bassins beta.187.
+Il demande des refuges adaptés au milieu et à la couleur, des fonds sédimentaires
+végétalisés sans arbres dans l'eau, et les pics/geysers du biome de soufre.
+
+Nouveau profil `details`, preset `sanctuary_test:living_details_v1`, graine 42.
+Aucune modification des anciennes sauvegardes ou générations. Même densité,
+mêmes bassins et mêmes emplacements/orientations d'ancres que beta.187.
+Livraison locale de laboratoire ; objectif de visite avant 9 h.
+
+## Réalisation
+
+Géométrie et orientation des refuges conservées. Terre, herbe et terre stérile
+pour la surface ; tuff, deepslate et calcite sous roche ; calcite et diorite
+sur les récifs. Les incrustations reprennent la teinte du secteur. Le verre
+reste au-dessus de l'améthyste, du côté de l'expansion.
+
+Les bassins sont remplis avant les arbres. Leur lit existant reçoit des plages
+cohérentes d'argile, boue, sable et gravier, sans agrandissement ni coque ajoutée.
+Les colonnes de plantation immergées sont réservées pendant la décoration.
+Herbes marines et quelques touffes de kelp occupent les fonds ; les matériaux
+meubles exigent un support rocheux. Contours et niveaux restent ceux de 187.
+
+Le soufre reçoit des stalagmites et stalactites natives, avec des longueurs
+variables, et des sources périodiques : magma, soufre puissant, eau source.
+Les volumes humides réservés, le donjon et les refuges sont évités. Les entités
+de bloc sont explicitement créées et sauvegardées pour activer les minuteries
+natives des geysers. Le contrôle vérifie l'entité et le ticker après réouverture.
+
+Table de butin propre à ce nouveau preset : une ou deux pièces en fer par
+wagonnet, parmi quatre armures, épée, pioche, hache et pelle. Enchantement par
+la fonction native, puissance de table 12 à 20, sans enchantement trésor.
+Les gemmes et les ressources déjà présentes restent dans le butin. Les anciens
+wagonnets et tables ne changent pas. La progression du futur monde minéral
+reste une intention, hors de cette livraison.
+
+## Vérifications
+
+Premier monde : les huit refuges gardent exactement leurs positions et axes.
+Quatre sédiments, 611 colonnes végétalisées et zéro tronc dans les bassins.
+Plan de 496 spires et 39 geysers ; 138 blocs de pic et huit sources contrôlés.
+32 tirages de butin : toujours une ou deux pièces enchantées en fer, les huit
+types d'équipement observés. Génération finale `solo188c/details/42` puis réouverture réussies, avec contrôle
+des entités de geyser et de leurs tickers natifs. Les blocs et entités sont
+relus dans la sauvegarde arrêtée : huit ancres éteintes, Bugrock allumé sans
+relais, 49 cartes complètes et 49 cadres horizontaux. Les quatre wagonnets sauvegardés portent tous la nouvelle table
+`sanctuary_test:chests/mine_cache_188` ; reçu `build/details188-saved-loot.json`.
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch`
+réussi en 7 min 54 s : 265 GameTests réussis. Les contrôles natifs finaux passent
+après la correction des entités de geyser, à froid et après réouverture.
+Le JAR du labo a ensuite été reconstruit et le pack optionnel resynchronisé
+avec `scripts/test_pack.py` : ses 146 classes correspondent aux classes compilées,
+sa table de butin correspond à la source et le JAR distribué est identique.
+Lors des 32 tirages après réouverture, 51 pièces enchantées couvrent les huit
+types d'équipement. Reçu de la suite générale : `build/details188-check-build.log`.
+
+Solo `visite188c/details/42`, monde `Sanctuary-Living-Details-188-Solo`, ouvert
+sous Vulkan : connexion à 09:00:41, vue 32 et simulation 12 confirmées dans le
+journal, puis passage du joueur en spectateur à 09:00:58. L'objectif avant 9 h
+a donc été dépassé. Le contrôle visuel des décors et des éruptions reste à faire
+pendant la visite ; la présence des blocs, entités et tickers est vérifiée.
+
+## Raccourcis de visite
+
+- Bassin ouest : `/tp -104.5 269 119.5 180 35`
+- Soufre et geysers : `/tp -217.5 159 -16.5`
+- Autre source : `/tp -201.5 150 8.5`
+- Wagonnet du donjon : `/tp 45.5 144 60.5`
+- Ancre nord : `/tp 36.5 250 -168.5 180 0`
+- Ancre sud, grotte : `/tp -71.5 176 205.5 0 0`
+- Ancre est, récif : `/tp 214.5 444 16.5 -90 0`
+
+Nouveau solo uniquement, vue 32, simulation 12, créatif avec vol et commandes.
+Aucune publication du canal public ni modification de Prism.
+
+Mesures du labo final : démarrage 12.839 s à froid / 0.912 s après réouverture ; prêt avec tous les contrôles en 71.525 s / 14.114 s. Mesurées pendant la suite générale, hors chargement graphique. Zéro région d’hydrologie. Reçus ignorés `build/details188-final-cold-result.json` et `build/details188-final-warm-result.json`.

docs/living-hats-seasons-beta105.md

@@ -0,0 +1,143 @@
+# beta.105 — Météo saisonnière, captures et chapeaux vivants
+
+Branche `codex/living-hats-seasons-beta105`, Minecraft 26.3.
+
+## Contrat avant modification
+
+- Molette dans le fût : navigation entre pages, bornée, sans perdre les objets
+  du curseur ni déplacer la souris au centre.
+- Panoramas : couleurs et brume du shader Sanctuary actif, six faces cohérentes,
+  profondeur conservée et caméra restaurée même après erreur.
+- Real Time : probabilités liées aux saisons astronomiques du calendrier réel.
+  Été surtout ensoleillé sans profil ciel gris ; automne plus humide ; hiver
+  avec neige. Des journées claires restent possibles dans les quatre saisons.
+  Le créateur demande explicitement flocons et accumulation naturelle au sol.
+  Le tirage du jour déjà sauvegardé reste stable ; nouveaux tirages saisonniers
+  les jours suivants, commandes opérateur disponibles. Aucune Weather TNT.
+- Mobs équipés : coups et boules de neige activent l’objet ; briquet, feu
+  d’artifice propulsant le porteur, spawner natif configuré, paratonnerre attirant
+  les éclairs. Les consommables et l’usure restent réels.
+- Cultures sur tête : croissance et récolte des produits/graines, sans duplication
+  de la graine initiale au retrait. Les aliments attirent les espèces qui les
+  mangent ; une carotte sur bâton guide les cochons vers le porteur.
+- Livre et plume : journal intime écrit en réaction aux caresses et blessures,
+  voix différente selon les quatre personnalités ; souvenirs variés, pas de log
+  technique. Pages existantes conservées et limites natives respectées.
+
+## Contrat de données
+
+Aucune sauvegarde personnelle n’est modifiée pendant les essais. Les objets et
+leur état continuent d’utiliser les données additives existantes de chapeau.
+Les journaux restent de véritables livres Minecraft récupérables. L’éventuel
+nouveau profil neige étend l’énumération météo : anciens états lisibles, aucune
+conversion automatique du jour courant. Un retour à une ancienne version après
+une journée neige nécessite d’abord de sélectionner un profil météo ancien.
+La neige peut modifier les blocs exposés pendant le jeu, selon la demande du
+créateur ; pas de régénération, d’expansion ni de changement de terrain au chargement.
+
+## Utilisation
+
+- Dans le fût, molette vers le bas : page suivante ; vers le haut : précédente.
+  Le défilement concerne le coffre et sa colonne de contrôles. Un objet tenu au
+  curseur bloque le changement de page, comme les boutons existants.
+- `/sanctuary weather forecast` annonce les sept prochains jours.
+  `/sanctuary weather snow` et `snow_showers` sélectionnent respectivement neige
+  continue et averses ; leurs équivalents `/weather` sont également disponibles.
+  Le mode Vanilla conserve le cycle Minecraft.
+- Sur un mob équipé, clic droit à main vide : caresse du livre, activation du
+  briquet/de la fusée, récolte d’une culture mûre. Coup ou boule de neige :
+  activation. Maj + clic droit à main vide : récupération de l’objet.
+- Blé, carottes, pommes de terre, betteraves : croissance des cultures portées,
+  récolte native et replantation. Les produits mûrs sont aussi rendus si l’on
+  retire la graine. Les plantes décoratives et tiges de melon/citrouille ne
+  deviennent pas des cultures de fruit mobiles.
+- Le spawner conserve l’espèce configurée et les contraintes Minecraft :
+  proximité d’un joueur, espace, lumière et limite d’entités. Une activation
+  lance une tentative immédiate ; elle ne garantit pas une apparition si
+  ces conditions ne sont pas réunies.
+- Le paratonnerre attire les éclairs naturels sous un ciel dégagé à portée
+  native, puis émet son impulsion redstone. Le briquet respecte la règle de modification du terrain par les mobs.
+  La fusée consomme l’objet, utilise ses effets natifs et propulse le porteur.
+- Les aliments portés attirent les animaux qui les consomment dans un rayon
+  de 10 blocs, avec abandon à 12 blocs ou sans visibilité. La carotte sur bâton
+  guide ainsi les cochons. Priorités de fuite et de reproduction conservées.
+- Le journal reprend la personnalité du familier ; celle d’un animal ordinaire
+  est déterminée de façon stable par son identité et son espèce. FR/EN selon
+  la langue du premier lecteur-interacteur. Les pages précédentes sont
+  conservées (limite native 100 pages), mais ne sont pas diffusées dans le
+  paquet d’apparence du chapeau.
+
+## Calendrier et périmètre
+
+Longitude solaire apparente calculée localement à partir des formules publiques
+[NOAA Solar Calculator](https://gml.noaa.gov/grad/solcalc/), avec contrôle des
+quatre passages 2026 contre les horaires de l’[US Naval Observatory](https://aa.usno.navy.mil/data/Earth_Seasons).
+Le tirage est journalier : le jour civil d’un équinoxe/solstice adopte la nouvelle
+saison, selon le fuseau Real Time. L’hémisphère sud inverse les saisons via la
+latitude solaire configurée. Il ne s’agit pas de la météo réelle d’une ville.
+Les pondérations de `weather.json` restent la base, modulée par la saison.
+Sur 10 000 graines par saison : journées claires 64,41 % / 94,79 % / 40,25 % /
+49,05 % (printemps/été/automne/hiver) avec la configuration par défaut.
+
+La neige passe par les précipitations natives des chunks chargés, respecte
+la limite native d’accumulation, la lumière et les supports Minecraft. Les biomes
+sans précipitations restent secs. Les chaudrons reçoivent aussi de la neige.
+La neige déposée reste un bloc natif : pas de balayage saisonnier supprimant
+les blocs des constructions. Sa fonte suit les règles Minecraft.
+Les captures intègrent le post-traitement et la brume Sanctuary ; aucune
+compatibilité avec un moteur externe Iris/Canvas/Oculus n’est déclarée.
+
+## Vérifications
+
+- `seasonal105Smoke` : 40 000 tirages, stabilité par graine/jour,
+  équinoxes/solstices 2026 à ± une heure, inversion sud, proportions saisonnières,
+  persistance d’une journée de neige et passage au lendemain.
+- `Living105ClientChecks` : client natif Minecraft 26.3 avec serveur intégré,
+  nouveau monde plat jetable. Journal avec page préalable, caresse/blessure,
+  récupération, récolte/replantation/retrait, vache attirée par le blé, cochon
+  guidé, vraie méthode d’impact de boule de neige, feu/usure, vol d’une vache,
+  apparition du spawner configuré, éclair/impulsion/extinction du paratonnerre,
+  neige déposée par `tickPrecipitation`, requête de flocons côté client,
+  molette suivant/précédent/bornes et deux panoramas complets de six faces.
+- Pour chaque face à saturation 0, contrôle des pixels désaturés ; comparaison
+  à saturation 200, présence de `sanctuary:vanilla_light` et profondeur du sol
+  conservée. Les vues sont soumises séparément au GPU pour éviter de réutiliser
+  les tampons natifs avant leur soumission. Aucun échec de post-traitement dans
+  l’essai final (53 secondes).
+
+Commande de reproduction :
+
+```sh
+JAVA_HOME=/chemin/vers/jdk25 ./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryLiving105ClientTests=true \
+  -PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true
+```
+
+Le délai serveur de trois ticks entre changements de page est supprimé : les
+paquets sont toujours validés contre l’identifiant du menu ouvert et son curseur.
+Les anciennes pages ne peuvent donc pas accepter de clics après remplacement.
+Le client et le serveur doivent utiliser ensemble beta.105 pour les nouveaux
+profils réseau de neige. Les anciens états enregistrés restent lisibles.
+
+## Livraison locale
+
+`check build assemblePack assembleTestPack -x :sanctuary:runGameTest` réussi
+sur la copie isolée `build/release-beta105` : 2 min 43 s, 125 tâches.
+Le test dédié est exclu conformément au refus antérieur de son EULA ; le test
+natif de cette livraison utilise un serveur intégré dans un monde neuf jetable.
+
+La copie part des sources et ressources vérifiées beta.104, auxquelles sont
+appliqués les 25 fichiers Java concernés, les libellés météo FR/EN et les mixins.
+Elle évite d’embarquer les modifications du chantier Statuaire beta.106 arrivé
+en parallèle dans le dossier partagé. Le travail beta.106 est conservé.
+`build/beta105-source-manifest.json` décrit les sources de cette compilation.
+
+Les sources JAR correspondent à cette copie ; les ressources du pack beta.104
+restent identiques sauf les deux fichiers de langue. JAR sans classes de test,
+archives et métadonnées 26.3 vérifiées ; archives beta.104 inchangées. Rapport :
+`build/beta105-artifact.json`. Aucun déploiement ni publication du canal.
+
+- [Sanctuary-beta.105.mrpack](../build/Sanctuary-beta.105.mrpack), 10083681 octets.
+  SHA-256 : `396c31ad80b4826e5cc0530001e90e498dfb3d36f951cb46d01b32870bf3212a`.
+- [Sanctuary-Test-beta.105.mrpack](../build/Sanctuary-Test-beta.105.mrpack), 10102603 octets.
+  SHA-256 : `6398eb413ea45cf383b71d5be07cb1eef6995158fe0909b06deabb36c1623ce4`.

docs/loading-animation-beta068.md

@@ -0,0 +1,68 @@
+# beta.068 — animation discrète du préchargement
+
+Branche `codex/loading-animation-beta068`, ticket LOAD-03.
+
+## Comportement
+
+Une ligne de neuf glyphes SGA, encadrée de crochets ASCII, accompagne les
+étapes réelles de préparation. Elle utilise la police d’enchantement native
+`minecraft:alt` : les lettres de Sanctuary, avec une lumière grise/blanche
+qui parcourt la ligne dans les deux sens en 3,2 secondes. Le fond uni et les
+textes Minecraft restent sobres. Aucun pourcentage fictif ni nouvelle texture.
+
+L’animation dépend de l’horloge monotone lue pendant chaque rendu, pas des
+ticks : elle continue pendant les longs calculs d’une même phase. Les glyphes
+sont préparés une seule fois, sans sondage de terrain ni travail serveur.
+
+La même ligne accompagne ensuite le téléchargement natif du terrain, sous la
+carte des chunks lorsqu’elle existe. La carte et la barre de progression de
+Minecraft conservent leur rendu et leur comportement. Si une interface trop
+petite ne laisse pas de place sous les chunks, l’indicateur est masqué plutôt
+que de recouvrir la progression. Les transports par portail sont hors de ce
+changement. L’introduction longue, sa musique, le flash et Hello World restent
+inchangés, comme le cache dérivé et les étapes publiées par le serveur.
+
+## Vérifications natives
+
+Client natif 26.3-pre-2 réussi en **41 s**. Huit captures pendant une phase
+identique, avec la méthode `tick()` de l’écran volontairement inactive. Les
+sept comparaisons de pixels successives diffèrent uniquement dans la ligne
+de glyphes ; le titre, le fond et l’étape restent identiques.
+
+Inspection FR/EN dans la fenêtre native 854 × 480, réglages GUI 2/3/4 avec
+le plafonnement automatique de Minecraft à la taille disponible. La carte des
+chunks et sa barre native restent visibles ; le message générique hors
+préparation garde son rendu habituel. Ces écrans de test utilisent des états
+fixes, sans créer de monde ni simuler un pourcentage dans le code livré.
+Les caches et les cycles de démarrage n’ont pas été modifiés ni remesurés ici.
+
+Preuves locales : `build/loading068-client.log`, les captures et la comparaison
+`build/loading068-evidence/animation-check.json`. Le test ne lance aucun serveur
+et ne demande aucune acceptation d’EULA.
+
+```sh
+JAVA_HOME=/Users/koka/Library/Java/JavaVirtualMachines/temurin-25.jdk/Contents/Home \
+./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryLoading068ClientTests=true \
+  -PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
+```
+
+## Livraison locale
+
+`check build assemblePack assembleTestPack` réussi en **2 min 15 s**, 122 tâches,
+avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
+-PsanctuaryQuickTests=true`. Aucun serveur dédié lancé.
+
+Les **1 647 classes** de l’archive correspondent à la compilation. Seuls
+`LoadingGlyphs`, `PreloadScreenMixin` et `PreloadTerrainScreenMixin` changent
+par rapport à beta.067. Intro, Hello World, cache, logique serveur, textures,
+sons, traductions et JEI restent identiques. Les archives beta.067 gardent
+leurs empreintes. Reçu : `build/loading068-artifact.json`.
+
+- [Pack normal beta.068](../build/Sanctuary-beta.068.mrpack), 5726390 octets.
+  SHA-256 : `cfb55d414186e6be5f0e19770049158302d4fbf37c0fa696306acda428594a2e`.
+- [Monde plat rapide beta.068](../build/Sanctuary-Test-beta.068.mrpack), 5745324 octets.
+  SHA-256 : `643913caf577ee61b23747f378e9a21f5b1a54531901791d47d8ad0a75531dff`.
+
+Aucun déploiement dans Prism, aucune publication du canal et aucun monde
+personnel modifié.

docs/loading-cache-beta064.md

@@ -0,0 +1,138 @@
+# beta.064 — cache des plans et préchargement natif
+
+Branche `codex/loading-cache-beta064`. Reprend l'audit beta.063 et conserve les
+travaux préexistants (HUD du resource pack et documentation des capes inclus).
+
+## Contrat du cache dérivé
+
+Le cache est facultatif et reconstructible dans `cache/sanctuary-plans-v1/`
+sous le dossier du monde. Il ne change aucun chunk, aucun journal d'expansion,
+aucune donnée d'habitant ni les paramètres du générateur. Un ancien monde sans
+cache suit exactement le calcul existant et remplit le cache ; supprimer ce
+répertoire rétablit le même calcul. Pas de migration de sauvegarde nécessaire.
+
+Les clés comprennent la graine, le générateur et ses paramètres, l'option
+structures, les versions des mods et toutes les couches de ressources de
+génération (`worldgen`, `structure`, `tags`, `dimension`, `dimension_type`) et
+les modèles NBT locaux de `generated/`. Les
+plans structurels incluent aussi la liste des îles concernées. Un changement
+invalide le cache ; une entrée illisible, incomplète ou dont l'empreinte diffère
+est ignorée puis recalculée. Écriture temporaire, synchronisation et renommage
+atomique. Aucun objet Minecraft vivant, monde, chunk ou état RNG n'est sérialisé.
+Les index dérivés sont reconstruits à partir des géométries validées.
+
+Le cache couvre l'hydrologie régionale (eau, terrasses, écoulements et lave),
+les traversées, salles souterraines, sanctuaire minier, ruines et patrimoine de
+la racine, ainsi que les pièces natives du village, des mines, des temples et
+des ruines asséchées. Ces dernières utilisent le NBT natif de Minecraft, dont
+la lecture doit restituer exactement la même écriture ; sinon elles sont
+recalculées. Les pièces restaurées appartiennent au nouveau serveur, sans
+réutiliser les objets du serveur précédent. Le lecteur vanilla des pièces jigsaw
+recalcule leurs limites à partir du modèle et perd les extensions réservées aux
+jonctions : le cache réapplique ces limites enregistrées, puis exige une égalité
+NBT complète. Cette correction reste locale au lecteur du cache, sans mixin de
+chargement des chunks ni modification des structures sauvegardées.
+
+Les plans aériens conservent leur journal persistant existant, qui fait
+également autorité. Les anciennes générations et les villes des expansions
+conservent leurs planificateurs actuels ; la livraison cible les plans de
+l'île Sanctuary actuelle (`generation24`, terrain alpha.30.7).
+
+## Préchargement
+
+Texte et étapes issus du travail réel du serveur intégré, fond uni et graphisme
+Minecraft. Aucun portail du Nether dans cette préparation. L'introduction,
+Hello World, sa durée, sa musique et le flash restent inchangés. Les étapes de
+calcul n'affichent pas de pourcentage inventé ; Minecraft fournit sa progression
+réelle des chunks dès qu'elle est disponible. La préparation locale affiche
+les étapes publiées par le serveur intégré avant même l'admission réseau.
+Un client distant ne reçoit pas de faux état d'un serveur qui n'a pas encore
+ouvert sa connexion : il conserve les étapes natives du téléchargement.
+Le transport dimensionnel par portail reste un écran Minecraft distinct.
+
+Les libellés FR/EN suivent le travail : vérification/lecture du cache, eau et
+lave, traversées, salles, sanctuaire minier, ruines, patrimoine, îlots aériens,
+village, mines, temples, enregistrement et point d'arrivée. Deux lignes
+centrées sur fond uni remplacent l'attente générique ; aucune texture ajoutée.
+La progression native des chunks et ses conditions de fermeture restent gérées
+par Minecraft. Aucun nouveau bouton d'annulation ne force un arrêt au milieu
+d'un calcul ou d'une écriture.
+
+## Vérification reproductible
+
+Client natif 26.3-pre-2, serveur intégré uniquement, monde de développement
+neuf : graine `42`, île moyenne de diamètre `724`, structures actives,
+distances de rendu et simulation de `8`. Première arrivée avec les 29,5 secondes
+d’introduction complètes. Ensuite réouverture du même monde, puis remplacement
+d’une seule entrée de cache par un contenu tronqué et nouvelle réouverture.
+
+Le contrôle compare les géométries des plans, l’eau et la lave, les index par
+colonne et par chunk, les écritures de blocs et de butin des renderers et une
+grille de points de protection. La lecture des pièces natives exige une égalité
+NBT complète après restauration. Les essais de fichiers couvrent l’absence,
+le changement de clé, une copie sous une mauvaise identité, un checksum faux,
+une validation refusée et un gzip tronqué. Chaque refus retombe sur le calcul.
+
+L’écran est rendu par Minecraft en FR/EN pour inspection visuelle. Les phases
+observées pendant le véritable démarrage sont enregistrées indépendamment des
+ticks du client, qui ne tournent pas pendant sa première boucle de chargement.
+Mesure locale du 15 septembre 2026, même scénario que l’audit beta.063 :
+
+| Parcours | Durée jusqu’au jeu |
+|---|---:|
+| Première création, cache vide, introduction complète | 122,255 s |
+| Réouverture avec cache | 2,126 s |
+| Entrée structurelle corrompue, recalcul automatique | 39,177 s |
+| Référence beta.063, réouverture sans cache | 58,701 s |
+
+Il s’agit d’une mesure sur cette machine et cette graine, pas d’une garantie de
+durée. Le cache accélère surtout les réouvertures ; un monde neuf doit toujours
+calculer ses plans et préparer ses chunks. Les mises à jour de version ou de
+ressources invalident volontairement les anciennes entrées. La première
+réouverture d’un ancien monde sans cache sert à le remplir.
+
+Réouverture : **3 lectures réussies, 0 échec, 0 écriture**. Récupération :
+**3 lectures réussies, 1 échec attendu, 1 remplacement**. Comparaison identique
+des **217 053 écritures de blocs/butin** et de 93 150 points de protection,
+ainsi que des plans et des index fluides. Les 17 étapes utiles du scénario ont
+été observées ; les libellés FR/EN et les captures natives sont vérifiés.
+Preuves locales : `build/loading064-client.log`,
+`build/loading064-evidence/timings.json` et captures dans le même dossier.
+
+
+```sh
+JAVA_HOME=/Users/koka/Library/Java/JavaVirtualMachines/temurin-25.jdk/Contents/Home \
+./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryLoading064ClientTests=true \
+  -PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
+```
+
+Le drapeau de test rapide facilite l’automatisation ; ce scénario réactive
+explicitement l’introduction longue avant la validation de Hello World.
+Aucun serveur dédié lancé, aucune EULA acceptée, aucun monde personnel modifié.
+
+
+## Livraison locale
+
+`./gradlew check build assemblePack assembleTestPack` réussi en **2 min 21 s**,
+**122 tâches**, avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
+-PsanctuaryQuickTests=true`. Le parcours natif plat/classique, avec Sanctuary
+activé/désactivé puis réouverture, passe ses **8 ouvertures** en 53 s
+(`build/gameplay064-client.log`). Les tests dédiés exclus restent remplacés ici
+par les essais du serveur intégré, conformément au refus d’accepter leur EULA.
+
+Archives comparées à beta.063 : **1 645 classes conformes à la compilation**,
+ressources FR/EN, mixins, métadonnées, dépendances exactes et absence de tests
+dans le mod. Les classes de Hello World, de l’introduction, les sons, les
+textures, les données de génération et JEI sont inchangés. Les variantes
+normal/Test diffèrent uniquement par le module de test rapide et leur nom.
+Les anciens MRpacks beta.063 conservent leurs empreintes originales.
+
+- [Pack normal beta.064](../build/Sanctuary-beta.064.mrpack), 5720330 octets.
+  SHA-256 : `c05b78e2caf27d52cb318979ee66e19e5bca9c90673f8868ae50f85f0e2ff2c0`.
+- [Monde plat rapide beta.064](../build/Sanctuary-Test-beta.064.mrpack), 5739264 octets.
+  SHA-256 : `962800291875ab5bebda1abaedc798e7cf110ba0ef13ac168a0b85b3b2c19d24`.
+
+Reçu : `build/loading064-artifact.json`. Aucun canal publié ni instance Prism
+modifié. Les optimisations de sondages partagés et de parallélisation de la
+première création proposées dans l’audit restent des tickets ultérieurs.

docs/loading-gameplay-beta063.md

@@ -0,0 +1,231 @@
+# beta.063 — audit du chargement et règle de jeu Sanctuary
+
+> Suite livrée dans [beta.064](loading-cache-beta064.md) : cache des plans et
+> étapes réelles sur fond uni, sans le portail de la proposition ci-dessous.
+> L’audit et les mesures beta.063 restent conservés ici.
+
+Branche `codex/loading-audit-gameplay-beta063`, après beta.062 conservée.
+
+## Contrat
+
+L'audit mesure séparément le démarrage du client, la création du terrain,
+Hello World, l'introduction et l'arrivée. Il compare une île neuve, sa
+réouverture, un monde plat et un monde Minecraft classique, sans utiliser
+de sauvegarde personnelle. L'habillage du préchargement est une proposition
+à examiner, pas une optimisation de terrain déjà livrée.
+
+La règle native `sanctuary:use_sanctuary`, « Utiliser Sanctuary », permet
+de choisir les règles Sanctuary à la création d'un monde, indépendamment
+de son générateur. Elle est activée par défaut dans le pack ; la désactiver
+avant la création conserve les capacités ordinaires du joueur. Activée sur
+un monde plat ou classique, elle apporte Hello World, la progression,
+l'inventaire, les familiers, les factions et les systèmes qui en dépendent,
+ainsi que les modes temporel et météorologique Sanctuary.
+
+Cette règle ne change jamais le générateur, le spawn natif, les chunks ou les
+structures du monde choisi. Les fonctions propres aux îles et aux expansions
+restent réservées à ce terrain. Les ressources et ajouts autonomes du mod
+restent chargés, y compris quand cette règle est désactivée.
+
+Le choix est fixé pour la partie : les commandes et options d'une partie
+déjà ouverte ne peuvent pas le basculer. Le serveur conserve le choix natif
+dans `level.dat` ; les données existantes d'habitant continuent d'identifier
+une partie Sanctuary lors des réouvertures. Pas de nouveau format propriétaire.
+Les parties Sanctuary et le module plat de test antérieurs conservent leur
+admission historique ; la protection existante des anciennes parties sans
+progression reste appliquée. Aucun Overworld classique déjà joué n'est
+converti automatiquement. Une conversion reste hors de cette livraison,
+conformément à la précision de l'utilisateur.
+
+## Mesures du 15 septembre 2026
+
+Client natif Minecraft **26.3-pre-2**, Fabric **0.19.5**, API
+**0.160.0+26.3**, Java 25 ; Mac Apple M1, huit processeurs logiques,
+tas JVM 2 Gio. Une exécution par scénario dans le même client, dans cet
+ordre, avec enregistrement JFR `profile`. Graine **42**, île Moyen **724**,
+structures actives, distances de rendu et de simulation **8**. Les autres
+applications du bureau restent ouvertes. Ce sont des observations locales,
+pas une moyenne représentative ni une preuve de gain entre versions.
+
+Le compteur commence à la demande de création/ouverture. « Jouable » signifie
+joueur présent, écran de jeu actif et fondu d'arrivée terminé. Hello World est
+validé automatiquement ; le temps passé à choisir son personnage est exclu.
+L'introduction complète reste active, même sur les terrains Minecraft.
+
+| Scénario | Hello World prêt | Fin de la séquence d'introduction | Jouable |
+| --- | ---: | ---: | ---: |
+| Nouvelle île Sanctuary | 74,292 s | 103,889 s | **122,101 s** |
+| Réouverture de cette île | Déjà accompli | Non rejouée | **58,701 s** |
+| Nouveau monde plat + Sanctuary | 0,929 s | 30,489 s | **33,246 s** |
+| Nouveau monde classique + Sanctuary | 3,809 s | 33,458 s | **37,632 s** |
+
+Le premier lancement du processus client jusqu'au début du parcours au menu
+prend environ **15 s**, en plus de ces durées. Il utilise les ressources déjà
+présentes sur cette machine : ce n'est pas une installation ou un cache disque
+à froid. Le profilage commence aux scénarios monde ; ce démarrage client est
+chronométré, mais pas attribué fonction par fonction.
+
+## Ce qui se passe réellement
+
+1. Le client charge les classes, ressources, textures et sons. L'enregistrement
+   des services Sanctuary n'est pas encore la planification complète des îles.
+2. Après « Créer », le serveur intégré construit les niveaux. Dans
+   `ExpansionRuntime.register`, l'événement `ServerLevelEvents.LOAD` prépare les
+   plans du générateur : eau, traversées, réseaux souterrains, sanctuaire minier,
+   patrimoine, village et expéditions. Cette étape bloque l'accès à Hello World.
+3. Le serveur choisit le spawn et prépare les chunks d'arrivée. La configuration
+   réseau ouvre Hello World puis l'introduction ; une partie de la préparation
+   du monde continue pendant ces **29,5 s** de cinéma.
+4. La séquence se termine, mais le monde peut ne pas être prêt. L'écran blanc
+   couvre alors l'attente, puis le fondu rend le jeu visible. Sur l'île mesurée,
+   environ **18,2 s** séparent la fin de l'intro de l'état jouable.
+
+La première planification de l'Overworld occupe environ **58,8 s** entre
+`SERVER_STARTING` et la fin de son événement `LOAD`. À la réouverture, elle
+occupe encore **56,8 s**. La majeure partie de ces plans est recalculée à chaque
+nouvelle instance du générateur ; le journal aérien existant ne met pas tous
+les autres plans en cache.
+
+Le `Time elapsed` natif est trompeur pour cet audit : il annonce **434 ms** à
+la réouverture alors que l'entrée prend **58,7 s**. Ce compteur démarre après
+les calculs lourds. Il ne doit pas servir seul de mesure du chargement complet.
+
+## Où part le CPU
+
+Les journaux de cette réouverture attribuent **23,913 s** aux traversées,
+**14,590 s** au patrimoine, **7,758 s** au sanctuaire minier et **2,999 s** au
+village. L'hydrologie annonce **13,052 s**, mais elle est appelée pendant la
+préparation des traversées : **ne pas additionner ces deux durées**.
+
+Dans les échantillons JFR des méthodes Java en exécution à la réouverture :
+
+| Méthode | Part des échantillons |
+| --- | ---: |
+| `SmearedPerlinNoise.addToVolume` | 37,81 % |
+| `NoiseStack.Perlin.get` | 22,80 % |
+| `GradientNoise.permute` | 8,51 % |
+
+Ces trois fonctions de bruit totalisent **69,12 %** des échantillons. Ce n'est
+ni une part exacte du temps mural ni un gain récupérable annoncé. Les pauses
+GC totalisent **838 ms** sur le profil de réouverture, contre **1,71 s** pour
+la création de l'île. La pression mémoire existe, mais elle n'explique pas
+l'essentiel de cette attente ; augmenter seulement la RAM ne cible pas le
+coût dominant identifié.
+
+Les profils incluent quelques secondes de jeu et la fermeture du monde.
+Une première tentative avec `waitForChunksDownload()` a attendu la complétion
+du rendu au-delà de l'arrivée jouable ; elle est conservée à part et exclue
+des résultats ci-dessus. Les assertions finales utilisent la présence du joueur,
+l'écran natif et la fin du fondu, pas ce critère plus strict du banc de tests.
+
+Sources : `ExpansionRuntime.java:35`, `SanctuaryChunkGenerator.java:93` et `:291`,
+`ProgressionService.java:194`, `IntroScreen.java:51` et `:170`,
+`IntroSpawnFlash.java:20`. Les appels répétés à `prepareTransit` sont gardés :
+certains sont protégés et certains prennent en compte les liens du patrimoine.
+L'audit n'en déduit pas qu'ils peuvent simplement être supprimés.
+
+## Habillage proposé, après retour utilisateur
+
+**Conserver toute l'introduction**, sa durée, sa musique au dévoilement du
+portail et son flash. L'habillage proposé concerne uniquement l'attente qui
+précède Hello World et la réouverture d'une partie.
+
+Écran sobre proche de Minecraft : fond sombre uni, portail natif au centre,
+texte Minecraft discret et bouton Annuler natif. Aucun grand logo ajouté,
+aucune carte décorative, aucun encadrement ni panneau de diagnostic permanent.
+Les textures du portail, de l'obsidienne, du bouton et la police bitmap de la
+proposition proviennent des ressources locales de Minecraft 26.3-pre-2.
+
+Le texte décrit l'étape réelle : ressources, calcul du terrain, préparation
+des alentours. Une barre et un compte de chunks peuvent apparaître uniquement
+lorsque leur total est connu ; les calculs de plans restent sans faux pourcentage.
+Le compteur `86 / 225` de la maquette est un exemple d'état, pas une mesure.
+Annuler demande un arrêt propre au serveur, sans quitter au milieu d'une
+écriture. Son comportement réel devra être intégré et testé avec l'écran.
+
+La proposition interactive a été simplifiée après rejet de la première
+direction. **Elle n'est pas intégrée au rendu du jeu dans beta.063.**
+
+## Prochains tickets proposés
+
+| Priorité | Résultat vérifiable | Garde-fous / validation |
+| --- | --- | --- |
+| 1 — Cache des plans | Réouvrir une île en relisant ses plans dérivés validés | Clé graine, révision de génération, paramètres et configurations ; écriture atomique ; corruption ou cache absent → recalcul ; comparaison exacte des plans et chunks, sans régénérer de monde utilisateur. Contrat de cache à formaliser avant développement. |
+| 2 — Préchargement natif | Afficher l'écran épuré dès le début de la création et à la réouverture | Phases instrumentées, fermeture propre, texte FR/EN, annulation et erreur visibles ; intro intacte ; mesures du coût de l'écran. |
+| 3 — Réutiliser les sondages | Éviter les colonnes de terrain recalculées entre plusieurs planificateurs | Cache borné, mêmes entrées et mêmes valeurs, empreintes bit à bit sur plusieurs graines ; reprendre la méthode de `docs/initial-loading.md`. |
+| 4 — Travail en parallèle | Réduire le chemin critique restant après les caches | Seulement sur données immuables ; aucun accès au niveau Minecraft depuis des threads arbitraires ; gains mesurés et déterminisme vérifié. |
+
+Aucun gain de ces futurs tickets n'est compté comme livré. La génération et
+ses paramètres sont inchangés dans beta.063. La proposition respecte le choix
+de conserver l'intro ; l'attente blanche mesurée reste un constat, pas une
+modification autorisée de cette séquence.
+
+## Utiliser la règle de jeu
+
+À la création d'un nouveau monde, choisir le terrain **classique** ou
+**plat**, puis laisser **Utiliser Sanctuary : Oui** dans les règles de jeu,
+catégorie Joueur. Hello World et les règles Sanctuary s'appliquent au terrain
+natif. Les capacités ordinaires sont conservées avec **Non**. Ce choix ne
+nécessite pas une installation du module de test rapide.
+
+`/gamerule sanctuary:use_sanctuary` permet de consulter le réglage. Une tentative
+de changement en jeu est refusée avec une explication FR/EN ; les autres règles
+restent modifiables. La capture du choix se fait au chargement de l'Overworld :
+dans cette version, `getGlobalGameRules()` n'est pas disponible avant sa création.
+
+## Vérifications
+
+- Audit client natif : île neuve, même île réouverte, plat et classique neufs,
+  intro complète ; `LOADING063_AUDIT_PASS`.
+- Parcours fonctionnel client et serveur intégré : plat/classique × activé/
+  désactivé, chacun créé puis réouvert, soit **8 ouvertures** ;
+  `GAMEPLAY063_PASS`. Vérifie Hello World uniquement si activé, sa non-répétition,
+  le familier initial conservé, les 3/10 cœurs et 1/4 rangées selon le mode,
+  l'absence de session d'expansion sur terrain natif, le temps et la météo.
+- Vérifie le refus des mutations en jeu des règles globales et du niveau,
+  le refus explicite de la commande et la modification d'une autre gamerule.
+  Libellé et description natifs testés en français et en anglais.
+- La non-conversion des anciens mondes classiques repose sur la garde
+  d'admission examinée dans le code ; aucun monde personnel n'est ouvert.
+
+Commandes reproductibles (Java 25) :
+
+```sh
+./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryLoading063ClientTests=true \
+  -PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
+
+./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryGameplay063ClientTests=true \
+  -PsanctuaryQuickTests=true -PsanctuaryClientNoVsync=true
+```
+
+Preuves locales ignorées : `build/loading063-audit.log`,
+`build/loading063-evidence/timings.tsv` (extrait des événements du journal),
+les deux profils JFR d'île et leurs vues CPU/GC dans ce même dossier,
+`build/gameplay063-client.log`. Les JFR plat/classique du dossier temporaire
+du runner ont été nettoyés au test suivant ; leurs chronométrages restent dans
+le journal intégral. Archiver `mods/sanctuary/build/run/clientGameTest/loading063/`
+avant de relancer un parcours pour conserver tous les profils.
+
+`./gradlew check build assemblePack assembleTestPack` réussit en **2 min 22 s**,
+avec `-x :sanctuary:runGameTest -PsanctuaryClientTests=true
+-PsanctuaryGameplay063ClientTests=true -PsanctuaryQuickTests=true
+-PsanctuaryClientNoVsync=true`. Les tests serveur dédiés restent exclus, selon
+le refus antérieur d'accepter leur EULA ; les huit ouvertures ci-dessus utilisent
+le serveur intégré au client natif et vérifient réellement les règles côté serveur.
+
+Les deux archives locales sont vérifiées : dépendances exactes, ZIP, identité
+des **1 628 classes compilées**, ressources, absence de classes de test, même
+contenu normal/Test sauf le module rapide. Le JAR, les classes d'introduction,
+les ressources et les sons non concernés sont comparés à beta.062 ; le terrain
+et toute la séquence d'introduction restent identiques. Les anciens packs
+beta.062 sont conservés avec leurs empreintes originales.
+
+- [Pack normal beta.063](../build/Sanctuary-beta.063.mrpack), SHA-256
+  `1af1ff168f5cf97d7f44bb28398eb79efae8e1c4858f05d5b4291b1dfe48ad93`.
+- [Pack Test beta.063](../build/Sanctuary-Test-beta.063.mrpack), SHA-256
+  `405a55e76233c8403f27320f104e09ee590cae652b97b4396dd6a5b1a7dd0531`.
+
+Reçu `build/loading063-artifact.json`, build `build/loading063-check.log`.
+Pas de déploiement Prism, de changement de canal ou de sauvegarde personnelle.

docs/main-menu-beta194.md

@@ -0,0 +1,50 @@
+# UI-194 — retirer Amis du menu principal
+
+Branche `codex/main-menu-beta194`, depuis beta.193, Minecraft 26.3.
+
+Le créateur suspend les retouches du terrain et les tests de screenshots,
+puis reprend le cadrage des interfaces. Le retrait d’Amis est la première
+modification demandée, déjà prévue dans [Storyquest](storyquest-beta173.md).
+
+## Résultat
+
+Le menu principal propose Solo, Multijoueur, puis Options et Quitter sur une
+même ligne. Cette dernière suit Multijoueur avec l’espacement natif de 24 unités
+GUI. Le bouton Amis n’est plus créé à la place de Realms ; l’entrée Realms et
+la petite icône sociale restent retirées. Les commandes restantes gardent
+leur ordre clavier et la version Sanctuary reste affichée.
+
+Le parcours de démonstration, dépourvu de Multijoueur, conserve sa disposition
+antérieure. Les autres accès sociaux et paramètres du compte ne sont pas
+modifiés. Aucun nouveau libellé : les commandes natives restent traduites FR/EN,
+les anciennes clés `sanctuary.menu.friends` sont conservées pour compatibilité.
+
+Le menu pause, Habitant, Combat, Factions et Storyquest restent des suites
+à concevoir. Aucune source de génération, donnée de biome ou sauvegarde n’est
+modifiée par ce lot. Aucune nouvelle série de captures n’est lancée.
+
+## Vérifications
+
+Le parcours natif existant `Title045ClientChecks` est actualisé pour vérifier
+l’absence d’Amis et de Realms, la disposition sans ligne vide, l’ordre clavier
+et l’ouverture d’Options en FR/EN aux quatre réglages GUI. Ses captures et son
+ancien parcours vers la liste d’amis sont retirés.
+
+Validation réussie : `./gradlew check build assemblePack assembleTestPack
+:sanctuary:runClientGameTest -PsanctuaryFocusedTests=menus
+-PsanctuaryClientTests=true -PsanctuaryTitleClientTests=true
+-PsanctuaryClientGraphicsBackend=vulkan`.
+Journal : `build/menu194-check-build.log`. Les contrôles purs et les quatre
+GameTests serveur ciblés passent. Le parcours client Vulkan passe en FR/EN,
+sans capture, avec ordre clavier, absence des boutons retirés et ouverture
+d’Options vérifiés. Dans la fenêtre 854 × 480 du test, les réglages GUI 3 et 4
+sont plafonnés par Minecraft à l’échelle effective 2.
+
+Les packs normal et de test sont assemblés. La comparaison des JAR beta.193 et
+beta.194 confirme que seule `TitleMenuMixin.class` change dans le code livré ;
+les données de génération sont identiques. Le module Demeure embarqué ne change
+que de version dans ses métadonnées. Reçu : `build/menu194-artifact.json`.
+Le labo beta.193 déjà ouvert n’est ni arrêté ni mis à jour par cette livraison.
+
+Livraison locale uniquement ; publication et mise à jour du jeu personnel
+ne sont pas demandées.