docs: cadrer les secrets, raids d’expansion et charges de faction

README.md

@@ -21,9 +21,14 @@ intérieurs et filons de l’alpha.21 sont conservés. Voir [les essais22](docs/
 et [la distribution](docs/packwiz.md).
 
 La suite est en [conception](docs/structures-conception.md) :
-départ naturel, quelques lieux isolés, fonctions reproductibles et donjon majeur
-à définir. Ce cahier précède la reprise du code ; l’alpha.22 reste la livraison
-actuelle.
+départ naturel, secrets et passages souterrains sur l’île, Lost Cities surtout
+sur les expansions. Les installations découvertes montrent des fonctions
+reproductibles avec contrôleur, terminal, afficheur, disquettes et blocs vanilla ;
+un immense laboratoire caché prépare l’accès collectif aux Cavernes. Le train
+et les rails restent des axes à reconstruire, même sans bâtiments terminaux.
+L’accès aux raids se découvrira sur une île d’expansion. Boss, portails et raids
+restent à concevoir. Ce cahier précède la reprise du code ; l’alpha.22
+reste la livraison décrite ici.
 
 ## Alpha.22 — trouver le bon terrain
 

docs/accueil-et-profils.md

@@ -0,0 +1,285 @@
+# Sanctuary — fiche personnage, initialisation et amitiés
+
+**Conception WG-26, sans interface ni système social implémenté.** Ce cahier
+complète les [identités dans le lore](histoire-steve-galactium.md#identités-apparences-et-transformations)
+et l’[entrée dans la mythologie](histoire-steve-galactium.md#entrer-dans-la-mythologie--accueil-avant-la-première-apparition).
+
+## Direction demandée
+
+- **La fiche personnage vient en premier.** Le texte de scénario proposé
+  précédemment est rejeté et retiré de l’accueil : il dévoilait trop le lore.
+  Aucun passage galactique ne précède la fiche.
+- Le profil montre le **skin et le pseudo actuels**. Le joueur peut écrire une
+  courte bio sur sa pratique de Minecraft ou sur son personnage.
+- **Une fois la fiche validée**, une petite cinématique figure l’initialisation
+  du personnage, avec une séquence de l’alphabet galactique et une recherche
+  d’emplacement sûr, comme un ordinateur qui démarre.
+- L’apparition jouable suit cette initialisation, dans la nature de Sanctuary.
+- **Première apparition sur le serveur : « helloworld {pseudo} ».** Les
+  connexions suivantes conservent le message habituel de connexion. Le critère
+  de première apparition suit l’UUID, tandis que le message montre le pseudo actuel.
+- Un système d’**amitiés natif** permet de partager la bio publiquement ou avec
+  ses amis. Il doit laisser la possibilité de personnages discrets ou mystérieux.
+- La présence, l’histoire et la progression sont **liées à l’UUID du compte**
+  dans le monde concerné. Pseudo, skin et bio peuvent évoluer.
+- Chaque joueur choisit une **couleur personnelle dans la palette du serveur**,
+  **sur sa fiche de création de personnage**. La palette est configurée avant
+  l’arrivée du premier joueur. Une couleur prise devient
+  indisponible aux autres. L’appartenance à une faction précède le pseudo ;
+  le prestige le suit en **chiffres romains**.
+
+L’ordre est demandé par l’auteur ; les plans, libellés, durées et commandes
+précises restent proposés. L’archive qui semble se mettre à jour seule reste
+une piste de fond du lore. L’accueil n’en donne pas d’explication et ne révèle
+ni les anciens, ni leurs installations, ni la nature de Galactium.
+
+## Fiche personnage
+
+Le profil emploie le compte existant ; « créer son personnage » ne signifie
+ni recréer une identité technique ni choisir une classe obligatoire.
+
+La fiche présente le skin, le pseudo, le **choix de couleur parmi les teintes
+disponibles** et un champ **« Votre bio » / « Your bio »**.
+Suggestion d’invite : **« Qu’aimez-vous faire dans Minecraft ? » / « What do you
+enjoy doing in Minecraft? »**. Le texte peut aussi être une courte présentation
+fictionnelle du personnage. Exemple : « Je construis des ponts beaucoup trop
+grands. Je cherche quelqu’un qui sait faire des ascenseurs. »
+
+La bio peut rester vide. Sa longueur maximale, sa mise en forme et l’éventuelle
+présentation de centres d’intérêt restent à choisir. Le texte ne fixe pas des
+compétences, des récompenses, une faction ou des objectifs obligatoires. Les
+points communs servent d’abord aux rencontres entre joueurs.
+
+La présentation conserve les principes du lore : chaque personne peut définir
+son personnage, sans déduction de genre depuis son skin et sans déclaration
+de genre ou de transidentité requise. Une bio est un espace d’expression
+volontaire, pas une demande de renseignements sur la vie réelle.
+
+La bio peut être complétée plus tard ; valider une fiche avec une bio vide permet de
+continuer. Les connexions suivantes ne forcent pas à la réécrire. Modifier son
+profil conserve l’UUID, la progression et les actes associés au personnage.
+
+## Couleur personnelle, faction et prestige
+
+**Direction retenue :** composer le nom visible dans l’ordre
+**faction → pseudo → prestige**. Exemple de présentation :
+**« Les Égarés Poupoutin VI »**. Le pseudo porte la couleur personnelle ; le
+préfixe identifie le groupe et permet aussi des associations de noms amusantes.
+Le choix entre nom, symbole ou combinaison des deux pour la faction reste à
+dessiner, ainsi que les séparateurs. Le prestige est placé à la suite du pseudo,
+sur la même ligne, en chiffres romains : **IV pour 4, VI pour 6**. Cette direction
+remplace l’idée de chiffres galactiques au-dessus du nom.
+
+### Palette réservée par joueur
+
+**Dernier choix de l’auteur : une palette préparée pour la population prévue.**
+Un serveur prévu pour **20 joueurs dispose de 20 couleurs distinctes**, définies
+avant toute arrivée. Le joueur choisit parmi les couleurs encore disponibles,
+et sa couleur est retirée des choix des autres joueurs. Le libre choix de
+n’importe quelle couleur par chaque joueur est remplacé par ce fonctionnement.
+La palette peut contenir des teintes personnalisées ; elle n’est pas limitée
+par conception aux couleurs nommées de Minecraft.
+
+Le choix appartient au profil **UUID dans ce serveur**, indépendamment du
+pseudo, du skin, du prestige ou de la faction. Une déconnexion ne libère pas
+la couleur : la palette couvre les habitants, pas seulement les personnes
+connectées simultanément. Changer de faction conserve donc sa couleur
+personnelle ; l’emblème ou le préfixe commun indique l’appartenance au groupe.
+
+**Emplacement retenu : le choix de couleur fait partie de la création du
+personnage.** Seules les teintes disponibles sont proposées à la sélection.
+**Détails de parcours proposés :** aperçu du pseudo dans la couleur choisie,
+puis réservation confirmée par le serveur à la validation de la fiche. Si deux
+personnes choisissent la même couleur en même temps, une seule l’obtient et
+l’autre voit les choix actualisés ; ouvrir une fiche ne réserve pas à lui seul
+une teinte indéfiniment. Un contour lisible autour du texte est proposé pour
+conserver les teintes choisies sur des décors clairs ou sombres.
+
+| Élément | Libellé proposé FR / EN |
+| --- | --- |
+| Choix | Couleur du joueur / Player color |
+| État d’une teinte | Disponible / Available ; Déjà choisie / Taken |
+| Concurrence au choix | Cette couleur vient d’être choisie. / This color was just taken. |
+
+L’agrandissement d’une palette déjà utilisée, le changement volontaire de
+couleur et le départ définitif d’un habitant restent à définir. Une palette
+épuisée ne justifie pas d’attribuer deux fois une couleur ou de reprendre celle
+d’un joueur absent. Le choix manuel ou la génération assistée de la palette
+par l’administrateur reste ouvert ; aucune liste de 20 teintes n’est imposée ici.
+
+### Factions et compteur de prestige
+
+**Une faction dispose de trois places au départ.** Les prestiges donnent des
+**charges personnelles liées à l’UUID**, que le joueur peut dépenser dans sa
+faction pour y débloquer des places. Ces crédits d’agrandissement sont distincts
+des charges collectives de Galactium. Ils ne transforment pas automatiquement
+la somme des prestiges des membres en capacité de faction.
+
+Quantité gagnée par prestige, coût d’une place, permanence des places après
+le départ d’un membre et éventuel remboursement restent à spécifier dans la
+[progression](progression-et-integrations.md#compétences-unlocks-galactique-et-prestige).
+La taille de faction ne détermine pas le nombre de couleurs du serveur.
+
+Le suffixe représente les prestiges effectivement accomplis, comptés côté
+serveur et rattachés à l’UUID ; il ne s’agit pas d’un texte libre du profil.
+Les charges dépensées ne réduisent pas ce compteur. Son affichage n’ajoute
+aucun pouvoir à la récompense en crédits d’agrandissement.
+**Propositions d’affichage :** aucun préfixe sans faction, aucun suffixe au
+prestige zéro ; reprendre cette composition dans le nom au-dessus du joueur,
+la liste des habitants et le chat, avec une lisibilité à vérifier dans chaque
+vue. Longueur du préfixe et dessin des symboles restent à concevoir.
+
+Le pseudo du compte demeure distinct du nom composé. La formule de première
+apparition reste exactement **« helloworld {pseudo} »** ; cette présentation
+sociale ne lui ajoute pas implicitement une faction ou un chiffre de prestige.
+
+## Cinématique d’initialisation après la fiche
+
+**Intention retenue :** faire sentir le démarrage d’une présence dans le monde
+par une courte opération visible. La séquence galactique apparaît seulement
+ici. Elle accompagne l’initialisation et la figuration d’une recherche de point
+d’entrée, sans nouveau texte de scénario ni traduction donnant une révélation.
+
+**Découpage proposé, à éprouver visuellement :**
+
+| Moment | Image et mouvement proposés |
+| --- | --- |
+| Fiche validée | La fiche s’efface ; un fond sombre et un curseur ou repère discret prennent le relais. |
+| Initialisation | Quelques lignes de glyphes galactiques s’inscrivent ou se stabilisent. Le personnage apparaît brièvement comme une silhouette ou un modèle en préparation. |
+| Recherche d’emplacement | Une grille abstraite ou une petite coupe de terrain parcourt plusieurs positions. Des cases s’éteignent ; un emplacement se stabilise. |
+| Point d’entrée prêt | Le repère s’immobilise. La transition conduit à la vue du joueur au point choisi sur l’île. |
+
+La grille n’est pas une carte révélant l’île, les ruines ou les ressources.
+Les formes, sons et glyphes suggèrent une opération ; le joueur en découvrira
+la portée plus tard. Le contenu exact de la séquence galactique reste à définir
+avec le [cahier du langage](langage-et-machines.md). Elle peut figurer des étapes
+d’initialisation et de positionnement sans être un programme exécutable ni une
+nouvelle déclaration de Galactium.
+
+Quelques libellés fonctionnels sont possibles si la lecture des étapes le
+demande ; ils restent proposés, et la scène peut surtout se lire par l’image :
+
+| Étape | Proposition FR / EN |
+| --- | --- |
+| Préparation | Initialisation / Initializing |
+| Recherche | Recherche d’un emplacement / Locating an entry point |
+| Destination validée | Point d’entrée prêt / Entry point ready |
+
+La recherche est **figurée par la cinématique** ; la sélection et la validation
+de l’emplacement réel restent à la charge du serveur. L’animation ne vaut pas
+preuve de sécurité : la fin vers l’apparition attend un point réellement prêt.
+Elle n’affiche pas de coordonnées inventées ni de pourcentage présenté comme
+une mesure réelle. Cette distinction reste interne à la conception, sans
+explication technique à ajouter à l’écran du joueur.
+
+Durée exacte et synchronisation restent à éprouver ; viser une petite séquence,
+sans allonger artificiellement une entrée déjà prête. Une option pour passer
+l’animation est proposée, en attendant tout de même la préparation réelle.
+La première arrivée est le cas à concevoir d’abord ; répétition ou variante
+abrégée aux connexions suivantes restent ouvertes. Une reprise ne réinitialise
+pas la progression conservée sous l’UUID.
+
+Le raccord à la connexion et au chargement sera défini dans le ticket d’interface.
+L’arrivée naturelle reste le résultat ; cette scène n’ajoute pas de dimension
+d’attente ni de déplacement vers une salle construite.
+
+## Première apparition — helloworld
+
+**Demandé par l’auteur :** pour la première apparition d’un personnage sur le
+serveur, remplacer l’annonce de connexion habituelle par
+**« helloworld {pseudo} »**, par exemple **« helloworld Poupoutin »**.
+« Après » est compris ici comme les connexions suivantes : elles utilisent
+l’annonce ordinaire de Minecraft, et non un second message ajouté immédiatement
+au premier accueil.
+
+Le message arrive **au moment de l’apparition effective**, après la cinématique
+et la préparation du point d’entrée. Ouvrir ou valider la fiche, commencer
+le chargement ou interrompre la connexion avant l’apparition ne suffit pas.
+Le message visible de première entrée remplace l’annonce ordinaire pour cet
+événement ; il ne faut pas annoncer une première fois le joueur avant le boot.
+
+L’historique d’accueil du serveur conserve cette première apparition par **UUID**.
+Une reconnexion, un redémarrage, une mort, un changement de dimension, de pseudo
+ou de skin ne la recommence pas. Le pseudo actuel est substitué dans le message ;
+un compte différent qui reprend un ancien pseudo garde son propre historique.
+Cette règle ne crée ni progression globale entre serveurs ni remise à zéro du profil.
+
+| Texte | Statut |
+| --- | --- |
+| **helloworld {pseudo}** | Formulation anglaise demandée. |
+| **helloworld {pseudo}** | Même formule proposée en français, sans préposition ; conserver le clin d’œil « helloworld ». |
+| Annonce des connexions suivantes | Réutiliser le message habituel de Minecraft et sa localisation. |
+
+L’enregistrement de la première apparition et l’émission du message doivent
+être raccordés au même événement serveur, avec une politique de reprise à
+définir avant code. Les profils déjà présents à l’installation du futur système
+nécessitent une règle explicite : l’absence du nouveau champ ne prouve pas
+qu’un ancien joueur vient d’apparaître pour la première fois. Aucun historique
+existant n’est migré ou réinitialisé par ce cahier.
+
+## Amitiés et visibilité de la bio
+
+**Fonctions demandées :** amis intégrés au jeu, bio publique ou réservée aux
+amis. Proposition de périmètre : les habitants du même serveur, sans publication
+sur un site ni annuaire global implicites.
+
+| Réglage proposé | Qui peut consulter la bio ? |
+| --- | --- |
+| **Publique / Public** | Les joueurs du serveur. |
+| **Amis / Friends** | Les amis dont la demande a été acceptée, et l’auteur du profil. |
+| **Masquée / Hidden — option supplémentaire proposée** | L’auteur seulement ; une bio vide permet aussi de ne rien présenter. |
+
+Le réglage est visible avant validation du profil. **Défaut proposé : Masquée**,
+avec choix explicite pour partager. Ce défaut et cette troisième option ne sont
+pas encore validés. La visibilité concerne la bio ; elle ne masque pas le pseudo
+ou le skin visibles en jouant.
+
+**Amitié réciproque proposée :** ouvrir une fiche d’habitant, envoyer une demande,
+puis attendre son acceptation. Une demande en attente ne donne pas accès aux
+bios d’amis. Chacun peut refuser ou retirer la relation. Elle est enregistrée
+entre UUID, avec les noms actuels à l’écran, et ne dépend pas de la présence
+simultanée des joueurs une fois établie.
+
+| Action à localiser | Libellé proposé FR / EN |
+| --- | --- |
+| Demander une amitié | Ajouter en ami / Add friend |
+| Répondre | Accepter / Accept ; Refuser / Decline |
+| Terminer la relation | Retirer des amis / Remove friend |
+| Changer sa présentation | Modifier le profil / Edit profile |
+| Entrer en jeu | Entrer dans Sanctuary / Enter Sanctuary |
+
+La consultation pourrait passer par une liste d’habitants et leurs fiches,
+avec un accès physique à proximité à étudier. Touches et écrans restent à
+dessiner avec l’inventaire personnalisé. Devenir ami ouvre l’accès prévu au
+profil ; permissions sur les coffres, factions, partage de gains et coordonnées
+conservent leurs règles propres.
+
+La visibilité est vérifiée **côté serveur avant d’envoyer la bio**, dans toutes
+ses vues. Retirer une amitié, restreindre la visibilité ou supprimer le texte
+actualise les accès et les vues du jeu. Cette règle ne peut pas effacer ce
+qu’une personne a déjà lu. Invitation, acceptation et changement de visibilité
+restent des actes du joueur, pas des actions automatiques du récit.
+
+## Personnalités à découvrir
+
+Une fiche peut raconter des goûts, un projet ou presque rien. Le mystère peut
+venir d’un personnage peu bavard, d’une bio énigmatique et des installations
+qu’il laisse découvrir. Le jeu ne complète pas sa biographie à sa place et
+ne publie pas ses informations privées dans l’accueil ou le lore.
+
+Les joueurs peuvent ainsi devenir des auteurs reconnaissables dans l’histoire
+de leur serveur. Cette direction ne donne aucun rôle particulier au créateur
+du mod dans la fiction, ni ne transforme les anciens en comptes de joueurs.
+Leur statut et leurs visites gardent le [cadrage du lore](histoire-steve-galactium.md#présences-de-passage).
+
+Un futur essai devra vérifier l’ordre fiche → initialisation → apparition,
+l’absence de texte narratif et de glyphes avant la fiche, l’attente d’un
+emplacement validé par le serveur, une première entrée avec bio vide, une bio publique,
+une demande d’ami en attente puis acceptée, un retrait et un changement de
+pseudo/skin conservant le même profil. Pour l’accueil, vérifier un seul
+« helloworld » à la première apparition effective, aucun en cas d’interruption
+avant apparition, puis l’annonce ordinaire après reconnexion et redémarrage.
+Vérifier également une palette de 20 teintes, deux choix simultanés de la même
+couleur, sa conservation hors ligne et après changement de faction, un profil
+sans faction ni prestige et le suffixe romain d’un prestige réel.
+Aucun de ces parcours n’est livré ici.

docs/audit-redstone-26.3.md

@@ -0,0 +1,390 @@
+# Redstone 26.3 et informatique Sanctuary
+
+**Audit de conception du 11 septembre 2026 — WG-26.** Lecture du code Java
+vanilla exact, des sources Sanctuary et des références historiques, recoupée
+avec les publications Mojang. Aucun composant, langage, recette ou changement
+de monde n’est livré par cet audit.
+
+Suite de conception : le [dossier Redstone Language V0.1](redstone-language-extensions.md)
+propose désormais les instructions, les fiches matérielles, les périphériques
+et les composants de signal/transport manquants. Ses nouveaux blocs et valeurs
+d’essai restent distincts des faits vanilla vérifiés dans cet audit.
+
+## Ce que Sanctuary change vraiment
+
+La redstone vanilla permet déjà logique, mémoire, calcul, automatismes et
+ordinateurs construits avec des blocs. Le contrôleur Sanctuary **concentre ces
+circuits dans une machine reprogrammable** ; le terminal et les disquettes
+permettent d’écrire, d’étudier et de partager ses programmes. L’afficheur rend
+leurs résultats lisibles dans le monde.
+
+Les nouveaux pouvoirs viennent des **appareils et des informations auxquels le
+programme accède** : émettre les particules d’un objet, lire précisément un
+inventaire si une interface le permet, consulter le calendrier Sanctuary, ou
+demander une expansion à une installation habilitée. Une instruction de calcul
+n’accorde pas à elle seule ces pouvoirs. Mojang donne déjà les ordinateurs et
+Minecraft exécuté dans Minecraft comme exemples de créations redstone ; il
+serait donc inexact de présenter Sanctuary comme l’invention du calcul vanilla.
+[Redstone Dust — Mojang](https://www.minecraft.net/de-de/article/redstone-dust).
+
+## Version et portée des constats
+
+Le projet cible **Minecraft Java 26.3-pre-2**, et non une édition Bedrock ni
+une version finale supposée. Le JAR local indique `stable: false`, une compilation
+du 4 septembre 2026, Java 25 et data pack 120. La pre-release 3, publiée le
+8 septembre, est postérieure à cette cible ; son existence ne met pas le pack
+à jour. La pre-2 corrige notamment la détection de fonte de neige/glace par les
+capteurs sculk ; la pre-3 touche notamment les calculs de number providers.
+[Pre-release 2](https://www.minecraft.net/en-us/article/minecraft-26-3-pre-release-2),
+[pre-release 3](https://www.minecraft.net/en-us/article/minecraft-26-3-pre-release-3).
+
+L’inventaire ci-dessous couvre les familles de composants, leurs mesures et
+leurs effets utiles à la conception. Il ne prétend pas énumérer tous les circuits
+que les joueurs peuvent composer, ni valider chaque montage en jeu. Les nombres
+précis viennent des classes 26.3-pre-2 identifiées en fin de document. Les
+publications d’anciennes versions servent de contexte ; leur comportement a été
+recoupé avec cette cible lorsqu’il est détaillé ici.
+
+## Le modèle vanilla : signal, temps et matière
+
+Une liaison redstone ordinaire porte une intensité entière **de 0 à 15**. Elle
+peut représenter un booléen, un niveau, ou une valeur codée par le constructeur.
+Elle ne transporte pas spontanément un nom d’objet, un texte ou une identité
+de joueur. Un montage peut transmettre davantage par plusieurs lignes ou par
+une séquence dans le temps ; cela exige un encodage et un récepteur.
+
+La poudre perd un niveau en propageant le signal d’une poudre à la suivante.
+Le répéteur réémet une sortie à 15 lorsque son entrée est active, avec un délai
+réglable de **2, 4, 6 ou 8 ticks de jeu**. Les blocs conducteurs, les directions
+et les alimentations fortes/faibles font partie du circuit : deux blocs voisins
+ne sont pas automatiquement deux appareils communicants.
+
+La simulation vise **20 ticks de jeu par seconde** au réglage normal. Un délai
+de circuit suit cette simulation, avec ses pauses et ralentissements. Le futur
+calendrier réel de Sanctuary est une autre source de temps : un jour de vingt-
+quatre heures ne doit pas rendre chaque répéteur soixante-douze fois plus lent.
+Un chronomètre devra préciser s’il mesure du temps simulé ou du temps réel.
+
+La redstone est une commande, sans réserve d’énergie consommée à chaque impulsion.
+Un four consomme son combustible et le crafter ses ingrédients ; la puissance
+du signal ne les fournit pas. Le contrôleur devra de même distinguer calcul,
+commande et consommation matérielle.
+
+## Les entrées et mesures disponibles
+
+| Famille vanilla | Ce que le circuit reçoit | Ce qu’il faut préserver dans Sanctuary |
+| --- | --- | --- |
+| Levier, boutons | État maintenu ou impulsion déclenchée par interaction ; certains boutons réagissent aussi aux projectiles. | Une commande locale n’identifie pas automatiquement son auteur. |
+| Plaques de pression ordinaires et pondérées | Présence ou niveau dépendant des entités selon le type de plaque. | Un compte d’entités n’est pas une liste de joueurs. |
+| Fil de détente et crochets | Détection sur une ligne installée. | Le parcours et les attaches ont une utilité physique. |
+| Coffre piégé | Signal lié au nombre d’utilisateurs qui l’ouvrent, dont les joueurs et les golems de cuivre ; son inventaire a aussi une mesure de comparateur. | État d’ouverture et contenu sont deux informations différentes ; ce signal ne prouve pas une présence humaine. |
+| Cible | Intensité liée à la précision de l’impact. | Un score de tir peut commencer par une valeur analogique, sans attribution personnelle implicite. |
+| Détecteur de lumière du jour, mode inversé | Valeur issue de l’éclairage du ciel et de l’angle solaire. | Ce n’est pas une horloge civile ni un capteur générique de toute lumière artificielle. |
+| Paratonnerre | Impulsion lors d’un impact de foudre. | Pas un capteur continu de pluie. |
+| Observateur | Impulsion lors d’une mise à jour détectée sur la face observée. | Il ne transmet ni le contenu complet du bloc ni une explication de son changement. |
+| Capteur sculk | Vibration reçue, puissance liée à la distance ; comparateur pour la fréquence de l’événement pendant l’activité. | Portée, trajet, occlusion et états du capteur comptent ; les événements ne donnent pas une identité complète. |
+| Capteur sculk calibré | Filtrage par fréquence avec une entrée de calibration à l’arrière ; plus grande portée. | Une entrée électrique peut paramétrer un capteur sans lui fournir un programme. |
+| Rail détecteur | Présence d’un wagon et lecture analogique de certains wagons. | Le transport lui-même peut servir de support d’information. |
+
+Le code donne une portée de **8 blocs** au capteur sculk ordinaire et **16** au
+calibré. L’activité dure respectivement **30 et 10 ticks**, puis le refroidissement
+dure **10 ticks**. Le calibré filtre la fréquence lorsque son entrée de
+calibration est non nulle. Ces mesures ne remplacent pas un capteur Sanctuary
+de statistiques ou d’advancements.
+
+La réception d’une vibration attend aussi que les neuf chunks du carré 3×3
+autour du capteur soient présents et autorisés à simuler les blocs. Le trajet
+prend `floor(distance)` ticks. La laine peut occulter la vibration et certaines
+actions accroupies sont ignorées. Ce dispositif n’est pas un journal exhaustif
+des actions des joueurs.
+
+### Le comparateur mérite un inventaire à lui seul
+
+Le comparateur compare son entrée arrière aux entrées latérales, ou soustrait
+la plus forte entrée latérale. En lecture de bloc, le sens dépend du bloc lu.
+Il peut déjà relier des objets usuels à des serrures, jauges et machines.
+[Présentation Mojang du comparateur](https://www.minecraft.net/nb-no/article/taking-inventory--redstone-comparator).
+
+| Bloc ou objet lu | Information disponible |
+| --- | --- |
+| Coffres, coffres en cuivre, tonneaux, shulkers, hoppers, droppers, dispensers, fours et alambics | Remplissage de l’inventaire, pondéré par capacité d’empilement ; pas le nom ni la quantité exacte de chaque objet. |
+| Pot décoré | Remplissage de son inventaire. |
+| Crafter | Nombre d’emplacements occupés **ou désactivés**, de 0 à 9 ; ce n’est pas une mesure standard de stacks pleines. |
+| Bibliothèque sculptée | Dernier emplacement manipulé, pas le texte des livres. |
+| Étagère — shelf | Présence des trois cases encodée par les poids 1, 2 et 4, soit 0–7, lisible à l’arrière ; ni quantité ni identité. |
+| Pupitre | Position de la page dans le livre, pas son texte ; tourner la page émet aussi une impulsion. |
+| Cadre et cadre lumineux | Présence et rotation de l’objet. |
+| Jukebox | Valeur définie par la chanson ; la lecture du disque produit aussi un signal d’activité. |
+| Gâteau et gâteau avec bougie | État du gâteau, donc parts restantes. |
+| Composteur | Niveau de compostage. |
+| Chaudrons d’eau/neige poudreuse/lave | Niveau ou état de remplissage prévu par la variante. |
+| Ruche et nid d’abeilles | Niveau de miel. |
+| Ancre de réapparition | Charge disponible. |
+| Cadre de portail de l’End | Présence d’un œil ; le bloc n’est pas une pièce fabriquable librement en survie. |
+| Ampoule en cuivre | État allumé mémorisé, sortie 15 ou 0. |
+| Statue de golem de cuivre | Pose debout = 1, assise = 2, course = 3, étoile = 4. |
+| Cœur de Creaking | Distance à son Creaking associé : `15 − floor(clamp(distance, 0, 32) / 32 × 15)` ; 0 sans associé ou à l’état déraciné. |
+| Capteur sculk, rail détecteur | Fréquence de vibration ou donnée du wagon pris en charge. |
+| Bloc de commande | Nombre de succès de la commande ; relève des outils administrateur, pas d’un composant de progression en survie. |
+
+Pour les inventaires ordinaires, la mesure est **0 si vide**, sinon
+`floor(14 × remplissage moyen) + 1`. Le remplissage tient compte du nombre de
+cases et de la capacité des stacks. Deux contenus différents peuvent donc donner
+la même intensité. Une jauge Sanctuary branchée seulement sur un comparateur
+doit présenter cette mesure, sans inventer un stock exact à partir de celle-ci.
+
+Les étagères et statues, apparues avec The Copper Age, sont bien présentes dans
+la cible 26.3. Une étagère alimentée permet, lors de l’interaction du joueur,
+d’échanger plusieurs emplacements avec sa barre rapide ; jusqu’à trois étagères
+connectées permettent l’échange de cette barre. La redstone seule n’effectue
+pas le clic du joueur. Ces objets offrent déjà des interfaces diégétiques.
+[The Copper Age — publication Java](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-21-9).
+
+## Ce que la redstone permet de construire et d’actionner
+
+| Famille | Capacité vanilla | Limite ou nuance utile |
+| --- | --- | --- |
+| Poudre, blocs conducteurs, bloc de redstone | Transport et source constante de signal. | Intensité et orientation ; pas un câble de données riches par défaut. |
+| Torches, répéteurs et comparateurs | Inversion, seuil, soustraction, délai, isolation, verrouillage. | Leur composition permet portes logiques, additionneurs, compteurs et séquenceurs. |
+| Boucles et mémoires construites | Horloges, impulsions, bascules, registres, stockage et machines de calcul. | Emprise, temps de propagation et mises à jour réelles. La liste des constructions possibles n’est pas fermée. |
+| Ampoule en cuivre | Bascule d’état à chaque nouvelle alimentation, état conservé sans signal maintenu. | Source lumineuse et mémoire simple ; elle ne module pas sa luminosité selon 1–15 comme le débit du particuleur. |
+| Pistons, pistons collants, slime et miel | Déplacer des blocs, ouvrir des portes, déplacer des entités et construire des machines mobiles. | Limite de poussée de 12 blocs ; blocs non déplaçables et réactions spécifiques. La cible Java refuse le déplacement des block entities. |
+| Portes, trappes, portillons | Commander des passages, des accès et des montages utilisant l’eau. | Les variantes gardent leurs règles d’interaction ; pas de téléportation générique. |
+| Rails ordinaires, propulseurs, détecteurs et activateurs | Aiguiller, déplacer/freiner, détecter ou agir sur les wagons adaptés. | Chaque type remplit un rôle ; les occupants et inventaires restent physiques. |
+| Hopper et wagons à inventaire | Transporter, aspirer et distribuer des items ; verrouiller un hopper par redstone. | Faces, inventaires admissibles, temps de transfert et capacité réelle. |
+| Dropper | Tenter de déplacer un item vers l’inventaire en face ; sans inventaire, le lâcher dans le monde. | Si l’inventaire trouvé refuse l’insertion, l’item reste dans le dropper. Ne reproduit pas toutes les actions d’un clic droit. |
+| Dispenser | Exécuter une action définie pour l’objet : projectiles, seaux, poudre d’os, allumage, tonte, etc. | L’objet doit avoir un comportement prévu ; il ne sait pas utiliser arbitrairement tout nouveau bloc. |
+| Crafter | Tenter une fabrication à chaque nouvelle impulsion, à partir des ingrédients de ses neuf cases. | Une recette valide est nécessaire. La grille peut être configurée ; l’ordinateur ne serait pas l’invention de l’auto-craft. |
+| Fours, alambics, composteurs et fermes | Chaînes de transformation alimentées et surveillées ; récolte par combinaisons mécaniques. | Leurs recettes, combustibles, temps et mécanismes de croissance restent nécessaires. |
+| Lampes, blocs musicaux, jukebox, cloche | Voyants, sons, musique, alarmes et animations construites. | Son, lumière et durée ont leurs propres règles. Un signal de bloc musical ne choisit pas sa note par une valeur arbitraire. |
+| TNT et projectiles | Déclenchement d’explosions, propulsion, pièges et récoltes selon le montage. | Consommation, dégâts et règles de drops ; le calcul ne crée pas gratuitement la matière. |
+| Eau, bulles, portails, perles de l’End | Transport et mécanismes indirects que des circuits peuvent déclencher ou organiser. | Pas d’opération vanilla ordinaire « générer un continent à ces coordonnées ». |
+| Allays, villageois, golems de cuivre | Collecte, récolte ou tri matériel selon les comportements de ces entités. | Ce sont des acteurs du montage, pas des CPU adressables par un programme vanilla. |
+
+Le crafter utilise déjà la chaîne **ingrédients → impulsion → résultat**, avec
+des hoppers possibles en alimentation. Le contrôleur pourra gérer le moment
+et la quantité de production ; il n’a pas besoin de remplacer ce bloc.
+[Guide Mojang du crafter](https://www.minecraft.net/en-us/article/crafting-crafter).
+
+Quelques cadences vérifiées : le dropper et le crafter programment leur action
+quatre ticks après une nouvelle alimentation ; un signal maintenu ne suffit
+pas à les faire répéter indéfiniment. Le hopper a un refroidissement de huit
+ticks après un transfert réussi ; il peut pousser puis aspirer dans un même
+cycle, et un ramassage au sol peut intégrer une pile. Il serait inexact de
+résumer tous ces appareils à « un item par tick ».
+
+Le golem de cuivre recherche ses coffres jusqu’à 32 blocs horizontalement et
+huit verticalement, prend au plus 16 objets, et dépend d’un chemin praticable.
+Il prélève dans les coffres en cuivre et dépose dans des coffres ordinaires ou
+piégés vides ou contenant le même type. Ce tri est déjà une capacité vanilla ;
+les futurs services payants des villageois de Sanctuary sont un autre chantier.
+
+Le dispenser 26.3-pre-2 a des comportements explicites pour les projectiles,
+les bateaux et wagons, les seaux, le briquet, la poudre d’os, la TNT, certaines
+constructions d’entités, les shulkers, bouteilles, glowstone, cisailles, brosse,
+rayons de miel et certaines potions. Les objets équipables ont également leurs
+règles. Cette liste de comportements spécialisés explique pourquoi **accepter
+un item par dropper** et **être activé par un dispenser** sont deux contrats.
+
+### Les particularités Java à ne pas effacer
+
+Les mises à jour de blocs et leur ordre font partie du fonctionnement des
+circuits. La quasi-connectivité existe notamment pour pistons et
+dispensers/droppers : l’alimentation peut être détectée au-dessus, avec des
+conditions de mise à jour. Cela ne signifie pas que tous les nouveaux appareils
+doivent l’adopter. Leurs faces, leur émission et leur réaction aux impulsions
+devront être spécifiées et essayées avec des circuits vanilla.
+
+Le code contient un évaluateur de poudre alternatif derrière
+`FeatureFlags.REDSTONE_EXPERIMENTS`. Sa présence dans le JAR ne prouve pas que
+tous les mondes l’activent. L’audit ne modifie aucune option expérimentale.
+L’activité dépend également des chunks et des entités effectivement simulés ;
+la présence d’un ordinateur ne donne pas automatiquement un chargement permanent.
+
+### Commandes et data packs : une autre couche du vanilla
+
+Les commandes, fonctions de data packs, scoreboards et entités d’affichage
+permettent déjà du calcul, du texte dynamique, des particules et des effets
+sur le monde. Il serait faux d’affirmer que Minecraft ne sait jamais faire ces
+choses. Mais leur mise en place relève de l’auteur de carte ou de l’administration,
+pas d’un ordinateur fabriqué puis programmé librement par un joueur en survie.
+Dans la cible, `/particle` et `/compute` exigent la permission de game master ;
+l’édition d’un bloc de commande vérifie aussi ce droit.
+
+La différence Sanctuary est de rendre certaines possibilités **constructibles,
+apprenables et reproductibles dans la partie**, à travers des appareils avec
+leurs règles. Le Redstone Language n’est pas une console de commandes opérateur.
+
+## Comparaison avec le socle Sanctuary
+
+| Élément Sanctuary | Ce qu’il rend plus pratique | Ce qu’il ajoute réellement | Statut |
+| --- | --- | --- | --- |
+| Contrôleur | Logique, compteurs, conditions, séquences, mémoire et calcul en peu de blocs. | Programme modifiable, processeur et RAM intégrés, six faces d’E/S. | Direction retenue ; architecture et cadence à concevoir. |
+| Terminal | Concevoir, examiner et corriger un montage logique. | Éditeur d’assembleur, assemblage, inspection de RAM/registres et chargement de programmes. | Retenu ; pas de bloc Assembleur séparé. |
+| Disquette | Réutiliser et transmettre une solution. | Programme porté par un objet que l’on peut trouver, copier et échanger. | Retenu ; recettes, capacité et copie à définir. |
+| Afficheur | Lire compteurs, jauges et états sans une grande matrice de lampes. | Texte dynamique programmable, écran rectangulaire connecté, huit lignes par bloc en hauteur. | Retenu ; connexion aux données et limites à concevoir. |
+| Particuleur | Produire des effets décoratifs contrôlés dans une construction. | Objet-échantillon choisissant les particules ; signal réglant leur débit. | Direction précisée ci-dessous ; pas de portage livré. |
+| Lecture précise d’inventaire | Comptage, tri et coordination de production. | Accès structuré aux types et quantités, au-delà du comparateur. | Interface à concevoir ; pas un effet automatique de la RAM. |
+| Calendrier et progression | Tableaux, objectifs, événements et suivi. | Données serveur Sanctuary consultables par des programmes. | Sources et droits à concevoir ; un capteur physique ne les invente pas. |
+| Installation Galactium | Orchestrer un projet collectif. | Demande d’expansion avec conditions matérielles, charge collective et résultat persistant. | Moteur d’expansion existant ; raccord jouable au programme absent. |
+| Convoyeurs, stockage titane, Chunky | Logistique visible, stockage consultable et activité permanente choisie. | Appareils supplémentaires avec matériaux, portée et progression propres. | Vision future ; ne sont pas acquis par le seul achat du contrôleur. |
+
+Le langage de calcul envisagé est un assembleur **8 bits**, avec RAM adressable.
+Les valeurs internes 0–255 ne changent pas les faces électriques 0–15. Texte,
+coordonnées et gros compteurs demandent une représentation ou un protocole
+adapté. Un CPU 8 bits n’impose pas une RAM de 256 octets ; sa capacité reste à
+choisir dans le [cahier informatique](langage-et-machines.md).
+
+La sauvegarde proposée porte sur l’état complet : programme, position d’exécution,
+registres, RAM et attentes. Les anciens ordinateurs locaux sauvegardaient une
+partie de cet état, mais recréaient le CPU au début de chaque tick. Ils sont
+des références à reprendre, pas une preuve que la nouvelle exécution continue
+est déjà disponible. Voir la [lecture du Redstone Computer](redstone-computer-reference.md).
+
+## Trois échanges à définir séparément
+
+| Échange | Exemple | Contrat |
+| --- | --- | --- |
+| Signal redstone | Le contrôleur sort 7 vers le particuleur, ou une impulsion vers un dropper. | Faces, valeur 0–15, maintien/impulsion, cadence et mises à jour. |
+| Objet physique | Un hopper/dropper apporte un échantillon au particuleur. | Inventaire source, place libre, faces d’insertion/extraction et transfert effectif. |
+| Donnée ou commande de périphérique | Le contrôleur écrit du texte sur l’afficheur ou lit un inventaire exact. | Connexion identifiée, données accessibles, résultat et actions permises. Ce protocole reste à concevoir. |
+
+Le minimum peut utiliser une connexion adjacente entre appareils compatibles,
+sans imposer un nouveau bloc de bus. Une communication riche par poudre ou entre
+contrôleurs distants demeure possible à concevoir, mais exige son propre protocole.
+Un signal redstone ne transporte pas à lui seul un `ItemStack`.
+
+Exemple : **coffre → comparateur → contrôleur → particuleur**. Le programme peut
+utiliser l’intensité reçue pour régler le débit de fumée. Il connaît alors un
+niveau de remplissage, pas « 128 lingots de fer ». Cette dernière information
+demanderait une lecture explicite de l’inventaire, donc une capacité supplémentaire.
+
+## Particuleur : contrat clair et montages
+
+**Retenu : un objet inséré au clic droit choisit les particules. Plus le signal
+est fort, plus l’appareil émet de particules.** Le contrat de travail utilise
+0 pour arrêter, puis un débit croissant de 1 à 15. La courbe, la cadence maximale
+et l’orientation de sortie restent à définir. Cette variation concerne le
+nombre de particules dans le temps ; elle n’impose pas un changement de taille,
+de vitesse ou de portée.
+
+L’insertion par **dropper** est demandée. Le **hopper accolé** est le candidat
+vanilla proposé pour l’alimentation continue. Le contrôleur peut régler le
+débit par une face électrique ordinaire, commander le dropper, ou verrouiller
+le hopper. Un éventuel transfert direct par le contrôleur demanderait une
+fonction de manipulation d’inventaire ; il ne fait pas apparaître un objet.
+
+**Proposition minimale : un emplacement d’échantillon.** Clic droit pour insérer
+ou remplacer en rendant l’ancien objet, main vide pour retirer. Je recommande
+de conserver l’échantillon pendant l’émission pour en faire un matériau de
+réglage d’un appareil décoratif ; sa consommation n’est pas encore décidée.
+Pour changer de particule automatiquement, prévoir une extraction puis une
+insertion réelles. Le transfert ne doit pas détruire l’échantillon précédent.
+
+Le code historique `26.2/redstoner` possède déjà une table de correspondances,
+un slot, le remplacement manuel et l’insertion automatisée. Il **refuse
+l’extraction automatisée** ; reprendre cette règle telle quelle bloquerait le
+changement automatique d’échantillon. Il augmente aussi vitesse et fréquence,
+et produit un nuage par défaut, même sans échantillon : ces détails historiques
+ne sont pas validés pour le nouveau particuleur.
+
+| Échantillon | Correspondance historique utilisable comme proposition |
+| --- | --- |
+| Charbon de bois | Fumée. |
+| Bloc musical | Notes. |
+| Perle de l’End | Particules de portail. |
+| Mousse | Spores. |
+
+La nouvelle table doit être explicite et extensible ; elle ne suppose pas que
+chaque item possède une unique « particule naturelle ». **Proposition : vide =
+aucune émission**, et règle explicite pour les objets non reconnus. Un comparateur
+de présence pourrait être utile ; il resterait facultatif. Les effets sont
+proposés comme visuels : une particule de flamme n’allumerait pas un incendie.
+
+Les scènes possibles sont simples à composer :
+
+- un atelier émet plus de fumée quand un stock ou une activité augmente ;
+- une arrivée déclenche une courte émission par plaque de pression ;
+- une installation montre attente, activité et fin par plusieurs émetteurs ;
+- un programme séquence musique, lampes et particules pour un spectacle ;
+- un réseau d’items change l’échantillon, tandis que le programme règle le débit.
+
+Le particuleur doit rester utilisable avec un levier ou un comparateur seul.
+Le contrôleur apporte les variations dans le temps et la coordination. Les
+ruines peuvent montrer ces usages en fonctionnement, sans panneau explicatif.
+
+## Où garder la puissance de construction
+
+**Recommandation :** les programmes calculent et coordonnent ; les blocs et
+installations conservent les opérations physiques. Le contrôleur choisit quand
+fabriquer ; le crafter fabrique avec ses ingrédients. Le contrôleur compte les
+impulsions ; le hopper déplace les objets. Le contrôleur choisit un débit ; le
+particuleur émet. Une interface supplémentaire peut enrichir cette relation,
+mais ses possibilités doivent être explicites.
+
+Cela rend la programmation puissante sans faire disparaître les chemins,
+coffres, rails, fermes et ateliers que les joueurs aiment construire. De petites
+machines restent utiles sans ordinateur ; plusieurs contrôleurs peuvent former
+une installation plus élaborée lorsque leurs connexions sont définies.
+
+Pour Galactium, le programme pourra calculer et soumettre une demande ; le
+serveur devra vérifier installation, charge collective, ressources et emprise.
+Le moteur actuel possède réservation, préparation progressive et reprise ; il
+ne fournit pas encore ce parcours de survie. Une instruction ne remplace pas
+les étapes de progression et ne permet pas de réécrire librement les blocs ou
+les sauvegardes. Voir le [raccord d’expansion](langage-et-machines.md#ce-que-le-moteur-fournit-déjà-et-ce-qui-manque).
+
+## Points à éprouver avant livraison
+
+Le premier essai jouable pourrait réunir un contrôleur, un terminal, une
+disquette, un coffre avec comparateur, un afficheur et un particuleur. Il
+vérifierait un programme lisible et copiable, une jauge honnête, un débit modulé
+et la reprise de son état. Le particuleur doit aussi réussir son essai autonome.
+Ce parcours est proposé ; il ne lance pas de nouvelle livraison.
+
+Les règles à arrêter portent sur les transitions de signal, les connexions,
+la cadence CPU, les transferts, la reprise et les états d’erreur. Calculer
+beaucoup d’instructions et déplacer beaucoup d’objets sont deux coûts distincts.
+Une émission décorative doit également rester supportable pour les clients :
+limites par appareil et par zone, synchronisation et génération visuelle à définir.
+Ni le programme ni le particuleur ne donnent un chargement de chunk permanent ;
+ce dernier reste lié au chantier Chunky et clés.
+
+## Traces de lecture et limites
+
+La lecture du code actif utilise `sanctuary-beta`, branche `codex/blocodex-natif`,
+commit **e654d56**. Le travail documentaire est isolé sur
+`codex/conception-territoire`. Le code actif enregistre notamment monde,
+expansions, Blocodex et recensements ; il n’enregistre pas le nouveau trio
+informatique ni le particuleur. Aucune comparaison de performances ni simulation
+de circuit n’a été exécutée pour cet audit.
+
+Le JAR de sources généré localement par Loom est
+`.gradle/loom-cache/minecraftMaven/net/minecraft/minecraft-merged-6974b2190e/26.3-pre-2/minecraft-merged-6974b2190e-26.3-pre-2-sources.jar`
+dans le dépôt de code. Les classes ont été lues en mémoire, sans import de sources
+vanilla dans Git. Le JAR déobfusqué de contrôle est
+`~/.gradle/caches/fabric-loom/minecraftMaven/net/minecraft/minecraft-merged-deobf/26.3-pre-2/minecraft-merged-deobf-26.3-pre-2.jar`,
+SHA-256 `980d5ffa0de0e2fe784a377858053d228dd56e0b0a59505a96a5b058cdac09ef`.
+
+| Preuve locale, sous `net/minecraft/` dans les sources vanilla | Constats associés |
+| --- | --- |
+| `world/level/SignalGetter` ; sous `world/level/` : `block/RedstoneWireBlock`, `redstone/RedstoneWireEvaluator`, `block/RepeaterBlock`, `block/DiodeBlock` | Intensité, propagation, sens, délais et évaluateur expérimental. |
+| `world/TickRateManager` | Cadence de simulation normale, réglable. |
+| Sous `world/level/block/piston/` : `PistonBaseBlock`, `PistonStructureResolver` | Quasi-connectivité, limite de 12 et refus des block entities. |
+| Sous `world/level/block/` : `ObserverBlock`, `RedstoneTorchBlock`, `DaylightDetectorBlock`, `CopperBulbBlock` | Détection, inversion, mesure solaire et bascule lumineuse. |
+| `world/inventory/AbstractContainerMenu`, `world/level/block/ComparatorBlock` et méthodes `getAnalogOutputSignal` des blocs recensés | Calcul de remplissage et sources de comparateur. |
+| Sous `world/level/block/` : `SculkSensorBlock`, `CalibratedSculkSensorBlock` ; sous `world/level/block/entity/` : `SculkSensorBlockEntity`, `CalibratedSculkSensorBlockEntity` ; `world/level/gameevent/vibrations/VibrationSystem` | Portées, filtrage, temps d’activité et conditions de réception. |
+| `world/level/block/DropperBlock`, `world/level/block/DispenserBlock`, `world/level/block/entity/HopperBlockEntity`, `core/dispenser/DispenseItemBehavior` | Transferts, impulsions, faces et usages spécialisés d’objets. |
+| `world/level/block/CrafterBlock`, `world/level/block/entity/CrafterBlockEntity`, `world/level/block/ShelfBlock`, `world/level/block/CopperGolemStatueBlock` | Fabrication, mesure des cases, étagères et sélecteur par pose. |
+| `world/level/block/CreakingHeartBlock`, `world/level/block/entity/CreakingHeartBlockEntity`, `world/entity/animal/golem/CopperGolemAi`, `world/entity/ai/behavior/TransportItemsBetweenContainers` | Mesures et acteurs des montages. |
+| `world/level/block/TrappedChestBlock`, `world/level/block/entity/ChestBlockEntity`, `world/entity/animal/golem/CopperGolemAi` | Signal d’ouverture par joueurs et golems. |
+| `server/commands/ParticleCommand`, `server/commands/ComputeCommand`, `world/level/block/CommandBlock` | Différence entre fonctions administrateur et appareils accessibles en survie. |
+
+Les preuves Sanctuary et historiques se trouvent dans
+`mods/sanctuary/src/main/java/fr/koka/sanctuary/SanctuaryMod.java`,
+`expansion/ExpansionRuntime.java`, le [cahier du langage](langage-et-machines.md)
+et la [lecture de Redstone Computer](redstone-computer-reference.md).
+L’ancien particuleur est dans le dépôt voisin `26.2/redstoner`, sous
+`src/main/java/fr/koka99cab/sanctuary26/redstoner/` : `block/ParticuleurBlock.java`,
+`block/entity/ParticuleurBlockEntity.java`, `particle/ParticuleurParticleTable.java`.
+Ces références ne constituent pas un portage ni une validation en 26.3.

docs/backlog.md

@@ -844,9 +844,473 @@ Ce cadre narratif ne constitue pas une nouvelle mécanique implémentée.
 Construire ensemble le [cahier de conception](structures-conception.md) de la
 prochaine organisation de Sanctuary Island. La direction retenue est un départ
 naturel, quelques lieux isolés et mystérieux, des fonctions reproductibles par
-les joueurs et un donjon majeur nécessaire à la progression. Villes,
-regroupements et autres structures restent en réserve. L’installation
-d’expansion peut être reconstruite ailleurs que dans la salle historique.
+les joueurs et un donjon majeur nécessaire à la progression. Les Lost Cities
+sont principalement destinées aux continents d’expansion ; les autres structures
+restent en réserve pour l’île initiale. L’installation d’expansion peut être
+reconstruite ailleurs que dans la salle historique. Cette grande salle essentielle,
+également évoquée comme « salle de transformation », peut exister sans ville.
+La correspondance des noms est une hypothèse de travail à préciser dans sa fiche.
+
+**Préparation de l’alpha.23 demandée, sans démarrer le code maintenant :**
+retirer les bâtiments ordinaires de la génération de Sanctuary Island, tout en
+conservant les secrets, la grande traversée, le train et les rails abandonnés.
+Les voies peuvent finir dans la nature, sans gare ni bâtiment obligatoire ;
+elles doivent inviter à reconstruire un réseau utilisable. Les structures
+écartées restent en réserve. La passe de volumes et de sélection est à distinguer
+des futurs systèmes de boss, portails et raids ; aucun de ceux-ci n’est déclaré
+livré par cette préparation, et aucun monde existant n’est nettoyé de ses bâtiments.
+
+La piscine voisine de la salle d’expansion est retirée de la sélection active.
+Les autres pool rooms restent en réserve. La priorité va aux égouts et
+canalisations éclairés par de la redstone, avec plusieurs accès vers la salle,
+dont la trappe. Des galeries peuvent sortir de la roche et traverser le vide,
+avec des raccords et des volumes cohérents. Il s’agit du prochain cadrage de
+génération, sans suppression de structures dans les sauvegardes existantes.
+
+Les secrets doivent faire découvrir des systèmes utilisables puis reproductibles :
+terminal, contrôleur, afficheur et disquettes associés aux coffres, hoppers et
+comparateurs. De grandes salles montrent plusieurs systèmes de farming et leurs
+ordinateurs. L’apprentissage passe par les blocs, flux, signaux et programmes,
+sans panneaux explicatifs ; les afficheurs fonctionnels restent présents.
+Dimensions, état initial, récupération et contenu restent à concevoir.
+
+Le donjon majeur prend la forme d’un **immense laboratoire caché dans l’île**,
+contenant le portail des Cavernes et un gardien à vaincre : **zombie géant ou
+golem de pierre**, choix ouvert. L’auteur peut obtenir des modèles et sources
+de golems, encore à examiner. La victoire permet de débloquer et stabiliser les
+portails vers le monde de minage, avec un **achievement annoncé à tout le serveur**.
+Le rôle de l’objet de quête antérieur et l’activation directe ou par cet objet
+restent à définir. Le déblocage est
+collectif et permanent pour le serveur. Tous les joueurs, y compris les nouveaux
+arrivants, peuvent ensuite construire leur propre portail sans refaire l’étape
+du donjon individuellement ni obtenir l’objet de quête pour chaque portail.
+Le comportement du boss, les modalités d’activation initiale et la construction ou recette des
+portails restent à concevoir ; les prérequis de l’expansion des continents restent
+à définir séparément. Cette progression n’est pas encore implémentée.
+
+La conception intègre aussi un langage secret fondé sur l’écriture galactique,
+reliant redstone programmable, expansions, waystones et End. Le
+[cahier du langage et des machines](langage-et-machines.md) distingue cette
+direction du socle retenu : contrôleur, terminal, afficheur et disquettes.
+Le bloc Assembleur est retiré ; le terminal assure l’assemblage du code.
+L’assembleur direct, les six faces d’entrée/sortie et la RAM adressable sont
+retenus. La base proposée conserve l’état complet du contrôleur ; la liaison
+série supplémentaire reste en réserve. Grammaire, apprentissage et fonctions
+des appareils restent à préciser ; aucun interpréteur ou nouveau bloc n’est
+livré par WG-26.
+
+Le [dossier Redstone Language V0.1](redstone-language-extensions.md) propose
+maintenant un jeu d’instructions, des règles d’exécution continue et les fiches
+de placement, interaction, connexion et reprise des appareils. Les valeurs
+d’essai — RAM 1 Kio, quatre registres 8 bits, 64 instructions/tick — restent
+des propositions, pas une livraison du mod. Il distingue charges collectives,
+signaux 0–15, données et transferts d’objets réels.
+
+L’auteur demande aussi de **chercher les nouveaux blocs derrière les manques**,
+y compris les analogies électroniques. Le condensateur et ses gestes sont
+retenus : entrée arrière, sortie avant, maintien supérieur, réglage au clic et
+décharge au sneak-clic ; délais numériques encore proposés. Le convoyeur en cuir
+se pose comme un rail, à vitesse unique, et doit s’arrêter sans redstone pour
+éteindre les usines. Cela remplace la convention précédente de marche sans
+alimentation et inversion avec signal. Sens manuel et moteur à deux commandes
+sont proposés pour distinguer marche et inversion. Recette en H de bâtons avec
+cuir central, rendement ouvert.
+Une nouvelle piste propose la vitesse par cadence : si « signal horaire »
+désigne une horloge redstone, chaque impulsion ferait avancer d’un pas et la
+fréquence réglerait la vitesse moyenne. Cette interprétation et ce mode restent
+à confirmer ; ils ne remplacent pas silencieusement la marche continue proposée.
+Le [cahier signal et transport](redstone-language-signaux-et-transport.md)
+conserve ces décisions. Transistor et atténuateur sont retirés, jugés redondants
+avec circuits et contrôleur ; l’impulseur est également écarté. Lecteur de stock,
+aiguilleur, convertisseur binaire, horloge,
+pluviomètre, Adresseur et prises complètent les pistes. Comptoir et ancre
+spatiale attendent les services économiques et Galactium. Ces blocs sont
+des propositions examinables ; leur mention n’en valide ni le nom ni la recette.
+
+L’auteur demande d’explorer des blocs dont l’objet inséré donne la fonction,
+avec des pistes autour des gemmes. Sa réserve visait le porte-outil ; il précise
+qu’elle ne doit pas brider l’exploration des autres appareils. Le
+[cahier outils et cristaux](redstone-language-objets-et-cristaux.md)
+garde ces propositions en réflexion, sans les engager pour implémentation. Les
+émeraudes paient un villageois pour une tâche liée à son métier dans son périmètre
+d’action. Un contrat de travail avec matières présentes, déplacements et résultat
+livré est proposé ; les prix, règles de règlement et modalités d’attribution
+restent à définir. Aucun pouvoir technique n’est attribué d’office aux gemmes.
+
+Le [cahier des machines multiblocs](machines-multiblocs.md) prolonge cette
+recherche. **Retenus : 27 fours ordinaires en cube plein 3 × 3 × 3**, pour une
+chauffe commune, plusieurs matières et des recettes à chaud ; **27 barils en
+cube plein**, nommés **Fût**, pour un stockage parcouru par pages ou défilement.
+**Fourneau** est le nom proposé du grand four. Le **grand baril de fermentation**
+est renommé et traite plusieurs stacks d’une même recette, mais sa composition
+reste à choisir. Le dessin des slots attend l’inventaire custom. Le grand four
+reprend le kitchen oven d'It's Alive !, en conservant recettes, pages et qualité
+du mod autonome. Les autres procédés culinaires gardent leurs rôles distincts.
+
+**Collections retenues :** neuf objets par face de bloc, **81 visibles par
+façade 3 × 3, 324 distincts sur quatre façades**, avec possibilité de façade
+seule. Cartes, recettes, disquettes, photos, disques et spawn eggs sont prévus.
+**Présentoir** reste un nom proposé. **Méga-pistons retenus :** neuf pistons,
+tête 3 × 3, course de trois blocs et variante collante ; masse poussable ouverte.
+
+**Trémie retenue :** neuf hoppers plats en 3 × 3, **45 cases** communes. La
+sortie sous le centre, prolongée si besoin par un hopper ordinaire orienté,
+reste proposée. **Carillon retenu : assemblage adjacent choisi**, accords et
+courtes séquences. L’ordre de sélection pour ordonner les notes et les commandes
+de jeu restent proposés, sans rangée ou carré imposé ni fusion automatique.
+
+**Clé à molette dorée retenue :** orienter des blocs comme escaliers et barils,
+**assembler ou réassembler volontairement les multiblocs et les désassembler**.
+La dissociation rend les composants indépendants sur place : 27 fours séparés
+restent utilisables dans leur cube, sans réassemblage automatique après mise
+à jour ou rechargement. Conserver les contenus actuels et distinguer récupération
+de blocs et désassemblage. Gestes exacts, recette, usure, autres blocs concernés
+et traitement du piston en mouvement restent proposés ou à définir dans sa
+[fiche](machines-multiblocs.md#clé-à-molette-dorée--assembler-désassembler-et-orienter).
+L’auteur confirme la **Trémie facultative** : neuf hoppers voisins peuvent
+garder leurs cinq cases chacun, leurs becs et leurs circuits indépendants.
+**Règle commune retenue :** blocs indépendants dès la pose, réunion volontaire avec
+la clé, sans regroupement automatique imposé par la proximité.
+
+**Métablit** est le nom proposé par l’auteur ; la fonction d’établi collectif
+avec projet persistant reste proposée, sans rendre son usage obligatoire pour
+les crafts existants. La presse à moule est écartée ; Veilleur et batterie de
+distribution restent proposés, bassin, serre, écluse et alambic en réserve.
+Capacités hors Trémie/collections, débits, combustibles, alliages, coûts,
+fermentation et cycles hors ligne restent à concevoir. Ce travail reste
+documentaire, sans conversion de conteneurs ou de fours existants, nouvelle
+recette ou sauvegarde modifiée.
+
+L’[audit redstone Java 26.3](audit-redstone-26.3.md) couvre le modèle vanilla,
+ses composants et les différences du socle informatique Sanctuary. La cible
+effectivement lue est 26.3-pre-2, avec références Mojang et classes locales ;
+aucune mise à jour de version n’est incluse. Calcul et mémoire existent déjà
+en circuits vanilla ; la compacité, la reprogrammation et les supports de code
+sont les apports informatiques. Lectures exactes d’inventaires, texte et données
+serveur nécessitent des interfaces, distinctes du signal 0–15 et du transfert
+matériel des objets. Les opérations Galactium restent à raccorder à la progression.
+
+Le particuleur associe **objet-échantillon et type de particules**, puis
+**puissance redstone et débit d’émission** : arrêt à 0, débit croissant de 1 à 15.
+Clic droit et insertion par dropper sont demandés ; hopper proposé. Un contrôleur
+peut piloter le signal et les blocs d’alimentation ; un transfert direct d’item
+demande son contrat propre. Le code historique refuse l’extraction automatisée,
+à revoir pour permettre un changement automatique d’échantillon. Conservation
+de l’objet, table des effets, faces et cadence restent à définir. Aucun portage
+n’est réalisé par ce ticket documentaire.
+
+Les disquettes de langage redstone sont proposées comme supports physiques des
+programmes : écriture, transport, partage et découverte dans les ruines. Le
+partage, la duplication et la revente des programmes sont retenus. Parcours
+terminal/disquette/contrôleur, modalités de copie, capacité et vente restent à
+concevoir ; recevoir un programme ne fournit ni ressources ni déblocages.
+Aucun nouvel item n’est livré ici.
+
+La [lecture de Redstone Computer 2.0](redstone-computer-reference.md) documente
+la référence locale demandée et propose un socle programmable autonome relié
+aux fonctions Sanctuary. Le CPU continu, les périphériques et leurs débits
+restent à concevoir ; les plafonds et le chargement forcé historiques ne sont
+pas adoptés comme règles Sanctuary.
+
+Le cahier propose ensuite une expansion pilotée par programme dans une
+construction multibloc faite autour du contrôleur : pièces fonctionnelles,
+ressources, demande et suivi visibles dans le monde. Le moteur de génération
+existant fournit une partie des opérations ; raccord asynchrone, construction,
+consommation et déblocages restent à concevoir. Le minimum informatique conserve
+les trois blocs et les disquettes ; le bloc Assembleur reste retiré.
+
+La direction retenue pour le noyau galactique est maintenant : sa casse le fait
+disparaître sans objet récupérable, le serveur parle en galactique et une charge
+d’expansion devient disponible collectivement. Elle persiste indépendamment du
+découvreur ou de l’installation. Le noyau transportable, installé ou rechargeable
+est abandonné ; la machine utilise une charge commune et des ressources. Les
+météorites sont une voie de découverte, avec d’autres à définir.
+
+**Galactium est le nom retenu pour l’ensemble du système d’expansion.** Une interface
+est demandée. Le cahier propose une vue du terminal pour la réserve commune,
+le projet local, les ressources et la progression, liée
+au programme assembleur. La consultation n’immobilise aucune charge ; le lancement
+accepté engage la charge et les ressources une seule fois côté serveur.
+Disposition, règles de dépense collective et reprise après échec restent à
+préciser. Aucun nouvel écran, bloc ou événement n’est livré dans ce chantier.
+
+La demande de programmes à thème pour Indoors, Backrooms, Cavernes, Lost City,
+Nether et End reçoit une proposition dans le cahier : coordonner, mesurer,
+délimiter, retrouver, transformer et adresser. Ce sont des fonctions et exemples
+de programmes réutilisables à discuter, pas six déblocages déjà validés. Le
+déblocage collectif des Cavernes, les villes principalement sur les expansions et les accès aux autres
+dimensions conservent leurs décisions existantes. Aucun de ces programmes n’est
+implémenté dans ce ticket documentaire.
+
+La conception comprend désormais une recherche sur toutes les mises à jour de
+contenu Java et les premières apparitions importantes en version de développement,
+avec un dossier distinct sur l’ordre des skins. L’orthographe **Efe** remplace
+Mefe sur décision de l’auteur. La [proposition mythologique](histoire-steve-galactium.md)
+sépare la chronologie réelle, ses interprétations et les biographies inventées :
+Galactium comme mathémagie, découverte des anciennes solutions et disparition
+des neuf. Le récit et les rôles proposés ne deviennent pas automatiquement du
+canon ni des fonctionnalités livrées.
+
+La direction cosmologique retient **Galactium comme le vide structurant** qui
+donne aux choses leur place et leurs relations, dans une approche d’exploration
+et d’ingénierie de science-fiction. Le nom englobe désormais le phénomène et le
+système d’expansion. Sa conscience éventuelle reste ouverte ; les anciens
+peuvent en maîtriser certains effets sans comprendre l’ensemble. L’assembleur,
+les installations, les charges collectives et les ressources conservent leurs
+contrats de conception. Cette précision est documentaire.
+
+Les communications de Galactium retiennent coordonnées, morceaux de programmes
+et rendez-vous préécrits. Elles passent par des [afficheurs diégétiques](langage-et-machines.md#afficheurs-diégétiques-textes-dynamiques-et-statistiques)
+avec du texte dynamique ; ces supports peuvent aussi afficher des statistiques.
+Les rendez-vous sont préparés à l’avance, puis leurs données peuvent s’actualiser
+depuis l’état du serveur. Les autres catégories de messages et exemples refusés
+par l’auteur sont exclus. Le support retenu est un panneau extensible : raccord
+visuel CTM, carré ou rectangle plein uniquement, huit lignes par bloc en hauteur.
+Un écran de W × H blocs présente 8H lignes sur toute la largeur W. L’extension
+en attente jusqu’à complétion du rectangle est proposée pour permettre la pose
+bloc par bloc. Taille maximale, casse, fusion de contenus, mesures accessibles
+et raccordement aux programmes restent à définir ; aucun afficheur n’est implémenté.
+
+Le [cahier des connexions](langage-et-machines.md#connexions-aux-fonctions-de-minecraft--proposition)
+propose un panneau autonome lisant un signal redstone et un écran relié directement
+à une face du contrôleur pour afficher ses calculs. Réserves, fret, chronomètres,
+énigmes, livres et tableaux de statistiques donnent des usages à discuter.
+Le comparateur reste une mesure de remplissage ; quantités exactes, contenu
+des livres et données personnelles demandent des sources distinctes à concevoir.
+Ces propositions ne fixent pas encore le protocole ni les nouveaux accès du langage.
+
+L’auteur retient **chronomètre, calendrier, jauge de coffre et progression**
+comme programmes de départ d’un **afficheur programmable à usage général**.
+Les joueurs peuvent les modifier et créer leurs propres applications ; fret,
+stand de tir, énigmes et affichage de livres sont d’autres usages possibles,
+avec leurs sources et raccordements à concevoir. Les capacités du programme
+se composent à partir des données et opérations exposées par le serveur.
+La conception économique inclut désormais des [shops construits avec
+des blocs vanilla](vision.md#boutiques-construites-avec-des-blocs-vanilla).
+Un étal de joueur est proposé : stock en coffre ou tonneau, cadre d’article,
+afficheur de prix et disponibilité, achat serveur et livraison mailbox. Le
+contrôleur est facultatif dans cette proposition. Règles de transaction,
+propriété, déblocage et publication éventuelle au Black Market sont à concevoir
+avant implémentation.
+
+La consolidation retient **Sanctuary comme RPG Minecraft pour environ vingt
+joueurs**, avec des contributions variées : construction, redstone, minage,
+exploration, PvE et PvP. Cette cible ne modifie pas les presets 512/724/1024 et
+n’impose pas à tous de programmer. Les [informations à découvrir](vision.md#informations-à-découvrir)
+comprennent des cartes au trésor pointant un coffre réel sur une île déjà générée,
+des programmes et des palettes du Blocodex liées aux advancements Minecraft et
+Sanctuary pour ouvrir des articles achetables. La mémoire personnelle actuelle
+des blocs n’accorde aucun achat ; portée des déblocages, stocks et paiement
+restent des contrats distincts à définir.
+
+**Black Market désigne désormais le shop en ligne du serveur**, avec des biens
+courants et certaines anomalies à définir, en rubis ou saphirs selon l’offre.
+Il ne désigne plus uniquement les offres des joueurs. Le rubis est la monnaie
+principale des échanges entre joueurs, des boutiques et des navets. L’émeraude
+conserve le rôle villageois ; les achats en saphirs sont à articuler aux réservations
+de catalogue. Le shop doit préserver la demande pour la production et le commerce
+entre joueurs. Disponibilités, limites et prix restent à éprouver ; aucune monnaie,
+offre ni nouvelle liaison de progression n’est livrée par ce ticket.
+
+La direction vise des [combinaisons émergentes](langage-et-machines.md#combinaisons-émergentes) :
+réutiliser mesures, temps, objectifs, mémoire et opérations dans des montages
+différents. Réserve régulée, chantier collectif, parcours à sessions, marché
+à horaires, approvisionnement rémunéré et fret sont des exemples proposés.
+Les sources de données et les contrats de chaque action restent nécessaires ;
+ces exemples ne deviennent pas des fonctionnalités livrées ni une liste fermée
+de modes d’afficheur.
+
+Le [cahier de progression et d’intégration](progression-et-integrations.md)
+relie les découvertes aux fonctions communautaires à débloquer : recettes JEI,
+minimap, carte du monde et waypoints, plans Litematica/Architext, avec les waystones, l’alchimie
+et l’enchantement à articuler. Il distingue acquis serveur, affichage client et
+fonctions réelles ; paliers et portée personnelle ou collective restent à définir.
+**Nature’s Compass et la recherche automatique de biomes sont retirés.** Les
+waystones se découvrent notamment comme ascenseurs vers une installation ; leurs
+liaisons horizontales restent précises, vers une destination connue et coûteuses
+en XP selon la distance.
+
+La progression distingue désormais **compétences par paliers**, **unlocks
+facultatifs** uniques ou par paliers, et **facultés galactiques** endgame.
+Lorsque **toutes les compétences sont au maximum**, le personnage peut acquérir
+des facultés galactiques ou choisir un prestige. Ni tous les unlocks ni les
+facultés galactiques ne sont nécessaires au prestige. Celui-ci donne des charges
+personnelles à dépenser pour ajouter des places dans sa faction :
+**les unlocks achetés restent acquis et les compétences
+sont à remonter**. Conservation et réactivation des facultés galactiques acquises,
+XP restante, collections, liste des compétences, seuils et prix restent à préciser.
+
+Mining règle la vitesse et la capacité du vein mining ; Build règle la portée
+et la capacité du vein building. Ces techniques se débloquent avec les
+compétences, sans achats d’unlocks séparés, et suivent leurs niveaux après un
+prestige. Mining 0 désactive le vein mining ; le premier repère est un groupe
+de **4 blocs au total dès Mining 1**, puis davantage aux niveaux suivants.
+**64 blocs** est un exemple avancé, sans courbe ou plafond encore fixé.
+Le [cahier des paliers](progression-et-integrations.md#vein-mining-et-vein-building--paliers-des-compétences)
+retient une casse commencée simultanément sur tous les blocs sélectionnés,
+avec une durée dépendant du groupe, des blocs, de l’outil et de Mining. Un groupe
+plus grand prend davantage de temps ; le gain réduit aussi les manipulations
+entre les blocs. Le vein building remplit un trou ou une surface sur un seul
+plan, avec les matériaux du joueur et dans sa portée. Seuils de Build, durées,
+usure, interruptions et sélection restent à définir.
+L’affichage des noms d’entités est
+un unlock unique retenu, avec catégories, listes de noms et identifiants de
+mobs personnalisables par configuration.
+
+**Minecraft Schematics est la source retenue**, avec bibliothèque personnelle
+et prévisualisations dans le menu Build. Le combat et l’obtention de blocs
+assortis peuvent donner ou proposer des plans ; seuils et conditions restent à
+choisir. Au stade galactique, **toutes les compétences au maximum** et un coût proposé de **64 niveaux**
+ouvriraient la consultation du catalogue complet du site. Auteur, source et
+conditions de réutilisation restent associés aux plans ; aucun import ni pose
+gratuite n’est réalisé. Architext n’est pas retrouvé à ce stade.
+
+L’auteur demande des manipulations natives de l’inventaire incrémental et une
+réimplémentation des familiers : emplacement de spawn egg près de la main
+secondaire, effet passif et actif par touche, avec un emplacement de cape.
+Un slot cosmétique distinct au-dessus de la cape reçoit des créations 3D sans
+pouvoir. La priorité des familiers est leur présence : collisions avec le décor,
+franchissement des obstacles et absence de collision gênant les joueurs. Ils
+ne donnent aucun loot ; leur mortalité reste ouverte. Ender Dragon et Wither
+sont retenus comme familiers galactiques, sans fixer leurs effets ni leur taille.
+AppleSkin ou un HUD natif doit suivre les capacités réelles ; l’état de l’équipement
+dispose d’un affichage activable. Porter un hostile conserve son danger.
+Sound Physics Remastered est la référence acoustique confirmée. Les préférences
+visuelles/sonores libres et les correctifs du pack sans déblocage sont le cadrage
+proposé ; NetherPortalFix reste un candidat du pack à vérifier sur la version
+exacte. Aucun de ces ajouts n’est livré.
+
+Les familles de butin retenues sont **général, capes, cosmétiques et familiers**,
+distinctes de la rareté des équipements. « Loots spawner » est interprété comme
+des spawn eggs, sans attribuer de blocs spawners. Couleurs et hiérarchie restent
+à valider. **Anomaly** désigne l’équipement ultime en titane, infrabricable,
+incassable, doté d’enchantements exceptionnels et nommé en galactique ; le lien avec
+la lootbox historique et ses sources reste à articuler, sans taux de drop fixé.
+
+Les pages culinaires d’**It’s Alive !** rejoignent explicitement cette progression :
+livre de **Kai**, cuisinier fixé par le tirage de conception du 11 septembre 2026,
+et pages secrètes des sorcières. Le livre n’est plus attribué à Steve et le nom
+n’est pas tiré de nouveau à chaque monde. La qualité des plats dépendrait de la
+préparation et du moment de récupération ; indices, durées et effets restent à
+concevoir, avec des concours jugés par Kai. It’s Alive ! conserve son autonomie.
+
+Les anciens peuvent visiter l’île pendant une journée et ouvrir un menu au
+clic droit. Kai accompagne la cuisine et Alex la nature ; Ari pour le Build,
+Makena pour la redstone et Zuri pour les étoiles et le temps sont désormais des rôles retenus.
+Steve reste absent ; des flashs d’Herobrine sont souhaités sans l’identifier à
+Steve. Rythme des visites, quêtes, échanges et concours restent à définir, sans
+maison permanente imposée à chaque ancien ni invocation supplémentaire retenue.
+
+Le [journal des transformations](journal-et-progression-du-monde.md) prépare un
+suivi causal daté des entrées, sorties, procédés et acteurs. Production, transfert,
+consommation, perte, connaissance et stock y sont distingués. Les futurs plans,
+Backrooms, Indoors et donjons pourraient exploiter cette histoire ; les compteurs
+journaliers actuels ne la reconstruisent pas. Provenance, couverture, budgets,
+persistance et reprise doivent précéder toute récompense ou restitution ; une
+nouvelle génération ne réécrit pas les lieux déjà visités.
+
+La direction des [raids instanciés](progression-et-integrations.md#raids-collectifs-instanciés)
+retient **un raid par semaine pour tout le serveur, dix joueurs requis**. Le
+portail secret est désormais à découvrir et débloquer sur **une île générée par
+expansion**, pas sur Sanctuary Island. Fréquence et conditions d’accès restent
+à définir. Le donjon est procédural, difficile, inspiré des Trial Chambers
+avec une palette propre à concevoir, en mode aventure et avec blocs incassables.
+Pas de sortie libre pendant l’épreuve ; abandon et retour sûr sont à concevoir.
+Le **butin matériel est commun**, prévu pour dix et partagé librement par les
+joueurs après ramassage, sans attribution personnelle automatique. Difficulté
+fixée au lancement, quota commun même avec plusieurs portails, incidents et
+réutilisation restent à traiter. Le raid ne remplace pas le donjon
+initial des Cavernes ni les spawners exploitables du monde persistant.
+
+Les [lieux aériens](structures-conception.md#lieux-flottants-du-monde-initial)
+initiaux comprennent un ou deux îlots riches envisagés, des bateaux marchands
+en périphérie de Sanctuary pour obtenir les premiers villageois et des
+montgolfières. Cascades d’accès facultatives, coffres et implantation restent à
+dessiner ; les temples sont retirés de la génération de base. Un laboratoire de
+confinement animal avec Mooblooms est souhaité sur les expansions, sans quota
+garanti ni ajout à l’île initiale. Le départ naturel reste prioritaire.
+Les expansions pourront aussi accueillir un biome étrange dominé par le
+mycélium ; palette, fréquence et conditions de génération restent à définir.
+
+Les très grands continents peuvent accueillir des océans et des temples ou
+monuments sous-marins pour une rencontre de boss aquatique à définir. Un mob
+géant est souhaité dans le volcan, sans identité ni récompense arrêtée. Les
+Lost Cities peuvent déborder sur le vide, même sur une expansion de **64 blocs
+de rayon** : raccords, accès et volumes doivent rester cohérents. Cet
+assouplissement ciblé n’impose pas les villes à chaque île et ne change pas les
+presets de Sanctuary Island ; les placements incohérents restent refusables.
+
+Le bateau-poule doit pouvoir tracter et soulever, par des cordes, d’autres bateaux
+occupés par des villageois ou des animaux. Cela relie le transport à l’extraction
+depuis les bateaux marchands périphériques et le laboratoire de Mooblooms.
+Attaches, charges, nombre de bateaux, maniabilité et limites physiques restent
+à concevoir et tester. Aucun véhicule, lieu ou butin n’est livré par ce ticket.
+
+Le **Booat**, surnommé « bi-poule » entre nous, est une mécanique centrale : un
+grand bateau à quatre, fabriqué avec quatre bateaux et décliné dans toutes les
+variantes de bois. La capacité est confirmée : quatre joueurs sur l’eau, deux
+joueurs et deux poules en vol, pilote compris. Recette détaillée, variantes de
+radeaux, traction et comportement après perte d’une poule restent à définir.
+
+La [chronologie Sanctuary](chronologie-sanctuary.md) articule ce récit au temps
+réel : origine historique Minecraft, origine Sanctuary et âge propre à chaque
+partie. Les dates données de mémoire (16 mars, 24 mai, 17 août et 8 septembre
+2026) sont confrontées aux [archives](recherche-archives-sanctuary.md) avant de
+devenir des constantes du jeu. Un nom de dépôt, un commit et une publication
+ne prouvent pas le même événement. Aucun changement d’horloge ou de sauvegarde
+n’est livré ici.
+
+Une [direction culturelle implicitement queer](histoire-steve-galactium.md#identités-apparences-et-transformations)
+est retenue : apparence, identité et possibilités de jeu ne se déterminent pas
+mutuellement ; les transformations peuvent être ordinaires dans le récit.
+Les scènes et avatars successifs restent des propositions. Cette mythologie
+appartient à Sanctuary, sans assigner une identité aux joueurs ni la présenter
+comme un fait du canon officiel de Minecraft.
+
+Une [entrée dans la mythologie](histoire-steve-galactium.md#entrer-dans-la-mythologie--accueil-avant-la-première-apparition)
+est demandée avant la première apparition jouable : **fiche personnage d’abord**,
+avec skin, pseudo et bio, puis **courte cinématique** avec séquence en alphabet
+galactique, initialisation du personnage et figuration graphique d’une recherche
+d’emplacement sûr, comme un ordinateur qui démarre. L’arrivée se fait ensuite
+dans la nature. Le choix réel et la vérification de l’emplacement restent du
+ressort du serveur ; les détails de la représentation sont à concevoir.
+L’ancien scénario et le fragment galactique avant le profil sont retirés.
+L’archive reste une piste narrative sous-jacente, sans explication à l’accueil.
+La demande inclut des **amitiés natives et une bio publique ou réservée aux amis**.
+Le [cahier d’accueil et des profils](accueil-et-profils.md) conserve une bio
+facultative, des demandes d’amitié acceptées et une visibilité appliquée côté
+serveur. Le mode Masquée et son emploi par défaut restent proposés.
+Aucune déclaration de genre ou d’identité personnelle n’est requise.
+**Rattachement au compte retenu :** présence dans la mythologie,
+événements et progression dans le monde concerné sont liés au compte authentifié
+(UUID), avec pseudo et skin actuels à l’affichage. Un changement de nom ou
+d’apparence conserve cette continuité. La première apparition effective sur le
+serveur, après la cinématique, publie une seule fois **« helloworld {pseudo} »** ;
+les connexions suivantes utilisent **« {pseudo} joins the game »**, avec suivi par
+UUID et pseudo actuel affiché. Durée, gestes, fréquence et raccord à
+la connexion restent proposés ou à concevoir. Aucun écran, cinématique,
+traitement de connexion, système social ou format de sauvegarde n’est livré par ce cahier.
+
+Le nom visible se compose **faction → pseudo → prestige en chiffres romains** ;
+nom ou emblème du groupe restent à dessiner. La couleur reste personnelle,
+choisie dans une **palette configurée avant tout joueur** : 20 habitants prévus,
+20 teintes distinctes. Chaque choix réserve une couleur à l’UUID, même hors
+ligne ; elle devient indisponible pour les autres. Cette palette remplace le
+choix individuel entièrement libre et ne suit pas les changements de faction.
+**Le choix de couleur est intégré à la fiche de création de personnage.**
+Extension de palette et réattribution restent à définir.
+**Une faction commence avec trois places.** Les prestiges donnent des charges
+personnelles liées au joueur, qu’il peut dépenser dans sa faction pour ajouter
+des places. Ces charges sont distinctes de Galactium ; leur dépense ne diminue
+pas le compteur romain des prestiges accomplis. Nombre de charges gagnées,
+coût des places et conséquences d’un départ restent à définir, sans nouvelle
+capacité bonus. Voir le [cahier des profils](accueil-et-profils.md#couleur-personnelle-faction-et-prestige).
+
+L’audit retrouve l’alpha publique du 7 juillet 2026, confirmée par Modrinth et
+par l’empreinte de l’archive locale. Les créations de dépôts du 17 août et du
+8 septembre ne prouvent pas, à elles seules, les dates de début des phases.
+L’anniversaire annuel de Sanctuary est retenu pour la future release officielle,
+avec une date à consigner lors de cette publication ; l’événement reste à concevoir.
 
 Le résultat attendu est une sélection précise, les règles d’implantation et de
 découverte, des fiches de lieux avec utilité et architecture, le rôle du boss et
@@ -868,13 +1332,13 @@ Ces thèmes servent à retrouver la vision, pas à demander leur implémentation
 | --- | --- |
 | Distribution et apparence | packwiz, mods communautaires, resource packs, shaders, icône, chargement, crédits et attributions |
 | Expansion collective | deposit boxes, objectifs de production, ordinateur d'expansion, ouvertures persistantes |
-| Progression | capacités, XP, inventaire, prestiges débloquant des slots de factions, recettes et advancements, capes et familiers |
+| Progression | compétences et unlocks par paliers, facultés galactiques au maximum des compétences, prestige avec unlocks conservés et charges personnelles pour agrandir sa faction, XP, inventaire, recettes et advancements, capes et familiers |
 | Économie | gemmes, mailbox, shop, offres horaires, bourse du navet (achat à la loterie du dimanche, revente au shop pendant la semaine), black market, catalogue, coffre-fort et drill |
-| Groupes et métiers | couleurs, équipes temporaires, factions et slots liés aux prestiges, cloches et bannières, villageois et copper golems |
+| Groupes et métiers | palette de couleurs personnelles réservées par UUID, préfixe de faction et suffixe de prestige romain, équipes temporaires, factions de trois membres agrandies en dépensant des charges de prestige, cloches et bannières, villageois et copper golems |
 | Production et construction | convoyeurs, stockage, terminaux, ordinateur 8 bits, vein mining/building, plans et prefabs |
 | Dimensions | cavernes, Alpha, Backrooms, indoors, salles secrètes et récupération des objets perdus |
 | Faune et combats | zombies, fantômes, baleine, creepers, poules rares, Mooblooms, noms, armes et explosifs |
-| Mobilité | waystones, téléporteurs, ziplines, grappin, aéronefs, Magic Carpet et interactions physiques |
+| Mobilité | waystones, téléporteurs, ziplines, grappin, bateau-poule et Booat, aéronefs, Magic Carpet et interactions physiques |
 | Temps et histoire | temps réel, calendrier, événements, loterie, étoiles, constellations, cube et sept boules |
 | Objets et surprises | caméra, œil d'araignée révélant les niveaux de lumière, disque blanc, chunky, particuleur, lucky blocks et lootboxes |
 | It's Alive ! | agriculture localisée, ustensiles, recettes, fermentation, affinage et pages secrètes |

docs/chronologie-sanctuary.md

@@ -0,0 +1,192 @@
+# Chronologie de Sanctuary et calendrier en temps réel
+
+**Repères donnés de mémoire : création le 16 mars 2026, développement le 24 mai,
+alpha le 17 août et bêta le 8 septembre.** Ils restent à confronter aux versions
+historiques ; un souvenir n’est pas une date de publication certifiée. Minecraft
+constitue la chronologie principale, dans laquelle Sanctuary ouvre sa propre histoire.
+Le temps du monde doit suivre le temps réel. Les conventions de calendrier
+ci-dessous constituent une proposition avant implémentation.
+
+Ce document complète [l’histoire de Steve et de Galactium](histoire-steve-galactium.md)
+et les dossiers [2009–2014](recherche-minecraft-2009-2014.md),
+[2015–2026](recherche-minecraft-2015-2026.md) et
+[personnages](recherche-minecraft-personnages.md). « Chronologie principale »
+désigne l’histoire de Minecraft, pas une demande de fusion Git dans `main`.
+
+## Les origines et les jalons
+
+| Repère | Date ou origine | Sens |
+| --- | --- | --- |
+| **Ère Minecraft** | **17 mai 2009**, origine proposée | Anniversaire public reconnu par Mojang. Les prototypes antérieurs appartiennent à la préhistoire documentaire. |
+| **Ère Sanctuary** | **16 mars 2026**, souvenir de l’auteur | Origine de travail à confirmer avant de la figer dans les sauvegardes. |
+| **Développement / première version** | **24 mai 2026**, souvenir et mention de l’ancien site | 69 jours après cette origine ; annonce datée de mai, conservée dans Git en juillet seulement. |
+| **Alpha publique retrouvée** | **7 juillet 2026**, publication Modrinth et archive identique | Pack `2026.07.07`, Minecraft `26.1.2`, 113 jours après l’origine proposée. |
+| **Dépôt historique / jalon alpha évoqué** | **17 août 2026**, création Gitea attestée | 154 jours après l’origine proposée ; l’alpha publiée en juillet est antérieure. |
+| **Nouvelle base nommée Beta** | **8 septembre 2026**, création Gitea et premier commit attestés | 176 jours après l’origine proposée ; ses premières versions restent numérotées alpha. |
+| **Anniversaire officiel** | Jour de la future release officielle, à enregistrer lors de sa publication | Fête annuelle de Sanctuary, retenue par l’auteur ; ne pas la fixer à une ancienne alpha par défaut. |
+| **Âge de la partie** | Création effective de chaque monde serveur | Histoire locale de cette communauté : découvertes, charges, expansions et événements. |
+
+Le 17 mai s’appuie sur l’anniversaire célébré par Mojang ; ce choix calendaire
+ne prétend pas dater le premier prototype. Le modèle humain antérieur au
+lancement public est étudié dans le dossier personnages.
+[Mojang, 17 mai 2024](https://www.minecraft.net/en-us/article/the-15th-anniversary-cape).
+
+Un serveur créé en septembre ne prétend pas avoir fonctionné depuis mars.
+Il partage un passé narratif, puis possède son propre historique de partie.
+Les neuf disparus appartiennent à cette histoire proposée ; les réalisations
+des joueurs sont celles réellement enregistrées dans leur monde. Des serveurs
+séparés ne partagent pas leurs réserves de charges.
+
+## Place dans la chronologie principale
+
+Les possibilités du jeu sont documentées dans les dossiers historiques. Leur
+lecture narrative ci-dessous reste une proposition pour Sanctuary.
+
+| Période | Repère Minecraft | Lecture mythologique proposée |
+| --- | --- | --- |
+| 2009–début 2010 | Premières phases et Indev ; construction, survie, fabrication, types de mondes dont les îles flottantes. | Steve mesure et rend habitable un lieu limité. |
+| 2010–2011 | Infdev, Alpha, Beta, 1.0 : élargissement du monde, redstone, Nether, mécanismes, puis End et enchantements. | Les limites et les relations entre les lieux deviennent des questions. |
+| 2012–2013 | 1.1 à 1.7.2 : commerce, écriture, automatisation et diversité des territoires. | Les solutions deviennent des installations capables de fonctionner pendant une absence. |
+| 2014 | 1.8 et arrivée d’Alex. | Une deuxième mémoire compare et conserve les transformations du monde. |
+| 2016–2019 | 1.9 à 1.15 : exploration, progrès, océans, métiers, vie des villages et abeilles. | Steve et Alex cherchent à relier des lieux et des usages sans en perdre l’histoire. |
+| 2020–2021 | 1.16 à 1.18 : Nether enrichi, repérage et retour, cuivre, améthyste, nouvelles profondeurs. | Matière, forme et adresse deviennent comparables : premières formulations de Galactium. |
+| 2022 | 1.19 et apparition commune des sept nouveaux skins. | Les neuf mettent en commun leurs expériences et retrouvent d’autres traces anciennes. |
+| 2023–2025 | 1.20, 1.21 et drops : archéologie, conservation des récits, fabrication automatique et nouveaux usages. | Les expériences deviennent une infrastructure ; la prospérité augmente les dépendances. |
+| **16 mars 2026, provisoire** | Création donnée de mémoire. | Origine proposée de la branche narrative Sanctuary. |
+| **24 mai 2026, à recouper** | Jalon de développement donné de mémoire. | Son équivalent dans la fiction reste à choisir. |
+| **7 juillet 2026** | Publication alpha `2026.07.07` sur Modrinth, archive retrouvée. | Première diffusion alpha directement recoupée par cet audit, pas nécessairement toute première diffusion du projet. |
+| **17 août 2026** | Création du dépôt historique attestée ; début exact de l’alpha 26.2 encore inconnu. | Une étape de développement ne date pas automatiquement une catastrophe du récit. |
+| **8 septembre 2026** | Nouvelle base `sanctuary-beta` attestée dans Git ; version initiale `0.1.0-alpha.1`. | Distinguer le nom du projet, sa phase souhaitée et les versions effectivement distribuées. |
+| Après la fondation | Minecraft et Sanctuary continuent d’évoluer ; chaque partie enregistre ses propres événements. | Les joueurs peuvent vivre l’histoire suivante, sans tout attribuer aux anciens. |
+
+Si le 16 mars est confirmé, la dernière Java stable à la fondation est **1.21.11**, publiée le 9 décembre
+2025. **26.1 / Tiny Takeover** paraît le **24 mars 2026**, huit jours après la
+fondation, et avant le jalon éditorial du 24 mai retrouvé sur l’ancien site. **26.2 / Chaos Cubed**,
+du **16 juin 2026**, vient ensuite. Le détail de 26.3 et de ses préversions figure
+dans le dossier récent.
+[Java 1.21.11](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-21-11),
+[Java 26.1](https://www.minecraft.net/en-us/article/minecraft-java-edition-26-1),
+[Java 26.2](https://www.minecraft.net/en-us/article/minecraft-java-edition-26-2).
+
+Cette comparaison ne prouve pas quelle version Minecraft le premier mod de
+développement utilisait. Elle n’oblige ni à recréer une ancienne instance ni
+à retirer les blocs récents des mondes actuels. Elle sert à dater un récit :
+un élément ajouté après la fin choisie pour l’activité des anciens demande une
+intervention ultérieure ou un prototype effectivement documenté. Disponibilité
+expérimentale et sortie stable sont deux événements différents.
+
+Les sources locales et distantes, ainsi que leurs limites, sont consignées dans
+[l’audit des archives Sanctuary](recherche-archives-sanctuary.md). Les noms de
+versions historiques sont conservés tels quels : ils ne sont pas renommés pour
+les faire correspondre à ces quatre souvenirs.
+
+La création ne date pas automatiquement la disparition des neuf. Même après
+confirmation des jalons, leur donner le sens d’une dernière période d’expériences
+ou d’une séparation serait un choix narratif supplémentaire.
+
+## Compter les jours
+
+Sous réserve de confirmer l’origine du 16 mars, proposition : afficher des
+**jours civils écoulés**, avec **J+0** le jour de
+l’origine. Les dates de fondation sont des dates, pas des instants UTC dont on
+aurait inventé l’heure. Elles restent affichées comme le 17 mai et le 16 mars,
+quel que soit le fuseau choisi pour présenter un événement.
+
+Pour une même date civile `d` dans le fuseau calendaire de référence :
+
+```text
+jour_minecraft(d) = différence de dates entre 2009-05-17 et d
+jour_sanctuary(d) = différence de dates entre 2026-03-16 et d
+jour_partie(d)    = différence de dates entre la création de cette partie et d
+```
+
+**jour_minecraft = jour_sanctuary + 6 147**.
+
+| Date civile | Ère Minecraft | Ère Sanctuary proposée | Depuis le jalon du 24 mai |
+| --- | ---: | ---: | ---: |
+| 16 mars 2026 | J+6 147 | J+0 | Avant le jalon |
+| 24 mars 2026 | J+6 155 | J+8 | Avant le jalon |
+| 24 mai 2026 | J+6 216 | J+69 | J+0 |
+| 7 juillet 2026 | J+6 260 | J+113 | J+44 |
+| 17 août 2026 | J+6 301 | J+154 | J+85 |
+| 8 septembre 2026 | J+6 323 | J+176 | J+107 |
+| 11 septembre 2026 | J+6 326 | J+179 | J+110 |
+
+Un affichage possible serait **« Sanctuary · J+179 · 08:00 »**, avec l’ère
+Minecraft et l’âge de la partie dans le calendrier détaillé. Le 11 septembre
+est un exemple daté, pas une valeur à figer dans le jeu. L’âge de la partie ne
+peut être rempli qu’à partir de son origine effective. Afficher « Jour 1 »
+plutôt que J+0 demanderait un décalage explicite ; 179 jours écoulés et le
+180e jour sont deux façons différentes de décrire la même date.
+
+## Horloge commune et simulation
+
+La direction retenue est une correspondance avec l’heure civile choisie par
+l’administrateur : à 8 h dans ce fuseau, il est 8 h dans le monde. Tous les
+joueurs partagent ce repère, même s’ils habitent dans des pays différents.
+Le sommeil ne fait pas sauter la nuit.
+
+La date et l’heure ne dépendent pas de la vitesse de simulation. Les événements
+peuvent conserver un instant UTC, présenté dans le fuseau choisi. Les jours du
+calendrier changent à minuit dans son fuseau de référence, par différence de
+dates civiles : une journée de changement d’heure ne dure pas toujours
+86 400 secondes. Un fuseau géographique et un décalage horaire fixe sont deux
+choix différents à présenter clairement.
+
+| Domaine | Comportement proposé |
+| --- | --- |
+| Date, heure et âge calendaire | Continuent avec le temps réel, même serveur arrêté. |
+| Ciel de l’Overworld | Retrouve l’heure civile courante à la reprise ; transitions et changements de fuseau restent à concevoir. |
+| Cultures, mobs, redstone et programmes | Ne reçoivent pas automatiquement des heures de simulation hors ligne. |
+| Charge libérée ou expansion acceptée | État persistant ; le passage du temps ne crée aucune charge ni nouvelle opération. |
+| Nether, End, Indoors et Backrooms | Peuvent partager une date commune en gardant leurs ambiances et cycles propres. |
+
+Attendre quelques ticks permet de coordonner un montage ; attendre dimanche
+concerne une échéance civile. Le futur langage doit distinguer ces usages.
+Une sauvegarde ou restauration conserve l’origine de la partie. Changer le
+fuseau d’affichage ne réécrit pas les instants du journal. Changer le fuseau
+du calendrier ou corriger une horloge système exige une règle explicite.
+
+## Événements, étoiles et mémoire
+
+**Sanctuary aura un anniversaire annuel à la date de sa release officielle.**
+La direction est retenue ; le jour reste inconnu jusqu’à cette publication.
+L’historique retrouvé du 7 juillet concerne une alpha et ne remplace pas ce
+futur jalon. L’anniversaire commun du jeu peut être célébré par chaque serveur,
+en plus de l’âge propre de sa partie. Le calendrier le signalera ; la fête,
+ses activités et ses éventuelles récompenses restent à concevoir. Aucune
+récompense économique ni charge d’expansion automatique n’est décidée ici.
+
+Loterie du dimanche, achat hebdomadaire des navets, offres horaires, anniversaires
+et panneaux d’événements s’appuieraient sur le même calendrier. Le traitement
+d’une échéance manquée pendant un arrêt reste à définir ; aucun tirage ni gain
+rétroactif automatique n’est décidé ici.
+
+Le dimanche civil peut donner un repère concret au cycle de six jours puis un
+jour de fête. Un cycle compté depuis la fondation serait une autre convention,
+à distinguer de la semaine civile.
+
+Les étoiles naissent toujours des accomplissements réels de la partie. Des
+milliers de jours d’histoire préalable ne donnent pas automatiquement les
+étoiles des anciens aux nouveaux joueurs. Des cartes célestes retrouvées dans
+l’observatoire pourraient témoigner d’un autre ciel : une piste narrative.
+
+Un noyau brisé, une charge libérée, une expansion acceptée et un continent
+ouvert constituent des événements différents. Leurs dates suivent ce qui s’est
+effectivement produit sur le serveur. Le calendrier rend leur succession
+consultable sans fabriquer un historique d’activités antérieures.
+
+## Points restant à définir
+
+- Recouper les quatre dates données de mémoire ; fixer ensuite l’origine Sanctuary, l’origine Minecraft proposée du 17 mai 2009 et l’affichage J+0.
+- Enregistrer la date effective de la release officielle pour l’anniversaire annuel de Sanctuary.
+- Choisir le fuseau initial et les règles de changement de fuseau ou d’horloge.
+- Déterminer l’origine d’une ancienne partie sans date fiable, avec un contrat de migration avant toute écriture dans sa sauvegarde.
+- Définir reprises, expirations et opérations hors ligne pour les activités qui emploient le temps réel.
+- Choisir les éventuels événements de fiction correspondant aux jalons historiques, ainsi que la date ou l’intervalle de disparition des anciens.
+
+Les relevés quotidiens du Blocodex décrits actuellement sont agrégés en UTC.
+Ils ne fournissent pas à eux seuls un journal local exhaustif ni un passé
+antérieur à leur installation. Le calendrier futur doit conserver ces limites.
+Ce document ne change ni l’horloge du jeu, ni les sauvegardes, ni les règles
+économiques d’une instance.

docs/histoire-steve-galactium.md

@@ -0,0 +1,507 @@
+# La mémoire de Steve et la naissance de Galactium
+
+Sanctuary peut raconter l’histoire d’une civilisation qui a grandi avec les
+possibilités de Minecraft. Les mises à jour fournissent l’ordre des découvertes,
+les personnages fournissent des regards différents sur ces découvertes, et les
+ruines permettent aux joueurs d’en retrouver les conséquences.
+
+La chronologie documentaire et le récit ont deux statuts distincts. Les dates
+et contenus sont établis dans les dossiers sourcés ci-dessous. La biographie,
+les relations entre les anciens et l’explication mathémagique sont une
+**proposition de mythologie Sanctuary**, pas un récit officiel de Mojang.
+
+## Corpus historique et périmètre
+
+Le dossier suit Java Edition, des premières versions de 2009 aux contenus
+documentés en 2026. Il couvre les mises à jour de contenu et les premières
+apparitions importantes dans les versions de développement. Les correctifs
+strictement techniques ne reçoivent pas chacun un épisode mythologique. Les
+différences de disponibilité des personnages entre Java, Launcher et Bedrock
+sont signalées dans leur dossier.
+
+| Dossier | Contenu |
+| --- | --- |
+| [Minecraft de 2009 à 2014](recherche-minecraft-2009-2014.md) | Premières phases, Alpha, Beta et versions 1.0 à 1.8 ; fondations du monde, des machines et des déplacements. |
+| [Minecraft de 2015 à 2026](recherche-minecraft-2015-2026.md) | Mises à jour de contenu modernes et snapshots déterminants ; statut des versions récentes. |
+| [Apparition des personnages](recherche-minecraft-personnages.md) | Steve, Alex et les sept nouveaux skins, dates et limites de ce que les sources établissent. |
+| [Chronologie Sanctuary et temps réel](chronologie-sanctuary.md) | Articulation avec Minecraft, repères de création et calendrier partagé. |
+| [Archives historiques Sanctuary](recherche-archives-sanctuary.md) | Recoupement des souvenirs de l’auteur avec les dépôts, annonces et anciens packs. |
+
+Le Minecraft Wiki actuel est communautaire. L’ancien statut officiel a pris fin
+en 2021 ; les annonces Mojang servent de sources primaires complémentaires.
+L’accès direct à certaines pages anglaises du wiki étant indisponible, les
+dossiers distinguent les éléments recoupés et les limites des extraits indexés.
+La recherche est arrêtée au 11 septembre 2026 ; une préversion observée ne vaut
+pas confirmation de sa sortie stable. [S1](#sources-de-cadrage)
+
+Les films, romans, Minecraft Dungeons, Legends et Story Mode ne définissent pas
+ici la biographie des neuf. Leurs continuités ne sont pas fusionnées avec celle
+du jeu Java. L’apparition d’une mécanique dans une mise à jour indique quand elle
+devient disponible dans le jeu ; elle ne prouve pas que Steve l’a inventée ni
+que ses habitants viennent de naître.
+
+## Ordre des anciens
+
+Le récit respecte trois arrivées documentaires : **Steve, puis Alex, puis Ari,
+Efe, Kai, Makena, Noor, Sunny et Zuri comme une même génération d’apparition**.
+La liste des sept n’est pas un ordre d’ancienneté. Leur annonce commune a lieu
+en 2022 ; aucune arrivée successive propre à chacun n’est établie par cette
+annonce. L’orthographe retenue pour Sanctuary est désormais **Efe**.
+[S2](#sources-de-cadrage) [S3](#sources-de-cadrage)
+
+Cela suggère un récit avec un premier témoin, une deuxième mémoire indépendante,
+puis un groupe capable de transformer les expériences en infrastructure.
+Steve n’a pas besoin d’être le premier être vivant ni l’auteur de tous les
+vestiges. Son importance vient de la durée de son expérience. Alex ne vient pas
+simplement l’assister : Alex apporte une autre manière d’habiter et de raconter
+le monde. Les sept nouveaux personnages ont ensuite leurs propres recherches,
+leurs installations et leurs désaccords.
+
+## Le fil mythologique proposé
+
+### 1. Le monde que Steve peut encore compter
+
+Les phases initiales donnent un vocabulaire limité de blocs et de constructions.
+Indev propose notamment des types de mondes insulaires et flottants, avant
+l’évolution vers Infdev. Ce précédent fournit à Sanctuary une parenté historique
+avec une forme ancienne de Minecraft. [S4](#sources-de-cadrage)
+
+Dans le récit, Steve commence par mesurer ce qui l’entoure. Un mur a une
+épaisseur, une réserve un nombre de cases, un trajet une distance parcourable.
+Steve construit pour dormir, ranger, cultiver, éclairer. Le premier savoir est
+de rendre un petit endroit habitable et de pouvoir le retrouver.
+
+La trace de cette époque serait modeste : une cabane agrandie plusieurs fois,
+des matériaux simples, un ancien niveau de sol encore visible sous une extension.
+Le cube originel pourrait être le repère à partir duquel Steve avait commencé
+à compter. Cela n’établit pas encore qui a créé ce cube.
+
+### 2. L’horizon cesse de donner une limite
+
+Infdev et l’évolution de la génération permettent de prendre comme tournant
+l’élargissement du monde. Dans la fiction, Steve découvre que marcher plus loin
+ne rapproche plus nécessairement d’un bord. L’abondance existe, mais elle se
+trouve ailleurs. Les besoins deviennent des problèmes de trajet, de retour et
+de transport.
+
+Le Nether offre ensuite un autre rapport aux distances. L’enchantement et les
+premières rencontres avec l’End ouvrent la possibilité que les lieux obéissent
+à des relations que la simple marche ne révèle pas. Ces apparitions restent
+dans leur ordre historique, détaillé dans le dossier ancien.
+
+Steve commence à conserver des signes. Certains se répètent autour d’objets
+ou de passages. La compréhension vient de plusieurs observations concordantes,
+pas d’un livre donnant immédiatement les règles de l’univers. Les glyphes des
+enchantements sont un point de départ visuel ; leur sens opératoire appartient
+à la fiction de Sanctuary.
+
+### 3. Une installation continue après le départ de sa main
+
+La redstone, les pistons, les systèmes de stockage et les hoppers marquent des
+étapes différentes de l’histoire réelle. Le récit peut faire grandir les
+constructions en respectant leur ordre, sans placer un dispositif tardif dans
+une ruine primitive dépourvue de réparations.
+
+Steve résout d’abord un travail répétitif. L’eau arrive au bon endroit ; une
+porte attend une condition ; les ressources se rassemblent. Le progrès lui
+donne du temps pour partir. Les premières infrastructures sont des solutions
+utiles à des besoins ordinaires, dont on peut encore comprendre le fonctionnement.
+
+Un ancien poste de pompage doit montrer ce qu’il alimentait. Un tunnel doit
+permettre de deviner ce qu’il rapprochait. Les premières traces de Galactium
+peuvent ainsi se cacher dans un dispositif utile, avant d’être identifiées comme
+une théorie générale.
+
+### 4. Alex conserve ce que Steve laisse fonctionner
+
+L’arrivée d’Alex appartient à la période 1.8, en 2014. Elle constitue un repère
+documentaire ; le rôle suivant est une proposition de personnage.
+[S3](#sources-de-cadrage)
+
+Alex compare les lieux. Une carte, une coupe de terrain et la mémoire d’un
+trajet montrent que deux descriptions du même endroit peuvent diverger.
+Alex conserve les anciennes versions des plans au lieu de les remplacer.
+Des pages corrigées et plusieurs entrées d’un même bâtiment permettent de
+comprendre sa transformation.
+
+Le désaccord fondateur pourrait être simple : Steve veut qu’une installation
+continue de servir ; Alex veut que quelqu’un puisse encore expliquer pourquoi
+elle existe et où elle mène. Ces deux ambitions sont utiles. Leur tension devient
+plus difficile à résoudre à mesure que les installations se multiplient.
+
+### 5. Ils apprennent à donner une adresse à autre chose qu’un chemin
+
+Les développements de l’End, des océans, des villages et des ressources donnent
+des années d’exploration et de construction au duo. Les développements ultérieurs
+des boussoles liées à la magnétite et des ancres de réapparition fournissent des
+motifs particulièrement adaptés à Galactium : un objet peut conserver une
+relation avec un lieu, et un retour peut demander une condition matérielle.
+[S5](#sources-de-cadrage) [S6](#sources-de-cadrage)
+
+Dans le récit, Steve et Alex n’inventent pas tous ces phénomènes. Ils comparent
+les choses que le monde permet déjà. Leur découverte consiste à reconnaître
+une grammaire commune derrière plusieurs pratiques.
+
+Un programme peut alors décrire une opération ; une construction en réunit les
+conditions. La formule devient opérante quand la matière, la forme et les accès
+s’accordent. C’est le début proposé de la mathémagie, plutôt qu’une permission
+arbitraire donnée à un personnage omnipotent.
+
+### 6. Les profondeurs possèdent déjà leur histoire
+
+Les nouvelles profondeurs, puis les cités anciennes, apportent un avertissement
+qui n’est pas nécessairement une menace. La présentation officielle du Deep Dark
+conserve elle-même une architecture et un passé énigmatiques. Elle ne permet pas
+d’attribuer toutes les cités aux neuf disparus. [S7](#sources-de-cadrage)
+
+Dans Sanctuary, les deux personnages peuvent découvrir des installations dont
+la logique leur ressemble, sans reconnaître leur époque ni leurs auteurs.
+Certaines solutions ont peut-être été trouvées plusieurs fois. Ce soupçon donne
+une profondeur au monde sans obliger à révéler sa première civilisation.
+
+Une boussole de récupération fournit aussi un motif réel : une information peut
+encore désigner une ancienne position après une mort. Le passage de cette idée à
+la recherche des espaces orphelins demeure notre invention. [S8](#sources-de-cadrage)
+
+### 7. Sept personnes rendent la découverte habitable
+
+À partir de leur apparition documentaire commune en 2022, les sept nouveaux
+personnages peuvent rejoindre le récit. Ils héritent des premières découvertes
+mais ne partagent pas tous la même idée de leur usage. L’archéologie, les moyens
+de conserver des livres et les développements de la fabrication automatique
+peuvent ensuite accompagner leurs travaux. [S9](#sources-de-cadrage)
+[S10](#sources-de-cadrage)
+
+Galactium devient une infrastructure parce que le groupe résout de vrais
+problèmes : nourrir, transporter, construire à plusieurs, produire, retrouver
+les objets et agrandir les espaces devenus trop petits. La ville peut naître
+de ces besoins. Ses cuisines, bassins, ateliers et corridors précèdent leurs
+versions abandonnées.
+
+Le succès produit la difficulté. Chaque dispositif rend un autre dispositif
+plus facile à construire. Les personnes qui comprennent toutes les dépendances
+deviennent moins nombreuses que les installations en service.
+
+### 8. Le monde conserve les résultats, même quand leur usage se perd
+
+Le lien proposé entre les systèmes est le suivant : un Indoor est un espace
+délimité dont on conserve la référence ; une Backroom garde une forme et de la
+matière lorsque leur contexte devient introuvable. Une expansion ajoute un
+territoire accessible. Les échanges et opérations peuvent laisser du ballast,
+dont les modalités économiques restent à concevoir.
+
+Les noyaux rendent des expansions possibles. Leur casse les fait disparaître
+et libère une charge commune ; le serveur répond en galactique. Le noyau, la
+charge et le ballast ont des rôles distincts. Aucun passage du récit ne fixe
+une conversion quantitative entre eux ni ne remet le noyau dans un inventaire.
+
+La grande question des anciens devient : comment cesser de faire fonctionner
+une installation sans retirer à quelqu’un son accès, son logement, son trajet
+ou son moyen de subsistance ? L’arrêt de chaque machine semble possible pris
+isolément. L’arrêt de l’ensemble ne possède plus de solution qu’ils sachent
+exécuter en préservant tous ces usages.
+
+### 9. La séparation
+
+**Proposition de dénouement à valider.** Les anciens entreprennent de réduire
+leur dépendance au système. Ils séparent les fonctions, déplacent des accès,
+isolent des volumes et cherchent à conserver une région habitable autour du
+repère initial. Des chantiers interrompus et des raccords provisoires témoignent
+de ce travail de maintenance.
+
+Les territoires demeurent, mais leurs relations ne forment plus un monde que
+les anciens savent parcourir entièrement. Certaines destinations deviennent
+inaccessibles depuis les points de départ connus. Les neuf disparaissent des
+lieux que les joueurs explorent ; leur mort, leur transformation ou leur
+destination ne sont pas établies.
+
+Sanctuary Island serait la région dont le repère commun tient encore. Les
+nouveaux joueurs y apparaissent dans la nature et retrouvent progressivement
+les installations. Une première expansion prouve qu’il est à nouveau possible
+d’établir une relation stable avec un autre territoire. Elle ne prouve pas que
+chaque nouveau continent existait déjà dans l’ancienne partie.
+
+Le canon donné conserve son sens : ils ont construit quelque chose qu’ils ne
+savaient plus refermer. Le récit ne désigne pas un coupable unique. Les traces
+montrent des problèmes réellement résolus, puis des tentatives de préserver
+les bénéfices de ces solutions.
+
+## Les neuf voix proposées
+
+Ces rôles sont des personnages de Sanctuary à discuter. Ils ne découlent ni de
+la couleur des skins, ni de leur nom, ni d’une biographie officielle. Les sept
+personnages apparus en 2022 ne sont pas rétroactivement les auteurs des inventions
+antérieures ; ils peuvent les apprendre, les adapter et les critiquer.
+
+**Précisions retenues le 11 septembre 2026 : Kai est le cuisinier fixe**, choisi
+par un tirage unique parmi les sept personnages ajoutés après Steve et Alex.
+Le livre de recettes lui est attribué. **Alex porte le domaine de la nature et
+des biomes ; Steve reste absent.** Les rôles d’**Ari pour le build**, de **Makena
+pour la redstone** et de **Zuri pour les étoiles et le temps** sont également
+retenus. Les questions personnelles et détails biographiques ci-dessous restent
+des propositions, distinctes de ces domaines désormais choisis.
+
+| Personnage | Question personnelle | Contribution et trace à retrouver |
+| --- | --- | --- |
+| **Steve** | Comment faire durer ce que l’on a construit ? | Premiers montages, réparations successives, programmes simples toujours exécutés. Sa force est la continuité ; son angle mort serait de prendre un fonctionnement durable pour une compréhension durable. |
+| **Alex** | Comment connaître et habiter les milieux de Sanctuary ? | Domaine nature et biomes retenu ; plantes, observations et connaissance des lieux donnent des pistes d’activités. Cela ne réintroduit pas une recherche automatique de biomes. |
+| **Ari** | Quelle forme suffit pour qu’un intérieur tienne ? | Volumes d’essai, portes à différentes échelles, plans d’Indoors. Ari recherche la précision sans réduire l’habitat à un volume abstrait. |
+| **Efe** | D’où vient la matière, et que devient-elle après usage ? | Relevés, stations de prospection, réserves et premiers indices de ballast. Efe cherche à rendre visibles les conséquences de la production. |
+| **Kai** | Comment transformer une récolte en un repas réussi ? | Cuisinier fixe, livre de recettes à reconstituer, préparation et cuisson, concours et jugement des plats. Les règles de qualité restent à définir ; l’ancienne piste de liaisons spatiales est retirée de ce rôle. |
+| **Makena** | Comment une installation peut-elle servir plusieurs personnes ? | Ateliers, circulation des ressources, interfaces d’usage et programmes de Régie. Makena transforme une expérience en équipement collectif. |
+| **Noor** | Que reste-t-il quand une adresse ne répond plus ? | Journaux d’opérations, signaux sans destination et balises de recherche. Noor distingue une trace d’une preuve, y compris lorsque les autres veulent conclure. |
+| **Sunny** | Qu’est-ce qu’un espace habitable pour autre chose qu’une machine ? | Jardins, serres et chemins vivants restent des pistes à distinguer du domaine d’Alex. Le rôle de cuisinier et son livre sont attribués à Kai. |
+| **Zuri** | Comment savoir que deux événements appartiennent à la même histoire ? | Observatoire, relevés du ciel et correspondances avec les événements collectifs. Zuri cherche des repères de temps quand les espaces cessent d’en fournir. |
+
+Leurs relations peuvent traverser leurs spécialités. Une archive de Noor peut
+contredire une carte d’Alex ; Sunny peut réutiliser une expérience d’Ari ; un
+montage de Steve peut être compris grâce aux mesures d’Efe. Aucun personnage
+ne devient le propriétaire exclusif d’un programme nécessaire aux joueurs.
+
+### Identités, apparences et transformations
+
+**Direction culturelle retenue : une mythologie implicitement queer.** Sanctuary
+accueille la possibilité de se transformer et de se définir sans que l’apparence
+détermine l’identité ou le rôle. La formule « on est tous trans » exprime ici
+une métaphore de la transformation commune ; elle n’assigne pas une identité
+trans à chaque personne. Cette lecture appartient à Sanctuary, sans prétendre
+définir le canon de Mojang ni les identités de personnes réelles.
+
+Dans cette conception, skins et modèles aux bras larges ou fins ne constituent
+pas des catégories de genre donnant des capacités, des métiers ou des destins
+différents. L’absence de genre mécanique ne signifie pas l’absence de genre
+vécu : chaque joueur reste libre de se définir. Une apparence ne suffit pas à
+déduire cette identité.
+
+**Pistes de mise en scène, encore proposées :** les visiteurs transmettent des
+pratiques choisies, sans métiers assignés selon le genre ; les changements
+d’apparence sont ordinaires et n’exigent pas de justification dans le récit.
+Des traces de plusieurs avatars pourraient appartenir à un même auteur de
+construction ou de programme. Ce serait une possibilité à explorer dans les
+ruines, pas une nouvelle identité confirmée des anciens ni une explication
+acquise de leur disparition.
+
+### Entrer dans la mythologie — accueil avant la première apparition
+
+**Déroulement demandé : fiche personnage, courte cinématique d’initialisation,
+puis arrivée naturelle.** La fiche présente d’abord le skin, le pseudo et une
+bio que le joueur peut écrire. La séquence en alphabet galactique apparaît
+ensuite, dans la cinématique, avec l’initialisation du personnage et une
+représentation graphique de recherche d’un emplacement sûr, comme un ordinateur
+qui démarre. L’ancien scénario avant le profil est retiré. Sanctuary comme
+archive qui semble se mettre à jour seule reste une piste narrative sous-jacente,
+dont l’accueil n’explique ni le fonctionnement ni l’origine.
+La lecture queer reste implicite, sans demander de se déclarer trans ni de
+partager cette lecture. La mise en scène précise reste en discussion.
+Le [cahier d’accueil et des profils](accueil-et-profils.md) détaille ce parcours
+et le système d’amitiés natif demandé ; aucun écran ni cinématique n’est livré.
+
+Le personnage entre dans une histoire commencée avant lui, avec la possibilité
+d’y laisser ses propres traces. Le lien aux anciens tient à cette qualité
+d’habitant et d’auteur de constructions, de programmes et de souvenirs. Il
+n’impose ni descendance, ni réincarnation d’un ancien, ni rôle d’élu au joueur.
+
+**Ordre retenu ; gestes et représentation encore à dessiner :**
+
+1. Montrer le skin actuel et le nom de jeu, puis proposer une bio et son
+   réglage de visibilité. Elle peut rester vide, parler de goûts Minecraft
+   ou présenter un personnage fictif ; aucune classe n’est imposée.
+2. Après la fiche, jouer une courte séquence d’initialisation avec l’alphabet
+   galactique et une recherche d’emplacement représentée graphiquement.
+   Les motifs, animations et liens aux données réelles restent à concevoir ;
+   aucun jeu de paramètres fictifs de sécurité n’est arrêté. Le serveur choisit
+   et vérifie l’emplacement réel d’arrivée.
+3. Donner la main au joueur dans un endroit naturel. Les vestiges, machines
+   et secrets se découvrent ensuite par l’exploration.
+
+La première apparition effective sur le serveur, après cette initialisation,
+publie une seule fois **« helloworld {pseudo} »**. Les connexions suivantes
+gardent **« {pseudo} joins the game »** ; le suivi repose sur l’UUID, avec le
+pseudo actuel à l’affichage.
+
+La proposition privilégie la première arrivée dans un monde. La bio peut être
+complétée plus tard ; durée de la cinématique, possibilité de la passer et
+traitement des connexions suivantes restent à préciser. Un changement de skin
+actualise l’apparence présentée et conserve
+la continuité de l’histoire du joueur. Il n’exige ni nouveau départ, ni annonce
+publique, ni justification narrative de cette transformation.
+
+La scène n’infère aucun genre depuis le skin, le modèle de bras ou le pseudo.
+Aucune déclaration de genre, de transidentité ou de passé personnel n’est requise
+pour entrer. La bio facultative laisse la place à l’identité vécue
+du joueur ; elle ne décrète pas que son genre n’existe pas. Des formulations
+comme « Bienvenue » et « Entrer » permettent de s’adresser à tout le monde.
+
+**Piste visuelle ultérieure :** représenter les joueurs avec le même soin que
+les anciens dans les portraits, cartes ou archives où leur présence a du sens.
+Ce parallèle peut se découvrir plus tard ; l’accueil ne dévoile pas d’emblée
+les neuf personnages ni leurs destins. Les archives d’apparences successives
+ne sont pas requises par cette proposition.
+
+L’alphabet galactique appartient à la mise en scène d’initialisation, après le
+profil. Il ne constitue ni une explication de Galactium ni une nouvelle prise
+de parole du système. Les conseils, diagnostics, fragments biographiques ou
+appels automatiques déjà écartés ne sont pas réintroduits. La bio est écrite
+par le joueur ; la cinématique ne la complète pas ni ne révèle sa version
+réservée aux amis.
+
+« Avant la connexion » désigne ici l’expérience **avant la première apparition
+jouable**. Le raccord à la connexion, aux données du monde et au chargement
+sera choisi dans le ticket d’interface ; aucune dimension d’attente ni nouvelle
+scène de spawn n’est introduite par ce document.
+
+**Décision retenue : la présence dans la mythologie, l’histoire et la progression
+du personnage sont liées à l’UUID du compte du joueur**, dans le monde concerné.
+Le pseudo et le skin servent à présenter ce personnage et peuvent évoluer.
+La proposition de fonder cette continuité sur le nom est remplacée par ce choix.
+
+Pour la future réalisation, le rattachement au compte authentifié utilise
+son **UUID**, tandis que l’accueil affiche le pseudo et le skin actuels.
+Changer de nom ou de skin ne doit pas créer un autre
+personnage, effacer sa progression ou réattribuer ses actes à quelqu’un qui
+reprendrait son ancien nom. L’écran n’affiche pas cet identifiant technique
+et n’exige pas de conserver publiquement la liste des anciens pseudos.
+Le contrat d’identité et son raccord au journal serveur restent à implémenter ;
+aucune migration de données n’est effectuée ici.
+
+### Présences de passage
+
+L’auteur souhaite que des personnages **visitent Sanctuary pendant une journée**,
+se promènent et proposent au clic droit un menu de discussion, des quêtes ou
+des échanges spécialisés. Kai peut organiser des concours de cuisine ; le
+personnage du build peut demander des constructions et incarner l’accès au
+catalogue galactique. Un marchand de décoration est une piste, sans identité
+fixée. L’invocation évoquée auparavant reste en réserve.
+
+La nature de ces présences reste à écrire ; leur visite n’explique pas encore
+la disparition des anciens ni leur état actuel. Steve demeure absent ; des
+**flashs d’Herobrine** sont souhaités, sans identifier Herobrine à Steve ou en
+faire automatiquement un boss. Les rendez-vous de visiteurs se rattachent au
+temps réel et ne remplacent pas les communications restreintes de Galactium.
+Voir les [visiteurs et leurs pratiques](progression-et-integrations.md#visiteurs-et-pratiques-des-anciens).
+
+## Mathémagie commune
+
+**Direction retenue : Galactium est le vide qui structure ce qui l’entoure.**
+L’auteur souhaite une approche de science-fiction, dans un esprit d’exploration
+et d’ingénierie évoquant Star Trek, avec une ampleur qui peut sembler divine.
+Cette cosmologie appartient à Sanctuary. Galactium désigne désormais aussi le
+fondement du système d’expansion qui porte déjà ce nom.
+
+Formulation proposée pour le récit :
+
+> La matière donne une forme aux choses. Le Galactium leur permet de tenir ensemble.
+
+Ce vide serait présent entre les îles comme dans les relations entre blocs,
+lieux et dimensions. Les anciens découvrent progressivement des effets
+reproductibles : maintenir un volume, conserver une adresse, relier deux lieux.
+Ils construisent des instruments, comparent leurs résultats et transmettent des
+programmes. Leur maîtrise pratique peut progresser plus vite que leur compréhension
+de ce qu’ils utilisent. Cette piste prolonge l’histoire des solutions devenues
+une infrastructure dont ils ne savent plus organiser l’arrêt.
+
+La comparaison avec Dieu exprime sa portée cosmologique. Sa conscience, sa
+volonté et l’existence d’une intention restent ouvertes. La réponse galactique
+du serveur lors de la casse d’un noyau pourrait être comprise comme un signal
+ou une présence : ces lectures sont des propositions. Les ruines
+peuvent conserver des mesures, des essais et des dispositifs de secours ; leurs
+auteurs ont appris à agir sur le monde avec une connaissance incomplète.
+
+Galactium peut ainsi se manifester comme une présence qui habite le serveur.
+Ses secrets retenus sont des coordonnées, des morceaux de programmes et des
+rendez-vous préécrits. Leur présentation passe par des [afficheurs diégétiques](langage-et-machines.md#afficheurs-diégétiques-textes-dynamiques-et-statistiques)
+qui peuvent afficher du texte dynamique et des statistiques. Les messages
+d’histoire, conseils, diagnostics et demandes mystérieuses proposés puis rejetés
+ne font pas partie de cette sélection.
+
+L’omniprésence de Galactium ne donne pas un usage illimité de ses effets. Les
+programmes en assembleur pilotent les opérations d’installations construites ;
+les charges collectives, ressources et conditions de réalisation gardent leurs
+rôles. L’origine des Endermen et la cause précise de la disparition des anciens
+ne sont pas résolues par cette définition.
+
+Une notation de conception peut guider l’écriture :
+
+**Lieu = matière + forme + adresse + relations maintenues.**
+
+C’est une règle de fiction, à transformer plus tard en contrats de jeu. Elle
+ne prétend pas être une loi physique ni une égalité de quantités de blocs.
+Les programmes permettent de mesurer, délimiter, transformer, relier et suivre
+des opérations. Les installations apportent les moyens matériels et les
+conditions d’exécution.
+
+Le cube possède six orientations, autour d’un point de référence. Les sept
+boules pourraient se rattacher à cette image d’un repère complet. Leurs épreuves
+déjà envisagées — fortune, cauchemar, Notch et cristal du nécromancien — gardent
+leurs intentions. Les fonctions restantes et la signification finale restent
+à définir ; neuf personnages ne doivent pas être artificiellement ramenés à
+sept postes fixes.
+
+Les Cavernes restent un monde de minage dont le donjon débloque les portails
+collectivement. Le Nether et l’End gardent leurs accès propres. Les fonctions
+thématiques proposées dans le [cahier des machines](langage-et-machines.md#programmes-à-thème-et-fonctions-des-lieux)
+peuvent enrichir cette histoire sans imposer une campagne à étapes obligatoires.
+Le monde Alpha peut conserver une expérience primitive, avec ses formes et ses
+textures ; sa relation à Notch demeure un choix de fiction Sanctuary distinct
+de l’histoire réelle de son développeur.
+
+## Rendre cette histoire visible dans les structures
+
+Une ruine doit pouvoir être comprise avant d’être lue. Elle possède une
+ressource d’entrée, une transformation ou une circulation, un résultat et des
+personnes auxquelles elle servait. Son abandon révèle des usages interrompus.
+
+| Trace | Lecture possible en jeu |
+| --- | --- |
+| Deux générations de matériaux et un ancien seuil conservé | Le bâtiment a été agrandi ; sa date de fondation et sa dernière intervention diffèrent. |
+| Une conduite encore raccordée à un bassin, avec une commande manquante | L’installation fournissait de l’eau ; le défaut est compréhensible et réparable. |
+| Un programme sur disquette, ses variantes et un montage d’essai | Les anciens comparaient des solutions ; le code devient un outil transmissible. |
+| Une salle d’expansion déséquipée, avec plans et raccords | La fonction peut être reconstruite ailleurs ; l’endroit conserve sa valeur de découverte. |
+| Un journal de transfert et une destination qui ne répond plus | La perte est un lien à examiner, pas la preuve immédiate d’une mort. |
+| Des palettes de Backrooms associées à différentes activités anciennes | L’histoire économique laisse des couches que les joueurs peuvent interpréter. |
+
+La sélection actuelle reste un départ naturel, l’observatoire, la salle
+d’expansion, un atelier caché, la traversée souterraine et le donjon majeur.
+Les Lost Cities sont principalement destinées aux continents d’expansion ;
+les autres bâtiments restent en réserve sur l’île initiale. Les salles secrètes
+y transmettent des solutions utilisables et reproductibles par leurs montages,
+avec terminaux, contrôleurs, afficheurs, disquettes et blocs vanilla. La grande
+salle ancienne reste essentielle, sans dépendre d’une ville au-dessus. Écrire ce
+passé et ces usages ne les active pas automatiquement dans la génération actuelle.
+
+## Décisions à valider et limites
+
+Le respect de l’ordre des mises à jour, l’orthographe Efe et la distinction entre
+faits et fiction sont établis pour ce dossier. Le récit de la séparation,
+les relations personnelles, la fonction précise du cube et les sept épreuves
+restent des propositions. La cause finale de la disparition des neuf doit être
+choisie consciemment, avec ce que les joueurs peuvent réellement en découvrir.
+
+Le calendrier souhaité suit le temps réel et prend Minecraft comme chronologie
+principale. Les repères Sanctuary donnés de mémoire — 16 mars, 24 mai, 17 août
+et 8 septembre 2026 — font l’objet d’un audit avant d’être figés. Leur sens
+fictionnel, l’âge biologique des personnages et la date de leur disparition
+restent à choisir. Une snapshot peut inspirer un prototype abandonné ; une fonctionnalité
+retirée ne devient pas pour autant un pouvoir disponible dans le mod.
+
+Ce dossier n’implémente aucune dimension, machine, quête ou altération de monde.
+Les espaces orphelins demeurent une fiction correctement sauvegardée ; la
+recherche des objets perdus doit conserver leur unicité. La mythologie prépare
+les futurs tickets jouables et leurs critères de vérification.
+
+## Sources de cadrage
+
+Les dossiers historiques contiennent les références détaillées par mise à jour.
+Les sources suivantes soutiennent les rapprochements factuels employés ici ;
+elles ne valident pas les biographies et la cosmologie proposées.
+
+- **S1. Minecraft Wiki**, [Community portal — Microsoft status update](https://minecraft.wiki/w/Minecraft_Wiki:Community_portal/Microsoft_status_update), avis sur la fin du statut officiel, 2021.
+- **S2. Mojang, Sofia Dankis**, [Introducing New Default Minecraft Skins](https://www.minecraft.net/en-us/article/introducing-new-default-skins), 20 octobre 2022 ; [Minecraft Live 2022: The Recap](https://www.minecraft.net/en-us/article/minecraft-live-2022-the-recap), annonce commune.
+- **S3. Minecraft Wiki**, [Alex](https://minecraft.wiki/w/Alex), historique Java 1.8-pre1 ; voir les dates et leurs recoupements dans le dossier personnages.
+- **S4. Minecraft Wiki**, [Seed (world generation)](https://minecraft.wiki/w/Seed_%28world_generation%29), historique Indev des types flottants ; [World type, édition japonaise](https://ja.minecraft.wiki/w/ワールドタイプ), évolution des types de mondes.
+- **S5. Mojang, Duncan Geere**, [Block of the Week: Lodestone](https://www.minecraft.net/nb-no/article/block-week--lodestone), 20 août 2020.
+- **S6. Mojang, Adrian Östergård**, [Minecraft Snapshot 20w12a](https://www.minecraft.net/da-dk/article/minecraft-snapshot-20w12a), 18 mars 2020, ancre de réapparition.
+- **S7. Mojang**, [Around the Block: Deep Dark](https://www.minecraft.net/en-us/article/around-block--deep-dark), présentation du biome et commentaire de conception de Mariana Salimena.
+- **S8. Mojang, Duncan Geere**, [Taking Inventory: Recovery Compass](https://www.minecraft.net/de-de/article/taking-inventory--recovery-compass), 19 janvier 2023.
+- **S9. Mojang, Sofia Dankis**, [The Trails & Tales Update is Here](https://www.minecraft.net/en-us/article/trails-tales-update-here), 7 juin 2023.
+- **S10. Mojang, Duncan Geere**, [Crafting with the Crafter](https://www.minecraft.net/fr-ca/article/crafting-crafter), 6 juin 2024.

docs/journal-et-progression-du-monde.md

@@ -0,0 +1,105 @@
+# Sanctuary — journal des transformations et progression du monde
+
+**Conception en discussion, WG-26.** L’auteur demande un suivi profond des
+joueurs, des entrées, des sorties et des transformations dans le temps. Ce
+document prépare un futur journal ; il ne crée aucune collecte, génération,
+récompense ou migration de sauvegarde.
+
+## Intention
+
+Le serveur doit pouvoir relier les découvertes et la production à leurs effets :
+matériaux obtenus, procédés utilisés, programmes exécutés, objets échangés ou
+perdus et étapes accomplies. Cette histoire nourrit les propositions de plans,
+les Backrooms, les Indoors et les futurs donjons. L’objectif ressemble à un
+suivi expérimental : savoir ce qui est entré dans une opération, ce qui en est
+sorti et comment elle s’inscrit dans une suite d’actions.
+
+## Ce qui existe et ce qui manque
+
+Lecture du dépôt de développement le **11 septembre 2026** : le Blocodex possède
+une mémoire personnelle des blocs ; les recensements de stocks sont partiels.
+L’historique d’activité conserve cinq compteurs journaliers UTC pour l’ensemble
+du serveur : blocs minés et posés, objets ramassés, jetés et fabriqués. Il ne
+reconstitue pas les consommations ni les transformations des machines.
+
+Références de cette lecture, dans le dépôt voisin `sanctuary-beta` :
+`docs/blocodex.md`, `docs/cosmologie.md` et
+`mods/sanctuary/src/main/java/fr/koka/sanctuary/knowledge/history/MaterialActivityHistory.java`.
+Ces compteurs ne donnent pas l’auteur de chaque opération, les entrées d’une
+recette, les destinations ou les pertes. Ils ne constituent pas le journal
+transactionnel nécessaire aux récompenses ou aux restitutions. Les événements
+antérieurs ou non observés restent inconnus ; ils ne sont pas reconstruits
+artificiellement à partir d’un total.
+
+## Décrire des opérations réellement terminées
+
+Le format reste à définir. Les informations proposées sont : identifiant stable
+d’opération, date UTC et ordre serveur, joueur ou machine à l’origine de l’action,
+type d’opération, lieu et références utiles, entrées et sorties effectives, recette
+ou programme concerné et version pertinente. Une opération automatique ne doit
+pas être attribuée au joueur le plus proche : opérateur, propriétaire et
+bénéficiaire peuvent être différents.
+
+| Fait | Sens à préserver |
+| --- | --- |
+| Observation | Preuve personnelle qu’un bloc a été aperçu ; ne suffit pas au déclencheur de plan fondé sur des blocs obtenus. |
+| Obtention | Possession attestée pouvant proposer un plan associé ; ne signifie pas qu’un stock suffisant est encore disponible. |
+| Production | Produits réellement créés par une récolte, une extraction ou un procédé ; un compteur de blocs minés ne donne pas toujours les drops obtenus. |
+| Transformation | Entrées consommées, sorties, restes et coproduits d’une même opération, avec sa recette ou son procédé. |
+| Transfert | Déplacement entre inventaires, machine, sol ou joueur ; déplacer puis ramasser une stack ne la produit pas une seconde fois. |
+| Consommation | Usage final, par exemple manger un aliment ; distinguer ce cas de son emploi comme ingrédient. |
+| Perte confirmée | Destruction, combustion ou disparition dans le vide selon les règles à instrumenter. Mort, déconnexion et chunk déchargé ne prouvent pas une destruction. |
+| Récompense ou restitution | Attribution distincte, référencée une seule fois. Une récupération en Backrooms doit se rattacher à la perte concernée sans laisser également l’original récupérable. |
+
+Exemple proposé pour une future chaîne d’It’s Alive ! : récolte de blé, passage
+au moulin pour obtenir de la farine, préparation et cuisson du pain, puis repas.
+Les quantités, ingrédients supplémentaires, combustible et restes proviennent
+des recettes effectivement exécutées. Chaque transfert au coffre reste un
+transfert ; il ne gonfle pas la production. Cet exemple n’atteste pas une
+recette actuellement livrée.
+
+Une variation de stock seule n’explique pas sa cause. L’instrumentation doit
+observer les opérations à leur aboutissement et signaler les zones non couvertes.
+Pour les programmes, le suivi vise leurs actions sur les appareils et la matière ;
+le journal d’économie n’a pas besoin de recopier chaque instruction CPU exécutée.
+
+## Ce que l’histoire pourra produire
+
+| Usage futur | Données et résultat à concevoir |
+| --- | --- |
+| Bibliothèque de plans | Associer les blocs obtenus et familles de matériaux à des architectures pertinentes. Distinguer proposition, déblocage et matériaux nécessaires à la construction. |
+| Backrooms | Réutiliser des traces de l’activité pour composer des espaces et des distributions ; relier séparément les objets réellement perdus à leur éventuelle récupération. |
+| Indoors procéduraux | Composer des espaces contrôlés et intéressants à partir de thèmes ou usages observés. Propriété, accès et génération gardent leur contrat propre. |
+| Donjons et raids | Proposer des épreuves correspondant aux étapes atteintes, avec de nouvelles combinaisons de salles, ennemis, objectifs et coordination. La progression ne se résume pas à augmenter les points de vie. |
+
+Le ballast conserve son rôle cosmologique de trace des opérations ; une unité
+comptée ne devient pas automatiquement une unité de ballast ni un objet disponible
+dans une Backroom. Les conversions, règles de composition et ressources restent
+à définir. Les fonctions reproductibles des machines et l’autonomie d’It’s Alive !
+sont conservées.
+
+Chaque nouvelle génération doit pouvoir être reliée à une période d’observation,
+sa couverture, la règle de sélection, la graine et la version du générateur.
+Ces paramètres sont fixés pour la génération concernée : l’évolution du serveur
+ne réécrit pas une installation déjà visitée et ne change pas une épreuve en cours.
+Un raid peut être conçu pour un effectif donné puis conserver cette difficulté
+pendant sa tentative. Les nouvelles versions de recettes ne réinterprètent pas
+les anciennes transformations comme si leurs rendements avaient toujours été identiques.
+
+## Continuité et coût du suivi
+
+L’ambition de couverture doit être rendue mesurable : quelles opérations sont
+instrumentées, depuis quand et avec quelles interruptions. Prévoir collecte
+événementielle, budgets d’écriture, files bornées et regroupements exploitables
+sans scanner le monde ni charger des chunks pour tenter de reconstruire le passé.
+La durée de conservation des événements détaillés et celle des agrégats restent
+à choisir ; un agrégat ne prétend pas conserver une causalité qu’il a perdue.
+
+Le journal qui décide d’un achat, d’un quota de raid ou d’une restitution doit
+définir sa reprise après incident. Un même événement ne doit pas attribuer deux
+récompenses après reconnexion. Les agrégats actuels ne suffisent pas à garantir
+ce comportement. Aucun format existant n’est modifié par cette conception ;
+une implémentation demandera son propre contrat de sauvegarde et de migration.
+
+Les applications et règles de raid sont précisées dans le
+[cahier de progression](progression-et-integrations.md#raids-collectifs-instanciés).

docs/langage-et-machines.md

@@ -0,0 +1,788 @@
+# Sanctuary — écriture galactique et machines programmables
+
+**Conception en discussion, WG-26.** Ce cahier distingue la direction demandée
+des rôles proposés. Aucun langage, bloc ou changement de progression n’est
+implémenté par ce document.
+
+## Direction retenue
+
+Exploiter l’alphabet galactique de Minecraft comme écriture d’un langage secret
+dans Sanctuary. Ce langage doit relier la redstone programmable, les expansions,
+les waystones et l’End. **Le socle informatique retient trois blocs :
+contrôleur, terminal et afficheur, avec les disquettes comme objets. Le bloc Assembleur
+est retiré de la conception.** L’assemblage du code est une fonction du terminal.
+
+**Précisions retenues : programmation directement en assembleur, six faces
+d’entrée/sortie et une véritable RAM adressable pour les contrôleurs.** L’auteur
+n’a pas de préférence arrêtée sur le terme « sérialisable ». La base de travail
+proposée est de sauvegarder l’état complet du contrôleur ; une communication
+en série plus riche reste une extension à étudier selon les besoins des montages.
+Une première proposition détaillée définit maintenant le langage et
+l’architecture ; elle reste à valider et à implémenter.
+
+La [lecture du Redstone Computer historique](redstone-computer-reference.md)
+retrouve déjà un assembleur, de la RAM, six faces, des bus, du tri d’items et un
+réseau. Son CPU repart cependant au début à chaque tick. Le cahier de référence
+distingue les capacités à reprendre d’une future machine réellement continue,
+ainsi que les limites matérielles d’un objet très puissant utilisable en survie.
+
+L’[audit redstone 26.3](audit-redstone-26.3.md) inventorie les capteurs,
+comparateurs, actionneurs, transports et automatismes vanilla. Il situe ce
+que les ordinateurs rendent plus compact et ce que les appareils Sanctuary
+ajoutent réellement. Il sépare signal électrique, transfert physique d’objets
+et échange de données avec un périphérique, notamment pour le particuleur.
+
+Le [dossier Redstone Language V0.1](redstone-language-extensions.md) complète
+ce cadrage avec les [instructions](redstone-language-instructions.md), les
+[fiches des appareils](redstone-language-composants.md) et les
+[composants de signal et de transport](redstone-language-signaux-et-transport.md).
+**Le socle minimal n’est pas un plafond : un manque peut révéler un nouveau
+bloc à créer.** Le condensateur et ses interactions sont désormais retenus.
+Le convoyeur se pose comme un rail, à vitesse unique, avec arrêt sans redstone ;
+la commande d’inversion reste à choisir. Lecteur de stock, aiguilleur, convertisseur, capteurs et
+connexion adressée restent proposés. Transistor, atténuateur et impulseur
+sont écartés ; une [exploration par objets et cristaux](redstone-language-objets-et-cristaux.md)
+cherche d’autres gestes de machine. Les valeurs V0.1 restent un profil d’essai,
+pas du code livré.
+
+Le [cahier des machines multiblocs](machines-multiblocs.md) explore les appareils
+que ces programmes pourront coordonner : grand four (nom proposé : Fourneau),
+Fût, grand baril de fermentation, Trémie, Carillon, méga-pistons et autres
+constructions. Les collections visibles et le Métablit y sont aussi étudiés.
+Chaque appareil conserve ses gestes locaux, son contenu et ses
+recettes ; la programmation n’est pas nécessaire à son premier usage manuel.
+
+Nous étendons le lore à partir de motifs de Minecraft. Le lien opératoire entre
+ces glyphes, les destinations et les machines est une création Sanctuary.
+L’origine du langage, son rapport exact à l’End et ce que les neuf disparus ont
+découvert restent à écrire.
+
+Le cadrage cosmologique retient **Galactium comme le vide structurant qui permet
+aux choses d’avoir une place et des relations**. Ce nom englobe le phénomène et
+le système d’expansion développé pour en utiliser certains effets. L’approche
+privilégie observation, expérimentation et ingénierie ; conscience ou volonté
+éventuelles restent ouvertes. Voir la [mathémagie proposée](histoire-steve-galactium.md#mathémagie-commune).
+Les programmes restent de l’assembleur exécuté par les contrôleurs : ils calculent
+et pilotent les opérations des installations. Une opération spatiale exige
+toujours ses conditions matérielles et collectives ; cette cosmologie n’ajoute
+ni instruction universelle ni ressource infinie utilisable par un joueur.
+
+Le jeu de référence 26.3-pre-2 emploie la police `minecraft:alt` pour les mots
+tirés au hasard par `EnchantmentNames`, affichés dans `EnchantmentScreen`.
+Cette lecture du code vanilla fournit une référence visuelle ; la grammaire
+exécutable et ses effets sont à concevoir pour Sanctuary.
+
+## Proposition : une écriture, des instructions et des usages
+
+L’écriture donne les signes visibles sur les inscriptions et les appareils.
+La grammaire définit les opérations que les joueurs peuvent composer. Les
+installations donnent à ces opérations des effets dans le monde.
+
+Un premier vocabulaire pourrait permettre de **lire, comparer, mémoriser,
+écrire une sortie, attendre et répéter**. Des usages spatiaux pourraient ensuite
+introduire des notions de **référence, liaison, destination et stabilité**.
+Leurs noms, glyphes, syntaxe et conditions d’apprentissage ne sont pas arrêtés.
+
+La lecture des ruines peut apprendre à reconnaître un programme par ce qu’il
+faisait : pomper, temporiser une porte, aiguiller une voie, maintenir une liaison.
+Des variantes annotées et des montages encore utilisables peuvent permettre
+d’expérimenter. Le partage des programmes entre joueurs est retenu ; ses
+modalités de copie et de vente restent à définir.
+
+**Le mode de programmation retenu est l’assembleur direct.** Registres, adresses,
+instructions et étiquettes doivent permettre d’écrire un vrai programme. Une
+transcription saisissable au clavier et un affichage en glyphes peuvent présenter
+le même code ; les mnémotechniques exacts restent à choisir. L’édition visuelle
+n’est pas le mode retenu. Une aide à la lecture et au diagnostic est proposée ;
+sa disponibilité et une éventuelle traduction progressive restent à décider.
+Le Blocodex ne devient pas automatiquement un lexique de ce langage.
+
+## Proposition de lien avec les Endermen
+
+La téléportation des Endermen fournit un point d’appui observable dans Minecraft
+([présentation officielle](https://www.minecraft.net/en-us/article/minecraft-mobs)).
+Dans le lore proposé pour Sanctuary, certaines séquences galactiques pourraient
+décrire les opérations de l’espace que les Endermen accomplissent.
+
+Le joueur pourrait découvrir une même séquence dans des traces de téléportation,
+sur une ancienne waystone et dans un programme d’atelier. Une répétition permet
+d’associer les signes à un effet, puis une annotation laissée par les anciens
+joueurs aide à comprendre son usage. Les noms galactiques des Endermen déjà
+évoqués dans la vision peuvent prolonger cette présence de l’écriture.
+
+Piste narrative : les anciens joueurs ont appris à reproduire dans leurs
+machines certaines opérations observées chez les Endermen. Cette hypothèse
+reste à valider ; elle ne fixe ni l’inventeur du langage, ni l’identité des
+Endermen, ni la cause de la disparition des neuf personnages. Le déchiffrement
+des lettres et l’apprentissage des opérations sont deux étapes de compréhension.
+
+Les premières instructions redstone pourraient s’apprendre avec un montage
+simple. Les notions de destination, liaison et stabilité se découvriraient par
+les installations spatiales. Les conditions de ces découvertes et les traces
+visuelles de téléportation sont des propositions, pas de nouveaux effets livrés.
+
+## Ensemble minimal retenu
+
+| Élément | Fonction | Précision proposée dans V0.1 |
+| --- | --- | --- |
+| Contrôleur — bloc | Exécuter le programme avec processeur, registres, RAM intégrée et six faces d’entrée/sortie. Fonctionner après retrait du terminal. | Profil d’essai : quatre registres 8 bits, RAM 1 Kio, 64 instructions/tick ; état complet conservé. |
+| Terminal — bloc | Écrire, vérifier et assembler le code, lire/écrire les disquettes ; observer registres, RAM, ports et instruction exécutée, démarrer, arrêter et essayer pas à pas. | Connexion DEVICE adjacente ; document de travail dans le contrôleur. Pas-à-pas à préciser avant code. |
+| Afficheur — bloc | Présenter dans le monde les textes, mesures et résultats des programmes sur une surface rectangulaire extensible. | Huit lignes/bloc retenues ; plafond 8 × 4 panneaux et 16 colonnes/bloc proposés. |
+| Disquette — objet | Conserver, transporter et partager un programme ; le charger dans un contrôleur. | Source 16 Kio et 512 instructions proposées ; pas de copie de RAM, retrait possible après chargement. |
+
+Le terminal sert à programmer et diagnostiquer ; il n’a pas besoin de rester
+attaché à chaque contrôleur pour que celui-ci fonctionne. Processeur et RAM
+sont intégrés au contrôleur. Aucun bloc supplémentaire d’assemblage, lecteur de
+disquette ou module RAM n’est nécessaire au premier ensemble.
+L’afficheur rend le fonctionnement visible ; ce socle de trois blocs ne signifie
+pas que chaque circuit redstone doive obligatoirement les utiliser tous.
+
+Pour l’expansion, l’auteur retient un **noyau dont la casse provoque la disparition
+sans objet récupérable et libère une charge collective pour le serveur**. Les
+météorites sont une voie de découverte demandée, avec d’autres voies à définir.
+Le noyau n’est plus une pièce transportable à installer ou recharger dans la
+machine. L’installation utilise les charges communes et les ressources apportées.
+**Galactium nomme l’ensemble du système d’expansion**, pour lequel une interface
+est demandée ; son accès par le terminal est proposé ci-dessous. Dépôt et ancrage
+restent à concevoir sans imposer un nouveau bloc au premier automate redstone.
+Un premier bus local adressé est désormais proposé dans le dossier V0.1 ;
+réseaux entre contrôleurs, catalogues publics et appareils de construction
+restent en réserve. Le terminal de stockage en titane reste une fonction distincte.
+
+Pour le premier langage, proposer le nécessaire à un automate : lire et écrire
+les ports, charger et stocker la RAM, calculer, comparer, faire un saut, attendre
+et arrêter. Les mnémotechniques et détails sont proposés dans le
+[jeu d’instructions](redstone-language-instructions.md). Un compteur
+d’impulsions commandant une porte, conservé après rechargement, suffirait à
+vérifier l’utilité du premier ensemble avec les blocs redstone ordinaires.
+
+## Particuleur et commande des effets
+
+Le particuleur est un **appareil complémentaire**, utilisable sans ordinateur.
+Un objet inséré au clic droit choisit le type de particules ; le signal règle
+le débit, avec 0 pour l’arrêt et une émission croissante de 1 à 15. L’insertion
+par dropper est demandée, le hopper accolé est proposé. Le contrôleur peut
+piloter l’intensité et l’alimentation ; un transfert direct d’échantillon exige
+une fonction d’inventaire définie. Le [contrat du particuleur](audit-redstone-26.3.md#particuleur--contrat-clair-et-montages)
+précise décisions, propositions et limites de l’ancien code. Son portage,
+la table des effets et la consommation éventuelle restent à réaliser ou décider.
+
+## Disquettes de langage redstone
+
+**Support proposé par l’auteur : des disquettes de programmes redstone.** Les
+disques musicaux fournissent le parallèle d’un contenu porté par un objet ; la
+disquette donne une forme physique au code que l’on conserve et transmet.
+
+Parcours proposé : fabriquer une disquette vierge, écrire le code au terminal,
+le vérifier et l’assembler dans ce même terminal, l’enregistrer sur la disquette,
+puis charger le programme dans un contrôleur. Le terminal pourrait relire et
+modifier le code. Conserver la source avec le programme assemblé permettrait
+d’étudier ce que l’on a trouvé ou reçu.
+
+Une première version pourrait contenir un programme par disquette, avec un nom
+et une étiquette. La copie demanderait un support vierge ; ses modalités et son
+coût restent à définir. **Les programmes sont obtenables, partageables,
+duplicables et revendables**, notamment pour les montages de farming. Les
+disquettes peuvent en porter des copies, rangées dans des coffres ou exposées
+dans des cadres. Leur capacité et leur recette ne sont
+pas fixées.
+
+Les ruines pourraient conserver des disquettes nommées d’après leur ancienne
+fonction : pompage, aiguillage, porte de maintenance ou protocole spatial.
+Leur code consultable et les effets du montage permettent d’étudier l’installation.
+La direction actuelle des salles exclut les panneaux explicatifs ; les éventuelles
+annotations du code ne constituent pas un cours obligatoire ni un guide affiché
+dans la pièce. Ces contenus précis restent des propositions de butin.
+
+La proposition V0.1 transporte le programme sans RAM ni état d’exécution et
+conserve le programme dans le contrôleur après retrait de la disquette. Les
+gestes, limites et copies sont détaillés dans la
+[fiche disquette](redstone-language-composants.md#disquette--transporter-un-programme).
+Les déblocages et droits d’une installation demeurent ceux du serveur, même
+quand son programme est copié. Aucun support n’est implémenté ici.
+
+## Architecture du contrôleur à définir
+
+La vision conserve la piste d’un ordinateur 8 bits. Dans la proposition, les
+valeurs internes peuvent aller de 0 à 255 ; les intensités redstone des faces
+restent de 0 à 15. Le passage entre les deux doit être explicite et compréhensible.
+
+Le contrôleur aurait un compteur d’instruction, des registres, des indicateurs
+de comparaison et une RAM dont le programme peut lire et modifier les cases.
+Le profil V0.1 propose 1 Kio de RAM, des adresses sur 16 bits, quatre registres
+A/B/C/D et un programme séparé de la RAM. Ces choix ne sont pas encore validés
+par un prototype. Un processeur 8 bits n’impose pas une RAM de 256 octets.
+
+Les six faces sont les ports physiques. V0.1 propose OFF, IN, OUT ou DEVICE
+par face, avec les directions du monde comme adresses. Une communication série
+entre contrôleurs demanderait un protocole : signaux, rythme, transfert d’un
+octet et comportement en cas d’interruption.
+
+**Base de travail proposée : conserver l’état complet.** Programme, RAM,
+registres, compteur d’instruction et état d’attente seraient enregistrés pour
+retrouver la machine après un rechargement. Les six faces assureraient d’abord
+les échanges redstone ordinaires ; le protocole série supplémentaire reste en
+réserve. Il faudra distinguer sauvegarder un bloc en place, le déplacer,
+copier son programme et cloner sa mémoire. La capacité de RAM et le comportement
+lors d’une coupure d’alimentation éventuelle restent à définir.
+
+## Premier usage redstone à dessiner
+
+Exemple avec la **syntaxe proposée V0.1**, non implémentée :
+
+```text
+loop:
+  IN   A, NORTH
+  ST   0x10, A
+  LD   B, 0x10
+  OUT  SOUTH, B
+  WAIT 1
+  JMP  loop
+```
+
+Ce petit exercice lit le signal nord, l’enregistre à une adresse de RAM, le
+relit et le reproduit au sud. Il illustre registres, mémoire, ports et boucle.
+Un programme suivant pourrait comparer un seuil, compter des impulsions ou
+temporiser une porte. Le nord doit être configuré IN et le sud OUT ; `WAIT 1`
+reprend au prochain tick chargé. Les règles complètes sont dans la proposition
+d’instructions, sans exécution réelle de ce programme dans le présent chantier.
+
+La future exécution devra avoir un budget borné par tick et un comportement
+défini à l’arrêt, à l’erreur, au déchargement et au redémarrage. Les programmes
+agissent par les fonctions autorisées des appareils. Les opérations d’expansion
+restent soumises aux ressources, destinations et validations du serveur.
+
+## Liaisons avec la progression et les lieux
+
+**Décision déjà acquise :** l’étape du donjon de Sanctuary Island débloque les
+portails vers les Cavernes de façon collective et permanente. Tous les joueurs,
+y compris les nouveaux arrivants, peuvent ensuite fabriquer leur portail.
+Copier une inscription ne remplace pas cette étape ; sa validation initiale
+et l’usage de l’objet de quête restent à définir.
+
+Les waystones, expansions et accès à l’End peuvent partager une écriture et des
+notions tout en conservant leurs propres appareils et règles. Aucune nouvelle
+condition d’accès à l’End ni obligation de programmer chaque waystone n’est
+fixée ici. Les joueurs doivent pouvoir profiter des installations communes ;
+la programmation comme spécialité volontaire est une proposition à discuter.
+
+**Direction retenue : apprendre par des installations concrètes dans les salles
+secrètes de l’île.** Terminaux, contrôleurs, afficheurs et disquettes se combinent
+à des coffres, hoppers et comparateurs. Le joueur découvre un système en action,
+peut en suivre les raccords et comprendre comment le reproduire chez lui.
+L’effet spectaculaire doit venir de ce que fait la construction. De grandes
+salles peuvent présenter plusieurs systèmes de farming avec ordinateurs,
+**sans panneaux explicatifs**. Les joueurs suivent les stocks, les transferts,
+les signaux et les programmes pour comprendre. Les afficheurs montrent les
+sorties utiles à l’installation, sans devenir un tutoriel. Les dialogues des
+futurs visiteurs ne remplacent pas ce mode de découverte.
+
+Le programme lui-même devient un bien échangeable : une copie peut être utilisée,
+modifiée ou revendue, sans transmettre les ressources ni les droits de l’installation.
+Sa vente devra respecter le contrat de transaction du serveur comme les autres
+biens. L’ordinateur est un système central de Sanctuary, pas seulement le bouton
+d’ouverture des continents.
+
+Exemple proposé pour l’atelier : un coffre alimente une chaîne de hoppers ; un
+comparateur transmet le remplissage, le contrôleur commande un arrêt au seuil
+et l’afficheur en montre l’état. Le signal du comparateur ne fournit pas un
+inventaire exact. Une disquette pourrait transmettre le programme du montage.
+La grande salle d’expansion, évoquée aussi comme « salle de transformation »,
+étend cette découverte à l’ouverture des continents. Son nom détaillé, son
+équipement initial et ce qui doit être rééquipé restent à définir. Le donjon
+garde le rôle de stabiliser l’accès collectif aux Cavernes. Ces exemples ne
+livrent encore aucun appareil ni objet au butin.
+
+Les connaissances, recensements et activités du Blocodex peuvent alimenter des
+usages à définir. Une palette connue, un stock observé et une matière engagée
+dans une opération restent des informations distinctes. Les relevés ne donnent
+pas automatiquement un droit de prélèvement ou d’accès aux stocks d’autrui.
+
+La nouvelle direction relie aussi les palettes du Blocodex aux advancements
+Minecraft et Sanctuary pour ouvrir des achats au **Black Market, le shop du
+serveur**. Cette éligibilité commerciale est une intégration future, distincte
+de la mémoire personnelle des blocs actuellement livrée. Elle ne garantit ni
+le stock ni le paiement, et ne débloque pas implicitement une recette. Les
+conditions personnelles ou collectives restent à définir dans la
+[conception des informations et de l’économie](vision.md#informations-à-découvrir).
+Les cartes au trésor visent des coffres réels sur des îles déjà générées ; elles
+ne consomment pas de charge ni n’ouvrent à elles seules de nouveau territoire.
+
+La cosmologie des Indoors contrôlés et des Backrooms orphelines peut prolonger
+ces expériences. Le ballast et la traduction des opérations en espaces restent
+à concevoir ; une erreur de programmation ne provoque pas automatiquement une
+Backroom ni une altération de sauvegarde.
+
+### Programmes à thème et fonctions des lieux
+
+**Proposition en discussion**, à la demande d’articuler Galactium avec Indoors,
+Backrooms, Cavernes, Lost City, Nether et End. Chaque famille transmettrait une
+opération caractéristique, réutilisable dans les constructions des joueurs.
+Les noms ci-dessous sont des noms de travail lisibles, pas des instructions
+d’assembleur définies ni des traductions galactiques officielles.
+
+| Lieu ou espace associé | Programme proposé | Fonction distinctive et installation |
+| --- | --- | --- |
+| Lost City et ateliers anciens | **Régie — coordonner** | Piloter une séquence entre plusieurs circuits : pompage, portes, éclairage ou manutention. Un poste de contrôle et des raccords permettent de comprendre les dépendances d’une ancienne infrastructure. |
+| Cavernes | **Sonde — mesurer** | Relever les couches et rechercher des indices de gisement dans un périmètre mesuré par une station de prospection construite. Le joueur choisit où sonder puis interprète le relevé ; portée, résolution et coût restent à concevoir. |
+| Indoors | **Volume — délimiter** | Définir un intérieur borné, conserver sa référence et l’associer à un accès. Le programme équipe une installation qui crée ou gère cet espace ; il ne copie pas automatiquement son contenu. |
+| Backrooms | **Trace — retrouver** | Lire une référence orpheline et poser des repères de retour depuis une station ou des balises. Le programme aide l’exploration ; la restauration d’un espace ou le rapatriement de son contenu ne sont pas des effets acquis. |
+| Nether | **Conversion — transformer** | Conduire une transformation matérielle précise : ressources d’entrée, étapes de traitement et produit de sortie dans une installation thermique. La recette donnerait sa fonction particulière au montage ; aucun alliage, nouveau carburant ou rendement n’est encore choisi. |
+| End | **Liaison — adresser** | Identifier deux extrémités et établir une relation entre elles. Une première application pourrait transmettre un signal entre deux ancres construites ; un passage ou un transfert demanderait ensuite son propre appareil et ses règles. |
+
+Lost City reste une famille de vestiges, pas une nouvelle dimension. Les villes
+sont principalement destinées aux expansions ; Sanctuary Island conserve ses
+lieux secrets et ses passages souterrains. Un atelier isolé pourrait déjà
+contenir un exemple de Régie. Les Cavernes restent destinées au minage, sans
+ajouter de mineshaft ni de parking à leur génération : la station de prospection
+serait construite par les joueurs. Son relevé local se distingue du Blocodex,
+qui conserve des connaissances et des recensements avec une couverture donnée ;
+ce nouveau capteur n’est pas implémenté par les mesures existantes.
+
+Le lien Volume/Trace reprend la cosmologie définie : un Indoor possède une
+référence et un usage contrôlés ; une Backroom conserve des espaces et de la
+matière dont le contexte a disparu. Trace pourrait en éclairer des indices sans
+expliquer automatiquement leur origine. Le ballast reste une trace à concevoir
+des opérations économiques ; il n’est pas assimilé aux charges d’expansion.
+Les objets d’accès des Indoors liés à la mailbox, l’entrée des Backrooms par le
+lit et la récupération des objets perdus gardent leurs contrats à définir.
+Les pool rooms physiques de l’île ne deviennent pas des Backrooms par cette
+seule association.
+
+Les disquettes portent de vrais programmes modifiables qui combinent des
+opérations offertes par les installations. Copier un programme transmet le
+savoir-faire ; l’appareil, les ressources et les déblocages du serveur déterminent
+ses effets possibles. Les exemples peuvent être utilisés puis étudiés sans
+imposer à chaque joueur d’écrire tous les programmes. Les lieux de découverte
+et les conditions d’apprentissage restent à choisir ; les six familles ne
+forment pas une campagne obligatoire dans un ordre fixé.
+
+Exemple de combinaison ultérieure : Sonde fournit un relevé pour préparer une
+expédition ; Conversion prépare une ressource définie par la recette du montage ;
+Régie coordonne son alimentation et sa demande d’expansion. Après ouverture, une
+installation de Liaison pourrait relier des équipements des deux territoires.
+Cette combinaison serait une possibilité avancée, pas un prérequis aux premières
+expansions. Les autres fonctions gardent des usages autonomes.
+
+Le donjon de Sanctuary débloque toujours les portails des Cavernes collectivement
+et définitivement ; Sonde n’est pas nécessaire pour gagner cet accès. Aucun
+nouveau verrou sur les portails du Nether ou de l’End n’est adopté. Une charge
+de noyau sert pour l’instant à une expansion : coût d’un Indoor, d’une liaison ou
+d’une exploration des Backrooms à décider séparément. La reprise, les pertes et
+la récupération d’objets exigeraient leurs propres règles avant implémentation.
+
+## Programmer les fonctions du jeu et construire une expansion
+
+**Proposition en réponse à la demande de programmer le jeu lui-même.** Le
+programme doit pouvoir composer des comportements ayant des effets réels :
+enchaîner des actions, conserver des états, réagir aux entrées et piloter les
+fonctions offertes par son installation. La redstone forme le premier usage ;
+les capacités spatiales pourraient être une extension du même ordinateur.
+
+Techniquement, cela demande de relier la machine virtuelle à des opérations du
+moteur Sanctuary. L’assembleur reste le langage de calcul. Les périphériques
+offrent les actions possibles et des résultats consultables : disponibilité,
+état, demande acceptée ou refusée, progression, fin. Le programme peut choisir
+et composer ces opérations au lieu de simplement déclencher un menu prédéfini.
+
+Deux niveaux sont à distinguer dans la conception : piloter le générateur de
+continents existant avec des paramètres calculés par le programme, puis, dans
+un éventuel chantier ultérieur, permettre de programmer des règles de forme ou
+de composition du terrain. Le second niveau demanderait son propre contrat de
+génération déterministe et bornée ; il n’est pas fourni par l’API actuelle.
+
+### Une construction qui donne une capacité au contrôleur
+
+Proposer une **installation multibloc** composée de blocs ordinaires autour du
+contrôleur. Sa forme serait reconnue par Sanctuary et lui donnerait accès aux
+opérations d’expansion, en utilisant une charge de la réserve collective.
+Le contrôleur exécute, le terminal permet de programmer et l’afficheur présente
+les résultats ; cette installation spatiale ajoute une capacité particulière
+à ce socle. Sa reconnaissance et ses effets
+constituent une mécanique proposée, non un comportement vanilla.
+
+| Partie de l’installation — proposition | Rôle concret à donner à sa construction |
+| --- | --- |
+| Socle et cadre orienté | Définir le point de référence et les directions desservies. |
+| Éléments conducteurs ou de stabilisation | Définir une capacité de l’installation, éventuellement la taille maximale d’expansion ; matériaux, forme et relation à la capacité à choisir. |
+| Coffres et acheminement par hoppers | Apporter les ressources effectivement engagées dans l’opération ; quantités et consommation à définir. |
+| Contrôleur, terminal et disquette | Calculer la demande, exécuter la procédure et consulter son état. |
+| Leviers, lampes et sorties redstone | Commander le démarrage et rendre visibles attente, manque de ressources et achèvement. |
+
+Le dépôt pourrait utiliser les coffres de la construction ; son orientation et
+son ancrage restent à définir. Aucun noyau intact n’est nécessaire dans le montage.
+Un premier appareil compact pourrait être agrandi ou relié à d’autres équipements
+selon des règles à concevoir.
+L’habillage architectural resterait libre autour des pièces fonctionnelles :
+la salle ancienne sert de modèle rééquipable, et la machine est reproductible
+ailleurs. Le plan exact, les matériaux et les dimensions restent des décisions
+ouvertes ; aucune grande forme rituelle obligatoire n’est validée ici.
+
+### Bloc graine et météorites
+
+**Direction retenue : casser le noyau le fait disparaître sans bloc ni fragment
+à ramasser. Une charge d’expansion devient disponible pour tout le serveur.**
+Le serveur émet un message en écriture galactique ; texte, traduction, son et
+répétition de cette réaction restent à choisir. La phrase poétique proposée au
+départ est abandonnée. Aucun sens canonique n’est attribué au message.
+
+Cette direction remplace les propositions de noyau récupérable, de pièce à
+enfermer dans une installation et de recharge du même objet. La charge persiste
+indépendamment du découvreur et de toute machine, même après déconnexion ou
+redémarrage. Elle ne devient pas un objet à ranger ou à échanger. L’intention
+est de rendre son usage collectif ; les moyens d’accès aux noyaux encore intacts
+et le choix de qui peut engager une charge restent à définir.
+
+« Bloc graine » reste une description de travail. Le nom du bloc reste ouvert ;
+KOR n’est qu’une proposition. **Galactium est le nom retenu par l’auteur pour
+tout le système d’expansion**, qui comprend la réserve de charges, les programmes,
+les installations et leurs opérations. Ce nom ne désigne pas une monnaie ou une
+quantité dans un inventaire. Les noms inventés pour Sanctuary ne sont pas des
+traductions officielles de Minecraft.
+
+| Voie de découverte | Statut et intérêt proposé |
+| --- | --- |
+| Noyau de météorite | Piste demandée. Trouver un bloc étrange dans une enveloppe rocheuse ; anciens impacts et chutes observables sont deux formes possibles à choisir. |
+| Installation ancienne | Proposition. Découvrir un noyau dormant sur place et le briser pour libérer sa charge ; la construction explique son ancien usage. |
+| Reconstitution sur place | Piste ultérieure non validée. Les éventuels ingrédients doivent avoir leur propre provenance, puisque la casse d’un noyau ne donne aucun fragment. |
+
+Le rapprochement avec le cube originel reste une hypothèse de lore. Rareté,
+disponibilité renouvelable, fréquence et effets des météorites restent ouverts.
+La charge ne remplace pas l’objet de quête débloquant collectivement les portails
+de minage ; elle n’accorde pas automatiquement une recette de noyau. Aucun bloc,
+message galactique ou événement météorique n’est implémenté ici.
+
+### Afficheurs diégétiques, textes dynamiques et statistiques
+
+**Direction retenue : afficher les textes sur des afficheurs diégétiques, intégrés
+au monde.** Ils peuvent transmettre les communications de Galactium et présenter
+des statistiques actualisées. Le support retenu est un **panneau afficheur
+extensible** : plusieurs panneaux posés côte à côte forment un grand écran.
+La recette et l’apparence précise restent à choisir.
+
+#### Panneaux extensibles et surface rectangulaire
+
+**Un bloc afficheur offre huit lignes de texte.** Les panneaux se raccordent
+dans un même plan, avec la même orientation, par leurs côtés. La surface commune
+est un **carré ou un rectangle plein** : chaque emplacement de son emprise doit
+être occupé. Une diagonale seule, un angle de mur, une forme en L ou en T et un
+rectangle troué ne constituent pas un écran unique.
+
+Le raccord visuel de type **CTM** conserve les coins et la bordure extérieure,
+en effaçant les bordures internes. Le texte traverse les raccords comme sur une
+seule surface ; chaque bloc n’affiche pas une copie indépendante du contenu.
+CTM décrit ici le résultat visuel souhaité ; le choix technique du rendu reste
+à faire lors de l’implémentation.
+
+Pour un écran de largeur W et de hauteur H, mesurées en blocs, la capacité est
+de **8 × H lignes**, chacune utilisant la largeur W. Ajouter en largeur allonge
+les lignes ; ajouter en hauteur augmente leur nombre. La taille des caractères
+reste constante. Le nombre de caractères par bloc en largeur reste à calibrer
+avec les polices lisible et galactique.
+
+| Largeur × hauteur | Lignes | Largeur de chaque ligne |
+| --- | ---: | --- |
+| 1 × 1 | 8 | 1 bloc |
+| 2 × 1 | 8 | 2 blocs |
+| 2 × 2 | 16 | 2 blocs |
+| 3 × 2 | 16 | 3 blocs |
+| 4 × 3 | 24 | 4 blocs |
+
+**Proposition pour construire bloc par bloc :** un panneau isolé forme un écran
+1 × 1. Un panneau ajouté contre un écran devient une extension de cet écran ;
+il reste en attente tant que l’ensemble ne forme pas un rectangle plein.
+L’écran existant conserve sa surface active et son contenu. Dès que le rectangle
+est complété, l’affichage s’étend. Ainsi, pour passer de 2 × 1 à 2 × 2, le premier
+panneau de la deuxième rangée attend le second ; la forme en L intermédiaire
+n’est jamais utilisée comme surface commune d’affichage.
+
+La taille maximale, le débordement du texte, l’édition, les connexions au
+contrôleur, la casse d’un panneau et la rencontre de deux écrans déjà configurés
+restent à préciser. Agrandir ou reconfigurer l’écran doit préserver son contenu ;
+une fusion ne doit pas écraser silencieusement le programme ou les données
+d’un autre écran. Les rendez-vous, statistiques et textes utilisent la même
+surface d’affichage.
+
+#### Connexions aux fonctions de Minecraft — proposition
+
+**Direction retenue : l’afficheur programmable est un écran à usage général.**
+Le programme du contrôleur décide de ce qu’il affiche et de son évolution à
+partir des données et entrées disponibles. Les joueurs peuvent écrire, modifier,
+enregistrer sur disquette et partager leurs propres applications. La liste des
+usages est ouverte.
+
+**Premiers usages retenus par l’auteur : chronomètre, calendrier, jauge de
+coffre et progression.** Ils deviennent des programmes de départ utilisables et
+modifiables. Leurs sources et raccordements restent à construire. Les autres
+exemples ci-dessous illustrent des applications possibles de ce même écran.
+
+| Usage retenu | Première application proposée | Point restant à préciser |
+| --- | --- | --- |
+| Chronomètre | Deux entrées de départ et d’arrivée, durée de la session affichée. | Source de temps, arrêt/reprise et attribution éventuelle d’un record. |
+| Calendrier | Heure et date du serveur, âge de la partie et rendez-vous préécrits. | Convention de calendrier, fuseau et mise en page. |
+| Jauge de coffre | Comparateur raccordé à une jauge de remplissage. | Configuration et rendu des seize niveaux du signal. |
+| Progression | Avancement d’un objectif mesurable, par exemple ressources réunies pour un projet collectif. | Définition de l’objectif, source du relevé et valeur à atteindre. |
+
+Deux usages complémentaires sont proposés, avant de choisir le premier ticket :
+un panneau autonome pour des contenus simples, et une sortie du contrôleur pour
+les mises en page programmées.
+
+**Panneau autonome.** Il conserve un texte préparé et peut lire une entrée
+redstone. Le signal peut piloter un nombre, une jauge ou un choix parmi des
+textes configurés par le joueur. L’édition, le côté d’entrée et les conflits
+avec une connexion au contrôleur restent à définir. Une première application
+serait un coffre, son comparateur et une jauge sur l’afficheur.
+
+Le comparateur vanilla donne une intensité de remplissage entre 0 et 15. Cette
+mesure ne suffit pas à compter exactement les objets ni à identifier leur type.
+La jauge doit conserver cette précision limitée. Une quantité exacte demanderait
+une lecture d’inventaire distincte, encore à concevoir.
+[Référence Mojang sur le comparateur](https://www.minecraft.net/nb-no/article/taking-inventory--redstone-comparator).
+
+**Écran du contrôleur.** Proposition minimale : relier directement une face du
+contrôleur à l’arrière d’un panneau appartenant à l’écran. Ce raccord adresse
+toute la surface rectangulaire. Le terminal sert à écrire et charger le programme,
+le contrôleur conserve les calculs et la RAM, l’afficheur présente le résultat.
+Des opérations d’écriture de texte à une ligne/colonne, de nombres, d’effacement
+et de changement de page seraient à définir dans le langage. Aucun nom
+d’instruction n’est fixé ici.
+
+La capacité actuellement définie est une grille de texte adressable de huit
+lignes par bloc en hauteur, sur toute la largeur du rectangle. Le programme
+compose librement ses libellés, nombres et glyphes, puis modifie leur position
+ou leur contenu. Couleurs, graphismes, interaction directe avec la surface et
+caractéristiques typographiques supplémentaires restent à concevoir.
+
+Un même matériel peut ainsi accueillir un compteur, un tableau économique,
+une interface de boutique, un puzzle ou un petit jeu utilisant cette grille.
+Le contrôleur exécute les calculs avec sa RAM ; le terminal édite le programme ;
+l’afficheur présente le résultat. Les entrées redstone permettent déjà de
+concevoir des interactions par boutons et leviers, sans décider d’un écran tactile.
+
+Le programme compose les données et opérations que Minecraft et Sanctuary lui
+exposent par les raccordements définis. Lire un stock, acheter un lot ou demander
+une expansion exige toujours la source ou le service correspondant. Le texte
+affiché ne remplace pas l’état autoritaire du serveur. Ces contrats donnent aux
+programmes des capacités combinables, dont les applications ne sont pas limitées
+à celles prévues par les auteurs du mod.
+
+Cette liaison de données est distincte de l’intensité redstone : les caractères
+et tableaux ne sont pas transmis implicitement par une simple poudre alimentée.
+Le même contrôleur pourrait utiliser ses autres faces pour des entrées et
+sorties ordinaires. Les câbles de données, écrans distants et connexions de
+plusieurs écrans restent des extensions à étudier.
+
+| Construction proposée | Entrées et usage de l’écran |
+| --- | --- |
+| Réserve ou silo | Comparateur vers jauge de remplissage ; mesure analogique limitée aux niveaux disponibles. |
+| Voie de fret | Détection redstone d’un passage vers indication d’occupation ou comptage des impulsions ; la destination affichée est configurée. |
+| Stand de tir | Signal du bloc cible vers jauge de précision ; le contrôleur peut mémoriser les scores d’une session. |
+| Parcours chronométré | Deux entrées pour départ et arrivée ; le contrôleur mesure une session et conserve un record. Temps réel ou ticks doivent être explicitement choisis. |
+| Salle d’énigmes construite par les joueurs | Boutons et leviers vers programme, symboles et résultat d’une combinaison ; les textes sont préparés par le constructeur. |
+| Affichage de livre | Piste de lecture d’un livre fourni au montage, pour afficher une page ou un texte sur le grand écran ; raccordement et accès au livre restent à concevoir. |
+| Place ou atelier collectif | Données du calendrier, statistiques ou progression d’un projet vers tableau local ; chaque donnée demande sa source serveur définie. |
+
+La cible vanilla produit une intensité liée à la proximité du centre de l’impact.
+Sa valeur peut fournir l’entrée du stand de tir proposé.
+[Référence Mojang sur la cible](https://www.minecraft.net/tr-tr/article/block-week--target).
+
+Un signal ne fournit pas automatiquement l’identité d’un participant : les
+compteurs et chronomètres peuvent d’abord décrire une session ou une installation.
+L’attribution personnelle d’un record demanderait une règle et une source
+d’identification supplémentaires. Les capteurs d’inventaire, lectures de livres,
+statistiques et données Sanctuary sont des connexions futures à spécifier ;
+l’afficheur ne découvre pas automatiquement toutes les données du monde.
+
+Les textes composés par les joueurs pour leurs installations sont distincts de
+la sélection des communications de Galactium décrite ci-dessous. Ces usages
+et modes de connexion sont des propositions, sans nouvelle fonction implémentée.
+
+La conception s’étend aussi à des [boutiques construites avec des blocs
+vanilla](vision.md#boutiques-construites-avec-des-blocs-vanilla). Un afficheur y
+présenterait une offre, son prix et les lots réellement disponibles. Ces valeurs
+demandent un contrat de commerce dédié ; la jauge analogique de coffre ne suffit
+pas à établir une offre ou à encaisser un achat.
+
+#### Combinaisons émergentes
+
+**Direction retenue : permettre aux joueurs de composer de nouveaux usages
+avec les mêmes blocs et programmes.** Une mesure de remplissage, un temps,
+un objectif ou une opération de commerce doit pouvoir être utilisé par le
+programme pour afficher, comparer, mémoriser puis commander une action.
+Les quatre applications de départ fournissent des exemples à réutiliser.
+
+Le contrôleur garde l’état nécessaire à ces enchaînements : une session en
+cours, un seuil atteint, une demande déjà traitée. Le partage d’une disquette
+permet de reprendre un programme et d’adapter ses paramètres à une autre
+construction. Les protocoles et capacités concrètes restent à définir.
+
+| Combinaison proposée | Construction obtenue |
+| --- | --- |
+| Jauge de coffre + deux seuils + sortie redstone | **Réserve régulée** : demander le réapprovisionnement au seuil bas et arrêter au seuil haut. Deux seuils distincts évitent les bascules continuelles autour d’une seule valeur. |
+| Progression + dépôt collectif + afficheur | **Chantier commun** : montrer les apports validés et ce qui manque pour l’objectif choisi, puis indiquer qu’il est atteint. L’affichage ne construit pas automatiquement le bâtiment. |
+| Calendrier + chronomètre + entrées de départ/arrivée | **Parcours à sessions** : horaires préparés, compte à rebours, durée de la session et réouverture suivante. Les records personnels demanderaient toujours une identification supplémentaire. |
+| Chronomètre + compteur en mémoire + boutons | **Atelier partagé** : distribuer des numéros de passage, afficher le tour courant et la durée d’usage, puis libérer la place. Le numéro désigne un tour, sans attribuer automatiquement une identité au joueur. |
+| Boutique + stock enregistré + calendrier | **Marché à horaires** : une offre financée par le stock du vendeur devient accessible aux horaires préparés. Un changement d’heure ne crée aucune marchandise. |
+| Boutique + objectif de ressources + budget du propriétaire | **Comptoir d’approvisionnement** : proposition de commande d’achat rémunérant les apports acceptés jusqu’à l’objectif ou l’épuisement du budget. Ce sens d’échange demande une extension du contrat de commerce. |
+| Mesure locale + minuterie + sorties redstone | **Poste de fret** : programmer un départ quand le chargement atteint un seuil ou qu’une durée s’est écoulée. L’occupation de la voie doit provenir d’une entrée définie. |
+
+Parcours d’expérimentation proposé : construire une jauge, lui ajouter une
+commande à seuil, puis afficher l’objectif de réapprovisionnement. Le joueur
+peut ensuite employer ce montage pour son atelier ou pour alimenter un magasin.
+La fonction vient de la composition du programme, des raccordements et de
+la construction.
+
+Ces exemples ne sont pas de nouveaux modes imposés à l’afficheur. Les données
+riches de dépôt, de commerce et de calendrier exigent leurs sources serveur ;
+un signal analogique ne suffit pas à déterminer les apports exacts d’un joueur.
+Les transactions conservent leurs vérifications et une opération déjà traitée
+ne doit pas être répétée au simple rechargement du programme. Les horaires de
+rendez-vous restent préparés ; cette composition ne réintroduit aucune catégorie
+de message Galactium rejetée.
+
+Pour une première démonstration, réserve régulée, chantier commun et parcours
+à sessions sont des candidats proposés, à choisir une fois leurs sources et
+connexions définies. Aucun de ces montages n’est livré par ce cahier.
+
+#### Contenus des afficheurs
+
+La sélection des secrets de Galactium se limite à :
+
+- Coordonnées et indices de localisation.
+- Morceaux de programmes galactiques.
+- Rendez-vous liés au calendrier ou au ciel, **écrits à l’avance**.
+
+Les rendez-vous ont un texte, un horaire et des conditions de déclenchement
+préparés. L’affichage peut actualiser des champs issus du jeu : emplacement,
+date, heure ou temps restant, selon le message. Leur schéma exact reste à définir.
+Le caractère dynamique concerne ces données et leur présentation ; le rendez-vous
+et son texte sont conçus en amont.
+
+**Les statistiques sont également demandées.** Exemples d’usages proposés : âge
+de la partie, quantité de ressources d’un stock consultable, avancement d’un
+projet ou nombre d’expansions ouvertes. Chaque affichage doit désigner la mesure
+et son périmètre réel. Le serveur fournit les valeurs ; les relevés partiels du
+Blocodex ne deviennent pas un total de toute l’île. Le choix des statistiques,
+leurs sources et la liaison éventuelle avec les programmes restent à concevoir.
+
+La sélection exclut les astuces, fragments d’histoire des anciens, diagnostics
+de machines, appels de lieux inaccessibles, réactions aux constructions et
+demandes mystérieuses précédemment proposés comme messages de Galactium. Les
+exemples de phrases rejetés sont abandonnés. Le terminal conserve ses fonctions
+d’édition et de diagnostic technique décrites ailleurs dans ce cahier.
+
+L’emplacement des afficheurs, leurs conditions d’accès et de lecture, la fréquence
+d’actualisation et la présentation galactique restent à définir. Ce cadrage
+documentaire n’ajoute encore aucun affichage ou événement au jeu.
+
+### Réserve collective et interface Galactium
+
+**Demande retenue : une interface pour Galactium, l’ensemble du système
+d’expansion.** Elle doit relier programmation, installation, préparation et
+usage des charges collectives. L’accès proposé est une vue du terminal existant,
+relié à une installation. Il n’ajoute pas de bloc ni de menu personnel obligatoire.
+
+La base de travail est **un noyau brisé → une charge commune → une expansion**.
+Les ressources apportées à la machine restent un coût distinct, croissant selon
+la taille du projet ; recettes et quantités sont à équilibrer. Le noyau ne se
+recharge pas. Briser un noyau alimente la réserve sans lancer de génération.
+
+| Zone proposée du terminal | Informations et actions |
+| --- | --- |
+| Réserve du serveur | Charges disponibles et charges engagées dans les opérations en cours, partagées par toutes les installations. |
+| Projet de l’installation | Île de départ, direction, climat, relief, taille et emplacement candidat ; un schéma de recherche, pas une carte exacte promise avant génération. |
+| Préparation | État du montage, programme chargé, ressources présentes et manquantes, conditions restantes pour démarrer. |
+| Opération | Lancement quand les conditions sont satisfaites, état de préparation, progression et résultat ; l’opération peut être retrouvée après réouverture. |
+
+Le terminal présenterait une **vue d’utilisation** de l’installation et garderait
+son **éditeur assembleur**. Le programme fournit la demande et pilote la machine ;
+la vue affiche cette même demande et son suivi. Une action à l’écran doit passer
+par le même contrat que le programme. L’interface ne remplace pas la construction,
+les ressources ou le contrôleur par un simple bouton de création de continent.
+
+Ouvrir le terminal, consulter un projet ou enregistrer une disquette ne réserve
+aucune charge. La charge est engagée une seule fois lorsque le serveur accepte
+effectivement le lancement avec les ressources. Une demande refusée ne la dépense
+pas. Deux installations sollicitant la dernière charge ne peuvent pas toutes
+deux l’obtenir. Une opération acceptée conserve son identité et son engagement
+après déconnexion, fermeture ou casse du terminal ; la reprise ne paie pas à
+nouveau. Le traitement d’un échec après acceptation devra être défini avec le
+contrat de sauvegarde et de reprise, sans remboursement ni nouvelle génération
+automatiques supposés.
+
+Les inscriptions et la réaction du serveur gardent l’écriture galactique.
+Compteurs, actions et conditions de fonctionnement doivent rester compréhensibles,
+avec libellés FR/EN ; la place de la transcription et du déchiffrement reste à
+dessiner. Des témoins redstone visibles sur la machine sont proposés en complément
+de l’écran. La visibilité de la réserve depuis les autres lieux et les règles
+collectives de dépense sont ouvertes : aucun vote ou droit exclusif du propriétaire
+du terminal n’est décidé ici.
+
+### Parcours proposé dans le monde
+
+1. Libérer une charge en brisant un noyau, ou utiliser une charge déjà disponible
+   pour le serveur. Retrouver un programme et les raccords de l’installation
+   ancienne, ou utiliser un programme partagé ; construire les éléments nécessaires.
+2. Préparer au terminal une demande : parent, direction, climat, relief et taille
+   dans les capacités et déblocages disponibles.
+3. Chercher un emplacement et afficher un projet ainsi que son coût. Un schéma
+   de recherche ne doit pas être présenté comme une carte exacte déjà générée.
+4. Apporter les matériaux et donner le départ. Le serveur valide ensemble la
+   construction, l’accès, la destination et l’engagement d’une charge commune
+   avec les ressources. Consulter un projet ne dépense rien.
+5. Le contrôleur conserve l’identifiant de l’opération et suit sa préparation.
+   Les lampes et le terminal rendent le travail lisible ; un programme repris
+   suit la même opération.
+6. Une fois le continent prêt, sa cartographie et son relevé réel de ressources
+   pourraient devenir des résultats consultables. Leur production reste à réaliser.
+
+Ces échanges pourraient passer par des registres de périphérique, décrits en
+assembleur et affichés en galactique. Un descripteur ou des valeurs sur plusieurs
+octets devront représenter les coordonnées, tailles et quantités qui dépassent
+255 ; un signal redstone ordinaire reste compris entre 0 et 15.
+
+### Ce que le moteur fournit déjà et ce qui manque
+
+Lecture du code d’expansion de l’alpha.23 locale : `ExpansionRuntime.Session`
+expose recherche de candidat, sondage, création, progression et reprise. Les
+diamètres admis vont de 64 à 1 024 selon les profils disponibles. Une création
+réserve durablement son emprise avant la préparation progressive des chunks.
+Ces fonctions sont actuellement utilisées par des commandes opérateur.
+
+Le candidat proposé n’effectue pas à lui seul toute l’admission. Celle-ci peut
+attendre jusqu’à 30 secondes dans le chemin actuel ; elle devra être adaptée
+avant tout appel depuis un programme. La préparation des chunks est déjà suivie
+par une file. La réutilisation de certains vides certifiés demande actuellement
+un rechargement du monde. Ce parcours technique ne constitue pas encore une
+machine utilisable en survie.
+
+Le raccord futur devra introduire une demande asynchrone avec identité persistante,
+plutôt qu’appeler la création à chaque tour de boucle. Il reste à définir le
+contrat entre charge collective, ressources engagées, réservation du terrain,
+interruption et reprise. La réserve collective et l’interface Galactium n’existent
+pas encore dans ce moteur. Les règles de sauvegarde et les constructions
+existantes sont conservées ;
+une opération enregistrée n’est pas annulée par simple retrait de la disquette.
+
+Le Blocodex peut fournir des connaissances et des observations ; les stocks
+réservés dans l’installation relèvent du contrat de consommation à construire.
+Le relevé de la nouvelle région intervient après génération, avec sa couverture.
+Le programme ne relance pas des graines pour garantir un quota de minerai.
+L’éventuelle trace de ballast appartient au futur contrat économique.
+
+Le déblocage collectif des portails de minage reste une décision distincte.
+Ce multibloc ne fixe pas les conditions de la première expansion, ni la forme
+des waystones ou des portails vers les autres dimensions.
+
+## Prochaines décisions
+
+1. Apprentissage des glyphes et des instructions ; lien exact avec les Endermen.
+2. Connexion du terminal au contrôleur et chargement du programme depuis la disquette.
+3. Taille de RAM, premier montage, rythme d’exécution et règles de reprise.
+4. Capacité, recette, copie, lecture et chargement des disquettes ; contenus découverts dans les ruines.
+5. Construction d’expansion : pièces fonctionnelles, forme, capacité, ressources et opérations programmables ; confirmer ou ajuster la proposition multibloc.
+6. Galactium : nom du noyau et voies de découverte, message galactique et forme des météorites ; disponibilité des charges et règles de dépense collective.
+7. Interface : accès depuis le terminal, disposition, lisibilité FR/EN et lien avec l’éditeur assembleur ; valider la proposition avant implémentation.
+
+Le [cahier des lieux](structures-conception.md) conserve les décisions générales
+et le [document de vision](vision.md) le périmètre du projet.

docs/machines-multiblocs.md

@@ -0,0 +1,674 @@
+# Sanctuary — machines que l’on construit
+
+**Exploration WG-26 ; aucun nouveau bloc, recette ou format de sauvegarde livré.**
+Le principe précisé par l’auteur est **l’assemblage de blocs identiques en une
+version agrandie de leur fonction** : 27 fours en cube plein deviennent un
+grand appareil de cuisson ; 27 barils deviennent un **Fût**. La précédente
+proposition de four creux entouré de briques est remplacée. **Fourneau** est
+le nom proposé ici pour les 27 fours, encore à valider avec l’auteur.
+
+Le **grand baril de fermentation** est le nom retenu pour traiter plusieurs
+stacks d’une même recette. Le kitchen oven d'It's Alive ! est regroupé dans le
+Fourneau, dont les recettes et la chaleur restent à concevoir. **Métablit** est
+le nom proposé par l’auteur ; sa fonction d’établi collectif reste en discussion.
+
+Les collections deviennent visibles sur des présentoirs : **9 objets par face
+de bloc, 81 par façade 3 × 3 et 324 objets distincts sur quatre façades**. Les
+méga-pistons sont eux aussi retenus en conception : **9 pistons en façade 3 × 3,
+course de 3 blocs**, avec variante collante. Les autres assemblages décrits plus
+bas distinguent désormais la **Trémie retenue : 9 hoppers à plat et 45 cases**,
+et le **Carillon retenu pour ses accords et courtes séquences, formé par un
+assemblage adjacent choisi**. Les appareils supplémentaires restent proposés ; aucun n’est livré.
+
+La **clé à molette dorée** est retenue pour **orienter, assembler volontairement
+et désassembler**. Les blocs restent indépendants à la pose ; le joueur choisit
+de les réunir avec la clé. L’auteur confirme ce choix pour les hoppers :
+un montage de neuf hoppers doit pouvoir conserver ses neuf circuits au lieu
+de devenir une Trémie. Ses gestes et sa fabrication sont à concevoir.
+
+Le coffre 3 × 3 × 3 évoqué sert ici de référence au principe de construction.
+Aucun coffre de ce type n’a été identifié dans le code courant ni les documents
+consultés. Le stockage en titane reliant 128 coffres est une autre fonction ;
+ce cahier ne présente donc pas ce coffre comme déjà implémenté.
+
+## Clé à molette dorée — assembler, désassembler et orienter
+
+**Retenu par l’auteur :** un objet spécial, la **clé à molette dorée**, permet
+d’assembler volontairement des blocs compatibles, de dissocier un multibloc,
+d’intervenir sur les pistons et de tourner des blocs comme les escaliers et
+les barils. Nom anglais proposé :
+**Golden Wrench**. Recette, obtention, durabilité et vitesse de récupération
+restent à définir ; la couleur dorée ne fixe pas un coût ni un enchantement.
+
+### Retrouver les blocs indépendants
+
+Pour répondre à l’exemple des 27 fours, « casser le multibloc » est interprété
+ici comme **dissocier la machine sur place**. Les 27 fours restent posés et
+retrouvent un fonctionnement individuel. Le même principe s’applique aux neuf
+bases du méga-piston, y compris sa variante collante. Récupérer un bloc dans
+l’inventaire est une autre action ; la clé ne compacte pas les 27 composants
+en un objet machine transportable.
+
+**Exigence : la dissociation persiste.** Une forme compatible n’est pas forcément
+un assemblage actif. Les blocs séparés doivent rester indépendants après une
+mise à jour voisine, un déchargement ou une réouverture, même si le cube de
+fours est toujours complet. Le joueur peut les réunir à nouveau avec la même
+clé : cette fonction est validée. Le geste exact de réassemblage reste à choisir.
+
+**Règle commune retenue : poser ne suffit pas à assembler.** Les blocs
+nouvellement posés gardent leur usage individuel ; le joueur les réunit
+volontairement avec la clé. Fours, hoppers et pistons peuvent ainsi rester
+des composants indépendants. Proposition de retour visuel : une forme compatible
+est mise en évidence avec l’outil avant de modifier les circuits.
+
+Le démontage conserve **l’état actuel** des matériaux et du travail. Il ne
+restaure pas les anciens inventaires d’avant assemblage : du combustible a
+pu être consommé et des recettes terminées depuis. Les contenus encore
+présents sont redistribués ou restitués une seule fois ; les matières d’un
+résultat terminé ne reviennent pas en plus de ce résultat. La répartition
+dans les cases des fours/barils individuels et le traitement d’un surplus
+restent à définir. Si une séparation ne peut pas conserver le contenu, elle
+doit attendre une récupération du stock, sans supprimer les objets.
+
+Pour le méga-piston, le démontage concerne **l’ensemble réel de la mécanique**,
+avec ses bases, sa tête et sa tige. Une tête déployée ne devient pas un piston
+supplémentaire à récolter. Proposition de premier comportement : intervenir
+une fois le piston rétracté et immobile ; une demande pendant le mouvement
+ne déplace pas instantanément sa charge. La récupération d’un piston ordinaire
+avec la clé est également à prévoir, avec sa durée et son usure propres.
+
+### Gestes proposés
+
+| Situation | Geste à essayer | Résultat attendu |
+| --- | --- | --- |
+| Blocs indépendants compatibles | Sélection puis validation avec la clé ; combinaison de touches à définir | Former volontairement une machine commune à partir des blocs choisis. |
+| Bloc indépendant orientable | Clic droit avec la clé | Passer à l’orientation admissible suivante, avec un aperçu du sens obtenu. |
+| Multibloc actif | Sneak + clic droit avec la clé | Mettre en évidence tout le groupe visé et le dissocier sur place, selon son état de fonctionnement. |
+| Bloc à récupérer | Minage avec la clé | Récupérer le bloc admissible ; durée, outils compatibles et cas des pistons à préciser. |
+| Composant d’un multibloc actif, demande de rotation | Clic droit avec la clé | Montrer l’assemblage concerné ; dissocier avant de tourner un seul composant, afin de ne pas désorganiser silencieusement la machine. |
+
+Les trois fonctions sont retenues ; ces gestes précis restent proposés. La clé tenue distingue l’intention
+de réglage des clics usuels : ouvrir un baril, accorder un bloc musical,
+configurer un contrôleur ou insérer un objet dans le particuleur.
+
+Le **Carillon** emploie aussi la clé pour réunir volontairement les blocs
+adjacents choisis. La séquence de sélection et de validation reste à dessiner ;
+elle respecte le choix d’un assemblage adjacent volontaire.
+Le geste d’assemblage doit se distinguer de la rotation d’un bloc indépendant.
+
+### Orientations et autres usages à explorer
+
+| Cible | Fonction retenue ou piste |
+| --- | --- |
+| **Escalier — demandé** | Tourner sa direction en conservant le matériau ; le raccord aux voisins est recalculé. Retourner haut/bas est une possibilité supplémentaire à choisir séparément. |
+| **Baril — demandé** | Réorienter son ouverture en conservant son contenu et son identité. Les 27 barils d’un Fût doivent d’abord être dissociés pour être réglés individuellement. |
+| **Piston — piste de réglage** | Changer la direction une fois rétracté, sans déplacer les blocs devant lui ni modifier sa variante normale/collante. |
+| **Hopper — piste** | Tourner le bec vers une sortie admissible, pour raccorder notamment le hopper situé sous la Trémie. Cela ne choisit pas une destination distante. |
+| **Bûche ou pilier — piste** | Changer l’axe en place, avec les états permis par le bloc. |
+| **Répéteur, comparateur, distributeur — pistes** | Corriger la direction en conservant les réglages ou objets. La nouvelle connexion suit la construction obtenue. |
+
+L’admissibilité dépend du bloc : support, raccords, pièces liées et état de
+fonctionnement. La liste n’accorde pas automatiquement une rotation à tous
+les blocs ou multiblocs du pack. Pour les appareils à entrée/sortie relative,
+une rotation réévalue les connexions et retire les anciens signaux des faces
+abandonnées.
+
+**Contrôleur :** une éventuelle rotation à la clé garde les adresses cardinales
+du programme et la configuration de ses faces ; tourner sa façade ne remappe
+pas `NORTH` vers `EAST`. CPU et RAM sont conservés. Cette extension demanderait
+un contrôleur arrêté ou en pause et une vérification des connexions avant
+reprise. Elle complète les [fiches des composants](redstone-language-composants.md),
+sans changer le langage ni les commandes main vide.
+
+Les opérations restent des modifications de construction validées côté
+serveur, avec les mêmes droits de modification du lieu. La clé ne termine
+pas une recette et ne relance pas un programme pour effectuer une rotation.
+
+## Fourneau — 27 fours et une chauffe commune
+
+L’intérêt est de **traiter une charge de matériaux dans un même appareil chauffé**.
+Le joueur assemble les 27 fours, apporte le combustible et choisit la charge.
+Le contrôleur peut ensuite organiser les cycles, mais le four doit être utilisable
+à la main et avec une commande redstone simple.
+
+### Forme retenue et aspect proposé
+
+**27 blocs de four ordinaires forment un cube plein de 3 × 3 × 3**, y compris
+le bloc central. Ni cavité laissée vide, ni briques de remplacement, ni foyer
+supplémentaire à fabriquer. Proposition : la forme complète est reconnue
+comme compatible avec un seul appareil, doté d’une grande façade et d’une
+interface commune. Une disposition dissociée à la clé reste indépendante
+jusqu’à un réassemblage volontaire.
+Le choix de sa façade, la règle d’orientation des blocs et son raccord visuel
+restent à éprouver.
+
+Trois couches identiques, `F` représentant un vrai bloc de four :
+
+```text
+Base       Milieu     Dessus
+FFF        FFF        FFF
+FFF        FFF        FFF
+FFF        FFF        FFF
+```
+
+La grille de matériaux est un inventaire de l’appareil ; elle ne nécessite pas
+neuf cellules vides à l’intérieur de ce cube. Les 27 fours construits donnent
+la forme et le coût de l’ensemble, pas automatiquement 27 fois la vitesse ou
+le rendement. Le regroupement doit conserver les objets, combustibles et états
+présents avant formation, sans continuer simultanément 27 cuissons indépendantes.
+Le contrat de formation/démontage sera défini avant toute conversion en jeu.
+
+**Nom proposé : Fourneau.** « Méga-four » reste descriptif pendant la discussion.
+Le nom ne désigne pas un assemblage de hauts fourneaux : le matériau demandé
+est bien le four ordinaire. Aucun registre existant n’est renommé dans ce cahier.
+
+### Deux usages à comparer dans le même appareil
+
+| Usage proposé | Charge et résultat |
+| --- | --- |
+| **Cuire une fournée / Batch smelting** | Les neuf cases accueillent des matières à cuire selon les recettes admises. Plusieurs pièces partagent un cycle de chauffe ; les résultats restent ceux des recettes. Aucun mélange accidentel ne devient automatiquement un alliage. |
+| **Recette à chaud / Heat crafting** | La grille 3 × 3 forme une seule recette composée : ingrédients, positions ou proportions définis par la recette, durée et résultat. Les matériaux sont traités ensemble. C’est la piste pour les alliages et de nouvelles transformations. |
+
+Le mode serait choisi explicitement à la façade, avant de lancer la charge.
+Cela rend compréhensible la différence entre deux minerais cuits séparément
+et deux matériaux destinés à une transformation commune. Un livre de recettes
+ou un programme peut aider à préparer le plateau ; ni l’un ni l’autre n’est
+requis pour les premières utilisations manuelles.
+
+**Capacité d’essai proposée :** neuf cases d’entrée et un bac de résultats
+acceptant plusieurs types d’objets. Neuf cases ne signifient pas que neuf stacks
+complètes doivent fondre instantanément. Pour un premier cycle de cuisson,
+prélever une unité par case occupée admissible ; pour une recette composée,
+prélever les quantités définies par cette recette. Les réserves restantes
+peuvent alimenter les cycles suivants.
+
+Une recette à chaud ressemble ainsi à un craft qui demande aussi une cuisson :
+**disposer → chauffer → récupérer**. Le premier essai n’a pas besoin de degrés
+réels, de pression, de gaz ou d’une interface de simulation industrielle.
+Des familles de chauffe pourront apparaître si certaines recettes le justifient.
+
+### Source de chaleur et intérêt du volume
+
+Une seule source de chaleur alimente l’appareil entier. La proposition de
+départ est **un foyer et une réserve de combustible communs**. Le foyer peut
+consommer plusieurs unités au fil de la fournée ; « une source » désigne son
+emplacement, pas une unité de combustible valable indéfiniment.
+
+La durée et le combustible consommé doivent dépendre du travail demandé. Le
+gain du grand four peut venir de la chauffe partagée et du traitement par lots,
+avec un rendement à comparer à une installation de fours ordinaires. Aucun
+multiplicateur de vitesse, de combustible ou de minerais n’est arrêté ici.
+
+Un contact avec une source extérieure, un foyer permanent ou le
+[siphon thermique proposé](redstone-language-objets-et-cristaux.md#siphon-thermique)
+sont d’autres pistes. Ils demanderaient leurs propres règles ; ils ne donnent
+pas implicitement une production illimitée gratuite au premier four.
+
+### Cycle proposé
+
+1. Compléter le cube de 27 fours et former volontairement l’installation avec
+   la clé, selon le geste à choisir. Un cube dissocié reste indépendant tant
+   que le joueur n’a pas choisi de le réunir à nouveau.
+2. Charger le plateau, choisir le mode et alimenter le foyer.
+3. Prévisualiser les ingrédients utilisés et les résultats, puis lancer. Le
+   serveur vérifie la recette, le combustible et la place nécessaire au résultat.
+4. Isoler la charge en cours ; les apports ultérieurs attendent le cycle suivant.
+   Le foyer chauffe pendant la durée de travail, avec une animation et un état
+   lisibles en façade.
+5. Déposer le résultat une seule fois dans le bac, prêt au retrait. Un cycle
+   n’éjecte pas son contenu dans le vide parce que le bac voisin est plein.
+
+Pour ce prototype proposé, les ingrédients engagés sont gardés dans la charge
+en cours jusqu’à la transformation. Une structure cassée arrête le traitement ;
+avant transformation, les matériaux de la charge restent récupérables et le
+combustible déjà brûlé reste dépensé. Après transformation, seul le résultat
+correspondant existe. Une reprise ne doit pas refaire le même lot.
+
+La politique de refroidissement après coupure ou rupture est à éprouver. Pour
+les matières industrielles, aucune destruction, explosion ou surveillance
+constante n’est ajoutée par défaut. Les recettes culinaires conservent au
+contraire les fenêtres de cuisson et de récupération prévues par It's Alive ! :
+le méga-four ne garantit pas automatiquement la meilleure qualité d’un plat.
+
+### Redstone, convoyeurs et programmes
+
+La proposition distingue **autoriser les cycles** et **fournir la chaleur**.
+Un levier peut permettre les fournées automatiques ; le combustible reste requis.
+Une coupure empêche les nouveaux engagements et met le traitement en pause selon
+la règle thermique choisie. Le fonctionnement manuel ne dépend pas d’un CPU.
+
+Un comparateur pourrait donner le remplissage du bac de résultats. Les états
+« prêt », « chauffe », « manque de matière » et l’avancement exact pourraient
+passer par une interface de données vers un contrôleur et un afficheur, sans
+faire signifier plusieurs mesures différentes au même signal de comparateur.
+
+L’automatisation demande des **points d’accès identifiés** : entrées du plateau,
+combustible, sortie. Leur forme et leurs faces seront définies avec le dessin
+retenu, en respectant les ingrédients des recettes positionnelles. Un convoyeur
+amène des drops à un collecteur ; un coffre collé ne les aspire pas spontanément.
+Les opérations se font dans un inventaire commun, sans recopier le contenu
+dans chacun des 27 fours constitutifs.
+
+Un programme pourrait remplir, vérifier, chauffer puis évacuer. Copier sa
+disquette ne copie ni le four, ni le stock, ni les recettes débloquées. Le
+programme thématique **Conversion**, déjà proposé pour le Nether, pourrait
+montrer un savoir-faire de ce type ; il n’impose pas de verrou Nether au four.
+
+## Recettes et place dans la progression
+
+L’auteur souhaite ouvrir la possibilité des alliages. Leur composition et leurs
+usages restent à concevoir ; la présence du silver et du titane dans la vision
+ne les transforme pas automatiquement en alliages fabriquables. Les équipements
+Anomaly restent infrabricables selon la règle retenue.
+
+Pour éprouver le four, préparer deux familles de recettes : une cuisson par lot
+qui conserve les rendements usuels des recettes choisies, puis **une recette à
+plusieurs ingrédients dont le produit a un usage clair**. La première révèle le
+confort de la chauffe commune ; la seconde justifie la nouvelle fonction du four.
+Le choix du premier alliage doit venir avec la pièce, le bloc ou l'équipement
+auquel il sert, sans ajouter plusieurs métaux seulement pour remplir une grille.
+
+Le maçon ou un autre métier approprié pourrait travailler dans un atelier qui
+emploie ce four, selon les futures tâches rémunérées des villageois. L’appareil
+traite une charge ; le travailleur se déplace, approvisionne et organise une tâche
+de métier.
+
+### Une cuisson commune avec It's Alive !
+
+**Direction retenue : le méga-four accueille les recettes de cuisson d'It's
+Alive ! et reprend le rôle du kitchen oven.** Il n’y a pas besoin de maintenir
+deux appareils qui font la même cuisson dans le pack. Les poêles, marmites,
+moulins, séchoirs et autres procédés distincts gardent leurs rôles ; cette
+décision ne transforme pas toute préparation culinaire en cuisson au four.
+
+It's Alive ! reste autonome : ingrédients, recettes, pages, qualité et suivi
+culinaire restent sous sa responsabilité. L’appareil de chauffe commun doit
+donc pouvoir être fourni avec ce mod ou une dépendance partagée explicitement
+déclarée, sans imposer le reste de Sanctuary pour jouer à sa cuisine. Le choix
+du module qui porte le four appartient au ticket d’architecture, avant code.
+
+Les recettes métallurgiques et culinaires utilisent le même service de charge
+et de chauffe, avec leurs propres résultats et règles. Le regroupement ne crée
+pas de contamination des aliments, de bonus d’alliage sur les plats ou de
+nouvelle étape de nettoyage implicite. Le modèle mélangeant différentes durées
+et fenêtres culinaires dans une même fournée devra être essayé ; un premier
+cycle homogène peut servir de témoin avant de promettre toutes les combinaisons.
+
+## Fût — 27 barils et un stockage paginé
+
+**Nom retenu : Fût**, à la place de giga-baril. **27 barils ordinaires assemblés
+en cube plein de 3 × 3 × 3** donnent un stockage commun parcouru par **pages
+et/ou défilement**. L’intégration des cases à l’inventaire custom reste
+explicitement ouverte à la demande de l’auteur.
+
+Le matériau et le gabarit sont désormais définis. Le dessin du fût, son orientation,
+la capacité, les tailles supplémentaires et la présentation des pages restent
+à préciser. Proposition : les barils contenant déjà des objets conservent leurs
+quantités lors du regroupement ; le nouvel inventaire ne les copie pas en plus
+des anciens. Ce contrat doit aussi fonctionner au démontage.
+
+- Le nombre de pages présente une capacité réelle et finie ; faire défiler
+  n’ajoute pas des emplacements sans limite.
+- Deux joueurs ou deux ouvertures accèdent au même contenu autoritaire. Tourner
+  une page change la vue, pas l’identité ou le nombre des objets stockés.
+- Les hoppers, s’ils sont raccordés, travaillent sur le stockage selon leurs
+  faces et filtres ; ils ne dépendent pas de la page affichée par un joueur.
+- L’agrandissement ou la casse doit conserver une représentation unique des
+  matières. Réduire la capacité ne peut pas faire disparaître le contenu des
+  pages devenues invisibles. Le comportement concret est à définir avant code.
+- Une page de conteneur n’est pas une rangée supplémentaire de l’inventaire
+  personnel ; la progression des cases du joueur garde son contrat.
+
+Le Fût est un **lieu de stockage**. Le terminal en titane reste l’outil
+de consultation d’un réseau de coffres ; les deux capacités ne sont pas confondues.
+Le baril de fermentation décrit ci-dessous est une machine de transformation,
+pas une autre page ou un mode caché du dépôt.
+
+## Grand baril de fermentation — une recette, plusieurs stacks
+
+**Nom retenu : grand baril de fermentation.** Il traite plusieurs stacks d’une **même recette de fermentation**
+dans un grand baril. Une recette peut comporter plusieurs ingrédients ; « même
+recette » ne signifie pas « un seul type d’objet ». Les proportions doivent
+rester celles de la recette, multipliées par la taille du lot engagé.
+
+La composition exacte du grand baril n’est pas déduite de celle du Fût de stockage.
+Proposition : une cuve de fermentation construite, reconnaissable à sa bonde
+et à son point de remplissage. Un premier gabarit 3 × 3 × 3 peut être étudié,
+sans en faire la taille imposée de tous les procédés culinaires.
+
+1. Choisir la recette et charger ses ingrédients jusqu’à la quantité souhaitée.
+2. Fermer le lot : afficher la recette, les quantités utilisées et les résultats
+   attendus. Les ingrédients en excès restent hors du lot engagé.
+3. Lancer une fermentation commune, avec une date de départ et les conditions
+   définies par It's Alive !.
+4. Récupérer la production ou poursuivre un vieillissement si la recette le prévoit.
+
+Pour le premier contrat proposé, ajouter des ingrédients après le départ ne
+leur donne pas rétroactivement l’âge du lot. Ils attendent un nouveau cycle.
+La fermentation de plusieurs stacks suit un même procédé ; rendement, durée,
+volume utile et conditions ne sont pas fixés par le nombre de stacks seul.
+
+Le vieillissement du vin et l’affinage déjà prévus gardent leurs règles. La bière
+ne reçoit pas automatiquement le bonus de vieillissement du vin. Les pages
+culinaires et l’apprentissage des recettes restent ceux d'It's Alive !.
+
+La relation entre temps réel, arrêt du serveur et progression du lot est à
+choisir explicitement : une date sauvegardée peut permettre une évolution
+hors ligne, mais ce n’est pas déduit du calendrier de Sanctuary. Recharger une
+cuve ne doit ni recommencer un lot ni produire deux fois ses résultats.
+
+Le rôle de la redstone serait d’autoriser le lancement et les transferts, avec
+un état lisible sur place. Couper un fil n’arrête pas automatiquement un procédé
+biologique : les règles de conservation et d’interruption appartiennent à la
+recette. Un afficheur peut montrer recette, durée et quantité sans rendre un
+ordinateur obligatoire pour faire fermenter une charge.
+
+## Métablit — proposition d’établi collectif
+
+L’auteur propose le nom **Métablit**. La fonction explorée ici est un établi
+construit où **un projet reste en place**, avec son plan et les matériaux que
+plusieurs joueurs apportent. Un joueur doit aussi pouvoir l’utiliser seul.
+
+La surface peut montrer les pièces déjà réunies et celles qui manquent. Fermer
+l’interface ne rend pas tout au dernier visiteur ; le projet appartient à la
+table et ses accès suivent les règles de l’installation. Une fabrication
+réussie consomme ses matériaux et produit un seul résultat récupérable.
+
+**Exemple de projet à éprouver :** rassembler les quatre bateaux nécessaires
+au Booat, les voir dans le projet, puis réaliser la recette. Le Métablit ne
+devient pas obligatoire pour cette recette déjà prévue, et n’en change pas
+les ingrédients par défaut. D’autres assemblages peuvent révéler si cette
+forme de travail apporte assez pour justifier le bloc.
+
+Un plan utilise les connaissances et recettes effectivement accessibles.
+La table ne débloque pas le catalogue mondial de schematics, ne remplace pas
+les conditions galactiques du build et ne construit pas gratuitement l’ouvrage
+ailleurs dans le monde. Taille de la surface, grille, gestes et distinction
+avec crafter/table de craft restent à préciser : la seule augmentation de
+taille d’un menu ne suffit pas à expliquer son intérêt.
+
+## Présentoirs de collection — objets visibles sur les façades
+
+L’auteur retient les archives modulaires et précise leur rôle de **collection
+visible**, proche de celui des item frames. **Présentoir** est un nom proposé
+pour le bloc à neuf emplacements ; ce nom et sa fabrication restent ouverts.
+
+**Comptage confirmé avec l’auteur :**
+
+| Disposition | Objets distincts exposables |
+| --- | --- |
+| Une face de bloc | 3 × 3 petits emplacements, soit **9 objets**. |
+| Une façade de 3 × 3 blocs | Neuf faces de bloc, soit **81 objets visibles simultanément** en grille 9 × 9. |
+| Quatre façades de 3 × 3 | **81 objets différents par face, soit 324 au total**. |
+
+Une façade plate 3 × 3 suffit : la construction en volume n’est pas obligatoire.
+Dans une disposition cubique avec quatre murs, les angles présentent deux
+faces distinctes. Leurs objets ne sont pas des copies vus depuis deux côtés :
+chaque face possède ses propres neuf emplacements. Le nombre de blocs supports
+ne suffit donc pas à déterminer la capacité. Dessus et dessous n’ajoutent pas
+implicitement d’autres emplacements aux 324 confirmés.
+
+Ce sont des objets visibles dans le monde, **sans pagination des 81 objets de
+la façade**. Le Fût conserve sa pagination de stockage ; l’afficheur programmable
+conserve ses huit lignes de texte par bloc. Ces trois appareils ont des fonctions
+et des rendus distincts.
+
+### Contenus à exposer
+
+| Demandé par l’auteur | Présentation à concevoir |
+| --- | --- |
+| Cartes, plans et recettes | Montrer leur support, avec la carte miniature ou une couverture lisible. Une consultation peut ouvrir le contenu déjà accessible. |
+| Photos | Conserver la carte ou le support photographique réel et afficher l’image correspondante ; ne pas fabriquer neuf copies de la carte. |
+| Disquettes | Icône, nom du programme ou étiquette. L’exposition ne charge pas le programme dans un contrôleur. |
+| Disques blancs, disques musicaux/CD | Pochette ou disque visible, selon le modèle retenu. Le présentoir n’est pas automatiquement un jukebox. |
+| Spawn eggs | Œufs visibles par catégorie ou couleur, sans apparition d’entité ni activation de pouvoir de familier. |
+
+**Proposition de généralisation :** accepter aussi outils, armes, armures,
+gemmes, fleurs, trophées et autres items représentables dans une case. Un
+premier principe simple serait **un objet physique par emplacement**, pas une
+stack cachée derrière chaque icône. Les cas de modèles volumineux ou de contenus
+moddés devront être éprouvés ; aucune liste universelle n’est déjà implémentée.
+
+Le joueur viserait un des neuf emplacements pour insérer ou retirer son objet.
+Les gestes exacts et la consultation restent à dessiner avec l’inventaire custom.
+Exposer une recette ou un plan ne débloque pas automatiquement ses droits pour
+tout le serveur. Casser un support doit rendre les objets concernés une seule
+fois, y compris ses deux faces s’il appartient à un angle.
+
+**Constructions possibles :** mur des expéditions en cartes et photos, bibliothèque
+publique de programmes, collection de disques, galerie d’œufs rares. Le rendu
+de 324 items, notamment des cartes, devra rester lisible et raisonnable à distance ;
+les niveaux de détail pourront réduire le coût sans réduire le nombre d’objets
+réels ou transformer les façades en pages invisibles.
+
+## Méga-pistons — une façade mobile sur trois blocs
+
+**Retenu et confirmé :** neuf pistons assemblés en façade **3 × 3** donnent
+une tête commune **3 × 3**, dont la **course est de trois blocs**. La variante
+collante est également demandée. Ce n’est pas seulement neuf pistons qui
+avancent chacun d’un bloc.
+
+Proposition de formation : neuf pistons ordinaires de même orientation donnent
+le méga-piston ; neuf pistons collants de même orientation donnent sa variante
+collante. Les mélanges ne constituent pas un troisième comportement par défaut.
+La profondeur des bases et l’aspect de la tige déployée restent à dessiner.
+La clé à molette dorée permet de dissocier les neuf bases pour retrouver des
+pistons indépendants. Le cas rétracté est proposé pour le premier essai ;
+l’outil ne sépare pas neuf mouvements pendant une course commune.
+
+- La redstone commande **un mouvement d’ensemble**. Alimenter plusieurs blocs
+  constitutifs ne multiplie pas les poussées ni la distance parcourue.
+- La tête doit contrôler son trajet complet, pas seulement la destination à
+  trois blocs : elle ne traverse pas un obstacle intermédiaire.
+- Proposition : si une partie bloque le mouvement admissible, l’ensemble
+  refuse de démarrer. Les neuf cases ne se désolidarisent pas pour avancer
+  indépendamment et arracher un morceau de la construction.
+- La version collante doit ramener la charge admissible avec sa tête lors de
+  la rétraction. Limites, blocs adhérents et collisions restent à définir ;
+  le mot « collant » ne promet pas de déplacer tous les conteneurs ou machines.
+- Les **27 cellules balayées** par la tête pendant sa course ne sont pas une
+  limite validée de 27 blocs transportés. Masse poussable, nombre de blocs en
+  profondeur, durée et interactions slime/miel sont des réglages distincts.
+
+L’interruption en cours de déplacement, le déchargement et la casse demandent
+un état de mouvement commun, sauvegardé une seule fois. Aucun de ces détails
+ne doit être remplacé par une copie des neuf mouvements de pistons indépendants.
+
+**Constructions possibles :** grande porte rétractable de trois blocs, plateforme
+élévatrice sur une course de trois blocs, mur mobile ou poste d’amenée d’une
+section de construction. Le trajet réel doit être animé et perceptible ; le
+moteur ne téléporte pas la charge à travers des blocs.
+
+## Trémie — neuf hoppers et une grande surface de collecte
+
+**Retenu par l’auteur :** neuf hoppers à plat, en carré **3 × 3**, recueillent
+les drops sur leur surface et réunissent **neuf fois l’inventaire d’un hopper**.
+Le hopper Java de la cible possède cinq emplacements : la Trémie dispose donc
+de **45 cases communes**, avec les limites d’empilement propres aux objets.
+Ce gain de capacité ne fixe pas un débit de sortie neuf fois supérieur.
+
+**Choix explicitement demandé : la Trémie est facultative.** Les joueurs
+peuvent conserver neuf hoppers côte à côte pour construire un autre circuit.
+Chaque hopper indépendant garde ses cinq cases, son bec, ses connexions et
+sa commande redstone. La réserve de 45 cases communes et la sortie unique
+appartiennent seulement à l’assemblage actif.
+
+Règle retenue : les hoppers se posent indépendamment et la clé
+à molette dorée permet de choisir leur réunion en Trémie. Les poser en 3 × 3,
+compléter un coin manquant ou approcher un autre hopper ne doit donc pas
+convertir un montage par simple voisinage. Désassembler à la clé rend les
+neuf blocs indépendants, sans les réunir à nouveau après rechargement.
+
+### Sortie proposée : sous le centre
+
+La sortie reste à choisir. La proposition la plus lisible est **un seul bec
+sous le bloc central**, visible dans le modèle raccordé. Les huit autres
+hoppers constituent les bords du collecteur ; leurs anciennes orientations
+ne deviennent pas huit sorties supplémentaires une fois l’ensemble formé.
+
+```text
+Vue de dessus              Coupe par le centre
+H H H                       H H H
+H C H                         ↓
+H H H                       sortie
+
+C : hopper central ; sortie sous C
+```
+
+Le joueur peut mettre le conteneur destinataire sous ce bec. Pour partir sur
+un côté, il place **un hopper ordinaire dessous, orienté vers la suite de son
+circuit** ; si nécessaire, une chaîne rejoint le bord du plateau. Ce hopper
+supplémentaire est un raccord indépendant avec ses cinq cases, pas une dixième
+partie obligatoire de la Trémie. La sortie n’est ni distante ni choisie dans
+le menu d’un ordinateur.
+
+Autre piste : un bec latéral choisi lors de l’assemblage. Elle économise de la
+hauteur, mais demande de montrer quel bord évacue les objets et comment le
+joueur le choisit. Elle n’est pas cumulée d’office avec la sortie centrale.
+
+### Fonctionnement à éprouver
+
+- Le stock est commun aux neuf surfaces. Les neuf inventaires d’origine ne
+  continuent pas à se transférer les mêmes objets en parallèle.
+- Dans la proposition à bec central, les extractions automatiques passent
+  par ce raccord identifié ; mettre un hopper sous un angle n’ajoute pas une
+  deuxième sortie cachée. Les interfaces d’insertion restent à préciser.
+- Destination pleine ou absente : les objets restent dans les 45 cases ; une
+  réserve pleine laisse les nouveaux drops dans le monde, sans les effacer.
+- La collecte concerne la surface construite, pas un rayon d’aspiration
+  élargi autour de l’appareil. La collecte et le débit d’évacuation seront
+  réglés séparément.
+- Proposition de commande : alimenter le bloc central verrouille l’ensemble,
+  selon le rôle d’arrêt du hopper. La portée électrique, le comparateur et
+  les faces de commande doivent être rendus lisibles avant de fixer le contrat.
+- La formation volontaire à la clé est retenue ; une
+  nappe de hoppers indépendants conserve ses circuits et ne devient pas
+  obligatoirement une Trémie du fait de sa forme.
+  Au démontage à la clé, le stock actuel est conservé une seule fois et les
+  orientations indépendantes sont rétablies ; l’ancien stock d’avant formation
+  n’est pas restauré en plus du contenu courant. La dissociation persiste.
+
+**Usages :** réception sous une récolte, convergence de plusieurs convoyeurs,
+grand bac de déchargement. Le terminal peut consulter le stock ; il n’est pas
+requis pour décider où les objets ressortent.
+
+## Carillon — des notes réunies en instrument
+
+**Retenu par l’auteur :** réunir des blocs musicaux pour former des **accords
+ou de courtes séquences**, avec un **assemblage adjacent choisi**. Le joueur
+choisit les blocs qui appartiennent à son instrument. Ni rangée obligatoire,
+ni carré 3 × 3, ni nombre de neuf notes imposé. Le simple voisinage ne forme
+pas automatiquement un groupe. Ce choix remplace la préférence précédente
+pour une rangée ; les contraintes rectangulaires de l’afficheur ne s’appliquent
+pas au Carillon.
+
+### Sélection de l’instrument et ordre de lecture
+
+Proposition de gestes et de lecture, encore à éprouver :
+
+1. Entrer volontairement en assemblage sur un premier bloc musical ; il sert
+   de point de commande identifiable pour le groupe.
+2. Ajouter les blocs souhaités, chacun étant adjacent par une face à au moins
+   un bloc déjà sélectionné. Une diagonale seule ne suffit pas dans cette
+   proposition. Un voisin non sélectionné reste indépendant.
+3. **Utiliser l’ordre de sélection comme ordre initial de la séquence.** Le
+   nouveau bloc n’a pas besoin de toucher la dernière note sélectionnée : il
+   touche le groupe. Les branches restent possibles sans demander au moteur
+   de deviner quel chemin musical suivre.
+4. Montrer cet ordre par de petits numéros ou repères pendant le réglage,
+   écouter un aperçu, puis valider. Une commande de réordonnancement reste
+   à dessiner pour changer la mélodie sans reconstruire l’instrument.
+
+Le nombre maximal de notes, les gestes exacts et l’éventuelle construction
+en volume restent à définir. La clé à molette dorée est retenue pour réunir
+le groupe choisi et pour le désassembler.
+Des blocs musicaux non réunis gardent leur fonctionnement individuel ; deux
+carillons peuvent être voisins sans fusionner. La casse suspend le groupe
+concerné jusqu’à réparation ou redéfinition, selon un contrat à préciser,
+plutôt que de renuméroter la mélodie silencieusement.
+
+Un raccord visuel discret ferait apparaître un cadre commun, en gardant chaque
+bloc accessible pour l’accorder et chaque position lisible pendant le jeu.
+Ni coque cubique ni neuf blocs supplémentaires d’habillage ne sont nécessaires
+dans cette proposition.
+
+### Notes, instruments et tempo
+
+Chaque bloc garde sa note et son instrument. Pour les instruments usuels,
+le support sous **chaque bloc** continue à déterminer le timbre : le groupe
+ne remplace pas tous les supports par celui du premier bloc. Les exceptions
+vanilla utilisant un instrument au-dessus doivent aussi être conservées.
+Un habillage commun ne doit pas obturer l’espace nécessaire au jeu des notes.
+Ces règles sont vérifiées dans `NoteBlock` pour la cible Java 26.3-pre-2.
+
+Deux modes proposés, sélectionnables sur l’instrument avec un repère visible :
+
+- **Accord :** une impulsion joue ensemble les notes du groupe.
+- **Séquence :** une impulsion joue la prochaine note, puis avance d’une case.
+  Une horloge redstone donne le tempo ; sans nouvelle impulsion, la lecture
+  attend. Après la dernière note, le prochain déclenchement revient au début.
+
+Ainsi, un bouton permet de jouer à la main et un circuit peut commander un
+motif. Une commande locale de retour au début est à prévoir. Les clics usuels
+d’accordage et d’écoute doivent rester disponibles ; changer une note pendant
+l’édition ne déclenche pas toute la séquence involontairement.
+
+Le lancement d’une phrase entière par une seule impulsion est une **variante
+à comparer**, avec un tempo interne à régler. Il ne se cumule pas implicitement
+avec le mode où chaque impulsion donne une note. Silences, répétitions d’une
+note et durées individuelles sont des pistes ultérieures, pas un séquenceur
+complet déjà décidé. Les programmes peuvent ensuite composer avec les mêmes
+commandes physiques, sans être nécessaires pour jouer un accord.
+
+**Usages :** sonnerie de gare, horloge qui joue une courte mélodie, alarme
+reconnaissable ou instrument que plusieurs joueurs accompagnent. Le Carillon
+ne lit pas automatiquement les disques exposés dans un présentoir.
+
+## Autres assemblages de blocs identiques à explorer
+
+La recherche suit désormais le principe de regroupement précisé par l’auteur :
+une grande surface ou un volume donne une fonction commune aux blocs posés.
+Les gabarits et les noms ci-dessous sont proposés, pas retenus.
+
+| Assemblage proposé | Fonction agrandie | Exemples d’usage |
+| --- | --- | --- |
+| **Veilleur : 9 observateurs en façade, 3 × 3** | Surveiller les neuf positions juste devant la façade ; montrer où un changement a eu lieu et permettre d’en récupérer l’information. | Surveillance d’une surface cultivée ; porte à combinaison de blocs. Aucune lecture à travers toute l’île ni détection de maturité s’il n’y a pas de donnée définie. |
+| **Batterie de distribution : 9 distributeurs en façade, 3 × 3** | Choisir une bouche ou enchaîner les neuf dans une séquence, avec leurs vrais objets et comportements de distribution admis. | Arrosage de positions définies avec des seaux ; spectacle de feux d’artifice. Pas de gain gratuit de projectiles par objet consommé. |
+
+Le Veilleur et la batterie de distribution demandent une interface de sélection claire pour ne pas seulement
+regrouper les menus des neuf blocs.
+
+La **presse à moule est retirée de la sélection** : l’auteur juge la fabrication
+déjà couverte par le crafter qu’il évoque. Le terme retranscrit « gel crafter »
+n’a pas permis d’identifier un autre composant dans les sources consultées ;
+aucun comportement d’un nouveau crafter n’est supposé ici. Le Métablit reste
+en réflexion, sans réintroduire la presse sous un autre nom.
+
+Les anciennes pistes de bassin de traitement, serre climatique, écluse et
+alambic restent en réserve comme installations construites. Elles n’appartiennent
+pas automatiquement à la nouvelle famille de blocs identiques assemblés.
+Les recettes culinaires éventuelles d’un bassin ou alambic restent de la
+responsabilité d'It's Alive !.
+
+## Règles communes à prévoir pour les multiblocs
+
+- La construction reconnaît sa forme, ses blocs constitutifs et ses pièces utiles. Un décor voisin
+  ne fait pas gagner silencieusement une capacité ou un rendement.
+- La clé à molette dorée permet une dissociation durable en blocs indépendants.
+  Reconnaître une forme compatible ne la réactive pas contre le choix du joueur.
+- Règle commune retenue : la formation elle-même est volontaire, avec la clé.
+  Les circuits de hoppers et les groupes de fours ordinaires restent utilisables
+  dès la pose, sans devoir obtenir un outil pour empêcher leur regroupement.
+- Une installation possède un seul état de référence. Deux façades ne dupliquent
+  pas les stocks ; deux machines ne revendiquent pas les mêmes blocs constitutifs.
+- Décharger un morceau suspend le fonctionnement concerné sans charger le monde
+  à distance ni rejouer des cycles écoulés hors ligne.
+- Casser ou modifier l’assemblage a un effet explicite sur le travail et les
+  matières ; déplacement et récupération ne copient pas une charge en cours.
+- Les constructions fonctionnent avec leurs gestes locaux ; le terminal, le
+  contrôleur et l’afficheur permettent ensuite d’en coordonner plusieurs.
+
+Ces règles sont des exigences pour les futurs tickets, pas un format de sauvegarde
+déjà adopté. La première validation proposée reste **un four construit à la main,
+une fournée ordinaire et une recette composée**, avec arrêt/reprise et retrait
+des résultats. Aucun monde existant n’est modifié pour ce cahier.

docs/progression-et-integrations.md

@@ -0,0 +1,650 @@
+# Sanctuary — progression, outils et intégrations
+
+**Conception en discussion, WG-26.** Ce cahier relie les outils communautaires,
+les capacités Sanctuary et les découvertes à la progression. Il ne livre aucun
+mod, plan, slot ou changement de sauvegarde. La version de référence du chantier
+reste Minecraft **26.3-pre-2, Fabric** ; chaque intégration demandera une
+vérification sur cette version exacte avant distribution.
+
+## Direction retenue
+
+Sanctuary est un RPG Minecraft pour une communauté d’environ vingt joueurs.
+Explorer, construire, produire, programmer et combattre donnent des moyens
+différents de progresser. Certains outils de confort deviennent des capacités
+que l’on acquiert : consultation des recettes, orientation, plans de construction
+ou informations supplémentaires. Les fonctionnalités à débloquer sont définies
+par Sanctuary ; le mod communautaire peut en fournir l’interface ou l’outil.
+
+**Cadrage proposé :** laisser les réglages de présentation, de performance et
+d’accessibilité à la disposition du joueur. Shaders, textures HD et acoustique
+ne demanderaient pas d’XP et resteraient désactivables. Les correctifs du pack
+s’appliqueraient dès leur installation. L’auteur a remis en question le principe
+de « débloquer la HD » ; ce choix visuel ne devient pas un palier acquis.
+
+Le nom précisé par l’auteur est **Sound Physics Remastered**. Il traite
+l’atténuation, la réverbération et l’absorption du son à travers les blocs.
+C’est une référence acoustique distincte des shaders.
+[Source du projet](https://github.com/henkelmax/sound-physics-remastered).
+
+## Compétences, unlocks, galactique et prestige
+
+**Cadrage retenu :** les compétences montent par paliers achetables en XP.
+Les unlocks sont des achats facultatifs, parfois uniques, parfois eux-mêmes
+répartis en paliers. Terminer ses compétences ouvre deux possibilités : acheter
+des facultés galactiques de fin de jeu, ou choisir un prestige. Il n’est pas
+nécessaire de prendre la première voie pour emprunter la seconde.
+
+| Ensemble | Rôle | Condition retenue |
+| --- | --- | --- |
+| Compétences | Faire progresser les capacités du personnage : vie, faim, vitesse de minage et capacité du vein mining, portée de construction et capacité du vein building, avec respiration et inventaire déjà prévus. | Acheter les paliers ; les effets vein se débloquent avec Mining et Build, sans achat séparé. Liste définitive, plafonds et prix à arrêter. |
+| Unlocks facultatifs | Ajouter des outils pratiques : indicateur alimentaire, minimap, carte et noms des entités. | Achat unique ou par paliers, avec d’éventuels prérequis de compétence ou de découverte à définir. |
+| Facultés galactiques | Ouvrir des possibilités endgame, dont le catalogue complet des builds. | **Toutes les compétences au maximum**, puis acquisition de chaque faculté ; les autres unlocks ne sont pas tous exigés. |
+| Prestige | Recommencer la progression personnelle et faire grandir sa faction. | **Toutes les compétences au maximum** ; ni tous les unlocks, ni les facultés galactiques ne sont requis. Récompense en charges personnelles à dépenser pour débloquer des slots dans sa faction, sans nouvelles capacités bonus. |
+
+Le stade galactique n’est plus conditionné au seul maximum de Build. Son
+accès ne donne pas gratuitement toutes les facultés et ne déclenche pas un
+prestige automatique. Le catalogue constitue la première faculté définie ;
+les autres restent à imaginer. Aucun coût distinct d’« entrée en mode galactique »
+n’est ajouté à ce stade.
+
+La vitesse demandée ici est celle du **minage**. Aucun arbre de vitesse de
+déplacement n’est ajouté par cette discussion ; le sprint initialement verrouillé
+reste à situer dans la progression. L’exemple de coûts doublés **1, 2, 4, 8, 16,
+32, 64 niveaux** reste une piste d’équilibrage, pas sept paliers identiques
+imposés à chaque compétence ou unlock.
+
+**Remise à zéro retenue : les unlocks achetés restent acquis, les compétences
+reviennent au départ et sont à remonter.** Il n’est pas nécessaire de racheter
+la minimap. Le vein mining et le vein building appartiennent aux compétences :
+leur disponibilité et leur capacité suivent donc le niveau actuel de Mining
+et de Build après le prestige. Au retour de Mining au niveau zéro, le vein
+mining redevient désactivé ; il revient en remontant Mining. La portée de pose
+et le remplissage suivent de même la progression actuelle de Build. Ils ne
+font pas partie des unlocks achetés séparément et conservés.
+
+Les facultés galactiques restent soumises au maximum de toutes les compétences.
+**Proposition complémentaire :** conserver celles déjà achetées, puis réactiver
+leur usage au nouveau maximum sans les racheter. Ce traitement, l’XP restante
+et celui des collections restent à préciser. La remise à zéro des compétences
+n’efface pas le monde ni ses déblocages collectifs, comme les portails des Cavernes.
+
+**Affichage retenu :** le compteur de prestiges suit le pseudo en chiffres
+romains, par exemple **Poupoutin VI** pour six prestiges. Le nom ou symbole de
+faction précède le pseudo, qui garde sa couleur personnelle choisie dans la
+palette réservée du serveur. Cet affichage n’ajoute pas de récompense mécanique.
+Voir les [règles de présentation](accueil-et-profils.md#couleur-personnelle-faction-et-prestige).
+
+**Capacité initiale retenue : trois membres par faction.** Les prestiges donnent
+des **charges personnelles**, rattachées à l’UUID du joueur. Celui-ci peut les
+dépenser dans sa faction pour débloquer des places supplémentaires. Ces crédits
+d’agrandissement sont distincts des charges collectives de **Galactium** ; ils
+ne servent pas à ouvrir des continents. La capacité d’une faction n’est pas
+calculée automatiquement en additionnant les prestiges de ses membres : le
+joueur choisit de dépenser ses charges.
+
+Le nombre de charges gagnées par prestige, le coût de chaque place et le devenir
+des places financées après le départ d’un membre restent à fixer. Aucun
+remboursement, retrait automatique de place ni conversion d’une charge en une
+place n’est décidé ici. Le suffixe romain continue d’indiquer les prestiges
+accomplis, indépendamment des charges déjà dépensées.
+
+### Vein mining et vein building : paliers des compétences
+
+**Direction retenue : ce sont des mécaniques centrales de Mining et de Build.**
+Elles se débloquent et augmentent en montant ces compétences, sans achat d’un
+unlock supplémentaire. Le joueur peut choisir de les utiliser ou de garder
+le geste bloc par bloc. La proposition précédente de deux arbres d’achats
+facultatifs séparés est remplacée par ce fonctionnement.
+
+**Recommandation de conception :** conserver ce lien direct. Un palier de
+Mining ou de Build apporte ainsi un changement de geste perceptible, sans
+demander un second achat pour une progression étroitement liée. Réserver les
+achats d’unlocks séparés aux outils de confort et d’information. Le déblocage
+de l’action groupée n’en impose pas l’utilisation à chaque clic.
+
+| Compétence | Repères de progression | Effet de l’action groupée |
+| --- | --- | --- |
+| Mining | Niveau 0 : vein mining désactivé. Premier repère donné : dès le niveau 1, jusqu’à **4 blocs au total**, bloc visé compris. Les niveaux suivants augmentent ce nombre ; **64 blocs** est un exemple de groupe avancé, sans niveau ni plafond définitif fixé. | Compter les blocs sélectionnés, puis commencer leur minage en même temps. |
+| Build | La portée et la capacité de remplissage évoluent avec la compétence. Niveau d’activation et nombres de blocs par palier restent à définir ; les chiffres de Mining ne sont pas automatiquement recopiés. | Remplir un trou ou une surface sur **un seul plan**, avec une limite de blocs posés. |
+
+Le **vein mining commence sur tout le groupe sélectionné simultanément**.
+L’action doit donner à percevoir que tous ces blocs sont en cours de casse,
+plutôt qu’un premier bloc cassé suivi de la disparition instantanée des autres.
+Une représentation des fissures sur les blocs est une proposition visuelle à
+éprouver. L’outil choisi, les blocs concernés, le nombre à casser et la vitesse
+de Mining déterminent la durée de travail. À conditions égales, un groupe plus
+grand demande davantage de temps : casser 64 blocs ne coûte pas le temps d’un
+seul bloc. Le gain recherché vient aussi des petites manipulations évitées entre
+viser, miner, casser et récupérer chaque bloc.
+
+La formule de durée reste à équilibrer : aucune somme exacte des durées vanilla,
+aucun multiplicateur ni pourcentage d’accélération n’est arrêté. Commencer le
+minage simultanément ne fixe pas encore si tous les blocs terminent leur casse
+ensemble ou selon des progressions individuelles. L’admissibilité des blocs,
+les outils et enchantements, l’usure, le moment des drops et le traitement des
+interruptions restent à spécifier, notamment si l’outil casse ou change pendant
+l’action. L’ancienne intention de veine contiguë ou de plan orienté est conservée ;
+le geste précis de sélection reste à concevoir.
+Le journal des transformations comptera les blocs effectivement cassés ou
+posés, et les entrées et sorties réelles, sans compter la sélection initiale
+comme une opération déjà accomplie.
+
+Le **vein building remplit une surface plane**, y compris un trou au milieu
+d’une surface existante. Il ne remplit pas un volume en trois dimensions.
+Les cases à compléter, le plan choisi et la limite du palier doivent être
+lisibles avant la pose. Les blocs viennent de l’inventaire et les positions
+restent dans la portée acquise de Build, sans remplacer implicitement les blocs
+occupés. Orientation horizontale ou verticale, sélection du contour, délai de
+pose et cas où les matériaux manquent restent à éprouver. Le temps de casse
+groupée du vein mining n’impose pas la même animation au vein building.
+
+Les limites de groupe et de portée servent des fonctions différentes ; agrandir
+la surface traitée n’allonge pas implicitement la portée. Les règles de récolte,
+de protection et d’aventure continuent de s’appliquer. Aucun coût d’XP par action
+n’est décidé en plus de l’achat des paliers de compétence.
+
+### Unlocks uniques et informations par paliers
+
+L’indicateur alimentaire, la minimap et la carte du monde font partie des outils
+facultatifs souhaités. Proposition : acheter d’abord une lecture simple, puis
+des informations supplémentaires lorsque cela apporte un usage distinct, par
+exemple les waypoints. Carte du monde et minimap ne dévoilent pas automatiquement
+les territoires inexplorés. Leur découpage et les intégrations exactes restent
+à choisir ; aucun achat d’affichage ne modifie la faim réelle ou le terrain.
+
+**L’affichage des noms d’entités est un unlock unique retenu.** Une configuration
+permettra d’ajouter des listes de noms et des catégories personnalisées, en
+associant chaque catégorie à un ou plusieurs identifiants de mobs. Les familles
+humoristiques prévues, comme les pseudos de zombies et les noms galactiques des
+Endermen, restent des listes de départ. Priorité entre catégories qui se recoupent,
+attribution stable d’un nom et comportement lors d’une modification de configuration
+restent à définir. Débloquer l’affichage ne remplace pas les noms donnés aux
+entités par les joueurs.
+
+## Capacités à relier aux découvertes
+
+La sélection des fonctions est retenue ; leurs paliers, coûts et conditions
+exactes restent à dessiner. Ce tableau ne prescrit pas une campagne linéaire.
+
+| Domaine | Capacité envisagée | Distinction à conserver |
+| --- | --- | --- |
+| Recettes — JEI | Révéler les recettes par familles et advancements Minecraft/Sanctuary. | Affichage d’une recette, fabrication autorisée et achat au Black Market sont trois règles différentes. |
+| Cuisine — It’s Alive ! | Débloquer des pages culinaires et compléter le livre de recettes de Kai ; conserver les pages secrètes des sorcières. | Page trouvée, recette connue, affichage JEI, ingrédients disponibles et autorisation de préparation restent à articuler. Le mod culinaire garde son autonomie. |
+| Orientation — Xaero’s Minimap et carte à intégrer | Débloquer la minimap, la carte du monde et des fonctions de waypoints, selon des paliers à définir. | Un repère n’autorise pas une téléportation et ne révèle pas automatiquement les trésors ou salles cachées. Le choix d’outil pour la carte reste ouvert. |
+| Voyage — waystones | Découvrir un ascenseur dans une île générée, reliant par exemple la surface à un laboratoire. Verticalement : ascenseur ; horizontalement : téléportation précise, coûteuse en XP. | L’usage concret enseigne le transport ; aucun palier abstrait supplémentaire n’est décidé. La minimap ne fournit pas cette capacité. |
+| Alchimie et enchantement | Relier la connaissance des procédés et les usages aux étapes de jeu. | Préciser quels procédés sont concernés avant de verrouiller des actions vanilla ou de choisir un mod. |
+| Architecture — Architext / Litematica | Ouvrir le bouton de bibliothèque dans les pouvoirs, puis acquérir des plans, dont des aqueducs, par le combat ou l’obtention de blocs associés. | Une combinaison de matériaux découverts peut proposer une architecture ; connaître le plan ne fournit ni matériaux ni pose gratuite. |
+| Nourriture — AppleSkin ou HUD Sanctuary | Débloquer un indicateur rendant lisibles faim, saturation et effet d’un aliment, avec l’habillage Sanctuary. | L’unlock facultatif est retenu ; le choix d’intégration et le détail des informations par palier restent ouverts. Les valeurs suivent les capacités réelles du joueur. |
+| Équipement | Afficher ou masquer l’état de l’armure et des outils, notamment leur durabilité restante. | Un réglage de visibilité ne répare pas l’équipement ; son éventuel palier n’est pas encore choisi. |
+| Cosmétique | Équiper une création d’artiste 3D dans un slot au-dessus de la cape, après déblocage ou obtention dans un loot cosmétique. | Apparence uniquement : aucun pouvoir, bonus de statistiques ou slot de stockage accordé par cet objet. |
+| Familiers | Équiper un spawn egg pour obtenir un effet passif et un effet actif déclenché par une touche. | Pouvoir d’un œuf équipé, apparition d’une entité et portage d’un animal sont des systèmes différents. |
+
+La progression personnelle reste distincte des acquis communs. Le donjon majeur
+stabilise les portails des Cavernes pour tout le serveur, y compris les futurs
+arrivants. Une bibliothèque de plans, un waypoint ou une information nutritionnelle
+ne deviennent pas collectifs par défaut : leur portée sera écrite dans chaque
+fiche de capacité. L’inventaire garde sa progression prévue et les prestiges
+leurs charges personnelles à dépenser dans les slots de faction.
+
+**Nature’s Compass et la recherche automatique de biomes sont retirés de la
+sélection actuelle.** L’auteur privilégie l’exploration d’îles aux climats et
+biomes définis. Cela conserve la minimap et les waypoints, sans les assimiler
+à une recherche de ressources ou de destinations cachées.
+
+Les waystones d’ascenseur permettent d’apprendre le geste dans une installation :
+sauter pour monter, se baisser pour descendre, sans devoir connaître au préalable
+l’étage adjacent. Les liaisons horizontales restent précises, dans une même
+dimension et vers une waystone connue, avec un coût d’XP croissant selon la
+distance. Aucune gratuité ni nouveau tarif vertical n’est fixé ici.
+
+## Un contrat de déblocage commun
+
+Proposition : chaque capacité relie une condition de découverte ou un advancement,
+un éventuel achat en XP et une fonction disponible. Un achat n’est pas imposé
+à toutes les récompenses. Pour chaque fiche, préciser :
+
+- ce qui est obtenu et comment le joueur le découvre ;
+- si l’acquis est personnel ou commun au serveur ;
+- ce qui persiste et ce que le joueur peut ensuite activer ou masquer ;
+- ce que fournissent Sanctuary et l’intégration communautaire choisie.
+
+Le serveur conserve les acquis et contrôle les actions qui engagent le monde :
+achats, déplacements, effets actifs, transfert d’objets et éventuelle aide de pose.
+Le client reçoit les capacités pour présenter les bons boutons et données.
+Masquer JEI ou une minimap dans le pack ne prouve pas qu’un autre client ne puisse
+afficher une information déjà reçue. Le contrat doit porter sur les possibilités
+du jeu, sans confondre bouton caché et autorisation côté serveur.
+
+Le partage de savoir reste possible : un joueur peut expliquer une recette ou
+montrer une construction à un autre. Un plan débloqué ouvre l’accès à un outil
+et à sa fiche ; il n’interdit pas de reproduire manuellement une forme observée.
+
+Le suivi demandé s’étend à un [journal des transformations](journal-et-progression-du-monde.md) :
+entrées, sorties, procédés et suites d’actions datées. Il alimentera propositions
+de plans, Backrooms, Indoors et donjons en lien avec la progression réelle.
+Les compteurs journaliers actuels ne fournissent pas encore cette histoire causale.
+
+## Pages culinaires et lieux encore inexplorés
+
+**Direction retenue :** la cuisine d’**It’s Alive !** participe à la progression
+par des pages à débloquer. La vision prévoit le livre de Kai à reconstituer
+et des pages secrètes gardées par les sorcières, notamment pour des techniques
+de transformation. Le déblocage des pages s’articule aux recettes consultables
+et aux aliments issus de cultures localisées ; connaître une recette ne fournit
+pas ses ingrédients ni son équipement de cuisine.
+
+**Kai est le cuisinier fixe de Sanctuary.** Le tirage de conception du
+11 septembre 2026 a choisi Kai parmi Ari, Efe, Kai, Makena, Noor, Sunny et Zuri.
+L’auteur a retenu un nom unique pour le lore, sans nouveau tirage par monde.
+Mojang a ajouté ces **sept** personnages après Steve et Alex ; le rôle culinaire
+est une création Sanctuary, pas une biographie officielle. Le livre change
+d’auteur ; la présence de Kai comme visiteur est désormais souhaitée et reste
+à implémenter dans le système de visites décrit ci-dessous.
+[Présentation officielle](https://www.minecraft.net/en-us/article/introducing-new-default-skins).
+
+Un parcours proposé serait : trouver une page, apprendre le procédé, obtenir
+les ingrédients dans les biomes concernés, construire les équipements et produire.
+Consommation de la page à la lecture, partage entre joueurs, doublons, portée
+des acquis et verrouillage éventuel de la préparation restent à définir. Ce
+contrat doit appartenir à l’intégration Sanctuary, sans imposer cette progression
+à une partie qui utilise It’s Alive ! seul.
+
+La révision culinaire demande une **préparation attentive et une récupération
+au bon moment** : le joueur apprend les temps utiles et observe quand le plat
+est prêt, notamment dans un chaudron ou un appareil de cuisine. La qualité du
+résultat doit en dépendre. Fenêtre de réussite, indices visuels ou sonores,
+sous-cuisson, surcuisson et tolérances restent à concevoir par recette. Le temps
+réel du calendrier ne fixe pas automatiquement des durées de cuisson de plusieurs heures.
+
+Une pastille ou une étoile sur l’item pourrait indiquer cette qualité. L’auteur
+envisage aussi des variantes d’items ; la proposition technique est de conserver
+une qualité sur l’objet, avec affichage adapté, pour éviter de multiplier les
+identifiants de chaque plat. Ce choix et le format de sauvegarde ne sont pas
+implémentés. Qualité culinaire, rareté d’équipement et couleur des lootboxes sont
+des informations distinctes. Effets de la qualité, empilement, conservation et
+comportement après déchargement ou arrêt restent à spécifier.
+
+Kai pourrait organiser des **compétitions de cuisine** et juger les plats selon
+des critères de préparation à définir. Les règles du concours indiquent ce qui
+est évalué et les récompenses possibles. Le lien entre alimentation, fabrication et qualité devra
+être visible dans le journal des transformations.
+
+L’auteur souhaite des lieux **présents dans le monde initial mais encore
+inexplorés**. La direction actuelle distingue :
+
+- un ou deux îlots suspendus envisagés, riches, avec un coffre à déterrer ; une
+  cascade peut permettre d’y monter, mais elle n’est pas obligatoire et peut
+  s’écouler dans le vide indépendamment de ce qui se trouve dessous ;
+- des bateaux marchands répartis en périphérie de Sanctuary, première voie pour
+  obtenir des villageois ; le navire amarré proposé précédemment est abandonné ;
+- des montgolfières détenant des richesses, avec accès et contenu à définir.
+
+Les temples sont retirés de la génération de base. Ils restent une piste future
+de structures autour de Sanctuary, avec une inspiration du Nether à préciser,
+sans implémentation demandée maintenant. Nombre exact, visibilité, accès et
+répartition des autres sites doivent préserver le départ naturel. Les marchands
+ne fixent pas encore un système de vente de villageois ni un véhicule pilotable.
+Pages, plans et programmes peuvent accompagner les lieux selon leur usage ;
+leurs tables de butin restent à concevoir. Voir la [conception des lieux](structures-conception.md).
+
+## Architecture : une collection de savoir-faire
+
+**Direction demandée :** reprendre l’idée d’Architext et constituer une bibliothèque
+de schematics crédités, consultable dans le **menu Build avec des prévisualisations**.
+**Minecraft Schematics est la source retenue pour l’instant.** Le menu permet de
+parcourir la bibliothèque personnelle de plans acquis ; l’accès au catalogue
+complet du site constitue un stade ultérieur, distinct de ce premier bouton.
+Les victoires sur des monstres peuvent accorder des plans. L’obtention de blocs
+qui vont ensemble peut également proposer une architecture : le catalogue relie
+les découvertes de matériaux à des usages possibles. Les associations entre
+rencontres, matériaux et architectures, répétitions, doublons et partage restent à définir.
+L’exploration des installations anciennes peut aussi montrer l’utilité d’un plan,
+en continuité avec les secrets de Sanctuary Island.
+
+Proposition : utiliser les possessions attestées dans la progression pour
+reconnaître une famille de matériaux et proposer un plan une fois. La possession
+simultanée de tous les blocs, le seuil nécessaire et le passage de proposition
+à déblocage restent à choisir. Le simple fait d’apercevoir un bloc ne remplace
+pas automatiquement son obtention ; le stock présent et la connaissance acquise
+restent deux mesures distinctes.
+
+**Faculté galactique de Build :** après avoir atteint le maximum de **toutes
+les compétences du personnage**, un achat important en XP ouvre le catalogue
+des créations du site dans le menu. **64 niveaux** est le coût proposé par
+l’auteur, à éprouver. Il s’agit
+d’un accès élargi aux plans des autres créateurs, distinct des plans gagnés au
+fil de la progression. Cela ne débloque pas automatiquement toutes les autres
+capacités et ne transforme pas les constructions en blocs gratuits.
+
+Les prévisualisations doivent aider à choisir une création : vue du build,
+auteur, dimensions, matériaux et format. Leur technique de rendu reste à choisir.
+Le catalogue complet est un objectif de consultation ; son index, sa mise à jour
+et la récupération des fichiers restent à concevoir avec le site. Une fiche
+peut être visible sans que son format ou sa disponibilité permette déjà son
+chargement dans Sanctuary. Aucune aspiration du site n’est lancée dans ce chantier.
+
+Le premier usage proposé est un aperçu de construction, une liste de matériaux,
+une orientation et une aide à la pose en survie. Débloquer un aqueduc ne le pose
+pas instantanément dans le monde et ne livre pas ses matériaux. Une construction
+automatique demanderait une capacité distincte ; elle n’est pas décidée ici.
+
+Chaque entrée doit garder le titre, l’auteur de la construction, la page source,
+la version et le format du fichier, les matériaux, les dimensions et le déblocage
+Sanctuary associé. Si une autre personne a réalisé l’adaptation, son crédit
+s’ajoute à celui de l’auteur. Les plans de progression forment une collection
+sélectionnée et vérifiée ; le stade galactique élargit ensuite la consultation
+au catalogue du site. Une récompense n’entraîne pas un téléchargement aléatoire.
+
+Les conditions de réutilisation et de redistribution sont vérifiées pour chaque
+plan retenu ; un téléchargement public et une mention d’auteur ne suffisent pas
+à établir ces conditions. Pour l’instant, la recherche de catalogue n’importe
+aucun schematic dans le pack. Le format et les blocs d’un plan doivent également
+être compatibles avec le jeu réellement distribué.
+
+### Catalogues repérés
+
+La recherche avait repéré deux sources ; **Minecraft Schematics est désormais
+retenu**, Abfielder reste une référence écartée de cette première intégration.
+Aucune bibliothèque n’est déjà importée.
+
+| Catalogue | Exemple et limites |
+| --- | --- |
+| [Minecraft Schematics](https://www.minecraft-schematics.com/) — retenu | Catalogue de schémas et de mondes. Exemple : [Bakery Market Stall, EcoSMP_Official](https://www.minecraft-schematics.com/schematic/31569/). Le format du fichier et le rôle du contributeur sont à vérifier : publier une fiche ne prouve pas que l’on est l’auteur original. |
+| [Abfielder](https://abfielder.com/Products/BrowseProducts.php) — référence non retenue | Autre source repérée pendant la recherche ; pas d’intégration prévue à ce stade. |
+
+Les [conditions de Minecraft Schematics](https://www.minecraft-schematics.com/terms/)
+et celles d’[Abfielder](https://www.abfielder.com/termsAndConditions) ne donnent
+pas une autorisation globale de reprendre toutes les créations dans le pack.
+Le choix d’un plan pour la bibliothèque ne l’autorise pas non plus automatiquement
+comme structure générée dans le monde.
+
+**Architext : référence historique non retrouvée dans la recherche actuelle.**
+Les sources, documents, noms de fichiers et chemins de l’historique Git 26.2 ont
+été consultés, avec une recherche bornée également sous le dossier Sanctuary.
+La reprise est donc celle de l’intention exprimée par l’auteur ; aucun ancien
+comportement de placement ou de progression n’est attesté ici. L’auteur prévoit
+de retrouver le module ; son étude sera ajoutée lorsqu’il sera disponible.
+
+## Inventaire, équipement et familiers
+
+**Décision demandée : réimplémenter la manipulation d’inventaire dans Sanctuary.**
+Glisser, répartir et transférer les stacks devront suivre les emplacements ouverts
+de l’inventaire incrémental. Ne pas intégrer Mouse Tweaks comme base imposée ni
+confier cette logique à des profils de mods communautaires. Les préférences
+d’affichage et de commandes sont à distinguer du nombre de slots autorisés.
+
+La direction ajoute des emplacements d’équipement pour cape et familier, avec
+le slot de spawn egg près de la main secondaire, au-dessus dans la disposition
+évoquée. Elle ne fixe pas encore plusieurs familiers simultanés ni des rangées
+de stockage supplémentaires accordées par une cape. La cape conserve pour
+l’instant son rôle d’apparence ; ses éventuels effets restent à choisir.
+
+Un **slot cosmétique distinct au-dessus de la cape** est désormais demandé.
+Il reçoit des créations 3D confiées à un artiste et débloquées en jeu, notamment
+par des loots cosmétiques. Ce slot et son équipement sont purement visuels.
+Il ne remplace ni le familier ni la cape et n’ajoute aucun pouvoir. La coexistence
+des modèles avec l’armure et la cape, les emplacements visuels et la collection
+restent à dessiner.
+
+La cible est un **passif et un actif pour chaque spawn egg du catalogue Sanctuary**.
+La touche d’activation sera configurable. Effet, durée, coût, délai de réutilisation,
+cible et interactions doivent être décrits ensemble. Les règles d’acquisition,
+de retrait, de mort du joueur et de changement d’œuf restent à définir pour la
+nouvelle implémentation ; les comportements de l’ancien mod ne sont pas repris
+automatiquement. **La priorité de réécriture est leur présence dans le monde** :
+collisions avec le décor, déplacements capables de monter et descendre les
+obstacles, sans collision gênant les joueurs. Les anciens usages de pouvoirs
+restent des références à réévaluer.
+
+Un familier ne donne **aucun loot**. L’auteur évoque des familiers tuables, puis
+laisse cette possibilité en suspens : leur mortalité n’est pas décidée. Défaite,
+retour éventuel et rapport aux pouvoirs de l’œuf restent à concevoir ensemble.
+
+Leur collection doit aussi avoir des raretés : commun, peu commun, rare,
+extraordinaire, puis légendaire ou galactique selon la hiérarchie à préciser.
+**L’Ender Dragon et le Wither sont des familiers galactiques** dans la direction
+retenue. La place relative de légendaire et galactique reste ouverte ; ce
+classement ne décide pas de la taille physique ni de la puissance de leurs effets.
+
+### Lecture ciblée des anciens familiers
+
+Le dépôt voisin **26.2** a été consulté sans exécution ni modification. Sous
+`sanctuary/src/main/java/fr/koka99cab/sanctuary26/sanctuary/` :
+
+| Référence locale | Comportement observé et enseignement |
+| --- | --- |
+| `mixin/client/InventoryScreenMixin.java` et `gameplay/SanctuaryCompanionEggSlot.java` | Slot d’œuf unique au-dessus de la main secondaire, cape séparée ; le slot accepte un spawn egg, quantité un. Cette disposition fournit une référence à redessiner avec le nouvel inventaire. |
+| `gameplay/SanctuaryCompanionPowers.java` | Le serveur relit l’œuf et valide le déblocage et le délai avant l’actif. Les passifs incluent chauve-souris : vision nocturne/chute lente, avec sonar actif ; axolotl : respiration aquatique, avec soin actif. Ces effets historiques ne fixent pas le nouvel équilibrage. |
+| `progression/SanctuaryPlayerProgress.java` et `gameplay/SanctuaryInventoryCapacity.java` | Œuf et cape enregistrés par joueur ; objets perdus à la mort sans keepInventory. Ce contrat historique n’arrête pas celui de la future réécriture. |
+| `gameplay/SanctuaryCompanions.java` et `gameplay/SanctuaryCompanionPowers.java` | Le familier visible est une copie temporaire distincte des pouvoirs de l’œuf. Sa mort ne coupe pas automatiquement les passifs ; l’état vaincu et les délais d’actifs ne sont pas persistés. La nouvelle version doit définir leur devenir à la mort et à la reconnexion. |
+| `gameplay/SanctuaryCapeService.java` | Cape cosmétique et synchronisée entre joueurs ; aucune augmentation de capacité retrouvée dans ce système. |
+
+Les œufs acceptés par le slot dépassent les identifiants dotés d’un pouvoir
+explicite : tous les œufs n’ont donc pas effectivement un couple actif/passif
+dans l’ancien code. La nouvelle version doit rendre lisible la prise en charge
+de chaque œuf et éviter les objets équipables sans effet défini. Le familier
+visible neutralisé par l’ancien système ne doit pas servir tel quel au portage
+d’un hostile qui reste dangereux.
+
+## Porter un animal sans le neutraliser
+
+Le geste retenu est **sneak + clic droit**, pour porter un animal sur la tête,
+avec un seul mob porté à la fois selon la vision existante. La nouvelle direction
+permet aussi de porter des mobs hostiles, **qui restent capables d’attaquer**.
+Porter ne doit donc pas les transformer automatiquement en animaux apprivoisés
+ou supprimer leur danger. Tailles extrêmes, boss, conflits d’interaction et
+conditions de dépose restent à concevoir.
+
+Carry On est une référence d’interaction, pas le contrat déjà adopté. Sa page
+décrit le transport de blocs à inventaire et de mobs ; le portage d’hostiles en
+survie est désactivé par défaut et configurable. Elle ne suffit pas à établir
+le comportement de combat demandé pendant le portage.
+[Page du projet Carry On](https://www.curseforge.com/minecraft/mc-mods/carry-on).
+La capacité de déplacer tous les coffres, spawners ou machines n’est pas déduite
+de cette référence. Elle aurait des conséquences propres pour les boutiques et
+les donjons, à décider avant intégration.
+
+### Bateau-poule et extraction aérienne
+
+**Montage retenu :** placer un villageois ou un animal dans un bateau, relier
+ce bateau par une corde au bateau-poule, puis le soulever et le transporter.
+Le bateau occupé sert de nacelle ; le bateau-poule fournit le vol. Cette
+combinaison donne un usage aux villageois des navires marchands et aux animaux
+des laboratoires d’expansion, notamment les Mooblooms.
+
+La traction doit rester une interaction construite par les joueurs. Nombre de
+bateaux transportés, charge, vitesse, longueur de corde, dépose, rupture et
+comportement après déchargement restent à tester. Aucun objet ou passager n’est
+dupliqué par le transfert ; il s’agit du déplacement des occupants existants.
+Le montage ne décide pas des autres capacités de portage ou de téléportation.
+
+### Booat
+
+**Booat est le nom en jeu ; « bi-poule » reste le surnom entre nous.** Ce grand
+bateau où l’on peut être à quatre fait partie des **mécaniques centrales du mod**.
+**Capacité confirmée : quatre joueurs sur l’eau, puis deux joueurs et deux
+poules en vol.** Les poules occupent deux des quatre places et fournissent le
+vol ; le pilote compte parmi les deux joueurs transportés.
+
+La recette demandée combine **quatre bateaux** et le véhicule doit exister dans
+toutes les variantes de bois. Disposition de la recette, mélange éventuel des
+essences et traitement des variantes de radeaux restent à préciser. Le Booat
+s’ajoute au bateau-poule simple et au biplan déjà envisagé. La traction par corde
+est une articulation à tester, avec charge et comportement en cas de perte
+d’une poule à définir ; aucune recette ni entité n’est implémentée ici.
+
+## Visiteurs et pratiques des anciens
+
+**Direction actuelle : des personnages visitent Sanctuary pendant une journée**,
+se promènent sur l’île et ouvrent un menu de discussion au clic droit. Leur
+activité peut comprendre une quête liée à leur domaine, une compétition ou des
+offres spécialisées. Le modèle évoqué est celui des visiteurs d’Animal Crossing,
+avec par exemple un marchand de tapis ou de décoration.
+
+L’invocation proposée auparavant reste en réserve : la visite est le fonctionnement
+à concevoir en premier, sans ajouter deux systèmes de venue simultanément.
+La nature de cette présence demeure mystérieuse ; un ancien visible n’est pas
+la confirmation d’une résurrection ni l’explication de la disparition des neuf.
+Les rencontres n’exigent pas une nouvelle ruine ou une maison permanente pour
+chaque personnage et conservent le départ naturel.
+
+| Personnage | Domaine | Statut |
+| --- | --- | --- |
+| Kai | Cuisine, pages, préparation et concours avec jugement des plats. | Cuisinier fixe retenu ; détails des concours à définir. |
+| Alex | Nature et biomes. | Rôle retenu ; ne réintroduit pas Nature’s Compass ni une recherche automatique de biomes. |
+| Ari | Architecture, quêtes de construction, plans et accès au Build galactique. | Rôle retenu ; activités et rencontres à concevoir. |
+| Makena | Redstone, ordinateurs et automatismes. | Rôle retenu ; ateliers et programmes de Régie à concevoir. |
+| Zuri | Étoiles, constellations, temps réel et calendrier. | Rôle retenu ; activités de l’observatoire à concevoir. |
+| Steve | Personnage absent. | Absence retenue ; il ne devient pas un visiteur ordinaire. |
+
+L’auteur souhaite des **flashs d’Herobrine**. Forme, fréquence et déclenchement
+restent ouverts ; ces apparitions ne prouvent pas qu’Herobrine est Steve et ne
+définissent pas un boss. Les rôles d’Efe, Noor et Sunny et l’identité d’un marchand
+de décoration restent à préciser ; ils ne reçoivent pas automatiquement une boutique.
+
+Ari pourrait donner des quêtes de bâtiments et incarner l’accès galactique au
+catalogue. **Toutes les compétences au maximum et coût proposé de 64 niveaux**
+sont les conditions prévues ; la rencontre ne les annule pas. Les ordinateurs
+restent étudiables dans de grandes salles de farming **sans panneaux explicatifs** :
+le visiteur peut proposer une activité sans remplacer cette découverte par un cours.
+
+La journée de présence se rattache au calendrier réel du serveur. Fréquence des
+visites, heures d’arrivée/départ ou durée de vingt-quatre heures, nombre simultané
+et devenir d’une quête après le départ restent à décider. Les conversations,
+offres et récompenses demandent leurs propres règles ; aucun achat ni dialogue
+n’est ajouté par ce document. Les échanges commerciaux doivent s’articuler à
+l’économie en rubis et à la progression, sans offrir à chaque visite tous les
+biens recherchés par les joueurs.
+
+## Raids collectifs instanciés
+
+**Direction retenue : un raid pour tout le serveur par semaine.** Cette limite
+est commune ; elle n’accorde pas un raid supplémentaire à chaque joueur.
+**Dix joueurs doivent se réunir à un portail secret situé sur une île obtenue
+par génération d’expansion.**
+Le raid difficile est conçu pour cet effectif ; il ne devient pas plus facile
+parce que seulement deux, trois ou quatre joueurs se présentent. Ce portail
+constitue un lieu distinct du laboratoire, donjon d’accès aux Cavernes
+qui reste sur Sanctuary Island. Les conditions de découverte et d’activation
+du portail, ainsi que la fréquence ou la garantie de génération d’une île
+d’accès aux raids, restent à définir. Aucun portail n’est exigé sur chaque
+expansion. Le découvrir n’accorde pas de raid supplémentaire au-delà du quota
+hebdomadaire du serveur. La gestion d’une déconnexion reste également à préciser.
+
+Le portail conduit le groupe dans un **donjon généré procéduralement**, au sein
+d’une instance préparée pour l’épreuve. Les **Trial Chambers** servent
+d’inspiration pour la conception de ce lieu, avec une palette propre encore à
+choisir ; cela ne fixe ni une reprise de leur code ni leurs mécaniques exactes.
+Il se joue **en mode aventure, avec des blocs incassables et sans sortie libre
+pendant l’épreuve**. Ce contrat demande de traiter aussi les effets des explosions,
+des objets et des téléportations Sanctuary ; le seul nom du mode de jeu ne
+constitue pas sa vérification. Les parcours, objectifs et mécanismes de résolution
+doivent rester praticables dans ces conditions. Les règles d’abandon et de retour
+sûr restent à concevoir : ce choix ne condamne pas un joueur à rester bloqué dans
+l’instance après un incident.
+
+La progression sert à préparer les nouveaux donjons : rencontres, organisation,
+contraintes et objectifs évoluent, au-delà d’une augmentation des statistiques.
+La carte, son effectif de référence, ses règles et sa difficulté sont fixés au
+lancement ; une reconnexion reprend la même tentative. La fin de l’épreuve doit
+restaurer les conditions habituelles des joueurs. Mort, échec collectif, abandon,
+reprise après incident et retour sûr restent à définir avant implémentation.
+
+Les cartes créées par les joueurs restent une **possibilité future**. Il faudrait
+distinguer leur atelier de construction et la version admise dans le circuit
+récompensé. Le butin de raid appartient aux règles du serveur ; dessiner un coffre
+ou déclarer une difficulté ne donne pas automatiquement droit à son contenu.
+Le mode de sélection et de validation de telles cartes reste à concevoir,
+sans restreindre ici la création libre.
+
+Le raid fournit un **butin commun matériel à ramasser, dimensionné pour dix
+joueurs**, pouvant comprendre des équipements enchantés différents et du titane.
+Les participants le répartissent librement entre eux ; le serveur ne crée pas
+d’attribution personnelle ni de partage automatique à parts égales. Les quantités,
+la qualité, les conditions d’apparition et le devenir du butin lors d’une
+déconnexion ou d’un incident restent à définir. Une réentrée dans la même instance
+ne crée ni nouvelle tentative ni nouvelle réserve de récompenses.
+
+Le moment qui consomme le raid hebdomadaire reste ouvert : entrée effective,
+lancement ou autre étape confirmée. Il faut aussi choisir le jour de remise à
+disposition, la semaine calendaire ou le délai glissant et le traitement d’un
+incident. Le calendrier du jeu fournit le cadre de temps réel ; aucun jour de
+raid n’est fixé par la loterie du dimanche. Ces raids restent distincts du
+donjon initial qui ouvre collectivement les Cavernes, des tunnels explorables
+et des spawners exploitables dans les donjons ordinaires.
+
+## Familles de butin et rareté des équipements
+
+La famille d’un loot décrit son contenu ; la couleur décrit la rareté d’un
+équipement. Un cosmétique rare reste sans pouvoir. La nouvelle sélection retient :
+
+| Famille | Contenu envisagé |
+| --- | --- |
+| Général | Objets ordinaires ou intéressants et équipements de plusieurs raretés ; cas extrêmement rares de légendaire. |
+| Familiers / spawn eggs | Œufs de familiers. L’auteur dit « loots spawner » ; la correspondance avec les spawn eggs de la vision est l’hypothèse actuelle, sans attribuer de blocs spawners. |
+| Capes | Éléments de la collection de capes. |
+| Cosmétiques | Créations visuelles équipables dans le nouveau slot, sans bonus de jeu. |
+
+Les couleurs évoquées sont blanc, vert, bleu, violet et jaune. Proposition de
+classement à valider : **commun, peu commun, rare, épique, légendaire** dans cet
+ordre. Matériau, enchantements, durabilité et rareté ne sont pas une même donnée.
+Les légendaires sont très puissants mais peuvent rester cassables.
+
+**Anomaly** est le niveau ultime : équipement en titane, doté d’enchantements
+exceptionnels, incassable, avec un nom écrit en galactique. Cette direction
+prolonge les équipements infrabricables de la vision ; elle ne rend pas toutes
+les machines fabriquées en titane incassables ou Anomaly. Les bornes des effets
+et les combinaisons d’enchantements restent à équilibrer.
+
+L’ancienne lootbox Anomaly et sa place dans la loterie sont conservées comme
+pistes à articuler à cette nouvelle classification. Le caractère ultime de
+l’équipement ne décide pas seul de son contenant ni de toutes ses sources.
+Le butin général peut exceptionnellement donner du légendaire ; sa probabilité
+et l’éventuelle présence d’Anomalies ne sont pas fixées. Le butin commun d’un raid
+ne garantit ni une Anomaly au groupe ni un équipement de ce niveau à chaque
+participant.
+
+Les probabilités doivent être évaluées sur le volume réel d’ouvertures issu des
+farms : le nombre moyen de résultats rares dépend du nombre d’essais autant que
+de la chance par essai. Les farms ordinaires restent possibles ; la rareté des
+récompenses du raid s’appuie aussi sur son rythme collectif hebdomadaire.
+Tables, pondérations, doublons, conditions de gains et circulation des objets
+restent à spécifier. Aucun taux chiffré n’est adopté ici.
+
+## Références et intégration du pack
+
+Sources consultées le **11 septembre 2026**. Elles décrivent les projets ; elles
+ne valident pas à elles seules un ensemble compatible avec 26.3-pre-2.
+
+| Projet | Fait vérifié et conséquence pour Sanctuary |
+| --- | --- |
+| [JEI — API de recettes](https://github.com/mezz/JustEnoughItems/blob/26.2/CommonApi/src/main/java/mezz/jei/api/recipe/IRecipeManager.java) | Expose le masquage et le réaffichage des recettes pour la progression. Un adaptateur pourrait refléter les acquis Sanctuary ; cette API d’affichage ne bloque pas la fabrication. La référence lue est une branche 26.2, pas une preuve de compatibilité 26.3. |
+| [Xaero’s Minimap](https://www.curseforge.com/minecraft/mc-mods/xaeros-minimap) | Décrit des réglages serveur, une exigence d’objet et des effets désactivant minimap, waypoints, radar d’entités ou cartes de cavernes. Ces points de raccord sont à évaluer pour les paliers. La téléportation par waypoint reste soumise aux permissions de commande. |
+| [Litematica](https://modrinth.com/mod/litematica) et [MaLiLib](https://github.com/maruohon/malilib) | Plans fantômes, listes de matériaux et vérification de construction, avec bibliothèque d’interface/configuration. Le catalogue Sanctuary serait un ajout ; l’aide de pose doit être essayée avec le serveur, notamment son [protocole Easy Place](https://github.com/maruohon/litematica/wiki/Easy-Place). |
+| [AppleSkin](https://github.com/squeek502/AppleSkin) | Affiche faim, saturation, épuisement et effet potentiel des aliments. Évaluer son intégration avec le HUD à capacité variable et les textures Sanctuary, ou développer ce rendu nativement. Ne pas transposer l’API Forge à Fabric sans vérification. |
+| [Nature’s Compass](https://github.com/MattCzyr/NaturesCompass) — référence retirée | Le projet permet une recherche de biomes ; cette fonction n’est plus retenue pour la progression actuelle de Sanctuary. |
+| [Carry On](https://www.curseforge.com/minecraft/mc-mods/carry-on) | Référence pour le geste de transport ; la règle des hostiles et les interactions Sanctuary nécessitent leur propre validation. |
+| [Sound Physics Remastered](https://github.com/henkelmax/sound-physics-remastered) | Acoustique spatiale ; préférence optionnelle proposée, avec vérification de son effet sur les sons utiles au jeu. |
+| [NetherPortalFix](https://github.com/TwelveIterations/NetherPortalFix) | Corrige les destinations de retour des portails du Nether en multijoueur. Candidat pour le pack, sans déblocage de progression ; ne garantit pas tous les futurs portails Galactium, Indoors ou Cavernes. |
+
+Les catalogues Modrinth de [JEI](https://modrinth.com/mod/jei/versions),
+[Xaero](https://modrinth.com/mod/xaeros-minimap/versions),
+[Litematica](https://modrinth.com/mod/litematica/versions) et
+[MaLiLib](https://modrinth.com/mod/malilib/versions), interrogés pour Fabric et
+exactement `26.3-pre-2`, n’ont retourné aucun fichier déclaré pour cette combinaison
+au relevé. Leur disponibilité sur la cible est **non confirmée**, sans conclure
+à une incompatibilité. Les autres candidats ne sont pas validés pour cette cible
+par la seule lecture de leurs descriptions.
+
+Aucun JAR, dépendance ou configuration de profil n’est ajouté ici. Pour chaque
+intégration future, vérifier l’artefact Fabric exact, ses dépendances et ses
+points de raccord, puis essayer les états avant/après déblocage. L’installation
+d’un mod dans le pack et l’obtention d’une capacité par un joueur sont deux
+opérations différentes ; on n’installe pas un JAR au moment d’un advancement.
+
+## Prochain résultat de conception
+
+Décrire un petit ensemble de fiches jouables reliant une découverte, un acquis
+et son usage concret, puis choisir les premiers plans et effets de familiers.
+Les coûts, paliers, sources des plans et effets exacts restent en discussion.
+Ce cahier ne lance ni portage des anciens modules ni livraison du pack.

docs/recherche-archives-sanctuary.md

@@ -0,0 +1,119 @@
+# Archives de Sanctuary : dater le projet et ses versions
+
+Audit documentaire du **11 septembre 2026**, en lecture seule. Les souvenirs
+initiaux de l’auteur sont : création le 16 mars, développement le 24 mai,
+alpha le 17 août et bêta le 8 septembre 2026. Il a précisé que ces dates étaient
+approximatives. On conserve ces indications et on les confronte aux traces.
+
+**Résultat le plus solide : une distribution classée alpha est publiée sur
+Modrinth le 7 juillet 2026. L’archive locale est exactement celle de cette
+publication.** Le 17 août ne peut donc pas être présenté comme la première
+publication alpha de toutes les lignées de Sanctuary.
+
+## Chronologie retrouvée
+
+Les heures locales ci-dessous sont exprimées en **Europe/Paris** ; les
+horodatages des services sont conservés en UTC dans les références.
+
+| Date | Trace retrouvée | Ce qu’elle établit |
+| --- | --- | --- |
+| **16 mars 2026** | Souvenir de création donné par l’auteur. | Origine possible du projet. Aucune pièce ciblée consultée ne confirme encore ce jour. |
+| **24 mai 2026** | Ancien site : article `Release 1.0.0`, qualifié de première version publique, et aperçu de l’île. | Date éditoriale explicitement écrite ; les fichiers ne sont conservés dans Git qu’à partir de juillet. Elle ne prouve pas seule une publication en mai. |
+| **21 juin 2026, 14:01** | Champ `published` du projet Modrinth `FgOqyAXd`. | Repère de publication du projet sur cette plateforme ; pas la date de création de Sanctuary ni d’une version précise. |
+| **4 juillet 2026, 20:27** | Premier commit du dépôt racine, sources déjà à Minecraft `26.1.2`, mod `1.0.0`. | État de sources conservé. L’import initial n’est pas le premier jour de travail. |
+| **7 juillet 2026, 16:31** | Modrinth : `Sanctuary v2026.07.07`, canal **alpha**, Minecraft `26.1.2`. | Publication d’une version datée par la plateforme ; archive retrouvée localement et identique. |
+| **7 juillet 2026, 21:44** | Premier commit du site, contenant déjà les articles datés du 24 mai. | Les mentions du 24 mai sont présentes dans cet état de juillet. Elles ne constituent pas une archive Git de mai. |
+| **8 juillet 2026, 05:27** | Ajout de `sanctuary.mrpack` dans le dépôt racine. | Conservation Git de l’artefact publié la veille, sans changement de sa date de publication. |
+| **17 août 2026, 09:57** | Création Gitea du dépôt `koka/sanctuary`. | Confirme ce jour pour l’ouverture de ce dépôt ; ne suffit pas à dater la première alpha 26.2. |
+| **25 août 2026, 22:20** | Import initial de la lignée 26.2, déjà numérotée `26.2.0-alpha.195`. | Les versions précédentes sont antérieures à cet import, mais toutes leurs dates ne sont pas conservées dans cet historique. |
+| **8 septembre 2026, 00:53 puis 03:24** | Création Gitea de `sanctuary-beta`, puis premier commit Fabric 26.3, version `0.1.0-alpha.1`. | Nouvelle base du projet nommé Beta ; sa version initiale reste explicitement alpha. |
+| **10 septembre 2026** | Ancienne lignée 26.2 à `alpha.244` ; nouvelle lignée distribuée à `0.1.0-alpha.22`. | Les lignées coexistent. Le nom `sanctuary-beta` n’est pas une migration rétroactive de leur phase. |
+
+## Preuves locales et sources primaires
+
+### Le site et les sources de juillet
+
+- [Article du site, `blogPosts.js:8`](../../sanctuary-minecraft.fr/src/blogPosts.js#L8) : date `2026-05-24`, version `1.0.0`. La seconde entrée porte la même date. Les changements décrivent aussi le site ; un texte préparatoire demeure possible.
+- Dépôt `sanctuary-minecraft.fr`, commit **`6a24b3f92bc4af5f76fff78d1c97bcb8dcb4926e`**, auteur `2026-07-07T21:26:28+02:00`, enregistrement `2026-07-07T21:44:11+02:00`. Les deux articles sont déjà présents.
+- Dépôt racine `sanctuary`, commit **`c796a203218a8308f485b9eeb0d95233563a6c4b`**, `2026-07-04T20:27:08+02:00`, intitulé « Initial sanctuary sources ». Son fichier `Worldgen/sanctuary/gradle.properties` contient `minecraft_version=26.1.2` et `mod_version=1.0.0`.
+- Dans ce dépôt, commit **`4dcb80ec9746cde95a28c75cb946341c3df5b463`**, `2026-07-08T05:27:00+02:00`, conservation du pack.
+
+Une date auteur/committer est une métadonnée Git, pas une certification externe
+du jour de sortie. Les noms et versions sont retranscrits tels qu’ils existent.
+
+### La publication Modrinth et le pack conservé
+
+[Projet Sanctuary](https://modrinth.com/modpack/sanctuary-koka99),
+[version retrouvée](https://modrinth.com/modpack/sanctuary-koka99/version/wieO1Ib6),
+[métadonnées du projet](https://api.modrinth.com/v2/project/FgOqyAXd),
+[métadonnées de la version](https://api.modrinth.com/v2/version/wieO1Ib6).
+
+- Projet : `published = 2026-06-21T12:01:28.666880Z`.
+- Version `wieO1Ib6` : `version_number = 2026.07.07`, `version_type = alpha`, `date_published = 2026-07-07T14:31:33.057373Z`.
+- Fichier `sanctuary.mrpack`, **7 221 067 octets**. Son SHA-512 annoncé par la plateforme est identique à celui de [l’archive locale](../../sanctuary.mrpack).
+- Dans `modrinth.index.json` : `versionId = 07.07.2026`, Minecraft `26.1.2`, Fabric Loader `0.19.2`.
+- SHA-256 local : `42662167aad9f0b58bea06bda2c1e482d6618a55abab07a8120fa517a45b0909`.
+
+La vérification lit uniquement le manifeste de l’archive et calcule ses
+empreintes ; elle n’installe ni ne lance le pack. Une seule version est renvoyée
+par l’API publique du projet au relevé. Cela ne prouve pas qu’il n’y en ait jamais
+eu d’autres, retirées ou diffusées ailleurs.
+
+### Les lignées 26.2 et 26.3
+
+[Métadonnées Gitea du dépôt historique](https://git.botsu.net/api/v1/repos/koka/sanctuary)
+: `created_at = 2026-08-17T07:57:49Z`. Les listes publiques de tags et de
+releases de ce dépôt sont vides au relevé ; des branches de livraison existent.
+
+Le [changelog 26.2 importé](https://git.botsu.net/koka/sanctuary/src/commit/94644a28f05b8010f06ec1181fe6c74a50ad80d6/CHANGELOG.md)
+conserve `26.2.0-alpha.1` et décrit dix modules, une instance Prism et un premier
+MRpack, **sans date**. Son introduction précise que cet historique est reconstitué
+depuis les archives et que les dates disponibles ne sont pas fiables.
+Le commit d’import **`94644a28f05b8010f06ec1181fe6c74a50ad80d6`**, le
+25 août à 22:20:18 +02:00, contient déjà le **pack `26.2.0-alpha.195`** et le
+**module Sanctuary `0.0.0-alpha.111`** : les deux numérotations sont distinctes.
+Les 263 commits alors atteignables depuis `main` ne portent aucune date auteur
+ou committer antérieure au 25 août ; les autres branches ne sont pas toutes
+auditées. Le commit de livraison
+**`72f609f77cd59b074ff8b77f7161fcb89bdba4eb`**, le 10 septembre à
+14:45:33 +02:00, est encore une alpha 26.2.
+
+[Métadonnées du dépôt actuel](https://git.botsu.net/api/v1/repos/koka/sanctuary-beta)
+: `created_at = 2026-09-07T22:53:39Z`, soit le **8 septembre à 00:53:39**
+à Paris. Ce décalage explique la différence de date UTC.
+
+Premier [commit des sources 26.3](https://git.botsu.net/koka/sanctuary-beta/commit/e48de1b400e8a406c6a6fe91e995f89311f45106)
+: auteur `2026-09-08T03:24:04+02:00`, commit `03:24:19+02:00` ;
+`gradle.properties` et `packwiz/pack.toml` donnent `0.1.0-alpha.1`, sur
+Minecraft `26.3-pre-2`. Les [releases publiques](https://git.botsu.net/api/v1/repos/koka/sanctuary-beta/releases?limit=50)
+confirment les distributions alpha suivantes, de l’alpha.2 le 8 septembre
+à l’alpha.22 le 10 septembre au moment du relevé.
+
+## Conséquences pour la chronologie et le lore
+
+On distingue maintenant **création du projet**, **première diffusion retrouvée**,
+**refonte 26.2** et **nouvelle base 26.3**. « Dev → alpha → bêta » ne décrit pas
+fidèlement tous les numéros retrouvés : une `1.0.0` locale précède déjà les
+alphas ultérieures. Chaque lignée garde son histoire.
+
+Le **16 mars** peut rester l’origine narrative souhaitée, si l’auteur la
+confirme comme telle, même sans document contemporain. Le **24 mai** a une
+trace éditoriale ; **le 7 juillet est une publication alpha directement
+recoupée**. Le **17 août** et le **8 septembre** sont attestés pour leurs
+dépôts respectifs. Aucune de ces dates ne fixe automatiquement la disparition
+de Steve et des autres anciens.
+
+Le [calendrier proposé](chronologie-sanctuary.md) garde les calculs fondés sur
+le 16 mars explicitement conditionnels. Retrouver une version plus ancienne
+précisera l’histoire documentaire sans réécrire des sauvegardes existantes.
+
+## Limites de l’audit
+
+Les recherches portent sur les documents et métadonnées des dépôts locaux
+pertinents, les archives identifiées, Gitea et Modrinth. Les dates de copie des
+dossiers et les noms de sauvegardes ne sont pas des preuves de publication.
+Les worktrees `26.2-notch`, `26.2-terminal-menu` et `26.2-ticket-90` partagent
+le dépôt 26.2 : ce ne sont pas trois témoignages indépendants. Les mondes n’ont
+pas été ouverts, les anciens dépôts n’ont pas été modifiés et aucun artefact
+historique n’a été republié. D’autres sauvegardes ou publications disparues
+pourraient encore préciser le 16 mars, le 24 mai et le début exact de 26.2.

docs/recherche-minecraft-2009-2014.md

@@ -0,0 +1,83 @@
+# Minecraft Java, 2009–2014 : chronologie des formes, ressources et systèmes
+
+Recherche documentaire du 11 septembre 2026. Ce dossier couvre les changements majeurs de contenu de Pre-classic à la 1.8, avec les premières versions de développement utiles. Il ne répertorie pas chaque correctif ni chaque build ancien perdu. Les dates décrivent le développement du logiciel, **pas une histoire canonique des habitants de Minecraft** : rien ici n’attribue les inventions à Steve, Alex ou aux autres personnages de Sanctuary.
+
+Les versions Alpha, Beta et les versions stables sont des séries différentes : Beta 1.8 n’est pas la 1.8 de 2014. Plusieurs identifiants Indev/Infdev ont été reconstruits à partir de dates et d’archives ; le détail horaire peut changer lorsqu’un exemplaire est retrouvé. Une texture présente dans les fichiers, un objet disponible et une mécanique fonctionnelle constituent trois jalons distincts. [Formats des versions](https://fr.minecraft.wiki/w/Formats_des_versions), [discussion archivistique sur Indev/Infdev](https://minecraft.wiki/w/Forum%3AChanging_Indev_and_Infdev_naming_scheme).
+
+## 2009 : construire, puis survivre
+
+| Date / période | Version ou étape | Contenu et portée |
+|---|---|---|
+| 10–16 mai 2009 | Pre-classic | Prototypes de déplacement, terrain cubique, placement et destruction. C’est une période de développement, non une sortie commerciale. [Chronologie Java](https://nl.minecraft.wiki/w/Javaeditie_versiegeschiedenis). |
+| 17 mai 2009 | Première diffusion publique de Classic | La construction précède la progression de survie complète. La réédition officielle de Classic illustre ce vocabulaire initial réduit de blocs. [Historique Java](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Hebrew_translation/Java_Edition), [rétrospective Mojang](https://www.minecraft.net/en-us/article/embrace-past-minecraft-classic). |
+| Fin mai–juin 2009 | Classic, tests multijoueurs puis extensions créatives | Le monde partagé apparaît très tôt. Le terrain, les liquides, la végétation et les matériaux décoratifs s’étoffent ; il ne faut pas leur attribuer rétrospectivement toutes leurs propriétés de survie. [Versions Classic](https://nl.minecraft.wiki/w/Javaeditie_versiegeschiedenis). |
+| 1er septembre 2009 | 0.24 SURVIVAL TEST | Santé, dégâts, affrontements et collecte structurent une branche de survie, parallèle au mode créatif. Les ennemis emblématiques appartiennent donc à une phase antérieure au craft complet. [Survival Test](https://de.minecraft.wiki/w/Survival_Test). |
+| 23 décembre 2009 | Début Indev | Éclairage dynamique et torches ; la survie devient progressivement un ensemble cohérent de systèmes. Les thèmes de monde expérimentaux n’équivalent pas encore à des dimensions accessibles par portail. [Historique des blocs](https://minecraft.wiki/w/Block_hardness), [période Indev](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Finnish_translation/Java_Edition). |
+
+## 2010 : mondes finis, îles flottantes, machines et Nether
+
+| Date / version | Apparition importante |
+|---|---|
+| **6 janvier, Indev 20100106** | Sélection des types « island », « floating », « flat », « original », des formes et des tailles. Le monde flottant est une possibilité historique du générateur. [Historique de génération](https://minecraft.wiki/w/Seed_%28world_generation%29). |
+| **7 janvier, Indev 20100107** | Les mondes flottants profonds peuvent avoir plusieurs couches d’îles ; thèmes normal et hell. [Historique de génération](https://minecraft.wiki/w/Seed_%28world_generation%29). |
+| **22 janvier, Indev 20100122** | Eau générée au-dessus du niveau marin et sur les îles flottantes ; ajustements des cavernes inondées. Ces expériences combinent déjà verticalité et hydrologie. [Historique de génération](https://minecraft.wiki/w/Seed_%28world_generation%29). |
+| 24–30 janvier, Indev | Coffres le 24 ; fabrication le 29 ; établi le 30. Les outils existaient auparavant, notamment distribués dans la maison Indev. Le stockage et la fabrication ne sont donc pas strictement simultanés. [Coffres](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Vietnamese_translation/R%C6%B0%C6%A1ng), [fabrication](https://ko.minecraft.wiki/w/%EC%A0%9C%EC%9E%91), [établi](https://de.minecraft.wiki/w/Numerische_Identifikation). |
+| 6 février, Indev | Blé, graines, houe, terre labourée et pain : première chaîne agricole. [Mojang, Wheat](https://www.minecraft.net/es-es/article/taking-inventory--wheat). |
+| 19 février, Indev | Le four remplace la cuisson/fonte par mise à feu des objets ; la transformation acquiert son bloc spécialisé. [Historique de la cuisson](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Indonesian_translation/Pembakaran). |
+| 27 février–mars, Infdev | Début du terrain extensible. Les anciens paramètres ne fonctionnent plus, puis disparaissent du menu le **27 mars**. « Infini » décrit une génération étendue à la demande, pas une dimension physiquement sans limites. [Types de monde](https://ja.minecraft.wiki/w/%E3%83%AF%E3%83%BC%E3%83%AB%E3%83%89%E3%82%BF%E3%82%A4%E3%83%97). |
+| Juin, Infdev | Panneaux, portes et échelles le 7 ; seaux le 15 ; interactions eau/lave productrices de pierre et d’obsidienne ; rails et wagonnets le **18 juin**. [Objets](https://minecraft.wiki/w/Items.png), [pierre renouvelable](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Toki_Pona_translation/Cobblestone). |
+| **25 juin**, Infdev | Donjons et générateurs de monstres : une structure rassemble danger répétable et butin. Les selles apparaissent à cette période. [Structures](https://it.minecraft.wiki/w/Struttura), [spawners](https://minecraft.wiki/w/Block_hardness), [objets](https://minecraft.wiki/w/Items.png). |
+| **2 juillet**, Alpha v1.0.1 | Minerai et poudre de redstone, torches, leviers, boutons, plaques et portes en fer. La redstone remplace les engrenages expérimentaux d’Indev. [Mojang, Redstone Ore](https://www.minecraft.net/fr-fr/article/redstone-ore), [engrenages](https://minecraft.wiki/w/Java_Edition_block_render_history/Gear). |
+| Juillet, Alpha v1.0.4–v1.0.14 | Mondes enneigés ; bateaux ; canne, papier, livres et bibliothèques ; argile, briques, slimes ; poules, œufs, jukebox et disques. Les wagonnets avec coffre et avec four donnent des usages logistiques au rail. [Objets Alpha](https://minecraft.wiki/w/Items.png), [dates des versions](https://nl.minecraft.wiki/w/Javaeditie_versiegeschiedenis). |
+| **3 août**, Alpha v1.0.15 ; août–septembre | Survie multijoueur ; puis barrières et spider jockeys. Boussole en v1.1.0, accroupissement et canne à pêche en v1.1.1 ; l’existence de la canne précède la pêche fonctionnelle de l’Halloween Update. [Chronologie Alpha](https://nl.minecraft.wiki/w/Javaeditie_versiegeschiedenis), [objets](https://minecraft.wiki/w/Items.png), [pêche](https://www.minecraft.net/fr-ca/article/desert). |
+| **30 octobre**, Alpha v1.2.0, Halloween Update | Nether et portails, ghasts et cochons zombies, nouveaux matériaux infernaux ; biomes formalisés dans l’Overworld, pêche et variations visuelles du ciel. Le Nether n’a pas encore ses forteresses. [Mojang, Nether Wastes](https://www.minecraft.net/fr-ca/article/around-block--nether-wastes), [Forest](https://www.minecraft.net/tr-tr/article/forest), [date](https://minecraft.wiki/w/Major_updates). |
+
+Le précédent pertinent pour Sanctuary est précis : **Indev proposait réellement des îles flottantes, des couches verticales et de l’eau en altitude avant leur abandon dans Infdev**. Ce n’est ni une preuve que l’End existait déjà ni un événement vécu par des personnages. Le thème Indev « hell » changeait l’environnement d’un monde ; le Nether de 2010 introduit un autre espace et le passage par portail. Cette distinction empêche de fusionner trois expérimentations différentes. [Types de monde](https://ja.minecraft.wiki/w/%E3%83%AF%E3%83%BC%E3%83%AB%E3%83%89%E3%82%BF%E3%82%A4%E3%83%97), [portail en obsidienne](https://minecraft.wiki/w/obsidian).
+
+## 2011 : Beta, infrastructures et aventure
+
+| Sortie | Version | Contenu majeur |
+|---|---|---|
+| 20 décembre 2010 | Beta 1.0 | Nouvelle phase ; travail sur les inventaires et le multijoueur. Beta 1.1 suit surtout pour stabiliser. [Période Beta](https://fr.minecraft.wiki/w/%C3%89dition_Java_B%C3%AAta). |
+| 13 janvier 2011 | Beta 1.2 | Distributeur, bloc musical, charbon de bois, grès, lapis et teintures, gâteau, poulpes, bouleaux et épicéas. Les essences précèdent leurs planches distinctes de 2012. [Historique des blocs](https://minecraft.wiki/w/Block_hardness), [bois](https://minecraft.wiki/w/Oak-log-top), [Beta](https://fr.minecraft.wiki/w/%C3%89dition_Java_B%C3%AAta). |
+| 22 février | Beta 1.3 | Lits, répéteurs, nouvelles dalles ; saisie de graine et stockage des chunks par régions. La temporisation redstone et le saut de nuit deviennent des outils ordinaires. [Beta 1.3](https://uk.minecraft.wiki/w/Beta_1.3_%28Java_Edition%29). |
+| 31 mars | Beta 1.4 | Loups apprivoisables et cookies ; premier compagnon de survie de cette série. [Historique Beta](https://nl.minecraft.wiki/w/Javaeditie_versiegeschiedenis), [loups dans les taïgas](https://minecraft.wiki/w/Tiaga). |
+| 19 avril | Beta 1.5 | Météo, statistiques et achievements ; rails propulseurs et détecteurs. Les pousses spécifiques rendent bouleau et épicéa renouvelables. [Beta 1.5](https://es.minecraft.wiki/w/Java_Edition_Beta_1.5), [bois](https://minecraft.wiki/w/Oak-log-top). |
+| 26 mai | Beta 1.6 | Cartes, trappes et Nether multijoueur ; hautes herbes et végétation supplémentaire. [Beta 1.6](https://uk.minecraft.wiki/w/Beta_1.6_%28Java_Edition%29). |
+| 30 juin | Beta 1.7 | Pistons, pistons collants et cisailles : les circuits peuvent déplacer la matière. [Beta 1.7](https://zh.minecraft.wiki/w/Java%E7%89%88Beta_1.7). |
+| **14 septembre** | Beta 1.8, Adventure Update | Faim, sprint, expérience, créatif renouvelé ; Endermen, araignées venimeuses ; villages initialement vides, mines abandonnées, forteresses, ravins ; rivières et grands océans. Briques de pierre, vitres, barreaux, lianes et champignons géants enrichissent les ruines possibles. [Beta 1.8](https://zh.minecraft.wiki/w/Java%E7%89%88Beta_1.8?variant=zh-cn), [structures](https://it.minecraft.wiki/w/Struttura). |
+| **18 novembre** | **1.0.0** | Achèvement de l’Adventure Update : End, dragon et conclusion, enchantements, potions, élevage, hardcore, nouveaux habitants et forteresses du Nether. Ces systèmes ont plusieurs premières apparitions distinctes ci-dessous. [Date](https://minecraft.wiki/w/Major_updates), [Mojang, Ender Dragon](https://www.minecraft.net/pt-pt/article/ender-dragon). |
+
+Les versions nommées **Beta 1.9 Prerelease** préparent la **1.0.0** ; il n’existe pas de sortie stable Beta 1.9 équivalente. La première introduit notamment villageois et forteresses du Nether ; ces villageois n’échangent pas encore. La **Prerelease 3 du 6 octobre** apporte table d’enchantement, alambic, œil de l’Ender et développement de l’élevage. La **Prerelease 4 du 13 octobre** rend l’End accessible et introduit le dragon encore en chantier. La Prerelease 6 de novembre complète notamment la conclusion. [Villageois historiques](https://minecraft.wiki/w/Villager_%28old%29), [Prerelease 3](https://es.minecraft.wiki/w/Java_Edition_Beta_1.9_Prerelease_3), [Prerelease 4](https://ru.minecraft.wiki/w/Beta_1.9_Prerelease_4_%28Java_Edition%29), [historique du protocole](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/wiki.vg_merge/Protocol_History).
+
+## 2012 : habiter, échanger, écrire et administrer
+
+| Sortie | Version | Contenu majeur et premier jalon utile |
+|---|---|---|
+| **12 janvier** | 1.1 | Langues supplémentaires, œufs d’apparition, monde superplat. Superflat arrive en **12w01a** ; il ne constitue pas le retour intégral des générateurs Indev. [1.1](https://ru.minecraft.wiki/w/1.1_%28Java_Edition%29), [types de monde](https://fr.minecraft.wiki/w/Type_de_monde). |
+| **1er mars** | 1.2.1 | Jungles, ocelots/chats, golems de fer, lampes redstone, sièges de villages ; format Anvil et hauteur **128 → 256**. Jungle dès **12w03a**, lampes **12w07a**. Les biomes sont conservés dans les données des chunks. [1.2.1](https://minecraft.wiki/w/Java_Edition_1.2.1). |
+| **22 mars** | 1.2.4 | Planches distinctes de bouleau, épicéa et jungle ; grès taillé et sculpté. Ces blocs décoratifs ne datent pas tous de l’arrivée des arbres correspondants. [Historique des blocs](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Swedish_translation/Block), [dates](https://nl.minecraft.wiki/w/Javaeditie_versiegeschiedenis). |
+| **1er août** | 1.3.1 | Commerce villageois et émeraudes, livres éditables, coffres de l’Ender, temples désert/jungle, crochets et fils, mode aventure, LAN et serveur intégré. Commerce et coffre arrivent en **12w21a** ; le stockage Ender devient personnel en **12w24a**. [1.3.1](https://es.minecraft.wiki/w/Java_Edition_1.3.1), [coffre de l’Ender](https://fr.minecraft.wiki/w/Coffre_de_l%27ender). |
+| **25 octobre** | 1.4.2, Pretty Scary Update | Wither, balise, sorcières, chauves-souris, squelettes wither, zombies villageois guérissables ; enclumes, cadres, pots, murets, carottes/pommes de terre ; commandes et règles de jeu. Bloc de commande et balise : **12w32a** ; enclume : **12w41a**. [Historique des blocs](https://minecraft.wiki/w/Block_hardness), [règles](https://fr.minecraft.wiki/w/R%C3%A8gle_de_jeu), [Mojang, Command Block](https://www.minecraft.net/ko-kr/article/block-week-command-block). |
+| **14 novembre** | 1.4.4 | Disque « wait » disponible ; « 11 » devient obtenable en survie ; commande `/enchant`. Une musique peut donc exister avant son objet accessible. [Annonce officielle](https://mcupdate.tumblr.com/post/35704186352/minecraft-144), [disques](https://minecraft.wiki/rest.php/v1/page/Music_Disc/html), [commande](https://pt.minecraft.wiki/w/Comandos/enchant). |
+| **20 décembre** | 1.4.6 | Livres enchantés et feux d’artifice ; premiers prototypes en **12w49a, le 7 décembre**. L’enchantement devient stockable dans un objet transmissible. [12w49a](https://zh.minecraft.wiki/w/12w49a?variant=zh-cn), [dates](https://nl.minecraft.wiki/w/Javaeditie_versiegeschiedenis). |
+
+## 2013–2014 : logistique, diversité et monde programmable
+
+| Sortie | Version | Contenu majeur et premiers jalons |
+|---|---|---|
+| **13 mars 2013** | 1.5, Redstone Update | Entonnoirs, comparateurs, droppers, capteurs solaires, coffres piégés, plaques pondérées, bloc de redstone, quartz et scoreboard. Comparateur/entonnoir apparaissent en **13w01a**, dropper en **13w03a**. Transport, mesure et transformation peuvent s’articuler en installations autonomes. [Redstone Update](https://es.minecraft.wiki/w/Redstone_Update), [dropper](https://fr.minecraft.wiki/w/Dropper), [Mojang, Hopper](https://www.minecraft.net/en-us/article/hopper). |
+| **1er juillet** | 1.6.1, Horse Update | Chevaux, ânes, mules, laisses, armures pour chevaux, étiquettes, foin, tapis, argile durcie/colorée et bloc de charbon ; packs de ressources et nouveau lanceur. Chevaux dès **13w16a, le 18 avril**. En 1.6.2, les bébés zombies apparaissent naturellement. [Horse Update](https://minecraft.wiki/w/Horse_Update), [premier nouveau lanceur](https://minecraft.wiki/w/Launcher_0.1). |
+| **25 octobre** | 1.7.2, The Update that Changed the World | Nouvelle distribution climatique : mesa, savane, forêt couverte, grandes taïgas, forêts fleuries, pics de glace ; nouveaux poissons pêchables, fleurs, podzol et verre coloré. Biomes **13w36a**, verre **13w41a**, bois d’acacia/chêne noir **13w43a** : leurs biomes précèdent leurs bois définitifs. Monde Amplifié. [Biomes](https://ko.minecraft.wiki/w/%EC%83%9D%EB%AC%BC_%EA%B5%B0%EA%B3%84), [blocs](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Esperanto_translation/Bloko), [types](https://fr.minecraft.wiki/w/Type_de_monde). |
+| **10 décembre** | 1.7.4 | Chicken jockeys, d’abord en **13w49a** : une petite version ajoute aussi du contenu, pas seulement des correctifs. [Dates](https://nl.minecraft.wiki/w/Javaeditie_versiegeschiedenis), [zombies villageois historiques](https://minecraft.wiki/w/Zombie_Villager_%28old%29), [Mojang](https://www.minecraft.net/en-us/article/meet-chicken-jockey). |
+| **2 septembre 2014** | 1.8, Bountiful Update | Monuments océaniques, gardiens, lapins, endermites ; granite/andésite/diorite, slime, prismarine, lanternes aquatiques, éponges humides, grès rouge ; bannières, porte-armures, portes/barrières par essence. Alex rejoint les apparences par défaut. [Date](https://minecraft.wiki/w/Major_updates), [Mojang, Ocean Monument](https://www.minecraft.net/en-us/article/ocean-monument), [blocs](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Indonesian_translation/Balok), [Alex](https://minecraft.wiki/w/Alex). |
+
+Pour la 1.8, les étapes sont espacées : pierres et slime en **14w02a**, spectateur en **14w05a**, générateur personnalisé en **14w17a**, monuments en **14w25a**, lapins en **14w27a**. Ce sont des premières apparitions de développement ; septembre est leur diffusion stable commune. [Pierres](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Persian_translation/%D8%B3%D9%86%DA%AF), [spectateur](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Indonesian_translation/Mode_Penonton), [types](https://fr.minecraft.wiki/w/Type_de_monde), [structures](https://it.minecraft.wiki/w/Struttura), [créatures](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Indonesian_translation/Makhluk). L’enchantement change également en **14w02a** : dépense de lapis-lazuli et aperçu d’un enchantement possible, bien après l’introduction du minerai. [Historique de l’enchantement](https://minecraft.wiki/w/Minecraft_Wiki%3AProjects/Indonesian_translation/Penyihiran).
+
+La programmation du monde suit une autre filiation : bloc de commande en 2012 ; `/summon` puis `/setblock` et `/tellraw` en 2013 ; `/clone` et `/fill` en **14w03a**, `/execute` en **14w07a**, `/worldborder` en **14w17a**, `/title` en **14w20a**. Ces outils sont ceux de l’administration et de la création de cartes, pas un ordinateur craftable vanilla. La 1.8.1 du 24 novembre ajoute notamment `doEntityDrops`, sans nouveau grand ensemble de structures. [Historique des commandes](https://zh.minecraft.wiki/w/%E5%91%BD%E4%BB%A4?variant=zh-tw), [Mojang, Command Block](https://www.minecraft.net/ko-kr/article/block-week-command-block), [règles de jeu](https://fr.minecraft.wiki/w/R%C3%A8gle_de_jeu).
+
+## Limites et usage de cette chronologie
+
+Les sources combinent Minecraft Wiki communautaire actuel, ses traductions et rétrospectives officielles Mojang ; une annonce officielle contemporaine a également été retrouvée pour la 1.4.4. Certaines pages ne sont consultables que par leurs extraits indexés. Les annonces originales Mojang de plusieurs versions anciennes et des builds perdus restent à recouper : ce dossier ne prétend pas constituer leur archivage exhaustif. Les mises à jour mineures de comportement ne sont pas toutes détaillées : par exemple la **1.3.2 du 16 août 2012** fait générer les grands chênes avec des branches horizontales. [Bois](https://minecraft.wiki/w/Oak-log-top), [dates](https://nl.minecraft.wiki/w/Javaeditie_versiegeschiedenis).
+
+Pour une reconstruction jouable, vérifier le **build exact**, pas seulement sa famille : charbon de bois après les fours, planches distinctes après les arbres, commerce après les villageois, End après les Endermen. Les primitives actuelles ne doivent pas être rétroprojetées : ni échange villageois en Beta 1.8, ni îles externes de l’End de 1.9 dans la 1.0, ni programmation de survie par bloc de commande. Les rapprochements avec Galactium et les anciens joueurs devront rester explicitement des inventions de Sanctuary.

docs/recherche-minecraft-2015-2026.md

@@ -0,0 +1,68 @@
+# Minecraft Java, 2015–2026 : chronologie documentaire
+
+Recherche arrêtée au **11 septembre 2026** : histoire publique du jeu, sans ajout au canon de Sanctuary. Périmètre : mises à jour de contenu depuis les snapshots de la 1.9, petits *drops* et premières apparitions expérimentales importantes. Les correctifs ordinaires ne sont pas détaillés. Les snapshots événementiels du **1er avril** ne sont pas inventoriés intégralement ; **20w14∞** fait l’objet d’un encadré ciblé.
+
+Une **annonce** n’est pas encore jouable ; un **snapshot** est une version de développement ; une **préversion** ou une **release candidate** reste antérieure à la sortie stable. Un contenu proposé derrière une option expérimentale ne devient pas, de ce seul fait, du contenu normal de la version qui l’héberge. Cette distinction est explicitement utilisée par Mojang depuis les *feature flags*. [Explications et règles des fonctionnalités expérimentales, 1.19.3](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-19-3).
+
+Sources : notes de Mojang sur Minecraft.net et historiques de **Minecraft Wiki**, dont sa [liste des grandes mises à jour](https://minecraft.wiki/w/Major_updates). Certaines pages du Wiki bloquaient la lecture automatisée : seuls leurs passages indexés ont alors été consultés, avec recoupement officiel disponible. Les dates ci-dessous désignent la disponibilité des versions ; les dates éditoriales d’articles traduits ou remaniés peuvent différer.
+
+## 2015–2020 : destinations, métiers et production
+
+| Version et disponibilité | Premières apparitions importantes | Contenu et distinction historique |
+| --- | --- | --- |
+| **Préparation de la 1.9 — 2015** | **15w31a, 29 juillet** : extension de l’End et shulkers. **15w41a, 7 octobre** : élytres. | Les cités de l’End ont été montrées avant leur disponibilité stable. Les élytres arrivent plus tard dans la même campagne de snapshots : il serait faux de leur donner automatiquement la date du premier snapshot. [Mojang : histoire des cités de l’End](https://www.minecraft.net/zh-hans/article/end-city), [Wiki : historique des créatures](https://minecraft.wiki/w/Minecraft_Wiki:Projects/Slovak_translation/Mob), [Wiki : historique des élytres parmi les outils](https://minecraft.wiki/w/Minecraft_Wiki:Projects/Indonesian_translation/Alat). |
+| **1.9 — Combat Update, 29 février 2016** | Les essais de 2015 précèdent cette sortie stable. | Refonte du combat, main secondaire, boucliers et flèches à effets ; l’End devient une destination d’exploration après le dragon, avec cités, vaisseaux, shulkers et élytres. Le shulker existe donc avant sa boîte transportable. [Mojang : shulker et Combat Update](https://www.minecraft.net/nl-nl/article/shulker), [Wiki : dates des mises à jour](https://minecraft.wiki/w/Major_updates). |
+| **1.10 — Frostburn Update, 8 juin 2016** | **16w20a, 18 mai** : ours polaires, husks, strays et magma. | Diversification du chaud et du froid, fossiles et blocs d’os, briques rouges du Nether et blocs de verrues. Le magma acquiert plus tard d’autres usages aquatiques ; ne pas attribuer ses colonnes de bulles à sa première apparition. [Mojang : histoire du magma](https://www.minecraft.net/zh-hant/article/block-week-magma), [Wiki : blocs de 16w20a](https://minecraft.wiki/w/Minecraft_Wiki:Projects/Finnish_translation/Kuutio), [Wiki : 1.10](https://minecraft.wiki/w/Major_updates). |
+| **1.11 — Exploration Update, 14 novembre 2016** | **16w39a, 28 septembre** : cartographes, nouveaux illageois, lamas, observateurs et boîtes de shulker. | Les manoirs donnent une destination aux cartes d’exploration vendues par les cartographes ; évocateurs, vindicateurs, vexes et totems accompagnent cette exploration. Les boîtes déplacent un stock complet d’objets, tandis que l’observateur enrichit la redstone. [Wiki : détail de 16w39a](https://de.minecraft.wiki/w/16w39a), [Wiki : chronologie des blocs](https://minecraft.wiki/w/Minecraft_Wiki:Projects/Finnish_translation/Kuutio), [dates](https://minecraft.wiki/w/Major_updates). |
+| **1.11.1 — 20 décembre 2016** | **16w50a, 15 décembre** prépare ce petit ajout de contenu. | Propulsion des élytres par fusées, pépites de fer, recyclage métallique et enchantement Sweeping Edge. Ne pas confondre le vol plané de la 1.9 avec cette autonomie de déplacement ultérieure. La note officielle a été actualisée pour le correctif 1.11.2 : son titre actuel couvre aussi celui-ci. [Note officielle 1.11.1/1.11.2](https://www.minecraft.net/en-us/article/minecraft-1112-released). |
+| **1.12 — World of Color, 7 juin 2017** | **17w06a, 8 février** : béton et terre cuite émaillée. **17w13a, 30 mars** : advancements, livre de recettes, perroquets. | Palettes colorées, lits teints et nouvelles possibilités décoratives. Les advancements remplacent les anciens achievements Java et peuvent récompenser ou guider des parcours personnalisés ; le livre de recettes accompagne la découverte de la fabrication. [Sortie officielle](https://www.minecraft.net/en-us/article/world-color-released), [17w13a](https://www.minecraft.net/en-us/article/minecraft-snapshot-17w13a), [Wiki : advancements](https://minecraft.wiki/w/Advancements). |
+| **1.13 — Update Aquatic, 18 juillet 2018** | **18w07a, 14 février** : nage, trident, tortues, algues, colonnes de bulles et phantoms. | Océans différenciés, coraux, poissons, dauphins, noyés, épaves, ruines et trésors enfouis composent une exploration maritime. Conduits et eau partageant certains blocs transforment aussi la construction. Cette version rassemble une évolution technique majeure et un ajout de monde. [Sortie officielle](https://www.minecraft.net/en-us/article/update-aquatic-out-java), [première vague aquatique](https://www.minecraft.net/en-us/article/minecraft-snapshot-18w07a). |
+| **1.13.1 — 22 août 2018** | Petit prolongement de la 1.13, pas un nouveau grand thème. | Ajout de coraux morts, changements écologiques des poissons et calamars, et commande `/forceload`. Celle-ci est un outil administratif de maintien des chunks, pas un bloc de survie analogue aux futures clés de Sanctuary. [Note officielle](https://www.minecraft.net/es-mx/article/minecraft-1131-released). |
+| **1.14 — Village & Pillage, 23 avril 2019** | **18w43a, 24 octobre 2018** : bambou, pandas, pillagers et première vague de nouveaux blocs/textures. | Villages à architecture régionale, postes de travail, nouvelles règles de métiers et d’échanges, cloches, raids, avant-postes et ravageurs. Tonneaux, fumoirs, hauts fourneaux, lanternes, échafaudages et tailleurs de pierre densifient les lieux de production. Ce n’est pas encore un système général de villageois ouvriers exécutant des commandes du joueur. [Snapshot](https://www.minecraft.net/de-de/article/minecraft-snapshot-18w43a), [sortie et métiers](https://www.minecraft.net/en-us/article/village---pillage-out-java-). |
+| **1.15 — Buzzy Bees, 10 décembre 2019** | **19w34a, 22 août** : abeilles, ruches et miel ; la production est déjà observable en snapshot. | Abeilles pollinisatrices, nids, ruches fabriquées, miel, rayons et blocs de miel créent une chaîne de récolte liée aux fleurs et au feu de camp. Les blocs collants enrichissent les machines ; les golems de fer deviennent réparables. [Premier snapshot officiel](https://feedback.minecraft.net/hc/en-us/articles/360032831011-Minecraft-Java-Edition-Snapshot-19W34A), [sortie](https://www.minecraft.net/en-us/article/buzzy-bees-out-now-in-java). |
+| **1.15.2 — 21 janvier 2020** | Petit prolongement de l’apiculture. | Un chêne ou bouleau poussé depuis une jeune pousse près d’une fleur, à deux blocs au plus et au même niveau, a **5 %** de chances de porter un nid. Les nids deviennent ainsi renouvelables par plantation. Ajout des règles `doPatrolSpawning` et `doTraderSpawning`. [Note officielle](https://feedback.minecraft.net/hc/en-us/articles/360038800232-Minecraft-Java-Edition-1-15-2). |
+| **1.16 — Nether Update, 23 juin 2020** | **20w06a, 5 février** : nouvelles forêts, vallée des âmes, hoglins et netherite. | Basalte, blackstone, végétations fongiques, piglins et troc, arpenteurs, ancres de réapparition, bastions et portails en ruine rendent le Nether plus habitable et plus historique. Le minerai de débris antiques fournit une nouvelle étape matérielle après le diamant. [Premier snapshot](https://feedback.minecraft.net/hc/en-us/articles/360039129472-Minecraft-Java-Edition-Snapshot-20W06A), [sortie officielle](https://www.minecraft.net/en-us/article/nether-update-java). |
+| **1.16.2 — 11 août 2020** | **20w27a, 1er juillet** : piglin brute. | Les brutes gardent les bastions et ne se laissent pas détourner par l’or : une spécialisation de défense s’ajoute à une structure existante. Ce petit ajout mérite une place séparée des correctifs ordinaires. [Snapshot](https://www.minecraft.net/de-de/article/minecraft-snapshot-20w27a), [sortie](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-16-2). |
+
+> **20w14∞ (`20w14infinite`), 1er avril 2020 — expérience événementielle.** Mojang propose d’écrire quelques mots dans un livre puis de le jeter dans un portail du Nether : le texte donne accès à un monde particulier. L’annonce humoristique présente plus de deux milliards de mondes et une machine de Turing tridimensionnelle. [Présentation originale de Mojang](https://www.minecraft.net/en-us/article/every-update-imaginable-coming-minecraft).
+>
+> Ce rapprochement entre écriture, calcul et destinations peut nourrir la réflexion sur Galactium et les Indoors. Il ne décrit ni un contenu Java stable, ni une compatibilité technique, ni un système déjà implémenté dans Sanctuary.
+
+## 2021–2024 : profondeur, traces et systèmes composables
+
+| Version et disponibilité | Premières apparitions importantes | Contenu et distinction historique |
+| --- | --- | --- |
+| **1.17 — Caves & Cliffs, partie I, 8 juin 2021** | **20w45a, 4 novembre 2020** : cuivre, améthyste, longue-vue, paratonnerre, verre teinté. **21w08a, 24 février 2021** : le grimstone devient deepslate. | Géodes, cuivre oxydable, pierre des abîmes, mousses, spéléothèmes, axolotls, chèvres et poulpes luisants. Les matériaux arrivent avant la grande transformation stable du relief : la 1.17 normale ne possède pas encore l’Overworld complet de la 1.18. [20w45a](https://feedback.minecraft.net/hc/en-us/articles/360051653692-Minecraft-Java-Edition-Snapshot-20W45A), [21w08a](https://www.minecraft.net/pl-pl/article/minecraft-snapshot-21w08a), [Wiki : partie I](https://minecraft.wiki/w/Java_Edition_guides/Caves_%26_Cliffs%3A_Part_I). |
+| **1.18 — Caves & Cliffs, partie II, 30 novembre 2021** | **21w06a, 10 février** : premières cavernes à bruit et aquifères ; retirés de la série 1.17 le **14 avril**, puis retravaillés séparément. | Montagnes et cavernes profondes, lush caves et dripstone caves naturellement distribuées ; Overworld de **−64 à 319**, soit **384 couches**. Nouvelles distributions des minerais, grandes veines cuivre/granit et fer/tuf. [Premier essai](https://www.minecraft.net/es-mx/article/minecraft-snapshot-21w06a), [séparation des versions](https://www.minecraft.net/en-us/article/minecraft-snapshot-21w15a), [sortie](https://feedback.minecraft.net/hc/en-us/articles/4415128577293-Minecraft-Java-Edition-1-18). |
+| **1.19 — The Wild Update, 7 juin 2022** | **17 février** : essai Deep Dark distinct ; **22w13a, 31 mars** : allay et cités anciennes dans la série régulière. | Deep Dark, sculk, Warden et cités anciennes ; mangrove, boue, briques de boue, grenouilles, têtards, allays et bateaux-coffres. Les cités offrent déjà une ruine souterraine documentée ; elles ne prouvent pas à elles seules l’existence d’un ancien peuple précis. [Essai Deep Dark](https://www.minecraft.net/en-us/article/a-very-scary-snapshot), [22w13a](https://www.minecraft.net/en-us/article/minecraft-snapshot-22w13a), [sortie](https://www.minecraft.net/en-us/article/the-wild-update-out-today-java). |
+| **1.19.1 — 27 juillet 2022** | **22w24a, 15 juin** : duplication des allays. | Un allay dansant près d’un jukebox peut se dupliquer avec un éclat d’améthyste. La version introduit aussi le signalement des conversations ; cette histoire du logiciel reste distincte d’une explication fictionnelle du monde. [Snapshot](https://feedback.minecraft.net/hc/en-us/articles/6968038003085-Minecraft-Java-Edition-Snapshot-22w24a), [sortie](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-19-1). |
+| **1.19.3 — 7 décembre 2022** | **22w42a, 19 octobre** : premiers essais des contenus de la future 1.20 derrière une option. | Inventaire créatif réorganisé, nouveaux skins par défaut et vex remanié. Chameaux, bois de bambou et autres contenus activables pour tester la 1.20 ne doivent pas être datés comme une disponibilité normale en 1.19.3. [Note officielle et séparation des expérimentations](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-19-3). |
+| **1.19.4 — 14 mars 2023** | **23w06a, 8 février** : entités d’affichage ; **23w07a, 15 février** : entités d’interaction. | Affichages de blocs, objets et textes, commandes `/ride` et `/damage`, élevage équin amélioré, jukebox automatisable : de nouveaux outils de mise en scène. [Sortie](https://feedback.minecraft.net/hc/en-us/articles/13987663727757-Minecraft-Java-Edition-1-19-4), [23w06a](https://www.minecraft.net/zh-hant/article/minecraft-snapshot-23w06a), [23w07a](https://www.minecraft.net/de-de/article/minecraft-snapshot-23w07a). |
+| **1.20 — Trails & Tales, 7 juin 2023** | **23w07a, 15 février** : archéologie, sniffer et cerisiers, alors expérimentaux. | Sables/graviers suspects, brossage, tessons, pots décorés, ruines des sentiers, graines anciennes et sniffer ; cerisiers, bambou constructible, chameaux, bibliothèques sculptées, enseignes suspendues et ornements d’armure. Des objets portent désormais des traces collectables du passé, sans récit historique unique imposé. [Snapshot](https://www.minecraft.net/de-de/article/minecraft-snapshot-23w07a), [sortie officielle](https://www.minecraft.net/en-us/article/trails-tales-update-here), [Wiki : date 1.20](https://minecraft.wiki/w/Java_Edition_1.20). |
+| **1.20.2 — 21 septembre 2023** | Expérimentation séparée du rééquilibrage des échanges. | Plus de diamants dans les profondeurs, macros de fonctions, commande aléatoire et nouvelles possibilités de packs. La réforme expérimentale des bibliothécaires/cartographes n’est pas automatiquement la règle normale des villages. [Note officielle](https://feedback.minecraft.net/hc/en-us/articles/19703470383757-Minecraft-Java-Edition-1-20-2). |
+| **1.20.3 — 5 décembre 2023** | **23w41a, 11 octobre** prépare les pots fonctionnels. | Les pots décorés stockent une pile d’objets et interagissent avec hoppers, droppers et comparateurs ; les chauves-souris changent d’apparence. Ajout de `/tick`. Les chambres d’épreuves de l’expérimentation 1.21 ne sont pas encore la génération normale. [Snapshot](https://www.minecraft.net/de-de/article/minecraft-snapshot-23w41a), [sortie](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-20-3). |
+| **1.20.5 — Armored Paws, 23 avril 2024** | **23w51a, 18 décembre 2023** : tatou et armure de loup ; **24w10a, 6 mars 2024** : variantes de loups. | Tatous, écailles brossables et armures réparables/teignables pour les loups ; huit variantes complètent le loup connu, selon les biomes. Cette protection animale précède Tricky Trials : elle n’est pas un ajout de la 1.21. [23w51a](https://www.minecraft.net/sv-se/article/minecraft-snapshot-23w51a), [24w10a](https://www.minecraft.net/pl-pl/article/minecraft-snapshot-24w10a), [sortie](https://www.minecraft.net/ru-ru/article/minecraft-java-edition-1-20-5). |
+| **1.21 — Tricky Trials, 13 juin 2024** | **23w42a, 18 octobre 2023** : crafter ; **23w45a, 8 novembre** : chambres d’épreuves et Breeze ; **24w11a, 14 mars 2024** : masse. | Chambres modulaires, générateurs d’épreuves, coffres-forts à clés, épreuves inquiétantes, Breeze et Bogged ; masse, charges de vent, tuf travaillé et nouveaux cuivres. Le crafter ouvre la fabrication automatisée vanilla. [Crafter](https://www.minecraft.net/pt-pt/article/minecraft-snapshot-23w42a), [chambres](https://www.minecraft.net/nl-nl/article/minecraft-snapshot-23w45a), [masse](https://www.minecraft.net/es-es/article/minecraft-snapshot-24w11a), [sortie](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-21). |
+| **1.21.2 — Bundles of Bravery, 22 octobre 2024** | Les bundles existaient à l’essai dès **20w45a**, en 2020. | Les bundles deviennent enfin du contenu normal, avec variantes teintes. Les bébés dauphins/calamars et le Hardcore pour Realms Java complètent le drop. Ce n’est pas la première apparition du mode Hardcore dans Java, ni une sortie stable des bundles en 1.17. [Premier essai](https://feedback.minecraft.net/hc/en-us/articles/360051653692-Minecraft-Java-Edition-Snapshot-20W45A), [sortie](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-21-2). |
+| **1.21.4 — The Garden Awakens, 3 décembre 2024** | **24w40a, 2 octobre** : Pale Garden expérimental. | Jardin pâle, chêne pâle, mousses suspendues, Creaking et cœur associé, résine et eyeblossoms. L’écosystème nocturne lie comportement de créature et bloc caché dans un arbre. Les premières annonces et le premier essai ne représentent pas encore tous les blocs du drop final. [Snapshot](https://www.minecraft.net/en-us/article/minecraft-snapshot-24w40a), [sortie](https://www.minecraft.net/ko-kr/article/minecraft-java-edition-1-21-4). |
+
+## 2025–11 septembre 2026 : drops et frontière contemporaine
+
+| Version et disponibilité | Premières apparitions importantes | Contenu et distinction historique |
+| --- | --- | --- |
+| **1.21.5 — Spring to Life, 25 mars 2025** | **25w02a, 8 janvier** : cochons climatiques, fleurs sauvages, feuilles mortes et particules de feuilles. | Variantes chaudes/froides des cochons, vaches et poules, nouveaux sons de loups, arbres tombés, buissons à lucioles, herbes sèches et fleurs de cactus. L’identité climatique passe aussi par les petites ambiances et la faune. [Snapshot](https://www.minecraft.net/ja-jp/article/minecraft-snapshot-25w02a), [sortie](https://www.minecraft.net/sv-se/article/minecraft-java-edition-1-21-5), [Wiki](https://minecraft.wiki/w/Java_Edition_1.21.5). |
+| **1.21.6 — Chase the Skies, 17 juin 2025** | **25w15a, 8 avril** : ghast desséché, ghastling, happy ghast, harnais et barre de localisation. | Monture volante coopérative, élevage du ghast, selles fabriquables, nouvelles interactions de laisses et musique. Java reçoit des améliorations du brouillard et des nuages : la note parle d’étapes vers Vibrant Visuals, pas de sa livraison complète sur Java. [Snapshot](https://www.minecraft.net/pl-pl/article/minecraft-snapshot-25w15a), [sortie](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-21-6). |
+| **1.21.7 — 30 juin 2025** | Petit ajout entre deux grands drops. | Disque **Lava Chicken**, obtenu sur un chicken jockey, et tableau **Dennis**, en plus des correctifs. Il faut conserver cette ligne si l’on suit l’apparition d’objets culturels et décoratifs, même si le numéro ressemble à un simple correctif. [Note officielle](https://www.minecraft.net/es-es/article/minecraft-java-edition-1-21-7). |
+| **1.21.9 — The Copper Age, 30 septembre 2025** | **25w31a, 29 juillet** : golem/coffre de cuivre, équipement et étagères. | Le cuivre devient outil, armure, stockage, décor et compagnon de tri ; les golems s’oxydent en statues. Les étagères exposent des objets et peuvent échanger des groupes de cases avec la barre rapide. Le minerai, lui, existait depuis 1.17. [Snapshot](https://www.minecraft.net/en-us/article/minecraft-snapshot-25w31a), [sortie](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-21-9). |
+| **1.21.11 — Mounts of Mayhem, 9 décembre 2025** | **25w41a, 9 octobre** : nautiles, nautiles zombies, lances et chevaux zombies naturellement accessibles. | Combat monté, lance, montures aquatiques et armures associées ; camel husk, parched et armure de cheval en netherite complètent la sortie. Le cheval zombie existait auparavant comme entité : sa disponibilité naturelle est une évolution distincte. [Snapshot](https://www.minecraft.net/en-us/article/minecraft-snapshot-25w41a), [sortie](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-21-11). |
+| **26.1 — Tiny Takeover, 24 mars 2026** | Série inaugurée le **16 décembre 2025** ; **snapshot 2, 7 janvier 2026** : première vague de bébés remaniés et étiquettes fabriquables. | Nouveaux modèles/sons de bébés animaux, étiquettes fabriquables et pissenlit doré permettant de suspendre leur croissance. Cette version suit Mounts of Mayhem ; la nouvelle numérotation ne signifie pas un nouveau jeu. [Snapshot 2](https://www.minecraft.net/tr-tr/article/minecraft-26-1-snapshot-2), [sortie](https://www.minecraft.net/en-us/article/minecraft-java-edition-26-1), [numérotation officielle](https://www.minecraft.net/pl-pl/article/minecraft-new-version-numbering-system). |
+| **26.2 — Chaos Cubed, 16 juin 2026** | **Snapshot 1, 7 avril** : grottes de soufre, sulfur cube, cinabre et nouvelles sources. | Géologie sulfurée, soufre/cinabre constructibles, soufre puissant et interactions eau/chaleur produisant des geysers. Le sulfur cube absorbe des blocs et change de comportement physique. Vulkan est proposé expérimentalement : ne pas le transformer en disponibilité graphique universelle. [Premier snapshot](https://www.minecraft.net/da-dk/article/minecraft-26-2-snapshot-1), [sortie](https://www.minecraft.net/en-us/article/minecraft-java-edition-26-2). |
+| **26.3 — développement, pas encore stable au 11 septembre 2026** | **Snapshot 1, 23 juin** ; **préversion 1, 1er septembre** ; **RC1, 10 septembre**. | Dappled Forest, peupliers et feuilles colorées, champignons de tronc, arbustes rouges, camps abandonnés, dalles/escaliers de laine apparaissent en développement. Ne pas inventer une date de sortie stable ou confondre ce numéro avec Bedrock. [Nouveautés initiales](https://www.minecraft.net/en-us/article/minecraft-26-3-snapshot-1), [préversion](https://www.minecraft.net/en-us/article/minecraft-26-3-pre-release-1), [manifeste primaire Mojang](https://piston-meta.mojang.com/mc/game/version_manifest_v2.json). |
+
+## Bornes d’utilisation pour Sanctuary
+
+Au relevé du **11 septembre 2026**, le manifeste Mojang donne `latest.release = 26.2` et `latest.snapshot = 26.3-rc-1`. Cette dernière est datée du **10 septembre à 11:28:25 UTC** ; `26.3-pre-2`, utilisée comme base du dépôt, est datée du **4 septembre**. Le manifeste classe également les préversions et RC dans la catégorie technique `snapshot` : cela ne les rend pas stables. [Manifeste des versions Java](https://piston-meta.mojang.com/mc/game/version_manifest_v2.json).
+
+Le **16 mars 2026** est le repère de fondation fourni de mémoire par Koka, **en cours d’audit**. Si cette date est confirmée, **1.21.11** est alors la dernière Java stable ; **26.1 sort huit jours après**, le 24 mars. Les sorties ultérieures constituent l’histoire publique contemporaine de la partie ; leur transformation en événements vécus par les joueurs appartient à la conception, pas à cette recherche.
+
+Enfin, une cité de l’End, un bastion, une chambre d’épreuves ou un camp abandonné est un fait de génération documenté. En déduire ses constructeurs, leur disparition ou une catastrophe serait une interprétation supplémentaire. La chronologie permet de dater les matériaux, outils et formes de lieux ; elle ne fournit pas, à elle seule, un canon expliquant les ruines.

docs/recherche-minecraft-personnages.md

@@ -0,0 +1,175 @@
+# Personnages de Minecraft : chronologie et limites documentaires
+
+Recherche du **11 septembre 2026**, destinée à la conception de Sanctuary.
+Ce dossier sépare les dates de développement, les apparitions publiques et
+l’invention narrative. **Efe** est l’orthographe officielle, confirmée pour
+Sanctuary par Koka ; l’ancienne transcription « Mefe » n’est pas un dixième
+personnage. Aucun rôle individuel ni ordre d’arrivée fictif n’est fixé ici.
+
+## Ce que l’on peut dater
+
+La chronologie exploitable est **Steve, puis Alex, puis un groupe de sept**.
+Une date d’ajout de skin décrit un choix d’apparence disponible pour le joueur ;
+elle ne date ni la naissance du personnage ni son arrivée dans un monde fictif.
+De même, le premier modèle visible, l’annonce d’une version et le contenu du
+Launcher ne sont pas nécessairement contemporains.
+
+Les sources Mojang sont prioritaires pour les annonces et les contenus livrés.
+Minecraft Wiki sert à reconstituer les premières versions, avec prudence :
+plusieurs pages anciennes ne sont accessibles ici que par leurs extraits
+indexés. Les liens vers d’anciens billets Mojang ou tweets identifiés mais non
+relus sont signalés comme tels ; ils ne sont pas présentés comme des preuves
+primaires intégralement vérifiées.
+
+## Steve : distinguer modèle, joueur et nom
+
+Le modèle humain associé rétrospectivement à Steve apparaît dans
+**rd-132328, le 13 mai 2009**. Il sert d’abord à des entités autonomes. Son modèle
+est ensuite repris pour représenter les autres joueurs dans le premier test
+multijoueur **0.0.15a, le 31 mai 2009**. Il faut donc distinguer ces deux étapes,
+et éviter d’écrire que Steve était déjà un personnage nommé avec une biographie
+dans le tout premier prototype. La page actuelle du Wiki décrit cette filiation
+entre mob et joueur ; l’ancienne page du test multijoueur précise sa date.
+[Minecraft Wiki : Mob (entity)](https://minecraft.wiki/w/Mob_%28entity%29),
+[historique 0.0.15a conservé sur l’ancien Wiki](https://minecraft.fandom.com/wiki/Java_Edition_Classic_0.0.15a_%28Multiplayer_Test_1%29).
+
+Le **17 mai 2009** reste la date anniversaire publique célébrée par Mojang.
+Elle ne doit pas effacer les essais des jours précédents. Pour un calendrier
+Sanctuary comptant les jours depuis « le début de Minecraft », c’est un repère
+public solide, tandis que le 13 mai peut désigner la préhistoire des prototypes.
+[Mojang, anniversaire du 17 mai 2024](https://www.minecraft.net/en-us/article/the-15th-anniversary-cape).
+
+Le nom **Steve** est documenté bien plus tard, vers **octobre 2010**. Le Wiki
+renvoie à une intervention de Notch et à l’histoire du personnage invité dans
+*Super Meat Boy*. Le tweet original n’a pas pu être relu pendant cette recherche :
+retenir le mois, sans lui attribuer un jour ni reproduire une citation incertaine.
+L’orthographe interrogative « Steve? » appartient à cette histoire du nom ; elle
+ne prouve pas une identité secrète. Le réexamen des premiers noms communautaires
+montre justement pourquoi un surnom ancien ne suffit pas à établir un canon.
+[Discussion documentaire du Wiki et référence au tweet](https://minecraft.wiki/w/Talk%3AMob_%28entity%29).
+
+## Alex : 2014, avec une nuance sur les dates
+
+Alex est introduite dans **Java 1.8-pre1**, annoncée publiquement le
+**22 août 2014**, puis intégrée à la version stable **1.8 du 2 septembre 2014**.
+Cette apparition accompagne le modèle aux bras plus fins. Ce n’est pas une
+nouvelle espèce ni une profession imposée au joueur.
+[Minecraft Wiki : Alex](https://minecraft.wiki/w/Alex),
+[historique de la Bountiful Update](https://minecraft.fandom.com/wiki/Bountiful_Update).
+
+Le manifeste officiel contient toutefois un `releaseTime` au **21 août** pour
+1.8-pre1. Cette différence est conservée : l’horodatage du paquet ne remplace pas
+la date de publication attestée dans l’historique de l’annonce. Pour la version
+stable, les métadonnées confirment le 2 septembre. L’ancien billet Mojang de la
+préversion a été retrouvé par référence mais son contenu original n’était pas
+accessible à la relecture.
+[Métadonnées Mojang de 1.8-pre1](https://piston-meta.mojang.com/v1/packages/00ddc59925abc10e08047c94657e3365b1e031d6/1.8-pre1.json),
+[métadonnées de 1.8](https://piston-meta.mojang.com/v1/packages/9eb165eef46294062d8698c8a78e8ac914949e7a/1.8.json).
+
+## Ari, Sunny, Kai, Zuri, Efe, Makena et Noor : une même promotion
+
+Les sept nouveaux skins sont annoncés ensemble à **Minecraft Live, le
+15 octobre 2022**. Mojang précise que Sunny, Efe et Noor étaient déjà visibles
+dans les bandes-annonces de *The Wild Update*. Une apparition promotionnelle
+antérieure ne signifie donc pas que leur skin était déjà disponible dans le jeu.
+[Mojang, récapitulatif de Minecraft Live 2022](https://www.minecraft.net/en-us/article/minecraft-live-2022-the-recap).
+
+Le déploiement comporte plusieurs jalons :
+
+| Date | Événement établi | Portée exacte |
+| --- | --- | --- |
+| 20 octobre 2022 | Article présentant les sept nouveaux skins | Présentation officielle de leurs noms et du choix élargi. |
+| 20 octobre 2022 | Launcher 2.3.462 | Le Wiki recense leur ajout parmi les skins Java proposés par le Launcher. |
+| 9 novembre 2022 | Snapshot Java 22w45a | Ajout des nouveaux skins par défaut pour les joueurs hors ligne. |
+| 29 novembre 2022 | Bedrock 1.19.50 | Nouveaux skins sélectionnables dans le Dressing Room. |
+| 29 novembre 2022 | Vidéo officielle de lancement | Mojang annonce leur disponibilité au lancement du jeu à partir de cette date. |
+| 7 décembre 2022 | Java 1.19.3 stable | La version stable reprend les nouveaux skins hors ligne. |
+
+Sources de chaque jalon :
+[présentation Mojang du 20 octobre](https://www.minecraft.net/en-us/article/introducing-new-default-skins),
+[Wiki : Launcher 2.3.462](https://minecraft.wiki/w/Launcher_2.3.462),
+[snapshot 22w45a](https://www.minecraft.net/en-us/article/minecraft-snapshot-22w45a),
+[Bedrock 1.19.50](https://www.minecraft.net/en-us/article/1-19-50-update-available-bedrock),
+[vidéo Minecraft du 29 novembre](https://www.youtube.com/watch?v=oXKVfLTrdBM),
+[Java 1.19.3](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-19-3).
+
+Ces sources ne donnent **aucune succession individuelle d’ajouts** entre les
+sept. L’ordre « Ari, Sunny, Kai, Zuri, Efe, Makena, Noor » peut être conservé pour
+présenter le groupe dans Sanctuary, mais pas comme une chronologie Minecraft.
+Une éventuelle succession de leurs arrivées sur Sanctuary devra être écrite et
+validée comme fiction. Il ne faut pas inventer sept mises à jour différentes
+pour obtenir artificiellement neuf époques correspondant aux neuf noms.
+
+## Apparences officielles et biographies inventées
+
+Mojang présente les skins comme des apparences permettant aux joueurs de raconter
+leurs propres histoires. Les neuf constituent des options, avec des modèles
+larges et fins ; l’article ne leur attribue pas neuf spécialités nécessaires au
+fonctionnement du monde. Une tenue, une bande-annonce ou un accessoire ne suffit
+pas à imposer pour toujours le métier, la personnalité ou la filiation d’un
+personnage.
+[Mojang : Introducing new default Minecraft skins](https://www.minecraft.net/en-us/article/introducing-new-default-skins).
+
+Pour Sanctuary, « Steve a construit cet atelier » ou « Efe a travaillé sur cette
+installation » sera donc une décision d’auteur. Elle pourra s’appuyer sur le
+catalogue d’objets disponible à une époque, mais elle ne devra pas être présentée
+comme une révélation de Mojang. Les adaptations, vidéos promotionnelles et jeux
+dérivés demandent eux aussi un périmètre explicite : on ne fusionne pas leurs
+scènes en une biographie unique par défaut.
+
+## Endermen, anciens bâtisseurs et Herobrine
+
+L’explication officielle de la **création des Endermen**, donnée par Jens dans
+un article de 2017, cite l’inspiration du Slenderman et indique que l’End a été
+conçu après le mob. C’est une histoire de développement. Elle n’établit pas
+qu’une civilisation humaine s’est transformée en Endermen. Le récit des
+« anciens bâtisseurs » et de leur métamorphose doit rester identifié comme
+théorie communautaire ou réécriture propre à Sanctuary.
+[Mojang : Meet the Enderman](https://www.minecraft.net/en-us/article/meet-enderman).
+
+La présence de villes et de navires dans l’End fournit des vestiges à interpréter.
+La présentation officielle du biome décrit leurs habitants, leurs dangers et
+leur réutilisation possible comme camp ; elle ne nomme pas Steve, Alex ou les
+sept comme constructeurs. L’absence de signature peut nourrir le mystère sans
+obliger à trancher immédiatement l’origine de chaque structure.
+[Mojang : End Highlands](https://www.minecraft.net/en-us/article/around-block--end-highlands).
+
+La mention **« Removed Herobrine »** figure réellement dans des changelogs,
+par exemple celui de Java 1.16.2. Elle ne constitue pas une preuve de présence
+antérieure d’un mob Herobrine : le texte officiel archivé des suggestions
+écartées refuse les creepypastas. Une référence au folklore peut être étudiée
+séparément ; elle ne transforme pas Herobrine en dixième skin historique ni en
+cause établie de la disparition des neuf.
+[Java 1.16.2](https://www.minecraft.net/en-us/article/minecraft-java-edition-1-16-2),
+[politique archivée, mise à jour le 7 mai 2020](https://feedback.minecraft.net/hc/en-us/articles/360005029872--Archived-Previously-Considered-Suggestions).
+
+## Les anciens modèles de Dock ne complètent pas le groupe
+
+Rana et les variantes autrefois appelées « Steve », « Black Steve » et
+« Beast Boy » appartiennent aux essais de modèles d’Indev, fin 2009 et janvier
+2010. Le Wiki actuel distingue le nom de Rana des trois surnoms communautaires
+des autres variantes. Ils ne constituent pas trois prédécesseurs biographiques
+du skin Steve et ne doivent pas être ajoutés par défaut aux neuf personnages
+retenus. Leur intérêt éventuel pour Sanctuary serait celui d’une trace des
+formes abandonnées du développement.
+[Minecraft Wiki : modèles historiques du mob](https://minecraft.wiki/w/Mob_%28entity%29).
+
+## Conséquences pour la mythologie de Sanctuary
+
+La matière historique permet d’imaginer des couches d’occupation correspondant à
+des possibilités successives du jeu : construire, transporter, automatiser,
+observer, explorer plus loin. Il est préférable de dater une **solution** par ses
+matériaux et ses techniques, puis de choisir ses auteurs, plutôt que d’attribuer
+automatiquement chaque grande mise à jour à un nouveau personnage.
+
+Les neuf peuvent avoir modifié les mêmes installations, laissé des réparations,
+poursuivi le travail d’autres personnes ou retrouvé leurs méthodes. Cette piste
+sert la formule retenue : une infrastructure dont l’auteur disparaît derrière
+son fonctionnement. Elle demeure une proposition de récit, sans généalogie ni
+responsabilité encore assignée.
+
+Galactium, le cube originel, ses six faces et son septième champ central sont
+des éléments propres à la conception de Sanctuary. La chronologie documentée
+n’impose pas de faire correspondre les sept skins de 2022 aux sept champs, ni
+de placer Steve et Alex hors de la cosmologie. Ce rapprochement peut être
+discuté pour sa valeur narrative, mais ne découle pas de l’histoire officielle.

docs/redstone-computer-reference.md

@@ -0,0 +1,127 @@
+# Redstone Computer — référence et proposition pour Sanctuary
+
+**Lecture du 10 septembre 2026, WG-26.** Référence locale demandée par l’auteur :
+`/Users/koka/Documents/sanctuary/Redstone/redstone_computer`.
+Le README et les sources ont été lus, sans compilation ni essai en jeu. Le
+manifeste indique Redstone Computer 2.0.0, Minecraft 26.1.2, auteur KOKA99CAB et
+licence GPL-3.0-or-later. Cette lecture ne vérifie pas un portage vers 26.3.
+
+Le dossier historique `26.2/redstoner` a été consulté ponctuellement pour sa VM.
+Ces deux références restent intactes. Aucune de leurs classes n’est importée
+dans Sanctuary par ce cahier.
+
+## Capacités retrouvées dans le code
+
+Les trois profils sont définis dans `program/ProgramTarget.java` :
+
+| Machine historique | RAM en octets logiques | Budget d’instructions par tick |
+| --- | --- | --- |
+| Redstone Computer 8 bits | 256 | 96 |
+| Redstone Controller | 1 024 | 256 |
+| Personal Computer | 4 096 | 1 024 |
+
+Ces valeurs décrivent l’ancienne version ; elles ne sont pas des réglages validés
+pour les futurs contrôleurs Sanctuary.
+
+- `vm/RedstoneProgram.java` : assembleur interprété, labels, sauts, calculs,
+  logique, registres A–D sur 8 bits, indicateurs de comparaison et RAM adressable.
+- `block/entity/RedstoneComputerBlockEntity.java` : six faces de lecture/émission
+  redstone 0–15, comparateur, impulsions, inventaire d’entrée/sortie, reconnaissance
+  d’items et transfert conditionnel vers des inventaires adjacents.
+- `block/entity/BusConnectorBlockEntity.java`, `IoExtenderBlockEntity.java` et
+  `DisplayMatrixBlockEntity.java` : échanges cadencés, extensions d’entrées/sorties,
+  affichages et adressage. Le mod dispose aussi d’un détecteur de pluie.
+- `src/client/java/fr/koka99cab/redstone_computer/gui/RedstoneComputerScreen.java` : édition du code et exemples de porte
+  logique, filtre d’items, relais de bus et mémoire commandée par une horloge.
+- `network/PersonalComputerNetworking.java` : programmes enregistrés, catalogue
+  public, contrôle à distance, gestion d’appareils associés et transfert de propriété.
+- `server/RedstoneComputerServer.java` : lecture de collection, advancements et
+  statistiques personnelles pour alimenter des programmes.
+- `server/ComputerNetworkService.java` : appareils liés par identifiant et code,
+  consultation de leur état et possibilité de garder leurs chunks chargés.
+
+Le langage lit des ports et appelle les opérations définies par son interface
+`Host`. Dans le code parcouru, il ne fournit pas une instruction d’exécution
+arbitraire de commandes opérateur. Les transferts déplacent des items existants ;
+ce n’est pas une machine de création libre de blocs.
+
+## Points à reprendre autrement
+
+**Le processeur n’est pas continu dans cette référence.** `RedstoneProgram.tick`
+crée un nouveau CPU et repart à l’instruction zéro à chaque tick. Registres,
+indicateurs et position d’exécution sont recréés. Le message de budget atteint
+n’implique pas une reprise à l’instruction suivante. La RAM, le programme,
+l’inventaire et les impulsions sont néanmoins sauvegardés par l’entité de bloc.
+
+Le projet Sanctuary souhaite un ordinateur dont l’état complet peut être
+retrouvé. Cela demande de concevoir la continuité du processeur, ses attentes,
+ses arrêts et les opérations déjà effectuées, puis de les vérifier en sauvegarde
+et rechargement. La conservation de RAM seule ne suffit pas.
+
+Les transferts sont limités jusqu’à 64 items par instruction, sans budget global
+de débit par machine. Les budgets de calcul historiques ne donnent donc pas à
+eux seuls un équilibre de production ou une garantie de performance du serveur.
+Un registre d’adresse doit aussi permettre d’exploiter la RAM étendue : un
+registre de données 8 bits seul ne couvre que 256 adresses en accès indirect.
+
+L’ancien réseau autorise quatre appareils épinglés par profil et un plafond
+global de chunks forcés de 128 par défaut. Pour Sanctuary, le maintien en activité
+doit être raccordé au système **Chunky et clés de chunk** déjà prévu. Un programme
+ou un terminal réseau ne doit pas offrir un second accès gratuit à cette fonction.
+
+Les connaissances et statistiques de l’ancien ordinateur font désormais doublon
+avec le Blocodex et le recensement Sanctuary : proposer des consommateurs de ce
+socle commun. Les compteurs exacts ne doivent pas être ramenés silencieusement à
+255 pour tenir dans un registre ; une représentation ou un protocole est à choisir.
+
+Les tests historiques lus portent notamment sur les impulsions et les profils
+mémoire. Ils ne constituent pas une validation du futur CPU continu, des actions
+matérielles ou de la charge d’un serveur Sanctuary.
+
+## Proposition : une grande puissance obtenue en survie
+
+« Code légal » est compris ici comme une capacité très puissante construite et
+utilisée dans la partie, avec les ressources et déblocages du jeu. La puissance
+recherchée vient de ce que le joueur peut composer avec ses programmes.
+
+Proposer un **socle autonome de calcul et de redstone programmable**, auquel
+Sanctuary raccorde ses fonctions particulières. Ce découpage est une proposition
+d’architecture, pas la création d’un nouveau mod ou d’identifiants.
+
+| Pouvoir proposé | Effet intéressant | Condition matérielle ou de progression |
+| --- | --- | --- |
+| Circuits programmables | Horloges, mémoires, séquenceurs, serrures, ascenseurs, aiguillages et petits jeux. | Ports physiques, entrées réelles et exécution bornée. |
+| Production pilotée | Reconnaître, compter, trier, traiter des lots et coordonner des machines. | Inventaires et périphériques accessibles ; débit de transfert explicite. |
+| Programmes partageables | Récupérer, comprendre, adapter et transmettre un montage fonctionnel. | Code copiable, matériel à construire et autorisations propres à l’installation. |
+| Construction assistée — piste ultérieure | Produire un plan, puis commander sa réalisation avec des matériaux connus. | Appareil de placement à concevoir, vraie réserve de blocs, zone et cadence définies. Connaître un matériau ne le fournit pas. |
+| Installations spatiales Sanctuary | Préparer une expansion, établir une liaison ou piloter un accès à un espace. | Ancre, dépôt et autres appareils à définir ; destinations, ressources et déblocages validés côté serveur. |
+
+La liberté du langage doit permettre de créer des montages imprévus. Les limites
+portent sur la mémoire, le temps de calcul et les capacités des périphériques.
+Un code long attend son prochain budget ; il ne recommence pas silencieusement
+au début. Le premier budget n’est pas fixé par cette lecture.
+
+La copie d’un programme est une manière de partager un savoir. Les joueurs
+peuvent construire et utiliser des installations communes sans tous devenir
+programmeurs. Les ruines pourraient fournir des montages lisibles par leurs
+anciens usages : pompage, orientation, production, puis opérations spatiales.
+
+Le galactique conserve son rôle de langage opératoire proposé dans le
+[cahier des machines](langage-et-machines.md). Les pouvoirs spatiaux demeurent
+soumis à leur progression, dont le déblocage collectif permanent des portails
+de minage. L’origine des glyphes et leur lien aux Endermen restent à écrire.
+
+## Première preuve jouable proposée
+
+Le socle Sanctuary retient désormais trois blocs : contrôleur à six faces avec
+RAM intégrée, terminal et afficheur, plus les disquettes. L’assemblage du code
+est une fonction du terminal. Un compteur d’impulsions pilotant une porte suffirait à éprouver
+la première version avec les blocs redstone ordinaires, sans périphérique de
+manipulation d’items. Programme et état seraient inspectables, sauvegardés et
+repris après rechargement. Un autre joueur pourrait réutiliser le code avec son
+propre matériel. Le tri et les autres périphériques restent des extensions.
+
+Cette preuve testerait la continuité du CPU, l’utilité en survie et le partage
+avant les fonctions spatiales. Taille mémoire, coût, alimentation, débit et
+forme des blocs restent à concevoir ensemble. Aucune livraison n’est lancée
+par cette proposition.

docs/redstone-language-composants.md

@@ -0,0 +1,270 @@
+# Redstone Language — fiches des composants
+
+**Proposition de conception, WG-26 ; aucun bloc ni comportement livré.** Ces
+fiches complètent le [cahier du langage](langage-et-machines.md),
+l’[ISA proposée](redstone-language-instructions.md) et
+l’[audit redstone](audit-redstone-26.3.md). Les
+[extensions](redstone-language-extensions.md) et les
+[composants de signal et transport](redstone-language-signaux-et-transport.md)
+explorent les appareils supplémentaires. Ces fiches rendent le premier ensemble
+constructible et compréhensible en jeu. Les paragraphes **Retenu** rappellent
+les choix de l’auteur ; les gestes, valeurs, interfaces et règles de conservation
+marqués **Proposition** forment un contrat à éprouver, sans devenir du canon.
+
+## Ensemble et règles communes
+
+**Retenu :** trois blocs informatiques — contrôleur, terminal, afficheur — et
+une disquette de programme. Le particuleur est un appareil complémentaire,
+utilisable sans ordinateur. L’assemblage appartient au terminal ; processeur et
+RAM sont intégrés au contrôleur. Aucun bloc Assembleur, lecteur de disquette,
+module RAM ou bus de données supplémentaire n’est nécessaire à cet ensemble.
+
+**Proposition commune :** les gestes portant sur les objets et la configuration
+aboutissent côté serveur. Un menu affiche l’état confirmé, pas un résultat
+anticipé. Les blocs posés conservent leur orientation et ne tournent pas sous
+un clic de configuration. Pour les déplacer, on les récupère puis on les repose.
+Un objet tenu qui n’a pas d’usage propre sur l’appareil garde son interaction
+habituelle ; sneak avec un bloc permet notamment de construire contre lui.
+
+La [clé à molette dorée](machines-multiblocs.md#clé-à-molette-dorée--assembler-désassembler-et-orienter)
+est retenue pour orienter des blocs, assembler volontairement et dissocier les multiblocs.
+Son application aux appareils de cette fiche reste à définir : elle serait
+une interaction explicite avec un outil tenu, distincte des clics de configuration
+main vide. Pour le contrôleur, tourner la façade ne remapperait ni les ports
+cardinaux, ni le programme ; l’état de travail serait conservé et les connexions
+revérifiées à l’arrêt ou en pause avant reprise.
+
+| Matière et déplacement — propositions | Comportement du premier ensemble |
+| --- | --- |
+| Eau | Blocs non waterloggables, pose en cellule sèche ; aucun bonus, court-circuit ou destruction électrique simulé. L’eau n’entre pas dans leur volume. |
+| Pistons | Les quatre types de blocs ne sont ni poussés ni tirés ; pas de copie de leur état par déplacement. |
+| Support | Contrôleur et particuleur sont des blocs pleins ordinaires. Terminal et afficheur se fixent sur une face verticale solide ; perdre ce support provoque leur dépose. Les composants d’un écran doivent donc avoir chacun un support. |
+| Récupération | Proposition : pioche pour récupérer l’appareil ; ses objets internes sont conservés ou rendus une seule fois selon les fiches ci-dessous. Pas d’obligation de Silk Touch pour retrouver un programme. |
+| Destruction sans récupération | Aucune seconde machine ni sauvegarde portable n’est créée. Une éventuelle restitution Sanctuary appartient à son contrat propre. |
+| Indices | Faces, prises, fentes et témoins intégrés permettent de reconnaître entrées, sorties, marche et erreur. Couleur et forme se complètent ; aucun panneau explicatif généré n’est nécessaire. |
+
+Les entrées redstone lisent ce qui arrive réellement au bloc. Les sorties ne
+sont pas une alimentation forte omnidirectionnelle gratuite : seuls les ports
+prévus émettent, selon un raccord redstone à vérifier sur le jeu exact.
+Les lectures de périphériques et les transferts d’objets ne sont pas des
+intensités électriques cachées.
+
+## Contrôleur — la machine qui continue
+
+**Retenu :** assembleur direct, six faces d’entrée/sortie, RAM adressable et
+fonctionnement autonome après retrait du terminal.
+
+**Profil d’essai proposé :** 1 Kio de RAM, quatre registres de 8 bits et au plus
+64 instructions exécutées par tick serveur. Code et RAM sont distincts ; les
+adresses doivent couvrir la RAM entière. Ce sont des valeurs de prototype,
+pas des caractéristiques déjà validées. Le détail des instructions appartient
+à l’[ISA proposée](redstone-language-instructions.md).
+
+| Fiche — propositions | Comportement |
+| --- | --- |
+| Forme et placement | Petit bloc technique plein, façade de repérage tournée vers le joueur. Les six ports restent identifiables sur toutes les faces. Les adresses physiques suivent les directions du monde ; changer la pose ne remappe pas silencieusement le programme. |
+| Clic droit, main vide | Ouvre la configuration locale des faces et un résumé de marche ; l’édition du programme se fait au terminal. |
+| Sneak + clic droit, main vide | Ouvre directement la fiche de la face visée. Aucun changement de mode au simple toucher. |
+| Objet tenu | La disquette ne se charge pas directement dans ce bloc : elle utilise le terminal. Poser un terminal ou un afficheur contre une face reste un geste de construction. |
+| Entrées/sorties | Chaque face prend exactement un mode : **OFF**, **IN**, **OUT** ou **DEVICE**. IN lit l’intensité 0–15 réellement reçue par cette face. OUT fournit seulement un signal faible 0–15 sur cette face, jamais un signal fort ; les autres faces ne relaient pas sa valeur. DEVICE adresse un appareil adjacent compatible et n’émet pas simultanément de redstone. OFF ne fait ni l’un ni l’autre. |
+| Réglage des faces | Machine arrêtée ou en pause ; le changement désactive d’abord les sorties concernées. Les faces non configurées sont OFF. Un périphérique manquant donne un état indisponible, sans charger un chunk pour le chercher. |
+| Comparateur et inventaire | Pas de sortie de comparateur dédiée ni d’inventaire d’objets. RAM occupée et valeur du dernier port ne sont pas un remplissage de coffre. |
+| Indices | Port rentrant, sortant ou prise distincte ; témoins de marche, pause et erreur. Le terminal fournit le détail utile au dépannage. |
+
+**Proposition d’état :** le contrôleur conserve le document de programme
+(source, bytecode correspondant, version et crédits), la RAM, les registres,
+le compteur d’instruction, la pile d’appels, les indicateurs, l’attente, les
+valeurs mémorisées des sorties et la configuration des faces. HALT, pause et
+erreur mettent immédiatement les sorties électriques à zéro. Une reprise
+explicite ne réémet pas une ancienne valeur avant le calcul
+prévu par le programme. Arrêter le CPU n’annule pas une opération serveur déjà
+engagée par une installation : son journal conserve son autorité.
+
+Un rechargement de la machine en place reprend son état sauvegardé : une machine
+en marche continue au compteur d’instruction conservé, une machine arrêtée
+reste arrêtée. Pour la machine en marche, les valeurs mémorisées des sorties
+sont restaurées, puis modes de ports, connexions et entrées sont relus avant
+leur réémission sur les faces OUT valides. Le CPU ne repart pas au début et
+ne rejoue pas une instruction pour reconstruire ces valeurs. Il n’y a pas de
+rattrapage des ticks pendant lesquels le chunk ou le serveur n’exécutait pas
+la machine.
+
+**Casse et récupération proposées :** couper les sorties, puis transférer une
+seule fois le document et l’état de travail dans l’objet machine, marqué
+**STOPPED**, avec RAM, compteur d’instruction et pile conservés. Sa repose
+demande une reprise explicite au terminal pour continuer à cet endroit. Une
+relance distincte repart au début du même programme, remet le CPU à l’état
+initial et conserve la RAM. L’appareil ne démarre pas seul dans un coffre,
+une main ou une nouvelle installation. L’export sur disquette ne copie pas
+cet état de travail.
+
+## Terminal — écrire et examiner
+
+**Retenu :** éditeur d’assembleur, vérification, assemblage, lecture/écriture des
+disquettes, inspection et commandes d’exécution. Il n’exécute pas le CPU à la
+place du contrôleur et n’est pas nécessaire à son fonctionnement continu.
+
+| Fiche — propositions | Comportement |
+| --- | --- |
+| Placement | Console fixée contre un contrôleur : son dos touche une face DEVICE et sa façade reste accessible. Un terminal correspond à ce seul contrôleur adjacent ; aucun réseau distant implicite. |
+| Clic droit, main vide | Ouvre l’éditeur et les vues programme, RAM, registres et ports. Sans connexion valide : écran déconnecté, sans machine locale de remplacement. |
+| Sneak + clic droit, main vide | Retire la disquette présente, rendue dans l’inventaire ou déposée au sol si nécessaire. |
+| Disquette tenue | Insère un seul support si la fente est libre ; une fente occupée ne détruit ni ne remplace automatiquement son contenu. Le menu propose ensuite lire, charger ou enregistrer. |
+| Autres entrées/sorties | Dialogue avec le contrôleur par son dos DEVICE ; aucune émission redstone ni alimentation obligatoire pour l’éditeur dans ce prototype. |
+| Comparateur | Proposition : 0 sans disquette, 15 avec disquette. Cela n’indique ni validité du code ni avancement du CPU. |
+| Automatisation | Insertion d’une disquette par dessus ou côtés libres, extraction par dessous. La façade et le dos de connexion n’exposent pas la fente. Un hopper change le support présent, jamais le programme chargé. |
+
+**Une seule source de travail proposée :** le contrôleur possède le document
+éditable. Le terminal en présente une vue ; il ne garde pas une deuxième copie
+persistante indépendante. Sans contrôleur, il ne propose donc pas d’éditeur
+autonome. Plusieurs vues éventuelles utilisent la révision du même document,
+sans écraser silencieusement une modification concurrente.
+
+Éditer ou assembler demande un CPU arrêté ou en pause ; charger un autre
+programme exige l’état arrêté. Les modifications
+forment une révision source marquée non assemblée : tant que le bytecode de
+cette révision n’est pas validé, elle ne peut pas être exécutée ou exportée
+comme programme prêt. Un assemblage raté laisse les données de travail intactes
+et les sorties arrêtées. Charger un autre programme remplace explicitement le
+document, remet RAM, registres et exécution à leur état initial et laisse le
+CPU arrêté : la RAM est alors entièrement à zéro. Relancer le même programme
+garde sa RAM ; reprendre une pause conserve aussi le compteur d’instruction,
+la pile et l’attente.
+
+**Retrait proposé :** casser seulement le terminal ne détruit ni n’arrête le
+contrôleur. Le terminal tombe comme appareil vide ; la disquette tombe séparément
+une seule fois. Le contenu de l’éditeur reste dans le contrôleur. Une fente
+visuellement occupée, le petit écran et l’indication de connexion suffisent à
+rendre l’usage lisible.
+
+## Afficheur — un écran construit
+
+**Retenu :** panneaux coplanaires de même orientation, rectangle plein, raccord
+visuel CTM et **huit lignes par bloc en hauteur**. Le texte traverse les joints ;
+ce n’est pas une copie du texte sur chaque panneau. L’écran tactile n’appartient
+pas au premier ensemble.
+
+**Valeurs d’essai proposées :** au plus **8 × 4 panneaux**, avec **16 colonnes
+logiques par bloc**. Un écran maximal aurait 128 colonnes et 32 lignes. La grille
+doit être essayée avec les glyphes galactiques, les accents et les traductions.
+Un glyphe large peut occuper deux cases : seize colonnes ne garantissent pas
+seize caractères de toute écriture. La prise en charge des glyphes CJK reste
+à vérifier avec le rendu, sans promettre une police déjà disponible.
+
+| Fiche — propositions | Comportement |
+| --- | --- |
+| Pose et orientation | Panneau sur face verticale solide, avant tourné vers la pièce. Raccord seulement entre côtés de même plan et même orientation ; pas autour d’un angle. |
+| Clic droit, main vide | Ouvre la configuration de l’écran : texte autonome, entrée analogique ou pilotage DEVICE. Ce menu de configuration n’en fait pas un écran tactile programmable. |
+| Sneak + clic droit, main vide | Montre l’ancre, les dimensions et les panneaux en attente, sans changer de groupe ni effacer le texte. |
+| Objet tenu | Aucun inventaire. Un panneau tenu se pose normalement ; pas de disquette directement dans la surface. |
+| Connexion | Un seul contrôleur pilote le rectangle, par une face DEVICE touchant le dos d’un de ses panneaux. L’extension de bus propose une prise de données pleine qui assure à la fois support et connexion distante. Une seconde connexion ne remplace pas automatiquement la première. |
+| Modes autonomes | Texte statique conservé ou lecture 0–15 au dos d’un panneau d’entrée désigné, pour nombre, jauge ou sélection de texte. Le mode DEVICE désactive cette entrée analogique. |
+| Sorties et comparateur | Aucun signal redstone, aucune sortie de comparateur et aucun transfert d’objets. Un contenu chiffré n’est pas une mesure électrique envoyée aux voisins. |
+
+Le contrôleur étant un bloc plein à face solide, il peut servir directement de
+support au panneau connecté : sa face DEVICE touche le dos de ce panneau.
+Les autres panneaux reposent sur les blocs solides voisins. Aucun câble ou
+bloc de support intermédiaire ne s’insère entre la prise et le panneau ; un
+terminal utilise une autre face DEVICE libre du contrôleur.
+
+**Construction progressive proposée :** un premier panneau crée une ancre 1 × 1.
+Des panneaux vierges ajoutés au bord sont adoptés comme extensions ; l’ancien
+rectangle reste actif pendant une rangée incomplète. L’agrandissement cherche
+localement le plus grand rectangle plein contenant toute la surface active,
+dans la limite d’essai. À égalité, largeur puis hauteur donnent un choix stable.
+Il ne déplace pas l’ancre et ne réorganise pas l’écran à chaque chargement.
+Deux écrans déjà configurés restent distincts : leur simple contact ne fusionne
+ni leurs textes ni leurs contrôleurs.
+
+**Conservation proposée :** seule l’ancre possède le texte et la configuration ;
+les autres panneaux conservent une référence de groupe. Déconnexion ou pause du
+contrôleur fige la dernière image avec un indice de liaison interrompue. Elle
+ne transforme pas les panneaux en copies autonomes du programme.
+
+Casser un panneau invalide la surface s’il manque une case : affichage du groupe
+suspendu, contenu intégral conservé dans l’ancre. Les morceaux ne deviennent
+pas autant d’écrans configurés. Recompléter le rectangle réactive le groupe.
+Si l’ancre est récupérée, **un seul panneau-objet** transporte sa configuration
+et son contenu ; les panneaux restants deviennent orphelins, sans texte dupliqué.
+Reposer cette ancre au raccord attendu peut restaurer le groupe. Une remise à
+zéro explicite permet de réutiliser un panneau orphelin comme panneau vierge.
+Une réduction volontaire de surface masque le débordement sans supprimer le
+contenu conservé ; aucun texte n’est perdu par simple redimensionnement.
+
+## Disquette — transporter un programme
+
+**Retenu :** support physique partageable, copiable et revendable, utilisable
+au terminal. La lecture du programme permet d’étudier et de reprendre un montage.
+
+**Proposition :** une disquette contient un programme avec source, bytecode
+correspondant, version de format et de langage, nom et crédits. Elle ne transporte
+ni RAM, ni registres, ni état d’attente, ni autorisation d’achat ou d’expansion.
+La capacité d’essai est de **16 Kio de source UTF-8 et 512 instructions au plus**,
+en accord avec l’[ISA proposée](redstone-language-instructions.md). Un dépassement
+refuse l’enregistrement sans tronquer le programme ; son nom ne remplace pas
+son format ni sa validation.
+
+- Clic droit sur le terminal : insertion ; main vide sur le terminal : menu ;
+  sneak + main vide : retrait. Sur les autres blocs, la disquette ne lance rien.
+- Lire affiche le contenu sans modifier le contrôleur. Charger exige un CPU
+  arrêté et importe un programme valide dans son document de travail. Le support
+  peut ensuite être retiré : le contrôleur garde son programme.
+- Enregistrer exporte la révision assemblée du contrôleur vers une disquette
+  vierge, ou remplace explicitement le contenu du support inséré. L’insertion
+  d’un disque enregistré ne constitue jamais à elle seule une demande d’effacement.
+- Copier utilise le même parcours : importer, retirer l’original, insérer un
+  support vierge, enregistrer. La copie emploie réellement ce support ; elle ne
+  clone pas la machine. Crédits d’origine et adaptation restent distingués.
+- Format inconnu ou code invalide : lecture signalée comme impossible, sans
+  vider le support ou la machine. Un programme reçu n’obtient aucun droit nouveau.
+
+La disquette est un objet rangeable et transportable par les conteneurs usuels,
+sans comportement propre de piston, d’eau ou de comparateur. Hors terminal,
+elle suit les règles d’objet au sol et de destruction du jeu. Le passage dans
+un hopper ne l’exécute pas. Une étiquette lisible et une différence entre vierge
+et enregistrée suffisent au premier aspect visuel.
+
+## Particuleur — choisir un effet, régler son débit
+
+**Retenu :** clic droit avec un objet pour choisir le type de particules,
+insertion par dropper et débit lié au signal : **0 arrête ; 1–15 émet de plus
+en plus**. Le contrôleur peut commander cette redstone ordinaire, sans être
+nécessaire au particuleur.
+
+| Fiche — propositions | Comportement |
+| --- | --- |
+| Corps et pose | Bloc plein avec bouche visible, orientable suivant les six directions. Il projette depuis cette bouche, pas depuis un voisin invisible. |
+| Emplacement | Un seul objet-échantillon conservé et non consommé par les émissions. C’est une proposition : l’ancienne version l’utilisait ainsi, mais la consommation n’est pas encore tranchée pour la reprise. |
+| Clic avec objet | Insère un objet, ou remplace l’échantillon en rendant le précédent. Le même objet déjà présent ne consomme pas une seconde unité. |
+| Main vide | Clic droit retire l’échantillon ; sneak + clic droit fait le même retrait, sans changer la direction. |
+| Automatisation | Dropper ou hopper vers le dessus, les côtés ou l’arrière pour remplir l’emplacement vide ; extraction par dessous. La bouche n’expose jamais d’inventaire : orientée vers le bas, elle empêche donc cette extraction inférieure. Pour un changement automatique d’effet, choisir une autre orientation. |
+| Redstone | Lire le meilleur signal reçu 0–15 ; ne rien émettre électriquement et ne pas alimenter fortement les voisins. La bouche reste un débouché visuel, pas une sortie redstone. |
+| Débit d’essai | Exemple à tester : **2 × signal particules par seconde**, réparties dans le temps. Ce n’est pas une valeur retenue ; taille, vitesse et portée ne croissent pas automatiquement avec le signal. |
+| Vide ou objet sans effet | Aucune émission ; indice discret de fente vide ou d’échantillon sans correspondance. Pas de nuage de remplacement implicite. |
+| Comparateur | 0 vide, 15 occupé, même si l’échantillon n’a pas d’effet reconnu. Il indique une présence, pas le type de particule ni le débit. |
+| Récupération | Appareil et échantillon rendus séparément, une seule fois. Le bloc récupéré ne garde pas une seconde copie de l’objet inséré. |
+
+**Table proposée :** associer les objets à des familles d’effets compréhensibles,
+par exemple charbon de bois/fumée, bloc musical/notes, mousse/spores. La table
+exacte et les objets moddés restent à choisir ; une particule de flamme ne met
+pas le feu et une particule d’eau ne crée pas de fluide. Un budget d’émission et
+des réglages visuels permettront de maîtriser le coût de plusieurs appareils.
+
+Une sortie du contrôleur règle le débit ; une autre peut déclencher le dropper
+ou verrouiller un hopper. Changer l’échantillon exige toujours un transfert
+physique réussi. Une future interface d’inventaire pourrait l’effectuer avec
+son propre contrat ; le signal 0–15 n’encode pas une identité d’objet.
+
+## Trois montages pour éprouver l’ensemble
+
+| Montage proposé | Ce que l’on comprend en observant |
+| --- | --- |
+| Réserve régulée | Coffre et comparateur vers IN ; contrôleur vers verrou de hopper ; afficheur connecté montrant la mesure 0–15. Retirer le terminal ne coupe pas la régulation. |
+| Atelier visible | Contrôleur produisant une sortie variable vers un particuleur à fumée. La quantité suit l’activité calculée ; l’échantillon détermine l’apparence. |
+| Programme transmis | Un montage fonctionne ; son terminal permet de lire le code, d’enregistrer une disquette et de charger un second contrôleur arrêté. Le deuxième reçoit le programme, pas le stock, la RAM ou les droits du premier. |
+
+Ces fiches n’ajoutent aucune recette définitive ni identifiant de registre.
+Pistes matérielles seulement : pierre lisse et cuivre pour les boîtiers, redstone
+pour les circuits, verre pour les surfaces, papier et métal pour les supports.
+Quantités, coûts, progression, textures et compatibilité restent à éprouver dans
+le ticket d’implémentation.

docs/redstone-language-extensions.md

@@ -0,0 +1,476 @@
+# Redstone Language — ensemble et nouveaux composants
+
+**Proposition V0.1, WG-26, 11 septembre 2026. Documentation, sans implémentation.**
+Le socle retenu reste contrôleur, terminal, afficheur et disquettes, complété
+par le particuleur. Ce socle n’interdit pas d’inventer d’autres blocs : **un
+besoin que le montage ne sait pas résoudre peut révéler un composant manquant.**
+Les nouveaux noms et les valeurs ci-dessous constituent une proposition à
+examiner ensemble, pas des fonctionnalités déjà validées ou livrées.
+
+Le dossier forme désormais un ensemble de travail :
+
+| Partie | Contrat proposé |
+| --- | --- |
+| [Instructions](redstone-language-instructions.md) | Grammaire, registres, mémoire, calcul, branchements, ticks, signaux, échanges périphériques, erreurs et reprise. |
+| [Composants du socle](redstone-language-composants.md) | Placement, clics, six faces, disquettes, écran rectangulaire, inventaires, casse et conservation. |
+| [Signal et transport](redstone-language-signaux-et-transport.md) | Condensateur retenu ; convoyeur en cuir à vitesse unique, posé comme un rail, arrêté sans redstone. Inversion à choisir ; moteur optionnel proposé. |
+| [Objets, outils et cristaux](redstone-language-objets-et-cristaux.md) | Exploration ouverte d’appareils ; rôle des objets insérés et phénomènes physiques. Tâches locales des villageois payées en émeraudes. |
+| [Machines multiblocs](machines-multiblocs.md) | 27 fours pour le grand four partagé avec It's Alive ! (nom proposé : Fourneau) ; Fût de 27 barils ; grand baril de fermentation ; collections visibles et méga-pistons. Trémie à 45 cases ; Carillon par assemblage adjacent choisi. Clé à molette dorée pour orienter, assembler volontairement et dissocier ; blocs indépendants à la pose. Métablit et autres pistes restent à explorer. |
+| Ce document | Nouveaux composants révélés par les besoins, connexions, profils de données et montages. |
+| [Audit vanilla](audit-redstone-26.3.md) | Ce que Minecraft Java 26.3-pre-2 fournit effectivement ; comparaison avec les intentions Sanctuary. |
+| [Langage et Galactium](langage-et-machines.md) | Direction culturelle, exploration, progression et installations spatiales. |
+
+Les règles V0.1 précisent les anciennes pistes ouvertes ; leurs chiffres restent
+un profil d’essai. Elles ne sont ni une compatibilité avec l’ancien assembleur,
+ni une nouvelle version du pack.
+
+## Trouver le bloc derrière le manque
+
+Le programme calcule. Un capteur rend une donnée accessible. Un actionneur
+effectue une opération physique. La construction relie ces capacités. Ajouter
+un bloc se justifie quand il apporte une opération distincte, lisible dans le
+monde et réutilisable dans plusieurs montages.
+
+| Besoin du joueur | Réponse existante ou trou | Proposition |
+| --- | --- | --- |
+| Savoir si un coffre est presque plein | Un comparateur suffit pour son remplissage 0–15. | Aucun nouveau bloc nécessaire. |
+| Connaître le nombre exact de lingots de fer | Le remplissage ne donne ni l’identité ni la quantité exacte. | **Lecteur de stock** : instrument de mesure accolé au conteneur. |
+| Déplacer des objets en continu | Hoppers, droppers et transports vanilla. | Les conserver comme premier transport. |
+| Choisir au cours du programme quel objet part dans quelle direction | Il faut un point physique de sélection, un stock intermédiaire et un résultat de transfert. | **Aiguilleur** : petit répartiteur d’objets. |
+| Calculer, mémoriser, temporiser | Circuits vanilla ; contrôleur pour compacter et reprogrammer. | Pas d’additionneur, de RAM externe ou d’assembleur obligatoire. |
+| Faire monter et redescendre progressivement un signal | Un petit instrument peut exprimer ce comportement sans programme. | **Condensateur** : charge analogique, sans nouveau système d’énergie imposé. |
+| Déplacer les drops à découvert sur une chaîne | Le convoyeur en cuir se pose comme un rail, à vitesse unique, et s’arrête sans redstone. | **Convoyeur en cuir** : marche alimentée ; sens réglé à la pose ou au clic proposé. Un moteur optionnel pourrait séparer marche et inversion. |
+| Relier quatre commandes binaires à une intensité | Le contrôleur pourrait le calculer ; un petit composant électrique peut aussi le faire seul. | **Convertisseur binaire**, encodeur/décodeur 4 bits. |
+| Réagir à la pluie réellement reçue | La mesure doit avoir un lieu, une exposition et un sens. | **Pluviomètre**, distinct d’une lecture globale invisible. |
+| Programmer dimanche à midi | Compter des ticks ne donne pas le calendrier civil du serveur. | **Horloge de référence**. |
+| Relier plusieurs appareils au-delà des six voisins | La poudre transporte une intensité ; les octets nécessitent une liaison définie. | **Adresseur, fil et prise de données**, extension physique optionnelle. |
+| Afficher ou vendre quelque chose à un joueur précis | Une impulsion n’identifie pas son auteur et ne constitue pas un paiement. | **Comptoir**, point de transaction avec interaction explicite. |
+| Ouvrir une expansion depuis un programme | Une coordonnée calculée ne crée pas un lieu. | **Ancre spatiale**, interface matérielle d’une installation Galactium. |
+| Fabriquer un objet suivant une recette | Le crafter assure déjà une fabrication matérielle. | Le piloter ; pas de commande de création libre d’objets dans le CPU. |
+| Transformer une ressource, pomper un fluide, prospecter une roche | Certains usages spatiaux ou industriels demanderont d’autres opérations. | Des besoins à démontrer par un montage ; ne pas ajouter d’emblée un bloc universel qui fait tout. |
+
+Les noms « lecteur », « aiguilleur », « horloge », « comptoir » et « ancre »
+expriment ici une fonction. Leurs noms définitifs, éventuellement galactiques,
+leur recette et leur place dans la progression restent à choisir.
+
+## Règles communes proposées
+
+Les fiches suivantes proposent des blocs pleins, non waterloggables, récupérables
+à la pioche et immobiles aux pistons pour ce prototype. Leur façade est visible ;
+la pose fixe une orientation horizontale. Les indications avant/arrière/gauche/
+droite désignent cette orientation du bloc ; les programmes adressent toujours
+les faces cardinales du contrôleur. Le terminal permet de voir la correspondance.
+
+Un clic droit main vide ouvre une configuration, jamais une exécution cachée.
+Sneak avec un bloc tenu permet de construire contre l’appareil. Un objet sans
+interaction décrite conserve son usage normal. Les réglages appartiennent au
+bloc, les résultats réels au serveur. Une casse rend le bloc et son inventaire
+une seule fois ; une donnée de mesure ne devient pas un objet supplémentaire.
+
+Les sorties de signal proposées sont **faibles et limitées à leurs faces
+désignées**, sans alimentation forte des voisins. Une prise DEVICE ne transporte
+ni objets ni énergie. Une face ne cumule pas entrée électrique, sortie électrique
+et prise DEVICE. Il n’y a pas de chargement de chunks induit par la connexion.
+
+La mesure ou l’action ne travaille que lorsque les blocs nécessaires sont
+chargés et autorisés à fonctionner. Il faut traiter un voisin indisponible
+comme indisponible ; une mesure ancienne ne devient pas un zéro mesuré.
+
+## Lecteur de stock
+
+**Primitif : examiner un seul conteneur réellement accolé.** Un coffre double
+accessible constitue un inventaire logique ; un réseau de 128 coffres n’est
+pas découvert par ce petit bloc. Le terminal de stockage en titane garde son
+rôle distinct. Les adaptateurs d’inventaire devront respecter les faces et
+restrictions des conteneurs ; la fiche ne promet pas la compatibilité de tous
+les inventaires moddés.
+
+| Fiche proposée | Comportement |
+| --- | --- |
+| Faces | Avant : sonde vers le conteneur. Arrière : DEVICE. Gauche/droite : sortie faible de seuil. Dessus/dessous : sans fonction de transfert. |
+| Interaction | Main vide : choisir une case ou « tout le conteneur », un filtre et un seuil. Un objet tenu sert de modèle au filtre sans être consommé ; aucune case de stockage réelle. |
+| Filtre | Identité d’objet, avec option de correspondance exacte des composants. Sans filtre, compter toutes les unités ; ne pas confondre unités et stacks. |
+| Mesure | Acquisition périodique toutes les 4 ticks chargés, avec première acquisition au premier tick disponible. Le CPU peut figer le dernier relevé dans un instantané distinct. Conserver types, composants, quantités et révision de cet instantané jusqu’à la prochaine capture. Une lecture multi-octets ne mélange pas deux relevés. |
+| Usage sans CPU | Seuil de quantité configuré : sortie 15 si atteint, 0 sinon. Témoin distinct si aucune mesure valide ; les sorties reviennent alors à 0. |
+| Comparateur | Relayer le remplissage ordinaire 0–15 du conteneur quand disponible ; ne pas faire passer un nombre exact dans ce signal. |
+| DEVICE | Capturer le dernier relevé, consulter sa validité, sa révision, le total filtré et les lignes du stock. Aucun retrait ou insertion. |
+| Sauvegarde | Conserver filtre et seuil ; au rechargement marquer le relevé périmé jusqu’à une mesure réelle. |
+
+Usages : arrêt d’une chaîne à 128 lingots, inventaire d’atelier, compteur de
+dons, recherche du matériau manquant. Le relevé n’établit pas qui possède un
+objet ou qui l’a déposé. Il ne réserve pas le stock : un hopper peut le modifier
+après sa lecture.
+
+## Aiguilleur
+
+**Primitif : choisir la sortie d’objets présents dans l’appareil.** Il sépare
+la manipulation de matière du CPU. Le programme peut être très puissant sans
+que chaque contrôleur soit en même temps un coffre et une pompe universelle.
+
+| Fiche proposée | Comportement |
+| --- | --- |
+| Faces | Dessus : entrée hopper/dropper. Avant, gauche, droite, dessous : destinations matérielles. Arrière : DEVICE, ou entrée redstone dans le mode autonome, jamais les deux. |
+| Inventaire | 5 cases, limites de stack des objets conservées. Les objets entrent réellement ; aucun prélèvement distant dans un coffre. |
+| Interaction | Main vide : inventaire et filtres par sortie. Un filtre est un modèle de comparaison ; retirer un vrai objet exige l’interaction d’inventaire habituelle. |
+| Mode autonome | Une transition 0 → positif sur l’arrière demande le transfert d’une unité selon les filtres ; priorité avant, droite, gauche, dessous. Le signal maintenu ne recommence pas sans nouveau front. |
+| Mode DEVICE | Demander une sortie, une case source et une quantité de 1 à 64 ; figer aussi l’identité et les composants de l’objet alors présent. L’appareil renvoie une identité d’opération et le nombre effectivement déplacé de cet objet. |
+| Cadence | Proposition : une unité tous les 8 ticks chargés, au total pour l’appareil. Une commande de 64 unités organise une suite de transferts, pas un déplacement instantané de 64 stacks. |
+| Destination bloquée | Conserver l’objet ; ne rien jeter dans le vide. Terminer avec résultat partiel après 40 ticks chargés consécutifs sans insertion possible. |
+| Automatisation passive | Les sorties permettent aussi une extraction par hopper suivant leur filtre ; cette extraction modifie le vrai stock. L’opération active revérifie chaque unité, sans réserver une copie. Si la case devient vide ou contient un autre objet/composants, terminer avec le résultat partiel ; ne jamais poursuivre avec l’objet remplaçant. |
+| Comparateur | Remplissage ordinaire des 5 cases. Il ne représente pas l’avancement de la commande. |
+| Casse/reprise | Les unités déjà transférées restent transférées ; rendre le tampon restant, terminer l’opération interrompue et conserver son reçu. Déchargement : suspendre, sans rejouer les transferts terminés. |
+
+Usages : commandes préparées par quantité, échantillons du particuleur, tri
+changeant selon le travail d’une usine, alimentation d’un crafter. Le programme
+choisit ; les inventaires voisins acceptent ou refusent. Le profil doit exposer
+un résultat même si le stock observé auparavant a changé.
+
+## Convertisseur binaire
+
+**Primitif : passer entre quatre états électriques et un nombre 0–15.** C’est
+un composant utilisable avec des leviers, des lampes ou des pistons, sans CPU.
+
+Proposition : mode encodeur ou décodeur choisi au clic dans la configuration.
+Avant porte la valeur analogique ; arrière, gauche, droite et dessus portent
+respectivement les bits de poids **1, 2, 4 et 8**. Dessous reçoit une horloge.
+Il n’y a pas de port DEVICE dans cette première fiche.
+
+- **Encodeur** : relever les quatre entrées au front montant inférieur ; une
+  entrée positive vaut 1. Publier leur somme sur l’avant et la conserver jusqu’au
+  prochain front. Exemple : poids 1 et 4 actifs donnent 5.
+- **Décodeur** : relever l’intensité avant au front montant inférieur ; publier
+  0 ou 15 sur les quatre sorties selon les bits, puis les conserver. Valeur 10 :
+  seuls les poids 2 et 8 sont allumés.
+- Proposition de délai : mise à jour après 2 ticks serveur. Pas de mode transparent
+  caché. Changer de mode met les sorties à zéro ; la valeur mémorisée en place
+  est sauvegardée, mais un bloc récupéré se repose à zéro.
+- Comparateur : dernière valeur 0–15 mémorisée. Aucun inventaire.
+
+Cette reprise simplifie le principe de l’extendeur historique, sans prétendre
+ajouter quatre canaux analogiques indépendants. Usages : code de porte à quatre
+leviers, sélection de gare, télécommande d’effets, lecture des bits d’un calcul.
+
+## Pluviomètre
+
+**Primitif : mesurer la pluie qui arrive ici.** Proposition distincte de l’ancien
+détecteur qui regardait la météo globale.
+
+La coupelle supérieure doit être exposée à la précipitation du lieu. La neige
+ne compte pas comme pluie. Relevé toutes les 20 ticks chargés ; état binaire,
+sans inventer une intensité locale variable. Arrière DEVICE, autres faces
+horizontales sortie faible 0/15 ; dessus mesure et dessous support.
+
+Main vide : inverser la sortie dans la configuration. Le relevé brut reste
+identique pour DEVICE. Comparateur : 15 quand le capteur reçoit de la pluie,
+0 sinon, indépendamment de l’inversion. Aucun inventaire, aucun prélèvement
+d’eau. Au rechargement, attendre un relevé avant d’annoncer un état valide.
+
+Usages : toit automatique, affichage de météo locale, spectacle de particules,
+commande d’une installation extérieure. La météo globale et l’orage peuvent
+devenir d’autres informations, mais ne sont pas faussement présentés comme
+mesurés par cette coupelle.
+
+## Horloge de référence
+
+**Primitif : obtenir une date du serveur et déclencher un rendez-vous configuré.**
+Le chronomètre de machine reste un programme comptant ses ticks ; cette horloge
+apporte l’heure civile pour le temps réel de Sanctuary.
+
+| Fiche proposée | Comportement |
+| --- | --- |
+| Faces | Arrière DEVICE ; avant sortie faible d’alarme ; autres faces sans émission. Aucun inventaire. |
+| Interaction | Clic : date locale du serveur, fuseau administrateur et calendrier d’alarme. Le joueur ne change pas l’horloge du serveur. |
+| Données | Date civile, instant UTC, jour de semaine et âge de cette partie. Distinguer âge de la partie, date historique de Minecraft et fondation de Sanctuary le 16 mars 2026. |
+| Mise à jour | Un relevé cohérent par seconde réelle quand l’appareil fonctionne ; aucune génération de tick de machine supplémentaire. |
+| Alarme | Règle unique jour/heure ; impulsion de 4 ticks chargés à la prochaine occurrence, identifiée par son instant UTC. Sauvegarder la dernière occurrence émise. |
+| Arrêt, retard, changement d’heure | Une occurrence entièrement passée hors fonctionnement est manquée. À l’automne, choisir la première occurrence d’une heure locale doublée ; au printemps, ignorer une heure locale inexistante. Un recul de l’horloge ne rejoue pas une occurrence déjà enregistrée. |
+| Comparateur | Quart de journée affiné en 16 positions : `floor(secondes_locales_du_jour × 16 / 86400)`, 0–15. Ce signal ne contient pas une date. |
+
+Usages : calendrier public, ouverture du marché du dimanche, rendez-vous
+préécrits, affichage d’anniversaire. La programmation d’un horaire ne crée ni
+offre commerciale ni événement de progression par elle-même.
+
+## Adresseur, fil et prise de données
+
+**Primitif : choisir un appareil sur une liaison construite.** Cette extension
+évite de transformer la poudre en réseau invisible ou d’exiger un contrôleur
+collé derrière chaque mesure distante. Elle n’est pas requise pour une liaison
+DEVICE directe.
+
+Proposition matérielle : un Adresseur plein, dos vers une face DEVICE du CPU,
+avant vers le fil ; les autres faces sont inactives. Un **fil de données** est
+un bloc de connexion fin à six branches, sans inventaire ni transfert d’items,
+sans émission redstone. Il peut relier une prise DEVICE exposée ; il n’occupe
+pas la même cellule que la poudre. Pose et récupération ne dupliquent pas
+les appareils raccordés. Il ne charge pas les chunks traversés.
+
+Une **prise de données** pleine termine le fil : sa face avant DEVICE peut
+supporter un afficheur mural, ses autres faces reçoivent les branches du fil.
+Elle ne sélectionne pas une adresse et ne conserve pas le texte ; l’afficheur
+reste le périphérique. Le fil fin seul ne constitue pas un support d’écran.
+La prise reprend les règles de casse des blocs de connexion : aucune copie
+de données, perte du support entraînant la dépose du panneau. Le panneau peut
+toujours être posé directement sur un contrôleur pour le montage minimal.
+
+Le réseau d’essai admet **64 segments, prises comprises, et 16 appareils**, dans une même dimension,
+avec **un seul Adresseur maître**. Les chemins cycliques sont parcourus une seule
+fois ; un dépassement ou deux maîtres met le réseau en conflit visible. Une
+rupture ne change pas les noms des appareils et ne réadresse pas leurs voisins.
+
+Un clic sur chaque appareil lui attribue une adresse locale 1–16 ; doublon
+signalé, pas de choix aléatoire. Un clic sur l’Adresseur montre les adresses et
+leur disponibilité. Le CPU sélectionne une adresse dans son registre local,
+puis lit/écrit la fenêtre distante. Tous les accès distants voient le même
+budget CPU ; débit supplémentaire proposé de **16 octets par tick et par bus**,
+puis `BUSY`. Les accès sont courts, sans attente bloquante.
+
+Comparateur de l’Adresseur : 15 réseau utilisable, 0 sans réseau ou en conflit.
+Le terminal précise la cause. Changer la sélection ne réexécute aucune commande.
+Déconnecter un appareil n’annule pas une opération qu’il a déjà acceptée.
+Le fil ne constitue ni une liaison interdimensionnelle, ni un tunnel gratuit
+pour les objets. Un fil isolé se récupère comme matériau, sans état d’exécution.
+
+Usages : poste central d’atelier, plusieurs réserves, écrans éloignés, contrôle
+d’une construction étalée. Un réseau entre plusieurs CPU demandera un protocole
+supplémentaire : il n’est pas déduit de ce premier bus à maître unique.
+
+## Comptoir
+
+**Primitif : recevoir l’accord d’un participant identifié à une opération.**
+Un même bloc peut servir à une vente, un dépôt collectif ou une inscription.
+Il n’est pas un lecteur universel de l’identité des joueurs autour de lui.
+
+Proposition : face avant interactive, arrière DEVICE. Dessus, dessous et côtés
+ne manipulent pas directement d’objets ; les coffres raccordés à l’installation
+portent les biens. Aucun comparateur révélant un portefeuille. Au clic droit,
+le joueur voit l’offre exacte et confirme. Le serveur produit alors un reçu
+opaque associé à cette offre, cette révision et ce joueur. Un hopper ou une
+impulsion ne peut pas remplacer ce geste.
+
+L’offre préparée par le programme référence des biens réels, une quantité,
+un prix, une monnaie et une destination. Rubis comme monnaie de référence ;
+les autres monnaies ne sont admises que par une offre les acceptant explicitement.
+Pour ce profil d’essai : **une offre et une transaction active par comptoir** ;
+une file plus large peut être construite avec plusieurs comptoirs.
+
+Le service commercial revérifie offre, stock, fonds et destinataire au moment
+de l’engagement. Il réserve puis termine la transaction avec un reçu durable.
+Une sortie électrique pourrait indiquer la réussite ; elle ne déclenche pas
+elle-même un second retrait de monnaie. En cas de casse ou de crash, le service
+termine ou restitue les réservations selon son journal ; il ne rembourse pas
+aveuglément un achat déjà livré. Le matériel exact des dépôts et portefeuilles
+dépend du contrat économique encore à concevoir.
+
+Usages : boutique d’un joueur, retrait de commande, caisse d’événement, inscription
+à un concours. Une démonstration avant l’économie peut se limiter à l’échange
+d’items présents ; elle ne serait pas encore le Black Market de Sanctuary.
+
+## Ancre spatiale
+
+**Primitif : donner un point matériel de référence à un projet spatial.**
+L’ancre est une proposition distincte du noyau galactique : le noyau disparaît
+en libérant une charge collective ; aucune charge n’est enfermée dans cette
+nouvelle machine ni transportée dans son item.
+
+Proposition : socle plein, marqueur d’orientation sur sa face supérieure,
+prise DEVICE à l’arrière. Clic main vide : installation reconnue, projet,
+conditions matérielles et opération courante. Aucun inventaire intégré ; des
+conteneurs raccordés apportent les ressources. Un comparateur peut indiquer
+0–15 d’avancement d’une opération, avec un témoin distinct pour attente/refus.
+
+Le programme compose un projet puis demande une vérification : destination,
+climat, taille admissible, disponibilité spatiale, ressources et déblocages.
+La vérification n’engage pas une charge. Un lancement accepté réserve les
+ressources et une charge dans le journal du serveur, retourne l’identité de
+l’opération et poursuit le travail progressivement. Le même identifiant relu
+après interruption doit retrouver le même projet, pas une autre expansion.
+
+La construction précise du multibloc et sa recette ne sont pas encore choisies.
+Cette fiche rend explicite **où** doit vivre son interface. Une copie de programme
+ne copie ni charge, ni réservation, ni progression collective. Retirer l’ancre
+cesse d’offrir le point de commande ; il ne fait pas disparaître un continent
+engagé ou terminé et ne restitue pas une charge consommée par défaut.
+
+Usages proposés : ouverture de continent, référence d’un Indoor, installation
+de liaison. Chaque usage possède son propre contrat ; ils ne consomment pas
+automatiquement tous une charge d’expansion. Le déblocage collectif des portails
+des Cavernes reste issu du donjon prévu, pas d’un opcode qui contourne ce passage.
+
+## Lire et écrire un périphérique
+
+Le langage conserve deux instructions génériques : `PREAD` et `PWRITE`. Les
+appareils donnent un sens aux adresses ; il n’est pas nécessaire d’inventer
+`BUY`, `SUMMON`, `GIVE`, `SCANWORLD` ou une nouvelle instruction par boutique.
+
+### Convention proposée de données
+
+- Octets non signés ; valeurs multi-octets **petit-boutistes**, octet faible
+  à l’adresse la plus basse. La paire d’adressage `[A:B]` du CPU reste haut/bas :
+  il s’agit d’une notation d’adresse, pas d’un autre stockage de données.
+- `0x0000` lecture : version du profil, ici 1. `0x0001` lecture : type du profil.
+  `0x0002` lecture : état local, 0 indisponible, 1 prêt, 2 occupé, 3 erreur.
+  Autres adresses seulement si la fiche les expose ; sinon `BAD_ADDRESS`.
+- Types **provisoires de documentation** : 1 afficheur, 2 lecteur de stock,
+  3 aiguilleur, 4 horloge, 5 pluviomètre, 6 adresseur, 7 comptoir, 8 ancre.
+  Ni identifiants `sanctuary:*` ni numéros définitifs de sauvegarde.
+- `STATUS = 0` signifie lecture réussie ou écriture acceptée. Les états de
+  tâche et reçus se lisent séparément. Après un refus de lecture, le registre
+  destination conserve son ancienne valeur : vérifier `STATUS` avant de l’utiliser.
+- Une seule liaison pilote un appareil dans le prototype. Brancher simultanément
+  un contrôleur direct et un bus rend la liaison conflictuelle ; pas de dernier
+  écrivain gagnant silencieusement.
+
+### Premier profil d’afficheur
+
+L’écran fournit largeur en colonnes à `0x0010` et hauteur en lignes à `0x0011`.
+Un octet suffit avec le plafond proposé de 128 × 32. Le programme prépare une
+trame dans le tampon de l’appareil, puis la publie en une opération.
+
+| Adresse | Accès et valeur proposés |
+| --- | --- |
+| `0x0020` | Écriture commande : 1 commencer une trame vide ; 2 publier ; 3 abandonner le tampon. Autre valeur refusée. |
+| `0x0021` | Écriture : ajouter un octet UTF-8 à la trame ouverte ; maximum 16 Kio. Lecture refusée. |
+| `0x0022` | Lecture : 0 aucun tampon, 1 trame en cours. |
+| `0x0023`–`0x0024` | Lecture : longueur du tampon sur 16 bits, figée tant qu’aucun octet n’est ajouté. |
+
+Publier vérifie UTF-8 et la capacité ; une trame invalide conserve l’ancienne
+image et le tampon pour correction/abandon. Une trame publiée ferme le tampon.
+LF avance d’une ligne, CR est refusé ; le texte se replie à la largeur logique,
+le débordement vertical est conservé mais masqué comme dans la fiche d’écran.
+Une coupure de liaison abandonne la trame inachevée et garde la dernière image.
+Le premier profil transporte du texte ; couleurs, pictogrammes et édition d’une
+zone peuvent étendre le profil sans être prétendus disponibles dans ces octets.
+
+Exemple proposé avec un afficheur au sud, face SOUTH en DEVICE :
+
+```text
+PWRITE SOUTH, 0x0020, 1  ; commencer
+CMP STATUS, 0
+JNZ erreur
+PWRITE SOUTH, 0x0021, 79 ; O
+CMP STATUS, 0
+JNZ erreur
+PWRITE SOUTH, 0x0021, 75 ; K
+CMP STATUS, 0
+JNZ erreur
+PWRITE SOUTH, 0x0020, 2  ; publier « OK »
+CMP STATUS, 0
+JNZ erreur
+HALT
+erreur:
+  HALT
+```
+
+`HALT` coupe les sorties électriques du CPU ; l’image publiée reste dans
+l’afficheur. Cet exemple ne vérifie que les écritures acceptées, pas la présence
+d’un joueur devant l’écran.
+
+### Relevés du stock, du temps et de la pluie
+
+Pour ces trois instruments, `0x0010` est une commande d’instantané, écriture 1.
+`BUSY` signifie qu’aucun nouveau relevé n’a été accepté. La photographie publiée
+reste stable jusqu’à la suivante ; son âge et sa disponibilité restent distincts.
+Les octets de révision à `0x0011`–`0x0014` identifient ce relevé sur 32 bits.
+Les adresses `0x0015`–`0x0018` donnent son âge **au moment de la capture**, en
+ticks chargés u32, figé avec lui. `0x0019` vaut 1 si cet instantané reste
+utilisable, 0 si aucune capture n’existe ou si son instrument est indisponible.
+
+| Profil | Données proposées |
+| --- | --- |
+| Stock | `0x0020`–`0x0023` quantité totale filtrée u32 ; `0x0024`–`0x0025` nombre de lignes u16. Sélecteur de ligne u16 écrit à `0x0030`–`0x0031`, validé par écriture 1 à `0x0032`. Ligne sélectionnée : quantité u32 à `0x0040`, longueur u16 à `0x0044`, identifiant UTF-8 à partir de `0x0100` (maximum 256 octets). Les composants exacts sont un jeton u32 à `0x0046`, local à cet instantané ; aucun numéro global d’item supposé stable. |
+| Horloge | Instant UTC en secondes u64 à `0x0020` ; année u16 à `0x0028`, mois/jour/heure/minute/seconde/jour de semaine aux octets `0x002A` à `0x002F`, lundi=1 ; âge de partie en jours u32 à `0x0030`. Les champs proviennent du même relevé et du fuseau serveur. |
+| Pluviomètre | Octet `0x0020` : 0 sec, 1 pluie reçue. Ne pas utiliser le relevé si l’état local dit indisponible. |
+
+Les acquisitions périodiques alimentent les sorties autonomes et un relevé
+interne courant ; elles ne remplacent pas l’instantané détenu par le CPU.
+La commande capture le dernier relevé disponible de l’instrument. Elle ne
+force pas une inspection coûteuse pour chaque instruction du CPU. Les relevés
+stock et pluie sont invalidés quand le voisin ou l’exposition nécessaires ne
+peuvent plus être examinés. Un compteur dépassant u32 est signalé hors plage,
+jamais tronqué en petite quantité. Un consommateur relit la révision après une
+lecture longue ; si elle a changé, il recommence son relevé.
+
+### Commandes matérielles et opérations longues
+
+Pour l’aiguilleur, une préparation comporte case source, direction et quantité.
+Le comptoir prépare une offre ; l’ancre prépare un projet. Ces derniers schémas
+dépendent des systèmes économiques et spatiaux et ne reçoivent pas ici une
+fausse table binaire définitive. Ils doivent partager ce cycle :
+
+1. Écrire une préparation dans l’appareil ; les écritures partielles ne font
+   rien au monde. Valider sa forme et figer une révision.
+2. Demander l’engagement de cette révision avec une clé de requête persistante.
+   Une révision déjà engagée renvoie la même opération, sans nouvel achat ni
+   nouvelle expansion. Un refus ne consomme rien.
+3. Consulter `en attente / en cours / terminée / partielle / refusée / interrompue`
+   et le reçu : quantité réellement déplacée, transaction ou projet.
+4. Acquitter le résultat pour libérer l’unique emplacement actif. Une nouvelle
+   demande exige une nouvelle préparation ; réécrire « démarrer » en boucle ne
+   crée pas d’opération neuve.
+
+Proposition pour l’aiguilleur : case 0–4 à `0x0010`, direction 0 avant, 1 droite,
+2 gauche, 3 dessous à `0x0011`, quantité 1–64 à `0x0012`. Commande `0x0013` :
+1 figer, 2 engager, 3 acquitter, 4 abandonner une préparation non engagée.
+Identité d’opération u64 à `0x0020`, état à `0x0028` (0 vide, 1 préparée, 2 en cours,
+3 terminée, 4 partielle, 5 refusée, 6 interrompue), quantité transférée à `0x0029`.
+La préparation figée porte une identité attribuée et sauvegardée par l’appareil ;
+le CPU ne doit pas improviser une clé aléatoire à chaque tick. Le reçu est figé
+avant acquittement ; aucune nouvelle préparation pendant l’opération active.
+
+Le journal de l’appareil ou du service garantit les reprises et l’absence de
+double engagement. **Sauvegarder la RAM seule ne garantit pas cela.** Les crashes
+entre mutation d’inventaire et écriture du reçu demandent un contrat de sauvegarde
+et des essais dédiés avant d’annoncer des transactions fiables. Ce dossier ne
+modifie aucun format de sauvegarde actuel.
+
+### Fenêtre de l’Adresseur
+
+Adresse distante 1–16 sélectionnée par écriture à `0x0010`. Fenêtre CPU
+`0x0100`–`0x80FF` : déduire `0x0100` pour obtenir l’adresse distante 0–`0x7FFF`.
+Le profil local de l’Adresseur reste lisible hors fenêtre. Une valeur d’adresse
+inconnue donne `NO_DEVICE` ; un conflit donne `DEVICE_ERROR` ; dépassement du
+débit donne `BUSY`, sans accepter l’accès. Pas d’emboîtement d’Adresseurs dans
+ce prototype. Tous les profils détaillés ci-dessus tiennent dans cette fenêtre.
+
+## Ce que l’ancien mod apporte réellement
+
+Lecture locale des registres et méthodes, sans essai de compatibilité 26.3 :
+
+| Référence | Présence vérifiée | Rapport à cette proposition |
+| --- | --- | --- |
+| `Redstone/redstone_computer`, 2.0.0 pour 26.1.2 | `rain_detector`, `io_extender`, `bus_connector`, `display_matrix` et ordinateurs. | Pistes concrètes. Le capteur regarde la météo globale ; le bus sert surtout les matrices et n’est pas le protocole défini ici. |
+| `Redstone/adresseur`, 1.0.0 pour 26.1.2 | Initialiseur qui journalise, sans registre de bloc. | Nom disponible comme intention ; aucun fonctionnement ancien à présenter comme porté. |
+| `Redstone/drawer` et `26.2/redstoner` | Stockage mono-objet à compteur `long`. | Pas de compatibilité hopper établie dans les interfaces inspectées ; ne pas le mettre dans une chaîne comme déjà fonctionnel. |
+| `26.2/redstoner` | Particuleur, terminal de stockage jusqu’à 128 coffres/tonneaux, panneaux spécialisés et ordinateurs. | La reprise des capteurs exacts et des affichages peut s’en inspirer, sans restaurer tout l’ancien OS dans le terminal. |
+
+Les ordinateurs historiques transfèrent aussi leurs propres cases d’entrée
+vers un inventaire voisin. Cela motive l’aiguilleur séparé ; ce code ne prouve
+pas une lecture universelle des coffres alentour. Les références sont conservées
+dans les dossiers voisins, jamais modifiées par ce chantier. Voir aussi la
+[lecture historique](redstone-computer-reference.md).
+
+## Montages qui justifient les composants
+
+| Installation proposée | Composition et expérience |
+| --- | --- |
+| Petite chaîne de production | Comparateur → contrôleur → crafter/dropper ; le lecteur devient utile seulement quand on veut une quantité exacte d’un matériau. |
+| Réserve industrielle | Lecteur → contrôleur → aiguilleur ; afficheur montrant commandes, stocks et quantités réellement livrées. |
+| Atelier spectaculaire | Aiguilleur changeant l’échantillon du particuleur ; puissance de redstone variant avec les étapes du programme. |
+| Galerie à quatre destinations | Convertisseur, quatre leviers et aiguillages construits ; contrôleur facultatif pour programmer une séquence. |
+| Marché du dimanche | Horloge → afficheur d’horaires ; comptoir pour les transactions réelles. Le prix et les règles du navet appartiennent à l’économie. |
+| Station d’observation | Pluviomètre et horloge reliés par Adresseur ; historique calculé dans la RAM, affiché dans le monde. |
+| Ancienne salle d’expansion | Programme trouvé sur disquette, ressources dans des conteneurs, contrôleur, ancre et afficheur de suivi ; installation reproductible ailleurs. |
+
+Pour la première réalisation, proposer le socle informatique et le particuleur,
+avec **condensateur et convoyeur** comme premiers composants autonomes,
+puis **lecteur, aiguilleur et convertisseur** : on peut déjà mesurer, décider,
+agir et voir un résultat dans de nombreux montages. Horloge/pluie et réseau
+forment des extensions indépendantes. Comptoir et ancre attendent leurs services
+réels. Cet ordre organise le travail sans limiter définitivement l’ensemble.
+
+La prochaine validation doit porter sur des constructions jouables : lecture
+exacte malgré les hoppers actifs, sortie bloquée sans perte, écran agrandi sans
+texte copié, signal réellement raccordable, heure d’été/hiver, interruption et
+reprise des opérations. Les recettes, textures, noms FR/EN, budgets et schémas
+de sauvegarde appartiendront aux tickets de code ; aucune livraison n’est
+prétendue dans ce cahier.

docs/redstone-language-instructions.md

@@ -0,0 +1,354 @@
+# Redstone Language — proposition d’instructions V0.1
+
+**Cahier de conception, WG-26. Aucun interpréteur n’est livré ici.** La version
+V0.1 désigne cette proposition de langage, pas une version du mod Sanctuary.
+Les noms, nombres et comportements ci-dessous sont proposés ensemble pour
+obtenir un contrat vérifiable ; ils restent soumis à validation et à essais.
+
+Les choix déjà retenus sont l’assembleur écrit directement, les six faces
+d’entrée/sortie, la RAM adressable et le socle contrôleur, terminal, afficheur
+et disquettes. Le bloc Assembleur est retiré : le terminal assemble le code.
+La sauvegarde complète du processeur demeure la base de travail proposée dans
+le [cahier des machines](langage-et-machines.md#architecture-du-contrôleur-à-définir).
+Ce document la précise ; il ne reprend pas implicitement les opcodes ni les
+limites du [Redstone Computer historique](redstone-computer-reference.md).
+
+## Machine proposée
+
+| Élément | Proposition V0.1 |
+| --- | --- |
+| Registres de données | `A`, `B`, `C`, `D` : quatre entiers non signés sur 8 bits, de 0 à 255. |
+| RAM | **1 Kio**, soit 1 024 cases d’un octet ; adresses valides de 0 à 1 023. Taille proposée pour l’équilibrage. |
+| Adresse | Entier sur 16 bits, fourni par un littéral ou une paire de registres ; cet espace d’adressage ne fournit pas 64 Kio de RAM. |
+| Programme | Au plus **512 instructions** et **16 Kio de source UTF-8** ; code séparé de la RAM, non modifiable par `ST`. Limites proposées. |
+| Exécution | Au plus **64 instructions par tick serveur et par contrôleur chargé**. Ce budget proposé ne promet pas un débit global sans essais de charge. |
+| Compteur d’instruction | `PC` interne, inspectable au terminal ; modifié par le déroulement, les sauts et les appels, pas par `MOV`. |
+| Pile d’appels | **16 adresses de retour**, séparées de la RAM. `SP` interne vaut de 0 à 16 ; aucun `PUSH`/`POP` de données dans cette version. |
+| Comparaison | Deux indicateurs `ZF` et `CF`, modifiés uniquement par `CMP` pendant l’exécution. |
+| Résultat périphérique | `STATUS`, octet en lecture seule pour le programme, distinct de `ZF` et `CF`. |
+| Faces | `NORTH`, `SOUTH`, `EAST`, `WEST`, `UP`, `DOWN`, selon les directions du monde ; pas d’alias dépendant de l’orientation du joueur. |
+
+Un registre n’est pas un item et une case de RAM ne contient pas un bloc du
+monde. Ces octets décrivent un calcul ; seul un appareil explicitement relié
+peut interpréter certains résultats comme une demande d’action.
+
+## Écriture et opérandes
+
+Une instruction par ligne ; arguments séparés par des virgules. Un point-virgule
+introduit un commentaire jusqu’à la fin de la ligne. Une étiquette occupe une
+ligne sous la forme `boucle:`. Les lignes vides, commentaires et étiquettes ne
+consomment pas le budget d’instructions.
+
+Les instructions, registres et faces sont insensibles à la casse ; les
+étiquettes sont sensibles à la casse, uniques, composées de lettres ASCII,
+chiffres et `_`, sans commencer par un chiffre ni reprendre un mot réservé.
+Les constantes sont décimales ou hexadécimales avec préfixe `0x` ; aucune
+conversion silencieuse d’une constante hors limites n’est autorisée.
+
+| Notation dans les tableaux | Opérande autorisé |
+| --- | --- |
+| `r` | Un registre destination parmi `A`, `B`, `C`, `D`. |
+| `v`, `x`, `y` | Un registre de données, `STATUS`, ou un littéral de 0 à 255. |
+| `a` | Adresse de 0 à 65 535 écrite littéralement, ou paire `[A:B]`, `[B:C]`, etc. de deux registres de données distincts. |
+| `t` | Durée entière de 1 à 65 535 : littéral, registre de données ou paire de registres. Une valeur calculée égale à zéro est une erreur. |
+| `label` | Étiquette du programme ; pas de saut vers la RAM ni vers un nombre calculé. |
+| `face` | Une des six faces nommées ci-dessus. |
+
+Dans `[A:B]`, `A` est l’octet haut et `B` l’octet bas : l’adresse vaut
+`256 × A + B`. Cette notation compose une adresse, elle ne lit pas à elle seule
+la RAM. Seules `LD` et `ST` accèdent à la mémoire ; pour les périphériques,
+l’adresse désigne un registre de l’appareil.
+
+```text
+MOV A, 0x03
+MOV B, 0xFF
+MOV C, 42
+ST [A:B], C     ; écrit 42 à l’adresse RAM 1023
+LD D, 1023     ; D vaut 42
+```
+
+Un accès RAM à l’adresse 1024 ou au-delà échoue : il ne revient pas au début
+de la RAM. Pour un accès indirect dont un registre sert aussi de destination,
+tous les opérandes sont évalués avant l’écriture du résultat.
+
+## Instructions du noyau
+
+Toutes les instructions exécutées comptent pour une unité du budget, y compris
+un saut, `WAIT` ou une lecture périphérique. Une instruction atomique terminée
+avance `PC`, sauf si elle fixe une autre destination. Une erreur conserve la
+position de l’instruction fautive pour le diagnostic.
+
+### Mémoire et calcul
+
+| Instruction | Effet |
+| --- | --- |
+| `MOV r, v` | Copie la valeur dans le registre. |
+| `LD r, a` | Charge l’octet de RAM à cette adresse. |
+| `ST a, v` | Écrit un octet à cette adresse de RAM. |
+| `ADD r, v` | Addition, puis résultat modulo 256. |
+| `SUB r, v` | Soustraction, puis résultat modulo 256 ; `0 − 1` donne 255. |
+| `MUL r, v` | Multiplication, puis résultat modulo 256. |
+| `DIV r, v` | Quotient entier non signé ; division par zéro : erreur. |
+| `MOD r, v` | Reste de la division entière ; diviseur zéro : erreur. |
+| `AND r, v` | ET bit à bit. |
+| `OR r, v` | OU bit à bit. |
+| `XOR r, v` | OU exclusif bit à bit. |
+| `NOT r` | Inverse les huit bits : `255 − r`. |
+| `SHL r, v` | Décale vers la gauche, insère des zéros et ne conserve que huit bits. Décalage de 8 ou plus : résultat zéro. |
+| `SHR r, v` | Décale vers la droite en insérant des zéros. Décalage de 8 ou plus : résultat zéro. |
+
+Ces calculs ne modifient pas `ZF` ou `CF`. Un dépassement arithmétique ne provoque
+pas d’erreur ; il est volontairement modulo 256. La division par zéro échoue
+avant toute modification du registre destination.
+
+### Comparaison et déroulement
+
+| Instruction | Effet |
+| --- | --- |
+| `CMP x, y` | Compare sans modifier les opérandes : `ZF = (x == y)` et `CF = (x < y)`, en non signé. |
+| `JMP label` | Saute sans condition. |
+| `JZ label` | Saute si la dernière comparaison était égale. |
+| `JNZ label` | Saute si elle était différente. |
+| `JC label` | Saute si son opérande gauche était strictement inférieur au droit. |
+| `JNC label` | Saute si son opérande gauche était supérieur ou égal au droit. |
+| `CALL label` | Empile l’adresse de l’instruction suivante puis saute. Une pile pleine provoque une erreur avant le saut. |
+| `RET` | Dépile une adresse et y revient. Une pile vide provoque une erreur. |
+| `WAIT t` | Avance `PC`, termine la tranche d’exécution et attend le nombre de ticks défini ci-dessous. |
+| `HALT` | Termine le programme, met toutes les sorties redstone à zéro et conserve la RAM. |
+| `NOP` | Ne fait rien, mais consomme une instruction. |
+
+Ici `CF` est le résultat « inférieur » de `CMP`, pas une retenue implicite de
+`ADD`. Les branches lisent exclusivement la dernière comparaison, même après
+un calcul ou un accès périphérique. `ZF` et `CF` sont faux à l’initialisation.
+Le registre de données `C` reste distinct de `CF`. Le terminal emploie les noms
+`ZF` et `CF` ; le programme teste ces indicateurs avec les sauts conditionnels,
+sans nouvel opérande lisible par `MOV`.
+Atteindre la fin du programme sans saut a le même effet que `HALT`.
+
+### Redstone ordinaire
+
+| Instruction | Effet |
+| --- | --- |
+| `IN r, face` | Copie l’intensité entrante, de 0 à 15, observée sur cette face. |
+| `OUT face, v` | Prépare l’intensité sortante ; la valeur est explicitement bornée à 0–15, donc 42 donne 15. |
+
+Chaque face possède exactement un mode configuré : **OFF**, **IN**, **OUT** ou
+**DEVICE**. Les faces sont OFF par défaut. `IN` exige le mode IN et `OUT` le mode
+OUT ; un mode incorrect provoque une erreur de VM `BAD_PORT_MODE` avant tout
+effet. OFF et DEVICE n’émettent pas de redstone. Le réglage s’effectue machine
+arrêtée ou en pause, selon le [contrat des composants](redstone-language-composants.md#contrôleur--la-machine-qui-continue).
+
+`IN` ne lit ni le registre de sortie du contrôleur ni le contenu exact d’un
+coffre. Une boucle redstone réellement construite peut revenir sur une entrée ;
+elle suit alors les mises à jour physiques, sans retour implicite du logiciel.
+
+## Ticks, entrées et sorties
+
+La **tranche d’exécution** est le passage d’un contrôleur pendant un tick,
+jusqu’à `WAIT`, `HALT`, une erreur ou l’épuisement des 64 instructions proposées.
+Les entrées redstone des contrôleurs sont photographiées dans une phase commune
+avant leur exécution ; toutes les lectures `IN` d’un même tick voient ces valeurs.
+Une sortie calculée ce tick ne devient donc pas une nouvelle entrée logicielle
+d’un autre contrôleur au milieu de sa tranche.
+
+Les `OUT` alimentent un tampon : la dernière écriture de chaque face l’emporte.
+Les sorties sont publiées en fin de tranche ; une face sans nouvelle écriture
+conserve son intensité précédente. `HALT`, erreur et pause de diagnostic imposent
+zéro et abandonnent les écritures de sortie en attente de cette tranche.
+Deux `OUT` successifs, 15 puis 0 sans attente entre eux, ne produisent pas une
+impulsion physique. Il faut laisser au moins un tick entre les deux états.
+
+L’épuisement du budget conserve `PC`, registres, indicateurs, pile et RAM ; le
+programme continue à l’instruction suivante lors du prochain tick. Il ne repart
+jamais silencieusement à son début. Une boucle infinie reste bornée par ce budget.
+
+`WAIT 1` exécuté au tick `n` reprend au tick chargé suivant ; `WAIT 5` reprend
+après cinq ticks chargés. L’attente ne consomme pas d’instructions pendant les
+ticks intermédiaires. Elle mesure des ticks serveur, **pas l’heure civile** ;
+ralentissement, arrêt du serveur et déchargement ne sont pas du temps simulé
+en rattrapage. Un futur périphérique d’horloge fournit séparément le temps réel.
+
+Cette proposition ne charge aucun chunk et n’ajoute aucune énergie obligatoire.
+Un éventuel coût d’alimentation et le budget global de nombreux contrôleurs
+restent à éprouver sans confondre alimentation redstone et temps de calcul.
+
+## Extension par registres périphériques
+
+Le noyau utilise deux opérations génériques supplémentaires ; les profils des
+appareils définissent ensuite la signification de leurs registres. Un appareil
+doit être **physiquement adjacent sur la face choisie, en mode DEVICE**, et
+exposer ce protocole. `PREAD` ou `PWRITE` sur une face d’un autre mode provoque
+`BAD_PORT_MODE` avant l’opération ; aucun signal redstone n’est émis en DEVICE.
+Un coffre vanilla n’acquiert pas spontanément cette interface.
+Les [profils d’extension](redstone-language-extensions.md) définissent les
+registres et les commandes de chaque type d’appareil ; ils complètent ce noyau.
+
+| Instruction | Effet |
+| --- | --- |
+| `PREAD r, face, a` | Lit un octet du registre périphérique indiqué. En cas de refus périphérique, conserve `r` et renseigne `STATUS`. |
+| `PWRITE face, a, v` | Écrit un octet dans ce registre périphérique et renseigne `STATUS`. |
+
+`STATUS` est lisible par `MOV`, `CMP` et les autres opérandes de valeur. Il ne
+peut pas être destination. Seules `PREAD` et `PWRITE` exécutées sur une face
+DEVICE le modifient pendant le programme ; `IN`, `OUT`, les calculs et les
+sauts le conservent. `BAD_PORT_MODE` laisse aussi sa valeur précédente intacte.
+
+| Valeur de `STATUS` | Résultat proposé |
+| --- | --- |
+| 0 — `OK` | Lecture réussie ou écriture acceptée. |
+| 1 — `NO_DEVICE` | Aucun périphérique compatible sur cette face. |
+| 2 — `BAD_ADDRESS` | Registre non exposé par ce profil. |
+| 3 — `READ_ONLY` | Écriture refusée sur un registre en lecture seule. |
+| 4 — `WRITE_ONLY` | Lecture refusée sur un registre en écriture seule. |
+| 5 — `BUSY` | Opération non acceptée parce que l’appareil est occupé ; réessai ultérieur possible. |
+| 6 — `BAD_VALUE` | Octet valide pour le langage, mais valeur refusée par ce registre. |
+| 7 — `DEVICE_ERROR` | Appareil en erreur ; consulter son état selon son profil. |
+
+Les noms de statut sont des libellés de documentation, pas des constantes
+supplémentaires de l’assembleur V0.1 : le code compare, par exemple, `STATUS`
+à `0`. Un refus périphérique ne met pas à lui seul la VM en erreur ; le
+programme peut choisir une attente, une autre branche ou `HALT`.
+Pour une écriture ayant reçu une réponse, les statuts 1 à 7 signifient que cette
+écriture n’a pas été acceptée ; une erreur ultérieure d’une tâche acceptée est
+rapportée par l’état d’opération de l’appareil, pas en réécrivant ce résultat.
+
+Une écriture `OK` n’est pas une preuve qu’une tâche longue est terminée. Les
+appareils exposent séparément l’état de leurs opérations, les résultats et leur
+protocole de confirmation. Une commande déjà acceptée ne doit pas être envoyée
+de nouveau comme une demande neuve à chaque tick. `BUSY` signifie ici qu’aucune
+acceptation n’a eu lieu pour cette écriture.
+
+Contrairement à `OUT`, une écriture périphérique acceptée prend effet lors de
+l’instruction ; elle ne fait pas partie du tampon redstone. Une erreur ultérieure
+du programme ne l’annule pas. Les registres de préparation et de validation
+d’une commande composée doivent appartenir au profil de l’appareil.
+
+Chaque lecture ou écriture doit être courte et bornée. Un calcul long, transfert
+matériel ou travail de génération se prépare dans l’appareil puis se suit par
+son état ; il ne bloque pas le thread serveur dans `PREAD` ou `PWRITE`. Le profil
+définit aussi les instantanés nécessaires à une lecture de plusieurs octets.
+Deux octets lus à des moments différents ne forment pas automatiquement un
+compteur cohérent sur 16 bits.
+
+Les intensités redstone ne transportent pas implicitement ces octets. Lecteur
+de conteneur, horloge, aiguillage d’objets, afficheur ou installation d’expansion
+demandent leurs profils et blocs physiques ; le langage ne donne pas une vue
+globale des inventaires, des joueurs ou du monde. Il n’existe aucune instruction
+d’exécution de commandes opérateur, de création libre d’items ou de modification
+arbitraire de chunks. Voir les [connexions proposées](langage-et-machines.md#connexions-aux-fonctions-de-minecraft--proposition).
+
+## Diagnostic, arrêt et sauvegarde
+
+Le terminal distingue **prêt, en marche, en attente, en pause, arrêté pour
+transport (STOPPED), terminé et en erreur**. Il montre la ligne, `PC`, les
+registres, `ZF/CF`, `STATUS`, la RAM, la
+pile, l’attente restante et les intensités d’entrée/sortie. Une erreur de syntaxe,
+étiquette absente, argument invalide ou dépassement de taille empêche le
+chargement du nouveau programme et laisse l’ancien intact.
+
+| Situation | Comportement proposé |
+| --- | --- |
+| Autre programme valide chargé | Chargement sur machine arrêtée : document remplacé, RAM à zéro, sorties zéro, `PC` au début, registres et pile à zéro, indicateurs faux, `STATUS = 0`, aucune attente. CPU prêt mais arrêté. Une autre révision assemblée compte comme un autre programme. |
+| Démarrer / relancer le même programme | Commence au début avec le même état initial de CPU ; conserve la RAM. Relancer n’efface pas les effets des exécutions précédentes. |
+| Pause de diagnostic | Arrête entre deux instructions, met les sorties à zéro, conserve CPU/RAM/pile/attente. Reprendre continue sans restaurer automatiquement les anciennes intensités. |
+| `HALT` ou fin du programme | État terminé et sorties zéro ; RAM conservée. Il faut relancer pour recommencer, pas attendre le tick suivant. |
+| Erreur d’exécution | Arrêt et sorties zéro ; ligne fautive et état conservés pour diagnostic. Pas de redémarrage automatique ; correction/rechargement ou relance explicite. |
+| Réinitialisation de la machine | Action distincte du chargement : remet aussi la RAM à zéro, conserve le programme, revient à l’état prêt. |
+| Retrait du terminal ou de la disquette | N’arrête pas le contrôleur ; le programme chargé reste dans la machine. La disquette transporte source et programme, pas l’état courant de RAM/CPU. |
+| Déchargement / arrêt du serveur | Fige la machine et sauvegarde son état ; aucun tick d’exécution ni d’attente n’est rattrapé hors chargement. |
+| Rechargement du bloc en place | Restaure l’état et les intensités mémorisées. Avant toute réémission, relit les entrées, la configuration des ports et les connexions ; seuls les ports OUT valides peuvent réémettre si la machine était en marche ou en attente. Pause, STOPPED, fin et erreur conservent des sorties zéro. |
+| Casse et déplacement | Coupe les sorties et transfère une seule fois le programme et l’état complet, dont RAM, registres, `PC`, pile et attente, dans l’objet récupéré marqué STOPPED. La repose reste arrêtée ; une reprise explicite continue cet état, sorties zéro jusqu’aux prochains `OUT`, ou une relance remet le CPU au début en conservant la RAM. |
+
+Les erreurs de VM comprennent division par zéro, adresse RAM hors limites,
+attente nulle, pile d’appels pleine ou vide et mode de face incorrect. Une instruction fautive ne
+modifie pas partiellement ses registres ou sa RAM. Les instructions déjà
+terminées, dont les écritures périphériques acceptées, ne sont pas annulées.
+
+Le pas-à-pas du terminal devra distinguer inspection et exécution réelle d’une
+instruction, notamment `PWRITE`. Son fonctionnement détaillé reste à concevoir ;
+une prévisualisation de programme ne doit pas être présentée comme un essai
+réel réussi sur les machines du monde.
+
+L’état sauvegardé comprend la version du langage, le programme associé,
+registres, RAM, `PC`, pile et `SP`, indicateurs, `STATUS`, mode, attente restante,
+configuration des faces et sorties publiées. La capture se fait à une frontière de tranche achevée,
+après publication des sorties, sans persister une moitié de calcul ou un tampon
+`OUT` inachevé. Un état inconnu ou incohérent
+est conservé pour diagnostic et ne s’exécute pas en étant silencieusement réinitialisé.
+
+Le format, l’écriture durable et la reprise après crash demandent un ticket
+propre. La sauvegarde de la VM ne garantit pas seule l’unicité d’une transaction
+d’objet ou d’expansion : les opérations acceptées appartiennent au contrat de
+reprise de chaque appareil. Casser le contrôleur ou retirer la disquette ne
+révoque pas automatiquement une opération déjà enregistrée ailleurs.
+
+## Exemples avec ce contrat
+
+### Compter les fronts montants d’une entrée
+
+RAM `0` garde le compteur modulo 256 ; RAM `1` garde l’état haut précédent.
+Le programme tourne en continu, une lecture par tick. Un bouton maintenu ne
+compte qu’une fois ; les impulsions entièrement survenues entre deux relevés
+ne sont pas promises comme détectées. Les deux cases sont initialisées à zéro
+sur une machine neuve ; relancer conserve le compteur. Configurer NORTH en IN
+avant de lancer le programme.
+
+```text
+boucle:
+  IN A, NORTH
+  CMP A, 0
+  JZ bas
+  LD B, 1
+  CMP B, 0
+  JNZ attente
+  LD C, 0
+  ADD C, 1
+  ST 0, C
+  MOV D, 1
+  ST 1, D
+  JMP attente
+bas:
+  MOV D, 0
+  ST 1, D
+attente:
+  WAIT 1
+  JMP boucle
+```
+
+### Un comparateur règle un particuleur
+
+Le comparateur arrive au nord ; la sortie est mène au particuleur, dans lequel
+un échantillon a été placé. Le programme transmet uniquement le signal 0–15 :
+il ne reconnaît pas l’objet du coffre et ne choisit pas l’échantillon. Le
+particuleur reste un appareil Sanctuary à implémenter, pas un bloc vanilla.
+Configurer NORTH en IN et EAST en OUT.
+
+```text
+boucle:
+  IN A, NORTH
+  OUT EAST, A
+  WAIT 1
+  JMP boucle
+```
+
+### Des bouffées de particules avec `WAIT`
+
+Sur le même particuleur, cinq ticks chargés d’émission puis quinze d’arrêt.
+Ces valeurs illustrent le programme, pas un coût ou une règle du particuleur.
+Le temps réel dépend du rythme du serveur ; le retrait du terminal ne l’arrête pas.
+EAST est configurée en OUT.
+
+```text
+boucle:
+  OUT EAST, 15
+  WAIT 5
+  OUT EAST, 0
+  WAIT 15
+  JMP boucle
+```
+
+Le prochain ticket devra valider notamment le budget sans remise à zéro du CPU,
+les bords arithmétiques, l’adressage au-delà de 255, les attentes, le comptage
+des fronts, la publication des sorties et les transitions de sauvegarde.
+Les exemples restent des spécifications sur papier ; aucune VM n’a été exécutée
+pour ce cahier et aucun monde n’a été modifié.

docs/redstone-language-objets-et-cristaux.md

@@ -0,0 +1,203 @@
+# Redstone — objets, cristaux et métiers
+
+**Exploration WG-26 ; aucun nouveau bloc ou comportement livré.** L’auteur
+demande de poursuivre la recherche sans se brider : sa réserve visait le
+porte-outil, pas l’ensemble des phénomènes proposés. Les idées de ce cahier
+restent à discuter ; aucune n’est validée pour implémentation. L’émeraude paie
+un villageois pour une tâche de son métier dans son périmètre d’action ; ce
+rôle économique est retenu indépendamment de la recherche sur les cristaux.
+
+Le [condensateur et le convoyeur](redstone-language-signaux-et-transport.md)
+gardent leurs décisions acquises. Transistor, atténuateur et impulseur sont
+retirés de la sélection. Faisceau à gemmes et suspension d’objets restent des
+pistes exploratoires ; leur mise de côté venait d’une interprétation trop
+large du retour de l’auteur. Continuer à chercher ne les transforme pas en
+fonctionnalités retenues.
+
+## Villageois — un métier, un lieu, un travail
+
+**Retenu :** les émeraudes servent à rémunérer des actions cohérentes avec le
+métier vanilla du villageois, dans un périmètre d’action. Récolte, transformation
+et services restent les trois secteurs de la [vision](vision.md#villageois-et-automatisation).
+L’appartenance des villages aux factions via bannière et cloche reste un système
+à concevoir séparément, notamment pour ses rayons et conflits d’affectation.
+
+**Contrat de travail proposé :**
+
+- Le joueur choisit une tâche du métier et lui associe une parcelle ou un atelier,
+  un poste et des conteneurs. La forme exacte de cette attribution reste ouverte ;
+  aucun nouveau bloc « employeur » n’est imposé par cette note.
+- Le périmètre est identifiable en jeu. Le villageois doit pouvoir atteindre
+  le lieu, disposer des ingrédients ou outils requis et de place pour le résultat.
+  Aucun rayon chiffré n’est arrêté ici.
+- Le travail est observable : déplacement, manipulation et activité au poste.
+  Les matières sont réellement prises, utilisées et déposées. Un paiement ne
+  génère pas à lui seul un produit à distance.
+- Un prix en émeraudes correspond à un lot ou service explicite. Proposition :
+  réserver le paiement puis régler le résultat terminé. Une attente devant un
+  coffre plein n’est pas une tâche accomplie.
+- Chemin coupé, ressources manquantes, destination pleine ou villageois indisponible
+  interrompent le travail. Reprendre ne doit reproduire ni un produit déjà livré
+  ni son paiement. Les règles de réservation et sauvegarde demandent leur ticket.
+
+| Exemple de tâche Sanctuary proposée | Travail et limite |
+| --- | --- |
+| Fermier : entretenir une parcelle de blé | Récolter les plants mûrs, replanter avec les graines disponibles, puis porter la récolte au conteneur associé. Définir si le contrat paie la livraison ou l’entretien complet ; ne pas compter deux fois le même travail. |
+| Maçon : préparer une commande | Prendre la pierre fournie, travailler à son tailleur de pierre suivant une recette admise et déposer les éléments produits dans le coffre de l’atelier. La commande ne transforme pas les émeraudes en matériaux absents. |
+
+Ces services payés sont **des comportements Sanctuary à développer**, pas une
+affirmation qu’un villageois vanilla sait déjà exécuter ces commandes. Le choix
+des recettes et gestes doit rester cohérent avec le poste et la version du jeu.
+Les tâches culinaires éventuelles devront respecter les recettes et appareils
+d’It's Alive ! ; elles ne sont pas déduites d’une profession seule.
+
+## Porte-outil — éprouver un seul geste d’abord
+
+**Piste : une tête mécanique reçoit un outil visible.** Une impulsion lui fait
+accomplir un geste déterminé sur la case immédiatement devant elle. L’outil
+choisit l’opération ; le circuit détermine quand elle doit se produire.
+
+Le premier essai à proposer serait **la hache qui écorce une bûche**. Le joueur
+construit l’amenée et l’évacuation des blocs, par exemple avec des pistons. Le
+résultat reste une bûche écorcée posée : écorcer ne la casse pas, ne la convertit
+pas en drop et ne l’envoie pas automatiquement sur un convoyeur.
+
+Ce geste donne une question vérifiable avant d’agrandir le catalogue : est-ce
+agréable de construire une petite scierie autour d’une tête à hache ? Une houe
+qui travaille une terre admissible peut constituer un autre essai, sans valider
+d’office toutes les utilisations d’outils ou interactions de joueur.
+
+| Règle proposée | Effet sur la construction |
+| --- | --- |
+| Une case d’outil, une tête orientée, une cible voisine | L’objet donne un geste local ; la machine ne parcourt pas une parcelle. |
+| Une nouvelle impulsion demande une opération | Le signal maintenu ne devient pas une vitesse de travail infinie. Le délai du geste reste à éprouver. |
+| Cible et conditions admissibles, outil utilisable | Une demande impossible n’effectue rien. L’outil subit l’usure prévue pour un geste réussi. |
+| Matière réellement présente | Pas de duplication, de produit gratuit ou de transformation d’un objet depuis son simple nom. |
+| Retrait de l’outil | La tête ne sait plus effectuer le geste ; aucun outil virtuel ne le remplace. |
+
+La pioche automatique, le combat et les enchantements ne sont pas acquis avec
+ce bloc. Leur ajout pourrait modifier le rôle des compétences, l’XP ou la
+progression des joueurs ; il demanderait une décision propre. La fiche ne
+promet pas une imitation de tous les clics droits ou une identité de joueur
+simulée dotée de ses permissions.
+
+Le [distributeur vanilla](audit-redstone-26.3.md#ce-que-la-redstone-permet-de-construire-et-dactionner)
+et les autres appareils couvrent déjà certaines utilisations d’objets. Avant
+chaque geste ajouté, vérifier l’apport sur la version cible. Le porte-outil
+mérite sa place seulement si sa construction apporte un usage apprécié.
+
+## Articuler acteurs et machines
+
+Le **villageois** réalise une tâche de métier : il se déplace et organise une
+suite de manipulations dans son espace. Le **porte-outil** proposé accomplit
+un geste local répété ; c’est la construction du joueur qui doit lui présenter
+les bons blocs. Les deux ne doivent pas devenir deux versions du même service.
+
+Le convoyeur transporte les drops. Le crafter assure les fabrications admises.
+Le contrôleur coordonne les signaux et interfaces effectivement construites.
+Il ne donne pas un métier supplémentaire à un villageois et ne transforme pas
+la monnaie en pouvoir de machine.
+
+## Phénomènes à explorer
+
+Ces appareils sont des propositions de discussion, pas un nouveau lot de blocs
+à coder. L’objet inséré peut définir un geste, une matière ou un accord. Le
+signal peut ensuite déclencher, maintenir ou mesurer le phénomène. Chaque
+appareil garde une fonction compréhensible ; une gemme ne constitue pas un
+prétexte pour réunir des pouvoirs sans rapport dans le même bloc.
+
+### Siphon thermique
+
+Un appareil à deux extrémités retire de la chaleur à l’une pour la concentrer
+à l’autre. Un bâton de Blaze serait une piste de cœur inséré ; cristaux et
+matériaux de fabrication restent à choisir. Le résultat doit être visible aux
+deux endroits : refroidissement d’un côté, chauffage de l’autre.
+
+**Constructions possibles :** une réserve de glace liée à une cuisine ; une
+serre dont la chaleur vient d’un autre lieu de l’installation ; une porte de
+glace qui fond quand on redirige le côté chaud. Le monde ne reçoit pas d’office
+une simulation thermique générale : les transformations admissibles et leur
+contrepartie matérielle sont à concevoir avant d’annoncer cet appareil.
+
+### Miroir de matière
+
+Deux cadres liés échangent le contenu matériel de leur ouverture. Une perle
+de l’Ender insérée est une piste pour leur liaison ; le mécanisme évoque les
+opérations spatiales de Sanctuary. Les blocs restent des blocs existants :
+ils quittent une ouverture pour occuper l’autre, sans copie.
+
+**Constructions possibles :** un mur se range ailleurs pour ouvrir un passage ;
+une section d’usine terminée échange sa place avec la prochaine section à
+travailler. Dimensions, distance, contenu admis et coûts sont ouverts. Les
+inventaires et machines à état demanderaient un vrai contrat de déplacement,
+pas une copie de leur apparence. Le lien éventuel aux programmes Galactium
+est une piste, sans attribuer à ces cadres une charge d’expansion gratuite.
+
+### Lentille de suspension
+
+Un cristal maintient un objet libre dans un petit volume visible ; couper le
+signal le relâche. L’améthyste est une première piste visuelle pour le cœur,
+pas une correspondance retenue.
+
+**Constructions possibles :** attendre avec une récolte suspendue au-dessus
+d’un convoyeur ; exposer un butin dont la chute dépend d’un circuit. Une
+extension aux projectiles permettrait une épreuve de salves ; elle doit être
+évaluée séparément. Quantité retenue, mouvement, âge et ramassage doivent être
+distingués : suspendre ne signifie pas créer une copie dans un inventaire caché.
+
+### Prisme accordé
+
+Un cristal taillé dans un émetteur définit l’accord d’un faisceau visible ;
+un récepteur portant le même accord restitue le signal reçu. Les différentes
+gemmes pourraient distinguer les accords sans devenir cinq niveaux de puissance.
+
+**Constructions possibles :** commander un mécanisme visible sur une autre
+plateforme ; ouvrir une porte en alignant un trajet entre des ouvertures.
+Portée, obstacles, visibilité et motifs restent à essayer. Une lentille en rubis
+serait un composant matériel, pas un prélèvement de monnaie à chaque impulsion.
+Les données complexes gardent les interfaces prévues dans les autres cahiers.
+
+### Mémoire de geste
+
+Une variante du porte-outil pourrait recevoir un support de mémoire et un
+outil : le joueur montre un geste, l’appareil en conserve une description puis
+le reproduit sur la cible présentée. Le lapis serait une piste de matériau
+d’inscription, sans décision fixée.
+
+**Constructions possibles :** enseigner l’écorçage d’une bûche, puis construire
+une amenée par pistons ; enregistrer un geste de culture dans un atelier.
+Cela pourrait aussi se révéler redondant avec les programmes sur disquette :
+son intérêt serait l’apprentissage par démonstration et la présence de l’outil,
+pas un deuxième langage imposé ou un joueur artificiel capable de tout faire.
+
+### Diffuseur d’appât et cœur de serre
+
+Deux autres pistes donnent une fonction à des objets ordinaires :
+
+- **Diffuseur d’appât :** la nourriture insérée attire les animaux intéressés
+  dans un voisinage visible. On peut déplacer des points d’attraction pour
+  guider un troupeau dans un sas. Attirer, nourrir et reproduire sont des
+  opérations distinctes ; aucune n’est implicitement accordée par les autres.
+- **Cœur de serre :** la matière introduite contribue à refroidir, chauffer
+  ou humidifier une installation construite avec parois et ouvertures. On
+  rapporte d’abord une plante rare d’un continent, puis on construit chez soi
+  les conditions permettant sa culture. L’appareil ne fournit pas la graine
+  inconnue. Le siphon thermique pourrait en devenir un composant, au lieu de
+  créer deux systèmes de chaleur indépendants.
+
+Ces mécanismes restent ouverts à la critique. Un premier essai devrait montrer
+le geste et deux constructions possibles, avant de fixer recettes ou budgets.
+
+## Cristaux et gemmes — préserver leurs rôles et explorer leurs matières
+
+Améthyste et lapis restent des matériaux à explorer ; les correspondances
+techniques ci-dessus sont des propositions, aucune n’est retenue. Émeraudes pour les
+villageois, rubis pour les échanges entre joueurs et shops, saphirs pour les
+achats et réservations prévus conservent leur rôle économique.
+
+Le principe « un objet donne sa fonction à un appareil » reste une piste, déjà
+illustrée par le particuleur. L’émeraude peut rémunérer un acteur tandis qu’une
+autre pierre participe matériellement à un appareil ; un rôle n’impose pas
+un autre rôle. L’exploration n’exige pas de remplir une table de cinq pouvoirs
+correspondant aux cinq gemmes mentionnées. Elle reste ouverte, sans nouveaux
+blocs ni coûts ajoutés au jeu.

docs/redstone-language-signaux-et-transport.md

@@ -0,0 +1,266 @@
+# Redstone Language — signaux et transport visible
+
+**Conception WG-26 ; aucun nouveau bloc livré.** Deux appareils
+autonomes sont retenus pour le premier essai : un **condensateur de signal** et un
+**convoyeur en cuir**. Ils complètent les
+[composants informatiques](redstone-language-composants.md), les
+[instructions proposées](redstone-language-instructions.md) et les
+[extensions et périphériques](redstone-language-extensions.md).
+
+Le condensateur, ses faces, son maintien et ses gestes sont validés en conception.
+Le convoyeur transporte des drops sur une bande posée comme un rail au sol,
+avec une seule vitesse. **Il reste arrêté à la pose sans alimentation**, afin
+de pouvoir éteindre une usine. Sa recette en H est retenue. La commande de
+marche et le choix du sens proposés sont distingués ci-dessous.
+**Les valeurs d’essai et les comportements encore proposés sont
+signalés ci-dessous** : ces décisions de conception ne sont pas une livraison.
+Le contrôleur peut piloter les appareils par la redstone ordinaire ; ils ne
+demandent ni terminal ni nouveau réseau de données pour fonctionner.
+
+## Condensateur — faire évoluer une intensité
+
+Le condensateur conserve une **valeur de signal de 0 à 15**, qui rejoint
+progressivement la valeur d’entrée. Il n’accumule pas de RF, de combustible
+ou d’énergie capable d’accélérer une machine. Son intérêt est un changement
+graduel et visible : montée d’une jauge, apparition d’un effet, extinction
+progressive ou commande qui amortit des variations brèves.
+
+### Faces et gestes retenus
+
+| Élément | Contrat retenu, sauf valeur explicitement proposée |
+| --- | --- |
+| Pose | Bloc plein, orientation horizontale ; flèche vers la sortie. Entrée arrière, sortie avant. Le corps présente une réglette de charge. |
+| Entrée arrière | Lire uniquement l’intensité réellement reçue sur cette face, notée `S`, de 0 à 15. Une alimentation latérale ne remplace pas cette entrée. |
+| Sortie avant | Émettre la charge courante `Q` comme signal faible, sur cette seule face ; aucune sortie forte ni gain au-delà de 15. |
+| Maintien par dessus | Un signal positif sur la face supérieure gèle charge et délai restant. La sortie garde sa valeur : ce maintien n’est pas un arrêt électrique. |
+| Autres faces | Pas d’entrée supplémentaire et pas de relais omnidirectionnel du signal. Un comparateur peut lire la charge du bloc. |
+| Clic droit, main vide | Régler le délai `N` entre deux paliers : cycle proposé **1, 2, 4, 8 ticks**, avec **4** par défaut. Le réglage est visible sur le corps. |
+| Sneak + clic droit, main vide | Décharger immédiatement à zéro et réinitialiser le délai. Si l’entrée reste positive, la charge recommence ensuite normalement. |
+| Objet tenu | Aucun échantillon, carburant ni inventaire. Sneak avec un bloc garde le geste de construction contre l’appareil. |
+| Comparateur | Valeur `Q`, de 0 à 15 ; ce n’est pas un nombre d’objets ni une réserve d’énergie. |
+
+### Profil de charge proposé
+
+Le principe de charge et de décharge progressives est retenu. Pour le premier
+profil d’essai, lorsque le maintien est inactif, chaque intervalle de `N` ticks
+actifs permet **un seul palier** :
+
+- si `Q < S`, augmenter `Q` de 1, sans dépasser `S` ;
+- si `Q > S`, diminuer `Q` de 1, sans descendre sous `S` ;
+- si `Q = S`, garder la valeur ; une nouvelle différence commence un intervalle.
+
+L’entrée est la cible et le plafond **pendant la charge**. Si elle baisse,
+la charge peut rester temporairement supérieure pendant sa décharge : passer
+de 15 à une entrée 5 descend jusqu’à 5 ; couper l’entrée descend jusqu’à 0.
+Un plafond appliqué instantanément à la baisse supprimerait précisément cet
+effet de condensateur. Charge et décharge utilisent le même `N` dans ce premier
+essai ; pas de deuxième réglage avant d’en démontrer l’utilité.
+
+Les valeurs de `N`, le pas de charge et la durée résultante restent des réglages
+d’essai. Exemple proposé avec `N = 4` : une entrée stable à 15 fait passer la
+sortie de 0 à 15 en 60 ticks actifs ; la coupure la ramène à zéro en 60 ticks. À 20 ticks par
+seconde, chaque trajet dure trois secondes. Ce délai suit les ticks effectivement
+exécutés, sans promettre trois secondes réelles lorsque le serveur ralentit.
+Changer `N` garde `Q` et commence un nouvel intervalle ; cela ne crée aucun
+palier supplémentaire au clic.
+
+Le maintien supérieur suspend aussi l’intervalle en cours. À sa levée, on relit
+l’entrée et on poursuit le délai restant vers cette cible actuelle. La réglette
+indique la charge ; un second indice de forme ou d’animation signale le maintien.
+Un signal en entrée ne fait jamais effectuer plusieurs ticks de machine à la fois.
+
+### Conservation, retrait et bord de chunk
+
+**Proposition :** charge, réglage et délai restant sont sauvegardés dans le
+bloc posé. Un chunk déchargé n’avance plus ; au retour, les faces et l’entrée
+sont relues avant de remettre la sortie en service. Aucune charge ou décharge
+hors ligne n’est rattrapée. L’appareil ne charge pas le chunk voisin pour
+demander son signal : une connexion indisponible reprend quand le voisin est
+réellement actif, sans calcul de trajet à distance.
+
+Le bloc ne se déplace pas par piston. Sa casse coupe sa sortie ; la récupération
+rend un seul appareil avec son réglage `N`, mais **sans charge conservée**.
+Cette remise à zéro est propre à ce composant, distincte de la mémoire portable
+proposée pour le contrôleur. Une destruction sans butin ne fabrique aucun objet
+de charge. Pas de waterlogging ni de simulation de court-circuit dans ce premier
+essai ; le boîtier plein suit le support d’un bloc ordinaire.
+
+## Convoyeur en cuir — déplacer les drops
+
+Le convoyeur fait circuler **les entités d’objets présentes sur sa surface**.
+Il ne contient pas de slots et ne devient pas un hopper invisible. Un dropper
+dépose les objets, le tapis les transporte, puis un dispositif réel les reçoit.
+Une stack au sol reste la même quantité d’objets pendant ce trajet.
+
+### Forme retenue et commandes proposées
+
+| Élément | Contrat et statut |
+| --- | --- |
+| Matière et forme | **Retenu :** bande en cuir, posée comme un rail au sol, avec un support. Rouleaux et châssis visibles restent une proposition d’apparence. |
+| Repos | **Retenu :** arrêté sans alimentation, notamment à la pose sur un emplacement non alimenté. Poser une bande ne la fait pas fonctionner toute seule. |
+| Direction | **Proposé :** une flèche choisit le sens à la pose ; clic droit, main vide, pour inverser cette flèche. Le réglage manuel et son interaction avec les raccords restent à valider. |
+| Signal redstone | **Retenu :** 0 arrête l’entraînement. **Convention proposée :** de 1 à 15, marche dans le sens de la flèche à la même vitesse. La force du signal ne choisit ni une vitesse ni un sens inverse. |
+| Sortie électrique | **Proposé :** aucune. Le convoyeur ne relaie pas une alimentation forte et ne fournit pas de comparateur d’inventaire. |
+| Entrée/sortie d’objets | **Retenu :** des drops tombent ou glissent sur la bande. Ni aspiration d’un coffre voisin, ni insertion directe dans son inventaire. |
+| Vitesse | **Retenu :** une seule vitesse. **Valeur d’essai : 0,08 bloc par tick actif**, soit 1,6 bloc par seconde à 20 ticks/seconde. Une cible de déplacement local, pas une téléportation ni une augmentation du tick rate. |
+| Transport concerné | Objets au sol. L’entraînement des joueurs, mobs, bateaux ou wagons n’est pas retenu dans ce contrat. |
+
+La recette retenue utilise **six bâtons et un cuir central**, disposés en H.
+Interprétation de la grille : `B` = bâton, `C` = cuir, `.` = case vide.
+
+```text
+B.B
+BCB
+B.B
+```
+
+Le **nombre de convoyeurs produits n’est pas fixé**. L’ancien contrat
+« 0 = avance, 1–15 = sens inverse » est **remplacé** par la demande d’une usine
+éteignable : sans alimentation, la bande ne tourne pas. Le réglage du sens
+reste distinct de la commande de marche ; aucun arrêt manuel mémorisé n’est
+nécessaire à cette proposition.
+
+### Inversion automatique — moteur optionnel proposé
+
+Un **moteur de convoyeur** pourrait apporter deux commandes redstone distinctes :
+**marche** et **inversion**. Proposition : marche à zéro garde la bande arrêtée,
+quelle que soit l’inversion ; marche positive autorise la vitesse unique,
+et l’autre commande choisit le sens nominal ou inverse. Une seule intensité
+0–15 n’essaie donc pas de coder simultanément arrêt, marche et direction.
+
+Ce moteur reste **une proposition, pas un bloc retenu ni un équipement
+obligatoire** : la bande simple garde sa commande ordinaire et son réglage
+manuel proposé. Ses faces, son raccord physique aux bandes, sa portée bornée,
+le traitement des embranchements et la priorité entre plusieurs moteurs
+restent à définir. Aucune propagation infinie le long des convoyeurs ni
+activation de chunks à distance n’est admise implicitement. La fonction est
+à raccorder au cahier des [extensions](redstone-language-extensions.md) si
+elle est retenue ; aucun protocole de liaison n’est encore fixé.
+
+### Nouvelle piste — vitesse par cadence
+
+L’auteur demande si le « signal horaire » pourrait modifier la vitesse. La
+proposition interprète ici ce terme comme **une horloge redstone à impulsions**,
+pas une heure du calendrier ; cette interprétation reste à confirmer. Ce n’est
+pas encore un remplacement validé de la marche continue à vitesse unique.
+
+**Proposition : une impulsion fait avancer d’un pas fixe.** La fréquence des
+impulsions règle la vitesse moyenne ; leur absence arrête le tapis. Le sens
+reste réglé séparément. Seul un front montant compte : une alimentation maintenue
+produit un pas, pas une succession de pas. Le retour à zéro prépare l’impulsion
+suivante. L’intensité 1–15 ne modifie pas la distance d’un pas dans cette variante.
+
+Le pas et la fréquence maximale restent à éprouver. Le mouvement peut être
+animé entre deux positions, sans déplacement instantané à travers une collision.
+Si un pas est déjà en cours ou bloqué, une nouvelle impulsion ne doit pas créer
+une réserve illimitée de mouvements à rejouer ensuite. Le choix entre refus
+visible et courte attente devra appartenir à la fiche du moteur retenu.
+
+**Montage possible :** faire avancer une pièce, attendre l’opération d’un poste,
+puis envoyer l’impulsion suivante. Un contrôleur pourrait varier la cadence,
+mais une horloge construite en redstone suffirait à la marche régulière.
+
+Deux comportements restent donc à comparer : **alimenté = marche continue**,
+ou **impulsion = un pas**. Ils ne doivent pas être mélangés silencieusement sur
+la même entrée. Un mode explicite ou deux variantes de moteur seraient des
+solutions à discuter si les deux usages sont souhaités.
+
+### Raccords et déplacement à essayer
+
+L’autoconnexion, les virages et les pentes sont des **propositions à essayer**
+pour retrouver une pose familière de rails. Leur géométrie et leur comportement
+en inversion ne sont pas encore fixés ; cette fiche ne les présente ni comme
+implémentés ni comme exclus.
+
+Un objet soutenu par une bande alimentée suit sa ligne centrale et sa direction,
+en respectant les collisions. Une correction latérale modeste peut le recentrer
+sans traverser un obstacle. Le déplacement est attribué au segment sous son
+centre et appliqué **une seule fois par tick** : chevaucher deux bandes ne
+double pas la vitesse. La hauteur basse permet de garder l’objet accessible
+aux interactions ordinaires.
+
+Deux bandes adjacentes dont les tracés et mouvements se raccordent peuvent se
+transmettre l’objet. Pour les raccords incompatibles, la résolution reste à
+essayer avec les virages et l’inversion : **ne jamais dupliquer les drops ni
+additionner deux entraînements dans le même tick**. Aucun transfert fictif
+ne traverse une collision. Une convergence ne devient pas un trieur par type.
+
+Un mur ou une sortie obstruée arrête le mouvement avant collision. Les objets
+peuvent se rapprocher et fusionner selon les règles normales des stacks ; il
+n’existe pas de file d’attente d’inventaire cachée ni de pression qui pousse un
+objet à travers un bloc. Couper l’alimentation supprime l’entraînement de la
+bande ; cela ne fige pas les entités contre un ramassage, un courant ou une
+autre force. Une inversion agit sur les drops encore présents ;
+elle ne récupère pas ceux déjà ramassés, collectés ou tombés hors de la bande.
+
+### Réception, chute et distance
+
+Une bande peut déboucher sur une chute, un autre tapis plus bas, un bac ouvert
+ou une zone de collecte. À un bout libre dans un chunk actif, l’objet quitte la
+bande puis suit sa physique normale : aucune plateforme invisible ne le sauve
+du vide. Un coffre fermé en face ne constitue pas un récepteur. Un hopper ou un
+hopper minecart peut recueillir les drops depuis une position où sa collecte
+les atteint réellement ; l’aspiration sous le châssis devra être vérifiée sur
+la forme retenue, sans promettre un passage à travers un bloc plein.
+
+Le comparateur du coffre de réception mesure ce coffre ; le tapis n’en connaît
+pas spontanément le stock. Avec une logique de seuil, le circuit peut arrêter
+**le déclenchement du dropper en amont et couper l’alimentation des bandes**.
+Les objets restent accessibles sur la ligne. Un retour vers un autre bac
+pourrait ensuite utiliser le changement manuel de sens ou le moteur optionnel,
+si cette inversion est retenue. Le bac doit réellement recueillir les drops ;
+ni le tapis ni le moteur ne connaissent spontanément les capacités de réception.
+
+La longueur est celle des bandes réellement posées. Il n’y a pas de portée
+magique entre deux points ni de recherche de route globale. À la frontière
+d’un chunk non actif, le tapis retient l’objet avant le transfert : pas de
+chargement forcé, de dépôt dans un inventaire fictif ou de copie différée.
+Quand les deux côtés sont actifs, le passage reprend depuis l’objet existant.
+La bande doit aussi être alimentée. Une frontière chargée ne donne aucun
+déplacement additionnel.
+
+**Conservation proposée :** les objets gardent leur quantité, composants,
+dommages, âge et règles normales de ramassage. Le convoyeur ne réinitialise pas
+leur durée de vie et n’accorde pas une conservation infinie à une longue ligne.
+Décharger un chunk suspend son travail, sans simuler ensuite les déplacements
+manqués. Les interactions concurrentes — ramassage, fusion, collecte ou casse —
+doivent concerner l’entité encore présente, jamais une seconde représentation.
+
+### Casse et réglages visuels
+
+Proposition de sauvegarde : le segment conserve son orientation, son sens
+manuel et sa forme, puis relit l’alimentation pour autoriser la marche au
+chargement ; il reste arrêté à zéro. Il n’a aucun contenu
+à extraire lors de sa casse : les objets déjà dessus restent dans le monde et
+peuvent tomber si leur support disparaît. Perdre le bloc de support dépose la
+bande une seule fois. Un outil approprié au châssis permet sa récupération ;
+outil exact et temps de casse restent des réglages de fabrication. La recette
+en H est retenue, son rendement reste ouvert.
+
+Proposition initiale : segments non poussables par piston et non waterloggables.
+En présence d’eau au-dessus, l’entraînement est suspendu et les drops suivent
+le courant ; la lave garde son danger ordinaire. La flèche nominale reste
+lisible ; l’animation indique le sens de mouvement actif. Le cuir n’est pas
+une nouvelle source d’énergie et aucun carburant n’est ajouté par ces fiches.
+
+## Pistes écartées — archive de décision
+
+- **Transistor redstone :** écarté par l’utilisateur, retiré de la sélection.
+- **Atténuateur réglable :** écarté par l’utilisateur, retiré de la sélection.
+- **Impulseur / accélérateur :** écarté par l’utilisateur, retiré de la sélection.
+
+## Montages d’essai
+
+| Construction | Enchaînement observable |
+| --- | --- |
+| Fumée d’atelier progressive | Levier → condensateur → particuleur. La fumée monte puis décroît après coupure ; le même échantillon conserve le type d’effet. |
+| Indicateur de réserve amorti | Comparateur de coffre → condensateur → afficheur analogique. L’écran montre une tendance retardée, explicitement différente du stock instantané ; cette mesure ne sert pas à décider un paiement. |
+| Ligne de fabrication visible | Dropper → convoyeur en cuir alimenté → chute de collecte → hopper/coffre. Couper les déclenchements du dropper et l’alimentation des bandes éteint la ligne ; les drops restent dans le monde. |
+| Réception protégée | Comparateur du coffre et logique de seuil → arrêt des déclenchements du dropper en amont et coupure des bandes. Le circuit traite les apports et les drops en trajet, sans retourner automatiquement le tapis à la coupure. |
+| Retour vers un bac — proposition | Après arrêt des apports, changer le sens manuellement puis réalimenter ; si le moteur optionnel est retenu, séparer sa commande d’inversion de sa commande de marche. Le bac de retour est une construction réelle. |
+
+Les essais devront distinguer collisions, limites de chunk, signal réellement
+reçu, maintien du condensateur, arrêt/reprise des bandes, inversion proposée et quantité d’objets
+avant/après transfert. Ils précèdent les réglages définitifs et l’ajout au pack.
+Ces appareils conservent leurs usages autonomes ; une installation programmée
+réemploie les mêmes faces et les mêmes règles, sans les contourner.

docs/structures-audit.md

@@ -28,7 +28,7 @@ Sources locales : [planificateur17](../mods/sanctuary/src/main/java/fr/koka/sanc
 ## Ligne de conception retenue après cet audit
 
 **Minecraft comme archéologie d’un autre Minecraft.** Steve, Ari, Sunny, Kai,
-Zuri, Alex, Mefe, Makena, Noor sont les personnages disparus de la partie. Ils
+Zuri, Alex, Efe, Makena, Noor sont les personnages disparus de la partie. Ils
 ont découvert quelque chose de révolutionnaire et ont continué parce que ça
 marchait, jusqu’au moment où ça n’a plus marché.
 

docs/structures-conception.md

@@ -4,21 +4,33 @@
 `codex/conception-territoire`. Ce document prépare la prochaine passe ; il ne
 décrit pas une nouvelle version livrée. L’alpha.22 reste la version publiée.
 
-Le périmètre est l’organisation de Sanctuary Island, la sélection des vestiges,
-leurs usages, leurs relations et les besoins des futurs ordinateurs qui
-influencent leurs espaces. Les règles détaillées des autres systèmes de la
-bêta restent dans leurs futurs chantiers.
+Le périmètre est l’organisation de Sanctuary Island, la place des Lost Cities
+dans les continents d’expansion, la sélection des vestiges, leurs usages et
+leurs relations. Les futurs ordinateurs et afficheurs influencent les espaces
+à concevoir. Les règles détaillées des autres systèmes de la bêta restent dans
+leurs futurs chantiers.
 
 ## Décisions retenues dans la discussion
 
 | Sujet | Décision |
 | --- | --- |
 | Arrivée | Commencer dans un endroit naturel et découvrir les premières installations en explorant. |
-| Présence ancienne | Retenir quelques lieux isolés : observatoire, salle d’expansion et atelier caché, avec la grande traversée souterraine. Renforcer leur importance et leur mystère. |
-| Villes et regroupements | Garder villes, clusters, satellites et autres bâtiments en réserve. La proposition d’un noyau gare–poste–dépôt n’est pas la sélection actuelle. |
+| Présence ancienne | Sanctuary Island conserve ses secrets, salles cachées et passages souterrains : observatoire, grande salle d’expansion et atelier caché, avec la grande traversée. Retirer les bâtiments ordinaires de la future sélection de génération de l’île. Ajouter le grand laboratoire des Cavernes ; l’accès aux raids se découvre sur une île d’expansion. |
+| Voies abandonnées | Conserver le train et les rails au milieu de l’île : leurs tracés donnent des directions aux constructions des joueurs et invitent à réparer le réseau. Aucun bâtiment ni gare obligatoire à leurs extrémités. |
+| Sites flottants initiaux | Envisager un ou deux îlots suspendus riches avec un coffre enterré, des bateaux marchands répartis en périphérie de Sanctuary et des montgolfières contenant des richesses. Les temples quittent la génération de base. Une première structure volante sur ou au-dessus de Sanctuary Island reste souhaitée ; dimensions, distribution et visibilité sont à préciser en conservant le départ naturel. |
+| Villes et regroupements | Les Lost Cities restent destinées aux expansions ; ce cadrage ne les ramène pas sur Sanctuary Island. Elles peuvent déborder de petites îles de rayon 64 blocs si leurs surplombs, raccords et constructions restent cohérents. Cet assouplissement est ciblé, sans forçage général des placements. |
 | Réappropriation | Les fonctions des ruines sont reproductibles dans les installations des joueurs, avec quelques lieux collectifs uniques encore à définir. |
-| Expansion | La grande salle ancienne est rééquipable. Les joueurs peuvent construire une autre installation d’expansion ailleurs ; la salle historique n’est pas un monopole géographique. |
-| Donjon majeur | Ajouter au moins un donjon difficile, essentiel à la progression, avec un boss et un objet de quête. Son objectif précis, son boss et son fonctionnement restent à définir. D’autres tunnels sont souhaités ; leur organisation reste ouverte. |
+| Expansion | La grande salle ancienne est essentielle et rééquipable, indépendamment d’une ville. Les joueurs peuvent construire une autre installation d’expansion ailleurs ; la salle historique n’est pas un monopole géographique. « Salle de transformation » est rapproché de cette salle comme correspondance de travail, à confirmer. |
+| Réseau de la salle | Privilégier les égouts et canalisations éclairés par la redstone, avec plusieurs galeries d’accès à la grande salle. La trappe reste un accès parmi les autres. La piscine près de cette salle quitte la sélection active ; les autres pool rooms restent en réserve. |
+| Rencontres des expansions | Concevoir de grands continents avec océans, temples ou monuments sous-marins pour un futur boss aquatique, ainsi qu’un volcan abritant un mob géant. Identités, implantation, rencontres et récompenses restent à définir. |
+| Galactium | Nom retenu pour tout le système d’expansion. Casser un noyau le fait disparaître sans objet récupérable, provoque une réaction du serveur en galactique et libère une charge collective. Une interface est demandée ; la vue dans le terminal reste une proposition. |
+| Langage et machines | Employer l’écriture galactique comme langage secret reliant redstone programmable, expansions, waystones et End. Programmer directement en assembleur des contrôleurs avec six faces d’entrée/sortie et une RAM adressable. Socle retenu : contrôleur, terminal, afficheur et disquettes ; le bloc Assembleur est retiré, l’assemblage du code appartient au terminal. Base proposée : état complet sauvegardé, liaison série supplémentaire en réserve ; détails et apprentissage à définir. |
+| Découverte des machines | L’exploration doit révéler les premiers usages concrets du terminal, du contrôleur, de l’afficheur programmable et des disquettes, associés à des coffres, hoppers, comparateurs et autres blocs vanilla. Concevoir des scènes spectaculaires dont les systèmes peuvent être compris, reproduits et adaptés par les joueurs. |
+| Accès et apprentissage | Intégrer des waystones comme ascenseurs dans les îles générées : une entrée naturelle conduit à une installation ou un laboratoire inférieur. Leur usage fait découvrir le transport vertical et la téléportation horizontale précise, coûteuse en XP. Aucun nouveau palier abstrait n’est ajouté pour enseigner cet usage. |
+| Salles de machines | Concevoir des salles plus grandes, accueillant plusieurs systèmes de farming avec ordinateurs. Apprendre en observant blocs, flux, redstone et programmes consultables, sans panneau explicatif ni texte tutoriel. Les afficheurs fonctionnels restent présents. |
+| Joueurs | Viser une expérience de RPG Minecraft pour environ vingt joueurs aux pratiques variées : construction, redstone, minage, PvP et PvE. Cette direction ne change pas les dimensions des mondes ni n’instaure des classes obligatoires. |
+| Donjon majeur | Un immense laboratoire caché dans l’île abrite le portail des Cavernes et son gardien : zombie géant ou golem de pierre, choix ouvert. Vaincre le gardien permet de stabiliser et débloquer les portails collectivement et définitivement ; tous peuvent ensuite construire leur portail. Annoncer cette première réussite comme un achievement de serveur. L’objet de quête évoqué auparavant et son usage restent à raccorder à cette victoire. |
+| Secret des raids | Un lieu caché sur une île générée par expansion abrite un portail exigeant dix joueurs pour lancer un raid. Un raid par semaine pour tout le serveur ; donjon procédural difficile en aventure et butin matériel commun réparti par les joueurs. |
 | Architecture | Préférer les blocs de verre pour les grandes baies. Conserver les matériaux sobres appréciés ; rendre les usages lisibles dans les volumes et leurs abords. |
 | Récit | Minecraft comme archéologie d’un autre Minecraft : chaque ruine témoigne d’une ancienne solution, d’installations utilisées et de chantiers interrompus. |
 | Méthode | Définir ensemble avant de reprendre le code. Aucun nouveau binaire, aucune modification de monde ou mise à jour d’instance dans ce chantier documentaire. |
@@ -28,10 +40,36 @@ d’expansion indépendamment d’une ville** reste une contrainte de travail. L
 place exacte dans cette sélection restreinte doit être dessinée ; on ne déduit
 pas du retrait de la ville la suppression de ses infrastructures souterraines.
 
+Dans la dernière synthèse de l’auteur, **« grande salle de transformation »** est
+comprise provisoirement comme la grande salle d’expansion déjà prévue. Cette
+correspondance sert à poursuivre sa conception : elle n’ajoute pas une seconde
+salle, ne renomme aucun identifiant et ne lui attribue pas une nouvelle fonction
+de transformation matérielle. Son rôle essentiel demande de prévoir un accès et
+un emplacement adaptés sans dépendre de la présence d’une Lost City.
+
 La nature de la découverte des anciens joueurs, leurs rôles et la cause précise
 de leur disparition restent ouverts. Les neuf noms et le canon sont conservés
 dans [la vision](vision.md#minecraft-comme-archéologie-dun-autre-minecraft).
 
+## Préparation de l’alpha.23 — sans démarrer l’implémentation
+
+L’auteur souhaite reprendre le code **après cette discussion**, pas pendant
+ce cadrage. La prochaine passe doit dépeupler la surface des bâtiments qui ne
+font pas partie des secrets retenus, tout en préservant le train, les rails,
+la grande traversée et les accès souterrains. Retirer une gare ou une scierie
+du catalogue actif de l’île ne doit pas supprimer par dépendance son tracé
+ferroviaire. Un arrêt dans la nature ou une voie interrompue peuvent constituer
+une invitation à construire, sans bâtiment à générer pour les justifier.
+
+**Proposition de découpage pour l’alpha.23 :** vérifier d’abord la sélection,
+les réseaux et les volumes du laboratoire des Cavernes sur l’île initiale.
+Réserver une rencontre de grande taille et un espace pour son portail ;
+concevoir séparément l’accès aux raids comme découverte d’expansion. Les mobs,
+portails fonctionnels, achievements collectifs et instances hebdomadaires
+demandent leurs propres contrats avant de promettre leur livraison dans la 23.
+Les structures écartées restent réutilisables pour les expansions ou une autre
+sélection. Aucun bâtiment n’est effacé des mondes existants par ce travail.
+
 ## Ce que change cette direction
 
 Le test alpha.22 Moyen, graine 0, conserve quatorze infrastructures alors que la
@@ -40,39 +78,224 @@ donner une impression d’île très occupée. La prochaine conception doit choi
 une petite sélection avant de chercher ses emplacements : le catalogue entier
 n’est pas une liste à remplir à chaque génération.
 
-Le projet de regroupements reste disponible pour la suite. La sélection actuelle
-privilégie les découvertes isolées et l’espace laissé aux nouvelles constructions.
-Les bâtiments mis en réserve restent documentés et réutilisables ; cette mise
-en réserve ne signifie pas effacer des structures dans des sauvegardes existantes.
+Les ensembles urbains trouvent désormais surtout leur place sur les continents
+d’expansion. Le catalogue de leurs bâtiments reste disponible pour cette future
+conception ; cela ne garantit pas une ville sur chaque continent. Sur Sanctuary
+Island, les découvertes isolées et souterraines laissent la surface naturelle
+disponible pour les nouvelles constructions. L’observatoire conserve son besoin
+d’un ciel dégagé et doit trouver sa place dans ce relief, à découvrir en explorant.
+
+Cette nouvelle répartition est une direction de conception : l’alpha.22 publiée
+conserve ses règles et ses structures. Les bâtiments en réserve ne sont ni
+supprimés des sauvegardes existantes ni déplacés vers un autre continent par ce
+document.
 
 ## Sélection retenue et variantes en réserve
 
 **Sélection validée :** observatoire, salle d’expansion et atelier caché, avec la
-grande traversée souterraine. Un donjon difficile avec boss et objet de quête
-s’ajoute à cette sélection. Les plans et la fréquence des trois lieux restent
-à définir. Excavation et piscine sont des variantes en réserve, sans ajout
-automatique à la sélection.
+grande traversée souterraine et les voies ferrées abandonnées. Le donjon majeur
+prend la forme d’un immense laboratoire caché. Le secret du portail des raids
+est désormais réservé à une île d’expansion. Les plans, emplacements et fréquences
+restent à définir,
+avec une présence à assurer pour les lieux nécessaires à la progression.
+La piscine près de la salle d’expansion est retirée de la sélection
+active. Les autres piscines ou pool rooms et l’excavation restent des variantes
+en réserve, sans ajout automatique à la sélection.
 
 | Lieu ou variante | Ancienne solution et implantation | Utilité à définir pour l’exploration | Prolongement possible en bêta |
 | --- | --- | --- | --- |
 | Observatoire | Observer depuis une hauteur avec un ciel dégagé ; instruments et traces de relevés. | Panorama, orientation, emplacement d’observation et objet vanilla cohérent. | Comprendre les étoiles et les constellations, que les joueurs pourront observer et tracer depuis leurs propres lieux. |
-| Salle d’expansion | Volume souterrain ayant accueilli une installation collective ; accès et raccordements à comprendre. | Découverte majeure et espace rééquipable. Son état initial et les éléments récupérables restent à choisir. | Assembler une installation d’expansion ici ou ailleurs. L’architecture exacte des machines reste à définir. |
-| Atelier caché | Petit espace personnel aménagé derrière une entrée secondaire ou dans un ouvrage. | Abri, outillage ou équipement utile ; indices d’un travail interrompu. Contenu exact à choisir. | Modèle d’une installation reproductible ; aucune caméra ou machine encore absente promise dans les coffres. |
-| Donjon majeur | Ancienne fonction, implantation et cause de danger à concevoir ; le lieu doit conserver la trace d’une ancienne solution. | Objectif de conception : une exploration difficile, une rencontre avec un boss et un objet de quête nécessaire à la progression. Aucune rencontre n’est implémentée par ce document. | Étape de progression à choisir ; règles collectives, répétition du combat et attribution de l’objet encore ouvertes. |
+| Salle d’expansion | Grand volume souterrain essentiel ayant accueilli une installation collective ; plusieurs accès par des galeries d’égouts et de canalisations, dont une trappe, même sans ville au-dessus. | Découverte majeure et espace rééquipable, avec éclairage redstone et raccordements lisibles. La piscine voisine est retirée ; état initial et éléments récupérables à choisir. | Assembler une installation d’expansion ici ou ailleurs. « Salle de transformation » désigne provisoirement ce même lieu ; aucune fonction supplémentaire n’en est déduite. |
+| Atelier caché | Entrée discrète intégrée au terrain, pouvant ouvrir sur de grandes salles d’installation ou de laboratoire ; plans et dimensions à dessiner. | Outillage et plusieurs systèmes de farming à comprendre et essayer ; traces d’un travail interrompu. Contenu exact à choisir. | Installations reproductibles, programmes partageables, duplicables et revendables. Leur présence jouable dépendra de leur implémentation ; aucune machine nouvelle n’est ajoutée aux coffres de l’alpha publiée. |
+| Laboratoire caché — donjon majeur | Immense installation souterraine abritant le portail des Cavernes, distincte de la salle d’expansion. L’ancien usage exact reste à concevoir. | Exploration difficile et gardien à vaincre : zombie géant ou golem de pierre. Prévoir les volumes de combat et les circulations avant de fixer le mob. | Stabilisation collective et permanente des portails du monde de minage, annoncée à tout le serveur. Objet de quête et geste d’activation à préciser. |
+| Accès secret aux raids — expansion | Lieu caché sur une île générée par expansion, avec un portail et une aire de rassemblement pour dix joueurs. Architecture distincte du laboratoire à dessiner. | Découvrir le lieu et s’y réunir ; le donjon du raid se déroule dans une instance, pas dans la traversée ordinaire. | Un raid hebdomadaire pour le serveur, aventure procédurale difficile, butin commun matériel à partager librement. |
 | Excavation rare — alternative | Ancien front d’extraction, lié à une masse rocheuse et à un gisement réel. | Descendre dans des grottes contenant des ressources encore exploitables. Richesse et rareté à équilibrer. | Extraction, transport et production construits par les joueurs. |
-| Piscine ou pool rooms — alternative | Installation hydraulique avec un premier usage identifiable, puis des espaces plus mystérieux. | Exploration, circulations humides et sèches, passages vers les profondeurs. | Éventuel donjon physique ; distinct de la dimension Backrooms des objets perdus. |
+| Autres piscines ou pool rooms — en réserve | Installation hydraulique avec un premier usage identifiable, puis des espaces plus mystérieux ; aucun placement actif près de la salle d’expansion. | Exploration, circulations humides et sèches, passages vers les profondeurs. | Éventuel donjon physique ; distinct de la dimension Backrooms des objets perdus. |
 
 La traversée est une infrastructure de circulation, pas un quota de bâtiments
-annexes. Ses sorties peuvent être isolées. Les égouts peuvent exister ailleurs
-que sous une ville ; leur sélection et leurs liens avec les lieux retenus restent
-à décider. Plusieurs réseaux peuvent se rejoindre ponctuellement, conformément
-à la direction déjà retenue.
+annexes. Ses sorties peuvent être isolées. **Le réseau d’égouts et de canalisations
+devient prioritaire autour de la salle**, avec plusieurs galeries qui y conduisent
+et un éclairage par la redstone. La trappe est conservée comme l’une des entrées,
+sans concentrer tout l’accès sur elle. Tracés, embranchements, alimentation de
+l’éclairage et raccords à la grande traversée restent à dessiner. Ces réseaux
+existent indépendamment d’une ville et peuvent se rejoindre ponctuellement.
 
-Restent notamment en réserve : logements, hôtel, restaurant, bibliothèque,
-caserne, places et parcs urbains ; gare, maintenance, poste, dépôt, cartothèque,
-quai, relais, serre, pompage, sous-station, club photo, scierie et autres chantiers.
-Ce regroupement sert à organiser la conception, sans modifier leurs identifiants
-ou affirmer que chaque nom correspond à un type de structure distinct déjà codé.
+Des ouvertures dans les parois de l’île et des tronçons suspendus dans le vide
+sont permis. Les transitions, parois, appuis ou suspensions et raccordements
+doivent former une construction cohérente : l’ouverture sur le vide ne justifie
+pas des morceaux détachés ou des circulations coupées par erreur. Cette direction
+ne modifie pas les piscines, égouts ou accès déjà présents dans les sauvegardes
+des versions livrées.
+
+Pour Sanctuary Island, restent notamment en réserve : logements, hôtel,
+restaurant, bibliothèque, caserne, places et parcs urbains ; gare, maintenance,
+poste, dépôt, cartothèque, quai, relais, serre, pompage, sous-station, club photo,
+scierie et autres chantiers. Les bâtiments urbains pourront servir aux Lost Cities
+des continents, avec une sélection et une distribution encore à dessiner. Cette
+répartition ne modifie aucun identifiant et n’affirme pas que chaque nom correspond
+à un type de structure distinct déjà codé.
+
+### Laboratoire de confinement animal — expansions
+
+**Nouvelle structure souhaitée, réservée aux continents d’expansion :** un
+laboratoire avec des cellules ou enclos de confinement animal, comprenant des
+**Mooblooms**. Les espaces doivent rendre lisible cette ancienne activité
+expérimentale par leur architecture, leurs animaux et leurs installations,
+sans panneaux explicatifs. Cette direction ne définit aucune mécanique
+d’expérimentation sur les animaux.
+
+Plan, accès, circulations entre enclos, ouverture des cellules et moyens de
+libérer les animaux restent à concevoir. L’extraction aérienne peut employer le
+montage retenu : animal embarqué dans un bateau, relié par une corde et soulevé
+par un bateau-poule. Il faut dessiner un accès qui rende cette sortie possible.
+Le **Booat**, nom en jeu du véhicule surnommé **bi-poule**, est un grand bateau à
+quatre, retenu parmi les mécaniques centrales. Il accueille quatre joueurs sur
+l’eau, puis deux joueurs et deux poules en vol, comme confirmé dans le
+[cahier du Booat](progression-et-integrations.md#booat). Sa fabrication emploie
+quatre bateaux et il possède des variantes de bois. Ses dimensions et son usage
+pour l’extraction doivent être pris en compte dans le dessin de ces accès ;
+aucun comportement de transport n’est implémenté ici.
+Variantes de Mooblooms,
+autres occupants, fréquence du laboratoire et contenu ne sont pas fixés ; sa
+présence n’est pas garantie sur chaque continent. Ce lieu ne s’ajoute pas à la
+sélection de Sanctuary Island.
+
+« Laboratoire » désigne cette nouvelle structure, sans réactiver l’ancien choix
+de génération Laboratory. Aucun bâtiment, animal ou comportement n’est ajouté
+aux mondes par ce document.
+
+### Reliefs et grandes rencontres des expansions
+
+Les grands continents peuvent comporter des **océans avec des temples ou
+monuments sous-marins**, destinés à accueillir un futur **boss aquatique**.
+Un **volcan abritant un mob géant** constitue une autre direction de structure.
+Les deux rencontres restent à concevoir : aucun nom de mob, comportement,
+nombre, récompense ou condition de progression n’est fixé. Formes des reliefs,
+implantation, circulations et accès doivent être dessinés avec les structures.
+Ces lieux concernent les expansions, sans réintroduire les temples dans la
+génération de base de Sanctuary Island ni remplacer le donjon de l’île qui
+débloque l’accès aux Cavernes.
+
+Les **Lost Cities peuvent déborder des petites îles de rayon 64 blocs**, soit
+un diamètre nominal de 128 blocs. Ce repère décrit le terrain envisagé, pas un
+nouveau preset de création de monde. L’emprise construite peut dépasser la rive
+avec des surplombs cohérents ; bâtiments, voies, raccords et structures porteuses
+doivent rester lisibles comme un même ensemble.
+
+Cet assouplissement vise ces implantations urbaines d’expansion : il ne rétablit
+ni un forçage global de la génération, ni des villes sur l’île de départ. Les
+conditions de refus, les limites de débordement et la protection des emprises
+existantes restent à définir avant toute modification du générateur. Aucun
+placement supplémentaire n’est livré par ce document.
+
+### Lieux flottants du monde initial
+
+Ces sites appartiennent à la **génération initiale du monde**, avant toute
+expansion Galactium. « Déjà générés » signifie ici présents dans ce monde,
+mais encore inexplorés ; leur réalisation technique peut rester progressive
+avec le chargement des chunks. Cette direction ne demande ni charge d’expansion
+ni pré-génération massive de tous les chunks.
+
+L’objectif envisagé est **un ou deux îlots suspendus riches**, avec un coffre
+enterré à découvrir. Leurs dimensions, leurs ressources et le nombre finalement
+retenu restent à concevoir. Des cascades peuvent servir d’accès vertical, mais
+elles ne sont pas obligatoires : elles peuvent tomber dans le vide sans exiger
+un terrain ou une île dessous.
+
+Les **bateaux marchands se répartissent tout autour de Sanctuary, en périphérie**.
+Ils constituent la première voie prévue pour obtenir des villageois. Pour les
+ramener, les joueurs les embarquent dans des bateaux qu’ils relient par des
+cordes à leur bateau-poule : celui-ci les soulève et les transporte. Accès,
+nombre de navires, répartition des villageois et limites de traction restent à
+dessiner. Les **montgolfières contiennent des richesses**, dont la nature et la
+répartition ne sont pas encore fixées.
+
+La première structure volante souhaitée près de Sanctuary, sur ou au-dessus de
+l’île, doit être dessinée avec le relief, les accès et la vue depuis l’arrivée.
+Le choix du type de structure et sa position restent ouverts ; cette découverte
+doit conserver la sensation de commencer dans un endroit naturel. Ces pistes
+ne constituent pas un catalogue à placer entièrement à chaque graine.
+
+Le comportement fixe ou mobile des bateaux et ballons reste à définir ; aucun
+déplacement de véhicule n’est adopté par cette répartition. La présence souhaitée
+de marchands et de villageois ne livre pas de PNJ ni de système de commerce.
+Ces lieux pourraient faire découvrir des pages culinaires d’**It's Alive !**,
+des plans de construction ou des programmes sur disquette, en lien avec la
+progression à concevoir. Leur répartition, les conditions de déblocage et le
+contenu des coffres restent ouverts ; aucun butin n’est attribué par ce document.
+
+**Les temples sont retirés de la génération de base.** Ils restent une idée de
+futures structures autour de Sanctuary, avec une inspiration du Nether encore
+à préciser. Ni leur forme, ni leur accès, ni leur contenu ne sont définis ou
+implémentés ici.
+
+### Descendre vers les installations par une waystone
+
+**Direction retenue :** trouver une waystone dans un accès naturel d’une île
+générée, puis l’utiliser comme ascenseur vers un niveau inférieur contenant
+un laboratoire ou une installation. La descente fait découvrir le lieu et
+l’appareil par leur usage. Le choix des îles, des accès et des étages reste à
+concevoir ; aucune quantité par île ni obligation d’en mettre dans chaque
+structure n’est fixée.
+
+La même waystone possède deux usages : verticalement, sauter pour monter et
+s’accroupir pour descendre, sans devoir connaître l’étage au préalable ;
+horizontalement, rejoindre précisément une waystone connue de la même dimension,
+avec un coût élevé en XP croissant avec la distance. Ce sont les fonctions d’un
+même appareil, pas deux nouveaux paliers de progression. Alignement, portée,
+arrivée praticable et barèmes restent à préciser avec le
+[cahier de progression](progression-et-integrations.md).
+
+Dessiner les arrivées, les retours et les circulations en cohérence avec la
+grande traversée et les autres accès. Ces ascenseurs complètent les passages
+souterrains et leurs découvertes ; ils ne suppriment pas le parcours du donjon.
+Ils restent une intention de génération future, sans modification de l’alpha
+publiée ou des sauvegardes existantes.
+
+## Découvrir des usages concrets
+
+**Direction retenue :** les lieux donnent à voir ce que les futurs appareils
+permettent de faire. Le spectaculaire vient des volumes, des circulations et
+du fonctionnement de l’installation : un effet visible doit pouvoir être relié
+à des blocs et à un programme que les joueurs pourront étudier puis reproduire.
+Les salles de machines doivent être plus grandes et montrer plusieurs systèmes
+de farming avec leurs ordinateurs. Leurs dimensions découlent des installations
+et des circulations à dessiner ; aucune taille ni liste obligatoire de fermes
+n’est arrêtée. **Aucun panneau explicatif ni texte tutoriel** : on apprend en
+regardant les blocs, en suivant les flux d’objets et les signaux redstone, puis
+en consultant et essayant les programmes. Les afficheurs montrent les données
+et l’état réel des systèmes ; ils ne deviennent pas des panneaux de cours.
+Les scènes suivantes sont des pistes de conception, pas des montages livrés ni
+une obligation de placer tous les appareils dans chaque lieu.
+
+| Lieu | Scène proposée à dessiner | Ce que les joueurs peuvent en reprendre |
+| --- | --- | --- |
+| Atelier caché ou laboratoire | Plusieurs systèmes de farming avec leurs ordinateurs laissent suivre la production, les transferts et le stockage. Un montage proposé régule une réserve : coffre, comparateur, contrôleur, hopper et afficheur ; la sortie redstone commande le transfert selon un seuil. Terminal et disquette rendent le programme consultable. | Des systèmes à reproduire séparément ou à combiner dans leurs propres fermes. Le comparateur donne une mesure de 0 à 15, pas un inventaire exact ; types de fermes et raccords restent à choisir. |
+| Observatoire | Un afficheur intégré au poste d’observation présente un calendrier ou un rendez-vous céleste préparé, avec des données issues des sources serveur prévues. Le programme et les instruments expliquent l’usage de l’espace sans imposer un cours ou un dialogue. | Un poste d’observation ou un calendrier dans leurs propres constructions ; les données accessibles et les raccordements restent à définir. |
+| Grande salle d’expansion | Depuis l’entrée, les joueurs peuvent lire l’organisation du socle, des apports et du poste de commande. Terminal, contrôleur et afficheur permettent de préparer et suivre une opération une fois les conditions réunies ; les parties manquantes restent à choisir. | Une installation d’expansion reproductible ailleurs. L’écran présente l’état réel du projet, des charges et des apports validés ; il ne promet pas une carte exacte avant génération. |
+
+Les disquettes trouvées pourraient conserver les programmes de ces installations.
+Leur état initial, leurs recettes, leur récupération et les conditions d’accès
+restent à choisir. **Les programmes sont partageables, duplicables et revendables**
+dans la direction retenue ; modalités de copie, supports et règles de vente
+restent à concevoir. Un programme partagé ne fournit ni les ressources ni les
+déblocages collectifs nécessaires à son fonctionnement. Les contrats techniques
+et les autres combinaisons sont dans le
+[cahier des machines](langage-et-machines.md#combinaisons-émergentes).
+
+L’exploration peut intéresser celui qui bâtit, mine, programme ou combat. Aucun
+profil ne devient une classe obligatoire ; le fait de profiter d’une installation
+commune n’impose pas à chacun d’en écrire le programme. Le PvP fait partie des
+pratiques évoquées, mais ce cadrage ne fixe aucune règle de combat, de protection
+ou de propriété supplémentaire.
+
+**Piste d’information : cartes au trésor.** Une carte pourrait orienter vers une
+île déjà présente dans le monde, site initial ou expansion déjà ouverte, avec
+une croix indiquant un coffre enterré dont l’emplacement est confirmé. La
+distinction entre site initial et chunks déjà chargés est celle définie ci-dessus.
+Elle donne une destination à explorer ; elle ne crée pas l’île, ne dévoile pas
+un futur continent non généré et ne promet pas un coffre réapprovisionné. Origine
+des cartes, accès à l’île, sélection des coffres et contenu restent à concevoir.
 
 ## Définir le territoire
 
@@ -83,10 +306,11 @@ Ils n’ont pas encore de valeurs chiffrées acceptées.
 | --- | --- |
 | Départ naturel | Ce que le joueur peut voir depuis son arrivée et les espaces proches réservés à sa première construction. Traiter aussi les trappes et portiques souterrains. |
 | Première découverte | Type d’indice, distance d’exploration souhaitée, visibilité d’un lieu ou de son entrée. Une vue cachée par le relief n’est pas équivalente à un simple éloignement. |
+| Répartition entre îles | Lost Cities surtout sur les continents ; lieux secrets et passages de Sanctuary Island à intégrer au relief, ainsi que les sites flottants du monde initial et la première structure volante proche de l’île. Préciser les fréquences et les éventuelles exceptions sans transformer cette priorité en quota garanti. |
 | Nombre de lieux | Lieux présents à chaque graine, lieux variables, remplacements possibles et limites de répétition. |
 | Espacement | Distances entre destinations, secteurs naturels continus et proximité éventuelle d’entrées de sous-sols. |
 | Tailles d’île | Base actuelle : Petit 512, Moyen 724 par défaut, Grand 1024. Décider si la sélection reste la même selon la taille ou si seuls les espacements changent. Aucun agrandissement supplémentaire n’est décidé. |
-| Relations | Pour chaque chemin ou galerie, deux destinations réelles ou une extrémité de chantier lisible ; choix des connexions directes, interrompues et seulement suggérées. |
+| Relations | Plusieurs accès par égouts et canalisations éclairés en redstone vers la salle, avec la trappe parmi eux. Les voies ferrées peuvent finir dans la nature sans bâtiment ; leurs interruptions doivent être lisibles et réparables. Dessiner les ouvertures dans les parois et les tronçons suspendus avec des raccords cohérents. |
 | Refus | Règle pour un lieu facultatif sans terrain adapté ; recherche d’un autre accès ou emplacement pour une infrastructure de base. Les garanties et les budgets devront être conciliés. |
 | Ressources | Ce que la ruine offre comme butin et comme matériaux démontables ; ce que le joueur doit encore produire lui-même. |
 
@@ -101,7 +325,7 @@ sa fonction pendant le codage.
 4. **Plan :** pièces nécessaires, dimensions, cours ou abords, circulations, accès aux sous-sols.
 5. **Architecture :** palette, structure porteuse, toiture, vitrage, détails qui expliquent l’usage.
 6. **État :** parties entretenues autrefois, réparations, chantier arrêté, dommages localisés ; aucun défaut de raccord ne fait office de ruine.
-7. **Usage dans la prochaine livraison :** ce qu’un joueur peut réellement faire dès sa découverte.
+7. **Usage dans la prochaine livraison :** ce qu’un joueur peut réellement faire dès sa découverte ; pour un montage, ses blocs, son programme, ses entrées et ses effets observables. Distinguer ce qui fonctionne, ce qui est à rééquiper et ce qui reste futur.
 8. **Lien futur :** système bêta envisagé, connaissances transmises, éléments reproductibles et éventuelle exception collective.
 9. **Valeur :** butin, matériaux récupérables, gisement restant, répétition et effets pour plusieurs joueurs.
 10. **Admission et vérification :** placement acceptable, cas de refus, accès praticables, limites d’eau et de lave, exemples à voir en jeu.
@@ -112,20 +336,54 @@ sa fonction pendant le codage.
 pas encore son coût, ses prérequis ou les permissions pour ouvrir un continent.
 La reproduction d’une fonction n’implique pas qu’elle soit disponible dès le début.
 
-L’utilisateur réfléchit aux éléments suivants : **assembleur, bloc contrôleur,
-bloc terminal, bloc de dépôt et ancre spatiale**. Ce sont des concepts à définir,
-pas cinq blocs déjà implémentés avec des rôles figés. La vision évoque aussi un
-ordinateur 8 bits programmable avec six ports de redstone ; il faut préciser
-comment ces éléments se composent.
+Le socle retient **le contrôleur, le terminal, l’afficheur et les disquettes**.
+Le bloc Assembleur est retiré ; le terminal prépare et assemble le code. Le
+contrôleur intègre son processeur et sa RAM, avec six faces de redstone. Pour
+l’expansion, casser un noyau libère désormais dans la conception une charge
+commune au serveur : le noyau disparaît sans être récupéré ni installé dans la
+machine. Dépôt et ancrage restent à concevoir ; aucun de ces objets n’est
+implémenté par ce document.
+
+L’**afficheur programmable** est la surface visible de cet ensemble dans le
+monde : un rectangle plein de W × H panneaux offre 8H lignes sur toute la largeur
+W. Le contrôleur calcule et exécute, le terminal édite et assemble, la disquette
+transporte le programme et l’afficheur en présente les résultats. Coffres,
+hoppers et comparateurs fournissent des stocks, des transferts et des signaux
+réels. Leurs connexions et les accès aux données riches restent à définir ; le
+contrôleur n’acquiert pas une connaissance globale du monde.
+
+La direction est maintenant de relier ces appareils par un langage secret
+utilisant l’écriture galactique, également lié aux expansions, aux waystones et
+à l’End. Le [cahier du langage et des machines](langage-et-machines.md) propose
+une première répartition des rôles et un usage redstone. L’assembleur direct,
+les six faces d’entrée/sortie et la RAM adressable sont retenus. La sauvegarde
+complète de l’état est la base de travail proposée ; les autres rôles, valeurs
+et règles d’exécution restent à préciser avant le code.
+
+Pour rendre l’expansion diégétique, une
+[installation multibloc autour du contrôleur](langage-et-machines.md#programmer-les-fonctions-du-jeu-et-construire-une-expansion)
+est proposée. Des blocs ordinaires pourraient porter orientation, capacité et
+apport des ressources ; le programme préparerait et suivrait l’opération. Cette
+forme n’est pas encore validée et aucun coût ou plan n’est fixé.
+
+Les [noyaux d’expansion](langage-et-machines.md#bloc-graine-et-météorites) peuvent
+être découverts dans les météorites, et éventuellement dans les installations
+anciennes. D’autres voies restent à définir. Une
+[interface Galactium](langage-et-machines.md#réserve-collective-et-interface-galactium)
+est proposée dans le terminal : réserve commune, projet local, ressources et
+suivi de l’opération, avec accès à l’éditeur assembleur. Consulter ou préparer un
+projet n’immobilise aucune charge. Galactium nomme l’ensemble du système
+d’expansion. Les droits d’utilisation de la réserve et la disposition de
+l’interface restent en discussion.
 
 Avant de fixer le plan intérieur de la salle, décider :
 
 - ce que chaque élément reçoit, conserve, exécute ou affiche ;
-- ce que désigne exactement l’assembleur et comment le joueur programme ;
+- comment le terminal permet de programmer, assembler, enregistrer et charger le code ;
 - la différence entre terminal informatique et terminal de stockage en titane ;
 - la différence entre dépôt de machine, deposit box collective et mailbox personnelle ;
 - les connexions physiques et l’encombrement d’une installation complète ;
-- la fonction de l’ancre : rattachement à un lieu, orientation, destination ou autre rôle à définir ;
+- l’ancrage de l’installation et sa destination, ainsi que les règles de dépense des charges communes ;
 - les conditions de découverte, construction et activation, dont les ressources et autorisations côté serveur ;
 - ce qu’il reste dans la salle ancienne : installation incomplète, pièces récupérables, schéma, emplacement ou traces seulement.
 
@@ -135,10 +393,43 @@ des recettes. Cette séquence est un outil de conception, pas une campagne impos
 
 ## Donjon majeur et tunnels supplémentaires
 
-Le donjon doit compter dans la progression et comporter un boss ainsi qu’un objet
-de quête. **Le blocage levé par cet objet n’est pas encore choisi** : première
-expansion, étape avancée ou objectif collectif final sont des possibilités en
-discussion, pas des règles cumulatives.
+**Le donjon majeur devient un immense laboratoire caché dans Sanctuary Island.**
+Il contient un portail vers la dimension des **Cavernes**, le monde de minage,
+dont l’accès est éteint ou instable tant que son gardien n’est pas vaincu.
+Le choix reste ouvert entre **zombie géant et golem de pierre**. L’auteur
+indique pouvoir obtenir des sources et modèles de golems auprès d’un ami ;
+ils ne sont pas encore fournis ni intégrés. Ce lieu est distinct de la salle
+d’expansion Galactium et du laboratoire de confinement animal des expansions.
+
+Le parcours retenu est : découvrir le laboratoire, l’explorer, vaincre le
+gardien, puis ouvrir durablement les portails de minage. Le rôle de l’objet de
+quête prévu auparavant reste à préciser : victoire déclenchant directement la
+stabilisation ou objet utilisé pour la confirmer. La disparition d’un objet ne
+doit pas rendre impossible le premier accès collectif. Un **message de réussite
+à tout le serveur**, présenté comme un achievement collectif, marque le premier
+déblocage ; formulation, image et lien éventuel avec les advancements restent
+à concevoir. Cette annonce ne crée pas un verrou par joueur.
+
+**Piste proposée :** un golem lié à l’ancienne installation pourrait rendre
+visible la relation entre gardien et portail instable. Ce serait la trace d’une
+ancienne solution de contrôle, dont la fonction exacte reste à écrire ; cette
+piste ne décide pas le boss et ne transforme pas le lieu en réacteur nucléaire.
+
+**Le déblocage est collectif et permanent à l’échelle du serveur.** Une fois
+cette étape accomplie, chaque joueur peut fabriquer son propre portail vers les
+Cavernes, y compris s’il rejoint le serveur plus tard. Il n’a pas à refaire
+individuellement le donjon ni à obtenir l’objet de quête pour chaque portail.
+La construction des portails, leur recette et leurs modalités d’activation
+restent à définir.
+
+La stabilisation porte ici sur les portails vers cette dimension. Son sens
+cosmologique éventuel n’est pas fixé.
+
+La préparation du donjon doit être possible avant cet accès, avec les ressources
+disponibles sur l’île. Le nécromancien et sa boule de cristal déjà prévus dans les
+Cavernes restent une rencontre ultérieure distincte : on ne doit pas devoir
+entrer dans cette dimension pour obtenir la clé de son premier accès. Aucun
+prérequis supplémentaire pour l’expansion des continents n’est décidé ici.
 
 Sa nécessité impose de concevoir sa présence et son accessibilité sur l’île.
 Un lieu indispensable ne peut pas être traité comme une décoration facultative
@@ -150,10 +441,10 @@ dont l’absence serait sans conséquence. Les contraintes de génération devro
 - **Fonction ancienne :** qu’avait-on résolu ou protégé dans ce lieu ? Ne pas décider par défaut que c’est le réacteur.
 - **Découverte :** indices depuis la surface, tunnels d’approche, entrée principale et éventuels raccourcis.
 - **Difficulté :** type de préparation attendu, dangers des salles et possibilités de retraite.
-- **Boss :** identité, relation au lieu, comportements reconnaissables et conditions de victoire.
-- **Objet de quête :** ce qu’il est, ce qu’il débloque et s’il est consommé, conservé ou installé.
-- **Coopération :** victoire et déblocage à l’échelle du joueur, du groupe ou du serveur ; accueil des joueurs arrivés plus tard.
-- **Persistance :** combat unique ou rejouable, partage du butin, conséquence d’un objet perdu ou d’un site endommagé.
+- **Boss :** choisir entre zombie géant et golem de pierre, puis préciser sa relation au portail, ses comportements et les conditions de victoire. Les dix joueurs des raids ne deviennent pas un effectif requis pour ce combat.
+- **Objet de quête :** sa nature, la manière de stabiliser les portails et s’il est consommé, conservé ou installé.
+- **Activation collective :** geste qui valide l’étape pour tout le serveur ; devenir de l’objet après cette validation. La portée du déblocage et l’accès des nouveaux arrivants sont acquis.
+- **Persistance :** combat unique ou rejouable, partage du butin et récupération d’un objet perdu avant activation. Le déblocage déjà acquis reste permanent si l’objet ou le lieu est ensuite perdu ou endommagé.
 - **Après la victoire :** usage de la structure, exploitation éventuelle des spawners, accès aux galeries et ressources restantes.
 
 La direction antérieure des donjons prévoit des reliques collectives uniques et
@@ -166,16 +457,43 @@ parfois connectés, sans imposer une galerie continue sous toute l’île. La gr
 traversée utile aux déplacements et le parcours difficile du donjon doivent être
 distingués lors du dessin de leurs accès.
 
+### Raids instanciés — chantier futur distinct
+
+**Le portail des raids se découvre sur une île générée par expansion.**
+Cette direction remplace son placement sur Sanctuary Island ; le laboratoire
+des Cavernes reste dans l’île initiale. Générer une île donne une nouvelle
+destination à explorer, puis l’accès au raid est à découvrir et débloquer.
+Les conditions précises, la fréquence du lieu et sa garantie éventuelle ne sont
+pas fixées : toutes les expansions ne reçoivent pas automatiquement un portail.
+Il faut y réunir **dix joueurs** pour lancer l’épreuve.
+**Un raid pour tout le serveur par semaine**
+reste la limite commune. Le lieu d’accès est physique et persistant ; la
+destination est un donjon difficile généré procéduralement dans une instance,
+en **mode aventure**, avec une palette de blocs propre à concevoir. L’inspiration
+donnée est celle des **Trial Chambers**, développée à une autre échelle ; elle
+ne fixe pas automatiquement leurs blocs, spawners ou règles de récompenses.
+
+Le **butin est commun et matériel** : les joueurs le ramassent et le répartissent
+entre eux, avec une quantité à équilibrer pour dix. Il n’y a ni dix récompenses
+personnelles automatiques, ni partage égal imposé. Cela remplace l’ancienne
+direction de butin personnel pour ces raids seulement. Consommation du quota,
+déconnexions, échec, retour et réutilisation de l’instance restent dans le
+[chantier de progression](progression-et-integrations.md#raids-collectifs-instanciés).
+
+Ce souhait ne remplace ni le donjon majeur qui débloque collectivement les
+Cavernes, ni les tunnels et systèmes de farming du monde persistant. Aucun raid,
+Indoor ou rythme de réinitialisation n’est implémenté par ce cahier.
+
 ## Décisions ouvertes et ordre de discussion
 
 | Étape | Résultat attendu | État |
 | --- | --- | --- |
 | 1. Fonctions reproductibles | Règle commune et place des exceptions collectives. | Principe retenu ; exceptions à nommer. |
-| 2. Salle d’expansion | Lieu rééquipable et installation reproductible ailleurs. | Retenu ; contenu initial à définir. |
-| 3. Sélection | Observatoire, salle d’expansion, atelier caché, grande traversée et donjon majeur. | Retenue ; tunnels supplémentaires et fréquences à définir. |
-| 4. Objet du donjon | Étape de progression débloquée, puis nature du boss et de l’objet. | Question en cours. |
-| 5. Territoire | Arrivée, découverte, quantités, espacements et différences entre les trois tailles. | À définir. |
-| 6. Fiches des lieux | Plans, utilité immédiate, indices, matériaux et état d’abandon. | À définir pour la sélection retenue. |
+| 2. Salle d’expansion | Grande salle essentielle et rééquipable ; réseau d’égouts et de canalisations avec plusieurs accès, sans piscine voisine. | Direction retenue ; trappe conservée, éclairage redstone, tracés et contenu initial à définir. Correspondance « salle de transformation » à confirmer. |
+| 3. Sélection | Sur l’île initiale : observatoire, salle d’expansion, atelier caché, grande traversée, train et rails abandonnés, laboratoire des Cavernes. Sur une expansion : accès secret aux raids. | Retenue ; bâtiments ordinaires écartés de l’île initiale, tracés sans bâtiment terminal permis, plans et distribution à définir. |
+| 4. Objet du donjon | Accès au monde de minage par victoire sur le gardien du laboratoire, puis stabilisation des portails. | Déblocage collectif permanent annoncé au serveur ; chacun peut ensuite fabriquer son portail. Zombie géant ou golem de pierre, objet et activation à définir. |
+| 5. Territoire | Arrivée naturelle, lieux secrets de l’île, Lost Cities surtout sur les continents ; quantités, espacements et différences entre les trois tailles. | Direction retenue ; valeurs à définir, sans redimensionnement pour la cible d’environ vingt joueurs. |
+| 6. Fiches des lieux | Plans, usages concrets des appareils, indices, matériaux et état d’abandon ; systèmes à reproduire. | À définir pour la sélection retenue ; cartes au trésor comme piste d’information. |
 | 7. Machines | Rôles et connexions nécessaires pour dimensionner la salle. | Concepts en discussion. |
 | 8. Contrat de génération | Garanties, refus, ressources, exemples visuels et critères d’essai. | À définir avant de créer les tickets de code. |
 

docs/vision.md

@@ -10,6 +10,12 @@ La cible demandée est **Minecraft 26.3 avec Fabric**. Au démarrage du dépôt,
 
 Sanctuary transforme Minecraft en un monde flottant d'exploration, de production et de progression collective. Tous les joueurs commencent sur l'île de Sanctuary, isolée dans le vide. Leurs constructions, leurs explorations et leurs chaînes de production permettent d'ouvrir de nouveaux continents suspendus.
 
+La cible de conception est un **RPG dans Minecraft pour une communauté d’environ
+vingt joueurs**. Construction, redstone, exploration, minage, PvE et PvP doivent
+trouver leur place dans cette progression. Les joueurs peuvent se compléter
+sans devoir tous pratiquer chaque activité ni apprendre l’assembleur. Cette
+cible de communauté ne change pas les trois tailles d’île 512/724/1024.
+
 L'objectif mythologique est de progresser d'une condition très limitée, proche du hardcore, vers les possibilités du mode créatif, par la coopération. Le serveur conserve l'histoire de cette transformation : les continents ouverts, les ressources produites, les événements, les étoiles et les constellations. Battre l'Ender Dragon devient un événement parmi d'autres, et non la conclusion obligatoire d'une campagne.
 
 ## Principes de conception
@@ -20,12 +26,13 @@ L'objectif mythologique est de progresser d'une condition très limitée, proche
 - **Une progression par l'expérience et la production.** L'XP sert aux capacités, aux transports et aux actions créatives ; les ressources et les métiers soutiennent l'expansion.
 - **Un monde aux ressources localisées.** Il faut partir explorer pour trouver certains biomes, cultures, structures et matériaux.
 - **Humour, surprise et souvenirs.** Les noms d'entités, les événements, les animaux rares et les objets insolites comptent autant que les systèmes économiques.
+- **Identités et transformations.** Porter une mythologie implicitement queer : apparences et changements de forme ne déterminent ni identité, ni métier, ni capacités. Chacun définit son personnage ; cette lecture culturelle appartient à Sanctuary. Voir les [identités dans le lore](histoire-steve-galactium.md#identités-apparences-et-transformations).
 - **Un développement par tickets.** Livrer une petite mécanique jouable et vérifiable, puis l'ajuster avec des tickets de fonctionnalités et de bugs. Ne pas construire tous les systèmes avant de pouvoir jouer.
 
 ## Minecraft comme archéologie d’un autre Minecraft
 
 **Canon et ligne de conception retenus.** Steve, Ari, Sunny, Kai, Zuri, Alex,
-Mefe, Makena, Noor sont les personnages disparus de la partie. Ils ont découvert
+Efe, Makena, Noor sont les personnages disparus de la partie. Ils ont découvert
 quelque chose de révolutionnaire et ont continué parce que ça marchait. Jusqu’au
 moment où ça n’a plus marché.
 
@@ -43,6 +50,45 @@ catastrophe précise n’est confirmée par ce principe. **La mise en scène de
 histoire et ses liens avec la progression restent à implémenter** ; les versions
 livrées et leurs tests établissent ce que chaque structure contient effectivement.
 
+La [mémoire de Steve et la naissance de Galactium](histoire-steve-galactium.md)
+propose une mythologie fondée sur la chronologie documentée des mises à jour :
+Steve, puis Alex, puis les sept personnages apparus ensemble en 2022. Les dates
+et contenus de Minecraft sont séparés des biographies et des causes inventées
+pour Sanctuary. L’orthographe Efe est retenue ; les rôles et le dénouement de ce
+récit restent à valider.
+
+**Galactium est le vide qui structure ce qui l’entoure.** Ce fondement cosmologique
+et le système d’expansion qui en exploite les effets portent le même nom.
+L’approche souhaitée est celle de l’exploration et de l’ingénierie de science-fiction :
+les anciens savent provoquer certains phénomènes avant d’en comprendre toute la
+nature. Sa portée peut évoquer le divin ; conscience et volonté restent ouvertes.
+Le [cahier mythologique](histoire-steve-galactium.md#mathémagie-commune) développe
+cette direction sans fixer une nouvelle cause à leur disparition.
+
+Un [accueil avant la première apparition](histoire-steve-galactium.md#entrer-dans-la-mythologie--accueil-avant-la-première-apparition)
+est demandé dans cet ordre : **fiche personnage d’abord**, avec skin, pseudo et
+bio, puis **courte cinématique d’initialisation**, puis arrivée naturelle.
+La séquence en alphabet galactique intervient après la fiche ; elle accompagne
+l’initialisation du personnage et une figuration graphique de recherche d’un
+emplacement sûr, comme un ordinateur qui démarre. Le choix réel de l’emplacement
+et sa vérification appartiennent au serveur ; les détails visuels restent à
+concevoir. L’ancien scénario avant le profil est retiré. L’archive qui semble
+se mettre à jour seule reste une piste sous-jacente, à découvrir plutôt qu’à
+expliquer dans l’accueil.
+Des **amitiés natives et une visibilité publique ou réservée aux amis** sont
+demandées. Bio facultative, amitié après acceptation et partage limité au serveur
+sont détaillés dans le [cahier d’accueil et des profils](accueil-et-profils.md).
+La lecture queer reste implicite, sans identité assignée ni formulaire d’identité
+imposé. Gestes, durée et mise en scène restent à discuter ; aucun écran,
+cinématique ou système social n’est livré.
+**Rattachement au compte retenu :** la présence dans cette histoire, les actes
+et la progression du personnage sont liés à l’UUID du compte du joueur dans le monde
+concerné. Le pseudo et le skin actuels servent à le présenter et peuvent évoluer.
+La première apparition effective sur le serveur, après la cinématique, publie
+une seule fois **« helloworld {pseudo} »** ; les connexions suivantes gardent
+le message habituel **« {pseudo} joins the game »**, avec suivi par UUID et pseudo
+actuel à l’affichage.
+
 ## Périmètre de départ
 
 Le premier incrément porte sur le socle Fabric et la génération du monde : retrouver le générateur 26.2, produire une île principale dans un vrai vide, assurer une arrivée commune et sûre, puis poser une manière reproductible de générer des continents à une distance, une direction et une taille choisies.
@@ -68,6 +114,16 @@ L'apparence du pack peut inclure les mentions affichées, les crédits, l'icône
 
 Les intégrations communautaires envisagées comprennent Fabric API, Sodium, Iris, Vitrail, Indium, Just Enough Items, Simple Voice Chat, Xaero's Minimap et Dynamic Torches. Golden Days est envisagé pour l'apparence du monde Alpha, et Litematica pour les plans de construction. Ce sont des pistes d'intégration : la disponibilité sur la version cible, les noms exacts, les dépendances et les conditions de distribution doivent être vérifiés au moment de chaque ticket.
 
+La conception ajoute **AppleSkin**, **Carry On** comme
+référence de portage, **Sound Physics Remastered** pour l’acoustique et
+**NetherPortalFix** comme correctif potentiel du pack. Le
+[cahier de progression et d’intégration](progression-et-integrations.md)
+distingue les capacités à débloquer, les systèmes natifs et les préférences
+personnelles. Laisser shaders, HD et acoustique optionnels dès le départ est
+la proposition actuelle ; les correctifs ne sont pas des récompenses à gagner.
+Nature’s Compass et la recherche automatique de biomes sont retirés de la
+sélection actuelle, au profit de l’exploration des îles et de leurs climats définis.
+
 **TerraMix** désigne ici le catalogue natif de 100 biomes d'**Another World**, retrouvé dans l'historique 26.2. Sa reprise et son extension sont une piste pour les continents ; ce nom ne désigne pas une nouvelle dépendance externe obligatoire.
 
 ## Monde flottant et expansion
@@ -190,21 +246,98 @@ Leur géographie doit rester variée : perforations et passages de vide, océans
 
 L'ambition est de reprendre puis d'étendre la centaine de biomes du catalogue TerraMix d'Another World, avec des biomes originaux comme le **Black Desert**. Cette diversité sera introduite après la validation du terrain de base et de son adaptation technique.
 
+Les **expansions pourront aussi accueillir un biome étrange à dominante de
+mycélium**. Cette possibilité est explicitement retenue pour le chantier des
+continents ; palette, formes, végétation et fréquence restent à concevoir.
+La présence de mycélium déjà discutée pour l’intérieur de Sanctuary Island ne
+remplace pas cette nouvelle intention de biome d’expansion.
+
+Les très grands continents pourront contenir des **océans** accueillant des
+temples ou monuments sous-marins, avec une rencontre de boss aquatique à définir.
+Un **mob géant vivant dans un volcan** est également souhaité ; son identité,
+son rôle et ses récompenses restent ouverts. Ces lieux ne sont pas imposés à
+chaque expansion et ne changent pas les tailles de l’île initiale.
+
 ### Structures et territoires
 
 **Direction en conception après l’alpha.22 :** départ dans un endroit naturel,
 puis découverte de quelques lieux isolés. La sélection retient l’observatoire,
-la salle d’expansion, un atelier caché et la grande traversée, avec l’ajout à
-concevoir d’un donjon difficile, un boss et un objet de quête essentiel à la
-progression. Les villes, regroupements et autres structures restent en réserve.
+la salle d’expansion, un atelier caché et la grande traversée. **Le train et les
+rails abandonnés au milieu de l’île sont conservés**, même sans bâtiment au bout :
+ils donnent des axes aux constructions futures et invitent à réparer le réseau.
+Un **immense laboratoire caché** précise le donjon majeur : il contient le portail
+des Cavernes et un gardien à choisir entre **zombie géant et golem de pierre**.
+La victoire sur ce gardien permet de stabiliser les portails pour tout le serveur de façon
+permanente, avec un achievement collectif annoncé. Chaque joueur pourra ensuite
+construire son portail ; l’usage initial de l’objet de quête reste à préciser.
+**Les Lost Cities sont principalement destinées aux continents d’expansion.**
+Sur Sanctuary Island, la sélection conserve les secrets et passages souterrains ;
+les autres bâtiments sont écartés de la prochaine sélection et restent en réserve.
+Retirer une gare ne retire pas ses rails. Le **portail des raids est un secret
+d’une île générée par expansion**, à découvrir puis débloquer ; sa
+fréquence et ses conditions restent à préciser. Fréquences et implantation des
+villes sur les expansions seront définies avec leur génération. Cette direction
+prépare l’alpha.23 sans en lancer l’implémentation ni promettre que tous les
+systèmes associés seront jouables dans cette version.
+
+Sur les petites expansions, y compris une île de **64 blocs de rayon**, une
+ville pourra déborder de la roche et comporter des parties suspendues. Le
+placement reste cohérent par ses accès, raccords et volumes ; ce dépassement
+n’est plus à lui seul un motif de refus. Cette exception ne force pas toutes
+les villes et ne réintroduit pas de centre-ville sur Sanctuary Island. Le rayon
+évoqué ici n’est pas un nouveau preset ni un diamètre de 64 blocs.
+
 Les fonctions sont reproductibles chez les joueurs, y compris l’installation
 d’expansion ; quelques exceptions collectives restent à définir. La salle
-ancienne peut être rééquipée et servir de modèle. Voir le
+ancienne peut être rééquipée et servir de modèle. La « salle de transformation »
+évoquée par l’auteur est rapprochée ici de cette grande salle d’expansion ;
+son nom et sa fonction détaillée restent à préciser. Elle garde une place
+centrale dans la découverte, indépendamment d’une ville au-dessus.
+
+**La piscine voisine de la salle d’expansion est écartée de la prochaine
+sélection**, faute d’usage retenu. La priorité devient un réseau d’égouts et
+de canalisations **éclairé par de la redstone**, avec plusieurs voies de
+découverte vers la salle. La trappe reste un accès possible parmi d’autres.
+Les galeries peuvent sortir des parois, ouvrir sur l’extérieur et traverser le
+vide en tronçons suspendus, avec des raccords et une construction lisibles.
+Les autres pool rooms restent en réserve. Cette révision de conception ne
+supprime aucune structure d’un monde existant.
+
+Les salles secrètes montrent des **installations utilisables et reproductibles** :
+terminaux, contrôleurs, afficheurs et disquettes associés à des coffres, hoppers
+et comparateurs. On découvre une ancienne solution en observant ses effets,
+puis on peut comprendre le montage et le réemployer. Les scènes doivent créer
+des découvertes marquantes par leur fonctionnement. De grandes salles peuvent
+accueillir plusieurs montages de farming, sans panneaux explicatifs : le joueur
+étudie les flux, les machines, la redstone et les programmes. Les afficheurs
+gardent leurs sorties fonctionnelles. Les programmes sont obtenables, partageables,
+duplicables et revendables. Les programmes précis, l’état
+initial des appareils et les conditions de récupération restent à concevoir. Voir le
 [cahier de conception en discussion](structures-conception.md).
+
+La sélection s’ouvre aussi à des **lieux aériens présents dans le monde initial,
+encore inexplorés**. Un ou deux îlots suspendus sont envisagés, riches et dotés
+d’un coffre enterré. Une cascade peut servir d’accès, mais elle n’est pas
+obligatoire et peut tomber dans le vide indépendamment du terrain dessous.
+Des bateaux marchands se répartissent en périphérie de Sanctuary et constituent
+la première voie pour obtenir des villageois. Les montgolfières détiennent des
+richesses ; le navire amarré précédemment proposé est abandonné. Visibilité,
+accès, commerce et déplacement éventuel de ces structures restent à concevoir.
+Les temples sont retirés de la génération de base, conservés comme piste future
+autour de Sanctuary d’inspiration Nether à préciser, sans implémentation immédiate.
+Ces sites initiaux ne demandent pas de charge Galactium ni de pré-génération
+massive ; ils conservent le départ naturel et peuvent accueillir pages, plans ou programmes.
+
 Ces décisions préparent la suite ; les paragraphes datés ci-dessous conservent
 l’historique des versions et ne signifient pas que cette nouvelle sélection est
 déjà implémentée.
 
+Un **laboratoire de confinement animal** est également souhaité dans les
+expansions, avec des cellules ou enclos contenant notamment des **Mooblooms**.
+Architecture, ouverture et extraction restent à dessiner. Ce nouveau lieu ne
+réintroduit pas le choix de génération Laboratory et n’est pas ajouté à l’île
+initiale par cette intention.
+
 - **Structures vanilla** : admises dans les nouvelles générations lorsque leur
   biome, leur emprise et leurs fondations conviennent au terrain flottant.
   L’autorisation ne garantit pas leur présence sur chaque île. Le laboratoire
@@ -281,6 +414,22 @@ déjà implémentée.
 | **Backrooms** | Monde sombre à plusieurs niveaux, exploré avec une source de lumière. Les joueurs y arrivent dans un lit. Il reçoit dans des coffres les objets perdus dans le vide ou brûlés ; c'est aussi un territoire d'exploration et un lieu de quête. |
 | **Indoors** | Petits espaces associés à des objets, déclinés en classes de volume, avec une taille indicative allant de 5 × 5 × 5 à 100 × 100 × 100 blocs. Ils peuvent servir d'intérieurs, de salles secrètes ou de lieux d'événements. |
 
+**Accès au monde de minage — décision de conception :** vaincre le gardien de
+l’immense laboratoire caché dans Sanctuary Island permet de débloquer et
+stabiliser les portails vers les Cavernes. Le portail du laboratoire est éteint
+ou instable avant cette victoire. Zombie géant ou golem de pierre, objet de quête
+éventuellement utilisé et geste d’activation restent à préciser. Un achievement
+de serveur annonce le premier déblocage à tous, avec une formulation à concevoir.
+Ce déblocage est collectif et permanent à l’échelle du serveur :
+une fois cette étape accomplie, tous les joueurs, y compris les nouveaux arrivants,
+peuvent construire leur propre portail. Il n’est pas nécessaire de refaire le
+donjon individuellement ni d’obtenir l’objet de quête pour chaque portail.
+Les modalités d’activation initiale, ainsi que la construction et
+la recette des portails, restent à définir dans le
+[cahier des lieux](structures-conception.md#donjon-majeur-et-tunnels-supplémentaires).
+Ce donjon de l’île est distinct de la rencontre du nécromancien dans les Cavernes.
+Les portails et cette progression ne sont pas encore implémentés.
+
 La géométrie des indoors reste à décider : certains peuvent être des volumes précisément délimités, d'autres des espaces fermés qui se rebouclent en trois dimensions, de type tore 3D. Leurs objets d'accès sont liés à la mailbox de leur propriétaire et doivent être récupérables s'ils sont perdus. Les règles de propriété, de partage, de transfert et de sortie sûre seront définies avant leur implémentation.
 
 ## Progression personnelle et collective
@@ -293,21 +442,105 @@ L'XP et les niveaux permettent d'acheter des améliorations. L'exemple de courbe
 
 Les capacités peuvent atteindre les valeurs usuelles de dix cœurs, dix icônes de nourriture et une respiration complète par la progression normale en XP. Le nombre d'étapes et les plafonds seront arrêtés dans les tickets concernés.
 
+Les **compétences** s’achètent par paliers : notamment vie, faim, vitesse de
+minage et portée de construction. Les capacités de vein mining et de vein
+building se débloquent avec les paliers de Mining et de Build, sans achat
+séparé. Les **unlocks** ajoutent des outils facultatifs,
+par achat unique ou par paliers. La liste définitive des compétences inclut les
+progressions déjà prévues de respiration et d’inventaire et reste à arrêter
+avant équilibrage ; cette distinction ne crée pas une compétence de vitesse
+de déplacement.
+
+Le **mode galactique** ouvre des facultés endgame lorsque **toutes les compétences
+du personnage sont au maximum**. L’accès au catalogue complet des builds en est
+la première faculté définie ; les autres restent à imaginer. Atteindre ce stade
+ne débloque pas gratuitement les facultés et ne déclenche pas un prestige.
+
 ### Inventaire, prestige et déblocages
 
 L'inventaire commence à une rangée et peut s'étendre jusqu'à six par la progression normale. La place de la barre rapide dans ce comptage reste à préciser.
 
-Les **prestiges débloquent des slots de factions**. Ils ne donnent pas de capacités bonus ni de rangées d'inventaire supplémentaires. Le nombre de slots accordés par prestige et leurs règles d'utilisation seront précisés dans les tickets de factions.
+Les **prestiges donnent des charges personnelles à dépenser pour ajouter des
+places dans sa faction** et témoignent d’une progression recommencée.
+Ils deviennent accessibles lorsque **toutes les compétences sont
+au maximum**, sans exiger tous les unlocks ni les facultés galactiques. Ils ne
+donnent pas de capacités bonus ni de rangées d’inventaire supplémentaires.
+**Les unlocks achetés restent acquis ; les compétences reviennent au départ
+et sont à remonter.** Le vein mining et le vein building suivent les compétences
+remises au départ ; Mining au niveau zéro désactive de nouveau le vein mining.
+Ces techniques ne sont pas des unlocks conservés à leur ancien palier. Le
+devenir des facultés galactiques déjà achetées,
+l’XP restante, les collections, le nombre de charges gagnées, le coût des places
+et leurs règles d’utilisation restent à préciser.
 
 La progression peut débloquer une table de fabrication dans l'inventaire, des capacités de minage et de construction, et l'accès à certaines fonctions de mods communautaires. Les joueurs peuvent également porter des capes et des familiers ; les spawn eggs correspondent à différents pouvoirs de familier.
 
 Les recettes de Just Enough Items sont révélées par paliers liés aux advancements. Les advancements Minecraft donnent accès aux recettes Minecraft ; ceux de Sanctuary ouvrent les blocs décoratifs, équipements et systèmes correspondants. Il faudra distinguer dans chaque ticket l'affichage des recettes, leur connaissance et l'autorisation réelle de fabriquer.
 
+La progression doit aussi articuler **minimap, carte du monde, waypoints, alchimie,
+enchantement et bibliothèque de plans**. Xaero’s Minimap et Litematica sont des
+références d’intégration ; un repère ne donne pas un droit de téléportation.
+Déblocages personnels, étapes collectives, coûts et informations affichées
+seront définis par capacité. Le serveur conserve les acquis ; installer un
+mod et débloquer une de ses fonctions sont deux opérations différentes.
+Les waystones s’apprennent aussi par leur présence dans les îles générées :
+un ascenseur peut relier un étage à une installation ou à un laboratoire.
+
+L’indicateur alimentaire est un unlock facultatif. Un HUD inspiré d’AppleSkin
+ou adapté depuis ce mod doit suivre la faim et la santé réellement disponibles
+et employer les textures Sanctuary.
+Un toggle permettrait de consulter l’état de l’équipement et sa durabilité.
+Les gestes de transfert et répartition des stacks seront natifs à Sanctuary
+pour respecter les slots de l’inventaire incrémental ; Mouse Tweaks et les
+profils de mods communautaires ne constituent pas la base retenue pour cette logique.
+Voir les [capacités et leur contrat de déblocage](progression-et-integrations.md).
+
+Les emplacements de cape et de familier complètent l’équipement. Le slot de
+spawn egg est envisagé au-dessus de la main secondaire ; chaque œuf pris en
+charge associe un **passif et un actif commandé par une touche configurable**.
+La réécriture des familiers vise surtout leur présence : collisions avec le
+décor, montée et descente des obstacles, sans collision gênant les joueurs.
+Ils ne donnent aucun loot ; leur mortalité reste ouverte. La collection prévoit
+des raretés dont la hiérarchie reste à préciser ; Ender Dragon et Wither sont
+galactiques. Effets, délais et acquisition restent à définir ; ces
+slots d’équipement n’attribuent pas automatiquement de nouvelles rangées de stockage.
+
+Un **slot cosmétique au-dessus de la cape** reçoit des créations d’artiste 3D
+à débloquer en jeu, notamment dans des loots cosmétiques. Aucun pouvoir ni bonus
+n’est associé à cet équipement d’apparence.
+
+Le [journal des transformations](journal-et-progression-du-monde.md) doit suivre
+les entrées, sorties, procédés et leur succession pour alimenter plans proposés,
+Backrooms, Indoors et donjons. Ce suivi causal reste à développer : les totaux
+journaliers actuels ne permettent pas de reconstituer ces chaînes.
+
+### Informations à découvrir
+
+L’exploration apporte aussi des outils pour agir : des programmes sur disquette,
+des cartes au trésor et les connaissances du Blocodex.
+
+- **Cartes au trésor** : une croix indique un coffre réellement caché dans le sol
+  d’une île déjà générée. Trouver une carte n’ouvre pas une expansion. Attribution,
+  contenu du coffre et partage des découvertes restent à définir.
+- **Palettes du Blocodex et advancements** : les familles de matériaux sont
+  reliées à la progression Minecraft et Sanctuary pour ouvrir l’accès à des
+  articles achetables au Black Market. La correspondance entre palettes et
+  advancements, ainsi que la portée personnelle ou collective, restent à définir.
+
+Le Blocodex actuel conserve des preuves personnelles de connaissance des blocs
+et propose des palettes ; il ne confère pas de droits d’achat. L’intégration
+future distinguera **connaissance, déblocage commercial, offre disponible et
+paiement**. Voir ou posséder un bloc ne remplace pas automatiquement l’advancement
+requis. Les palettes de blocs ne couvrent pas à elles seules les équipements
+ou anomalies ; leurs conditions demanderont une définition propre. Le déblocage
+commercial ne fournit aucun objet gratuitement et ne débloque pas implicitement
+sa fabrication.
+
 ### Construction et production
 
-- **Mining** améliore la vitesse de minage et ouvre le vein mining : extraction de blocs d'une même veine ou sur un plan défini par l'orientation du joueur.
-- **Building** ouvre des outils de pose et de remplissage de surfaces, dont le vein building.
-- **Plans et préfabriqués** : conserver et copier ses constructions, puis accéder à un catalogue de prefabs. Une intégration adaptée de Litematica est envisagée. Un ancien concept de « voxelier » dans un ordinateur permettait de créer des modèles en cubes ; cette piste est considérée comme complexe et n'est pas prioritaire.
+- **Mining** améliore la vitesse et débloque le **vein mining** à ses paliers. Au niveau 0, il est désactivé ; le premier repère donné est **4 blocs au total dès le niveau 1**. Les paliers suivants augmentent la taille du groupe, avec **64 blocs** comme exemple avancé, sans courbe ni plafond fixés. Tous les blocs sélectionnés commencent à être minés simultanément ; la durée dépend du groupe, des blocs, de l’outil et de Mining. Un groupe plus grand demande plus de temps. Le geste évite les manipulations répétées entre les blocs tout en conservant un travail de casse perceptible.
+- **Building** améliore la portée et débloque le **vein building** à ses paliers : remplir un trou ou une surface sur un seul plan, avec les matériaux du joueur et dans sa portée acquise. Les seuils et nombres de blocs restent à définir. Ces deux techniques font partie des compétences, sans unlock acheté séparément. Voir le [contrat des paliers et des gestes](progression-et-integrations.md#vein-mining-et-vein-building--paliers-des-compétences), dont durées, usure et interruptions restent à préciser.
+- **Plans et préfabriqués** : reprendre l’intention d’Architext avec **Minecraft Schematics** comme source retenue et Litematica comme outil envisagé. Le menu Build permet de parcourir les plans acquis et leurs prévisualisations. Combat et obtention de blocs associés peuvent ouvrir ou proposer des architectures. Lorsque **toutes les compétences du personnage sont au maximum**, une **faculté galactique**, pour un coût proposé de **64 niveaux**, ouvre le catalogue complet du site. Cet achat n’est pas requis pour le prestige, ne livre pas les matériaux ni une pose gratuite. Chaque création conserve auteur, source, format et conditions de réutilisation. Partage et doublons restent à définir ; le « voxelier » d’édition de modèles en cubes n’est pas prioritaire. Voir le [cahier des plans](progression-et-integrations.md#architecture--une-collection-de-savoir-faire).
 
 ## Monnaies, propriétés et échanges
 
@@ -318,16 +551,82 @@ Les trois gemmes forment la palette et la symbolique triangulaire de Sanctuary.
 | Gemme | Fonction souhaitée |
 | --- | --- |
 | **Émeraude** | Économie locale des villageois, échanges et travail dans le monde. |
-| **Rubis** | Monnaie des échanges passant par les services du serveur et ses boutiques. Nouveau minerai à extraire. |
-| **Saphir** | Réservation et sauvegarde de quantités limitées d'objets dans le catalogue. Nouveau minerai à extraire. |
+| **Rubis** | Monnaie principale entre joueurs et boutiques, dont le Black Market et la bourse du navet. Nouveau minerai à extraire. |
+| **Saphir** | Certains achats au Black Market et réservation de quantités limitées dans le catalogue. Articulation et offres concernées à définir. Nouveau minerai à extraire. |
 
 ### Mailbox, dépôts et boutiques
 
 Chaque joueur a une **mailbox** et le serveur dispose de **deposit boxes** pour les apports collectifs. Les achats autorisés sont livrés dans la mailbox. Les échanges doivent pouvoir être reliés à la progression du serveur et aux ressources qu'il conserve.
 
-Le shop propose des offres flash renouvelées toutes les heures. Le joueur peut débloquer jusqu'à neuf emplacements avec son XP. Le black market accueille les offres des joueurs ; le catalogue permet de réserver une quantité limitée d'un objet contre des saphirs. Des extensions et emplacements supplémentaires peuvent apparaître comme récompenses d'événements.
+**Le Black Market désigne désormais le shop en ligne du serveur Sanctuary.**
+Cette définition remplace l’ancien usage du nom limité aux offres des joueurs.
+On y trouve des biens courants et certaines anomalies, avec des achats en rubis
+ou en saphirs selon les offres. La nature des anomalies vendables reste à définir ;
+elle n’autorise pas automatiquement la vente de tout équipement rare ou objet de quête.
+Les palettes et advancements peuvent ouvrir des articles au catalogue, sans
+garantir qu’une offre soit en stock ni qu’elle soit gratuite.
 
-Le shop pourrait devenir une infrastructure coûteuse à construire, accessible physiquement et située en fin de progression. Sa forme exacte reste ouverte : bâtiment joueur, service du serveur ou combinaison des deux. Des casinos événementiels peuvent être installés dans de grands indoors où les joueurs se retrouvent.
+Le shop propose des offres flash renouvelées toutes les heures. Le joueur peut
+débloquer jusqu’à neuf emplacements avec son XP. Le catalogue conserve la piste
+des réservations en saphirs, à articuler avec les achats. Des extensions et
+emplacements supplémentaires peuvent apparaître comme récompenses d’événements.
+
+Le commerce entre joueurs garde sa propre place : vendre sa production, rechercher
+une ressource et négocier, principalement en rubis. Des échanges convenus en
+émeraudes ou saphirs restent possibles ; aucun taux de conversion n’est fixé.
+Le Black Market doit compléter cette économie et préserver l’intérêt d’explorer,
+de produire et de commercer ensemble. Stocks limités, disponibilités variables
+et conditions de progression sont des leviers à éprouver, sans prix ni quotas
+arrêtés ici. Il ne doit pas fournir systématiquement tout ce que les joueurs
+pourraient produire ou rechercher les uns auprès des autres.
+
+L’accès au Black Market pourrait prendre la forme d’une infrastructure coûteuse
+à construire et accessible physiquement. Son appareil d’accès, sa place dans la
+progression et l’éventuel accueil d’offres de joueurs restent ouverts. Des casinos
+événementiels peuvent être installés dans de grands indoors où les joueurs se retrouvent.
+
+### Boutiques construites avec des blocs vanilla
+
+**Direction demandée : une économie avec des shops construits en blocs
+vanilla+, intégrant les afficheurs.** Le joueur compose son comptoir avec des
+éléments usuels et des fonctions Sanctuary. Le premier modèle proposé est une
+boutique de joueur avec son offre et un stock fini fourni par son propriétaire.
+Son éventuelle publication dans le Black Market, le modèle et son déblocage
+restent à définir.
+
+| Élément proposé | Rôle |
+| --- | --- |
+| Coffre ou tonneau raccordé | Contenir les marchandises réellement mises en vente. |
+| Cadre | Présenter l’article associé à l’offre. |
+| Afficheur | Montrer l’article, la quantité par lot, le prix et les lots disponibles. |
+| Interaction sur le comptoir | Identifier l’acheteur et demander l’achat de l’offre affichée. Le bloc ou la face exacte restent à choisir. |
+| Mailbox | Recevoir une seule fois les achats autorisés, conformément au principe existant. |
+| Contrôleur, facultatif | Programmer l’affichage ou une automatisation ultérieure du magasin. |
+
+Le vendeur choisirait l’article, la quantité du lot et son prix. Les rubis sont
+la monnaie principale retenue pour le commerce. Les autres moyens de paiement
+acceptés par un comptoir restent à spécifier selon les rôles des trois gemmes.
+Offres flash du serveur, vente de stock par un joueur et réservation de catalogue
+conservent leurs règles propres.
+
+Exemple de présentation, sans fixer l’équilibrage : **16 bûches · 3 rubis ·
+5 lots disponibles**. Le prix et la disponibilité proviennent de l’offre et
+du stock exact qui lui est associé. L’afficheur ne déduit pas ces données du
+signal d’un comparateur. Une impulsion redstone seule ne désigne pas un acheteur.
+
+Le serveur doit traiter l’achat comme une opération cohérente : vérifier le
+stock et le paiement, retirer le lot, transférer la somme et attribuer la livraison
+une seule fois. Deux acheteurs ou un transfert par hopper ne doivent pas pouvoir
+consommer le même stock. Les ventes entre joueurs transfèrent une monnaie
+existante ; aucune rémunération ni récompense XP supplémentaire n’est décidée.
+
+La propriété du comptoir, l’accès aux coffres, les hoppers, la destruction,
+le retrait d’une offre et le devenir d’un achat interrompu restent à spécifier.
+Le stock commercial conserve un rôle distinct du coffre-fort et de ses futures
+règles de braquage. Architecture, recette éventuelle d’association au service,
+nombre d’offres par comptoir et place dans la progression sont ouverts.
+Il s’agit d’une conception : aucune boutique, monnaie ou livraison n’est ajoutée
+au jeu par ce document.
 
 ### Bourse du navet
 
@@ -337,27 +636,124 @@ Les **navets** s'achètent **uniquement le dimanche, lors de la loterie**. Penda
 
 Chaque joueur peut posséder un seul coffre-fort. Il contient plus de gemmes qu'un inventaire et permet un porte-monnaie utilisable en jeu. Le coffre doit pouvoir être caché et peut être percé avec une **drill en titane**.
 
-Chaque joueur a une couleur unique, qui sert de couleur d'équipe. Des joueurs peuvent se fédérer en équipes temporaires, factions ou voisinages et partager les gains d'une action, y compris d'un braquage. Les slots de factions se débloquent grâce aux prestiges. Les conditions d'accès, les protections et l'équilibrage entre coopération et conflit devront être explicités dans ces tickets.
+Chaque joueur choisit, **dans la fiche de création de personnage**, une
+**couleur personnelle dans une palette configurée avant la première arrivée**,
+dimensionnée pour la population prévue :
+**20 joueurs, 20 couleurs distinctes**. Une couleur choisie est réservée à
+l’UUID du joueur, y compris hors ligne, et n’est plus disponible aux autres.
+Les teintes peuvent être personnalisées dans cette palette ; les joueurs ne
+choisissent plus librement hors de celle-ci. La faction est indiquée **avant
+le pseudo**, par un nom ou symbole à préciser, et le prestige **après le pseudo
+en chiffres romains**. Changer de faction ne remplace pas la couleur personnelle.
+Voir le [cahier des profils](accueil-et-profils.md#couleur-personnelle-faction-et-prestige).
+
+Des joueurs peuvent se fédérer en équipes temporaires, factions ou voisinages
+et partager les gains d’une action, y compris d’un braquage. **Une faction commence
+avec une capacité de trois membres.** Les prestiges donnent à chaque joueur des
+**charges personnelles**, qu’il peut dépenser dans sa faction pour débloquer des
+places supplémentaires. Ce n’est pas une augmentation automatique selon la somme
+des prestiges des membres ; ces charges sont distinctes de celles de Galactium.
+Quantité gagnée, coût d’une place et devenir des contributions après départ
+restent à définir. Les conditions d’accès, les protections et l’équilibrage entre
+coopération et conflit devront être explicités dans ces tickets.
 
 ## Villageois et automatisation
 
 Une bannière placée au-dessus d'une cloche associe un village à une faction. Faire sonner la cloche permet de mettre à jour l'appartenance des villageois concernés à l'équipe associée. Le rayon, le choix de la bannière et les conflits de cloches restent à spécifier.
 
-Les villageois peuvent être payés en émeraudes pour réaliser des tâches cohérentes avec leur métier vanilla. Trois secteurs se complètent : **récolte**, **transformation** et **services**. Ils peuvent, par exemple, récolter du blé, le déposer dans une boîte ou le moudre. Les copper golems et la redstone participent au transport et aux chaînes de production.
+Les villageois peuvent être payés en émeraudes pour réaliser des tâches cohérentes avec leur métier vanilla, **dans leur périmètre d’action**. Trois secteurs se complètent : **récolte**, **transformation** et **services**. Ils peuvent, par exemple, récolter du blé, le déposer dans une boîte ou le moudre. Les copper golems et la redstone participent au transport et aux chaînes de production. Les matières, déplacements et résultats doivent appartenir à une installation réelle ; le [cahier outils et métiers](redstone-language-objets-et-cristaux.md) propose le contrat, sans livrer ces services.
 
-Les **conveyor belts**, fabriqués notamment avec du cuir de vache, déplacent les objets sous forme de drops dans le sens de pose du bloc. Ils se combinent avec les droppers pour acheminer les ressources sur des distances importantes.
+Les **convoyeurs en cuir** se posent au sol comme des rails. Ils déplacent les drops à une seule vitesse et restent arrêtés sans redstone. La recette forme un H de bâtons avec un cuir au centre. Le sens réglé à la pose/clic et un moteur optionnel pour l’inversion automatique sont des propositions ; l’ancienne convention qui faisait avancer les bandes sans alimentation est retirée. Ils se combinent avec les droppers et récepteurs réels de la construction ; voir leur [fiche](redstone-language-signaux-et-transport.md#convoyeur-en-cuir--déplacer-les-drops).
 
 ## Machines, équipements et redstone
 
-- **Ordinateur 8 bits** : bloc programmable avec six ports d'entrée et de sortie, permettant de construire ses propres comportements de redstone. Des évolutions en contrôleur et en ordinateur d'interface donnent accès, dans le monde, aux systèmes d'expansion.
-- **Installation d’expansion à définir** : assembleur, bloc contrôleur, bloc terminal, bloc de dépôt et ancre spatiale sont les éléments actuellement envisagés. Leurs rôles et connexions restent à concevoir. L’installation pourra être reconstruite ailleurs que dans la salle ancienne ; voir le [cahier de conception](structures-conception.md#ordinateurs-et-installation-dexpansion).
+Le [dossier Redstone Language V0.1](redstone-language-extensions.md) détaille
+le langage et ses appareils au-delà de leurs seuls rôles. Le socle de trois
+blocs informatiques ne limite pas l’extension : **un manque peut révéler un
+nouveau composant à créer**, utilisable seul puis combiné aux contrôleurs.
+Le condensateur est retenu, avec entrée arrière, sortie avant, maintien supérieur
+et gestes décrits dans sa fiche ; les délais chiffrés restent des propositions.
+Le [convoyeur en cuir](redstone-language-signaux-et-transport.md) se pose comme
+un rail, avance à une seule vitesse et s’arrête sans alimentation ; la commande
+d’inversion reste à choisir séparément.
+Une variante à impulsions est explorée : pas fixe et vitesse moyenne réglée par
+une horloge redstone ; elle n’est pas encore retenue à la place de la marche continue.
+La recette demandée dessine un H de bâtons avec un cuir au centre ; le rendement
+reste à définir. Transistor, atténuateur et impulseur sont retirés de la sélection.
+Lecteur de stock, aiguilleur, convertisseur, capteurs et connexions adressées
+restent proposés. L’[exploration des outils et cristaux](redstone-language-objets-et-cristaux.md)
+reste ouverte : le retour sur le porte-outil ne rejette pas les phénomènes plus
+étranges. Aucun de ces nouveaux appareils n’est encore retenu. Les émeraudes
+paient les tâches de métier des villageois dans leur périmètre. Ces fiches
+constituent de la conception, sans nouveaux blocs livrés.
+
+Le [cahier des machines construites](machines-multiblocs.md) retient le principe
+de blocs identiques réunis en une fonction agrandie : **27 fours ordinaires en
+cube plein 3 × 3 × 3**, pour une chauffe commune, des fournées et des recettes
+à chaud ; **27 barils en cube plein**, nommés **Fût**, pour un stockage paginé
+ou défilant. **Fourneau** est le nom proposé pour le grand four ; ses recettes
+et son rendement restent à concevoir. Il reprend le rôle du kitchen oven
+d'It's Alive !, dont les règles culinaires restent propres au mod autonome.
+Le **grand baril de fermentation** traite plusieurs stacks d’une même recette ;
+sa composition n’est pas déduite de celle du Fût. Les capacités et l’intégration
+des cases à l’inventaire custom restent ouvertes.
+
+Les archives deviennent des **collections visibles** : neuf objets par face
+de bloc, **81 par façade 3 × 3 et 324 objets distincts sur quatre façades**.
+Cartes, recettes, disquettes, photos, disques et spawn eggs s’exposent, y compris
+sur une façade seule ; **Présentoir** reste un nom proposé. Les **méga-pistons**
+réunissent neuf pistons pour une **tête 3 × 3 et une course de trois blocs**,
+avec variante collante. La masse poussable reste à définir.
+
+La **Trémie** est retenue : neuf hoppers à plat en 3 × 3 réunissent leur collecte
+et **45 cases** de stockage. Une sortie unique sous le centre est proposée,
+avec un hopper ordinaire dessous pour orienter la suite du circuit. Le
+**Carillon** est retenu pour jouer des accords et de courtes séquences, par
+**assemblage adjacent choisi** de blocs musicaux. Aucune rangée ni forme carrée
+n’est imposée ; l’ordre de sélection comme ordre musical est une proposition.
+
+La **clé à molette dorée** est retenue pour orienter les blocs, notamment
+escaliers et barils, **assembler ou réassembler volontairement les multiblocs
+et les désassembler**. Les **27 fours peuvent rester
+indépendants dans leur cube**, et les méga-pistons retrouver leurs neuf bases
+indépendantes ; cette séparation doit persister après rechargement. Les stocks
+actuels sont conservés, sans rétablir des matières déjà consommées. Clic droit
+pour orienter et sneak-clic pour dissocier sont des gestes proposés. La recette,
+l’usure, les gestes exacts, les autres blocs concernés et le traitement des
+pistons en mouvement ou récupérés restent à préciser dans le
+[cahier des multiblocs](machines-multiblocs.md#clé-à-molette-dorée--assembler-désassembler-et-orienter).
+Le choix vaut explicitement pour les hoppers : **neuf hoppers voisins peuvent
+rester neuf circuits indépendants**, chacun avec ses cases et sa sortie.
+La règle commune est retenue : **les blocs restent indépendants dès la pose**
+et leur assemblage avec la clé est volontaire ; la Trémie reste facultative.
+
+**Métablit** est le nom proposé par l’auteur ; un grand établi collectif gardant
+un projet en préparation est une fonction proposée. La presse à moule est
+écartée. Veilleur et batterie de distribution restent proposés ; bassin,
+serre, écluse et alambic restent en réserve. Ces cahiers ne livrent aucun bloc.
+
+L’[audit redstone Java 26.3](audit-redstone-26.3.md) relie ces intentions aux
+possibilités vanilla déjà présentes : capteurs, mémoires, comparateurs,
+actionneurs, transports et auto-craft. Les ordinateurs concentrent des circuits
+dans des programmes ; les nouveaux appareils et leurs interfaces donnent les
+effets supplémentaires. La lecture du code ne constitue pas leur implémentation.
+
+- **Langage secret et écriture galactique** : reprendre cette écriture de Minecraft pour relier les blocs de redstone programmables, les expansions, les waystones et l’End dans le lore de Sanctuary. Programmation directement en assembleur ; socle de trois blocs : contrôleur avec processeur, RAM et six faces d’entrée/sortie, terminal d’édition/diagnostic et afficheur programmable, avec les disquettes comme supports de programmes. Le bloc Assembleur est retiré ; le terminal assemble le code et l’écrit sur disquette. La base proposée conserve l’état complet du contrôleur ; une liaison série supplémentaire reste en réserve. Grammaire, détails et apprentissage sont en conception dans le [cahier du langage et des machines](langage-et-machines.md). Ces ajouts ne sont pas encore implémentés.
+- **Architecture 8 bits** : piste de calcul interne du contrôleur avec RAM adressable et six faces électriques 0–15. Les textes, inventaires exacts et opérations d’expansion demandent des connexions de périphériques définies. Le contrôleur, le terminal et l’afficheur sont les trois rôles retenus ; leurs capacités ne sont pas trois tailles d’ordinateur déjà implémentées.
+- **Disquettes de langage redstone** : supports physiques pour conserver, transporter et partager les programmes en assembleur. Le parcours terminal → disquette → contrôleur, les copies et les programmes retrouvés dans les ruines sont proposés dans le [cahier des machines](langage-et-machines.md#disquettes-de-langage-redstone). Capacité, recette et chargement restent à définir ; ces objets ne sont pas encore implémentés.
+- **Installation d’expansion à définir** : contrôleur, terminal, afficheur et disquettes composent le socle informatique retenu. La machine utilise une charge collective et des ressources ; elle pourra être reconstruite ailleurs que dans la salle ancienne. Dépôt, ancrage, construction et connexions restent à concevoir ; voir le [cahier de conception](structures-conception.md#ordinateurs-et-installation-dexpansion).
+- **Noyau galactique et charges collectives** : casser le noyau le fait disparaître sans bloc ni fragment récupérable. Le serveur parle en galactique et une charge d’expansion devient disponible pour tous, indépendamment du découvreur ou d’une installation. Les météorites sont une voie de découverte, avec d’autres à définir. Le noyau n’est plus rechargeable ; les ressources alimentent l’installation. Nom du bloc, disponibilité et message restent en discussion dans le [cahier du noyau](langage-et-machines.md#bloc-graine-et-météorites). Aucun bloc ni événement météorique n’est encore implémenté.
+- **Galactium et son interface** : Galactium est le nom retenu pour tout le système d’expansion, qui relie charges collectives, programmes et installations. Une interface est demandée ; une vue du terminal est proposée : réserve, projet d’expansion, ressources et progression, reliés au programme assembleur. Consulter un projet ne réserve pas de charge ; l’engagement intervient au lancement accepté par le serveur. Accès, disposition et règles de dépense restent à définir dans le [cahier d’interface](langage-et-machines.md#réserve-collective-et-interface-galactium). Cette interface n’est pas encore implémentée.
+- **Afficheurs diégétiques** : panneaux extensibles pour des textes dynamiques et des statistiques. Des panneaux adjacents dans un même plan forment un écran carré ou rectangulaire plein, avec raccord visuel CTM et huit lignes par bloc en hauteur : un écran de 3 × 2 blocs offre seize lignes sur trois blocs de largeur. Les formes en L, en T ou trouées sont exclues. Galactium y transmet des coordonnées, des morceaux de programmes et des rendez-vous écrits à l’avance ; leurs champs peuvent s’actualiser depuis les données du serveur. Des mesures comme l’âge de la partie, un stock ou la progression d’un projet sont des usages proposés. Construction progressive, taille maximale, données accessibles et rendu sont détaillés ou restent à préciser dans le [cahier des afficheurs](langage-et-machines.md#afficheurs-diégétiques-textes-dynamiques-et-statistiques). Les anciennes propositions de conseils, histoire, diagnostics ou demandes mystérieuses comme messages de Galactium sont retirées. Ces afficheurs restent à implémenter.
+- **Afficheur programmable à usage général** : le contrôleur pilote librement le contenu de l’écran à partir des entrées, données et opérations accessibles. Chronomètre, calendrier, jauge de coffre et progression sont les programmes de départ retenus, utilisables et modifiables ; les joueurs peuvent créer et partager leurs propres applications sur disquette. La grille de texte est définie, les extensions graphiques et interactions restent à concevoir. Les boutiques vanilla+ prolongent ces usages avec leur propre contrat de commerce.
+- **Programmes à thème — proposition** : associer aux vestiges et dimensions des savoir-faire reproductibles : Régie pour coordonner les installations anciennes, Sonde pour prospecter les Cavernes, Volume pour les Indoors, Trace pour lire les espaces orphelins, Conversion pour les transformations du Nether et Liaison pour l’adressage spatial associé à l’End. Les noms, capacités et lieux d’apprentissage restent en discussion dans le [cahier des programmes](langage-et-machines.md#programmes-à-thème-et-fonctions-des-lieux) ; ils n’ajoutent ni ordre de campagne obligatoire, ni nouveau verrou d’accès, ni dépense de charge généralisée à toutes les dimensions.
 - **Terminal et storage en titane** : stockage de fin de progression, avec jusqu'à 128 coffres connectés consultables par un terminal commun, afin de déposer et retrouver ses objets sans tri manuel constant.
 - **Chunky et clé de chunk** : bloc fabriquable maintenant un chunk actif. Son activation requiert une clé trouvable dans les donjons et structures, afin que le chargement permanent ait une valeur d'exploration et d'échange. L'orthographe des noms sera fixée à partir de l'historique.
-- **Particuleur** : émetteur de particules dont l'effet dépend de l'objet inséré et dont l'intensité dépend du signal de redstone.
+- **Particuleur** : objet inséré au clic droit pour choisir les particules, insertion automatisable par dropper et hopper proposé ; débit croissant avec la force du signal, de l’arrêt à 0 au maximum à 15. Le contrôleur peut régler ce signal et commander l’alimentation. Extraction pour changer d’échantillon, correspondances d’objets, consommation éventuelle et cadence maximale restent à définir dans le [contrat du particuleur](audit-redstone-26.3.md#particuleur--contrat-clair-et-montages). Cet appareil doit aussi fonctionner sans ordinateur.
 - **Caméra** : photographie le jeu et transforme les images en cartes Minecraft utilisables dans les item frames.
 - **Œil d'araignée (spider eye)** : révèle les niveaux de lumière dans le monde, pour visualiser l'intensité de l'éclairage.
 - **Disque blanc** : renommé avec une référence à une vidéo YouTube, il permet d'en jouer le contenu dans un jukebox. La forme exacte de la référence et le comportement audiovisuel restent à décider.
-- **Équipements en titane d'anomaly** : équipements impossibles à fabriquer, indestructibles, avec des enchantements exceptionnellement forts. Les machines fabriquables en titane forment une catégorie distincte.
+- **Équipements Anomaly** : équipements ultimes en titane, impossibles à fabriquer, indestructibles, avec des enchantements exceptionnellement forts et un nom en écriture galactique. Les légendaires peuvent rester cassables ; les machines fabriquables en titane forment une catégorie distincte.
 
 ### Armes et explosifs
 
@@ -375,20 +771,56 @@ Les **lucky blocks** déclenchent volontairement un événement imprévisible, p
 
 | Système | Comportement souhaité |
 | --- | --- |
-| **Waystones horizontales** | Voyager dans une même dimension vers une waystone connue, avec un coût d'XP croissant selon la distance. |
+| **Waystones horizontales** | Téléportation précise dans une même dimension vers une waystone connue, coûteuse en XP, avec un coût croissant selon la distance. |
 | **Waystones verticales** | Ascenseurs : sauter pour monter, se baisser pour descendre. L'étage de destination n'a pas besoin d'avoir été découvert. |
 | **Téléporteur longue distance** | Préparation plus lente, mais grandes distances possibles, avec une arrivée approximative. |
 | **Zipline** | Corde reliant deux installations, jusqu'à une distance indicative de 512 blocs. Un clic droit lance le trajet, moins rapide qu'un minecart à pleine vitesse. |
 | **Grappling rod** | Viser un point pour s'y tirer, avec un risque réel de chute. Consomme des leads qui ne sont pas récupérés. |
-| **Bateau avec poule** | Aéronef simple obtenu en plaçant une poule dans un bateau, permettant notamment le transport de villageois. |
+| **Bateau avec poule** | Aéronef simple obtenu en plaçant une poule dans un bateau. Il peut soulever et transporter par des cordes d’autres bateaux occupés par des villageois ou animaux. |
+| **Booat** | Grand bateau à quatre, mécanique centrale du mod, fabriqué avec quatre bateaux. Quatre joueurs sur l’eau ; deux joueurs et deux poules en vol, pilote compris. Toutes les variantes de bois sont souhaitées. « Bi-poule » est son surnom de conception. |
 | **Biplan** | Aéronef à deux places, plus rapide que le bateau volant, mais plus lent que les elytras. |
 | **Happy Ghast** | Monture volante à quatre places, avec une vitesse doublée. « Happy gust » a été prononcé dans la description ; l'identifiant exact est à vérifier. |
 | **Totem de Notch / Magic Carpet** | En tenant le totem, faire apparaître une plateforme de verre sous ses pieds pour marcher dans les airs et faciliter la construction. La taille de la plateforme, évoquée comme trois blocs, reste à fixer. |
 
 Un sneak + clic droit permet de porter un mob sur sa tête, avec une limite d'un mob porté. Sur un autre joueur, le même geste permet de se placer sur sa tête. Un double sneak sans déplacement permet de s'asseoir.
 
+Le **bateau-poule sert à l’extraction aérienne** : embarquer un villageois ou un
+animal dans un bateau, relier ce bateau par une corde au bateau-poule, le soulever,
+puis l’amener à destination. Cela relie les premiers villageois des bateaux
+marchands et les animaux des laboratoires aux constructions des joueurs.
+Nombre de bateaux tractés, charge, vitesse, longueur et rupture des cordes,
+dépose et reprise après déchargement restent à tester et à définir. Ce montage
+ne téléporte pas automatiquement les occupants et ne remplace pas le portage à la main.
+
+Le **Booat** s’ajoute à ce montage et au biplan envisagé. Disposition de recette,
+mélange des essences, variantes de radeaux, traction et vol après perte d’une
+poule restent à concevoir dans le [cahier du Booat](progression-et-integrations.md#booat).
+
+La direction du portage inclut les animaux et les mobs hostiles ; **les hostiles
+restent capables d’attaquer pendant le transport**. Carry On sert de référence,
+mais ses règles ne sont pas adoptées telles quelles. Exceptions de taille ou
+de boss, dépose et interactions restent à concevoir ; déplacer les blocs à
+inventaire et les spawners n’est pas automatiquement inclus.
+
 ## Faune, créatures et personnages
 
+### Visiteurs de Sanctuary
+
+Des personnages peuvent visiter l’île pendant une journée, s’y promener et
+ouvrir un menu de discussion au clic droit. Quêtes thématiques, compétitions
+et échanges spécialisés donnent un usage à ces rencontres, à la manière des
+visiteurs d’Animal Crossing. **Kai** est le cuisinier ; **Alex** porte la nature
+et les biomes. **Ari** pour le build, **Makena** pour la redstone et **Zuri** pour
+les étoiles, le calendrier et le temps réel sont également des rôles retenus.
+
+Le personnage du build pourrait donner des quêtes et accompagner l’accès
+galactique au catalogue sans retirer les prérequis de progression. Un marchand
+de tapis ou de décoration reste à attribuer. **Steve reste absent**, avec des
+flashs d’Herobrine souhaités dont le sens reste ouvert. La visite ne confirme
+pas une résurrection ; l’invocation reste en réserve. Calendrier des venues,
+dialogues, offres et durée exacte restent à concevoir dans le
+[cahier des visiteurs](progression-et-integrations.md#visiteurs-et-pratiques-des-anciens).
+
 ### Hostiles et fantômes
 
 Une famille de zombies inspirée de Left 4 Dead comprend le **Hunter**, le **Charger**, le **Spitter**, le **Boomer** et l'**Infecté**. Le **Tank** et le **zombie géant** sont des boss futurs.
@@ -416,7 +848,13 @@ Ces quatre variantes **ne peuvent pas se reproduire**. Leur rareté doit préser
 
 Les **Mooblooms** sont des variantes de vaches très rares associées aux fleurs, avec de petites et grandes versions. La liste initiale comprend hibiscus, narcisse, tulipes roses, orange, rouges et blanches, marguerite/oxeye daisy, tournesol, allium, houstonie/azure bluet, orchidée bleue, bleuet/cornflower, pissenlit, muguet, lilas, rose, rose bleue et coquelicot/poppy. Les libellés exacts, la variante « moobloom » générique et les équivalences linguistiques devront être alignés sur les ressources existantes.
 
-La progression peut débloquer l'affichage de noms pour toutes les familles d'entités. Chaque famille a un registre humoristique : pseudos « kikoolol Xbox 360 » pour les zombies, alphabet galactique Minecraft pour les Endermen, et des noms variés pour les animaux.
+Un **unlock unique facultatif** permet d’afficher les noms des familles d’entités.
+Chaque famille a un registre humoristique : pseudos « kikoolol Xbox 360 » pour
+les zombies, alphabet galactique Minecraft pour les Endermen et noms variés pour
+les animaux. Une configuration permettra d’ajouter des catégories et des listes
+de noms personnalisées en leur associant les identifiants des mobs concernés.
+Attribution stable et priorité des catégories restent à définir ; les noms
+donnés par les joueurs sont conservés.
 
 ### Végétation propre à Sanctuary
 
@@ -426,7 +864,13 @@ Nouveaux bois envisagés : **lavande, ébène, mossy et blueberry**. De nouvelle
 
 L'heure du jeu suit l'heure réelle : à 8 h du matin sur le serveur, il est 8 h dans le monde. L'administrateur choisit le fuseau ou le décalage horaire. Le sommeil ne sert donc plus à faire avancer la nuit, ce qui libère un rôle pour le lit comme entrée dans les Backrooms.
 
-Un calendrier expose des nombres de jours simples : âge du serveur depuis sa création et nombre de jours écoulés depuis une origine historique de Minecraft. La date exacte de cette origine reste à choisir. Cette chronologie fait partie de la mythologie de Sanctuary.
+Un calendrier expose des nombres de jours simples : âge de la partie, ère Sanctuary et ère Minecraft. Minecraft constitue la chronologie principale ; le 17 mai 2009 et l’affichage J+0 sont proposés comme repères. Création le 16 mars 2026, développement le 24 mai, alpha le 17 août et bêta le 8 septembre sont des dates données de mémoire, à recouper avec les archives avant de les figer. Le dépôt actuel commence le 8 septembre avec une version numérotée alpha : nom du projet et phase de livraison doivent rester distincts. Voir la [chronologie et le calendrier en temps réel](chronologie-sanctuary.md) et [l’audit des archives](recherche-archives-sanctuary.md). Ce calendrier reste à implémenter.
+
+L’audit retrouve une alpha publiée le **7 juillet 2026**, avec son pack exact,
+avant la création du dépôt historique le 17 août. **L’anniversaire annuel de
+Sanctuary sera celui de sa future release officielle**, dont la date sera
+consignée à la publication. Cette fête commune reste distincte de la création
+du projet et de l’anniversaire propre à chaque partie ; son contenu est à définir.
 
 Des panneaux d'événements permettent de proposer une activité et de s'inscrire, en lien avec les factions. Des anniversaires issus d'Only Fun peuvent y être reliés. Des événements suivent un cycle évoqué comme six jours actifs et un septième jour de repos ou de fête ; la durée et l'ancrage hebdomadaire doivent être confirmés.
 
@@ -446,7 +890,38 @@ Il peut tracer des constellations depuis son point de vue, directement dans le c
 
 Les panneaux de quêtes utilisent les trois gemmes et leurs couleurs : vert émeraude, rouge rubis, bleu saphir, pour trois paliers de difficulté. Le nombre de quêtes réalisables est limité par heure. Le joueur voit les récompenses avant de choisir ; les quêtes donnent notamment de l'XP et des lootboxes.
 
-Quatre catégories de lootboxes sont prévues : **normales**, **capes**, **spawn eggs** et **anomaly**. Les anomaly peuvent contenir les équipements en titane impossibles à fabriquer.
+La sélection actuelle distingue **loots généraux, capes, cosmétiques et
+familiers/spawn eggs**. « Loot spawner » est compris provisoirement comme cette
+dernière famille, sans accorder automatiquement des blocs spawners. L’ancienne
+lootbox Anomaly reste à articuler à ces catégories et à la loterie.
+
+Les équipements peuvent porter les couleurs blanc, vert, bleu, violet et jaune ;
+les noms et seuils de rareté restent à arrêter. Les loots généraux peuvent contenir
+du légendaire dans des cas extrêmement rares, à équilibrer avec les volumes
+d’ouverture des farms. Anomaly est le niveau ultime défini ci-dessus ; son accès
+n’est pas garanti par un loot général. Les raretés des familiers et les familles
+de contenants restent des classifications distinctes.
+
+### Raids collectifs
+
+**Un raid pour tout le serveur par semaine, avec dix joueurs requis.**
+L’accès est un **portail secret découvert sur une île générée par expansion**,
+pas sur Sanctuary Island. Ses conditions de déblocage restent à définir.
+Le raid est un donjon procédural difficile dans une instance, en mode aventure,
+avec blocs incassables et sans sortie libre pendant l’épreuve. L’inspiration
+est celle des Trial Chambers, à une autre échelle et avec une palette propre
+à concevoir. Sa difficulté ne diminue pas pour un petit groupe.
+
+La progression du serveur permet de préparer de nouvelles épreuves et de nouveaux
+défis de coordination, avec un **butin matériel commun**, dimensionné pour dix
+et réparti librement par les joueurs après ramassage. Il peut inclure du titane
+et des équipements enchantés différents, sans récompense personnelle automatique
+ni partage égal imposé. Les paramètres d’une tentative restent fixes.
+Remise à disposition hebdomadaire, consommation du quota, échec, reconnexion,
+retour et attribution des récompenses restent à définir dans le
+[cahier des raids](progression-et-integrations.md#raids-collectifs-instanciés).
+Ces instances ne remplacent pas le donjon ouvrant les Cavernes ni les donjons
+ordinaires aux spawners exploitables.
 
 ### Le cube originel et les sept boules
 
@@ -465,6 +940,16 @@ Les trois autres boules, les noms définitifs et la manière de les réunir rest
 
 It's Alive ! est un mod autonome de cultures, de préparation et de transformation alimentaire. Son intégration à Sanctuary apporte des raisons d'explorer, de commercer et de produire ensemble.
 
+La direction retient désormais le **grand four commun de 27 fours** (nom
+proposé : Fourneau) pour les recettes de cuisson qui relevaient du kitchen
+oven, et un **grand baril de fermentation**
+traitant plusieurs stacks d’une même recette. Les poêles, marmites et autres
+procédés distincts ne disparaissent pas avec ce regroupement. Recettes, pages,
+qualité et vieillissement restent de la responsabilité d'It's Alive ! ; la
+distribution de l’appareil commun doit préserver l’usage autonome du mod.
+Voir les [machines multiblocs](machines-multiblocs.md) pour les propositions
+de charges, d’interfaces et de cycles ; aucun appareil n’est livré ici.
+
 Les cultures et ingrédients se trouvent dans des biomes appropriés à leur température et à leur humidité. Tout ne pousse pas et ne se trouve pas partout. Certaines variations de récolte suivent une logique comparable à la recherche de baies dans Cobblemon.
 
 ### Contenus envisagés
@@ -480,7 +965,28 @@ Les cultures et ingrédients se trouvent dans des biomes appropriés à leur tem
 
 Le vin peut vieillir pour gagner en qualité. Le fromage et le saucisson peuvent également être affinés ; ce vieillissement n'est pas prévu pour la bière dans l'intention actuelle.
 
-Des **pages culinaires** reconstituent le livre de recettes perdu de Steve. Il ne contient pas toutes les recettes : des sorcières gardent des **secret pages**, obtenues en les combattant, qui révèlent notamment certaines techniques de crème, beurre, vin et bière.
+La révision culinaire doit aussi rendre la **préparation et le moment de
+récupération** déterminants : apprendre les temps de cuisson et reconnaître
+quand retirer un plat, notamment d’un chaudron. Sa qualité peut être indiquée
+par une étoile ou une pastille ; variantes d’items ou donnée de qualité restent
+à choisir. Cette qualité se distingue des raretés d’équipement. Kai pourra
+organiser des compétitions et juger les plats selon des critères à définir.
+
+Des **pages culinaires** reconstituent le livre de recettes perdu de **Kai**,
+désigné cuisinier de Sanctuary par un tirage unique de conception. Le nom reste
+le même dans tous les mondes. Kai appartient aux sept personnages ajoutés après
+Steve et Alex ; ce rôle culinaire est propre au lore Sanctuary. Le livre ne
+contient pas toutes les recettes : des sorcières gardent des **secret pages**,
+obtenues en les combattant, qui révèlent notamment certaines techniques de crème,
+beurre, vin et bière. Voir le [tirage et sa source](progression-et-integrations.md#pages-culinaires-et-lieux-encore-inexplorés).
+
+Les pages à débloquer font partie de la progression de Sanctuary, avec les plans
+de construction et les autres savoirs trouvés en exploration. Des lieux initiaux
+encore inexplorés, dont les structures volantes envisagées, pourraient en conserver
+selon leur fonction. Le lien page apprise → recette consultable → préparation
+autorisée reste à spécifier, ainsi que le partage, les doublons et les équipements
+nécessaires. Cette intégration préserve l’usage autonome d’It’s Alive !. Voir
+les [pages et lieux de découverte](progression-et-integrations.md#pages-culinaires-et-lieux-encore-inexplorés).
 
 ## Only Fun — interactions sociales et absurdes
 
@@ -497,7 +1003,7 @@ Les inconnues ne bloquent pas l'initialisation ni le terrain de base. Elles sont
 - Taille, altitude, relief, réserve de ressources et identité visuelle de Sanctuary Island.
 - Forme des continents, distances d'expansion, coûts collectifs et contrôle de leur ouverture.
 - Adaptation du catalogue TerraMix historique et compatibilité des mods communautaires avec la cible Fabric.
-- Courbe d'XP, lignes d'inventaire et distinction entre rangée et barre rapide ; conditions de passage des prestiges, nombre et fonctionnement des slots de factions débloqués.
+- Courbe d’XP, liste et plafonds des compétences, lignes d’inventaire et distinction entre rangée et barre rapide ; XP restante et facultés galactiques après prestige, nombre et fonctionnement des slots de factions. Le prérequis de prestige est fixé : toutes les compétences au maximum ; les unlocks restent acquis et les compétences sont à remonter.
 - Conditions de perte et de récupération des objets, durée de conservation dans les Backrooms et garantie d'unicité.
 - Nature et propriété des indoors, partage des accès et comportement à la déconnexion.
 - Règles des boutiques, du coffre-fort, du braquage et des équipes temporaires.