sanctuary-beta/docs/backlog.md

Backlog de démarrage

Ce fichier prépare les premiers tickets à publier sur le Git du projet. Aucun identifiant ci-dessous n'est un numéro d'issue distante et aucun ticket n'est présumé publié. Les identifiants BOOT-* et WG-* servent seulement à relier les travaux tant que les issues n'existent pas.

Le document de vision conserve les idées à long terme. Ce backlog organise uniquement le socle et les premiers incréments de génération. Une fonctionnalité n'est considérée comme livrée que lorsque son résultat et sa validation figurent dans le dépôt ou dans son issue.

Premier jalon : un monde Sanctuary jouable

État au 8 septembre 2026 : BOOT-01 et WG-01 sont réalisés dans le premier commit. Le prototype WG-02 et l'initialisation du spawn WG-03 sont implémentés et passent les tests serveur décrits dans Validation. Les essais visuels, multijoueurs et de redémarrage indiqués dans ce document restent à faire avant de clôturer tous leurs critères. WG-04 à WG-07 restent ouverts, avec les incréments de l’île initiale décrits ci-dessous. WG-08 est validé ; WG-09 est livré en alpha.8, avec mesures moteur et mise à jour Prism vérifiées. WG-10 est livré en alpha.9, avec mesures moteur et synchronisation Prism vérifiées. WG-11 est livré en alpha.10 : tailles 5/20/100 validées sur la graine 0, release publiée et même instance Prism synchronisée. WG-12 est livré en alpha.11 : Petit/Grand, génération accélérée et même instance Prism synchronisée deux fois ; voir Distribution.

Résultat visé : un client et un serveur Fabric compatibles peuvent ouvrir un monde Sanctuary, plusieurs joueurs y arrivent sur une même île sûre et les chunks extérieurs restent vides. La génération est reproductible et ses limites sont documentées.

BOOT-01 — Initialiser le dépôt et la construction Fabric

But : disposer d'une base clonable et vérifiable pour travailler par tickets.

Critères d'acceptation :

• Les versions réellement utilisées de Minecraft, Java, Fabric Loader, Fabric API et de l'outillage sont fixées et documentées.
• La cible souhaitée 26.3 est distinguée de la version exécutée si sa disponibilité oblige à utiliser une version de développement ou à différer la migration.
• Une commande reproductible construit le mod ; le README explique le lancement et les prérequis.
• Les métadonnées identifient Sanctuary sans annoncer les fonctionnalités de la vision comme déjà présentes.
• Le dépôt contient les consignes de contribution et des modèles de tickets ; les binaires, caches et sauvegardes de jeu ne sont pas suivis par accident.

WG-01 — Auditer le générateur Sanctuary 26.2

But : identifier précisément le code et les ressources utiles avant de les adapter.

Critères d'acceptation :

• Les fichiers, commits ou références historiques consultés sont cités dans une note d'audit.
• La note explique l'algorithme de l'île, le vide, le point d'apparition, les dépendances et les paramètres structurants.
• Les éléments réutilisables, les défauts connus et les changements d'API de la cible sont séparés.
• La réutilisation de ressources est accompagnée de leur origine et de leur licence connue ; les inconnues sont explicitement notées.
• L'audit n'installe ni ne déploie l'ancienne version et ne modifie pas ses sauvegardes.

WG-02 — Enregistrer un monde Sanctuary avec île principale et vide

Dépendances : BOOT-01, WG-01.

But : créer le premier terrain identifiable comme Sanctuary.

Critères d'acceptation :

• Une procédure documentée permet de créer un monde utilisant le générateur Sanctuary sur la version testée.
• Une île principale est générée au point de départ prévu ; ses coordonnées, son altitude et ses dimensions sont explicites.
• Au-delà de son emprise, les chunks de contrôle sont vides, sans fondation ni terrain vanilla inattendu.
• Une même seed et une même configuration donnent les mêmes blocs aux positions de contrôle.
• Les jointures entre chunks voisins ne créent pas de fissures ou de parois artificielles dues à une discontinuité du calcul.
• Un monde Minecraft ordinaire reste créable sans sélectionner Sanctuary.

WG-03 — Assurer une arrivée commune et un redémarrage sûr

Dépendance : WG-02.

But : éviter qu'un nouveau joueur apparaisse dans le vide et vérifier le comportement multijoueur.

Critères d'acceptation :

• Le spawn du monde se situe sur une surface stable de l'île, avec l'espace nécessaire au joueur.
• Deux nouveaux joueurs arrivent dans la zone de départ commune, sans traverser le sol ni apparaître hors de l'île.
• Le comportement après une mort sans lit est vérifié ; l'ajout ultérieur des Backrooms n'est pas requis pour ce ticket.
• Après sauvegarde et redémarrage, le générateur, la seed et le spawn sont conservés.
• Un scénario manuel reproductible couvre le client et le serveur dédié, avec la version et la seed utilisées.

Deuxième jalon : des continents d'essai reproductibles

Ce jalon fournit un outil de développement du terrain. L'interface d'expansion et son coût collectif viendront dans des tickets distincts, lorsque la génération sera satisfaisante.

WG-04 — Décrire et placer un continent d'essai

Dépendance : WG-03.

But : pouvoir générer une terre suspendue à une direction, une distance et une taille explicites.

Critères d'acceptation :

• Un schéma décrit au minimum l'identifiant, le centre ou la direction et la distance, les dimensions, l'altitude et la seed du continent.
• Le premier champ de recherche utilise huit directions climatiques : nord froid, sud chaud, ouest sec, est humide ; les diagonales combinent ces tendances. Chaque candidat expose sa signature et sa distribution de température/humidité.
• La sélection climatique ne force ni la forme du terrain ni des quotas de ressources. Un relevé après génération identifie les stocks réellement produits, son emprise, sa version et son niveau de complétude. Voir le contrat.
• Une configuration ou commande de développement documentée crée un continent reproductible.
• Les paramètres invalides et les chevauchements interdits sont rejetés avec un message compréhensible.
• Des limites de taille et de coût de génération sont définies à partir d'une mesure réelle.
• Le continent et ses paramètres restent identiques après rechargement du monde.

