sanctuary-beta/AGENTS.md

Sanctuary Beta — travail par tickets

Ce dépôt contient le pack Sanctuary et ses mods. Lire README.md, puis le ticket concerné. La vision est dans docs/vision.md ; elle décrit aussi des fonctionnalités futures.

• Avant une modification, lire l'état Git et préserver les changements existants.
• Un ticket correspond à un résultat jouable ou vérifiable et à une branche codex/<sujet>.
• Garder les changements ciblés. Le dépôt voisin 26.2 est une référence historique, pas une cible de modification ou de déploiement.
• Les sources Java sont dans mods/<mod>/, le manifeste du pack dans packwiz/.
• Les règles de jeu et sauvegardes font autorité côté serveur. Les mods autonomes gardent leur propre responsabilité.
• Ne pas modifier un monde existant, régénérer des chunks, changer un format de sauvegarde ou activer une expansion sans contrat de migration explicite.
• Garder les identifiants sanctuary:* stables et documenter toute évolution de la génération avec graine et version.
• Ajouter les libellés FR/EN des nouvelles interfaces. Vérifier les dépendances pour la version Minecraft exacte ; aucune compatibilité supposée à partir du nom d'un mod.
• Lancer ./gradlew check build pour livrer du code, et ./gradlew assemblePack si la distribution change. Ajouter seulement les tests utiles au comportement touché.
• Pour chaque nouvelle livraison du mod, incrémenter mod_version et pack_version dans gradle.properties, synchroniser packwiz/pack.toml et documenter le changement. Une simple modification documentaire n'incrémente pas les binaires.
• Le pack Beta suit un canal packwiz stable et une seule instance Prism. Pour une mise à jour demandée, suivre docs/packwiz.md : publier un artefact vérifié et immuable, avancer le canal, puis synchroniser l'instance existante en conservant ses sauvegardes et réglages.
• Ne pas versionner de secrets, mondes, JAR générés ou dépendances téléchargées. Le wrapper Gradle fait exception.
• Ne pas déployer dans une installation de jeu ou un serveur personnel sans demande correspondante. Les serveurs de test restent dans les dossiers de développement ignorés.
• Une livraison explique le résultat, les vérifications effectuées et les limites encore ouvertes. Ne pas marquer une intention comme implémentée.