sanctuary-beta/docs/prochains-tickets.md

# Prochains tickets — carte immersive, progression et New Game+

Cadrage du 13 septembre 2026, après l'essai de beta.006.
Branche documentaire : `codex/roadmap-progression-ngplus`.
**Statut : MAP-03 implémenté en beta.007, PROG-02A en beta.008, PROG-02B en beta.009, PROG-02C en beta.010 ; CYCLE-01, PROG-03, FACTION-01 et NGP-01 sont réunis dans beta.011.**
Le cadrage initial organisait la prochaine séance, évoquée pour demain.
Le créateur a ensuite demandé la carte immersive ; ses vérifications sont
consignées dans [la livraison beta.007](atlas-immersive-beta007.md).

La version **beta.013** aligne les compétences sur une ligne et abaisse le
dernier achat à 48 niveaux ([contrat](progression-inline-beta013.md)), après
les transferts et barres rapides de [beta.012](inventory-flow-beta012.md).
Les numéros suivants sont des cibles
indicatives, à attribuer au moment des livraisons sans réutiliser une version.
Les identifiants de tickets ci-dessous sont locaux au dépôt.

## Ordre de travail

Le créateur demande désormais d'achever la progression avant le New Game+,
et de concevoir les factions en lien avec celui-ci. Cela complète la priorité
antérieure carte → Demeure → factions/claims → New Game+.

| Ordre | Ticket | Résultat vérifiable | Prérequis | Livraison visée |
| --- | --- | --- | --- | --- |
| Cadrage dès maintenant | CYCLE-01 | Contrat commun progression, recommencement, prestige et factions | Décisions du créateur | [Contrat beta.011](cycle-factions-beta011.md) |
| 1 | MAP-03 | Carte plein écran, transparence et commandes superposées | MAP-02 livré en beta.006 | [beta.007](atlas-immersive-beta007.md) |
| 2 | PROG-02A | Compétence Minage et vein mining jouables | Contrat des rangs et des entrées | [beta.008](mining-beta008.md) |
| 3 | PROG-02B | Compétence Construction et vein building jouables | PROG-02A pour les commandes communes | [beta.009](building-beta009.md) |
| 4 | PROG-02C | Compétence Inventaire fonctionnelle, objets préservés | Politique d'inventaire CYCLE-01 | [beta.010](inventory-beta010.md) |
| 5 | PROG-03 | Parcours de progression complet et fin atteignable | PROG-02A/B/C et règle de fin | [beta.011](cycle-factions-beta011.md) |
| 6 | FACTION-01 | Factions persistantes et capacités articulées au prestige | CYCLE-01 ; progression complète avant validation finale | [beta.011](cycle-factions-beta011.md) |
| 7 | NGP-01 | Premier recommencement complet, du personnage aux factions | PROG-03, FACTION-01, CYCLE-01 | [beta.011](cycle-factions-beta011.md) |

Le [contrat commun beta.011](cycle-factions-beta011.md) remplace les questions
ouvertes ci-dessous pour les prix, les rôles et la conservation. Ces quatre
tickets interdépendants sont livrés ensemble sur `codex/factions-new-game-plus`,
à la demande du créateur. Les critères initiaux restent conservés ci-dessous.
La suite est CLAIM-01 : le présent lot n'attribue aucune protection de chunk.

```mermaid
flowchart LR
    M[Carte immersive] --> A[Minage]
    A --> B[Construction]
    B --> I[Inventaire]
    I --> P[Progression complète]
    C[Contrat cycle et factions] --> I
    C --> F[Factions]
    P --> F
    F --> N[New Game+ et prestige]
    P --> N
```

## CYCLE-01 — Définir ce qui termine et ce qui recommence

**Branche prévue :** `codex/progression-cycle-contract`.
**Résultat :** une règle de fin de progression et une matrice de conservation
suffisamment précises pour implémenter le reset sans inventer de règles.

Décisions déjà acquises : les six compétences sont Vie, Faim, Minage,
Construction, Souffle et Inventaire. Une mort ordinaire conserve compétences
et aptitudes ; elle suit la règle d'XP récupérable existante. Un recommencement
de personnage est distinct : les compétences sont à remonter, les aptitudes
acquises sont conservées. Demeure mesure l'habitation ; ce n'est pas une
propriété ni une autorisation de modifier les blocs.