WG-05 — Ouvrir une expansion sans écraser l'existant

Dépendance : WG-04.

But : garantir que l'évolution du monde préserve les constructions et l'exploration.

Critères d'acceptation :

• La politique envers les chunks déjà générés est décidée et documentée avant l'implémentation : refus, réservation préalable ou mécanisme explicite de modification.
• Une nouvelle expansion ne remplace aucun bloc joueur silencieusement.
• Répéter la même demande ne crée pas de duplicata et ne décale pas les continents existants.
• L'état des expansions survit à un redémarrage et contient une version de format permettant de prévoir les migrations.
• Une interruption entre réservation et génération est simulée ; la reprise ou le refus reste cohérent et expliqué.

WG-06 — Ajouter reliefs, perforations et eaux retenues

Dépendance : WG-04 ; combiner avec WG-05 avant l'usage sur une sauvegarde jouée.

But : donner aux continents une géographie reconnaissable au-delà d'une simple masse de pierre.

Critères d'acceptation :

• Un jeu de seeds de référence montre des reliefs, montagnes, ravins et perforations traversantes.
• Des bassins accueillent lacs ou océans, et un premier type de rivière flottante est démontré.
• Pour l'île initiale tempérée et légèrement humide : privilégier petits étangs, lacs de surface, rivière et berges propices à la canne à sucre, avec quelques plages plus sèches. Pas de grands bassins souterrains remplis d'eau.
• Les étangs et les lacs retiennent leur eau après les mises à jour de blocs. Des sources rocheuses déclarées peuvent former des cascades jusqu’au vide ; leurs écoulements restent attribuables à ces sources, sans inondation globale.
• Les profils du dessous et les bords du continent sont inspectés visuellement depuis les airs.
• La génération est mesurée sur une emprise et une machine indiquées ; les valeurs observées sont consignées, sans annoncer un objectif de performance non mesuré.

Incrément île initiale — alpha.4 : première hydrologie de surface retenue, conservée pour les sauvegardes de cette version.

Incrément île initiale — alpha.5 : plages plus larges, dépôts de trois à cinq couches sur support naturel, excavation limitée, rives variées et sources rocheuses pouvant former des cascades jusque dans le vide. Le contrat et l’isolation des anciennes générations sont décrits dans Génération. Ce travail prépare les eaux des continents sans clore WG-06 : océans, grandes rivières et ouverture des continents restent à développer.

Incrément île initiale — alpha.6 : retrait des courts ruisseaux, conservation des bassins, présence de roche élargie et sources de paroi dans les strates inférieures. Les écoulements sont contrôlés dans le moteur et les anciennes générations sont préservées.

Suite suivie dans WG-09 — grande rivière facultative : chercher un long parcours qui épouse l’île, avec source, chute et bassin, rives de sable, gravier et argile. Le démontrer sur la vraie densité Minecraft puis après décoration et ticks de fluide, avec une graine et des coordonnées reproductibles. Les essais du prototype alpha.6 n’ont fourni aucun parcours retenu sur les graines de référence ; ce prototype n’est pas distribué. Ne pas imposer de rivière si le relief ne s’y prête pas.

WG-07 — Introduire un premier biome distinct et une structure

Dépendance : WG-06.

But : valider les points d'extension avant d'ajouter un grand catalogue de contenus.

Critères d'acceptation :

• Le ticket choisit un premier biome, par exemple le Black Desert, avec des règles de surface et d'ambiance explicites.
• Une petite structure de référence se place sur un terrain compatible, sans flotter accidentellement ni détruire une construction existante.
• Le lien entre biome, végétation, ressources et règles de placement est documenté.
• La reprise du catalogue TerraMix natif d'Another World 26.2 est évaluée séparément ; « plus de cent biomes » reste une ambition tant que son adaptation n'est pas vérifiée.
• Les limites des futures zones Lost Cities et des structures uniques sont identifiées sans imposer leur livraison dans ce ticket.

Incrément île initiale — alpha.5 : cinq variantes tempérées à dominante forestière, dont Dappled Forest vanilla 26.3, et petits filons de sept minerais à des altitudes adaptées. Leurs stocks sont observés après génération. Cela ne clôture pas WG-07 : aucune structure de référence ni reprise du catalogue TerraMix n’est encore fournie. La survie initiale doit permettre de produire et progresser au-delà du bois et de la pierre ; l’accès à toute la progression Minecraft n’est pas encore garanti pour chaque seed.

Ticket palette — alpha.6 : réserver les biomes très contrastés de la 26.3, dont Dappled Forest, aux futurs continents. L’île combine prairies fleuries, bosquets et zones rocheuses, avec des teintes cohérentes et une végétation effective sur les corniches inférieures. Cela ne livre pas encore les continents.

WG-08 — Forêts de survie et minerais visibles — alpha.7

Branche : codex/woodland-canopy.

But : conserver les formes rocheuses appréciées en alpha.6 tout en donnant à l’île de vraies forêts de surface et des ressources de départ repérables.

Critères d’acceptation :

• Chênes majoritaires parmi les arbres de surface observés, bouleaux secondaires, avec des arbres au cœur de l’île et des clairières fleuries.
• Chênes noirs réels et champignons sur des corniches intérieures naturelles ; jungle/bambou et matières de soufre rares et localisés.
• Un éventuel arbre remarquable, choisi parmi les essences rares, sans ajout de terrain ni obligation de fournir chaque essence par graine.
• Affleurements de pierre, andésite, diorite et granite ; sable et gravier associés aux eaux, avec des couches soutenues.
• Charbon, fer et cuivre visibles au contact de l’air sur la roche, avec des petits filons sans quota corrigé après génération.
• Démonstration dans le moteur, maintien des eaux après 1 800 ticks et conservation des anciennes générations. Publication packwiz et mise à jour de l’instance Prism existante en conservant ses données personnelles.

