feat: add native Blocodex and material census for alpha23

docs/cosmologie.md

@@ -0,0 +1,275 @@
+# Sanctuary — matière, espaces et mémoire
+
+**Cahier de conception issu du texte de l’auteur.** Il prolonge
+[la vision](vision.md) et [la conception des lieux](structures-conception.md).
+Les citations conservent les formulations fournies ; les points à préciser
+sont identifiés comme tels. Ce document ne livre aucun générateur ni système
+économique. **Backrooms, Indoors, shop et ballast ne sont pas implémentés.**
+Le Blocodex natif de l’alpha.23 locale fournit un premier socle de données
+pour des mécaniques futures, avec les limites décrites dans [son contrat](blocodex.md).
+
+## Minecraft comme archéologie d’un autre Minecraft
+
+Steve, Ari, Sunny, Kai, Zuri, Alex, Mefe, Makena et Noor sont les neuf 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é.
+
+> Ils n’ont pas ouvert quelque chose qu’ils n’auraient pas dû ouvrir. Ils ont
+> construit quelque chose qu’ils ne savaient plus refermer.
+
+L’histoire part de quelque chose qui a fonctionné : des besoins satisfaits, des
+lieux devenus utilisables, des opérations répétées et des installations agrandies.
+Une ruine doit permettre de retrouver cette ancienne solution. Ses circulations,
+ses raccords, ses réparations et ses extensions racontent un fonctionnement avant
+de raconter son interruption.
+
+> Chaque ruine de sanctuary doit être une trace d’une ancienne solution pas
+> seulement la trace d’un problème.
+
+La découverte précise, la succession des expériences et les rôles des neuf
+personnages restent à écrire. Aucun métier, aucune responsabilité individuelle
+ni cause définitive de leur disparition ne leur sont attribués ici. On conserve
+en particulier **Mefe**, tel que nommé par l’auteur. Il n’est pas décidé que
+chacun possède un bâtiment, une machine, une gemme ou une quête correspondante.
+
+## Deux devenirs de la même technologie
+
+Les Indoors et les Backrooms appartiennent à la même logique de fabrication des
+espaces. Ce qui les distingue est leur relation à une intention et à une
+référence : sait-on encore pourquoi cet espace existe et comment le retrouver ?
+
+| Espace | Direction donnée par l’auteur | Conséquence pour la conception |
+| --- | --- | --- |
+| **Indoor** | « espace artificiel référencé et contrôlé » | Un intérieur est produit intentionnellement et reste associé à son accès et à son usage. Une porte peut mener à un espace dix fois plus grand que le bâtiment extérieur. |
+| **Backroom** | « espace artificiel orphelin » | Un espace demeure alors que sa destination ou sa raison d’être a disparu. Sa forme peut conserver les restes d’une fonction sans retrouver l’ensemble auquel elle appartenait. |
+
+L’auteur décrit chaque Indoor comme une petite dimension instanciée. Les
+computers utilisent **probablement** cette technologie pour leurs expériences :
+cette relation est une piste forte, sans avoir encore de protocole ni de machine
+définitivement assignée.
+
+Les Backrooms, dans cette cosmologie, ne sont pas une destination demandée au
+même titre qu’un monde. Elles sont ce que la machine produit lorsqu’elle ne sait
+pas où mettre quelque chose :
+
+- un espace généré puis annulé ;
+- une expérience interrompue ;
+- deux règles demandant deux états incompatibles ;
+- une room qui n’est plus référencée ;
+- une coordonnée qu’aucun monde ne revendique.
+
+> La machine ne détruit pas parfaitement les espaces. Elle les laisse derrière.
+> Backrooms.
+
+L’image du « garbage collector raté de Minecraft » exprime cette accumulation.
+L’arborescence proposée par l’auteur la représente ainsi :
+
+```text
+WORLD
+├── overworld
+├── caverns
+├── nether
+├── end
+├── sanctuary
+└── /unreferenced/
+    └── backrooms
+```
+
+C’est une représentation narrative, pas une arborescence de fichiers ni la
+liste des dimensions actuellement enregistrées par le mod. **L’espace orphelin
+est une fiction à mettre en scène.** Une réalisation Minecraft devra conserver
+des espaces correctement sauvegardés, identifiés et référencés côté serveur.
+Le choix entre dimensions techniques et régions d’un espace partagé reste à
+concevoir. Rien ici ne prévoit de perdre de vraies références de sauvegarde,
+de supprimer des chunks ou de provoquer leur corruption pour obtenir cet effet.
+
+## De la matière sans contexte
+
+Le système reçoit des matériaux et tente de les réorganiser en espace valide :
+
+```text
+stone stone dirt copper oak_planks iron stone glass ...
+```
+
+Il possède de la matière, mais aucune destination n’a été demandée. Il tente
+alors de l’encoder sous forme de chunks : un couloir, une salle, encore une
+salle, un plafond, une porte donnant sur rien, une plomberie sans bâtiment,
+un entrepôt infini.
+
+> Les Backrooms sont la tentative du générateur de Minecraft de faire quelque
+> chose avec de la matière sans contexte.
+
+La **matière** donne une palette et une présence physique. Le **contexte** lui
+donnait un usage, des dimensions, des voisins, un accès ou une destination.
+Cette distinction permet de dessiner un lieu dont les parties sont intelligibles
+alors que leur assemblage ne retrouve plus son intention : une plomberie garde
+sa logique de raccord, mais le bâtiment qu’elle devait desservir n’est plus là.
+Elle ne justifie pas de remplacer la conception par des blocs placés au hasard.
+
+Il reste à définir ce que la machine conserve de ce contexte : seulement les
+matériaux, des fragments de plans, des types de pièces, des relations entre
+espaces ou des traces d’opérations. Aucun catalogue de rooms ni algorithme de
+recomposition n’est arrêté. Les palettes limitées et le futur moteur de
+traduction en structures peuvent servir cette direction ; le moteur n’est pas
+créé par ce document.
+
+## Le ballast de l’économie
+
+La direction fournie relie directement cette cosmologie aux actions des joueurs.
+Utiliser le shop, téléporter, ouvrir des Indoors, déplacer de la matière ou
+expandre le monde produit du **ballast**. Plus ces opérations se multiplient,
+plus les Backrooms se remplissent. Elles deviennent l’externalité du système
+économique de Sanctuary : une activité visible laisse ailleurs des conséquences
+que ses utilisateurs pourront découvrir beaucoup plus tard.
+
+Le ballast relie donc production, échanges et géographie. Un objet déplacé ne
+change pas seulement de propriétaire ou de position dans cette vision ; son
+passage par ces technologies peut laisser une empreinte dans le monde.
+La forme de cette empreinte reste à décider pour chaque opération.
+
+| Opération envisagée | Articulation à définir avant de l’implémenter |
+| --- | --- |
+| Shop et échanges | Quel événement produit du ballast : vente, achat, consommation par un service, autre opération ? Quelle matière lui correspond et à quel moment l’échange est-il terminé ? |
+| Téléportation | Que laisse le déplacement : trace de matière transportée, coût matériel ou autre résidu à choisir ? Les types de téléportation partagent-ils cette règle ? |
+| Ouverture d’un Indoor | Que produit la création d’un espace contrôlé ? Que deviennent ensuite une fermeture, un transfert d’accès ou une expérience interrompue ? |
+| Déplacement de matière | Quelles opérations participent à cette économie ? Un transport manuel, un convoyeur, un stockage ou une transformation ne sont pas encore déclarés équivalents. |
+| Expansion | Comment la préparation et la création d’un continent se rattachent-elles aux matériaux engagés et aux espaces laissés derrière ? |
+
+« Ballast » ne fixe pas encore une quantité, une unité, un coût ou une monnaie.
+Il faut notamment décider s’il représente une matière effectivement retirée,
+une trace de son traitement ou les deux selon les opérations. Aucun taux de
+conversion ni conservation quantitative stricte n’est établi. Le document
+n’autorise donc pas à prélever des objets dans les inventaires ou à les dupliquer
+dans des coffres au nom de cette cosmologie.
+
+## Lire l’histoire économique dans la géologie
+
+La génération doit dépendre du comportement réel des joueurs. L’auteur donne
+trois exemples qui fixent la direction sans constituer des recettes de génération :
+
+| Histoire du serveur | Trace possible dans les Backrooms |
+| --- | --- |
+| Le serveur consomme énormément de pierre. | Les premières couches deviennent minérales. |
+| Une phase d’industrialisation utilise beaucoup de cuivre. | Des zones techniques apparaissent. |
+| Des tonnes de bois sont sacrifiées. | Un gigantesque Indoor abandonné peut émerger. |
+
+Des mois après, les joueurs peuvent descendre et reconnaître dans les lieux
+traversés une période de l’histoire du serveur. Le choix des matériaux doit
+pouvoir conserver une différence entre une phase minérale, une phase industrielle
+et d’autres formes de production, au lieu de tout réduire à la dernière palette
+dominante.
+
+Cette intention demande une temporalité explicite. Deux histoires se rencontrent :
+celle des neuf personnages, antérieure à l’arrivée des joueurs, et celle que le
+serveur écrit pendant la partie. La première fournit les vestiges d’un autre
+Minecraft ; la seconde peut produire de nouveaux dépôts et de nouvelles traces.
+La présence de strates initiales issues de l’ancienne partie, leur contenu et
+leur articulation avec les apports actuels restent à décider.
+
+Il faut encore choisir la durée des périodes observées, ce qui forme un dépôt,
+le moment où un dépôt devient un lieu et la manière dont les périodes se
+succèdent dans l’espace. Une couche n’est pas nécessairement un niveau vertical :
+la géographie de cette chronologie reste à dessiner. La règle devra préserver
+les espaces déjà visités et construits ; changer les statistiques actuelles ne
+doit pas devenir une régénération implicite d’anciens chunks.
+
+## Ce que le socle méta peut fournir
+
+Le Blocodex appartient à Sanctuary et peut être consulté par plusieurs mécaniques.
+Il distingue actuellement connaissance, observation, minage, possession passée,
+jet, pose et stock porté. Les critères de connaissance et les familles de
+matériaux peuvent aider un futur moteur à constituer une palette utilisable.
+
+Ces informations personnelles ne suffisent cependant pas à décrire l’histoire économique :
+
+- **miné** ne veut pas dire consommé par le shop ou engagé dans une machine ;
+- **jeté** compte les jets volontaires vanilla, pas les objets brûlés ou perdus
+  dans le vide ;
+- **déjà possédé** est une preuve persistante, pas un stock encore disponible ;
+- **posé** ne fournit pas à lui seul le plan d’une construction ni sa date ;
+- le stock personnel ne recense pas tous les coffres et réseaux du serveur.
+
+Le socle méta distingue maintenant trois relevés :
+
+| Relevé | Ce qu’il permet de connaître |
+| --- | --- |
+| Mémoire personnelle | Ce qu’un joueur a vu, miné, possédé, jeté ou posé ; des critères pour ses palettes. |
+| Distribution actuelle | Les blocs du terrain chargé et les stocks accessibles, comptés séparément avec leur couverture. |
+| Activité datée du serveur | Les quantités minées, posées, ramassées, jetées et fabriquées, agrégées par jour UTC depuis l’installation. |
+
+Le troisième relevé conserve une trace des périodes d’activité après le
+déplacement des stocks. Il peut montrer une période de minage intense de cuivre,
+mais ne prouve pas que ce cuivre a été sacrifié à une machine. Il ne reconstruit
+pas les mois précédant son installation et ne calcule aucun ballast. Les limites
+de persistance et de couverture figurent dans le [contrat méta](blocodex.md).
+
+Avant la génération historique, il faudra donc définir quels faits les systèmes
+économiques enregistrent : action réalisée, matériau, quantité, moment ou période,
+origine et destination utiles à cette action. Leur traitement devra distinguer
+une opération terminée d’une tentative refusée et éviter de compter plusieurs
+fois la même opération après reprise. La granularité, la conservation et le
+format de ces transactions restent à concevoir dans un contrat propre. Les
+agrégats journaliers déjà disponibles ne sont pas un journal transactionnel :
+ils ne doivent autoriser ni prélèvement, ni récompense, ni restitution d’objet.
+
+## Machines, références et anciennes solutions
+
+Les computers pourraient expérimenter dans les Indoors parce qu’ils offrent
+des espaces contrôlés. Il reste à préciser ce qu’ils demandent à un espace et
+comment cette demande le rattache à une installation, une porte ou un usage.
+La cause d’un orphelin dans la fiction devra être compréhensible sans demander
+au joueur de connaître les fichiers de sauvegarde.
+
+L’assembleur, le contrôleur, le terminal, le dépôt et l’ancre spatiale restent
+des concepts en discussion dans [le cahier des machines](structures-conception.md#ordinateurs-et-installation-dexpansion).
+Les questions communes sont maintenant plus précises : qui formule la demande
+d’espace, qui fournit sa matière, qui conserve sa référence, qui présente son
+état, et comment une fermeture ou une interruption est représentée ? Cette liste
+ne répartit pas arbitrairement cinq fonctions entre cinq blocs.
+
+Les ruines peuvent rendre ces questions visibles par leurs usages passés.
+L’observatoire, la salle d’expansion rééquipable, l’atelier caché et la grande
+traversée restent la sélection de conception actuelle. Pour chacun, il faut
+retrouver ce qui y était observé, préparé, fabriqué ou relié, puis montrer les
+extensions et le travail interrompu. Ce sont des questions de fiche de lieu,
+pas la confirmation de machines présentes ni d’un accès aux Backrooms dans
+chaque ruine. Le donjon majeur conserve son boss et son objet de quête à définir ;
+il n’est pas automatiquement identifié au réacteur ou à l’origine de la panne.
+
+La même ligne relie le passé et la partie actuelle :
+
+> une infrastructure dont l’auteur a progressivement disparu derrière son
+> fonctionnement.
+
+## Accès, retour et récupération : règles encore ouvertes
+
+La vision antérieure envisage le lit pour entrer dans les Backrooms, des sources
+de lumière pour les explorer et des coffres recueillant des objets perdus dans
+le vide ou brûlés. Elle prévoit aussi des accès d’Indoors liés à la mailbox de
+leur propriétaire. Ces intentions doivent être raccordées à la cosmologie du
+ballast ; elles ne définissent pas encore un parcours complet.
+
+Avant un ticket jouable, il faut notamment arrêter :
+
+1. Les moyens d’entrer, les destinations d’arrivée, le retour et le comportement
+   lors d’une mort ou d’une déconnexion.
+2. La propriété et le partage des Indoors, la perte de leur objet d’accès, leur
+   fermeture et la distinction entre un accès absent et un espace fictionnellement
+   devenu orphelin.
+3. Le rapport entre ballast, géologie et objets récupérables : quelle part fait
+   décor ou ressource, quelle part demeure un objet identifiable, et comment sa
+   récupération évite une restitution multiple.
+4. Les opérations qui alimentent réellement les dépôts, leurs unités, leur
+   cadence et les limites de stockage et de génération.
+5. Les indices permettant de lire une période économique ou une ancienne solution,
+   sans attribuer d’avance une cause à tous les lieux et aux neuf disparus.
+
+Les pool rooms et salles étranges physiques sous l’île restent des structures
+de l’Overworld. Leur ressemblance éventuelle avec les Backrooms ne les transforme
+pas automatiquement en espaces orphelins. Les passages entre ces lieux, les
+Indoors et les Backrooms devront être décidés explicitement.
+
+La prochaine étape de conception peut prendre un seul cas complet : une
+opération économique réelle, la trace qu’elle conserve, son dépôt, puis le lieu
+que ce dépôt permettrait de générer et d’explorer. Ce cas permettrait de fixer un
+premier contrat vérifiable sans prétendre que toute la cosmologie est déjà jouable.