sanctuary-beta/docs/inventory-sorting-beta014.md

# 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`.