# Blocodex — navigation, découvertes et vitrine de l'habitant

Discussion du 13 septembre 2026, après l'essai de beta.004.
Branche de conception : `codex/blocodex-navigation`.
**Cadrage uniquement : les comportements ci-dessous ne sont pas encore livrés.**
Le pack beta.004 reste inchangé ; cette note ne modifie aucune sauvegarde.

## Décisions exprimées par le créateur

- Conserver le rendu Minecraft, le titre en haut et le bouton Terminé en bas.
- Réunir statistiques, advancements, carte, descriptions et constructions
  dans la navigation du Blocodex.
- Cacher les entrées non découvertes aux joueurs ; permettre leur inspection
  aux opérateurs. Distinguer explicitement les essais joueur et opérateur.
- Retirer S'asseoir des aptitudes et du passeport. La faculté de s'asseoir
  reste disponible dès le début ; seul son emplacement dans ces menus change.
- Faire du passeport une fiche dont on peut être fier : exploits accomplis,
  constellation favorite, type de créature favori.
- Un favori doit être découvert. Le type de créature favori peut changer une
  fois toutes les **24 heures réelles** et donne une influence légère, notamment sur l'apprivoisement
  et le butin. Le choix quotidien de différents types est volontairement permis.
- Intégrer les plans de construction avec Litematica.
- Le créateur valide la maquette comme référence à conserver et réutiliser
  pour le site, avec le fonds d'images et de documents jusqu'à alpha.30.7.
- Priorité suivante : carte native Sanctuary inspirée de Xaero, puis Demeure,
  factions et claims, New Game Plus et prestiges. L’exploration précède le
  déblocage de Grande carte. Voir [MAP-01](atlas-beta005.md).

## Organisation proposée

Quatre rubriques principales stables, puis une navigation locale. L'accès à
une fonction est retrouvé par sa place et son nom, quelle que soit la touche
qui a ouvert le Blocodex. À petite échelle, les sous-rubriques passent sur
plusieurs lignes ; le corps défile sans déplacer l'en-tête ni le pied de page.

| Rubrique FR / EN | Sous-rubriques proposées | Rôle |
| --- | --- | --- |
| Découvertes / Discovery | Blocs, Objets, Créatures, Recettes | Ce que je connais, avec description et actions contextuelles. |
| Progression / Progression | Capacités, Exploits, Statistiques | Compétences à gauche et aptitudes à droite ; advancements Minecraft en priorité, accomplissements Sanctuary séparés ; compteurs vanilla. |
| Monde / World | Atlas, Constructions, Histoire | Cartes et marqueurs ; plans et matériaux ; événements, Gazette, archives et liens avec le Galactium lorsqu'ils seront disponibles. |
| Habitant / Inhabitant | Passeport et vitrine sur la même page | Identité, exploits épinglés, constellation favorite et créature favorite. |

La maquette approuvée utilise **Monde** à la place de Story pour accueillir
la carte et les constructions en plus de l'histoire. La référence archivée
est dans [archives/web](../archives/web/README.md) ; son statut reste une
conception validée, sans implémentation supplémentaire dans beta.004.

Les boutons Statistiques et Advancements peuvent d'abord ouvrir les écrans
natifs depuis Progression et revenir au Blocodex. Il n'est pas nécessaire de
réécrire leurs données ou leur rendu pour unifier l'accès. Le cadre reste
identique pour les pages Sanctuary ; les écrans communautaires peuvent garder
leur présentation avec un retour au bon écran parent.

L'item description devient le contenu de la fiche d'un objet découvert,
pas une rubrique de plus. Depuis une recette : ouvrir l'objet connu ; depuis
un exploit accompli : l'épingler dans le passeport ; depuis un favori : ouvrir
sa fiche ; depuis un plan : consulter les matériaux connus.

## Découvertes et droit de fabrication

Le socle actuel ne suit que les blocs. Il transmet leur catalogue complet,
et affiche aussi les noms inconnus : voir `BlockKnowledgeNetworking` et
`SanctuaryBlocodexScreen`. Les objets indépendants et créatures exigent un
contrat de découverte supplémentaire avant leur intégration réelle.

Pour la nouvelle vue joueur, une entrée inconnue ne produit aucune ligne,
silhouette, nom, description, résultat de recherche ou liste de favoris.
Afficher le nombre découvert, sans total de registre révélant les manques.
Les éventuelles pistes viendront de quêtes ou conversations, sans exposer
automatiquement le catalogue secret.

Filtrer la réponse Sanctuary côté serveur et les vues côté client. Une
navigation depuis une recette, un plan ou une recherche ne doit pas révéler
indirectement les noms et descriptions masqués. Ne pas considérer le registre
Minecraft, nécessaire au client, comme un secret cryptographiquement caché.

Conserver trois décisions distinctes : découverte de l'objet, accès à
l'outil de consultation des recettes, révélation d'une recette particulière.
**La fabrication manuelle reste libre**, même si la recette n'est pas révélée.
Les écrans vanilla conservent leurs règles de visibilité d'advancements ; on
ne cache pas un objectif Minecraft normal simplement parce qu'il est inachevé.

## Opérateur et essais

En solo, Autoriser les commandes permet d'accéder aux outils opérateur selon
les permissions réellement accordées. En multijoueur, le serveur décide des
droits du joueur ; le mode créatif seul n'est pas une preuve d'autorisation.
Utiliser le niveau des commandes Sanctuary existantes comme référence.