**Condition confirmée par le créateur : les six compétences au maximum.**
Vie, Faim, Minage, Construction, Souffle et Inventaire doivent chacune atteindre
leur plafond. Il n'est pas nécessaire d'avoir acheté toutes les aptitudes.
Les aptitudes déjà acquises sont conservées au recommencement. Le serveur
évalue les six rangs ; une future aptitude n'ajoute pas un prérequis au NGP.

À fixer dans ce ticket :

- La présentation des six compétences et de leurs plafonds dans le Blocodex,
  ainsi que le traitement d'une évolution future des plafonds : un équilibrage
  ne doit pas modifier silencieusement une fin de cycle déjà enregistrée.
- Le rapport entre New Game+, compteur de prestige et récompense : ce sont
  des notions à relier explicitement, pas trois synonymes à supposer.
- La règle des charges ou places de faction : capacité d'en créer une,
  d'agrandir une faction, d'en rejoindre plusieurs ou autre effet ; quantité,
  détenteur de la capacité et éventuelle mise en commun.
- Pour identité, bio, couleur, aptitudes, compétences, achats, XP restante,
  objets, recettes/découvertes, Atlas, Demeure, exploits, argent et affiliations :
  indiquer conservé, réinitialisé ou archivé. Les aptitudes conservées ne peuvent
  pas dépendre accidentellement d'un ancien rang qui les rendrait inutilisables.
- Le sort des objets quand les emplacements d'inventaire diminuent, et celui
  d'une faction lorsque son créateur recommence. Aucune suppression implicite
  d'objets, de membres, de constructions ou d'archives collectives.

**Acceptation :** deux exemples chiffrés avant/après (premier puis second
cycle), un cas avec inventaire plein et un cas avec faction existante. Vérifier
qu'aucun prérequis ne forme une boucle impossible : finir la progression ne
peut pas exiger une faction si sa création exige le premier prestige.
Ce ticket ne régénère pas le monde et n'introduit pas la quête finale donnant
collectivement accès au créatif ou aux droits opérateur.

## MAP-03 — Faire de la carte le fond du Blocodex

**Branche :** `codex/atlas-immersive`.
**Implémentation :** [beta.007 et ses vérifications](atlas-immersive-beta007.md).
**Résultat :** la carte occupe l'écran ; l'interface se pose dessus.

Le rendu de beta.006 était limité à 720 unités GUI en largeur, réservait deux lignes
de commandes et un pied de coordonnées, puis découpait la texture dans la bande
restante. Cette combinaison produisait le rectangle étroit observé en beta.006.

Demandes visuelles retenues :

- Étendre la surface cartographique jusqu'aux bords de l'écran, sous les zones
  assombries du haut et du bas. La partie directement lisible rejoint les
  boutons supérieurs et descend jusqu'au bouton de retour, actuellement
  **Done / Terminé** (appelé « down » dans la discussion).
- Conserver un carré éclairci au centre, avec la carte plus sombre autour.
  Ce carré est un traitement de lumière : il ne découpe ni ne limite la carte.
  Adapter sa taille au GUI ; régler les opacités sur des captures en jeu.
- Rendre transparent ce qui n'a pas de surface cartographique à dessiner.
  Le vide observé et l'inconnu gardent leurs états distincts côté serveur,
  même si leur représentation utilise la transparence. Le fond du menu peut
  rester visible ; aucun terrain cartographique inconnu n'est reconstruit.
- Superposer coordonnées et zoom en bas à gauche, avec contraste suffisant.
  Les onglets, le retour, le recentrage, le zoom, la grille, Demeure et le mode
  opérateur restent des commandes accessibles ; leurs panneaux n'enlèvent plus
  deux bandes de hauteur à la carte.
- Donner la priorité des clics aux boutons. Le reste de la carte, y compris
  les zones assombries, accepte déplacement et zoom. Garder les glissements
  successifs et le relâchement hors zone validés en beta.006.

**Acceptation :** captures à 640×480, 1280×720 et écran large, plusieurs échelles
GUI ; carte visible jusque sous les habillages, coordonnées lisibles, commandes
sans chevauchement. Vérifier transparence du vide, brouillard, panorama déplacé,
zone sans relevés, mode verrouillé, vue opérateur, révocation et retour parent.
La grille et les empreintes restent alignées avec la carte sur tout l'écran.

