sanctuary-beta/docs/testing-alpha23.md

Validation alpha.23 — Blocodex et socle méta

Relevé du 10 septembre 2026, branche codex/blocodex-natif. Cible : Minecraft 26.3-pre-2, Fabric Loader 0.19.5, Fabric API 0.160.0+26.3, Java 25, Sanctuary/pack 0.1.0-alpha.23. Le contrat Blocodex définit les informations et leur couverture.

Résultats disponibles

Vérification	Résultat observé	Preuve locale
Client natif : widgets, interface et connexion au serveur intégré	Réussie, BUILD SUCCESSFUL in 34s	build/blocodex-client-network-tests.log
Compilation et persistance quotidienne des activités	Réussies, BUILD SUCCESSFUL in 9s	build/blocodex-meta-compile.log
Persistance de la mémoire personnelle	Smoke réussi dans la passe complète	build/blocodex-meta-check-build.log, ligne Block knowledge smoke passed
GameTests natifs	24/24 réussis, dont 16 pour le socle méta	build/blocodex-meta-check-build.log, All 24 required tests passed
Passe complète et assemblage du pack	Réussis, BUILD SUCCESSFUL in 4m 18s	build/blocodex-meta-check-build.log

Les tests de stockage couvrent les instantanés immuables, les compteurs exacts, l’isolement des UUID ou des journées, les identifiants de mods absents, le JSON strict et le refus d’écraser silencieusement un fichier invalide. Leur succès est complété par les tests natifs ci-dessous.

Les neuf tests de connaissance vérifient poses réussies et refusées, variantes murales, statistiques de minage et jets volontaires, distinction des morts, regard occulté, inventaire/curseur, états et notifications indépendants, sauvegarde après déconnexion depuis un thread réseau, et palettes combinables. Deux tests terrain vérifient pose/remplacement/retrait, exclusion immédiate des comptages obsolètes, couverture et budget partagé entre lectures, sans charger de chunk absent. Deux tests stocks vérifient les quatre catégories, un double coffre ouvert sans double comptage et la conservation du butin non généré. Trois tests d’activité vérifient les actions natives, les quantités datées, la séparation des observations et des actions, la relecture après sauvegarde, les journées absentes et les commandes avec identifiants complets. Le test de fabrication appelle la complétion vanilla d’un item ; il ne joue pas une recette entière dans l’établi. Les huit tests généraux de génération passent aussi.

Artefact local vérifié

Le JAR mods/sanctuary/build/libs/sanctuary-0.1.0-alpha.23.jar mesure 1 914 798 octets. Sa copie dans build/packwiz/mods/ est identique. SHA-256 :

740107901c06d1c54838a944d01431e4f134f6989e1900b294cc0c0d210b1d4f

Le manifeste embarqué, l’entrée client, les classes de recensement et d’historique, le tag de palette naturelle et les paramètres des traductions FR/EN sont vérifiés. Les manifestes du dépôt et du pack assemblé indiquent 0.1.0-alpha.23. Le contrôle pack vérifie les versions et empreintes de l’index.

Protocole client exécuté

Le client de développement commence par une fixture explicite de 260 blocs en trois fragments. Les widgets réels vérifient recherche, filtres et pagination, assemblage atomique, rejet des réponses périmées ou invalides, et conservation des grands compteurs dans la narration. Deux dimensions de GUI sont exercées : 854 × 480 et 427 × 240, avec une aide défilante. Cette fixture ne prétend pas représenter un inventaire de joueur.

La seconde passe crée un nouveau monde plat de développement, graine 1, en survie, avec les commandes désactivées. Elle utilise la véritable touche B, la connexion Minecraft et les paquets du mod :

1. Préparer côté serveur un bloc d’or devant le joueur et trois blocs de diamant dans son inventaire ; laisser les observations ordinaires du serveur agir.
2. Regarder l’or puis ouvrir B : l’or est vu sans être possédé ; le diamant est possédé avec un stock de 3 sans être vu ; l’émeraude reste inconnue.
3. Fermer l’écran, retirer les diamants, puis rouvrir avec B : la possession passée reste vraie et le stock actuel vaut 0.
4. Fermer le monde et vérifier le fichier de mémoire personnelle sauvegardé.

Les deux diagnostics signalent passed: true dans mods/sanctuary/build/run/clientGameTest/diagnostics/ :

• sanctuary-blocodex-client.json : fixture, widgets et fragments ;
• sanctuary-blocodex-network-client.json : états avant/après, touche et paquets réels, observation du regard et sauvegarde à la fermeture.

Les captures 0005_sanctuary-blocodex-network-carried-three.png et 0006_sanctuary-blocodex-network-sticky-possession.png se trouvent dans le dossier screenshots/ du même client. La seconde a été inspectée : le diamant reste connu et possédé, avec Inventory: 0, dans l’interface anglaise du test.

Reproduction et limites

Depuis la racine du dépôt, avec Java 25 et un environnement graphique :

./gradlew -PsanctuaryClientTests=true :sanctuary:runClientGameTest
./gradlew :sanctuary:materialActivitySmoke
./gradlew check build assemblePack

La dernière commande a terminé avec succès. Le scénario client prouve une connexion intégrée réelle ; il ne constitue pas une validation réseau à plusieurs clients sur un serveur distant. Les essais ne constituent pas un profil de performance d’un grand serveur.

Les mondes, captures, diagnostics et journaux de test restent dans les dossiers de développement ignorés. Le scénario réseau vérifie que sa nouvelle sauvegarde est créée sous mods/sanctuary/build/run/clientGameTest/saves/. Aucune instance Prism ni sauvegarde personnelle n’a été mise à jour. Aucune publication ni modification du canal packwiz n’a été effectuée pour ces essais.