Guide des outils de planification : utilisez les pages build, matériaux et équipe comme un flux de travail

Les pages de planification répondent à trois questions différentes, et elles fonctionnent le mieux en séquence. Le constructeur d'équipe /team-build répond à « cette rotation se connecte-t-elle » à partir des règles d'application et de consommation. Le planificateur de build /build-planner répond à « que porte cette équipe » à partir de la compatibilité, des options, des sets et des Runes. Le répond à « que porte cette équipe » à partir de la compatibilité, des options, des sets et des Runes. Le planificateur de matériaux /material-planner répond à « combien tout cela coûte-t-il » à partir du registre cumulé des améliorations. Commencer par le mauvais outil gaspille la session, donc le flux de travail compte plus que n'importe quelle page isolée.

L'ordre du pipeline est : équipe d'abord, build ensuite, matériaux en troisième. Une équipe qui ne se connecte pas rend le build hors de propos ; un build que l'on ne peut pas se permettre fait des matériaux la vraie contrainte. Exécuter les trois pages dans l'ordre transforme chaque décision d'amélioration en séquence vérifiable.

L'habitude hebdomadaire commence par la rotation. Ouvrez le constructeur d'équipe /team-build, re-vérifiez la chaîne du trio actif contre le roster et les règles actuels, et confirmez qu'aucun nouveau déblocage n'a changé les maillons. Le constructeur signale quel maillon manque quand la chaîne échoue, donc le premier correctif est généralement un slot, pas une reconstruction. Quand la rotation est confirmée, la question d'équipe est close pour la semaine.

La question d'équipe doit être re-posée après chaque déblocage, patch ou refonte, car les faits de chaîne sont calculés à partir des données actuelles. Un connecteur optimal la semaine dernière peut avoir une route moins chère cette semaine, et le constructeur le montre sans dépenser quoi que ce soit.

Une fois la rotation connectée, la question du build commence : quel équipement convient à l'équipe, quels seuils de set le loadout active, et quelles Runes soutiennent le même objectif. Le planificateur de build /build-planner détient l'état du loadout — les cinq slots, les pièces, les cibles d'amélioration, les slots de Runes — et compare les alternatives sans dépenser de matériaux. La réponse du build alimente les cibles de farm : une pièce de set, un pool d'options, un niveau d'amélioration.

Le planificateur de build attrape aussi les erreurs transversales : un set qui semble bon dans la base mais entre en conflit avec les altérations de l'équipe, ou une Rune qui booste une statistique que la rotation n'utilise jamais. Comparer le loadout à la chaîne garde les deux réponses cohérentes.

La question finale est le coût. Le planificateur de matériaux /material-planner fusionne les jalons de compétences de l'équipe, les cibles d'amélioration du build et tous les objectifs de Karma ou de cuisine en un registre de pénuries unique, et le registre est le calendrier de farm. La route des pénuries vient de la base d'objets /items et de la et de la carte d'Orbis /map, et la boucle hebdomadaire nourrit le reste. Quand le registre montre une pénurie sans source documentée, cet objet devient une vérification en jeu plutôt qu'un rendement planifié.

Le registre est aussi la vérification de réalité. Un build qui semble parfait mais coûte trois semaines d'un matériau partagé est une décision différente une fois le chiffre visible, et le planificateur rend le chiffre visible avant la dépense. Le flux de travail honnête se termine par le registre, pas par le build.

Les trois pages fonctionnent le mieux comme une revue hebdomadaire unique : équipe dans le constructeur d'équipe /team-build, loadout dans le planificateur de build /build-planner, budget dans le , budget dans le planificateur de matériaux /material-planner, et les questions restantes routées vers les bases et la carte. La revue prend quelques minutes et remplace trois improvisations par un plan. Quand le jeu change — un patch, un déblocage, un nouveau type de contenu — la même revue se relance contre les données actuelles, donc le plan ne survit jamais à ses faits.

Le pipeline sert aussi de dépannage : quand une décision bloque, la question est simplement de savoir dans laquelle des trois étapes elle se situe. Un doute sur un héros se règle dans le constructeur d'équipe /team-build ; un doute sur un loadout se règle dans le planificateur de build /build-planner ; un doute sur un budget se règle dans le ; un doute sur un budget se règle dans le planificateur de matériaux /material-planner. Classer le problème dans la bonne étape évite de re-planifier tout ce qui est déjà confirmé.