**Données :** rendu client et disposition ; conserver les relevés et identifiants
existants. Aucun format de sauvegarde ou changement de génération attendu.
**Hors lot :** minimap, marqueurs, partage et nouveaux droits de claim.

## PROG-02A — Minage et vein mining

**Branche :** `codex/progression-vein-mining`.
**Implémentation :** [beta.008, contrat et vérifications](mining-beta008.md).
**Résultat :** acheter des rangs de Minage et extraire un groupe de blocs par
un geste volontaire, prévisualisé et limité par la progression du serveur.

- Remplacer « À venir » par rang, effet présent, prochain effet et coût.
  Minage reste une compétence dans la colonne gauche.
- Reprendre la sélection historique de blocs identiques connectés par leurs
  faces, son aperçu, son arrêt et ses limites. L'orientation en plan, évoquée
  dans la vision, ne doit pas être annoncée comme déjà fournie par cet
  algorithme de veine ; son éventuel ajout demande un mode explicite.
- Une touche configurable maintenue avec le clic gauche engage l'action.
  Une souris sans bouton latéral doit pouvoir l'utiliser ; B garde le Blocodex.
  Prévoir le choix d'une taille inférieure à celle autorisée par le rang.
- Le serveur recalcule la sélection, applique les règles des outils, la durée,
  la durabilité, la faim, les enchantements et les permissions de chaque bloc.
  Interrompre au relâchement, changement d'outil, mort ou déconnexion.
- Utiliser les actions natives pour les drops et l'XP ; une casse effective
  produit une seule découverte/statistique/trace Demeure. La sélection et
  l'aperçu ne produisent aucune récompense ni influence.

**Référence historique, à équilibrer :** rangs 0–7, limites
`1 / 4 / 8 / 16 / 32 / 64 / 128 / 256`, recherche à sept blocs sur chaque axe.
Le multiplicateur de vitesse historique va de 25 % à 100 %. Cette lenteur
initiale, ces quantités et les anciens coûts ne constituent pas encore un
équilibrage approuvé pour la bêta. Les valeurs d'essai seront documentées.

**Acceptation :** rang zéro, achat et plafond, outil adapté/inadapté, usure jusqu'à
rupture, Fortune/Silk Touch, cible indestructible, coffre exclu, arrêt immédiat,
deux joueurs sur la même veine, chunk non chargé, permission refusée et requête
client demandant un rang supérieur. Son du groupe maîtrisé et aperçu cohérent.

**Données :** rédiger le contrat d'évolution des rangs et de l'historique avant
le code ; relire beta.003–006 sans changer les achats, aptitudes, identité ou
couleur. Reconnexion, redémarrage et mort conservent les rangs acquis.

## PROG-02B — Construction et vein building

**Branche :** `codex/progression-vein-building`.
**Implémentation :** [beta.009, contrat et vérifications](building-beta009.md).
**Résultat :** acheter des rangs de Construction puis poser une surface annoncée
par l'aperçu, en consommant les blocs réellement utilisés.

- Activer la compétence de gauche avec rang, effet et coût. Reprendre les plans
  historiques : face cliquée et orientation du joueur déterminent sol, mur
  ou plafond et ordre de pose.
- Partager les conventions de commande avec Minage : touche reconfigurable
  et clic droit, taille ajustable dans le plafond acheté, arrêt au relâchement.
  La touche B historique du Builder doit être remplacée.
- Recalculer la sélection sur le serveur ; poser par l'action Minecraft
  normale pour respecter orientation, supports, collisions et permissions.
  Revalider chaque cible si le monde change pendant l'opération.
- Consommer seulement les objets effectivement posés ; arrêter proprement à
  l'épuisement du stock. Préserver les refus et les contenus des blocs.
  Chaque pose réussie alimente une seule fois Blocodex, statistiques et Demeure.
- Séparer clairement capacités de construction, mode créatif et statut
  opérateur. Un opérateur en survie ne reçoit pas des matériaux gratuits.

**Référence historique, à équilibrer :** rangs 0–7, diamètres
`1 / 3 / 5 / 7 / 9 / 11 / 13 / 15` ; cadence de survie historique 0,5 pose par
tick. La portée 3–5,5 blocs historique est distincte du diamètre du plan.
Décider explicitement si la compétence reprend aussi cette portée, sans
modifier la portée d'attaque. Coûts et cadence à éprouver avec Minage.