Un opérateur peut ouvrir une **Vue opérateur** explicitement marquée, avec
catalogue complet et états de découverte. La vue joueur reste disponible
pour tester le parcours ordinaire. Inspecter un contenu ne le marque pas
découvert et n'accorde aucun exploit, XP, favori ou aptitude.

La vue joueur d'un opérateur sert à vérifier l'affichage. Elle ne transforme
pas ses permissions : les tests d'autorité exigent aussi un vrai joueur sans
droits. Séparer les actions de diagnostic des actions qui modifient l'état.
Toute révocation de droits invalide la vue opérateur et son cache.

Matrice minimale du futur ticket :

- Solo sans commandes et client non-opérateur : inconnus absents, recherches
  et chemins indirects filtrés, aucun accès aux outils opérateur.
- Solo avec commandes et opérateur serveur : inspection complète possible,
  marquée comme telle ; aucune découverte enregistrée par cette inspection.
- Opérateur en vue joueur : mêmes lignes visibles que selon ses découvertes.
- Retrait des droits avec une page ouverte : retour à la vue autorisée.
- Découverte réelle, mort et reconnexion : mise à jour puis conservation.
- Carte verrouillée : raccourcis, menus et autres points d'entrée respectent
  le même droit ; minimap, grande carte et marqueurs restent trois aptitudes.

## Passeport et affinité

Proposition : trois emplacements d'exploits Minecraft déjà obtenus, une
constellation connue et un type de créature découvert. Le nombre de trophées
et le moyen de partager le passeport restent à confirmer. Les identifiants
référencent les sources de vérité ; épingler n'accorde pas l'accomplissement.
La constellation favorite nécessite le futur système du ciel : aucune liste
fictive ne doit devenir un catalogue réel dans le mod.

Pour la créature, le créateur confirme un délai de **24 heures réelles depuis le dernier
changement**, calculé côté serveur et conservé après mort, déconnexion et
redémarrage. Il ne s'agit pas d'une remise à zéro à minuit.

Seul le favori courant donne un léger bonus, sans cumul permanent des anciens
choix. Les animaux déjà apprivoisés restent apprivoisés. Ne pas inventer
l'apprivoisement d'une espèce qui n'a pas cette mécanique : chaque type doit
avoir un effet adapté ou ne recevoir aucun effet mécanique.

Restent à régler avant le code : coefficient, types éligibles, variante ou
type entier, attribution du butin en coopération, et portée du bonus de butin
(mort de l'animal, productions comme laine/œufs, ou les deux). Un bonus à la
mort encourage à chasser son favori ; un bonus aux productions encourage à
s'en occuper. Le profil peut rester discret sans afficher un pourcentage.

Le contrat de persistance des favoris doit être écrit avant d'ajouter des
données aux habitants. Préférer un ajout versionné avec absence interprétée
comme aucun favori, sans réécriture silencieuse des profils beta.003/004.

## Carte et constructions

Sanctuary développe désormais sa cartographie native ; le partage futur
des découvertes reste de joueur à joueur. Litematica conserve la gestion de schémas, les projections et les
listes de matériaux : [documentation de l'auteur](https://github.com/maruohon/litematica/wiki/Frequently-Asked-Questions).
Sanctuary fournit le point d'entrée, les droits et les liens vers ses données.
Un plan reçu ne constitue pas automatiquement une découverte de ses matériaux.
Préciser le filtrage de la projection et de la liste avant l'intégration pour
éviter de révéler des matériaux inconnus par ces écrans.

Aucune compatibilité Minecraft 26.3-pre-2 de Xaero, JEI ou Litematica n'est
établie par cette note, et aucun de ces mods n'est ajouté au pack. Vérifier
version exacte, dépendances, API et distribution au ticket de chaque adaptateur.
Le collage créatif d'un schéma ne doit pas devenir une fonction de construction
accessible par la seule découverte d'un plan.

## Découpage proposé

L'ordre historique était carte native, puis Demeure, factions/claims,
New Game Plus et prestiges. Après beta.006, le créateur demande la carte
immersive et l'achèvement des six compétences avant le New Game+ ; les factions
sont conçues avec le cycle. Les [prochains tickets](prochains-tickets.md) font
foi pour cet ordre actualisé. Les lots d'interface ci-dessous restent identifiés.

1. **UI-02** : retirer S'asseoir de ces deux pages, filtrer le catalogue actuel
   selon les droits et découvertes, ajouter les accès natifs Statistiques et
   Advancements. Tests joueur/opérateur et retour des écrans. Aucun favori,
   nouveau format de sauvegarde ou mod communautaire nécessaire.
2. **KNOW-02 / PROFILE-02** : découverte des objets et créatures, épinglage
   des exploits et contrat des favoris. Effets d'affinité dans un lot séparé
   une fois les règles chiffrées arrêtées ; le délai de 24 heures est confirmé.
3. **MAP-01 / CONNECT-01** : carte native, puis adaptateurs recettes et plans sur des versions
   vérifiées ; réutiliser les mêmes contrôles de découverte et d'aptitudes.

La maquette de discussion illustre la navigation avec des données fictives.
Elle ne démontre ni l'intégration des mods ni l'application des permissions.