Revert fullscreen Pause map layer while keeping Story and M shortcut

Reverts the layout experiment from 5ea7950 at the creator request. Restore beta.235 map presentation, retain 94fefc0, and withdraw the old trial pack without creating a new release.

.gitignore

@@ -15,3 +15,6 @@ screenshots/
 .env
 .env.*
 !.env.example
+__pycache__/
+/archives/web/snapshots/
+/ressources-pack/*.zip

AGENTS.md

@@ -11,8 +11,9 @@ 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 `mod_version` et `pack_version` dans `gradle.properties`, synchroniser `packwiz/pack.toml` et documenter le changement. Une simple modification documentaire n'incrémente pas les binaires.
+- 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.
 - Ne pas versionner de secrets, mondes, JAR générés ou dépendances téléchargées. Le wrapper Gradle fait exception.
 - Ne pas déployer dans une installation de jeu ou un serveur personnel sans demande correspondante. Les serveurs de test restent dans les dossiers de développement ignorés.

CONTRIBUTING.md

@@ -27,6 +27,11 @@ Les nombres, ressources et interfaces encore incertains peuvent rester des hypot
 
 Les commandes exactes de développement vivent dans le [README](README.md), afin de ne pas maintenir deux listes divergentes.
 
+Les livraisons du mod et du pack partagent le compteur `beta.xxx`,
+à partir de `beta.001`. Incrémenter les deux propriétés et le manifeste
+packwiz ensemble ; le tag reprend cette version exacte, sans `v`. Une modification
+documentaire seule ne consomme pas de numéro. Voir [Versionnement](docs/versioning.md).
+
 ## Vérifier la génération du monde
 
 Utiliser une sauvegarde de développement dédiée et conserver la seed des observations. Les vérifications pertinentes comprennent le spawn, les limites de l'île, le vide, les jointures de chunks, le comportement de l'eau, le redémarrage et l'arrivée de plusieurs joueurs.

THIRD_PARTY_NOTICES.md

@@ -4,6 +4,18 @@ Le code Sanctuary est distribué sous GPL-3.0-or-later, comme la version 26.2 do
 la génération est reprise. Voir `LICENSE` et `docs/migration-26.2.md` pour la
 provenance détaillée et le périmètre du portage.
 
+Le minage groupé beta.008 reprend les paliers, la sélection par faces et le
+contour de sélection de Sanctuary 26.2 (GPL-3.0-or-later, même dépôt historique
+en lecture seule). Le service de progression, le contrôle des gestes et le
+calcul de durée sont adaptés à la bêta et aux API Minecraft 26.3-pre-2.
+Voir `docs/mining-beta008.md` ; aucun mod externe de minage n'est embarqué.
+
+Construction beta.009 adapte le plan orienté `SanctuaryBuildPlane` et les
+principes de sélection/session de `gameplay/building` dans le même Sanctuary
+26.2, GPL-3.0-or-later. Les contextes de placement, permissions, gestes et
+migrations sont adaptés à la bêta et testés sur Minecraft 26.3-pre-2.
+Voir `docs/building-beta009.md`.
+
 Minecraft appartient à Mojang Studios / Microsoft. Sanctuary est un projet
 communautaire indépendant. Le dépôt ne redistribue pas le jeu.
 
@@ -21,6 +33,16 @@ Fabric Loader : Apache-2.0. Fabric API : Apache-2.0. Fabric Loom et le wrapper
 Gradle : Apache-2.0. Ces projets conservent leurs auteurs, notices et licences.
 Les dépendances sont résolues depuis leurs distributions officielles.
 
+Les six icônes de compétences dans
+`assets/sanctuary/textures/gui/progression/` ont été fournies par le créateur
+le 13 septembre 2026. Depuis beta.015, elles utilisent ses nouveaux fichiers
+`progression_heart.png`, `progression_food.png`, `progression_mining.png`,
+`progression_building.png`, `progression_breath.png` et `progression_inventory.png`.
+Les PNG 9×9 sont conservés octet pour octet, y compris leur transparence.
+Les noms de ressources restent stables : `food` correspond à `hunger`,
+`breath` à `breathing`, et le préfixe `progression_` est retiré.
+Les mêmes PNG sont préparés dans `ressources-pack/sanctuary/` pour le resource pack.
+
 Le fichier préexistant `ressources-pack/helloworld/assets/minecraft_title.png`
 est conservé comme source graphique fournie par le propriétaire du dépôt.
 Il n'est pas encore installé dans le pack généré. Sa provenance et son adaptation
@@ -29,3 +51,95 @@ Il n'est pas encore installé dans le pack généré. Sa provenance et son adapt
 Les resource packs, shaders et mods communautaires envisagés dans la vision
 ne sont pas inclus automatiquement. Chaque ajout aura une version, une source,
 un hash et les crédits de sa distribution.
+
+Demeure est intégré au code de Sanctuary depuis beta.204, sous GPL-3.0-or-later. Son modèle
+provient des sources de KOKA99CAB dans `Structures/demeure`, référencées par
+l’inventaire 26.2, et a été adapté à Minecraft 26.3-pre-2. Voir
+`mods/demeure/PROVENANCE.md` pour les empreintes et les différences du port.
+Le JAR Sanctuary conserve sa licence GPL et `licenses/Demeure-PROVENANCE.md`.
+
+## Inventaire beta.010
+
+Les interfaces, algorithmes de transfert et PNG d'inventaire proviennent de
+`../26.2/sanctuary`, projet Sanctuary de Koka sous GPL-3.0-or-later. Le portage
+conserve les six variantes personnelles, la barre rapide et sa sélection,
+les panneaux des conteneurs natifs et leurs fonds supérieurs. Les PNG sont
+copiés sans retouche dans le namespace `sanctuary` ; le serveur 26.2 et ses
+sauvegardes ne sont pas modifiés. Cape, œuf de compagnon et moteur Aircraft
+ne font pas partie de ce lot.
+
+## Équipement beta.018
+
+Les repères de cases vides `egg.png`, `cape.png` et `cosmetics.png` (16 × 16)
+proviennent des fichiers fournis par le créateur le 13 septembre 2026 dans
+`../textures/`. Ils sont conservés octet pour octet dans le mod et le resource pack.
+
+Cape Zéro utilise temporairement le visuel **Vanilla Cape** de Mojang/Microsoft,
+téléchargé depuis le serveur officiel de textures Minecraft :
+https://textures.minecraft.net/texture/f9a76537647989f9a0b6d001e320dac591c359e9e61a31f4ce11c88f207f0ad4
+SHA-256 : `f9a76537647989f9a0b6d001e320dac591c359e9e61a31f4ce11c88f207f0ad4`.
+Présentation originale : https://www.minecraft.net/en-us/article/introducing-vanilla-cape
+L’icône d’objet correspondante provient de `../26.2/sanctuary`
+(`textures/item/cape/vanilla_cape.png`). Ces images sont un placeholder de test,
+restent la propriété de leurs auteurs et ne sont pas placées sous la licence
+du code Sanctuary. Il ne s’agit pas d’une cape officielle accordée au compte.
+
+Les familiers utilisent les modèles et textures résolus par Minecraft installé ;
+aucune copie des textures de mobs ni aucun ancien pouvoir n’est embarqué.
+
+## JEI beta.024
+
+Just Enough Items, mezz, MIT : fork source de la branche 26.2, commit
+`aae2dfcfb82e6b5bce787ba72bb2eda7339b274f`, adapté à Minecraft 26.3-pre-2.
+Le JAR contient la licence d’origine et [la provenance du portage](mods/jei/PROVENANCE.md).
+Les patches et la reconstruction sont fournis ; les téléchargements restent ignorés.
+Baked Substring Index 0.1.0 (MIT, James Mitchell) et Suffix Tree 1.1.0
+(Apache-2.0, Alessandro Bahgat Shehata) sont inclus avec leurs licences.
+
+## Références solaires beta.037
+
+Les villes de référence et leurs coordonnées publiques proviennent de `zone.tab`
+et les alias de `backward`, dans IANA tzdata **2026d** (domaine public).
+Archive : https://data.iana.org/time-zones/releases/tzdata2026d.tar.gz
+SHA-256 : `0cb2aa8e333c3dc049badc42a0c61f21987b8cd44e107fa900bad764aacc7767`.
+Licence : https://data.iana.org/time-zones/tzdb/LICENSE
+Le script `scripts/compile_solar_references.py` produit les 549 références/alias
+embarqués. Le jeu ne télécharge ni ces données ni une position utilisateur.
+Les équations saisonnières approximatives suivent la fiche publique NOAA :
+https://gml.noaa.gov/grad/solcalc/solareqns.PDF
+
+## Informations alimentaires beta.038 — AppleSkin
+
+L’asset `assets/sanctuary/textures/gui/food_details.png` est une copie intacte
+de `resources/assets/appleskin/textures/icons.png` par squeek502 et contributeurs,
+[AppleSkin, branche 26.2-fabric](https://github.com/squeek502/AppleSkin/tree/62513191f6a3497447595c2215d466ad1d2bdb92),
+commit `62513191f6a3497447595c2215d466ad1d2bdb92`, sous Unlicense.
+Le comportement des contours et leurs coordonnées d’atlas suivent cette source ;
+l’intégration, la synchronisation et le calcul de capacité sont propres à Sanctuary.
+Texte de licence : [Unlicense amont](https://github.com/squeek502/AppleSkin/blob/62513191f6a3497447595c2215d466ad1d2bdb92/LICENSE).
+
+## Briques et argile beta.102
+
+Les seize textures de blocs de briques ont été fournies par le créateur de
+Sanctuary. Les variantes d’argile, de boule d’argile et de brique sont des
+recolorations des textures Minecraft 26.3 de Mojang/Microsoft. Les ressources
+de modèles, butin et états reprennent leurs équivalents natifs 26.3.
+`tools/generate-colored-bricks.py` documente cette transformation ;
+`tools/colored-bricks-palette.json` conserve couleurs et empreintes des PNG fournis.
+Ces ressources dérivées ne sont pas présentées comme des créations originales.
+
+## Clé dorée beta.121
+
+Le PNG 16 × 16 `golden_wrench.png` a été fourni par le créateur de Sanctuary
+le 17 septembre 2026. Il est conservé octet pour octet dans le mod, le pack
+intégré et le template personnel (SHA-256
+`a97570908db75caf8e6fc2f5ecabf12c54fd99bfea7be634df66c4310dca22af`).
+Le template regroupe les ressources client déjà distribuées par Sanctuary ;
+leurs crédits et conditions respectives restent applicables.
+
+MariaDB Connector/J 3.5.10 (`org.mariadb.jdbc:mariadb-java-client`),
+MariaDB Corporation et contributeurs : LGPL-2.1-or-later. Le JAR officiel est
+embarqué comme dépendance imbriquée, sans modification, pour le stockage
+communautaire optionnel. Sa licence est fournie dans `licenses/mariadb-connector-j-LGPL-2.1.txt` du JAR Sanctuary.
+Sources correspondantes : https://github.com/mariadb-corporation/mariadb-connector-j/tree/3.5.10
+(distribution Maven Central 3.5.10).

archives/web/README.md

@@ -0,0 +1,50 @@
+# Archives pour le site Sanctuary
+
+Ce dossier conserve les références réutilisables pour le site et le Galactium.
+Il est indépendant de `build` : nettoyer les builds ne supprime pas les
+collections placées ici. Aucun contenu n'est publié automatiquement.
+
+- [Maquette Blocodex autonome](blocodex-navigation-v1/index.html) : ouvrir
+  ce fichier dans un navigateur, même hors ligne. Copier son dossier suffit.
+- [Source de la maquette](blocodex-navigation-v1/fragment.html) et
+  [guide de réutilisation](blocodex-navigation-v1/README.md).
+- [ZIP léger de la maquette](snapshots/Sanctuary-Blocodex-2026-09-13-v1.zip)
+  (10 188 octets), avec HTML autonome et source éditable.
+- [Collection du 13 septembre 2026](snapshots/2026-09-13-web-v1/index.html) :
+  catalogue des images, PDF, documents, atlas et maquette.
+- [Archive ZIP complète](snapshots/Sanctuary-Web-Archive-2026-09-13-v1.zip).
+- [Inventaire et empreintes](catalog-2026-09-13-web-v1.json).
+
+Collection initiale : **782 fichiers**, ZIP de **196 242 020 octets**.
+Copie vérifiée par SHA-256, intégrité ZIP et empreintes de chaque membre
+contrôlées ; les trois manifestes originaux des atlas passent également.
+Reçu : [receipt-2026-09-13-web-v1.json](receipt-2026-09-13-web-v1.json).
+
+Les collections volumineuses et ZIP sont conservés localement dans
+`snapshots/`, ignoré par Git. Les sources de la maquette, les notices, le
+script et le catalogue peuvent être versionnés. Une copie locale durable
+ne remplace pas une sauvegarde sur un autre support.
+
+Le fonds alpha réunit les images et PDF retrouvés dans les sorties du dépôt
+jusqu'à alpha.30.7 et les trois atlas complets alpha.30.5, 30.6 et 30.7.
+Leur provenance distingue artefacts livrés, essais intermédiaires et documents
+de conception. Une image de recherche n'est pas une preuve de fonctionnalité
+livrée. Les sources originales restent intactes et les doublons conservent
+leurs chemins pour ne pas perdre leur contexte.
+
+La collection inclut aussi les captures beta.003/004, les six icônes de
+compétences et la maquette validée du Blocodex, dans des catégories séparées.
+Les documents sont une photographie au jour de l'archivage ; les archives
+atlas originales conservent en plus leur documentation historique exacte.
+
+Une version de collection est immuable : le script refuse de l'écraser.
+Pour une nouvelle collecte, choisir un autre identifiant :
+
+```sh
+python3 scripts/archive_web_assets.py --id AAAA-MM-JJ-web-v2
+```
+
+Le catalogue JSON contient les chemins relatifs, sources, catégories, versions
+déduites des noms, tailles et SHA-256, pour une future ingestion par le site.
+La présence d'un fichier dans l'archive ne change pas sa licence : conserver
+les notices et les crédits, notamment pour les contenus issus de Minecraft.

archives/web/blocodex-navigation-v1/README.md

@@ -0,0 +1,30 @@
+# Blocodex — référence interactive v1
+
+Conception et navigation approuvées par le créateur le 13 septembre 2026,
+après beta.004. La maquette contient des données fictives.
+
+Ouvrir `index.html` dans un navigateur. Elle fonctionne sans Codex, sans
+serveur, sans compte, sans connexion et sans dépendance téléchargée.
+Les interactions sont en mémoire : recharger revient à l'état initial.
+Le délai de 24 heures est illustré, pas appliqué à un véritable habitant.
+La vue opérateur est une simulation d'interface, pas une permission réelle.
+
+`fragment.html` conserve exactement la source affichée dans la conversation.
+`index.html` l'encapsule dans une page française autonome, avec ses styles
+et son JavaScript. Le sélecteur de variante Tweak est facultatif et reste
+inactif hors Codex ; aucune fonction de la navigation n'en dépend.
+
+Pour le site, copier le dossier ou intégrer le fragment dans un composant
+isolé. Conserver l'identifiant racine unique et exécuter le script après le
+montage ; prévoir une instance par page. Les données et actions réelles
+seront raccordées ultérieurement aux services Sanctuary.
+
+L'export standard Visualize a été produit avant l'encapsulation hors ligne.
+L'archive réutilisable garde uniquement la maquette et son code, sans le
+runtime d'aperçu, ses bibliothèques CDN ou un appel aux API de l'application.
+
+Origine : discussion Sanctuary / Blocodex du 13 septembre 2026.
+La mise en page a été créée pour ce projet ; aucun sprite Minecraft ou police
+propriétaire n'est embarqué dans cette maquette. Les polices sont système.
+Le cadrage est conservé dans `references/docs/blocodex-navigation.md` au sein
+de la collection complète. Le code du jeu reste en beta.004 à cet archivage.

archives/web/blocodex-navigation-v1/fragment.html

@@ -0,0 +1,124 @@
+<div id="sanctuary-navigation" aria-label="Proposition de navigation du Blocodex">
+  <style>
+    #sanctuary-navigation {font:14px/1.5 ui-monospace,SFMono-Regular,Consolas,monospace;color:#ededed;color-scheme:dark;}
+    #sanctuary-navigation * {box-sizing:border-box;}
+    #sanctuary-navigation .mc-window {background:#232820;border:2px solid #121411;}
+    #sanctuary-navigation .mc-head {padding:14px 12px 10px;background:#20261e;border-bottom:2px solid #747b6e;}
+    #sanctuary-navigation .mc-title {text-align:center;font-size:20px;text-shadow:2px 2px #111;margin-bottom:12px;}
+    #sanctuary-navigation .mc-nav {display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:5px;}
+    #sanctuary-navigation button {font:inherit;color:#f2f2f2;cursor:pointer;background:#626262;border:2px solid #121212;box-shadow:inset 2px 2px #9b9b9b,inset -2px -2px #373737;border-radius:0;padding:7px 9px;min-width:0;text-shadow:1px 1px #242424;}
+    #sanctuary-navigation button:hover {background:#787878;}
+    #sanctuary-navigation button[aria-pressed="true"] {background:#32382f;box-shadow:inset 1px 1px #192015;color:#b7d7a4;}
+    #sanctuary-navigation button:disabled {background:#343434;box-shadow:none;color:#aaa;cursor:default;}
+    #sanctuary-navigation .mc-preview {display:flex;align-items:center;justify-content:space-between;gap:8px;flex-wrap:wrap;padding:10px 12px;background:#171b16;color:#c6cdc1;font-size:12px;}
+    #sanctuary-navigation select {font:inherit;background:#30362b;color:#fff;border:1px solid #92998c;border-radius:0;padding:5px;max-width:100%;}
+    #sanctuary-navigation .mc-local {display:flex;gap:5px;flex-wrap:wrap;padding:10px 12px 0;}
+    #sanctuary-navigation .mc-local button {padding:4px 9px;}
+    #sanctuary-navigation .mc-main {padding:18px 16px;min-height:300px;}
+    #sanctuary-navigation .mc-two {display:grid;grid-template-columns:1fr 1fr;gap:20px;}
+    #sanctuary-navigation .mc-heading {font-size:16px;margin:0 0 10px;color:#b7d7a4;font-weight:400;}
+    #sanctuary-navigation .mc-caption {color:#c2c8be;font-size:12px;margin:5px 0 12px;}
+    #sanctuary-navigation .mc-name {font-size:21px;color:#87c7f0;}
+    #sanctuary-navigation .mc-list {display:grid;gap:6px;margin-bottom:12px;}
+    #sanctuary-navigation .mc-row {display:flex;justify-content:space-between;align-items:center;gap:14px;padding:8px 0;border-bottom:1px solid #444b3e;}
+    #sanctuary-navigation .mc-row span:last-child {text-align:right;color:#c4cec1;font-size:12px;}
+    #sanctuary-navigation .mc-choice {display:block;margin:0 0 14px;}
+    #sanctuary-navigation .mc-choice select {display:block;width:100%;margin-top:5px;}
+    #sanctuary-navigation .mc-main p {margin:0 0 12px;}
+    #sanctuary-navigation .mc-link {width:100%;text-align:left;}
+    #sanctuary-navigation .mc-op {color:#f1cd82;border-bottom:1px solid #9c8150;padding:0 0 12px;margin-bottom:14px;}
+    #sanctuary-navigation .mc-footer {padding:14px;text-align:center;border-top:2px solid #747b6e;background:#20261e;}
+    #sanctuary-navigation .mc-footer button {width:min(240px,100%);}
+    #sanctuary-navigation .mc-detail {padding:12px;background:#181d16;border-left:2px solid #8aa579;}
+    #sanctuary-navigation .mc-lock {display:grid;gap:8px;max-width:360px;margin:25px auto;text-align:center;}
+    #sanctuary-navigation .mc-badge {color:#e2ce88;}
+    #sanctuary-navigation .mc-status {color:#b7d7a4;font-size:12px;}
+    @media(max-width:500px) {
+      #sanctuary-navigation .mc-nav {grid-template-columns:repeat(2,minmax(0,1fr));}
+      #sanctuary-navigation .mc-two {grid-template-columns:1fr;gap:16px;}
+      #sanctuary-navigation .mc-main {padding:14px 12px;min-height:280px;}
+      #sanctuary-navigation .mc-row {gap:8px;}
+    }
+    @media(pointer:coarse) {#sanctuary-navigation button {min-height:44px;}}
+  </style>
+  <div class="mc-window">
+    <div class="mc-preview">
+      <span>Maquette · données fictives</span>
+      <label>Vue d’essai <select data-role aria-label="Profil simulé"><option value="player">Joueur</option><option value="operator">Opérateur</option></select></label>
+    </div>
+    <div class="mc-head">
+      <div class="mc-title">Blocodex</div>
+      <nav class="mc-nav" aria-label="Rubriques du Blocodex">
+        <button type="button" data-tab="discovery" aria-pressed="false">Découvertes</button>
+        <button type="button" data-tab="progress" aria-pressed="false">Progression</button>
+        <button type="button" data-tab="world" aria-pressed="false">Monde</button>
+        <button type="button" data-tab="inhabitant" aria-pressed="true">Habitant</button>
+      </nav>
+    </div>
+    <nav class="mc-local" aria-label="Sous-rubriques"></nav>
+    <div class="mc-main" aria-live="polite"></div>
+    <div class="mc-footer"><button type="button" data-done>Terminé</button></div>
+  </div>
+  <script>
+    (() => {
+      const root=document.getElementById('sanctuary-navigation');
+      const content=root.querySelector('.mc-main');
+      const local=root.querySelector('.mc-local');
+      const nav=root.querySelector('.mc-nav');
+      const state={tab:'inhabitant',page:'',role:'player',favorite:'Loup',changed:false,trophy:'Des diamants !',constellation:'La Traversée',detail:'',worldLabel:'Monde'};
+      const pages={discovery:['Blocs','Objets','Créatures','Recettes'],progress:['Capacités','Exploits','Statistiques'],world:['Atlas','Constructions','Histoire'],inhabitant:[]};
+      const knowledge={Blocs:[['Pierre','Roche minée et déjà possédée.',true],['Bûche de chêne','Bois observé et récolté.',true],['Terre','Bloc observé et déjà possédé.',true],['Débris antiques','Aucune découverte personnelle.',false]],Objets:[['Pomme','Objet ramassé. Sa fiche décrit ses usages connus.',true],['Pioche en pierre','Outil fabriqué et déjà possédé.',true],['Élytre','Aucune découverte personnelle.',false]],Créatures:[['Loup','Créature observée. Peut être choisie comme favorite.',true],['Chat','Créature observée. Peut être choisie comme favorite.',true],['Renard','Aucune découverte personnelle.',false]]};
+      const esc=value=>String(value).replace(/[&<>"']/g,c=>({'&':'&amp;','<':'&lt;','>':'&gt;','"':'&quot;',"'":'&#39;'}[c]));
+      const row=(a,b)=>`<div class="mc-row"><span>${esc(a)}</span><span>${esc(b)}</span></div>`;
+      const button=(label,action)=>`<button type="button" data-action="${action}">${label}</button>`;
+      function go(tab,page=''){state.tab=tab;state.page=page||pages[tab][0]||'';state.detail='';render();}
+      function render(){
+        root.querySelector('[data-tab="world"]').textContent=state.worldLabel;
+        nav.querySelectorAll('button').forEach(b=>b.setAttribute('aria-pressed',String(b.dataset.tab===state.tab)));
+        local.innerHTML=pages[state.tab].map(p=>`<button type="button" data-page="${p}" aria-pressed="${p===state.page}">${p}</button>`).join('');
+        local.hidden=!pages[state.tab].length;
+        const op=state.role==='operator'?'<div class="mc-op">Vue opérateur · inspection sans découverte automatique</div>':'';
+        let body='';
+        if(state.tab==='inhabitant'){
+          body=`<div class="mc-two"><section><div class="mc-name">poupoutain</div><p class="mc-caption">Habitant de Sanctuary</p><p>Je construis des passages entre les îles.</p><div class="mc-heading">À l’honneur</div><div class="mc-detail"><span class="mc-badge">★ ${esc(state.trophy)}</span><div class="mc-caption">Exploit Minecraft accompli</div>${button('Choisir un exploit','achievements')}</div></section><section><label class="mc-choice">Constellation favorite<select data-constellation><option${state.constellation==='La Traversée'?' selected':''}>La Traversée</option><option${state.constellation==='Le Refuge'?' selected':''}>Le Refuge</option></select></label><label class="mc-choice">Créature favorite<select data-favorite ${state.changed?'disabled':''}><option${state.favorite==='Loup'?' selected':''}>Loup</option><option${state.favorite==='Chat'?' selected':''}>Chat</option></select></label><div class="mc-caption">Choix parmi les créatures découvertes.</div><p class="mc-status">${state.changed?'Favori modifié · prochain changement dans 24 h':'Changement disponible'}</p>${button('Ouvrir le bestiaire','creatures')}</section></div>`;
+        } else if(state.tab==='discovery'){
+          if(state.page==='Recettes') body=`<div class="mc-heading">Recettes révélées</div>${row('Pioche en pierre','Consultable')}${row('Planches de chêne','Consultable')}<p class="mc-caption">La fabrication manuelle reste libre.</p>`;
+          else {
+            const entries=knowledge[state.page];
+            const visible=entries.filter(e=>e[2]||state.role==='operator');
+            body=`${op}<div class="mc-heading">${state.page} · ${visible.length} ${state.role==='operator'?'entrées':'découvertes'}</div><div class="mc-two"><div class="mc-list">${visible.map(e=>`<button type="button" class="mc-link" data-entry="${esc(e[0])}">${esc(e[0])}${e[2]?'':' · Non découvert'}</button>`).join('')}</div><div class="mc-detail">${state.detail?esc(state.detail):'Sélectionner une découverte'}</div></div>`;
+          }
+        } else if(state.tab==='progress'){
+          if(state.page==='Capacités') body=`<div class="mc-two"><section><div class="mc-heading">Compétences</div>${row('Vie','3')}${row('Faim','3')}${row('Minage','À venir')}${row('Construction','À venir')}${row('Souffle','3')}${row('Inventaire','À venir')}</section><section><div class="mc-heading">Aptitudes</div>${row('Noms des mobs','Acquis')}${row('Minimap','À acquérir')}${row('Grande carte','À acquérir')}${row('Marqueurs','À acquérir')}</section></div>`;
+          if(state.page==='Exploits') body=`<div class="mc-heading">Minecraft</div><div class="mc-list"><button type="button" class="mc-link" data-trophy="Des diamants !">★ Des diamants ! · Épingler au passeport</button><button type="button" class="mc-link" data-trophy="L’âge de pierre">★ L’âge de pierre · Épingler au passeport</button></div><div class="mc-heading">Sanctuary · accomplissements du serveur</div><div class="mc-caption">Objectifs collectifs et ouvertures d’expansions.</div>`;
+          if(state.page==='Statistiques') body=`<div class="mc-heading">Mes statistiques Minecraft</div>${row('Blocs minés','248')}${row('Distance parcourue','3,2 km')}${row('Temps de jeu','2 h 14 min')}<div class="mc-caption">Accès aux compteurs vanilla depuis la progression.</div>`;
+        } else if(state.tab==='world'){
+          if(state.page==='Atlas') body=`<div class="mc-lock"><div class="mc-heading">Grande carte</div><p>Aptitude à acquérir</p>${button('Voir dans Progression','abilities')}<div class="mc-caption">Minimap, grande carte et marqueurs se débloquent séparément.</div></div>`;
+          if(state.page==='Constructions') body=`<div class="mc-heading">Mes plans</div><div class="mc-detail"><p>Passerelle en bois</p>${row('Planches de chêne','64')}${row('Barrières de chêne','24')}<div class="mc-caption">Plan d’exemple · matériaux déjà connus</div><button type="button" disabled>Projection Litematica · intégration à venir</button></div>`;
+          if(state.page==='Histoire') body=`<div class="mc-heading">Histoire du monde</div>${row('Chronique','Événements et découvertes')}${row('Gazette','Nouvelles et courrier')}${row('Archives','Documents révélés du Galactium')}<div class="mc-caption">Seules les histoires révélées apparaissent.</div>`;
+        }
+        content.innerHTML=body;
+      }
+      root.addEventListener('click',event=>{
+        const b=event.target.closest('button');if(!b||b.disabled)return;
+        if(b.dataset.tab){go(b.dataset.tab);return;}
+        if(b.dataset.page){go(state.tab,b.dataset.page);return;}
+        if(b.dataset.trophy){state.trophy=b.dataset.trophy;go('inhabitant');return;}
+        if(b.dataset.entry){const e=knowledge[state.page].find(e=>e[0]===b.dataset.entry);state.detail=e[0]+' — '+e[1];render();return;}
+        if(b.dataset.action==='achievements')go('progress','Exploits');
+        if(b.dataset.action==='creatures')go('discovery','Créatures');
+        if(b.dataset.action==='abilities')go('progress','Capacités');
+        if(b.hasAttribute('data-done')){content.innerHTML='<div class="mc-lock">Retour au jeu</div>';local.hidden=true;b.textContent='Rouvrir le Blocodex';b.removeAttribute('data-done');b.setAttribute('data-reopen','');}
+        else if(b.hasAttribute('data-reopen')){b.textContent='Terminé';b.removeAttribute('data-reopen');b.setAttribute('data-done','');render();}
+      });
+      root.addEventListener('change',event=>{
+        const e=event.target;
+        if(e.hasAttribute('data-role')){state.role=e.value;state.detail='';render();}
+        if(e.hasAttribute('data-favorite')&&!state.changed){state.favorite=e.value;state.changed=true;render();}
+        if(e.hasAttribute('data-constellation')){state.constellation=e.value;render();}
+      });
+      render();
+      if(globalThis.Tweak){const tweak=new Tweak({container:root,onChange:render});tweak.addSelect(state,'worldLabel',{label:'Nom de la troisième rubrique',options:['Monde','Histoire']});}
+    })();
+  </script>
+</div>

archives/web/blocodex-navigation-v1/index.html

@@ -0,0 +1,138 @@
+<!doctype html>
+<html lang="fr">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<meta name="referrer" content="no-referrer">
+<meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'unsafe-inline'; style-src 'unsafe-inline'; img-src data:; connect-src 'none'; base-uri 'none'; form-action 'none'">
+<title>Sanctuary — Blocodex, référence interactive</title>
+<style>html{background:#171b16;color-scheme:dark}body{margin:0;padding:16px;max-width:1024px;margin-inline:auto}button,select{font-family:inherit}</style>
+</head>
+<body>
+<div id="sanctuary-navigation" aria-label="Proposition de navigation du Blocodex">
+  <style>
+    #sanctuary-navigation {font:14px/1.5 ui-monospace,SFMono-Regular,Consolas,monospace;color:#ededed;color-scheme:dark;}
+    #sanctuary-navigation * {box-sizing:border-box;}
+    #sanctuary-navigation .mc-window {background:#232820;border:2px solid #121411;}
+    #sanctuary-navigation .mc-head {padding:14px 12px 10px;background:#20261e;border-bottom:2px solid #747b6e;}
+    #sanctuary-navigation .mc-title {text-align:center;font-size:20px;text-shadow:2px 2px #111;margin-bottom:12px;}
+    #sanctuary-navigation .mc-nav {display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:5px;}
+    #sanctuary-navigation button {font:inherit;color:#f2f2f2;cursor:pointer;background:#626262;border:2px solid #121212;box-shadow:inset 2px 2px #9b9b9b,inset -2px -2px #373737;border-radius:0;padding:7px 9px;min-width:0;text-shadow:1px 1px #242424;}
+    #sanctuary-navigation button:hover {background:#787878;}
+    #sanctuary-navigation button[aria-pressed="true"] {background:#32382f;box-shadow:inset 1px 1px #192015;color:#b7d7a4;}
+    #sanctuary-navigation button:disabled {background:#343434;box-shadow:none;color:#aaa;cursor:default;}
+    #sanctuary-navigation .mc-preview {display:flex;align-items:center;justify-content:space-between;gap:8px;flex-wrap:wrap;padding:10px 12px;background:#171b16;color:#c6cdc1;font-size:12px;}
+    #sanctuary-navigation select {font:inherit;background:#30362b;color:#fff;border:1px solid #92998c;border-radius:0;padding:5px;max-width:100%;}
+    #sanctuary-navigation .mc-local {display:flex;gap:5px;flex-wrap:wrap;padding:10px 12px 0;}
+    #sanctuary-navigation .mc-local button {padding:4px 9px;}
+    #sanctuary-navigation .mc-main {padding:18px 16px;min-height:300px;}
+    #sanctuary-navigation .mc-two {display:grid;grid-template-columns:1fr 1fr;gap:20px;}
+    #sanctuary-navigation .mc-heading {font-size:16px;margin:0 0 10px;color:#b7d7a4;font-weight:400;}
+    #sanctuary-navigation .mc-caption {color:#c2c8be;font-size:12px;margin:5px 0 12px;}
+    #sanctuary-navigation .mc-name {font-size:21px;color:#87c7f0;}
+    #sanctuary-navigation .mc-list {display:grid;gap:6px;margin-bottom:12px;}
+    #sanctuary-navigation .mc-row {display:flex;justify-content:space-between;align-items:center;gap:14px;padding:8px 0;border-bottom:1px solid #444b3e;}
+    #sanctuary-navigation .mc-row span:last-child {text-align:right;color:#c4cec1;font-size:12px;}
+    #sanctuary-navigation .mc-choice {display:block;margin:0 0 14px;}
+    #sanctuary-navigation .mc-choice select {display:block;width:100%;margin-top:5px;}
+    #sanctuary-navigation .mc-main p {margin:0 0 12px;}
+    #sanctuary-navigation .mc-link {width:100%;text-align:left;}
+    #sanctuary-navigation .mc-op {color:#f1cd82;border-bottom:1px solid #9c8150;padding:0 0 12px;margin-bottom:14px;}
+    #sanctuary-navigation .mc-footer {padding:14px;text-align:center;border-top:2px solid #747b6e;background:#20261e;}
+    #sanctuary-navigation .mc-footer button {width:min(240px,100%);}
+    #sanctuary-navigation .mc-detail {padding:12px;background:#181d16;border-left:2px solid #8aa579;}
+    #sanctuary-navigation .mc-lock {display:grid;gap:8px;max-width:360px;margin:25px auto;text-align:center;}
+    #sanctuary-navigation .mc-badge {color:#e2ce88;}
+    #sanctuary-navigation .mc-status {color:#b7d7a4;font-size:12px;}
+    @media(max-width:500px) {
+      #sanctuary-navigation .mc-nav {grid-template-columns:repeat(2,minmax(0,1fr));}
+      #sanctuary-navigation .mc-two {grid-template-columns:1fr;gap:16px;}
+      #sanctuary-navigation .mc-main {padding:14px 12px;min-height:280px;}
+      #sanctuary-navigation .mc-row {gap:8px;}
+    }
+    @media(pointer:coarse) {#sanctuary-navigation button {min-height:44px;}}
+  </style>
+  <div class="mc-window">
+    <div class="mc-preview">
+      <span>Maquette · données fictives</span>
+      <label>Vue d’essai <select data-role aria-label="Profil simulé"><option value="player">Joueur</option><option value="operator">Opérateur</option></select></label>
+    </div>
+    <div class="mc-head">
+      <div class="mc-title">Blocodex</div>
+      <nav class="mc-nav" aria-label="Rubriques du Blocodex">
+        <button type="button" data-tab="discovery" aria-pressed="false">Découvertes</button>
+        <button type="button" data-tab="progress" aria-pressed="false">Progression</button>
+        <button type="button" data-tab="world" aria-pressed="false">Monde</button>
+        <button type="button" data-tab="inhabitant" aria-pressed="true">Habitant</button>
+      </nav>
+    </div>
+    <nav class="mc-local" aria-label="Sous-rubriques"></nav>
+    <div class="mc-main" aria-live="polite"></div>
+    <div class="mc-footer"><button type="button" data-done>Terminé</button></div>
+  </div>
+  <script>
+    (() => {
+      const root=document.getElementById('sanctuary-navigation');
+      const content=root.querySelector('.mc-main');
+      const local=root.querySelector('.mc-local');
+      const nav=root.querySelector('.mc-nav');
+      const state={tab:'inhabitant',page:'',role:'player',favorite:'Loup',changed:false,trophy:'Des diamants !',constellation:'La Traversée',detail:'',worldLabel:'Monde'};
+      const pages={discovery:['Blocs','Objets','Créatures','Recettes'],progress:['Capacités','Exploits','Statistiques'],world:['Atlas','Constructions','Histoire'],inhabitant:[]};
+      const knowledge={Blocs:[['Pierre','Roche minée et déjà possédée.',true],['Bûche de chêne','Bois observé et récolté.',true],['Terre','Bloc observé et déjà possédé.',true],['Débris antiques','Aucune découverte personnelle.',false]],Objets:[['Pomme','Objet ramassé. Sa fiche décrit ses usages connus.',true],['Pioche en pierre','Outil fabriqué et déjà possédé.',true],['Élytre','Aucune découverte personnelle.',false]],Créatures:[['Loup','Créature observée. Peut être choisie comme favorite.',true],['Chat','Créature observée. Peut être choisie comme favorite.',true],['Renard','Aucune découverte personnelle.',false]]};
+      const esc=value=>String(value).replace(/[&<>"']/g,c=>({'&':'&amp;','<':'&lt;','>':'&gt;','"':'&quot;',"'":'&#39;'}[c]));
+      const row=(a,b)=>`<div class="mc-row"><span>${esc(a)}</span><span>${esc(b)}</span></div>`;
+      const button=(label,action)=>`<button type="button" data-action="${action}">${label}</button>`;
+      function go(tab,page=''){state.tab=tab;state.page=page||pages[tab][0]||'';state.detail='';render();}
+      function render(){
+        root.querySelector('[data-tab="world"]').textContent=state.worldLabel;
+        nav.querySelectorAll('button').forEach(b=>b.setAttribute('aria-pressed',String(b.dataset.tab===state.tab)));
+        local.innerHTML=pages[state.tab].map(p=>`<button type="button" data-page="${p}" aria-pressed="${p===state.page}">${p}</button>`).join('');
+        local.hidden=!pages[state.tab].length;
+        const op=state.role==='operator'?'<div class="mc-op">Vue opérateur · inspection sans découverte automatique</div>':'';
+        let body='';
+        if(state.tab==='inhabitant'){
+          body=`<div class="mc-two"><section><div class="mc-name">poupoutain</div><p class="mc-caption">Habitant de Sanctuary</p><p>Je construis des passages entre les îles.</p><div class="mc-heading">À l’honneur</div><div class="mc-detail"><span class="mc-badge">★ ${esc(state.trophy)}</span><div class="mc-caption">Exploit Minecraft accompli</div>${button('Choisir un exploit','achievements')}</div></section><section><label class="mc-choice">Constellation favorite<select data-constellation><option${state.constellation==='La Traversée'?' selected':''}>La Traversée</option><option${state.constellation==='Le Refuge'?' selected':''}>Le Refuge</option></select></label><label class="mc-choice">Créature favorite<select data-favorite ${state.changed?'disabled':''}><option${state.favorite==='Loup'?' selected':''}>Loup</option><option${state.favorite==='Chat'?' selected':''}>Chat</option></select></label><div class="mc-caption">Choix parmi les créatures découvertes.</div><p class="mc-status">${state.changed?'Favori modifié · prochain changement dans 24 h':'Changement disponible'}</p>${button('Ouvrir le bestiaire','creatures')}</section></div>`;
+        } else if(state.tab==='discovery'){
+          if(state.page==='Recettes') body=`<div class="mc-heading">Recettes révélées</div>${row('Pioche en pierre','Consultable')}${row('Planches de chêne','Consultable')}<p class="mc-caption">La fabrication manuelle reste libre.</p>`;
+          else {
+            const entries=knowledge[state.page];
+            const visible=entries.filter(e=>e[2]||state.role==='operator');
+            body=`${op}<div class="mc-heading">${state.page} · ${visible.length} ${state.role==='operator'?'entrées':'découvertes'}</div><div class="mc-two"><div class="mc-list">${visible.map(e=>`<button type="button" class="mc-link" data-entry="${esc(e[0])}">${esc(e[0])}${e[2]?'':' · Non découvert'}</button>`).join('')}</div><div class="mc-detail">${state.detail?esc(state.detail):'Sélectionner une découverte'}</div></div>`;
+          }
+        } else if(state.tab==='progress'){
+          if(state.page==='Capacités') body=`<div class="mc-two"><section><div class="mc-heading">Compétences</div>${row('Vie','3')}${row('Faim','3')}${row('Minage','À venir')}${row('Construction','À venir')}${row('Souffle','3')}${row('Inventaire','À venir')}</section><section><div class="mc-heading">Aptitudes</div>${row('Noms des mobs','Acquis')}${row('Minimap','À acquérir')}${row('Grande carte','À acquérir')}${row('Marqueurs','À acquérir')}</section></div>`;
+          if(state.page==='Exploits') body=`<div class="mc-heading">Minecraft</div><div class="mc-list"><button type="button" class="mc-link" data-trophy="Des diamants !">★ Des diamants ! · Épingler au passeport</button><button type="button" class="mc-link" data-trophy="L’âge de pierre">★ L’âge de pierre · Épingler au passeport</button></div><div class="mc-heading">Sanctuary · accomplissements du serveur</div><div class="mc-caption">Objectifs collectifs et ouvertures d’expansions.</div>`;
+          if(state.page==='Statistiques') body=`<div class="mc-heading">Mes statistiques Minecraft</div>${row('Blocs minés','248')}${row('Distance parcourue','3,2 km')}${row('Temps de jeu','2 h 14 min')}<div class="mc-caption">Accès aux compteurs vanilla depuis la progression.</div>`;
+        } else if(state.tab==='world'){
+          if(state.page==='Atlas') body=`<div class="mc-lock"><div class="mc-heading">Grande carte</div><p>Aptitude à acquérir</p>${button('Voir dans Progression','abilities')}<div class="mc-caption">Minimap, grande carte et marqueurs se débloquent séparément.</div></div>`;
+          if(state.page==='Constructions') body=`<div class="mc-heading">Mes plans</div><div class="mc-detail"><p>Passerelle en bois</p>${row('Planches de chêne','64')}${row('Barrières de chêne','24')}<div class="mc-caption">Plan d’exemple · matériaux déjà connus</div><button type="button" disabled>Projection Litematica · intégration à venir</button></div>`;
+          if(state.page==='Histoire') body=`<div class="mc-heading">Histoire du monde</div>${row('Chronique','Événements et découvertes')}${row('Gazette','Nouvelles et courrier')}${row('Archives','Documents révélés du Galactium')}<div class="mc-caption">Seules les histoires révélées apparaissent.</div>`;
+        }
+        content.innerHTML=body;
+      }
+      root.addEventListener('click',event=>{
+        const b=event.target.closest('button');if(!b||b.disabled)return;
+        if(b.dataset.tab){go(b.dataset.tab);return;}
+        if(b.dataset.page){go(state.tab,b.dataset.page);return;}
+        if(b.dataset.trophy){state.trophy=b.dataset.trophy;go('inhabitant');return;}
+        if(b.dataset.entry){const e=knowledge[state.page].find(e=>e[0]===b.dataset.entry);state.detail=e[0]+' — '+e[1];render();return;}
+        if(b.dataset.action==='achievements')go('progress','Exploits');
+        if(b.dataset.action==='creatures')go('discovery','Créatures');
+        if(b.dataset.action==='abilities')go('progress','Capacités');
+        if(b.hasAttribute('data-done')){content.innerHTML='<div class="mc-lock">Retour au jeu</div>';local.hidden=true;b.textContent='Rouvrir le Blocodex';b.removeAttribute('data-done');b.setAttribute('data-reopen','');}
+        else if(b.hasAttribute('data-reopen')){b.textContent='Terminé';b.removeAttribute('data-reopen');b.setAttribute('data-done','');render();}
+      });
+      root.addEventListener('change',event=>{
+        const e=event.target;
+        if(e.hasAttribute('data-role')){state.role=e.value;state.detail='';render();}
+        if(e.hasAttribute('data-favorite')&&!state.changed){state.favorite=e.value;state.changed=true;render();}
+        if(e.hasAttribute('data-constellation')){state.constellation=e.value;render();}
+      });
+      render();
+      if(globalThis.Tweak){const tweak=new Tweak({container:root,onChange:render});tweak.addSelect(state,'worldLabel',{label:'Nom de la troisième rubrique',options:['Monde','Histoire']});}
+    })();
+  </script>
+</div>
+
+</body>
+</html>

archives/web/receipt-2026-09-13-web-v1.json

@@ -0,0 +1,28 @@
+{
+  "id": "2026-09-13-web-v1",
+  "zip": "snapshots/Sanctuary-Web-Archive-2026-09-13-v1.zip",
+  "zip_bytes": 196242020,
+  "zip_sha256": "5e6277942e791a928b70c2b11490d5367f6b10a4b6d3b196c9cef703b1e431d5",
+  "manifest_sha256": "735e08a304a398fdb3d95c73c9c8f95c87027ae9d0459f708cfac044dd837622",
+  "file_count": 782,
+  "counts": {
+    "alpha-figures": 13,
+    "alpha-research": 406,
+    "alpha-atlas": 248,
+    "beta-previews": 17,
+    "creator-icons": 6,
+    "title-reference": 1,
+    "alpha-release-atlas": 3,
+    "blocodex-concept": 3,
+    "documentation": 74,
+    "integration-intake": 2,
+    "reproduction-script": 6,
+    "archive-index": 2
+  },
+  "checks": [
+    "copies_sha256",
+    "three_original_atlas_manifests",
+    "zip_crc",
+    "zip_members_sha256"
+  ]
+}

archives/web/references/open-maps-intake-2026-09-13.json

@@ -0,0 +1,584 @@
+{
+  "checked_at": "2026-09-13",
+  "target": "26.3-pre-2",
+  "projects": [
+    {
+      "slug": "simple-atlas",
+      "title": "Simple Atlas",
+      "license": {
+        "id": "MIT",
+        "name": "MIT License",
+        "url": null
+      },
+      "source_url": "https://github.com/RubberToe-06/simple_atlas",
+      "description": "A no-nonsense Vanilla+ Atlas for all your mapping needs! Heavily inspired by Map Atlases by Pepperoni-Jabroni",
+      "fabric_latest": [
+        {
+          "id": "6Hy4rXil",
+          "version_number": "1.2.0",
+          "date_published": "2026-06-18T20:58:16.322322Z",
+          "game_versions": [
+            "26.2"
+          ],
+          "loaders": [
+            "fabric",
+            "quilt"
+          ],
+          "dependencies": [
+            {
+              "version_id": "Nv3xnWXd",
+              "project_id": "9s6osm5g",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_26_2": [
+        {
+          "id": "6Hy4rXil",
+          "version_number": "1.2.0",
+          "date_published": "2026-06-18T20:58:16.322322Z",
+          "game_versions": [
+            "26.2"
+          ],
+          "loaders": [
+            "fabric",
+            "quilt"
+          ],
+          "dependencies": [
+            {
+              "version_id": "Nv3xnWXd",
+              "project_id": "9s6osm5g",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_target": []
+    },
+    {
+      "slug": "improved-maps",
+      "title": "Improved Maps",
+      "license": {
+        "id": "MIT",
+        "name": "MIT License",
+        "url": null
+      },
+      "source_url": "https://github.com/craftycorvid/ImprovedMaps",
+      "description": "Server-side mod (with optional client-side features) implementing Atlases and other map features",
+      "fabric_latest": [
+        {
+          "id": "kS9puVhR",
+          "version_number": "1.0",
+          "date_published": "2026-08-21T22:56:45.560111Z",
+          "game_versions": [
+            "26.2"
+          ],
+          "loaders": [
+            "fabric"
+          ],
+          "dependencies": [
+            {
+              "version_id": null,
+              "project_id": "mOgUt4GM",
+              "file_name": null,
+              "dependency_type": "optional"
+            },
+            {
+              "version_id": null,
+              "project_id": "xGdtZczs",
+              "file_name": null,
+              "dependency_type": "required"
+            },
+            {
+              "version_id": null,
+              "project_id": "1eAoo2KR",
+              "file_name": null,
+              "dependency_type": "optional"
+            },
+            {
+              "version_id": null,
+              "project_id": "P7dR8mSH",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_26_2": [
+        {
+          "id": "kS9puVhR",
+          "version_number": "1.0",
+          "date_published": "2026-08-21T22:56:45.560111Z",
+          "game_versions": [
+            "26.2"
+          ],
+          "loaders": [
+            "fabric"
+          ],
+          "dependencies": [
+            {
+              "version_id": null,
+              "project_id": "mOgUt4GM",
+              "file_name": null,
+              "dependency_type": "optional"
+            },
+            {
+              "version_id": null,
+              "project_id": "xGdtZczs",
+              "file_name": null,
+              "dependency_type": "required"
+            },
+            {
+              "version_id": null,
+              "project_id": "1eAoo2KR",
+              "file_name": null,
+              "dependency_type": "optional"
+            },
+            {
+              "version_id": null,
+              "project_id": "P7dR8mSH",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_target": []
+    },
+    {
+      "slug": "ultimate_map_atlases",
+      "title": "Ultimate Map Atlases",
+      "license": {
+        "id": "GPL-3.0-only",
+        "name": "GNU General Public License v3.0 only",
+        "url": null
+      },
+      "source_url": "https://github.com/nanakytim/Ultimate_Map_Atlases",
+      "description": "Atlases can be crafted and store Maps, making exploration easier and more fun! Works in tandem with a Compass.",
+      "fabric_latest": [
+        {
+          "id": "bgd39YOI",
+          "version_number": "26.2",
+          "date_published": "2026-06-17T13:27:13.516403Z",
+          "game_versions": [
+            "26.2"
+          ],
+          "loaders": [
+            "fabric"
+          ],
+          "dependencies": []
+        }
+      ],
+      "fabric_26_2": [
+        {
+          "id": "bgd39YOI",
+          "version_number": "26.2",
+          "date_published": "2026-06-17T13:27:13.516403Z",
+          "game_versions": [
+            "26.2"
+          ],
+          "loaders": [
+            "fabric"
+          ],
+          "dependencies": []
+        }
+      ],
+      "fabric_target": []
+    },
+    {
+      "slug": "bluemap",
+      "title": "BlueMap",
+      "license": {
+        "id": "MIT",
+        "name": "MIT License",
+        "url": "https://github.com/BlueMap-Minecraft/BlueMap/blob/master/LICENSE"
+      },
+      "source_url": "https://github.com/BlueMap-Minecraft/BlueMap",
+      "description": "A Minecraft mapping tool that creates 3D models of your Minecraft worlds and displays them in a web viewer.",
+      "fabric_latest": [
+        {
+          "id": "xvccCRD9",
+          "version_number": "5.24-fabric",
+          "date_published": "2026-09-10T15:38:16.522019Z",
+          "game_versions": [
+            "26.1",
+            "26.1.1",
+            "26.1.2",
+            "26.2"
+          ],
+          "loaders": [
+            "fabric"
+          ],
+          "dependencies": [
+            {
+              "version_id": null,
+              "project_id": "P7dR8mSH",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_26_2": [
+        {
+          "id": "xvccCRD9",
+          "version_number": "5.24-fabric",
+          "date_published": "2026-09-10T15:38:16.522019Z",
+          "game_versions": [
+            "26.1",
+            "26.1.1",
+            "26.1.2",
+            "26.2"
+          ],
+          "loaders": [
+            "fabric"
+          ],
+          "dependencies": [
+            {
+              "version_id": null,
+              "project_id": "P7dR8mSH",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_target": []
+    },
+    {
+      "slug": "map-atlases-forge",
+      "title": "Map Atlases [Forge]",
+      "license": {
+        "id": "GPL-3.0-only",
+        "name": "GNU General Public License v3.0 only",
+        "url": null
+      },
+      "source_url": "https://github.com/MehVahdJukaar/mapatlases-neoforge",
+      "description": "A world map/mini map mod based on vanilla Maps!",
+      "fabric_latest": [],
+      "fabric_26_2": [],
+      "fabric_target": []
+    },
+    {
+      "slug": "antique-atlas",
+      "title": "Antique Atlas",
+      "license": {
+        "id": "GPL-3.0-only",
+        "name": "GNU General Public License v3.0 only",
+        "url": null
+      },
+      "source_url": "https://github.com/AntiqueAtlasTeam/AntiqueAtlas",
+      "description": "Antique Atlas is a craftable item that enables a special map screen.",
+      "fabric_latest": [
+        {
+          "id": "BTztSCC6",
+          "version_number": "7.1.1-fabric-mc1.18.2",
+          "date_published": "2023-03-30T19:15:50.719038Z",
+          "game_versions": [
+            "1.18.2"
+          ],
+          "loaders": [
+            "fabric"
+          ],
+          "dependencies": [
+            {
+              "version_id": "j5zDzQqi",
+              "project_id": "lhGA9TYQ",
+              "file_name": null,
+              "dependency_type": "required"
+            },
+            {
+              "version_id": "BLMp2TRt",
+              "project_id": "9s6osm5g",
+              "file_name": null,
+              "dependency_type": "required"
+            },
+            {
+              "version_id": "95QMsRyb",
+              "project_id": "P7dR8mSH",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_26_2": [],
+      "fabric_target": []
+    },
+    {
+      "slug": "antique-atlas-4",
+      "title": "Antique Atlas 4",
+      "license": {
+        "id": "LGPL-3.0-or-later",
+        "name": "GNU Lesser General Public License v3.0 or later",
+        "url": null
+      },
+      "source_url": "https://github.com/sisby-folk/antique-atlas",
+      "description": "A hand-drawn clientside world map, with map sharing, structure discovery, and less!\nA map frontend for Surveyor based on hunternif's Antique Atlas.",
+      "fabric_latest": [
+        {
+          "id": "2sDsTAId",
+          "version_number": "3.1.2+1.21",
+          "date_published": "2026-01-05T08:52:18.929507Z",
+          "game_versions": [
+            "1.21.1"
+          ],
+          "loaders": [
+            "fabric",
+            "neoforge",
+            "quilt"
+          ],
+          "dependencies": [
+            {
+              "version_id": null,
+              "project_id": "tNmWwdI2",
+              "file_name": null,
+              "dependency_type": "required"
+            },
+            {
+              "version_id": "4AkOEqGy",
+              "project_id": "P7dR8mSH",
+              "file_name": null,
+              "dependency_type": "required"
+            },
+            {
+              "version_id": "iLOZqG06",
+              "project_id": "4KjqhPc9",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_26_2": [],
+      "fabric_target": []
+    },
+    {
+      "slug": "surveyor",
+      "title": "Surveyor Map Framework",
+      "license": {
+        "id": "LGPL-3.0-or-later",
+        "name": "GNU Lesser General Public License v3.0 or later",
+        "url": null
+      },
+      "source_url": "https://github.com/sisby-folk/surveyor",
+      "description": "Maps with friends! A world map backend with multiplayer sharing, automatic structure/POI marking, and unified mod compatibility.",
+      "fabric_latest": [
+        {
+          "id": "V7SEIRs6",
+          "version_number": "1.2.4+26.1",
+          "date_published": "2026-05-10T08:39:52.185927Z",
+          "game_versions": [
+            "26.1.2"
+          ],
+          "loaders": [
+            "fabric"
+          ],
+          "dependencies": [
+            {
+              "version_id": null,
+              "project_id": "tNmWwdI2",
+              "file_name": null,
+              "dependency_type": "required"
+            },
+            {
+              "version_id": "mmmOfXE7",
+              "project_id": "P7dR8mSH",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_26_2": [],
+      "fabric_target": []
+    },
+    {
+      "slug": "voxelmap-updated",
+      "title": "VoxelMap-Updated",
+      "license": {
+        "id": "LicenseRef-All-Rights-Reserved",
+        "name": "",
+        "url": null
+      },
+      "source_url": "https://github.com/fantahund/VoxelMap",
+      "description": "Minimap and Worldmap. Have an overview of your surroundings, or view the entire world. Create waypoints.",
+      "fabric_latest": [
+        {
+          "id": "BjsGekii",
+          "version_number": "26.2-1.16.10",
+          "date_published": "2026-08-30T03:23:58.999214Z",
+          "game_versions": [
+            "26.2"
+          ],
+          "loaders": [
+            "fabric"
+          ],
+          "dependencies": [
+            {
+              "version_id": null,
+              "project_id": "P7dR8mSH",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_26_2": [
+        {
+          "id": "BjsGekii",
+          "version_number": "26.2-1.16.10",
+          "date_published": "2026-08-30T03:23:58.999214Z",
+          "game_versions": [
+            "26.2"
+          ],
+          "loaders": [
+            "fabric"
+          ],
+          "dependencies": [
+            {
+              "version_id": null,
+              "project_id": "P7dR8mSH",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_target": []
+    },
+    {
+      "slug": "xaeroplus",
+      "title": "XaeroPlus",
+      "license": {
+        "id": "MIT",
+        "name": "MIT License",
+        "url": null
+      },
+      "source_url": "https://github.com/rfresh2/XaeroPlus/",
+      "description": "Xaero WorldMap / Minimap Extra Features",
+      "fabric_latest": [
+        {
+          "id": "kbQweqjZ",
+          "version_number": "2.36.1+fabric-1.21.11",
+          "date_published": "2026-09-10T21:10:52.358083Z",
+          "game_versions": [
+            "1.21.11"
+          ],
+          "loaders": [
+            "fabric",
+            "quilt"
+          ],
+          "dependencies": [
+            {
+              "version_id": null,
+              "project_id": "P7dR8mSH",
+              "file_name": null,
+              "dependency_type": "required"
+            },
+            {
+              "version_id": null,
+              "project_id": "FlFKBOIX",
+              "file_name": null,
+              "dependency_type": "optional"
+            },
+            {
+              "version_id": null,
+              "project_id": "1bokaNcj",
+              "file_name": null,
+              "dependency_type": "required"
+            },
+            {
+              "version_id": null,
+              "project_id": "NcUtCpym",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_26_2": [
+        {
+          "id": "Ts3KSCxm",
+          "version_number": "2.36.1+fabric-26.2",
+          "date_published": "2026-09-10T21:07:47.448275Z",
+          "game_versions": [
+            "26.2"
+          ],
+          "loaders": [
+            "fabric",
+            "quilt"
+          ],
+          "dependencies": [
+            {
+              "version_id": null,
+              "project_id": "1bokaNcj",
+              "file_name": null,
+              "dependency_type": "required"
+            },
+            {
+              "version_id": null,
+              "project_id": "NcUtCpym",
+              "file_name": null,
+              "dependency_type": "required"
+            },
+            {
+              "version_id": null,
+              "project_id": "FlFKBOIX",
+              "file_name": null,
+              "dependency_type": "optional"
+            },
+            {
+              "version_id": null,
+              "project_id": "P7dR8mSH",
+              "file_name": null,
+              "dependency_type": "required"
+            }
+          ]
+        }
+      ],
+      "fabric_target": []
+    }
+  ],
+  "licenses_verified_in_source": [
+    {
+      "repository": "craftycorvid/ImprovedMaps",
+      "default_branch": "main",
+      "license_spdx": "MIT",
+      "license_url": "https://github.com/craftycorvid/ImprovedMaps/blob/main/LICENSE",
+      "license_git_sha": "e67ce634ddce2140ca1546d2e5beb1c04859f60f",
+      "license_sha256": "a566859281767627d275c468319d0713d86f317b6f798ba9bf48d6da07991b32",
+      "archived": false
+    },
+    {
+      "repository": "RubberToe-06/simple_atlas",
+      "default_branch": "master",
+      "license_spdx": "MIT",
+      "license_url": "https://github.com/RubberToe-06/simple_atlas/blob/master/LICENSE",
+      "license_git_sha": "705cd5167be9a1045008e89018f67e9e501b272f",
+      "license_sha256": "9766022d74839286286f97d9f3928033bd15445605bdaab4ff4806b434c08c67",
+      "archived": false
+    },
+    {
+      "repository": "nanakytim/Ultimate_Map_Atlases",
+      "default_branch": "main",
+      "license_spdx": "GPL-3.0",
+      "license_url": "https://github.com/nanakytim/Ultimate_Map_Atlases/blob/main/LICENSE",
+      "license_git_sha": "f288702d2fa16d3cdf0035b15a9fcbc552cd88e7",
+      "license_sha256": "3972dc9744f6499f0f9b2dbf76696f2ae7ad8af9b23dde66d6af86c9dfb36986",
+      "archived": false
+    },
+    {
+      "repository": "BlueMap-Minecraft/BlueMap",
+      "default_branch": "master",
+      "license_spdx": "MIT",
+      "license_url": "https://github.com/BlueMap-Minecraft/BlueMap/blob/master/LICENSE",
+      "license_git_sha": "0a98021f607f47cc173f081a768e99e12bd2f6a3",
+      "license_sha256": "f1c190d4a1ff29606cbed7a0d97fc7b7117cc2e1169e19caa753198957dbbfd6",
+      "archived": false
+    }
+  ]
+}

archives/web/references/xaero-intake-2026-09-13.json

@@ -0,0 +1,116 @@
+{
+  "checked_at": "2026-09-13",
+  "target": "26.3-pre-2",
+  "projects": [
+    {
+      "project": "xaeros-minimap",
+      "license": {
+        "id": "LicenseRef-All-Rights-Reserved",
+        "name": "",
+        "url": null
+      },
+      "source_url": null,
+      "versions": {
+        "26.2": {
+          "count": 9,
+          "latest": [
+            {
+              "id": "tBIPWIKW",
+              "version_number": "fabric-26.2-26.5.0",
+              "date_published": "2026-09-10T11:44:27.035690Z",
+              "version_type": "release",
+              "dependencies": [
+                {
+                  "version_id": null,
+                  "project_id": "P7dR8mSH",
+                  "file_name": null,
+                  "dependency_type": "required"
+                },
+                {
+                  "version_id": null,
+                  "project_id": "gF3BGWvG",
+                  "file_name": null,
+                  "dependency_type": "optional"
+                }
+              ],
+              "files": [
+                {
+                  "id": "MR2dtOXn",
+                  "hashes": {
+                    "sha1": "40282debf4cd8e91712ba26d90e78f2e3eb067e1",
+                    "sha512": "b00df8bb410fae12b08788044f2f03cec34bfc4506da419d11d364e2f229b814dbb272d297fbe4b0cdfac18beeeed4dc8f1bdfc96fb113867857527e31965049"
+                  },
+                  "url": "https://cdn.modrinth.com/data/1bokaNcj/versions/tBIPWIKW/xaerominimap-fabric-26.2-26.5.0.jar",
+                  "filename": "xaerominimap-fabric-26.2-26.5.0.jar",
+                  "primary": true,
+                  "size": 2221887,
+                  "file_type": null
+                }
+              ]
+            }
+          ]
+        },
+        "26.3-pre-2": {
+          "count": 0,
+          "latest": []
+        }
+      },
+      "metadata_source": "https://api.modrinth.com/v2/project/xaeros-minimap"
+    },
+    {
+      "project": "xaeros-world-map",
+      "license": {
+        "id": "LicenseRef-All-Rights-Reserved",
+        "name": "",
+        "url": null
+      },
+      "source_url": null,
+      "versions": {
+        "26.2": {
+          "count": 10,
+          "latest": [
+            {
+              "id": "DxU1zijU",
+              "version_number": "fabric-26.2-1.46.0",
+              "date_published": "2026-09-10T11:32:01.420372Z",
+              "version_type": "release",
+              "dependencies": [
+                {
+                  "version_id": null,
+                  "project_id": "gF3BGWvG",
+                  "file_name": null,
+                  "dependency_type": "optional"
+                },
+                {
+                  "version_id": null,
+                  "project_id": "P7dR8mSH",
+                  "file_name": null,
+                  "dependency_type": "required"
+                }
+              ],
+              "files": [
+                {
+                  "id": "Acre79W6",
+                  "hashes": {
+                    "sha512": "37284868eed7bb105362ba1df3da38e860a0f889e50dcae43ddaf167c33817b8ece289770f89b138e327b145d15ae36a4df850202770236a4eefd7b413158438",
+                    "sha1": "1056e2f81860045a8c1fb1d6823ca3f4c832dc60"
+                  },
+                  "url": "https://cdn.modrinth.com/data/NcUtCpym/versions/DxU1zijU/xaeroworldmap-fabric-26.2-1.46.0.jar",
+                  "filename": "xaeroworldmap-fabric-26.2-1.46.0.jar",
+                  "primary": true,
+                  "size": 1477476,
+                  "file_type": null
+                }
+              ]
+            }
+          ]
+        },
+        "26.3-pre-2": {
+          "count": 0,
+          "latest": []
+        }
+      },
+      "metadata_source": "https://api.modrinth.com/v2/project/xaeros-world-map"
+    }
+  ]
+}

build.gradle

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

docs/access-code-beta144.md

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

docs/actualisation-tests-beta165.md

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

docs/adventure-ecology-beta180.md

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

docs/arenas-beta073.md

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

docs/arrival-mount-beta061.md

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

docs/atlas-altitude-beta058.md

@@ -0,0 +1,96 @@
+# beta.058 — altitude de la carte
+
+Ticket `codex/atlas-altitude-beta058`.
+
+## Contrat avant implémentation
+
+Deux boutons ↑ / ↓ sous Recentrer et le zoom choisissent les plafonds
+0, 140, 280, 420, 560 et 640. La carte ouvre à 640 (surface habituelle) ;
+chaque plafond montre le premier bloc coloré situé à cette altitude ou plus
+bas. C'est une coupe horizontale : une roche coupée reste visible, sans
+chercher automatiquement une grotte. Le dernier pas fait 80 blocs.
+La position et le zoom ne changent pas. Les extrémités désactivent leur bouton.
+Chunks et Demeure sont désactivés par défaut, réactivables par leurs boutons.
+Le cadre central et ses quatre panneaux assombris sont retirés. Le nord
+conserve son emplacement.
+
+Les relevés restent personnels et utilisent le même masque d'exploration
+horizontal qu'auparavant. Les six plafonds sont relevés lors des nouvelles
+visites, même avant l'achat de Grande carte. Aucun chunk distant n'est chargé
+ou généré. La vue opérateur inspecte seulement les chunks chargés et n'inscrit
+pas ses consultations dans les découvertes personnelles.
+
+## Contrat de données additif
+
+Le fichier existant `data/sanctuary-atlas/<UUID>.json` et son schéma 2 restent
+la référence de la surface à 640. Aucune conversion ni réinterprétation des
+anciens pixels. Les cinq autres plafonds utilisent le même format dans des
+fichiers distincts `data/sanctuary-atlas/layers/<UUID>/<altitude>.json`.
+Les anciens relevés de surface ne permettent pas d'inventer leurs couleurs
+inférieures : ces dernières apparaissent lors des revisites. Un retour à
+beta.057 ignore simplement les fichiers supplémentaires ; la surface reste
+lisible. Aucun monde personnel n'est ouvert ou modifié pendant le travail.
+
+Chaque plafond conserve la limite de 16 384 chunks. Le client ne garde que
+la couche affichée ; le token réseau change avec l'altitude, empêchant les
+anciens paquets de repeindre une autre couche. Le protocole `atlas_request`
+ajoute un plafond validé : client et serveur doivent avoir la même version.
+Le serveur relève un chunk à la fois et saute les sections entièrement vides.
+Les sauvegardes périodiques des couches sont étalées dans le temps.
+
+## Vérifications
+
+Le parcours natif `Atlas058ClientChecks` réussit sur la version finale en **1 min 44 s**, avec un
+vrai monde de développement Sanctuary de 640 blocs de haut :
+
+- couleurs différentes aux six plafonds, coupe inclusive, verre transparent,
+  colonne vide, accord entre le relevé d'une couche et celui des six couches ;
+- absence de chargement d'un chunk distant et masque d'exploration conservé ;
+- clics réels sur les boutons, limites 0/640, changement rapide, rejet des
+  anciens paquets terrain et Demeure, cadrage/zoom stables après rafraîchissement ;
+- relecture des six fichiers, absence de réécriture quand rien ne change,
+  achat de Grande carte après relevé, refus d'une requête opérateur non autorisée ;
+- codec réseau, refus des altitudes invalides, libellés FR/EN, petite interface ;
+- Chunks/Demeure désactivés à l'ouverture mais réactivables, absence du cadre
+  assombri et emplacement du nord conservé (captures inspectées).
+
+Commande :
+
+```sh
+./gradlew :sanctuary:runClientGameTest -x :sanctuary:runGameTest \
+  -PsanctuaryClientTests=true -PsanctuaryAtlas058ClientTests=true \
+  -PsanctuaryQuickTests=true
+```
+
+Journal : `build/atlas058-client.log`, marqueur `ATLAS058_PASS`.
+Captures inspectées : `build/atlas058-evidence/`.
+
+Le brouillard reste horizontal, comme dans les cartes existantes : ce lot
+n'introduit pas de visibilité optique ni de journal de découverte par caverne.
+Demeure reste une empreinte de chunk, sans séparation verticale des bâtiments.
+Au plafond maximal, les pixels de surface restent compatibles ; les anciens
+parcours ne sont pas reconstruits aux autres altitudes sans revisite.
+La charge d'un serveur rempli pendant une saison n'a pas été mesurée. Le
+plafond théorique est de 24 Mio de couleurs brutes par joueur pour six couches
+pleines, hors index et sérialisation, contre 4 Mio pour la surface seule.
+Chaque fichier reste borné à 12 Mio ; un fichier invalide est préservé et
+suspend l'atlas du joueur concerné. Les sauvegardes tournent sur les six
+couches toutes les 12 secondes, puis sont vidées à la déconnexion/fermeture.
+Aucun serveur dédié démarré, aucune EULA acceptée.
+
+
+## Livraison vérifiée
+
+`check build assemblePack assembleTestPack`, avec compilation des tests client
+et exclusion du serveur dédié `runGameTest`, réussit en **2 min 23 s**
+(`build/atlas058-check.log`). 1 601 classes du JAR correspondent au build.
+ZIP, versions, ressources, isolation du mod de test et JAR embarqués contrôlés.
+JEI et le code Demeure sont inchangés. Les archives beta.057 restent intactes.
+
+- Pack normal : `build/Sanctuary-beta.058.mrpack`, 5627223 octets ;
+  SHA-256 `bc9af60be020fd32f99a173638e9006cab128cf942df666e34e03824bac6f892`.
+- Pack de test : `build/Sanctuary-Test-beta.058.mrpack`, 5646157 octets ;
+  SHA-256 `010eb08df83117669d2f13d3c2e8641c965fac3ddec11fbab419f01a9cb94942`.
+- Reçu : `build/atlas058-artifact.json`.
+
+Aucune publication de canal ni synchronisation d'instance personnelle.

docs/atlas-beta005.md

@@ -0,0 +1,118 @@
+# MAP-01 — carte Sanctuary native, beta.005
+
+Ticket autorisé le 13 septembre 2026, branche `codex/native-map-beta005`.
+Carte de dessus écrite dans Sanctuary, inspirée des interactions de Xaero
+(glisser, zoomer, se recentrer). Aucun code, asset ou dépendance Xaero repris.
+
+## Comportement livré
+
+Le Blocodex ouvre une carte de surface de l'Overworld : nord en haut, terrain
+coloré, position et orientation de l'habitant, déplacement, zoom, recentrage.
+L'aptitude **Grande carte** coûte provisoirement 4 niveaux, configurables.
+L'exploration commence avant cet achat, conformément au choix du créateur.
+La mini-carte, les marqueurs et le partage volontaire entre habitants restent
+des tickets distincts. Aucun partage automatique de découvertes.
+
+La vue habitant affiche ses propres relevés. La vue opérateur est un choix
+explicite contrôlé par le serveur (`COMMANDS_GAMEMASTER`, commandes autorisées
+en solo). Elle peut inspecter les chunks déjà chargés, sans les inscrire dans
+les découvertes personnelles et sans charger/générer de terrain supplémentaire.
+La carte représente la surface supérieure, sans carte des grottes ni radar.
+
+Les couleurs de création d'habitant affichent des noms FR/EN (Azur,
+Pamplemousse, Sauge…) associés à leur teinte, en caractères Minecraft normaux.
+Les boutons et leur texte coloré restent natifs ; l'attribution RGB ne change
+pas. Les longs noms disposent du défilement et de l'infobulle vanilla.
+La carte laisse le monde évoluer pendant sa consultation, y compris en solo.
+
+## Contrat de sauvegarde et migration, écrit avant le code
+
+Les identifiants, chunks, graines et contrats de génération sont inchangés.
+Seuls les mondes dont la progression Sanctuary est déjà active participent.
+
+L'attachement `sanctuary:progression` passe du schéma 1 au schéma 2 : ajout du
+booléen `atlas`, initialement faux. Le lecteur valide les anciens champs et
+l'historique puis les conserve ; un prochain achat écrit le schéma 2. Les rangs,
+l'aptitude Noms, les coûts déjà payés et dates ne changent pas. Les morts et
+reconnexions conservent l'achat de Grande carte. Aucun prestige introduit.
+
+`progression.json` schéma 1 reste accepté sans réécriture : `atlasCost` vaut 4
+par défaut. Les nouvelles configurations utilisent le schéma 2 et ce champ.
+Pour régler le prix dans un ancien fichier, passer `schema` à 2 et ajouter
+`"atlasCost": 4` (ou le prix voulu), en conservant les autres valeurs.
+
+Des fichiers additifs `data/sanctuary-atlas/<UUID>.json` (schéma 1) conservent
+les relevés de surface de l'Overworld, liés à l'UUID et à la graine. Une tuile
+contient 16×16 couleurs de carte vanilla. Les relevés portent sur les chunks
+chargés dans un rayon de deux chunks autour de l'habitant, progressivement.
+Il s'agit d'une proximité cartographiée, pas d'une visibilité optique exacte.
+Les revisites actualisent le terrain ; les zones lointaines restent le dernier
+relevé. Les parcours antérieurs à beta.005 ne peuvent pas être reconstitués.
+
+Écriture atomique périodique et à la déconnexion/fermeture ; les derniers relevés
+peuvent être perdus lors d'un arrêt brutal. Une limite de 16 384 chunks par
+habitant borne ce premier lot ; une carte pleine reste consultable et signale
+qu'elle ne peut plus ajouter de zones. Un fichier invalide est conservé et
+désactive la carte concernée, sans effacer les données ni bloquer les autres.
+
+Avant une utilisation dans une sauvegarde personnelle, conserver une sauvegarde
+complète. Un retour à beta.004 exige la copie antérieure à la migration : son
+lecteur de progression ne connaît pas les achats `atlas`. Aucun monde personnel
+n'est ouvert par ce ticket, les essais utilisent des mondes de développement.
+
+## Vérification
+
+- `./gradlew check build -PsanctuaryFocusedTests=progression,map` : contrats
+  de progression et de relevés, et **7/7 tests natifs serveur** réussis.
+- `./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true
+  -PsanctuaryProgressionClientTests=true` : réussi, **1 min 46 s**. Vrai client,
+  création avant spawn, noms de couleurs FR, achat réel de Grande carte,
+  relevés antérieurs à l'achat, zoom/glisser/recentrer, GUI 320×240 et autres
+  tailles, commandes désactivées puis activées, inspection explicite,
+  révocation et effacement des tuiles opérateur, retour au menu pause,
+  mort et redémarrage du même monde de test.
+- La maquette archivée et les packs beta.003/004 restent immuables.
+- Captures : `build/beta005-preview/`. Logs : `build/beta005-client.log`,
+  `build/beta005-check-build.log`, `build/beta005-delivery.log`.
+
+Les essais ne mesurent pas encore une charge de 30 joueurs ni la durée d'une
+saison complète. La suite générale garde les deux assertions worldgen
+historiques signalées en beta.004 (hauteur 384 attendue contre 640 et support
+de sédiment seed 0) ; ce lot n'a pas modifié la génération.
+
+## Tester
+
+Installer le pack beta.005 côté client et la même version côté serveur.
+Dans le Blocodex (**B** ou **Échap**), acheter **Grande carte** dans Progression,
+puis ouvrir **Monde → Grande carte**. Glisser pour déplacer, molette ou boutons
+pour zoomer, Recentrer ou Début pour revenir au joueur. Les flèches déplacent
+la vue. Une zone noire n'est pas encore relevée ; le vide relevé est bleu sombre.
+Le relevé complet des environs immédiats prend environ cinq secondes.
+
+Avec les commandes autorisées en solo ou les droits opérateur, ouvrir la même
+carte puis choisir **Vue opérateur**. Cet accès ne nécessite pas l'achat de
+l'aptitude ; revenir à **Vue habitant** retrouve ses seuls relevés et l'exigence
+de l'aptitude. L'inspection ne charge pas de terrain distant : une zone absente
+peut simplement ne plus être chargée côté serveur.
+
+Les relevés couvrent l'Overworld supérieur, par proximité de deux chunks, sans
+reconstituer les parcours antérieurs à beta.005. Les marqueurs, mini-carte,
+partages, grottes, statistiques/advancements dans le Blocodex, filtrage des blocs
+inconnus et vitrines/favoris de l'habitant restent les prochains tickets.
+
+
+## Livraison locale vérifiée
+
+`./gradlew check build assemblePack -PsanctuaryFocusedTests=progression,map`
+réussit en 4 min 09 s ; **7/7 tests natifs serveur**. Export packwiz puis
+vérification du ZIP, JAR embarqué, versions internes, dépendance Fabric API,
+index packwiz, libellés FR/EN, six icônes originales et absence du mod de test.
+
+- MRpack : `build/Sanctuary-beta.005.mrpack`, 2 248 215 octets.
+- SHA-256 : `4a71465349af334b5bdeed4b0cc42dbef55de94e6acb7f0ab798cda477e6dc0e`.
+- Reçu : `build/atlas005-artifact.json`.
+- JAR : `mods/sanctuary/build/libs/sanctuary-beta.005.jar`.
+
+Les empreintes des MRpacks beta.003/004 et des deux ZIP d'archives Web v1 sont
+inchangées. Aucune publication distante, synchronisation Prism ou installation
+sur un serveur personnel n'a été effectuée.

docs/atlas-immersive-beta007.md

@@ -0,0 +1,82 @@
+# MAP-03 — Carte immersive — beta.007
+
+Branche : `codex/atlas-immersive`. Cible : Minecraft **26.3-pre-2**, Fabric
+Loader **0.19.5**, Fabric API **0.160.0+26.3**. Livraison locale d'essai.
+
+## Résultat
+
+**B → Monde → Grande carte** utilise toute la surface de l'écran. La carte
+continue sous les onglets, les commandes et le pied de page. Le carré central
+reste clair ; les abords sont assombris par des panneaux translucides. Le carré
+ne limite ni le terrain ni les gestes de navigation.
+
+Journal, recentrage et zoom sont superposés à gauche ; vue habitant/opérateur,
+grille de chunks et empreintes Demeure à droite. Le titre et les onglets natifs
+restent en haut, **Done / Terminé** en bas. Les coordonnées sous le pointeur,
+le zoom et la vue active sont affichés en bas à gauche sur un fond contrasté.
+Les autres écrans du Blocodex gardent leur cadre.
+
+Le glisser-déplacer et la molette fonctionnent sur les zones sombres jusqu'aux
+bords de l'écran. Les boutons gardent la priorité sur la carte, même lorsqu'ils
+sont désactivés. Grille, empreintes et indicateur du joueur utilisent les mêmes
+coordonnées que le terrain. Le zoom minimal s'adapte à la taille du GUI pour
+préserver la couverture de la fenêtre cartographique de 1 024 × 1 024 blocs.
+
+## Transparence et données
+
+L'inconnu et le vide observé sont transparents dans la texture ; le fond natif
+du jeu reste visible derrière. Leurs états restent distincts dans les relevés.
+La grille peut traverser une zone transparente lorsqu'elle est activée ; les
+empreintes ne peignent que les pixels de terrain effectivement connus.
+
+Les relevés personnels, l'exploration avant l'achat de Grande carte et le
+brouillard de beta.006 sont conservés. La vue opérateur reste une action
+explicite vérifiée par le serveur. Un changement de vue ou une révocation
+efface l'image précédente avant son prochain rendu.
+
+Ce ticket modifie le rendu et les entrées client. Il ne change ni les formats
+de sauvegarde, ni le protocole des relevés, ni le terrain ou les expansions.
+Demeure garde son rôle d'empreinte, sans réservation ni protection. Mini-carte,
+marqueurs et partage restent dans leurs tickets respectifs.
+
+## Vérifications et artefact
+
+- Client Minecraft natif :
+  `./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true -PsanctuaryProgressionClientTests=true`
+  réussi en **1 min 51 s**. Paquets réels, achat de Grande carte, texture alpha,
+  molette et gestes via `MouseHandler`, glissements successifs et dans les quatre
+  marges, priorité des boutons, recentrage, grille, empreintes, changement de
+  rôle, révocation, fermeture native et retour au Blocodex vérifiés.
+- Captures inspectées à **640×480**, **1280×720** (GUI automatique),
+  **1920×1080** (échelles 1 et 3), ainsi qu'en français. Les boutons ne se
+  chevauchent pas. La vue opérateur montre le terrain continu derrière le
+  haut, le bas et les côtés. Captures conservées dans `build/beta007-preview/`.
+- Un premier passage a détecté que `AbstractWidget.isMouseOver` ignore les
+  boutons désactivés : leur zone laissait passer la molette. Le calcul utilise
+  désormais les limites du bouton visible ; le parcours complet a été relancé
+  avec succès. Journaux `build/beta007-client.log` (diagnostic) et
+  `build/beta007-client-final.log` (validation).
+
+- `./gradlew check build assemblePack -PsanctuaryFocusedTests=progression,map,demeure`
+  réussi en **4 min 4 s**, dont **8/8 tests natifs serveur**. Les contrôles de
+  contrats Atlas/Demeure et de progression passent également. La sélection
+  native est ciblée ; les deux assertions worldgen générales déjà connues en
+  beta.003/005 ne sont pas revendiquées corrigées. Journal :
+  `build/beta007-delivery.log`.
+- MRpack exporté avec packwiz puis vérifié : CRC ZIP, contenu exact, identité
+  des JAR construits, versions internes, dépendance Fabric API, index packwiz,
+  notices et licence Demeure, 378 clés FR/EN alignées et six icônes originales.
+  Les exports beta.003, .004, .005 et .006 conservent leurs empreintes.
+
+## Artefact d'essai
+
+[Sanctuary-beta.007.mrpack](../build/Sanctuary-beta.007.mrpack), **2 299 820 octets**.
+Demeure reste embarqué dans le JAR Sanctuary ; aucun ajout manuel nécessaire.
+
+- SHA-256 MRpack : `bc082e9143e15aea8f231b1205ed5e27cd9bf7b4e6a81d4895f69ff2a11e660d`.
+- SHA-256 Sanctuary : `7d14d6019176f0d413dfe27a2b0e9a8fe419ed88aad812d9c045dfb13f809752`.
+- SHA-256 Demeure : `70108b80df46e4dbcf2540b7a260b1c247bb8ea28db684f49b15b407d8853e43`.
+
+Reçu : `build/atlas007-artifact.json` ; vérificateur :
+`build/verify-beta007-pack.py`. Export local uniquement. Aucun monde personnel,
+canal de publication ou instance Prism n'a été modifié.

docs/atlas-markers-beta059.md

@@ -0,0 +1,85 @@
+# beta.059 — bannières et cartes au trésor
+
+Ticket `codex/atlas-markers-beta059`. Prolonge les altitudes et l'affichage
+sans cadre de beta.058.
+
+## Contrat avant implémentation
+
+- Un clic droit sur une bannière, main vide ou avec une carte remplie, ajoute
+  son repère personnel à l'atlas. Le même geste le retire ; la couleur et le
+  nom renommé sont repris. Une carte native tenue continue aussi son propre
+  enregistrement vanilla. Aucun achat supplémentaire : l'observation peut
+  précéder l'aptitude Grande carte, qui reste nécessaire pour ouvrir l'atlas.
+- Utiliser une carte au trésor remplie importe ses repères dans la World Map.
+  La carte physique reste disponible pour être partagée. Les cartes natives
+  d'exploration et leurs bannières sont prises en charge ; leur terrain n'est
+  pas copié dans le brouillard personnel.
+- Les trésors des îlots miniers sont lus dans le plan aérien déjà chargé et
+  sauvegardé, sans nouvelle recherche ni génération. Les opérateurs les voient
+  automatiquement. Un client normal ne reçoit jamais les coordonnées des
+  trésors qu'il n'a pas importés depuis une carte.
+- Les deux navires fournissent des cartes vers les premiers îlots miniers.
+  Les coffres miniers peuvent donner la carte de l'îlot suivant, notamment
+  le troisième des mondes Grand. Ce sont des cartes Minecraft remplies avec
+  le marqueur de trésor natif, sans nouvel objet ni texture.
+- Les repères utilisent les sprites de carte Minecraft. Les bannières nommées
+  ont leur texte ; le survol donne le nom et les coordonnées. Un point dont
+  l'altitude est connue disparaît sous un plafond inférieur à ce point.
+  Les cartes natives sans altitude restent visibles sur tous les plafonds.
+
+## Données et mondes existants
+
+Fichier personnel additif `data/sanctuary-atlas/markers/<UUID>.json`, schéma 1,
+lié à l'UUID et à la graine. Les journaux de terrain, couches, monde et plans
+restent inchangés. Limite de 512 repères ; écritures atomiques et conservation
+d'un fichier invalide. Reconnexion et prestige ne suppriment pas les repères.
+Un retour à beta.058 ignore ce fichier sans conversion.
+
+Les trois tables de butin aériennes conservent leurs objets et les quantités
+qu'elles déclarent, et ajoutent une carte. Leurs anciens champs `functions`
+/ `function`, ignorés dans cette version, sont adaptés en `modifier` / `type`
+pour appliquer effectivement ces quantités et la création de la carte.
+Seuls les coffres dont le butin n'a pas encore été généré utilisent ces tables ;
+aucun coffre déjà ouvert n'est rempli, aucun contenu existant n'est réécrit.
+Les coffres et positions sont ceux des plans d'origine, sans migration de
+structures, de chunks ou de graine. Les tests ne touchent que des mondes de
+laboratoire. Aucune publication ou installation personnelle implicite.
+
+## Vérifications
+
+- `atlas059Smoke` : persistance Unicode, isolation UUID/graine, limite de
+  512 repères, suppression, absence de réécriture sans changement, filtrage
+  du cadrage et de l'altitude, conservation des fichiers corrompus.
+- Parcours client Minecraft 26.3-pre-2 sur un monde Sanctuary de laboratoire,
+  graine 42, taille moyenne, structures activées : clic droit réel sur une
+  bannière renommée, retrait et ajout, changement de nom, import depuis une
+  carte en main gauche, lecture des trois tables de butin natives, quantités
+  conservées, cartes dirigées vers les deux coffres du plan, utilisation
+  physique de la carte au trésor, conservation de l'objet et absence de doublon.
+- Le client normal reçoit uniquement le trésor découvert. Le mode opérateur
+  montre les deux sans les enregistrer ; sa désactivation et un paquet tardif
+  ne rétablissent pas les coordonnées cachées. Suppression d'une bannière
+  chargée, relecture du journal, codec avec altitude inconnue et libellés FR/EN
+  vérifiés. Sprites natifs contrôlés et captures inspectées.
+- `:sanctuary:atlas059Smoke :sanctuary:runClientGameTest` réussi en 2 min 57 s,
+  avec `-PsanctuaryClientTests=true -PsanctuaryAtlas059ClientTests=true
+  -PsanctuaryQuickTests=true`. Journal : `build/atlas059-client.log`, marqueur
+  `ATLAS059_PASS`.
+- `./gradlew check build assemblePack assembleTestPack` réussi en 2 min 9 s,
+  122 tâches, avec les mêmes propriétés et `-x :sanctuary:runGameTest`.
+  Journal : `build/atlas059-check.log`. Aucun serveur dédié ni acceptation
+  d'EULA ; les tests natifs utilisent le serveur intégré de développement.
+- Les deux exports packwiz sont vérifiés par `build/verify-atlas059.py` :
+  1 607 classes conformes au build, changements limités aux classes prévues,
+  ressources existantes préservées hors libellés et trois tables documentées,
+  JEI inchangé et archives beta.058 intactes.
+
+Archives locales : [pack normal](../build/Sanctuary-beta.059.mrpack) et
+[monde plat rapide](../build/Sanctuary-Test-beta.059.mrpack).
+Reçu détaillé : `build/atlas059-artifact.json` ; captures dans
+`build/atlas059-evidence/`.
+
+Le parcours natif couvre les deux trésors du monde moyen. Le troisième îlot
+du monde Grand suit le même plan et la même règle de carte suivante, mais n'a
+pas fait l'objet d'un second monde de test. Aucun essai avec plusieurs clients
+humains simultanés ni mesure de FPS n'est revendiqué ici.

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/backrooms-implementation.md

@@ -0,0 +1,378 @@
+# BR-01 — Explorer les Backrooms alimentées par le ballast
+
+**Ticket local préparé le 15 septembre 2026. Statut : à implémenter après la
+livraison et la validation du suivi du ballast.** Cette préparation est
+documentaire ; elle n'active aucune dimension ni aucun transfert en jeu.
+
+- Branche documentaire : `codex/backrooms-ticket`.
+- Branche prévue pour l'implémentation : `codex/backrooms-generation`.
+- Livraison `beta.xxx` : numéro à attribuer au moment de la livraison du code.
+- Cible relevée dans `gradle.properties` : Minecraft **26.3-pre-2**, Java 25.
+  Vérifier les API et dépendances de la version effectivement ciblée au démarrage.
+- Prérequis bloquant : **suivi du ballast livré**, avec contrat de données et
+  preuves de reprise. Référence du ticket amont à ajouter lorsqu'il sera créé ;
+  aucun ticket dédié à ce suivi n'est identifié dans le backlog à cette date.
+
+## 1. Résultat attendu
+
+Un joueur termine son sommeil dans son lit de l'Overworld et rejoint sa salle
+personnelle, un Indoor de protection situé dans les Backrooms communes. Un
+tableau cache une porte ouverte donnant sur le réseau. Le joueur explore des
+couloirs, salles, bassins et infrastructures, peut rencontrer un autre joueur
+ou découvrir sa salle, puis dort dans un lit trouvé sur place pour revenir à
+son propre lit d'origine dans l'Overworld.
+
+Les nouvelles régions portent l'empreinte du ballast réellement suivi dans
+Sanctuary. Les régions déjà planifiées conservent leur génération ; les lieux
+visités, les constructions et les cartes dessinées par les joueurs restent
+utiles après changement de période, reconnexion et redémarrage.
+
+## 2. Décisions du créateur à respecter
+
+Ces règles proviennent de la discussion de conception et priment sur les
+anciennes intentions d'accès encore ouvertes dans la vision et la cosmologie.
+
+- Les Backrooms sont le dysfonctionnement d'Indoors interconnectés. Le ballast
+  du monde y est redirigé et alimente leur croissance procédurale.
+- Steve a aménagé un refuge de protection associé au renoncement à poursuivre
+  ce chemin. Il a caché le passage avec **un tableau devant une porte ouverte**.
+  Ce geste simple ne fait pas de Steve l'ingénieur de toute l'infrastructure.
+- Chaque joueur dispose d'une salle stable, liée à son identité et intégrée
+  physiquement à la génération des Backrooms. Le lit est son accès personnel.
+- Un autre joueur peut découvrir cette salle à pied et y entrer. Son propre lit
+  ne lui permet pas de choisir la salle d'autrui comme destination.
+- Le sommeil complet déclenche le passage ; il ne fait pas passer la nuit.
+- Dans les Backrooms, **n'importe quel lit utilisable permet de revenir à son
+  propre lit d'origine dans l'Overworld**. Son propriétaire ou sa proximité
+  d'une salle personnelle ne change pas la destination.
+- Les Backrooms ne présentent pas de coordonnées aux joueurs. Chacun construit
+  sa connaissance des trajets et sa cartographie.
+- Couloirs et salles doivent former des lieux explorables avec des ambiances
+  dreamcore, poolrooms et des matériaux liés à l'activité des joueurs, dont
+  la cobblestone (« cobble »).
+
+Les modalités des sections suivantes sont des **choix proposés pour réaliser
+ce premier lot**. Elles ne sont pas des fonctionnalités déjà livrées.
+
+## 3. Condition de démarrage : le ballast doit être exploitable
+
+Le suivi amont doit fournir et documenter :
+
+1. Les opérations qui produisent du ballast, leurs unités, matériaux, quantités,
+   dates/périodes et périmètres d'origine. Distinguer événement terminé, tentative
+   refusée et données absentes. Un zéro enregistré n'est pas une panne de collecte.
+2. Une identité stable des événements ou lots et une reprise sans double compte.
+   Une relecture après arrêt ne produit pas un nouvel apport de matière.
+3. Des instantanés immuables et versionnés, identifiables par période et révision,
+   dont la lecture ne modifie pas le registre économique. Leur archivage doit
+   permettre de comprendre l'origine d'un secteur après évolution du suivi.
+4. La nature du ballast : matière comptable, empreinte d'une opération, ou les
+   deux. Fixer les règles de réservation, de consommation et de récupération
+   lorsque des blocs générés représentent une quantité économique extractible.
+5. Le traitement des actions réalisées dans les Backrooms. Générer un bloc,
+   rejouer un événement ou recycler un matériau ne doit pas alimenter une boucle
+   de création non prévue par le contrat amont.
+6. Les contrôles de sauvegarde, de restauration et de conservation des données,
+   ainsi qu'au moins un parcours réel allant d'une opération au lot enregistré.
+
+Le socle [d'activité datée](blocodex.md#relevés-datés--portée-de-lalpha23)
+observe déjà minage, pose, fabrication, ramassage et jet volontaire. Ces agrégats
+ne prouvent ni consommation ni perte ; ils ne distinguent actuellement ni
+joueur ni dimension. **Ils ne remplacent pas le prérequis ballast.**
+
+BR-01 consomme l'interface du suivi livré. Il ne crée pas les producteurs
+économiques futurs et ne reconstitue pas fictivement leurs transactions.
+Les données synthétiques servent aux tests, sans devenir l'historique du serveur.
+
+## 4. Sommeil, salle personnelle et retour
+
+### Parcours nominal
+
+| Situation | Comportement attendu |
+| --- | --- |
+| Sommeil complet dans le lit personnel validé de l'Overworld | Le serveur prépare la destination, mémorise le retour, puis transfère le joueur dans sa salle. |
+| Premier voyage | Une seule salle est réservée pour l'identité du joueur ; son arrivée et ses raccords sont prêts avant le transfert. |
+| Voyages suivants, y compris après déplacement du lit personnel | Le joueur retrouve la même salle. Le retour est ancré au lit d'origine de ce nouveau voyage. |
+| Réveil volontaire avant la fin du sommeil | Aucun transfert, aucune nouvelle salle créée par le simple début de la pose. |
+| Sommeil dans un lit des Backrooms | Retour au lit d'origine enregistré pour ce joueur ; aucune modification de l'ancrage vers le lit utilisé sur place. |
+| Deux joueurs utilisent successivement le même lit des Backrooms | Chacun revient dans son Overworld à son propre point de retour. |
+| Découverte de la salle d'autrui à pied | Entrée possible ; la salle conserve son identité et son lien au propriétaire. |
+
+Proposition d'interaction : une durée de sommeil individuelle de **100 ticks**
+(environ cinq secondes à 20 ticks/s), à éprouver en jeu. Elle ne dépend pas du
+nombre de joueurs couchés. Permettre le parcours de jour comme de nuit dans les
+mondes Sanctuary où la fonction est activée, sans saut d'heure ni de météo.
+Les lits des Backrooms doivent fonctionner sans explosion.
+
+Réutiliser la règle du lit personnel unique et vérifier son implémentation au
+démarrage : un point de réapparition ne prouve pas à lui seul la propriété d'un
+lit. Si cette association manque, la liaison minimale joueur/lit fait partie
+du parcours BR-01 ; la politique de remplacement doit préserver les lits déjà
+posés. Les lits portés comme accessoires décoratifs ne sont pas des accès.
+
+### Conservation et incidents
+
+- Le lien à la salle repose sur l'identité persistante, jamais sur le pseudo,
+  le nom d'un lit, un prestige ou les coordonnées du lit extérieur.
+- Enregistrer le retour avant le départ. Un transfert a une identité et un état
+  persistants ; interruption, nouvelle requête ou reprise ne créent pas une
+  seconde salle et ne dupliquent pas l'inventaire.
+- Si la destination n'est pas prête, maintenir le joueur en sécurité à la source
+  et permettre d'annuler. Ne pas transférer dans un chunk incomplet.
+- Déconnexion avant transfert : annuler le sommeil. Déconnexion après transfert :
+  reprendre à la dernière position sûre sauvegardée dans les Backrooms, avec
+  le même retour. Un redémarrage n'impose pas un réveil dans l'Overworld.
+- Lit d'origine détruit ou arrivée obstruée : proposer un retour à une position
+  sûre proche de l'ancrage, recherchée dans un rayon borné ; à défaut, utiliser
+  l'arrivée sûre de l'Overworld. Signaler ce secours en FR/EN. Ne pas recréer le
+  lit, modifier le terrain ni rediriger vers la salle d'un autre joueur.
+- Mort : retour proposé dans l'Overworld selon cet ancrage et ce secours ;
+  conserver les règles Sanctuary existantes de mort, d'XP, d'inventaire et de
+  tombe. Une tombe éventuelle reste à son emplacement et ne révèle pas ses
+  coordonnées dans les interfaces joueur. Aucun système de restitution nouvelle
+  des objets perdus n'est ajouté par BR-01.
+- Pour le premier lot, la protection de la salle signifie une arrivée sûre et
+  l'absence d'apparition naturelle de monstres à l'intérieur. Elle ne crée pas
+  implicitement de claim, de verrou de visite ou de règle d'invulnérabilité.
+  Les droits existants s'appliquent aux modifications ; les changements permis
+  aux joueurs persistent, y compris si le tableau ou la porte est retiré.
+
+## 5. Monde partagé et génération progressive
+
+### Hébergement proposé
+
+Utiliser une dimension technique commune, avec l'identifiant proposé
+`sanctuary:backrooms`, à vérifier libre avant enregistrement puis à conserver.
+Les salles personnelles sont des emplacements dans ce monde partagé. Les trajets
+du premier lot sont physiques, continus et stables ; le lit assure les transferts
+vers et depuis l'Overworld.
+
+Un **secteur** est un ensemble de salles et de circulations planifié comme une
+unité. Son plan contient les emprises, niveaux, raccords aux secteurs voisins,
+réservations de salles personnelles et données de génération.
+
+### Ordre de génération
+
+1. Réserver un secteur libre et ses raccords. Associer un instantané de ballast,
+   une graine dérivée, une version de générateur et une version de recettes.
+2. Produire le réseau des pièces : couloirs, embranchements, boucles, impasses
+   lisibles, différences de hauteur et espaces que l'on aperçoit avant d'y accéder.
+3. Attribuer fonctions et ambiances aux ensembles de pièces. Prévoir les
+   transitions et les emplacements stables des refuges personnels.
+4. Construire sols, enveloppes, plafonds, supports, portes, escaliers et bassins.
+   Valider passage à hauteur de joueur, raccords et confinement de l'eau.
+5. Appliquer les matériaux par rôle, puis le mobilier, les lumières et les repères.
+6. Rendre les portions prêtes accessibles à mesure de l'exploration, en respectant
+   un budget borné de travail et de génération anticipée.
+
+Les portes de liaison aux secteurs futurs sont prévues dès le plan initial.
+Une nouvelle salle personnelle occupe une réservation libre ou un nouveau
+secteur raccordé ; elle n'écrase pas une pièce ni une construction existante.
+Le plan garantit un chemin vers le réseau commun et évite les poches isolées.
+
+Les raccords partagés utilisent une convention déterministe conservée côté
+serveur, indépendante de l'ordre de chargement des chunks. Deux joueurs qui
+approchent par des côtés différents réutilisent la même réservation. Le ballast
+ne doit jamais être relu en direct pour changer un raccord pendant sa construction.
+
+La planification réserve une géométrie ; elle ne garde pas tout le monde chargé.
+Bornes de secteur, anticipation, tâches par tick et file d'attente seront
+configurables. Une file saturée ralentit la préparation et maintient les accès
+non prêts fermés de manière sûre. Mesurer les coûts sur le serveur de test.
+
+## 6. Architecture, ambiances et matière
+
+Les plans varient leurs proportions et leurs connexions. Des éléments composés
+à la main peuvent fournir portes, éclairages ou mobilier ; ils ne doivent pas
+imposer une unique salle répétée à chaque tirage.
+
+| Famille du premier lot | Formes et usages | Repères et transitions |
+| --- | --- | --- |
+| Habitation | Chambre, dortoir, salon, couloir étroit | Mobilier, changements de hauteur, ouvertures vers d'autres pièces. |
+| Poolrooms | Bassins, arches, passerelles, vestiaires, douches | Rigoles et zones humides annoncent les bassins ; un chemin praticable permet de progresser. |
+| Infrastructure minérale | Réserves, fondations, soutènements, galeries de maintenance | Cobble, pierre et réparations visibles derrière les enveloppes aménagées. |
+| Traitement dreamcore transversal | Jardin enfermé, lumière évoquant le jour, fenêtre intérieure, volume disproportionné | Étrangeté obtenue d'abord par proportions, répétitions et vues ; aucun portail à rendu spécial requis. |
+
+La relation au ballast agit sur les familles de volumes, les proportions de
+matériaux et leurs rôles. Exemples de recettes proposées :
+
+- Pierre/cobble : épaissir les fondations et favoriser les galeries techniques.
+- Bois travaillé : favoriser cloisons, chambres, réserves et passerelles.
+- Verre : favoriser serres, espaces d'observation et séparations transparentes.
+- Cuivre : favoriser des équipements et architectures techniques ou hydrauliques.
+
+Conserver des palettes par fonction : une poolroom garde son identité même si
+le ballast minéral domine. Les pondérations plafonnées ou à croissance ralentie
+évitent que les matériaux les plus abondants effacent toutes les autres familles.
+Ces transformations de poids n'altèrent jamais les quantités du registre source.
+
+La relation à l'action n'est utilisée que si le suivi la fournit explicitement :
+du cuivre observé ne prouve pas à lui seul qu'une usine a été construite.
+
+### Périodes et ressources
+
+- Associer chaque secteur à une période/révision au moment de sa réservation et
+  conserver les données suffisantes pour reproduire ce plan. Le changement de
+  période influence uniquement de nouvelles réservations.
+- Fournir une base architecturale ancienne pour un serveur au ballast enregistré
+  nul. L'identifier comme héritage fictionnel ; ne pas inventer d'activité passée.
+- En cas d'indisponibilité du suivi, continuer à charger les secteurs connus et
+  les retours sûrs ; suspendre la réservation de nouveaux secteurs. Une panne
+  ne doit pas devenir silencieusement une période de ballast nul.
+- Distinguer l'influence visuelle de la matière comptable récupérable. Avant de
+  rendre des blocs issus du ballast extractibles, appliquer le contrat amont de
+  débit/réservation et de reprise, sans double attribution entre secteurs.
+  La minabilité et les drops du décor doivent être fixés et testés avant livraison.
+  Aucun coffre ne copie automatiquement les objets des joueurs.
+
+## 7. Orientation et intégration au client
+
+- Masquer les positions numériques des surfaces fournies par Sanctuary et du
+  client pris en charge dans cette dimension : F3, HUD, Atlas, marqueurs,
+  Demeure, fiches de lieux, notifications, tombe et messages de transfert.
+- Suspendre le relevé et l'affichage automatiques de la carte/mini-carte pour les
+  Backrooms. Préserver les cartes déjà enregistrées pour les autres dimensions.
+  Vérifier aussi les fonctions natives de carte qui pourraient contourner ce
+  parcours dans le client distribué.
+- Préserver les moyens manuels existants : noms, panneaux, livres, croquis et
+  repères construits. Un éditeur de carte manuelle est hors de ce ticket.
+- Ne pas diffuser un annuaire des salles personnelles ni leurs positions.
+  La découverte physique reste possible, sans autorisation du propriétaire.
+- Les coordonnées restent utilisables dans des diagnostics opérateur explicites
+  et les preuves de test. L'absence de coordonnées est une règle d'interface et
+  de jeu, pas une promesse de cacher la position à un client modifié.
+- Tous les nouveaux messages et libellés sont fournis en français et en anglais.
+
+## 8. Persistance, migration et version de génération
+
+Avant le code qui écrit des données, documenter les schémas et transitions :
+
+- par joueur : identité, identifiant stable de salle, ancrage de retour et état
+  d'un éventuel transfert ;
+- par secteur : identifiant/emprise, voisins et raccords, état de préparation,
+  graine, versions, instantané de ballast et réservations de refuges ;
+- pour la reprise : étapes déjà enregistrées, réservations de matière lorsque
+  nécessaires, traitement d'une interruption entre planification et disponibilité.
+
+Conserver les chunks Minecraft comme état construit et modifiable. Le plan
+sert à produire les portions neuves ; il ne repeint pas les chunks sauvegardés.
+Une donnée invalide est signalée et conservée, sans recréation silencieuse de
+salle ou de registre vide. Une mise à jour ne réinterprète pas les secteurs
+anciens avec de nouvelles recettes.
+
+Développer d'abord sur des mondes neufs dans les dossiers ignorés. Avant toute
+activation sur une sauvegarde existante, livrer un contrat d'adoption explicite :
+ajout de la dimension et des registres, initialisation des liaisons aux lits,
+conservation de l'Overworld, retour des joueurs présents dans les Backrooms lors
+d'une désactivation et limites d'un retour de version. Une désactivation ne
+supprime jamais les secteurs ni le ballast. Aucun déploiement personnel n'est
+inclus dans la rédaction ou l'implémentation de ce ticket.
+
+## 9. Étapes de réalisation du premier lot
+
+Les étapes composent un seul parcours livrable. Les prototypes intermédiaires
+restent dans les mondes de développement jusqu'à satisfaction des critères.
+
+1. **Contrats et intégration** : vérifier la livraison ballast, fixer son
+   adaptateur, les schémas, la minabilité du décor et la règle du lit unique.
+2. **Aller-retour** : dimension commune, deux salles distinctes, tableau et porte,
+   sommeil serveur, persistance et retours ordinaires/de secours.
+3. **Réseau procédural** : secteur d'essai d'environ 12 à 20 pièces, au moins
+   une boucle et deux altitudes, habitation → poolrooms → infrastructure ;
+   une scène dreamcore et des repères reconnaissables. Les nombres sont des
+   objectifs de prototype, pas des tailles universelles du monde.
+4. **Ballast et extension** : relier les recettes aux instantanés réels, comparer
+   plusieurs profils, prolonger vers un autre secteur et éprouver les reprises.
+5. **Parcours client et livraison** : orientation manuelle, FR/EN, multijoueur,
+   performances, sauvegardes et preuves des critères ci-dessous.
+
+## 10. Critères d'acceptation
+
+Toutes les cases décrivent des vérifications futures ; aucune n'est validée par
+la préparation de ce document.
+
+- [ ] **Prérequis** : contrat/version du suivi ballast référencés ; une opération
+  réelle alimente un lot puis un nouveau secteur sans transaction inventée.
+- [ ] **Accès** : sommeil complet individuel, de jour et de nuit, déclenchant
+  exactement un départ ; réveil anticipé sans départ ; temps et météo conservés.
+- [ ] **Identité et visite** : A et B ont deux salles persistantes dans le même
+  réseau ; A rejoint celle de B à pied et y entre ; chaque lit extérieur mène
+  exclusivement à la salle de son joueur.
+- [ ] **Retour** : A et B utilisent successivement un même lit des Backrooms,
+  dont celui d'une salle tierce, et rentrent chacun à leur origine. Tester lit
+  d'origine détruit, obstruction, remplacement et lit des Backrooms retiré
+  pendant le sommeil. Aucun transfert ne place le joueur dans le vide ou un mur.
+- [ ] **Interruption et mort** : reconnexion, redémarrage et arrêt à chaque étape
+  du transfert conservent une salle et un inventaire uniques ; mort/tombe suivent
+  le contrat existant et le secours reste praticable.
+- [ ] **Géométrie** : sur les graines `0`, `42` et `20260915`, démontrer deux
+  refuges raccordés, une boucle, deux altitudes, des passages praticables,
+  des bassins contenus et aucun raccord involontaire vers le vide.
+- [ ] **Identité des lieux** : parcours client montrant habitation, poolrooms,
+  infrastructure en cobble et au moins une scène dreamcore ; repères suffisants
+  pour refaire un trajet sans coordonnées. Une validation visuelle accompagne
+  les contrôles géométriques.
+- [ ] **Empreinte matérielle** : à graine et recettes égales, trois instantanés
+  contrôlés pierre/cobble, bois et verre/cuivre produisent des différences
+  vérifiables de matériaux/rôles tout en préservant le parcours et les ambiances.
+- [ ] **Histoire conservée** : un nouvel apport affecte un nouveau secteur ;
+  plan, constructions, contenus et blocs déjà générés du premier restent
+  inchangés. Une période nulle et des données manquantes suivent deux traitements
+  distincts. Les éventuelles quantités extractibles ne sont attribuées qu'une fois.
+- [ ] **Concurrence et reprise** : charger un plan par plusieurs ordres de chunks,
+  puis par deux explorateurs simultanés ; obtenir les mêmes raccords. Interrompre
+  la création d'un secteur et reprendre sans double réservation ni réécriture
+  de portions déjà disponibles aux joueurs.
+- [ ] **Orientation** : aucun affichage de coordonnées ni cartographie automatique
+  des Backrooms dans les surfaces prises en charge ; cartes de l'Overworld
+  conservées, diagnostics opérateur explicites, messages et parcours FR/EN testés.
+- [ ] **Charge et adoption** : file de génération bornée, arrivée sûre même en
+  retard de préparation, absence de blocage serveur ; fournir budget retenu,
+  mesures de temps de génération/tick/mémoire et configuration de la machine.
+  Vérifier le contrat d'adoption et le retour avant désactivation sur une copie
+  de développement, sans régénérer l'Overworld.
+
+### Vérifications et preuves à produire lors de l'implémentation
+
+- Tests purs du plan : raccords, accessibilité, recettes et reproductibilité.
+- GameTests serveur ciblés : sommeil, identité, retours, persistance, fluides,
+  ballast et absence de doubles effets. Essais à deux clients pour le parcours
+  complet et ses rendus ; un test serveur seul ne valide pas le masquage client.
+- `./gradlew check build`, puis `./gradlew assemblePack` si la distribution change.
+- Rapports avec version Minecraft/mod/générateur, graines, instantanés de ballast,
+  coordonnées opérateur, configuration et captures. Conserver mondes et artefacts
+  dans les dossiers de développement ignorés ; résumer les preuves dans le ticket.
+- À la livraison du mod, synchroniser `mod_version`, `pack_version` et
+  `packwiz/pack.toml` avec le prochain `beta.xxx`, conformément au
+  [versionnement](versioning.md). Ce document seul n'incrémente aucun binaire.
+
+## 11. Hors périmètre et décisions de démarrage
+
+Hors lot : système d'affinités/némésis, nouveaux pouvoirs, générateur général
+d'Indoors achetables, mailbox, shop, objets perdus restitués, quêtes/boss de
+Backrooms, portails à rendu transparent, géométrie qui se reboucle par
+téléportation, évolution des pièces déjà construites et éditeur de cartes.
+
+À fixer dans la première étape à partir du suivi livré : référence du prérequis,
+unités et périodes du ballast, droits d'extraction/drops, dimensions des secteurs,
+budgets de génération et détails de migration. Les réglages proposés de sommeil
+et de secours sont à éprouver. Ces décisions ne rouvrent pas les règles d'accès,
+de visite et de retour confirmées par le créateur.
+
+## 12. Références
+
+- [ANO-01 — doubles de Steve](steve-anomalies.md) prépare la suite : Herobrine
+  dans les Backrooms, mineur fantôme dans l'Overworld et les Backrooms, Steve
+  bugué persistant et transportable. Ces anomalies ont leurs lots propres et
+  ne bloquent pas la livraison du réseau BR-01. Leurs futures modifications
+  de blocs seront des actions de gameplay sauvegardées, jamais une régénération
+  implicite des secteurs existants.
+- [Cosmologie : matière, espaces et mémoire](cosmologie.md).
+- [Vision : dimensions et espaces](vision.md#dimensions-et-espaces).
+- [Blocodex : portée des relevés disponibles](blocodex.md).
+- [Temps réel : sommeil et horloges](realtime-beta037.md).
+- [Règles de contribution](../CONTRIBUTING.md) et
+  [modèle Fonctionnalité](../.gitea/ISSUE_TEMPLATE/feature.md).
+
+Le document conceptuel « Système des Habitants, Affinités et Anomalies » a nourri
+la discussion ; ses autres mécanismes ne sont pas des dépendances de BR-01.

docs/base-peaks-beta204.md

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

docs/blocodex-beta004.md

@@ -0,0 +1,95 @@
+# UI-01 — cadre natif du Blocodex et seuil de sprint
+
+Demande du 13 septembre 2026, branche `codex/blocodex-layout-beta004`.
+Livraison locale d'essai : `beta.004`, après l'export immuable de beta.003.
+
+## Résultat attendu
+
+Le titre Blocodex et les onglets restent en haut de l'écran, comme les menus
+Minecraft. Le bouton natif **Done / Terminé** reste centré en bas. Le corps
+utilise la largeur et la hauteur disponibles à l'échelle de GUI choisie.
+
+Ordre : **Discovery, Progression, Story, Inhabitant** ; traductions françaises
+**Découvertes, Progression, Histoire, Habitant**. Inhabitant conserve la fiche
+comme quatrième onglet. Discovery ouvre les connaissances de blocs existantes.
+La navigation garde le même cadre et Done revient à l'écran qui a ouvert le
+Blocodex, sans empiler les onglets comme des sous-menus.
+
+Compétences à gauche, aptitudes défilantes à droite. Les six compétences
+restent visibles ; Minage, Construction et Inventaire restent « À venir ».
+La fiche et l'histoire doivent rester entièrement lisibles par défilement,
+sans couper la biographie ni les libellés des événements.
+Les six PNG 9×9 fournis le 13 septembre sont utilisés sans modification :
+heart → Vie, hunger → Faim, mining → Minage, building → Construction,
+breathing → Souffle, inventory → Inventaire. La taille suit l'échelle entière
+du GUI ; une infobulle donne le nom de chaque compétence. À l'échelle minimale,
+la colonne gauche dispose de plus de place pour conserver icône et libellé.
+
+## Périmètre et validation
+
+Le retour du créateur ajoute la correction de la faim : beta.003 autorisait
+le sprint avec trois icônes pleines à cause d'un seuil relatif à la capacité.
+beta.004 restaure le seuil vanilla **strictement supérieur à 6 points**.
+Acheter le premier rang de Faim augmente la capacité mais ne remplit pas la
+barre ; manger au-delà de trois icônes permet ensuite de courir. Le serveur
+refuse un démarrage invalide et arrête un sprint quand la faim redescend à 6.
+Les exceptions vanilla du vol créatif et des montures sont conservées.
+
+Aucun prix, identifiant de sauvegarde ou terrain ne change. Les mondes et
+profils beta.003 restent lisibles sans migration. Aucun déploiement personnel.
+
+Vérifier en client natif : les quatre onglets, titre et Done ancrés, navigation
+par clavier et souris, fermeture vers le jeu et vers Échap, défilement,
+recherche et pagination de Discovery, tailles et échelles GUI natives.
+Vérifier le seuil de sprint avant/après le premier achat de Faim, la baisse
+de nourriture, la prédiction d'alimentation et l'exception créative.
+Exécuter `check build` avec les GameTests de progression ciblés, puis assembler
+et vérifier le MRpack beta.004.
+
+## Vérifications effectuées
+
+Sur macOS / Java 25, Minecraft `26.3-pre-2`, Fabric Loader `0.19.5`, Fabric API
+`0.160.0+26.3`, exclusivement dans les dossiers de développement ignorés :
+
+- `./gradlew check build -PsanctuaryFocusedTests=progression` réussit en
+  **4 min 8 s**. Les contrôles purs passent ainsi que **5/5 tests natifs**
+  exécutés par le serveur ciblé. Le scénario des capacités vérifie les seuils
+  de faim 6/7, l'achat qui ne nourrit pas, l'arrêt d'un sprint après baisse de
+  faim et l'exception du vol créatif. Les achats, respawn, données, noms et
+  position assise restent vérifiés par les scénarios de progression.
+- Le parcours client final passe les quatre onglets dans huit
+  configurations de fenêtre/échelle : fenêtres 854×480 et 960×720, options
+  GUI 1, 2, 3 et automatique. Les dimensions logiques obtenues vont de
+  **320×240 à 960×720**. Titre, onglets ordonnés et Done ancrés sont contrôlés,
+  ainsi que recherche et pagination sur le vrai catalogue serveur,
+  navigation clavier et retour vers le jeu ou le menu Échap. Les six icônes
+  sont présentes en 9×9 dans chaque configuration.
+- `./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true
+  -PsanctuaryProgressionClientTests=true` réussit en **1 min 37 s** sur le code
+  final : seuil client et prédiction d'alimentation, achats, mort et
+  redémarrage, navigation des quatre onglets. Les captures françaises au GUI
+  minimal et la progression à grande taille ont été inspectées : les icônes
+  sont nettes, associées aux bonnes compétences, sans chevauchement des libellés.
+- `./gradlew assemblePack -x check` réussit après les contrôles précédents,
+  sans les relancer pendant l'assemblage. L'export packwiz est vérifié : CRC
+  ZIP, versions interne/externe, JAR embarqué identique au build, cadre et
+  mixin de sprint présents, ressources JSON et clés FR/EN, empreinte Fabric
+  API, index packwiz, six PNG identiques aux originaux et empreinte beta.003
+  antérieure conservée.
+
+## Export local
+
+**[Sanctuary-beta.004.mrpack](../build/Sanctuary-beta.004.mrpack)**,
+2 214 350 octets. Minecraft et les dépendances restent inchangés.
+La sauvegarde beta.003 peut être conservée ; un nouveau monde n'est pas requis.
+
+SHA-256 MRpack : `aee4fdebd48d6719f85d2477fbefe90e12ae38313cc107615fa6105c0c57d475`.
+SHA-256 JAR : `3a8c26105121340a41644c817533bff59f519d7f02837efe570511568eba98a6`.
+Reçu : `build/blocodex004-artifact.json`. Aucun canal public ou installation
+Prism personnelle n'est modifié.
+
+Logs : `build/beta004-check-build.log`, `build/beta004-assemble-pack.log` et
+`build/beta004-client-final.log`. Captures finales : `build/beta004-preview/`.
+Les deux assertions worldgen historiques
+signalées en beta.003 ne font pas partie de la sélection native de ce ticket
+et ne sont pas présentées comme corrigées. Aucun essai Windows n'est revendiqué.

docs/blocodex-navigation.md

@@ -0,0 +1,175 @@
+# Blocodex — navigation, découvertes et vitrine de l'habitant
+
+Discussion du 13 septembre 2026, après l'essai de beta.004.
+Branche de conception : `codex/blocodex-navigation`.
+**Cadrage uniquement : les comportements ci-dessous ne sont pas encore livrés.**
+Le pack beta.004 reste inchangé ; cette note ne modifie aucune sauvegarde.
+
+## Décisions exprimées par le créateur
+
+- Conserver le rendu Minecraft, le titre en haut et le bouton Terminé en bas.
+- Réunir statistiques, advancements, carte, descriptions et constructions
+  dans la navigation du Blocodex.
+- Cacher les entrées non découvertes aux joueurs ; permettre leur inspection
+  aux opérateurs. Distinguer explicitement les essais joueur et opérateur.
+- Retirer S'asseoir des aptitudes et du passeport. La faculté de s'asseoir
+  reste disponible dès le début ; seul son emplacement dans ces menus change.
+- Faire du passeport une fiche dont on peut être fier : exploits accomplis,
+  constellation favorite, type de créature favori.
+- Un favori doit être découvert. Le type de créature favori peut changer une
+  fois toutes les **24 heures réelles** et donne une influence légère, notamment sur l'apprivoisement
+  et le butin. Le choix quotidien de différents types est volontairement permis.
+- Intégrer les plans de construction avec Litematica.
+- Le créateur valide la maquette comme référence à conserver et réutiliser
+  pour le site, avec le fonds d'images et de documents jusqu'à alpha.30.7.
+- Priorité suivante : carte native Sanctuary inspirée de Xaero, puis Demeure,
+  factions et claims, New Game Plus et prestiges. L’exploration précède le
+  déblocage de Grande carte. Voir [MAP-01](atlas-beta005.md).
+
+## Organisation proposée
+
+Quatre rubriques principales stables, puis une navigation locale. L'accès à
+une fonction est retrouvé par sa place et son nom, quelle que soit la touche
+qui a ouvert le Blocodex. À petite échelle, les sous-rubriques passent sur
+plusieurs lignes ; le corps défile sans déplacer l'en-tête ni le pied de page.
+
+| Rubrique FR / EN | Sous-rubriques proposées | Rôle |
+| --- | --- | --- |
+| Découvertes / Discovery | Blocs, Objets, Créatures, Recettes | Ce que je connais, avec description et actions contextuelles. |
+| Progression / Progression | Capacités, Exploits, Statistiques | Compétences à gauche et aptitudes à droite ; advancements Minecraft en priorité, accomplissements Sanctuary séparés ; compteurs vanilla. |
+| Monde / World | Atlas, Constructions, Histoire | Cartes et marqueurs ; plans et matériaux ; événements, Gazette, archives et liens avec le Galactium lorsqu'ils seront disponibles. |
+| Habitant / Inhabitant | Passeport et vitrine sur la même page | Identité, exploits épinglés, constellation favorite et créature favorite. |
+
+La maquette approuvée utilise **Monde** à la place de Story pour accueillir
+la carte et les constructions en plus de l'histoire. La référence archivée
+est dans [archives/web](../archives/web/README.md) ; son statut reste une
+conception validée, sans implémentation supplémentaire dans beta.004.
+
+Les boutons Statistiques et Advancements peuvent d'abord ouvrir les écrans
+natifs depuis Progression et revenir au Blocodex. Il n'est pas nécessaire de
+réécrire leurs données ou leur rendu pour unifier l'accès. Le cadre reste
+identique pour les pages Sanctuary ; les écrans communautaires peuvent garder
+leur présentation avec un retour au bon écran parent.
+
+L'item description devient le contenu de la fiche d'un objet découvert,
+pas une rubrique de plus. Depuis une recette : ouvrir l'objet connu ; depuis
+un exploit accompli : l'épingler dans le passeport ; depuis un favori : ouvrir
+sa fiche ; depuis un plan : consulter les matériaux connus.
+
+## Découvertes et droit de fabrication
+
+Le socle actuel ne suit que les blocs. Il transmet leur catalogue complet,
+et affiche aussi les noms inconnus : voir `BlockKnowledgeNetworking` et
+`SanctuaryBlocodexScreen`. Les objets indépendants et créatures exigent un
+contrat de découverte supplémentaire avant leur intégration réelle.
+
+Pour la nouvelle vue joueur, une entrée inconnue ne produit aucune ligne,
+silhouette, nom, description, résultat de recherche ou liste de favoris.
+Afficher le nombre découvert, sans total de registre révélant les manques.
+Les éventuelles pistes viendront de quêtes ou conversations, sans exposer
+automatiquement le catalogue secret.
+
+Filtrer la réponse Sanctuary côté serveur et les vues côté client. Une
+navigation depuis une recette, un plan ou une recherche ne doit pas révéler
+indirectement les noms et descriptions masqués. Ne pas considérer le registre
+Minecraft, nécessaire au client, comme un secret cryptographiquement caché.
+
+Conserver trois décisions distinctes : découverte de l'objet, accès à
+l'outil de consultation des recettes, révélation d'une recette particulière.
+**La fabrication manuelle reste libre**, même si la recette n'est pas révélée.
+Les écrans vanilla conservent leurs règles de visibilité d'advancements ; on
+ne cache pas un objectif Minecraft normal simplement parce qu'il est inachevé.
+
+## Opérateur et essais
+
+En solo, Autoriser les commandes permet d'accéder aux outils opérateur selon
+les permissions réellement accordées. En multijoueur, le serveur décide des
+droits du joueur ; le mode créatif seul n'est pas une preuve d'autorisation.
+Utiliser le niveau des commandes Sanctuary existantes comme référence.
+
+Un opérateur peut ouvrir une **Vue opérateur** explicitement marquée, avec
+catalogue complet et états de découverte. La vue joueur reste disponible
+pour tester le parcours ordinaire. Inspecter un contenu ne le marque pas
+découvert et n'accorde aucun exploit, XP, favori ou aptitude.
+
+La vue joueur d'un opérateur sert à vérifier l'affichage. Elle ne transforme
+pas ses permissions : les tests d'autorité exigent aussi un vrai joueur sans
+droits. Séparer les actions de diagnostic des actions qui modifient l'état.
+Toute révocation de droits invalide la vue opérateur et son cache.
+
+Matrice minimale du futur ticket :
+
+- Solo sans commandes et client non-opérateur : inconnus absents, recherches
+  et chemins indirects filtrés, aucun accès aux outils opérateur.
+- Solo avec commandes et opérateur serveur : inspection complète possible,
+  marquée comme telle ; aucune découverte enregistrée par cette inspection.
+- Opérateur en vue joueur : mêmes lignes visibles que selon ses découvertes.
+- Retrait des droits avec une page ouverte : retour à la vue autorisée.
+- Découverte réelle, mort et reconnexion : mise à jour puis conservation.
+- Carte verrouillée : raccourcis, menus et autres points d'entrée respectent
+  le même droit ; minimap, grande carte et marqueurs restent trois aptitudes.
+
+## Passeport et affinité
+
+Proposition : trois emplacements d'exploits Minecraft déjà obtenus, une
+constellation connue et un type de créature découvert. Le nombre de trophées
+et le moyen de partager le passeport restent à confirmer. Les identifiants
+référencent les sources de vérité ; épingler n'accorde pas l'accomplissement.
+La constellation favorite nécessite le futur système du ciel : aucune liste
+fictive ne doit devenir un catalogue réel dans le mod.
+
+Pour la créature, le créateur confirme un délai de **24 heures réelles depuis le dernier
+changement**, calculé côté serveur et conservé après mort, déconnexion et
+redémarrage. Il ne s'agit pas d'une remise à zéro à minuit.
+
+Seul le favori courant donne un léger bonus, sans cumul permanent des anciens
+choix. Les animaux déjà apprivoisés restent apprivoisés. Ne pas inventer
+l'apprivoisement d'une espèce qui n'a pas cette mécanique : chaque type doit
+avoir un effet adapté ou ne recevoir aucun effet mécanique.
+
+Restent à régler avant le code : coefficient, types éligibles, variante ou
+type entier, attribution du butin en coopération, et portée du bonus de butin
+(mort de l'animal, productions comme laine/œufs, ou les deux). Un bonus à la
+mort encourage à chasser son favori ; un bonus aux productions encourage à
+s'en occuper. Le profil peut rester discret sans afficher un pourcentage.
+
+Le contrat de persistance des favoris doit être écrit avant d'ajouter des
+données aux habitants. Préférer un ajout versionné avec absence interprétée
+comme aucun favori, sans réécriture silencieuse des profils beta.003/004.
+
+## Carte et constructions
+
+Sanctuary développe désormais sa cartographie native ; le partage futur
+des découvertes reste de joueur à joueur. Litematica conserve la gestion de schémas, les projections et les
+listes de matériaux : [documentation de l'auteur](https://github.com/maruohon/litematica/wiki/Frequently-Asked-Questions).
+Sanctuary fournit le point d'entrée, les droits et les liens vers ses données.
+Un plan reçu ne constitue pas automatiquement une découverte de ses matériaux.
+Préciser le filtrage de la projection et de la liste avant l'intégration pour
+éviter de révéler des matériaux inconnus par ces écrans.
+
+Aucune compatibilité Minecraft 26.3-pre-2 de Xaero, JEI ou Litematica n'est
+établie par cette note, et aucun de ces mods n'est ajouté au pack. Vérifier
+version exacte, dépendances, API et distribution au ticket de chaque adaptateur.
+Le collage créatif d'un schéma ne doit pas devenir une fonction de construction
+accessible par la seule découverte d'un plan.
+
+## Découpage proposé
+
+L'ordre historique était carte native, puis Demeure, factions/claims,
+New Game Plus et prestiges. Après beta.006, le créateur demande la carte
+immersive et l'achèvement des six compétences avant le New Game+ ; les factions
+sont conçues avec le cycle. Les [prochains tickets](prochains-tickets.md) font
+foi pour cet ordre actualisé. Les lots d'interface ci-dessous restent identifiés.
+
+1. **UI-02** : retirer S'asseoir de ces deux pages, filtrer le catalogue actuel
+   selon les droits et découvertes, ajouter les accès natifs Statistiques et
+   Advancements. Tests joueur/opérateur et retour des écrans. Aucun favori,
+   nouveau format de sauvegarde ou mod communautaire nécessaire.
+2. **KNOW-02 / PROFILE-02** : découverte des objets et créatures, épinglage
+   des exploits et contrat des favoris. Effets d'affinité dans un lot séparé
+   une fois les règles chiffrées arrêtées ; le délai de 24 heures est confirmé.
+3. **MAP-01 / CONNECT-01** : carte native, puis adaptateurs recettes et plans sur des versions
+   vérifiées ; réutiliser les mêmes contrôles de découverte et d'aptitudes.
+
+La maquette de discussion illustre la navigation avec des données fictives.
+Elle ne démontre ni l'intégration des mods ni l'application des permissions.

docs/blocodex.md

@@ -0,0 +1,255 @@
+# Blocodex natif — connaissances, matière et stocks
+
+Ticket META-01, branche `codex/blocodex-natif`, cible Minecraft **26.3-pre-2**.
+Le Blocodex appartient au mod Sanctuary. Il est disponible sans appareil,
+recette ni déblocage. La mémoire personnelle, le recensement du terrain et
+celui des stocks forment un socle commun aux futures palettes de structures,
+règles d’expansion et règles du shop. Les relevés datés ajoutent la temporalité
+nécessaire à une future lecture de l’histoire économique du serveur.
+
+## Contrat des informations
+
+La mémoire est personnelle : une identité de joueur (UUID), dans une sauvegarde
+de serveur, partagée entre ses dimensions. Les indicateurs sont indépendants.
+
+| Information | Sens |
+| --- | --- |
+| Inconnu | Aucune observation, possession, pose ni statistique de minage ou de jet. C'est un état calculé, pas une étape enregistrée. |
+| Vu | Le premier bloc rencontré par le regard du joueur, à au plus 32 blocs, observé côté serveur tous les 5 ticks. Les obstacles arrêtent le rayon ; les chunks absents ne sont pas chargés. Ce relevé ne couvre pas chaque pixel du champ de vision. |
+| Miné | Compteur vanilla `mined` du bloc. Ses règles sont conservées : notamment pas de minage créatif, ni de minage sans l'outil requis. |
+| Déjà possédé | Le bloc, sous forme d'item, a été présent dans l'inventaire personnel ou sur le curseur d'un menu. Les statistiques vanilla de ramassage et de jet prouvent aussi une possession passée. |
+| Jeté | Compteur vanilla `dropped` de l'item du bloc. Il compte les unités volontairement jetées, pas les objets éjectés à la mort ni le butin produit par le bloc cassé. |
+| Posé | Nombre de placements réussis par le joueur avec un item de bloc, y compris en créatif. Une tentative refusée, une interaction ou un placement par commande ne compte pas. |
+| En inventaire | Quantité actuellement dans l'inventaire personnel, équipement et curseur compris. Les coffres ouverts, ender chests et contenus imbriqués des boîtes ne sont pas inclus. |
+
+Les blocs sont identifiés par leur identifiant de registre ; les propriétés
+d'état (orientation, humidité, etc.) ne créent pas une nouvelle fiche. Deux
+identifiants restent distincts : une torche murale peut être vue et posée tandis
+que l'item possédé correspond à la torche debout. Les noms des blocs inconnus
+restent consultables, comme un catalogue ; cette version ne décide pas d'une
+politique de secrets ou de verrouillage des recettes.
+
+L'inventaire est observé chaque tick serveur, après les transactions de menus
+et avant la consommation d'un item placé. Les statistiques de ramassage/jet
+complètent ce relevé. Une mutation d'inventaire entièrement réalisée entre ces
+points par un autre mod ne peut pas être reconstruite après coup.
+Les spectateurs ne découvrent pas de blocs par le regard.
+
+## Persistance et arrivée dans une sauvegarde antérieure
+
+Contrat additif v1 : fichiers `data/sanctuary-blocodex/<uuid>.json`, enveloppe
+avec `schema: 1` et UUID, puis observations, possessions et poses par identifiant.
+Les statistiques vanilla restent dans leurs propres fichiers et sont seulement
+lues. Aucune conversion du terrain, des paramètres de génération, des chunks,
+du journal d'expansion ou des statistiques existantes n'est effectuée.
+
+Sans fichier Blocodex, les observations et poses commencent vides. Le minage,
+le jet et les preuves de possession sont disponibles depuis les statistiques
+vanilla déjà présentes. On n'invente pas les observations ni les poses passées
+à partir de `used`, qui compte aussi d'autres usages.
+
+Les changements sont sauvegardés tous les 600 ticks, lors de la sauvegarde du
+serveur, à la déconnexion et à l'arrêt. Un crash peut perdre les dernières
+observations ou poses non sauvegardées. Un fichier invalide ou d'une version
+inconnue désactive la mémoire concernée et n'est jamais remplacé silencieusement.
+Les identifiants de mods absents sont conservés sur disque. Les anciennes
+versions de Sanctuary ignorent ce répertoire additionnel ; les poses réalisées
+pendant un retour à une ancienne version ne peuvent pas être récupérées.
+
+## Réutilisation
+
+`BlockKnowledgeService.knowledge(player, block)` et `snapshot(player)` renvoient
+des valeurs immuables calculées côté serveur. Le service expose aussi sa santé ;
+un consommateur doit refuser une condition de progression si la mémoire est
+indisponible, plutôt que d'interpréter une panne comme une découverte vierge.
+`BlockKnowledgeEvents.CHANGED` permet de réagir aux observations, possessions,
+poses et changements de statistiques. Les écouteurs s'exécutent sur le thread
+serveur ; ils ne constituent pas un journal transactionnel de récompenses.
+
+Cette livraison ne verrouille aucune recette et n'accorde aucune récompense.
+Palettes disponibles, recherches, progression et structures pourront ensuite
+définir leurs propres conditions en utilisant cette API commune.
+
+### Palettes de structures
+
+`BlockKnowledgeService.palette(player, condition, tag)` croise les connaissances
+du joueur avec une famille de matériaux. Les critères `BlockKnowledgeFacet`
+sont combinables avec `and` et `or` : vus **ou** déjà possédés, minés **et**
+actuellement portés, etc. Le résultat immuable garde les identifiants triés et
+les quantités réellement portées.
+
+```java
+var candidates = BlockKnowledgeService.palette(player,
+        BlockKnowledgeFacet.SEEN.or(BlockKnowledgeFacet.POSSESSED),
+        BlockKnowledgeService.NATURAL_STRUCTURE_MATERIALS);
+```
+
+Le tag `sanctuary:structure_palette/natural` fournit une première famille de
+pierres, terres, bois, feuilles et autres matériaux naturels, modifiable par
+datapack. D'autres tags pourront définir des palettes minérales, végétales ou
+propres à un biome. Le choix des couleurs, les contraintes physiques des blocs,
+les quantités nécessaires et la construction de la structure appartiendront au
+moteur de structures : une sélection de palette ne réserve aucun stock et ne
+place aucun bloc.
+
+## Recensement du terrain chargé
+
+`TerrainCensus.snapshot(server)` expose une distribution des blocs par dimension ;
+`TerrainCensus.chunkSnapshot(level, pos)` fournit le détail d’un chunk déjà
+chargé. Ces lectures se font sur le thread serveur et renvoient des valeurs
+immuables. Elles parcourent les chunks `FULL` déjà accessibles, sans charger
+de chunk absent ni attendre la fin d’une génération.
+
+Le comptage utilise les palettes des sections de 16 × 16 × 16 blocs. Il regroupe
+les orientations et autres propriétés sous l’identifiant du bloc. Les blocs
+d’air sont exclus ; l’eau et la lave conservent leurs identifiants de blocs.
+Le budget est de **16 sections non vides par tick serveur**, partagé entre les
+dimensions et les demandes du même tick. Une section entièrement vide est
+reconnue par ses métadonnées, sans parcourir sa palette.
+
+Le relevé est progressif. Une section modifiée est retirée des totaux dès que
+sa révision change, puis remise dans la file de comptage. Les sections et
+chunks déchargés sortent du relevé. Un consommateur dispose, par dimension ou
+chunk, du nombre de sections chargées et comptées, du tick de capture, du tick
+du dernier comptage effectué et de l’âge de la plus ancienne attente.
+`complete()` et `coverage()` décrivent la couverture **des zones chargées**.
+Une couverture de 100 % ne signifie jamais que toute la sauvegarde a été lue.
+
+Pendant un rattrapage, zéro bloc compté ne prouve donc pas l’absence de ce bloc.
+Les futures règles d’expansion devront fixer leur couverture minimale et leur
+zone d’étude avant de prendre une décision. Les résultats en mémoire sont
+reconstruits après redémarrage ; ce service n’écrit pas dans les chunks et ne
+modifie pas leur génération.
+
+## Recensement des stocks présents
+
+`StockCensus.snapshot(server)` photographie les objets accessibles au tick de
+la demande, sur le thread serveur. Le parcours des slots et des entités chargées
+est effectué à la demande ; aucun abonnement ne le relance à chaque tick.
+Les quantités sont des unités d’items, tous
+types confondus : un lingot, un outil ou une graine sont comptés même s’ils ne
+correspondent pas à un bloc. Les composants, l’usure et les enchantements ne
+créent pas de nouveaux identifiants de stock dans cette version.
+
+| Catégorie | Couverture |
+| --- | --- |
+| `playerItems` | Joueurs connectés : inventaire personnel, équipement et curseur du menu. Le contenu du menu ouvert n’est pas additionné. |
+| `blockContainerItems` | Entités de blocs déjà instanciées dans les chunks chargés, qui exposent l’interface `Container` : coffres, hoppers, fours, pots décorés, etc. Chaque moitié d’un double coffre est comptée une fois. |
+| `entityContainerItems` | Entités chargées qui exposent `Container`, notamment les wagonnets et bateaux à coffre. |
+| `groundItems` | Quantités des `ItemEntity` chargées et encore présentes au sol. |
+
+Le relevé ne déballe **aucune table de butin**. Tout conteneur dont la table
+reste à résoudre est ignoré avant la lecture de ses slots ; son existence
+augmente `pendingLootContainers`. Les entités de blocs encore stockées sous
+forme de NBT et non instanciées sont également laissées intactes, avec leur
+nombre dans `pendingBlockEntities`. Leur contenu n’est pas remplacé par une
+estimation.
+
+La couverture exclut les joueurs hors ligne, les chunks et entités déchargés,
+les ender chests, le contenu imbriqué des shulker boxes et bundles, les grilles
+de fabrication en cours dans l’inventaire ou l’établi (`menuInputsIncluded()`
+est faux), les inventaires et équipements des créatures. Le résultat de
+fabrication affiché avant validation ne constitue pas un stock supplémentaire.
+Elle exclut aussi les objets internes
+des entités de blocs qui n’exposent pas `Container`, comme les aliments d’un feu
+de camp ou le livre d’un pupitre. Une shulker box portée compte comme un item ;
+une shulker box posée et chargée expose son conteneur. Les exclusions figurent
+dans le contrat de couverture ; `partial()` reste vrai.
+
+Ce relevé indique où se trouvent les unités observées. Il ne les réserve pas,
+ne les transfère pas et n’évalue pas leur prix. Ajouter le terrain aux stocks
+ne donne pas une quantité immédiatement vendable : une roche dans un chunk
+reste différente d’un item dans un coffre.
+
+## Consultation et futurs consommateurs communs
+
+`WorldCensusService.capture(server)` rassemble les deux relevés pour une même
+lecture côté serveur. Le consommateur réutilise cet instantané pendant son
+calcul et conserve ses informations de couverture. Le shop et les expansions
+pourront ainsi consulter la même base, avec leurs propres règles de fraîcheur,
+de portée géographique, de prix, de consommation et de réservation.
+
+Les diagnostics suivants sont réservés aux opérateurs :
+
+```text
+/sanctuary census
+/sanctuary census block minecraft:stone
+/sanctuary census item minecraft:gold_ingot
+```
+
+Le résumé présente la couverture du terrain par dimension, les quatre catégories
+de stocks et les conteneurs au butin encore indéterminé. Le Blocodex personnel
+accessible par **B** conserve les données du joueur ; ces diagnostics ne diffusent
+pas les inventaires agrégés aux autres joueurs.
+
+## Relevés datés — portée de l’alpha.23
+
+La collecte regroupe les activités observées par **jour civil UTC**, pour
+l’ensemble du serveur, sans attribution à un UUID ou à une dimension :
+
+| Action | Registre et unité |
+| --- | --- |
+| `mined` | `block` : nombre de blocs minés, selon les règles des statistiques vanilla. |
+| `placed` | `block` : placements réussis par le joueur, créatif inclus et spectateurs exclus. |
+| `picked_up` | `item` : unités ramassées observées par les statistiques vanilla. |
+| `dropped` | `item` : unités volontairement jetées observées par les statistiques vanilla. |
+| `crafted` | `item` : unités fabriquées créditées au joueur par les statistiques vanilla. |
+
+Chaque combinaison conserve son action, son registre, son identifiant et une
+quantité entière sur 64 bits, saturée à la valeur maximale en cas de dépassement.
+Un compteur de minage n’est pas transformé en nombre d’items produits. Les actions
+antérieures à l’installation ne sont pas réparties artificiellement entre des
+dates à partir des statistiques cumulées de Minecraft.
+
+`MaterialActivityHistory.snapshot(server, day)` expose un instantané immuable
+avec le jour, les compteurs, `recorded` et `unsaved`. Un jour sans données
+enregistrées demeure inconnu ; il ne constitue pas un historique d’activité nulle.
+Les opérateurs peuvent consulter `/sanctuary history` ou préciser une date avec
+`/sanctuary history 2026-09-10`. La commande affiche au plus les 16 lignes aux
+quantités les plus élevées et indique combien ont été omises ; l’API conserve
+l’ensemble des compteurs du jour.
+
+La persistance additionnelle utilise `data/sanctuary-activity/YYYY-MM-DD.json`,
+avec un schéma 1 et des dates UTC. Elle est séparée de la mémoire personnelle
+et des chunks. Les écritures ont lieu tous les **600 ticks**, à la sauvegarde
+et à l’arrêt du serveur, ainsi qu’au changement de jour observé par le service.
+Un crash peut perdre les derniers relevés non sauvegardés, soit normalement
+jusqu’à 30 secondes de jeu à 20 ticks par seconde. Le fichier conserve les
+identifiants de mods absents ; il refuse les schémas inconnus, doublons,
+compteurs invalides et changements externes. Une erreur arrête la collecte et
+rend le service indisponible jusqu’à réparation puis redémarrage, en conservant
+le fichier en cause. Les limites sont de 100 000 tuples et 16 Mio par jour.
+
+Ces relevés permettent de distinguer des périodes d’activité. Ils ne conservent
+pas d’historique des instantanés de stocks, ne couvrent pas la fabrication automatique des
+machines et n’établissent ni consommation, ni perte, ni destination des objets.
+Ils ne retracent pas chaque transfert entre coffres ou chaque changement de propriétaire, et
+ne constituent pas un journal transactionnel d’achats, de récompenses ou de
+réservations. Le **ballast**, ses unités, ses conversions et sa traduction en
+géologie restent à concevoir dans le [cahier de cosmologie](cosmologie.md).
+Aucun objet n’est consommé et aucune Backroom n’est générée par ces mesures.
+
+## Référence WSMC retrouvée
+
+La recherche locale a retrouvé une partie du travail précédent dans
+`/Users/koka/Documents/sanctuary/Gameplay/blocodex` :
+`ClientVoxelProjectBuilder` convertit des apparences de blocs et d’items en
+volumes/couches de blocs ; `BlocodexStudioPalettes` sélectionne des matériaux
+opaques appris. Le projet conserve aussi un instantané WSMC de 1 881 entrées
+(1 168 blocs, 490 items, 223 mobs), issu de Minecraft 1.21.11.
+
+Cette référence reste historique. La nouvelle API fournit la connaissance et
+les candidats de palette ; la traduction de modèles d’entités en structures
+(visage de creeper, squelette géant, etc.) reste un chantier distinct. Aucun
+générateur d’entités ni import de ce snapshot ancien n’est ajouté au registre
+de Minecraft 26.3 par le socle méta.
+
+## Validation
+
+Validation locale du 10 septembre 2026 : `./gradlew check build assemblePack`
+passe, avec **24 GameTests natifs réussis**. Le client graphique vérifie les
+widgets et les messages réels dans un nouveau monde intégré, avec B sans droit
+opérateur, observation serveur et possession conservée après retrait du stock.
+Les tests de stockage passent. Les [preuves et limites](testing-alpha23.md)
+détaillent le protocole, l’artefact et son empreinte. Alpha.23 assemblée localement ;
+publication du MRpack et mise à jour du canal demandées, en préparation.

docs/boat-collisions-beta065.md

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

docs/boat-passengers-beta091.md

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

docs/boats-head-beta049.md

@@ -0,0 +1,82 @@
+# beta.049 — bateaux rectangulaires et blocs portés
+
+Branche `codex/rectangular-boats-beta049`.
+
+## Contrat
+
+Quatre formats supplémentaires, largeur × longueur : 3 × 1, 1 × 3,
+2 × 3 et 3 × 2. Les recettes reprennent exactement cette disposition dans
+l'établi, avec uniquement des bateaux ordinaires identiques du même bois.
+Les onze bois natifs sont couverts : 44 variantes ajoutées, 66 au total.
+Les noms reprennent le bois suivi des dimensions, en français et en anglais.
+Les plans rejoignent aussi une collection Bateaux et radeaux déjà acquise.
+
+Chaque module accueille deux passagers, joueur ou animal. On remplit d'abord
+les places principales de tous les modules, puis leurs places secondaires.
+Cela donne 6 places en 3 × 1 et 1 × 3, 8 en 2 × 2, 12 en 2 × 3 et 3 × 2,
+et 18 en 3 × 3. Les deux sièges sont décalés de 0,8 bloc dans le même module.
+Les fonds natifs sont répétés, avec rebords uniquement
+à l'extérieur et deux rames. Les commandes, moteurs et piles de beta.048 sont
+conservés. Le supplément de masse est `(largeur + longueur − 2) × 0,25` :
+les carrés conservent exactement leur équilibre, et tourner une recette
+rectangulaire ne change pas sa puissance. Les limites de collision des nouveaux
+rectangles suivent leur orientation.
+
+## Blocs sur la tête
+
+- Les sons natifs incluent le joueur qui actionne le bloc, le porteur et les
+  joueurs proches. Une seule diffusion serveur ; les blocs posés conservent
+  leur mécanisme de prédiction habituel.
+- L'apparence reçoit l'état natif du bloc et les informations visibles du feu
+  de camp, du pupitre et du pot décoré. Les aliments en cuisson deviennent
+  visibles. Les événements d'ouverture et de fermeture des coffres sont transmis.
+- Les modèles natifs des blocs avec rendu spécial sont utilisés. Les bateaux
+  ordinaires et collectifs disposent aussi de leur modèle 3D comme chapeau.
+- Les façades des fours et les têtes sont tournées vers l'avant du personnage.
+  La transformation commune conserve le haut des modèles vers le haut.
+- Un coup infligeant des dégâts produit dix ticks de signal redstone local.
+  Distributeurs, droppers, lampes et autres récepteurs natifs réagissent à ce
+  signal. Une trémie respecte sa règle native : un signal la verrouille
+  temporairement. Le piston s'étend et se rétracte localement, sans pousser le
+  terrain. La TNT garde son amorçage réel déjà existant.
+
+Les cosmétiques bateaux restent des modèles portés ; ce ticket ne crée pas un
+second véhicule pilotable sur la tête. Les conditions des blocs fonctionnels
+et les règles de restitution de beta.043 restent applicables.
+
+## Données et limites
+
+Les anciens identifiants, bateaux et formats de sauvegarde restent stables.
+La forme des nouveaux bateaux est portée par leur identifiant enregistré.
+Les informations de rendu passent dans la synchronisation d'apparence existante,
+pas dans une copie récupérable de l'inventaire. Les coffres et les fours ne
+transmettent pas leur stockage à tous les observateurs. Aucun monde personnel
+ni chunk existant n'est modifié par cette livraison.
+
+Les animations de rendu sont limitées aux fonctions de présentation natives ;
+un modèle client ne simule pas un second bloc fonctionnel. Les sources d'énergie
+et les circuits environnants ne deviennent pas un réseau mobile de redstone.
+
+## Vérification
+
+`./gradlew check build :sanctuary:runGameTest assemblePack assembleTestPack`
+réussit avec les groupes `boatshead,poultry,headblocks,cosmetics` : **35 tests
+serveur**. Les 66 recettes sont fabriquées, leurs ingrédients mixtes refusés,
+les capacités complètes et les passagers sauvegardés/rechargés. Les sièges
+principaux précèdent les secondaires. Les paquets natifs de son contiennent
+une diffusion sans exclusion pour la trappe portée, tout en gardant l'exclusion
+vanilla sur un bloc normal. Les aliments, états, retrait des inventaires,
+impulsions, extinction de lampe et amorçage unique de TNT sont contrôlés.
+
+Le parcours client natif FR/EN passe : 66 modèles par tuiles, vol des quatre
+rectangles via les touches réelles, aliments du feu de camp, ouverture/fermeture
+de coffre et Shulker, animation de cloche avec fin, et bateaux comme chapeaux.
+Les captures des têtes et fours ont été relues : façades vers l'avant, haut des
+modèles conservé. Preuves dans `build/boats049-evidence/` ; logs
+`build/boats049-delivery.log` et `build/boats049-client-final.log`.
+
+Le reçu `build/boats049-artifact.json` atteste 1 529 classes et leurs ressources
+conformes au build, les deux MRpacks, JEI et les textures conservées. Les archives
+beta.048 sont inchangées. Aucun déploiement personnel ni publication du canal.
+Une session avec deux clients distants n'a pas été relancée : le son a été
+vérifié au niveau de sa diffusion serveur native, puis le rendu en client local.

docs/build-mining-beta080.md

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

docs/build-reach-beta081.md

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

docs/building-beta009.md

@@ -0,0 +1,108 @@
+# PROG-02B — Construction et vein building — beta.009
+
+Branche : `codex/progression-vein-building`. Implémentation et export local
+vérifiés le 13 septembre 2026 ; parcours graphique encore non validé, voir
+ci-dessous. Cible : Minecraft 26.3-pre-2, Fabric et Java 25.
+
+## Contrat préalable de migration
+
+La progression personnelle passe du schéma 3 au schéma 4, en ajoutant
+`building: 0`. Les schémas 1 et 2 passent d'abord par leurs migrations strictes
+existantes. Les rangs, achats, dates, coûts, aptitudes et révisions sont
+conservés sans achat fictif. L'historique accepte sept achats Construction
+supplémentaires, soit 37 événements maximum ; chaque rang doit correspondre
+exactement à ses achats. Les données invalides sont refusées sans remise à zéro.
+La migration est idempotente et conserve l'identifiant `sanctuary:progression`.
+La restauration réattache la représentation canonique, ensuite enregistrée par
+la sauvegarde Minecraft normale. Mort, reconnexion et redémarrage conservent
+les rangs. Aucun New Game+ n'est activé.
+
+Les fichiers de configuration restent au schéma 2 : Construction utilise les
+sept `statCosts`, par défaut 1, 2, 4, 8, 16, 32 et 64 niveaux. Aucun changement
+des profils, couleurs, Atlas, Demeure, inventaire, génération ou chunks existants.
+Client et serveur doivent utiliser beta.009 ensemble. Les versions antérieures
+ne lisent pas le schéma 4 ; revenir en arrière exige une sauvegarde antérieure
+des données de joueur. Aucun monde personnel n'est ouvert ou modifié ici.
+
+## Contrat de jeu et valeurs d'essai
+
+- Rang 0 : pose Minecraft individuelle. Sept achats débloquent les diamètres
+  3, 5, 7, 9, 11, 13 et 15 (jusqu'à 225 emplacements dans un plan).
+- La portée de visée et d'attaque reste celle de Minecraft. Seul le plan autour
+  du point de départ s'agrandit ; aucune portée d'attaque supplémentaire.
+- Une pose tous les deux ticks en survie ; lots bornés en créatif. Le statut
+  opérateur en survie n'accorde ni matériaux gratuits ni cadence créative.
+- R est la touche commune configurable : avec un bloc en main, aperçu de
+  construction ; R + clic droit maintenus posent, R + molette règle le diamètre.
+  R + clic gauche reste le minage. B reste le Blocodex.
+- Plan déterminé par la face visée et l'orientation du joueur, ordre du centre
+  vers l'extérieur. Le serveur recalcule et revalide les cibles, le stock et les
+  permissions. Relâcher, changer d'objet, ouvrir un menu, mourir, s'éloigner ou
+  perdre la connexion arrête le geste ; les poses déjà effectuées restent.
+- Les poses passent par le placement natif pour les orientations, supports,
+  collisions, contenus d'objets, consommation, statistiques et traces Demeure.
+  Aucune récompense pour l'aperçu ou une pose refusée. Les surfaces ne remplacent
+  pas les blocs occupés et n'ouvrent pas les contenants servant de support.
+  Une dalle peut être fusionnée par son contexte Minecraft natif.
+- Le plan couvre les emplacements dont le support existe déjà, comme le Builder
+  historique. L'aperçu ne dessine que les poses valides ; il ne coûte aucun objet.
+  La pile tenue fournit les matériaux, sans réapprovisionnement automatique.
+- Portes, lits et plantes doubles gardent la pose individuelle, pour ne pas
+  modifier une seconde case hors du plan validé. Échafaudages et nénuphars aussi :
+  leurs placements natifs recherchent une autre cible. Les contextes déplacés
+  et chunks non chargés sont refusés avant tout placement groupé.
+
+## Vérifications
+
+- `./gradlew :sanctuary:compileGametestJava check build assemblePack -PsanctuaryFocusedTests=progression,map,demeure,mining,building`
+  **réussi en 3 min 55 s**, avec **28 tests serveur natifs obligatoires réussis**,
+  dont dix scénarios Construction. Journal : `build/beta009-delivery-complete.log`.
+- Les contrôles purs relisent les schémas 1, 2 et 3 et vérifient l'idempotence,
+  les dates/coûts/rangs conservés, sept achats Construction, plafond et refus
+  d'un rang sans historique. La configuration reste au schéma 2.
+- Les tests serveur vérifient le passage par le placement natif, les six faces,
+  les quatre orientations, les plans de 225 cases sans doublon, les coûts,
+  l'absence d'extension de portée, les stocks courts, le créatif, les dalles
+  simples/doubles/hautes et les escaliers. Les collisions avec un animal,
+  contenants occupés, droits Fabric, mutation pendant un callback, concurrence,
+  interruption et expiration du maintien sont couverts. Les statistiques,
+  Blocodex et contributions Demeure proviennent des poses confirmées.
+- Le test de progression sauvegarde/recharge le joueur et copie ses achats,
+  dont Construction, lors d'une mort ordinaire. Le contrat de reprise est
+  contrôlé sans ouvrir un monde personnel.
+- Le parcours client `Building009ClientChecks` est écrit et compilé : achats
+  par clic, aperçus 25/9, molette, arrêt, consommation, une seule couche par
+  geste, reconfiguration et interruption par le Blocodex. **Son exécution
+  reste non validée** : les deux lancements se sont bloqués avant le monde
+  dans `Minecraft.<init>` / `SDL_GL_SwapWindow`. Le contrôle de bureau a
+  confirmé que le Mac était verrouillé. Aucun résultat graphique beta.009
+  ni capture en jeu n'est revendiqué. Les processus de test ont été arrêtés ;
+  la valeur VSync du dossier de développement a été remise à sa valeur initiale.
+  Journaux : `build/beta009-client.log`, `build/beta009-client-retry.log` ;
+  piles : `build/beta009-client-threads.txt`, `build/beta009-client-retry-threads.txt`.
+
+La sélection des tests serveur est limitée à
+`progression,map,demeure,mining,building` ; ce ticket ne revendique pas la
+correction des deux anciennes assertions de génération générales.
+
+Référence historique en lecture seule : sélection, plan et session de
+construction dans `../26.2/sanctuary`, GPL-3.0-or-later. Les appels natifs sont
+vérifiés dans les classes de Minecraft 26.3-pre-2, dont `BlockItem.place`,
+`ItemStack.useOn` et `ServerPlayerGameMode.useItemOn`. Le mixin commun contourne
+seulement l'interaction du support comme le fait la pose accroupie ; les hooks
+Fabric, le placement, les contenus d'objets, coûts et critères Minecraft restent
+actifs. La revalidation a lieu après les callbacks et avant l'usage de l'objet.
+
+## Artefact local
+
+- [Sanctuary-beta.009.mrpack](../build/Sanctuary-beta.009.mrpack), **2 360 956 octets**.
+- SHA-256 : `efa1ac7974b16e2f6169149518e08ed2bca4371b386b3413850b08618392da21`.
+- Reçu : `build/building009-artifact.json` ; somme séparée :
+  `build/Sanctuary-beta.009.mrpack.sha256`.
+- ZIP et JSON vérifiés, identité du JAR construit et du JAR Demeure embarqué,
+  versions internes, classes/mixins Construction, traductions FR/EN, six icônes
+  originales, hash Fabric API et index packwiz. Aucune classe de test embarquée.
+  Les exports beta.003 à beta.008 sont restés strictement identiques.
+
+L'artefact est disponible pour essai local. Le canal packwiz n'a pas été publié
+et aucune instance personnelle n'a été synchronisée.

docs/capes-gameplay.md

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

docs/carried-flight-panic-beta114.md

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

docs/carry-babies-beta041.md

@@ -0,0 +1,42 @@
+# beta.041 — bébés portés sans ralentissement
+
+Branche `codex/carry-babies-beta041`. Règle retenue : porter un bébé mob ne
+ralentit pas le porteur. La précision demandée à l'utilisateur reste ouverte ;
+cette interprétation est annoncée pendant le travail.
+
+Les bébés natifs ne contribuent plus au poids de la pile. Les autres passagers
+gardent un facteur de 0,75 chacun, avec le plancher global existant de 25 %.
+Un joueur portant un bébé compte toujours lui-même lorsqu'il monte sur un
+autre joueur. Le bébé ne rajoute pas une seconde pénalité au joueur du bas.
+
+Les familiers utilisent l'âge de leur modèle natif : si celui-ci peut être
+affiché en bébé, le familier bénéficie de la même exemption. Une petite taille
+aléatoire ou un modèle adulte réduit ne suffit pas à devenir un bébé.
+La vérification réutilise le modèle natif déjà mis en cache pour les sons ;
+aucune entité supplémentaire n'est ajoutée au monde ou animée côté serveur.
+
+Le calcul reste côté serveur et se remet à jour au prochain tick lorsqu'un
+animal grandit sur la tête. Prendre et déposer applique le changement
+immédiatement. Le portage, les collisions, le plané et les interactions gardent
+leurs règles existantes. Aucun identifiant, attachement ou format de sauvegarde
+n'est modifié.
+
+## Validation
+
+`./gradlew check build assemblePack assembleTestPack
+-PsanctuaryFocusedTests=carry,familiar,movement,corrections,familiarhit` réussit,
+avec **43 tests serveur natifs**. Les scénarios couvrent le bébé dans une pile
+de joueurs, la croissance sans dépose, le retour au statut bébé, les familiers
+vache/zombie et le dragon adulte réduit ; les anciens tests de poids, cumul de
+modificateurs, démontage, plané et réaction aux coups passent également.
+
+Les deux MRpacks correspondent aux 1 441 classes compilées. Seules les classes
+de CarryService et FamiliarEntity diffèrent de beta.040 ; les 173 PNG et les
+ressources client sont identiques. Aucun nouveau parcours graphique ou test de
+connexion réseau dédié : les résultats client de beta.040 restent consignés
+dans son reçu. Aucune acceptation d'EULA, installation personnelle ou
+publication du canal. Les exports beta.039 et beta.040 restent immuables.
+
+Exports : [pack normal](../build/Sanctuary-beta.041.mrpack) ·
+[profil plat rapide](../build/Sanctuary-Test-beta.041.mrpack).
+Preuves locales : `build/carry041-check.log`, `build/carry041-artifact.json`.

docs/cartographie-open-source.md

@@ -0,0 +1,73 @@
+# Cartographie — pistes MIT et GPLv3
+
+Relevé du 13 septembre 2026, demandé après la décision d'attendre Xaero.
+Sources : métadonnées et versions officielles Modrinth, README et fichiers
+LICENSE des dépôts liés par les auteurs. **Aucun mod installé, forké, compilé
+ou testé en jeu pendant cette étude.**
+
+## Pistes retenues pour comparaison
+
+| Projet | Licence du projet vérifiée dans les sources | Version Fabric 26.2 identifiée | Intérêt pour Sanctuary |
+| --- | --- | --- | --- |
+| [Improved Maps](https://modrinth.com/mod/improved-maps) | [MIT](https://github.com/craftycorvid/ImprovedMaps/blob/main/LICENSE) | `1.0`, ID `kS9puVhR`, 21 août 2026 | Atlas géré côté serveur, copie des cartes pour les transmettre ; minimap et grand atlas avec le complément client. |
+| [Simple Atlas](https://modrinth.com/mod/simple-atlas) | [MIT](https://github.com/RubberToe-06/simple_atlas/blob/master/LICENSE) | `1.2.0`, ID `6Hy4rXil`, 18 juin 2026 | Grande carte interactive, marqueurs, dimensions et fusion/copie d'atlas ; pas de minimap HUD annoncée dans les fonctions consultées. |
+| [Ultimate Map Atlases](https://modrinth.com/mod/ultimate_map_atlases) | [GPLv3](https://github.com/nanakytim/Ultimate_Map_Atlases/blob/main/LICENSE), Modrinth : `GPL-3.0-only` | `26.2`, ID `bgd39YOI`, 17 juin 2026 | Minimap et carte fondées sur les cartes vanilla, atlas ouvrable/fermable et boussole influençant son affichage. |
+| [BlueMap](https://modrinth.com/plugin/bluemap) | [MIT](https://github.com/BlueMap-Minecraft/BlueMap/blob/master/LICENSE) | `5.24-fabric`, ID `xvccCRD9`, 10 septembre 2026 | Carte 3D pour navigateur et site ; composant complémentaire, pas une minimap de jeu. |
+
+Pour **chacun de ces quatre projets**, le filtrage des versions publiées par
+Fabric + Minecraft `26.3-pre-2` renvoie **zéro version déclarée** au moment du
+relevé. Une build 26.2 ne constitue pas une preuve de fonctionnement sur la
+cible actuelle. Les pages générales peuvent décrire des fonctionnalités plus
+récentes que certains binaires : vérifier le tag et le JAR retenus avant code.
+
+## Lecture pour Sanctuary
+
+**Improved Maps est la première piste à étudier si nous revenons à un fork
+libre** : il réunit déjà minimap, grand atlas et cartes transmissibles. C'est
+une appréciation de conception fondée sur les fonctions annoncées, pas un
+résultat de test. Ses états sont liés à un objet atlas et aux cartes vanilla,
+pas encore à l'identité et aux aptitudes Sanctuary. Les marqueurs personnels,
+la séparation des trois aptitudes et l'ouverture sans objet depuis le Blocodex
+restent à vérifier ou développer.
+
+Simple Atlas est intéressant pour les marqueurs et la circulation de cartes.
+Ultimate Map Atlases est une autre base possible pour une approche diégétique
+où l'atlas s'ouvre et se ferme. Dans les deux cas, distinguer les découvertes
+du joueur des cartes contenues dans un item partagé.
+
+Ces trois solutions reposent sur les cartes vanilla : vérifier le rendu des
+îles flottantes, surfaces superposées, dimensions, performances et niveaux de
+zoom avant de les choisir comme remplaçant de Xaero. Leur licence principale
+ne suffit pas à valider toute la pile : Improved Maps annonce Polymer (LGPLv3)
+et Fabric API, Simple Atlas déclare Cloth Config (LGPLv3) dans sa version
+26.2 ; Ultimate Map Atlases ne déclare pas de dépendance dans cette fiche
+de version, ce qui ne prouve pas qu'il n'en a aucune à l'exécution.
+
+BlueMap peut alimenter le futur site/Galactium avec des vues 3D. Il lit les
+données du monde ; ses cartes ne sont donc pas automatiquement limitées aux
+découvertes individuelles. Définir les zones et informations publiables avant
+tout raccordement aux secrets et à la progression. Aucun rendu de monde ni
+serveur web BlueMap n'a été lancé ici.
+
+## Faux équivalents écartés du filtre strict
+
+- **XaeroPlus** est MIT, mais requiert Minimap et World Map, qui restent
+  All Rights Reserved. Il ne remplace pas leurs moteurs.
+- **VoxelMap-Updated** expose un dépôt source, mais le projet Modrinth
+  déclare All Rights Reserved : il ne répond pas au filtre MIT/GPLv3.
+- **Antique Atlas 4** et **Surveyor** sont annoncés sous LGPL-3.0-or-later.
+  Ce sont des pistes libres, mais distinctes de GPLv3 et hors du filtre exact
+  demandé. La branche récente d'Antique Atlas 4 ne doit pas être confondue
+  avec l'ancien **Antique Atlas**, GPLv3, dont la dernière build Fabric
+  identifiée est `7.1.1-fabric-mc1.18.2`.
+- **Map Atlases [Forge]** est GPLv3 mais le relevé ne contient pas de build
+  Fabric ; ne pas le confondre avec les ports ou variantes portant un nom proche.
+
+## Preuves conservées
+
+`archives/web/references/open-maps-intake-2026-09-13.json` contient les projets,
+leurs licences déclarées, URLs des sources, IDs et dépendances des versions,
+résultats du filtre exact et empreintes des fichiers LICENSE vérifiés dans
+les quatre dépôts retenus. Le créateur a ensuite choisi une carte native Sanctuary :
+voir [MAP-01](atlas-beta005.md). Ce relevé reste une référence historique,
+sans substitution automatique dans Sanctuary.

docs/catalogue-progression-beta099.md

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

docs/clay-contrast-beta104.md

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

docs/clay-sculpture-grid-beta113.md

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

docs/clay-workshop-hotbar-beta112.md

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

docs/clay-workshop-integration-beta110.md

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

docs/clay-workshop-ui-beta111.md

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

docs/cloud-vortex-beta077.md

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

docs/collections-beta035.md

@@ -0,0 +1,115 @@
+# RECIPES-035 — collections Minecraft jouables
+
+Branche `codex/collections-beta035`, base beta.034. Contrat tiré des
+[67 collections](collections-minecraft.md) et de leur
+[inventaire exhaustif](collections-minecraft-inventaire.md).
+
+## Contrat et reprise des habitants
+
+Les **2 042 recettes natives de Minecraft 26.3-pre-2** ont chacune leur collection
+principale. Les **126 advancements** ouvrent les familles du tableau : chaque
+advancement configuré suffit, sans achat du catalogue ni possession des ingrédients.
+Les collections de survie s’ouvrent également à la découverte d’un membre admissible
+ou d’une amorce. Comme depuis beta.024, « découverte » utilise les connaissances
+existantes : observation réelle d’un bloc, objet connu, inventaire ou statistiques
+natives. La lecture d’un plan ne crée jamais une découverte de son résultat ou de
+ses ingrédients. La fabrication manuelle reste libre.
+
+66 familles de survie et une référence technique sont livrées. La référence
+`sanctuary:technical_catalogue` n’a aucun déclencheur de survie et ne s’ajoute pas
+au carnet personnel, même avec un œuf de familier. Les blocs sans objet et les
+blocs non récupérables (bedrock, générateurs, cadres de portail, etc.) ne sont pas
+transformés en amorces d’inventaire. Les familles sans recette peuvent être
+connues sans produire un faux gain de plans.
+
+**Migration additive sans changement de format :** la pièce jointe
+`sanctuary:recipe_knowledge` reste en schéma 1 ; aucun champ de sauvegarde n’est
+ajouté, supprimé ou réinterprété. Au prochain chargement de leur carnet, les
+habitants reçoivent les compléments correspondant à leurs collections déjà
+ouvertes, objets connus et advancements déjà accomplis. Tous les identifiants et
+recettes déjà appris restent conservés, même absents des nouvelles données.
+Aucun monde existant n’est ouvert ou réécrit par la livraison.
+
+`sanctuary:basic_wood` et `sanctuary:brewing` restent stables. Le bois conserve son
+ancien tag `minecraft:planks` et **40 recettes complémentaires** de bateaux et
+menuiseries du Nether ; les 170 recettes primaires restent classées séparément.
+L’alchimie conserve le sélecteur `minecraft:brewing`, y compris les recettes de ce
+type ajoutées par un datapack ou un mod, en plus de ses 286 recettes primaires.
+Cette compatibilité ne révèle pas les pistons ou les boucliers avec une planche.
+L’achat unique du catalogue reste à **4 niveaux**.
+
+## Données et consultation
+
+Les 67 JSON sont dans `data/sanctuary/sanctuary_recipe_collections/`. `recipes`
+contient le classement principal ; `additional_recipes` préserve les accès
+historiques. `items`, `item_tags` et `advancements` sont des portes alternatives.
+`members.blocks` / `members.items` conservent le classement exact des identifiants
+pour les futures fiches ; ces listes ne constituent pas des possessions requises.
+`operator_only` empêche une définition technique de devenir un déblocage personnel.
+
+Le chargement indexe objets, tags et advancements une fois par rechargement de
+ressources. Une collection déjà enseignée ne reparcourt pas ses recettes à chaque
+actualisation d’habitant. `/reload` renouvelle cet index et réconcilie une fois
+les carnets ; aucune recette déjà apprise n’est retirée.
+
+**Discovery → Recettes** affiche les noms FR/EN des collections connues. L’accès
+au catalogue reste en haut, avant la liste, afin que les nouvelles collections
+ne repoussent pas le bouton d’ouverture. Les notifications beta.034 signalent
+les collections nouvellement ouvertes et regroupent les lots ; les reconnexions
+ne rejouent pas l’historique.
+
+Les fiches détaillées d’obtention, le musée visuel de tous les blocs, les gestes
+sans recette (commerce, oxydation, croissance…), quêtes et bounties restent à
+concevoir. Aucune recette artificielle ni expansion de dimension n’est ajoutée.
+
+## Compléter le catalogue
+
+Modifier les deux documents de référence, puis exécuter :
+
+```sh
+python3 scripts/compile_collections.py --write
+python3 scripts/compile_collections.py
+```
+
+Le contrôle compare les deux directions advancement/collection, les 2 042 recettes
+uniques, les 1 815 identifiants distincts, les amorces, les définitions serveur et
+les noms FR/EN. Il est intégré à `check` ; les tests Minecraft confrontent ensuite
+ces identifiants aux registres et recettes réellement chargés. Le générateur ne
+télécharge rien et ne modifie ni les recettes natives ni les documents sources.
+
+## Vérifications et livraison
+
+`./gradlew check build assemblePack assembleTestPack` avec les suites
+`collections,recipes,notifications,progression,cycle` réussit : **28 tests serveur**.
+La matrice exerce les **126 advancements**, les 66 voies de découverte des familles,
+les identifiants des registres réellement chargés, les limites bois/machines,
+les amorces du lit, de l’alambic, du fabricateur et de la brosse, l’isolation des
+habitants et la reprise des carnets beta.034. Les 2 042 recettes primaires sont
+comparées à l’ensemble des recettes vanilla chargées, sans identifiant manquant.
+
+Le parcours client natif final réussit sur le profil plat : achat réel du
+catalogue, familles enseignées par advancement sans ingrédients, consultation
+effective des plans de Shulker, transfert depuis la sixième rangée, vue opérateur
+et révocation, notifications, rendu FR/EN après rechargement terminé, puis
+véritables New Game+, mort/respawn et redémarrage du serveur. Les nouvelles
+collections et le reçu du catalogue sont conservés dans ces trois passages.
+Les captures sont dans `build/collections035-evidence`.
+
+L’assemblage final après les vérifications client utilise `assemblePack
+assembleTestPack -x check`, sans répéter les tests serveur déjà passés. Les classes
+du moteur serveur correspondent à celles vérifiées ; ZIP, 1 322 classes Sanctuary,
+67 définitions, traductions, dépendances imbriquées et profil facultatif ont été
+comparés aux builds. JEI conserve exactement son binaire `30.32.0-sanctuary.2`.
+
+- [Sanctuary-beta.035.mrpack](../build/Sanctuary-beta.035.mrpack), pack normal.
+- [Sanctuary-Test-beta.035.mrpack](../build/Sanctuary-Test-beta.035.mrpack), profil plat rapide.
+
+SHA-256 normal : `dfcf5927eaef183fe582b95454480849a08353561cb66d83a514d8a0274b5c60`.
+SHA-256 test : `f94f216b5b09c7ebeafea45a8d735978a4efc354aa245ffbfd993ee7e6db2b24`.
+Reçu : `build/collections035-artifact.json`. Journaux :
+`build/collections035-check.log`, `build/collections035-client-final.log` et
+`build/collections035-assemble-final.log`.
+
+Client et serveur beta.035 ensemble, sur Minecraft 26.3-pre-2 / Loader 0.19.5 /
+Fabric API 0.160.0+26.3. Les exports antérieurs sont inchangés. Aucun canal de
+distribution, instance Prism personnelle ou monde existant n’a été modifié.

docs/colored-brick-walls-beta118.md

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

docs/colored-bricks-beta102.md

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

docs/colored-bricks-order-beta103.md

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

docs/colored-dynamic-beta140.md

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

docs/colored-lights-beta139.md

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

docs/combat-beta078.md

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

docs/community-beta154.md

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

docs/community-cards-beta158.md

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

docs/community-contract-v1.md

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

docs/community-search-beta159.md

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

docs/companion-powers-balance-proposal.md

@@ -0,0 +1,351 @@
+# Familiers — proposition d’équilibrage v1
+
+Une [proposition v2 du 14 septembre 2026](spawn-eggs-refonte-v2.md) reprend
+la fréquence d’usage, la complémentarité avec les potions et les combinaisons
+libres entre joueurs. Elle reste documentaire et non implémentée ; cette v1
+conserve son rôle de référence de la première implémentation.
+
+Passe de conception du 13 septembre 2026, pour les **88 œufs Minecraft de
+26.3-pre-2** présents dans Sanctuary. Les cinq raretés sont : **commun, peu
+commun, rare, extraordinaire, légendaire**.
+
+**Première implémentation dans [beta.019](companion-powers-beta019.md), à éprouver.**
+Les [ajustements beta.020](familiar-interactions-beta020.md) remplacent les limites
+v1 de perception et de téléportation à travers les murs, et corrigent le freinage
+des chutes. Cette proposition reste la référence initiale pour les essais ;
+elle ne constitue pas un équilibrage déjà démontré. Les pouvoirs restent désactivés
+dans beta.018. L’[inventaire historique](companion-powers-inventory.md) conserve
+les anciennes définitions de 26.2 ; ce document propose de les remplacer.
+Les 25 anciennes variantes ItsAlive restent hors de cette première passe :
+elles ne font pas partie du pack actuel.
+
+## Intention
+
+Chaque familier donne **un passif identifiable et un actif qui change un geste
+de jeu**. Un œuf commun doit pouvoir rester un choix de fin de partie. La rareté
+décrit la difficulté d’obtention et l’ampleur de l’intervention ; elle ne doit pas
+devenir un multiplicateur général de dégâts, de vie ou de rendement.
+
+On part de trois cœurs, trois barres de faim et trois bulles de respiration.
+Les familiers complètent les compétences et les aptitudes. Ils ne donnent pas
+de rang d’inventaire, de tri gratuit, de nage rapide sans Nage, de carte complète,
+de recettes inconnues, de minage groupé au-delà du rang acheté ou de vol permanent.
+Les anciens bonus permanents Force II, Résistance II, respiration aquatique
+illimitée, régénération gratuite et trêve générale avec les monstres disparaissent.
+
+| Rareté | Place dans le jeu | Obtention proposée | Recharge habituelle |
+|---|---|---|---|
+| Commun | Un geste quotidien devient plus agréable ; une petite manœuvre utile. | Découverte et premier objectif lié à l’espèce. | 20–60 s |
+| Peu commun | Une spécialité nette : potager, plongée, troupeau, déplacement, protection. | Quelques objectifs différents et une offrande adaptée. | 30–75 s |
+| Rare | Un véritable outil de métier ou une action tactique marquante. | Expédition, maîtrise d’une activité ou petite quête propre au mob. | 40–100 s |
+| Extraordinaire | Une capacité qui transforme brièvement une situation, parfois en groupe. | Défi important, lieu spécifique et composant difficile à obtenir. | 60–150 s |
+| Légendaire | Un moment exceptionnel, visible et préparé, avec une identité forte. | Aboutissement d’une grande aventure ; déblocage collectif puis épreuve personnelle. | 180 s |
+
+Les chiffres de recharge ci-dessous priment sur ces fourchettes. La rareté de
+l’œuf est indépendante de la fréquence d’apparition naturelle du mob : un
+Creeper peut être courant dans le monde et son lien de familier être rare.
+La répartition couvre **22 communs, 22 peu communs, 25 rares, 16 extraordinaires
+et 3 légendaires**. Ces nombres ne sont pas des probabilités de tirage :
+l’obtention proposée passe par des objectifs identifiés, pas par une loterie.
+
+## Règles communes proposées
+
+### Équipement, coût et rythme
+
+- Un seul familier équipé, donc un seul passif et un seul actif. Le passif prend
+  effet après 10 secondes avec le même œuf. Les améliorations temporaires qu’il
+  donne cessent au déséquipement ; cela ne supprime pas les objets déjà déplacés
+  ou les blocs déjà construits légitimement.
+- Une aptitude générale **Lien actif**, proposée à **4 niveaux**, ouvre la touche
+  de pouvoir configurable. Les passifs viennent avec le familier. La rareté
+  n’ajoute pas une série de taxes en XP. Ce nom et ce prix sont implémentés dans beta.019 ; G est proposé par défaut
+  et reste reconfigurable.
+- La recharge appartient au joueur et au slot de familier : utiliser un actif
+  bloque tous les autres jusqu’à la fin de cette recharge. Changer d’œuf, mourir,
+  se reconnecter ou passer en New Game+ ne la réinitialise pas. Les échéances
+  utilisent le temps réel du serveur et sont conservées ; le temps hors ligne
+  peut s’écouler normalement. Les effets actifs, eux, ne travaillent pas hors ligne.
+- Pas de barre de mana supplémentaire ni de coût de faim uniforme. Les dépenses
+  sont indiquées : ingrédients, lait, munition, durabilité ou faim pour un soin.
+  Une action impossible ne consomme rien et ne lance pas la recharge. Une action
+  réellement déclenchée, même esquivée, dépense ses ressources et sa recharge.
+- Aucun bonus de vie maximale, de faim maximale ou de taille de groupe miné/posé.
+  Les soins ne dépassent jamais la vie maximale. **Un cœur = 2 points de vie
+  (PV)** ; une demi-barre de faim = 1 point de nourriture.
+- Les bonus de vitesse continus et temporaires d’un même familier ne se cumulent
+  pas : prendre le plus fort. Une impulsion ponctuelle reste limitée par sa
+  distance annoncée. Une plateforme ou suspension de familier ne constitue pas
+  un nouvel appui pour relancer un pouvoir aérien.
+- Un bonus de respiration ralentit la consommation d’air, sans remplir la jauge.
+  Une réserve d’air active ajoute seulement la quantité annoncée, plafonnée à
+  la capacité achetée. Les déplacements aquatiques restent lents sans Nage.
+- Un déplacement respecte les collisions et les zones autorisées. Pas de traversée
+  d’une paroi, de porte fermée ou d’un accès réservé. Une capacité de sauvetage
+  n’immunise pas contre la lave, le vide ou une chute ultérieure.
+
+### Production, progression et informations
+
+- Le compagnon invincible reste sans collision et n’est pas une cible qui absorbe
+  les attaques. Il ne combat, ne récolte, ne pond, ne se reproduit et ne produit
+  aucune ressource de manière autonome.
+- Un actif de récolte transforme ou ramasse uniquement des ressources réelles.
+  Plantation, construction et carburant utilisent le stock du joueur ; les outils
+  perdent leur durabilité. Une case d’inventaire verrouillée reste inutilisable.
+- Les plafonds de récolte ne cumulent pas un deuxième groupe avec le vein mining.
+  Un actif exécute soit son geste spécialisé, soit le geste groupé normal. Les
+  outils requis, protections, portées et limites de compétences restent applicables.
+- Les gains de rendement plafonnent à **+10 % au total**, y compris le favori et
+  les autres futurs systèmes. Pas de bonus aux minerais, au butin de mort, à l’XP,
+  aux charges de faction, aux monnaies rares ou aux probabilités d’œufs.
+- Un bonus de production se valide sur un cycle complet avec le même propriétaire
+  et le même familier. Un seul bonus par culture, animal ou machine et par cycle :
+  équiper au moment de récolter, multiplier les joueurs ou casser/reposer ne crée
+  pas de nouveau droit. Chaque cycle reste traçable côté serveur.
+- Un repérage aide à chercher dans les chunks déjà chargés ; il ne charge pas de
+  terrain distant. Il ne révèle ni coffres privés, ni contenu de coffres fermés,
+  ni identité ou position précise d’un joueur caché, ni secret du scénario. Les marqueurs temporaires de pouvoir
+  restent locaux au monde : ils ne débloquent aucune fonction de l’Atlas.
+- Les filtres par objet ou espèce ne proposent que les découvertes personnelles.
+  Un sonar peut signaler une présence anonyme, sans révéler son nom ou compléter
+  une entrée du Blockodex à travers un mur.
+
+### Combat et coopération
+
+- Les dégâts annoncés sont **par cible, avant protection, en PvE**. Les coups
+  respectent les immunités et fenêtres d’invulnérabilité natives : pas de double
+  impact caché par tick. Les dégâts viennent du joueur, jamais d’une IA invincible.
+- Les bonus offensifs passifs concernent les monstres, pas les autres joueurs.
+  En PvP, les interventions offensives viennent des actifs annoncés ci-dessous.
+- En PvP, les dégâts additionnels de familier sont plafonnés à **2 PV par cible
+  pour toute l’activation**, y compris projectiles, zones, poison et dégâts différés.
+  Les dégâts d’une arme utilisée normalement restent ceux de l’arme ; seul son
+  supplément de familier entre dans ce plafond. Aucune pénétration d’armure en PvP.
+- La visibilité et les droits du joueur sont vérifiés au déclenchement et à
+  l’impact. Pas d’explosion qui casse le terrain, d’incendie propagé, d’attaque à
+  travers une paroi ou de commande opérateur. Les boss résistent aux déplacements
+  forcés et aux entraves, mais prennent les dégâts permis par leurs règles natives.
+- Les ralentissements PvP sont limités à **20 % et 2 secondes** ; pas d’immobilisation
+  ni d’aveuglement d’un joueur. Après une entrave de familier, une cible est protégée
+  des nouvelles entraves de familiers pendant 6 secondes. Les déplacements forcés
+  d’un joueur ne dépassent pas 1 bloc ; leurs dégâts de chute attribuables au pouvoir
+  entrent dans le plafond PvP. À défaut de cette attribution fiable, on désactive
+  la poussée PvP au premier portage.
+- Les tirs et charges ont un signal perceptible d’au moins 0,5 seconde ; les actifs
+  légendaires annoncent leur départ durant 1,5 à 2 secondes. On peut esquiver,
+  interrompre une canalisation en blessant son auteur ou se mettre à couvert.
+- Les soins et déplacements de groupe concernent le propriétaire et des alliés
+  consentants, jamais des inconnus déplacés de force. Un même buff ne se cumule pas
+  entre familiers. Un soin, rechargement ou suspension de consommation d’air impose à son bénéficiaire une
+  récupération égale à la recharge du pouvoir reçu, pour empêcher les rotations
+  de soigneurs et les échanges entre espèces. Cette récupération est commune à
+  tous les familiers pour chaque famille d’effet : soin d’un côté, air de l’autre.
+  Elle est conservée à la reconnexion et au prestige. Les bonus de réduction de dégâts venant des familiers plafonnent à
+  25 %, sauf le coup unique explicitement protégé par une garde.
+- Les effets de peur ne fonctionnent que sur les petits monstres ordinaires,
+  pendant au plus 2 secondes sur un monstre déjà engagé. Aucun raid ou boss ne se
+  désactive. Une cible effrayée bénéficie ensuite de 10 secondes de répit.
+
+## Commun — gestes quotidiens et premières aventures
+
+| Familier | Passif | Actif proposé | Recharge |
+|---|---|---|---|
+| Chauve-souris (`bat`) | **Adaptation obscure** : après 3 s immobile dans l’obscurité, les surfaces visibles s’éclaircissent légèrement ; aucune vision à travers la roche. | **Écho** : pendant 6 s, indique la direction de trois présences vivantes maximum à 12 blocs ; aucune identité ni position précise derrière une paroi. | 30 s |
+| Chat (`cat`) | **Pattes de velours** : −20 % de dégâts de chute. | **Feulement** : repousse jusqu’à trois Creepers ou Phantoms à moins de 5 blocs et les fait hésiter 2 s ; aucune immunité ensuite. | 45 s |
+| Poule (`chicken`) | **Petites ailes** : la distance de chute tolérée augmente de 1 bloc. | **Battement** : ralentit la descente pendant 2 s, sans remonter et sans effacer la chute déjà accumulée. | 30 s |
+| Morue (`cod`) | **Petites branchies** : l’air diminue 10 % moins vite. | **Dernière bulle** : rend une bulle d’air ; utilisable seulement dans l’eau, sans dépasser la capacité achetée. | 45 s |
+| Vache (`cow`) | **Lait sélectif** : boire du lait conserve les effets bénéfiques. | **Lait partagé** : consomme un seau de lait, rend le seau vide et retire Poison/Faim au porteur et à deux alliés consentants à 3 blocs. | 60 s |
+| Âne (`donkey`) | **Pas chargé** : −10 % d’épuisement dû au sprint. | **Déchargement** : transfère au plus 18 piles existantes vers le coffre visé à portée normale, seulement des types déjà présents ; hotbar et équipement exclus. | 30 s |
+| Renard (`fox`) | **Approche discrète** : −15 % de distance de détection initiale par les animaux sauvages fuyants. | **Plongeon** : petit bond horizontal de 3 blocs, puis ramasse une pile visible à l’arrivée si une case est disponible. | 25 s |
+| Grenouille (`frog`) | **Berges faciles** : se déplacer au sol dans un bloc d’eau peu profonde est 10 % plus rapide ; ne débloque pas la nage. | **Langue** : attire une pile d’objets visible à 6 blocs ; peut aussi attirer d’un bloc un petit monstre ordinaire, sans dégâts. | 20 s |
+| Cheval (`horse`) | **Cavalier** : +10 % de vitesse à une monture terrestre réellement chevauchée, sans améliorer son saut. | **Galop** : +25 % de vitesse terrestre pendant 4 s, monté ou à pied ; exige la faim nécessaire au sprint. | 35 s |
+| Lama (`llama`) | **Caravanier** : les laisses du joueur tolèrent 2 blocs supplémentaires avant rupture. | **Crachat** : projectile à 10 blocs, 1 PV et ralentissement de 15 % pendant 2 s ; une seule cible. | 25 s |
+| Mule (`mule`) | **Sentier sûr** : −20 % de recul reçu en chevauchant une monture. | **Chargement** : transfère au plus 9 piles de stockage vers l’inventaire de sa monture visée, à 3 blocs ; aucune case ni capacité ajoutée. | 30 s |
+| Cochon (`pig`) | **Bon appétit** : +10 % de saturation obtenue avec carottes, betteraves et pommes de terre cuites ; aucun point de faim supplémentaire. | **Fouille** : indique durant 10 s jusqu’à trois végétaux récoltables déjà connus à 16 blocs, sans générer de truffe ou de butin. | 40 s |
+| Lapin (`rabbit`) | **Pied léger** : +10 % de vitesse en position accroupie. | **Bond** : saut dirigé jusqu’à 2 blocs de haut ou 3 blocs de long ; aucun enchaînement aérien. | 25 s |
+| Saumon (`salmon`) | **À contre-courant** : −25 % de poussée subie par l’eau courante. | **Remontée** : impulsion verticale jusqu’à 3 blocs dans l’eau ; ne donne pas d’air et respecte le plafond de la surface. | 30 s |
+| Mouton (`sheep`) | **Laine isolante** : le gel de la neige poudreuse s’accumule 20 % moins vite. | **Coussin** : consomme une laine pour réduire de 50 % les dégâts du prochain atterrissage dans les 8 s ; réduction plafonnée à 2 PV. | 45 s |
+| Squelette (`skeleton`) | **Main stable** : l’arc reste précis en déplacement lent, avec dispersion réduite de 15 %, sans accélérer sa charge. | **Tir repère** : la prochaine flèche tirée dans les 8 s marque sa cible 6 s pour le tireur ; dégâts normaux, munition consommée, joueurs visibles seulement en ligne de vue. | 35 s |
+| Slime (`slime`) | **Souplesse** : −15 % de dégâts de chute et −15 % de ralentissement dans les blocs de miel. | **Rebond** : réduit de 50 % un atterrissage imminent, au plus 2 PV, puis rebondit de 2 blocs maximum ; expire après 4 s, une seule fois. | 40 s |
+| Araignée (`spider`) | **Prise ferme** : +15 % de vitesse sur les échelles et les lianes. | **Accroche** : adhère à la paroi visée pendant 4 s et peut y grimper de 2 blocs maximum ; pas d’escalade permanente ni de plafond franchi. | 35 s |
+| Poulpe (`squid`) | **Eau claire** : réduit légèrement le voile sous-marin, sans voir plus loin que les chunks chargés. | **Nuage d’encre** : échappe 2 s à la détection de monstres aquatiques non-boss à 4 blocs ; contre des joueurs, produit uniquement un nuage de particules lisible. | 45 s |
+| Têtard (`tadpole`) | **Reprendre haleine** : la jauge d’air se recharge 20 % plus vite à la surface, sans augmenter sa capacité. | **Retour à la rive** : indique pendant 10 s la berge praticable la plus proche dans un rayon de 16 blocs ; pas de téléportation. | 30 s |
+| Poisson tropical (`tropical_fish`) | **Œil du récif** : les coraux et herbiers déjà découverts contrastent mieux sous l’eau à moins de 8 blocs. | **Palette vivante** : repère durant 10 s jusqu’à trois variantes de coraux ou poissons déjà connues dans un rayon de 16 blocs, sans dévoiler les inconnues. | 40 s |
+| Zombie (`zombie`) | **Tenace** : lorsque la vie est sous 30 %, le recul reçu diminue de 20 %. | **Second souffle** : transforme 1 point de nourriture en 1 PV sur 5 s ; dégâts reçus ou attaque interrompent le soin, la nourriture est déjà dépensée. | 60 s |
+
+## Peu commun — une spécialité affirmée
+
+| Familier | Passif | Actif proposé | Recharge |
+|---|---|---|---|
+| Tatou (`armadillo`) | **Carapace réflexe** : après 5 s accroupi, le prochain projectile inflige 15 % de dégâts en moins ; le bénéfice expire dès la fin de l’accroupissement. | **En boule** : garde immobile de 3 s, −40 % sur le premier coup uniquement, réduction plafonnée à 2 PV ; attaquer ou bouger la rompt. | 45 s |
+| Abeille (`bee`) | **Pollinisateur** : +10 % de progression naturelle des cultures proches à 4 blocs, seulement durant la présence active du joueur. | **Butinage** : consomme jusqu’à 4 poudres d’os pour traiter jusqu’à 4 plantes accessibles distinctes ; chaque plante reçoit une application native, sans garantie de maturité. | 45 s |
+| Dromadaire (`camel`) | **Endurance du désert** : −15 % d’épuisement du sprint sur sable et sable rouge. | **Grande enjambée** : franchit un intervalle horizontal jusqu’à 5 blocs, depuis un sol stable ; pas de charge infinie au-dessus du vide. | 40 s |
+| Araignée venimeuse (`cave_spider`) | **Habitué au venin** : −20 % de durée des nouveaux poisons reçus. | **Morsure** : la prochaine frappe de mêlée dans les 6 s ajoute jusqu’à 2 PV de poison sur 4 s ; poison non létal. | 45 s |
+| Golem de cuivre (`copper_golem`) | **Lecture du circuit** : affiche le niveau de signal du composant de redstone directement visé à portée normale. | **Diagnostic** : pendant 10 s, colore les états alimentés de 32 composants maximum appartenant au circuit exposé visé, dans un rayon de 8 blocs ; aucun signal modifié. | 40 s |
+| Dauphin (`dolphin`) | **Nage accompagnée** : +10 % de vitesse de nage, uniquement avec l’aptitude Nage et la faim requise. | **Sillage** : laisse pendant 5 s un courant de vitesse +20 % pour le porteur et deux nageurs consentants à 4 blocs ; ne fournit pas d’air. | 50 s |
+| Noyé (`drowned`) | **Main sous l’eau** : réduit de 10 % la pénalité de vitesse de minage sous-marin, sans supprimer la pénalité ni modifier les groupes. | **Ancrage** : reste stable dans l’eau pendant 6 s malgré les courants ; peut miner à portée habituelle et continue à consommer de l’air. | 40 s |
+| Poulpe luisant (`glow_squid`) | **Lueur douce** : éclairage personnel des surfaces visibles à 4 blocs sous l’eau ; aucun changement du niveau lumineux serveur. | **Balise vivante** : pose pour 20 s une balise lumineuse non solide à un point visible à 8 blocs, partagée avec le groupe ; pas de découverte ou waypoint permanent. | 45 s |
+| Chèvre (`goat`) | **Sabots** : réduit de 20 % les glissades sur glace quand on est accroupi. | **Coup de corne** : charge de 3 blocs, inflige 2 PV à la première cible et la pousse de 2 blocs maximum en PvE ; collisions respectées. | 40 s |
+| Momifié (`husk`) | **Marche aride** : les effets de Faim reçus durent 20 % moins longtemps. | **Poussière** : une zone de 3 blocs gêne 3 monstres maximum, ralentis de 20 % pendant 3 s ; aucun aveuglement de joueur. | 50 s |
+| Ocelot (`ocelot`) | **Sous-bois** : +10 % de vitesse en position accroupie dans une végétation dense, sans traverser les feuilles solides. | **Esquive** : pas latéral de 3 blocs ; aucun instant d’invulnérabilité ni passage à travers une entité solide. | 30 s |
+| Panda (`panda`) | **Gourmandise ciblée** : manger une part de gâteau donne 10 % de saturation supplémentaire. | **Culbute** : roulade de 3 blocs sur terrain libre ; réduit de 25 % le premier dégât reçu durant la seconde du mouvement, au plus 1 PV. | 40 s |
+| Perroquet (`parrot`) | **Sentinelle** : imite un monstre découvert et visible qui entre dans les 10 blocs, avec au moins 15 s entre alertes. | **Imitation** : attire l’attention de trois monstres ordinaires non engagés vers un point visible à 8 blocs pendant 4 s ; aucune cible invincible persistante. | 45 s |
+| Poisson-globe (`pufferfish`) | **Immunité partielle** : −20 % de dégâts de poison, sans supprimer les autres effets. | **Hérissement** : pendant 5 s, la première attaque de mêlée reçue applique à son auteur 2 PV de poison maximum sur 4 s, non létal ; n’annule pas le coup reçu. | 50 s |
+| Ours blanc (`polar_bear`) | **Pelage polaire** : −20 % de dégâts de gel. | **Protection du petit** : pendant 5 s, le porteur ou un allié consentant à 4 blocs subit 25 % de dégâts de mêlée en moins ; un seul bénéficiaire. | 60 s |
+| Golem de neige (`snow_golem`) | **Pas d’hiver** : le joueur ne s’enfonce plus pendant la première seconde d’un contact avec la neige poudreuse ; le gel reste possible. | **Bourrasque** : lance trois boules de neige en éventail, ralentissement 20 % pendant 2 s au plus une fois par cible ; consomme trois boules de neige, dégâts natifs. | 35 s |
+| Arpenteur (`strider`) | **Pieds chauds** : −20 % de dégâts de contact avec le magma, aucune immunité à la lave. | **Pas de braise** : pendant 3 s, permet de marcher sur la surface de lave sur 5 blocs maximum ; ne protège pas une immersion ni la fin de l’effet. | 60 s |
+| Tortue (`turtle`) | **Apnée tranquille** : l’air diminue 15 % moins vite quand le joueur reste presque immobile dans l’eau. | **Abri** : garde de 4 s, −40 % sur le premier projectile reçu, réduction plafonnée à 2 PV ; déplacement ralenti de 30 %, attaque impossible pendant la garde. | 50 s |
+| Villageois (`villager`) | **Carnet du voisinage** : mémorise les offres déjà consultées, leurs prix et l’heure de consultation ; n’actualise pas un marchand éloigné. | **Commande groupée** : exécute jusqu’à trois échanges d’une offre choisie en un geste, au prix et dans le stock actuels, puis place les résultats dans les cases libres. Fournitures réelles, aucune réservation de case verrouillée, aucun bonus d’XP par échange. | 45 s |
+| Loup (`wolf`) | **Riposte de meute** : +10 % de dégâts de mêlée contre le dernier monstre qui a blessé le porteur, durant 6 s. | **Cible de meute** : désigne un monstre visible à 12 blocs pendant 8 s ; les animaux déjà apprivoisés et réellement présents du porteur le priorisent, sans bonus de dégâts ou d’invincibilité. Ne déclenche pas une attaque collective contre un joueur. | 45 s |
+| Embourbé (`bogged`) | **Pied de marais** : +10 % de vitesse sur boue et dans l’eau peu profonde, sans nage rapide. | **Flèche des marais** : la prochaine flèche dans les 8 s porte 2 PV de poison non létal maximum sur 4 s ; utilise une flèche et l’arc normalement. | 50 s |
+| Desséché (`parched`) | **Habitué à l’épuisement** : les nouveaux effets de Faiblesse durent 20 % moins longtemps. | **Trait épuisant** : la prochaine flèche dans les 8 s réduit de 15 % les dégâts de mêlée de sa cible pendant 4 s ; ne détruit pas sa nourriture. | 50 s |
+
+## Rare — des outils de métier et de vraies manœuvres
+
+| Familier | Passif | Actif proposé | Recharge |
+|---|---|---|---|
+| Allay (`allay`) | **Ramasseur choisi** : rayon de ramassage de 4 blocs pour le seul type d’objet tenu en main secondaire ; objets libres et accessibles seulement. | **Récolte musicale** : attire pendant 8 s jusqu’à 16 piles libres du type choisi à 8 blocs, autour du joueur ou d’un bloc musical visé ; aucun accès aux conteneurs. | 45 s |
+| Axolotl (`axolotl`) | **Convalescence aquatique** : les dégâts reçus de monstres aquatiques diminuent de 10 %. | **Soin de rive** : au contact de l’eau, consomme 1 point de nourriture pour rendre 1 PV au porteur ou à un allié consentant à 4 blocs, sur 4 s ; interruption aux dégâts. | 60 s |
+| Blaze (`blaze`) | **Chaleur entretenue** : +10 % de progression de cuisson d’un four déjà allumé à 4 blocs ; consomme le carburant 10 % plus vite, sans multiplier l’XP par objet cuit. | **Salve ardente** : trois projectiles esquivables répartissant au plus 4 PV par cible, portée 16 blocs ; pas de feu au sol ni de brûlure supplémentaire. | 60 s |
+| Breeze (`breeze`) | **Lecture du vent** : les charges de vent personnelles produisent 15 % de recul en moins sur le porteur ; pas de réduction générale des explosions. | **Pas de vent** : impulsion de 5 blocs horizontalement ou 3 blocs verticalement depuis un appui, puis 1 s de descente ralentie ; une seule impulsion. | 40 s |
+| Dromadaire momifié (`camel_husk`) | **Caravane nocturne** : −15 % d’épuisement dû au sprint la nuit sur terrain sec. | **Traversée** : ruée horizontale de 6 blocs depuis le sol, sans dégâts ; le ralentissement de terrain est ignoré 2 s, mais les collisions restent actives. | 50 s |
+| Creeper (`creeper`) | **Mèche sensible** : alerte sonore lorsqu’une TNT amorcée ou un Creeper en amorçage est visible à 8 blocs ; ne désamorce rien. | **Détonation maîtrisée** : après 1 s d’annonce, souffle de rayon 3 blocs, jusqu’à 4 cibles, 4 PV chacune et petit recul ; aucun bloc détruit ni explosion à la mort. | 75 s |
+| Endermite (`endermite`) | **Récupération de perle** : −20 % de dégâts subis lors d’une téléportation par perle d’Ender. | **Petit décalage** : téléportation de 3 blocs maximum vers un sol visible et libre ; ne franchit pas de paroi, aucune annulation d’une chute engagée. | 45 s |
+| Gardien (`guardian`) | **Écailles** : −10 % de dégâts de projectiles reçus sous l’eau. | **Rayon** : verrouillage visible de 1,5 s, puis 4 PV à une cible à 12 blocs ; couper la ligne de vue ou blesser le lanceur interrompt le tir. | 60 s |
+| Hoglin (`hoglin`) | **Carrure** : −20 % de recul en mêlée. | **Percussion** : charge de 4 blocs, 4 PV à la première cible, recul PvE de 2 blocs ; s’arrête contre un obstacle. | 55 s |
+| Cube de magma (`magma_cube`) | **Peau chaude** : les embrasements reçus durent 20 % moins longtemps, sans protéger de la lave. | **Bond brûlant** : saut de 3 blocs maximum ; l’atterrissage dans les 3 s produit une onde de rayon 2 blocs, 3 PV, trois cibles maximum, sans incendie. | 55 s |
+| Mooshroom (`mooshroom`) | **Cuisine fongique** : les ragoûts aux champignons consommés donnent 10 % de saturation supplémentaire. | **Bouillon réconfortant** : consomme un ragoût aux champignons et rend son bol ; le porteur et deux alliés consentants à 4 blocs récupèrent chacun 1 PV sur 5 s. Un dégât interrompt le soin du bénéficiaire concerné ; aucune nourriture ajoutée. | 90 s |
+| Nautile (`nautilus`) | **Réserve mesurée** : l’air diminue 15 % moins vite pendant un déplacement lent. | **Cloche de plongée** : suspend la consommation d’air pendant 6 s pour le porteur immobile sous l’eau ; ne remplit pas sa jauge, bouger ou attaquer interrompt l’effet. | 75 s |
+| Phantom (`phantom`) | **Vol de nuit** : −20 % de dégâts de chute pendant la nuit. | **Glissade nocturne** : plane en descente durant 4 s maximum, sans gain d’altitude ; l’usage nocturne porte la durée à 6 s. | 65 s |
+| Piglin (`piglin`) | **Habitué du troc** : mémorise la liste des résultats de troc déjà obtenus ; les résultats inconnus restent masqués. | **Choix du marchand** : pour un seul prochain troc dans les 20 s, consomme deux lingots d’or et propose deux tirages natifs ; garde un résultat et abandonne l’autre. Pas d’amélioration des poids de rareté. | 90 s |
+| Pillard (`pillager`) | **Arbalétrier** : −10 % de temps de chargement de l’arbalète, sans modifier les munitions ou l’enchantement Charge rapide. | **Tir de couverture** : le prochain projectile d’arbalète dans les 8 s crée à l’impact une zone d’hésitation de 2 blocs pendant 3 s ; trois monstres maximum ralentis de 20 %, dégâts du projectile normaux. | 50 s |
+| Poisson d’argent (`silverfish`) | **Lecture de la pierre** : après avoir visé 2 s un bloc de pierre à portée, signale s’il est infesté ; aucun minerai révélé. | **Fissure témoin** : montre pendant 8 s les faces de cavité directement derrière le bloc visé, profondeur 2 blocs maximum ; ne révèle ni contenu, ni minerai, ni structure protégée. | 50 s |
+| Cube de soufre (`sulfur_cube`) | **Décontamination** : les nouveaux effets de Poison et de Faiblesse durent 10 % moins longtemps. | **Projection corrosive** : projectile à 10 blocs, 3 PV et dégâts de mêlée de la cible réduits de 15 % pendant 4 s ; aucune armure détruite, aucune corrosion de blocs. | 60 s |
+| Lama de marchand (`trader_llama`) | **Inventaire de caravane** : affiche les places libres des montures du joueur réellement présentes à 8 blocs. | **Convoi** : rappelle jusqu’à trois de ses montures à 12 blocs vers une place visible proche ; elles marchent, ne se téléportent pas et ne traversent pas les obstacles. | 60 s |
+| Marchand ambulant (`wandering_trader`) | **Carnet de voyage** : garde les offres et emplacements de marchands déjà rencontrés, avec date ; aucune actualisation distante ou garantie de présence. | **Étal partagé** : pendant 30 s, un allié consentant à 16 blocs peut consulter et effectuer une transaction du marchand devant le porteur avec ses propres ressources ; les deux joueurs restent proches, le prix et le stock sont inchangés. | 90 s |
+| Cheval-zombie (`zombie_horse`) | **Longue route** : la monture terrestre réellement contrôlée subit 20 % de dégâts de chute en moins ; le familier lui-même ne sert pas de monture. | **Endurance morte-vivante** : pendant 6 s, la monture et son cavalier reçoivent 20 % de recul en moins et traversent l’eau peu profonde 15 % plus vite ; pas de respiration offerte. | 60 s |
+| Zombie-villageois (`zombie_villager`) | **Médecin de campagne** : affiche l’avancement estimé d’une guérison de zombie-villageois visible à 6 blocs. | **Veille** : canalise 8 s près d’un zombie-villageois déjà en guérison pour avancer de 20 s son temps restant ; une seule application de familier par guérison, pas d’ingrédient économisé. | 90 s |
+| Piglin zombifié (`zombified_piglin`) | **Retenue** : raccourcit de 20 % la colère individuelle d’un Piglin zombifié, sans prévenir l’alerte de groupe ou pardonner une nouvelle attaque. | **Offrande d’apaisement** : consomme un lingot d’or pour interrompre 2 s la poursuite de trois Piglins zombifiés ordinaires à 5 blocs ; la colère reste enregistrée. | 75 s |
+| Vagabond (`stray`) | **Tireur du froid** : −20 % de glissade sur glace pendant la visée à l’arc. | **Trait givrant** : la prochaine flèche dans les 8 s ralentit de 20 % pendant 3 s ; munition et dégâts natifs, aucune glace placée. | 50 s |
+| Vindicateur (`vindicator`) | **Bûcheron précis** : −10 % de durée de casse des bûches à la hache, dans les limites normales du minage acheté. | **Brise-garde** : la prochaine frappe de hache dans les 6 s prolonge de 1 s une désactivation de bouclier réussie ; pas de dégâts supplémentaires. En PvP, prolongation plafonnée à 0,5 s. | 60 s |
+| Zoglin (`zoglin`) | **Instinct de survie** : −15 % de recul lorsque la vie est sous 50 %. | **Ruée furieuse** : charge de 5 blocs sans changement de direction après départ, 4 PV à la première cible ; annonce de 0,75 s qui permet l’esquive. | 60 s |
+
+## Extraordinaire — transformer une situation
+
+| Familier | Passif | Actif proposé | Recharge |
+|---|---|---|---|
+| Grinceur (`creaking`) | **Écorce** : après 3 s immobile au sol, −15 % de dégâts tant qu’on reste immobile ; attaquer interrompt ce passif. | **Enracinement** : pendant 6 s, immobile et sans attaquer, réduit les dégâts de 25 % et le recul de 50 % ; jusqu’à trois alliés consentants à 3 blocs reçoivent −10 % de dégâts tant qu’ils restent proches. | 100 s |
+| Grand gardien (`elder_guardian`) | **Bâtisseur immergé** : −15 % de pénalité de minage sous-marin, sans supprimer l’exigence d’air, d’outil ou de rang. | **Sanctuaire marin** : zone de rayon 4 blocs pendant 8 s, centrée au lancement ; le porteur et trois alliés consentants suspendent leur consommation d’air et subissent 15 % de dégâts en moins tant qu’ils y restent. | 120 s |
+| Enderman (`enderman`) | **Calme du regard** : croiser brièvement le regard d’un Enderman donne 1 s supplémentaire avant son agression ; une attaque ne bénéficie d’aucune tolérance. | **Pas de l’End** : téléportation jusqu’à 8 blocs sur un appui visible et libre, après 0,75 s de préparation ; ne traverse aucune paroi, porte fermée ou zone interdite. | 75 s |
+| Évocateur (`evoker`) | **Étude des maléfices** : les nouveaux effets de Faiblesse et de Lenteur durent 15 % moins longtemps. | **Ligne de crocs** : après 1 s d’annonce, dessine une ligne de 8 blocs sur un sol continu visible ; 5 PV par cible au maximum, trois cibles maximum, aucun croc derrière un mur. | 90 s |
+| Ghast (`ghast`) | **Artillerie aérienne** : les projectiles renvoyés par le joueur ont 10 % de vitesse supplémentaire, sans bonus de dégâts. | **Boulet spectral** : projectile lent et renvoyable, portée 24 blocs, explosion de rayon 2 blocs pour 5 PV, quatre cibles maximum ; terrain et feu inchangés. | 90 s |
+| Ghast joyeux (`happy_ghast`) | **Main du bâtisseur** : tient la position 0,5 s après avoir quitté accidentellement un bord en mode accroupi ; une fois par appui stable de 2 s, aucun escalier dans le vide. | **Plateforme de nuage** : crée à côté d’un bloc d’appui visible une plateforme personnelle de 3 × 3 pour 8 s, dans la portée de pose ; aucun objet ou bloc ne peut y être construit, elle ne porte ni passager ni mécanisme et avertit avant de disparaître. | 120 s |
+| Golem de fer (`iron_golem`) | **Présence protectrice** : le premier coup de mêlée reçu après 10 s sans dégâts inflige 15 % de dégâts en moins. | **Interposition** : pendant 5 s, le porteur et deux alliés consentants à 3 blocs réduisent les dégâts de mêlée de 25 % et ne sont pas projetés en l’air ; le porteur avance 20 % moins vite. | 90 s |
+| Piglin barbare (`piglin_brute`) | **Garde d’or** : porter au moins une pièce d’armure d’or réduit le recul de mêlée de 15 % ; aucune trêve avec les brutes. | **Contre brutal** : fenêtre de parade frontale de 1 s avec arme de mêlée ; si un coup est paré, réduit ses dégâts de 40 %, au plus 2 PV, puis la prochaine frappe dans les 3 s ajoute 2 PV en PvE. | 75 s |
+| Ravageur (`ravager`) | **Masse** : −25 % de recul terrestre, sans bonus de dégâts permanent. | **Percée** : charge annoncée de 6 blocs, heurte jusqu’à trois cibles, 5 PV chacune ; s’arrête devant le premier bloc solide et ne casse aucune culture. | 90 s |
+| Shulker (`shulker`) | **Prudence verticale** : −20 % de durée de Lévitation reçue. | **Ancrage de chantier** : reste suspendu à sa position actuelle pendant 6 s maximum, à moins de 4 blocs d’un appui solide ; peut poser à portée normale, sans ascension. Se déplacer annule l’effet, avertissement avant la chute. | 100 s |
+| Cheval-squelette (`skeleton_horse`) | **Cavalier des fonds** : l’air du cavalier diminue 15 % moins vite lorsqu’il est sur une monture immergée. | **Traversée des eaux** : le cavalier et sa monture marchent sur l’eau pendant 6 s et 10 blocs au maximum ; aucun effet sur la lave, aucune protection après expiration. | 90 s |
+| Renifleur (`sniffer`) | **Mémoire botanique** : en visant une plante connue, indique ses conditions de croissance manquantes observables : lumière, substrat ou eau, selon son espèce. | **Piste ancienne** : pendant 15 s, indique une direction approximative vers du sable ou du gravier suspect à 24 blocs, types déjà découverts et chunks déjà chargés ; ne lit pas le butin, ne détecte pas une salle fermée ou un lieu réservé au scénario. | 120 s |
+| Vex (`vex`) | **Esprit agile** : −20 % de durée de ralentissement dû aux effets reçus, sans traversée des collisions. | **Main spectrale** : atteint un bloc de construction visible 2 blocs au-delà de la portée habituelle pour une seule pose ou récupération autorisée ; exige outil, matériaux et rang, jamais de coffre ou mécanisme distant. | 60 s |
+| Sorcière (`witch`) | **Dosage précis** : les potions bues par le porteur durent 10 % plus longtemps ; aucune amplification de niveau ni changement des effets instantanés. | **Fiole partagée** : consomme une potion buvable choisie et transmet à deux alliés consentants à 4 blocs sa moitié de durée, ou sa moitié de soin instantané, chacun ; ne transforme pas une potion en objet revendable. | 100 s |
+| Wither squelette (`wither_skeleton`) | **Os calcinés** : les nouveaux effets de Wither durent 20 % moins longtemps. | **Entaille sombre** : la prochaine frappe de mêlée dans les 6 s applique au plus 3 PV de flétrissement sur 4 s et réduit les soins reçus de 20 % pendant 4 s ; soin réduit de 10 % et durée 2 s en PvP. | 75 s |
+| Nautile-zombie (`zombie_nautilus`) | **Sang-froid abyssal** : à moins d’un tiers d’air, le recul reçu sous l’eau diminue de 25 %, sans restaurer d’air. | **Sauvetage** : propulse vers le haut, sur 6 blocs maximum, le porteur et un allié immergé consentant à 3 blocs ; rend une bulle à chacun, sans dépasser leur capacité. Plafonds et obstacles arrêtent la remontée. | 120 s |
+
+## Légendaire — trois moments exceptionnels
+
+| Familier | Passif | Actif proposé | Recharge |
+|---|---|---|---|
+| Ender Dragon (`ender_dragon`) | **Maîtrise du ciel** : −20 % de dégâts de collision en élytres et de projectiles reçus en l’air ; aucune armure supplémentaire au sol. | **Essor draconique** : après 2 s d’annonce au sol, soulève de 8 blocs le porteur et trois alliés consentants à 4 blocs, puis permet 10 s de vol plané, déplacement total plafonné à 40 blocs. Aucun maintien d’altitude, aucune deuxième impulsion ; descente signalée, pas d’immunité à l’arrivée. | 180 s |
+| Warden (`warden`) | **Écoute profonde** : perçoit la direction de vibrations à 8 blocs, sans nom, silhouette ou coordonnées exactes ; les joueurs accroupis ne sont pas révélés. | **Onde sonique** : après 2 s de canalisation sonore, frappe dans une ligne de 12 blocs jusqu’à trois cibles visibles pour 10 PV chacune en PvE, interrompt leur attaque si elle est interruptible et détruit les projectiles hostiles rencontrés. Pas de dégâts à travers un mur, ni de pénétration d’armure en PvP. | 180 s |
+| Wither (`wither`) | **Volonté funèbre** : quand la vie passe sous 30 %, les nouveaux ralentissements durent 25 % moins longtemps ; aucune résurrection ni explosion à la mort. | **Moisson des ombres** : après 1,5 s d’annonce, tire trois crânes lents et esquivables vers les cibles visées à 16 blocs, au maximum 12 PV par cible et trois cibles au total. Les dégâts réellement infligés rendent 10 % de leur valeur au porteur, plafonnés au plus petit de 2 PV ou 20 % de sa vie maximale. Aucun vol de vie sur alliés, familiers, animaux apprivoisés ou cibles invulnérables ; aucun terrain détruit. | 180 s |
+
+## Obtenir les œufs sans transformer les animaux en distributeurs
+
+**Toute cette acquisition est proposée : beta.018 ne la contient pas.**
+
+1. Découvrir personnellement l’espèce en jeu ouvre sa fiche de lien dans le
+   Blockodex. Observer ne donne pas directement un œuf ou une série d’XP.
+2. Réussir un objectif approprié débloque une première essence : s’occuper d’un
+   animal, réaliser une production variée, accomplir une exploration ou maîtriser
+   une interaction avec un monstre. Pas de « tuer 500 exemplaires » ni de minuterie
+   AFK pour les obtenir.
+3. L’offrande fournit le coût matériel. Les objectifs et leurs récompenses sont
+   enregistrés par habitant et monde ; New Game+ ne distribue pas à nouveau les
+   premières récompenses. Les duplicatas éventuels demandent une recette ou un
+   échange explicite, pas une nouvelle validation de la même découverte.
+4. Le familier peut être conservé au prestige. Sa puissance n’augmente pas avec
+   le chiffre romain, et ses réserves respectent toujours les compétences du
+   personnage courant. Aucun prestige supplémentaire n’est requis pour rééquiper
+   un familier déjà acquis.
+
+Exemples de pistes d’obtention, à transformer ensuite en vrais objectifs :
+
+| Œuf | Objectif proposé |
+|---|---|
+| Poule — commun | Découvrir, nourrir et accompagner la croissance d’une poule réelle. |
+| Squelette — commun | Observer son arc et bloquer un tir avec un bouclier ; aucune ferme à kills requise. |
+| Abeille — peu commun | Installer un rucher et récolter miel puis cire en préservant ses habitantes. |
+| Golem de cuivre — peu commun | Construire puis diagnostiquer un premier circuit fonctionnel. |
+| Allay — rare | Rencontrer un Allay, lui confier un objet et organiser une collecte près d’un bloc musical. |
+| Piglin — rare | Découvrir plusieurs résultats de troc distincts ; pas acheter cent fois le même résultat. |
+| Golem de fer — extraordinaire | Participer à la défense d’un village puis à sa remise en état, avec des objectifs vérifiables. |
+| Renifleur — extraordinaire | Mener une séquence d’archéologie, faire éclore un véritable renifleur et cultiver ses plantes. |
+| Ender Dragon — légendaire | L’achèvement collectif de l’aventure de l’End ouvre le lien ; chaque habitant réalise ensuite son épreuve d’exploration. |
+| Warden — légendaire | Réussir une expédition de discrétion dans les profondeurs et rapporter une archive ; tuer le Warden n’est pas le passage obligé. |
+| Wither — légendaire | Participer au défi du Wither puis à la construction d’une balise utile à la communauté ; pas recevoir un œuf à chaque boss farmé. |
+
+Le déblocage collectif ne remet pas automatiquement un légendaire à tous les
+comptes. La contribution personnelle doit rester accessible aux nouveaux venus
+après l’événement, par une épreuve rejouable dont la récompense est unique pour
+chaque habitant. Les noms d’épreuves ci-dessus sont des intentions, pas des
+advancements déjà présents.
+
+L’objet obtenu en survie devra être un **œuf de familier inerte** : même apparence
+d’espèce et même slot, mais impossible à utiliser comme œuf d’apparition vanilla
+dans le monde ou dans un distributeur. Sans cette distinction, l’obtention d’un
+œuf de Wither, de villageois ou de renifleur ferait aussi apparaître des entités
+et casserait l’équilibre de production. Il faudra spécifier le contrat d’objet,
+sa provenance serveur et la migration des œufs de test avant tout portage ;
+aucune transformation des objets actuels n’est faite ici.
+
+Les règles actuelles de mort restent la référence : l’œuf équipé tombe si
+keepInventory est désactivé. Une récupération/recréation d’essence perdue et un
+éventuel commerce de familiers demandent leurs propres règles avant ouverture en
+survie. En première expérimentation, proposer le lien comme personnel et les
+objets de test comme opérateur évite de décider silencieusement de cette économie.
+
+## Première série de tests d’équilibrage
+
+Commencer par **Poule, Vache, Âne, Abeille, Golem de cuivre, Axolotl, Creeper,
+Enderman et Shulker**. Ce petit ensemble couvre chute, soin, transfert, production,
+information, dégâts, téléportation et construction. Il vérifie les règles communes
+avant de multiplier les effets. Les légendaires viennent après cette mesure.
+
+| Situation | Ce qu’il faut vérifier |
+|---|---|
+| Nouveau personnage à 3–3–3 | Aucun passif ne permet d’ignorer durablement faim, air ou chute ; un actif utile ne suppose pas un inventaire rempli de potions. |
+| Compétences maximales | Un commun est encore utile pour un métier ; il n’est pas remplacé automatiquement par un légendaire. |
+| Après New Game+ | Les réserves d’air, les soins et la portée groupée se bornent aux nouveaux rangs ; aucun coût ou délai réinitialisé. |
+| PvP à trois cœurs | Au plus un cœur de dégâts additionnels par activation et par cible, y compris poison, feu, impacts multiples et chute attribuable ; annonce et esquive réelles. |
+| 30 joueurs réunis | Pas de chaîne de peur, de boucliers ou de bulles d’air infinie ; pas de cumul de bonus de production et pas de recherche de chunks distants. |
+| Échanges et déséquipement | Aucun buff stocké en changeant d’œuf, aucune potion/munition/ressource dupliquée, une seule recharge commune persistante. |
+| Claims et lieux à secrets | Téléportations, silhouettes, main spectrale et plateformes respectent les accès ; les pouvoirs ne court-circuitent pas une salle fermée. |
+| Ergonomie | Prévisualiser la portée, l’appui, les bénéficiaires, les matériaux et la recharge ; un refus explique ce qui manque sans consommer l’action. |
+
+Mesurer le temps gagné sur une vraie tâche, le taux de survie et la fréquence
+d’utilisation. Un passif constamment équipé dans tous les contextes est suspect ;
+un actif jamais utilisé malgré sa disponibilité doit être renforcé ou remplacé.
+Les +10 % ne sont pas une garantie : les pouvoirs de construction et d’information
+peuvent gagner bien plus de temps qu’un petit bonus de dégâts.
+
+## Points à résoudre avant implémentation
+
+- Les bonus permanents de vitesse de production, les échanges à distance et les
+  plateformes demandent un état serveur dédié : ce
+  sont des contrats à écrire, pas de simples effets de potion à importer.
+- Le Renifleur ne génère aucun site ni butin. Le filtre excluant lieux protégés
+  et salles fermées doit être fiable avant d’activer sa recherche.
+- La main spectrale du Vex étend uniquement un geste de construction explicite ;
+  son interaction avec les structures protégées devra être testée avant activation.
+- Le premier ticket de pouvoirs inclura configuration serveur, libellés FR/EN,
+  attribution PvP et contrat de sauvegarde des recharges. Cette passe documentaire
+  ne modifie ni version, ni monde, ni binaire.

docs/companion-powers-beta019-coverage.md

@@ -0,0 +1,107 @@
+# beta.019 — couverture des familiers
+
+Les 88 passifs et 88 actifs disposent d’un chemin d’exécution. Les chiffres et
+conditions de chaque pouvoir restent détaillés dans la [proposition v1](companion-powers-balance-proposal.md).
+
+La suite client extrait les **88 modèles natifs**, à deux instants, en contrôlant
+leur éclairage et leur échelle. Cela ne constitue pas 88 essais manuels de pouvoirs.
+Le tableau distingue les contrôles comportementaux propres à une espèce des
+contrats communs (achat, persistance, coûts, portées, consentement et interruptions).
+La balance en partie réelle reste à éprouver ; « modèle seulement » signifie
+que le gameplay de cette espèce ne possède pas encore de scénario automatique dédié.
+
+Points d’entrée : `CompanionPassives` et les mixins `Companion*` pour les passifs ;
+`CompanionActions`, `CompanionWork`, `CompanionQueries`, `CompanionTrades`,
+`CompanionPlatform` et `CompanionProjectiles` pour les actifs. Les tests sont dans
+`Companion019GameTests`, `Companion019ClientChecks` et `Companion019Smoke`.
+
+| Familier | Passif implémenté | Actif implémenté | Vérification spécifique |
+| --- | --- | --- | --- |
+| Chauve-souris (`bat`) | Adaptation obscure | Écho (30 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Chat (`cat`) | Pattes de velours | Feulement (45 s) | Attribut de chute et suppression au changement d’œuf ; consentement. |
+| Poule (`chicken`) | Petites ailes | Battement (30 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Morue (`cod`) | Petites branchies | Dernière bulle (45 s) | Ajout d’air plafonné à trois bulles et récupération du bénéficiaire. |
+| Vache (`cow`) | Lait sélectif | Lait partagé (60 s) | Nettoyage natif du lait, conservation des effets bénéfiques, seau consommé/rendu. |
+| Âne (`donkey`) | Pas chargé | Déchargement (30 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Renard (`fox`) | Approche discrète | Plongeon (25 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Grenouille (`frog`) | Berges faciles | Langue (20 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Cheval (`horse`) | Cavalier | Galop (35 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Lama (`llama`) | Caravanier | Crachat (25 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Mule (`mule`) | Sentier sûr | Chargement (30 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Cochon (`pig`) | Bon appétit | Fouille (40 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Lapin (`rabbit`) | Pied léger | Bond (25 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Saumon (`salmon`) | À contre-courant | Remontée (30 s) | Navigation aquatique après le déplacement laborieux au sol. |
+| Mouton (`sheep`) | Laine isolante | Coussin (45 s) | Consommation dans les seules cases ouvertes ; coussin limité et utilisé une fois. |
+| Squelette (`skeleton`) | Main stable | Tir repère (35 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Slime (`slime`) | Souplesse | Rebond (40 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Araignée (`spider`) | Prise ferme | Accroche (35 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Poulpe (`squid`) | Eau claire | Nuage d’encre (45 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Têtard (`tadpole`) | Reprendre haleine | Retour à la rive (30 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Poisson tropical (`tropical_fish`) | Œil du récif | Palette vivante (40 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Zombie (`zombie`) | Tenace | Second souffle (60 s) | Achat, persistance de recharge, soin progressif payé en faim et interrompu par dégâts. |
+| Tatou (`armadillo`) | Carapace réflexe | En boule (45 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Abeille (`bee`) | Pollinisateur | Butinage (45 s) | Propriétaire du cycle de culture, interruption sans crédit récupérable. |
+| Dromadaire (`camel`) | Endurance du désert | Grande enjambée (40 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Araignée venimeuse (`cave_spider`) | Habitué au venin | Morsure (45 s) | Réduction native de durée du poison. |
+| Golem de cuivre (`copper_golem`) | Lecture du circuit | Diagnostic (40 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Dauphin (`dolphin`) | Nage accompagnée | Sillage (50 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Noyé (`drowned`) | Main sous l’eau | Ancrage (40 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Poulpe luisant (`glow_squid`) | Lueur douce | Balise vivante (45 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Chèvre (`goat`) | Sabots | Coup de corne (40 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Momifié (`husk`) | Marche aride | Poussière (50 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Ocelot (`ocelot`) | Sous-bois | Esquive (30 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Panda (`panda`) | Gourmandise ciblée | Culbute (40 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Perroquet (`parrot`) | Sentinelle | Imitation (45 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Poisson-globe (`pufferfish`) | Immunité partielle | Hérissement (50 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Ours blanc (`polar_bear`) | Pelage polaire | Protection du petit (60 s) | Révocation immédiate d’un effet allié. |
+| Golem de neige (`snow_golem`) | Pas d’hiver | Bourrasque (35 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Arpenteur (`strider`) | Pieds chauds | Pas de braise (60 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Tortue (`turtle`) | Apnée tranquille | Abri (50 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Villageois (`villager`) | Carnet du voisinage | Commande groupée (45 s) | Coûts natifs, limites de stock, objets produits et rejet du rejeu du devis. |
+| Loup (`wolf`) | Riposte de meute | Cible de meute (45 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Embourbé (`bogged`) | Pied de marais | Flèche des marais (50 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Desséché (`parched`) | Habitué à l’épuisement | Trait épuisant (50 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Allay (`allay`) | Ramasseur choisi | Récolte musicale (45 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Axolotl (`axolotl`) | Convalescence aquatique | Soin de rive (60 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Blaze (`blaze`) | Chaleur entretenue | Salve ardente (60 s) | Progression réelle du four, carburant accéléré et sortie unique. |
+| Breeze (`breeze`) | Lecture du vent | Pas de vent (40 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Dromadaire momifié (`camel_husk`) | Caravane nocturne | Traversée (50 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Creeper (`creeper`) | Mèche sensible | Détonation maîtrisée (75 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Endermite (`endermite`) | Récupération de perle | Petit décalage (45 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Gardien (`guardian`) | Écailles | Rayon (60 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Hoglin (`hoglin`) | Carrure | Percussion (55 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Cube de magma (`magma_cube`) | Peau chaude | Bond brûlant (55 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Mooshroom (`mooshroom`) | Cuisine fongique | Bouillon réconfortant (90 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Nautile (`nautilus`) | Réserve mesurée | Cloche de plongée (75 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Phantom (`phantom`) | Vol de nuit | Glissade nocturne (65 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Piglin (`piglin`) | Habitué du troc | Choix du marchand (90 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Pillard (`pillager`) | Arbalétrier | Tir de couverture (50 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Poisson d’argent (`silverfish`) | Lecture de la pierre | Fissure témoin (50 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Cube de soufre (`sulfur_cube`) | Décontamination | Projection corrosive (60 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Lama de marchand (`trader_llama`) | Inventaire de caravane | Convoi (60 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Marchand ambulant (`wandering_trader`) | Carnet de voyage | Étal partagé (90 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Cheval-zombie (`zombie_horse`) | Longue route | Endurance morte-vivante (60 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Zombie-villageois (`zombie_villager`) | Médecin de campagne | Veille (90 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Piglin zombifié (`zombified_piglin`) | Retenue | Offrande d’apaisement (75 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Vagabond (`stray`) | Tireur du froid | Trait givrant (50 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Vindicateur (`vindicator`) | Bûcheron précis | Brise-garde (60 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Zoglin (`zoglin`) | Instinct de survie | Ruée furieuse (60 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Grinceur (`creaking`) | Écorce | Enracinement (100 s) | Déplacement annule racines et résistance liée. |
+| Grand gardien (`elder_guardian`) | Bâtisseur immergé | Sanctuaire marin (120 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Enderman (`enderman`) | Calme du regard | Pas de l’End (75 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Évocateur (`evoker`) | Étude des maléfices | Ligne de crocs (90 s) | Crocs visuels temporaires exclus des sauvegardes. |
+| Ghast (`ghast`) | Artillerie aérienne | Boulet spectral (90 s) | Vol ; rendu client. |
+| Ghast joyeux (`happy_ghast`) | Main du bâtisseur | Plateforme de nuage (120 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Golem de fer (`iron_golem`) | Présence protectrice | Interposition (90 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Piglin barbare (`piglin_brute`) | Garde d’or | Contre brutal (75 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Ravageur (`ravager`) | Masse | Percée (90 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Shulker (`shulker`) | Prudence verticale | Ancrage de chantier (100 s) | Destruction du support arrête la suspension. |
+| Cheval-squelette (`skeleton_horse`) | Cavalier des fonds | Traversée des eaux (90 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Renifleur (`sniffer`) | Mémoire botanique | Piste ancienne (120 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Vex (`vex`) | Esprit agile | Main spectrale (60 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Sorcière (`witch`) | Dosage précis | Fiole partagée (100 s) | Potion réelle partagée, demi-durée, maintien d’une potion ordinaire ultérieure. |
+| Wither squelette (`wither_skeleton`) | Os calcinés | Entaille sombre (75 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Nautile-zombie (`zombie_nautilus`) | Sang-froid abyssal | Sauvetage (120 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Ender Dragon (`ender_dragon`) | Maîtrise du ciel | Essor draconique (180 s) | Déplacement aérien effectif, espace libre ; rendu client. |
+| Warden (`warden`) | Écoute profonde | Onde sonique (180 s) | Modèle natif ; essais gameplay spécifiques à poursuivre. |
+| Wither (`wither`) | Volonté funèbre | Moisson des ombres (180 s) | Plafonds PvE/PvP partagés, exclusion des apprivoisés ; vol. |

docs/companion-powers-beta019.md

@@ -0,0 +1,152 @@
+# beta.019 — pouvoirs des 88 familiers
+
+Ticket ouvert le 13 septembre 2026, branche `codex/companion-powers-beta019`.
+
+### États ajoutés et déplacements
+
+La livraison inclut les déplacements propres aux familles : vol orbital du
+Dragon, vol du Wither et des Ghasts, nage et difficultés des aquatiques hors de
+l’eau. Le familier reste temporaire, invincible et sans combat autonome.
+
+Les cycles de culture et de four utilisent de nouvelles pièces jointes JSON
+versionnées `sanctuary:companion_crop_cycles` sur le niveau et
+`sanctuary:companion_furnace_cycle` sur le four. Absence : aucun cycle antérieur
+crédité. Un cycle déjà entamé ne gagne pas de propriétaire rétroactivement.
+La présence continue, le même propriétaire et le même équipement sont vérifiés ;
+quitter la zone, changer de lien ou arrêter le serveur invalide le cycle en cours.
+Les fractions ne sont jamais transférées à un nouveau cycle. Aucun objet,
+résultat, carburant, niveau d’XP ou bloc de sauvegarde existant n’est converti.
+Un JSON invalide ou d’une version future est conservé et bloque seulement ce
+bonus. Les nouveaux tags peuvent être ignorés lors d’un retour à beta.018.
+La guérison du zombie-villageois reçoit un booléen persistant indépendant,
+`sanctuary:companion_cure_used`, absent par défaut, limitant Veille à une fois.
+Les devis, choix de troc et plateformes sont temporaires et ne survivent pas à
+une déconnexion. Un choix de troc abandonné perd ses deux lingots déjà offerts ;
+il ne fournit aucun des deux résultats.
+**Livraison locale beta.019 vérifiée — 13 septembre 2026.**
+
+Le créateur autorise l’implémentation des 88 passifs et 88 actifs de la
+[proposition v1](companion-powers-balance-proposal.md), et la correction du rendu
+noirci des compagnons. Les rangs I–III, les soins faisant évoluer le lien et les
+œufs Anomaly à contreparties sont explicitement reportés au prochain ticket.
+Aucun malus solaire ou autre malus historique n’est ajouté aux œufs ordinaires.
+
+## Contrat de stockage et de migration
+
+Les accessoires beta.018 et leurs identifiants restent inchangés. Aucun monde,
+chunk ou objet d’une installation personnelle n’est converti par les outils de
+développement. Les nouvelles données se créent uniquement quand le serveur du
+mod exécutera les nouvelles fonctionnalités.
+
+Le lien actif et les délais des pouvoirs utilisent un état joueur indépendant,
+versionné et persistant, copié à la mort et conservé au New Game+. L’absence de
+cet état signifie lien non acheté, aucune recharge. Une version inconnue ou des
+données invalides désactivent les pouvoirs de ce joueur sans effacer son état.
+L’achat utilise les niveaux réellement disponibles côté serveur. Les identifiants
+et achats des anciennes aptitudes ne sont pas renommés et leur stockage n’est
+pas réécrit pour ajouter ce lien indépendant.
+
+Les recharges reposent sur les échéances du serveur et sont communes au slot.
+Le déséquipement interrompt les améliorations temporaires. Reconnexion, mort et
+prestige ne donnent pas de nouvelle charge. Les améliorations de soin et d’air
+possèdent aussi leur récupération par bénéficiaire.
+
+La configuration dédiée `config/sanctuary/companion-powers.json` propose les
+valeurs v1, les cinq raretés et les réglages serveur. Les clients reçoivent une
+vue bornée de leur propre état. Les cibles, ressources, droits, dégâts et
+transactions sont contrôlés côté serveur. Le consentement aux effets alliés
+est explicite et révocable ; l’appartenance à une faction ne le remplace pas.
+
+Les œufs natifs restent les objets de test déjà utilisés en beta.018.
+L’obtention des essences en survie et leur forme inerte sont un chantier distinct
+de l’activation des pouvoirs demandée ici : aucun œuf natif n’est distribué par
+un advancement et aucune récompense d’acquisition n’est inventée.
+
+## Livraison et vérifications
+
+La livraison comprend une interface FR/EN lisible pour le lien actif,
+le familier équipé, sa rareté, ses deux effets, sa recharge et son raccourci.
+Le rendu est contrôlé dans le client avec les modèles natifs et leur lumière
+ambiante ; la couverture des scénarios est détaillée ci-dessous. Les vérifications couvrent les transactions, les interruptions,
+le PvP, les portées, l’absence de chargement distant, les capacités initiales et
+maximales, les échanges d’œufs, la mort et le prestige.
+
+Les pouvoirs et leurs vérifications sont [recensés individuellement](companion-powers-beta019-coverage.md). Une
+déclaration de registre ou une description affichée ne prouve pas à elle seule
+que son effet fonctionne. `check build` et `assemblePack` sont exécutés pour
+la livraison locale beta.019. Le canal packwiz et Prism ne sont pas modifiés
+sans demande de mise à jour correspondante.
+
+## Utilisation de la version d’essai
+
+Équiper un œuf dans sa case de familier. Son passif s’active après **10 secondes**
+avec le même œuf. **B → Progression → Aptitudes → Lien actif** coûte **4 niveaux**
+par défaut ; **G**, configurable dans Contrôles, déclenche le pouvoir.
+Le panneau **Familier** indique la rareté, le passif, l’actif, les conditions et
+la recharge. Il contient le consentement aux effets alliés et un bouton opérateur
+pour préparer un nouvel essai. Les achats, temps de recharge et récupérations
+soin/air sont stockés séparément des compétences et conservés à la mort et au prestige.
+
+Viser ce sur quoi agir : coffre, monstre, villageois ou surface. Les objets
+nécessaires se prennent dans les rangées ouvertes. Le villageois ouvre un devis
+aux prix et stocks natifs ; le Piglin offre deux tirages après paiement. Un choix
+en attente peut être rouvert dans le panneau Familier, par exemple après avoir
+libéré une case. Les relevés marchands s’affichent dans le carnet.
+
+Les équipes Minecraft et les membres d’une même faction Sanctuary sont exclus
+des cibles offensives. Recevoir les aides reste un consentement personnel,
+indépendant de la faction. Les poussées offensives PvP sont désactivées dans ce
+premier portage, comme prévu par la proposition.
+
+Les familiers utilisent des navigations terrestres, volantes ou aquatiques ;
+le Dragon décrit une orbite, le Wither et les Ghasts restent en vol. Poissons,
+calmars, gardiens, dauphins et nautiles nagent dans l’eau et se débattent au sol.
+Grenouilles, lapins et cubes bondissent ; les amphibies peuvent aussi nager.
+Ces déplacements sont propres au compagnon : aucune IA hostile native n’est importée.
+Le rendu réutilise les modèles et animations natifs, avec l’éclairage calculé à
+la position réelle du petit compagnon. Les anciens proxys non tickés conservaient
+une position précédente à l’origine, ce qui faussait l’échantillonnage de lumière.
+
+## Limites de cette première implémentation
+
+Les rangs I–III, œufs Anomaly, malus et évolution par les soins restent au prochain
+ticket. L’obtention des œufs en survie reste à concevoir. Aucun équilibrage de
+partie à 30 joueurs ni comportement de chaque actif en toutes circonstances
+n’est revendiqué. La [couverture](companion-powers-beta019-coverage.md) distingue
+les scénarios vérifiés des essais à poursuivre.
+
+La lumière du calmar luisant est une indication visuelle personnelle sur les
+surfaces cubiques exposées, sans modifier la lumière du monde ni les règles de
+spawn. Les signaux redstone sont un relevé du circuit au déclenchement. Les
+variantes de poissons tropicaux doivent avoir été observées personnellement ;
+leur mémoire utilise une note `seen_fish_v1` bornée, dérivée des identifiants
+natifs de motif et de couleurs. Ces indices ne révèlent aucune entrée via l’Atlas.
+Les permissions passent par les règles natives et le point d’intégration
+`CompanionWorld.ALLOW` ; les futurs claims devront s’y raccorder.
+
+## Proximité du joueur et transparence
+
+Les familiers volants passent progressivement de transparents à opaques entre
+**0,6 et 3,5 blocs** du regard du joueur. La distance à la caméra est également
+prise en compte en troisième personne. La courbe est continue et adoucie aux
+extrémités : aucun changement brutal d’opacité au seuil. Le corps et les couches
+des yeux partagent ce fondu, y compris pour le Dragon et le Wither.
+
+Le fondu appartient uniquement au rendu du familier volant. Il n’agit ni sur
+les monstres du monde ni sur les collisions, pouvoirs ou déplacements. La
+couleur et le matériau translucide sont inscrits dans chaque modèle envoyé au
+rendu différé ; l’opacité ne reste jamais active pour l’entité suivante.
+
+## Vérifications de livraison
+
+- `./gradlew check build assemblePack -PsanctuaryFocusedTests=companions,accessories,movement,progression,cycle,mining,building,inventory,inventoryflow,sorting,tutorial` : contrôles purs et **91 tests serveur réussis**.
+- Parcours client natif sur un nouveau monde Sanctuary de développement, graine 42 : achat à quatre niveaux, consentement, interface aux échelles 2/3/4, touche G et recharge après changement d’œuf, puis devis de villageois avec paiement réel.
+- Extraction des 88 modèles natifs à deux instants ; éclairage et échelle contrôlés. Pour chaque volant, vérification du matériau translucide et de l’alpha des couches du corps et des yeux, sans effet sur l’entité suivante. Captures de proximité à 4 / 2 / 0,8 blocs.
+- Le catalogue ne constitue pas une validation exhaustive du gameplay des 88 paires. Voir la [couverture par espèce](companion-powers-beta019-coverage.md).
+- MRpack contrôlé : CRC, versions, JAR embarqué identique au build, Demeure imbriqué identique, FR/EN, 88 passifs et 88 actifs, absence de tests. Les PNG existants et l’export beta.018 gardent leurs empreintes.
+
+Export : [Sanctuary-beta.019.mrpack](../build/Sanctuary-beta.019.mrpack).
+Reçu : `build/companion019-artifact.json`.
+
+SHA-256 MRpack : `ba3a7a0ceb1a9a71c135cdb5ddeacb431969eb2e8fd32d8bfaf5fab0e34d3bd3`.
+SHA-256 JAR : `e27cb61fdb1d55fec88f86cb8e9696eca6ca12a923129843208afbff6a6efc71`.

docs/companion-powers-inventory.md

@@ -0,0 +1,242 @@
+# Inventaire des pouvoirs de familiers — référence 26.2
+
+Relevé du 13 septembre 2026 pour préparer le ticket de validation des pouvoirs.
+**Aucun de ces pouvoirs n’est activé dans Sanctuary beta.018.** L’œuf y fournit
+uniquement l’apparence du compagnon, son suivi et les particules de caresse.
+
+La [proposition d’équilibrage v1](companion-powers-balance-proposal.md) classe
+les 88 œufs actuels en commun, peu commun, rare, extraordinaire et légendaire,
+avec de nouveaux passifs, actifs, coûts et recharges. C’est une proposition
+de remplacement ; le présent document reste le relevé historique de la 26.2.
+
+Le code historique contient **88 essences Minecraft** : elles correspondent
+exactement aux **88 fichiers d’œufs de Minecraft 26.3-pre-2**, version du pack.
+Il définit aussi **25 overrides ItsAlive**, absents du pack beta.018 actuel.
+Ce document décrit les branches du code, pas des comportements déjà testés en bêta.
+
+Les effets sans chiffre sont de niveau I. Les passifs concernent le joueur portant
+l’œuf. La recharge concerne l’actif, en secondes à 20 ticks/s. Chaque utilisation
+réussie ajoute **0,45 point d’épuisement**, et non 0,45 barre de faim. L’ancien
+actif exige l’aptitude COMPANION_ACTIVE_POWER ; son raccourci était G, configurable.
+Les cooldowns sont communs au joueur : changer d’œuf ne les annule pas.
+
+## Les 88 œufs Minecraft de notre version
+
+| Mob / œuf | Passifs et contreparties | Actif | Recharge |
+|---|---|---|---|
+| Abeille (`bee`) | Chute lente | Pollinisation | 12 s |
+| Allay (`allay`) | Chance | Aimant à objets | 8 s |
+| Âne (`donkey`) | Résistance | Aimant à objets | 10 s |
+| Araignée (`spider`) | Vision nocturne ; Escalade des murs | Langue agrippante | 8 s |
+| Araignée venimeuse (`cave_spider`) | Vision nocturne ; Escalade des murs | Poison | 8 s |
+| Arpenteur (`strider`) | Résistance au feu ; Faiblesse à l’eau/pluie | Ruée | 6 s |
+| Axolotl (`axolotl`) | Respiration aquatique | Soin | 14 s |
+| Blaze (`blaze`) | Résistance au feu ; Faiblesse à l’eau/pluie | Petite boule de feu | 8 s |
+| Breeze (`breeze`) | Chute lente | Ruée aérienne | 4 s |
+| Chat (`cat`) | Vitesse ; Apaise les Creepers ; Apaise les Phantoms | Effroi | 12 s |
+| Chauve-souris (`bat`) | Vision nocturne ; Chute lente | Sonar des entités | 10 s |
+| Cheval (`horse`) | Vitesse II | Ruée | 5 s |
+| Cheval-squelette (`skeleton_horse`) | Respiration aquatique ; Vision nocturne ; Trêve morts-vivants | Ruée | 7 s |
+| Cheval-zombie (`zombie_horse`) | Vitesse II ; Brûle au soleil ; Trêve morts-vivants | Ruée | 7 s |
+| Chèvre (`goat`) | Sauts améliorés ; Résistance | Charge | 7 s |
+| Cochon (`pig`) | Aucun | Repérage du butin | 14 s |
+| Creeper (`creeper`) | Explosion à la mort sans dégâts au terrain | Détonation | 16 s |
+| Cube de magma (`magma_cube`) | Résistance au feu ; Sauts améliorés II ; Faiblesse à l’eau/pluie | Bond | 5 s |
+| Cube de soufre (`sulfur_cube`) | Résistance au feu ; Faiblesse à l’eau/pluie | Acide | 9 s |
+| Dauphin (`dolphin`) | Respiration aquatique ; Grâce du dauphin | Sonar des entités | 9 s |
+| Desséché (`parched`) | Résistance au feu ; Faiblesse à l’eau/pluie ; Trêve morts-vivants | Acide | 10 s |
+| Dromadaire (`camel`) | Vitesse | Ruée | 6 s |
+| Dromadaire momifié (`camel_husk`) | Vitesse ; Trêve morts-vivants | Charge | 8 s |
+| Embourbé (`bogged`) | Vision nocturne ; Trêve morts-vivants | Poison | 10 s |
+| Ender Dragon (`ender_dragon`) | Chute lente ; Résistance II | Souffle du dragon | 20 s |
+| Enderman (`enderman`) | Force ; Faiblesse à l’eau/pluie | Téléportation | 6 s |
+| Endermite (`endermite`) | Vitesse II | Téléportation | 4 s |
+| Évocateur (`evoker`) | Chance | Crocs d’évocateur | 14 s |
+| Gardien (`guardian`) | Respiration aquatique | Rayon gardien | 10 s |
+| Ghast (`ghast`) | Chute lente ; Faiblesse à l’eau/pluie | Boule de feu explosive | 12 s |
+| Ghast joyeux (`happy_ghast`) | Chute lente | Flottement | 6 s |
+| Golem de cuivre (`copper_golem`) | Célérité | Sonar des entités | 10 s |
+| Golem de fer (`iron_golem`) | Résistance II | Frappe au sol | 12 s |
+| Golem de neige (`snow_golem`) | Aucun | Rafale de neige | 7 s |
+| Grand gardien (`elder_guardian`) | Respiration aquatique ; Force de conduit | Rayon gardien | 16 s |
+| Grenouille (`frog`) | Sauts améliorés II | Langue agrippante | 6 s |
+| Grinceur (`creaking`) | Vision nocturne ; Résistance III immobile | Enracinement | 14 s |
+| Hoglin (`hoglin`) | Force | Charge | 9 s |
+| Lama (`llama`) | Aucun | Crachat ciblé | 6 s |
+| Lama de marchand (`trader_llama`) | Chance | Troc chanceux | 14 s |
+| Lapin (`rabbit`) | Vitesse II ; Sauts améliorés II | Bond | 4 s |
+| Loup (`wolf`) | Force | Rugissement | 10 s |
+| Marchand ambulant (`wandering_trader`) | Chance II | Sonar des entités | 16 s |
+| Momifié (`husk`) | Force ; Trêve morts-vivants | Festin | 12 s |
+| Mooshroom (`mooshroom`) | Régénération | Festin | 12 s |
+| Morue (`cod`) | Respiration aquatique | Bulle protectrice | 12 s |
+| Mouton (`sheep`) | Chute lente ; Résistance | Flottement | 8 s |
+| Mule (`mule`) | Vitesse ; Résistance | Ruée | 7 s |
+| Nautile (`nautilus`) | Respiration aquatique ; Souffle du Nautile | Bulle protectrice | 8 s |
+| Nautile-zombie (`zombie_nautilus`) | Respiration aquatique ; Brûle au soleil ; Trêve morts-vivants | Bulle protectrice | 9 s |
+| Noyé (`drowned`) | Respiration aquatique ; Brûle au soleil ; Trêve morts-vivants | Crachat ciblé | 9 s |
+| Ocelot (`ocelot`) | Vitesse II ; Vision nocturne | Roulade | 5 s |
+| Ours blanc (`polar_bear`) | Résistance ; Respiration aquatique | Rugissement | 12 s |
+| Panda (`panda`) | Résistance | Roulade | 8 s |
+| Perroquet (`parrot`) | Chute lente | Sonar des entités | 8 s |
+| Phantom (`phantom`) | Vision nocturne ; Chute lente ; Brûle au soleil ; Trêve morts-vivants | Flottement | 6 s |
+| Piglin (`piglin`) | Chance ; Trêve Piglins | Troc chanceux | 16 s |
+| Piglin barbare (`piglin_brute`) | Force II ; Trêve Piglins | Frappe au sol | 10 s |
+| Piglin zombifié (`zombified_piglin`) | Résistance au feu ; Trêve morts-vivants ; Trêve Piglins | Troc chanceux | 14 s |
+| Pillard (`pillager`) | Chance | Crachat ciblé | 7 s |
+| Poisson d'argent (`silverfish`) | Célérité II | Téléportation | 5 s |
+| Poisson tropical (`tropical_fish`) | Respiration aquatique ; Vision nocturne | Bulle protectrice | 10 s |
+| Poisson-globe (`pufferfish`) | Respiration aquatique | Poison | 9 s |
+| Poule (`chicken`) | Chute lente | Flottement | 5 s |
+| Poulpe (`squid`) | Respiration aquatique | Encre | 9 s |
+| Poulpe luisant (`glow_squid`) | Respiration aquatique ; Vision nocturne | Encre | 10 s |
+| Ravageur (`ravager`) | Force II ; Résistance | Charge | 12 s |
+| Renard (`fox`) | Vitesse ; Vision nocturne | Roulade | 5 s |
+| Renifleur (`sniffer`) | Chance II | Repérage du butin | 12 s |
+| Saumon (`salmon`) | Respiration aquatique ; Grâce du dauphin | Ruée | 5 s |
+| Shulker (`shulker`) | Résistance ; Résistance III immobile | Lévitation | 10 s |
+| Slime (`slime`) | Sauts améliorés II ; Chute lente | Bond | 4 s |
+| Sorcière (`witch`) | Chance | Potion de soutien | 14 s |
+| Squelette (`skeleton`) | Vision nocturne ; Brûle au soleil ; Trêve morts-vivants | Crachat ciblé | 7 s |
+| Tatou (`armadillo`) | Aucun | Carapace | 12 s |
+| Têtard (`tadpole`) | Respiration aquatique ; Sauts améliorés | Bond | 5 s |
+| Tortue (`turtle`) | Respiration aquatique ; Résistance | Carapace | 10 s |
+| Vache (`cow`) | Aucun | Purification | 14 s |
+| Vagabond (`stray`) | Vision nocturne ; Brûle au soleil ; Trêve morts-vivants | Gel | 9 s |
+| Vex (`vex`) | Chute lente ; Vitesse | Téléportation | 5 s |
+| Villageois (`villager`) | Héros du village | Faveur villageoise | 18 s |
+| Vindicateur (`vindicator`) | Force II | Frappe au sol | 9 s |
+| Warden (`warden`) | Vision nocturne ; Résistance II | Onde sonique | 20 s |
+| Wither (`wither`) | Chute lente ; Résistance II ; Trêve morts-vivants | Flétrissement | 20 s |
+| Wither squelette (`wither_skeleton`) | Résistance au feu ; Trêve morts-vivants | Flétrissement | 12 s |
+| Zoglin (`zoglin`) | Force II ; Trêve morts-vivants | Charge | 10 s |
+| Zombie (`zombie`) | Force ; Brûle au soleil ; Trêve morts-vivants | Rugissement | 12 s |
+| Zombie-villageois (`zombie_villager`) | Chance ; Brûle au soleil ; Trêve morts-vivants | Faveur villageoise | 18 s |
+
+## Détail des traits passifs
+
+- **Trêve** : toutes les 10 ticks, efface la cible des mobs concernés qui visent
+  le propriétaire, dans une boîte de 24 blocs autour de lui. Ce n’est pas une
+  invulnérabilité. Le chat utilise ce même mécanisme pour Creepers et Phantoms.
+- **Morts-vivants reconnus par la trêve** : bogged, camel_husk, drowned, husk,
+  parched, phantom, skeleton, skeleton_horse, stray, wither_skeleton, zoglin,
+  zombie, zombie_horse, zombie_nautilus, zombie_villager, zombified_piglin.
+  Le boss Wither ne figure pas dans cette liste de cibles pacifiées.
+- **Faiblesse à l’eau/pluie** : Faiblesse II et Lenteur I tant que le joueur
+  est dans l’eau ou sous la pluie ; ce trait ne code pas de dégât direct.
+- **Soleil** : applique 45 ticks de feu chaque seconde si le ciel est lumineux,
+  visible au-dessus du joueur, sans eau/pluie. Aucun test de casque ici.
+- **Défense immobile** : Résistance III si la vitesse horizontale au carré est
+  inférieure à 0,0025. Le contrôle ne porte pas sur la vitesse verticale.
+- **Escalade** : pousse la vitesse verticale à au moins 0,18 contre un mur et
+  réinitialise la chute.
+- **Explosion à la mort** : puissance 3, sans feu ni destruction de blocs.
+- Les effets passifs ordinaires sont renouvelés toutes les 10 ticks pour 35 ticks.
+  Retirer l’œuf arrête leur renouvellement ; les dernières durées peuvent subsister.
+
+## Ce que font réellement les actifs
+
+Les dégâts indiqués sont des points de vie : **2 points = 1 cœur**, avant les
+réductions natives éventuelles. Les zones sont des boîtes autour du joueur,
+pas un rayon sphérique strict. Elles excluent le propriétaire et les familiers,
+mais peuvent inclure d’autres joueurs. Les actifs ciblés choisissent la créature
+vivante la plus proche dans un cône jusqu’à 24 blocs ; la fonction ne vérifie
+pas la ligne de vue. Ces points devront être testés et arbitrés avant portage.
+
+| Actif | Comportement du code historique |
+|---|---|
+| Acide (`ACID`) | Poison II et Lenteur II pendant 7 s sur la cible. |
+| Aimant à objets (`MAGNET`) | Attire les objets au sol dans une zone de 12 blocs autour du joueur, impulsion de 0,45 vers ses yeux. |
+| Bond (`BOUNCE`) | Vitesse verticale relevée au minimum à 1,05 ; distance de chute réinitialisée. |
+| Bond du chasseur (`POUNCE`) | Impulsion force 2,15, minimum vertical 0,65 ; si une cible existe, Lenteur V pendant 2,5 s. |
+| Boule de feu explosive (`FIREBALL`) | Lance une véritable LargeFireball native, puissance d’explosion 1. Les effets sur le terrain suivent le projectile natif. |
+| Bulle protectrice (`BUBBLE`) | Respiration aquatique pendant 15 s et Absorption I pendant 10 s. |
+| Carapace (`SHELL`) | Résistance IV et Lenteur II pendant 5 s. |
+| Charge (`CHARGE`) | Impulsion force 2,35, minimum vertical 0,15 ; Résistance II pendant 3 s. Aucun dégât de contact spécifique codé ici. |
+| Crachat ciblé (`SPIT`) | 3 dégâts d’attaque et recul sur la cible. Le code applique directement les dégâts : il ne crée pas de projectile de crachat ou de flèche. |
+| Crocs d’évocateur (`FANGS`) | Fait apparaître huit crocs natifs en ligne, espacés de 1,35 bloc dans la direction du regard. |
+| Détonation (`DETONATE`) | Explosion de puissance 2,25 centrée sur le joueur, sans feu ni destruction du terrain. |
+| Effroi (`SCARE`) | Même effet codé que Rugissement : 2 dégâts, recul, Faiblesse I pendant 4 s dans une zone de 11 blocs. |
+| Encre (`INK`) | Invisibilité 5 s pour le joueur ; Cécité 4 s aux autres entités vivantes proches, zone de 9 blocs. |
+| Enracinement (`ROOT`) | Résistance IV, Absorption II et Lenteur IV pendant 6 s. |
+| Faveur villageoise (`TRADE`) | Héros du village II pendant 15 s. |
+| Festin (`FEAST`) | Rend 3 points de vie, soit 1,5 cœur, et donne Absorption I pendant 10 s. Ne remplit pas la faim. |
+| Floraison (`BLOOM`) | Même effet codé que Pollinisation : Régénération I et Célérité I pendant 6 s aux autres entités vivantes proches, zone de 7 blocs. |
+| Flottement (`FLOAT`) | Ajoute une impulsion de 0,45 dans le regard et 0,55 vers le haut ; Chute lente pendant 8 s ; distance de chute réinitialisée. |
+| Flétrissement (`WITHER`) | Wither II pendant 7 s et 5 dégâts magiques sur la cible. |
+| Frappe au sol (`SLAM`) | 7 dégâts, recul et Faiblesse I pendant 4 s aux autres entités vivantes dans une zone de 8 blocs ; efface leur cible si elle était le propriétaire. |
+| Gel (`FREEZE`) | Lenteur IV et Faiblesse I pendant 8 s sur la cible ; ne crée pas de glace. |
+| Langue agrippante (`TONGUE`) | Attire la cible vers le joueur avec une impulsion horizontale et une composante verticale de 0,25. |
+| Lévitation (`LEVITATE`) | Lévitation I pendant 5 s sur la cible. |
+| Onde sonique (`SONIC`) | 10 dégâts de type sonicBoom et recul sur la cible. |
+| Petite boule de feu (`SMALL_FIREBALL`) | Lance une véritable SmallFireball native dans la direction regardée. |
+| Poison (`POISON`) | Poison I pendant 7 s sur la cible. |
+| Pollinisation (`POLLINATE`) | Régénération I et Célérité I pendant 6 s aux autres entités vivantes proches, zone de 7 blocs. Le propriétaire est exclu ; aucune pousse de cultures dans cette fonction. |
+| Potion de soutien (`POTION`) | Purification, Régénération II et Résistance I pendant 8 s. Cette potion est fixe, malgré l’ancien libellé « aléatoire ». |
+| Purification (`CLEANSE`) | Retire Lenteur, Fatigue de minage, Nausée, Cécité, Faim, Faiblesse, Poison, Wither et Obscurité. Ne retire pas indistinctement tous les effets. |
+| Rafale de neige (`SNOW`) | Même effet codé que Gel : Lenteur IV et Faiblesse I pendant 8 s ; pas de boule de neige native créée. |
+| Rayon gardien (`BEAM`) | 6 dégâts magiques et Surbrillance 5 s sur la cible. |
+| Repérage du butin (`TRUFFLE`) | Rend lumineux les objets déjà au sol dans une zone de 18 blocs et donne Chance II pendant 12 s. Ne génère aucun trésor ; le marquage des objets n’a pas de minuterie de retrait ici. |
+| Roulade (`ROLL`) | Impulsion force 1,35, minimum vertical 0,08 ; Résistance III pendant 1,5 s. |
+| Rugissement (`ROAR`) | 2 dégâts, recul et Faiblesse I pendant 4 s aux autres entités vivantes dans une zone de 11 blocs ; efface leur cible si elle était le propriétaire. |
+| Ruée (`DASH`) | Impulsion selon le regard : force 1,8, minimum vertical 0,12 ; distance de chute réinitialisée. |
+| Ruée aérienne (`AIR_DASH`) | Impulsion selon le regard : force 1,45, minimum vertical 0,45 ; distance de chute réinitialisée. |
+| Soin (`HEAL`) | Rend 6 points de vie, soit 3 cœurs. |
+| Sonar des entités (`SONAR`) | Applique Surbrillance pendant 10 s aux autres entités vivantes proches, zone de 28 blocs. Ne détecte ni minerais ni redstone. |
+| Souffle du dragon (`DRAGON_BREATH`) | Lance une véritable DragonFireball native. |
+| Troc chanceux (`BARTER`) | Chance III et Héros du village I pendant 12 s. Ne produit aucun échange ou objet à lui seul. |
+| Téléportation (`TELEPORT`) | Cherche une destination sans collision de 12 à 2 blocs devant le joueur, par pas de 0,5. Se téléporte à la première trouvée et réinitialise la chute. |
+| Vomi (`VOMIT`) | Cécité 6 s, Surbrillance 12 s et Faim II pendant 8 s sur la cible. Aucune attraction de horde codée dans cette fonction. |
+
+## Les 25 œufs ItsAlive historiques
+
+Ils sont résolus par l’identifiant de l’objet œuf, pour distinguer notamment les
+Mooblooms qui partagent un type d’entité. Ils ne sont pas distribués en beta.018.
+
+| Mob / œuf | Passifs et contreparties | Actif | Recharge |
+|---|---|---|---|
+| Œuf d'apparition d'infecté (`infected`) | Vitesse II à 40 % de vie ou moins ; Trêve Infectés | Rugissement | 10 s |
+| Œuf d'apparition de chargeur (`charger`) | Résistance ; Trêve Infectés | Charge | 9 s |
+| Œuf d'apparition de cracheur (`spitter`) | Trêve Infectés | Acide | 9 s |
+| Œuf d'apparition de Hunter (`hunter`) | Vitesse ; Trêve Infectés | Bond du chasseur | 7 s |
+| Œuf d'apparition de Moobloom allium (`allium_moobloom`) | Régénération | Purification | 12 s |
+| Œuf d'apparition de Moobloom bleuet (`cornflower_moobloom`) | Chance II | Troc chanceux | 16 s |
+| Œuf d'apparition de Moobloom coquelicot (`poppy_moobloom`) | Bonus de vie | Soin | 12 s |
+| Œuf d'apparition de Moobloom hibiscus (`hibiscus_moobloom`) | Régénération | Floraison | 14 s |
+| Œuf d'apparition de Moobloom houstonie bleue (`azure_bluet_moobloom`) | Célérité | Ruée | 7 s |
+| Œuf d'apparition de Moobloom lilas (`lilac_moobloom`) | Vitesse II | Ruée | 7 s |
+| Œuf d'apparition de Moobloom marguerite (`oxeye_daisy_moobloom`) | Aucun | Purification | 12 s |
+| Œuf d'apparition de Moobloom muguet (`lily_of_the_valley_moobloom`) | Aucun | Poison | 10 s |
+| Œuf d'apparition de Moobloom narcisse (`narcissus_moobloom`) | Absorption | Bulle protectrice | 14 s |
+| Œuf d'apparition de Moobloom orchidée bleue (`blue_orchid_moobloom`) | Respiration aquatique | Bulle protectrice | 12 s |
+| Œuf d'apparition de Moobloom pissenlit (`dandelion_moobloom`) | Chute lente | Flottement | 7 s |
+| Œuf d'apparition de Moobloom tournesol (`sunflower_moobloom`) | Célérité | Floraison | 10 s |
+| Œuf d'apparition de Moobloom tulipe blanche (`white_tulip_moobloom`) | Résistance | Carapace | 12 s |
+| Œuf d'apparition de Moobloom tulipe orange (`orange_tulip_moobloom`) | Résistance au feu | Floraison | 14 s |
+| Œuf d'apparition de Moobloom tulipe rose (`pink_tulip_moobloom`) | Régénération | Soin | 12 s |
+| Œuf d'apparition de Moobloom tulipe rouge (`red_tulip_moobloom`) | Force | Floraison | 14 s |
+| Œuf d'apparition de vomiteur (`vomiter`) | Trêve Infectés | Vomi | 12 s |
+| Œuf d’apparition de baleine volante (`flying_whale`) | Chute lente ; Respiration aquatique | Bulle protectrice | 10 s |
+| Œuf d’apparition de Bracken (`bracken`) | Vision nocturne ; Vitesse | Effroi | 12 s |
+| Œuf d’apparition de fantôme (`ghost`) | Invisibilité ; Chute lente | Téléportation | 7 s |
+| Œuf d’apparition de papillon (`papillon`) | Chute lente ; Sauts améliorés | Pollinisation | 8 s |
+
+## Sources et points à reprendre
+
+- [Registre et exécution historiques](../../26.2/sanctuary/src/main/java/fr/koka99cab/sanctuary26/sanctuary/gameplay/SanctuaryCompanionPowers.java) : registre vanilla ligne 827, ItsAlive ligne 918 ; passifs ligne 222, actifs ligne 286.
+- SHA-256 du Java consulté : `0b3ea8571161fe8eccb059ca2d5ca12f8351c80ad7cd5a81556e199175ebeea5`.
+- [Ancien résumé alpha.96](../../26.2/sanctuary/COMPANION_POWERS.md), conservé en lecture seule.
+- Œufs présents : fichiers `assets/minecraft/items/*_spawn_egg.json` du JAR
+  Minecraft 26.3-pre-2 ; noms FR issus de son index d’assets local.
+- [Contrat beta.018](companions-cosmetics-beta018.md) : pouvoirs expressément exclus du portage actuel.
+
+Le présent relevé corrige des imprécisions du résumé historique : le sonar du
+golem de cuivre est le sonar générique d’entités ; le chat possède aussi Vitesse ;
+l’Embourbé, l’Araignée venimeuse et le Grinceur ont Vision nocturne ; le dromadaire
+momifié a Vitesse ; le Nautile a aussi Respiration aquatique ; le Phantom a aussi
+la trêve. Potion n’est pas aléatoire, Festin ne nourrit pas, et les « projections »
+de squelette, noyé et pillard appliquent des dégâts ciblés sans projectile natif.
+Les seuls projectiles natifs créés dans le registre actif sont les boules de feu
+et le souffle du dragon ; les crocs sont leurs propres entités.
+
+Aucun effet, identifiant, réglage, monde ou binaire n’a été modifié pour ce relevé.

docs/companions-cosmetics-beta018.md

@@ -0,0 +1,153 @@
+# beta.018 — cases de familier, cape et cosmétique de tête
+
+Ticket du 13 septembre 2026, branche `codex/companions-cosmetics-beta018`.
+Contrat écrit avant les changements de stockage. Référence 26.2 consultée en
+lecture seule ; aucun pouvoir passif ou actif de familier n'est porté ici,
+sur décision explicite du créateur. Leur validation aura son ticket dédié.
+
+## Interface et objets
+
+L'en-tête de l'inventaire indique uniquement Inventaire / Inventory, sans
+compteur de rangées. La capacité reste lisible dans Progression et par les cases.
+Trois cases d'équipement distinctes rejoignent le panneau personnel, toujours
+disponibles : un œuf de familier, une cape, un objet cosmétique sur la tête.
+Chaque case contient un vrai objet, limité à une unité. Les clics et Maj-clics
+utilisent les menus synchronisés et respectent les rangées débloquées.
+De haut en bas : cosmétique de tête, cape, œuf de familier, main secondaire.
+Cet ordre est visuel ; les identifiants de stockage familier/cape/tête restent fixes.
+Maj-clic équipe automatiquement œufs et capes ; le cosmétique se place à la main.
+Le tri et le changement de hotbar ne déplacent pas cet équipement.
+Maj + clic gauche maintenu permet de parcourir les cases et d’exécuter leur
+Maj-clic natif successivement. Le geste part d’une case avec le curseur vide ;
+chaque case est visitée une seule fois, y compris lors d’un mouvement rapide.
+Relâcher le clic ou Maj termine le geste. Coffres, fours et autres conteneurs
+gardent leurs destinations et restrictions natives. Le catalogue créatif garde
+ses gestes d’origine ; l’inventaire personnel Sanctuary utilise ce raccourci.
+La touche de rangée fonctionne également en jeu sans écran : Tab avance,
+Maj + Tab recule. Elle reste configurable et garde la même sélection de rangée
+à la réouverture de l’inventaire. Seules les rangées débloquées sont parcourues.
+Une commutation interrompt l’utilisation de l’objet tenu, comme un changement
+de case de hotbar natif, et reste validée par le serveur.
+Les trois PNG fournis dans `../textures/{egg,cape,cosmetics}.png` sont copiés sans
+retouche dans le mod et dans les sources du resource pack.
+
+Un œuf d'apparition de mob équipé fait apparaître un petit compagnon temporaire
+qui se déplace réellement : navigation autour des obstacles, promenade proche
+et téléportation vers une place libre s'il est trop loin ou bloqué. Le suivi par
+apparition à côté du joueur de la 26.2 est remplacé. Le retirer le fait disparaître.
+Il est invincible et ne collisionne pas avec les autres entités. Le clic droit
+du propriétaire le caresse et émet des particules aux couleurs de son œuf.
+Une entité de familier dédiée utilise l'apparence du mob, afin de ne pas hériter
+de ses attaques ou comportements destructeurs. Les animations restent visuelles.
+Le familier n'est pas une source renouvelable de butin, d'XP ou de produits.
+Ses pouvoirs ne sont pas activés. Les œufs natifs restent disponibles pour les
+tests opérateur ; leur acquisition en survie n'est pas inventée dans ce ticket.
+
+`sanctuary:zero_cape` est une première cape de test, libellée Cape Zéro / Zero Cape,
+avec un visuel provisoire trouvé en ligne et une provenance documentée. Elle se
+teste depuis le créatif ou `/give`. Elle utilise le mouvement de cape natif ;
+elle ne modifie ni les élytres ni le compte Minecraft.
+
+Le cosmétique accepte tout objet/bloc. Il ne remplace pas le casque serveur et
+ne donne ni protection, ni effet, ni déclenchement d'objet. Les propriétés d'état
+de bloc sont utilisées pour le rendu lorsque possible. Un piston porté sur la
+tête s'étend brièvement quand le joueur reçoit des dégâts, uniquement en rendu :
+aucun bloc placé ou déplacé, aucun signal de redstone.
+
+## Sauvegarde, mort et New Game+
+
+Ajout d'un champ joueur `sanctuary:accessories`, schéma 1, contenant trois piles
+optionnelles dans l'ordre familier/cape/tête. Un ancien joueur beta.017 commence
+avec trois cases vides ; aucun déplacement ni changement des 54 cases existantes,
+du journal de progression ou de cycle. Les données inconnues/corrompues sont
+conservées et rendues non modifiables, sans remplacement silencieux.
+
+Les objets suivent la mort native : ils tombent si keepInventory est désactivé,
+sont conservés sinon. Le New Game+ les garde comme le reste de l'inventaire.
+La créature temporaire n'est jamais sauvegardée dans les chunks ; elle est
+recréée depuis l'œuf après reconnexion/changement de dimension, sans doublon.
+Les apparences cape/tête sont synchronisées par le serveur aux observateurs,
+y compris lors de l'arrivée d'un nouveau joueur. Aucun bonus serveur ne dépend
+de ces apparences. Nouveau contrat réseau `sanctuary:accessories_v1` : client et
+serveur beta.018 ensemble. Aucun monde personnel ou installation n'est modifié.
+
+## S’allonger et se reposer
+
+W est un geste de base gratuit. S’allonger disparaît des aptitudes achetables.
+Maj + W conserve le déblocage Se reposer et son coût. Le repos utilise le rendu
+natif de sommeil au lit, orienté selon le joueur, distinct de la posture mobile.
+Il ne déclenche pas le sommeil serveur, ne fixe pas de point de réapparition et
+ne fait pas avancer le temps. Les anciens champs et preuves d’achat `lying`
+sont conservés pour lire les sauvegardes beta.017 ; aucun nouvel achat n’est
+accepté et `lyingCost` devient un champ historique sans effet.
+
+## Validation
+
+### Sélections de minage et de construction
+
+Le retour d’essai ajouté pendant ce ticket fixe le groupe au premier clic
+maintenu avec R. Le client conserve l’origine, les cases et le palier ; le
+serveur valide la visée au démarrage puis poursuit le même travail sans exiger
+de regarder encore l’origine. Tourner la caméra ou bouger en restant à portée
+ne remet pas la charge à zéro. La construction garde son plan, sa face et ses
+directions de pose initiales, y compris pour les escaliers. Le contexte de pose
+est figé sans modifier la caméra ou la position réelle du joueur.
+
+La molette règle le palier avant le clic. Pendant le maintien, le groupe reste
+fixe, même après sa fin : il faut relâcher avant d’en choisir un autre. Les
+interruptions par changement d’outil, portée, menu, mort, droits, matériaux ou
+perte de maintien restent actives. Les interactions natives, durées, coûts et
+limites de blocs restent inchangés. Aucun nouveau format de sauvegarde ou paquet
+réseau n’est introduit pour ce verrouillage ; son état est temporaire.
+
+### Parcours client
+
+Le parcours automatisé du client Minecraft 26.3-pre-2, sur un monde de
+développement neuf de graine 42, passe avec le vrai clavier et la vraie souris :
+
+- Emplacements synchronisés et ordre visuel, inventaire à 1 et 6 rangées, FR/EN.
+- Maj-clic œuf/cape, placement manuel du cosmétique, piston avant/après un dégât
+  serveur et rendu d’épée, tête de joueur, coffre et piston.
+- Suivi vivant et caresse ; rendus loup, vache, perroquet, creeper, morue et ghast.
+- W gratuit, achat du repos, rendu de sommeil distinct et arrêt par déplacement.
+- Tab en jeu, Maj inverse, maintien sans répétition, autre touche configurée,
+  conservation des 54 positions visibles et de la colonne sélectionnée.
+- Balayage rapide dans les deux sens d’un coffre, destination pleine, une seule
+  visite par case, tri ingrédient/combustible du four, arrêt au relâchement de Maj,
+  équipement automatique œuf/cape et absence de cosmétique automatique.
+- Veine de huit blocs entièrement cassée après changement de visée et déplacement
+  à portée ; cible voisine conservée pendant le maintien, puis minée après
+  relâchement et nouveau clic. Molette sans effet sur la sélection verrouillée.
+- Surface de 25 escaliers terminée en regardant ailleurs et en bougeant, avec
+  orientation initiale et consommation exacte ; aucune nouvelle surface après
+  la fin tant que le clic est maintenu.
+
+Les captures sont dans `mods/sanctuary/build/run/clientGameTest/screenshots/` ;
+le journal complet final est `build/group-lock018-client.log` (1 min 46 s).
+`build/cosmetics018-client.log` conserve le premier parcours des accessoires
+et raccourcis, également réussi avant l’ajout des sélections verrouillées.
+
+Limites : les essais ne constituent pas une validation de toutes les espèces,
+de tous les modèles spéciaux d’objets/blocs, ni d’une session multijoueur sous
+latence. Le déplacement du compagnon reste terrestre, même pour une apparence
+aquatique ou volante. Les pouvoirs de familiers attendent leur ticket dédié.
+
+### Serveur et distribution
+
+`./gradlew check build assemblePack -PsanctuaryFocusedTests=accessories,progression,movement,inventory,inventoryflow,sorting,cycle,mining,building`
+passe en **4 min 51 s**, avec **67 tests serveur obligatoires réussis**, ainsi
+que les contrôles purs du dépôt. Journal : `build/cosmetics018-check-build.log`.
+Les tests couvrent les six capacités d’inventaire, équipement typé, destination
+pleine, mort, sauvegarde/rechargement, conservation au prestige, données futures
+préservées, navigation et invincibilité du familier, interruption de l’arc lors
+d’un changement de rangée, protections et coûts natifs du minage/construction.
+La durée de minage reste identique entre une caméra fixe et une caméra qui
+tourne ; le contexte de construction figé ne fuit pas dans la pose individuelle.
+
+Export local : [Sanctuary-beta.018.mrpack](../build/Sanctuary-beta.018.mrpack),
+**2 617 278 octets**. SHA-256 :
+`06997ae60f3306b9b973c4b5e83894ca302905fbdd337e1d0c36abf0fa4d9aba`.
+Reçu : `build/cosmetics018-artifact.json`. ZIP, versions, JAR Sanctuary et Demeure
+embarqués, ressources, libellés, index packwiz et dépendance Fabric API vérifiés.
+Les exports beta.003 à beta.017 restent identiques ; aucune installation
+personnelle ni canal publié n’a été modifié.

docs/consultation-discord-analyse.md

@@ -0,0 +1,187 @@
+# Sanctuary — analyse de la vision et préparation de la consultation
+
+**14 septembre 2026 · Ticket documentaire local CONSULT-01 · Branche `codex/consultation-discord`.**
+
+Livrable associé : **[120 posts Discord prêts à copier](consultation-discord-posts.md)**. Ils couvrent les décisions de jeu, les retours sur les mécaniques actuelles et les besoins de communauté déduits de l’analyse. Ils n’ont pas été publiés. Aucun vote, témoignage ou accord d’anciens joueurs n’a été inventé.
+
+Un **[extrait des 12 premiers posts](consultation-discord-premiere-serie.md)** permet de lancer la discussion sans parcourir toute la banque.
+
+## 1. Ce que l’analyse fait ressortir
+
+**Sanctuary dispose déjà d’une progression personnelle documentée, mais sa promesse centrale — transformer ensemble un monde grâce à ses activités — demande encore sa boucle de jeu collective.** On peut développer son personnage, explorer, construire, recommencer et créer une faction. Les recherches et contributions ouvrant un continent, l’économie, les protections territoriales, les quêtes et la grande histoire ne sont pas encore reliées en un parcours jouable documenté.
+
+La vision est cohérente autour de trois expériences : devenir capable de choses nouvelles ; rendre le monde habitable avec d’autres ; laisser une histoire visible dans les lieux et le ciel. Ses inconnues les plus importantes portent sur **qui peut agir, à quel rythme, avec quelles conséquences pour les autres et pour ceux qui arrivent plus tard**. Choisir d’abord les objets, leurs recettes ou leurs prix laisserait ces problèmes sans réponse.
+
+Les anciens joueurs peuvent particulièrement bien éclairer les moments qui rassemblaient, les contraintes qui décourageaient, le plaisir des pouvoirs et la manière dont les voisinages fonctionnaient. La documentation ne contient pas un corpus de leurs retours permettant de présumer ces préférences. Les deux premières questions sont donc libres et précèdent les listes de fonctionnalités.
+
+## 2. Périmètre et méthode
+
+La base est l’**état local de travail**, qui comportait de nombreuses modifications et additions avant cette tâche, sur `codex/realtime-tracking-beta037`. La configuration indique `mod_version=beta.037` et `pack_version=beta.037`. Les notes décrivent des exports locaux ; cela ne prouve pas que les anciens joueurs disposent de cette version ni qu’elle est installée sur un serveur public.
+
+Le corpus inventorié comprend les **102 fichiers Markdown alors présents dans `docs/`**, le README, le changelog, les consignes de contribution et de versionnement, les notices et guides du pack, les README des modules et les archives documentaires pertinentes. La vision, les cahiers de cosmologie, structures, expansion et progression ont été examinés pour leurs décisions ; les contrats de versions pertinentes ont été croisés pour actualiser les statuts. Les historiques de terrain et de validation ont été parcourus par leur structure, leurs états et leurs limites. Les grands inventaires de recettes servent à vérifier la couverture des familles, pas à voter ligne par ligne sur des milliers de recettes.
+
+Il s’agit d’un **audit documentaire de conception**, pas d’un nouvel audit exhaustif du code, d’une vérification de toutes les preuves historiques ni d’un essai multijoueur. « Livré » ci-dessous signifie **décrit comme livré et accompagné de vérifications dans le contrat concerné**. Aucun test Minecraft n’a été exécuté pour cette tâche documentaire et aucune compatibilité externe n’est extrapolée depuis une ancienne étude.
+
+Ordre de lecture retenu en cas de divergence : décision explicite récente pour l’intention ; contrat de livraison le plus récent sur la mécanique pour l’état documenté ; proposition datée pour les possibilités ; référence alpha ou 26.2 pour l’historique. Un document récent ne remplace un ancien contrat que sur les sujets qu’il traite.
+
+Les posts portent quatre statuts :
+
+- **Souvenir** : information à recueillir, absente des sources.
+- **Choix ouvert** : décision explicitement laissée à concevoir ou à équilibrer.
+- **Retour sur l’existant** : une règle existe ; on évalue son effet sans la présenter comme indécise à l’origine.
+- **Question déduite** : conséquence ou besoin identifié par l’analyse, à confirmer auprès des joueurs.
+
+## 3. Ce qui est déjà fixé ou documenté comme jouable
+
+| Sujet | Point de départ à conserver dans les discussions | Sources |
+| --- | --- | --- |
+| Monde | Un monde flottant commun ; Petit 512, Moyen 724, Grand 1 024 de diamètre nominal. Chantier de terrain clôturé par le créateur sur alpha.30.7. | [Vision](vision.md), [alpha.30.7](generation-alpha30.7.md) |
+| Expéditions | Quatre régions de 512 blocs déjà ouvertes dans les nouveaux mondes concernés. La révision beta.002 retient nord boréal, est tropical/volcan, sud aride/canyon, ouest humide/océan ; les futures ouvertures collectives restent absentes. | [beta.001](expeditions-beta001.md), [beta.002](expeditions-beta002.md), [expansion](expansion.md) |
+| Arrivée | Fiche d’habitant et couleur, accueil, cinématique de 29,5 secondes que l’on peut passer. Départ 3/3/3. | [Progression](progression-beta003-contract.md), [introduction](introduction-beta031.md) |
+| Compétences | Six compétences fonctionnelles. Minage individuel à vitesse native au départ, jusqu’à 200 % et veines de 256 blocs ; construction jusqu’aux plans 15×15 ; inventaire de 9 à 54 cases, hotbar comprise. | [Minage](mining-beta008.md), [construction](building-beta009.md), [inventaire](inventory-beta010.md) |
+| Coûts et amorce | Courbe par défaut 1, 2, 4, 8, 16, 32, 48 niveaux ; inventaire sur les cinq premiers achats. Cinq étapes de premiers gestes, 8 points d’XP chacune, une fois par habitant et monde. Équilibrage à éprouver. | [beta.013](progression-inline-beta013.md), [tutoriel](tutorial-xp-beta016.md) |
+| Mort | Compétences et aptitudes conservées. Sans keepInventory, 70 % des points d’XP non investis laissés en orbes récupérables par tous ; objets selon les règles de mort applicables. | [Contrat initial](progression-beta003-contract.md), [inventaire](inventory-beta010.md) |
+| New Game+ | Volontaire après les six compétences au maximum, sans exiger toutes les aptitudes. Compétences et XP remises à zéro par défaut ; aptitudes, objets, connaissances, monde et affiliations conservés. Objets des rangées verrouillées retirables. | [Cycles](cycle-factions-beta011.md) |
+| Factions | Une affiliation à la fois. Un cycle donne un prestige et une charge ; une charge fonde deux places, une charge ajoute une place. Invitations, départ, exclusion, transfert et dissolution existent. Aucun claim n’en découle. | [Cycles et factions](cycle-factions-beta011.md) |
+| Demeure | Mesure des empreintes d’habitation dans les zones connues ; la décroissance après absence ne constitue pas un droit de reprise de propriété. | [Demeure](demeure-beta006.md), [module](../mods/demeure/README.md) |
+| Connaissances et carte | Carte native personnelle de surface, exploration mémorisée avant achat, absence de partage automatique ; filtres Discovery des entrées connues. Bestiaire complet, minimap, marqueurs et partage restent des sujets distincts. | [Atlas](atlas-beta005.md), [menus beta.033](menus-discovery-beta033.md), [navigation](blocodex-navigation.md) |
+| Recettes | Catalogue JEI porté, connaissances distinctes de la possession, fabrication manuelle libre. 67 collections dont une technique ; 2 042 recettes classées et 126 advancements associés. Fiches détaillées d’obtention et musée encore futurs. | [Recettes](recipes-jei-beta024.md), [collections beta.035](collections-beta035.md) |
+| Familiers | 88 paires de pouvoirs révisées, recharges et budgets partagés, nom et taille persistants, interactions. Acquisition de survie, rangs I–III et Anomaly non livrés. | [beta.020](familiar-interactions-beta020.md), [beta.032](spawn-eggs-v2-beta032.md), [catalogue](spawn-eggs-v2-catalogue-beta032.md) |
+| Gestes et visuels | Portage et piles de joueurs, plongeon, posture allongée, plané avec animal volant porté, cosmétiques interactifs et lumières dynamiques. La TNT portée est une vraie exception avec dégâts. | [Accessoires](companions-cosmetics-beta018.md), [TNT](head-cosmetics-beta021.md), [lumières](dynamic-lights-beta030.md), [beta.036](corrections-beta036.md) |
+| Temps et objectifs | Temps réel saisonnier, choix serveur, sommeil sans saut de nuit, phantoms naturels d’insomnie désactivés en temps réel. Suivi commun avec trois objectifs épinglés au maximum ; quêtes non livrées. | [beta.037](realtime-beta037.md) |
+| Canon | Neuf anciens personnages, ruines comme traces d’anciennes solutions, Indoors contrôlés et Backrooms orphelins. Le canon et les identités retenus ne deviennent pas un sondage de popularité. | [Cosmologie](cosmologie.md) |
+
+## 4. Les tensions de design à résoudre en priorité
+
+| Tension | Pourquoi elle change réellement la partie | Décision ou essai utile |
+| --- | --- | --- |
+| Coopération / passage obligé par le prestige | Un groupe d’amis peut vouloir se structurer avant qu’un membre ait maximisé six compétences. Les places financées par répétition de cycles peuvent faire du groupe une récompense de grind. | P06, P07, P10–P12, puis essai de fondation à plusieurs. |
+| Départ fragile / joueur occasionnel | Trois cœurs et neuf cases peuvent créer de l’entraide ou décourager avant la première relation sociale. Les premiers gestes donnent déjà de l’XP : il faut mesurer le départ actuel. | P04, P08, P09, P15 et une heure sans commandes. |
+| Exploration / stocks disponibles | Quatre îles sont déjà ouvertes, et certains îlots aériens de la fin alpha sont volontairement riches. « Ressources rares » n’est pas une preuve de besoin d’expansion. | P19, P23, P26–P27 ; relever les ressources effectivement accessibles pendant une partie. |
+| Initiative / décision commune | Ouvrir une île modifie durablement le monde de tous. Le financeur, le constructeur de la machine et les futurs usagers ne sont pas forcément les mêmes. | P21–P25 ; préciser aussi la décision de lancement et l’annulation avant consommation. |
+| Progression / économie de l’XP | Capacités, enchantements, transports et futurs gestes créatifs peuvent se concurrencer. Une source d’XP dominante peut décider du rythme de tous les autres systèmes. | P09–P10, P18, P29 ; mesurer les budgets par activité avant de choisir les prix. |
+| Habiter / combattre / plaisanter | Factions, Demeure, braquages, téléportations, TNT et lucky blocks ne partagent pas encore un contrat de protection. Un geste amusant pour l’un peut détruire le projet d’un autre. | P31–P40, P114, P102 ; tester des situations aux frontières des permissions. |
+| Monde permanent / pression horaire | Temps réel, offres horaires, dimanche, quotas et production peuvent favoriser une disponibilité que les anciens n’ont plus. | P04–P06, P49, P52, P54–P55, P58, P100, P113. |
+| Découverte / connaissance extérieure | Les joueurs connaissent déjà Minecraft et peuvent consulter un wiki. Le secret du catalogue ne doit pas devenir une obligation d’ignorer ce qu’ils savent. | Garder la fabrication libre ; P63–P67 et un parcours d’information volontaire. |
+| Attachement / objet échangeable | Un compagnon nommé et singulier peut aussi être perdu, vendu, prêté ou remplacé par un plus rare. Ces intentions produisent des relations très différentes. | P71–P75 ; fixer l’acquisition et la récupération avant un marché des œufs. |
+| Histoire commune / événements manqués | Boss uniques, reliques et révélations peuvent laisser les absents sans rôle. Le ciel et les archives peuvent valoriser une première victoire sans rendre les suivants inutiles. | P06–P07, P82–P86, P107–P108, P116. |
+| Ballast / conservation économique | Une trace narrative n’est ni un prélèvement autorisé ni un stock restituable. Rendre le ballast exploitable peut créer une nouvelle source de monnaie ou de matériaux. | P92–P93, P117 ; un cas complet d’opération → trace → lieu → récupération. |
+| Proximité du créatif / avenir de la survie | Les possibilités créatives changent la valeur de la production, des objets rares et du commerce. Les droits opérateur ne sont pas une récompense de gameplay implicite. | P18 et P85 avant de définir la récompense des sept boules. |
+
+## 5. Carte complète des décisions restantes
+
+Les plages renvoient aux identifiants du [document de posts](consultation-discord-posts.md). La colonne finale conserve les détails à spécifier après la consultation : les joueurs choisissent une expérience, puis le ticket en fait une règle testable. Aucun de ces détails n’est marqué comme implémenté par ce document.
+
+| Domaine | Décisions de jeu encore ouvertes ou à réévaluer | Posts | Détails à arrêter au ticket |
+| --- | --- | --- | --- |
+| Identité du projet | Souvenirs à retrouver, irritants, priorité des piliers, durée des sessions et des aventures. | P01–P05 | Population et rythme de test visés ; distinguer monde permanent et futurs départs saisonniers. Aucun effacement décidé. |
+| Accueil et inclusion | Place des nouveaux, absents, non-combattants, autonomie des premières heures. | P06–P09, P111–P112 | Aides, jalons, lisibilité de la fiche et de l’introduction, accès sans vocal, besoins de clavier et de lecture. |
+| Progression | Temps du premier cycle, sources d’XP, intérêt du prestige, confort achetable et plafond d’inventaire. | P09–P16 | Prix et courbes après mesures ; ne pas récompenser de nouveau une découverte déjà payée ; traitement des futurs plafonds sans altérer les cycles archivés. |
+| Mort | XP publique ou réservée, pertes ordinaires et objets personnels, effort de récupération. | P13–P14, P73, P90–P91 | Expiration, décès répété, vide, lave, déconnexion, keepInventory et garanties contre les doubles restitutions. |
+| Factions | Moment de fondation, charges et capacité, délégation et responsable absent. | P11–P12, P35 | Rôles fins, seuils, invitations, règles de trésorerie future et sort des dépenses au départ ; ne pas confondre couleur d’habitant et identité collective. |
+| Claims et voisinages | Protection personnelle avant faction, agrandissement, visiteurs, abandon, visibilité Demeure. | P31–P36 | Emprise verticale, sous-sols, limites de chunk, espaces publics, accès aux animaux et coffres, chevauchements, alertes et contestations. Demeure reste une mesure sauf nouveau contrat explicite. |
+| Conflit et risques | PvP, conditions des braquages, enjeu volable, présence des défenseurs, dégâts collatéraux. | P37–P40, P114 | Fenêtres, cooldowns, avertissements, attribution d’une attaque, usages du foret, sanctions et réparation d’incidents. Les dates d’absence ne valent pas consentement. |
+| Expansion collective | Motivation après les quatre îles initiales, cadence, décideurs, formes de contribution et coûts. | P19–P23 | Population de référence, progression des prix, plusieurs projets simultanés, annulation, remboursement, droit de lancer et usage public de la nouvelle terre. |
+| Recherches et machine | Informations accessibles avant engagement, apprentissage, montage et programmation. | P24–P25, P60 | Rôles de l’assembleur, contrôleur, terminal, dépôt et ancre ; connexions, recettes, autorisations ; distinction mailbox / dépôt collectif / dépôt de machine. |
+| Territoire et ressources | Préservation de l’île, carrière, pénurie bloquante, ressources exclusives, identité des futurs biomes. | P19, P26–P27, P118 | Relevés après génération, ressources finies/renouvelables, emprises et accessibilité ; nouveau biome et palette sur graines versionnées, sans rouvrir implicitement le chantier alpha. |
+| Ruines | Utilité immédiate, indices, réappropriation, lien avec les machines et les personnages. | P78–P79, P84 | Pour chaque lieu : ancien usage, plan, accès, butin, état, exceptions collectives, présence garantie/facultative et répétition. Relire les versions plus récentes avant de reprendre WG-26. |
+| Donjon majeur | Blocage qu’il lève, nature du défi, bénéficiaires, répétition, usage après victoire. | P80–P84 | Identité et comportements du boss, objet installé/consommé/conservé, site indispensable accessible, objet perdu, participants tardifs, spawners et récompenses personnelles. |
+| Transport | Première traversée, priorité des moyens, coût et place des réseaux publics. | P28–P29, P119 | Waystones horizontales connues et ascenseurs, rayon et arrivée approximative du téléporteur, temps d’activation, accès, capacités et vitesses ; ziplines, leads consommés par grappin, bateau/poule, biplan, Happy Ghast, taille de Magic Carpet. |
+| Monnaies | Rôle pratique des trois gemmes, convertibilité, production et usages de dépense. | P42–P45, P48 | Origine et génération des rubis/saphirs, recettes, taux, frais, quantités, sinks et effets des fermes. Les valeurs de ponte de la vision demandent un essai d’économie. |
+| Boutique et marché | Lieu, stock réel ou apport du serveur, prix, échanges entre joueurs et renouvellement des offres. | P41–P46, P113 | Nombre et prix des neuf emplacements envisagés, durée d’une offre, frais d’annonce, réservation, transfert de propriété, livraison échouée et stockage plein. |
+| Catalogue et courrier | Signification exacte d’une réserve en saphirs, garantie apportée, livraison et délégation. | P45, P47, P49 | Limites par objet, dépôt ou assurance, propriétaire de la mailbox, récupération de l’accès, boîte pleine et envoi annulé ; éviter toute création illimitée par réservation. |
+| Navets et loterie | Achat dominical accessible, place du hasard, exclusivités et attentes des absents. | P49–P50 | Cours, fréquence, péremption éventuelle non décidée, ticket gagné/comment, probabilités, plafond, financement et règles des futurs casinos événementiels. |
+| Quêtes et événements | Activités utiles, quotas, partage des récompenses, rendez-vous libres ou programmés. | P51–P54 | Trois difficultés/gemmes, acceptation, abandon, expiration, dépôts, attribution XP/butins ; auteur des panneaux, inscriptions, anniversaires, visiteurs, concours et Gazette. |
+| Villageois et automatisation | Premières tâches, personnes autorisées, production en l’absence des joueurs. | P56–P58 | Rayon des cloches, bannières en conflit, salaires et entretien, stocks sources/destinations, métier, refus, capture/changement d’équipe ; différences ticks chargés / heures réelles. |
+| Machines de production | Convoyeurs, ordinateur, terminal commun et chargement de chunk. | P56, P58–P60 | Six ports, langage et exemples, stockage jusqu’à 128 coffres envisagés, connexion/permissions, périmètre et durée des clés de chunk, limites de charge serveur. |
+| Construction avancée | Plans guidés ou automatisés, circulation des schémas, utilité des prefabs. | P17, P61 | Attribution de l’auteur, partage/vente, matériaux inconnus, vraie consommation, permissions, supports, annulation ; vérifier Litematica sur la version exacte au ticket. Voxelier reste non prioritaire. |
+| Cartographie | Transmission volontaire, niveau d’information de la minimap, reliefs superposés, marqueurs. | P62–P64 | Copie ponctuelle ou mise à jour, périmètre du partage, provenance, carte de faction, limites du brouillard et de l’export Web ; autres dimensions et cartes souterraines. |
+| Découvertes | Critères du bestiaire, fiches d’obtention, niveau de guidage, alchimie par familles. | P65–P67, P115 | Vue/possession/fabrication distinctes, variantes d’espèces, gestes sans recette, encyclopédie technique, musée et récompenses éventuelles de collection ; contenu déjà connu conservé. |
+| Profil et affinités | Vitrine, favoris, effet sur apprivoisement, production ou chasse, consultation d’autrui. | P68–P69, P115, P120 | Nombre de trophées ; type/variante favori ; petit coefficient et bénéficiaire du butin ; délai de 24 h déjà retenu ; gestes et portée de lecture des PV. |
+| Familiers | Acquisition, hasard/objectif choisi, marché, perte, rangs et nature d’Anomaly. | P71–P76 | Contrat d’œuf de survie inerte à décider avant distribution ; duplication et première récompense ; sort des œufs de test, familles rares, découverte et stabilisation ; essais solo puis coop. |
+| Capes et objets exceptionnels | Valeur de souvenir, mérite, appartenance ou collection ; puissance des anomalies. | P50, P75, P77 | Visuel original de Cape Zéro, modes d’obtention des capes, tables des quatre familles de lootboxes, équipement titane indestructible et enchantements, rareté qui reste désirable sans remplacer tout le reste. |
+| Cosmologie et récit | Manière de raconter, rôle des joueurs dans l’issue, trois épreuves manquantes. | P78, P85–P86 | Nature exacte de la découverte, rôle encore vague de Zuri, liens d’Alex, journaux des neuf personnages, apparitions, dénouement ; ces révélations peuvent rester un atelier d’auteur séparé. |
+| Fin et après-fin | Réussite commune, droits créatifs de gameplay, poursuite du monde. | P05, P18, P85–P86 | Sept objets et leur réunion, seuil de fortune, cauchemar, rencontre d’Alpha, nécromancien, conséquences de victoire, nouveaux arrivants et nouveaux cycles. |
+| Dimensions | Priorité et rôle distinct des Cavernes, Alpha, Backrooms et Indoors. | P30, P87, P94 | Accès Nether/End existants ou à relier au parcours, ressources des Cavernes, cité ancienne et boss, apparence Alpha limitée à sa dimension ; conservation des régions exploitées. |
+| Backrooms | Accès, retour, récupération de biens perdus, propriété et rétention. | P88–P91 | Lumière et niveau de danger, lieu d’arrivée, mort/déconnexion, secours, distinction objet identifié / ressource de décor / résidu. Aucun espace réel ne devient sans référence de sauvegarde. |
+| Ballast et géologie | Trace gratuite, coût, conséquence contrôlable, lecture des périodes, extraction. | P92–P93, P117 | Opérations contributrices, unités, conservation ou transformation, provenance, période, moment de génération, strates des anciens, bornes ; préserver les lieux déjà explorés. |
+| Indoors | Usages, géométrie, propriété partagée et accès de remplacement. | P94–P97 | Tailles 5³ à 100³ indicatives, transfert/vente, déconnexion, visiteurs coincés, fermeture et devenir du contenu ; dimension technique ou régions d’un espace partagé à choisir par les développeurs. |
+| Cuisine et cultures | Complexité, terroirs, serres, transmission du savoir et temporalité alimentaire. | P98–P101 | Premier catalogue d’ingrédients/plats, ustensiles, étapes, nature de la « poudre », maturation du vin/fromage/saucisson, pages de Steve et pages secrètes ; rôle nutritionnel à mesurer avec Faim/Repos/familiers. |
+| Faune et végétation | Utilité et attachement aux rares, nouveaux environnements, productions localisées. | P48, P99, P106, P118 | Tables d’apparition, ponte non reproductible, armures de poule, variantes Moobloom, fleurs et bois lavande/ébène/mossy/blueberry ; formes, noms FR/EN et identifiants à stabiliser. |
+| Humour et danger | Limites d’Only Fun, événements absurdes, proximité des nouveaux hostiles. | P40, P102–P103, P106 | Portée des interactions, consentement, baleine fantôme et Happy Creeper, classes de zombies, fréquence, raids éventuels, distances aux refuges et comportement des boss. |
+| Armes et petits objets | Place des armes à feu, objets d’activité et écoute de musique. | P104–P105, P110 | Munitions pépites/lingots/minerais, argent/titane, creeper lock/mining rifle, enchantements, Weather/Fragment/Randomizer/Mega TNT ; format caméra/cartes, particuleur, référence du disque et lecture audiovisuelle. |
+| Ciel et calendrier | Organisation des étoiles, constellations, droits de dessin, cycles et datation visible. | P107–P109, P116 | Géométrie selon le point de vue, noms et longue-vue, étoiles adjacentes, coût point/segment, cycle stellaire de sept jours, origine et relation au soleil ; étoiles des absents et densité à long terme. |
+| Site et histoire | Gazette, activités entre connexions, publication volontaire et portée des découvertes. | P70, P120 | Identités partagées, événements personnels/collectifs, spoilers, causalité, exports et actions Web validées serveur ; journal fonctionnant sans site. Les agrégats matériels ne suffisent pas à reconstruire cette histoire. |
+| Pack et exploitation | Accessibilité, performances et format des essais ; besoin réel des intégrations. | P111–P112 | Contrôles sans bouton latéral, lisibilité, effets et sons réglables ; matrice de versions/licences, machines cibles, support Mac/Windows, rollback et canal. Master Key : rôles de maintenance, journal des réparations et diagnostics, distincts des pouvoirs de jeu. |
+
+## 6. Incohérences et formulations documentaires à corriger
+
+Ces points sont relevés pour un futur entretien documentaire ; les fichiers sources existants n’ont pas été réécrits dans cette tâche.
+
+| Passage pouvant induire en erreur | Lecture actualisée | Correction documentaire proposée |
+| --- | --- | --- |
+| [README](../README.md) : nouveautés beta.037, tableau de version et exemple de JAR encore beta.036. | Les deux propriétés sont beta.037 ; [la livraison](realtime-beta037.md) est locale. | Une courte fiche de version actuelle, puis un historique daté. Ne pas déduire l’état du canal depuis la version de travail. |
+| [Vision](vision.md) : progression décrite comme future dans « Périmètre de départ », conclusion invitant encore à obtenir le premier monde stable. | Des compétences, cycles et factions sont décrits comme livrés ; worldgen clôturé sur alpha.30.7. | Marquer ces paragraphes comme cadrage initial et ajouter l’état actuel en tête. |
+| Vision : tous commencent isolés avant l’ouverture progressive des continents. | [beta.001–002](expeditions-beta002.md) ouvre déjà quatre anciennes expéditions dans les nouveaux mondes concernés. | Distinguer les terres héritées de celles que les joueurs créeront ensuite. |
+| Vision/expansion : boussole froid/chaud/sec/humide. | Convention facultative ; les îles initiales ont une répartition spécifique confirmée, dont ouest humide et est tropical. | Ne pas transformer la convention climatique en loi des quatre expéditions. |
+| Vision et ancienne présentation worldgen : monde de 384 blocs. | [alpha.30.4](generation-alpha30.4.md) documente Y0–639 constructibles ; alpha.30.7 conserve le plafond Y640. | Distinguer hauteur constructible actuelle, volume du terrain et configurations historiques. |
+| Vision : minage très lent, place de la hotbar à préciser, taux de perte XP et charges encore ouverts. | [Minage](mining-beta008.md) démarre à 100 % ; [inventaire](inventory-beta010.md) inclut la hotbar ; [mort](progression-beta003-contract.md) et [cycles](cycle-factions-beta011.md) fixent des valeurs configurables. | Conserver ces mentions comme anciennes intentions, lier les contrats courants. Poser un retour d’essai, pas une question d’implémentation initiale. |
+| [Prochains tickets](prochains-tickets.md) et plusieurs sections du backlog gardent de longues questions désormais résolues en beta.011. | Le bandeau de statut est à jour, le corps conserve le cadrage d’origine. | Séparer « contrat final », « limites encore ouvertes » et « discussion historique ». |
+| [Backlog](backlog.md) : REALTIME « à cadrer » sous TIME-037 livré ; quêtes prévues en haut à gauche. | [beta.037](realtime-beta037.md) livre l’horloge et impose le même moteur et placement que les autres objectifs, sans second HUD. | Retirer ces deux entrées des prochaines décisions actives ou les marquer remplacées. |
+| [beta.034](notifications-beta034.md) : bas à droite et suivi automatique ; beta.033 : Factions/History dans Échap. | [beta.036](corrections-beta036.md) retient haut à droite par défaut et suivi choisi ; beta.034 déplace Factions/History dans Prestige. | Garder chaque contrat daté ; une notice joueur actuelle doit décrire seulement les accès actuels. |
+| [Navigation Blocodex](blocodex-navigation.md) : tout est encore présenté comme conception et les inconnus sont décrits visibles dans le socle. | Recettes, objets connus, filtrage et accès ont progressé en beta.024–036 ; vitrine/favoris et bestiaire restent à distinguer. | Une matrice par fonction évitera « tout livré » et « tout absent ». |
+| [Collections](collections-minecraft.md) : définitions intégrées en tête, puis « futur ticket » et ancienne séquence de livraison dans le corps ; README beta.024 encore « proposition non active ». | [beta.035](collections-beta035.md) matérialise les 67 collections. Les fiches d’obtention et le musée restent futurs. | Séparer les données livrées des extensions de présentation, conserver le prototype JSON comme exemple historique. |
+| [Familiers v1](companion-powers-balance-proposal.md), [v2](spawn-eggs-refonte-v2.md) : couches de propositions avec états à dates différentes. | [beta.032](spawn-eggs-v2-beta032.md) et son catalogue décrivent les 88 pouvoirs ; acquisition, rangs et Anomaly restent ouverts. | Présenter une source des valeurs courantes et une liste distincte des hypothèses d’acquisition. |
+| [Structures-conception](structures-conception.md) : « alpha.22 reste la version publiée », petite sélection de lieux, rôles des personnages encore largement ouverts. | Les versions [alpha.30.6](generation-alpha30.6.md), [alpha.30.7](generation-alpha30.7.md) et [cosmologie](cosmologie.md) décrivent des évolutions ultérieures. | Ne pas appliquer toute la liste WG-26 comme un prochain chantier. Réconcilier chaque lieu et son rôle avec la génération finale et le canon. |
+| Formules générales sur « Fabric API seule dépendance de gameplay » dans le README et les guides de pack. | Demeure et un fork JEI sont embarqués ; Fabric API reste la dépendance externe distincte décrite par le pack. | Distinguer dépendances externes, modules embarqués et intégrations envisagées. |
+| Anciennes notes : contrôles visuels en attente, versions suivantes : parcours clients réussis. | Une validation ultérieure ciblée n’est pas automatiquement celle de tous les anciens scénarios ni un test d’équilibre. | Une matrice consolidée « comportement / dernière preuve / essai restant » ferait gagner plus qu’une nouvelle accumulation de totaux de tests. |
+
+Le défaut principal de la documentation est donc **l’accumulation de l’historique dans les pages d’orientation**. Elle conserve utilement les décisions et les limites, mais le lecteur doit reconstruire lui-même ce qui fait encore débat. Une future page « état actuel et décisions ouvertes » reliée aux contrats éviterait de transformer les anciens « reste à faire » en nouveau backlog.
+
+## 7. Comment utiliser les réponses
+
+### Premier tour : choisir ce qu’on veut vivre
+
+Commencer par **P01 et P02**, sans afficher d’abord toutes les fonctionnalités possibles : on recueille les souvenirs spontanés. Continuer avec **P03, P06, P08, P12, P19, P21, P31, P37, P71, P85**. Cette série de douze questions fixe les priorités, le rythme social, la protection et les grandes récompenses.
+
+Lire les commentaires avant de conclure avec un pourcentage. Une préférence majoritaire pour le conflit peut aussi révéler qu’une partie du groupe ne reviendrait pas avec cette règle. Conserver séparément avis sur une ancienne version, préférence théorique et observation sur une bêta précise. La taille des groupes de répondants ne permet pas de présumer l’opinion de tous les anciens.
+
+### Deuxième tour : préciser seulement les branches retenues
+
+- Si le groupe veut des territoires durables : P32–P36, puis les accès et limites des protections.
+- Si le braquage est accepté : P39 et P114. Si le groupe choisit de le réserver aux donjons, ces questions deviennent inutiles.
+- Si l’expansion collective motive : P20, P22–P27, P119, puis le rôle du donjon P80.
+- Si les familiers comptent : P72–P75 et P76 sur des usages réels, sans mettre 88 fiches au vote d’un coup.
+- Si l’économie est prioritaire : P41–P50, P58, P113 ; vérifier ensemble sources de ressources, dépenses et disponibilité horaire.
+- Si les mystères attirent : P78–P86. Proposer P92–P93 et P117 dans un espace volontaire si l’on veut garder cette idée secrète pour le reste des joueurs.
+
+Les autres thèmes gardent leur série indépendante. Une préférence pour la cuisine n’impose pas immédiatement toute sa liste d’ingrédients ; on peut choisir une chaîne complète, par exemple récolter → transformer → préparer → partager.
+
+### Troisième tour : convertir les avis en petits essais
+
+| Essai proposé | Matériel déjà documenté | Observation attendue |
+| --- | --- | --- |
+| Une heure d’arrivée en survie | Profil normal, premiers gestes, compétences, inventaire. | Premier achat, premières morts, incompréhensions, moment où l’on veut aider quelqu’un ou demander de l’aide. |
+| Une tâche avec quelques familiers | Pouvoirs beta.032 ; œufs fournis dans un monde de test puisque l’acquisition n’existe pas. | Fréquence d’usage, effets compréhensibles, tâches rendues possibles, comparaison seul/à plusieurs et compagnon que l’on veut garder. |
+| Une expédition avec chantier | Quatre régions ouvertes, carte personnelle, gestes de construction. | Temps et difficulté de traversée, manque réel de ressources, besoin de transport et intérêt d’une future expansion. |
+| Un atelier de règles de voisinage | Situations discutées ou simulées ; ne pas prétendre que les claims sont actifs. | Visiteur, accident, stock commun, absence, reprise, personne hors faction ; règles contradictoires repérées avant le code. |
+
+Une décision exploitable contient : **règle provisoire, raison exprimée, personnes affectées, situation testée et critère qui conduirait à la revoir**. Le modèle de retour à la fin des posts rend cette décision visible sans la confondre avec une fonctionnalité livrée.
+
+## 8. Ce qui reste de la responsabilité de conception et de développement
+
+Certaines inconnues demandent un atelier d’auteur ou une preuve technique, plutôt qu’un vote Discord :
+
+- **Équilibrage chiffré** : coefficients des 88 familiers, coûts exacts, taux de change, tables de butin, quotas, courbes de prix, fréquences de ponte et de spawn. Les avis donnent le ressenti visé ; les parties et mesures fixent les valeurs d’essai.
+- **Contrats de données** : identités stables, achats non répétés, objets uniques, panne entre paiement et livraison, copie des cartes, restauration, fermeture d’Indoor et journal transactionnel du ballast. Un choix de joueur ne dispense pas de ces garanties.
+- **Sauvegardes et génération** : toute nouvelle version de terrain, dimension, extension ou récupération exige son périmètre et, si nécessaire, un contrat de migration. Aucun sondage n’autorise à effacer ou régénérer une partie existante.
+- **Intégrations** : disponibilité, licence, dépendances et comportement réel de Sodium, Iris, Simple Voice Chat, Litematica, Golden Days ou autres pistes sur la version exacte. Le besoin peut être voté ; la compatibilité se vérifie au moment du ticket.
+- **Canon et révélations** : nature de l’ancienne découverte, sacrifice et dénouement, détail des journaux et énigmes. On peut coécrire avec des volontaires avertis, sans dévoiler les réponses à tous pour choisir leur mode de découverte.
+- **Direction artistique** : formes d’arbres, silhouettes de lieux, variantes de Moobloom, graphismes de Cape Zéro, vocabulaire FR/EN et palette du pack. Après les attentes d’usage, présenter quelques exemples concrets permettra de décider plus utilement que des noms seuls.
+- **Exploitation et Master Key** : rôles de maintenance, diagnostics, réparation et journalisation ; état du canal de distribution, compatibilité client/serveur et limites de performances. L’administrateur doit pouvoir réparer un incident sans transformer les récompenses de jeu en droits opérateur.
+
+## 9. Livraison de cette analyse
+
+Trois fichiers documentaires ajoutés : analyse, banque complète et extrait de démarrage. Les changements préexistants ont été conservés ; aucun code, version binaire, manifeste, monde, serveur, canal packwiz ou instance Prism n’a été modifié par cette tâche. La branche documentaire conserve l’état de travail déjà présent ; elle ne constitue pas un commit isolé de l’ensemble des modifications antérieures.
+
+La vérification de livraison porte sur les **120 identifiants uniques**, les blocs à copier, leur longueur, les liens locaux et la couverture des familles de la vision. Les hypothèses sont signalées et les propositions de réponse ne valent ni résultats de sondage ni décisions validées. Une modification documentaire seule ne nécessite ni incrément beta ni construction Gradle.

docs/consultation-discord-premiere-serie.md

@@ -0,0 +1,181 @@
+# Sanctuary — les 12 premiers posts Discord
+
+Extrait préparé le 14 septembre 2026. Copier uniquement les blocs de texte. Publier les deux souvenirs en premier, puis avancer avec un ou deux sujets ouverts à la fois. Les numéros renvoient à la [banque complète de 120 posts](consultation-discord-posts.md).
+
+L’[analyse documentaire](consultation-discord-analyse.md) donne les sources, les décisions encore ouvertes et les points déjà réglés dans la bêta. Aucun message n’a été publié.
+
+## Message d’ouverture
+
+```text
+J’aimerais construire la suite de Sanctuary avec les personnes qui y ont joué.
+
+Je vais poster des questions petit à petit. Certaines parlent de vos souvenirs ; d’autres présentent une mécanique envisagée pour la suite. Quand quelque chose existe déjà dans la bêta, je le préciserai.
+
+Vous pouvez répondre avec une lettre, proposer autre chose ou raconter une situation vécue. « Je ne sais pas » et « ça ne m’intéresse pas » sont aussi utiles. Si vous parlez d’une ancienne partie, indiquez laquelle si vous vous en souvenez.
+
+Ce qui m’aide le plus : votre préférence et ce qu’elle changerait dans votre façon de jouer. Les votes me guideront ; les désaccords et les essais en jeu compteront aussi.
+```
+
+### P01 — Le souvenir à retrouver
+
+Souvenir libre · À publier avant les sondages de fonctionnalités.
+
+```text
+Quel moment vécu sur Sanctuary aimerais-tu pouvoir revivre dans la nouvelle version ?
+
+Raconte une scène précise : ce que tu faisais, avec qui, et ce qui l’a rendue mémorable. Ça peut être une construction, une découverte, un accident, une rencontre ou un truc complètement idiot.
+```
+
+### P02 — Ce qui te faisait décrocher
+
+Souvenir libre.
+
+```text
+Qu’est-ce qui t’a déjà fait perdre l’envie de te connecter à Sanctuary ?
+
+Une situation concrète m’aidera plus qu’une liste de fonctionnalités manquantes. Ça peut venir du jeu, du rythme du serveur ou de la vie du groupe. Pas besoin de nommer quelqu’un.
+```
+
+### P03 — La priorité à protéger
+
+Question déduite · Arbitrage entre les piliers de la vision.
+
+```text
+Si je dois protéger une seule qualité de Sanctuary dans les prochains développements, laquelle doit passer en premier ?
+
+A — L’exploration et les découvertes surprenantes.
+B — La construction et les grands projets communs.
+C — La progression, la production et les échanges.
+D — La vie du groupe, les rencontres et les moments absurdes.
+```
+
+### P06 — Revenir après une absence
+
+Question déduite · À traiter avant les coûts collectifs et le calendrier.
+
+```text
+Si tu reviens après deux semaines d’absence et que les autres ont beaucoup avancé, qu’est-ce qui t’aiderait le plus à reprendre ?
+
+A — Profiter immédiatement des infrastructures et des accès ouverts par le serveur.
+B — Avoir un parcours personnel de rattrapage plus court.
+C — Retrouver des activités utiles au groupe dès mon niveau actuel.
+D — Rejouer les grandes étapes manquées avec d’autres volontaires.
+```
+
+### P08 — Le départ fragile
+
+Retour sur l’existant · Ne propose pas de rétablir l’ancien minage ralenti.
+
+```text
+Dans la bêta, on commence avec 3 cœurs, une petite réserve de faim et d’air, et 9 cases d’inventaire. Le minage de départ garde la vitesse Minecraft normale ; les premiers gestes donnent un peu d’XP.
+
+Quel ressenti voudrais-tu pendant la première heure ?
+
+A — Une vraie fragilité qui rend l’entraide nécessaire.
+B — Un départ exigeant, avec un abri et les premiers progrès rapidement accessibles.
+C — Une mise en route assez confortable ; le danger vient ensuite de l’exploration.
+D — Il me faut un essai de cette bêta pour me prononcer.
+```
+
+### P12 — Fonder une faction avant le prestige
+
+Retour sur une règle livrée · Une évolution demanderait une décision explicite.
+
+```text
+Aujourd’hui, fonder une faction demande une charge gagnée en terminant un cycle. La faction commence à deux places ; ses invités n’ont pas besoin de prestige.
+
+À quel moment voudrais-tu pouvoir créer ton groupe officiel ?
+
+A — Dès l’arrivée ; le prestige servirait ensuite à le développer.
+B — Après un petit objectif collectif accessible en début de partie.
+C — Après le premier cycle, comme dans la bêta actuelle.
+D — Les groupes informels me suffisent ; la faction peut rester tardive.
+```
+
+### P19 — Ce que doit apporter une nouvelle île
+
+Choix ouvert · Distinction essentielle avec les quatre expéditions déjà ouvertes.
+
+```text
+Les nouveaux mondes ont déjà quatre îles d’expédition accessibles : boréale au nord, tropicale à l’est, aride au sud et océanique à l’ouest. Leur accès ne demande pas de déblocage collectif.
+
+Qu’est-ce qui justifierait le mieux de financer ensuite un nouveau continent ?
+
+A — Des ressources impossibles à trouver ailleurs.
+B — Un lieu de mystère, un donjon ou une nouvelle étape de l’histoire.
+C — Un nouveau territoire pour construire et s’installer.
+D — Un environnement qui permet de nouvelles cultures et productions.
+```
+
+### P21 — Qui choisit l’expansion
+
+Choix ouvert · Gouvernance à fixer avant les dépenses collectives.
+
+```text
+Une future installation permettra aux joueurs d’ouvrir un continent. Qui devrait décider du projet à financer ?
+
+A — L’ensemble du serveur, par un vote ouvert.
+B — Les personnes qui contribuent à ce projet.
+C — Chaque faction, pour ses propres expéditions.
+D — N’importe quel groupe qui construit l’installation et réunit les moyens.
+```
+
+### P31 — Une maison sans faction
+
+Choix ouvert · Demeure n’est actuellement pas une protection.
+
+```text
+La bêta sait montrer les lieux habités avec Demeure, mais ne protège pas encore les constructions par des claims.
+
+Comment voudrais-tu protéger ta première maison ?
+
+A — Un petit terrain personnel gratuit dès l’arrivée.
+B — Un terrain personnel gagné après quelques activités de début de partie.
+C — Une protection fournie par une faction que je rejoins.
+D — Des règles de voisinage et une intervention humaine en cas de problème.
+```
+
+### P37 — La place du PvP
+
+Choix ouvert · À trancher avant armes, familiers et braquages.
+
+```text
+Quelle place voudrais-tu donner aux combats entre joueurs dans Sanctuary ?
+
+A — Des duels acceptés par les deux personnes.
+B — Des arènes ou événements annoncés.
+C — Des conflits de factions déclarés, dans des zones et périodes précises.
+D — Un danger possible dans les territoires sauvages, avec des refuges protégés.
+```
+
+### P71 — Obtenir son premier familier
+
+Choix explicitement ouvert · Les pouvoirs sont livrés, leur acquisition normale en survie reste à concevoir.
+
+```text
+La bêta possède déjà les pouvoirs de 88 familiers, mais leur obtention en survie reste à construire.
+
+Comment voudrais-tu obtenir ton premier œuf de familier ?
+
+A — En prenant soin d’un animal ou en réussissant une interaction avec son espèce.
+B — En terminant une petite quête dont la récompense est connue.
+C — En découvrant un lieu ou un coffre, avec une part de surprise.
+D — En choisissant un compagnon de départ, puis en recherchant les suivants.
+```
+
+### P85 — Une réussite collective
+
+Choix ouvert · Ne révèle pas le dénouement narratif.
+
+```text
+Quel accomplissement te ferait dire « on a vraiment réussi cette aventure Sanctuary ensemble » ?
+
+A — Avoir transformé les îles en un monde habité et relié.
+B — Avoir résolu le grand mystère de ce monde.
+C — Avoir rendu possibles des constructions et techniques extraordinaires.
+D — Avoir créé une communauté dont les projets continuent sans objectif final imposé.
+```
+
+## Après ces premiers retours
+
+Choisir la prochaine série selon les réponses : progression, voisinage, expansion, familiers ou récit. Le [modèle de retour sur une discussion](consultation-discord-posts.md) permet ensuite d’annoncer une règle provisoire et l’essai qui servira à la vérifier.

docs/corrections-beta036.md

@@ -0,0 +1,121 @@
+# HUD-036 — notifications choisies, vol porté et discrétion
+
+Branche `codex/hud-gliding-stealth-beta036`, base beta.035.
+Cible inchangée : Minecraft 26.3-pre-2, Java 25.
+
+## Contrat jouable
+
+Les notifications démarrent **en haut à droite**. Options → Notifications propose
+les neuf ancrages : quatre coins, quatre milieux de bord et centre. La préférence
+locale existante est conservée ; les fichiers antérieurs sans position prennent
+le nouveau défaut. Aucun réglage de quête n’est ajouté.
+
+Les colonnes F3 et les annonces natives réservent leur surface réelle, mesurée
+sur la même image, y compris avec une échelle F3 différente. Le fil reste dans
+la colonne choisie, se place dans une zone libre et réduit le nombre de lignes
+si nécessaire. Barres de boss, sous-titres et ensemble vie/XP/hotbar réservent aussi
+leur place. Quand aucun emplacement lisible ne reste, les messages attendent ;
+le profiler circulaire et la visualisation de chunks suspendent le fil. F1, les
+menus et les écrans de chargement le masquent également.
+
+Un advancement commencé ne reste **plus suivi automatiquement à vie**. Ses
+nouveaux progrès s’effacent comme les découvertes (durée réglable 3–15 secondes,
+5 par défaut, plus deux secondes pour les progrès). Un état inchangé ne relance
+pas le délai. La mort et la réapparition effacent le fil temporaire sans rejouer
+les anciens critères ni les découvertes.
+
+Dans **Advancements**, cliquer sur une icône visible et incomplète l’épingle ;
+cliquer à nouveau retire le suivi. Un `+` doré marque l’icône et une indication
+FR/EN explique le geste. Glisser la carte de l’arbre ne bascule jamais le suivi.
+Jusqu’à **trois objectifs** sont choisis ; un quatrième remplace le plus ancien.
+Les critères reçus du serveur alimentent les jauges, même avant le premier
+critère réussi. Une réussite complète retire automatiquement l’épingle.
+Le choix survit à la mort et à la reconnexion, séparément pour chaque compte
+et monde local ou adresse de serveur. Les préférences restent uniquement dans
+`config/sanctuary-notifications.json` ; les clés de contexte sont hachées.
+L’option Objectifs épinglés masque ces suivis sans oublier la sélection.
+Les progrès récents non épinglés gardent leur bref affichage temporaire.
+
+## Déplacements
+
+Porter un animal volant sur sa tête permet de **planer automatiquement pendant
+la descente** : vitesse verticale plafonnée à 0,12 bloc/tick, sans impulsion vers
+le haut. Les poules comptent parmi les oiseaux qui amortissent la chute. Les
+familiers utilisent l’espèce de leur œuf. Le compagnon doit réellement être porté ;
+un animal proche ou simplement suiveur ne suffit pas. Le ralentissement dû au
+portage reste appliqué. Le vol créatif, les élytres, l’eau et la lave conservent
+leur fonctionnement. Une pile de joueurs ne transmet pas ce pouvoir à son socle.
+
+La distance de chute accumulée est effacée pendant le plané. Relâcher l’animal
+rétablit immédiatement la gravité et l’accumulation d’une nouvelle chute : aucune
+potion persistante ni immunité générale aux dégâts.
+
+Allongé ou au repos **au sol**, le joueur réduit de moitié sa visibilité dans
+les tests natifs de détection des mobs. L’effet se combine avec les règles
+Minecraft déjà présentes. À proximité, les mobs peuvent encore détecter et
+frapper. Le plongeon, la nage et le vol ne procurent pas ce bonus. Les cibles
+existantes ne sont pas effacées de force. La petite silhouette native demeure,
+y compris son intérêt face aux flèches ; aucun changement de visée des squelettes.
+
+## Compatibilité
+
+Aucun changement de schéma des sauvegardes serveur, des identifiants de jeu, des
+récompenses, des recettes, des générations ou des expansions. Les deux préférences
+client nouvelles et le suivi restent hors des mondes. Aucune installation de jeu
+personnelle n’est mise à jour par ce ticket.
+
+## Suite, non implémentée ici
+
+- Quêtes en haut à gauche : après les blocs rubis/saphir et leur contrat serveur.
+- Temps réel : horloge et fuseau système automatiques en solo ; fuseau choisi
+  dans la configuration serveur en multijoueur. Une région solaire approximative
+  choisie séparément doit déterminer latitude/saison/date, lever et coucher du
+  soleil. Le fuseau seul ne suffit pas à déterminer la géographie. Ne pas demander
+  d’adresse personnelle, ne pas collecter la géolocalisation ni publier une position
+  précise. Définir avant implémentation le profil solaire de secours en solo,
+  les changements d’heure, le passage de minuit et la migration du temps des mondes.
+
+## Vérifications
+
+`./gradlew check build assemblePack assembleTestPack` réussi avec les suites
+ciblées `corrections,notifications,carry,movement,progression,recipes,collections` :
+**36 tests serveur**, dont la matrice des 126 advancements de collections.
+Le contrôle de géométrie couvre 180 combinaisons et les collisions F3/toasts/boss/HUD.
+
+Deux parcours client natifs réussissent sur des mondes plats de développement :
+- « A Balanced Diet » après rotten flesh expire ; clic/re-clic/glissement de
+  l’arbre, épingle conservée après respawn et retirée après réussite.
+- 36 combinaisons GUI/position avec F3, son échelle indépendante, boss, hotbar,
+  réglages enregistrés et écrans FR/EN inspectés visuellement.
+- Vraie descente du joueur avec un perroquet porté et atterrissage sans dégâts.
+- Sorties des collections Archery, Woodworking, Boats and Rafts et Books and
+  Storage trouvées dans le filtre JEI ; ouverture des vraies recettes arc,
+  établi, bateau et livre sans possession préalable, avec inconnus préservés.
+
+La persistance du choix est contrôlée dans le fichier client ; la mort/respawn
+est exercée en jeu. La conservation à la reconnexion utilise ce même contexte
+chargé au retour, sans parcours supplémentaire de redémarrage pour ce ticket.
+La discrétion est contrôlée par les tests de détection natifs côté serveur ;
+l’équilibre face à plusieurs mobs en partie reste à apprécier.
+
+Exports locaux vérifiés : [normal](../build/Sanctuary-beta.036.mrpack) et
+[monde plat rapide](../build/Sanctuary-Test-beta.036.mrpack). Les 1 335 classes du
+mod, les trois classes du module de test, les JAR imbriqués et les ressources
+correspondent au build. Les collections et générations restent identiques ;
+les packs beta.034/beta.035 sont inchangés.
+Reçu : `build/corrections036-artifact.json` ; captures :
+`build/corrections036-evidence/`. Logs : `build/corrections036-check-final.log`,
+`build/corrections036-client-options-final.log`, `build/blueprint036-client.log`.
+
+## Retour JEI intégré
+
+Une collection pouvait enseigner ses recettes tout en laissant leurs sorties
+masquées dans le catalogue d’objets de JEI. La recherche de l’arc, d’un bateau ou
+d’un livre restait donc impossible tant que le joueur ne l’avait pas possédé.
+
+Les sorties des recettes connues deviennent désormais consultables dans JEI.
+Leur index se reconstruit sur changement du carnet ou du runtime, pas à chaque
+image. Cela n’ajoute aucune possession au carnet Discovery, ne révèle pas les
+matières premières inconnues et ne débloque aucune autre recette. L’aptitude
+Catalogue reste nécessaire. Les définitions de collections côté serveur,
+récompenses et format de carnet restent inchangés ; pas de changement du fork JEI.

docs/cosmologie.md

@@ -0,0 +1,338 @@
+# Sanctuary — matière, espaces et mémoire
+
+**Cahier de conception issu du texte de l’auteur.** Il prolonge
+[la vision](vision.md) et [la conception des lieux](structures-conception.md).
+Les citations conservent les formulations fournies ; les points à préciser
+sont identifiés comme tels. Ce document ne livre aucun générateur ni système
+économique. **Backrooms, Indoors, shop et ballast ne sont pas implémentés.**
+Le Blocodex natif de l’alpha.23 locale fournit un premier socle de données
+pour des mécaniques futures, avec les limites décrites dans [son contrat](blocodex.md).
+
+## Minecraft comme archéologie d’un autre Minecraft
+
+Steve, Ari, Sunny, Kai, Zuri, Alex, Efe, Makena et Noor sont les neuf personnages
+disparus de la partie. Ils ont découvert quelque chose de révolutionnaire et ont
+continué parce que ça marchait. Jusqu’au moment où ça n’a plus marché.
+
+> Ils n’ont pas ouvert quelque chose qu’ils n’auraient pas dû ouvrir. Ils ont
+> construit quelque chose qu’ils ne savaient plus refermer.
+
+L’histoire part de quelque chose qui a fonctionné : des besoins satisfaits, des
+lieux devenus utilisables, des opérations répétées et des installations agrandies.
+Une ruine doit permettre de retrouver cette ancienne solution. Ses circulations,
+ses raccords, ses réparations et ses extensions racontent un fonctionnement avant
+de raconter son interruption.
+
+> Chaque ruine de sanctuary doit être une trace d’une ancienne solution pas
+> seulement la trace d’un problème.
+
+Le dialogue fourni par le créateur pour la bêta.001 précise leurs rôles.
+Il emploie **Efe**, retenu ici à la place du « Mefe » de la première note.
+Kai et Efe sont jumeaux ; Steve et ses amis sont des héros trans. Cette dimension
+doit rester présente avec naturel, dans leurs relations et leurs actes.
+
+| Personnage | Rôle ou lien retenu dans les notes |
+| --- | --- |
+| Makena | Cuisine |
+| Sunny | Redstone |
+| Kai et Efe | Construction |
+| Zuri | « Exploitation », dont le sens et les limites restent à préciser |
+| Ari | Villageois |
+| Noor | Aventure |
+| Alex | Lien avec Steve, à développer |
+| Steve | Sacrifice et protection des joueurs |
+
+Dans cette fiction, Steve a contenu Notch en s’enfermant avec lui. Le
+**Galactium**, vide qui structure les mécaniques de Minecraft, est envisagé
+comme le lieu de son isolement. Alpha, Backrooms et un double laissé derrière
+lui participent aux pistes de dissimulation. Les compagnons disparus pourraient
+subsister comme apparitions et interlocuteurs de marchés particuliers.
+
+Des pages de journaux propres à chaque personnage permettraient de rapprocher
+des récits incomplets : leur lecture collective ferait comprendre l’histoire.
+Le retour de Steve, la transformation ou la défaite de Notch et les conséquences
+pour les joueurs restent des questions ouvertes. Les discussions autour du
+créatif ou d’un nouveau cycle ne fixent pas encore une fin de partie.
+Ces éléments concernent les personnages de la fiction Sanctuary.
+
+Les [quatre anciennes expéditions](expeditions-beta001.md) reprennent pour leurs
+noms Noor, Makena, Kai et Efe, Ari. Cela n’attribue pas automatiquement à chacun
+une machine, une gemme ou une quête. Les journaux à collecter, apparitions, boss
+et pouvoirs décrits ici ne sont pas implémentés dans ce ticket.
+
+## Les doubles de Steve — conception du 15 septembre 2026
+
+Les [trois doubles décrits dans ANO-01](steve-anomalies.md) sont des anomalies
+de Sanctuary. **Ils ne sont pas encore implémentés.** Leur origine détaillée
+reste à découvrir au fil de l'histoire.
+
+- **Herobrine** se cache dans les Backrooms. Il peut frapper, poser des blocs,
+  enfermer un joueur, avancer ou attendre derrière lui qu'il se retourne.
+  Au moment où le joueur le voit, il disparaît.
+- **Le mineur fantôme** creuse des galeries dans l'Overworld **et** les Backrooms,
+  surtout dans les chunks les moins marqués par Demeure. De face comme de dos,
+  on voit l'arrière de sa tête.
+- **Le Steve bugué** est extrêmement rare, en T-pose avec des UV mal placés.
+  Une fois trouvé, il reste ; on peut l'embarquer dans un bateau et le déplacer.
+  Cette présence durable constitue une preuve que Steve existe. Ses lieux
+  d'apparition restent à définir.
+
+Herobrine laisse des effets puis disparaît ; le mineur laisse des galeries ;
+le Steve bugué peut être conservé et montré aux autres. Ces comportements
+n'attribuent pas d'avance à l'un des doubles l'identité du Steve originel.
+ANO-01 distingue les décisions du créateur des modalités techniques proposées.
+
+## Deux devenirs de la même technologie
+
+Les Indoors et les Backrooms appartiennent à la même logique de fabrication des
+espaces. Ce qui les distingue est leur relation à une intention et à une
+référence : sait-on encore pourquoi cet espace existe et comment le retrouver ?
+
+| Espace | Direction donnée par l’auteur | Conséquence pour la conception |
+| --- | --- | --- |
+| **Indoor** | « espace artificiel référencé et contrôlé » | Un intérieur est produit intentionnellement et reste associé à son accès et à son usage. Une porte peut mener à un espace dix fois plus grand que le bâtiment extérieur. |
+| **Backroom** | « espace artificiel orphelin » | Un espace demeure alors que sa destination ou sa raison d’être a disparu. Sa forme peut conserver les restes d’une fonction sans retrouver l’ensemble auquel elle appartenait. |
+
+L’auteur décrit chaque Indoor comme une petite dimension instanciée. Les
+computers utilisent **probablement** cette technologie pour leurs expériences :
+cette relation est une piste forte, sans avoir encore de protocole ni de machine
+définitivement assignée.
+
+Les Backrooms, dans cette cosmologie, ne sont pas une destination demandée au
+même titre qu’un monde. Elles sont ce que la machine produit lorsqu’elle ne sait
+pas où mettre quelque chose :
+
+- un espace généré puis annulé ;
+- une expérience interrompue ;
+- deux règles demandant deux états incompatibles ;
+- une room qui n’est plus référencée ;
+- une coordonnée qu’aucun monde ne revendique.
+
+> La machine ne détruit pas parfaitement les espaces. Elle les laisse derrière.
+> Backrooms.
+
+L’image du « garbage collector raté de Minecraft » exprime cette accumulation.
+L’arborescence proposée par l’auteur la représente ainsi :
+
+```text
+WORLD
+├── overworld
+├── caverns
+├── nether
+├── end
+├── sanctuary
+└── /unreferenced/
+    └── backrooms
+```
+
+C’est une représentation narrative, pas une arborescence de fichiers ni la
+liste des dimensions actuellement enregistrées par le mod. **L’espace orphelin
+est une fiction à mettre en scène.** Une réalisation Minecraft devra conserver
+des espaces correctement sauvegardés, identifiés et référencés côté serveur.
+Le choix entre dimensions techniques et régions d’un espace partagé reste à
+concevoir. Rien ici ne prévoit de perdre de vraies références de sauvegarde,
+de supprimer des chunks ou de provoquer leur corruption pour obtenir cet effet.
+
+## De la matière sans contexte
+
+Le système reçoit des matériaux et tente de les réorganiser en espace valide :
+
+```text
+stone stone dirt copper oak_planks iron stone glass ...
+```
+
+Il possède de la matière, mais aucune destination n’a été demandée. Il tente
+alors de l’encoder sous forme de chunks : un couloir, une salle, encore une
+salle, un plafond, une porte donnant sur rien, une plomberie sans bâtiment,
+un entrepôt infini.
+
+> Les Backrooms sont la tentative du générateur de Minecraft de faire quelque
+> chose avec de la matière sans contexte.
+
+La **matière** donne une palette et une présence physique. Le **contexte** lui
+donnait un usage, des dimensions, des voisins, un accès ou une destination.
+Cette distinction permet de dessiner un lieu dont les parties sont intelligibles
+alors que leur assemblage ne retrouve plus son intention : une plomberie garde
+sa logique de raccord, mais le bâtiment qu’elle devait desservir n’est plus là.
+Elle ne justifie pas de remplacer la conception par des blocs placés au hasard.
+
+Il reste à définir ce que la machine conserve de ce contexte : seulement les
+matériaux, des fragments de plans, des types de pièces, des relations entre
+espaces ou des traces d’opérations. Aucun catalogue de rooms ni algorithme de
+recomposition n’est arrêté. Les palettes limitées et le futur moteur de
+traduction en structures peuvent servir cette direction ; le moteur n’est pas
+créé par ce document.
+
+## Le ballast de l’économie
+
+La direction fournie relie directement cette cosmologie aux actions des joueurs.
+Utiliser le shop, téléporter, ouvrir des Indoors, déplacer de la matière ou
+expandre le monde produit du **ballast**. Plus ces opérations se multiplient,
+plus les Backrooms se remplissent. Elles deviennent l’externalité du système
+économique de Sanctuary : une activité visible laisse ailleurs des conséquences
+que ses utilisateurs pourront découvrir beaucoup plus tard.
+
+Le ballast relie donc production, échanges et géographie. Un objet déplacé ne
+change pas seulement de propriétaire ou de position dans cette vision ; son
+passage par ces technologies peut laisser une empreinte dans le monde.
+La forme de cette empreinte reste à décider pour chaque opération.
+
+| Opération envisagée | Articulation à définir avant de l’implémenter |
+| --- | --- |
+| Shop et échanges | Quel événement produit du ballast : vente, achat, consommation par un service, autre opération ? Quelle matière lui correspond et à quel moment l’échange est-il terminé ? |
+| Téléportation | Que laisse le déplacement : trace de matière transportée, coût matériel ou autre résidu à choisir ? Les types de téléportation partagent-ils cette règle ? |
+| Ouverture d’un Indoor | Que produit la création d’un espace contrôlé ? Que deviennent ensuite une fermeture, un transfert d’accès ou une expérience interrompue ? |
+| Déplacement de matière | Quelles opérations participent à cette économie ? Un transport manuel, un convoyeur, un stockage ou une transformation ne sont pas encore déclarés équivalents. |
+| Expansion | Comment la préparation et la création d’un continent se rattachent-elles aux matériaux engagés et aux espaces laissés derrière ? |
+
+« Ballast » ne fixe pas encore une quantité, une unité, un coût ou une monnaie.
+Il faut notamment décider s’il représente une matière effectivement retirée,
+une trace de son traitement ou les deux selon les opérations. Aucun taux de
+conversion ni conservation quantitative stricte n’est établi. Le document
+n’autorise donc pas à prélever des objets dans les inventaires ou à les dupliquer
+dans des coffres au nom de cette cosmologie.
+
+## Lire l’histoire économique dans la géologie
+
+La génération doit dépendre du comportement réel des joueurs. L’auteur donne
+trois exemples qui fixent la direction sans constituer des recettes de génération :
+
+| Histoire du serveur | Trace possible dans les Backrooms |
+| --- | --- |
+| Le serveur consomme énormément de pierre. | Les premières couches deviennent minérales. |
+| Une phase d’industrialisation utilise beaucoup de cuivre. | Des zones techniques apparaissent. |
+| Des tonnes de bois sont sacrifiées. | Un gigantesque Indoor abandonné peut émerger. |
+
+Des mois après, les joueurs peuvent descendre et reconnaître dans les lieux
+traversés une période de l’histoire du serveur. Le choix des matériaux doit
+pouvoir conserver une différence entre une phase minérale, une phase industrielle
+et d’autres formes de production, au lieu de tout réduire à la dernière palette
+dominante.
+
+Cette intention demande une temporalité explicite. Deux histoires se rencontrent :
+celle des neuf personnages, antérieure à l’arrivée des joueurs, et celle que le
+serveur écrit pendant la partie. La première fournit les vestiges d’un autre
+Minecraft ; la seconde peut produire de nouveaux dépôts et de nouvelles traces.
+La présence de strates initiales issues de l’ancienne partie, leur contenu et
+leur articulation avec les apports actuels restent à décider.
+
+Il faut encore choisir la durée des périodes observées, ce qui forme un dépôt,
+le moment où un dépôt devient un lieu et la manière dont les périodes se
+succèdent dans l’espace. Une couche n’est pas nécessairement un niveau vertical :
+la géographie de cette chronologie reste à dessiner. La règle devra préserver
+les espaces déjà visités et construits ; changer les statistiques actuelles ne
+doit pas devenir une régénération implicite d’anciens chunks.
+
+## Ce que le socle méta peut fournir
+
+Le Blocodex appartient à Sanctuary et peut être consulté par plusieurs mécaniques.
+Il distingue actuellement connaissance, observation, minage, possession passée,
+jet, pose et stock porté. Les critères de connaissance et les familles de
+matériaux peuvent aider un futur moteur à constituer une palette utilisable.
+
+Ces informations personnelles ne suffisent cependant pas à décrire l’histoire économique :
+
+- **miné** ne veut pas dire consommé par le shop ou engagé dans une machine ;
+- **jeté** compte les jets volontaires vanilla, pas les objets brûlés ou perdus
+  dans le vide ;
+- **déjà possédé** est une preuve persistante, pas un stock encore disponible ;
+- **posé** ne fournit pas à lui seul le plan d’une construction ni sa date ;
+- le stock personnel ne recense pas tous les coffres et réseaux du serveur.
+
+Le socle méta distingue maintenant trois relevés :
+
+| Relevé | Ce qu’il permet de connaître |
+| --- | --- |
+| Mémoire personnelle | Ce qu’un joueur a vu, miné, possédé, jeté ou posé ; des critères pour ses palettes. |
+| Distribution actuelle | Les blocs du terrain chargé et les stocks accessibles, comptés séparément avec leur couverture. |
+| Activité datée du serveur | Les quantités minées, posées, ramassées, jetées et fabriquées, agrégées par jour UTC depuis l’installation. |
+
+Le troisième relevé conserve une trace des périodes d’activité après le
+déplacement des stocks. Il peut montrer une période de minage intense de cuivre,
+mais ne prouve pas que ce cuivre a été sacrifié à une machine. Il ne reconstruit
+pas les mois précédant son installation et ne calcule aucun ballast. Les limites
+de persistance et de couverture figurent dans le [contrat méta](blocodex.md).
+
+Avant la génération historique, il faudra donc définir quels faits les systèmes
+économiques enregistrent : action réalisée, matériau, quantité, moment ou période,
+origine et destination utiles à cette action. Leur traitement devra distinguer
+une opération terminée d’une tentative refusée et éviter de compter plusieurs
+fois la même opération après reprise. La granularité, la conservation et le
+format de ces transactions restent à concevoir dans un contrat propre. Les
+agrégats journaliers déjà disponibles ne sont pas un journal transactionnel :
+ils ne doivent autoriser ni prélèvement, ni récompense, ni restitution d’objet.
+
+## Machines, références et anciennes solutions
+
+Les computers pourraient expérimenter dans les Indoors parce qu’ils offrent
+des espaces contrôlés. Il reste à préciser ce qu’ils demandent à un espace et
+comment cette demande le rattache à une installation, une porte ou un usage.
+La cause d’un orphelin dans la fiction devra être compréhensible sans demander
+au joueur de connaître les fichiers de sauvegarde.
+
+L’assembleur, le contrôleur, le terminal, le dépôt et l’ancre spatiale restent
+des concepts en discussion dans [le cahier des machines](structures-conception.md#ordinateurs-et-installation-dexpansion).
+Les questions communes sont maintenant plus précises : qui formule la demande
+d’espace, qui fournit sa matière, qui conserve sa référence, qui présente son
+état, et comment une fermeture ou une interruption est représentée ? Cette liste
+ne répartit pas arbitrairement cinq fonctions entre cinq blocs.
+
+Les ruines peuvent rendre ces questions visibles par leurs usages passés.
+L’observatoire, la salle d’expansion rééquipable, l’atelier caché et la grande
+traversée restent la sélection de conception actuelle. Pour chacun, il faut
+retrouver ce qui y était observé, préparé, fabriqué ou relié, puis montrer les
+extensions et le travail interrompu. Ce sont des questions de fiche de lieu,
+pas la confirmation de machines présentes ni d’un accès aux Backrooms dans
+chaque ruine. Le donjon majeur conserve son boss et son objet de quête à définir ;
+il n’est pas automatiquement identifié au réacteur ou à l’origine de la panne.
+
+La même ligne relie le passé et la partie actuelle :
+
+> une infrastructure dont l’auteur a progressivement disparu derrière son
+> fonctionnement.
+
+## Accès, retour et récupération : règles encore ouvertes
+
+**Décisions du 15 septembre 2026 :** le [ticket BR-01](backrooms-implementation.md)
+fixe désormais le parcours des salles personnelles : sommeil complet depuis son
+lit de l'Overworld, arrivée dans un Indoor de protection intégré aux Backrooms,
+passage caché par Steve derrière un tableau et une porte ouverte. Les Indoors
+interconnectés forment le dysfonctionnement où le ballast du monde est redirigé.
+Chaque salle est liée à un joueur et peut être découverte et visitée à pied par
+les autres. Tout lit utilisable dans les Backrooms ramène chaque joueur à son
+propre lit d'origine dans l'Overworld. Les lieux se cartographient manuellement,
+sans coordonnées affichées. **Implémentation prévue seulement après le suivi
+du ballast.** Les règles d'accès ci-dessous sont le cadrage antérieur ; BR-01
+les précise pour ce parcours. Récupération d'objets perdus, économie et Indoors
+généraux conservent leurs contrats à établir.
+
+La vision antérieure envisage le lit pour entrer dans les Backrooms, des sources
+de lumière pour les explorer et des coffres recueillant des objets perdus dans
+le vide ou brûlés. Elle prévoit aussi des accès d’Indoors liés à la mailbox de
+leur propriétaire. Ces intentions doivent être raccordées à la cosmologie du
+ballast ; elles ne définissent pas encore un parcours complet.
+
+Avant un ticket jouable, il faut notamment arrêter :
+
+1. Les moyens d’entrer, les destinations d’arrivée, le retour et le comportement
+   lors d’une mort ou d’une déconnexion.
+2. La propriété et le partage des Indoors, la perte de leur objet d’accès, leur
+   fermeture et la distinction entre un accès absent et un espace fictionnellement
+   devenu orphelin.
+3. Le rapport entre ballast, géologie et objets récupérables : quelle part fait
+   décor ou ressource, quelle part demeure un objet identifiable, et comment sa
+   récupération évite une restitution multiple.
+4. Les opérations qui alimentent réellement les dépôts, leurs unités, leur
+   cadence et les limites de stockage et de génération.
+5. Les indices permettant de lire une période économique ou une ancienne solution,
+   sans attribuer d’avance une cause à tous les lieux et aux neuf disparus.
+
+Les pool rooms et salles étranges physiques sous l’île restent des structures
+de l’Overworld. Leur ressemblance éventuelle avec les Backrooms ne les transforme
+pas automatiquement en espaces orphelins. Les passages entre ces lieux, les
+Indoors et les Backrooms devront être décidés explicitement.
+
+La prochaine étape de conception peut prendre un seul cas complet : une
+opération économique réelle, la trace qu’elle conserve, son dépôt, puis le lieu
+que ce dépôt permettrait de générer et d’explorer. Ce cas permettrait de fixer un
+premier contrat vérifiable sans prétendre que toute la cosmologie est déjà jouable.

docs/creative-construction-beta098.md

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

docs/cycle-factions-beta011.md

@@ -0,0 +1,172 @@
+# CYCLE-01 · PROG-03 · FACTION-01 · NGP-01 — beta.011
+
+Contrat commun établi avant l'évolution des sauvegardes. Branche :
+`codex/factions-new-game-plus`. Minecraft reste **26.3-pre-2**.
+
+> Historique beta.011. Depuis [beta.038](graves-food-beta038.md), la fondation
+> coûte 10 niveaux et crée une seule place, sans prestige ; les charges servent
+> aux places supplémentaires. Les anciennes fondations restent inchangées.
+
+## Règles de cette livraison
+
+Un cycle est personnel. Le premier porte le numéro 1. Seul un habitant vivant
+ayant les **six compétences au maximum** peut confirmer son New Game+.
+Les aptitudes ne conditionnent pas ce passage. Une mort ordinaire ne termine
+jamais un cycle et ne distribue aucune récompense de prestige.
+
+Valeurs initiales de `config/sanctuary/cycle-factions.json` : chaque passage
+accorde **1 prestige et 1 charge personnelle**. Créer une faction coûte
+**1 charge**, donne **2 places**, fondateur compris. Chaque membre peut payer
+**1 charge pour ajouter 1 place**. Le plafond de cette première version est
+100 membres. Le prestige compte les cycles achevés ; ce n'est pas une monnaie.
+Les charges inutilisées appartiennent à l'habitant. Les places financées
+appartiennent à la faction et restent après un départ ou un New Game+.
+Aucun remboursement lors d'une dissolution. Les règles monétaires sont
+configurables au redémarrage, mais ne recalculent jamais les anciens événements.
+
+Une personne appartient à une seule faction à la fois. Le propriétaire invite,
+révoque les invitations, exclut, transmet la responsabilité et dissout.
+Les invitations durent 7 jours réels ; elles ne réservent pas de place.
+L'acceptation revalide place, invitation et absence d'autre faction. Les membres
+peuvent partir ; le propriétaire doit transmettre ou dissoudre. Son absence
+ne transfère pas automatiquement la propriété. Le changement de propriétaire
+annule les invitations en cours. La couleur de faction est copiée de celle du fondateur à sa création ;
+la couleur personnelle reste indépendante.
+Les factions n'accordent encore ni claims ni protection de blocs.
+
+## Matrice du New Game+
+
+| Donnée | Traitement |
+| --- | --- |
+| Six compétences | Rang zéro : 3 cœurs, 3 nourritures, 3 bulles, gestes individuels, 9 cases |
+| XP non dépensée | Remise à zéro par défaut ; option serveur `keepXp` |
+| Identité, UUID, pseudo enregistré, bio, couleur | Conservés |
+| Aptitudes et preuves de leurs achats | Conservées |
+| Achats du cycle terminé | Archivés intégralement, coûts et dates compris |
+| Objets, équipement, main secondaire, coffre de l'Ender | Conservés, sans déplacement |
+| Rangées d'inventaire redevenues verrouillées | Occupées et visibles en récupération : retrait autorisé, nouveau dépôt interdit |
+| Recettes, découvertes, Atlas personnel, statistiques et advancements | Conservés |
+| Demeure, faction, rôle, invitations encore valides | Conservés |
+| Prestige et charges personnelles | Conservés, puis récompense du cycle ajoutée une seule fois |
+| Monde, constructions, coordonnées du joueur | Conservés ; aucune régénération ou téléportation |
+| Santé, faim, air courants | Bornés aux nouvelles capacités, sans soin gratuit |
+| Argent, coffre-fort, favoris, mémoire Web | Systèmes futurs ; ce ticket ne crée ni ne migre de données fictives |
+
+Exemple : Alice termine son premier cycle, obtient prestige 1 / charge 1 et
+fonde une faction de deux places. Bob la rejoint sans payer. Son propre premier
+New Game+ lui donne une charge : il l'investit et la faction passe à trois
+places. Au deuxième New Game+ d'Alice, son prestige devient 2 ; sa nouvelle
+charge reste personnelle et son rôle de propriétaire demeure. Ses 54 cases
+pleines ne sont ni effacées ni jetées : les 45 cases désormais verrouillées
+restent retirables jusqu'à leur prochain déblocage.
+
+## Contrat de migration et reprise
+
+L'adoption des progressions beta.003–010 est additive : schémas 1–5 vers
+**schéma 6**, avec `cycle: 0` (zéro cycle terminé). Aucun achat n'est perdu.
+La révision réseau vaut `cycle * 64 + nombre d'achats actifs`, empêchant qu'un
+ancien clic d'achat soit accepté après remise à zéro. Les identifiants existants
+restent stables. La capacité de configuration `sanctuary:cycle_factions_v1`
+exige la mise à jour des deux côtés avant de rejoindre.
+
+Le nouveau fichier `data/sanctuary-cycle-factions.json` est un journal de monde
+versionné (schéma 1), lié à la graine, contenant UUID de monde et événements
+datés identifiables. Il reconstruit soldes, factions et fins de cycle. Chaque
+mutation est validée sur une copie, écrite par remplacement atomique puis
+publiée en mémoire. Une erreur ou un fichier modifié extérieurement bloque les
+mutations ; aucune remise à zéro silencieuse.
+
+Un New Game+ écrit **d'abord** sa fin de cycle et sa récompense dans ce journal,
+puis applique la nouvelle progression au joueur. Au prochain chargement, si
+le journal a un cycle d'avance, sa décision est rejouée sur le joueur (avec
+sa politique XP enregistrée). Si les numéros concordent, rien n'est réinitialisé.
+Un joueur en avance sur le journal, ou en retard de plus d’un cycle, est
+refusé, ce qui détecte une restauration partielle incompatible. Le délai entre clics utilise une horloge monotone réelle (250 ms), indépendante
+des ticks suspendus dans le menu pause solo. Lire une page ne consomme pas
+le délai réservé à une mutation. Le solde d’XP est envoyé explicitement avec
+la progression pour rester exact pendant cette pause. Les tentatives répétées d'un même cycle ne donnent
+pas de charge supplémentaire. La sauvegarde vanilla conserve les objets et
+la progression dans le même fichier joueur, comme en beta.010. Les acquisitions
+d’objets entre deux sauvegardes restent soumises à l’autosauvegarde Minecraft :
+ce journal ne remplace pas la sauvegarde générale du monde.
+
+Faire une copie complète du monde arrêté avant adoption ; restaurer ensemble
+le journal, les fichiers des joueurs et les autres données du monde. Le retour
+aux anciens binaires après adoption n'est pas supporté. Ce contrat autorise
+l'évolution du code de lecture/écriture ; aucun monde personnel n'est modifié
+par les travaux de développement.
+
+## Livraison et vérifications
+
+Les contrôles du contrat pur passent : reprise beta.010, cinq/six compétences,
+conservation des aptitudes, deux cycles successifs, double requête, dépenses,
+propriétaire absent, invitations concurrentes, expiration exacte à sept jours,
+transmission, dissolution, relecture du journal et refus d'une écriture après
+corruption ou modification externe.
+
+Les sept scénarios natifs propres à beta.011 passent (8/8 avec l'admission
+Fabric), puis la suite progression/carte/Demeure/minage/construction/inventaire/
+cycles passe à **45/45**. Ils couvrent notamment :
+
+- Inventaire réellement rempli de 54 piles avant passage ; récupération dans
+  le menu natif, équipement et coffre de l'Ender conservés.
+- Retour à 3/3/3 sans soin offert, XP zéro, nouvel achat possible et ancien
+  paquet d'achat refusé grâce à la révision de cycle.
+- Identité, statistiques, observations Atlas et influence Demeure conservées.
+- Décision de fin écrite puis relecture d'un ancien fichier joueur ; après une
+  seconde sauvegarde, l'XP et les achats du nouveau cycle ne sont plus remis
+  à zéro. L'option de conservation XP est prise dans la décision enregistrée.
+- Mort ordinaire après New Game+ : même progression, prestige et faction.
+- Création, invitations par pseudo/UUID, contribution d'un membre, changement
+  de responsable, conteneurs ouverts et mode spectateur refusés.
+
+Le test de reprise a d'abord détecté un problème de fixture : chaque joueur
+simulé possède un nouveau profil d'authentification, que Minecraft rétablit au
+chargement. La fixture de reconnexion utilise maintenant le même UUID.
+
+Le parcours client natif `Cycle011ClientChecks` est compilé : ouvert depuis
+le menu pause, cycle verrouillé, aperçu/annulation, passage confirmé, création
+et journal, à deux échelles GUI. **Il n'a pas été exécuté graphiquement : le
+Mac est verrouillé. Aucun rendu beta.011 n'est déclaré vérifié.**
+
+La commande de livraison est :
+
+```sh
+JAVA_HOME=/Users/koka/Library/Java/JavaVirtualMachines/temurin-25.jdk/Contents/Home \
+./gradlew check build assemblePack \
+  -PsanctuaryFocusedTests=progression,map,demeure,mining,building,inventory,cycle
+```
+
+Les logs restent ignorés dans `build/cycle011-delivery-final.log`,
+`build/cycle011-smoke.log` et `build/cycle011-client-final-compile.log`.
+La commande finale réussit en **3 min 55 s**, avec les 45 tests natifs et
+les contrôles purs. Le reçu `build/cycle011-artifact.json` confirme l'intégrité
+ZIP, l'identité des JAR compilés et embarqués, les versions beta.011, les
+87 libellés FR/EN des cycles, les dépendances exactes et les assets conservés.
+Les exports beta.003–010 gardent leurs empreintes précédentes.
+
+Artefact local : `build/Sanctuary-beta.011.mrpack` — 2 479 614 octets.
+SHA-256 : `dae0d1fbd8f410fd73b2d3053ef0f17539e24639c3d338ce84dbfca6e4f43ec0`.
+
+L'export local ne publie pas le canal packwiz et ne modifie aucune instance Prism.
+
+## Essai en jeu
+
+Installer la même beta.011 côté client et serveur. Dans un monde de test,
+`/experience add @s 1000 levels` permet à un opérateur de tester les achats
+sans attendre. Acheter les quarante rangs des six compétences dans le Blocodex,
+puis ouvrir **Progression → Cycle**. Acheter les aptitudes reste facultatif.
+Remplir aussi les dernières rangées avant de confirmer pour vérifier leur
+récupération. Un second joueur peut rejoindre la faction via son invitation
+sans avoir lui-même fait de New Game+.
+
+Les invitations et les actions de faction se trouvent dans **Monde → Factions**,
+l'historique dans **Monde → Journal des cycles et factions**. Les montants
+s'éditent dans `config/sanctuary/cycle-factions.json`, serveur arrêté : `reward`,
+`creationCost`, `initialCapacity`, `expansionCost`, `maxMembers`, `keepXp`.
+Le prestige reste toujours le nombre de cycles terminés. Le journal est borné
+à 100 000 événements / 16 Mio ; il refuse d'effacer les anciennes archives
+pour faire de la place. Une future rotation nécessitera son propre contrat.
+
+Le journal fournit une ontologie locale (`sanctuary:cycle_completed`, `sanctuary:faction_*`) ; aucune
+connexion au site ni distribution de droits opérateur n'est incluse.

docs/daily-weather-beta057.md

@@ -0,0 +1,119 @@
+# beta.057 — météo quotidienne Sanctuary
+
+Branche `codex/daily-weather-beta057`. Contrat avant implémentation : une météo
+commune par date civile du monde, en réutilisant le fuseau du système Real Time.
+La météo est indépendante du mode du soleil : `vanilla` rend le cycle à
+Minecraft ; `realtime` conserve le profil choisi pour la journée. Les profils
+pluie et orage sont continus ; le profil averses alterne pluie et pauses sèches.
+
+Le tirage local est déterministe selon la graine du monde et la date, sans
+réseau ni géolocalisation. Les proportions de départ configurables sont :
+65 % beau temps, 15 % ciel gris, 5 % brouillard, 10 % averses, 3 % pluie
+continue et 2 % orage continu. Ce sont des probabilités par journée.
+Les proportions se règlent dans `config/sanctuary/weather.json` ; la prévision
+déjà enregistrée pour aujourd'hui ne change pas lors d'un rechargement.
+Les transitions d'intensité, sons, neige par biome et éclairs restent natifs.
+Le profil averses place une pluie de 35 à 75 minutes dans chaque tranche de
+3 heures réelles, avec des pauses sèches. La position de chaque passage est
+calculée depuis la graine/date/tranche ; une reconnexion ne la déplace pas.
+Les tranches comptent le temps réellement écoulé depuis le minuit local,
+y compris lors des journées de 23 ou 25 heures au changement d'heure.
+
+Le ciel gris et les averses atténuent les couleurs du ciel et la lumière solaire
+sans transformer artificiellement l'état sec en pluie. Le brouillard utilise
+les distances natives (fin atmosphérique 80 blocs, ciel 120, nuages 96) et se
+compose avec le réglage Vanilla Light. La transition des ambiances prend environ
+10 secondes de jeu. Eau, lave, cécité et obscurité gardent leurs attributs natifs.
+La présentation se branche sur les couches d'environnement de Minecraft :
+pas de nouvelle passe shader, texture de bruit, reconstruction des chunks ni
+rechargement des shaders. Les moteurs de shaders externes restent à vérifier.
+
+Le serveur transmet le profil aux clients à la connexion et lors de ses
+changements, y compris le retour à Vanilla. La pluie et l'orage utilisent leurs
+paquets natifs. Le calcul météo se fait une fois par seconde ; l'écriture du
+journal n'a lieu qu'au changement de date ou de mode.
+
+## Contrat de sauvegarde et de retour
+
+Un fichier additif `data/sanctuary-weather.json`, schéma 1, conserve le mode,
+la date civile et sa prévision. Il est écrit atomiquement avant toute action
+météorologique. Aucun ancien schéma ni paramètre de génération n'est modifié.
+Un document invalide est conservé ; le chargement refuse la prise de contrôle.
+
+Le mode quotidien est activé par défaut seulement dans les mondes Sanctuary
+et Sanctuary Test. Un monde vanilla ordinaire garde son comportement natif.
+Les jours manqués ne sont pas simulés. La reconnexion et le redémarrage gardent
+le profil du jour ; un nouveau profil est choisi à minuit dans le fuseau du
+serveur intégré ou dédié, et non à chaque journée Minecraft.
+
+Le cycle aléatoire et l'effacement de la pluie par le sommeil sont suspendus
+uniquement quand cette météo contrôle le monde. Les règles de jeu sauvegardées
+ne sont pas modifiées. Le retour à Vanilla reprend les durées natives depuis
+l'état météo courant, sans conserver une durée de 24 heures en ticks.
+Sans le mod, Minecraft peut reprendre ses durées usuelles. Les autres systèmes
+de simulation et les dimensions sans météo restent natifs.
+
+## Commandes et extension future
+
+Configuration serveur `config/sanctuary/weather.json` :
+
+```json
+{
+  "enabled": true,
+  "overcastPercent": 15,
+  "fogPercent": 5,
+  "showersPercent": 10,
+  "rainPercent": 3,
+  "thunderPercent": 2
+}
+```
+
+Le beau temps représente le reste jusqu'à 100 %. Une somme supérieure à
+100 %, un entier négatif ou fractionnaire et un document invalide sont refusés.
+Les nouveaux poids s'appliquent au prochain jour ; `enabled: false` rend
+immédiatement la météo au moteur après rechargement. Le retour explicite
+à Vanilla dans un monde est conservé même après réactivation globale.
+
+- `/sanctuary weather` : consulter le mode, la prévision et sa date/fuseau.
+- `/sanctuary weather realtime` : activer le mode quotidien (opérateur).
+- `/sanctuary weather vanilla` : reprendre le cycle Minecraft (opérateur).
+- `/sanctuary weather reload` : recharger les proportions/configuration (opérateur).
+
+En Real Time, `/weather` indique comment reprendre le mode Vanilla pour
+changer la météo librement. Les mutations passent par l'autorité serveur.
+La Weather TNT qui force ou arrête la pluie appartient au prochain ticket ;
+aucun nouveau bloc, explosif ni recette n'est ajouté ici.
+
+## Vérifications
+
+Le contrôle `weather057Smoke`, intégré à `check`, passe 222 058 assertions :
+50 000 tirages quotidiens, proportions, bornes, persistance, rechargement,
+refus des données invalides, retours de mode et absence de rattrapage hors ligne.
+Il vérifie aussi les tranches d'averses, leurs pauses sèches, les journées de
+23/25 heures et le 29 février. Les proportions observées sont respectivement
+32 451 / 7 558 / 2 478 / 4 914 / 1 522 / 1 077 jours pour beau temps / gris /
+brouillard / averses / pluie / orage.
+
+Le client intégré `Weather057ClientChecks` vérifie les six profils natifs,
+les paquets de pluie/orage et du nouveau profil, le brouillard réellement
+utilisé par le rendu, l'absence de pluie en gris/brouillard, l'alternance humide
+et sèche pendant une même journée d'averses, et les passages de date.
+Les durées aléatoires sont suspendues sans modifier la règle de jeu ; le reset
+météo utilisé par le sommeil est bloqué en Real Time et disponible en Vanilla.
+Les commandes, leurs permissions, l'indépendance du soleil, les configurations
+invalides, les retours Vanilla et les libellés FR/EN sont vérifiés.
+
+`./gradlew check build assemblePack assembleTestPack -x :sanctuary:runGameTest`
+réussit sur Minecraft 26.3-pre-2 avec Java 25. Les essais natifs utilisent
+`-PsanctuaryClientTests=true -PsanctuaryWeather057ClientTests=true
+-PsanctuaryQuickTests=true`. Aucun serveur dédié ni EULA supplémentaire accepté.
+Les frontières horaires sont simulées avec une horloge injectée dans le monde
+de test ; plusieurs journées d'hébergement réel ne sont pas revendiquées.
+Aucun monde personnel, canal public ou instance de jeu n'est modifié.
+
+Logs : `build/weather057-check.log`, `build/weather057-client.log`.
+Captures : `build/weather057-evidence/`. La confirmation d'intégrité des exports
+est consignée dans `build/weather057-artifact.json`.
+
+[Pack normal](../build/Sanctuary-beta.057.mrpack) ·
+[Monde plat rapide](../build/Sanctuary-Test-beta.057.mrpack).

docs/demeure-beta006.md

@@ -0,0 +1,41 @@
+# Ticket beta.006 — Atlas exploré et premières empreintes Demeure
+
+Résultat livré localement : déplacer la carte par glisser-déposer répété, découvrir un paysage progressivement, afficher une grille de chunks et consulter les empreintes d'habitation. L'utilisateur a choisi les empreintes et la grille ; réservation, factions et protection des chunks restent au prochain ticket.
+
+## Source et périmètre
+
+La référence signalée par l'inventaire 26.2 se trouve dans `../Structures/demeure` (sources ciblant Minecraft 26.1.2, auteur KOKA99CAB, GPL-3.0-or-later). Aucun changement dans ces dépôts historiques. Demeure reste un mod autonome sous `mods/demeure`, embarqué dans Sanctuary et adapté aux API exactes de 26.3-pre-2. Il fournit les empreintes, Sanctuary décide de l'accès à leur représentation dans l'Atlas.
+
+Ce premier port reprend les influences par chunk, la nature initiale, les états neutre/sauvage/habité/partagé/contesté/dominé/abandonné et les traces des déplacements, de l'activité, des blocs réellement posés ou cassés, des récoltes, du sommeil et des morts. La présence animale, villageoise et hostile est agrégée autour des habitants actifs. Nourrissage, naissance, cuisson, propriété animale individuelle et commandes historiques attendent leurs hooks de réussite et leur ticket. Aucun clic infructueux n'est crédité, aucune XP n'est distribuée par Demeure.
+
+## Contrat de migration et de confidentialité
+
+- Aucun changement de génération, de graine, de chunks, d'expansion, de progression ou d'identité d'habitant.
+- L'Atlas passe du schéma JSON 1 au schéma 2 lors de sa prochaine sauvegarde. Les 256 pixels de chaque ancien chunk restent connus. Dans le même tableau de couleurs, 0 signifie désormais inconnu, 1 représente le vide effectivement observé, 4..255 conservent les couleurs Minecraft. Les anciens pixels 0..3 sont convertis en 1. Cette conversion est idempotente et ne peut révéler aucun nouveau chunk. Les lecteurs beta.005 refusent le schéma 2 : retour arrière exige de restaurer une sauvegarde préalable.
+- Les nouveaux relevés découvrent les pixels dans un rayon de 32 blocs avec une bordure tramée, en lisant uniquement les chunks déjà chargés. L'union des observations est conservée dès l'arrivée, même avant l'aptitude Grande carte. Une absence de couleur n'efface jamais une ancienne découverte. Il s'agit d'une révélation cartographique de surface, pas d'un calcul de visibilité optique.
+- Les identifiants et le format des paquets `sanctuary:atlas_request` / `sanctuary:atlas_response` restent stables. Les empreintes utilisent un nouveau paquet séparé et borné. Le client et le serveur doivent utiliser le même pack pour la nouvelle interprétation du pixel inconnu.
+- Demeure crée un fichier distinct `data/demeure/footprints-v1.json`, indexé par dimension et chunk, lié à la graine. Aucun ancien fichier Demeure n'est importé ni modifié. Les premiers scores commencent à zéro lors du portage.
+- Les jours sont des jours UTC réels (horloge serveur), indépendants de `/time`. Une interruption ne simule pas d'activité. La décroissance après 14 jours d'absence est appliquée avant toute nouvelle contribution ; revenir ne ressuscite pas les anciens scores. Un recul d'horloge ne crée ni nouvelle journée ni nouveau budget.
+- Les contributions par sujet et chunk sont plafonnées à 8 par jour réel, conservées avec leur budget et date. Maximum 16 384 chunks, 32 influences par chunk, fichier limité à 64 Mio. Aucun effacement silencieux en cas de limite ou de corruption ; le service refuse d'écraser un fichier corrompu ou modifié extérieurement.
+- Une grille géométrique peut couvrir le brouillard ; aucun état Demeure n'est transmis pour un chunk inconnu. Le survol d'un pixel inconnu ne révèle pas l'empreinte. Une empreinte ne constitue ni propriété ni protection et ne dit pas qu'un chunk est juridiquement réservable.
+- La vue opérateur demeure explicite et vérifiée sur le serveur ; elle n'ajoute aucune découverte personnelle. Changement de rôle, de dimension ou de permission efface les données de la vue précédente.
+
+## Validation effectuée
+
+- `./gradlew check build assemblePack -PsanctuaryFocusedTests=progression,map,demeure` : réussi en 4 minutes, **8/8 tests natifs serveur**. Le test Demeure vérifie les placements réussis/refusés, la destruction native, l'aptitude carte, les chunks inconnus, les permissions opérateur et les spectateurs. Un premier lancement avait échoué dans le montage du faux joueur spectateur (connexion absente) ; ce montage a été corrigé puis les huit tests ont été relancés avec succès.
+- `./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true -PsanctuaryProgressionClientTests=true` : réussi en 1 min 37 s. Les glissements passent par `MouseHandler.onButton/onMove`, avec les constantes SDL de Minecraft, et non par des appels directs au gestionnaire de la carte. Plusieurs gestes, relâchement hors carte, zoom natif, nouvelle requête, rafraîchissement, deux tailles de fenêtre, activation de la grille, vrais paquets Demeure, inspection opérateur et révocation sont vérifiés.
+- Les tests de contrats vérifient les anciens pixels de vide conservés, la migration idempotente, l'union de visites, les pixels inconnus, les fichiers corrompus, la capacité et l'isolation. Demeure vérifie aussi le budget après rechargement, le recul d'horloge, la décroissance avant retour, les états du territoire et les dimensions distinctes.
+- Les fichiers produits par le client natif contiennent **16 chunks / 2 913 pixels connus** dans l'Atlas schéma 2, et un chunk Demeure schéma 1. La sauvegarde est constatée dans le monde de développement ; aucun monde personnel n'a été ouvert.
+- Captures inspectées dans `build/beta006-preview/`, notamment les interfaces à 640 et 1280 pixels, le brouillard et la carte verrouillée. FR/EN alignés ; aucun changement aux icônes ni aux noms de couleurs approuvés.
+- La sélection native cible ce ticket et la progression. Les deux assertions worldgen générales déjà connues en beta.003/005 ne sont pas revendiquées corrigées. Réservation/protection des claims, factions et port complet des interactions Demeure restent hors de cette livraison.
+
+## Artefact d'essai
+
+[Sanctuary-beta.006.mrpack](../build/Sanctuary-beta.006.mrpack), **2 298 722 octets**.
+Le mod Demeure autonome est inclus dans le JAR Sanctuary via la déclaration Fabric `jars` ; l'assemblage contrôle son identité et sa licence. Aucun second fichier n'est à installer manuellement.
+
+- SHA-256 MRpack : `ef8499de78461e7eab7bafe3d1ccf38a2d06ec3a0e0884e8e10ffe30fc63071f`.
+- SHA-256 Sanctuary : `40f674ca491c1f7e12c0d5dd8994e01e7f998a079fa1853960cfc609c5d0fec6`.
+- SHA-256 Demeure : `8993d777ca47f0a7a7a9425532606f772dfdb5db07d400c2adb4207346acd674`.
+
+ZIP, versions internes, dépendances exactes, JAR imbriqué identique au build, notices, ressources et index packwiz vérifiés. Les MRpacks beta.003, .004 et .005 gardent leurs empreintes. Reçu `build/demeure006-artifact.json` ; journaux `build/beta006-delivery-final.log` et `build/beta006-client.log`. Export local uniquement : aucune publication de canal ni synchronisation Prism.

docs/demeure-map-performance-beta026.md

@@ -0,0 +1,72 @@
+# beta.026 — affichage Demeure sans recalcul par image
+
+Ticket sur `codex/demeure-map-performance-beta026`.
+
+## Diagnostic et contrat
+
+La couche Demeure parcourait ses chunks puis les 256 blocs de chaque chunk
+visible à chaque image. Chaque bloc connu produisait un rectangle GUI distinct,
+y compris quand rien ne changeait. Le nombre de dessins dépendait donc de la
+surface explorée visible ; le bouton Demeure désactivait ce travail.
+
+La correction prépare une texture transparente de 1 024 × 1 024 pixels, alignée
+sur celle du terrain. Son rendu demande un seul dessin. Seuls les chunks dont
+les pixels connus ou la couleur Demeure changent sont repeints. Déplacer ou
+zoomer transforme l’image existante ; changer la fenêtre de chunks la reprojette.
+Les lots réseau identiques ne doivent provoquer ni effacement, ni nouvel envoi
+de texture au GPU. Une empreinte absente du lot suivant doit disparaître.
+
+Demeure reste activé par défaut. Ses règles serveur, contributions, scores,
+dates et sauvegardes restent inchangés. Aucun format de sauvegarde ou protocole
+ne change, aucun chunk n’est généré ou modifié par ce ticket. Les zones inconnues
+et le vide restent transparents, le changement de vue/dimension et la révocation
+des droits effacent également la couche Demeure. Les textures sont libérées à
+la fermeture de l’écran. Mémoire supplémentaire bornée : 4 Mio de pixels côté
+CPU et une texture RGBA8 de 4 Mio côté GPU.
+
+## Vérifications et limites
+
+Mesure native avant/après avec une même surface de 256 chunks de laboratoire,
+en comptant les rectangles, les transferts de textures et le temps CPU de
+soumission de la couche. Cas fixes, déplacement maintenu, couche masquée/réactivée,
+lots identiques et modifiés, brouillard, permissions, redimensionnement et fermeture.
+Les mesures de soumission ne sont pas une promesse de FPS sur chaque machine.
+
+`./gradlew check build assemblePack -PsanctuaryClientTests=true
+-PsanctuaryMapPerfClientTests=true -PsanctuaryFocusedTests=progression,map,demeure`
+réussit : **9 tests natifs serveur**, contrôles de contrats, compilation du
+parcours graphique et assemblage du pack. Journal : `build/atlas026-check.log`.
+
+Le parcours graphique préparé s’exécute avec :
+
+```sh
+./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true \
+  -PsanctuaryMapPerfClientTests=true
+```
+
+Il **reste à exécuter sur une session macOS déverrouillée**. Les essais de
+référence ont été interrompus au démarrage graphique, avant les mesures ;
+`IOConsoleLocked` était vrai. Aucun gain chiffré de FPS, temps CPU mesuré ou
+résultat graphique n’est revendiqué pour cette livraison. Le code Atlas de
+référence a été contrôlé identique au JAR beta.025 et conservé dans
+`build/atlas026-before.class` pour une comparaison ultérieure ; les autres
+contrôles serveur ne dépendent pas de l’affichage.
+
+La couche réutilise les mêmes couleurs et alpha par pixel : 0 pour l’inconnu
+et le vide, `0xA0` au bord des chunks, `0x25` à l’intérieur. Un changement de
+métadonnées sans changement de couleur met à jour le survol sans repeindre.
+Les paquets terrain et Demeure sont appariés dans l’ordre déjà garanti par
+`AtlasService.reply` ; le résumé Demeure, même vide, clôt son lot terrain.
+Le lot en attente est borné à 16 chunks et annulé au changement de requête.
+
+## Artefact local
+
+[Sanctuary-beta.026.mrpack](../build/Sanctuary-beta.026.mrpack), **4 766 675 octets**.
+SHA-256 : `f564aabbee977d48e8f3d0d2ea4178b23b18f33f42110ab0dba733f2ae008fbb`.
+Reçu : `build/atlas026-artifact.json`.
+
+ZIP, version, 1 253 classes Sanctuary, absence de tests embarqués et identité
+des JAR Demeure/JEI vérifiés. Seule la classe de l’écran Atlas diffère dans le
+code compilé Sanctuary par rapport à beta.025 ; les classes du module Demeure
+sont identiques. L’export beta.025 conserve son empreinte. Aucun canal, instance
+Prism ou monde personnel n’a été modifié.

docs/diagonal-caves-beta227.md

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

docs/diagonal-islands-beta225.md

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

docs/diagonal-lower-groves-beta230.md

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

docs/diagonal-relief-beta226.md

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

docs/diagonal-shaping-beta228.md

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

docs/diagonal-understory-beta231.md

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

docs/diagonal-wetland-beta229.md

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

docs/directional-lights-beta141.md

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

docs/discord-beta130-160.md

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

docs/dive-until-collision-beta028.md

@@ -0,0 +1,42 @@
+# beta.028 — plongeon jusqu’à collision
+
+## Contrat
+
+Un saut en sprint suivi de **S’allonger** (W par défaut, touche configurable)
+déclenche toujours une seule impulsion vers l’avant. La posture de plongeon
+reste active jusqu’au contact du sol, d’un mur, d’un plafond ou à l’entrée dans
+l’eau ou la lave. La limite automatique de 30 ticks (1,5 seconde) est retirée.
+Relâcher ou réappuyer sur la touche, utiliser Maj ou tourner la caméra ne fait
+pas sortir de la posture en plein vol. Le serveur décide de sa fin.
+
+La gravité, les dégâts de chute et les règles de nage restent natifs. Le
+plongeon ne permet pas une nouvelle impulsion après avoir touché un mur :
+il faut à nouveau partir d’un saut en sprint depuis le sol. Mort, vol, monture
+et autres états incompatibles interrompent toujours la posture. Les règles
+de collision natives empêchent de se relever à travers un plafond trop bas.
+
+Le même attachement temporaire `sanctuary:lying` et la même valeur 3 sont
+réutilisés. Aucun nouveau format de sauvegarde, aucune migration et aucun
+changement des mondes. Client et serveur beta.028 ensemble.
+
+## Vérifications
+
+**32 tests serveur natifs réussis**, dont 5 nouveaux tests : maintien pendant
+240 ticks avec posture native et demandes répétées,
+collisions réelles via le moteur (mur, plafond, sol), redépart après un nouveau
+saut, arrêt dans l’eau et conservation de la nage verrouillée, mort et vol.
+Régressions familiers, repos et piles de joueurs incluses.
+
+`./gradlew check build assemblePack -PsanctuaryFocusedTests=carry,familiar,movement`
+réussit en 3 min 47 s. La vérification visuelle reste à confirmer : session Mac
+verrouillée pendant cette livraison.
+
+Export local vérifié : [Sanctuary-beta.028.mrpack](../build/Sanctuary-beta.028.mrpack).
+Versions, intégrité ZIP, 1 253 classes compilées et JAR imbriqués vérifiés.
+Seuls DiveService, LyingService et LyingClient (et leurs classes internes)
+changent dans le code du jeu ; les aides FR/EN sont actualisées. Le portage,
+la carte et les autres systèmes conservent leur code beta.027.
+L’export beta.027 reste intact. Aucun déploiement effectué.
+
+SHA-256 MRpack : `531386776236e08cbeef8a26b77ccaf04533cce6bb47f695777190d0e94e5793`.
+Reçu : `build/dive028-artifact.json` ; vérificateur : `build/verify-dive028.py`.

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/dynamic-lights-beta030.md

@@ -0,0 +1,107 @@
+# LIGHT-01 — éclairage dynamique, beta.030
+
+## Contrat
+
+Les objets lumineux tenus en main principale ou secondaire, les cosmétiques de
+tête et les objets jetés éclairent le décor et les entités. Les autres joueurs
+sont des sources au même titre que soi. Un gâteau coiffé d'une bougie n'éclaire
+que si sa bougie est allumée ; les états des blocs font autorité.
+
+L'effet est visuel côté client, sans bloc artificiel, modification de sauvegarde
+ou changement des règles de spawn. La lumière utilise la teinte native de la
+lightmap ; ce ticket ne crée pas de lumière colorée ni d'ombres dynamiques.
+
+Les objets jetés dans une cellule de 4 × 4 × 4 blocs partagent une source :
+l'objet le plus lumineux la représente, à une position arrondie au demi-bloc.
+Les quantités des piles ne multiplient pas la lumière. Les sources immobiles
+ne provoquent pas de reconstructions répétées du terrain. Les calculs utilisent
+un instantané immuable indexé par section et une file de sections dédupliquée,
+traitée avec un budget par tick, sans chargement de chunks.
+
+## Utilisation et réglages
+
+L'effet est activé de base, sans aptitude. Il suit aussi les objets lumineux
+tenus par les créatures, leurs équipements de tête et les entités en feu.
+Les inventaires fermés, coffres et rangées non sélectionnées ne sont pas des
+sources. Les spectateurs n'éclairent pas les autres joueurs.
+
+`config/sanctuary-dynamic-lights.json` est créé localement au premier lancement.
+Le redémarrage du client applique les changements :
+
+| Réglage | Valeur initiale | Rôle |
+| --- | ---: | --- |
+| `enabled` | `true` | Active l'éclairage visuel |
+| `updateIntervalTicks` | 4 | Collecte des objets cinq fois par seconde à 20 TPS client |
+| `dropClusterSize` | 4 | Taille des cellules de regroupement des objets jetés |
+| `maxSources` | 32 | Sources les plus proches ; celle du joueur local est prioritaire |
+| `range` | 48 | Distance maximale de collecte autour de la caméra, en blocs |
+| `sectionUpdatesPerTick` | 12 | Maximum de sections marquées à mettre à jour par tick |
+| `itemOverrides` | `{}` | Intensité 0–15 par identifiant d'objet, par exemple `"mod:lampe": 12` |
+
+Les réglages numériques sont bornés pour éviter un coût accidentel démesuré.
+Contrôles → Sanctuary propose également « Activer / désactiver les lumières
+dynamiques », sans touche attribuée par défaut. Ce raccourci agit pour la session.
+Une désactivation éteint aussi les sections précédemment éclairées.
+
+Les objets-blocs utilisent leur émission native et leur composant `BLOCK_STATE`.
+Les bougies colorées et les gâteaux composites utilisent exactement l'état
+synchronisé du cosmétique. Hors blocs, le seau de lave émet 15, bâton/poudre de
+Blaze 10, poudre lumineuse/baies lumineuses 8, poche d'encre luisante/cadre
+luminescent 6. Une surcharge d'objet remplace explicitement ce comportement,
+y compris son état allumé/éteint ; 0 permet d'exclure un objet.
+
+## Portée technique
+
+Le rendu natif de Minecraft **26.3-pre-2** reçoit des coordonnées de lightmap
+enrichies : terrain et occlusion ambiante, eau, particules, blocs-entités et
+entités. La lumière du ciel et les surfaces déjà lumineuses sont préservées.
+Les tâches de reconstruction reçoivent chacune un instantané immuable.
+Les changements de monde et déconnexions abandonnent les sources précédentes.
+
+La décroissance est radiale, avec la lightmap habituelle de Minecraft : elle
+ne calcule pas d'occultation par les murs ni de couleur propre à chaque lampe.
+Les sources distantes au-delà du rayon ou du budget sont ignorées ; beaucoup
+de sources mobiles peuvent rendre leur suivi plus progressif. Un mouvement
+de caméra seul ne change pas la position d'une lampe portée.
+
+## Vérifications
+
+- Contrôles CPU : 10 000 objets dans une même cellule donnent une seule source,
+  plafonnement des sources, priorité locale, coordonnées négatives, sections
+  dédupliquées, budget strict, aucune invalidation après 500 mises à jour
+  immobiles, déplacement, suppression et conservation des instantanés des workers.
+- 100 000 requêtes d'éclairage comparées à une référence brute sans index :
+  mêmes résultats. Sur ce Mac M1, un million de requêtes sur l'index de stress
+  prennent 20–26 ms sur les exécutions de vérification ; c'est une mesure CPU
+  isolée, pas un résultat FPS.
+- Client natif réussi (`build/dynamic030-client-final.log`) : pièce fermée
+  sombre, torche principale, lanterne des âmes secondaire, bloc lumineux sur
+  la tête, gâteau allumé puis éteint, autre joueur avec lanterne, déplacement
+  du porteur et suppression des objets. Les coordonnées de lumière du moteur
+  de monde restent à zéro alors que le maillage et les entités s'éclairent.
+- 200 torches jetées fusionnent naturellement en quatre piles, toutes servies
+  par une seule source. Le courant déplace les objets ; l'éclairage les suit.
+  Après leur retrait, l'image redevient sombre. Neuf captures sont conservées
+  dans `build/dynamic030-evidence/`.
+
+- `./gradlew check build assemblePack -PsanctuaryFocusedTests=lights,cosmetics,familiarhit -PsanctuaryExpansionReload=true`
+  réussit : **21 tests serveur**, dont le registre complet des objets-blocs,
+  les états de bougies, le gâteau manipulé par un habitant et sa synchronisation.
+  Les régressions des cosmétiques et réactions des familiers passent également.
+  Log : `build/dynamic030-check.log`.
+- Le client natif est lancé avec `./gradlew :sanctuary:runClientGameTest
+  -PsanctuaryClientTests=true -PsanctuaryLightsClientTests=true
+  -PsanctuaryFocusedTests=lights`. Le dernier parcours complet réussit.
+
+## Livraison locale
+
+[Sanctuary-beta.030.mrpack](../build/Sanctuary-beta.030.mrpack), 4 792 058 octets.
+Version interne `beta.030`. Les 1 269 classes compilées correspondent au JAR
+embarqué ; aucune classe de test n'est distribuée. Le JAR JEI et les classes
+Demeure sont identiques à beta.029. Les classes existantes de Sanctuary restent
+identiques, hors l'initialiseur qui enregistre l'éclairage. L'archive beta.029
+est préservée.
+
+SHA-256 : `7942c661cbb01b5d0e4b6a59d9839e450223ab57aa3d45297c6816e884d70e80`.
+Reçu : `build/dynamic030-artifact.json`. Export local vérifié, sans publication
+du canal ni installation dans Prism.

docs/east-crater-beta224.md

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

docs/east-volcano-beta223.md

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

docs/ecosysteme-communaute-economie.md

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

docs/eroded-massif-beta192.md

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

docs/expansion.md

@@ -7,6 +7,25 @@ les commandes d’expansion dans le choix public **Sanctuary**. Le
 alpha.12/12.1 et leur [laboratoire](alpha12-laboratory.md) restent historiques.
 Le déblocage par recherches, XP et contributions n’est pas encore implémenté.
 
+## beta.001 — anciennes expéditions proches
+
+Les nouveaux mondes bêta commencent avec Sanctuary et quatre régions ouvertes
+de 512 blocs : nord glacial/Peaks, est tropical/Volcan, sud aride/Canyon et
+ouest humide/Océan. Leur [contrat de création](expeditions-beta001.md) est
+distinct de celui des anciennes sauvegardes.
+
+Dans ces mondes, les commandes cherchent au plus près sur l’axe choisi, par
+pas de 16 blocs, en conservant les marges écrites et les contrôles d’occupation.
+Le dernier argument `distance` reste une distance minimale **entre centres** ;
+`0` demande le placement automatique le plus proche admissible. Les commandes
+dans les mondes alpha conservent le placement précédent et son secteur aléatoire.
+Les quatre régions initiales se génèrent à l’exploration, comme Sanctuary ;
+les futures régions créées par commande gardent la préparation progressive.
+
+Avec les permissions opérateur : `/sanctuary expansion list` affiche les noms
+et identifiants ; `/sanctuary expansion visit noor_vigil` visite la région du
+nord. Les autres identifiants sont `makena_embers`, `kai_efe_rift` et `ari_waters`.
+
 ## Taille initiale et extensions — alpha.13
 
 Le bouton natif **Personnaliser** propose **Petit** (512 blocs de diamètre

docs/expeditions-beta001.md

@@ -0,0 +1,155 @@
+# beta.001 — les quatre anciennes expéditions
+
+Ticket local **EXP-01**, branche `codex/ancient-expeditions-beta001`. Ce contrat
+décrit la création des quatre anciennes expéditions. La préparation de versionnement BETA-01 est conservée
+dans cette première bêta, encore non publiée.
+
+## Les régions
+
+Répartition confirmée par le créateur :
+
+| Direction | Nom | Climat | Relief |
+| --- | --- | --- | --- |
+| Nord | La Veille de Noor / Noor’s Vigil | glacial | peaks |
+| Est | Les Braises de Makena / Makena’s Embers | tropical | volcano |
+| Sud | La Faille de Kai et Efe / Kai and Efe’s Rift | arid | canyon |
+| Ouest | Les Eaux d’Ari / Ari’s Waters | humid | ocean |
+
+Ces régions sont les traces d’expéditions des anciens personnages, ouvertes
+avant l’arrivée des joueurs actuels. Le relief de Sanctuary reste celui de
+l’alpha.30.7 ; les quatre régions utilisent les générateurs d’expansion existants.
+Leur diamètre nominal est **512 blocs chacune**, confirmé par le créateur.
+
+## Contrat de création et de sauvegarde
+
+- Réserver les quatre régions ensemble lors de la création d’un **nouveau
+  monde Sanctuary bêta**, avant de publier les régions au générateur.
+- Enregistrer leur identité, graine dérivée, direction, climat, relief, taille
+  et position. Les îles sont ouvertes dès le départ ; leurs chunks se génèrent
+  à l’exploration, comme ceux de l’île initiale. Elles ne demandent pas de coût
+  ni de déblocage par les joueurs.
+- Distinguer ce contrat dans les paramètres du nouveau monde. L’absence du
+  paramètre `ancient_expeditions` conserve le contrat alpha.24/30.7 ; aucune ancienne sauvegarde ne
+  reçoit automatiquement les quatre îles.
+- Utiliser un journal bêta distinct, versionné, vérifié et atomique. Aucun
+  journal existant n’est converti : `data/sanctuary-world-beta001/expansions.json`,
+  schéma `3`, disposition `expedition_layout=1`. En cas de journal incomplet ou invalide,
+  arrêter avec une erreur au lieu de recréer les régions.
+- Conserver les identifiants des codecs et du terrain existants. Le nouveau
+  paramètre doit survivre à Personnaliser, à l’écriture du monde et au rechargement.
+- Une sauvegarde bêta n’est pas rétrocompatible avec les binaires alpha :
+  ne pas la rouvrir avec eux. Les mondes alpha restent sur leur ancien contrat.
+
+## Placement proche
+
+Chercher d’abord la position admissible la plus proche sur l’axe cardinal,
+sans l’écart supplémentaire ni le décalage aléatoire des anciennes commandes.
+Conserver les emprises écrites, la marge de décoration et la séparation des
+chunks ; les bateaux et autres réservations aériennes restent prioritaires.
+Avancer par pas d’un chunk si une réservation interdit la première position.
+La distance entre centres comprend les rayons des deux îles : ce n’est pas
+la longueur du vide à traverser entre leurs rivages.
+
+Le même placement proche est disponible pour les nouvelles demandes d’expansion
+dans les mondes bêta. Les contrôles d’occupation et de reprise du vide certifié
+restent obligatoires ; une distance `0` ne donne aucune permission d’écraser
+un chunk existant. Les positions et règles des mondes alpha sont conservées.
+
+Le plan utilise les identifiants stables `noor_vigil`, `makena_embers`,
+`kai_efe_rift`, `ari_waters`. Leurs noms FR/EN sont affichés dans la liste
+opérateur ; les identifiants restent présents pour les commandes. Les structures
+vanilla suivent les possibilités naturelles de chaque région : les quatre
+ouvertures initiales n’imposent pas un bâtiment particulier. Les futures
+expansions par commande gardent leur précontrôle de structure existant.
+
+## Périmètre narratif
+
+Le lore fourni associe Noor à l’aventure, Makena à la cuisine, Kai et Efe à la
+construction et Ari aux villageois. Les noms des expéditions prolongent ces rôles.
+Steve et ses amis sont des héros trans de cette fiction. Steve s’est sacrifié
+pour contenir Notch ; Galactium, Alpha, Backrooms et les récits fragmentaires
+des personnages nourrissent la suite. Le dénouement et les pouvoirs restent à
+définir. Ces éléments ne décrivent pas des mécaniques déjà livrées : aucun boss,
+pouvoir, journal à collecter ou déblocage créatif n’est ajouté par ce ticket.
+
+## Essai local
+
+Importer `build/Sanctuary-beta.001.mrpack` dans le lanceur, puis créer
+un **nouveau monde de type Sanctuary**. Pour une visite rapide, choisir Créatif
+et autoriser les commandes. La graine `0`, taille Moyen (724), permet de retrouver
+les mesures natives ci-dessous.
+
+`/sanctuary expansion list` affiche les cinq régions et les noms localisés.
+Les commandes de visite sont :
+
+```text
+/sanctuary expansion visit noor_vigil
+/sanctuary expansion visit makena_embers
+/sanctuary expansion visit kai_efe_rift
+/sanctuary expansion visit ari_waters
+```
+
+Le pack cible Minecraft `26.3-pre-2`, Fabric Loader `0.19.5` et Fabric API
+`0.160.0+26.3`, avec Java 25. Cet export local n’avance pas le canal packwiz
+publié et n’installe rien dans une instance personnelle.
+
+## Vérifications
+
+Plans déterministes sur les trois tailles et les graines `0`, `42` et
+`-7228211907433324401` ; quatre directions exactes, identités et profils attendus,
+emprises distinctes, réservations aériennes respectées et distances mesurées.
+La suite pure `ancientExpeditions001Smoke` passe : persistance des cinq régions,
+reprise, refus de corruption et d’un bootstrap interrompu, ajout d’une expansion
+ultérieure et ancien journal alpha inchangé octet pour octet. Les neuf plans
+utilisent un ciel vide ; un cas supplémentaire impose de vraies réservations
+de bateaux de fixture et vérifie leur priorité.
+
+`./gradlew assemblePack -x :sanctuary:check` réussit. L’export packwiz/Modrinth
+est vérifié : versions, index et empreintes, intégrité des deux archives,
+JAR embarqué identique au JAR construit et activation des expéditions dans
+le preset. Le reçu est dans `build/expeditions001-artifact.json` (ignoré).
+`./gradlew check build -PsanctuaryFocusedTests=expeditions` réussit en 4 min 29 s :
+tous les contrôles purs du cycle et les **3 GameTests ciblés** passent sur
+Moyen 724, graine `0`. Les quatre régions génèrent leurs vrais chunks, leurs
+biomes correspondent aux climats attendus, l’océan contient un bassin d’eau,
+et chaque visite trouve un point d’arrivée sûr. Un premier lancement avait
+expiré à cause d’un callback de test qui se replanifiait sous la même clé ;
+le scénario corrigé passe sans modifier le code de jeu.
+
+La seconde exécution, avec `-PsanctuaryExpansionReload=true`, réussit en
+1 min 40 s (**3/3**) : mêmes régions et codec, journal inchangé, et quatre
+blocs témoins posés lors du premier processus toujours présents après reprise.
+Les paramètres des trois tailles et des deux états de structures expérimentales
+passent aussi une écriture/lecture native sur disque ; un codec alpha sans
+le nouveau paramètre conserve son ancien journal.
+
+Mesures sur Moyen 724, graine `0`, disposition `1` :
+
+| Région | Centre X/Z | Ancienne distance entre centres | Nouvelle distance | Écart estimé de terrain sur l’axe |
+| --- | --- | --- | --- | --- |
+| Noor | 0 / -784 | 933 | 784 | 416 |
+| Makena | 784 / 0 | 1 076 | 784 | 360 |
+| Kai et Efe | 0 / 784 | 1 013 | 784 | 404 |
+| Ari | -784 / 0 | 1 096 | 784 | 348 |
+
+Distances en blocs. Le dernier relevé échantillonne les hauteurs du générateur
+tous les quatre blocs sur l’axe des centres ; ce n’est pas la distance minimale
+entre deux rivages ni un tracé de pont. Le placement gagne ici 149 à 312 blocs
+entre centres, mais les emprises conservées et la forme réelle des paysages
+laissent encore un vide important. Un rapprochement supplémentaire qui ferait
+se chevaucher leurs chunks demanderait une évolution du contrat de propriété.
+
+Après ces essais, la version interne a été simplifiée à `beta.001` à la demande
+du créateur. `./gradlew build assemblePack -x :sanctuary:check` réussit en 7 s.
+Le JAR final est identique au JAR testé, sauf le champ `version` de
+`fabric.mod.json`. Les 12 contrôles du nouveau format passent ; le MRpack
+final contient uniquement `sanctuary-beta.001.jar` comme JAR Sanctuary.
+
+Les preuves ignorées sont dans `build/expeditions001-check-build-retry.log`,
+`build/expeditions001-reload.log`, `build/beta001-clean-naming-assemble.log`,
+`build/expeditions001-artifact.json` et
+`mods/sanctuary/build/run/gameTest/diagnostics/expeditions001/724-0-{native,reload}.json`.
+Ce ciblage ne revendique pas la réussite de toute la suite native générale :
+les deux assertions déjà relevées pendant [BETA-01](versioning.md) restent
+ouvertes. Les chunks natifs sont vérifiés sur Moyen/graine `0` ; l’inspection
+visuelle client et les essais Windows restent à effectuer.

docs/expeditions-beta002.md

@@ -0,0 +1,106 @@
+# beta.002 — climats et temples des expéditions
+
+Ticket local **EXP-02**, branche `codex/expedition-biomes-temples-beta002`.
+Le créateur a validé visuellement la génération de beta.001 et demande :
+
+- Nord : boréal/Peaks, avec taïga, neige et biomes de glace dans la palette boréale.
+- Ouest : conserver l’île océanique humide, avec un bassin `warm_ocean` et du corail vivant.
+- Sud : une pyramide du désert sur l’île aride/Canyon.
+- Est : un temple de la jungle dans l’île tropicale/Volcan, à une position qui varie avec la graine.
+
+Les quatre noms, directions, diamètres de 512 blocs et règles de rapprochement
+de beta.001 sont conservés. Les deux bâtiments utilisent les structures vanilla,
+avec leurs coffres, pièges, sauvegarde et localisation natives.
+
+## Contrat des nouveaux mondes
+
+Les nouveaux mondes enregistrent `ancient_expeditions=true` et
+`expedition_revision=2` dans le générateur. L’absence de révision reste `1`
+pour beta.001 ; l’absence d’expéditions garde le contrat alpha. Le journal
+beta.002 utilise `data/sanctuary-world-beta002/expansions.json`, schéma `3`,
+`expedition_layout=2`. Aucun ancien journal n’est converti et aucun chunk
+d’une sauvegarde jouée n’est régénéré.
+
+Les nouveaux biomes ne s’appliquent qu’à cette révision. Les deux temples sont
+planifiés avant l’exploration, à partir de la graine et du terrain, puis leurs
+starts sont enregistrés par Minecraft lors de la génération des chunks.
+Ils respectent l’option vanilla de génération des structures. La disposition
+et ses règles restent versionnées pour éviter de déplacer un site au rechargement.
+
+## Placement des temples
+
+**Évolution beta.097** : le refus bloquant décrit dans cette version historique
+est remplacé par une recherche de secours, puis un placement garanti des pièces
+vanilla avec fondation si nécessaire. Les sites historiques admissibles restent
+prioritaires. Voir le [contrat du correctif](temple-crash-beta097.md).
+
+Les candidats sont des chunks de l’intérieur de chaque île, à au moins 48 blocs
+de son centre, ordonnés par un tirage déterministe. La recherche filtre le type
+voulu, puis conserve les conditions natives de biome, de pente et de fondation.
+Elle ne modifie pas le relief pour imposer un bâtiment. Elle partage un cache
+borné à 32 768 colonnes par temple. Si aucun site admissible n’est trouvé dans
+ce budget, la création refuse explicitement cette disposition au lieu d’annoncer
+un temple absent. Les essais de graines ci-dessous donnent le périmètre vérifié.
+
+Les starts utilisent `minecraft:desert_pyramid` et `minecraft:jungle_pyramid`.
+Ils sont connus de `/locate structure` et sauvegardés au format natif. Leur
+réservation protège aussi les salles enfouies, les coffres et les pièges contre
+les structures voisines et la décoration ultérieure. Seules les pièces du
+temple concerné peuvent écrire dans son volume protégé pendant sa génération.
+
+Le bassin d’Ari conserve ses contours, profondeur et eau de beta.001 ; son
+biome chaud active les véritables features de récif vanilla. Aucune décoration
+artificielle de corail mort ne remplace ce récif.
+
+## Vérifications
+
+Sur macOS / Java 25, avec les mêmes dépendances Minecraft `26.3-pre-2`,
+Fabric Loader `0.19.5` et Fabric API `0.160.0+26.3` :
+
+- `./gradlew check build -PsanctuaryFocusedTests=expeditions` réussit en
+  4 min 38 s : contrôles purs du cycle et **4/4 GameTests ciblés**.
+- Les plans des trois tailles sur les graines `0`, `42` et
+  `-7228211907433324401` conservent les centres et les graines des quatre îles.
+  Les journaux des deux révisions sont testés : relecture, refus de migration
+  implicite et octets beta.001 conservés. Les réglages beta.001 sans révision
+  explicite gardent leur valeur `1` ; les réglages beta.002 survivent à
+  Personnaliser et à une vraie sauvegarde/relecture des trois tailles.
+- Sur Moyen 724 / graine `0`, les chunks des deux temples sont générés et
+  inspectés, leurs starts passent un aller-retour NBT et `/locate` les trouve.
+  La pyramide possède **4 coffres et 9 TNT**, le temple de jungle **2 coffres
+  et 2 distributeurs**. La palette boréale échantillonnée contient les six
+  biomes : taiga, grove, snowy_taiga, snowy_plains, ice_spikes et frozen_peaks.
+  **69 blocs de corail vivant** sont comptés dans les trois premiers chunks
+  océaniques inspectés ; ce nombre n’est pas un inventaire de toute l’île.
+- La reprise dans un deuxième processus réussit, **4/4**, en 1 min 56 s.
+  Les rapports des temples/récif avant et après reprise sont identiques ;
+  le journal, les paramètres et les quatre blocs témoins des joueurs sont
+  conservés. Le refus de chevauchement inclut les chambres enfouies des temples.
+- Un nouveau monde Moyen 724 / graine `42` passe aussi **4/4**, en 2 min 15 s,
+  avec les six biomes boréaux et 178 blocs de corail vivant dans les trois
+  chunks inspectés. Les deux sites diffèrent de ceux de la graine `0` :
+  pyramide au chunk `[3, 48]` au lieu de `[2, 46]`, temple au chunk `[50, -7]`
+  au lieu de `[56, -3]`. Les coffres et pièges attendus sont présents.
+- `./gradlew assemblePack -x :sanctuary:check` réussit en 6 s après les
+  contrôles. L’export `build/Sanctuary-beta.002.mrpack` est vérifié : intégrité
+  ZIP, versions et dépendances, index packwiz, JAR embarqué identique au JAR
+  construit, révision `2` du nouveau preset et présence du lecteur beta.001.
+  Le reçu est dans `build/expeditions002-artifact.json`.
+
+MRpack SHA-256 : `8a7f956b554385362f70a6b535504ecf5223d3ee86bf3c81bce2913060c104ca`.
+JAR SHA-256 : `1d7ff72567aa6d9807332917368a13c1e72bcbb3b6d6620c4a0f72907978b4fb`.
+
+Importer **`Sanctuary-beta.002.mrpack`**, puis créer un nouveau monde de type
+**Sanctuary**, avec les structures activées pour visiter les temples. Les
+commandes `/sanctuary expansion visit kai_efe_rift` et
+`/sanctuary expansion visit makena_embers` amènent sur les îles concernées ;
+`/locate structure minecraft:desert_pyramid` et
+`/locate structure minecraft:jungle_pyramid` localisent les bâtiments natifs.
+
+Les logs ignorés sont dans `build/expeditions002-check-build.log`,
+`build/expeditions002-reload-0.log` et `build/expeditions002-native-42.log`.
+Les relevés détaillés sont dans
+`mods/sanctuary/build/run/gameTest/diagnostics/expeditions002/`.
+La suite native générale garde les deux assertions historiques décrites dans
+`docs/versioning.md` ; cette livraison ne les présente pas comme corrigées.
+L’inspection graphique du nouveau pack et les essais Windows restent à faire.

docs/exploration-familiers-beta100.md

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

docs/faction-two-slots-beta046.md

@@ -0,0 +1,46 @@
+# FACTION-046 — deux places dès la fondation
+
+Branche `codex/sky-flight-zoom-beta046`, à partir de beta.045.
+
+## Contrat
+
+Une nouvelle faction coûte toujours dix niveaux par défaut, sans prestige.
+Elle dispose de deux places : le fondateur responsable et un invité, qui rejoint
+sans payer et sans prestige. La troisième place et les suivantes demandent une
+charge de prestige chacune par défaut. Le serveur revalide la capacité à chaque
+acceptation : deux invitations simultanées ne permettent pas de dépasser la limite.
+
+## Migration
+
+La configuration `config/sanctuary/cycle-factions.json` passe au schéma 3.
+Les schémas 1 et 2 sont lus puis convertis une seule fois au chargement :
+`initialCapacity` devient 2 ; un ancien `maxMembers: 1` devient 2. Les prix,
+récompenses, autres plafonds et le réglage de conservation d'XP sont préservés
+(la conversion historique de `creationCost` vers dix niveaux reste applicable
+au schéma 1). Cette règle vaut uniquement pour les fondations futures.
+
+Le journal `data/sanctuary-cycle-factions.json` accepte les schémas 1, 2 et 3.
+La lecture ne réécrit pas les anciens événements : capacités, membres, dépenses,
+charges et prestiges existants restent identiques. La prochaine mutation écrit
+le schéma 3 avec l'historique conservé. Les créations anciennes à une place
+restent valides, les nouvelles créations en proposent deux. Les identifiants
+d'événements et de sauvegarde ne changent pas. Ne pas faire relire un journal
+schéma 3 par un ancien binaire ; restaurer ensemble journal et joueurs pour
+revenir en arrière. Aucun monde personnel n'est modifié pendant ce ticket.
+
+Le marqueur réseau additif `sanctuary:faction_founding_pair_v1` évite qu'un
+ancien client lise une configuration qu'il ne reconnaît pas. Les libellés FR/EN
+présentent les deux places, dont une pour le fondateur.
+
+## Vérifications et livraison
+
+Le test de contrat `cycle011Smoke` passe : conversion des configurations
+schémas 1/2, idempotence, conservation d’une ancienne faction à une place,
+fondation à deux places, invitation immédiate et écritures interrompues.
+Les scénarios natifs font partie des 20 GameTests serveur ciblés réussis :
+un invité rejoint sans prestige, un troisième membre est refusé jusqu’au
+financement d’une place, puis peut rejoindre. Les nouveaux instantanés client
+reflètent la capacité et les dépenses exactes.
+
+Build, exports et parcours client sont décrits dans
+[le ticket beta.046](sky-flight-zoom-beta046.md) et [Distribution](packwiz.md).