# beta.014 — rangement, hotbar mobile et préfixe de faction Ticket demandé le 13 septembre 2026, branche `codex/inventory-sorting-aptitude`. Contrat écrit avant l'implémentation et les migrations. ## Comportement Une aptitude permanente **Rangement** s'achète dans le panneau Aptitudes du Blocodex, pour 4 niveaux par défaut (prix configurable côté serveur). Elle ne conditionne pas le prestige. Dans un menu d'inventaire ou de conteneur natif, le clic molette range la zone personnelle visée. La touche souris ou clavier se règle dans les contrôles. Viser une case de stockage regroupe les piles compatibles puis trie toutes les rangées débloquées, y compris celles qui sont masquées par le défilement. La hotbar reste en place ; viser une de ses cases trie uniquement ses neuf cases. L'ordre est déterministe par identifiant de type d'objet, puis par groupe de composants dans l'ordre rencontré ; les piles pleines précèdent les restes. Deux objets dont les composants diffèrent ne sont jamais fusionnés. Les cases de récupération verrouillées, l'équipement, la main secondaire, la fabrication et le contenu du conteneur ouvert ne participent pas au rangement. Aucun tri avec un objet porté par le curseur ou pendant un glisser-déposer. Le catalogue créatif garde ses commandes natives ; la vue d'inventaire personnel Sanctuary permet le rangement avec l'aptitude. Le clic de sélection en jeu et le défilement de la molette conservent leurs fonctions. Le serveur vérifie l'aptitude, le menu, son état, la révision de progression, la capacité et le numéro de requête. Le client envoie une zone, jamais des objets. Les contenus sont préparés sur des copies avant d'appliquer le résultat dans les emplacements existants, puis synchronisés. Pas de nouvelle réserve d'objets. ## Migration La progression passe du schéma 7 au schéma 8 : ajout de `sorting: false` pour les habitants existants. Toutes les migrations 1–6 restent suivies. Les rangs, achats, coûts, dates, révisions et prestiges sont conservés. Le nouvel achat `sorting` rejoint l'historique des aptitudes et survit au changement de cycle. Les journaux de cycle existants restent immuables et sont relus par cette migration ; leur propre schéma ne change pas. La configuration passe du schéma 3 au schéma 4, avec `sortingCost: 4` ajouté. Les valeurs existantes restent identiques, y compris un prix final explicitement fixé à 64 dans le schéma 3. La migration antérieure des schémas 1/2 conserve son contrat. Le fichier est validé puis réécrit atomiquement une fois ; un fichier invalide est refusé sans remplacement. Le schéma 4 n'est pas réécrit au chargement. Nouvelle capacité réseau `sanctuary:inventory_sorting_v1`, requise avant le spawn sur un serveur Sanctuary. Les identifiants existants restent stables. Client et serveur doivent utiliser beta.014 ensemble. Le schéma des 18 cases supplémentaires reste identique ; la métadonnée additive de hotbar est précisée ci-dessous. Aucune modification de génération, de terrain ou d’expansion. ## Préfixe de faction — ajout demandé pendant le ticket Le nom de faction précède le nom affiché : `Les Arpenteurs · Poupoutain I`. Le préfixe prend la couleur de faction ; le pseudo et le prestige gardent la couleur personnelle. Le rendu est commun à la fiche Habitant, au nom affiché côté serveur (chat et messages), à la liste Tab et aux noms des joueurs en jeu. Quitter une faction ou la dissoudre retire le préfixe ; le nom enregistré du compte, son UUID et l'identité enregistrée restent identiques. Le serveur projette les données du journal de faction dans les noms affichés et les diffuse par le paquet natif de liste des joueurs. Pas de modification des équipes de scoreboard, ni nouveau format de sauvegarde. La fiche suit aussi les mises à jour de faction reçues pendant qu'elle est ouverte. Les descriptions d'aptitudes ne répètent plus la conservation au New Game+ : cette propriété est une règle globale, décrite dans le bilan du cycle. ## Hotbar mobile — correction du contrat beta.012/013 Tab déplace la sélection vers la rangée au-dessus (retour en bas au sommet), Maj+Tab vers celle en dessous. La molette sur le stockage suit le même geste. Les objets restent dans leurs cases visibles ; le cadre et la case sélectionnée se déplacent. Les neuf objets de cette rangée deviennent utilisables en jeu. La molette sur la rangée active choisit toujours une de ses neuf cases. Le rangement préserve cette rangée, sauf si elle est directement visée. Le serveur conserve les indices natifs des menus et de l'objet tenu. Une permutation entre la rangée active et les neuf cases natives est compensée par leur placement à l'écran ; les autres rangées gardent leur contenu et leur position. Aucun réservoir d'objets supplémentaire n'est créé. Le tri du stockage suit les positions visibles, de haut en bas, en excluant la rangée active. Migration additive explicite : `sanctuary:hotbar_row`, entier de 0 à 5, est enregistré dans le même instantané joueur que les objets. Absent dans beta.013 et avant, il vaut zéro (rangée de base en bas) et ne réordonne rien au chargement. Il est conservé à la reconnexion et avec l'inventaire après la mort. Si la capacité diminue sous la rangée active, celle-ci revient en bas et les objets gardent leurs positions visibles, les autres rangées devenant de récupération. Le schéma du stockage supplémentaire reste inchangé. Un nouvel état réseau `sanctuary:hotbar_row` synchronise cette sélection après les cases natives. La capacité beta.014 impose des clients et serveurs cohérents. Un stockage supplémentaire illisible interdit le tri et les permutations de hotbar sans remplacer les données originales. ## Vérifications Les tests de contrat passent : reprise des progressions 1–7, conservation des achats et prix, refus des aptitudes forgées, achat unique de Rangement, budget d'historique, conservation après deux cycles et relecture de leur journal. Un ancien journal contenant des progressions au schéma 7 se relit sans changer ses octets. La configuration migre vers le schéma 4 en conservant les réglages, puis un `sortingCost` personnalisé est relu sans réécrire le fichier. Journal : `build/inventory014-contracts.log`. Le test client natif passe avec Minecraft **26.3-pre-2**, Fabric Loader **0.19.5**, Fabric API **0.160.0+26.3** et Java 25 : ```sh ./gradlew :sanctuary:runClientGameTest -PsanctuaryClientTests=true \ -PsanctuarySortingClientTests=true -PsanctuaryInventoryClientTests=true ``` Le parcours crée un monde Sanctuary de laboratoire, graine 42. Trois niveaux ne permettent pas l'achat ; quatre activent le bouton de l'aptitude, en FR/EN. L'achat depuis le Blocodex dépense exactement quatre niveaux. Le clic molette réel fusionne et range le stockage, puis la hotbar séparément. Le raccourci remplacé par E range le stockage dans un coffre ouvert, sans fermer le menu et sans toucher au contenu du coffre ; Échap ferme le menu. L'état final est contrôlé côté serveur. Les préférences du test sont restaurées à la fin. Le parcours final fait ensuite un cycle complet des six rangées : les **54 couples coordonnées/contenus restent strictement identiques** à chaque appui sur Tab. Le premier appui monte le cadre de 18 pixels, et l'objet tenu natif correspond à la rangée choisie. La molette distingue rangée et case sélectionnée. Le coffre conserve ses objets, les deux tailles de GUI sont vérifiées, puis fermeture et réouverture conservent le cadre et toutes les positions d'objets. Le New Game+ réel ramène le cadre en bas. La charge gagnée fonde une faction : la fiche affiche son préfixe et le prestige I, puis perd le préfixe à la dissolution sans être refermée. Le nom client suit le paquet natif. Les descriptions individuelles FR/EN ne contiennent aucune mention du New Game+. Journal final : `build/inventory014-client-final.log` (`BUILD SUCCESSFUL`, 1 min 15 s). Dix captures : `build/inventory014-evidence/`. Les tests utilisent les menus Minecraft natifs, sans mods communautaires supplémentaires ni serveur à trente clients. Les mondes et classes de test restent dans les dossiers ignorés. ### Validation serveur et livraison locale ```sh ./gradlew check build assemblePack \ -PsanctuaryFocusedTests=progression,map,demeure,mining,building,inventory,cycle,inventoryflow,sorting ``` `build/inventory014-release-final.log` : **BUILD SUCCESSFUL**, 4 min 17 s ; **56 tests natifs serveur réussis**, avec les tests de contrat du dépôt. Ils vérifient les six capacités, les composants et limites de piles, les requêtes périmées/refusées, les objets au curseur, le statut spectateur, le prix réel, la mort et les sauvegardes. Le cadre mobile conserve les 54 cases à chaque étape, le tri exclut la rangée active, la réduction de capacité garde la récupération, et les données illisibles refusent les écritures. Le Maj-clic transfère la rangée active vers le coffre puis conserve la destination native sur cette rangée. Les appartenances de faction, les couleurs, les messages de liste des joueurs et les identités immuables sont vérifiés côté serveur. Le MRpack contient le JAR vérifié de Sanctuary et Demeure embarqué, ainsi que la dépendance Fabric API épinglée. Les classes de test et mondes sont absents. Les textures importées de 26.2 et les icônes sont identiques aux originaux. Les exports beta.003–013 conservent leurs empreintes. Il s'agit d'un export local de test ; aucun canal publié ni aucune instance personnelle n'est modifié. - [Sanctuary-beta.014.mrpack](../build/Sanctuary-beta.014.mrpack) - Vérification : `build/verify-beta014-pack.py` ; reçu : `build/inventory014-artifact.json`. - Taille : 2,527,741 octets. - SHA-256 MRpack : `9bc77d9fcdcc812d64f2c95d1270e00adc94b90bc08e055f3314e2950761ac49`. - SHA-256 JAR : `3eb4ac92de0ad671592ae79ed65f00547184d771ad72603952edf7bd86e0352c`.