Document beta.203 backup and single-mod consolidation audit

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,74 @@
+# 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.

README.md

@@ -1,5 +1,466 @@
 # Sanctuary
 
+## beta.203 — fractures et taïga géante au Nord
+
+[Dernière passe du Nord](docs/north-fracture-beta203.md) : variations de relief
+et ouvertures par bruit 3D, lisières de podzol irrégulières, épicéas pouvant
+atteindre 64 blocs. La neige ajoutée après végétation est retirée ; les sommets
+mêlent roche, neige et plusieurs glaces. Bassins protégés, cinq igloos conservés,
+aucun nouveau village. Profils neufs seulement, Nord 1024.
+
+## beta.202 — taïga et neige étagée au Nord
+
+[Écologie nordique](docs/north-ecology-beta202.md) : relief et lacs 201 conservés,
+vallées ouvertes et taïga sur herbe/podzol, grands épicéas et pics de glace natifs.
+La neige varie avec l'altitude et le climat ; la glace des grottes reste derrière
+une enveloppe rocheuse. Le village cherche une plaine entièrement enneigée.
+Profils neufs uniquement, expansion de 1024 blocs.
+
+## beta.201 — Nord compact et pics de glace vanilla
+
+[Glacier nordique](docs/north-glacier-beta201.md) : diamètre ramené à 1024,
+glace visible, deux lacs, bosquets d'épicéas et pics natifs `ice_spike` / `ice_patch`.
+Le village de cinq igloos et son laboratoire sont conservés et rapprochés du lac.
+Profils neufs uniquement ; les paysages froids des diagonales restent à concevoir.
+
+## beta.200 — premier Nord glacial
+
+[Expansion nordique](docs/north-expansion-beta200.md) : territoire de 2048 blocs,
+crêtes enneigées, taïga, cavernes de glace, lacs gelés et village de cinq igloos,
+dont un laboratoire souterrain. Placement dans la direction de l’ancre ; arrivée
+et relais préparés, puis génération pendant l’exploration. Nouveaux mondes uniquement.
+Export local : [MRpack de test](build/Sanctuary-Test-beta.200.mrpack).
+Compilation, contrôles ciblés et activation/reprise du Nord vérifiés ; la suite
+historique complète reste non validée, avec le détail dans le ticket.
+
+## beta.199 — relais d’expansion en cours de partie
+
+[Affinage du moteur existant](docs/runtime-expansions-beta199.md) : recherche
+automatique proche sur 360°, régions minces, relais de continuation, reprise
+après fermeture et annonce SGA à la fin. Nouveaux mondes de laboratoire
+Small/Medium/Large ; étoiles synchronisées sur sept journées Minecraft.
+
+## beta.198 — correction du plantage de création Large
+
+[Admission de la galerie centrale](docs/gallery-generation-beta198.md) :
+correction du défaut reproduit avec la graine Windows fournie, en conservant
+le portail au centre et les anciens profils. Nouveaux mondes uniquement.
+
+## beta.197 — arrivée et détails du laboratoire
+
+[Corrections du laboratoire](docs/worldgen-fixes-beta197.md) : départ sur
+l’île, cascades ouvertes vers l’extérieur, sol minier sans diagonales répétées
+et toit de cabane continu. Nouveaux profils Small/Medium/Large ; enquête séparée
+sur l’arrêt signalé chez un ami à la création Large.
+
+## beta.196 — laboratoire à partager
+
+[Pack de test Small, Medium et Large](docs/shared-lab-beta196.md) : une entrée
+Sanctuary, taille personnalisable, dernier terrain du labo et atlas adapté.
+Diagnostic du chargement et enregistrement JFR optionnel ; anciens mondes conservés.
+
+## beta.195 — choix de génération simplifiés
+
+[Sanctuary et les types vanilla](docs/worldgen-options-beta195.md) restent dans
+la création de monde ; les variantes de labo sont masquées, leurs sauvegardes
+restent lisibles. Nouvelle visite demandée sur le profil beta.193, graine 0,
+avec le menu principal sans Amis. Le terrain est conservé pour cette comparaison.
+
+## beta.194 — menu principal sans Amis
+
+[Reprise des interfaces](docs/main-menu-beta194.md) : Solo et Multijoueur sont suivis
+directement d’Options et Quitter, sans bouton Amis ni ligne vide. Le
+[fil rouge](docs/storyquest-fil-rouge.md) reprend les interfaces et le Storyquest ;
+les retouches de génération et les séries de captures sont suspendues.
+
+## beta.193 — raccordements et comparaison visuelle
+
+[Laboratoire sur plusieurs graines](docs/worldgen-continuity-beta193.md) : réservations
+communes pour les bassins, ancres aériennes posées sur le terrain réel et
+entailles locales du massif. Le nouveau profil `coherent` ajoute des contrôles
+de collision entre aménagements et des visites photo Vulkan reproductibles.
+Les anciens profils et sauvegardes restent séparés.
+
+## beta.192 — couronnes et faces du massif
+
+[Variante de relief érodé](docs/eroded-massif-beta192.md) : sommets localement
+plus plats, faces rocheuses plus raides et entailles entre les reliefs.
+Profil neuf `eroded`, graine 42 ; couverture végétale selon la pente réelle.
+Les cavités profondes et les aménagements existants restent conservés.
+
+## beta.191 — relief d’avant les plateaux
+
+[Retour à la base beta.188](docs/restore-relief-beta191.md) : relief et géologie
+antérieurs aux plateaux, passes de roche 189/190 retirées. Les corrections
+indépendantes des berges, ancres, ruines et du portail restent présentes.
+Profil neuf `original`, graine 42 ; génération, réouverture, 265 GameTests et
+assemblages validés.
+
+## beta.190 — retour au relief naturel
+
+[Affinage de Sanctuary Island](docs/natural-refinement-beta190.md) : fin des
+terrasses systématiques, épaules locales et affleurements sans cases de quatre
+blocs. Déversoir proche de cinq blocs de large, coffres de fer enchanté dans les
+quatre ruines. Profil `refined`, nouveau solo graine 42, vue 32 chunks.
+Les reliefs très étagés passent dans la réserve des expansions futures.
+
+## beta.189 — berges, reliefs et portail inférieur
+
+[Finition de la génération](docs/terrain-finish-beta189.md) : refuges de surface
+adaptés à la roche, sédiments selon profondeur et pente, berges sableuses,
+plantations d’arbres protégées, reliefs étagés et affleurements. Portail inférieur
+éclairé, cascade locale et quatre ruines sans excavation. Profil `finish`, nouvelle
+sauvegarde, graine 42. 265 GameTests, génération, réouverture et assemblages réussis.
+
+## beta.188 — fonds d’étangs et soufre vivant
+
+[Laboratoire de finition](docs/living-details-beta188.md) : refuges adaptés
+au milieu et à leur couleur, fonds mêlant argile, boue, sable et gravier,
+végétation aquatique, pics et geysers natifs. Wagonnets avec une ou deux
+pièces en fer enchanté. Profil `details`, monde neuf, graine 42.
+265 GameTests, contrôles natifs et assemblages réussis ; solo Vulkan ouvert
+à 32 chunks. Les anciennes sauvegardes restent inchangées.
+
+## beta.187 — cavités de soufre et bassins de surface
+
+[Nouveau laboratoire](docs/natural-caves-beta187.md) : soufre intégré aux
+cavités existantes, trois bassins ouverts au ciel et huit ancres orientées
+vers leur expansion, avec approche depuis le centre. Profil `natural`,
+graine 42, nouvelle sauvegarde. Génération et réouverture vérifiées,
+265 GameTests et assemblages réussis ; solo Vulkan ouvert à 32 chunks.
+
+## beta.186 — rosaces et huit refuges d'ancres
+
+[Nouveau laboratoire](docs/hidden-anchors-beta186.md) : balcon supérieur sans
+barrières, liserés incrustés dans les deux dômes et huit ancres adaptées au terrain
+de leur secteur. Dépôts distincts reliés aux gemmes du Bugrock. Profil `anchors`,
+graine 42, nouvelle sauvegarde. Génération et réouverture vérifiées, 265 GameTests
+et assemblages réussis ; solo Vulkan ouvert à 32 chunks.
+
+## beta.185 — tige fine et portail de toiture
+
+[Variante de laboratoire](docs/fine-stem-beta185.md) : ligne de calcite d’un bloc,
+sans escalier ni paliers, fleur conservée, portail horizontal incrusté au sommet
+et jour fermé sous les vitres du palais. Profil `stem`, monde neuf, graine 42.
+265 GameTests, contrôles natifs et assemblages réussis ; solo Vulkan ouvert
+à 32 chunks, départ dans le palais supérieur.
+
+## beta.184 — ascension naturelle
+
+[Nouveau laboratoire](docs/natural-ascent-beta184.md) : rosace et Bugrock à Y=640,
+tige parcourable, palais vitré vers Y=1280 avec atlas au sol et portail horizontal.
+La couronne se découvre en montant. Les bassins supérieurs dessinés sont remplacés
+par le remplissage de creux existants. Profil `ascent`, nouveau monde uniquement.
+265 GameTests, contrôles natifs et assemblages réussis ; solo Vulkan ouvert à
+32 chunks, départ sur la rosace.
+
+## beta.183 — lieux et ressources de l’île
+
+[Nouveau laboratoire](docs/island-discovery-beta183.md) : portail horizontal,
+secteurs de gemmes, soufre repérable, bassin supérieur, ISS et rosace aux huit
+couleurs du Bugrock. ISS avec cartes horizontales, salle et mosaïque adaptées
+au rayon du terrain. Profil `discovery`, monde neuf ; contrôles natifs,
+265 GameTests et assemblages réussis. Solo préparé à 32 chunks.
+
+## beta.182 — galerie inférieure et rosace
+
+[Nouvelle scène de laboratoire](docs/origin-gallery-beta182.md) : galerie
+naturelle sous le centre, trois salles à plusieurs niveaux, emplacement
+d’obsidienne ; cloche vitrée au-dessus du Bug Rock et huit axes dégagés.
+Nouveau profil `gallery`, monde neuf, contrôles natifs, 265 GameTests et
+assemblages réussis. Solo à 32 chunks visité par le créateur, qui valide sa palette et sa rosace.
+
+## beta.181 — origine à Y=320
+
+[Premier repère central](docs/origin-landmark-beta181.md) : petite rose des vents
+ouverte sur un fragment rocheux, Bug Rock en (0,320,0), lumineux et monochrome.
+Nouveau profil de labo `origin`, fondé sur l’île beta.180 ; contrôle natif réussi
+et solo Vulkan ouvert à 32 chunks. Suite générale et assemblages réussis.
+Les salles d’ancres, secteurs de gemmes, soufre, portail et ISS sont cadrés
+comme suites à construire.
+
+## beta.180 — bassins et donjon minier
+
+[Variante de laboratoire](docs/adventure-ecology-beta180.md) : grands bassins
+avec débordements, trois cerisiers sur l’île, récifs cherry et automne.
+Donjon ramifié avec spawners et wagonnets à butin (diamants, émeraudes,
+rubis et saphirs), éclairage réduit et cornichons hors de l’eau retirés.
+Solo Vulkan ouvert à 32 chunks, contrôles ciblés, validation générale et
+assemblages réussis.
+
+## beta.179 — grottes vivantes
+
+[Essai de laboratoire](docs/living-caves-beta179.md) : quelques cerisiers aux
+sommets, fin des bordures rocheuses du plateau, poches lush en terrasses,
+marais à lucioles, chênes noirs et mycélium violet. Première version de
+complexes miniers et d’une cabane de sorcière souterraine. Monde neuf ;
+contrôle natif réussi et solo Vulkan ouvert à 32 chunks. Suite générale
+de validation et assemblages réussis.
+
+## beta.178 — vallées bornées et grottes rocheuses
+
+Le [nouvel essai solo](docs/rocky-ecology-beta178.md) limite l’automne aux
+vallées Y=200–232 et expose la roche sur les flancs profonds. Les grottes
+gardent des mares et de petites plaques de mousse. Nouveau monde de labo,
+graine 42, vue à 32 chunks et commandes activées ; contrôle ciblé réussi,
+suite générale et assemblages réussis.
+
+## beta.177 — les biomes suivent le relief
+
+Le [nouvel essai de laboratoire](docs/relief-ecology-beta177.md) réunit
+forêts et plaines fleuries sur le plateau, automne dans les creux extérieurs,
+cerisiers sur un sommet local et végétation humide sous roche. La mangrove
+et la neige sont retirées ; des gisements de pierre interrompent les strates.
+Solo Vulkan à 32 chunks, relevés natifs et réouverture vérifiés ; 265/265
+GameTests, `check build` et assemblages réussis. Détails dans la fiche.
+
+## beta.176 — strates, biomes et mares du labo
+
+Le [nouveau laboratoire écologique](docs/island-ecology-beta176.md) conserve
+le relief beta.175 et ajoute des strates ondulées, de grandes régions
+automnales et de cerisiers, des récifs végétalisés et des mares locales.
+Ses biomes excluent les structures natives, notamment les mineshafts.
+Trois graines et une réouverture vérifiées ; visite solo Vulkan à 32 chunks.
+Une réserve sur la suite générale des familiers est détaillée dans la fiche.
+Aucune modification des mondes existants.
+
+## beta.175 — récifs aériens et minerais du labo
+
+Le [nouveau profil de laboratoire](docs/sky-fragments-beta175.md) remplace les
+anciennes masses flottantes par des récifs rares en bruit 3D, au-dessus de
+l’île principale conservée. Y=512–639 reste réservé à l’ISS. Cuivre et charbon
+abondants, peu de fer, lapis et améthyste, diamant enfoui dans la deepslate ;
+aucun or ni redstone dans cette répartition. Relevés natifs plutôt que vues
+en jeu ; contrat, mesures et limites dans la fiche du lot.
+
+## beta.174 — laboratoire de relief Sanctuary
+
+Le [labo worldgen](docs/worldgen-lab-beta174.md) ajoute un preset distinct
+pour travailler le relief de l'île sans les calculs de plans d'eau et de
+structures. La génération normale est conservée. Profil rapide et référence
+complète utilisent des mondes de développement séparés. Les résultats de
+validation et les limites sont consignés dans la fiche du lot.
+
+## Refonte de Sanctuary Island — direction du 29 septembre
+
+Le palais souterrain, ses accès et les raccordements au palais sont abandonnés
+dans la conception. Le [fil rouge de la refonte](docs/storyquest-fil-rouge.md)
+situe le socle, propose des plans géographiques indépendants et organise la
+suite en parcours jouables qui font avancer plusieurs systèmes ensemble.
+La priorité suivante est le labo worldgen rapide ci-dessus, puis un parcours
+arrivée, halte extérieure, ancre et conséquence visible. L'esthétique reste
+à comparer sur ce parcours.
+
+## beta.173 — prototype du palais, conservé comme essai technique
+
+Un palais octogonal par seed, huit ancres avec des matériaux distincts et le bloc
+originel en bedrock : éteint, allumé en noir et blanc, puis une gemme colorée par
+ancre activée. [Prototype, laboratoire et vérifications](docs/palais-prototype-beta173.md).
+Le prototype reste disponible dans son laboratoire ; son intégration sous
+Sanctuary Island sort du plan depuis le changement de direction du 29 septembre.
+
+Le [cadrage Storyquest](docs/storyquest-beta173.md) et l'[inventaire du socle
+beta.172](docs/storyquest-socle-beta172.md) conservent les autres chantiers de
+refonte. Les priorités courantes sont dans le fil rouge ci-dessus.
+Branche `codex/storyquest-beta173`.
+
+## beta.172 — cartes utilisables en jeu
+
+Une carte révélée ouvre désormais sa brèche à la position du joueur dans
+n'importe quel monde, en Survie comme en Créatif. L'exemplaire est consommé
+côté serveur dans les deux modes ; le terrain n'est pas modifié et les arrivées
+cherchent un sol valide autour du point d'invocation.
+[Contrat et vérifications](docs/horde-runtime-beta172.md).
+
+## beta.171 — hordes dominantes et chaos dimensionnel
+
+Chaque carte choisit une famille dominante — zombies, squelettes, creepers,
+arthropodes, pillards, cauchemars, infernaux, piglins, flétris ou créatures de
+l'End — puis y glisse des surprises. La dimension de découverte favorise très
+fortement ses propres monstres, sans interdire de rares intrus. La carte est
+séparée horizontalement : ordre exact des arrivées en haut, totalité du butin
+généreux en bas. [Contrat et vérifications](docs/horde-families-beta171.md).
+
+## beta.170 — carte de horde native et langage de particules
+
+La carte de horde est désormais un véritable objet-carte Sanctuary, disponible
+dans Outils et utilitaires. Chaque exemplaire vierge découvre en main une
+identité stable et différente ; difficulté, dessin, monstres et butins restent
+liés à cette carte. Révélation, refus, brèche, progression et résultat sont
+communiqués uniquement par des connexions de particules, sans message Sanctuary
+dans le chat. [Contrat et vérifications](docs/horde-map-native-beta170.md).
+
+## beta.169 — cartes de horde à invasion continue
+
+Une carte reste inconnue jusqu’à sa prise en main, puis révèle sa difficulté, ses
+12, 18 ou 27 monstres variés et leurs butins. Le clic droit ouvre une invasion
+sans vagues : les ennemis jaillissent un par un, de plus en plus vite. Récompenses
+généreuses propres aux espèces, rubis/saphirs et runes SGA natives. Les cartes
+beta.168 existantes restent compatibles.
+[Contrat et vérifications](docs/horde-invasion-beta169.md).
+
+## beta.168 — trois cartes de horde consommables
+
+Labo sans socle, apparition immédiate, combat spontané et butins sur les monstres.
+Trois cartes illustrées tenues comme des cartes Minecraft, trois difficultés.
+[Essayer le laboratoire et connaître ses limites](docs/horde-cartes-beta168.md).
+
+## beta.167 — prototype local de horde coopérative
+
+Une arène ronde de laboratoire, une carte réutilisable et un socle interactif
+pour réunir un groupe et lancer trois vagues de zombies. Inscription et départ
+explicites, résultat commun, sans récompense économique dans ce prototype.
+[Contrat, lancement et vérifications](docs/horde-lab-beta167.md).
+Le laboratoire utilise un nouveau monde ; aucune mise à jour de Prism ni du
+canal public n'est effectuée par ce chantier.
+
+[Dernière release : beta.166](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.166) ·
+[Historique des publications beta.144–166](docs/publications-beta144-166.md).
+Les releases sont distinctes du canal packwiz, qui reste inchangé lors de ce rattrapage.
+
+La [direction de travail du 25 septembre](docs/ecosysteme-communaute-economie.md)
+pose les liens entre tableau, Gazette, statistiques en BDD, État, navets,
+machines de loterie, bounties et expansions. C'est un cadrage de conception,
+avec décisions et propositions séparées, sans nouvelle livraison de jeu.
+
+## beta.166 — inscription depuis le site
+
+Accueil avec code récupéré sur le web et reprise après coupure.
+[Contrat, migration et vérifications](docs/inscription-web-beta166.md).
+
+## Vérification du socle beta.165
+
+Les 23 échecs historiques ont été corrigés dans les scénarios de test :
+252/252 GameTests passent, ainsi que `check build`. Code de jeu inchangé.
+[Actualisation et preuves](docs/actualisation-tests-beta165.md).
+
+## beta.165 — article Gazette et conversation
+
+Grande photo et texte dans un même conteneur à gauche, auteur dessous, réponses
+à droite ou sous l’article sur petit écran.
+[Résultat et vérifications](docs/gazette-scene-beta165.md) ·
+[Audit des 23 échecs connus](docs/audit-echecs-beta165.md).
+
+## beta.164 — calendrier et intendance
+
+Date et heure réunies à gauche ; titre serveur aligné sur la carte et les panneaux.
+[Résultat et vérifications](docs/pause-calendar-beta164.md).
+
+## beta.163 — menu pause encadré
+
+Calendrier, intendance et horloge en en-tête ; deux groupes de navigation,
+séparateurs natifs et reprise centrée dans le footer.
+[Résultat et vérifications](docs/pause-frame-beta163.md).
+
+## beta.162 — tableau en scène et conversation
+
+Portrait de l’auteur tourné vers la souris, bulle aux couleurs de l’annonce,
+demande à gauche et réponses à droite. Retour/Actualiser restent en haut ;
+la conversation passe dessous sur les GUI étroits.
+[Résultat et vérifications](docs/notice-scene-beta162.md).
+
+## beta.161 — correctifs de séance et site vivant
+
+Liste des joueurs sur U, suivi des demandes expliqué, intendance compacte et
+compteurs réels partagés avec le site. Site public en lecture seule, Gazette
+en accordéon avec aperçus compacts.
+[Contrat et vérifications](docs/session-fixes-beta161.md).
+
+## beta.160 — laboratoire de test en duo
+
+Shader désactivé sur une configuration neuve, serveur local léger, personnages
+de test optionnels et séances de captures horodatées.
+[Mode d’emploi et vérifications](docs/duo-lab-beta160.md) ·
+[Récap Discord 130–160](docs/discord-beta130-160.md).
+
+## beta.159 — recherche communautaire et galerie adaptable
+
+Recherche par joueur, titre ou texte, historique Serveur en lecture seule,
+année dans les dates et galerie adaptée au GUI avec grand aperçu.
+Repères « ! » et infobulles sur la carte pour les demandes suivies géolocalisées.
+[Résultat et vérifications](docs/community-search-beta159.md).
+
+## beta.158 — cartes communautaires et demandes suivies
+
+Grilles à deux colonnes, articles photo/texte, annonces colorées avec visages,
+coffres descriptifs et suivi persistant fichier/MariaDB. Sélecteur photo compact.
+[Contrat et vérifications](docs/community-cards-beta158.md).
+
+## beta.157 — photo obligatoire dans la Gazette
+
+Galerie de captures défilante, aperçu et assignation à un article. Publication
+avec photo obligatoire, stockage fichier ou MariaDB partagé avec le site.
+[Contrat de migration et vérifications](docs/gazette-photos-beta157.md).
+
+## beta.156 — reprendre la partie sous la colonne communautaire
+
+Le bouton Reprendre la partie est aligné sous la Gazette et le tableau
+d’affichage, en bas à droite. [Vérifications](docs/pause-resume-beta156.md).
+
+## beta.155 — nouvelle structure du menu pause
+
+Navigation Sanctuary à gauche, carte centrale, Gazette et demandes défilantes
+à droite. Date, intendance et heure en en-tête ; options et sortie en bas de la colonne
+gauche, reprise de la partie en bas au centre.
+[Contrat et vérifications](docs/pause-redesign-beta155.md).
+
+## beta.154 — Gazette et tableau communautaire
+
+Panneaux gauche/droite du menu pause, intendance, publication, réponses,
+modification et modération. Stockage fichier par défaut ; MariaDB optionnelle
+commune avec le site. Shaders beta.151 conservés.
+[Contrat et configuration](docs/community-contract-v1.md) ·
+[Vérifications et limites](docs/community-beta154.md).
+
+## beta.151 — Nether, reflets des blocs et SSR
+
+Synchronisation de l’inventaire au changement de dimension, retour de l’intensité
+spéculaire des blocs solides à son niveau antérieur et bois mat avec relief.
+SSR activé par défaut à 20 %, choix sauvegardés conservés.
+[Contrat et vérifications](docs/nether-pbr-beta151.md).
+
+## beta.150 — Terre mate et reflets du coucher de soleil
+
+Terre mate avec relief conservé. Le soleil et son reflet se colorent ensemble
+en suivant la couleur et la transition du coucher de soleil natif de Minecraft.
+Les accents lumineux suivent les normales animées des vaguelettes et leur
+orientation vers le soleil et la caméra. [Contrat et vérifications](docs/matte-dirt-beta150.md).
+
+## beta.149 — Distances PBR / SSR et feuillage
+
+Deux distances séparées, 64 blocs par défaut chacune, jusqu’à 256 blocs.
+Option renommée « SSR » et suppression du voile spéculaire sur le feuillage.
+[Contrat et vérifications](docs/independent-distances-beta149.md).
+
+## beta.148 — PBR 50 % et soleil diffus
+
+PBR à 50 %, reflet solaire plus doux avec fusion par texel préservant
+la texture de l’eau. SSR à 20 %, portée commune jusqu’à 256 blocs.
+[Contrat et vérifications](docs/pbr-soft-sun-beta148.md).
+
+## beta.147 — PBR proche, lune et portée 256
+
+Correction du scintillement à très courte distance, reflet lunaire adouci
+et distance commune PBR/SSR jusqu’à 256 blocs.
+[Contrat et vérifications](docs/pbr-close-range-beta147.md).
+
+## beta.146 — Reflets et transitions de l’eau
+
+Correction du masquage des personnages en F5 et sélection stricte des surfaces PBR.
+PBR à 80 % et SSR à 20 % par défaut, distance commune PBR/SSR
+(16/32/64/128 blocs), reflet solaire large et blanc avec léger bloom des matières.
+Eau naturelle selon le type de monde et mélange 1/3/5/9/17 blocs.
+[Contrat et vérifications](docs/reflections-water-beta146.md).
+
+## beta.145 — PBR de l’eau et reflets pixélisés (livraison locale)
+
+L’eau et le verre rejoignent le PBR natif. L’option expérimentale de reflets
+alimente les texels avec le paysage visible selon leurs normales.
+[Contrat, vérifications et limites](docs/pbr-ssr.md).
+Cette branche intègre un instantané des sources d’eau beta.144 ; elle ne
+publie pas le canal et ne synchronise pas Prism.
+
+
 Sanctuary est une extension gratuite de Minecraft qui transforme le jeu en un
 monde flottant d'exploration, de production et de progression collective.
 Les joueurs commencent ensemble sur Sanctuary Island et construisent les
@@ -20,10 +481,19 @@ La [vision complète](docs/vision.md) conserve les intentions ; le
 L’économie, les claims et les dimensions décrits dans la vision restent
 à implémenter.
 
-La version **beta.111** reprend ce socle et réorganise l’atelier d’argile avec un
-cadre Minecraft nine-slice ; les statuaires suivent le regard à la pose.
-Le [ticket](docs/clay-workshop-ui-beta111.md) décrit la compatibilité, les essais,
-la publication et la mise à jour de l’instance **Sanctuary Beta**.
+La version **beta.144** prépare une option d’**eau naturelle pixélisée** :
+couleur du biome, trois profils selon le fond et visibilité adaptée en immersion.
+Les océans gardent leur couleur native et le profil clair.
+[Contrat et vérifications](docs/natural-water-beta144.md). Livraison en cours.
+
+La version **beta.143** garde le sampler natif de précipitation pour la neige
+saisonnière, mais ralentit son rythme : l'accumulation est espacée par un
+facteur 12 et la fonte par le facteur temps réel 72. Les protections existantes
+restent inchangées : neige construite, biomes froids, hiver, profils neigeux
+et météo Vanilla. Le [ticket](docs/realtime-snow-melt-beta143.md) documente le
+contrat et les vérifications.
+La beta.143 est publiée et synchronisée dans l’instance Sanctuary Beta ;
+les 923 fichiers personnels suivis sont conservés.
 La [livraison précédente](docs/clay-workshop-integration-beta110.md) réunit déjà
 l’atelier, les œufs et la neige saisonnière dans l’instance **Sanctuary Beta**.
 Les [synchronisations antérieures](docs/git-sync-beta092.md) restent documentées.
@@ -34,6 +504,252 @@ La [carte native beta.005](docs/atlas-beta005.md) prend le relais après
 l’étude de Xaero et des alternatives libres.
 
 
+## beta.143 — Neige saisonnière en temps réel
+
+Accumulation ralentie par un facteur 12 et fonte saisonnière ralentie par le
+facteur naturel 72, tout en conservant le sampler natif des colonnes de
+précipitation. Deux blocs de neige fondent en environ 2,7 jours réels en été,
+5,4 au printemps et 11 en automne.
+[Contrat et vérifications](docs/realtime-snow-melt-beta143.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.143/Sanctuary-beta.143.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.143/Sanctuary-Test-beta.143.mrpack).
+
+## beta.142 — Vulkan par défaut et stabilité PBR
+
+Moteur natif Vulkan prioritaire, relief conservé pendant les reconstructions,
+calculs de reflets bornés et intensité initiale 80 %. Choix personnels conservés.
+[Contrat et vérifications](docs/pbr-refresh-beta142.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.142/Sanctuary-beta.142.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.142/Sanctuary-Test-beta.142.mrpack).
+
+## beta.141 — Direction locale et normales PBR
+
+Relief et reflets orientés par les lumières locales. Cache compact, confiance
+réduite pour les sources opposées, objets portés et fondus. Activer PBR et
+Lumières colorées ; portée PBR 32 blocs.
+[Contrat et vérifications](docs/directional-lights-beta141.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.141/Sanctuary-beta.141.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.141/Sanctuary-Test-beta.141.mrpack).
+
+## beta.140 — Lumières portées et fondus
+
+Mains et tête, distances 8/16/32/64, fondus, cuivre vert, redstone rouge et
+option pour la chaleur des torches. Lumières colorées activées à 30 % par défaut.
+[Contrat et vérifications](docs/colored-dynamic-beta140.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.140/Sanctuary-beta.140.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.140/Sanctuary-Test-beta.140.mrpack).
+
+## beta.139 — Lumières colorées
+
+Teintes chaudes, sources des âmes bleues, redstone rouge, froglights et matériaux lumineux.
+Option désactivée initialement, intensité 35 % ; propagation locale avec obstacles.
+[Contrat et vérifications](docs/colored-lights-beta139.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.139/Sanctuary-beta.139.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.139/Sanctuary-Test-beta.139.mrpack).
+
+## beta.138 — Rayons et brouillard
+
+Densité automatique des rayons selon le brouillard et les précipitations.
+[Contrat et vérifications](docs/shader-beta138.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.138/Sanctuary-beta.138.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.138/Sanctuary-Test-beta.138.mrpack).
+
+## beta.137 — Rayons solaires
+
+Faisceaux volumétriques légers, intensité réglable et feuillage perméable.
+[Contrat et vérifications](docs/shader-beta137.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.137/Sanctuary-beta.137.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.137/Sanctuary-Test-beta.137.mrpack).
+
+## beta.136 — Lens flare rectangulaire
+
+Soleil et lune, reflets doux et intensité indépendante du bloom.
+[Contrat et vérifications](docs/shader-beta136.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.136/Sanctuary-beta.136.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.136/Sanctuary-Test-beta.136.mrpack).
+
+## beta.135 — SSGI près des surfaces
+
+Correction des coupures à courte distance, sans flouter les textures.
+[Contrat et vérifications](docs/shader-beta135.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.135/Sanctuary-beta.135.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.135/Sanctuary-Test-beta.135.mrpack).
+
+## beta.134 — PBR optionnel et SSGI filtré
+
+Relief et reflets des matériaux ; lissage de la lumière indirecte.
+[Contrat et vérifications](docs/shader-beta134.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.134/Sanctuary-beta.134.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.134/Sanctuary-Test-beta.134.mrpack).
+
+## beta.133 — SSGI renforcé
+
+Couleurs voisines plus visibles, même budget de rayons et de cibles GPU.
+[Contrat et vérifications](docs/shader-beta133.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.133/Sanctuary-beta.133.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.133/Sanctuary-Test-beta.133.mrpack).
+
+## beta.132 — SSGI : diffusion locale des couleurs
+
+Rebond diffus des couleurs visibles, intensité réglable et reconstruction
+préservant les silhouettes. Expérimental, initialement désactivé.
+[Contrat et vérifications](docs/shader-beta132.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.132/Sanctuary-beta.132.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.132/Sanctuary-Test-beta.132.mrpack).
+
+## beta.131 — Émissifs indépendants et précision étendue
+
+Bloom, émissifs et highlight activés initialement ; halo facultatif et cinq
+précisions communes de 8 à 128 pixels/bloc.
+[Contrat et vérifications](docs/shader-beta131.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.131/Sanctuary-beta.131.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.131/Sanctuary-Test-beta.131.mrpack).
+
+## beta.130 — Bloom, minerais émissifs et précision commune
+
+Halo réglable des sources lumineuses et inclusions des vingt textures de
+minerais ; réglages par défaut 32/128/16 et ombres activées.
+[Contrat et vérifications](docs/shader-beta130.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.130/Sanctuary-beta.130.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.130/Sanctuary-Test-beta.130.mrpack).
+
+## beta.129 — Reflets CTM et ombres jusqu'à 256 blocs
+
+Reflets connectés réglables, cinq portées indépendantes, soleil plein à midi
+et correction du réalignement cyclique de la grille d'ombres.
+[Contrat et vérifications](docs/shader-beta129.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.129/Sanctuary-beta.129.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.129/Sanctuary-Test-beta.129.mrpack).
+
+## beta.128 — Ombres stables, lune et feuillage
+
+Grille de réception stabilisée, contours nets des blocs, atténuation à midi,
+ombre lunaire légère et feuillage nuancé selon son épaisseur.
+[Contrat et vérifications](docs/shader-beta128.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.128/Sanctuary-beta.128.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.128/Sanctuary-Test-beta.128.mrpack).
+
+## beta.127 — Shader : ombres portées pixélisées
+
+Ombres solaires natives, finesse 8/16/32 pixels par bloc et portée 16/32/64 blocs.
+Option désactivée par défaut, réglable sans rechargement des ressources.
+[Contrat et vérifications](docs/shader-beta127.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.127/Sanctuary-beta.127.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.127/Sanctuary-Test-beta.127.mrpack).
+
+## beta.126 — Gemmes, argile et découvertes
+
+Rubis et saphir avec filons configurables, couleurs originales avec l'argile,
+commandes de découverte globales ou ciblées.
+[Contrat et vérifications](docs/gems-beta126.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.126/Sanctuary-beta.126.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.126/Sanctuary-Test-beta.126.mrpack).
+
+## beta.125 — Sculptures : placement, éclats et animaux
+
+Coins et trois hauteurs sur la grille 1/16 ; particules issues des voxels ;
+modèles découverts disponibles dans le Clay Workshop.
+[Contrat et vérifications](docs/sculpture-placement-beta125.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.125/Sanctuary-beta.125.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.125/Sanctuary-Test-beta.125.mrpack).
+
+## beta.124 — Une boîte par sculpture
+
+Sélection et collisions simplifiées, dimensions ajustées et lumière conservée.
+[Contrat et vérifications](docs/sculpture-bounds-beta124.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.124/Sanctuary-beta.124.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.124/Sanctuary-Test-beta.124.mrpack).
+
+## beta.123 — Clé dorée et clé de Steve
+
+Orientations cohérentes, inventaires et eau préservés ; clé de Steve pour
+l’édition libre, utilisable aussi en survie. [Contrat et vérifications](docs/wrench-safety-beta123.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.123/Sanctuary-beta.123.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.123/Sanctuary-Test-beta.123.mrpack).
+
+## beta.122 — Sculptures : forme et lumière
+
+Collisions et sélection sur les voxels réels, creux traversables, lumière sans
+occlusion cubique. [Contrat et vérifications](docs/sculpture-shape-light-beta122.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.122/Sanctuary-beta.122.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.122/Sanctuary-Test-beta.122.mrpack).
+
+## beta.121 — Texture de clé et pack personnel
+
+Copie complète des ressources, création depuis le jeu et guide FR/EN inclus.
+[Contrat et vérifications](docs/resourcepack-template-beta121.md) ·
+[Template personnel](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.121/Sanctuary-Template-beta.121.zip) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.121/Sanctuary-beta.121.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.121/Sanctuary-Test-beta.121.mrpack).
+
+## beta.120 — Clé dorée et états de blocs
+
+Gestes du debug stick, rotation de textures et assemblage des machines conservé.
+[Contrat et vérifications](docs/golden-wrench-beta120.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.120/Sanctuary-beta.120.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.120/Sanctuary-Test-beta.120.mrpack).
+
+## beta.119 — Sculptures au centre ou au bord
+
+Pose selon le point visé, centrage sur la grille entière et ancrage conservé
+en sauvegarde. [Contrat et vérifications](docs/sculpture-center-beta119.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.119/Sanctuary-beta.119.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.119/Sanctuary-Test-beta.119.mrpack).
+
+## beta.118 — Murets en briques colorées
+
+Seize couleurs, fabrication et tailleur de pierre, eau, raccords et collisions
+natifs. [Contrat et vérifications](docs/colored-brick-walls-beta118.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.118/Sanctuary-beta.118.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.118/Sanctuary-Test-beta.118.mrpack).
+
+## beta.117 — Grain des textures et sculptures en chapeau
+
+Les petits cubes d'une sculpture reprennent plusieurs nuances des textures
+de la matière. Le modèle reste intact dans le slot chapeau et au retrait.
+[Contrat et vérifications](docs/sculpture-texture-grain-beta117.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.117/Sanctuary-beta.117.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.117/Sanctuary-Test-beta.117.mrpack).
+
+## beta.116 — Matières de sculpture et Fourneau
+
+Un bloc de matière devient une sculpture aux couleurs de sa texture. Hotbar,
+orientation et ancrage conservés. Le Fourneau accepte les dépôts dans chacune
+de ses 27 cases et explique sa chauffe commune.
+[Contrat et vérifications](docs/sculpture-materials-beta116.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.116/Sanctuary-beta.116.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.116/Sanctuary-Test-beta.116.mrpack).
+
+## beta.115 — Fourneau : dépôts et chauffe
+
+Correctif du décalage par trois cases, combustible stable et progression
+par cuisson. [Diagnostic et essais](docs/fourneau-transfers-beta115.md).
+Étape locale intégrée à la livraison commune beta.116.
+
+## beta.114 — Animaux portés et fuite en vol
+
+Un animal volant porté entraîne son porteur après un coup. La trajectoire
+aléatoire prend brièvement le dessus sur les commandes ; déposer l’animal
+interrompt le vol. [Contrat et vérifications](docs/carried-flight-panic-beta114.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.114/Sanctuary-beta.114.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.114/Sanctuary-Test-beta.114.mrpack).
+
+## beta.113 — Sculptures d’argile et alignement
+
+Pose contre le bord visé, orientation selon le regard et coordonnées entières
+pour chaque voxel, y compris les modèles de largeur impaire. L’accroche est
+conservée à la reconnexion. [Contrat et vérifications](docs/clay-sculpture-grid-beta113.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.113/Sanctuary-beta.113.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.113/Sanctuary-Test-beta.113.mrpack).
+
+## beta.112 — Atelier d’argile et hotbar
+
+Neuf cases de hotbar et deux emplacements de fabrication, dans un cadre fixe.
+Les transferts restent dans la hotbar ; une barre pleine ne consomme pas d’argile.
+[Contrat et vérifications](docs/clay-workshop-hotbar-beta112.md) ·
+[Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.112/Sanctuary-beta.112.mrpack) ·
+[Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.112/Sanctuary-Test-beta.112.mrpack).
+
 ## beta.111 — Atelier d’argile et pose orientée
 
 Cadre nine-slice, aperçu, fabrication et inventaire dans un menu commun.
@@ -2064,7 +2780,7 @@ Depuis beta.090, la cible est **Minecraft 26.3 finale**, publiée le 15 septembr
 | Fabric API | 0.160.5+26.3 |
 | Fabric Loom | 1.17.20 |
 | Gradle Wrapper | 9.5.1, distribution vérifiée par SHA-256 |
-| Sanctuary / pack | beta.111 |
+| Sanctuary / pack | beta.166 |
 
 Java 25 et Python 3.11 ou plus récent sont nécessaires. Le script pack utilise
 uniquement la bibliothèque standard et repère aussi une installation Python
@@ -2093,7 +2809,7 @@ décrits dans [Validation](docs/testing.md).
 
 Résultats :
 
-- `mods/sanctuary/build/libs/sanctuary-beta.111.jar` : mod à installer avec
+- `mods/sanctuary/build/libs/sanctuary-beta.166.jar` : mod à installer avec
   Fabric API sur la version Minecraft indiquée.
 - `build/packwiz/` : pack de développement complet, avec le mod construit et
   l'index vérifié. Voir [Installation packwiz](packwiz/README.md).

THIRD_PARTY_NOTICES.md

@@ -127,3 +127,19 @@ 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

@@ -15,7 +15,7 @@ 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', 'assembleResourcePack')
+    dependsOn(':sanctuary:build', 'verifyPack', 'assembleResourcePack', 'assembleResourceTemplate')
     commandLine('python3', 'scripts/pack.py', 'assemble')
 }
 
@@ -46,3 +46,21 @@ tasks.register('assembleTestPack', Exec) {
     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/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/audit-mod-unique-beta203.md

@@ -0,0 +1,299 @@
+# Audit du regroupement de Sanctuary beta.203
+
+Audit du 4 octobre 2026, demandé avant toute refonte. **Le regroupement est
+réalisable, mais Sanctuary Test contient maintenant une partie du jeu livré,
+et JEI constitue un moteur conséquent.** La voie recommandée est de conserver
+le comportement de la beta.203, absorber Demeure et les fonctionnalités du
+laboratoire, puis traiter le catalogue comme un chantier distinct.
+
+Cette livraison contient une sauvegarde et un audit. Aucun regroupement de
+code, changement de génération, migration de monde ou déploiement n'a été
+effectué. Les travaux proposés ci-dessous restent à réaliser.
+
+## État de référence et sauvegarde
+
+La référence est le commit `454d9a5c08717af807f233759d3a96d639a39d44`, branche
+`codex/north-fracture-beta203`, dans
+`/Users/koka/.codex/worktrees/storyquest-beta173/sanctuary-beta`.
+Son état Git était propre. Les propriétés du mod et du pack déclarent
+`beta.203`, pour Minecraft 26.3, Java 25, Fabric Loader 0.19.5 et Fabric API
+0.160.5+26.3.
+
+Le dossier principal ouvert au début de l'audit était encore sur `main`, en
+beta.168. La branche 203 possède 40 commits absents de ce `main` local. Cela
+explique le décalage initial ; le présent audit porte bien sur la 203.
+
+Sauvegarde locale :
+`/Users/koka/Documents/sanctuary-backups/beta.203-before-single-mod-20261004-225340/`.
+
+- Branche de sauvegarde : `codex/snapshot-beta203-before-single-mod-20261004-225340`.
+- `sanctuary-all-refs.bundle` : historique Git et références commises présentes
+  au moment de la sauvegarde, dont la 203 et le `main` local.
+- `sanctuary-beta.203-sources.tar.gz` : fichiers suivis de la 203.
+- `jei-upstream-aae2dfc.tar.gz` : sources amont exactes nécessaires au port JEI ;
+  le patch et le script de préparation sont dans les sources Sanctuary.
+- `artifacts/` : JAR existants de la 203, JAR de sources, MRpack Test, template
+  graphique et guide. Le JAR Sanctuary contient également JEI et MariaDB.
+- Reçu de livraison et deux journaux de validation 203 ; empreintes SHA-256
+  dans `manifest.json`, procédure dans `RESTORE.txt`.
+
+Les 16 fichiers du manifeste ont été contrôlés. Le bundle a été vérifié, puis
+cloné dans un répertoire neuf : commit attendu retrouvé, copie restaurée
+propre. Les 4 628 fichiers de l'archive source ont également été comparés
+octet pour octet à la copie 203 d'origine. Le MRpack sauvegardé a pour SHA-256
+`ba160b4134c0b9dbe402e1834bdbec4f5561bfd6bd9dc147590dd76ee30dbf4f`, identique
+au [reçu documenté de la 203](north-fracture-beta203.md).
+
+**Limite de sauvegarde :** la tentative de copie de la branche vers Gitea a
+échoué faute d'authentification HTTPS. Aucune sauvegarde distante nouvelle
+n'est confirmée. Cette sauvegarde locale du projet ne contient pas les mondes,
+réglages personnels, caches Gradle, essais ignorés ni changements non commis
+des autres worktrees. Elle ne constitue pas une installation complète hors ligne.
+
+## Inventaire mesuré
+
+Comptage des fichiers Java et de leurs lignes physiques, commentaires et
+lignes vides inclus. Les sources JEI sont celles préparées au commit fixé,
+dans les six répertoires effectivement compilés par son build.
+
+| Ensemble | Java livré | Lignes Java | Responsabilité actuelle |
+| --- | ---: | ---: | --- |
+| Sanctuary | 963 fichiers | 84 353 | Terrain historique, progression, inventaires, recettes côté serveur, Atlas, communauté, rendu, expansions |
+| Demeure | 4 fichiers | 347 | Empreintes du vivant, activité et persistance pour l'Atlas |
+| Sanctuary Test | 105 fichiers | 8 775 | Nouveau terrain, palais et cavernes, ancres, adaptation des expansions, outils de labo |
+| JEI embarqué | 924 fichiers | 69 104 | Recherche, catalogue, écrans de recettes, favoris, catégories, synchronisation et transferts |
+
+Sanctuary possède également 381 fichiers Java de tests, soit 60 380 lignes,
+répartis entre tests purs, GameTests serveur et tests client. Demeure et le
+module Test ont chacun un fichier de test supplémentaire. Le volume de tests
+ne prouve pas leur exécution sur chaque livraison.
+
+Les configurations déclarent 286 mixins Sanctuary, un Demeure, sept Sanctuary
+Test et sept JEI. Ces injections dans Minecraft rendent l'ordre
+d'initialisation et les interactions client/serveur sensibles aux déplacements.
+
+Le graphe de construction comprend quatre sous-projets. Sanctuary embarque
+Demeure, JEI et MariaDB dans son JAR ; JEI embarque deux bibliothèques d'indexation.
+Le MRpack 203 contient deux JAR de jeu au premier niveau, Sanctuary et Sanctuary
+Test, et télécharge Fabric API. L'inspection des archives confirme que les
+identités Fabric `demeure`, `jei` et `sanctuary_test` existent encore réellement.
+
+Sources : [settings.gradle](../settings.gradle),
+[dépendances Sanctuary](../mods/sanctuary/build.gradle),
+[manifeste Sanctuary](../mods/sanctuary/src/main/resources/fabric.mod.json),
+[port JEI](../mods/jei/build.gradle).
+
+## Les points qui rendent une fusion directe dangereuse
+
+### Sanctuary Test porte le terrain utilisé dans la 203
+
+Ce module n'est plus seulement un moyen de sauter l'introduction dans un monde
+plat. Il fournit 46 presets, 44 paramètres de bruit, 93 biomes et 13
+enregistrements de codecs. Son adaptateur `LabExpansions199` branche le terrain
+récent sur le journal, les réservations et la file de génération de Sanctuary.
+
+Il existe deux fichiers différents à l'emplacement
+`data/sanctuary/worldgen/world_preset/sanctuary.json`. Celui de Sanctuary
+sélectionne `sanctuary:island_v24`. Celui du module Test sélectionne le terrain
+natif du laboratoire, avec `sanctuary_test:ascent_1600` et les biomes du labo.
+Une copie avec écrasement implicite pourrait donc changer le terrain proposé
+par le bouton Sanctuary. Le tag des presets publics présente aussi une collision.
+
+Les classes `NorthTerrain200` à `NorthTerrain203`, déjà dans Sanctuary,
+référencent des biomes `sanctuary_test:*` fournis par l'autre module : la frontière
+des fonctionnalités ne suit pas celle des sous-projets Gradle.
+
+**Conséquence :** transférer explicitement le terrain et ses ressources, choisir
+un seul preset public, conserver les anciennes clés de registre, puis déplacer
+les outils de mesure vers des sources de développement. Le nom du mod peut
+disparaître sans renommer immédiatement tous les identifiants de ses ressources.
+Les numéros historiques ne suffisent pas à identifier du code supprimable.
+
+Sources : [initialisation du labo](../mods/sanctuary-test/src/main/java/fr/koka/sanctuarytest/WorldgenLab.java),
+[adaptateur des expansions](../mods/sanctuary-test/src/main/java/fr/koka/sanctuarytest/LabExpansions199.java),
+[preset livré par le labo](../mods/sanctuary-test/src/main/resources/data/sanctuary/worldgen/world_preset/sanctuary.json),
+[biomes du Nord 203](../mods/sanctuary/src/main/java/fr/koka/sanctuary/expansion/NorthTerrain203.java).
+
+### Les raccourcis du labo ne doivent pas devenir les règles ordinaires
+
+`QuickTestMod` active le pont pour mondes plats et enregistre plusieurs outils
+de test. Son paquet de configuration peut demander de sauter l'introduction
+pour les mondes du labo. `QuickTestClient` intervient dans la création de monde.
+`SkySurvey175` exige même un conteneur Fabric nommé `sanctuary_test`.
+
+Absorber aveuglément ces points d'entrée étendrait les comportements de labo
+au mod principal, ou laisserait des outils dépendre d'une identité supprimée.
+Il faut séparer les services nécessaires au jeu, les options explicites de
+développement et les tests, puis n'enregistrer chaque événement qu'une fois.
+
+Sources : [QuickTestMod](../mods/sanctuary-test/src/main/java/fr/koka/sanctuarytest/QuickTestMod.java),
+[QuickTestClient](../mods/sanctuary-test/src/main/java/fr/koka/sanctuarytest/QuickTestClient.java),
+[activation du gameplay](../mods/sanctuary/src/main/java/fr/koka/sanctuary/progression/SanctuaryGameplay.java).
+
+### Demeure est petit mais ses données doivent garder leur adresse
+
+Seuls deux fichiers Java de production Sanctuary référencent directement
+son package : l'initialisation et le paquet Atlas. L'absorption est donc
+relativement simple : service interne, événements, mixin de placement et tests.
+
+Il faut conserver `data/demeure/footprints-v1.json`, son schéma 1, la graine et
+les protections contre la corruption ou le remplacement externe. Renommer
+ce chemin pendant la fusion ferait apparaître un historique vide. Préserver
+aussi le filtre d'éligibilité fixé par Sanctuary et éviter un double comptage
+si l'ancien JAR Demeure reste installé.
+
+Sources : [service Demeure](../mods/demeure/src/main/java/fr/koka/demeure/DemeureService.java),
+[écriture atomique](../mods/demeure/src/main/java/fr/koka/demeure/AtomicJson.java).
+
+### JEI est le principal choix de conception
+
+Sanctuary ne référence directement les classes JEI que dans deux fichiers
+de production, `RecipeClient` et `SanctuaryJeiPlugin`. Cette frontière limitée
+est favorable à un remplacement. Elle masque toutefois un moteur de 924
+fichiers Java, avec un patch local de 1 491 lignes touchant 41 fichiers.
+
+JEI fournit aussi des services serveur : transferts d'ingrédients,
+sérialiseurs et synchronisation des recettes. Son démarrage dépend des points
+d'entrée Fabric, de mixins, d'un access widener et de services Java. Effacer
+son manifeste ne constitue donc pas une intégration fonctionnelle.
+
+Deux trajectoires sont possibles :
+
+- **Internaliser le moteur dérivé de JEI.** Faire disparaître le mod distinct,
+  adapter son démarrage et conserver ses comportements. Risque fonctionnel
+  plus limité, mais environ 69 000 lignes tierces restent à maintenir, avec
+  leurs crédits, licences, ressources et conventions.
+- **Construire le catalogue Sanctuary.** Remplacer progressivement le moteur
+  derrière une interface interne. C'est le meilleur moyen de réduire la
+  dépendance à JEI, avec davantage de développement et de validation.
+
+La seconde trajectoire doit couvrir la recherche, recettes/usages, favoris,
+historique, fluides, cuisson, alchimie et autres catégories réellement utilisées,
+les recettes de datapacks, les interfaces de conteneurs et les transferts avec
+inventaire étendu. Les règles d'apprentissage, recettes cachées, découvertes et
+révocation opérateur restent gouvernées par les services serveur Sanctuary.
+L'interface native seule ne suffit pas à remplacer ce contrat.
+
+Sources : [RecipeClient](../mods/sanctuary/src/main/java/fr/koka/sanctuary/client/RecipeClient.java),
+[pont JEI](../mods/sanctuary/src/main/java/fr/koka/sanctuary/client/SanctuaryJeiPlugin.java),
+[contrat des recettes](recipes-jei-beta024.md),
+[provenance JEI](../mods/jei/PROVENANCE.md).
+
+### Le build et la distribution imposent encore plusieurs mods
+
+`scripts/pack.py` exige explicitement les JAR imbriqués Demeure et JEI,
+leurs versions, licences et empreintes. `scripts/test_pack.py` exige un JAR
+`sanctuary_test`. Les scripts de lancement dépendent de ses tâches Gradle
+et de ses presets. Tous ces contrats devront évoluer dans les mêmes tickets
+que les modules concernés, en gardant les vérifications d'intégrité.
+
+Un seul mod de jeu Sanctuary peut continuer à utiliser Fabric Loader,
+Fabric API et des bibliothèques techniques. L'exigence plus stricte « aucune
+autre entrée Fabric, même technique » serait un périmètre différent : Fabric
+API et certaines bibliothèques imbriquées possèdent elles-mêmes des métadonnées.
+Elle n'est pas nécessaire pour réunir les fonctionnalités demandées.
+
+Sources : [assemblage du pack](../scripts/pack.py),
+[assemblage Test](../scripts/test_pack.py),
+[lancement du terrain](../scripts/worldgen_lab.py).
+
+## Nettoyage utile du dépôt
+
+Le découpage interne de Sanctuary existe déjà : progression, inventaire,
+recettes, communauté, rendu, monde, expansions, etc. Le conserver évite qu'un
+mod unique devienne une classe unique. Le terrain représente à lui seul
+35 599 lignes Java dans Sanctuary, avec des générations historiques enregistrées.
+
+Les premiers gains seraient de clarifier la référence de développement,
+d'extraire les paramètres et tâches répétitifs du `build.gradle` Sanctuary
+(1 355 lignes), et de transformer le README de 2 881 lignes en porte d'entrée
+vers un historique séparé. Certains passages annoncent toujours beta.166 et
+le README Demeure indique encore 26.3-pre-2 ; les propriétés de build et le
+ticket 203 sont les références utilisées ici.
+
+Il y avait 48 worktrees avant celui de cet audit. Ce nombre augmente le risque
+de travailler sur une ancienne version, comme l'a montré le décalage 168/203.
+Les archiver demandera de distinguer les branches terminées des travaux encore
+actifs. Aucun de ces worktrees n'a été supprimé par cet audit. Les gros dossiers
+`build/` ignorés ne sont pas assimilés à des sources mortes à effacer.
+
+## Découpage proposé en tickets vérifiables
+
+| Ticket proposé | Résultat attendu | Vérification déterminante |
+| --- | --- | --- |
+| UNI 01 Référence et contrats | Branche issue de 203, inventaire des clés persistantes, fonctions de catalogue et ressources en collision | Reconstruction depuis la sauvegarde, référence de tests documentée, exemplaires de mondes de développement |
+| UNI 02 Demeure interne | Plus de mod Demeure séparé ; empreintes et Atlas inchangés | Comptage unique des événements, relecture du fichier schéma 1, refus de corruption |
+| UNI 03 Terrain dans Sanctuary | Terrain 203, Nord, palais et relais disponibles avec Sanctuary seul | Création Small/Medium/Large, graines 0/42/4736390610738281858, reprise d'expansion et rechargement |
+| UNI 04 Outils de développement séparés | Plus de mod Sanctuary Test ; tâches de labo explicites et sources de test | Parcours normal sans raccourcis d'introduction, parcours labo opt-in, serveur dédié et client Vulkan |
+| UNI 05 Catalogue interne | Interface indépendante de JEI, puis internalisation ou remplacement selon le périmètre retenu | Recherche, usages, favoris, filtres de découverte et transferts réels en solo et à deux |
+| UNI 06 Distribution et documentation | Un artefact de jeu Sanctuary, installation existante débarrassée des anciens JAR, documentation actuelle | `check build`, `assemblePack`, contenu des archives et essai d'installation isolé |
+
+Chaque ticket reçoit une branche `codex/<sujet>`. Les livraisons binaires
+incrémentent la prochaine version disponible ; cet audit documentaire reste
+sur beta.203. Les étapes peuvent être rapprochées, mais chacune doit laisser
+un résultat vérifiable avant la suivante.
+
+Pour les mondes existants, établir d'abord un contrat de compatibilité : garder
+les codecs et noms `sanctuary:*` et `sanctuary_test:*`, les schémas et chemins,
+notamment `sanctuary-lab-expansions<révision>`. Vérifier sur des copies de
+développement les constructions, progression, recettes, empreintes et expansions
+en attente. Un changement de nom public ou de package Java ne justifie pas
+une régénération de chunks. Aucun essai sur un monde personnel n'est requis
+pour commencer ces tickets.
+
+## Difficulté estimée
+
+Estimation de travail concentré pour une personne connaissant le dépôt,
+incluant vérification et corrections ; ce ne sont pas des durées mesurées.
+
+| Périmètre | Ordre de grandeur | Incertitude principale |
+| --- | --- | --- |
+| Demeure absorbé | 0,5 à 1 jour | Persistance et absence de double enregistrement |
+| Terrain et fonctions Test absorbés, outils séparés | 3 à 5 jours | Anciennes clés, ressources en collision, chargement et reprise |
+| JEI internalisé avec son moteur conservé | 2 à 4 jours | Initialisation, services, ressources et transferts |
+| Catalogue propre remplaçant les usages actuels de JEI | 10 à 20 jours | Étendue exacte des catégories, confort d'usage et parité multijoueur |
+
+Avec la remise au propre du build et de la distribution, compter **environ
+une à deux semaines pour une unification conservatrice**, et **trois à cinq
+semaines pour un ensemble nettoyé avec remplacement du catalogue**. Une
+équivalence avec toutes les intégrations tierces possibles de JEI dépasserait
+ce périmètre. La phase UNI 01 doit resserrer ces estimations.
+
+Ma recommandation est d'absorber Demeure puis le terrain Test, en conservant
+les formats, et d'encapsuler immédiatement le catalogue avant de le remplacer.
+Renommer tous les identifiants et réécrire la génération dans cette même passe
+augmenterait le risque sans être nécessaire à l'objectif d'un mod unique.
+
+## Vérifications et limites de cet audit
+
+Sauvegarde et restauration vérifiées, archives existantes inspectées, graphe de
+dépendances et ressources en collision contrôlés. La copie d'audit possède sa
+branche `codex/audit-single-mod-beta203`, distincte des branches de jeu.
+
+Une exécution ciblée a été réalisée dans cette copie isolée :
+
+```sh
+./gradlew --no-daemon check build \
+  -PsanctuaryFocusedTests=demeure,recipes,operator,realtime \
+  -PsanctuaryAtlasOnly=true
+```
+
+**Résultat : BUILD SUCCESSFUL en 2 min 57 s ; 140 tâches, dont 139 exécutées,
+et 15/15 GameTests requis réussis.** Les tests numériques rattachés à `check`,
+la compilation des quatre modules, les contrôles du manifeste pack et des
+ressources ont également passé. Journal : `build/audit-beta203-check-build.log`.
+Le cache des sources JEI a été copié depuis le worktree 203, puis contrôlé
+par le script de préparation ; ce n'est pas une reconstruction sans caches.
+L'assemblage des packs n'a pas été relancé dans cet audit : les archives
+203 existantes ont été inspectées et sauvegardées.
+
+La [livraison 203](north-fracture-beta203.md) documente sept GameTests ciblés,
+les tests numériques et un essai natif North Small/42. La suite historique
+complète n'est plus validée depuis la [limite décrite en 200](north-expansion-beta200.md),
+où une exécution a été interrompue pendant la préparation d'un test hydrologique.
+Cet arrêt ne démontre pas un interblocage. Les succès antérieurs sur 265 tests
+ne constituent pas une validation de la 203.
+
+Cet audit n'est pas un test visuel, un essai Windows, une validation des
+performances ou une preuve de migration des sauvegardes. Aucun client graphique
+n'a été lancé ; les futures validations graphiques ciblent uniquement Vulkan.

docs/backlog.md

@@ -1,5 +1,169 @@
 # Backlog Sanctuary
 
+## 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).

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/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/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-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/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/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/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/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/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/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/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/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/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/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.

docs/matte-dirt-beta150.md

@@ -0,0 +1,96 @@
+# RENDER-150 — Terre mate et reflets solaires colorés
+
+Branche `codex/matte-dirt-beta150`, socle beta.149 `1c23d0c`.
+
+La terre sèche utilise un profil entièrement mat (rugosité 0,98, métal 0),
+comme le feuillage corrigé en beta.149. Cela enlève l’éclat blanc/gris diffus
+sans supprimer les normales ni le contraste de relief. Le SSR de ces matières
+est également atténué par leur rugosité, sans changer son réglage global.
+
+Blocs concernés : dirt, coarse_dirt, rooted_dirt, grass_block, dirt_path,
+farmland, podzol et mycelium. Les faces terreuses suivent ainsi le même profil.
+Les autres profils de matière sont inchangés.
+
+Le disque du soleil et son reflet utilisent la même couleur native
+`SkyRenderState.sunriseAndSunsetColor`, issue de l’attribut environnemental
+Minecraft `SUNRISE_SUNSET_COLOR`. Son alpha pilote la transition depuis le
+blanc : aucune palette horaire ou altitude artificielle. Le soleil reste
+neutre tant que le dégradé natif est absent et se colore avec le ciel.
+La teinte solaire est convertie en lumière linéaire pour le PBR. Le mixin
+modifie seulement la couleur du disque solaire, préserve l’alpha de pluie,
+la texture native et la lune, et respecte la désactivation globale de Vanilla Light.
+La fusion diffuse de l’eau et sa normale animée d’origine sont conservées.
+Les accents suivent les pentes des vaguelettes qui réfléchissent le soleil
+vers la caméra. Leur pulsation vient des normales animées de la texture,
+sans oscillateur indépendant ni inversion artificielle du relief.
+Une faible variation stable par texel évite des crêtes toutes identiques ;
+elle module seulement l’intensité, sans produire des points isolés aléatoires.
+Les détails s’atténuent lorsqu’ils deviennent plus petits qu’un pixel écran.
+Les accents restent limités au reflet solaire et conservent sa couleur.
+Les lampes et la lune gardent leurs
+couleurs propres.
+PBR 50 %, SSR 20 % et deux portées indépendantes de 64 blocs par défaut conservés.
+Minecraft 26.3, Java 25 et dépendances inchangés ; aucune sauvegarde modifiée.
+
+## Vérifications
+
+Tests des profils de terre et scènes GPU comparant PBR OFF/ON sur terre et
+feuillage : conservation de la couleur native et présence du relief.
+- Suites PBR finales Vulkan/OpenGL réussies, dont profils des huit types de
+  sol, proximité, intensités, préférences et feuillage.
+  Journaux : `build/beta150-pbr-vulkan-final.log` et
+  `build/beta150-pbr-opengl-final.log`.
+- Terre : 180 469 pixels contrôlés, saturation relative 0,99877 sur les deux
+  moteurs ; relief visible sur 145 415 pixels. Captures conservées dans
+  `build/evidence/beta150-pbr-vulkan-final/` et
+  `build/evidence/beta150-pbr-opengl-final/`.
+
+Les tests comparent la contribution PBR au rendu natif et capturent aussi
+le disque du soleil, avant puis pendant la transition native du ciel.
+Le contrôle serveur `./gradlew check build`, exécuté dans une copie isolée
+`build/server-validation` avant les derniers ajouts exclusivement client,
+compte 229 réussites et 23 échecs sur 252 tests. Les 23 identifiants d’échec
+sont identiques à beta.149 ; aucun nouvel identifiant. Le contrôle global
+n’est donc pas vert. Journaux : `build/beta150-check-build-isolated.log` et
+`build/beta150-server-failures.json`.
+
+Les scènes solaires comparent le rendu PBR au natif, avant et pendant le
+coucher de soleil. À 2 000 ticks, la teinte native est blanche ; à 11 500 ticks
+sa transition commence légèrement (alpha 0,051) ; à 12 400 ticks l’alpha
+natif atteint 0,831 et le disque devient chaud (centre RGB 255/255/135).
+Les deux moteurs ont validé cette synchronisation native.
+
+Un lancement sans sélection PBR a également rencontré l’assertion client
+Blocodex « The full snapshot must become visible together », avant les scènes
+GPU (`build/beta150-water-motion-vulkan.log`). Il ne constitue pas une
+validation de la suite client générale.
+
+La suite finale Vulkan des éclats liés aux vaguelettes passe
+(`build/beta150-wave-glints-vulkan.log`) : animation native, masquage F5,
+distances indépendantes, reflets solaires et lunaires, matériaux transparents,
+rechargement des ressources et redimensionnement. Dans la scène solaire,
+150 563 pixels sont éclaircis, sans pixel blanc saturé.
+
+La suite OpenGL finale passe également
+(`build/beta150-wave-glints-opengl.log`) : 148 180 pixels éclaircis, aucun
+pixel blanc saturé. Les captures finales sont conservées dans
+`build/evidence/beta150-wave-glints-vulkan/` et
+`build/evidence/beta150-wave-glints-opengl/`.
+Le ressenti des vaguelettes en mouvement reste à confirmer par le créateur
+sur sa configuration ; les tests ne constituent pas une validation esthétique.
+
+## Pack local
+
+Construction et assemblage réussis avec
+`./gradlew build assemblePack -x :sanctuary:check`, après le contrôle complet
+ci-dessus. L’exclusion ne transforme pas ses échecs connus en réussite.
+Export packwiz puis vérification ZIP, version Fabric, Minecraft 26.3,
+Loader 0.19.5, JAR unique identique au construit, shader final et mixin solaire.
+
+- Pack : `/Users/koka/Documents/sanctuary/sanctuary-beta/build/Sanctuary-beta.150.mrpack`
+- Taille : 10522942 octets.
+- SHA-256 pack : `65a4a44948dcdcf0325b5e24c076a03f8832184f25f5c1ff16f69bd3ee641b93`.
+- SHA-256 JAR : `4962e6f8cafd6ef3e81e088bf9b0092a264441632cfa095d4fe7394b855f093d`.
+- Reçu : `build/beta150-artifacts.json`, également copié à côté du pack.
+
+Aucun canal publié, aucune instance Prism ni sauvegarde personnelle modifiée.

docs/natural-ascent-beta184.md

@@ -0,0 +1,115 @@
+# ASCENT-184 — rosace à 640 et palais des hauteurs
+
+Ticket du 30 septembre 2026, branche `codex/natural-ascent-beta184`.
+Le retour sur beta.183 rejette l'ISS métallique visible depuis le sol et les
+nouveaux bassins supérieurs ovales en marches. La direction retenue est une
+machine naturelle : rosace, longue tige parcourable, couronne de palais comme
+un parapluie, carte au sol et portail horizontal au-dessus. Dernière correction
+explicite du créateur : **la rosace est à Y=640**, pas à 320.
+
+## Contrat de génération
+
+Nouveau profil de laboratoire `ascent`, preset `sanctuary_test:ascent_v1`,
+réglages `sanctuary_test:ascent_v1_10`, graine de visite **42**. Nouvelle dimension
+`sanctuary_test:ascent_1600`, constructible de Y=0 à 1599. Minecraft 26.3 accepte
+ce type de dimension dans la génération native vérifiée. Le bruit du terrain
+reste calculé entre 0 et 639 ; la décoration écrit les structures plus haut
+dans les sections du nouveau monde. Aucun bruit supplémentaire dans le ciel
+vide, aucune hydrologie régionale, aucun changement des sauvegardes précédentes.
+
+Les presets 180–183 restent distincts. Le nouveau profil reprend l'île, ses
+minerais, biomes, cavernes, soufre et donjon, mais ne place ni l'ISS métallique
+ni les bassins `Water183`. Les étangs souterrains beta.180 précédemment validés
+restent présents. Pas d'expansion, migration, nouveau mob ou portail fonctionnel.
+
+## Construction et découverte
+
+- Rosace et Bugrock translatés à **(0,640,0)**, sol à 638. Les huit couleurs et
+  approches de la rosace sont conservées ; la sortie est rejoint l'escalier.
+- Tige de tuf, deepslate, calcite et mousse, nervures enroulées, haltes latérales.
+  Escalier continu avec marches natives, de 638 à 1278 : 1 923 positions de
+  parcours, environ 1,9 km de chemin pour 640 blocs gagnés. Largeur généralement
+  de trois blocs, resserrée aux virages. Le parcours depuis l'île jusqu'à la
+  rosace reste à concevoir ; le test permet le vol et le spectateur.
+- Palais : nervures déployées à partir de 1160, sol à **1278**, voûte à **1310**.
+  Huit pétales vitrés, passages minéraux, cuivre oxydé, balcons. Pas de panneaux
+  solaires ni de modules métalliques. Le Bugrock reste uniquement sur la rosace.
+- Atlas natif au sol, 49 cartes sur ce terrain moyen, dans des cadres horizontaux.
+  Dimensions 5×5, 7×7 et 9×9 pour les rayons déjà pris en charge. Identifiants et
+  marqueurs propres à ce nouvel atlas ; l'atlas 183 reste inchangé.
+- Portail supérieur : cadre horizontal 7×7 d'obsidienne, coins en obsidienne
+  pleureuse, vide central 5×5, à 1287 au-dessus des cartes. Le portail inférieur
+  conserve son cadre 5×5 et son creux 3×3 à Y=175. Ce sont des infrastructures.
+
+À 32 chunks, la caméra native peut garder un plan lointain de 2 048 blocs :
+la hauteur seule ne suffit pas à dissimuler la couronne. Dans cette dimension
+uniquement, le frustum refuse les volumes entièrement au-dessus de 1152 lorsque
+la caméra est sous 560. La couronne devient donc éligible à l'affichage pendant
+l'approche de la rosace ; les règles normales de visibilité restent applicables.
+C'est une révélation côté rendu, pas une génération conditionnelle à un joueur.
+Un contrôle à l'entrée du client teste les deux API natives de frustum, depuis
+le sol et depuis 640. La couronne est aussi au-delà du volume maximal des ombres
+Sanctuary depuis le plateau (distance 256, extrusion solaire comprise). Cela
+ne supprime pas l'éclairage Minecraft inhérent aux blocs placés dans une colonne.
+
+## Eau dans les creux existants
+
+Recherche locale et bornée dans le champ réel de densité. Chaque candidat est
+rempli par parcours des cellules d'air adjacentes sous un niveau horizontal ;
+un chemin sortant du volume de recherche, vers le vide ou une zone réservée
+fait rejeter le candidat. On monte le niveau par essais bornés tant que la roche
+retient l'eau. Aucun mur de retenue, fond d'argile artificiel, marche ou excavation
+n'est dessiné. Seules les cellules encore en air reçoivent de l'eau à la décoration.
+Les cavités existantes, roches saillantes et végétaux conservés dictent le contour.
+
+Première génération native `solo184a`, graine 42 : 45 essais, plan en 852 ms,
+10 402 blocs d'eau dans la grande poche (surface de 1 045 cellules à Y=234),
+739 blocs dans la seconde (290 cellules à Y=242). Aucun débouché latéral/inférieur
+non retenu détecté après la décoration. Ce sont des eaux retenues ; aucune
+simulation de bassin versant ou de rivière à longue distance n'est introduite.
+
+## Vérification et visite
+
+Premier contrôle natif réussi : 567 échantillons profonds identiques, zéro région
+d'hydrologie, trois cerisiers, cinq spawners, quatre caches à butin, galerie,
+soufre et trois secteurs de gemmes présents. Les 56 246 entrées du plan du palais
+correspondent aux blocs générés ; toutes les positions de montée ont un support
+et deux blocs libres. Les 49 cartes sont uniques, remplies, figées et supportées.
+Serveur démarré en 5,3 s ; prêt en 43,6 s avec génération des sondages et contrôles.
+Ce dernier temps inclut les tests et ne mesure pas un démarrage normal du solo.
+
+Validation finale : `./gradlew check build assemblePack assembleTestPack
+:sanctuary-test:exportDuoLaunch` réussi en 6 min 54 s, **265/265 GameTests**.
+Journal `build/ascent184-check-build.log`. Nouveau monde final `solo184b/ascent/42`
+contrôlé et arrêté proprement : serveur en 5,25 s, prêt avec contrôles en 41,63 s ;
+plan d'eau en 806 ms, 10 401 et 739 blocs d'eau retenus sans fuite. Le nombre de blocs d'eau diffère d'une cellule entre les deux essais ;
+les niveaux et surfaces des plans restent identiques.
+Rapport `build/ascent184-quick-result-final.json`.
+
+Lecture NBT du monde arrêté : 49 cartes complètes, figées, identifiants uniques,
+49 cadres orientés vers le haut à Y=1279. Air confirmé aux anciens centres
+(0,320,0) et (0,576,0), bloc originel à (0,640,0), plancher d'atlas en calcite
+et portail supérieur creux. Reçus `build/ascent184-saved-atlas-final.json` et
+`build/ascent184-saved-blocks-final.json`.
+
+Solo neuf `visite184/ascent/42`, `Sanctuary-Ascent-184-Solo`, commandes, créatif,
+vol, vue 32 et simulation 12. Entrée client Vulkan confirmée le 30 septembre,
+contrôle natif du frustum réussi à **03:45:07** : couronne cachée à Y=250,
+rosace visible et couronne révélée à Y=640. Journal `build/ascent184-solo.log`.
+Le profil local KokaLab de ce monde utilise la couleur Ciel et le familier de
+labo par défaut. Le daemon de compilation a été arrêté pour libérer la mémoire.
+Aucune sauvegarde antérieure ni instance Prism modifiée. Les archives locales
+sont assemblées ; aucun canal public n'est avancé.
+
+| Lieu | Téléportation de visite |
+| --- | --- |
+| Rosace et départ de la montée | `/tp 0.5 639 5.5 180 -20` |
+| Palais et carte au sol | `/tp 6.5 1280 8.5 140 35` |
+| Vue extérieure de la couronne | `/tp 45 1295 45 135 10` |
+| Grande cavité en eau | `/tp -144 236 -96` |
+| Seconde cavité en eau | `/tp -16 245 128` |
+| Portail inférieur | `/tp 0.5 177 7.5 180 30` |
+
+Cette première silhouette reste à évaluer en visite, notamment le rythme de
+l'ascension et les proportions du palais. La graine 42 est la référence vérifiée ;
+la disponibilité de grandes cavités sur d'autres graines reste à éprouver.

docs/natural-caves-beta187.md

@@ -0,0 +1,100 @@
+# CAVES-187 — soufre naturel, ancres orientées et bassins visibles
+
+Ticket du 30 septembre 2026, branche `codex/natural-caves-beta187`.
+Retour beta.186 : coque de soufre artificielle, pylônes mal orientés et verre
+latéral, bassins de surface invisibles. Le relief et les trois secteurs de
+gemmes sont appréciés et conservés.
+
+Nouveau profil `natural`, preset `sanctuary_test:natural_caves_v1`, graine 42.
+Les anciens presets et sauvegardes restent inchangés. Le laboratoire ajoute
+un climat de soufre en trois dimensions dans la roche existante, une approche
+en mousse tournée vers le centre pour chaque ancre et des pylônes opposés,
+vers l'expansion, portant le verre au-dessus de l'améthyste. L'eau de surface
+est recherchée dans des dépressions réellement ouvertes au ciel ; toute fuite
+vers le vide fait rejeter le bassin. Aucun calcul régional d'hydrologie.
+
+Le climat de soufre utilise un bruit volumique et respecte la priorité des
+marais humides. La palette forme des dépôts cohérents de soufre, cinabre et
+calcite dans les blocs rocheux existants. Musique et couleurs du biome natif
+26.3 sont conservées. Les carvers, minerais et structures vanilla ne sont pas
+importés : l'île conserve ses cavités et sa distribution de ressources.
+L'ancienne coque et ses cheminées ne sont plus placées dans ce preset.
+
+Les pylônes portent améthyste puis verre, sur la même verticale. Leur porte
+pointe vers la direction exacte du secteur, y compris les diagonales. Le
+chemin en mousse est du côté opposé. La sélection vérifie le support naturel
+de la porte et du chemin ; les huit emplacements changent pour respecter
+cette orientation. La galerie, les rosaces et le palais restent conservés.
+
+L'eau de surface monte dans un creux par parcours prioritaire : chaque voxel
+est échantillonné une fois à la hauteur minimale qui le rend accessible.
+Une fuite, une structure réservée ou la limite de recherche arrête la montée.
+Les surfaces retenues doivent être majoritairement ouvertes au ciel. Aucun
+fond ajouté ni découpage elliptique ; les arbres voisins ne peuvent reboucher
+les cellules d'eau réservées. Les étangs souterrains appréciés sont conservés.
+L'atlas projette aussi les nouvelles eaux et perd le faux repère jaune de la
+cheminée supprimée. Les recherches sont bornées, en génération uniquement.
+
+## Contrôles natifs
+
+Graine 42, `solo187e/natural/42` : génération à froid réussie. Recherche des
+bassins en 2,674 s, contre 21,546 s au premier essai ; mêmes trois positions,
+niveaux et volumes retenus. Démarrage serveur 9,881 s, prêt après l'ensemble
+des contrôles en 50,190 s. Ces durées ne mesurent pas le démarrage graphique.
+Zéro région d'hydrologie et 567 échantillons de densité profonde conservés.
+
+| Bassin | Niveau | Surface totale | Surface sous ciel ouvert | Blocs d'eau |
+| --- | --- | --- | --- | --- |
+| Ouest, près de (-104, 88) | 248 | 1 994 | 1 475 | 11 935 |
+| Nord-est, près de (120, -136) | 244 | 839 | 536 | 2 329 |
+| Sud, près de (8, 136) | 254 | 1 321 | 904 | 9 446 |
+
+Aucune fuite native détectée. Quatre points de visite confirment le biome
+sulfureux, de la roche minéralisée et des cavités déjà présentes dans la densité.
+Les huit refuges passent le contrôle d'orientation et de verre vertical.
+Les dépôts distincts activent les huit gemmes ; les tests restaurent ensuite
+les ancres éteintes et le Bugrock allumé sans relais. Les secteurs de gemmes,
+les cinq spawners et quatre wagonnets à butin restent vérifiés.
+
+Réouverture réussie : démarrage serveur 0,618 s, prêt avec vérifications en
+8,226 s. Les huit ancres sont relues dans la sauvegarde éteintes et le masque
+du Bugrock vaut zéro ; 49 cartes complètes, figées, avec 49 cadres horizontaux
+uniques. Reçus ignorés : `build/natural187-final-cold-result.json`,
+`build/natural187-final-warm-result.json`, `build/natural187-saved-blocks.json`,
+`build/natural187-saved-atlas.json`.
+
+`./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch`
+réussi en **7 min 10 s**, **265/265 GameTests**. Journal :
+`build/natural187-check-build.log`. Daemon Gradle arrêté avant le client.
+Solo Vulkan rejoint à **08:40:37**, départ (-104,5 ; 269 ; 119,5), vue 32
+et simulation 12 confirmées dans `build/natural187-solo.log`. Contrôle client
+de visibilité verticale réussi à 08:40:39. Le créateur a pris la main et est
+passé en spectateur ; aucune téléportation d'inspection supplémentaire.
+L'appréciation visuelle des nouveaux bassins et du soufre reste celle de
+cette visite ; les mesures ci-dessus sont des vérifications natives.
+Seule la graine de visite est certifiée ; pas de migration des anciennes
+sauvegardes ni de modification du canal public ou de Prism.
+
+
+## Visite — graine 42
+
+Nouveau solo `visite187/natural/42`, `Sanctuary-Natural-Caves-187-Solo`.
+Vue 32, simulation 12, créatif, vol et commandes. Départ au-dessus du bassin
+ouest ; les anciennes visites restent conservées.
+
+| Lieu | Raccourci de visite |
+| --- | --- |
+| Bassin ouest | `/tp -104.5 269 119.5 180 35` |
+| Bassin nord-est | `/tp 120.5 258 -116.5 180 35` |
+| Bassin sud | `/tp 8.5 270 156.5 180 35` |
+| Soufre, cavité haute | `/tp -215.5 219 -35.5` |
+| Soufre, cavité profonde | `/tp -203.5 150 -11.5` |
+| Soufre, cavité nord-ouest | `/tp -191.5 152 -179.5` |
+| Ancre nord, approche intérieure | `/tp 36.5 250 -168.5 180 0` |
+| Ancre nord-est | `/tp 193.5 251 -84.5 -135 0` |
+| Ancre est, récif | `/tp 214.5 444 16.5 -90 0` |
+| Ancre sud-est | `/tp 157.5 226 145.5 -45 0` |
+| Ancre sud, grotte | `/tp -71.5 176 205.5 0 0` |
+| Ancre sud-ouest | `/tp -96.5 252 181.5 45 0` |
+| Ancre ouest | `/tp -96.5 230 0.5 90 0` |
+| Ancre nord-ouest, récif | `/tp -102.5 404 -160.5 135 0` |

docs/natural-refinement-beta190.md

@@ -0,0 +1,77 @@
+# WG-NATURE-190 — relief organique, déversoirs et butin des ruines
+
+Branche `codex/natural-refinement-beta190`, graine de visite **42**, Minecraft 26.3.
+Nouveau profil de laboratoire `refined`, preset `sanctuary_test:natural_refinement_v1`.
+Les sauvegardes précédentes restent des témoins ; aucune régénération ni migration.
+
+## Contrat de cet essai
+
+Après la visite beta.189 : supprimer les terrasses systématiques du relief principal,
+conserver quelques inflexions locales douces, des affleurements suivant la pente et
+sans masque en cases de quatre blocs. Les captures du 30 septembre à 20:44 et 20:45
+montrent le relief principal ; les îlots aériens ne sont pas la cause des paliers.
+Comparer les débouchés voisins des étangs au lieu de retenir le premier rayon ;
+privilégier une sortie courte, large de quatre ou cinq blocs et peu creusée.
+Conserver les cavités, le portail et les ruines appréciés. Remplacer la table de
+craft de chaque ruine par un coffre de matériel en fer enchanté.
+Aucun calcul d’hydrologie régionale ajouté ; travail local borné, décoration existante.
+
+## Réserve de conception, non implémentée
+
+- Expansion à grandes surfaces étagées et falaises ciselées : conserver la variante
+  beta.189 comme référence, avec une profondeur et une verticalité adaptées au thème.
+- Portails horizontaux : remplissage progressif avec une ressource renouvelable.
+  Perles d’Ender, source Endermen ou butin sont des pistes ; ressource, nombre,
+  recette et destination ne sont pas décidés. Aucun mécanisme d’activation ajouté ici.
+
+## Vérifications
+
+Compilation et génération/réouverture natives réussies, graine 42 :
+`build/refined190b-cold.json` et `build/refined190b-warm.json`.
+
+- 704 des 745 sommets échantillonnés gardent exactement la hauteur naturelle
+  antérieure aux terrasses ; 41 épaules retouchées, écart maximum 3 blocs.
+  30 246 densités des profondeurs et des îlots aériens identiques. Les corniches
+  fines sont conservées ; une première interpolation qui pouvait les supprimer
+  a été corrigée avant la visite.
+- Une sortie d’étang de cinq blocs de large, depuis X=150, Y=244, Z=-157 à -153
+  vers X=154–155. Chenal de 4–5 blocs, dont une partie dans l’étang ; huit blocs
+  retirés. Bord de chute irrégulier, 64 blocs préremplis puis écoulement natif.
+  La recherche compare les ouvertures proches, reste bornée à dix blocs et
+  deux cascades, et renonce si aucune bouche assez large ne convient.
+- 1 052 blocs de plage sèche, 434 plantes aquatiques, zéro tronc dans les
+  colonnes contrôlées des plages et étangs. Fonds : 1 337 sable, 249 gravier,
+  2 832 argile. Le choix du chenal ne crée pas de fond ou barrage artificiel.
+- Quatre ruines conservées, coffres en (25,164,-63), (-7,148,-79),
+  (65,164,-79), (57,121,-79). Couvercles dégagés, table de butin conservée
+  après réouverture. Une ou deux pièces en fer par coffre, enchantements
+  de table de niveau 12–20 : armure, épée, pioche, hache ou pelle.
+  32 tirages vérifiés à froid, puis 32 à chaud ; aucune pièce non enchantée.
+- Huit ancres, cartes du palais, gemmes, soufre, donjon et galerie contrôlés.
+  Ni nouvelle dimension ni activation des portails ajoutée.
+
+Démarrage natif : 12,331 s à froid / 0,673 s à chaud ; avec toute la batterie
+et le remplissage intégral des cartes : 81,505 s / 26,656 s. Plans locaux
+berges/déversoirs : 174 / 170 ms. Zéro région d’hydrologie calculée.
+Mesures obtenues pendant la suite de tests générale, sans garantie de durée
+identique sur chaque machine. Le solo ne lance pas ces contrôles lourds.
+
+`./gradlew check build assemblePack assembleTestPack` réussi en **9 min 22 s**,
+avec **265 GameTests réussis**. Après les derniers correctifs validés par le labo
+natif, le JAR optionnel a été réassemblé et le pack de test resynchronisé.
+Ses classes et ressources correspondent aux fichiers compilés, et sa copie
+assemblée est identique : `build/refined190-pack-receipt.json`.
+Aucune publication de canal ni mise à jour Prism. La validation esthétique reste
+celle de la prochaine visite ; les contrôles structurels ne la remplacent pas.
+
+
+## Visite
+
+Solo `Sanctuary-Natural-Refinement-190-Solo`, run `visite190`, profil `refined`,
+graine 42. Copie neuve du monde de diagnostic arrêté, sauvegardes antérieures
+préservées. Spectateur et commandes activés, vue 32, simulation 12, Vulkan.
+Connexion confirmée à **21:01:12**, position (178,260,-146), face à la cascade.
+Les 49 cartes et cadres horizontaux sont présents, complets et verrouillés ;
+les huit ancres et le Bugrock sont revenus à l’état initial après les contrôles.
+`build/refined190-saved-atlas.json`, `build/refined190-saved-blocks.json` et
+`build/refined190-solo.log` conservent ces vérifications.

docs/natural-water-beta144.md

@@ -0,0 +1,121 @@
+# WATER-144 — Eau naturelle pixélisée
+
+Branche `codex/water-beta144`, socle beta.143 publiée (`97ff2b5`) et suivi
+`580b241`. Minecraft 26.3, Java 25, dépendances conservées.
+
+## Contrat
+
+**Options → Shaders → Eau naturelle** est activée par défaut avec Sanctuary.
+L’intensité (0–100 %, défaut 100 %) agit sur la surface et l’immersion.
+L’interrupteur ou 0 % retrouve le rendu précédent. Les préférences existantes
+restent conservées ; un moteur externe suspend l’effet comme les autres effets
+natifs Sanctuary.
+
+La couleur native du biome reste la base, y compris les variantes d’océans.
+Les océans (`minecraft:is_ocean`) imposent le profil clair.
+Hors océan, le premier support situé au maximum huit blocs sous la cellule
+observée choisit le profil :
+
+| Profil | Fond | Mélange olive #788448 | Alpha natif | Distance de brume native |
+| --- | --- | ---: | ---: | ---: |
+| Claire | Pierre, matériaux construits, inconnus | 0 % | ×0,55 | ×1 |
+| Légèrement teintée | Sable, sable rouge, gravier, argile | 10 % | ×0,80 | ×0,70 |
+| Étang | Terre, terre stérile/enracinée, herbe, podzol, mycélium, boue, racines de palétuvier boueuses | 85 % | ×1 | ×0,40 |
+
+L’eau et les plantes aquatiques sans collision sont traversées. Un support
+immergé reste un fond ; absence de support, air ou données manquantes donnent
+une eau claire. La référence visuelle fournie pendant l’implémentation demande un véritable
+vert olive légèrement jaunâtre : le profil étang passe donc de 45 % à 85 %
+de mélange, tout en laissant les eaux claires et océaniques natives.
+Les surfaces profondes sans fond dans la limite restent donc
+claires. Les profils se mélangent aux sommets sur un bloc, sans filtrer les
+textures. L’eau sous un toit suit son fond, pas l’éclairage du bâtiment.
+
+La ressource client `assets/sanctuary/water_materials.json` accepte deux listes
+d’identifiants de blocs, `light` et `pond`, remplaçables par un resource pack.
+Les blocs absents des listes sont clairs. Une ressource invalide est signalée
+et reprend les familles embarquées. Le template personnel inclut cette ressource.
+
+## Rendu et coût
+
+Modification des seules couleurs/alpha des sommets de `FluidRenderer`, sans
+passe écran ni duplication de maillage. Textures, UV, animation, éclairage
+et tri des transparences restent natifs. Les calculs de profils sont différés
+jusqu’à l’émission d’un sommet visible, puis mutualisés dans la région compilée.
+Un test de palette élimine les sections sans eau avant toute copie de biomes.
+Les états de blocs viennent des copies natives ; les appartenances océaniques
+sont capturées avant l’envoi au worker. Aucun chargement de chunk n’est demandé.
+
+Un changement de bloc invalide la zone dépendante, huit blocs au-dessus et
+un bloc horizontalement. Les reconstructions natives recopient leurs données ;
+l’effet ne déclenche aucune reconstruction pour une lumière mobile.
+Un changement d’option reconstruit seulement les sections chargées contenant de
+l’eau ; les caches des autres effets restent disponibles. Le cache temporaire
+disparaît avec sa compilation, sans historique de monde.
+
+Sous l’eau, le profil est échantillonné au maximum une fois par tick, avec
+transition de 0,5 seconde. La couleur et les distances environnementales sont
+adaptées dans le rendu natif du brouillard. La teinte finale est appliquée après
+la normalisation de la vision aquatique, pour éviter de transformer l’olive en
+jaune fluorescent ; la luminosité issue des modificateurs natifs de vision
+et le bonus du compagnon calmar sont conservés. Lave et brume atmosphérique ne changent
+pas. Il n’y a pas de simulation d’absorption volumétrique ni de reflet ajouté.
+
+## Validation native
+
+Les essais utilisent un monde plat jetable, graine 122, avec bassins sur quartz,
+sable et boue, support du sable, plantes aquatiques, toit, frontière de sections
+et changement de biome océan. Une copie personnelle de ressource remplace
+réellement les familles de matériaux puis est désactivée.
+
+Les suites graphiques OpenGL et Vulkan ont passé les contrôles de surface,
+d’immersion, de fond modifié, d’océan, de ressources, de préférences et de
+cascades pendant le développement. La dernière optimisation reconstruit
+seulement les sections contenant de l’eau lors du changement d’option.
+Sa série de validation finale reste à terminer avant publication.
+
+### Protocole de performance
+
+Apple M1, macOS, Java 25, 854×480, distance de rendu 6 chunks,
+ombres 32 blocs / 16 pixels, PBR 50 %, autres effets activés.
+VSync désactivée, limite 260 (illimitée), limitation AFK désactivée.
+Pour chaque scène : OFF/ON/ON/OFF/ON/OFF/OFF/ON, dix secondes par passage,
+avec stabilisation des sections puis quatre secondes de chauffe entre passages.
+Le déplacement avance de 120 blocs et laisse les sections se compiler
+naturellement, sans vidange artificielle des caches des autres effets.
+Les moyennes des quatre médianes et P95 par état sont comparées avec les seuils
++5 % et +2 ms. Les temps de compilation de sections sont consignés également.
+
+Les essais courts initiaux ont montré une forte variabilité. Une limitation AFK
+à 30 FPS puis des clients Minecraft concurrents dans le chantier PBR/SSR ont
+été identifiés. Ces essais restent dans les preuves de développement ; ils
+ne valident pas la livraison. La série finale attend la fin du chantier
+concurrent, conformément à la demande du créateur. Les résultats ne sont pas
+présentés comme acquis, et aucun gain de performance universel n’est promis.
+
+Pour reproduire, avec Java 25 et un environnement graphique disponible :
+
+```sh
+./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true \
+  -PsanctuaryPixelShadows122ClientTests=true -PsanctuaryWater144ClientTests=true \
+  -PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true \
+  -PsanctuaryClientGraphicsBackend=vulkan > build/water144-vulkan.log 2>&1
+python3 scripts/check_water_performance.py build/water144-vulkan.log
+```
+
+Répéter avec `opengl`, sans autre client graphique simultané. Le vérificateur
+refuse les séries incomplètes et les dépassements ; il écrit le reçu détaillé
+près du journal. Le marqueur `WATER144_PASS` atteste les contrôles fonctionnels.
+
+### Assemblage et publication
+
+Le GameTest serveur dédié reste exclu conformément au refus antérieur de son
+EULA. La commande de livraison est `./gradlew check build assemblePack
+assembleTestPack -x :sanctuary:runGameTest` ; la suite complète non exclue
+n’est pas déclarée réussie. Les contrôles natifs de l’eau utilisent le serveur
+intégré d’un monde jetable. Aucun essai Windows n’est revendiqué.
+
+La release, le canal et l’instance ne sont pas encore mis à jour.
+Les preuves détaillées restent dans les dossiers ignorés :
+`build/water144-*.log`, `build/water144-*-performance.json`,
+`build/water144-*-isolation.json` et `build/water144-evidence/`.

docs/nether-pbr-beta151.md

@@ -0,0 +1,93 @@
+# FIX-151 — Nether, PBR opaque et SSR
+
+Branche `codex/nether-wood-beta151`, socle beta.150 `448e2fe`.
+
+## Déconnexion Nether
+
+Le rapport Windows beta.150 transmis le 18 septembre 2026 indique
+`IndexOutOfBoundsException: Index 46 out of bounds for length 46` lors de
+`ClientPacketListener.handleContainerContent`, paquet `container_set_content`.
+Le passage au Nether dans le test client local reproduit exactement cette trace
+(journal `build/beta151-client-first.log`). Ce défaut n’est pas un crash GPU.
+
+Minecraft recrée le joueur client et son menu lors de `handleRespawn`, utilisé
+aussi pour les changements de dimension. La progression n’était réattachée
+qu’en fin de tick ; un paquet d’inventaire dans le même lot arrivait avant la
+création des 18 cases supplémentaires et des 3 accessoires. Le correctif lie la
+progression déjà reçue au nouveau joueur dès la fin du traitement du paquet de
+respawn, avant le paquet suivant. Aucun paquet ni objet n’est ignoré et aucun
+format de sauvegarde ne change. Sans progression Sanctuary active, le chemin
+vanilla reste inchangé.
+
+## Rendu
+
+La beta.146 avait porté le gain solaire des surfaces opaques de 3 à 20
+(4 × 5), soit environ 6,7 fois plus. Le renforcement prévu pour les reflets de
+l’eau avait ainsi créé un voile sur les matières sombres, dont l’obsidienne.
+Les surfaces opaques retrouvent le gain 3 et le budget spéculaire total 0,5,
+partagé entre soleil et lampes. La teinte native du coucher de soleil, les
+normales et le relief sont conservés. Eau et verre conservent leur traitement.
+Le bois utilise le profil mat 0,98 : planches, bûches et variantes de construction,
+bambou, tiges et hyphes du Nether. Ce classement ne transforme pas le nylium en bois.
+
+SSR est activé par défaut à 20 %, avec portée 64 blocs. Un choix OFF déjà
+sauvegardé reste OFF. PBR reste à 50 % par défaut.
+
+## Cible graphique
+
+Décision du créateur pendant ce ticket : **Vulkan uniquement** pour les nouvelles
+validations. Le passage OpenGL de ce ticket s’était terminé avant cette demande ;
+il reste une trace historique, pas une cible à conserver ni à relancer.
+Cette décision est reportée dans `AGENTS.md` et `docs/testing.md`.
+
+## Vérification
+
+Les assertions GPU Vulkan et les quatre transferts successifs
+Overworld → Nether → Overworld → Nether → Overworld passent sur un nouveau monde
+plat de développement, graine 122. Après chaque transfert : menu de 67 cases,
+pile de 7 diamants en inventaire natif, 3 émeraudes dans la première case
+supplémentaire et 5 lingots d’or dans la dernière, toujours présents côté client.
+
+Les scènes PBR conservent 99,878 % de la saturation relative du chêne et 99,968 %
+de celle de l’épicéa écorcé sur 185 776 pixels chacune. Le relief affecte
+respectivement 101 382 et 51 671 pixels. De face, l’obsidienne ne gagne en moyenne
+que 5,114 niveaux RGB sur 255 (102 480 pixels), avec relief visible sur 95 225
+pixels. Captures inspectées : bois et obsidienne PBR OFF/ON.
+
+Les contrôles couvrent aussi les réglages SSR absents (ON/20 %), la persistance
+d’un choix OFF, les profils bois, les petits déplacements de caméra, les
+intensités, le rechargement des ressources et le redimensionnement.
+Le premier passage Vulkan corrigé valide toutes les assertions, mais se bloque
+ensuite à la fermeture dans les barrières de synchronisation du programme de
+test Fabric ; son processus est arrêté après capture des piles de threads.
+Premier journal : `build/beta151-client-vulkan-final.log` ; diagnostic :
+`build/beta151-client-shutdown-threads.txt`. Le second passage Vulkan réussit entièrement, fermeture comprise, en **3 min 9 s**
+(`build/beta151-client-vulkan-clean.log`). La suite OpenGL terminée avant l’abandon de
+cette cible a réussi en 2 min 42 s ; aucun nouveau test OpenGL n’est prévu.
+
+Le contrôle complet `./gradlew check build` dans `build/server-validation`
+(3 068 fichiers de production identiques aux sources courantes) termine en
+11 min 13 s : **229 réussites, 23 échecs sur 252**. Les 23 identifiants sont
+strictement identiques à beta.150 : aucun nouveau, aucun résolu.
+Le contrôle global reste rouge. Journaux et liste :
+`build/beta151-check-build.log`, `build/beta151-server-failures.json`.
+Ces échecs restent ouverts et ne constituent pas la validation du correctif
+réseau ; celui-ci repose sur la reproduction puis le test client des transferts.
+
+## Pack local
+
+`./gradlew build assemblePack -x :sanctuary:check` réussit en 11 s,
+indépendamment du contrôle complet en échec ci-dessus. Export packwiz réussi ;
+ZIP, version Fabric, Minecraft 26.3, Loader 0.19.5, JAR Sanctuary unique,
+mixin de respawn et shader exacts, classes conformes aux sorties compilées et
+absence des tests dans le JAR vérifiés.
+
+- Pack : `/Users/koka/Documents/sanctuary/sanctuary-beta/build/Sanctuary-beta.151.mrpack`.
+- SHA-256 pack : `1d87804d75edda0a95c318ea3feaf47ecadeeb29d86ca55483a42741d7a5fcab`.
+- SHA-256 JAR : `6676c67f8be4e650a9b6a8213c8b0fdf3cf7e62b030c3d1a6d4805d438a8e543`.
+- Reçu : `build/beta151-artifacts.json`.
+
+Les essais sont effectués sur Apple M1 ; la validation sur le PC Windows du
+créateur reste à faire.
+
+Aucune sauvegarde personnelle ouverte, aucun canal publié ni instance installée.

docs/north-ecology-beta202.md

@@ -0,0 +1,88 @@
+# EXP-202 — étagement du Nord et village enneigé
+
+Branche `codex/north-ecology-beta202`, depuis beta.201. Retour R021 et trois
+captures du labo 201 examinées (12:11:22, 12:11:46 et 12:12:57, 4 octobre 2026).
+
+Conserver les volumes, les cavités et les deux bassins 201, appréciés par le
+joueur. Refaire uniquement leur écologie et leurs sols : taïga, vallées ouvertes,
+podzol, épicéas géants natifs, neige progressive avec l'altitude, glaciers sur
+les hauteurs. Fin des aplats indépendants et du camouflage glace/glace bleue.
+Glace de cave limitée aux cavités protégées par une épaisseur de roche dans
+chaque direction ; aucune couche glacée appliquée aux falaises ou au dessous.
+Les cinq igloos doivent trouver une plaine réellement enneigée avant placement.
+Les pics de glace restent vanilla, comme demandé en R020.
+
+Nouveaux profils 202 et journal distinct, diamètre nordique 1024. Aucune migration
+ni régénération d'un monde existant ; 200 et 201 gardent leurs générateurs.
+L'île de départ et les autres directions restent inchangées. Le chantier est
+isolé de la visite 201 encore ouverte. Validation native neuve Small/42, contrôles
+numériques sur 0, 42 et 4736390610738281858 ; pas de campagne de captures.
+
+## Réalisation
+
+Le champ de densité et les deux bassins délèguent exactement à la génération
+201. Seuls les sols, la végétation, la couverture neigeuse et le placement du
+village changent. La limite de neige suit l'altitude, avec un versant nord plus
+froid. Son épaisseur progresse de quelques couches à un bloc après la végétation.
+Les glaciers sont réservés aux hauts versants ; aucune glace bleue ne peint
+la surface. Les vallées restent en herbe, les grands boisements en podzol.
+
+La taïga ordinaire et les épicéas géants réemploient les features 26.3 de taïga
+et `old_growth_spruce_taiga`. Aucun arbre géant custom ajouté. Les pics utilisent
+toujours `minecraft:ice_spike` et `minecraft:ice_patch`, sans remplacement des
+features natives. Les matériaux de cave glacée nécessitent du recouvrement et
+une assise rocheuse autour de la colonne ; les marges et dessous restent rocheux.
+Les cinq igloos cherchent une zone sèche, entièrement enneigée et peu pentue,
+avec classement par dénivelé. Aucun disque blanc ajouté sous le village.
+Caches numériques bornés ; pas de simulation hydrologique supplémentaire.
+
+## Vérifications du 4 octobre 2026
+
+- `north202Smoke` : neuf couples graine/taille (0, 42, 4736390610738281858 ;
+  512/724/1024), égalité des colonnes et densités avec 201, présence de taïga,
+  vallées, neige progressive et glacier minoritaire, protection du dessous.
+  Recherche du village vérifiée aussi sur les graines 1 à 100. Toutes passent.
+- Ressources historiques de génération inchangées, sauf le preset public qui
+  sélectionne désormais 202 et l'ajout du biome 202 au tag des ours polaires.
+  Les trois noise settings de l'île de départ sont identiques aux fichiers 201.
+- Essai natif final : `build/worldgen-lab/north202-native-b`, Small, graine 42,
+  diamètre de l'expansion 1024. Offrande réelle, interruption à 0/58 chunks,
+  reprise, cinq igloos, une cave de guérison, relais de continuation orienté Nord.
+- Échantillon de taïga : 1517 blocs de troncs, 7677 blocs de feuilles,
+  troncs atteignant 27 blocs, 13 empreintes de troncs larges, 3339 blocs de podzol.
+  Pics natifs : 2910 blocs de glace au-dessus du terrain, maximum sondé 43 blocs.
+  Ces nombres décrivent des échantillons, pas toute l'expansion.
+- Village : 333 des 339 colonnes sondées hors maisons portent de la neige.
+  Lac : 8995 blocs de glace et 41795 blocs d'eau, sans fuite dans l'air.
+  Caverne sondée : 49 blocs glacés et 2585 blocs d'air. Bordure sondée sur
+  16 directions : 340 blocs rocheux, aucune glace compacte/bleue.
+
+La validation esthétique reste celle de la visite. Pas de nouvelle campagne de
+captures. Visite native Small/42 uniquement : Windows et Medium/Large natifs
+ne sont pas vérifiés ici. Les sept autres directions restent provisoires.
+
+## Livraison locale
+
+`./gradlew check build assemblePack assembleTestPack
+-PsanctuaryFocusedTests=operator,realtime -PsanctuaryAtlasOnly=true` : succès,
+143 tâches, dont 126 exécutées ; sept GameTests ciblés et les smokes du projet.
+La suite native historique complète n'a pas été relancée (limite documentée
+pour beta.200). Logs : `build/north202-check-build.log` et
+`build/north202-native-final.log`.
+
+MRpack : `build/Sanctuary-Test-beta.202.mrpack`, copie identique dans Downloads
+avec `Sanctuary-Test-beta.202-Guide.txt`. ZIP, versions 26.3 / Loader 0.19.5,
+hashes Fabric API, deux JAR et leurs 2258 classes compilées vérifiés.
+Reçu local : `build/north202-artifact.json`.
+
+Taille : 12407853 octets ; SHA-256 :
+`b5ecdfcb2c4b1988f9402653a16c823b50f0661e8b1db0f0e7d6c21e9841f6f8`.
+
+Aucun monde inclus dans le MRpack. Aucun canal public ni instance Prism modifié.
+Visite neuve `Sanctuary-North-202-42`, issue de l'essai natif final, créatif,
+commandes activées, Vulkan, vue 32, simulation 4. Départ en vol près du village.
+Village `(-212,191,-1292)`, taïga géante `(144,215,-976)`, lac `(-247,258,-765)`,
+pics vers `(-208,281,-880)`, relais `(-128,202,-1240)`.
+
+Ouverture confirmée à 12:41:46 par `NORTH202_VISIT_OPEN`, joueur
+`(-160,228,-1247)` ; log `build/north202-visit-client.log`.

docs/north-expansion-beta200.md

@@ -0,0 +1,120 @@
+# EXP-200 — premier Nord glacial
+
+Branche `codex/north-expansion-beta200`, depuis beta.199. Retours R015–R017.
+
+## Résultat visé
+
+Un continent nordique de diamètre nominal 2048 : crêtes, pics, vallées de taïga
+neigeuse, neige poudreuse localisée, cavernes de glace et lacs gelés fermés.
+Chèvres et ours polaires natifs de Minecraft 26.3 (choix confirmé).
+Un village de plusieurs igloos ; un seul contient le laboratoire souterrain
+vanilla avec villageois zombie. Pas d'autre famille de structures dans cette
+première tranche. Le Sud, l'Est, l'Ouest et les diagonales seront travaillés à part.
+
+## Placement et ouverture
+
+L'identité du relais reste celle de son secteur. Recherche proche dans un
+éventail de ±15° devant l'ancre, sans basculer dans une autre direction.
+La première version 200 porte le Nord à 2048 ; les sept autres reliefs gardent
+leur taille/profil provisoire de 199. Le relais de continuation du Nord conserve
+la direction, le climat et la taille du Nord.
+
+Toute l'emprise est vérifiée vierge, réservée durablement et publiée avant les
+travaux. À cette échelle, `ready` signifie accès et relais préparés ; le reste
+est généré nativement pendant l'exploration. L'annonce SGA décrit cette ouverture,
+pas une pré-génération intégrale. Préparation bornée, sans simulation hydrologique
+globale ni réutilisation silencieuse de chunks déjà explorés.
+
+## Contrat des sauvegardes
+
+Nouveaux profils `shared_island200_small/medium/large`, journal distinct
+`sanctuary-lab-expansions200`. Aucun monde existant modifié ou migré ; les profils
+et ressources 196–199 restent inchangés. IDs historiques conservés. Les essais
+activent uniquement des expansions dans des mondes de développement neufs,
+graine 42 puis relevés déterministes sur 0 et 4736390610738281858.
+
+## Vérifications prévues
+
+Direction et diamètre, déterminisme, cavités, confinement des eaux, village
+et laboratoire habitable, vraie activation, sauvegarde et reprise. Compilation,
+`check build` et assemblages. Ne pas confondre vérification technique et validation
+esthétique : le rendu reste une première version à visiter.
+
+## Implantation et contrôles intermédiaires
+
+Le champ nordique compose des crêtes déformées, des sommets secondaires et des
+vallées, puis soustrait des passages et chambres 3D. Cache numérique borné par
+worker ; aucune lecture de chunks voisins pour dessiner le terrain. Six biomes
+nordiques reprennent l'écologie native de 26.3 ; les sources d'eau/lave dispersées
+et salles de monstres vanilla sont retirées de ces seuls profils. Les bassins
+ont un fond rocheux continu et une couverture de glace, sans hydrologie globale.
+
+Village : cinq igloos natifs orientés et ajustés individuellement au sol. Un
+seul laboratoire, avec échelle, coffre vanilla, potion de faiblesse, villageois
+et villageois zombie persistants. Les arbres évitent les maisons et les lacs.
+La faune initiale utilise les attributs du biome à la surface réelle, car la
+sélection vanilla à Y=1600 échantillonnait le vide ; règles de spawn natives
+conservées. Ours polaires également admis sur la glace des lacs.
+
+- `north200Smoke` : 9 couples graine/taille, huit éventails, relief/cavités,
+  bassins analytiquement fermés, journal 2048 et refus de 2048 en génération 199.
+- Essai intermédiaire Small/42, 2 Gio : vraie offrande nord, interruption à
+  0/58 chunks, puis reprise. Village de cinq igloos et un laboratoire contrôlés ;
+  lac avec 3475 blocs de glace et 10525 blocs d'eau, sans voisin d'air sous l'eau ;
+  136 blocs de glace et 1926 blocs d'air dans les colonnes de caverne sondées.
+  Ce sont des sondages locaux, pas les totaux du continent.
+- Le premier passage a révélé un barreau manquant sous la trappe : raccord
+  corrigé et vérifié lors du second passage. Les essais antérieurs restent
+  conservés sous `build/worldgen-lab/north200-native-a` et `north200-native-b`.
+- Les 148 ressources historiques de génération du module Test restent identiques
+  à beta.199 (hors preset public, qui sélectionne maintenant 200).
+
+## Essai final et livraison locale — 4 octobre 2026
+
+Le parcours serveur final `north200-native-final/small/42` répète l'activation
+réelle et l'interruption/reprise sur les sources livrées. Les 58 chunks d'accès
+et de relais passent à FULL ; cinq igloos, un laboratoire, le lac et la cavité
+glacée sont vérifiés. Les entités sauvegardées comprennent six ours polaires,
+trois renards, huit lapins, un villageois et un villageois zombie. Aucune chèvre
+observée dans ce petit échantillon : leurs règles natives sont présentes dans
+les sommets et pentes, sans validation d'une rencontre dans ce parcours.
+
+Le client Vulkan a ouvert une copie de visite neuve, `Sanctuary-North-200-42`,
+avec confirmation `NORTH200_VISIT_OPEN` à `(-200,224,-968)`. Créatif, commandes,
+vue 32 chunks et simulation 4 ; shaders désactivés. Le village se trouve autour
+de `(-200,212,-988)`, la trappe spéciale vers `(-193,210,-961)`, le lac sondé en
+`(-64,187,-1204)` et le relais suivant en `(-176,215,-2121)`.
+
+Archive locale : `build/Sanctuary-Test-beta.200.mrpack`, également copiée dans
+`/Users/koka/Downloads/`, avec `Sanctuary-Test-beta.200-Guide.txt`.
+12 366 771 octets ; SHA-256 :
+`2a29b35613f95540ec9d910e043a1f6f26b2dfe7d6d95c50997ba4bbde203cdc`.
+Intégrité ZIP, version, dépendances Minecraft 26.3 / Fabric Loader 0.19.5,
+empreintes Fabric API, deux JAR identiques au build et 2246 classes compilées
+vérifiés. Les trois tailles sont présentes ; aucune sauvegarde embarquée.
+Reçu : `build/north200-artifact.json`. Aucun canal public ni Prism synchronisé.
+
+La commande complète `check build assemblePack assembleTestPack` a été lancée,
+puis interrompue volontairement pendant
+`retainedHydrologySurvivesNativeDecoration` (ancienne génération 24, préparation
+de 112 chunks FULL). Les captures de threads montrent l'attente de génération ;
+elles ne démontrent pas un interblocage. Cette suite générale n'est pas validée.
+Logs : `build/north200-check-build.log`, `north200-fullcheck-threads*.txt`.
+Les essais serveur nordiques sont distincts de cette suite historique.
+
+Les sept GameTests `operator,realtime` passent avec le fixture plat
+`-PsanctuaryAtlasOnly=true`, indépendamment de l'essai natif nordique.
+Cette sélection ne remplace pas les 265 tests de la suite générale.
+La commande `./gradlew check build assemblePack assembleTestPack
+-PsanctuaryFocusedTests=operator,realtime -PsanctuaryAtlasOnly=true` termine avec
+succès : 141 tâches, dont 110 exécutées et 31 à jour. Elle inclut les tests
+numériques, notamment `north200Smoke`. Log complet :
+`build/north200-check-build-focused.log`. Archive revérifiée après l'assemblage
+final, identique aux JAR et classes finaux ; daemon de build arrêté ensuite.
+
+Limites : validation native détaillée sur Small/42, neuf couples graine/taille
+pour les contrôles numériques, pas de lancement Windows ni de visite native
+Medium/Large sur cette version. Les 2048 blocs désignent le diamètre nominal,
+pas une pré-génération intégrale. Le démarrage à 32 chunks a produit des retards
+de ticks avec les contrôles et un autre client simultanés sur le Mac 8 Gio :
+aucune conclusion de fluidité ni correction des saccades n'est revendiquée.

docs/north-fracture-beta203.md

@@ -0,0 +1,87 @@
+# EXP-203 — fractures, lisières et taïga géante
+
+Branche `codex/north-fracture-beta203`, depuis beta.202. Retour R022.
+Le rendu 202 est globalement validé. Passe ciblée demandée : ajouter de fortes
+variations locales de volume et des trous par bruit 3D, retirer la neige ajoutée
+après la végétation, brouiller les limites du podzol, donner aux grands épicéas
+une hauteur pouvant atteindre 64 et varier les matières des sommets glacés.
+Aucun nouveau village : la proposition supplémentaire est retirée par le joueur.
+Les cinq igloos existants restent présents.
+
+Nouveaux profils 203 seulement, Nord 1024. Aucun monde existant régénéré ni
+migré ; profils 200–202 inchangés. Bassins et basses plaines d'accueil protégés
+de la déformation. Pics de glace vanilla conservés. Arbres avec moteur natif,
+configuration propre au biome géant ; aucune modification globale des épicéas.
+Pas de simulation d'érosion ou d'hydrologie supplémentaire, caches bornés.
+
+## Réalisation
+
+Le champ 203 combine des déplacements verticaux locaux (deux échelles de bruit)
+et un bruit volumique négatif de plus grande portée. Les nouvelles poches
+peuvent traverser le toit ou le dessous, contrairement aux caves fermées 202.
+Le bruit est atténué sur les basses plaines, les bords et tout autour des lacs.
+Les seuils de sommet restent lisibles ; le détail 3D module les roches et glaces.
+
+La passe de neige après décoration n'est pas appelée pour 203. Les prairies
+froides gardent leur herbe ; la neige demeure comme matériau de sommet,
+substrat nécessaire aux pics vanilla et matériau des igloos existants.
+Le champ de podzol comporte deux fréquences de détail aux lisières. Le
+`alter_ground` circulaire des nouveaux grands arbres est supprimé.
+
+Les arbres réemploient `giant_trunk_placer` et `mega_pine_foliage_placer` de
+Minecraft 26.3. Configuration locale : hauteur 32 + aléa 0–16 + aléa 0–16,
+soit 32 à 64 blocs, couronne de 18–24 ; mélange de géants et de petits épicéas.
+Les features `ice_spike` / `ice_patch` restent natives et inchangées.
+
+## Contrôles
+
+`north203Smoke` passe sur neuf couples graine/taille (0, 42,
+4736390610738281858 ; Small/Medium/Large). Les déplacements locaux sondés vont
+jusqu'à environ −62 / +56 blocs selon le cas. Ouvertures de surface présentes,
+densité bornée, lacs et leurs coques inchangés, lisières de podzol irrégulières.
+Recherche des cinq igloos vérifiée également sur les graines 1 à 32.
+Les ressources worldgen historiques sont inchangées, hors sélection du nouveau
+preset public et ajout du biome 203 au tag des ours polaires. Les noise settings
+de l'île de départ restent identiques à 202. Aucun test visuel Windows ni
+nouvelle campagne de captures : le rendu est à juger dans le labo.
+
+
+Essai natif final : `build/worldgen-lab/north203-native-b`, Small/graine 42.
+Vraie offrande, interruption à 0/58 chunks, reprise et relais prêts. Cinq igloos
+et un laboratoire conservés. Recherche de cave orientée vers un intérieur
+suffisamment épais, plutôt que le sommet le plus haut désormais fracturé.
+
+Dans les échantillons : 4218 blocs de troncs, 10450 de feuilles, 21 empreintes
+de troncs larges ; tronc le plus haut mesuré 59 blocs (plafond configuré 64).
+Sommet : 309 blocs de glace bleue, 63 de glace ordinaire, 2154 de glace compacte,
+1219 de neige pleine et 1694 de roche. Pics vanilla : maximum sondé 13 blocs
+au-dessus du terrain. Prairie : zéro couche de neige parmi 339 colonnes.
+Lac : 8995 blocs de glace et 41795 d'eau, sans fuite ; caverne sondée : 226 blocs
+glacés et 1878 d'air. Bordure : 339 blocs rocheux, aucune glace compacte/bleue.
+Il s'agit de contrôles locaux, pas d'un comptage de toute l'expansion.
+
+
+## Livraison
+
+`./gradlew check build assemblePack assembleTestPack
+-PsanctuaryFocusedTests=operator,realtime -PsanctuaryAtlasOnly=true` : succès,
+144 tâches dont 120 exécutées, sept GameTests ciblés et les smokes du projet.
+La suite native historique complète n'a pas été relancée (limite beta.200).
+Logs : `build/north203-check-build.log` et `build/north203-native-final.log`.
+
+MRpack vérifié : `build/Sanctuary-Test-beta.203.mrpack`, copie identique dans
+Downloads avec le guide. Archives, versions, dépendances, empreintes Fabric API,
+JAR et 2265 classes compilées vérifiés ; reçu `build/north203-artifact.json`.
+
+12433661 octets ; SHA-256 :
+`ba160b4134c0b9dbe402e1834bdbec4f5561bfd6bd9dc147590dd76ee30dbf4f`.
+
+Visite neuve `Sanctuary-North-203-42`, issue de l'essai natif final. Créatif,
+commandes activées, Vulkan, vue 32, simulation 4 ; départ au-dessus de la taïga.
+Village `(-212,191,-1292)`, forêt `(144,215,-976)`, pics `(-208,278,-944)`,
+premier lac `(-247,258,-765)`. Aucun canal public ni instance Prism modifié.
+Pas de sauvegarde embarquée dans le pack ni de revendication sur les saccades.
+Essai natif Small/42 seulement ; Medium/Large sont contrôlés numériquement.
+
+Ouverture confirmée à 13:12:20 par `NORTH203_VISIT_OPEN`, départ
+`(196,292,-931)`, backend Vulkan confirmé dans `build/north203-visit-client.log`.

docs/north-glacier-beta201.md

@@ -0,0 +1,90 @@
+# EXP-201 — Nord compact, glacier et bosquets
+
+Branche `codex/north-glacier-beta201`, depuis beta.200 ; retours joueur R019–R020.
+
+## Résultat demandé
+
+Le diamètre du Nord passe de 2048 à 1024 blocs. Remplacer la nappe blanche perçue
+par un paysage de glace lisible : pics de glace, glacier, deux lacs gelés visibles,
+bosquets localisés et contraste roche/glace/neige. Conserver les cinq igloos et
+le laboratoire avec villageois zombie. Les lacs doivent contenir de l'eau sous
+leur glace ; la végétation doit être réellement générée, pas seulement déclarée.
+Les pics utilisent explicitement `minecraft:ice_spike` et `minecraft:ice_patch`
+de Minecraft 26.3, avec leurs placements natifs. Aucune forme de pic recodée.
+
+Le Nord ne doit pas devenir le catalogue de tous les biomes froids. Son identité
+est le glacier habité ; les grandes forêts boréales, côtes froides et autres
+paysages restent des pistes pour NO/NE. Leur répartition n'est pas décidée ici.
+
+## Contrat de génération
+
+Nouveaux profils 201 et journal `sanctuary-lab-expansions201`, destinés uniquement
+aux nouveaux mondes. Les profils et le champ nordique 200 restent disponibles
+pour les sauvegardes historiques ; aucune conversion des expansions 2048 déjà
+créées, ni régénération de chunks. Île de départ Small/Medium/Large inchangée.
+Placement dans l'éventail existant de ±15°. Préparation bornée de l'arrivée et du
+relais, puis exploration. Les sept autres directions restent provisoires.
+
+## Vérifications attendues
+
+Contrôle de taille et de direction, stabilité de la génération 200, proportions
+et visibilité des surfaces glaciaires, lacs fermés, relief vertical, bosquets et
+village. Vérification native de vrais troncs/feuilles, glace de surface non
+recouverte et pics élevés. Graines numériques 0, 42 et 4736390610738281858 ; visite
+native neuve Small/42. Pas de campagne de screenshots ni d'hydrologie globale.
+
+Les contrôles techniques ne remplacent pas le retour esthétique du joueur.
+
+## Intégration
+
+La 200 posait une couche de neige pendant le traitement du sol, avant les
+features végétales ; les arbres natifs de taïga passent par les saplings
+`spruce_checked` / `pine_checked`, qui exigent un support viable. La 201 laisse
+le sol des bosquets en herbe jusqu'à leur plantation. Les lacs et le glacier ne
+reçoivent plus la feature `freeze_top_layer`, afin que leur glace reste visible.
+Les zones de pics conservent au contraire le bloc de neige requis par la feature
+native `minecraft:spike`. Ses références et sa fréquence restent vanilla.
+
+Le substrat compact associe une crête, des épaules glaciaires, deux champs de
+pics natifs, deux bosquets et deux bassins fermés. Caches numériques bornés ;
+aucune simulation hydrologique globale. Le village est rapproché du premier lac.
+Le relief, les matériaux et le choix de biomes de la 200 gardent leur branche
+de génération historique.
+
+## Résultats — 4 octobre 2026
+
+- `north201Smoke` : neuf couples graine/taille, Nord 1024, relief, parts de glace,
+  bosquets, lacs et champs de pics, confinement des bassins, déterminisme et
+  routage historique 200. `north200Smoke` reste passant. Les 155 ressources
+  historiques worldgen du module Test restent identiques, hors preset public.
+- Serveur neuf Small/42, `build/worldgen-lab/north201-native-a` : vraie offrande,
+  interruption à 0/58 chunks, reprise et accès préparés. Cinq igloos, une cave
+  avec trappe/échelle/coffre/potion ; relais de continuation orienté Nord.
+- Échantillon du bosquet : 395 blocs de troncs et 3294 blocs de feuilles
+  d'épicéa, répartis sur 56 colonnes de troncs (pas un comptage d'arbres entiers).
+  Champ de pics natifs : 1838 blocs de glace compacte au-dessus du terrain,
+  maximum sondé de 11 blocs. Lac : 8995 blocs de couverture gelée et 41795 blocs
+  d'eau ; 7602 surfaces de glace visibles contrôlées, zéro couche de neige dessus.
+  Caverne : 561 blocs de glace et 2585 blocs d'air sondés. Totaux locaux uniquement.
+- `./gradlew check build assemblePack assembleTestPack
+  -PsanctuaryFocusedTests=operator,realtime -PsanctuaryAtlasOnly=true` : succès,
+  sept GameTests ciblés et tous les smokes associés, 142 tâches dont 118 exécutées.
+  La suite native historique complète n'a pas été relancée (limite beta.200).
+  Logs : `build/north201-check-build.log` et `build/north201-native-a.log`.
+
+Livraison locale : `build/Sanctuary-Test-beta.201.mrpack`, copie dans Downloads
+avec le guide. 12 386 623 octets ; SHA-256 :
+`37925f012e4096c253f25e573305237e71114448d866a57f3fbad6e3da6b3d89`.
+ZIP, dépendances 26.3 / Loader 0.19.5, empreintes Fabric API, JAR et 2252 classes
+compilées vérifiés. Les trois tailles sont incluses, aucune sauvegarde embarquée.
+Reçu : `build/north201-artifact.json`. Aucun canal public ni Prism modifié.
+
+Visite préparée : `Sanctuary-North-201-42`, nouveau monde issu de l'essai natif.
+Départ près du lac en `(-142,323,-705)`, créatif, commandes, Vulkan, vue 32 et
+simulation 4. Ouverture confirmée par `NORTH201_VISIT_OPEN` dans
+`build/north201-visit-client.log`. Village `(-128,205,-637)`, lac `(-247,258,-765)`, bosquet
+`(-324,258,-780)`, champ de pics vers `(-273,-1059)`, relais `(-128,202,-1240)`.
+
+Limites : visite native Small/42 seulement, pas d'essai Windows ou Medium/Large
+natif sur cette version. Pas de revendication sur les saccades. Les paysages
+NO/NE ne sont pas implémentés ; les anciens mondes ne changent pas de taille.

docs/notice-scene-beta162.md

@@ -0,0 +1,66 @@
+# beta.162 — scène du tableau et conversation
+
+Ticket issu du retour de séance du 24 septembre : conserver Retour/Actualiser en
+haut, montrer l’auteur avec son skin orienté vers la souris et sa demande dans
+une bulle colorée, puis les réponses à droite (dessous sur GUI étroit).
+
+Modification client uniquement, sans migration, écriture dans les mondes ni
+changement des contrats fichier/MariaDB. Réponses, modération et suivi gardent
+leurs validations serveur. Le portrait est un rendu GUI, pas une entité.
+
+## Présentation
+
+- Retour et Actualiser restent hors de la zone défilante.
+- Le portrait utilise le skin de la connexion de l’auteur s’il est présent,
+  sinon le cache de profils Minecraft asynchrone. Le skin natif de repli apparaît
+  pendant le chargement ou si le profil ne peut pas être résolu (notamment les
+  comptes fictifs/hors ligne). Aucun téléchargement synchrone dans le rendu.
+- Une bulle persistante encadrée montre catégorie/état, titre puis texte complet.
+  Information : jaune clair sur fond sombre jaune ; les autres catégories gardent
+  leurs couleurs. Les cartes de liste et du menu pause suivent aussi ce jaune.
+- Le portrait tourne doucement dans des angles bornés selon la position de la
+  souris, sans capturer ses mouvements et sans clic requis.
+- Demande et discussion défilent séparément si l’espace le permet ; le champ de
+  réponse et son bouton restent en bas de la discussion. Sur GUI étroit/bas,
+  un défilement unique garde les réponses sous la scène.
+- Matériaux, lieu, récompense, suivi, visages des réponses et modération sont
+  conservés. Les détails d’une demande vide ne sont plus affichés artificiellement.
+- Aucune animation de parole ni synchronisation vocale : « parle » désigne ici
+  la mise en scène visuelle avec la bulle.
+
+## Vérification
+
+- Compilation Java 25 / Minecraft 26.3 réussie.
+- Parcours natif Vulkan : `NOTICE162_SCENE_PASS`, puis
+  `SEARCH159_CLIENT_PASS mode=file`, build réussi en 1 min 59 s.
+- FR/EN, GUI 2/3/4 : scène, passage en colonne unique, boutons de retour au-dessus,
+  réponse au-dessus du footer en deux colonnes, angles du portrait bornés et
+  changement d’orientation avec la souris.
+- Brouillon conservé pendant les redimensionnements ; publication d’une réponse
+  et lecture de son contenu après rechargement serveur vérifiées.
+- Régressions communautaires : photos, recherche, suivi/désabonnement, marqueur
+  de carte et infobulle, restrictions de l’Intendance toujours validés.
+- Captures relues : `build/qa-beta162/0042_notice162-scene-fr_fr-2.png` et
+  `0043_notice162-scene-fr_fr-3.png`. Conversation : `0048_notice162-conversation.png`.
+- `./gradlew check build assemblePack` lancé : 252 GameTests terminés, 229 réussis
+  et 23 échecs, exactement les mêmes qu’en beta.161 (aucun ajouté/retiré).
+  Liste comparée : `build/session162-server-failures.json`.
+- Contrôles restants et assemblage avec exclusion ponctuelle de `runGameTest` :
+  réussis en 3 min 16 s (`check build assemblePack -x :sanctuary:runGameTest`).
+  Aucune assertion désactivée dans les sources. Log : `build/beta162-assembly.log`.
+
+Aucune modification de persistance : cette passe native utilise le mode fichier ;
+le laboratoire MariaDB partagé a été relancé avec la même interface, KokaLab
+connecté sur le monde existant `duo-flat-160`, Alice/Bob recréés, shader désactivé. Les figurants
+et profils hors ligne peuvent afficher un skin Minecraft de repli.
+
+## Livraison locale
+
+JAR : `mods/sanctuary/build/libs/sanctuary-beta.162.jar`.
+Pack assemblé : `build/packwiz`.
+SHA-256 : `35c5d82eba110ee2150f73baf6341efc90f87971965a3b4dd2bcd04add0a59ff`.
+
+Branche `codex/notice-scene-beta162`, tag local `beta.162`. Anciens JAR conservés.
+Aucune publication distante ni synchronisation de Prism dans cette livraison.
+Les 23 échecs préexistants restent ouverts ; les essais graphiques ne démontrent
+pas la résolution réseau d’un skin officiel absent dans ce laboratoire hors ligne.

docs/origin-gallery-beta182.md

@@ -0,0 +1,68 @@
+# ORIGIN-182 — galerie inférieure et rosace
+
+Suite du retour en jeu sur beta.181, le 30 septembre 2026. Branche
+`codex/origin-gallery-beta182`, dans le checkout de développement réutilisé
+`rocky-ecology-beta178`. La palette naturelle de l’origine est validée par le
+créateur. Les élévations gênent les huit directions ; elles doivent être
+placées entre les axes. Essayer une cloche vitrée en rosace et développer
+la scène souterraine. L’origine reste en l’air.
+
+La mention « le truc dans les airs » est interprétée ici comme la rosace,
+en attendant une éventuelle précision ; l’ISS reste un chantier séparé.
+
+## Contrat du nouveau monde
+
+Nouveau preset facultatif `sanctuary_test:gallery_v1`, profil `gallery`,
+graine 42. Les profils précédents et la génération normale restent disponibles
+avec leur génération propre. Aucun ancien monde, chunk ou format de sauvegarde
+n’est modifié. Aucune expansion ni dimension n’est activée par ce prototype.
+
+La galerie sélectionne une cavité centrale sous X=0/Z=0 par un échantillonnage
+borné du champ de densité existant. Deux chambres voisines forment une boucle
+avec elle ; les passages suivent des failles inclinées, les sols ondulent et
+les plafonds sont voûtés. Roche dominante, calcite par veines, mousse ponctuelle,
+quelques reliefs de tuf. Pas de murs rectangulaires plaqués sur toute la caverne.
+Un socle d’obsidienne central et deux montants sombres interrompus donnent un
+premier emplacement au portail inférieur. C’est une scène architecturale :
+ni portail actif, ni recette d’allumage ou téléportation ne sont implémentés.
+
+L’origine conserve la palette, le sol à huit directions et le bloc en
+(0,320,0), lumineux et monochrome. Une cloche de verre clair et blanc avec
+huit nervures de cuivre patiné remplace les trois élévations. Les supports
+sont entre les axes ; huit ouvertures basses conservent vues et passages.
+L’ISS, les huit salles d’ancres et les trois secteurs de gemmes ne sont pas
+ajoutés dans ce lot.
+
+Les deux lieux sont posés par chunk à la génération, sans ticker, sans
+recherche globale d’eau et sans journal de progression. Le plan souterrain
+est calculé une fois pour la source de biomes puis réutilisé. Une sauvegarde
+recharge les blocs, elle ne reconstruit pas les lieux.
+
+## Vérifications
+
+Compilation et export du lanceur réussis. Monde neuf `solo182a/gallery/42` :
+contrôles de la beta.180 conservés (567 échantillons de densité, trois cerisiers,
+bassins de 1 232 et 1 221 blocs, cinq spawners et quatre caches avec les gemmes).
+Zéro région d’hydrologie calculée.
+
+La galerie contient 1 558 colonnes sculptées ; 1 514 surfaces praticables
+appartiennent au même réseau, connecté par marches d’un bloc maximum.
+Les trois centres de salle sont en (0,175,0), (-34,169,-26), (-38,146,24).
+Le socle porte l’obsidienne en (0,177,0). La rosace compte 1 841 blocs avec
+le fragment rocheux : huit axes libres à hauteur du joueur et noyau lumineux
+sans relais activé. Rapport local `build/gallery182-quick-result.json`.
+Arrêt du serveur de préparation et sauvegarde terminés proprement.
+
+Solo neuf préparé sous `visite182/gallery/42`, `Sanctuary-Gallery-182-Solo`,
+vue 32, créatif et commandes, première vue sur la galerie.
+Visites : galerie `/tp 0.5 177 7.5 180 0` ; rosace
+`/tp 0.5 319 5.5 180 0`. Rendu et proportions à juger en jeu sur la graine 42 ;
+aucune autre graine ni capture du rendu n’est revendiquée.
+Suite générale `check build assemblePack assembleTestPack` réussie en 8 min 1 s,
+265/265 GameTests ; journal `build/gallery182-check-build.log`.
+
+Entrée dans le solo confirmée depuis par le créateur. Le journal
+`build/gallery182-solo.log` enregistre KokaLab connecté le 30 septembre à
+02:25:12, vue 32 chunks. Son retour valide la palette, la rosace et les étangs ;
+la correction du portail et les lieux manquants sont suivis dans
+[DISCOVERY-183](island-discovery-beta183.md).

docs/origin-landmark-beta181.md

@@ -0,0 +1,96 @@
+# ORIGIN-181 — repère central dans le ciel
+
+Retour du 30 septembre 2026 sur beta.180. Branche `codex/origin-landmark-beta181`.
+Le créateur apprécie le relief global et le donjon minier. Le prochain résultat
+à visiter est une petite construction ouverte qui signale le centre du monde,
+avec le bloc originel exactement en **X=0, Y=320, Z=0**. Cette décision remplace
+les positions antérieures envisagées pour ce bloc ; elle ne rétablit pas le palais.
+
+## Premier résultat
+
+Nouveau preset facultatif `sanctuary_test:origin_v1`, profil `origin`, graine 42.
+Terrain, écologie, bassins, cerisiers et donjon de beta.180 réutilisés. Un fragment
+rocheux porte une rose des vents à huit directions, en tuf, calcite et deepslate,
+avec cuivre patiné, quelques mousses et un croissant brisé. Le sol principal est
+à Y=318, le piédestal à Y=319 et le Bug Rock à Y=320. La silhouette culmine à 328.
+Circulation ouverte, pas de toiture ni de conteneur. Environ 19 blocs de large.
+
+Le bloc réutilise `sanctuary:origin_block` et sa texture existante : allumé en
+noir et blanc, lumière 15, masque des huit relais à zéro. Aucune ancre n’est
+activée. Ce premier lieu est un repère visuel ; pas encore d’interaction, de
+quête ni de trajet d’accès en survie. Le créatif et les commandes du labo
+permettent de juger le volume avant de définir le parcours.
+
+La pose se fait une seule fois par chunk, pendant la décoration native, sur
+quatre chunks autour de l’origine. Aucune recherche régionale, aucun calcul
+par tick, aucune entité ni hydrologie supplémentaire. La patine et la base
+rocheuse varient avec la graine ; la silhouette reste celle de ce premier essai.
+
+## Sauvegardes et validation
+
+Nouveau monde uniquement. Le preset beta.180 et la génération normale ne
+reçoivent pas ce lieu. Aucun ancien chunk ni format de sauvegarde n’est migré.
+La reprise recharge les blocs sauvegardés sans reconstruction. Pas de publication
+du canal, de mise à jour Prism ni d’installation serveur personnel.
+
+Le contrôle natif vérifie l’origine exacte, la présence du plan dans les quatre
+chunks, la circulation, l’ouverture vers le ciel et l’état monochrome lumineux.
+Les vérifications de beta.180 restent appliquées au nouveau profil.
+
+Essai natif `solo181a`, graine 42, réussi : 1 224 blocs du repère présents,
+quatre chunks, origine et passages conformes, 567 comparaisons de densité
+conservées et zéro région d’hydrologie. Trois cerisiers, surfaces de bassins
+de 1 232 et 1 221 blocs, cinq spawners et quatre caches avec les quatre gemmes
+validés. La lecture des chunks enregistrés confirme le bloc à (0,320,0),
+`lit=true`, `relays=0`. Rapport : `build/origin181-quick-result.json`.
+
+Compilation et export du lanceur réussis. Le solo neuf
+`visite181/origin/42`, nommé `Sanctuary-Origin-181-Solo`, est ouvert le
+30 septembre à 01:59 : Vulkan Apple M1, KokaLab connecté en (18.5,333,23.5),
+vue 32 chunks. Approche à pied pour la visite : `/tp 0.5 319 5.5 180 0`.
+L’appréciation esthétique reste à faire en jeu ; aucune capture du rendu
+n’est revendiquée. Seule la graine 42 est validée dans cette itération.
+Suite générale `check build assemblePack assembleTestPack` réussie en
+12 min 53 s, journal `build/origin181-check-build.log` dans le checkout
+`storyquest-beta173`. Contrôles et assemblages terminés avant la suite beta.182.
+
+Retour en jeu du créateur : palette et caractère naturel validés. Les trois
+élévations empiètent sur les directions ; prochaine variante avec supports
+entre les huit axes et piste d’une cloche vitrée en rosace. Garder l’origine
+en l’air pendant l’essai. Développer d’abord la galerie souterraine, puis
+le lieu aérien ; précision sur ce dernier demandée pendant la séance.
+
+## Suite de la séance : décisions et pistes, pas encore implémentées
+
+- **Gemmes :** trois secteurs souterrains distincts, émeraude, rubis et saphir,
+  avec veines exposées sur les surfaces rocheuses. Un stock limité comparable
+  aux diamants à l’échelle de l’île, pas par échantillon de chunks. Le chiffre
+  exact par gemme reste à régler. Proposition : compter séparément le stock
+  généré de chaque gemme ; densité locale lisible, rareté globale préservée.
+- **Soufre :** intégrer une poche de sulfur caves sur l’île principale. Le
+  profil beta.180 ne contient pas ce biome, même si le socle historique connaît
+  le soufre. Choisir une poche dédiée plutôt que repeindre les cavités humides.
+- **Huit ancres :** salles naturelles sculptées dans leur matière locale,
+  creux, reliefs irréguliers, bas-reliefs, végétation et piédestal portant le
+  bloc existant. Chaque lieu a sa géographie ; pas de ponts imposés vers le centre.
+- **Galerie inférieure :** caverne centrale sous X=0/Z=0, salles reliées par
+  des failles, dénivelés et emplacement de portail en obsidienne. Altitude,
+  emprise et lien exact avec les dimensions à préciser. Le palais abandonné
+  n’est pas réintroduit. Proposition technique : sonder un nombre borné de
+  points du champ de densité existant, sélectionner une cavité et ne retoucher
+  que ses passages ; calcul à la génération, aucun raycast permanent.
+- **Activation :** envie de remplacer le briquet par un objet fabriqué au
+  métabli, reliant préparation et découverte. Recette, composants et effet
+  encore ouverts ; ne pas modifier le portail vanilla avant ce contrat.
+- **Expansions :** privilégier l’expérience de surface, avec des masses tantôt
+  horizontales, tantôt verticales. La profondeur dépendra de chaque île ; ne
+  pas généraliser automatiquement toutes les cavités de Sanctuary à chaque île.
+- **ISS :** chantier architectural séparé dans la bande Y=512–640. Des
+  schematics pourront servir à analyser échelle, modules, circulation et
+  palette ; construire ensuite un plan original. Aucun fichier ISS reçu ici.
+  Fonction et quête restent à définir.
+
+Ordre proposé pour les essais suivants : origine visible → une salle d’ancre
+dans une cavité existante → trois secteurs de gemmes et une poche de soufre →
+déclinaison des autres ancres et galerie inférieure. Chaque essai garde son
+monde témoin et se juge en solo ; pas de grande étude scientifique imposée.

docs/packwiz.md

@@ -1,5 +1,13 @@
 # Distribution packwiz et Prism
 
+## Rattrapage des releases du 24 septembre 2026
+
+Les binaires conservés des beta.145–151 et beta.154–166 sont publiés dans Gitea.
+La beta.144 existante reste intacte ; les 152–153 demeurent des chantiers non livrés.
+[Inventaire, empreintes et limites](publications-beta144-166.md).
+Cette publication ne modifie ni le canal packwiz ni les installations Prism.
+
+
 Sanctuary Beta utilise une seule instance Prism, synchronisée avant chaque
 lancement par packwiz. Le canal reste à l'adresse :
 
@@ -14,6 +22,332 @@ JAR Sanctuary sont des pièces jointes de releases Gitea. Aucun JAR de mod ou
 dépendance téléchargée n'entre dans l'historique Git. Le canal Beta est distinct
 de l'ancien pack 26.2.
 
+## beta.144 — Eau naturelle pixélisée (préparation)
+
+Trois profils de couleur/transparence selon le fond, océans clairs et brume
+aquatique adaptée. Le [ticket de livraison](natural-water-beta144.md) décrit
+la teinte olive retenue, les contrôles et le protocole de performance.
+La publication et la synchronisation attendent la validation finale isolée.
+Les textures restent à beta.121 ; Minecraft 26.3 et les dépendances sont conservés.
+
+## beta.143 — Neige saisonnière en temps réel
+
+Accumulation espacée par un facteur 12 et fonte par le facteur temps réel 72,
+avec le sampler natif de précipitation conservé. Protections inchangées pour
+la neige construite, les biomes froids, l'hiver, les profils neigeux et la
+météo Vanilla. [Contrat et vérifications](realtime-snow-melt-beta143.md).
+[Release beta.143](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.143)
+publiée ; canal `bafff5e9fcdd95c5dd184953a34ada805e455797`. Deux synchronisations
+isolées puis deux dans l'instance Sanctuary Beta réussies. Les 923 fichiers
+personnels suivis gardent leurs hashes. Aucun monde personnel ouvert ;
+sauvegarde préalable `sanctuary-backups/before-beta.143/`. Archives vérifiées
+dans `sanctuary-beta/build/`.
+
+## beta.142 — Vulkan par défaut et stabilité PBR
+
+Vulkan natif prioritaire, rafraîchissements PBR stables et intensité initiale
+80 %, calculs de reflets bornés. [Contrat et vérifications](pbr-refresh-beta142.md).
+[Release beta.142](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.142)
+publiée ; canal `d661260e2bbabb0326c86d6cc543daf986979596`. Deux synchronisations isolées
+puis deux dans l'instance Sanctuary Beta réussies. Les 923 fichiers personnels
+suivis gardent leurs hashes. Aucun monde personnel ouvert ; sauvegarde préalable
+`sanctuary-backups/before-beta.142/`. Archives vérifiées dans `sanctuary-beta/build/`.
+Un choix OpenGL explicite reste conservé : sélectionner Vulkan dans les réglages
+vidéo et redémarrer pour changer ce choix. La capture Windows de bruit en
+mouvement reste à reconfirmer sur son pilote ; les contrôles OpenGL/Vulkan Mac
+et la correction du domaine numérique du reflet sont documentés dans le ticket.
+
+## beta.141 — Direction des lumières pour les normales PBR
+
+Directions locales mises en cache, sources portées, confiance réduite lorsque
+les sources s'opposent et fondus. Activer PBR et Lumières colorées ; portée PBR
+de 32 blocs. [Contrat et vérifications](directional-lights-beta141.md).
+[Release beta.141](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.141)
+publiée ; canal `7e6c84400f80db24bf5204cd21d628194ae9f0f7`. Deux synchronisations isolées
+puis deux dans l'instance Sanctuary Beta réussies. Les 923 fichiers personnels
+suivis gardent leurs hashes. Aucun monde personnel ouvert ; sauvegarde préalable
+`sanctuary-backups/before-beta.141/`. Archives vérifiées dans `sanctuary-beta/build/`.
+
+## beta.140 — Lumières portées et fondus
+
+Couleurs des objets en main et sur la tête, distances 8/16/32/64 et fondus
+préservant la teinte. Torches natives par défaut, option chaude, cuivre vert
+et redstone rouge. [Contrat et vérifications](colored-dynamic-beta140.md).
+[Release beta.140](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.140)
+publiée ; canal `2c360a0759d4a164f82c89ac2bef04ff69d50875`. Deux synchronisations isolées
+puis deux dans l'instance Sanctuary Beta réussies. Les 923 fichiers personnels
+suivis gardent leurs hashes. Aucun monde personnel ouvert ; sauvegarde préalable
+`sanctuary-backups/before-beta.140/`. Archives vérifiées dans `sanctuary-beta/build/`.
+
+## beta.138 — Densité des rayons selon la météo
+
+Brouillard plus dense et diffus, précipitations et atténuation de l'orage.
+Réglage manuel conservé, aucune nouvelle option ni modification de sauvegarde.
+[Contrat et vérifications](shader-beta138.md).
+[Release beta.138](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.138)
+publiée ; canal `c049423de1971079b9d61874d83adeb6f1ad49f7`. Deux synchronisations isolées,
+puis deux dans la même instance Sanctuary Beta réussies. Les 923 fichiers
+personnels suivis gardent leurs hashes. Aucun monde personnel ouvert ;
+sauvegarde préalable `sanctuary-backups/before-beta.138/`.
+Packs normal/Test/template vérifiés dans `sanctuary-beta/build/`.
+
+## beta.137 — Rayons solaires volumétriques
+
+Rayons à travers les ouvertures et le feuillage, activés à 35 %, indépendants
+du bloom et de l'affichage des ombres de surface. Carte solaire partagée.
+[Contrat et vérifications](shader-beta137.md).
+[Release beta.137](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.137)
+publiée ; canal `68cb39a5edbf5d34def02f670e2488ee852605b8`. Deux synchronisations isolées,
+puis deux dans la même instance Sanctuary Beta réussies. Les 923 fichiers
+personnels suivis gardent leurs hashes. Aucun monde personnel ouvert ;
+sauvegarde préalable `sanctuary-backups/before-beta.137/`.
+Packs normal/Test/template vérifiés dans `sanctuary-beta/build/`.
+
+## beta.136 — Lens flare rectangulaire
+
+Rectangles à dégradé doux pour le soleil et la lune, activés à 30 % et
+réglables indépendamment du bloom. Occultation par les blocs et phases lunaires.
+[Contrat et vérifications](shader-beta136.md).
+[Release beta.136](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.136)
+publiée ; canal `dd5b545a7cfbb957f2c70e9dc17034b44caef98f`. Deux synchronisations isolées,
+puis deux dans la même instance Sanctuary Beta réussies. Les 923 fichiers
+personnels suivis gardent leurs hashes. Aucun monde personnel ouvert ;
+sauvegarde préalable `sanctuary-backups/before-beta.136/`.
+Packs normal/Test/template vérifiés dans `sanctuary-beta/build/`.
+
+## beta.135 — SSGI en proximité et nouveaux défauts
+
+Normales stables près des surfaces, atténuation progressive du rebond au contact.
+Bloom à 20 %, PBR et SSGI activés par défaut, choix personnels existants conservés.
+[Contrat et vérifications](shader-beta135.md).
+[Release beta.135](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.135)
+publiée ; canal `5b0df577fcd036937c25be3a1f4580f9db3103a1`. Deux synchronisations isolées,
+puis deux dans la même instance Sanctuary Beta réussies. Les 923 fichiers
+personnels suivis gardent leurs hashes. Aucun monde personnel ouvert ;
+sauvegarde préalable `sanctuary-backups/before-beta.135/`.
+Packs normal/Test/template vérifiés dans `sanctuary-beta/build/`.
+
+## beta.134 — PBR optionnel et SSGI filtré
+
+Normales procédurales en cache, rugosité/métallicité par famille et reflets
+directionnels. Filtrage SSGI et suppression de sa forte réinjection neutre.
+[Contrat et vérifications](shader-beta134.md).
+[Release beta.134](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.134)
+publiée ; canal `35ec0f6e145002f6367944df5b75e2703958eaef`. Deux synchronisations isolées,
+puis deux dans la même instance Sanctuary Beta réussies. Les 923 fichiers
+personnels suivis gardent leurs hashes. Aucun monde personnel ouvert ;
+sauvegarde préalable `sanctuary-backups/before-beta.134/`.
+Packs normal/Test/template vérifiés dans `sanctuary-beta/build/`.
+
+## beta.133 — SSGI renforcé
+
+Diffusion des couleurs rendue visible au réglage 35, même budget de rayons
+et cibles GPU. [Contrat et vérifications](shader-beta133.md).
+[Release beta.133](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.133)
+publiée ; canal `9ceb5a5353c9d1b8bb7834a20e818fd65096ff98`. Deux synchronisations isolées,
+puis deux dans la même instance Sanctuary Beta réussies. Les 923 fichiers
+personnels suivis gardent leurs hashes. Aucun monde personnel ouvert ;
+sauvegarde préalable `sanctuary-backups/before-beta.133/`.
+Packs normal/Test/template vérifiés dans `sanctuary-beta/build/`.
+
+## beta.132 — SSGI expérimental
+
+Diffusion locale des couleurs visibles, rayon 2,5 blocs, intensité réglable,
+initialement OFF. [Contrat et vérifications](shader-beta132.md).
+[Release beta.132](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.132)
+publiée ; canal `9edaaedc0205c525ecce9de66b5ca7827c56c28f`. Deux synchronisations isolées,
+puis deux dans la même instance Sanctuary Beta réussies. Les 923 fichiers
+personnels suivis gardent leurs hashes. Aucun monde personnel ouvert ;
+sauvegarde préalable `sanctuary-backups/before-beta.132/`.
+Packs normal/Test/template vérifiés dans `sanctuary-beta/build/`.
+
+## beta.131 — émissifs indépendants et précision étendue
+
+Bloom, émissifs et highlight ON initialement. Couper le halo ou régler son
+intensité à zéro garde les inclusions lumineuses. Précisions 64/128 ajoutées,
+défaut 16 conservé. [Contrat et vérifications](shader-beta131.md).
+[Release beta.131](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.131)
+publiée ; canal `efb18c274d95d988a9566b8c52751469f002cdda`. Deux synchronisations isolées,
+puis deux dans la même instance Sanctuary Beta réussies. Les 923 fichiers
+personnels suivis sont conservés, préférences et sauvegardes comprises.
+Aucun monde personnel ouvert ; sauvegarde `sanctuary-backups/before-beta.131/`.
+Archives normal/Test/template vérifiées dans `sanctuary-beta/build/`.
+
+## beta.130 — bloom et précision commune
+
+Bloom réglable, masques sélectifs des vingt textures de minerais, précision
+commune aux ombres et au highlight. Réglages initiaux 32/128/16 et Pixel Shadows
+activé ; anciennes préférences conservées. [Contrat et vérifications](shader-beta130.md).
+[Release beta.130](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.130)
+publiée ; canal `68e06353bf880af04c1c72d4e3a159f11f94b619`. Deux synchronisations isolées
+puis deux dans la même instance **Sanctuary Beta** réussies. Les 923 fichiers
+personnels suivis, réglages de shaders compris, gardent leurs hashes. Aucun
+monde personnel ouvert ; sauvegarde préalable `sanctuary-backups/before-beta.130/`.
+Packs normal/Test et template vérifiés et copiés dans `sanctuary-beta/build/`.
+
+## beta.129 — reflets CTM et portées 16–256 blocs
+
+Reflets connectés entre tous les matériaux coplanaires, portée indépendante,
+ombres à 128/256 blocs, intensité rétablie à midi et correction du réalignement
+cyclique de la grille lumineuse. [Contrat et vérifications](shader-beta129.md).
+[Release beta.129](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.129)
+publiée ; canal `2eaa0130a4cd475c598beefdab40f48fc8681ab7`. Deux synchronisations isolées
+puis deux dans la même instance **Sanctuary Beta** réussies. Les 923 fichiers
+personnels suivis, réglages de shaders compris, sont conservés. Aucun monde
+personnel ouvert ; copie préalable dans `sanctuary-backups/before-beta.129/`.
+Packs normal/Test et template copiés et vérifiés dans `sanctuary-beta/build/`.
+
+## beta.128 — stabilité des ombres, lune et feuillage
+
+Ombres des blocs nettes et stabilisées, atténuation à midi, lune légère et
+feuillage nuancé selon son épaisseur. [Contrat et vérifications](shader-beta128.md).
+[Release beta.128](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.128)
+publiée ; canal `eba01726ee132a6e548d129fa7ee04f24c880917`. Deux synchronisations isolées
+puis deux dans la même instance **Sanctuary Beta** réussies. Les 923 fichiers
+personnels suivis, réglages de shaders compris, sont conservés. Aucun monde
+personnel ouvert ; copie préalable dans `sanctuary-backups/before-beta.128/`.
+Packs normal/Test et template copiés et vérifiés dans `sanctuary-beta/build/`.
+
+## beta.127 — shader et ombres pixélisées
+
+Ombres solaires optionnelles intégrées à Sanctuary · Vanilla Light, avec finesse
+et portée réglables. Socle beta.126 conservé. [Contrat et vérifications](shader-beta127.md).
+[Release beta.127](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.127)
+publiée ; canal `7fd24a43e01ee497a23311e3c78e1dd3dddd877a`. Deux synchronisations
+isolées puis deux dans la même instance **Sanctuary Beta** réussies.
+Les 923 fichiers personnels suivis, réglages de shaders compris, sont conservés.
+Aucun monde personnel ouvert ; copie préalable dans `sanctuary-backups/before-beta.127/`.
+Packs normal/Test et template copiés et vérifiés dans `sanctuary-beta/build/`.
+
+## beta.126 — gemmes, argile et découvertes
+
+Rubis et saphir, nouvelles textures d'items, argile conservant les couleurs
+originales et commandes de découverte communes aux recettes et catalogues.
+[Contrat et vérifications](gems-beta126.md).
+[Release beta.126](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.126)
+publiée ; canal `31749b95d21ce5bced6b9e5759499da6f8a67e6e`. Deux synchronisations
+isolées puis deux dans la même instance **Sanctuary Beta** réussies.
+Les 923 fichiers personnels et réglages suivis sont inchangé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/`.
+
+## beta.125 — placement, éclats et animaux sculptés
+
+Coins et trois hauteurs, particules de voxels et espèces découvertes au Clay
+Workshop. [Contrat et vérifications](sculpture-placement-beta125.md).
+[Release beta.125](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.125)
+publiée ; canal `47eb833911a96eef0b13805dafe65b2ab7b95c87`. Deux
+synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussies. Les 923 fichiers personnels et réglages suivis sont inchangés ;
+sauvegardes restées fermées. Copie préalable dans
+`sanctuary-backups/before-beta.125/`. Packs normal/Test et template copiés
+et vérifiés dans le dossier habituel `sanctuary-beta/build/`.
+
+## beta.124 — une boîte par sculpture
+
+Une boîte ajustée commune à la sélection et aux collisions ; détails physiques
+simplifiés, orientation/ancrage et éclairage conservés.
+[Contrat et vérifications](sculpture-bounds-beta124.md).
+[Release beta.124](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.124)
+publiée ; canal `67ebcc7d07f8b75e8988f6099e3d6e5704f123fb`. Deux
+synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussies. Les 923 fichiers personnels et réglages suivis sont inchangés ;
+sauvegardes restées fermées. Copie préalable des fichiers remplacés dans
+`sanctuary-backups/before-beta.124/`. Packs normal/Test et template également
+copiés et vérifiés dans le dossier habituel `sanctuary-beta/build/`.
+
+## beta.123 — clé dorée et clé de Steve
+
+La clé dorée se limite aux orientations cohérentes ; la clé de Steve reprend
+les états et textures libres, utilisables aussi en survie dès sa récupération.
+[Contrat et vérifications](wrench-safety-beta123.md).
+[Release beta.123](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.123)
+publiée ; canal `f988d01b901f2d3eda0b4ab47a48540dc627d1b5`. Deux
+synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussies. Les 923 fichiers personnels et réglages suivis sont inchangés ;
+sauvegardes restées fermées. Copie préalable des fichiers remplacés dans
+`sanctuary-backups/before-beta.123/`.
+
+## beta.122 — formes et lumière des sculptures
+
+Sélection et collisions sur les voxels réels ; suppression de l'occlusion cubique.
+[Contrat et vérifications](sculpture-shape-light-beta122.md).
+[Release beta.122](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.122)
+publiée ; canal `3d340bea0093b709c6018624795a1b3ca557b72d`. Deux
+synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussies. Les 923 fichiers personnels et réglages suivis sont inchangés ;
+sauvegardes restées fermées. Copie préalable des fichiers remplacés dans
+`sanctuary-backups/before-beta.122/`.
+
+## beta.121 — texture de clé et pack personnel
+
+PNG du créateur et copie complète modifiable depuis l'écran des packs.
+[Contrat et vérifications](resourcepack-template-beta121.md).
+[Release beta.121](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.121)
+publiée ; canal `e3e6572da9288fbbcfa36bf6b7dd3aa0d1c54f5e`. Deux
+synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussies. Les 923 fichiers personnels et réglages suivis sont inchangés ;
+sauvegardes restées fermées. Copie préalable des fichiers remplacés dans
+`sanctuary-backups/before-beta.121/`. Le template personnel est créé par le
+joueur, jamais géré ou réécrit par packwiz.
+
+## beta.120 — clé dorée et états de blocs
+
+Gestes du debug stick, rotation des textures et assemblages prioritaires.
+[Contrat et vérifications](golden-wrench-beta120.md).
+[Release beta.120](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.120)
+publiée ; canal `e8060764a444a58b0a17318a3821dfeb1a0c33c6`. Deux
+synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussies. Les 923 fichiers personnels et réglages suivis sont inchangés ;
+sauvegardes restées fermées. Copie préalable des fichiers remplacés dans
+`sanctuary-backups/before-beta.120/`.
+
+## beta.119 — pose centrée des sculptures
+
+Centre accessible au point visé, bords conservés et grille entière de 1/16.
+[Contrat et vérifications](sculpture-center-beta119.md).
+[Release beta.119](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.119)
+publiée ; canal `5e823af7807f524f6394acad402fe62328c7e4ab`. Deux
+synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussies. Les 923 fichiers personnels et réglages suivis sont inchangés ;
+sauvegardes restées fermées. Copie préalable des fichiers remplacés dans
+`sanctuary-backups/before-beta.119/`.
+
+## beta.118 — murets en briques colorées
+
+Seize murets natifs, recettes, tailleur, eau et série créative par couleurs.
+[Contrat et vérifications](colored-brick-walls-beta118.md).
+[Release beta.118](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.118)
+publiée ; canal `e6bab433bea9528f67d39af0d6c7bcb6443e4817`. Deux
+synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussies. Les 923 fichiers personnels et réglages suivis sont inchangés ;
+sauvegardes restées fermées. Copie préalable des fichiers remplacés dans
+`sanctuary-backups/before-beta.118/`.
+
+## beta.117 — grain des textures et sculptures en chapeau
+
+Échantillonnage des pixels de plusieurs textures, grain stable même sur un
+modèle uni et conservation des données du chapeau.
+[Contrat et vérifications](sculpture-texture-grain-beta117.md).
+[Release beta.117](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.117)
+publiée ; canal `a5b75a70f86e42afb8e06ba4daa9880d61c6373e`. Deux
+synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussies. Les 923 fichiers personnels et réglages suivis sont inchangés ;
+sauvegardes restées fermées. Copie préalable des fichiers remplacés dans
+`sanctuary-backups/before-beta.117/`.
+
+## beta.116 — palettes de sculpture et Fourneau
+
+Le Clay Workshop utilise les nuances des textures de blocs ; le Fourneau
+corrige les décalages de cases et explique la chauffe.
+[Contrat et vérifications](sculpture-materials-beta116.md).
+[Release beta.116](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.116)
+publiée ; canal `c741870160f8a21f0a9793f20f0e624ebdbacdb6`. Deux
+synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussies. Les 923 fichiers personnels et réglages suivis sont inchangés ;
+sauvegardes restées fermées. Copie préalable des fichiers remplacés dans
+`sanctuary-backups/before-beta.116/`.
+
 ## beta.110 — version commune
 
 Clay Workshop, Statuaire et import GLB intégrés aux œufs et à la neige saisonnière.

docs/palais-originel-iss-beta173.md

@@ -0,0 +1,258 @@
+# Palais originel, verticalité et International Sanctuary Station
+
+> **Statut au 29 septembre 2026 : concept historique.** Le créateur abandonne
+> le palais souterrain, ses accès et les raccordements au palais. Le
+> [fil rouge courant](storyquest-fil-rouge.md) remplace ces choix d'implantation.
+> Le texte ci-dessous conserve la discussion du 28 septembre et ne constitue
+> plus une consigne de construction du palais. Les pistes ISS, chenil et
+> ordinateurs restent ouvertes indépendamment de ce bâtiment. Aucun code ni
+> monde de laboratoire n'est supprimé par ce changement documentaire.
+
+**Discussion du 28 septembre 2026 — conception, sans code.** Précisions du
+créateur après le [cadrage Storyquest](storyquest-beta173.md), sur la même
+branche `codex/storyquest-beta173`, issue de beta.172. Les formes et intentions
+retenues sont distinguées des mécaniques encore hésitantes. Aucun monde,
+paramètre de génération, familier ou format de sauvegarde n'est modifié ici.
+
+**Premier lot décidé ensuite :** un palais par seed, huit ancres extérieures
+et huit demandes de matériaux distincts. Le bloc originel garde l'illustration
+fournie ; chacune des huit gemmes se colore indépendamment. Le
+[contrat de prototype](palais-prototype-beta173.md) décrit ce qui est réellement
+implémenté dans le laboratoire et les limites de l'intégration au monde.
+
+## Le secret devient un lieu commun à habiter
+
+Le secret sous le spawn prend la forme d'un **palais sobre, haut sous plafond,
+à huit coins**. Après discussion du niveau zéro et du vortex, le créateur
+précise : **adapter la hauteur au terrain**. Le palais garde son centre en
+**`x=0, z=0`**, avec une **altitude déterminée par le relief**. La salle n'est
+donc plus contrainte à Y=0.
+
+**Le bloc originel suit le palais**, confirmation explicite du créateur. Sa
+position devient `(x=0, y=altitude adaptée, z=0)` : l'origine horizontale reste
+fixe, l'altitude accompagne le lieu. L'idée initiale d'un bloc exactement en
+`(0, 0, 0)` est remplacée ; aucun bloc séparé à Y=0 ni liaison vers ce niveau
+n'est requis. Sa position précise dans le volume de la salle reste à dessiner.
+
+Ce palais représente une **cartographie intérieure de Sanctuary Island**,
+puis l'expédition et l'aventure de ses habitants. Le complexe est léger, assez
+vide pour que les joueurs le personnalisent : une page blanche avec une
+architecture reconnaissable. Sa richesse vient progressivement de leur partie.
+La palette, les dimensions, les proportions et le mobilier initial restent à
+dessiner. « Palais » n'implique ni dorures ni décor luxueux.
+
+Le lieu est souterrain par son implantation et ses accès. Si le terrain à
+l'origine est trop mince ou absent, **le palais ressort sous l'île et reste
+visible au-dessus du vide**. Le créateur souhaite un endroit lumineux,
+repérable depuis l'extérieur, notamment la nuit. Le vortex de nuages doit
+participer à la vue en dessous.
+
+La fonction recherchée est une **base d'opérations pour les expéditions** :
+comprendre les destinations, voir les matériaux nécessaires, préparer le départ
+et conserver la mémoire de ce qui a été accompli. Le rôle exact des machines
+et la mécanique d'ouverture des territoires ne sont pas encore décidés.
+
+### Proposition spatiale à discuter
+
+Faire correspondre les huit secteurs de la salle aux huit directions autour
+de l'île, avec une orientation lisible depuis le bloc originel. Chaque secteur
+pourrait recevoir un indice découvert, l'état d'une liaison, les besoins de sa
+prochaine expédition et les souvenirs rapportés. Les joueurs complètent
+eux-mêmes l'aménagement avec cartes, cadres, bannières, trophées et constructions.
+Le palais devient une carte que l'on parcourt à pied.
+
+Les huit coins de l'île désignent ici des secteurs à définir sur son contour ;
+ils n'imposent pas une île géométriquement octogonale. Le rapprochement entre
+coins du palais, lieux périphériques et liaisons est une proposition cohérente
+avec la demande, pas encore un plan d'implantation validé.
+
+Il faut encore décider ce que les joueurs peuvent déplacer ou casser, et
+comment ils réparent une installation devenue inutilisable. La personnalisation
+ne vaut pas décision de protéger tout le palais. L'ancien contrat de conception
+permet aussi de reconstruire une installation d'expansion ailleurs : préciser
+ce qui relève du bloc originel unique et ce qui reste reproductible.
+
+## Les accès font jouer la profondeur
+
+Le créateur envisage plusieurs accès complémentaires, sans choisir encore
+leur nombre ni leur disposition :
+
+| Accès évoqué | Expérience recherchée | Point à dessiner ou vérifier |
+| --- | --- | --- |
+| Ascenseur aquatique | Monter et descendre rapidement, avec eau et bulles | Les algues et la « terre des abîmes » sont les termes de la discussion ; le bloc de propulsion et le montage exact restent à préciser |
+| Puits de chute avec réception dans l'eau | Se laisser tomber vers le palais central | Continuité du bassin, visibilité de la réception, sortie et absence de fuite dans le vide |
+| Escaliers | Accès progressif qui fait découvrir les volumes souterrains | Arrivée dans la salle, paliers, raccourcis et lien avec les galeries |
+| Ouvertures verticales | Apercevoir en contrebas un sol d'eau et oser descendre | Lecture du trajet, réception réelle, retour et espace pour les compagnons |
+
+Proposition : une première descente lente qui révèle le palais, puis un trajet
+rapide pour les usages quotidiens. Le choix entre escalier, chute et ascenseur
+peut exprimer cette différence sans obliger à construire les trois dès le début.
+
+### Implantation retenue : une hauteur adaptée au terrain
+
+Le preset actuel emploie `sanctuary:sanctuary_640`, avec **`min_y: 0`** et
+**`height: 640`**. Le vortex a **`HEIGHT=0`**, avec une épaisseur de quatre blocs
+dans son rendu. Ce sont des valeurs lues dans les sources beta.172, pas des
+mesures de terrain d'une graine particulière :
+
+- [Preset Sanctuary](../mods/sanctuary/src/main/resources/data/sanctuary/worldgen/world_preset/sanctuary.json).
+- [Type de dimension](../mods/sanctuary/src/main/resources/data/sanctuary/dimension_type/sanctuary_640.json).
+- [Hauteur du vortex](../mods/sanctuary/src/main/java/fr/koka/sanctuary/sky/VortexClouds.java).
+- [Épaisseur et rendu](../mods/sanctuary/src/main/java/fr/koka/sanctuary/client/VortexCloudRenderer.java).
+
+Ces contraintes ont conduit le créateur à choisir une hauteur adaptée au terrain.
+La proposition précédente d'imposer la salle juste au-dessus du bloc à Y=0
+est remplacée par cette décision. **Le vortex peut conserver sa hauteur actuelle** ;
+aucun déplacement des nuages ni changement de limite du monde n'est nécessaire
+par principe. Leur séparation visuelle devra être vérifiée sur la coupe choisie.
+
+Proposition de placement : examiner le relief sous le centre de l'île et sur
+l'emprise du palais, puis choisir un niveau permettant la grande hauteur sous
+plafond et les accès. La salle peut traverser l'enveloppe inférieure du terrain
+et laisser une façade lumineuse visible dans le vide. Il ne faut ni l'enterrer
+entièrement à tout prix, ni aplatir toute l'île pour l'accueillir.
+
+Avant le code, fixer la marge au-dessus du vortex, la couverture rocheuse
+souhaitée, le volume de la salle et la solution lorsque le relief ne fournit
+pas assez d'épaisseur. Prévoir planchers, bassins et fondations dans les limites
+constructibles. La même graine et la même version de génération doivent choisir
+la même implantation. Ces règles détaillées restent à dessiner puis à tester
+sur de nouveaux mondes ; aucune partie existante n'est repositionnée.
+
+## Les huit objets et la Sanctuary Key restent ouverts
+
+Le créateur envisage des **collectibles répartis dans les huit secteurs de
+l'île**, permettant d'activer de nouvelles expéditions, la génération de
+nouvelles îles et un nouveau point d'intérêt à découvrir. Il hésite sur le
+fait de placer ces objets derrière des défis et sur la forme d'une clé appelée
+provisoirement **Sanctuary Key**. Aucun identifiant d'objet n'est fixé.
+
+| Possibilité | Ce qu'elle favorise | Limite à discuter |
+| --- | --- | --- |
+| Collectible trouvé par exploration | Curiosité, lecture du paysage et surprises | Le défi peut se résumer à trouver le bon endroit |
+| Clé obtenue après une épreuve | Accomplissement clair et aventures différentes | Huit épreuves identiques donneraient une progression répétitive |
+| Découverte puis préparation de l'expédition | Exploreurs, constructeurs et producteurs ont chacun un rôle | Il faut rendre les besoins compréhensibles et éviter les attentes sans activité |
+
+**Proposition recommandée pour la discussion :** découvrir dans un secteur un
+objet ou un signe lié à une liaison, puis préparer l'expédition au palais. Le
+défi peut varier selon le lieu : combat, exploration, mécanisme, construction
+ou coopération. Cette proposition ne décide ni d'une clé pour chaque direction,
+ni d'un objet consommé, ni de l'obligation de réunir les huit avant de partir.
+
+Avant le premier essai, choisir ce que l'objet autorise, qui peut l'apporter,
+où les matériaux sont réellement déposés et qui lance le départ. Prévoir le
+cas d'un objet perdu et celui d'un nouveau joueur arrivé après l'ouverture.
+La preuve durable d'ouverture appartient au serveur ; le trophée exposé au
+palais peut raconter cette ouverture sans être la seule preuve qui la conserve.
+
+Les huit collectibles ne remplacent pas automatiquement les **sept boules de
+cristal** de la vision historique. Leur relation éventuelle est à discuter.
+
+## La montée vers l'ISS
+
+Le créateur souhaite développer la verticalité au-dessus de l'île par des
+structures en hauteur, jusqu'à l'**ISS — International Sanctuary Station**.
+Cette station métallique, inspirée visuellement de l'ISS, constitue une trace
+laissée par un ancien joueur. Son identité n'est pas encore choisie.
+
+Elle comprendrait une **carte de l'île avec des cadres d'objets posés à
+l'horizontale**. La taille, l'altitude, l'accès et la mise à jour de cette carte
+restent à définir. Il faut lui donner une fonction particulière, reliée à un
+système ou une quête. Trouver la station pour obtenir un familier particulier
+est une piste du créateur, pas une récompense déjà arrêtée.
+
+```mermaid
+flowchart TB
+    ISS[ISS : trace d'un ancien joueur et fonction à définir]
+    HAUT[Structures en hauteur : itinéraire à concevoir]
+    ILE[Surface : spawn, habitants et huit secteurs]
+    ACCES[Descente : escaliers, eau ou puits]
+    PALAIS[Palais octogonal : préparer et raconter les expéditions]
+    ORIGINE[Bloc originel : suit le palais, x=0 et z=0]
+    ISS --- HAUT --- ILE --- ACCES --- PALAIS --- ORIGINE
+```
+
+Schéma d'intention sans échelle : aucun ordre de déblocage ni palier d'altitude
+obligatoire n'est décidé. Le palais s'adapte au terrain ; le vortex est à Y=0.
+Le nœud du bloc indique son lien avec le palais, pas un étage nécessairement séparé.
+
+Proposition : faire du palais le lieu où l'on **prépare et engage** l'expédition,
+et de l'ISS un lieu où l'on **observe et repère** des phénomènes célestes. Une
+fonction de reconnaissance donnerait une raison d'y retourner après avoir
+trouvé le familier. Elle doit être distinguée du rôle de l'observatoire déjà
+envisagé sur l'île ; ne pas créer trois lieux qui donnent la même information.
+
+L'ISS pourrait suggérer une destination ou un événement aérien sans révéler
+tous les secrets. La carte pourrait être le relevé ancien du précédent joueur
+ou un outil actualisé : ce choix change ce qu'elle raconte. Prévoir l'accès des
+nouveaux arrivants et le retour au sol avant de choisir une récompense rare.
+
+## Chenil et incubateurs de familiers
+
+Piste du créateur : un **vrai bloc** reçoit le familier pour lui faire gagner
+de l'XP. **Deux yeux apparaissent sur le bloc lorsqu'il est occupé.** Le dispositif
+peut devenir un chenil ou un incubateur ; son nom et sa place dans le palais
+restent ouverts. Des **multiblocs de tailles différentes** pourraient accueillir
+des familiers miniatures ou colossaux. Les dimensions ne sont pas fixées.
+
+Il faut distinguer cette idée de l'incubation du 25 septembre : celle-ci faisait
+fructifier une réserve avec les déplacements, poses et casses du joueur. Le
+nouvel incubateur est un lieu physique où l'on dépose le compagnon. Ils peuvent
+se remplacer ou se compléter ; aucune double croissance automatique n'est décidée.
+
+Le point de conception principal est de garder un intérêt à emmener son
+familier. **Proposition à éprouver :** un entraînement limité au chenil, soutenu
+éventuellement par de la nourriture appréciée, tandis que l'aventure développe
+le lien et l'expérience autrement. Plafond, nourriture, vitesse et arrêt hors
+ligne restent des propositions, sans règle chiffrée ni rendement acquis.
+
+Avant le code, préciser : XP propre du familier ou réserve récupérable par le
+joueur ; propriétaire et personnes autorisées à le retirer ; croissance selon
+temps simulé ou réel ; comportement hors ligne et hors chunks chargés ; sort
+du pensionnaire à la casse ou dissociation. Le même familier ne doit pas exister
+simultanément dans le chenil et sur la tête. Les deux yeux signalent l'occupation,
+mais l'identité du pensionnaire doit aussi pouvoir être reconnue.
+
+Si la forme multibloc est retenue, la rapprocher du système d'assemblage
+volontaire existant. Ne pas imposer automatiquement une cage colossale à tout
+familier de grande apparence avant d'avoir choisi la règle de taille.
+
+## Ordinateurs : commencer par la tâche à accomplir
+
+Le créateur envisage **assembleur, terminal et écran**, en référence à un mod
+d'ordinateurs non identifié avec certitude. Aucun choix de dépendance n'est
+effectué. Le [cahier d'installation d'expansion](structures-conception.md#ordinateurs-et-installation-dexpansion)
+évoque déjà assembleur, contrôleur, terminal, dépôt et ancre, mais ces rôles
+restent conceptuels. Le terminal de stockage est encore une autre fonction.
+
+Le premier besoin est concret : **choisir une expédition, voir les matériaux
+nécessaires, constater ce qui est déposé et comprendre ce qui manque**. On peut
+dessiner ce parcours dans une alcôve du palais avant de décider de l'ordinateur.
+
+Proposition de progression : une installation locale compréhensible à la main,
+puis un écran de suivi partagé, puis éventuellement automatisation et programmation.
+Un dépôt physique possède les matériaux ; un écran les montre ; le système
+serveur valide l'expédition. Le rôle de l'assembleur doit être choisi avant
+d'ajouter un bloc dont on ne sait pas ce qu'il fabrique.
+
+Cette approche conserve de la place pour les computers sans les rendre
+obligatoires par défaut pour découvrir le palais. Si un mod externe est choisi,
+son identité et sa compatibilité Minecraft 26.3 seront vérifiées dans le ticket
+d'intégration ; aucun nom n'est déduit de la description seule.
+
+## Prochain résultat de conception proposé
+
+Dessiner **un plan et une coupe du palais**, avec huit secteurs, bloc originel,
+altitude adaptée au terrain, hauteur de salle, partie extérieure, accès et nuages.
+Placer seulement les
+emplacements fonctionnels nécessaires pour essayer **une** expédition :
+destination, éventuel objet de déblocage et besoins matériels. Garder les
+autres espaces disponibles pour les joueurs et les évolutions suivantes.
+
+L'ISS et le chenil peuvent alors avoir une fiche propre, liée à cette coupe
+verticale. Ils ne deviennent pas des prérequis techniques à la première salle.
+Les trois décisions suivantes sont : **moment de découverte du palais**,
+**premier geste d'expédition** et **ce que l'ISS permet de faire après sa visite**.
+
+Validation documentaire : références locales et diff contrôlés. Aucun build
+ou essai de jeu relancé ; aucune fonctionnalité décrite ici n'est implémentée.

docs/palais-prototype-beta173.md

@@ -0,0 +1,150 @@
+# beta.173 — palais procédural et bloc originel
+
+> **Statut au 29 septembre 2026 : prototype technique conservé, architecture
+> abandonnée pour la suite.** Le palais souterrain, ses accès et les
+> raccordements au palais sortent de la conception. Le
+> [fil rouge courant](storyquest-fil-rouge.md) prépare des lieux indépendants.
+> Cette fiche décrit fidèlement le laboratoire livré et ses essais ; elle
+> n'annonce plus l'intégration du palais à Sanctuary Island.
+
+Ticket d'implémentation ouvert le 28 septembre 2026, branche
+`codex/storyquest-beta173`, base beta.172. Première scène jouable issue du
+[palais originel](palais-originel-iss-beta173.md). Livraison locale vérifiée.
+
+## Contrat avant implémentation
+
+Le palais est construit par un générateur versionné, avec une graine explicite.
+Le volume octogonal, la hauteur, les baies, la toiture et le dessin du sol
+peuvent varier. Une même graine/version reproduit le même plan. Il conserve
+une salle haute et sobre, huit secteurs ouverts, un escalier et un puits d'eau.
+La première scène est centrée en X=0, Z=0 et surélevée dans un monde plat neuf.
+Chaque monde de laboratoire contient **un seul palais, déterminé par sa seed**.
+Pour comparer une autre architecture, créer un autre monde neuf avec une autre seed.
+
+L'intégration au terrain de Sanctuary Island était envisagée lors de ce lot ;
+elle est abandonnée le 29 septembre. Ce lot n'appelle pas le générateur dans
+les mondes de production. Il ne crée ni
+expansion, ni quête, ni ISS, ni ordinateur, ni récompense.
+
+Le nouveau bloc `sanctuary:origin_block` reprend les propriétés de la bedrock
+et l'image fournie par le créateur, conservée sans retouche dans
+`mods/sanctuary/src/main/art/origin-logo.png`. Son rendu est dérivé de manière
+déterministe à la construction des ressources :
+
+- éteint : image sombre et désaturée, aucune lumière émise ;
+- allumé sans relais : image en niveaux de gris, centre blanc, lumière 15 ;
+- allumé avec des relais : chaque relais rend sa couleur à la gemme associée ;
+  les autres restent grises et le centre reste blanc.
+
+Huit bits indépendants représentent les huit relais, pas un simple compteur.
+L'ordre des activations est libre. L'extinction masque les couleurs sans effacer
+l'état des relais. Ces états sont des propriétés de bloc natives, sauvegardées
+dans les nouveaux chunks ; aucun ancien format n'est converti.
+
+Huit blocs `sanctuary:expansion_anchor` sont disposés à l'extérieur, dans les
+huit directions, sur des plateformes reliées à pied au palais. Chacun accepte
+un matériau distinct, décision du créateur du 28 septembre. Clic droit avec la
+quantité en main : dépôt entier, consommé côté serveur, ancre allumée et bit
+associé du bloc originel activé. Un dépôt insuffisant ou incorrect reste intact ;
+une ancre déjà allumée ne consomme plus. Les demandes sont communes à la partie,
+sans crédit individuel ni dépôt partiel dans ce premier lot.
+
+| Direction / gemme | Demande provisoire |
+| --- | --- |
+| Nord / bleu | 32 pierres |
+| Nord-est / vert clair | 16 bûches de chêne |
+| Est / vert | 16 blés |
+| Sud-est / orange | 4 lingots d'or |
+| Sud / rouge | 16 poudres de redstone |
+| Sud-ouest / rose-violet | 8 éclats d'améthyste |
+| Ouest / jaune | 8 lingots de fer |
+| Nord-ouest / menthe | 16 verres |
+
+Le bloc central s'allume/s'éteint par clic droit dans ce laboratoire. Il faut
+l'allumer avant les dépôts ; l'éteindre conserve les ancres et leurs bits.
+Les coûts servent au prototype et ne constituent pas l'équilibrage final.
+Ces ancres ne déclenchent encore aucune génération d'expansion.
+
+## Monde et écritures autorisées
+
+Le module facultatif Sanctuary Test, le dossier dédié `palace-flat-173` et le
+commutateur `sanctuary.palaceLab=true` conditionnent le laboratoire. La préparation
+refuse toute autre partie. Une emprise doit être entièrement libre avant la
+première écriture. Un palais prêt est rechargé tel quel ; il n'existe pas de
+commande de régénération. Les écritures sont réparties sur plusieurs ticks serveur.
+
+Un journal indépendant `palace-lab-173.json`, schéma 1 / génération 1, enregistre
+graine, altitude et phase du palais. Les états des blocs restent dans les chunks.
+Une génération interrompue est conservée comme incomplète ; utiliser un nouveau
+dossier de laboratoire. Pas de nettoyage ou de reprise destructive.
+Une version inconnue ou un journal invalide bloque la préparation et préserve
+le fichier. Le retrait de cette version après création de ces nouveaux blocs
+n'est pas une conversion prise en charge ; conserver le monde de développement.
+
+## Visiter et comparer
+
+Depuis cette branche, avec Java 25 :
+
+```sh
+./gradlew :sanctuary-test:exportDuoLaunch
+python3 scripts/palace_lab.py prepare --seed 173
+python3 scripts/palace_lab.py server --seed 173
+# Dans un second terminal :
+python3 scripts/palace_lab.py client --seed 173
+```
+
+Le client utilise Vulkan. Le serveur écoute uniquement sur `127.0.0.1:25579`.
+Créatif pour visiter et aménager ; `/palais materiaux` donne les huit demandes,
+`/palais retour` ramène dans la salle. Les messages sont traduits FR/EN.
+Une autre seed utilise un autre dossier sous `build/palace-173/` ; arrêter le
+serveur précédent avant de lancer l'autre. Le lanceur préserve les fichiers
+existants et refuse une modification du nom de monde, de la seed ou du réseau.
+
+Le palais est à Y=96 dans ce laboratoire, au-dessus du terrain plat. Le plan
+accepte une altitude arbitraire. Le placement sous Sanctuary Island à une
+altitude calculée n'a pas été intégré et n'est plus prévu ; la géographie des
+huit ancres est à reprendre indépendamment de ce palais.
+
+## Vérifications
+
+- Les quatre nouveaux GameTests passent (cinq tests requis avec le témoin du
+  banc). Onze graines incluent `0`, `173`, des voisins et les extrêmes 64 bits :
+  plan entier reproductible, variation d'architecture, huit accès praticables
+  et toutes les écritures contenues dans l'emprise. Une emprise occupée est
+  refusée sans écriture. Dépôts faux, insuffisants ou répétés conservés ; les
+  huit dépôts valides activent les bits attendus dans un ordre non séquentiel.
+- Les 512 combinaisons d'allumage et de relais survivent au codec natif de
+  sauvegarde. Lumière 0/15 et conservation des bits à l'extinction vérifiées.
+- Client Minecraft **26.3 / Vulkan / Apple M1**, scénario
+  `Palace173ClientChecks` réussi : extérieur, intérieur, éteint, monochrome,
+  trois gemmes et huit gemmes. Six captures examinées dans
+  `build/palace-validation/screenshots/`. Synchronisation serveur/client du
+  masque de gemmes vérifiée. Le premier lancement avait omis le profil Test ;
+  le scénario passe avec `-PsanctuaryQuickTests=true`.
+- Image source strictement identique au PNG fourni (SHA-256
+  `33adb8f689d55b7bf8d0824b02942ea3823f128b27fab458713ab9582061a1a0`).
+  Compilation Python, JSON FR/EN et préparation répétée du laboratoire : les
+  cinq fichiers de configuration restent identiques.
+
+Commandes ciblées :
+
+```sh
+./gradlew :sanctuary:runGameTest :sanctuary-test:compileJava -PsanctuaryFocusedTests=palace173 -PsanctuaryAtlasOnly=true
+./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true -PsanctuaryPalace173ClientTests=true -PsanctuaryQuickTests=true -PsanctuaryClientGraphicsBackend=vulkan
+```
+
+- `./gradlew check build assemblePack assembleTestPack :sanctuary-test:exportDuoLaunch`
+  **réussi**, 265/265 GameTests, contrôles du pack et autres contrôles du dépôt
+  réussis (12 min 35 s). Profils packwiz normal et Test assemblés localement.
+- JAR vérifié : beta.173, générateur présent, 512 états du bloc et 257 textures.
+  SHA-256 : `fa1f92f1a84b5f863e5f323ab0afe63e01acbd08c06181e5f636ab5b372886f9`.
+- Serveur dédié réellement démarré sur loopback, journal `ready`, puis reprise
+  du même monde. Allumage avec masque `73` et un bloc d'aménagement témoin
+  conservés après arrêt/reprise (`PALACE173_GEMS_RELOAD_PASS` et
+  `PALACE173_CUSTOMIZATION_RELOAD_PASS`). Le témoin est ensuite retiré et le
+  bloc éteint pour la première visite ; serveur arrêté proprement. Le lanceur
+  accepte aussi le `sanctuary_test\:flat` réécrit automatiquement par Minecraft
+  dans les propriétés Java.
+
+Les journaux restent ignorés dans `build/palace-validation/`. Les artefacts
+restent locaux ; aucun canal public ni profil Prism n'a été mis à jour.

docs/pause-calendar-beta164.md

@@ -0,0 +1,25 @@
+# beta.164 — calendrier compact et intendance alignée
+
+Calendrier à la largeur de la navigation : jour agrandi et heure sur la première
+ligne, mois et année ensemble dessous. Le titre serveur est aligné à gauche
+et couvre la carte ainsi que les panneaux Gazette/Tableau.
+
+Interface cliente uniquement. Aucun changement de stockage ou de monde.
+
+Vérification client Vulkan réussie : FR/EN aux échelles GUI 2, 3 et 4.
+Le test contrôle la largeur du calendrier, l’heure dans son libellé accessible,
+les limites de l’intendance et les interactions communautaires existantes.
+Captures conservées dans `build/qa-beta164/` et journal dans
+`build/beta164-client-retry.log`. Inspection visuelle FR GUI 4 et EN GUI 2 effectuée.
+Le premier test a détecté que StringWidget redimensionnait le calendrier lors
+du changement de texte ; la largeur de navigation est maintenant réappliquée.
+
+`check build assemblePack --continue` exécuté : les mêmes 23 GameTests qu’en
+beta.163 échouent, aucun nouvel échec (comparaison enregistrée dans
+`build/session164-server-failures.json`). La suite complète reste en échec.
+L’assemblage séparé `build assemblePack :sanctuary-test:exportDuoLaunch
+-x :sanctuary:check` réussit après ce contrôle.
+
+Anciennes archives conservées ; aucune publication distante.
+JAR : `mods/sanctuary/build/libs/sanctuary-beta.164.jar`.
+SHA-256 : `5bdfb097004a7932a075fbce9013556266f76ddd491ca21a24e12609c8600e53`.

docs/pause-frame-beta163.md

@@ -0,0 +1,27 @@
+# beta.163 — cadre du menu pause
+
+Retour de séance : Découverte/Progression séparés de Habitant/Factions/Combat,
+bouton Monde retiré, séparateurs natifs de Progression, reprise centrée dans le
+footer, calendrier à gauche, message serveur au centre et horloge à droite.
+
+Interface cliente uniquement, sans migration ni modification de règles ou de
+mondes. « Options du monde » reste dans les réglages en bas à gauche ; seul le
+raccourci de navigation Monde disparaît. La carte centrale reste disponible.
+
+Vérifications :
+- Test client natif Vulkan réussi : FR/EN aux échelles GUI 2, 3 et 4,
+  calendrier, séparation des groupes, limites des widgets et reprise centrée.
+  Captures dans `build/qa-beta163/` ; journal `build/beta163-client-retry.log`.
+- Le scénario communautaire vérifie aussi la scène du tableau et les échanges.
+  Une première exécution a expiré pendant une publication ; le test respecte
+  désormais le délai serveur entre deux écritures.
+- `check build assemblePack --continue` : 23 échecs GameTest, ensemble identique
+  à beta.162, aucun nouvel échec. Les autres tâches ont terminé ; la suite
+  complète reste donc en échec. Comparaison dans `build/session163-server-failures.json`.
+- Assemblage réussi avec `build assemblePack :sanctuary-test:exportDuoLaunch
+  -x :sanctuary:check`, après la vérification complète.
+
+JAR local : `mods/sanctuary/build/libs/sanctuary-beta.163.jar`.
+SHA-256 : `72df10885d1bcb3b623c46bddf361839c23f06dfd543119f91ac5e006a8f961e`.
+Aucune publication distante ; anciens JAR conservés.
+

docs/pause-redesign-beta155.md

@@ -0,0 +1,114 @@
+# PAUSE-155 — une entrée Sanctuary, trois espaces
+
+Branche `codex/pause-redesign-beta155`, livraison locale `beta.155`.
+Suite de [COMMUNITY-154](community-beta154.md).
+
+## Résultat attendu
+
+Remplacer l'ancienne grille du menu pause par trois espaces sans fond ou
+séparateurs imposés à chaque espace :
+
+- En-tête : date locale à gauche, dernier message d'intendance au centre,
+  heure locale à droite. Le message ouvre directement sa publication.
+- Corps : navigation permanente Découverte, Monde, Progression, Habitant,
+  Faction et Batailles à gauche, tous espacés de 4 pixels comme les boutons
+  d’options. Carte personnelle au centre. Gazette au-dessus du tableau d'affichage à droite.
+- Bas de la colonne gauche : Options, Options du monde, puis Sauvegarder et
+  quitter, empilés dans cet ordre et alignés avec les six boutons Sanctuary.
+  Reprendre la partie se trouve seul tout en bas de la colonne centrale,
+  sous la carte. Les actions natives Minecraft sont réutilisées, y compris
+  Déconnexion en multijoueur. À grande échelle d'interface, les six boutons
+  de navigation deviennent plus compacts pour préserver cette séparation.
+
+La Gazette présente des boutons-titres avec la tête de l’auteur dans un carré
+de 20 pixels à gauche, sur la même ligne ; le nom reste disponible au survol. Les demandes prennent la forme de
+cartes encadrées avec aperçu, auteur, catégorie et état. Chaque zone possède
+son propre défilement à la molette et sa barre de défilement. Le bouton +
+ouvre la rédaction, l'en-tête ouvre la liste complète. « Afficher la suite »
+ajoute la page suivante sans quitter le menu ni remettre le défilement à zéro.
+La lecture des publications longues et des conversations utilise le
+conteneur défilant natif existant.
+
+## Périmètre technique
+
+La carte utilise exclusivement les relevés personnels de l'atlas existant,
+sans chargement ou génération de chunks. Elle respecte le déblocage de
+l'atlas et les restrictions de dimension. Un clic ouvre la carte détaillée.
+Le serveur solo transmet les relevés existants pendant la pause, par lots bornés,
+sans observer de nouveaux blocs ni avancer la simulation. La limite de fréquence
+accepte aussi le temps réel lorsque les ticks du monde sont arrêtés.
+La texture et le flux réseau sont libérés en quittant le menu ; les réponses
+tardives ne sont acceptées que par l'écran courant et son jeton.
+
+Les publications utilisent les mêmes opérations paginées du contrat v1,
+en fichier comme en MariaDB. Aucune migration, table ou modification du site.
+L'actualisation des premières pages intervient lorsque leur défilement est en
+haut ; une liste étendue reste stable jusqu'à sa réouverture.
+Les textes d'interface sont disponibles en français et anglais.
+
+La sélection d'un screenshot pour la Gazette reste l'étape suivante.
+Les visages des demandes du tableau restent différés ; ceux de la Gazette
+et des conversations sont présents. Les futures entrées
+économiques ne sont pas des boutons factices.
+
+## 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. Base de développement
+MariaDB 12.3.3, distincte des données personnelles et du site public.
+
+- Essais natifs Vulkan réussis dans les deux modes : fichier et MariaDB.
+  Français et anglais, GUI 2/3/4 à 1280 × 960 pixels (jusqu'à 320 × 240 unités
+  d'interface), contrôles contenus dans l'écran.
+- Six vrais boutons Sanctuary ; espacement uniforme de 4 pixels en haut et
+  en bas ; avatars d’articles alignés à gauche des titres.
+  Défilements indépendants à la molette, ajout de la treizième publication par
+  pagination sans retour en haut, lecture jusqu'au bas des longs articles et
+  demandes, réponse publiée et relue.
+- Options et Options du monde natives, reprise du jeu, ouverture de la carte
+  détaillée puis retour au menu. Carte personnelle reçue en plusieurs lots
+  pendant la pause ; l'horloge de simulation du monde reste immobile.
+- Logs : `build/pause155-client-file.log`, `build/pause155-client-database.log`.
+  Captures : `build/pause155-{file,database}-screenshots/`, aperçu
+  `build/pause155-preview.png`. Les articles et le terrain de ces captures
+  proviennent exclusivement d'un monde de test plat et de données fictives.
+
+`./gradlew check build` a terminé ses 252 GameTests : 229 réussites et les
+23 échecs déjà recensés dans beta.154 (mêmes identifiants, aucun ajout ni
+retrait). La commande échoue donc ; ce n'est pas un contrôle global vert.
+Log : `build/pause155-check-build.log`, comparaison :
+`build/pause155-server-failures.json` / `build/community-server-failures.json`.
+`./gradlew check build assemblePack -x :sanctuary:runGameTest` réussit :
+compilation, contrôles hors GameTests et assemblage. Les derniers ajustements
+visuels de disposition sont ensuite vérifiés par les scénarios client natifs
+et un nouvel assemblage des artefacts, sans réexécuter les 252 GameTests.
+Log : `build/pause155-build-pack.log`.
+Aucun déploiement personnel ni publication du canal packwiz.
+
+Commande des essais natifs :
+
+```sh
+./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true \
+  -PsanctuaryQuickTests=true -PsanctuaryPause155ClientTests=true \
+  -PsanctuaryClientGraphicsBackend=vulkan
+```
+
+Le scénario MariaDB utilise les variables de développement documentées dans
+[COMMUNITY-154](community-beta154.md). Le schéma reste le contrat v1.
+La sélection de screenshots et la validation Windows restent ouvertes.
+
+
+## Artefacts locaux vérifiés
+
+Assemblage final réussi avec `./gradlew build assemblePack -x :sanctuary:check`,
+après réussite des essais natifs de la disposition finale dans les deux modes.
+Export packwiz réussi. ZIP, version Fabric/Minecraft, JAR unique dans le MRpack,
+pilote MariaDB embarqué et absence des classes de test vérifiés. Les 29 fichiers
+shader sont identiques octet pour octet à beta.151. Les anciens JAR et le pack
+beta.154 sont conservés, leurs empreintes vérifiées.
+
+Reçu : `build/pause155-artifacts.json`. Logs : `build/pause155-final-assemble.log`
+et `build/pause155-export.log`.
+
+- `mods/sanctuary/build/libs/sanctuary-beta.155.jar` — SHA-256 `e8ba34ddd2726eb48fcea2b56a6f5a2e0262354553378c5bc25ca6f5061d32dc`.
+- `build/Sanctuary-beta.155.mrpack` — SHA-256 `11be47c07edbb8180b4d6911a1eff7656ba2ce4168d35b96096519a2491e899f`.

docs/pause-resume-beta156.md

@@ -0,0 +1,33 @@
+# PAUSE-156 — reprendre la partie sous la colonne droite
+
+Branche `codex/pause-resume-right-beta156`, livraison locale `beta.156`.
+Suite de [PAUSE-155](pause-redesign-beta155.md).
+
+Le bouton natif Reprendre la partie se trouve en bas à droite, sous la colonne
+Gazette / tableau, avec le même alignement et la même largeur. Il conserve son
+action native et les libellés français / anglais de Minecraft.
+
+La modification concerne uniquement sa géométrie. Les options restent en bas
+à gauche ; les publications, le stockage, la carte et les shaders conservent
+leur fonctionnement de beta.155. Aucune migration ni installation personnelle.
+
+## Vérifications
+
+Le scénario client Vulkan existant passe en français et anglais, GUI 2/3/4 à
+1280 × 960 : alignement du bouton avec la colonne droite, largeur identique,
+absence de chevauchement avec le tableau, reprise effective du jeu. Les
+interactions communautaires du scénario passent également en mode fichier.
+Log : `build/pause156-client.log`, aperçu `build/pause156-preview.png`.
+
+`./gradlew check build assemblePack -x :sanctuary:runGameTest` réussit.
+Export packwiz, intégrité ZIP, versions du mod / pack et contenu du JAR
+embarqué vérifiés. Les shaders sont inchangés et les artefacts beta.155
+conservés avec leurs empreintes. Logs : `build/pause156-build-pack.log`,
+`build/pause156-export.log`, reçu `build/pause156-artifacts.json`.
+La suite serveur complète de beta.155 compte 229 réussites / 252, avec les
+23 échecs historiques. Elle n’est pas relancée pour ce déplacement de bouton.
+
+## Artefacts locaux
+
+- `mods/sanctuary/build/libs/sanctuary-beta.156.jar` — SHA-256 `c325a757cff6063fe3702e755a57a3abc13ad86e071762354a3c449504d51c6f`.
+- `build/Sanctuary-beta.156.mrpack` — SHA-256 `0537273dbfecb071d481f3f22982fbbb9a8e8a75581e38128ded87926ee699d0`.

docs/pbr-close-range-beta147.md

@@ -0,0 +1,82 @@
+# RENDER-147 — PBR proche, lune et portée 256 blocs
+
+Branche `codex/pbr-close-range-beta147`, socle beta.146 `cf9a670`.
+Minecraft 26.3, Java 25 ; dépendances et formats de sauvegarde inchangés.
+
+## Résultat
+
+- Le prépassage des récepteurs PBR comparait encore les profondeurs natives
+  avec un epsilon fixe de 0,0000001. En profondeur inversée, cette marge
+  devenait trop stricte au voisinage de la caméra : de nombreux fragments
+  alternaient entre le rendu natif et le PBR lors de mouvements minuscules.
+- La comparaison utilise maintenant une distance reconstruite avec la marge
+  bornée de 5 mm déjà employée par les passes couleur. La sélection de la
+  surface PBR la plus proche et son test de profondeur EQUAL restent stricts.
+  Aucun décalage du maillage ni fondu supprimant le PBR près de la caméra.
+- La lune ne reçoit plus le renforcement spéculaire du soleil (×20 pour
+  l’eau, ×4 pour les autres matières). Son coefficient lunaire et ses phases
+  restent appliqués ; le grand reflet solaire est conservé.
+- Distance commune PBR/SSR : 16, 32 (défaut), 64, 128 ou 256 blocs.
+  À 256, le rayon SSR peut aussi rechercher jusqu’à 256 blocs. Nombre de pas
+  et budgets de maillage inchangés ; les limites du terrain visible/chargé,
+  des reflets hors écran et du budget de maillage subsistent.
+- PBR 80 %, SSR 20 %, mélange des eaux et préférences de beta.146 conservés.
+  Libellés FR/EN mis à jour.
+
+## Vérifications
+
+Mondes de test jetables, macOS Apple M1. Aucune sauvegarde personnelle utilisée.
+
+- Reproduction avant correction sous Vulkan : à 12 cm du sol de briques,
+  59 442 / 262 272 pixels changent de plus de 12 niveaux RVB cumulés sous une
+  rotation de 0,00002 degré. Le test échoue. Journal :
+  `build/beta147-close-before-vulkan.log`.
+- Même scène après correction : 1 / 262 272 pixels à 12 cm ; également testé
+  à 25 cm, 50 cm et 1 m. Suite PBR Vulkan réussie :
+  `build/beta147-close-after-vulkan.log`.
+- Preuves avant/après dans `build/evidence/close-before-vulkan/` et
+  `build/evidence/close-after-vulkan/`.
+
+- Suite PBR et préférences OpenGL finale réussie : mêmes scènes proches,
+  persistance des distances dont 256 blocs, FR/EN, OFF/zéro, intensités,
+  rechargement, redimensionnement et effets combinés.
+  Journal : `build/beta147-close-final-opengl.log` ; preuves :
+  `build/evidence/beta147-close-final-opengl/`.
+
+- Suite SSR Vulkan finale réussie : F5, intersections, portées dont 256,
+  eau/verre/métal, OFF/zéro, rechargement et redimensionnement.
+  Journal : `build/beta147-ssr-final-vulkan.log` ; preuves :
+  `build/evidence/beta147-ssr-final-vulkan/`.
+- À PBR 80 % / SSR 20 %, le soleil conserve 22 697 pixels quasi blancs sur
+  la scène aquatique 854 × 480. La lune seule en compte zéro, tout en modifiant
+  visiblement 40 808 pixels par rapport au PBR OFF. Capture du bloom lunaire
+  inspectée : reflet doux, sans plateau blanc.
+
+- Suite SSR OpenGL finale réussie également : zéro pixel quasi blanc pour
+  la lune, 22 111 pour le soleil et 40 749 pixels de reflet lunaire visibles.
+  Intersections : 91 / 518 400 pixels changés sous rotation minuscule.
+  Journal : `build/beta147-ssr-final-opengl.log` ; captures correspondantes
+  dans `build/evidence/beta147-ssr-final-opengl/`.
+- `./gradlew check build` dans un instantané isolé : 252 tests serveur,
+  229 réussis, 23 échecs, avec exactement les mêmes identifiants que beta.146.
+  Journal : `build/beta147-check-build-isolated.log` ; comparaison :
+  `build/beta147-server-failures.json`. La vérification globale reste en échec.
+  Les derniers ajouts lune/256 concernent exclusivement le rendu client,
+  ses réglages et ses tests ; ils sont validés par les suites finales ci-dessus.
+- Assemblage final réussi : `./gradlew build assemblePack -x :sanctuary:check`,
+  après les contrôles purs et serveur exécutés dans l’instantané, sans les
+  répéter. Journal : `build/beta147-build-pack.log`. Cette exclusion ne
+  transforme pas le contrôle complet en réussite.
+
+## Artefact
+
+[Sanctuary-beta.147.mrpack](../build/Sanctuary-beta.147.mrpack), également copié
+à côté de beta.146 dans `sanctuary-beta/build/`. Aucun ancien pack remplacé,
+aucune installation Prism ou publication effectuée.
+
+Archive ZIP vérifiée, un seul JAR Sanctuary beta.147, identique au JAR construit,
+shaders identiques aux sources finales, options FR/EN 256 présentes,
+Minecraft 26.3 / Fabric Loader 0.19.5 conservés. Taille : 10 519 851 octets.
+SHA-256 : `b8044243dbe160d5171ea584052cf5732393e4d91352c29c33b727af80c0a5bc`.
+Reçu : `build/beta147-artifacts.json`.
+

docs/pbr-refresh-beta142.md

@@ -0,0 +1,173 @@
+# PBR-142 — Stabilité du relief et Vulkan par défaut
+
+Socle beta.141 `7ce01c4`, branche `codex/pbr-refresh-beta142`.
+Minecraft 26.3 / Java 25. Livraison beta.142.
+
+## Contrat
+
+Corriger le clignotement lors de la reconstruction des sections PBR : conserver
+le rendu précédent jusqu'à ce que le remplaçant soit disponible et éviter les
+reconstructions dues seulement aux lumières dynamiques. Une invalidation pendant
+une reconstruction doit être conservée, sans annuler indéfiniment le travail.
+Le PBR passe à 80 % par défaut, valeur confirmée par l'utilisateur ; les choix
+explicitement enregistrés restent conservés.
+
+La capture `2026-09-18_04.19.34.png` montre des points très clairs, plus fins
+que les pixels des textures, sur des parois et un plafond de grotte. L'utilisateur
+confirme OpenGL et leur disparition quand seul le PBR est coupé. Examiner
+les lectures de textures et les calculs aux angles rasants séparément du cache.
+
+Tests natifs prévus : recalcul de section sous observation, invalidations
+répétées, remplacement atomique, suppression réelle de blocs, lumière portée,
+cache et préférences ; OpenGL et Vulkan. Pas de monde personnel ouvert.
+
+## Précision du signalement et implémentation
+
+L'utilisateur précise ensuite que le bruit apparaît **en mouvement**, et demande
+le passage à Vulkan. Il ne faut donc pas attribuer les points de sa capture au
+seul clignotement de reconstruction : ce sont deux vérifications distinctes.
+
+- Les sections PBR publiées restent affichées jusqu'au remplacement de leur
+  maillage. Une nouvelle invalidation durant la construction est mémorisée ;
+  elle n'annule plus continuellement le travail. Le budget permanent reste
+  24 Mio, avec temporairement l'ancien et le nouveau maillage d'une section.
+- Les invalidations de lumière dynamique ne régénèrent plus la géométrie PBR.
+  Les changements de blocs et de lumière du ciel restent pris en compte.
+- Lectures explicites des texels de profondeur/scène et du niveau de matériau,
+  gradients de texture calculés avant les rejets de fragments. Les produits
+  scalaires des reflets sont bornés, la puissance entière de Fresnel est
+  explicite, les résultats non finis ne remplacent pas la scène native.
+  Aucun flou ajouté aux textures.
+- Le choix graphique natif « Par défaut » devient « Vulkan (par défaut) »
+  (FR/EN) et essaie Vulkan en premier. Minecraft conserve son repli OpenGL si
+  Vulkan ne peut pas être initialisé. Un choix **OpenGL explicite** reste
+  disponible ; pour une installation ainsi réglée, sélectionner Vulkan dans
+  les réglages vidéo puis redémarrer. Aucun moteur externe ni VulkanMod ajouté.
+- 80 % est la nouvelle intensité PBR initiale. Les valeurs déjà enregistrées
+  explicitement restent conservées.
+
+Le code Minecraft 26.3 a été inspecté : `PreferredGraphicsApi.VULKAN` essaie
+Vulkan puis OpenGL ; le choix natif `DEFAULT` essayait auparavant OpenGL d'abord.
+Tous les effets Sanctuary utilisent déjà l'API graphique native. Le seul hook
+OpenGL direct est le correctif spécifique de lecture des panoramas dans
+`GlCommandEncoder` ; il ne remplace pas la voie Vulkan native.
+
+Référence pour les lectures après contrôle divergent :
+[documentation Khronos des samplers](https://wikis.khronos.org/opengl/Sampler_%28GLSL%29).
+La correction rend ces lectures explicites ; elle ne constitue pas à elle seule
+une reproduction du défaut sur le pilote Windows de l'utilisateur.
+
+## Observations de diagnostic
+
+Le détecteur de points blancs isolés (minimum RGB 170, au moins cinq voisins
+sur huit sous 120) compte 669 points sur l'image utilisateur et zéro sur la
+première grotte de contrôle. Il s'agit de scènes, résolutions et pilotes différents,
+pas d'un avant/après reproduisant exactement le bug utilisateur. Les rendus
+natifs OpenGL de contrôle étaient déjà exempts de ce grain avant les nouvelles
+protections du shader ; le signalement Windows reste donc à reconfirmer là-bas.
+
+Le test de rafraîchissement conserve les mêmes maillages publiés durant douze
+invalidations consécutives, compare l'image et vérifie que des remplacements
+aboutissent. Le test de torche alterne quatre fois les torches normales/des âmes
+sans reconstruction des normales. Le contrôle de mouvement presse réellement
+Avancer, maintient la torche et le PBR actifs et vérifie un déplacement d'au moins
+un bloc avant de vérifier les 24 captures. Les angles -30°, 0° et 35° sont aussi
+contrôlés, ainsi que les effets combinés et les préférences.
+
+### Domaine invalide du reflet de la torche en main
+
+Pour la lumière du joueur en vue subjective, la source est la caméra : le
+vecteur lumière et le vecteur de vue sont parallèles. L'ancien
+`pow(1 - max(dot(v,h),0),5)` n'avait aucune borne supérieure pour ce produit
+scalaire. Un calcul reproductible Float32 (100 000 positions, graine 142)
+donne 19 991 bases légèrement négatives, jusqu'à -2,3841858e-7, contre zéro
+après clamp. C'est une reproduction numérique d'un **domaine de calcul invalide**,
+pas une reproduction des pixels produits par le pilote utilisateur.
+
+GLSL 3.30 ne définit pas `pow` pour une base négative, même avec un exposant
+entier : [spécification Khronos, fonctions exponentielles](https://registry.khronos.org/OpenGL/specs/gl/GLSLangSpec.3.30.pdf).
+Le correctif borne les cosinus à [0,1] et remplace cette puissance par des
+multiplications. La torche alignée sur la caméra ne dépend donc plus du traitement
+de cette entrée invalide par le pilote. Reçu numérique ignoré :
+`build/pbr142-fresnel-domain.json`.
+
+### Mise à jour des fixtures antérieures
+
+La suite Vulkan complète s'est arrêtée au contrôle SSGI de coin : l'oracle
+ne trouvait plus de pierre neutre (`rows=0`), car les lumières colorées ajoutées
+depuis beta.139/140 teintaient la pierre avec la lave. Le test de proximité SSGI
+et le test PBR solaire isolent désormais leur effet en coupant cette autre passe.
+Aucun seuil n'a été diminué et aucun changement de rendu SSGI n'est livré.
+Le sous-ensemble en échec est relancé séparément ; les étapes précédentes
+(ombres, CTM, bloom, lens flare, déplacement SSGI) avaient réussi.
+
+## Vérifications natives
+
+Sur Mac Apple M1, Java 25 et Minecraft 26.3 :
+
+- OpenGL : suite couleurs/directions/rafraîchissement en 3 min 36 s, puis
+  déplacement continu avec torche active en 1 min 36 s. Zéro point blanc isolé
+  sur les 24 images de mouvement et les trois angles de grotte.
+- Vulkan/MoltenVK 1.4.2 : sélection automatique sans argument de moteur,
+  couleurs/directions/rafraîchissement en 3 min 47 s. Dernier test continu avec
+  torche active en 1 min 37 s, zéro point blanc isolé sur les 24 images.
+- Ombrages lune/midi/feuilles, distances et précisions, stabilité temps réel,
+  CTM, bloom (minerais, torche, lampe, lave, soleil), émissifs indépendants et
+  lens flare validés sous Vulkan dans la suite d'effets. Le déplacement SSGI
+  sur douze blocs passe également. La suite s'arrête ensuite sur l'oracle
+  ancien de couleur de pierre décrit ci-dessus : ne pas présenter ce lancement
+  de 7 min 15 s comme une réussite complète.
+- Reprise ciblée après isolation de cet oracle : SSGI près des surfaces puis
+  PBR extérieur réussis sous Vulkan en 2 min 55 s. Proximité 35/100, haute
+  résolution, léger mouvement, toit ajouté/retiré, reload, resize, zéro/OFF et
+  effets combinés. Gain SSGI au coin test : 6,01 sur 99 lignes à 35 %.
+- Les nouvelles valeurs initiales et les choix enregistrés sont testés, dont
+  une intensité PBR explicitement enregistrée à 50 qui reste à 50.
+
+Les premiers essais du nouveau contrôle de mouvement ont permis de corriger
+son entrée clavier : `pressKey` ne maintient pas une touche enfoncée. Le test
+final utilise `holdKey` puis `releaseKey`, vérifie le déplacement réel et refuse
+la disparition de la lumière portée ou du PBR pendant les captures.
+
+Les jeux de test utilisent uniquement des mondes neufs et ignorés. La capture
+et le pilote Windows utilisateur n'ont pas été reproduits à l'identique ; leur
+retest reste ouvert malgré les corrections numériques et les contrôles natifs.
+
+## Construction et archives
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit en **2 min 38 s**, 126 tâches. Le GameTest serveur dédié reste exclu
+selon le refus EULA antérieur ; les suites clientes ci-dessus ont réellement
+utilisé les deux moteurs natifs. `git diff --check` passe.
+
+Les archives normale/Test embarquent le même JAR, leurs versions/index/hashes
+sont vérifiés, leurs sources correspondent aux fichiers courants. Le template
+contient exactement les ressources attendues. Les onze entrées de production
+modifiées par rapport à beta.141 sont limitées au PBR, au choix graphique et
+aux traductions ; les ressources de jeu antérieures sont conservées.
+
+SHA-256 du JAR : `0bc2da9df2ef004e6dc78932cfde7b31b7717c63c83ceed789d151177c41bc1a`.
+
+- `Sanctuary-beta.142.mrpack` : 10464746 octets ; SHA-256 `dba4fd8e1e3b20136faa1c1de3494df3cb250c87de199c04e07883c786ca48ee`.
+- `Sanctuary-Test-beta.142.mrpack` : 10483672 octets ; SHA-256 `d56b81a4aea6649a40a3c49dedee904989943a518ad0ae7c520b808dd0f9b9a7`.
+
+Reçu détaillé ignoré : `build/shader142-artifact.json`.
+
+## Livraison réalisée
+
+[Release beta.142](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.142)
+publiée depuis `ea151dd5df8c7c5abd0107656f40c723efbf2ebe`. Canal stable :
+`d661260e2bbabb0326c86d6cc543daf986979596`. Archives normale/Test, ZIP d'amorçage Prism et template
+publiés avec vérification de leurs téléchargements ; tag et artefacts immuables.
+
+Deux synchronisations isolées puis deux synchronisations de l'instance
+**Sanctuary Beta** réussies. Les 923 fichiers personnels suivis ont conservé
+leurs hashes, notamment mondes, réglages et packs personnels. Aucun monde
+personnel ouvert. Sauvegarde préalable : `sanctuary-backups/before-beta.142/`.
+L'instance locale conserve son réglage graphique natif « default », qui démarre
+désormais avec Vulkan prioritaire. Un Windows explicitement réglé sur OpenGL
+doit sélectionner Vulkan dans les réglages vidéo et redémarrer.
+
+Archives locales également dans `sanctuary-beta/build/`. Le checkout de travail
+historique modifié `sanctuary-beta` n'a pas été réinitialisé ; seules ces archives
+ignorées y ont été déposées. Sources sur `codex/pbr-refresh-beta142`.

docs/pbr-soft-sun-beta148.md

@@ -0,0 +1,68 @@
+# RENDER-148 — PBR 50 % et reflet solaire diffus
+
+Branche `codex/pbr-soft-sun-beta148`, socle beta.147 `96a36d9`.
+Minecraft 26.3, Java 25, dépendances et sauvegardes inchangés.
+
+## Résultat
+
+- PBR à 50 % par défaut, SSR toujours à 20 % et portée commune jusqu’à 256.
+- Les configurations anciennes contenant exactement PBR 80 % passent à 50 %.
+  Un marqueur de migration conserve ensuite tout choix explicite, y compris
+  un nouveau choix 80 %. Les autres anciennes intensités restent conservées.
+- Le reflet solaire de l’eau avait un renforcement ×20 et une compression
+  exponentielle qui effaçait les détails dans une large zone blanche.
+  Le renforcement passe à ×6 et le lobe est plus diffus (rugosité minimale
+  de 0,42 au lieu de 0,34 pour le lobe céleste de l’eau).
+- Pour le soleil sur l’eau, fusion par texel entre éclaircissement vers le
+  blanc et lumière douce fondée sur la couleur native. La pondération emploie
+  une compression rationnelle, sans atteindre brutalement un plateau blanc.
+  La texture et ses animations restent natives ; aucun bruit ajouté.
+- La lune conserve son intensité atténuée, sans renforcement solaire.
+  Les lampes et matières solides conservent leur fusion spéculaire précédente.
+  Le bloom reste réglable et suit la lumière réellement ajoutée.
+
+## Vérifications
+
+Scènes plates jetables, Apple M1, Vulkan et OpenGL. Le test solaire contrôle
+une lumière largement visible et limite les pixels quasi blancs à moins de
+0,5 % de l’image, au lieu d’imposer une grande tache blanche.
+
+Premier contrôle Vulkan à PBR 50 % / SSR 20 % : 149 908 pixels éclaircis,
+zéro pixel quasi blanc sur 854 × 480. Captures vues du dessus et à soleil bas
+inspectées : la texture reste visible dans la traînée lumineuse.
+Preuves : `build/evidence/beta148-preview/`.
+Rendu de la traînée solaire approuvé par le créateur après inspection de la capture.
+
+- Suites SSR complètes Vulkan et OpenGL réussies : F5, intersections, portées,
+  eau/verre/métal, OFF/zéro, lune, bloom, rechargement et redimensionnement.
+  Journaux : `build/beta148-ssr-vulkan.log`, `build/beta148-ssr-opengl.log`.
+  Sous OpenGL, 146 680 pixels éclaircis et zéro pixel quasi blanc dans la scène
+  solaire. La lune reste visible sans saturation (35 865 pixels modifiés).
+  Preuves : `build/evidence/beta148-ssr-vulkan/` et
+  `build/evidence/beta148-ssr-opengl/`.
+
+- Suites PBR/préférences Vulkan et OpenGL réussies : défaut 50 %, migration
+  de l’ancien 80 %, conservation d’un nouveau choix explicite 80 %, valeurs
+  personnalisées, FR/EN, proximité, OFF/zéro, intensités et rechargement.
+  Journaux : `build/beta148-pbr-vulkan.log`, `build/beta148-pbr-opengl.log`.
+- `./gradlew check build` dans l’instantané isolé : 252 tests serveur,
+  229 réussis, 23 échecs. Exactement les mêmes identifiants que beta.147,
+  aucun nouvel échec. Journal : `build/beta148-check-build-isolated.log` ;
+  comparaison : `build/beta148-server-failures.json`. Le contrôle global
+  demeure donc en échec.
+- Assemblage final réussi : `./gradlew build assemblePack -x :sanctuary:check`,
+  sans répéter les contrôles purs et serveur déjà exécutés dans l’instantané.
+  Journal : `build/beta148-build-pack.log`. L’exclusion ne constitue pas
+  une réussite du contrôle complet.
+
+## Artefact
+
+[Sanctuary-beta.148.mrpack](../build/Sanctuary-beta.148.mrpack), également copié
+à côté des autres versions dans `sanctuary-beta/build/`. Archive ZIP vérifiée,
+un seul JAR Sanctuary beta.148 identique au JAR construit, shaders finaux
+identiques aux sources, textes FR/EN 50 % et dépendances exactes vérifiés.
+Taille : 10 520 050 octets. SHA-256 :
+`597cc2a96eabc3cf0ebf8ac59b4f94cf7cabf0c773e1dce13c10736ca6fcba38`.
+Reçu : `build/beta148-artifacts.json`.
+Aucune publication ni installation Prism effectuée.
+

docs/pbr-ssr.md

@@ -0,0 +1,221 @@
+# PBR-SSR — eau, verre et reflets pixélisés
+
+Livraison locale **beta.145**, branche `codex/pbr-ssr`. Socle PBR beta.142 /
+suivi beta.143 et copie figée des sources du chantier d’eau beta.144. Minecraft 26.3, API graphique native.
+
+## Contrat
+
+Les reflets colorent les texels de matière sur une grille 16 × 16 liée aux UV,
+avec les normales procédurales existantes. Eau et verre sont diélectriques.
+L’eau reprend les faces du tessellateur natif (niveaux, pentes, écoulements,
+waterlogging), sans modification de géométrie ni simulation de vagues.
+Le verre réfléchit aussi sur les zones sans pigment de sa texture. Les pixels
+pigmentés conservent leur relief même avec un alpha faible ; l’alpha nul
+utilise la normale géométrique.
+
+Les images des normales d’eau sont préparées au chargement du matériau ; leur
+séquence suit l’horloge effective des animations de l’atlas, avec interpolation.
+Seules les petites tuiles de normales changent sur le GPU, pas le maillage.
+Les normales des textures haute résolution sont rééchantillonnées à 16 × 16.
+Au-delà de 1 024 images par sprite, un avertissement signale le repli vers
+une normale fixe pour borner la mémoire.
+
+L’option FR/EN « Reflets du paysage — expérimental » est OFF initialement,
+intensité 50 %, bornée entre 0 et 100. Elle exige le PBR actif. L’eau naturelle
+reste indépendante pour ses couleurs, sa transparence et sa brume.
+
+## Pipeline et limites
+
+Couleur et profondeur du paysage sont copiées après les opaques et avant les
+transparences, dans les deux chemins natifs. Le chemin classique ferme la passe
+opaque avant la copie, puis reprend la transparence native dans une nouvelle
+passe. Aucune copie d’attachement Vulkan encore ouvert.
+
+Une profondeur propre sélectionne le récepteur PBR le plus proche devant le
+paysage opaque. Une vitre devant l’eau reçoit seule le SSR ; les couches
+suivantes conservent leur rendu natif. La profondeur du fond n’est pas utilisée
+comme profondeur de surface de l’eau.
+
+8 à 32 pas déterministes adaptés à la longueur écran, puis quatre raffinements maximum, récepteurs jusqu’à
+32 blocs et rayons jusqu’à 128 blocs. Pas de bruit aléatoire, historique,
+réflexion récursive, réfraction nouvelle, lecture GPU vers CPU ou ajout de
+lumière de gameplay. Les objets hors écran ou masqués ne sont pas retrouvés. Les détails fins entre
+deux pas peuvent être manqués ; une interpolation finale affine le point
+d’intersection sans augmenter le nombre de recherches.
+Un échec revient progressivement au rendu existant ; les transparences et les
+effets Sanctuary postérieurs à la capture ne figurent pas dans le reflet.
+
+Les reflets sont composés après le SSGI, avant contours, bloom et rayons.
+La main et le HUD restent en dehors du traitement. Le PBR conserve son
+périmètre Overworld hors immersion et s’efface avec les moteurs externes.
+
+Budget de maillages : 24 Mio de solides, 8 Mio supplémentaires de transparences.
+Deux profondeurs plein écran servent aux surfaces PBR ; la couleur de paysage
+SSR est allouée seulement à ON/intensité positive. La copie de composition PBR
+existante est réutilisée. Aucun buffer de normales plein écran.
+La grille visuelle ne signifie pas qu’un seul fragment GPU est exécuté par texel.
+
+## Intégration
+
+Le commit `38f4d6c` apporte le SSR et les récepteurs transparents. Le commit
+`0cfd51e` importe une copie contrôlée des sources beta.144 depuis le chantier
+`codex/water-beta144`, fondé sur `580b241`. Les empreintes des fichiers ont été
+comparées avant et après la copie ; le reçu local est dans
+`build/water144-snapshot/manifest.json`. Cette intégration ne prétend pas que
+beta.144 a été publiée ou que son benchmark isolé est terminé. Le code de
+production de cet instantané est identique à celui du commit
+`7eef945` ensuite créé sur la branche d’eau. Les essais ci-dessous portent
+sur les sources réunies dans cette branche.
+
+Points d’entrée : `PbrMaterials` et `PbrAnimation` pour les normales animées,
+`PbrFluidMesh` pour le tessellateur natif, `PbrTerrain` pour les deux budgets,
+`ReflectionSceneMixin` pour la capture opaque, `PixelReflections` et
+`pixel_reflections.fsh` pour la sélection et le rayon. Les horloges de sprites
+sont référencées faiblement des deux côtés afin de ne pas retenir les anciens
+atlas après rechargement.
+
+## Vérifications
+
+Machine : Apple M1, Minecraft 26.3, Java 25, macOS. Mondes plats de test neufs,
+graine 122 ; aucune sauvegarde personnelle utilisée. Les captures conservent
+le préfixe historique `sanctuary-beta142-shader` du banc de test.
+
+- Client OpenGL 4.1 Metal 90.5, transparence classique : suite SSR réussie avec les sources d’eau
+  intégrées (`build/ssr145-opengl-final.log`).
+- Client Vulkan/MoltenVK : suite SSR avec transparence améliorée réussie
+  (`build/ssr145-vulkan-final.log`).
+- Régression du PBR historique et nouvelles assertions de profils, normales
+  transparentes, persistance, bornes et traductions SSR : réussies
+  (`build/ssr145-pbr-regression-retry.log`). Une première tentative interrompue
+  s’était arrêtée sur un timeout de sémaphore Vulkan ; elle reste un échec
+  consigné dans `build/ssr145-pbr-regression.log`.
+- Suite fonctionnelle eau beta.144 : réussie, y compris profils, fond modifié,
+  brume, océan, rechargement, préférences, cascades et pack de matériaux
+  (`build/ssr145-water-functional.log`). Son long benchmark autonome a été
+  explicitement sauté ; le coût SSR est mesuré séparément ci-dessous.
+- Le relief rouge puis bleu produit deux contributions de couleur distinctes
+  dans le bassin ; caché par un mur opaque, ce changement ne traverse pas le mur.
+- Eau animée sans nouvelle analyse de texture, verre transparent devant l’eau,
+  métal, déplacement minime de caméra, rotation, OFF/zéro, immersion,
+  rechargement de ressources et redimensionnement sont exercés par assertions.
+  L’horloge d’eau reste active après rechargement ; les profils sable et étang
+  restent corrects avec PBR et SSR simultanément actifs.
+- Des captures couvrent également les effets combinés, la lune, les angles
+  rasants, la translation de caméra, la sortie du paysage hors écran, la pierre
+  rugueuse OFF/ON, des vitres colorées superposées, un écoulement, une cascade
+  et une dalle gorgée d’eau. Elles ne remplacent pas une inspection
+  artistique de tous les angles et de tous les packs.
+
+Captures locales OpenGL : [OFF](../build/ssr-evidence/beta145-opengl-final/0000_sanctuary-beta142-shader-ssr-water-off.png),
+[ON](../build/ssr-evidence/beta145-opengl-final/0001_sanctuary-beta142-shader-ssr-water-on.png).
+Le dossier `build/ssr-evidence/beta145-opengl-final/` contient les autres captures.
+Les mêmes cas Vulkan sont conservés dans
+`build/ssr-evidence/beta145-vulkan-final/`. Les comparaisons eau, métal et
+verre empilé ont été inspectées visuellement. Ces pièces sont ignorées par Git.
+
+## Coût mesuré
+
+1920 × 1080, PBR à 80 %, SSR à 100 % pour accentuer le résultat, VSync OFF,
+limite de FPS et réduction AFK désactivées. Chaque scène chauffe 30 ticks par
+état avant 80 ticks de mesure, soit 324 à 483 images pour OpenGL et 317 à 477 pour Vulkan. Ordre OFF puis
+ON ; il s’agit d’un diagnostic local court, pas d’une campagne statistique.
+Le temps de frame mesure `Minecraft.renderFrame`, présentation comprise.
+
+| OpenGL | Médiane OFF / ON (ms) | p95 OFF / ON (ms) | Écart médian |
+| --- | --- | --- | --- |
+| Petit étang | 7,57 / 9,42 | 10,35 / 12,50 | +1,85 ms |
+| Eau dominante | 7,76 / 11,67 | 10,67 / 13,96 | +3,91 ms |
+| Construction vitrée | 7,85 / 10,12 | 10,67 / 12,65 | +2,27 ms |
+
+| Vulkan | Médiane OFF / ON (ms) | p95 OFF / ON (ms) | Écart médian |
+| --- | --- | --- | --- |
+| Petit étang | 7,97 / 10,36 | 8,97 / 11,49 | +2,40 ms |
+| Eau dominante | 10,10 / 12,23 | 10,97 / 12,97 | +2,13 ms |
+| Construction vitrée | 8,52 / 11,25 | 9,49 / 12,20 | +2,72 ms |
+
+La mesure GPU Vulkan autour de `PixelReflections.render` donne, à ON,
+**2,07 / 2,18 ms** (médiane / p95) pour l’étang, **2,56 / 2,63 ms** pour
+l’eau dominante et **2,09 / 2,21 ms** pour le verre. À OFF, la sonde mesure
+0,03 ms environ. Ce périmètre couvre la copie de composition et le dessin
+SSR ; il exclut la capture opaque antérieure et la profondeur partagée PBR.
+La sonde utilise les valeurs rendues par la requête native, pas une mesure
+GPU du jeu complet.
+
+La requête GPU native ne fournit pas de mesure exploitable sur ce pilote
+OpenGL ; ce champ est indisponible, pas nul. Les premiers essais contaminés
+par la réduction AFK à 30 FPS sont exclus des résultats retenus.
+**L’objectif de surcoût médian inférieur à 2 ms n’est pas respecté dans l’ensemble des
+scènes.** L’option reste expérimentale et désactivée par défaut.
+
+À 1080p : profondeurs partagées par le PBR = 15,82 Mio ; copie couleur SSR
+supplémentaire = 7,91 Mio, libérée à OFF/zéro. Total de ces cibles à ON :
+23,73 Mio. Les maillages observés occupent environ 0,51–0,55 Mio de solides et
+1,09–1,21 Mio de transparences, en dessous des plafonds 24 / 8 Mio vérifiés
+par assertion. Ces compteurs n’incluent ni la mémoire du moteur, ni la copie
+PBR existante, ni les atlas de matériaux de 6,25 Mio chacun ; ce ne sont pas
+des mesures de mémoire totale du processus.
+
+## Construction et contrôles généraux
+
+`./gradlew check build` a été exécuté jusqu’au bout : **229 GameTests serveur
+réussis sur 252, 23 échecs**, en 8 min 45 s pour la commande complète.
+Les échecs concernent les tombes/familiers, le catalogue, deux invariants de
+génération, les placements de blocs/progression/construction et les menus
+natifs. Les tests concernés et le code de gameplay serveur ne sont pas
+modifiés par ce lot. Aucun contre-test de toute la branche de départ n’est
+revendiqué. Le journal complet est `build/ssr145-check-build.log` ; le relevé
+exhaustif est `build/ssr145-server-failures.json`.
+
+L’assemblage est repris avec `./gradlew check build assemblePack assembleTestPack
+-x :sanctuary:runGameTest`, en excluant uniquement cette tâche déjà exécutée.
+Cette commande réussit en 2 min 56 s (126 tâches) ; vérification du pack,
+compilation, contrôles hors GameTests serveur et assemblages passent. Les
+exports MRpack sont produits depuis leurs dossiers packwiz de staging.
+L’intégrité ZIP, les métadonnées, les traductions et mixins SSR ainsi que
+l’identité du JAR embarqué dans les deux packs sont contrôlées.
+Cette exclusion ne transforme pas le contrôle complet en succès.
+
+## Reproduire les essais client
+
+Base de chaque commande :
+
+```sh
+./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryQuickTests=true \
+  -PsanctuaryPbr134ClientTests=true -PsanctuaryClientNoVsync=true
+```
+
+- SSR Vulkan : ajouter `-PsanctuarySsrClientTests=true
+  -PsanctuaryClientGraphicsBackend=vulkan -PsanctuaryClientImprovedTransparency=true`.
+- SSR OpenGL : ajouter `-PsanctuarySsrClientTests=true
+  -PsanctuaryClientGraphicsBackend=opengl -PsanctuaryClientImprovedTransparency=false`.
+- Régression PBR : ajouter uniquement `-PsanctuaryClientGraphicsBackend=vulkan`.
+- Profils et rendu de l’eau : ajouter `-PsanctuaryWater144ClientTests=true
+  -PsanctuaryWater144FunctionalOnly=true -PsanctuaryClientGraphicsBackend=vulkan`.
+
+Le mode fonctionnel saute uniquement le long benchmark autonome beta.144.
+Les sondes de temps de frame/GPU et lectures d’images appartiennent au mod
+de test ; elles ne sont pas embarquées dans le JAR de production.
+
+## Artefacts locaux
+
+Les archives finales sont rafraîchies depuis le JAR testé, puis revérifiées
+(`build/ssr145-artifacts.json`). Aucun tag ni canal n’est publié.
+
+| Artefact | Octets | SHA-256 |
+| --- | ---: | --- |
+| [sanctuary-beta.145.jar](../mods/sanctuary/build/libs/sanctuary-beta.145.jar) | 11369411 | `55341e2f5c8dcc352190fe96d15e86cd1ee6bb4ea2908441b70491d48f86f608` |
+| [Sanctuary-beta.145.mrpack](../build/Sanctuary-beta.145.mrpack) | 10508045 | `8bebe6227cbfe629c714a7c7547640ab5ccfbefaaf211484a93c042cfb42b5c5` |
+| [Sanctuary-Test-beta.145.mrpack](../build/Sanctuary-Test-beta.145.mrpack) | 10526966 | `54402ff8414ed1ae0d12b3b97af70c547c44dde2f3aa183712ae3769f99efbe7` |
+| [Sanctuary-Template-beta.145.zip](../build/Sanctuary-Template-beta.145.zip) | 4358316 | `226d92362a5ce922b8757b36f30c312081aca5cf73a299b82a221a12f384a95b` |
+
+## Limites de validation
+
+Le banc utilise un relief construit reproductible, pas une montagne générée
+représentative de tous les biomes. La validation artistique sur terrain généré,
+les textures personnalisées avec ordre/durées/interpolation atypiques et la
+stabilité sur un long trajet restent à compléter. Les surfaces peuvent perdre les petits détails entre
+les pas SSR et les zones hors écran ne sont jamais reconstruites. Windows,
+autres GPU et moteurs graphiques externes ne sont pas validés ici.
+
+Aucune publication de canal ni synchronisation Prism dans cette livraison.

docs/pixel-shadows-source122.md

@@ -0,0 +1,128 @@
+# Préparation locale des ombres portées pixélisées (ancien numéro beta.122)
+
+Ticket du 17 septembre 2026, branche locale `codex/pixel-shadows-beta122`.
+Cette préparation n'a jamais été publiée sous le numéro beta.122, déjà utilisé
+par une autre livraison. Elle est intégrée au socle beta.126 et livrée en
+[beta.127](shader-beta127.md). Les chemins et mesures ci-dessous décrivent
+les essais historiques dans le dossier de préparation.
+Demande : ajouter aux réglages de Sanctuary · Vanilla Light des ombres portées
+pixélisées, avec une finesse et une distance réglables.
+
+## Utilisation
+
+Dans **Options → Shaders**, activer **Sanctuary · Vanilla Light**, puis
+**Ombres portées pixélisées**. L'option est désactivée par défaut pour conserver
+le coût et le rendu des installations existantes. Les choix sont :
+
+- finesse de **8, 16 ou 32 pixels par bloc**, défaut 16 ;
+- distance de **16, 32 ou 64 blocs**, défaut 32.
+
+Ces préférences sont conservées dans `config/sanctuary-shaders.json`, avec les
+anciens champs de couleur. Leurs valeurs numériques sont ramenées aux choix
+admis au chargement. Les libellés et explications sont disponibles en FR/EN.
+Les réglages s'appliquent sans recharger les ressources.
+
+## Rendu et périmètre
+
+Une carte de profondeur rend les formes d'occultation des blocs solides chargés
+autour de la caméra, indépendamment de leur présence à l'écran. Les dalles et
+escaliers conservent leurs formes. Le cache est invalidé par les changements de
+blocs, les paquets de chunks et les reconstructions du moteur natif.
+La direction solaire vient du ciel natif extrait par Minecraft, et respecte
+ainsi l'angle solaire de Sanctuary. L'effet s'atténue sous la pluie, à l'horizon,
+dans la brume et à la limite de sa portée. Il s'arrête la nuit, dans les dimensions
+sans soleil, dans les fluides et lorsqu'un moteur externe suspend Vanilla Light.
+
+La profondeur du monde est lue directement par le GPU après le rendu du monde,
+avant la main et l'interface. L'inverse de la projection réelle inclut les effets
+de caméra. Les points recevant l'ombre sont arrondis sur une grille ancrée dans
+le monde ; le plan de la face est conservé pour limiter les auto-ombres.
+La carte solaire utilise également une origine alignée sur ses texels.
+Le HUD, la main, les étoiles et les captures panoramiques techniques gardent leur
+chemin de rendu. Aucun niveau de lumière de gameplay, règle serveur, sauvegarde
+ou générateur n'est changé. Aucune dépendance de rendu n'est ajoutée.
+
+Cette première version couvre les **formes d'occultation des blocs** : les entités
+conservent leurs ombres natives ; les feuillages ajourés, modèles non occultants,
+block entities animés, eau et verre ne projettent pas de nouvelles silhouettes.
+Les transparences et particules déjà composées peuvent recevoir l'assombrissement
+du terrain derrière elles. Il n'y a pas d'ombres de lune ou de torches, ni de
+séparation de l'éclairage local émissif dans cette passe d'assombrissement.
+
+## Coût et cycle de vie
+
+Les maillages sont mis en cache par section de 16³, avec au plus quatre sections
+commencées par image et un budget souple de 3 ms pour leur construction. Les
+ombres apparaissent progressivement pendant la préparation après activation ou
+déplacement. Le volume des obstacles part de la portée choisie avec une marge de huit blocs,
+puis s’étend vers le soleil sur deux fois cette portée, arrondi aux sections.
+Les obstacles au-delà de ce volume ou dans des chunks non chargés ne sont pas
+représentés. Les mises à jour de lumière seule ne reconstruisent pas les formes.
+Le cache de sommets est plafonné à 96 Mio et omet les formes pathologiques qui
+dépassent ses limites. Les textures de profondeur font entre 512 et 4 096 pixels
+de côté selon finesse et portée. Le coût exact dépend de la scène et du GPU.
+
+Les ressources sont libérées à la désactivation, au changement de monde, à la
+reconstruction des ressources et à l'arrêt du client. Cette livraison est locale :
+aucun avancement du canal packwiz ni installation personnelle ne fait partie du
+ticket.
+
+## Vérification
+
+Validation native sur **Minecraft 26.3, Java 25, macOS / Apple M1, OpenGL 4.1**,
+dans un nouveau monde plat de développement, graine **122** :
+
+- Comparaison GPU activation/désactivation sur une plateforme blanche avec
+  pilier, dalle et escalier : **920 échantillons assombris**, 63 412 inchangés,
+  aucun éclairci sur les 64 332 échantillons de sol retenus.
+- Pilier entièrement hors du frustum : **42 048 échantillons** restent dans
+  son ombre. Le retrait du pilier restitue la lumière sur **42 048 / 42 048**
+  échantillons et préserve les 23 616 échantillons déjà éclairés. Sa repose
+  restitue la même ombre, sans désactiver le cache entre ces manipulations.
+- Les trois finesses et les trois portées sont appliquées en direct ; les cartes
+  GPU sont redimensionnées aux dimensions attendues. Désactiver l'option libère
+  la texture et ne soumet plus de passe d'ombres.
+- À minuit, activer ou désactiver l'option donne la même image et aucune passe
+  solaire n'est soumise. Au retour du jour, le rendu reprend.
+- Le rechargement des ressources restitue la même image. Les préférences
+  persistent à la relecture du fichier et leurs valeurs extrêmes sont bornées.
+- Menus FR/EN inspectés en capture ; les libellés tiennent dans les contrôles
+  natifs à la taille de test. Les vues de finesse 8/16/32 sont conservées.
+
+```sh
+./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryPixelShadows122ClientTests=true \
+  -PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true
+```
+
+Succès en **1 min 17 s**, marqueur `PIXEL_SHADOWS122_CLIENT_PASS` dans
+`build/pixel-shadows122-client.log`. Captures inspectées dans
+`build/pixel-shadows122-evidence/final/`. Les pixels sont relus uniquement dans
+le test ; le code de rendu de production n'effectue aucune lecture CPU de GPU.
+Les premiers démarrages ont permis de corriger les identifiants de pipelines,
+la directive GLSL `#include` attendue par 26.3 et deux libellés répétés du menu.
+
+La commande de livraison est :
+
+```sh
+./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest
+```
+
+Le serveur GameTest dédié est exclu, conformément au refus de son EULA déjà
+consigné dans les livraisons précédentes. Le test graphique utilise le serveur
+intégré de son monde neuf. Aucun monde personnel n'est ouvert.
+La construction finale **réussit en 2 min 18 s** (126 tâches), journal
+`build/pixel-shadows122-build-final.log`. Le contrôle des archives confirme
+**868 sources Java** et **1 869 classes** identiques aux sorties construites,
+les ressources GLSL/FR/EN exactes dans le JAR et le template, et le même JAR
+dans les profils packwiz normal et Test. Aucune fixture cliente n'est embarquée.
+Reçu : `build/pixel-shadows122-artifact.json`.
+
+Artefacts locaux : `mods/sanctuary/build/libs/sanctuary-beta.122.jar`,
+`build/packwiz/`, `build/packwiz-test/` et `build/Sanctuary-Template-beta.122.zip`.
+SHA-256 du JAR :
+`66987681cede1d2adc1dda449078e8fa85310eb2c3fecd7a905d772ce75739c9`.
+
+Pas de mesure de FPS, d'essai Windows/Vulkan, de pack Iris ni de silhouettes
+animées revendiqués. Le shader reste un assombrissement graphique appliqué au
+rendu opaque et déjà composé, avec les limites de transparence décrites plus haut.

docs/publications-beta144-166.md

@@ -0,0 +1,44 @@
+# Publications beta.144 à beta.166
+
+Rattrapage des releases Gitea du 24 septembre 2026. La beta.144 était déjà publiée ; ses tags et fichiers restent inchangés. Les archives suivantes sont publiées avec leurs binaires conservés, sans reconstruire ni renuméroter les anciens mods.
+
+| Version | Commit source | Fichiers (hors SHA-256) |
+| --- | --- | --- |
+| [beta.145](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.145) | `ed2d08827260` | sanctuary-beta.145.jar, Sanctuary-Test-beta.145.mrpack, Sanctuary-beta.145.mrpack, Sanctuary-Template-beta.145.zip |
+| [beta.146](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.146) | `cf9a670f4415` | sanctuary-beta.146.jar, Sanctuary-beta.146.mrpack, Sanctuary-Template-beta.146.zip |
+| [beta.147](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.147) | `96a36d99bea0` | sanctuary-beta.147.jar, Sanctuary-beta.147.mrpack, Sanctuary-Template-beta.147.zip |
+| [beta.148](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.148) | `6f871446bbbf` | sanctuary-beta.148.jar, Sanctuary-beta.148.mrpack, Sanctuary-Template-beta.148.zip |
+| [beta.149](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.149) | `1c23d0c17ec9` | sanctuary-beta.149.jar, Sanctuary-beta.149.mrpack, Sanctuary-Template-beta.149.zip |
+| [beta.150](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.150) | `448e2febff2a` | sanctuary-beta.150.jar, Sanctuary-beta.150.mrpack, Sanctuary-Template-beta.150.zip |
+| [beta.151](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.151) | `b97ec6c9e820` | sanctuary-beta.151.jar, Sanctuary-beta.151.mrpack, Sanctuary-Template-beta.151.zip |
+| [beta.154](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.154) | `0eb1a381d4d3` | sanctuary-beta.154.jar, Sanctuary-beta.154.mrpack, Sanctuary-Template-beta.154.zip |
+| [beta.155](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.155) | `3bfb3cb251a1` | sanctuary-beta.155.jar, Sanctuary-beta.155.mrpack, Sanctuary-Template-beta.155.zip |
+| [beta.156](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.156) | `32158e2e0513` | sanctuary-beta.156.jar, Sanctuary-beta.156.mrpack, Sanctuary-Template-beta.156.zip |
+| [beta.157](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.157) | `9791d178ab5e` | sanctuary-beta.157.jar, Sanctuary-beta.157.mrpack, Sanctuary-Template-beta.157.zip |
+| [beta.158](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.158) | `19aa8054a52f` | sanctuary-beta.158.jar, Sanctuary-beta.158.mrpack, Sanctuary-Template-beta.158.zip |
+| [beta.159](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.159) | `bdaad0c94032` | sanctuary-beta.159.jar, Sanctuary-beta.159.mrpack, Sanctuary-Template-beta.159.zip |
+| [beta.160](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.160) | `c1d22786745d` | sanctuary-beta.160.jar, Sanctuary-beta.160.mrpack, Sanctuary-Template-beta.160.zip |
+| [beta.161](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.161) | `8deba7cfb47d` | sanctuary-beta.161.jar, Sanctuary-Template-beta.161.zip |
+| [beta.162](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.162) | `0c55a375623b` | sanctuary-beta.162.jar, Sanctuary-Template-beta.162.zip |
+| [beta.163](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.163) | `905b3bcfa125` | sanctuary-beta.163.jar, Sanctuary-Template-beta.163.zip |
+| [beta.164](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.164) | `9a429c40a15b` | sanctuary-beta.164.jar, Sanctuary-Template-beta.164.zip |
+| [beta.165](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.165) | `dbb9e3428da2` | sanctuary-beta.165.jar, Sanctuary-Template-beta.165.zip |
+| [beta.166](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.166) | `460c4706d37a` | sanctuary-beta.166.jar, Sanctuary-Template-beta.166.zip |
+
+## Historique et intégration
+
+La PR [#1 de Chris](https://git.botsu.net/koka/sanctuary-beta/pulls/1), intitulée « beta.144 — Code d’accès », est intégrée par le merge `ad960ef`, puis corrigée et livrée dans `460c470` (beta.166). Son numéro de version historique ne remplace pas la release beta.144 dédiée à l’eau. `main` a été avancé en fast-forward sur beta.166. La PR est clôturée : Gitea refuse le mode « manually-merged » dans ce dépôt, elle reste donc affichée comme fermée plutôt que fusionnée. Sa branche et ses commits sont conservés.
+
+Les beta.152 et beta.153 sont des chantiers shaders non finalisés : aucun commit de livraison ni JAR Sanctuary vérifiable retrouvé. Aucun tag ou binaire artificiel n’est créé pour remplir ces numéros. Les fichiers de travail locaux sont conservés.
+
+## Contrôles et limites
+
+- Intégrité ZIP, version Fabric et version source contrôlées pour chaque JAR ; sources Java archivées comparées aux commits de livraison.
+- Le ZIP de sources beta.145 est antérieur à une correction : il n’est pas publié. Le JAR correspond exactement au SHA-256 documenté dans le ticket, et la classe concernée correspond au binaire beta.146 dont les sources sont vérifiées.
+- Les MRpack embarquent le JAR de leur release, vérifié par SHA-256. Le MRpack beta.150 conservé contenait un binaire intermédiaire : une copie a été réassemblée avec le JAR final ; l’original local reste intact.
+- Chaque pièce jointe est retéléchargée anonymement et comparée à son SHA-256 local. Chaque release comporte son fichier SHA256SUMS.
+- Les anciens échecs de tests restent documentés dans les tickets liés aux releases historiques. Cette publication rétrospective ne prétend pas les avoir corrigés dans les anciens binaires.
+- La beta.166 a passé `check build assemblePack`, avec 252/252 GameTests ; voir [le contrat et les vérifications](inscription-web-beta166.md). Le parcours OAuth Discord et l’inscription sous le pseudo du dossier ont ensuite été testés localement.
+- Site compagnon : branche `codex/inscription-web-beta166`, commit `89973c1` publié. Les 12 tests ciblés accès/parrainage passent (162 assertions), y compris le refus d’un autre pseudo et la génération d’invitation refusée à un candidat en attente même administrateur.
+
+Le canal packwiz et les installations personnelles ne sont pas modifiés par ce rattrapage. Aucun monde, ancien JAR ou secret n’est ajouté à Git. Les fichiers `.env`, sauvegardes SQL et configurations privées du labo restent locaux.

docs/realtime-snow-melt-beta143.md

@@ -0,0 +1,68 @@
+# SNOW-143 — Neige saisonnière en temps réel
+
+Branche `codex/realtime-snow-melt-beta143`, socle beta.142. Minecraft 26.3 /
+Java 25. Livraison beta.143.
+
+## Comportement
+
+L'accumulation et la fonte saisonnière conservent le sampler natif de
+précipitation `ServerLevel.tickPrecipitation`. Sanctuary ne scanne donc toujours
+pas les chunks et ne force aucun chargement de terrain. Le changement porte
+seulement sur la probabilité des mutations de neige.
+
+Pendant une chute de neige, Sanctuary ajoute désormais une couche une fois sur
+12 échantillons natifs en moyenne. La neige reste visible pendant une session,
+mais les colonnes ne montent plus instantanément. À `randomTickSpeed = 3`, une
+couche apparaît en moyenne après environ 40 minutes de neige continue.
+
+Pour la fonte, chaque tirage saisonnier est multiplié par `72`, le rapport
+entre une journée réelle de 24 heures et une journée Minecraft de 20 minutes.
+
+Une couche fond désormais en moyenne en 4 h 05 en été,
+8 h 10 au printemps et 16 h 25 en automne. Avec le plafond actuel de deux blocs,
+une colonne météo suivie met environ 2,7 jours réels à disparaître en été,
+5,4 jours au printemps et 11 jours en automne. L'hiver ne fond toujours pas.
+
+Les règles de protection restent celles de beta.109 : seule la neige déposée
+par la météo Sanctuary depuis l'ajout du suivi `sanctuary:natural_snow_v1`
+peut fondre. La neige construite, l'ancienne neige non suivie, les couches
+manuelles, les biomes froids, les profils neigeux et la météo Vanilla restent
+préservés. Aucun format de sauvegarde ne change.
+
+## Vérifications
+
+Vérifié le 18 septembre 2026 sur macOS, Java 25.
+
+- `./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true
+  -PsanctuaryMelt109ClientTests=true -PsanctuaryClientNoVsync=true
+  -PsanctuaryQuickTests=true` : réussi en 57 s, avec le marqueur
+  `MELT109_NATIVE_PASS`. Le test couvre l'accumulation beta.108 ralentie,
+  la fonte couche par couche, la provenance persistante, les saisons, la
+  gamerule, la météo Vanilla, les profils neigeux, les biomes froids et le
+  rechargement de monde.
+- `./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest` :
+  réussi en 2 min 31 s, 126 tâches. Le GameTest serveur dédié reste exclu
+  conformément au refus antérieur de son EULA ; les contrôles natifs utilisent
+  le serveur intégré.
+- `python3 scripts/pack.py check` : versions, icône et index packwiz vérifiés.
+- Exports MRpack produits avec `packwiz modrinth export`, intégrité ZIP vérifiée.
+  Les deux MRpack embarquent exactement le JAR Sanctuary construit.
+
+| Artefact | Taille | SHA-256 |
+| --- | ---: | --- |
+| `sanctuary-beta.143.jar` | 11 323 665 octets | `fd4b663ac2b2a106624c42b09997db229cc14d6c39d44ae83079bc6aa9d39a08` |
+| `Sanctuary-beta.143.mrpack` | 10 464 931 octets | `e55caaa41c5a3a2666ff5415846e18f44d504ac34b698f3d974091cfb52364c5` |
+| `Sanctuary-Test-beta.143.mrpack` | 10 483 858 octets | `b14bca04c4a48771209d0f7e234ff9ef6b800eb236fb969a6f0dfcee5620dafc` |
+| `Sanctuary-Template-beta.143.zip` | 4 354 153 octets | `071fd8da67d1d0224b89889a5fcbc4cd269673dddb7a52f89aa78802f154605a` |
+
+## Publication
+
+[Release beta.143](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.143)
+publiée depuis le commit `97ff2b54cb63afe8fdd88bfa8f2ebb25dbe3b86d`.
+Le canal packwiz stable pointe sur
+`bafff5e9fcdd95c5dd184953a34ada805e455797`.
+
+Deux synchronisations isolées, puis deux synchronisations dans l'instance
+Sanctuary Beta ont réussi. Les 923 fichiers personnels suivis gardent leurs
+hashes ; aucun monde personnel n'a été ouvert. Sauvegarde préalable :
+`sanctuary-backups/before-beta.143/`.

docs/reflections-water-beta146.md

@@ -0,0 +1,112 @@
+# RENDER-146 — Reflets, portée commune et transitions de l’eau
+
+Branche `codex/reflections-water-beta146`, socle beta.145 `ed2d088`.
+Minecraft 26.3, Java 25 et dépendances inchangés. Préparation locale uniquement.
+
+## Contrat
+
+- Les passes PBR et SSR vérifient la profondeur finale du rendu natif pour
+  masquer les personnages, notamment en F5. La profondeur du paysage capturée
+  avant les transparences reste celle utilisée pour rechercher le reflet.
+- Le PBR utilise le test matériel EQUAL contre la profondeur du récepteur
+  sélectionné. L’ancienne tolérance de 3,5 cm pouvait accepter des faces
+  concurrentes près des coins ; elle est supprimée. La comparaison avec la
+  profondeur native conserve seulement une marge de 5 mm pour les différences
+  d’ordre de calcul des matrices, sans relâcher la sélection stricte du récepteur.
+  La position du vertex est déclarée invariante entre les passes.
+- PBR à 80 % et SSR à 20 % par défaut, pour toutes les matières, eau comprise.
+  Deux intensités d’effets distinctes, sans réglage séparé solide/liquide.
+  Les préférences explicites déjà enregistrées restent conservées.
+- Distance PBR/SSR commune : 16, 32 (défaut), 64, 128 blocs. Maillages,
+  sélection des récepteurs et fondu final emploient ce réglage. Le rayon SSR
+  conserve sa recherche maximale de 128 blocs dans le paysage visible.
+  Budgets de maillages inchangés : solides 24 Mio, transparences 8 Mio.
+  Une forte densité à grande portée peut donc limiter les surfaces disponibles.
+- Le reflet du soleil adopte un lobe plus large sur l’eau, avec une irradiance
+  renforcée : grande empreinte blanche vue du dessus et traînée étendue aux
+  angles rasants. Les lampes conservent leur lobe local.
+  Les éclats spéculaires ne sont plus plafonnés au gris moyen. Leur compression
+  conserve une valeur finie pouvant approcher le blanc. Une contribution douce
+  des seules passes PBR/SSR alimente le bloom existant, sans faire briller tous
+  les blocs blancs. Le réglage Bloom et son intensité gardent autorité.
+- Eau naturelle OFF par défaut dans une dimension ordinaire, ON pour une
+  dimension dont le générateur est Sanctuary / ExpansionChunkGenerator.
+  Le serveur transmet ce contexte à la connexion, au changement de dimension
+  et à la réapparition, y compris en multijoueur. Le défaut automatique nécessite
+  ce contexte envoyé par un serveur beta.146 ; sans lui, le client utilise le
+  défaut ordinaire OFF, toujours réglable. Aucune donnée de monde modifiée.
+  Les choix ON/OFF sont mémorisés séparément pour ces deux catégories.
+  Un ancien OFF explicite est conservé dans les deux ; un ancien ON global
+  adopte les nouveaux défauts par contexte.
+- Mélange des profils sur 1×1, 3×3, 5×5, 9×9 (défaut) ou 17×17 blocs, puis
+  interpolation aux sommets. Océans toujours clairs. La texture demeure native.
+  Surface et immersion utilisent la même étendue. Les changements du fond
+  invalident toute la largeur dépendante ; changer le réglage reconstruit les
+  sections chargées contenant de l’eau.
+
+Le filtre de surface est calculé dans la copie de région native, avec sommes
+préfixées par hauteur pour borner le coût des sommets. Aucun accès au monde
+vivant depuis le worker, chargement de chunk ou modification de sauvegarde.
+Les textes des nouvelles options sont fournis en français et en anglais.
+
+## Vérifications
+
+Machine : Apple M1, macOS, Java 25, Minecraft 26.3. Mondes plats jetables,
+graine 122 ; aucune sauvegarde personnelle utilisée.
+
+- Suite SSR/PBR Vulkan avec transparence améliorée : réussie
+  (`build/beta146-final-settings-vulkan.log`). F5 avec personnage réel en créatif,
+  portée 16/32/64/128, couleur du paysage, eau/verre/métal, OFF/zéro,
+  immersion, rechargement de ressources et redimensionnement.
+- Suite SSR/PBR OpenGL finale réussie également
+  (`build/beta146-final-settings-opengl.log`), avec 22 450 pixels quasi blancs
+  dans la scène solaire et 99 / 518 400 pixels modifiés dans le contrôle
+  des intersections. Captures dans `build/evidence/final-settings-opengl/`.
+- F5 : les 1 900 pixels du torse contrôlés sont strictement identiques entre
+  SSR OFF et ON, tandis que le reflet reste présent autour du personnage.
+- Soleil : 22 111 pixels quasi blancs sur 854 × 480 à PBR 80 % / SSR 20 %,
+  sans bloom, sur la scène de contrôle Vulkan. Les captures vues du dessus et
+  à soleil bas montrent une empreinte large et une traînée allongée.
+  Bloom OFF libère sa cible.
+- Mur, sol et escaliers en contact : 86 pixels sur 518 400 changent de plus
+  de 12 niveaux cumulés lors d’une rotation de 0,00002 degré ; seuil du test
+  0,1 %. Le cadre exclut l’eau animée, qui ne constitue pas une référence
+  de stabilité pour les blocs statiques.
+
+- Eau : suites fonctionnelles Vulkan et OpenGL réussies
+  (`build/beta146-water-vulkan.log`, `build/beta146-water-opengl.log`).
+  Profils, mélange 5/9/17, changement de contexte transmis par le serveur,
+  préférences séparées, immersion, fond modifié, océans, eau courante,
+  waterlogging et rechargement. OpenGL contrôle aussi l’égalité des couleurs
+  aux frontières des copies de région et avec l’échantillonnage de brume.
+- `./gradlew check build` exécuté dans un instantané isolé des sources :
+  252 tests serveur, 229 réussis et 23 échecs. Les identifiants des échecs
+  correspondent exactement au reçu archivé beta.145 ; aucun nouvel identifiant.
+  Il ne s’agit pas d’une nouvelle exécution comparative de beta.145.
+  Journal : `build/beta146-check-build-isolated.log` ; comparaison :
+  `build/beta146-server-failures.json`. Les derniers changements après cet
+  instantané concernent le rendu client, ses réglages et ses tests.
+
+Les preuves Vulkan finales sont dans `build/evidence/final-settings-vulkan/`.
+La suite de régression PBR et de préférences finale réussit
+(`build/beta146-final-pbr-preferences.log`) : PBR 80 %, SSR 20 %, persistance,
+migration des anciennes préférences, FR/EN, OFF/zéro et rechargement.
+La commande finale `./gradlew check build assemblePack -x :sanctuary:runGameTest`
+réussit (125 tâches), sans répéter la suite serveur isolée déjà exécutée.
+Journal : `build/beta146-final-build-pack.log`. Cette exclusion ne transforme
+pas les 23 échecs serveur en validation globale réussie.
+
+## Artefact local
+
+Le pack [Sanctuary-beta.146.mrpack](../build/Sanctuary-beta.146.mrpack) est exporté
+et copié dans le dossier `sanctuary-beta/build/`, à côté des autres versions.
+Intégrité ZIP, version beta.146, Minecraft 26.3 et identité du JAR embarqué
+avec le JAR construit contrôlées ; shaders finaux présents et identiques aux sources.
+Taille : 10 519 634 octets. SHA-256 :
+`9f3f7a840652d401741cbe3c85bbb5626326542179754cb599479b01a6b4c955`.
+Reçu : `build/beta146-artifacts.json`.
+
+Aucun benchmark isolé de performance de beta.146 n’est revendiqué : des
+contrôles serveur peuvent tourner simultanément. Les limites SSR hors écran,
+de maillage à grande portée et de compatibilité avec d’autres GPU subsistent.
+Aucune publication ou synchronisation Prism.

docs/relief-ecology-beta177.md

@@ -0,0 +1,196 @@
+# WG-ECO-177 — écologie liée au relief
+
+Branche `codex/relief-ecology-beta177`, base beta.176 `96433d3` conservée.
+Demande : nouveau test solo à 32 chunks intégrant les retours R019–R021.
+
+## Contrat
+
+Nouveau preset de laboratoire `sanctuary_test:relief_ecology_v1`, graine 42.
+Aucune migration ni réouverture des anciens laboratoires avec de nouveaux
+chunks. Les sauvegardes beta.175 et beta.176 restent conservées.
+
+- Plateau : forêts normales et plaines fleuries, sans bandes géographiques
+  automne/cerisiers. Classification par hauteur de surface et couverture.
+- Creux à ciel ouvert : automne. Hauteurs : cerisiers. Une élévation locale
+  autour d'un sommet existant crée un relief arboré, sous le plafond 320 ;
+  la roche profonde et les cinq récifs conservent le champ précédent.
+- Sous une couverture de roche : cavités humides, mousse, chêne noir et
+  champignons géants. Ne pas confondre sous-sol et vallée basse extérieure.
+- Marais sur un récif uniquement, aucune mangrove. Petits fragments hauts
+  sobres, sans tapis fleuri. Températures chaudes et aucune décoration de gel.
+- Géologie : conserver des strates lisibles, les interrompre avec des
+  gisements cohérents de pierre/andésite/granite/diorite ; deepslate profonde,
+  ressources conservées, aucun ajout d'or ni de redstone.
+- Mares locales, pas d'hydrologie régionale, pas de structures natives.
+  Villages et structures aériennes restent à concevoir, pas livrés ici.
+
+Le signalement « map cassée » reste sans symptôme précis : le créateur ne se
+rappelle plus s'il parlait de la carte opérateur ou du monde. Vérifier le
+chemin de lecture de l'atlas et les données du nouveau monde ; ne pas
+inventer de diagnostic ni modifier une interface sans défaut identifié.
+
+## Vérifications prévues
+
+Relevés natifs du relief, biomes à la surface et sous roche, végétation des
+cavités, eau après ticks, absence de neige/glace/mangrove, ciel 512–639 libre,
+répartition minérale sur toute l'île 42 et carte lisible depuis les chunks.
+Compilation, `check build`, assemblages, puis ouverture du solo Vulkan à
+32 chunks avec commandes. La visite peut commencer dès les contrôles du
+laboratoire terminés pendant que la suite générale continue, conformément
+à la préférence exprimée pendant la visite précédente.
+
+## Réalisation
+
+Le profil CLI `terrain` sélectionne ce nouveau preset. Les anciens profils
+gardent leur générateur. Tout le code de génération nouveau est dans le
+module facultatif `sanctuary-test` ; le preset Sanctuary normal est conservé.
+
+Le sélecteur de biomes partage une hauteur de surface par colonne de quatre
+blocs, mise en cache dans les limites de l'île. Une couverture de roche de
+plus de douze blocs prend priorité sur la tranche d'altitude : les grottes
+restent des cavités humides. À l'extérieur, les seuils initiaux sont Y≈237
+et Y≈264, avec une variation lente de trois blocs. Forêt et prairie fleurie
+se partagent la tranche intermédiaire par un bruit de grande échelle.
+Ces seuils sont des réglages de prototype, à juger pendant la visite.
+
+Un sommet existant parmi douze candidats proches du centre reçoit une
+élévation locale douce, de rayon 96 blocs, uniquement entre Y=216 et 319.
+Le relief profond et le champ des récifs beta.175 sont conservés. Les trois
+récifs bas reçoivent jungle, forêt et marais ; les deux fragments supérieurs
+restent sobres. Le ciel 512–639 reste réservé à l'ISS.
+
+Les biomes ont une température empêchant la neige aux altitudes du monde ;
+la décoration native `freeze_top_layer` est aussi retirée. Sous roche, les
+décorations natives de lush caves sont complétées par des tentatives bornées
+de chêne noir et de champignons géants dans les cavités existantes. Un arbre
+demande de l'air, un plafond de roche et un socle solide ; aucune salle n'est
+excavée. Le sol autour reçoit de la mousse, puis les features natives 26.3
+contrôlent et placent le végétal.
+
+Sous la transition profonde, les lits rocheux précédents sont conservés.
+Plus haut, deux bruits tridimensionnels forment des gisements d'andésite,
+granite et diorite, avec des régions de pierre ordinaire et d'autres où les
+strates restent visibles. Les minerais et mares utilisent les composants
+précédents ; leurs quantités réelles sont remesurées après décoration.
+
+## Reproduction
+
+```sh
+./gradlew :sanctuary-test:exportDuoLaunch
+python3 scripts/worldgen_lab.py prepare --profile terrain --seed 42 --run nouvel-essai
+python3 scripts/worldgen_lab.py server --profile terrain --seed 42 --run nouvel-essai --verify
+```
+
+Ajouter `--whole-island` à la préparation et au serveur pour le recensement
+intégral. Le lanceur refuse de réutiliser un monde dont l'empreinte des
+sources a changé. Les mesures sortent dans `relief-ecology-v1-cold` et
+`relief-ecology-v1-warm`. `scripts/ecology_atlas.py` rend cartes, coupes et
+recensement minéral à partir de ces données natives.
+
+## Mesures natives — graine 42
+
+Série `science177b`, Java 25 / Minecraft 26.3, heap serveur 1 536 MiB.
+[Atlas et coupes](/Users/koka/Documents/sanctuary/retours-sessions/2026-09-29_1506-storyquest/releves-beta177/graine-42/atlas.png)
+et [recensement minéral](/Users/koka/Documents/sanctuary/retours-sessions/2026-09-29_1506-storyquest/releves-beta177/graine-42/minerals.png).
+L'archive conserve données, coupes binaires, identité et journaux.
+
+| Contrôle | Résultat |
+| --- | ---: |
+| Densités profondes et aériennes identiques à beta.175 | 42 500 / 42 500 |
+| Témoins de biome sous couverture rocheuse | 358 / 358 en cavités humides |
+| Climats vérifiés contre la neige, neuf biomes × quatre altitudes | 36 / 36 |
+| Neige, glace et blocs de mangrove dans l'enveloppe recensée | 0 |
+| Végétaux natifs sous roche retrouvés dans les blocs | 8 chênes noirs, 3 champignons bruns, 6 rouges |
+| Mares générées / mares témoins stables pendant 240 ticks | 60 / 8 |
+| Ensembles de structures natives admissibles | 0 |
+| Plans hydrologiques régionaux calculés | 0 |
+| Air contrôlé en Y=512–639, autour des cinq récifs | 1 474 560 blocs |
+| Tuile d'atlas du spawn | 256 pixels lisibles, aucun chargement de chunk ajouté |
+
+La première tentative `science177a` avait été rejetée par le test des
+chênes noirs. Les critères d'espace et de socle ont été assouplis : quatre
+cases sous le tronc au lieu d'une fondation plane de six blocs de large,
+et précontrôle d'air moins large. Le test passe dans le nouveau monde,
+avec les vérifications natives des collisions conservées.
+
+La carte de surface échantillonnée tous les huit blocs contient 32,86 % de
+forêt, 24,87 % de prairie fleurie, 33,25 % d'automne et 8,36 % de cerisiers.
+Le reste, 0,66 %, correspond à de petits reliefs périphériques classés en
+vide par le sélecteur de surface. Ce ne sont pas des surfaces exactes au
+bloc près. Le sommet local atteint Y≈302 ; son centre est `(38, 296, 88)`.
+La proportion des vallées, les lisières et la silhouette restent à juger en jeu.
+
+### Ressources sur toute l'île
+
+Recensement réel de **2 000 chunks**, Y=0–639, après décoration, sans
+extrapolation des chunks du spawn. Variantes pierre et deepslate additionnées :
+
+| Ressource | Blocs |
+| --- | ---: |
+| Cuivre | 202 008 |
+| Charbon | 144 464 |
+| Fer | 5 592 |
+| Lapis | 7 139 |
+| Diamant | **304** |
+| Or | 0 |
+| Redstone | 0 |
+
+Tous les diamants sont en deepslate, sous Y=136, sans voisin d'air.
+Améthyste : 6 513 blocs ordinaires, 1 630 bourgeonnants et 269
+bourgeons/cristaux. La décoration et les nouvelles surfaces changent certains
+totaux par rapport à beta.176 ; aucune augmentation des paramètres de
+placement des minerais n'est faite dans ce lot.
+
+Réouverture : mêmes cartes de surface/récifs, mêmes palettes et coupes de
+blocs octet par octet, mêmes sources d'eau après 240 ticks supplémentaires.
+Les 17 végétaux témoins sous roche sont retrouvés. Ces résultats concernent
+la graine 42 ; aucune généralisation à toutes les graines n'est revendiquée.
+
+### Durées et portée
+
+| Passage | Initialisation serveur hors bootstrap JVM | Processus → fin du diagnostic |
+| --- | ---: | ---: |
+| Création et recensement intégral | 6,126 s | 317,799 s |
+| Réouverture et recensement intégral | 0,961 s | 41,350 s |
+
+Le recensement à froid prend 207,176 s. Ce coût de diagnostic ne tourne pas
+pendant la visite ; ces durées ont aussi été mesurées pendant les contrôles
+généraux du pack et ne constituent pas un benchmark isolé ni une mesure de FPS.
+
+## Solo et livraison
+
+Le client est entré dans `Sanctuary-Relief-177-Solo` le 29 septembre à
+22:07 CEST : serveur intégré, KokaLab à `(-9.5, 249, -4.5)`, backend Vulkan
+(MoltenVK 1.4.2 / Apple M1), distance de vue passée à **32 chunks** dans le
+journal. Commandes autorisées et mode créatif dans la copie neuve ;
+`/gamemode spectator` permet la visite libre. Les réglages de la visite
+beta.176 sont repris, shader de laboratoire désactivé. Les diagnostics ne
+sont pas activés dans le client.
+
+Le monde provient de la copie du serveur scientifique arrêté proprement
+après réouverture. Les anciennes sauvegardes sont conservées. Aucun canal,
+serveur personnel ni instance Prism n'est mis à jour.
+
+Repères d'observation en spectateur :
+
+| Lieu | Commande |
+| --- | --- |
+| Sommet à cerisiers | `/tp @s 38 318 88` |
+| Chêne noir de cavité | `/tp @s -89 168 119` |
+| Champignon rouge de cavité | `/tp @s 23 169 -57` |
+| Récif forêt, ancienne place de la mangrove | `/tp @s -102 430 -172` |
+| Récif marais | `/tp @s 219 470 22` |
+
+Compilation et diagnostics du laboratoire réussis.
+`./gradlew check build assemblePack assembleTestPack` : **BUILD SUCCESSFUL**
+en 25 min 50 s, **265/265 GameTests réussis**, contrôles statiques et smokes
+réussis. Le test de portage intermittent de beta.176 passe dans cette suite,
+sans modification du code des familiers ; son ancien échec n'est pas effacé.
+Versions, icône et hashes d'index du pack vérifiés ; distributions locales
+dans `build/packwiz` et `build/packwiz-test`. Journal complet archivé dans
+`releves-beta177/check-build.log`. Aucune nouvelle dépendance ajoutée.
+
+L'esthétique attend les retours de visite. Les grands plans d'eau, cascades,
+structures aériennes, villages Sanctuary et station ISS restent hors de ce lot.
+Le contrôle d'atlas vérifie la lecture des données ; il ne diagnostique pas
+le signalement imprécis « map cassée » ni l'ensemble de son interface.

docs/resourcepack-template-beta121.md

@@ -0,0 +1,125 @@
+# RP-02 — Clé dorée et pack personnel — beta.121
+
+Contrat du 17 septembre 2026, branche `codex/resourcepack-template-beta121`.
+Le créateur fournit `golden_wrench.png` et valide un bouton qui crée une copie
+personnelle complète, modifiable et jamais écrasée par les mises à jour.
+
+## Résultat
+
+La clé dorée reprend exactement le PNG fourni, 16 × 16, sans conversion ni
+redessin. Le modèle reste un item plat `minecraft:item/handheld`. Empreinte :
+`a97570908db75caf8e6fc2f5ecabf12c54fd99bfea7be634df66c4310dca22af`.
+Le même fichier est fourni par le mod et par « Textures Sanctuary » ; désactiver
+le pack intégré conserve donc aussi la nouvelle clé.
+
+Dans **Options → Packs de ressources**, **Personnaliser Sanctuary** crée
+`resourcepacks/Sanctuary-Custom/`. Le bouton devient **Ouvrir ma copie**.
+La copie contient toutes les ressources client de Sanctuary : textures, modèles,
+étiquettes d'items, blockstates, sons, shaders, langues et remplacements Minecraft
+présents dans le pack intégré. Celui-ci prend priorité sur les assets de base
+lors de l'export. Un guide FR/EN, la licence et les crédits accompagnent la copie.
+
+Le joueur active sa copie avec les commandes natives et la place au-dessus des
+packs qu'il veut remplacer. Créer la copie ne change ni l'ordre ni la sélection.
+Une modification se recharge avec F3 + T ; désactiver le pack retrouve les
+ressources fournies par le mod. L'écran de sélection des datapacks n'est pas modifié.
+
+La copie est un **instantané**. Elle ne se synchronise pas avec les mises à jour :
+les fichiers personnalisés restent toujours intacts. Le guide recommande de
+supprimer les fichiers non personnalisés pour laisser les prochaines ressources
+du mod s'appliquer. Pour repartir d'un instantané récent, renommer le dossier
+existant puis créer une nouvelle copie. Aucun fichier utilisateur n'est écrasé.
+
+La copie s'effectue hors du fil de rendu, dans un dossier temporaire voisin,
+puis le résultat complet rejoint la liste native. Une erreur de copie est
+signalée par le bouton et le journal du jeu ; un chemin occupé par un fichier
+n'est pas remplacé. Aucune extraction au démarrage ni pendant les mises à jour.
+
+## Distribution
+
+`./gradlew assembleResourceTemplate` produit
+`build/Sanctuary-Template-beta.121.zip`, un pack personnel complet à décompresser
+dans `resourcepacks/Sanctuary-Custom/`. `assemblePack` le produit aussi.
+`build/Sanctuary-Resource-Pack-beta.121.zip` reste l'export du pack graphique
+intégré ; son manifeste versionné contient 151 fichiers et les images historiques
+sont conservées. L'identifiant intégré `sanctuary:textures` reste stable et son
+activation reste contrôlée par le joueur.
+
+Le template ne contient pas tous les assets vanilla ni ceux des autres mods.
+Il ne contient pas les recettes, règles serveur ou sauvegardes. Il conserve
+les crédits et conditions des ressources d'origine. Aucune génération, aucun
+identifiant de bloc et aucun format de sauvegarde ne changent.
+
+## Vérifications
+
+Le parcours `ResourceTemplate121ClientChecks` passe en **35 s** sur le client
+Minecraft 26.3 macOS, sans ouvrir de monde :
+
+- Bouton natif et disposition FR/EN aux échelles 2 et 3, captures relues.
+- Export complet de **1 202 fichiers**, empreintes identiques aux ressources
+  sources après application des priorités du pack intégré.
+- PNG fourni vérifié par SHA-256 et affiché avec sa transparence.
+- Création sans changer la sélection ni l'ordre des packs.
+- Modification d'une texture et ajout d'un fichier personnel : aucun octet
+  réécrit lors d'un second export ni au rechargement des ressources.
+- Priorité réelle de la texture personnalisée, puis retour à la clé fournie
+  après désactivation. Activation et désactivation conservées à la redécouverte.
+- Chemin occupé par un fichier refusé sans le modifier ; aucun bouton ajouté
+  à l'écran des datapacks.
+
+```sh
+./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryResourceTemplate121ClientTests=true \
+  -PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true
+```
+
+Marqueur `TEMPLATE121_PASS` dans `build/template121-client.log` ; captures et
+empreintes de la copie dans `build/template121-evidence/`. Le premier essai
+avait échoué dans l'aperçu du test qui créait un ItemStack avant connexion à
+un monde ; cet aperçu affiche maintenant directement la texture résolue.
+Le modèle plat existant n'est pas modifié. Pas d'essai Windows ni d'ouverture
+automatisée du gestionnaire de fichiers. Le GameTest serveur 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 10 s**, 126 tâches. Les sources JAR correspondent aux sources
+Java du dépôt. La comparaison avec beta.120 limite les différences de production
+aux deux nouvelles classes, au hook d'interface, aux libellés et aux ressources
+prévues (12 entrées). Aucun changement de gameplay, de données serveur ou de
+monde. Les packs normal/Test contiennent le même JAR Sanctuary, sans fixture
+ni sauvegarde. Le ZIP du template et l'export natif ont exactement les mêmes
+1 202 fichiers et empreintes. Le pack intégré conserve ses 151 fichiers vérifiés.
+
+Reçu : `build/template121-artifact.json`. Artefacts locaux validés :
+
+- `Sanctuary-beta.121.mrpack` : 10261791 octets, SHA-256
+  `040d68f342155120fa21e0ffcdf34aa38e3225c78862960536622de53ed9fd9f`.
+- `Sanctuary-Test-beta.121.mrpack` : 10280716 octets, SHA-256
+  `7f5bbd4e13aea4c245d072725c094ca64826ee8debc8607623783c114d437685`.
+- `Sanctuary-Resource-Pack-beta.121.zip` : 3757952 octets, SHA-256
+  `bbf3c18ea6abc64d951911215975cb6c48c7fc5e0246f6e5f5192a3d061c211d`.
+- `Sanctuary-Template-beta.121.zip` : 4315131 octets, SHA-256
+  `6fad376c53474fa8bcb0a2e6ae4c13ea61ab91bdd78735be443032d485ed541a`.
+
+JAR Sanctuary : SHA-256
+`4276f4fc9834805e3e6d12cd19adba7837e3007656b77f31d525c7b976f9925d`.
+
+## Publication et installation
+
+La [release beta.121](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.121)
+est publiée depuis `d9b3dd6bedf32448f8c6e5bfa4da10cb69968bc7`. Tag et artefacts immuables,
+téléchargements publics vérifiés. Canal packwiz :
+`e3e6572da9288fbbcfa36bf6b7dd3aa0d1c54f5e`.
+
+Deux synchronisations isolées puis deux dans **Sanctuary Beta** réussissent.
+Un seul JAR Sanctuary beta.121 est actif ; le second passage est identique.
+Les **923 fichiers personnels et réglages suivis** restent inchangés,
+y compris les packs de ressources. Aucune copie personnelle n'est créée par
+la mise à jour : chaque joueur utilise le bouton quand il le souhaite.
+Aucun monde personnel ouvert. Copie préalable dans
+`sanctuary-backups/before-beta.121/` de l'instance existante ; reçus
+`build/template121-isolated.json` et `build/template121-prism.json`.
+
+- [Template personnel complet](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.121/Sanctuary-Template-beta.121.zip).
+- [Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.121/Sanctuary-beta.121.mrpack).
+- [Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.121/Sanctuary-Test-beta.121.mrpack).

docs/restore-relief-beta191.md

@@ -0,0 +1,61 @@
+# WG-RESTORE-191 — revenir avant les plateaux
+
+Branche `codex/restore-relief-beta191`, Minecraft 26.3, graine de visite 42.
+Nouveau profil `original`, preset `sanctuary_test:pre_terraces_v1`.
+
+## Contrat
+
+Le retour beta.190 rejette toujours le relief et les affleurements ajoutés depuis
+les plateaux. Restaurer exactement le champ de densité **beta.188**, avant les
+terrasses beta.189 et les épaules beta.190. Retirer leurs passes d’affleurements
+et leur exclusion d’arbres sur ces affleurements. La géologie d’origine retrouve
+sa responsabilité : pierre, strates, gisements, cavités et pointes existantes.
+
+Conserver les corrections indépendantes appréciées : ancres au sol, berges,
+cascade large, galerie éclairée et coffres de fer enchanté dans les ruines.
+Cela restaure le relief et la géologie de base, pas tous les blocs d’un monde
+beta.188 puisque ces aménagements récents restent présents.
+
+L’intention pour la suite est un récif avec creux, cavités et pointes, avec
+quelques formations singulières par endroits. Aucun nouveau lissage, plateau
+ni déformation généralisée dans cette remise à plat du travail.
+Les variantes 189/190 restent des références conservées, hors de ce nouveau profil.
+Nouveaux mondes seulement ; aucune sauvegarde existante modifiée ou régénérée.
+
+## Vérifications
+
+Génération et réouverture natives réussies, graine 42 :
+`build/original191a-cold.json` et `build/original191a-warm.json`.
+
+- **134 480 densités identiques** aux paramètres enregistrés de beta.188, de
+  Y=0 à Y=632 sur l’île et ses îlots ; aucun remappage de hauteur activé.
+- Passes d’affleurements 189/190 court-circuitées dans ce profil. Leur masque
+  est inactif sur les 1 681 colonnes contrôlées ; la règle de géologie d’origine
+  et les plantations natives reprennent la surface hors des aménagements réservés.
+- Comparaison au commit beta.188 `658aaf8` : corps du calcul de densité, paramètres
+  de bruit, îlots aériens et règle de géologie identiques. Preuve locale :
+  `build/original191-baseline-receipt.json`.
+- Huit ancres, 49 cartes et cadres du palais, salle inférieure et éclairage,
+  quatre ruines avec coffres enchantés, donjon, gemmes et soufre contrôlés.
+- Cascade de cinq blocs de large conservée, chenal de 4–5 blocs et huit blocs
+  de roche retirés ; aucune nouvelle déformation de montagne pour la produire.
+  Zéro tronc dans les colonnes contrôlées des bassins et berges.
+
+Démarrage natif : 12,281 s à froid et 0,738 s à chaud ; avec tous les contrôles
+et le remplissage des cartes : 79,283 s / 22,798 s. Zéro région d’hydrologie.
+Ces contrôles de laboratoire ne sont pas lancés au démarrage du solo.
+
+`./gradlew check build assemblePack assembleTestPack` réussi en **7 min 40 s**,
+**265 GameTests réussis**. Le JAR est identique aux classes et ressources compilées
+et à sa copie distribuée dans le pack de test : `build/original191-pack-receipt.json`.
+Aucune publication ni modification de l’installation Prism. Le client Vulkan est lancé avec la nouvelle
+sauvegarde `Sanctuary-Original-Relief-191-Solo`, run `visite191`, profil `original`,
+vue 32 et simulation 12, spectateur, commandes autorisées, position préparée
+(94,316,153) face au relief. Connexion confirmée à **21:46:39**, vue 32 et simulation 12 ; Vulkan confirmé.
+Les cartes et l’état initial des ancres ont été relus dans cette copie neuve.
+Les sauvegardes 188/189/190 restent conservées.
+
+
+Le créateur a confirmé l’ouverture ; la connexion est vérifiée dans
+`build/original191-solo.log`. Cette confirmation porte sur l’entrée dans le solo,
+pas encore sur l’appréciation esthétique du terrain restauré.

docs/revue-pr1-chris-beta165.md

@@ -0,0 +1,91 @@
+# Revue PR #1 de Chris — intégration sur beta.165
+
+PR : [beta.144 — Code d’accès à la création Hello World](https://git.botsu.net/koka/sanctuary-beta/pulls/1).
+Révision examinée : `8de569bbf188f7b76ede9235d3a2e5449907bcd5`.
+Socle local : beta.165 + audit documentaire ; les corrections de GameTests restent
+un chantier distinct. Dépôt web local examiné : `sanctuary-web-community`, commit
+`1feab73`. Vérification du distant web après fetch : `6640966b7306b36735c622cc4e75f31467e6f249`, aucun écart sur `AccessCodeService.php` et `routes/api.php`. Inventaire API : une PR mod ouverte, aucune PR web ouverte.
+
+## Verdict
+
+**Intégrable, mais ne pas fusionner telle quelle.** Le principal blocage est la
+reprise après consommation du code côté site. Aucun merge distant, publication,
+activation du contrôle d’accès ou commentaire à Chris n’a été effectué.
+
+## Constats
+
+### P1 — code consommé sans possibilité de reprendre l’accueil
+
+Dans `ProgressionService.java` de la PR, lignes 375–382, le serveur appelle
+`redeem` puis ignore le résultat si la session s’est déconnectée avant le retour.
+Le site peut donc avoir consommé le code alors que le ledger local n’a jamais
+été écrit. Une coupure réseau après consommation, avant réception de la réponse,
+produit la même fenêtre.
+
+Le site actuel (`AccessCodeService.php:71–72`) répond `already_used` sans
+`minecraft_username` ni `discord_id`. `AccessCodes.redeem` exige ces champs pour
+la reprise et refuse donc. De plus, même si le site est corrigé pour les renvoyer,
+`AccessCodes.verifyKey:50` transforme encore tout `already_used` en `code_used` ;
+`HelloWorldScreen.updateSelection` ne permet de confirmer que `code_recognized`
+ou un pending local. La réparation doit donc couvrir **le site, le serveur et
+le parcours client**, pas seulement ajouter deux champs à la réponse API.
+
+Correction recommandée : un contrat de consommation rejouable pour le même compte
+et la même admission, avec identité confirmée par l’API serveur authentifiée ;
+réconciliation du résultat après déconnexion et reprise au prochain accueil.
+Un code révoqué, un autre compte et une requête non autorisée doivent rester
+refusés. Vérifier l’identité complète et la portée du reçu avant de l’accepter.
+Le ledger ne doit jamais conserver le code brut ni le jeton API.
+
+La documentation actuelle de la PR dit qu’une déconnexion avant `redeemed`
+ne consomme pas le code : ce n’est pas garanti dès que le POST est parti.
+Le smoke teste un ledger après `remember`, pas la fenêtre avant cette écriture.
+
+### P2 — compatibilité des clients existants à expliciter
+
+Le nouveau contrôle de capacité `AccessPayloads.Gate` dans CONFIGURE est placé
+avant la recherche de l’habitant. Activer l’accès impose donc aussi la mise à
+jour des clients des habitants déjà enregistrés. La promesse « habitant existant
+entre sans écran » ne signifie pas compatibilité avec un ancien client.
+Décider et tester ce contrat avant activation : mise à jour coordonnée ou
+capacité exigée uniquement pour les accueils qui utilisent le code.
+
+## Compatibilité avec nos changements
+
+`git merge-tree --write-tree HEAD origin/pr-1` a été exécuté sans changer le
+checkout. Trace ignorée : `build/pr1-merge-tree.txt`.
+
+- Conflits textuels uniquement dans `gradle.properties` et `packwiz/pack.toml`.
+  **Ne pas reprendre beta.144** : réserver le prochain numéro libre au moment
+  de la livraison, synchroniser les manifestes et garder les archives existantes.
+- Les changements de progression et Hello World s’appliquent sans conflit textuel
+  au socle examiné. Cela ne constitue pas une preuve de compatibilité fonctionnelle.
+- Pas de changement proposé aux tables communautaires ou aux pages Gazette/Tableau.
+  L’admission appelle une API HTTP du site ; elle n’utilise pas directement le
+  stockage des publications. Tester quand même fichier et MariaDB en régression.
+- Sans URL/jeton, la fonctionnalité se désactive. Le laboratoire actuel ne doit pas
+  être activé implicitement : ses comptes locaux doivent rester accessibles.
+- Le ledger ajoute `data/sanctuary-access.json` sans réécrire le registre des
+  habitants. Prévoir sauvegarde et comportement de retour arrière avant activation.
+
+## Plan d’intégration concret
+
+1. Finaliser et enregistrer les corrections de tests séparément.
+2. Préparer une branche d’intégration depuis ce socle et importer le changement
+   de Chris, en résolvant uniquement les numéros de version puis les adaptations
+   réellement nécessaires. Conserver son attribution.
+3. Corriger et documenter ensemble le contrat de reprise site/mod ; écrire les
+   tests du POST consommé avec réponse perdue et déconnexion concurrente.
+4. Valider l’accueil sans configuration, l’accueil configuré neuf, un habitant
+   existant, client ancien, code invalide, mauvais pseudo, code révoqué, panne
+   du site, jeton rejeté, deux confirmations et redémarrage entre les écritures.
+   Vérifier qu’un seul habitant et un seul familier sont créés et qu’aucun coût
+   n’est dupliqué.
+5. Jouer le parcours réel sur un serveur jetable avec API de test, puis rejouer
+   les échanges Gazette/Tableau en fichier et MariaDB. Garder le site public
+   communautaire en lecture seule.
+6. Livrer et taguer le nouveau compteur ; activer seulement sur le serveur
+   explicitement visé, après configuration et sauvegarde.
+
+Pas de compilation ni d’essai de handshake de cette PR revendiqués ici.
+La suite en cours concerne les tests actualisés de beta.165, pas le code de Chris.

docs/rocky-ecology-beta178.md

@@ -0,0 +1,30 @@
+# WG-ECO-178 — vallées bornées et grottes minérales
+
+Retour de visite beta.177 : automne trop envahissant sur le plateau et les
+bords, cavités trop uniformément lush. Le créateur précise : roche dominante,
+petites eaux et mousse localisée ; priorité au solo, sans nouveaux atlas.
+
+Branche `codex/rocky-ecology-beta178`, base `9613322`. Nouveau preset de labo
+`sanctuary_test:rocky_ecology_v1`, profil CLI `rocky`, graine 42. Aucune
+migration : le solo beta.177 ouvert reste sur son ancien générateur.
+
+Automne limité aux sols Y=200–232, entourés de relief plus haut et sans
+chute périphérique. Sous Y=200 et sur les flancs raides : géologie exposée.
+Les grottes gardent surtout leur roche ; mousse en plaques, poches végétales
+rares, petits bassins retenus et décorations de stalactites. Les bosquets de
+chênes noirs/champignons restent ponctuels. Relief, récifs, minerais et
+absence d'hydrologie régionale conservent leurs composants précédents.
+
+Contrôles ciblés de chargement et du comportement modifié avant le nouveau
+solo ; `check build assemblePack assembleTestPack` exigé pour la livraison.
+Pas de recensement complet ni de cartes scientifiques dans cette passe.
+Contrôle natif `solo178d`, graine 42 : réussi, 567 comparaisons de densité
+identiques au socle profond, aucun calcul d’hydrologie régionale. Dans les
+neuf chunks centraux contrôlés, 380 sols rocheux sur 405, 23 en mousse et
+cinq sources d’eau observées ; ce petit échantillon ne décrit pas toute l’île.
+
+Solo neuf `visite178/rocky/42`, sauvegarde `Sanctuary-Rocky-178-Solo`,
+vue 32, simulation 12, commandes activées. Compilation et `check build assemblePack assembleTestPack` réussis
+(23 min 35 s, résultat du 29 septembre). Aucun ancien monde ni canal de distribution modifié.
+Ouverture confirmée le 29 septembre à 22:47 : Vulkan sur Apple M1,
+KokaLab connecté en solo et distance serveur passée à 32 chunks.

docs/runtime-expansions-beta199.md

@@ -0,0 +1,143 @@
+# EXP-199 — affiner les expansions et les raccorder au laboratoire
+
+Branche `codex/runtime-expansions-beta199`, depuis beta.198. Retour R014.
+Implémentation et validation locales ; aucune publication du canal packwiz ni mise à jour de Prism.
+
+## Contrat retenu
+
+Réutiliser `ExpansionJournal`, `ExpansionRuntime`, les contrôles d'occupation,
+les contextes de bruit natifs et les biomes d'expansion existants. Les ancres
+actuelles du laboratoire doivent désormais demander une vraie expansion.
+Recherche automatique sur 360°, priorité à la proximité du parent parmi les
+sites admissibles, une région immuable par relais, et un nouveau relais sur
+chaque région prête. Relief fin : surface large et ondulée, quelques plateaux
+souples, volumes amincis en conservant les cavités du bruit 3D.
+
+Les lectures d'admission et la préparation native sont échelonnées entre les
+ticks. Annonce SGA aux joueurs seulement après les chunks FULL et le relais.
+Les doubles activations ne créent ni second continent ni double prélèvement.
+La sauvegarde reprend une région réservée après interruption.
+
+## Contrat de nouveaux mondes
+
+Les profils 196–198 gardent leurs paramètres et leurs ancres de démonstration.
+Les nouveaux profils 199 initialisent un journal d'expansions propre. Aucun
+ancien monde n'est migré, aucun chunk existant régénéré, aucun ancien format
+réécrit. Première admission limitée aux régions réellement vierges ; même du
+vide déjà généré reste protégé. Cette contrainte peut éloigner une expansion
+si le joueur a déjà exploré les alentours ; ce n'est pas une promesse de
+contact bord à bord. La réutilisation du vide certifié reste le mécanisme
+historique distinct, à ne pas activer implicitement dans une partie.
+
+## Ciel et performance
+
+Rotation stellaire : sept journées Minecraft, sur l'horloge du monde faisant
+autorité ; conserver la même transformation pour la visée et les constellations.
+Les saccades sont également signalées à l'arrêt, y compris shader Sanctuary désactivé (confirmation du créateur). Aucune cause n'est attribuée
+au worldgen sans mesure ; préserver cette enquête séparément du réglage des
+expansions. Les débordements de mares restent consignés sans nouvelle refonte.
+
+## Première tranche jouable
+
+Le relais demande les mêmes huit offrandes distinctes que le laboratoire. Le
+joueur reste à proximité, offrande en main, pendant la recherche. Les matériaux
+ne sont retirés qu'après réservation durable. Une seule préparation est active
+à la fois ; chaque relais ouvre une région de diamètre nominal 256 blocs, avec
+un relais de continuation. Le climat suit la couleur du relais d'origine ; la
+position réelle est choisie automatiquement parmi 64 angles, par distances
+croissantes sur la grille de chunks. Le relief réutilise la densité 3D historique,
+comprimée verticalement autour de Y=220 et déformée par son bruit cohérent.
+
+Les biomes naturels décorent ces nappes. Les villages et forteresses vanilla ne
+sont pas réactivés par l'ajout de ces biomes à la palette : leurs structures
+seront une tranche distincte. Les structures et reliefs de l'île centrale sont
+conservés. Pour Small/42, une recherche locale plus précise peut retrouver les
+sols d'ancres manqués par la grille historique ; les réservations d'eau suivent
+alors leurs emprises réelles avec marge au lieu d'exclure un secteur entier.
+
+Le moteur conserve son journal et sa file native, avec un adaptateur réservé aux
+profils 199. Admission : 32 lectures asynchrones au maximum par lot, contrôle des
+chunks chargés et des sauvegardes concurrentes, mémorisation des refus
+pour éliminer les candidats qui recouvrent un chunk déjà trouvé occupé, puis réservation et publication
+sur le même tour serveur. Le relais suivant est placé après les chunks FULL ;
+l'annonce SGA possède une infobulle lisible donnant ses coordonnées.
+
+Limites : pas de régénération du vide déjà exploré, pas de choix de direction,
+pas encore de variation du prix/taille pour les relais successifs. La limite
+historique reste de 64 régions, Sanctuary incluse. Le journal et l'inventaire
+joueur sont deux fichiers Minecraft distincts : la protection contre le double
+clic ne constitue pas une transaction atomique entre ces fichiers lors d'une
+coupure brutale au milieu d'une sauvegarde.
+
+## Périmètre de validation
+
+Placement proche sur tous les angles et refus des emprises occupées, densités
+bornées et nappes fines, horloge stellaire cyclique, activation réelle, deuxième
+relais, double interaction, interruption/reprise et notification après FULL.
+`check build`, assemblages et essai client Vulkan avant livraison locale.
+
+## Relevés de validation
+
+- Compilation et assemblages : `check build assemblePack assembleTestPack`,
+  avec les suites natives `operator,realtime`, réussis (7 GameTests et contrôles
+  purs). La vérification du placement couvre 9 couples graine/taille : 0, 42 et
+  4736390610738281858 × Small/Medium/Large, les huit secteurs, l'ordre de distance,
+  les conflits et la réouverture du journal.
+  Dernier passage complet : `build/expansion199-check-build-delivery.log`,
+  réussi en 3 min 40 s. Compilation finale des tests client réussie également.
+- Nouveau Small, graine 42, 2 Gio : serveur prêt vers 14,2 s ; première expansion
+  au centre (368, -368), relais Y=231, après 418 chunks FULL. Le deuxième relais
+  réserve son enfant environ 11 s après l'annonce du premier. L'arrêt volontaire
+  a lieu avec cet enfant encore réservé. Cette durée inclut les essais et n'est
+  pas le temps normal de création d'un monde.
+- Journaux finaux : `build/expansion199-check-build-final.log` et
+  `build/worldgen-lab/expansion199-native-final/small/42/`. Les premiers essais
+  interrompus restent conservés et ne sont pas des validations.
+- Réouverture du même Small/42 : enfant repris, 418 chunks FULL, relais
+  (912, 236, -368), une seule annonce pour cet enfant et aucune répétition de
+  celle du parent. Sur 81 colonnes échantillonnées, 1380 blocs non vides, entre
+  Y=191 et Y=275 (végétation comprise) : ce relevé local ne mesure pas le volume
+  total de toutes les expansions.
+- Client Vulkan, Small/42 : arrivée sur l'île, synchronisation native des étoiles
+  et pause de l'horloge, vraie interaction du joueur avec le relais, double clic
+  sans double prélèvement. Un bloc d'or placé dans le premier candidat reste
+  intact et force l'admission d'un autre emplacement. Les interfaces FR/EN,
+  trois tailles, profils historiques et aller-retour disque passent également.
+- Deux essais client consécutifs terminent l'expansion puis sauvegardent et
+  ferment normalement (`build/expansion199-client-pass-a.log` et
+  `build/expansion199-client.log`). Le tout premier essai avait réussi les
+  assertions puis rencontré une exception dans `ChunkMap.tick`, lors du suivi
+  des entités. Cause non isolée : un contrôle de réentrance et 100 ticks
+  d'observation supplémentaires n'ont pas reproduit le défaut. Ce résultat
+  n'est pas un correctif prouvé du crash initial. Pas d'essai direct Windows.
+
+### Saccades : capture locale, cause non isolée
+
+Première capture client macOS Vulkan, Small/42, vue 8 chunks, shader désactivé, joueur immobile :
+1241 images relevées, médiane 31,15 ms (limitation de cadence de l'environnement
+de test), P95 33,12 ms, P99 33,71 ms, maximum 98,01 ms, 7 images au-delà de 50 ms.
+258 sections ont encore été compilées pendant la capture. Le JFR contient 4152
+échantillons de workers dans la génération, et des pauses GC jusqu'à 88,45 ms.
+Le joueur immobile ne signifiait donc pas que le chargement avait terminé.
+Ce relevé n'isole pas les saccades d'une partie complètement stabilisée, et ne
+prouve pas leur cause chez le créateur. Le shader n'est pas nécessaire pour
+reproduire quelques images longues dans cet environnement. Aucun correctif
+général des saccades n'est revendiqué dans cette livraison.
+
+Mesures ignorées par Git :
+`build/expansion199-stationary-first/stationary.json` et `stationary.jfr`.
+Les captures suivantes restent sous
+`mods/sanctuary/build/run/clientGameTest/diagnostics/expansion199/`.
+Pas de nouvelle campagne de screenshots.
+
+## Livraison locale
+
+`Sanctuary-Test-beta.199.mrpack`, 12 322 965 octets, copié dans
+`/Users/koka/Downloads/` avec `Sanctuary-Test-beta.199-Guide.txt`.
+SHA-256 : `fd2ebe4f43bf0d455377a2f456106165ff5e3519e5c3dce4126818c03f4ae44f`.
+
+Intégrité ZIP, manifeste Minecraft 26.3/Fabric Loader 0.19.5, dépendances externes,
+JAR intégrés comparés aux classes compilées et anciennes ressources vérifiés.
+Les 142 ressources historiques de génération restent identiques à beta.198 ;
+le preset public vise désormais 199. Reçu : `build/expansion199-artifact.json`.
+Le canal packwiz et l'installation Prism n'ont pas été modifiés.

docs/sculpture-bounds-beta124.md

@@ -0,0 +1,93 @@
+# SCULPT-10 — Une boîte par sculpture — beta.124
+
+Contrat du 17 septembre 2026, branche `codex/sculpture-bounds-beta124`.
+Le créateur choisit **une seule boîte pour la sélection et les collisions**.
+Ce ticket remplace la forme physique détaillée de beta.122.
+
+La boîte englobe exactement les dimensions occupées par la sculpture, après
+orientation et ancrage au centre ou au bord. Elle suit toujours la grille 1/16,
+y compris les tailles impaires et les modèles comportant des marges vides.
+Les trous et petits détails restent visibles mais n'ont plus leurs propres
+surfaces de collision : on ne grimpe plus sur leurs petites marches. Une arche
+se sélectionne et bloque désormais sur tout son volume englobant.
+
+La pose utilise la même boîte avant la création de l'entité de bloc : elle
+refuse une intersection avec le joueur, y compris dans les trous visuels.
+Les petites sculptures laissent libre le reste du bloc autour de leur boîte.
+La forme reste mise en cache par modèle et état ; elle ne se recalcule qu'après
+un changement de modèle, d'orientation ou d'ancrage. Les requêtes physiques et
+le contour partagent cette même forme native.
+
+Le calcul parcourt les cellules une seule fois, sans créer de copies tournées
+ni de grille de collisions 16³. Le contour émet toujours douze arêtes.
+Il s'agit d'une simplification du travail géométrique ; aucun gain de FPS global
+n'est annoncé sans mesure sur une scène représentative.
+
+Le rendu des sculptures et les règles de lumière de beta.122 restent inchangés :
+pas d'occlusion de cube plein, pas d'émission artificielle de lumière. Aucun
+identifiant, format d'item ou de sauvegarde ne change. Les anciennes sculptures
+utilisent la nouvelle forme à partir de leurs données existantes, sans réécriture
+des mondes ni régénération de chunks. L'atelier et les clés restent inchangés.
+
+## Vérifications
+
+Le parcours `Sculpture122ClientChecks`, adapté au nouveau contrat, passe en
+**39 s** sur Minecraft 26.3, client macOS et serveur intégré jetable de graine 122.
+
+- Sélection native de tout le volume, y compris le trou visuel d'une arche ;
+  contour rectangulaire relu dans la capture.
+- Même boîte physique et de sélection sur client et serveur ; intérieur rempli,
+  dimensions exactes sans profondeur artificielle de bloc entier.
+- **80 cas** : boîte unique comparée aux limites du maillage réellement émis,
+  douze arêtes exactement, même objet réutilisé lors des requêtes répétées.
+  Arche, marges vides, cube de 4 096 cellules et voxel unique, dans les quatre
+  orientations et cinq ancrages.
+- **5 120 placements** de rendu toujours alignés sur la grille entière.
+- Pose refusée dans le joueur, y compris entre deux piliers séparés ; petite
+  sculpture autorisée à côté du joueur, hors de sa boîte physique.
+- Cache renouvelé après changement d'orientation/ancrage ou de modèle ;
+  conservation après sauvegarde/reconnexion.
+- **75 sculptures superposées** : ciel à 15 ; toit de pierre témoin sombre ;
+  lumière de bloc transmise avec atténuation normale ; pièce close à 0.
+
+Marqueurs dans `build/sculpture124-client.log`, notamment
+`SCULPTURE124_BOUNDS_PASS 80`, plus les contrôles de régression de beta.122.
+Captures relues dans `build/sculpture124-evidence/`. Aucun essai Windows,
+client distant ou shader tiers ; le coût des boîtes est simplifié sans benchmark
+FPS global.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+passe en **2 min 9 s**, 126 tâches (110 exécutées, 16 à jour).
+Les sources des JAR correspondent aux sources du dépôt. La comparaison avec
+beta.123 limite les différences de production aux trois classes de
+`SculptureGeometry` ; ressources, clés, interfaces, données et éclairage restent
+identiques. Les packs normal/Test contiennent le même JAR, sans sauvegarde
+ni fixture. Le template personnel conserve exactement les ressources de beta.123.
+
+- Pack normal : 10 271 059 octets, SHA-256
+  `2075e4ac7a7e7e2effcd82586d46769607ca1a67e8d9110b000fa378d1bc5506`.
+- Pack Test : 10 289 985 octets, SHA-256
+  `88263e6896590ea9694b18084666e7234e934064e8d7d596d34866a68cc5ea23`.
+- JAR Sanctuary : SHA-256
+  `b3969b1a3738b8a5d332b2083db0dd722900239f73035c335b738f70328d43f1`.
+
+Reçu local : `build/sculpture124-artifact.json`. Les packs normal/Test et le
+template sont aussi copiés, avec vérification octet pour octet, dans le dossier
+habituel `sanctuary-beta/build/`.
+
+Le GameTest dédié reste exclu conformément au refus antérieur de son EULA.
+Aucun monde personnel n'est ouvert par les essais.
+
+## Publication et installation
+
+La [release beta.124](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.124)
+est publiée depuis `00179e30ef0b45ef98378bc164a7810552dd1bdd`.
+Le tag exact et les artefacts sont immuables, leurs téléchargements publics
+vérifiés. Canal packwiz : `67ebcc7d07f8b75e8988f6099e3d6e5704f123fb`.
+
+Deux synchronisations isolées puis deux dans **Sanctuary Beta** réussissent.
+Un seul JAR Sanctuary beta.124 est actif, conforme au hash vérifié ; le second
+passage ne change rien. Les **923 fichiers personnels et réglages suivis**
+restent inchangés, sans ouverture de monde personnel. Copie préalable dans
+`sanctuary-backups/before-beta.124/` de l'instance existante.
+Reçus : `build/sculpture124-isolated.json` et `build/sculpture124-prism.json`.

docs/sculpture-center-beta119.md

@@ -0,0 +1,84 @@
+# STAT-07 — Pose centrée des sculptures — beta.119
+
+Contrat du 17 septembre 2026, branche `codex/sculpture-center-beta119`.
+
+Viser le carré central de 8 × 8 pixels de la face supérieure ou inférieure
+du bloc place la sculpture au centre. Les limites de cette zone sont incluses.
+Autour, le bord horizontal le plus proche reste choisi ; une pose latérale
+continue à s'appuyer contre le bloc support. L'orientation suit le regard.
+L'aide du Clay Workshop explique les deux possibilités en français et anglais.
+
+Le centrage utilise l'emprise réelle des voxels après rotation, en ignorant les
+marges transparentes. Tous les sommets restent sur la grille de 1/16 de bloc.
+Une dimension impaire ne peut pas être parfaitement symétrique dans un bloc de
+16 pixels sans décaler ses voxels : elle prend donc le centrage entier le plus
+proche, avec un pixel de différence entre les deux marges. Aucune position à
+un demi-voxel n'est introduite.
+
+## Compatibilité
+
+La pose réutilise `anchor=center`, déjà présent depuis beta.113. Aucun nouvel
+état, identifiant, composant ou format de sauvegarde. Les sculptures existantes
+gardent leur ancrage ; casser et reposer choisit l'emplacement visé. Le rendu,
+les couleurs, les chapeaux et les collisions restent inchangés. Aucun parcours
+de monde existant, aucune régénération. Client et serveur doivent utiliser
+ensemble la nouvelle version pour le choix de pose.
+
+## Vérifications et livraison
+
+Le parcours natif `Statuary106ClientChecks`, avec `Sculpture113ClientChecks`,
+passe en **54 s** sur Minecraft 26.3/macOS :
+
+- Vrais clics de pose centrée dans quatre orientations, sur client et serveur,
+  puis pose contre les quatre bords sans modifier les couleurs du modèle.
+- Limites incluses et points immédiatement de part et d'autre de la zone,
+  faces supérieure/inférieure et positions positives/négatives ; faces
+  latérales toujours calées contre le support.
+- 5 120 combinaisons de largeur/profondeur, orientation et ancrage : géométrie
+  effectivement rendue sur la grille exacte, emprise sans dépassement,
+  centrage pair/impair et marges transparentes.
+- Sauvegarde/reconnexion des sculptures centrées et aux bords, sans fichier
+  source ; rotations/miroirs, anciens états, fabrication et hotbar vérifiés.
+
+```sh
+./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryStatuary106ClientTests=true \
+  -PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true
+```
+
+Marqueurs `SCULPTURE119_PASS`, `STATUARY113_PASS` et
+`SCULPTURE113_GEOMETRY_PASS` dans `build/sculpture119-client.log`.
+Captures conservées dans `build/sculpture119-evidence/`, vue centrée relue.
+Monde plat jetable de graine 106 ; aucun monde personnel ouvert. Pas de
+validation Windows ni de test depuis deux ordinateurs.
+Le GameTest dédié reste exclu conformément au refus antérieur de son EULA ;
+le parcours natif utilise le serveur intégré.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+passe en **2 min 24 s**, 125 tâches. Les sources JAR correspondent aux sources
+du dépôt ; seuls `SculptureAnchor.class` et le texte d'aide FR/EN diffèrent
+parmi les classes et ressources de production de beta.118. Les deux packs
+contiennent le même JAR, sans monde ni fixture de test.
+
+- Sanctuary-beta.119.mrpack : 10216447 octets, SHA-256
+  `ce29702eaaac7301c77fb6af63a76c6bc1c0c704313ce1b8243c95b5fe59d893`.
+- Sanctuary-Test-beta.119.mrpack : 10235369 octets, SHA-256
+  `a1a2845f9678b1144d7d9eab4867970cc1776fe0ad5d51722c8110b7c1d4c682`.
+- JAR Sanctuary : SHA-256
+  `d353bd89b16c53ee1ee48836fa2ff4b311249b280992300c28bf03048d805bff`.
+
+Reçu local : `build/sculpture119-artifact.json`.
+
+## Publication et installation
+
+La [release beta.119](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.119)
+est publiée depuis `3fd64e1f2a77ea2584b087d6339cf605d8ee0e9b`. Le tag exact et les
+artefacts sont immuables ; leurs téléchargements publics sont vérifiés.
+Le canal packwiz avance à `5e823af7807f524f6394acad402fe62328c7e4ab`.
+
+Deux synchronisations isolées puis deux dans **Sanctuary Beta** réussissent.
+Un seul JAR Sanctuary beta.119 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.119/` de l'instance existante. Reçus locaux :
+`build/sculpture119-isolated.json` et `build/sculpture119-prism.json`.

docs/sculpture-materials-beta116.md

@@ -0,0 +1,102 @@
+# beta.116 — Sculptures à partir des textures de blocs
+
+Ticket sur `codex/sculpture-materials-beta116`, comprenant aussi le correctif
+Fourneau beta.115 dans la livraison commune.
+
+Le Clay Workshop accepte les objets-blocs comme matière. Le client prélève une
+palette bornée dans la texture du bloc issue du pack actif, avec sa teinte, puis
+le modèle conserve sa géométrie et transpose ses valeurs claires/sombres dans
+cette palette. L'aperçu et le résultat utilisent le même calcul. Un bloc est
+consommé par sculpture ; les neuf cases de hotbar restent les seules accessibles.
+
+## Contrat des données et du réseau
+
+Les sculptures existantes conservent exactement leurs voxels sauvegardés :
+schéma 1 inchangé, identifiants `sanctuary:*` stables. Les nouvelles sculptures
+stockent elles aussi leurs couleurs finales dans ce format. Aucun chargement
+ne recolore les objets ou constructions existants. Orientation et ancrage
+beta.113 inchangés, sans migration ni modification d'un monde personnel.
+
+La sélection du menu ajoute l'identité de la matière et une palette de 256
+couleurs opaques au maximum. Ce sont des données d'apparence fournies par le
+client, comme le modèle déjà importé ; elles n'octroient ni objets ni propriétés
+de bloc. Le serveur vérifie le menu, son jeton, l'accès à l'atelier, les limites
+et l'objet effectivement présent. Il applique lui-même la palette et facture
+chaque résultat. Un changement de matière invalide immédiatement l'ancien
+résultat jusqu'à réception de la sélection correspondante. Les deux côtés
+doivent utiliser beta.116. Aucun nouveau format de sauvegarde.
+
+## Vérifications natives
+
+`Sculpture116ClientChecks` passe en 1 min 7 s, sur un nouveau monde plat de
+Minecraft 26.3, graine 116, puis la régression complète de l'atelier :
+
+- Les 1 207 objets-blocs enregistrés ont une palette opaque, non vide et bornée.
+- Fabrication payée avec pierre, planches de chêne, or, laine rouge, verre,
+  feuilles de chêne, argile et ardoise ; aperçu identique au résultat serveur.
+- Conservation des tons clairs/sombres du modèle et de ses coordonnées, sans
+  convertir les 16 argiles colorées en une simple couleur unie.
+- Une matière différente efface aussitôt l'ancien résultat ; une sélection
+  périmée ou un jeton incorrect ne fabrique rien et ne consomme aucun objet.
+- Les conteneurs contenant des objets sont refusés ; ils peuvent servir de
+  matière une fois vidés. Les objets qui ne sont pas des blocs sont refusés.
+- Bornes et opacité des palettes, véritable rechargement des ressources,
+  neuf cases de hotbar, stock plein, consommation exacte et restitution.
+- Poses selon les quatre regards, accroche au bord, grille de voxels,
+  casse/repose, sauvegarde et reconnexion après suppression du fichier GLB.
+- Interface FR/EN aux échelles 2/3, génération de plan au Métabli inchangée.
+
+Marqueurs `SCULPTURE116_PALETTES`, `SCULPTURE116_MATERIALS_PASS`,
+`SCULPTURE116_PASS` et régressions 106/111/112/113 dans
+`build/sculpture116-client.log`. Captures relues dans
+`build/sculpture116-evidence/`. Un libellé est raccourci en « Bloc » pour éviter
+le contact avec « Sculpture » dans le cadre compact.
+
+La palette vient de la texture représentative du modèle de bloc du pack actif,
+avec la teinte locale ; une texture animée utilise sa première image. Les blocs
+sans texture lisible utilisent leur couleur de carte. Il s'agit d'un transfert
+de couleurs sur les voxels opaques, sans transparence, émission ou fonction
+spéciale du bloc d'origine. Les sculptures existantes gardent leurs couleurs.
+
+Essais natifs macOS avec serveur intégré ; pas de client Windows ni de test
+LAN à plusieurs joueurs. Le serveur dédié de GameTest reste exclu selon le
+refus antérieur de son EULA. Aucun monde personnel ouvert.
+
+La régression native du Fourneau passe également dans beta.116, en 42 s :
+`build/sculpture116-furnace.log`, captures FR/EN dans
+`build/sculpture116-furnace-evidence/`. Les 27 cases, le glisser-déposer, les
+combustibles et les états de cuisson restent conformes au ticket beta.115.
+
+## Construction et archives
+
+`check build assemblePack assembleTestPack -x :sanctuary:runGameTest` réussit
+en 2 min 23 s : 125 tâches, dont 105 exécutées. Sources Java concordantes avec
+les JAR sources, versions alignées et intégrité des deux MRpack vérifiées.
+Le JAR conserve à l'identique le correctif Fourneau beta.115 ; seuls les
+classes de matière de sculpture et libellés FR/EN changent dans la production.
+Les classes de test et modèles GLB de test sont absents des archives.
+
+- `Sanctuary-beta.116.mrpack` : 10189831 octets, SHA-256
+  `7df04a6e2a57e76a55ca57bd7520b05cbb573392690b401b868837498807d252`.
+- `Sanctuary-Test-beta.116.mrpack` : 10208754 octets, SHA-256
+  `f4c9293e20384b05366d092fc7ee1abea275940a02373ee4036f73f0caa43747`.
+- JAR Sanctuary :
+  `76a9205783c8b18506c32c9eef6c481d95fd3ba0746a2bdd558a194534a51a32`.
+
+Reçu local : `build/sculpture116-artifact.json`.
+
+## Publication et instance
+
+La [release beta.116](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.116)
+est publiée avec le JAR, les deux MRpack et l'amorçage Prism. Le tag immuable
+désigne `e3ca9fcd6383f7646e4fea7e5098e7097ebb30aa` ; téléchargements publics
+et empreintes vérifiés. Le canal packwiz avance au commit
+`c741870160f8a21f0a9793f20f0e624ebdbacdb6`.
+
+Deux synchronisations isolées, puis deux dans l'unique instance **Sanctuary
+Beta**, réussissent. La seconde passe laisse les fichiers gérés inchangés,
+avec un seul JAR Sanctuary beta.116. Minecraft 26.3, Loader 0.19.5 et Fabric
+API 0.160.5+26.3 conservés. Les 923 fichiers personnels et réglages suivis
+restent identiques ; aucun monde personnel n'a été ouvert. Sauvegarde des
+fichiers remplacés dans `sanctuary-backups/before-beta.116/` de cette instance.
+Reçus : `build/sculpture116-isolated.json`, `build/sculpture116-prism.json`.

docs/sculpture-placement-beta125.md

@@ -0,0 +1,108 @@
+# SCULPT-11 — Placement, éclats et modèles découverts — beta.125
+
+Contrat du 17 septembre 2026, branche `codex/sculpture-placement-beta125`.
+
+Le point visé choisit neuf positions horizontales (centre, quatre bords et quatre
+coins) et trois hauteurs (bas, milieu et haut). Sur un support, la sculpture
+repose au bas de son bloc ; sous un plafond, elle touche le haut ; sur une face
+latérale, elle suit la hauteur visée et reste contre le support. Les sculptures
+restent debout et s'orientent selon le regard horizontal du joueur.
+La bande centrale occupe les huit pixels médians, limites incluses. Toute pose
+reste sur la grille 1/16 : une dimension impaire utilise le centre entier le
+plus proche, jamais un demi-voxel. Rendu, boîte unique de sélection et collision
+partagent les mêmes offsets. La lumière conserve les règles de beta.122.
+
+## Compatibilité additive des états existants
+
+Les cinq anciennes valeurs `anchor` gardent exactement leurs noms. Quatre
+valeurs de coin sont ajoutées. La nouvelle propriété `vertical_anchor` accepte
+`bottom`, `center`, `top` et `original`, valeur par défaut réservée à la
+compatibilité. La lecture d'un ancien bloc sans cette propriété conserve
+l'ancienne hauteur, même si le modèle a des marges transparentes en bas.
+Le bloc possède 144 états : 108 placements nouveaux et 36 états de compatibilité.
+
+Le schéma 1 des sculptures, leurs données de voxels et tous leurs identifiants
+restent inchangés. Aucun monde n'est parcouru ou réécrit, aucun chunk régénéré.
+Les nouveaux ancrages nécessitent beta.125 ; le retour à une version antérieure
+ne garantit pas leur position. Ce contrat autorise l'ajout compatible des états,
+pas une migration destructive des sauvegardes personnelles.
+
+## Particules
+
+Les coups et la casse émettent des éclats de la couleur des surfaces voxelisées
+réellement affichées, avec leur orientation et leur ancrage. Un coup vise la
+surface réelle la plus proche du point sélectionné, même devant un trou visuel.
+La casse échantillonne au plus 64 faces ; aucun calcul de texture n'est refait.
+Les éclats utilisent une taille de voxel, la gravité et la lumière natives.
+Une petite mémoire par monde (128 entrées de 64 faces, validité 40 ticks) conserve les
+surfaces si la suppression du bloc précède l'événement de casse. Les autres
+blocs gardent leurs particules habituelles.
+
+## Clay Workshop
+
+L'onglet Animaux utilise exactement les découvertes serveur du catalogue de
+statues (rencontre, victoire ou mort face à l'espèce). Le menu transmet cette
+liste à chaque ouverture, sans dépendre d'une visite préalable au Métabli.
+Le modèle natif et sa texture sont capturés localement, voxelisés en miniature,
+puis recolorés par la matière choisie. Le résultat reste fabriqué et payé côté
+serveur. Les sélections d'espèces non découvertes sont refusées. L'onglet Imports
+conserve les fichiers GLB. Aucun nouveau format de sculpture n'est introduit.
+Libellés FR et EN.
+
+## Vérifications
+
+Le parcours natif `Sculpture125ClientChecks` passe en **1 min 2 s**, client
+Minecraft 26.3 sur macOS et serveur intégré jetable (graines 125 et 122).
+
+- 54 clics réels sur les six faces : centres, bords, coins et hauteurs.
+- 432 contextes de pose, coordonnées positives/négatives, quatre orientations,
+  rotations et miroirs ; 144 états valides.
+- 20 anciens états sans `vertical_anchor` conservent leur hauteur et marges.
+- Couleur exacte des éclats au point frappé, surfaces réellement occupées,
+  limite de 64 fragments, événement après suppression et particules normales
+  d'un bloc de pierre témoin.
+- Atelier : découvertes par rencontre, victoire et mort, transmission native
+  du menu, refus serveur d'une espèce inconnue, trois modèles natifs (vache,
+  mouton, cochon), paiement d'un bloc en survie et import GLB conservé.
+- Sauvegarde et reconnexion avec les nouveaux coins et hauteurs.
+- 576 formes comparées aux limites du maillage affiché, boîte unique partagée,
+  cache réutilisé et 12 arêtes ; 9 216 empreintes orientées sur grille entière.
+- 75 sculptures superposées : ciel à 15, lumière de bloc à 13 après traversée,
+  pièce noire à 0. Pose dans le joueur refusée, même devant un trou visuel.
+
+Marqueurs dans `build/sculpture125-client.log`. Captures de plafond, murs et
+atelier relues dans `build/sculpture125-evidence/`. Aucun essai Windows,
+client distant ou shader tiers ; trois espèces vérifiées visuellement, sans
+prétendre avoir inspecté chaque espèce. Aucun benchmark FPS global.
+
+Le GameTest dédié demeure exclu conformément au refus antérieur de son EULA.
+Les mondes de test sont jetables ; aucun monde personnel n'est ouvert.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+passe en **2 min 16 s**, 126 tâches (110 exécutées, 16 à jour). Les sources
+des JAR correspondent exactement au dépôt. La comparaison avec beta.124
+limite les différences aux classes de placement, particules et atelier prévues,
+aux nouveaux libellés FR/EN, au mixin client et à la source blanche de particules.
+Les packs normal/Test partagent le même JAR, sans monde ni fixture ; le template
+reproduit les ressources du mod et du pack intégré.
+
+- Sanctuary-beta.125.mrpack : 10286360 octets, SHA-256 `9277e59c640c40392ab3750b402bb840020884878f6ece6978e6c4653e18655e`.
+- Sanctuary-Test-beta.125.mrpack : 10305282 octets, SHA-256 `9e3dbfa14b5382ba4eb62a78fa7d2161758c2f0e1fdc50fbd5ed776fd4ce32c5`.
+- JAR Sanctuary : SHA-256 `b38b75b900dd8cbe015318c739d5547fd7eac52f4337fa517e98f3f6f0ce3b46`.
+
+Reçu local : `build/sculpture125-artifact.json`. Les deux packs et le template
+sont copiés et vérifiés dans le dossier habituel `sanctuary-beta/build/`.
+
+## Publication et installation
+
+La [release beta.125](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.125)
+est publiée depuis `4ec5b0d028a23a9f753770988ffba61015e2e49a`.
+Tag et artefacts immuables, téléchargements publics vérifiés. Canal packwiz :
+`47eb833911a96eef0b13805dafe65b2ab7b95c87`.
+
+Deux synchronisations isolées puis deux dans l'instance **Sanctuary Beta**
+réussissent. Un seul JAR Sanctuary beta.125 est actif, conforme au hash vérifié ;
+le second passage ne change rien. Les **923 fichiers personnels et réglages
+suivis** restent inchangés, sans ouverture de monde personnel. Copie préalable
+sous `sanctuary-backups/before-beta.125/`. Reçus :
+`build/sculpture125-isolated.json` et `build/sculpture125-prism.json`.

docs/sculpture-shape-light-beta122.md

@@ -0,0 +1,108 @@
+# SCULPT-09 — Forme physique et lumière — beta.122
+
+Contrat du 17 septembre 2026, branche `codex/sculpture-shape-light-beta122`.
+Le créateur demande des bounding boxes adaptées aux sculptures et la suppression
+des ombres cubiques visibles lorsqu'on en pose plusieurs côte à côte.
+
+La sélection, le contact avec les entités et les collisions suivent les voxels
+occupés de chaque sculpture, y compris les creux. Le rendu et la forme physique
+partagent leur placement entier sur la grille 1/16, après orientation et ancrage.
+Le centre, les quatre bords et les dimensions impaires gardent leur alignement.
+La pose vérifie aussi les voxels portés avant que l’entité de bloc existe :
+elle refuse une intersection avec le joueur et autorise les espaces libres.
+La forme est construite directement sur une grille native 16³ et mise en cache
+par entité de bloc, modèle et état ; aucun calcul complet à chaque interrogation.
+
+Les sculptures transmettent la lumière et ne sont plus utilisées comme cubes
+pleins par l'occlusion ambiante. Leurs faces restent éclairées par le monde,
+sans émission de lumière et sans rendu à luminosité maximale. Cette règle est
+commune aux sculptures : l'éclairage natif stocké par bloc ne permet pas une
+ombre distincte pour chaque petit voxel. L'atelier d'argile reste inchangé.
+
+Aucun identifiant, blockstate, format d'item ou schéma sauvegardé ne change.
+Les formes sont recalculées à partir des voxels existants ; aucune migration,
+aucun parcours de monde ni régénération de chunk. Les données inconnues gardent
+leur conservation opaque et une petite base sélectionnable pour récupérer l'item.
+Le travail de documentation déjà présent dans l'autre branche reste intact.
+
+## Vérifications et livraison
+
+Le parcours `Sculpture122ClientChecks` passe en **37 s** sur Minecraft 26.3,
+client macOS et serveur intégré, dans un monde plat jetable de graine 122 :
+
+- Pose par la commande native d'utilisation ; sélection du pilier et visée
+  à travers le trou d'une arche jusqu'au bloc derrière, captures relues.
+- Requêtes natives de collision côté serveur et client : voxels occupés solides,
+  espace vide libre, aucune profondeur artificielle d'un bloc entier.
+- Pose refusée dans le joueur, sans consommer l'objet ; petite sculpture acceptée
+  dans la partie libre du même bloc, sans intersection avec le joueur.
+- **80 cas** confrontent le volume et les faces de collision au maillage réellement
+  émis : arche creuse, marges vides, cube de 4 096 voxels, voxel unique, quatre
+  orientations et cinq ancrages. Chaque interrogation répétée réutilise la forme.
+- Régression de **5 120 placements** du rendu existant : dimensions paires/impaires,
+  orientations et ancrages, plus marqueurs de direction et modèles avec marges.
+- Changement d'orientation/ancrage puis changement des voxels sur la même entité :
+  cache recalculé et forme client synchronisée.
+- **75 sculptures en trois couches** : skylight natif conservé à 15 partout.
+  Un toit de pierre témoin produit toujours une ombre. La lumière d'un bloc
+  traverse une sculpture avec l'atténuation de distance native (13 à deux blocs).
+- Le rendu reçoit la lumière réelle du monde : 15 au ciel, **0 dans une pièce
+  fermée et obscure**. Aucun rendu artificiellement lumineux.
+- Sauvegarde/reconnexion : modèle, collisions et lumière conservés sur les
+  deux côtés, sans fichier 3D source.
+
+```sh
+./gradlew :sanctuary:runClientGameTest \
+  -PsanctuaryClientTests=true -PsanctuarySculpture122ClientTests=true \
+  -PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true
+```
+
+Marqueurs `SCULPTURE122_PASS`, `SCULPTURE122_GEOMETRY_PASS`,
+`SCULPTURE122_PLACEMENT_PASS`, `SCULPTURE122_LIGHT_PASS` et
+`SCULPTURE113_GEOMETRY_PASS` dans `build/sculpture122-client.log` ; captures
+conservées dans `build/sculpture122-evidence/`. Le test prépare explicitement
+son sol à Y=0 : le preset plat nu commence à Y=-1.
+Aucun monde personnel ouvert ; pas d'essai Windows ni depuis deux ordinateurs,
+ni de garantie sur les ombres ajoutées par des shaders tiers.
+Le GameTest serveur 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 13 s**, 126 tâches. Les sources JAR correspondent aux sources
+Java du dépôt. Par rapport à beta.121, les différences de production se limitent
+aux classes des sculptures et à la nouvelle géométrie partagée (14 entrées,
+y compris le déplacement du sélecteur synthétique d'orientation). Toutes les
+ressources client, données serveur et configurations de mixins sont identiques.
+Les packs normal/Test contiennent le même JAR, sans sauvegarde ni fixture.
+Le template beta.122 contient les mêmes ressources que beta.121, octet pour octet.
+
+Reçu local : `build/sculpture122-artifact.json`.
+
+- `Sanctuary-beta.122.mrpack` : 10267459 octets, SHA-256
+  `b6e24d65797eb7f16670d2f3a591b5f2476820608f72241ecd37fb78a486008e`.
+- `Sanctuary-Test-beta.122.mrpack` : 10286380 octets, SHA-256
+  `90487ee3ad4298fccb8c24e8781af4cbf043d88dc0379fba5c21d99733dac92d`.
+
+JAR Sanctuary : SHA-256
+`ff8ebf89f39a64809fae6912253386793e9b5e66ec0adb9fa7521729893d406e`.
+
+## Publication et installation
+
+La [release beta.122](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.122)
+est publiée depuis `edc7fc3dfb117cde61be42c1d79b03af11f5dec6`. Tag et artefacts immuables,
+téléchargements publics vérifiés. Canal packwiz :
+`3d340bea0093b709c6018624795a1b3ca557b72d`.
+
+Deux synchronisations isolées puis deux dans **Sanctuary Beta** réussissent.
+Un seul JAR Sanctuary beta.122 est actif ; le second passage est identique.
+Les **923 fichiers personnels et réglages suivis** restent inchangés.
+Aucun monde personnel ouvert. Copie préalable dans
+`sanctuary-backups/before-beta.122/` de l'instance existante ; reçus
+`build/sculpture122-isolated.json` et `build/sculpture122-prism.json`.
+
+Le ticket a été réalisé dans le worktree `sanctuary-sculpture-beta122` afin de
+préserver les changements de `docs/vision.md` et `docs/villageois-illageois.md`
+déjà présents sur la branche de documentation du checkout principal.
+
+- [Pack normal](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.122/Sanctuary-beta.122.mrpack).
+- [Pack de test](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.122/Sanctuary-Test-beta.122.mrpack).
+- [Template personnel](https://git.botsu.net/koka/sanctuary-beta/releases/download/beta.122/Sanctuary-Template-beta.122.zip).

docs/sculpture-texture-grain-beta117.md

@@ -0,0 +1,110 @@
+# beta.117 — Grain des textures et sculptures en chapeau
+
+Ticket sur `codex/sculpture-texture-grain-beta117`, Minecraft 26.3.
+
+En beta.116, une couleur du modèle source était associée à une seule nuance
+de matière. Un modèle uni restait donc uni malgré les pixels différents de la
+texture. La sélection utilise maintenant les textures des faces du modèle de
+bloc, avec leurs propres teintes du pack actif. Un échantillonnage de pixels
+répartit leurs couleurs exactes dans les voxels, sans couleur interpolée.
+
+## Coût et comportement
+
+Au maximum 32 matériaux de faces et 16 × 16 échantillons par matériau sont lus,
+puis ramenés à la palette existante de 256 entrées. Les répétitions conservent
+la fréquence des nuances. Les pixels transparents sont écartés ; les textures
+animées utilisent la première image. Les blocs sans texture lisible gardent
+le repli antérieur sur la texture représentative, puis la couleur de carte.
+
+La sélection d'une nuance utilise un mélange entier déterministe des coordonnées
+de chaque voxel. Un modèle uni utilise toute la palette ; un modèle ombré
+utilise des plages de nuances qui suivent ses zones claires et sombres.
+Ce grain est un transfert de palette, pas une projection UV conservant les
+motifs ou les veinures du bloc. Les voxels restent opaques.
+
+Le calcul utilise Java standard et les modèles/textures déjà chargés par
+Minecraft, sans bibliothèque supplémentaire. Aucun calcul de matière dans
+le rendu par image. Le client ne rééchantillonne qu'au changement de matière
+ou de ressources ; une rotation réutilise la palette. Le serveur conserve
+le modèle recoloré pour les fabrications suivantes avec la même sélection.
+
+## Chapeaux et données
+
+Le système de blocs portés retirait `BLOCK_ENTITY_DATA` des objets pour isoler
+les inventaires des coffres et fourneaux. Sur une sculpture, ce composant est
+la géométrie elle-même : le slot contenait encore un objet, devenu invisible.
+Les sculptures conservent désormais ce composant à l'équipement et au retrait.
+
+Si une ancienne sculpture équipée a perdu ce composant, mais que sa session
+de chapeau possède encore le modèle, il est restauré depuis cette donnée
+serveur. La restauration ne fabrique aucune géométrie manquante. Les objets
+déjà retirés et dépourvus de toute copie du modèle ne sont pas reconstructibles
+par ce correctif. Les règles de contenu des coffres restent inchangées.
+
+Identifiants, schéma 1 des sculptures, structure des accessoires et paquet
+de sélection inchangés. Les couleurs déjà sauvegardées restent intactes.
+Les deux côtés utilisent beta.117 pour le même calcul de prévisualisation et
+de fabrication. Aucun monde personnel ouvert ni migration de sauvegarde.
+
+## Vérifications
+
+Le scénario client natif complet passe en 2 min 1 s sur macOS avec serveur
+intégré, monde plat jetable de graine 116. Il reprend le scénario beta.116
+avec un GLB entièrement uni, plus les régressions de l'atelier 106/111/112/113 :
+
+- 1 207 objets-blocs échantillonnés, huit fabrications payées avec aperçu
+  identique au résultat serveur, consommation exacte d'un bloc.
+- Répartition 25 % / 75 % de deux couleurs de texture sur un modèle uni,
+  aucune couleur inventée, conservation des zones claires et sombres.
+- Couleurs réellement présentes dans les textures natives des faces, avec
+  plusieurs matériaux d'une bûche ; grain présent sur pierre, bois et minerai.
+- Motif indépendant de l'ordre des voxels, stable et sauvegardé ; rechargement
+  des ressources, palette bornée, inventaire plein et sélections périmées.
+- Vrais clics des slots hotbar/chapeau, conservation exacte des composants
+  et du nom personnalisé, icône et modèle porté visibles, retrait/rééquipement.
+- Restauration d'un objet privé de sa géométrie depuis une ancienne session
+  équipée, puis sauvegarde et reconnexion du client avec le chapeau intact.
+- Pose, bord visé, orientation, casse/repose, reconnexion sans fichier source,
+  menus FR/EN et génération du plan du Métabli inchangés.
+
+Mesure indicative après échauffement, modèle maximal de 4 096 voxels,
+101 applications sur le Mac de développement : médiane **0,283 ms**, p95
+**0,971 ms**. Ce n'est pas une garantie de temps sur d'autres machines ; le
+calcul n'est exécuté ni chaque image ni à chaque objet fabriqué identique.
+
+Marqueurs `SCULPTURE117_GRAIN_PASS`, `SCULPTURE117_HAT_PASS`,
+`SCULPTURE117_HAT_RECONNECT_PASS`, `SCULPTURE116_PASS` dans
+`build/sculpture117-final-client.log`. Captures relues dans
+`build/sculpture117-evidence/`. Pas d'essai Windows ou LAN. Le GameTest dédié
+reste exclu selon le refus antérieur de son EULA.
+
+`check build assemblePack assembleTestPack -x :sanctuary:runGameTest` réussit
+en **3 min 7 s**, 125 tâches dont 105 exécutées. JAR sources concordants,
+versions, contenu et intégrité des deux archives vérifiés. La comparaison
+avec beta.116 limite les changements de production au calcul des matières,
+à son cache dans le menu et au traitement des sculptures en chapeau.
+Les modèles de test et classes de GameTest sont absents de la livraison.
+
+- `Sanctuary-beta.117.mrpack` : 10191137 octets, SHA-256
+  `adbe5a40bbd050ebc84ff8aca61a7a3643dcf25ec8f2ac59b91561e48275cbbb`.
+- `Sanctuary-Test-beta.117.mrpack` : 10210059 octets, SHA-256
+  `0dacb12b30bde66c647871101a4f4c6b0b58e7ceb29f7743398f8a569b958a6e`.
+- JAR Sanctuary :
+  `1ce63f97f17c6098f3c86c6753f9b912bce39d88e05ba240423c38bdc97307ee`.
+
+Reçu : `build/sculpture117-artifact.json`.
+
+## Publication et instance
+
+La [release beta.117](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.117)
+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
+`0f1efdec830342e25d3316b356330ad937d0d942`. Le canal packwiz avance au commit
+`a5b75a70f86e42afb8e06ba4daa9880d61c6373e`.
+
+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.117 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.117/`.
+Reçus : `build/sculpture117-isolated.json`, `build/sculpture117-prism.json`.

docs/session-fixes-beta161.md

@@ -0,0 +1,78 @@
+# beta.161 — correctifs de la séance du 23 septembre
+
+Ticket : R002–R009 du carnet de séance. Branches `codex/session-fixes-beta161`.
+
+## Contrat de données et migration additive
+
+Aucun monde ni chunk n’est régénéré, aucun format existant n’est modifié.
+Le nouveau fichier `data/sanctuary-server-metrics.json` version 1 conserve le temps
+réel cumulé depuis l’activation du compteur, les morts connues par UUID et les
+UUID des figurants exclus. Au premier démarrage, les morts sont importées des
+statistiques Minecraft déjà présentes ; le temps antérieur n’est pas inventé.
+Les valeurs vivantes sont relevées côté serveur, sauvegardées toutes les 30 secondes
+et à l’arrêt. Les arrêts ne comptent pas dans la durée. Un crash peut perdre au
+plus la période depuis le dernier relevé enregistré. Un fichier corrompu ou
+modifié extérieurement arrête la collecte sans le remplacer.
+
+En mode base, appliquer la migration Web additive `create_sanctuary_server_metrics_table`
+avant de lancer le mod. Elle crée une table indépendante, une ligne par server_id ;
+le schéma communautaire v3 et ses données restent inchangés. Le serveur publie un
+instantané toutes les 30 secondes et un état arrêté à l’arrêt propre. En cas de
+panne SQL le compteur local continue ; le site marque la dernière mesure périmée
+après 90 secondes. Une table absente ne bloque pas les publications communautaires.
+La suppression de cette nouvelle table au rollback perd uniquement les instantanés,
+recréés depuis le fichier local à la prochaine publication. Ne pas supprimer le fichier
+local pour revenir en arrière ; les anciennes versions l’ignorent.
+Un seul serveur actif par server_id, comme pour les publications. Les morts de tous
+les joueurs ayant des statistiques sont cumulées, y compris les joueurs déconnectés.
+Les figurants du laboratoire sont exclus des morts et des joueurs en ligne.
+
+## Résultat livré
+
+Liste des joueurs sur U (migration unique de Tab ; autres choix conservés), suivi
+et place unique expliqués dans les demandes. Site : retour au dessin d’origine,
+intendance limitée au titre, page officielle avec retour, pas de navbar de rubriques
+ni de sélecteur de langue ni d’incitation à se connecter dans les publications.
+Gazette en accordéon exclusif : le dernier article visible est ouvert au chargement,
+ouvrir un autre referme le précédent. Photo entière à gauche, extrait court à droite,
+visage/pseudo/date et lien de lecture alignés en bas. Calendrier jour/mois encadré,
+message officiel à droite, sans heure ; année dans le footer.
+Les pages publiques du site sont en lecture seule, y compris leurs anciennes
+routes d’écriture pour les comptes connectés et le staff. L’administration
+Intendance réservée au staff reste disponible. Les joueurs publient, répondent
+et suivent les demandes dans Minecraft. Compteurs réels et état périmé explicite.
+
+## Vérifications
+
+| Vérification | Résultat |
+| --- | --- |
+| `./gradlew check build assemblePack` | 252 GameTests : 229 réussis, les mêmes 23 échecs que beta.160, aucun nouvel échec dans cette passe. Comparaison dans `build/session161-server-failures.json`. |
+| Contrôles JVM et persistance fichier/SQL | Réussis, dont `SERVER_METRICS161_PASS` et `COMMUNITY154_SQL_PASS` dans `build/beta161-release.log`. |
+| Démarrage et raccourci U | `SESSION161_KEYS_PASS` : défaut U, migration unique depuis Tab, choix personnalisé conservé. |
+| Parcours natif communautaire | `SEARCH159_CLIENT_PASS mode=file` : photos/galerie, FR/EN, GUI 2/3/4, recherche, bulletin en lecture seule, suivi et infobulle du repère. Captures dans `mods/sanctuary/build/run/clientGameTest/screenshots/`. |
+| Web SQLite et MariaDB isolée | 29 tests, 252 assertions réussies ; lecture seule visiteurs/joueurs/staff, contrats de persistance, statistiques absentes/périmées/arrêtées. Pint et `git diff --check` réussis. |
+| Navigateur | Accordéon exclusif, lien vers l’article, calendrier sans heure, visage/auteur/date et lecture en bas ; vérification desktop et 390 × 844. |
+| Assemblage final | `./gradlew build assemblePack :sanctuary-test:exportDuoLaunch -x :sanctuary:check` réussi, après les vérifications ci-dessus. Exclusion ponctuelle des tests connus en échec, pas de suppression d’assertion. |
+| Laboratoire réel | Monde existant `duo-flat-160` relancé, serveur 768 MiB/client 2048 MiB, shaders désactivés. KokaLab non OP, 26 niveaux conservés. Deux figurants, compteur SQL et Web : 1 humain. Journal de durée persisté et exclusions vérifiées. |
+
+Le premier démarrage de test a révélé une mauvaise déclaration du nouveau mixin :
+`PlayerListKeyMixin` au lieu de `client.PlayerListKeyMixin`. Elle est corrigée ;
+la classe et sa déclaration sont présentes dans le JAR final. Le test natif a
+ensuite réussi. L’assemblage avait redéclenché une seconde passe de GameTests
+serveur ; cette répétition a été interrompue, la première passe complète faisant
+foi. Logs distincts : `beta161-check-build.log`, `beta161-release.log`,
+`beta161-client.log`, `beta161-assembly.log`, sous `build/`.
+
+Livraison locale uniquement : `mods/sanctuary/build/libs/sanctuary-beta.161.jar`
+et pack assemblé dans `build/packwiz`. SHA-256 du JAR :
+`c6e0424bf091c41827730bc260dad3b95b7c949fb0dcc41811f0ae3d94bce79c`.
+Les 29 ressources shader sont identiques à beta.160. Les anciens JAR beta.154–160
+sont conservés. Aucun canal public ni instance Prism personnelle n’a été modifié.
+Le téléchargement public du site reste l’ancien lien beta.151, hors de cette
+livraison locale. Les 23 échecs préexistants restent ouverts.
+
+Le compteur de jours débute à l’activation de cette version : le fonctionnement
+antérieur n’était pas mesuré. Le site reçoit les nouveaux compteurs au rechargement
+de la page. La mesure d’une mort réelle supplémentaire n’a pas été provoquée sur
+le personnage de la séance ; l’import et l’incrément sont couverts par le test du
+journal et les tests de lecture Web.

docs/shader-beta127.md

@@ -0,0 +1,88 @@
+# SHADER-127 — intégration des ombres portées pixélisées
+
+Demande du 17 septembre 2026 : livrer le shader dans **beta.127**.
+Branche `codex/shader-beta127`, socle publié beta.126, Minecraft 26.3 / Java 25.
+
+La préparation locale [des ombres pixélisées](pixel-shadows-source122.md) est
+intégrée sans écraser les changements non publiés du dossier d'origine.
+Les gemmes, dernières textures de rubis/saphir, l'argile spéciale et les
+commandes de découverte de beta.126 sont conservées.
+
+## Utilisation
+
+**Options → Shaders → Sanctuary · Vanilla Light → Ombres portées pixélisées**.
+L'option est désactivée par défaut ; son activation reste un choix du joueur.
+Finesse : 8/16/32 pixels par bloc ; portée : 16/32/64 blocs. Défauts : 16 et 32.
+Les paramètres FR/EN s'appliquent immédiatement et persistent dans
+`config/sanctuary-shaders.json`. La mise à jour préserve les réglages personnels.
+Le rendu est natif au mod : aucun pack Iris, téléchargement supplémentaire ou
+nouvelle dépendance de rendu.
+
+## Périmètre
+
+Ombres solaires des formes d'occultation des blocs chargés, incluant dalles,
+escaliers et obstacles hors écran. Carte de profondeur GPU, grille ancrée dans
+le monde, atténuation selon soleil, pluie et brume. L'effet s'arrête la nuit,
+dans les dimensions sans soleil, dans les fluides ou avec un moteur externe.
+Le HUD et la main ne passent pas dans cet effet. La lumière de gameplay,
+les règles serveur, les sauvegardes et la génération ne sont pas modifiées.
+
+La préparation limite le cache à 96 Mio et sa construction à quatre sections
+par image dans un budget souple de 3 ms. L'intégration supprime seulement une
+invalidation de bord exécutée deux fois à l'identique dans le cache de terrain.
+Les formes non occultantes, feuillages ajourés, eau/verre et entités animées ne
+projettent pas de nouvelles silhouettes. Les transparences déjà composées
+peuvent recevoir l'assombrissement du terrain situé derrière elles. Pas
+d'ombres de torches/lune ni de mesure de FPS revendiquée.
+
+## Vérifications et livraison
+
+Client natif Minecraft 26.3 / Java 25 sur macOS, monde neuf plat, graine 122 :
+`PixelShadows122ClientChecks` réussit sur la beta.127 en **1 min 26 s**.
+Le nom de cette fixture historique est conservé pour suivre la même scène.
+
+- Activation : 920 échantillons de sol assombris, 63 412 inchangés, aucun éclairci.
+- Pilier hors écran : 42 048 échantillons restent ombrés ; le retrait du pilier
+  restitue la lumière sur les 42 048 et conserve les 23 616 déjà éclairés.
+  La repose rétablit la même ombre sans désactiver le cache.
+- Trois finesses et trois portées, redimensionnement GPU, désactivation/libération,
+  arrêt nocturne, reprise diurne et rechargement des ressources vérifiés.
+- Préférences persistantes et bornées ; captures FR/EN inspectées, sans texte
+  tronqué. La scène pilier/dalle/escalier est également inspectée visuellement.
+
+Logs : `build/shader127-client.log`. Captures :
+`mods/sanctuary/build/run/clientGameTest/screenshots/`.
+Le serveur GameTest dédié reste exclu conformément au refus antérieur de son
+EULA. Aucun monde personnel n'est ouvert. Aucun essai Windows/Vulkan ou FPS
+n'est revendiqué ; la validation graphique est celle du client natif local.
+
+
+Build `./gradlew check build assemblePack assembleTestPack
+-x :sanctuary:runGameTest` réussi en **2 min 25 s**, 126 tâches. Les sources
+Java dans les archives correspondent aux sources du ticket. La comparaison
+avec le JAR beta.126 ne trouve que **21 entrées de production modifiées**,
+toutes liées au shader, à son initialisation, ses mixins et ses libellés.
+Les règles de jeu, données, textures de gemmes, sculptures et découvertes
+sont identiques. Normal et Test contiennent le même JAR ; le template exporte
+exactement les ressources du mod. Aucune fixture de test ni monde embarqué.
+
+| Artefact | SHA-256 |
+| --- | --- |
+| `Sanctuary-beta.127.mrpack` | `23fa6ca0c5d1f1033e13e5370d669491b398d5a99e13f8bd1e983f998a24a20a` |
+| `Sanctuary-Test-beta.127.mrpack` | `f185f3a743ba23cd6c024d1c1e46587706bf4f3edb5e14d7e5dee522a1ebf2c2` |
+| `sanctuary-beta.127.jar` | `3ef3fab67f4f703864a1acc9ae2395c636d206f3128d3399140eaf045a46d5f3` |
+
+## Publication et synchronisation
+
+[Release beta.127](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.127)
+publiée depuis `00be1eb0d0bfe042442d90255385033a7765092f` ; artefacts immuables retéléchargés
+et vérifiés. Canal packwiz : `7fd24a43e01ee497a23311e3c78e1dd3dddd877a`.
+Deux synchronisations isolées puis deux dans l'instance existante
+**Sanctuary Beta** ont réussi. Les **923 fichiers personnels** suivis,
+y compris les préférences de shaders, sont conservés. Aucun monde personnel
+ouvert ; copie préalable dans `sanctuary-backups/before-beta.127/`.
+
+Les packs normal/Test et le template sont aussi copiés et vérifiés dans
+`sanctuary-beta/build/`. Reçus locaux : `build/shader127-artifact.json`,
+`build/shader127-isolated.json`, `build/shader127-prism.json` et journal de
+publication `build/shader127-publication.log`.

docs/shader-beta128.md

@@ -0,0 +1,106 @@
+# SHADER-128 — stabilité, lune et feuillage
+
+Demandes du 17 septembre 2026 : réduire le jitter des bords et à midi, conserver
+des ombres de blocs nettes et un feuillage nuancé, ajouter une ombre lunaire
+fine et une transmission
+irrégulière du feuillage selon son épaisseur. Branche `codex/moon-foliage-beta128`,
+socle publié beta.127, Minecraft 26.3 / Java 25.
+
+## Résultat
+
+Les faces de voxels reçoivent l'ombre sur une grille fixe ; leur plan est
+stabilisé au 1/16 de bloc et les faces inclinées conservent leur normale. La
+carte de profondeur utilise un ancrage par 16 blocs avec alignement de ses
+texels. **Les ombres des blocs restent nettes** : le créateur a écarté leur
+adoucissement après l'essai visuel. Le filtrage est réservé au feuillage.
+Le soleil continue de se déplacer : ce mouvement naturel peut toujours faire
+avancer une ombre d'une case. L'objectif est de supprimer les oscillations
+liées à la caméra, pas de figer le temps.
+
+Entre une élévation solaire de 0,92 et le zénith, l'intensité diminue doucement
+jusqu'à 25 % de sa valeur habituelle : alpha maximal 0,095 au lieu de 0,38.
+La lune réutilise la même carte et son angle natif ; alpha maximal 0,10 selon
+sa phase, nul à la nouvelle lune. Horizon, pluie, portée et brume atténuent
+les deux lumières. Pas de seconde passe de carte lunaire simultanée.
+
+Les blocs du tag vanilla `leaves` projettent une couverture probabiliste fixe
+sur une grille de quart de bloc. Les faces internes restent présentes : plus
+le rayon traverse de couches, moins il a de chances de passer. Il s'agit d'une
+approximation statistique de l'épaisseur, pas d'un comptage des feuilles ni
+d'une lecture des trous de leur texture. Quatre échantillons bilinéaires sur
+un quart de bloc mélangent cette couverture
+en nuances, évaluées sur la grille pixélisée. Un masque R8 distingue feuilles
+et blocs dans la même passe de profondeur, pour garder les silhouettes opaques
+nettes. Les comparaisons suivent le plan récepteur pour éviter l'auto-ombrage
+sur les surfaces obliques. Le motif ne dépend ni du temps ni de la caméra et
+ne demande aucune lecture GPU côté CPU en production.
+Les budgets du cache restent 96 Mio, quatre sections et 3 ms souples par image.
+Le feuillage ajoute des faces ; son filtrage utilise seize comparaisons de
+profondeur et, selon le cas, autant de lectures du masque. Les ombres opaques
+pleines utilisent le chemin court. Le masque prend 4 Mio à la définition
+par défaut, 16 Mio au maximum ; aucune promesse de FPS n'est faite.
+
+Réglages existants et libellés FR/EN conservés/actualisés. Les ombres restent
+optionnelles et désactivées par défaut. Règles, éclairage de gameplay, mondes
+et génération inchangés. Les limitations de beta.127 concernant les entités,
+fluides, verre et autres formes non occultantes subsistent.
+
+## Vérifications
+
+`PixelShadows122ClientChecks`, fixture historique étendue, réussit en **1 min
+44 s** dans un monde neuf plat, graine 122, client natif macOS/OpenGL.
+
+- Soleil : 920 échantillons de sol ombrés et 63 412 inchangés ; retrait/repose
+  d'un pilier hors écran restitue puis rétablit son ombre.
+- Lune : ombre localisée mesurée ; arrêt des passes à la nouvelle lune.
+- Midi : ombre atténuée et **zéro échantillon de transition adoucie sur 65 664**
+  dans la scène de contrôle du contour opaque.
+- Caméra : petits déplacements autour de l'ancien ancrage entier et du nouvel
+  ancrage par 16 blocs, retour au point initial, petites rotations en vue
+  oblique, instants avant/après midi et passage de 5999 à 6001 ticks.
+  Comparaisons d'images avec tolérance de trois niveaux par canal et moins
+  de 1 % d'échantillons changés pour ces petits mouvements.
+- Vue oblique : 19 637 échantillons ombrés, 46 027 inchangés sur le sol blanc.
+- Feuillage : assombrissement moyen mesuré d'environ **18,6 %** pour une couche,
+  **31,7 %** pour quatre, contre **36,8 %** sous une couverture solide.
+  Motif fixe dans le temps ; modification des couches invalide le cache actif.
+- Trois finesses/trois portées, désactivation/libération GPU, préférences
+  persistantes, rechargement des ressources, textes FR/EN et captures inspectés.
+
+Commande native : `./gradlew :sanctuary:runClientGameTest
+-PsanctuaryClientTests=true -PsanctuaryPixelShadows122ClientTests=true
+-PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true` sous Java 25.
+Logs : `build/shader128-client.log` ; captures sous
+`mods/sanctuary/build/run/clientGameTest/screenshots/`.
+
+`./gradlew check build assemblePack assembleTestPack
+-x :sanctuary:runGameTest` réussit en **2 min 24 s**, 126 tâches.
+Les sources archivées correspondent au ticket. **13 entrées de production**
+diffèrent de beta.127, limitées aux classes du shader, GLSL et libellés FR/EN.
+Gemmes, sculptures, découvertes, données et règles de jeu restent identiques.
+Normal et Test embarquent le même JAR ; le template correspond exactement aux
+ressources exportables. Aucun monde ni fixture de test embarqué.
+Le serveur GameTest dédié reste exclu conformément au refus antérieur de son
+EULA. Aucun monde personnel utilisé. Aucun essai Windows/Vulkan revendiqué.
+
+## Artefacts vérifiés
+
+| Artefact | SHA-256 |
+| --- | --- |
+| `Sanctuary-beta.128.mrpack` | `84125b18366afde52c8cba4bc7007257b1c3d8b79d413338abe64d0e0ae8feaf` |
+| `Sanctuary-Test-beta.128.mrpack` | `6bfb10d8d63875bfb84e813d4f0a9faf5db30902cc0400deda0993c08b86e597` |
+| `sanctuary-beta.128.jar` | `c54cbae7efaa7059c8fd4d28801087983379958fe34eedff51682d106d649c6a` |
+
+## Publication et synchronisation
+
+[Release beta.128](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.128)
+publiée depuis `a4e96c0d99c976231d7ca92b1db6bdb6aa7083c6` ; les artefacts immuables ont été
+retéléchargés et vérifiés. Canal packwiz : `eba01726ee132a6e548d129fa7ee04f24c880917`.
+Deux synchronisations isolées puis deux dans l'instance existante
+**Sanctuary Beta** ont réussi. Les **923 fichiers personnels** suivis,
+y compris les réglages de shaders, sont conservés. Aucun monde personnel
+ouvert ; copie préalable dans `sanctuary-backups/before-beta.128/`.
+Packs normal/Test et template copiés et vérifiés dans `sanctuary-beta/build/`.
+
+Reçus locaux : `build/shader128-artifact.json`, `build/shader128-isolated.json`,
+`build/shader128-prism.json` ; journal : `build/shader128-publication.log`.

docs/shader-beta129.md

@@ -0,0 +1,119 @@
+# SHADER-129 — arêtes connectées et portées étendues
+
+Demandes du 17 septembre 2026 : highlight optionnel, puis raccordement CTM de
+tous les blocs coplanaires, portée indépendante 16–256 blocs, ombres à 128/256,
+suppression de l'atténuation au zénith et du réalignement cyclique des ombres.
+Branche `codex/edge-highlights-beta129`, socle beta.128, Minecraft 26.3 / Java 25.
+
+## Résultat
+
+Dans **Options → Shaders → Sanctuary · Vanilla Light**, les reflets sur les
+arêtes sont désactivés par défaut. L'intensité va de 0 à 100 ; la valeur 30
+éclaircit au maximum de 12 %. Leur portée se règle indépendamment des ombres :
+**16, 32, 64, 128 ou 256 blocs**. Les anciens réglages restent conservés.
+
+Le highlight raccorde les surfaces plates, y compris entre matériaux différents,
+sans dessiner les jonctions intérieures. Il suit les contours visibles du relief,
+y compris les dalles et escaliers. Il multiplie la couleur existante pour garder
+les pixels des textures et composer avec les ombres. Ce CTM géométrique utilise
+la profondeur déjà produite par Minecraft : aucune liste de blocs autorisés,
+aucun pack CTM à fournir, aucune exploration CPU du volume de 256 blocs.
+Une cassure/repose modifie le contour dès que le terrain natif est réaffiché.
+
+Le trait proche suit la grille de 1/16 de bloc. À distance, la couverture devient
+partielle pour limiter le scintillement des traits plus petits qu'un pixel.
+La portée choisie s'efface progressivement dans son dernier quart et respecte
+la brume ainsi que la distance de rendu. Une passe plein écran, quatre sondes
+de profondeur et un tampon uniforme de 176 octets ; aucun retour GPU vers CPU
+en production. L'arrêt de l'option ou une intensité nulle libèrent ce tampon.
+
+Ce n'est pas un remplacement des textures par des variantes CTM. Le calcul
+concerne les faces visibles alignées sur la grille : les faces hors écran,
+les surfaces transparentes absentes de la profondeur et les géométries
+arbitrairement inclinées ne sont pas reconstruites. À très grande distance,
+les détails plus petits qu'un pixel peuvent rester imperceptibles. Aucun
+chargement de chunk forcé, aucune promesse de FPS.
+
+Les ombres proposent les cinq mêmes portées. La carte reste plafonnée à
+4096 × 4096 : les grandes distances réduisent sa précision spatiale. Le cache
+garde ses limites de 96 Mio, quatre sections et 3 ms souples de construction
+par image ; la réconciliation des chunks est limitée aux ticks et changements
+de caméra/terrain plutôt qu'à toutes les images.
+
+L'intensité solaire reste pleine au zénith. Les contours opaques restent nets,
+le filtrage du feuillage et les ombres légères de la lune sont conservés.
+Le réalignement de la grille lumineuse a lieu au changement d'ancrage de la
+caméra, avec transfert de phase par texels entiers. La rotation du soleil ne
+réarrondit plus la projection de l'origine mondiale à chaque image, source
+de sauts périodiques amplifiés aux grandes coordonnées. Le soleil continue
+d'avancer ; une ombre pixélisée peut naturellement changer de case. Cette
+correction ne modifie pas l'horloge serveur ni sa cadence native.
+
+Textes FR/EN. Aucun changement de règles, sauvegardes, génération, gemmes,
+sculptures ou découvertes.
+
+## Vérifications et livraison
+
+Le client natif réussit en **2 min 41 s**, dans un monde neuf plat, graine 122,
+sur macOS / Apple M1 / OpenGL :
+
+- CTM : 596 échantillons éclaircis sur le contour et 65 068 conservés ; les
+  20 centres et 20 jonctions coplanaires ciblés restent intacts, y compris
+  au changement de matériau. L'intensité 90 produit environ trois fois le gain.
+- Ouverture d'un trou : 716 échantillons éclaircis ; la fermeture restitue
+  l'image connectée. Au-delà de 16 blocs, le réglage 16 supprime le contour ;
+  le réglage 64 le rétablit (254 échantillons éclaircis).
+- Cinq portées CTM et cinq portées d'ombres, persistance/clamp, migration des
+  anciennes préférences, arrêt/libération, rechargement, caméra et vue oblique
+  avec ombres. Captures françaises/anglaises inspectées ; suppression ensuite
+  d'un préfixe redondant dans le libellé de portée.
+- Soleil, lune, nouvelle lune, ombres opaques nettes à midi et transmission
+  du feuillage restent vérifiés. Casters hors écran et retrait/repose actifs.
+- 2 000 petits pas solaires aux coordonnées ±100 000 vérifient l'absence de
+  saut de translation de la carte ; changement d'ancrage par texels entiers.
+  La séquence du vrai service realtime suit 294 images : angle avancé de
+  0,000694 radian, aucun rebond dans les 65 664 échantillons de sol suivis.
+  Sur cette courte séquence, aucune case opaque n'a changé ; cela ne constitue
+  pas une mesure de mouvement visible sur une journée entière.
+
+La fixture initiale capturait parfois le terrain avant la fin de sa construction
+native : elle attend désormais la réception de toute la plateforme et la fin
+compilée des sections. Aucun changement de gameplay pour contourner ce problème.
+
+Commande : `./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true
+-PsanctuaryPixelShadows122ClientTests=true -PsanctuaryClientNoVsync=true
+-PsanctuaryQuickTests=true`. Log `build/shader129-client.log`, captures sous
+`mods/sanctuary/build/run/clientGameTest/screenshots/`.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit en **2 min 17 s**, 126 tâches. Une dernière passe d’assemblage intègre
+la simplification du libellé de portée (2 min 18 s). Les archives sont vérifiées :
+**17 entrées de production** diffèrent de beta.128, limitées au shader et à ses
+interfaces. Même JAR dans normal/Test, sources archivées conformes, ressources
+du template exactes, assets des gemmes inchangés. Aucun monde ni test embarqué.
+Le serveur GameTest dédié
+reste exclu conformément au refus antérieur de son EULA. Aucun monde personnel
+utilisé pour les essais, aucun résultat Windows/Vulkan revendiqué.
+
+
+Archives vérifiées dans `build/` et recopiées dans le dossier de livraison
+habituel `sanctuary-beta/build/` :
+
+- Normal : 10 353 946 octets, SHA-256
+  `2c7735194faab8a699004e69ad543ce6e8fabdebe297b759bffd31fea2dcc2e8`.
+- Test : 10 372 872 octets, SHA-256
+  `cca572ee313d1d7e66ed745bb48bac62490998760d9b7bbfc7a1f6d60c430dce`.
+- JAR Sanctuary :
+  `ca3e2ff4e0717a3a54c1d57478d43aade39d001b71c4eec745d76f010f7def54`.
+
+[Release beta.129](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.129)
+publiée depuis `35103a7ea8635dc4ed26293f00e86d99aaacfca8`. Canal packwiz
+`2eaa0130a4cd475c598beefdab40f48fc8681ab7`. Deux synchronisations isolées puis deux synchronisations
+dans l'instance **Sanctuary Beta** ont réussi. Les **923 fichiers personnels**
+suivis, dont les réglages de shader, sont inchangés. Aucun monde personnel ouvert.
+Sauvegarde préalable des fichiers gérés : `sanctuary-backups/before-beta.129/`.
+Le JAR installé a le hash vérifié ci-dessus. Reçus locaux :
+`build/shader129-artifact.json`, `build/shader129-isolated.json` et
+`build/shader129-prism.json`. Le checkout initial avec ses modifications en
+cours a été préservé ; seule la copie des archives versionnées rejoint son
+répertoire `build/`.

docs/shader-beta130.md

@@ -0,0 +1,131 @@
+# SHADER-130 — bloom et précision commune
+
+Demandes du 17 septembre 2026 : bloom réglable du soleil et des sources
+lumineuses ; inclusions émissives du fer, cuivre, redstone, lapis, diamant,
+émeraude, rubis, saphir, quartz et or ; réglage commun « Précision » pour
+les ombres et le highlight. Branche `codex/bloom-beta130`, socle beta.129,
+Minecraft 26.3 / Java 25.
+
+## Résultat
+
+Dans **Options → Shaders → Sanctuary · Vanilla Light**, le bloom possède
+un interrupteur, une intensité et une diffusion réglables de 0 à 100.
+Les minerais ont leur propre interrupteur et intensité. Le bloom reste
+optionnel, désactivé initialement, avec une intensité préparée à 35, une
+diffusion à 50 et une émission des minerais à 50. Une intensité globale
+nulle arrête les passes et libère les ressources de cet effet.
+
+Les nouveaux réglages par défaut sont **Pixel Shadows activé**, distance
+des ombres **128 blocs**, highlight **32 blocs** et **Précision 16 pixels
+par bloc**. La précision unique propose 8, 16 et 32 et contrôle simultanément
+ombres et arêtes. La clé JSON historique `shadowPixels` est conservée :
+les préférences déjà personnalisées ne sont pas écrasées.
+
+Les vingt textures de minerais sont analysées depuis les ressources actives.
+La palette de pierre, de deepslate ou de netherrack est comparée aux pixels
+colorés des inclusions, avec un traitement du quartz et de l'or du Nether.
+Les reflets clairs accolés aux inclusions sont conservés. Le masque est
+calculé une fois par texture et conservé en cache jusqu'au rechargement des
+ressources. Une texture optionnelle `<nom>_e.png` peut préciser ce masque
+pour une texture candidate ; sa luminance maximale multipliée par l'alpha
+remplace la détection automatique. Les couleurs affichées viennent toujours
+de l'atlas Minecraft actif, y compris son animation.
+
+Les sources sont les faces visibles des modèles de blocs lumineux, la lave,
+le soleil et la lune. Les lampes éteintes ne produisent pas de halo. Le
+niveau lumineux natif pondère les sources ordinaires ; l'émission des minerais
+est purement graphique. La profondeur du terrain élimine les inclusions
+cachées et masque le soleil derrière les constructions. Le cœur émissif
+conserve ses pixels nets, tandis qu'un halo séparé est diffusé à résolution
+réduite puis composé sur l'image.
+
+Aucun niveau de lumière serveur, spawn, règle de jeu, format de sauvegarde,
+identifiant ou paramètre de génération ne change. Aucun monde personnel
+n'est ouvert pour les essais.
+
+## Coût et limites
+
+La géométrie suit uniquement les sections natives visibles et déjà chargées.
+Leur palette permet d'écarter rapidement les sections sans source ; le cache
+invalide les sections touchées lors des modifications. Construction répartie
+sur les images, au plus quatre sections démarrées et un budget souple de
+3 ms, cache GPU plafonné à 32 Mio et 16 384 faces par section. Une section
+qui dépasse les limites est omise. Aucun chargement de chunk forcé.
+
+Le masque GPU est plafonné à 256 textures, chacune échantillonnée au plus en
+64 × 64 ; les textures natives 16 × 16 conservent leurs texels. Les masques
+animés utilisent leur première image, tandis que la couleur reste animée.
+La carte d'émission est à la résolution de l'écran ; la diffusion séparable
+utilise deux cibles flottantes à 1/8 de largeur et de hauteur, sans retour
+GPU vers CPU en production. Les allocations sont libérées à l'arrêt, au
+rechargement et à la déconnexion, et recréées au changement de taille.
+
+Cette première version ne reconstruit pas les sources hors écran, les
+particules, les entités lumineuses ni les modèles dessinés exclusivement par
+un renderer de block entity. Les packs très différents peuvent demander un
+masque explicite. Les silhouettes des liquides sont approximées puis
+masquées par la profondeur native. Aucune promesse de FPS ni validation
+Windows/Vulkan ; les essais graphiques portent sur macOS / Apple M1 / OpenGL.
+
+## Vérifications
+
+Le test client ciblé réussit en **1 min 29 s**, dans un nouveau monde plat,
+graine 122. Il analyse les vingt textures, refuse les pixels gris de leur
+roche, mesure le gain nocturne et les variations réelles d'intensité/diffusion.
+Couvrir les minerais de pierre supprime toute source émissive. Retirer les
+blocs rétablit l'émission ; le rechargement des ressources fait de même.
+Torche, glowstone, lampe alimentée, lave et soleil sont vérifiés, ainsi que
+l'arrêt de la lampe et l'occultation du soleil par de la pierre. Les valeurs
+par défaut et la conservation d'anciens choix personnalisés passent.
+
+Log ciblé : `build/shader130-client-bloom.log` ; masques inspectables dans
+`mods/sanctuary/build/run/clientGameTest/bloom130-ore-masks.png` et son CSV.
+La suite shader complète réussit en **3 min 16 s** : casters hors écran,
+retrait/repose, trois précisions, cinq portées, lune, zénith, feuillage,
+realtime, caméra et rechargement restent vérifiés. Les arêtes CTM restent
+raccordées entre matériaux ; 1 295 échantillons du contour sont éclaircis
+à précision 8, 596 à 16 et 120 à 32. Les captures françaises/anglaises et
+le rendu des minerais/du soleil sont inspectés.
+
+Commandes natives : `./gradlew :sanctuary:runClientGameTest
+-PsanctuaryClientTests=true -PsanctuaryPixelShadows122ClientTests=true
+-PsanctuaryClientNoVsync=true -PsanctuaryQuickTests=true`. Le test ciblé utilise
+`-PsanctuaryBloom130ClientTests=true` à la place de la propriété PixelShadows.
+Log complet : `build/shader130-client-full.log` ; captures sous
+`mods/sanctuary/build/run/clientGameTest/screenshots/`.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit en **2 min 24 s**, 126 tâches. Le serveur GameTest dédié reste exclu
+conformément au refus antérieur de son EULA. La comparaison au binaire beta.129
+trouve **24 entrées de production** modifiées, toutes limitées au shader et à
+ses interfaces. Gameplay et textures des gemmes inchangés ; aucun test,
+monde ou modèle GLB embarqué. Les sources archivées correspondent aux sources
+Java, les packs normal/Test embarquent le même JAR et le template contient
+exactement les ressources prévues.
+
+Archives vérifiées dans `build/` et recopiées dans le dossier habituel
+`sanctuary-beta/build/` :
+
+
+- `Sanctuary-beta.130.mrpack` : 10386021 octets, SHA-256
+  `7a3fcd4e496fa136eb3e0896fa7b856ae91771123186fa8df13c8fb1e0cf3e9a`.
+
+- `Sanctuary-Test-beta.130.mrpack` : 10404944 octets, SHA-256
+  `8de094fcbc58a300cc24d64c8d1b7931fdb8db354c75defa6bf2a2aa4a123a23`.
+
+JAR : `1ac4d1b1339361fb665f03ca3bd359163db5037ffd90e684c5a461759f6076e7`.
+
+[Release beta.130](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.130)
+publiée depuis `534dfec4f88169a200702b50d1ba87d85c107bee`. Canal packwiz
+`68e06353bf880af04c1c72d4e3a159f11f94b619`. Les téléchargements publics sont vérifiés par SHA-256.
+Deux synchronisations isolées, puis deux dans la même instance **Sanctuary
+Beta**, réussissent. Un seul JAR Sanctuary beta.130 est actif. Les
+**923 fichiers personnels suivis** conservent leurs hashes, dont les mondes,
+packs et préférences de shaders. Sauvegarde préalable dans
+`sanctuary-backups/before-beta.130/` de l'instance. Aucun monde personnel ouvert.
+
+Reçus locaux ignorés : `build/shader130-artifact.json`,
+`build/shader130-isolated.json`, `build/shader130-prism.json` et
+`build/shader130-publication.log`. Le checkout original conserve ses
+modifications préexistantes ; seuls les trois artefacts versionnés vérifiés
+sont recopiés dans son dossier `build/`.

docs/shader-beta131.md

@@ -0,0 +1,91 @@
+# SHADER-131 — émissifs indépendants et réglages initiaux
+
+Demande : activer par défaut bloom, minerais émissifs et highlight ; garder
+les émissifs avec halo coupé ou intensité du bloom à zéro, sans bouton ajouté ;
+ajouter 64 et 128 pixels/bloc en options. Précision initiale 16, distances
+highlight 32 et ombres 128 conservées. Préférences personnalisées préservées.
+Branche `codex/emissive-beta131`, socle beta.130, Minecraft 26.3 / Java 25.
+
+Le futur effet demandé est une légère teinte diffusée depuis les blocs
+voisins, pas des reflets reconnaissables. Étude seulement pour ce ticket ;
+aucun SSR ou éclairage indirect expérimental activé.
+
+## Comportement et validation
+
+Le curseur à zéro et l'interrupteur Bloom coupent uniquement le halo.
+Le réglage existant des minerais contrôle leurs inclusions nettes séparément.
+Sans halo, les cibles de diffusion GPU sont libérées ; l'émission garde
+seulement les ressources nécessaires. Tout désactiver libère l'ensemble.
+La grille commune propose 8, 16, 32, 64 et 128, sans augmenter le plafond
+4096 de la carte d'ombres. Libellés FR/EN et essais clients natifs sur les
+inclusions, l'absence de halo, les transitions et les nouvelles précisions.
+Aucun changement de lumière serveur, de génération ou de sauvegardes.
+
+Le cœur émissif et le halo utilisent maintenant deux chemins indépendants.
+Les textures et leur analyse restent celles de beta.130. Avec le halo coupé,
+la carte d'émission est effacée avant les faces, le cœur net est composé,
+et les passes de ciel, réduction, diffusion et application du halo sont
+omises. Le retour au bloom recrée ses cibles. Aucun bouton ajouté, aides
+FR/EN adaptées et choix explicitement désactivés toujours conservés.
+
+## Vérifications
+
+Suite client native réussie en **3 min 46 s**, monde plat neuf de graine 122,
+macOS / Apple M1 / OpenGL. Cinq précisions sauvegardées et chargées, bornes
+et seuils de normalisation, carte d'ombres plafonnée et arêtes CTM rendues
+à 64/128. Le gain mesuré des traits diminue de 0,02778 à précision 32 à
+0,02094 à 64, puis 0,01013 à 128 dans la même scène.
+
+Les inclusions restent nettes sans halo : le rendu Bloom OFF correspond
+au rendu intensité zéro. Aucun gain mesuré hors du masque source, ressources
+de diffusion absentes ; couper aussi les émissifs libère l'ensemble et
+restitue l'image initiale. Réactiver le bloom restitue son image précédente.
+Captures OFF/zéro inspectées. Valeurs initiales ON vérifiées ; un ancien
+choix explicitement OFF reste OFF. Les essais beta.130 (vingt masques,
+occultation, sources, rechargement), lune, feuillage et realtime passent.
+
+Le premier essai rencontrait une assertion historique attendant le highlight
+OFF lorsqu'une clé était absente. Elle attend désormais la nouvelle valeur
+ON ; les cas de préférences explicitement désactivées restent testés.
+
+Commande : `./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true
+-PsanctuaryPixelShadows122ClientTests=true -PsanctuaryClientNoVsync=true
+-PsanctuaryQuickTests=true`. Log : `build/shader131-client-full.log` ; captures
+sous `mods/sanctuary/build/run/clientGameTest/screenshots/`.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit en **2 min 30 s**, 126 tâches. Les archives normal/Test, leurs sources
+et le template sont vérifiés. Six entrées de production changent : moteur
+Bloom, préférences, interface et libellés. Gameplay, shaders GLSL et textures
+restent identiques à beta.130. Aucun résultat Windows/Vulkan
+revendiqué ; le serveur GameTest dédié reste exclu conformément au refus
+antérieur de son EULA.
+
+## Piste suivante — diffusion des couleurs
+
+Choix confirmé : légère teinte des surfaces voisines. Une estimation SSGI
+utilise la couleur et la profondeur visibles pour des rebonds diffus ; voir
+la [documentation primaire Unity](https://docs.unity3d.com/Packages/com.unity.render-pipelines.high-definition@17.0/manual/Override-Screen-Space-GI.html).
+Proposition à expérimenter : faible intensité, courte portée autour des
+surfaces, calcul réduit, rejet par profondeur pour ne pas teinter au travers
+des murs. Vérifier les bords de l'écran, les blocs hors champ, la stabilité
+en mouvement et les textures avant de fixer une qualité. Cette piste n'est
+pas implémentée dans beta.131.
+
+## Livraison
+
+- `Sanctuary-beta.131.mrpack` : 10386312 octets ; SHA-256 `e02067e424bf4f54512d5cfb1b5cde0fe232aa6bdadc0d38981cd15817a6387a`.
+- `Sanctuary-Test-beta.131.mrpack` : 10405238 octets ; SHA-256 `298387cce5a5b7cdc09b3a9d24859b674a736b25abcbafa7995b813757641265`.
+
+JAR : `87210da23f7781efccdbdbf5d4e2d3c1ff1857a7f326027b93d6a301c7dfdb0d`.
+
+Archives vérifiées recopiées dans `sanctuary-beta/build/`. [Release beta.131](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.131)
+publiée depuis `078d3e6833daa7de7f6c6d0e1a6c17d5dbefe075`. Canal packwiz
+`efb18c274d95d988a9566b8c52751469f002cdda`. Téléchargements publics vérifiés par hash.
+Deux synchronisations isolées, puis deux dans la même instance **Sanctuary Beta**
+réussissent. Un seul JAR Sanctuary beta.131 ; les **923 fichiers personnels
+suivis** conservent leurs hashes, dont les préférences de shaders et les mondes.
+Sauvegarde préalable `sanctuary-backups/before-beta.131/` ; aucun monde personnel
+ouvert. Reçus ignorés : `build/shader131-artifact.json`,
+`build/shader131-isolated.json`, `build/shader131-prism.json` et
+`build/shader131-publication.log`. Le checkout original conserve ses changements.

docs/shader-beta132.md

@@ -0,0 +1,106 @@
+# SHADER-132 — diffusion locale SSGI expérimentale
+
+Demande : légère teinte diffusée des surfaces voisines, sans reflets miroir
+ni shader d'eau. Branche `codex/ssgi-beta132`, socle beta.131, Minecraft 26.3 /
+Java 25. Aucun changement de génération, sauvegarde ou lumière serveur.
+
+## Résultat
+
+**Options → Shaders → SSGI · couleurs diffusées** active un rebond diffus
+local. L'effet expérimental est initialement OFF, avec une intensité préparée
+à **35 %** ; le curseur propose 0–100. À zéro ou OFF, ses cibles et uniformes
+GPU sont libérés. Les autres effets et leurs préférences sont conservés.
+
+La couleur d'une surface visible peut teinter les surfaces proches qui lui
+font face. Le calcul porte à **2,5 blocs** du récepteur et s'estompe entre
+24 et 32 blocs de la caméra. Il utilise une copie de la couleur native après
+les ombres, avec la profondeur et des normales reconstruites. Le premier
+obstacle arrête chaque rayon, même si son épaisseur empêche de retenir une
+intersection. Les plans coplanaires ne s'éclairent pas eux-mêmes.
+
+Douze directions hémisphériques fixes, au maximum dix étapes par rayon,
+sont évaluées à demi-résolution en largeur et hauteur. La reconstruction
+plein écran est guidée par la profondeur pour conserver les silhouettes et
+les détails des textures. Le cœur des émissifs, le highlight et le bloom
+sont composés ensuite : pas de halo réinjecté dans le rebond ni de boucle
+de rétroaction d'une image sur l'autre. Aucune lecture GPU vers CPU ni
+recherche de chunks en production. Pas de bruit temporel ou d'historique.
+
+Deux cibles, RGBA8 plein écran et RGBA16 flottant à demi-résolution, soit
+environ six octets par pixel de l'écran, plus 176 octets d'uniformes par
+segment du tampon natif. Redimensionnement, arrêt, déconnexion et
+rechargement libèrent/recréent les ressources possédées. Ce budget n'est
+pas une garantie de FPS ; le SSGI coûte davantage qu'un simple réglage de
+colorimétrie.
+
+## Limites de cette version
+
+L'estimation utilise seulement la couleur et la profondeur visibles. Les
+blocs hors champ ou cachés n'apportent pas leur couleur. Le résultat peut
+changer lorsqu'ils entrent ou sortent de l'image ; une atténuation près
+des bords limite la coupure. Les surfaces transparentes absentes de la
+profondeur ne sont pas reconstruites. Petits objets et intersections plus
+minces que l'échantillonnage peuvent manquer. Il s'agit d'une approximation
+diffuse locale, pas d'une simulation complète d'éclairage global ni de
+reflets spéculaires. Aucune modification de l'eau et aucune source hors
+champ déduite ou générée.
+
+## Vérifications
+
+Test ciblé natif réussi en **1 min** sur macOS / Apple M1 / OpenGL, nouveau
+monde plat de graine 122. À intensité 90, les échantillons du sol blanc
+montrent un gain rouge cumulé de 8 968 contre 20 bleu devant le mur rouge,
+puis 9 168 bleu contre 23 rouge devant le mur bleu. Le sol seul est inchangé.
+OFF/zéro restituent l'image de base et libèrent les cibles ; intensité 20
+réduit le gain. Changer la couleur du mur complètement occulté laisse
+l'image inchangée. Rechargement, caméra fixe, mouvement infinitésimal et
+retour à la caméra d'origine passent, sans accumulation de couleur.
+
+Deux ajustements de fixture ont précédé ce résultat : inclure dans les
+mesures le blanc légèrement bleuté par l'éclairage natif, et formater les
+petits angles de `/tp` en décimal car la commande refuse la notation
+scientifique. Aucun comportement du jeu modifié pour ces corrections.
+
+Log ciblé : `build/shader132-client-ssgi.log`. La suite complète réussit en
+**4 min 18 s** et vérifie aussi une fenêtre 961 × 541, le retour à sa taille
+initiale, le SSGI avec ombres/highlight/bloom/émissifs actifs, ainsi que
+l'arrêt global du shader. Les captures françaises et anglaises passent.
+Les contrôles précédents des cinq précisions, ombres, lune, feuillage, CTM,
+bloom et émissifs restent réussis. Log : `build/shader132-client-full.log`.
+
+Commandes : `./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true
+-PsanctuaryPixelShadows122ClientTests=true -PsanctuaryClientNoVsync=true
+-PsanctuaryQuickTests=true`. Pour le test ciblé, remplacer la propriété
+PixelShadows par `-PsanctuarySsgi132ClientTests=true`.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit en **2 min 25 s**, 126 tâches. Les packs normal/Test contiennent le
+même JAR ; sources archivées et template de ressources correspondent aux
+sources. Comparaison avec beta.131 : **11 entrées de production** modifiées,
+limitées au SSGI, à ses options et à ses points d'appel. Gameplay et textures
+des gemmes inchangés, aucun monde ni test embarqué. Aucun résultat
+Windows/Vulkan revendiqué.
+Le serveur GameTest dédié reste exclu conformément au refus antérieur de
+son EULA. Les captures panoramiques et les milieux de brume sous l'eau/lave
+ou neige poudreuse suspendent cette passe, comme les autres effets de
+profondeur Sanctuary.
+
+## Livraison
+
+- `Sanctuary-beta.132.mrpack` : 10394026 octets, SHA-256 `a7c0823e00f36925919645e32e7792242ec1d01015b41bee5b4f6285b9fc533d`.
+- `Sanctuary-Test-beta.132.mrpack` : 10412949 octets, SHA-256 `9bc30a7d6d5834f9323f15f0c39d3f49d200e1a97d739266ab373c9e1ba4a8fd`.
+
+JAR : `83eb2d091a7acd85eaa8b3b6a00a40ea483f9eeb2a30c033bdf68b4d717c5142`.
+
+Archives vérifiées recopiées dans `sanctuary-beta/build/`. [Release beta.132](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.132)
+publiée depuis `7e21781a9a08c669c7d6b65653bd9d408887689c`. Canal packwiz
+`9edaaedc0205c525ecce9de66b5ca7827c56c28f` ; téléchargements publics vérifiés par SHA-256.
+Deux synchronisations isolées, puis deux dans la même instance **Sanctuary Beta**,
+réussissent. Un seul JAR beta.132 actif ; les **923 fichiers personnels suivis**,
+dont sauvegardes et préférences de shaders, gardent leurs hashes. Sauvegarde
+préalable `sanctuary-backups/before-beta.132/` ; aucun monde personnel ouvert.
+Le checkout original conserve ses changements préexistants.
+
+Reçus locaux ignorés : `build/shader132-artifact.json`,
+`build/shader132-isolated.json`, `build/shader132-prism.json`,
+`build/shader132-publication.log`.

docs/shader-beta133.md

@@ -0,0 +1,106 @@
+# SHADER-133 — SSGI visible au réglage courant
+
+Demande : le rebond diffus de beta.132 est trop discret pour être distingué.
+Branche `codex/ssgi-strength-beta133`, socle beta.132, Minecraft 26.3 / Java 25.
+
+## Changement
+
+La collecte conserve douze directions, dix étapes, une demi-résolution et
+un rayon de 2,5 blocs. L'atténuation spatiale devient linéaire plutôt que
+quadratique. Le mélange est reconstruit en lumière approximativement linéaire,
+puis réencodé une seule fois. Un gain artistique plus fort rend la couleur
+lisible et une courbe progressive évite de couper brutalement les canaux
+à blanc. Les surfaces sans rebond restent intactes. La force demeure réglable
+de 0 à 100, avec le même réglage initial de 35 ; aucune préférence enregistrée
+n'est écrasée. SSGI reste optionnel, initialement désactivé.
+
+Aucun rayon, cible GPU ou texture de matériau supplémentaire. La composition
+ajoute une exponentielle et une racine carrée par canal ; le coût exact en FPS
+reste à mesurer sur la machine du joueur. Les normales de géométrie orientent
+déjà le rebond. Pas de PBR ni de normales procédurales de textures ajoutés.
+
+## Piste matériaux
+
+Pour une étape distincte, des normales de faible amplitude calculées au
+chargement des textures, mises en cache, et une rugosité par famille de matériaux
+permettraient d'étudier du relief et des reflets orientés. Une simple conversion
+luminosité → hauteur ne connaît pas le relief réel : un motif peint peut devenir
+une bosse artificielle. Commencer sur pierre, briques et bois avec une amplitude
+réglable serait préférable à une génération aveugle pour tous les blocs.
+La passe actuelle ne possède ni atlas de normales, ni identifiants de matériaux,
+ni albédo non éclairé ; des images seules ne suffiraient pas à les exploiter.
+
+## Limites conservées
+
+Approximation diffuse à partir de la couleur déjà éclairée, pas un transport
+physique complet. Seules les surfaces visibles contribuent, avec variations
+possibles aux entrées/sorties d'écran. Premier obstacle bloquant, pas d'historique
+ni de bruit temporel ; aucune modification d'eau, monde ou lumière serveur.
+
+## Vérifications
+
+Suite client native complète réussie en **4 min 29 s**, sur macOS / Apple M1 /
+OpenGL, dans un monde de test plat (graine 122). Les comparaisons ON/OFF à 35 %
+mesurent, sur les pixels neutres du sol :
+
+| Mur | Pixels avec gain ≥ 8/255 | Pixels avec gain ≥ 16/255 | Gain cumulé du canal dominant |
+| --- | ---: | ---: | ---: |
+| Rouge | 16 487 | 7 311 | 305 221 |
+| Bleu | 14 954 | 7 328 | 309 991 |
+
+À 90 %, les gains dominants atteignent 654 683 et 655 867, contre 8 968 et
+9 168 au même réglage dans la fixture beta.132. Ce rapport concerne uniquement
+cette scène et ces pixels, pas une promesse de gain uniforme dans tous les mondes.
+Les captures confirment une bande colorée au pied du mur. Un premier réglage
+intermédiaire a été rejeté car aucun pixel du sol ne dépassait 8/255 à 35 % ;
+un second a passé les contrôles ciblés, puis la force a encore été augmentée
+après examen visuel. Les valeurs finales sont celles de la suite complète.
+
+Le test impose maintenant plus de 5 000 pixels à 8/255 et plus de 500 à 16/255
+au réglage 35, pour les deux couleurs. Intensité, OFF/zéro, absence de rebond
+coplanaire, occultation d'un mur changeant de couleur, caméra fixe, déplacement
+infinitésimal, retour de caméra, redimensionnement et rechargement passent.
+Ombres, lune, feuillage, CTM, cinq précisions, bloom, émissifs indépendants et
+interfaces FR/EN restent validés, y compris avec le SSGI actif.
+
+Commande : `./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true
+-PsanctuaryPixelShadows122ClientTests=true -PsanctuaryClientNoVsync=true
+-PsanctuaryQuickTests=true`. Log : `build/shader133-client-full.log`.
+Le nom de la propriété ciblée `sanctuarySsgi132ClientTests` est conservé.
+
+Comparateur local autonome : `build/SSGI-beta.133-comparaison.html`, captures
+natives OFF/35/90 des murs rouge/bleu, sans retouche. Pas de validation
+Windows/Vulkan ni de mesure de coût FPS revendiquée.
+
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit en **2 min 21 s**, 126 tâches. Le serveur GameTest dédié reste exclu
+conformément au refus EULA antérieur. Log : `build/shader133-build.log`.
+Les archives normal/Test contiennent le même JAR ; sources archivées et template
+de ressources correspondent aux sources. Comparaison avec beta.132 : **5 entrées
+de production** changées (classe du compositeur, deux shaders, libellés FR/EN).
+Gameplay, textures, sauvegardes et dépendances inchangés.
+
+## Artefacts
+
+- `Sanctuary-beta.133.mrpack` : 10394282 octets, SHA-256 `0c90a070da7f969706abeeec1bdfb0830bb52244c20fccbca4fd876f3fbe0564`.
+- `Sanctuary-Test-beta.133.mrpack` : 10413204 octets, SHA-256 `e01f0355bf2cce18156fe94a069e142bedc498624ba0b6e2729ae0f23ea73e80`.
+
+JAR : `a01cae4a98606007b533ca09ec9f072f19a1db2e9b8de466f4ad075d5c1fc185`.
+
+
+## Livraison
+
+[Release beta.133](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.133)
+publiée depuis `216d3f75b576bd2ed531653012f9cc6c4801d87a`. Canal packwiz
+`9ceb5a5353c9d1b8bb7834a20e818fd65096ff98` ; téléchargements publics vérifiés par SHA-256.
+Deux synchronisations isolées puis deux synchronisations de la même instance
+**Sanctuary Beta** réussissent. Un seul JAR beta.133 actif ; les **923 fichiers
+personnels suivis**, dont sauvegardes et préférences, gardent leurs hashes.
+Sauvegarde préalable `sanctuary-backups/before-beta.133/`, aucun monde personnel
+ouvert. Le checkout original conserve ses changements préexistants.
+
+Les archives normal/Test/template et le comparateur natif sont également dans
+`sanctuary-beta/build/`. Reçus locaux ignorés : `build/shader133-artifact.json`,
+`build/shader133-isolated.json`, `build/shader133-prism.json` et
+`build/shader133-publication.log`.

docs/shader-beta134.md

@@ -0,0 +1,109 @@
+# SHADER-134 — PBR procédural optionnel et herbe SSGI
+
+Demande : ajouter en option des normales calculées à partir des textures actives,
+avec rugosité des matériaux et reflets orientés. Retour : le SSGI renforcé
+éclaire artificiellement l'intérieur de l'herbe ; vérifier et corriger ce cas.
+Branche `codex/pbr-beta134`, socle beta.133, Minecraft 26.3 / Java 25.
+
+## Contrat
+
+PBR initialement OFF, intensité 50 réglable 0–100. Cartes de normales à partir
+des différences de luminance, amplitude limitée ; rugosité/métallicité par
+famille de blocs, repli rugueux pour les types inconnus. Analyse des ressources
+actives conservée en cache jusqu'à désactivation ou rechargement ; pas de fichiers
+écrits dans le pack personnel, pas de GPU readback en production.
+
+Portée 32 blocs, sections visibles construites progressivement. Budget de maillage
+24 Mio, atlas de 4 096 matériaux en 16 × 16 avec bordures (1 280 × 1 280 RGBA8,
+6,25 Mio), copie RGBA8 de l'image courante et uniformes. Les textures de plus haute
+résolution sont échantillonnées à 16 × 16 ; première image des textures animées.
+La couleur et l'animation restent celles de l'atlas natif. Pas de parallax ni
+de géométrie ajoutée aux blocs ; les motifs clairs peuvent donner un faux relief.
+
+La passe utilise une réponse spéculaire GGX (normales, rugosité, métallicité,
+Fresnel) et module l'éclairage diffus déjà rendu. Elle ne remplace pas tout le
+pipeline Minecraft par un moteur PBR physique. Soleil/lune, exposition au ciel et
+carte d'ombres active limitent les reflets ; pas de reflets miroir, d'environnement
+SSR, ni de direction locale déduite pour chaque torche. Aucun rendu PBR d'eau,
+d'entités, d'items ou de modèles spéciaux hors maillage de terrain.
+
+## SSGI
+
+Les normales des faces presque axiales sont stabilisées sur leur axe. Deux passes
+spatiales filtrent la lumière indirecte à demi-résolution, avec rejet des voisins
+hors du plan du récepteur et interpolation de l'échantillonnage. Les textures de
+l'image restent nettes. Un tampon RGBA16F supplémentaire à demi-résolution porte
+le budget des cibles SSGI à environ 8 octets par pixel plein écran (contre 6).
+Pas d'historique temporel ni de rémanence ajoutés.
+
+Un parcours de 12 blocs a reproduit des bandes sur un mur et un éclaircissement
+artificiel d'herbe à 35 et 100. Le filtrage seul ne suffisait pas : la collecte
+réinjectait aussi trop fortement la lumière ambiante neutre. Elle conserve
+maintenant la composante chromatique de la source, en soustrayant son canal
+linéaire minimum. L'éclairage ambiant neutre reste celui de Minecraft. Ce réglage
+vise le transfert de couleur voulu, pas une simulation physique complète du
+rebond blanc. Les sources hors champ/cachées restent absentes du SSGI ; le résultat
+peut encore varier lors d'un déplacement important. PBR et SSGI restent indépendants.
+
+## Vérification
+
+Test PBR ciblé réussi en 1 min 13 s : relief éclairé/ombré, intensités 20/50/100,
+soleil matin/soir, cache stable, préférences, OFF/zéro, mouvement infinitésimal,
+redimensionnement, rechargement et combinaison des effets. Le premier parcours
+SSGI est conservé comme reproduction ; résultats finaux ci-dessous.
+
+
+Le parcours corrigé a réussi en **2 min 47 s** avec 13 positions réparties sur
+12 blocs, à 35 et 100, chaque fois comparées à OFF. Un mob immobile, des brins
+d'herbe et un mur figurent dans la scène. Retour au point initial sans rémanence.
+Sur les captures de ce parcours, le maximum du gain vert moyen mesuré dans
+l'herbe passe sous 9,73 niveaux à 35 et 24,51 à 100. Le test impose ensuite
+respectivement des limites de 12 et 30 à chaque position. L'essai reproduisant
+le défaut atteignait notamment 23,68 et 49,20 à l'extrémité droite.
+Ces mesures décrivent cette scène, pas une garantie d'absence d'artefacts
+dans tous les mondes ni sur toutes les cartes graphiques.
+
+
+La suite client complète réussit en **7 min** sur macOS / Apple M1 / OpenGL.
+Elle inclut le parcours latéral et ses seuils de gain, les deux couleurs de rebond,
+le PBR, les ombres, le feuillage, les cinq précisions, le CTM, les émissifs, le
+bloom, les préférences et les écrans FR/EN. Log : `build/shader134-client-full.log`.
+Le contrôle PBR final réussit en **1 min 19 s** : placement/retrait d'un toit,
+invalidations de lumière/maillage et rendu combiné avec les ombres actives. Les
+reflets utilisent maintenant la grille des ombres pour leur test de visibilité. Aucun résultat Windows/Vulkan ni
+mesure de FPS revendiqués.
+
+
+## Construction et artefacts
+
+`./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/shader134-build.log`.
+Packs normal/Test : même JAR Sanctuary. Sources archivées et template identiques
+aux sources. Comparaison à beta.133 : **23 entrées de production** changées,
+limitées au rendu, à ses options et points d'appel. Gameplay et gemmes inchangés.
+
+- `Sanctuary-beta.134.mrpack` : 10421971 octets, SHA-256 `d5bc79acb1d56e7dcf83c976156fdb2fcde80c98e443bde8a6ab312d56887b7f`.
+- `Sanctuary-Test-beta.134.mrpack` : 10440898 octets, SHA-256 `04308ebb9adaf76b30a3cbf4fa32ab897e76842803fc8c8411cfa32952d1bdd5`.
+
+JAR : `a6e69622a5e6629f70dd19b7494ad3b00916bc02169b73635f0e2d563929b7fa`.
+
+Comparateur local : `build/Shader-beta.134-comparaison.html`. Il contient les
+captures natives PBR OFF/50/100 et le parcours SSGI de 12 blocs OFF/35/100.
+Le parcours est une succession de positions enregistrées, pas une mesure des FPS.
+
+
+## Livraison
+
+[Release beta.134](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.134)
+publiée depuis `fc4a0cb68ed2d89163c8e74773976df5bab4f3f1`. Canal packwiz
+`35ec0f6e145002f6367944df5b75e2703958eaef` ; téléchargements publics vérifiés par SHA-256.
+Deux synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussissent. Un seul JAR beta.134 actif ; les **923 fichiers personnels suivis**,
+dont sauvegardes et préférences, gardent leurs hashes. Copie préalable dans
+`sanctuary-backups/before-beta.134/`, aucun monde personnel ouvert.
+
+Packs normal/Test/template et comparateur natif vérifiés également dans
+`sanctuary-beta/build/`. Le checkout original garde ses changements préexistants.
+Reçus locaux ignorés : `build/shader134-artifact.json`, `build/shader134-isolated.json`,
+`build/shader134-prism.json`, `build/shader134-publication.log`.

docs/shader-beta135.md

@@ -0,0 +1,116 @@
+# SHADER-135 — SSGI en contre-plongée et près des surfaces
+
+Demande : supprimer les déchirures horizontales sous une surface, notamment
+près de la lave, et atténuer proprement le rebond quand la caméra s'approche
+d'une source ou d'un mur. Branche `codex/shader-closeup-beta135`, socle beta.134.
+Minecraft 26.3 / Java 25 ; aucune modification de monde ou de gameplay.
+
+## Diagnostic et correction
+
+Le calcul des normales comparait l'aire du pixel en unités du monde à un seuil
+fixe. À courte distance ou à haute résolution, cette aire devient naturellement
+très petite : le rejet pouvait couper une surface continue. Les deux directions
+sont maintenant normalisées avant leur produit vectoriel. Les texels de bord
+sont bornés et les voisins sans profondeur ne créent plus de fausse surface.
+
+La composition utilise le centre exact du texel de profondeur. Le rebond
+s'atténue entre 0,4 et 0,06 bloc de distance au **plan** receveur, et lorsque la
+vue devient presque tangente. Cette distance évite une découpe circulaire sur
+un mur plat. L'image native reste nette ; aucune texture du décor n'est floutée.
+
+Les sondes sortant du volume de projection sont rejetées. Leur contribution
+s'atténue près du plan de caméra et de la limite d'épaisseur d'un impact, au lieu
+d'une contribution pleine jusqu'à cette limite. Trois ressources GLSL modifiées ;
+aucune passe, cible GPU, lecture CPU, histoire temporelle ou option ajoutée.
+Les 12 rayons × 10 pas et les deux passes de filtrage spatial restent inchangés.
+
+## Réglages initiaux
+
+Demande ajoutée pendant la livraison : **bloom 20 %**, **PBR ON** et **SSGI ON**.
+Les intensités PBR 50 et SSGI 35 restent inchangées. Les champs absents du fichier
+de préférences prennent ces nouvelles valeurs ; les choix explicites du joueur
+restent conservés. Aides françaises et anglaises mises à jour. Vérification
+native supplémentaire des préférences vierges, partielles et personnalisées.
+
+## Reproduction native
+
+Deux scènes isolées : stone au-dessus de la lave, puis coin à 0,5 bloc d'une
+paroi rouge. Caméra en contre-plongée, sept distances au plafond de 2 à 0,04 bloc,
+comparaisons OFF/35/100 avant/après. Dans la première scène, à 0,1 bloc et
+intensité 100, le saut maximal de gain rouge moyen entre lignes de pixels neutres
+passe de **14,88 à 0,052** niveaux sur 255. Dans le coin, à 0,4 bloc et intensité
+35, le rebond auparavant rejeté revient (gain moyen de **6,01** niveaux), puis
+s'atténue à l'approche du contact. Ces chiffres concernent ces scènes uniquement.
+
+Les deux essais ciblés corrigés réussissent en 1 min 18 s et 1 min 17 s sur
+Apple M1 / OpenGL. Images avant/après conservées dans `build/closeup-*` ;
+comparateur autonome `build/Shader-beta.135-comparaison.html`.
+
+## Régression et livraison
+
+Les contrôles natifs de la suite générale réussissent jusqu'au parcours SSGI :
+ombres, lune, feuillage, temps réel, CTM, émissifs/bloom, couleurs de rebond,
+occlusion, réglages, rechargement et déplacement latéral de 12 blocs à 35/100.
+Log : `build/shader135-client-main.log`. La suite n'est pas présentée comme
+entièrement réussie : elle s'est arrêtée sur une attente incorrecte du nouveau
+test, qui demandait du rebond alors que sa source était sortie du champ.
+
+Le scénario corrigé distingue la haute résolution avec source visible de la
+vue très relevée sans source visible. Le bassin possède un fond pour isoler la
+lave des essais suivants ; les particules du scénario précédent sont effacées
+avant la comparaison PBR statique. Une première tentative avait aussi rencontré
+le refus natif de remettre l'horloge à sa valeur actuelle ; la préparation de
+l'heure est désormais répétable. Ces changements concernent uniquement les tests.
+
+Le contrôle final ciblé **réussit en 2 min 52 s** : les deux scènes, 35/100,
+sept distances, 1280 × 720 avec source visible, source hors champ, mouvement
+minuscule, rendu combiné, puis contrôles PBR complets (cache, intensités,
+matériaux, soleil, toit, OFF/zéro, redimensionnement et rechargement).
+Log : `build/shader135-client-final.log` ; marqueurs `SSGI135_CLOSEUP_PASS` et
+`PBR134_PASS`. Les seuils de proximité et PBR sont conservés.
+Le contrôle supplémentaire des nouveaux défauts et du PBR **réussit en
+1 min 16 s** : préférences vierges, champs absents, valeurs personnelles conservées,
+puis rendu PBR et combinaison des effets. Log : `build/shader135-defaults-client.log`.
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit en **2 min 18 s**, 126 tâches. Le serveur GameTest dédié demeure exclu
+conformément au refus EULA antérieur. Les classes des scénarios clients compilent
+aussi après leur isolation explicite des effets activés par défaut.
+Log : `build/shader135-build.log` ; compilation : `build/shader135-test-compile.log`.
+
+## Archives vérifiées
+
+Comparaison à beta.134 : **6 entrées de production** modifiées, limitées aux
+trois ressources SSGI, aux valeurs initiales et aux aides FR/EN. Gameplay et
+textures des gemmes inchangés. Packs normal/Test : JAR Sanctuary identique ;
+archives de sources et template conformes aux sources. Reçu local ignoré :
+`build/shader135-artifact.json`.
+
+
+## Limites
+
+Le SSGI utilise seulement les surfaces visibles : les sources hors champ restent
+absentes et un grand changement de vue peut modifier le rebond. L'atténuation
+proche est volontaire ; ce n'est pas une simulation volumétrique. Le brouillard
+natif de submersion continue de suspendre le SSGI, comme en beta.134. Aucun
+résultat Windows/Vulkan ni mesure de FPS revendiqués.
+
+- `Sanctuary-beta.135.mrpack` : 10422391 octets ; SHA-256 `36ac278f9f5ecd2cefd69da16ea7d153ff44c5fc8e6bf0b3a3d6b71f5d767af6`.
+
+- `Sanctuary-Test-beta.135.mrpack` : 10441314 octets ; SHA-256 `e096374f7ea0856b20392e5d277e94f6c3d411723d7ffc10ceccdd9f0bf5c4d4`.
+
+JAR : `a68ccd04a92a962c46a76b26a80cb44a4faf7a13a562094dde51010ade594c10`.
+
+## Livraison
+
+[Release beta.135](https://git.botsu.net/koka/sanctuary-beta/releases/tag/beta.135)
+publiée depuis `7fada570efb5ed579e6e4d7bc2b87079c7131b31`. Canal packwiz
+`5b0df577fcd036937c25be3a1f4580f9db3103a1` ; téléchargements publics vérifiés par SHA-256.
+Deux synchronisations isolées puis deux dans la même instance **Sanctuary Beta**
+réussissent. Un seul JAR beta.135 actif ; les **923 fichiers personnels suivis**,
+dont sauvegardes et préférences, gardent leurs hashes. Copie préalable dans
+`sanctuary-backups/before-beta.135/`, aucun monde personnel ouvert.
+
+Packs normal/Test/template et comparateur natif également vérifiés dans
+`sanctuary-beta/build/`. Le checkout original garde ses changements préexistants.
+Reçus locaux ignorés : `build/shader135-artifact.json`, `build/shader135-isolated.json`,
+`build/shader135-prism.json`, `build/shader135-publication.log`.