Antone Barbaud
c1b414f400
CRCore bootstrap class: one-line setup for game plugins (new CRCore(this).enable()).
Wires SQLite, services with event firing, and the /core command tree.
SQLite layer (fr.luc.crcore.database): Database wrapper exposing execute/update/
queryOne/query plus a fluent TableBuilder. ColumnType enum, RowMapper interface,
DatabaseException. Game plugins create their own tables in 2 lines via
db.table("foo").ifNotExists().column(...).create().
Repositories: SqliteTeamRepository and SqlitePlayerProfileRepository extend their
InMemory counterparts (write-through cache). 5 internal tables prefixed crcore_.
Command framework refactored for nested sub-commands: subcommand storage moved
from BaseCommand to AbstractCommand, recursive dispatch() and tabComplete(),
replaceSubCommand() for plugin overrides.
Default /core team commands (13 leaf sub-commands): create, delete, add, remove,
join, leave, info, list, transfer, visibility, score, top, setspawn. Each in its
own class under fr.luc.crcore.command.builtin.team, fully substitutable.
Bukkit events: 9 team events (Create/Dissolve/MemberAdd/MemberRemove/PlayerJoin/
LeadershipTransfer/VisibilityChange/ScoreChange/SpawnPointChange) + 3 player
events (ProfileCreate/Delete/ScoreChange). All post-only, non-cancellable.
BukkitEventFiringTeamServiceImpl and BukkitEventFiringPlayerProfileServiceImpl
override the on* hooks to call Bukkit.getPluginManager().callEvent.
JavaDoc on all new public classes and key existing ones. docs/, GEMINI.md and
PUML diagrams synced: new sections (built-in commands, events, database,
bootstrap), 4 new diagrams (builtin-commands, events, database, bootstrap-
sequence), and 7 new architecture decisions logged.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
79 lines
3.4 KiB
Markdown
79 lines
3.4 KiB
Markdown
# 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, player, commandes built-in, events, database)
|
|
- `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.
|
|
|
|
## Nature du projet
|
|
|
|
**CR-Core** est une **librairie Java/Maven** consommée par des plugins Bukkit
|
|
("plugins de jeu"). Pas de `plugin.yml` côté core — c'est le plugin de jeu
|
|
qui en a un et qui instancie {@code CRCore} dans son {@code onEnable()}.
|
|
|
|
- **Nom** : CR-Core (artifactId Maven : `CR-Core`)
|
|
- **Type** : librairie (`jar`)
|
|
- **Cible runtime** : serveur Paper/Spigot 1.16.5
|
|
- **Build** : Maven, Java 16
|
|
- **Package racine** : `fr.luc.crcore`
|
|
- **SQLite** : `org.xerial:sqlite-jdbc` (compile scope)
|
|
|
|
## Domaines
|
|
|
|
- `fr.luc.crcore.common` — abstractions partagées (`Identifiable`, `Named`,
|
|
`ScoreHolder`, `AbstractEntity`, `Repository<T>`)
|
|
- `fr.luc.crcore.team` — équipes : visibilité (PUBLIC/PRIVATE), membres,
|
|
leader, scores nommés, classements, point de spawn. Sous-package `event/`
|
|
pour les évènements Bukkit.
|
|
- `fr.luc.crcore.player` — profils joueurs : scores nommés, classements
|
|
individuels. Sous-package `event/`.
|
|
- `fr.luc.crcore.command` — framework de commandes (nested sub-commands,
|
|
arguments typés, tab-complete). Sous-package `builtin/` pour les commandes
|
|
par défaut `/core team ...`.
|
|
- `fr.luc.crcore.database` — wrapper SQLite minimaliste (`Database`,
|
|
`TableBuilder`, `RowMapper`).
|
|
- `fr.luc.crcore.CRCore` — point d'entrée bootstrap (instancié en une ligne
|
|
par le plugin de jeu).
|
|
|
|
## Principe : simple par défaut, overridable partout
|
|
|
|
Chaque service expose des **hooks `protected`** que les plugins de jeu peuvent
|
|
overrider :
|
|
- factories (`newTeam`, `newRanking`, `newProfile`)
|
|
- validations (`validateName`, `validateJoinable`, …)
|
|
- post-hooks (`onAfterCreate`, `onMemberAdded`, `onScoreChanged`, …)
|
|
|
|
Chaque commande built-in (`TeamCreateSubCommand`, etc.) est elle aussi
|
|
substituable par nom via `replaceSubCommand(...)`.
|
|
|
|
**Règles** :
|
|
- Pas de `final` sur les classes du noyau.
|
|
- Méthodes-clés en `protected` (pas `private`).
|
|
- Hooks `onBefore...` / `onAfter...` partout où ça a du sens.
|
|
- Factories pour permettre les sous-classes.
|
|
|
|
## Workflow attendu
|
|
|
|
1. Lire le contexte pertinent dans `docs/`.
|
|
2. Discuter / valider l'approche avec l'utilisateur si nécessaire.
|
|
3. Mettre à jour `docs/` (et le `.puml` concerné) avec la décision ou la spec.
|
|
4. 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**.
|
|
- JavaDoc en français sur les classes publiques et les méthodes non triviales.
|
|
- Séparation stricte : `interface`, `enum`, `abstract class`, `class` concrète,
|
|
`exception` — chacun dans son fichier.
|