# 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

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.
- Séparation stricte : `interface`, `enum`, `abstract class`, `class` concrète,
  `exception` — chacun dans son fichier.