Vérification alpha.7 : les trois graines de référence passent les tests du moteur, dont les forêts, les minerais exposés et les eaux après 1 800 ticks. Les observations et leurs limites sont consignées dans Validation.

WG-09 — Failles, rivière et profondeurs — alpha.8

Branche : codex/rifts-rivers-and-depths.

But : ouvrir l’intérieur de l’île, enrichir sa géologie et ses ressources de survie, tout en conservant les forêts de surface appréciées en alpha.7.

Critères d’acceptation :

• Une à trois traces de failles courbes, de longueur nominale 84 à 160 blocs et de largeur variable, retirent uniquement de la matière du relief initial. Leur intersection réelle avec la roche est montrée sur les graines testées.
• Les forêts de chênes et de bouleaux restent présentes en surface. Des gros champignons, des petits champignons dispersés et des tapis de mousse, podzol et mycélium occupent les corniches compatibles de l’intérieur humide.
• Les matières changent avec la profondeur, avec des nappes de tuf, cobblestone, pierre moussue et boue compactée, puis ardoise des abîmes, roche noire et basalte. Des poches de soufre réellement accessibles sont observées sur le terrain.
• Charbon, fer et cuivre exposés sont plus faciles à repérer dans les relevés. L’émeraude est ajoutée ; or, diamant, redstone et lapis sont cherchés aux altitudes présentes. Aucun stock fixé n’est réinjecté après comptage.
• Des bassins plus grands sont retenus. Une rivière facultative est démontrée par un chemin d’eau continu d’au moins 140 blocs, reliant deux bassins au même niveau avec source rocheuse et cascade entrante. Le tracé est arrondi à l’échelle de 16 à 32 blocs, avec largeur de lit variable d’environ 5 à 7 blocs. L’incision du lit reste bornée à 16 blocs ; les berges de rivière s’étagent progressivement avec au plus 12 blocs retirés, contre 2 pour les autres rives. Le fond et les dépôts reposent sur le terrain existant.
• La poche de lave couverte est recherchée en priorité sur une corniche basse entre Y=64 et Y=160 ; la recherche plus haute n’intervient que si aucun emplacement profond compatible n’est trouvé.
• Une à deux sources profondes de lave sont recherchées lorsque le site est compatible ; leurs coulées viennent des ticks vanilla. Les supports, les eaux voisines et la végétation sont contrôlés après simulation réelle.
• La nouvelle clé sanctuary:sanctuary_rift n’active ces traitements que pour les nouveaux mondes. Les données et comportements historiques restent séparés.
• Les graines 0, 42 et 8675309 disposent de mesures moteur explicites, avec fluides actifs pendant 1 800 ticks. Une absence de rivière ou de source est rapportée honnêtement ; un bassin isolé ne valide pas une rivière.
• Après validation : build et pack vérifiés, publication immuable, deux synchronisations du canal packwiz et conservation de la même instance Prism, de ses sauvegardes et de ses réglages.

Vérification moteur alpha.8 — 9 septembre 2026 : les trois graines de référence passent les contrôles finaux, dont les deux bassins terminaux, les champignons connectés et 1 800 ticks de fluides. Les stocks et leurs périmètres sont consignés dans Validation. Le build complet est réussi. L’alpha.8 est publiée sur le canal stable et la même instance Prism est synchronisée deux fois, avec sauvegardes et réglages conservés. Le ticket est livré ; l’appréciation visuelle et l’équilibrage en partie restent à éprouver. Ce ticket local n’est pas une issue distante publiée.

WG-10 — Cavités luxuriantes et terrasses d’eau — alpha.9

Branche : codex/lush-caverns-and-water-terraces.

But : rendre les cavités sous Sanctuary plus vivantes et lumineuses, diversifier leurs ressources et créer des eaux plus volumineuses, sans remplacer les forêts et la rivière de surface appréciées en alpha.8.

Critères d’acceptation :

• Des cavités luxuriantes portent une végétation réellement lumineuse et enracinée dans les surfaces et plafonds existants. Les observations doivent distinguer un biome déclaré, ses blocs décoratifs et leur lumière réelle.
• Des secteurs à spéléothèmes et des géodes d’améthyste sont recherchés dans la roche compatible ; leurs supports, leurs volumes et leur accessibilité sont contrôlés dans les vrais chunks, sans géodes suspendues dans le vide.
• Le soufre occupe moins de roche qu’en alpha.8, sur un périmètre de comparaison explicite. Les geysers éventuels utilisent le soufre actif et les conditions exactes de Minecraft 26.3-pre-2 ; leur fonctionnement doit être démontré, sans confondre un bloc jaune avec un geyser actif.
• Les forêts, la rivière et les bassins de surface restent présents lorsque le relief le permet. Les lacs plus profonds et volumineux sont mesurés en blocs d’eau réels, avec fond et parois retenus après simulation.
• Des groupes facultatifs de deux bassins naturels en terrasses peuvent relier plusieurs niveaux par des cascades déclarées. Chaque palier doit avoir ses supports et son propre volume retenu ; une cascade isolée ou des plans d’eau sans liaison ne valident pas un groupe de terrasses. Le second bassin peut avoir une sortie terminale vers les roches ou le vide, sans créer un troisième palier.
• Ces cascades offrent un passage vertical selon les règles de nage de Minecraft. « Rizières » désigne seulement leur disposition paysagère : aucune culture de riz ni téléportation n’entre dans ce ticket.
• Les sorties d’eau sont contrôlées après décoration et après 1 800 ticks, y compris aux frontières de chunks. Leur finition initiale doit préserver les aménagements du joueur aux rechargements suivants.
• Le nouveau réglage sanctuary:sanctuary_cavern s’applique aux nouveaux mondes. Les identifiants et traitements alpha.1 à alpha.8 restent séparés ; aucune sauvegarde personnelle n’est modifiée par les essais.
• Les graines 0, 42 et 8675309 disposent de mesures identifiées par version. Les sites absents sont signalés ; aucun quota de ressources ni bassin de secours ne remplit un relief incompatible.
• Après validation : check build assemblePack, artefacts immuables vérifiés, deux synchronisations isolées puis deux dans la même instance Prism, sauvegardes et réglages conservés.

