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 validé dans les sources alpha.11 : Petit/Grand et génération accélérée. La publication et la synchronisation sont consignées dans 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 validée dans les sources

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

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.