feat: add native Blocodex and material census for alpha23

docs/testing-alpha23.md

@@ -0,0 +1,104 @@
+# 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](blocodex.md) 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 :
+
+```text
+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 :
+
+```sh
+./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.