Validation moteur au 9 septembre 2026 : les trois graines de référence passent les contrôles finaux. Les preuves cumulées démontrent un groupe de deux paliers reliés, un geyser actif et les décors souterrains demandés ; les absences locales et périmètres de mesure figurent dans Validation. Le build est réussi ; la release et le canal packwiz sont publiés. Les deux synchronisations isolées puis les deux passages dans la même instance Prism réussissent, avec 260 fichiers personnels et réglages conservés. Ce ticket local n’est pas une issue distante publiée ; l’essai visuel et l’équilibrage restent ouverts.

WG-11 — Tailles d’île selon la capacité — alpha.10 livrée

Branche : codex/player-capacity-presets.

But : choisir une île initiale adaptée à un groupe de 5, 20 ou 100 joueurs, avec 20 joueurs par défaut, tout en conservant l’ambiance et les anciennes parties.

Critères d’acceptation :

• La création d’un nouveau monde propose trois choix identifiables en FR/EN : Sanctuary par défaut pour 20 joueurs et des variantes pour 5 et 100 joueurs. Les presets sanctuary:sanctuary_5, sanctuary:sanctuary et sanctuary:sanctuary_100 sélectionnent respectivement les paramètres sanctuary:population_5, sanctuary:population_20 et sanctuary:population_100, qui doivent persister dans le monde sauvegardé.
• L’aire nominale suit le rapport capacité/5. Les diamètres de référence sont 512, 1 024 et environ 2 290 blocs ; la hauteur reste de 384 blocs. Le contour sculpté dépend de la graine et n’est pas remplacé par un cercle ou un cylindre.
• Le choix dimensionne la génération, sans modifier max-players, imposer un quota de ressources ni redimensionner l’île lorsque des joueurs arrivent.
• Les tailles conservent un extérieur vide, un spawn naturel, les forêts et l’écologie des cavités. Les eaux et les décors doivent être contrôlés dans les vrais chunks de la taille testée, pas seulement extrapolés depuis l’alpha.9.
• Les réglages et identifiants des générations précédentes restent séparés. Une mise à jour du pack n’agrandit pas un ancien monde, ne convertit pas son générateur et ne régénère aucun chunk.
• La validation progresse de 5 à 20 puis 100 joueurs dans des mondes de développement neufs. Chaque résultat précise capacité, graine, emprise réellement inspectée et durée observée. Un petit échantillon ne valide pas l’intégralité d’une grande île.
• Les tests de génération ne sont pas présentés comme des connexions de joueurs simulées ni comme une promesse de performances multijoueurs.
• Après validation : check build assemblePack, artefacts immuables vérifiés, deux synchronisations isolées puis deux dans la même instance Prism, avec sauvegardes et réglages conservés.

État au 9 septembre 2026 : implémentation et validation moteur terminées sur la graine 0 pour les profils 5, 20 et 100. Les onze tests requis passent dans chaque monde, avec les fluides pendant 1 800 ticks et la persistance réelle des réglages sur disque. Le build et les artefacts sont vérifiés ; la release et le canal sont publiés. Deux synchronisations isolées puis deux dans la même instance Prism réussissent, avec 363 fichiers personnels et réglages conservés. Les références figurent dans Distribution. Les anciens mondes restent inchangés. Les observations ne couvrent pas toute l’île de 100 joueurs, et le coût initial d’un plan régional reste notable. Ce ticket local n’est pas une issue distante publiée.

WG-12 — Petit, Grand et génération plus rapide — alpha.11 livrée

Branche : codex/worldgen-performance.

Problème : les grands formats éloignent trop les constructions. Les essais signalent aussi plusieurs minutes de chargement puis des chunks difficiles à utiliser. Le ticket rapproche les deux choix de départ et optimise les calculs, avec des preuves distinctes pour la taille et la vitesse.

Critères d’acceptation :

• Proposer seulement Petit et Grand dans la création, avec Grand par défaut, et libellés FR/EN. Petit garde le diamètre nominal de 512 blocs ; Grand vise environ 724 blocs, soit une aire nominale deux fois supérieure. La hauteur reste de 384 blocs. Les nombres 5/10 ne servent que de repères internes de surface, sans capacité de joueurs garantie.
• Associer Petit à sanctuary:sanctuary_5 / sanctuary:population_5 et Grand à sanctuary:sanctuary / nouveau réglage sanctuary:population_10. Garder les anciens réglages population_20 et population_100 chargeables, tout en cachant leurs formats dans les choix publics de création.
• Ne pas modifier le relief d’une sauvegarde existante, son identifiant ou son format. Les changements du défaut de création ne convertissent pas un monde. Aucune sauvegarde personnelle n’est ouverte pendant les essais.
• Pour l’optimisation, conserver les résultats à paramètres identiques : densités, plans et blocs utiles, ordre déterministe et protections de l’eau, des terrasses et de la lave. Le nouveau relief Grand a une clé distincte ; la réduction de surface ne compte pas comme gain de calcul à géométrie égale.
• Mesurer séparément démarrage initial, planification et génération d’un lot explicite de chunks. Fixer machine, Java, mémoire, graine, paramètres, coordonnées et état des caches pour comparer alpha.10 et alpha.11.
• Viser 120 secondes au plus de démarrage initial pour les choix publics et au moins 30 % de gain sur les phases comparées à géométrie identique. Un temps de planificateur seul ne prouve pas l’entrée dans un monde jouable. Préciser les bornes de chronométrage et ne pas promettre ces seuils pour tout matériel ou pour une charge de cent joueurs.
• Valider Petit et Grand, plus un témoin de compatibilité et de performance sur l’ancien profil 20. Les anciennes mesures 100 restent historiques ; ce format n’est plus un choix public ni le centre du plan de validation. Examiner le premier accès, le cache réutilisé et les chunks d’exploration.
• Conserver les contrôles moteur de fluides et de réentrée sans marqueur, puis exécuter check build assemblePack sur les sources finales. Garder visibles les limites et toute cible de performance non atteinte.
• Après validation seulement : artefacts immuables, canal packwiz stable, deux synchronisations isolées puis deux dans la même instance Prism. Les mondes, réglages et mods personnels, même désactivés, doivent être préservés.