**Acceptation :** sol/mur/plafond, quatre orientations, dalles et escaliers,
stock insuffisant, cible occupée, annulation en cours, changement d'objet,
limite de chunk chargé, deux bâtisseurs concurrents et permission refusée.
L'aperçu ne consomme pas d'objet ; une pose refusée n'est pas comptabilisée.
Les rangs et achats survivent à la mort et au redémarrage.

## PROG-02C — Terminer la compétence Inventaire

**Branche :** `codex/progression-inventory`.
**Implémentation :** [beta.010, contrat et vérifications](inventory-beta010.md).
**Résultat :** une sixième compétence achetable et utile, avec une capacité
réelle, la même côté serveur et dans tous les menus.

Cadrer le nombre de rangées, le rôle de la barre rapide et les plafonds.
La proposition historique d'une à six rangées reste une référence à confirmer,
pas l'état actuel de beta.006. Les parties déjà remplies exigent un contrat
d'adoption : activer un petit inventaire ne peut pas supprimer des objets.

**Acceptation :** clic, glisser-déposer, déplacement rapide, collecte, fabrication,
conteneurs, mort, `keepInventory`, reconnexion et rechargement, sans duplication
ni disparition. Contrôler le protocole des emplacements ; un client ne peut pas
utiliser une case verrouillée. Préparer le cas de réduction au New Game+ selon
CYCLE-01, sans activer un reset dans ce ticket.

## PROG-03 — Rendre la progression achevable

**Branche prévue :** `codex/progression-complete`.
**Résultat :** un nouvel habitant peut comprendre, financer et terminer le
parcours retenu ; le serveur sait dire précisément ce qu'il lui manque.

- Les six compétences sont fonctionnelles et testées ensemble. Fixer rangs,
  plafonds et coûts, et éprouver les interactions Faim/Minage/Construction.
- Vérifier les aptitudes présentes, leurs conditions d'achat et leur
  conservation au prochain cycle. Les aptitudes futures gardent leurs tickets
  propres et ne retardent pas la fin des six compétences ; aucun bouton
  achetable ne promet un effet absent.
- Donner une indication accessible pour obtenir les premiers niveaux. Choisir
  entre tutoriel des sources d'XP existantes et objectifs de découverte à usage
  limité, puis vérifier un début de partie en survie sans commandes opérateur.
  Toute récompense de première découverte doit définir sa persistance au NGP.
- Appliquer la condition confirmée **six compétences au maximum** et afficher
  les compétences encore incomplètes dans le Blocodex. Le contrôle repose sur
  les rangs serveur. Des aptitudes non achetées n'empêchent pas le NGP.

**Acceptation :** cinq compétences maximales et une incomplète refusent le
NGP ; les six maximales l'autorisent même si des aptitudes restent non acquises.
Vérifier parcours début/milieu/fin, insuffisance d'XP, achats doublés,
mort avant et après achat, déconnexion, sauvegarde et reprise. Le futur NGP
reste inaccessible tant que ses prérequis ne sont pas remplis. Documenter
les réglages retenus et les limites ouvertes avant de déclarer la progression
terminée. Fournir un MRpack d'essai de cette boucle complète.

## FACTION-01 — Factions persistantes, capacités et prestige

**Branche prévue :** `codex/factions-foundation`.
**Résultat :** créer, rejoindre et administrer une faction avec des identités
stables, et expliquer les capacités liées au prestige dans le Blocodex.

Définir rôles, invitations/acceptation, départ, transfert et dissolution,
ainsi que la distinction entre couleur d'habitant et identité de faction.
Implémenter les charges/places selon CYCLE-01 ; leurs montants et bénéficiaires
ne sont pas déduits des anciens « slots ». Fournir l'opération serveur qui
recevra la récompense d'un cycle une seule fois ; NGP-01 en sera le déclencheur.

**Acceptation :** au moins deux habitants, invitations concurrentes, absence
de l'administrateur, déconnexion, rechargement et capacité épuisée. Un reset
personnel ne peut pas effacer implicitement une faction ou ses membres.
La progression ordinaire, les permissions opérateur et les rôles de faction
restent distincts. Aucun droit de modification de terrain n'est déduit d'une
empreinte Demeure ou de l'appartenance à une faction.

