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