État : livré. Artefacts immuables publiés, canal stable avancé, deux synchronisations isolées et deux dans la même instance Prism, avec 364 fichiers personnels et réglages suivis conservés. Tailles et code validés. check build assemblePack passe, ainsi que douze tests moteur sur Petit et Grand (graine 0, 1 800 ticks), les contrôles de persistance et l’équivalence bit à bit. Le benchmark ancien20 comparable baisse de 84,65 % au départ et de 86,38 % en exploration. Grand atteint 62,67 secondes pour création + 289 chunks FULL. Cette mesure serveur ne valide pas le rendu ni un temps de chargement universel. Voir Validation, résultats et Distribution pour le reçu de publication et de synchronisation. Ce ticket local n’est pas une issue distante publiée.

WG-13 — Laboratoire d’expansion à branches — alpha.12

Branche : codex/expansion-lab.

But : tester en opérateur de nouvelles îles, des climats alternatifs, les reliefs hauts et les structures vanilla avant de développer leur progression.

Critères d’acceptation :

• Nouveau preset laboratoire ; Petit/Grand et anciennes parties conservés.
• Commandes pour préparer, créer, suivre, reprendre et visiter une île ; opérateurs uniquement, raccourcis et retours FR/EN.
• Parent et direction indépendants du climat, avec tailles nominales bornées 64/128/256/512 et reliefs versionnés. Une branche peut changer de climat.
• Application du relief haut aussi à l’île initiale expérimentale ; dessous historique et sources anciennes préservés.
• Structures vanilla sélectionnées par biome avec contrôles d’emprise/support ; preuve moteur d’une structure réellement placée et de son butin natif.
• Journal atomique et repris après interruption, demandes répétées sans doublon, refus des chunks existants y compris vides, conservation d’un bloc témoin.
• Contrat de réservation explicite avant toute activation. Aucun ancien monde converti ; aucune suppression de chunks ni commande de régénération.
• check build assemblePack et tests moteur sur monde jetable, avec limites documentées. Les recherches, prix, boîtes postales et le Void restent planifiés.

État : implémenté et vérifié localement : build/pack, douze tests historiques, expansions et rechargement moteur de graine 42. Release et MRpack publiés, canal packwiz avancé et même instance Prism synchronisée deux fois ; 466 fichiers personnels et réglages suivis conservés. Validation visuelle et multijoueur encore ouverte. Contrat et portée des preuves dans Laboratoire alpha.12. Ce ticket ne clôture pas par avance les océans, toute la palette de structures ou la progression collective prévus par WG-04 à WG-07 et la vision.

WG-14 — Distance et recherche d’un emplacement libre — alpha.12.1

Branche : codex/expansion-free-space.

Problème : les huit premiers emplacements peuvent contenir du vide déjà sauvegardé. L’alpha.12 refuse alors toutes les directions au lieu de chercher plus loin, et ne propose aucun paramètre de distance.

Contrat et résultat attendu :

• Distance minimale facultative en fin de quick, create et preview, en blocs entre les centres du parent et de l’enfant ; 0 ou omission = automatique.
• Rechercher au plus 32 positions sur le même rayon en dépassant les zones occupées ; conserver le budget global de lecture de 30 secondes.
• Seule une occupation certaine autorise un nouvel essai. Une erreur disque, un timeout ou un terrain sans sol ne doivent pas devenir un nouveau tirage.
• Préserver les anciennes commandes, les identifiants, la graine de chaque île, les descripteurs de génération 12 et le journal v1. La correction s’applique aux mondes laboratoire alpha.12 sans conversion. Les régions existantes sont inchangées ; seules de nouvelles réservations peuvent être ajoutées.
• Vérifier les huit premières directions occupées, la création plus loin, la distance demandée depuis une île fille et les chunks sauvegardés après redémarrage. Fournir les retours FR/EN et la distribution packwiz/MRpack.

État : correction implémentée, smokes et scénarios moteur de création/rechargement réussis. check build assemblePack et douze tests historiques réussis. Release, MRpack et canal packwiz publiés ; même instance Prism synchronisée deux fois, avec 466 fichiers personnels et réglages suivis conservés.

WG-15 — Unifier Sanctuary et ses options — alpha.13

Branche : codex/unified-worldgen.

• Un seul type public Sanctuary, bouton Personnaliser avec Petit (512), Moyen (724, défaut), Grand (1 024). Choix enregistré dans le générateur ; Annuler conserve les réglages. Les types vanilla restent disponibles.
• Réunir le relief, les forêts, minerais, rivières, bassins, terrasses et lave de Sanctuary avec les cavités vanilla luxuriantes, à spéléothèmes et soufrées du laboratoire, en protégeant les volumes hydrologiques pendant la décoration.
• Les outils d’expansion alpha.12.1 fonctionnent dans les nouveaux mondes unifiés. Même contrat opérateur, réservation de zones nouvelles et refus du vide exploré.
• Nouveau codec et origine génération 13 ; les anciens codecs et journaux restent chargeables. Aucun monde personnel n’est ouvert ou converti, aucun chunk régénéré.
• Vérifier les trois tailles, cavités réellement décorées et fluides après ticks, persistance/rechargement, UI client, build et distribution dans la même instance.

