# 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.