Files

T

Antone Barbaud ffc77c4213 feat: initial CR-Core library (team + player + command framework)

Pure Maven library for CR Minecraft game plugins, targeting Paper 1.16.5.

Common abstractions (fr.luc.crcore.common): Identifiable, Named, ScoreHolder,
AbstractEntity, Repository<T>.

Team domain (fr.luc.crcore.team): Team entity with name/tag/color/leader/
visibility (PUBLIC|PRIVATE)/members/scores/spawn point, TeamMember,
TeamRole/TeamColor/TeamVisibility enums, TeamRanking record, TeamService with
overridable hooks (factories, validations, lifecycle events), in-memory
repository, dedicated exception hierarchy.

Player domain (fr.luc.crcore.player): PlayerProfile with named scores per
player, PlayerProfileService with auto-creation, individual rankings,
exception hierarchy. Both Team and PlayerProfile implement ScoreHolder.

Command framework (fr.luc.crcore.command): Command interface,
AbstractCommand base, BaseCommand (CommandExecutor + TabCompleter), SubCommand,
CommandContext, CommandResult, ArgumentType<T> + ArgumentTypes catalogue
(STRING, INTEGER, DOUBLE, BOOLEAN, ONLINE_PLAYER, enumOf, choice).

Docs (docs/) is the single source of truth: README, setup, features,
decisions log, and 6 PlantUML diagrams (team class/sequence/activity/join,
player class, command class).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

2026-06-08 17:17:56 +02:00

2.7 KiB

Raw Blame History

GEMINI.md — Instructions pour l'assistant

Source de vérité

Le dossier docs/ est la source unique de vérité du projet.

Toute spécification, règle, décision technique, commande ou contrainte doit être lue depuis docs/ et écrite dans docs/.
Avant d'implémenter, vérifier ce qui est consigné dans docs/.
Toute nouvelle information donnée par l'utilisateur va dans le fichier adapté :
- docs/features.md — domaines fonctionnels (team, command, …)
- docs/decisions.md — décisions techniques / architecturales
- docs/setup.md — installation, build, intégration côté plugin de jeu
- docs/README.md — vue d'ensemble et index
- docs/diagrams/*.puml — diagrammes (classe / séquence / activité)
En cas de conflit code ↔ docs/, docs/ fait foi : aligner le code, ou mettre la doc à jour explicitement avec l'utilisateur.

Nature du projet

CR-Core est une librairie Java/Maven pure — pas un plugin Bukkit. Elle fournit les briques réutilisables (domaine team, framework de commandes, abstractions communes) que chaque plugin de jeu (futur CitesPlugin, etc.) consomme en dépendance Maven.

Nom : CR-Core (artifactId Maven : CR-Core)
Type : librairie (jar) — pas de plugin.yml, pas de JavaPlugin
Cible runtime : serveur Paper/Spigot 1.16.5 (le plugin de jeu downstream est responsable du plugin.yml et de l'enregistrement des commandes)
Build : Maven, Java 16
Package racine : fr.luc.crcore

Principe : simple par défaut, overridable partout

Toutes les classes du noyau sont conçues pour être étendues. Les services fournissent une implémentation "tout faite" (ex. TeamServiceImpl), mais chaque étape importante est exposée via une méthode protected (newTeam, validateName, onAfterCreate, …) qu'une sous-classe peut overrider.

Règles :

Pas de final sur les classes du noyau, sauf raison forte.
Méthodes-clés en protected (pas private) pour permettre l'override.
Hooks onBefore... / onAfter... partout où ça a du sens.
Factories (newTeam, newMember, …) pour permettre de substituer des sous-classes sans réécrire le service.

Workflow attendu

Lire le contexte pertinent dans docs/.
Discuter / valider l'approche avec l'utilisateur si nécessaire.
Mettre à jour docs/ (et le .puml concerné) avec la décision ou la spec.
Implémenter le code conformément à la doc.

Conventions de code

Code (classes, méthodes, attributs, variables) en anglais standard.
Messages joueur et documentation en français.
Séparation stricte : interface, enum, abstract class, class concrète, exception — chacun dans son fichier.

2.7 KiB Raw Blame History