État : implémenté et vérifié : bouton natif, paramètres sur disque, huit tests moteur par taille sur la graine 42, eau après 1 800 ticks, trois cavités natives, compatibilité historique et rechargement des expansions. Moyen : 63,66 s pour création et 289 chunks FULL dans le protocole serveur de référence. check build assemblePack passe. Release, MRpack et canal packwiz publiés ; même instance Prism synchronisée deux fois, avec 601 fichiers personnels et réglages suivis conservés. Les limites, dont l’absence de preuve de camp dans l’origine unifiée des graines inspectées, sont documentées dans Validation.

WG-16 — Journal d’expansion sous Windows — alpha.13.1

Branche : codex/windows-expansion-journal.

Problème : après le remplacement atomique du journal, l’ouverture de son répertoire par FileChannel échoue sous Windows avec AccessDeniedException. La session arrête alors toute expansion, même si la réservation a déjà été écrite.

• Écarter uniquement la synchronisation de répertoire non prise en charge par le système de fichiers Windows ; conserver force du fichier, remplacement atomique, relecture stricte et arrêt sur les véritables erreurs de stockage.
• Conserver le schéma, les identifiants, la géométrie et les journaux existants. Après mise à jour et rechargement, reprendre les réservations déjà enregistrées avec le mécanisme existant, sans suppression ni reconstruction de l’historique.
• Tester le chemin Windows par injection, une panne après remplacement et la reprise, puis le build et les scénarios moteur dans le développement local.
• Publier le correctif sur le canal stable. La machine Windows signalée n’est pas accessible depuis cet environnement Mac : ne pas prétendre l’avoir testée.

État : correctif et tests vérifiés en alpha.13.1. check build assemblePack passe, ainsi que le smoke du journal et les scénarios de création/rechargement dans deux processus Minecraft distincts. Validation Windows par injection sur macOS ; aucun essai Windows natif. Correctif publié depuis b19e93d, canal stable avancé et deux synchronisations isolées puis deux dans la même instance Prism Mac réussies, avec 713 fichiers personnels et réglages suivis conservés. Preuves dans Validation et Distribution.

WG-17 — Lost City, territoires urbains en ruine — alpha.14

Branche : codex/lost-city-biome.

Contrat : créer un biome Lost City avec quartiers contemporains explorables, rues, ponts, parcs boisés, jardins, aires de jeux, mémoriaux, places, marchés, parkings, excavations, piscines et bâtiments variés : appartements, hôtels, bibliothèques, restaurants/cuisines, casernes et grands halls. Les palettes reposent sur la pierre, la pierre lisse et les briques de pierre avec leurs variantes usées. Les zombies vanilla occupent les lieux par les règles de spawn ; aucun spawner ni nouveau zombie spécial dans cette étape.

• Des quartiers localisés peuvent apparaître sur l’île initiale ; conserver une majorité de terrain naturel et les systèmes hydrologiques/cavités.
• Profil d’expansion lost_city pour tester des territoires urbains plus vastes. Bâtiments, circulations et ponts s’appuient sur le relief, sans remplir le vide.
• Structures natives persistantes, génération déterministe par graine, décoration bornée par chunk, intérieurs accessibles et butin limité.
• Dix-sept types de parcelles aux aménagements distincts. Parkings souterrains, piscines et fouilles conditionnés à une roche continue sur toute l’emprise ; garage en surface ou parc de repli sinon. Parois et marches des piscines, escaliers et barrières des fouilles, ponts sans remplissage du vide.
• Expansions 64/128/256/512/1 024 dans les nouveaux mondes 14 ; quick sans taille tire selon les poids 40/30/18/9/3, avec résultat reproductible par graine et identifiant. Placement proche dans un secteur directionnel, séparation des emprises circulaires écrites et garde aux coins de chunks.
• Nouvelle génération 14, codec sanctuary:island_v14, journal propre data/sanctuary-world-v14/expansions.json de schéma 1. Ce contrat s’applique uniquement aux nouveaux mondes et à leurs expansions autorisées par commande. Les codecs 12/13, leurs journaux et les chunks existants gardent leur génération. Aucun monde personnel n’est ouvert, modifié, converti ou régénéré.
• Contrat particulier de reprise du vide, limité aux mondes 14 : certificat explicite pour des chunks FULL entièrement vides et vierges, lié au jeton immuable de la réservation. Réouverture obligatoire avant préparation et recontrôle de la preuve ; aucune régénération de terrain occupé. L’absence d’une preuve complète, des entités, POI, ticks ou événements bloc empêchent l’admission. Le contrat détaillé fait partie du ticket.
• Vérifier structures et biomes dans le moteur, persistance après redémarrage, fondations, circulation, absence de spawners/villageois, héritage Windows, build et pack. Livrer dans le canal stable et la même instance Prism.

État : terminé et livré en alpha.14. Build et tests moteur réussis, release et canal packwiz publiés, deux synchronisations isolées puis deux dans la même instance Prism Mac réussies, 713 fichiers personnels et réglages suivis conservés. Aucun essai Windows natif effectué. Les résultats sont suivis dans Validation alpha.14. Les alpha.15/.16 poursuivront la validation de génération avant la bêta consacrée aux systèmes et à la progression. Les infectés, spitters, boomers, hunters, chargeurs et autres variantes restent réservés à la bêta.

WG-18 — Lost City, ville compacte et réseaux souterrains — alpha.15

Branche : codex/lost-city-interiors.

Contrat : reprendre les bâtiments avec des pièces aménagées et une circulation lisible, puis rendre les équipements souterrains et franchissements réellement découvrables dans une petite ville dense et reliée.