## NGP-01 — Premier cycle complet

**Branche prévue :** `codex/new-game-plus`.
**Résultat :** un habitant éligible termine son parcours, choisit de recommencer,
retrouve ses aptitudes et reçoit l'effet de prestige/faction convenu.

- Afficher avant le choix ce qui est conservé, remis à zéro et archivé.
  Le déclenchement est volontaire et validé côté serveur.
- Appliquer ensemble la nouvelle progression, le traitement d'inventaire et
  l'effet de prestige/faction. Identifier le cycle pour qu'une répétition de
  requête ou une reprise après interruption ne donne pas deux récompenses.
- Garder la mort ordinaire séparée ; annuler une demande ne modifie aucune
  donnée. Le caractère individuel du recommencement ne permet pas de déduire
  une régénération du monde commun.
- Enregistrer un événement daté de cycle, avec identifiants stables d'habitant
  et de faction lorsque pertinent, pour la mémoire du serveur et le futur
  site. Ce lot ne construit pas la connexion Web.

**Acceptation :** premier puis deuxième cycle, une compétence sous le maximum,
six compétences au maximum sans toutes les aptitudes, aptitudes
conservées, compétences remises à leur départ décidé, objets traités sans perte,
faction existante, répétition de requête, interruption et redémarrage. Tester
la reprise à chaque étape de la transition ; aucune récompense de découverte
ou de prestige ne doit être encaissée deux fois pour un même événement.

## Après ce jalon

**CLAIM-01** traitera la réservation et la protection des chunks à partir des
factions et d'un contrat dédié : emprise, capacités, droits, conflits, abandon
et incidence du prestige. La grille et Demeure restent des lectures du monde
jusqu'à ce ticket. Mini-carte, marqueurs, partage, recettes, plans et autres
aptitudes gardent leurs tickets propres. Leur absence ne bloque pas le New
Game+ lorsque les six compétences sont au maximum.

Le [cadrage CLAIM-01 — titres de propriété temporaires](property-titles-ticket.md)
précise les décisions du 15 septembre 2026 : un titre couvre un seul chunk ;
il faut renommer l'objet puis faire un clic droit pour revendiquer le chunk.
Un autre titre portant le même nom permet d'étendre la même propriété,
y compris à un chunk séparé, sans revendiquer les chunks intermédiaires.
Les titres restent attachés aux chunks ; une réserve de **saphirs consommés
successivement** entretient leur protection en temps réel, même lorsque le
joueur est déconnecté, tant que le serveur tourne. À la fin de la période
payée, sans assez de saphirs pour renouveler, la protection disparaît
immédiatement. Acquisition des titres, tarifs d'entretien, paliers, durée des
périodes, traitement des arrêts du serveur et droits de réservation sans
protection restent à décider ; ce mécanisme n'est pas encore implémenté.

## Références et validation des livraisons

La référence historique est consultée en lecture seule dans `../26.2/sanctuary` :
[contrat de progression](../../26.2/sanctuary/PROGRESSION.md),
[limites par rang](../../26.2/sanctuary/src/main/java/fr/koka99cab/sanctuary26/sanctuary/gameplay/SanctuaryBulkActionLimits.java),
[sélection des veines](../../26.2/sanctuary/src/main/java/fr/koka99cab/sanctuary26/sanctuary/gameplay/mining/SanctuaryVeinSelection.java)
et [plans de pose](../../26.2/sanctuary/src/main/java/fr/koka99cab/sanctuary26/sanctuary/gameplay/building/SanctuaryBuildPlane.java).
Ces sources attestent les mécanismes cités, sans prouver leur portabilité.
La cible de travail reste celle de `gradle.properties`, actuellement 26.3-pre-2.

Pour chaque ticket de code : contrat de données préalable si nécessaire,
libellés FR/EN, `./gradlew check build`, tests natifs ciblés et parcours client
adaptés au comportement, puis `./gradlew assemblePack` et MRpack immuable
lors d'une livraison. Incrémenter mod et pack ensemble. Les actions groupées
respectent les protections effectives ; aucun test ne doit inventer des claims
absents. Conserver les mondes personnels et les anciens artefacts.