• Premier chantier : plans intérieurs propres aux appartements, hôtels, bibliothèques, restaurants, casernes et halls ; seuil, portes, vestibule, couloirs, escaliers, sols, plafonds, chambres et détails d'usage.
• Deuxième chantier en parallèle : égouts procéduraux, pool rooms et garages reliés par des passages, avec accès depuis la surface. Les portions exposées au vide exigent des chaînes ou des pylônes ancrés dans la roche, de longueur bornée. Préserver les eaux naturelles et contenir les bassins construits.
• Troisième chantier : une grille urbaine compacte, avec lots, rues et carrefours jointifs. Les lots sans accès au réseau sont refusés ; les terrasses et dégagements restent dans l’emprise urbaine certifiée. Les ponts et viaducs prolongent ce réseau. Aucun équipement ne doit flotter sans appui.
• Retour de l’essai anticipé : corriger les charnières, les dossiers des sièges et les lanternes ; contrôler les directions après rotation et leur appui sur des blocs complets. Une grande salle sèche accessible dans les tunnels prépare la future machine d’expansion, sans l’activer dans cet incrément.
• Le biome sanctuary:lost_city est conservé : il est effectivement utilisé pour les parcelles urbaines, la décoration et les apparitions naturelles.
• Nouvelle génération 15, codec sanctuary:island_v15, journal propre data/sanctuary-world-v15/expansions.json. Les mondes 12/13/14 conservent leurs codecs, plans et rendus historiques, y compris les chunks encore non générés. Les nouvelles pièces ont un identifiant et des paramètres persistants propres. Aucun monde personnel n'est ouvert, converti ou régénéré pour cette livraison.
• La reprise certifiée du vide conserve le contrat WG-17 dans le journal15, avec une identité de génération stricte ; aucun certificat14 n'autorise15.
• Vérifier parcours, portes et lits, géométrie/supports, eau après ticks, témoins natifs des équipements, biomes et persistance après réouverture. Exécuter check build assemblePack, publier un artefact immuable, avancer packwiz et synchroniser deux fois la même instance Prism avec conservation des réglages.

État : livré et vérifié. Les tests détaillés et les scénarios natifs de création/réouverture passent, avec 76 pièces conservées. check build assemblePack final passe. Release, canal packwiz et même instance Prism à jour ; deux synchronisations réussies et 767 fichiers personnels/réglages suivis conservés. Voir les preuves et le reçu.

WG-19 — Sanctuary habitée avant nous — alpha.16

Branche : codex/sanctuary-ruins-alpha16.

Contrat : conserver l’alpha.15 publiée et corriger les ruines pour que Sanctuary Island possède un quartier identifiable et des infrastructures profondes qui donnent l’impression d’une occupation antérieure.

• Une zone de ville est obligatoire sur la nouvelle île initiale ; les continents restent soumis à leur profil et au terrain. Garder une ville compacte, ses rues continues et la salle souterraine existante.
• Remplacer les minuscules bassins des pool rooms par de grandes piscines souterraines, avec volumes lisibles, allées et accès découvrables.
• Prolonger des égouts jusqu’à de vraies ouvertures extérieures, avec sources et écoulements natifs contrôlés ; les fuites vers le vide sont souhaitées.
• Ajouter sous la ville des plateformes de parking profondes, des ouvertures et des circulations en descente. Les volumes, supports et coûts de génération restent bornés ; ne pas fabriquer une masse cylindrique sous l’île.
• Varier les plans et usages entre étages ; sanitaires clos et raccordés aux cloisons, lits adossés à un mur, orientations et passages cohérents.
• Nouvelle génération16, codecs et pièces propres : les mondes publiés jusqu’à15 gardent leurs plans, rendus, journaux et chunks futurs. Aucun monde personnel n’est converti ou régénéré. Tests dans de nouveaux mondes de développement.
• Le réacteur, les nouvelles familles de donjons, les reliques et leurs règles de butin restent à concevoir par questions à partir de la vision. Ne pas implémenter le réacteur ni activer la progression dans cet incrément.
• Valider la présence et l’accès des piscines, les exutoires après ticks réels, les parcours, la variation des étages, la persistance et la compatibilité15. Exécuter check build assemblePack, publier l’alpha.16 et synchroniser la même instance Prism selon le canal packwiz et ses sauvegardes ciblées.

État : livré et vérifié. Création et réouverture natives réussies, 71 pièces conservées, piscine de 50 × 25 et parking à huit niveaux démontrés. Les six reliefs contrôlés ont une ville ; les équipements restent conditionnels. check build assemblePack passe et la compatibilité15 conserve les empreintes publiées. Voir les preuves. Release et canal packwiz publiés ; même instance Prism synchronisée deux fois, avec les 767 fichiers personnels et réglages suivis conservés. Voir le reçu. Les choix des futurs réseaux et donjons sont consignés dans la vision.

WG-20 — Réseaux oubliés, prototype réversible — alpha.17

Branche : codex/structures-experiment-alpha17.

Contrat : rendre explorables les trois familles validées : mines et ateliers, lieux étranges physiques dans l’île, infrastructures abandonnées. Les traces privilégient des installations utilisables et des chantiers interrompus.

• Nouveau générateur 17 et option « Structures expérimentales » dans le bouton natif Personnaliser. La taille et l’option sont enregistrées avec le nouveau monde ; aucune activation rétroactive ou suppression de structures existantes.
• Conserver les codecs, pièces, plans et futurs chunks des générations publiées, dont 16. La ville 16 reste le socle de 17 ; les nouveaux réseaux disposent de leurs pièces natives, emprises protégées et calculs bornés propres.
• Trois petits réseaux recherchés sur l’île initiale, avec accès de surface, salles, galeries et mobilier. Les continents ne reçoivent pas ce prototype. Les connexions entre réseaux seront évaluées après les premières implantations.
• Ne pas implémenter de réacteur, progression, reliques ou règles de récompenses personnelles. Les coffres éventuels utilisent des tables vanilla différées.
• Tester terrain/supports, connexions internes, accès, réglage sauvegardé, placement natif et réouverture. Livrer le pack et synchroniser l’instance existante selon le protocole packwiz. Donner graines et coordonnées d’essai.

État : livré en alpha.17. Création/réouverture, option désactivée, compatibilité 16 et check build assemblePack passent. Release et canal packwiz publiés, même instance Prism synchronisée deux fois ; les 767 fichiers personnels et réglages suivis sont conservés. Voir le reçu et les coordonnées d’essai. Retour arrière par branche/artefact et option désactivée pour un autre nouveau monde. Aucun retour binaire vers 16 dans une sauvegarde 17 n’est déclaré compatible ; les mondes d’essai restent séparés.

WG-21 — Audit des structures et des anciennes circulations

Branche : codex/structures-audit.

Demande : avant de poursuivre l’implémentation, proposer des structures contemporaines, des axes abandonnés à l’échelle de l’île et leurs liens possibles avec l’expansion, la mailbox et les objets utiles cachés dans des lieux secrets.

État : audit documenté, propositions à discuter. Le catalogue et schéma de relations distinguent les trois petits ensembles actuels des futurs tracés entre destinations, proposent des voies de fret dégradées et des usages pour les bâtiments. Les outils vanilla servent d’idées de butin ; la caméra et les systèmes restent pour la bêta. Aucune structure, règle de butin, version binaire ou instance Prism modifiée. La sélection des lieux et la réalisation des axes feront l’objet du chantier suivant ; ce catalogue n’est pas une liste d’ajouts tous validés.

WG-22 — Anciennes infrastructures et liaisons — alpha.19

Branche : codex/heritage-worldgen-alpha19.

Demande validée : première passe de toutes les nouvelles structures du catalogue WG-21 et de leurs liaisons avant la bêta, en conservant la possibilité de revenir à une génération sans ce chantier.

• Ajouter les quatorze lieux avec architectures, entrées, pièces, mobilier et petits butins vanilla associés à leur usage. Présence selon le terrain ; relever les lieux réellement générés et donner les coordonnées des témoins.
• Planifier des voies de fret et chemins entre destinations réelles, avec sections abandonnées lisibles, appuis et passages vérifiés. Rechercher les raccords aux anciennes installations dans un budget borné.
• Garder une majorité naturelle à l’île ; conserver le terrain, l’hydrologie, la ville et les réseaux existants comme base. Première île uniquement.
• Nouveau codec 19, option expérimentale sauvegardée à la création du monde. Option désactivée : socle urbain seul. Les mondes 17 et antérieurs gardent leur génération, leurs pièces et leurs futurs chunks. Aucune conversion, suppression de structures ou rétrogradation d’une sauvegarde 19.
• Les bâtiments préparent les futurs services ; mailbox, deposit boxes, caméra, réacteur, progression et récompenses personnelles restent pour la bêta. Les coffres de cette passe sont partagés et utilisent du butin vanilla.
• Vérifier créations/réouvertures, option désactivée, anciens mondes, supports, circulations et vrais placements. check build assemblePack, artefacts, publication packwiz et mise à jour de la même instance Prism.

État : livré en alpha.19 ; code, artefacts et synchronisation Prism vérifiés. Voir les essais natifs et la carte des lieux. Version 19 demandée explicitement ; aucune version 18 publiée dans ce dépôt à l’ouverture du chantier. Le catalogue est maintenant accepté pour une première passe, sans imposer sa présence exhaustive sur chaque graine.

WG-23 — Identité architecturale et blocs détaillés — alpha.20

Branche : codex/architecture-alpha20.

Demande : donner aux bâtiments une identité contemporaine lisible selon leur fonction, corriger les vitres isolées et détailler formes, façades et circulations. Employer du tuf, ses briques et variantes ciselées, du chêne, du bouleau, du granit, de la diorite et de l’andésite ; conserver les fondations en briques de pierre. Ajouter des blocs sculptés et du relief architectural.

• Reprendre les quatorze lieux expérimentaux, les bâtiments de Lost City, leurs espaces extérieurs et leurs sous-sols ; palettes par usage, volumes en retrait, biseaux, baies, corniches, liserés et mobilier adapté.
• Résoudre les connexions des vitres, grilles, clôtures et murs ainsi que les angles d’escaliers depuis la géométrie complète, avant le découpage par chunk.
• Dessiner les bordures de routes avec les briques de tuf et le tuf ciselé, en conservant la circulation et les tracés sauvegardés.
• Garder les plans de placement et les emprises certifiées ; génération 20 et types de pièces distincts. Les mondes 19 et antérieurs gardent leurs rendus, y compris dans les futurs chunks. Aucune rénovation rétroactive.
• Garder le bouton natif Personnaliser, les trois tailles et l’option des structures expérimentales pour les nouveaux mondes.
• Vérifier les états réels des blocs, les accès, les supports, les coffres, la création/réouverture et la compatibilité avec la version 19 publiée. Livrer le pack 20 par le canal stable et synchroniser la même instance Prism.

État : livré en alpha.20 ; code, artefacts et même instance Prism vérifiés. Voir le contrat et les essais alpha.20.

Réserve de thèmes futurs

Ces thèmes servent à retrouver la vision, pas à demander leur implémentation immédiate. On en extrait un ticket seulement lorsqu'il devient utile au prochain incrément jouable.

Thème	Contenus à découper plus tard
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
É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
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
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
Only Fun	interactions potaches, chanvre, anniversaires et intégration aux événements
Master Key	permissions communes, configuration, diagnostic et réparation du serveur

Définition pratique d'un ticket terminé

Un ticket contient un résultat observable, un périmètre limité et des critères d'acceptation vérifiables. Sa conclusion indique le comportement livré, la version testée, les vérifications réellement exécutées et les limitations qui subsistent. Les nouveaux besoins découverts deviennent de nouveaux tickets plutôt que des ajouts implicites à tous les systèmes.