# Mission : adapter le fichier `agents.md` aux règles de développement du projet

Tu es un agent de développement logiciel spécialisé en C++ et SDL3.

Ta mission consiste à **analyser puis modifier le fichier `agents.md` du projet** afin d'y intégrer les conventions de programmation et les contraintes pédagogiques définies ci-dessous.

Ces instructions devront être appliquées systématiquement lors de toute création, modification, correction ou refactorisation de code dans ce projet.

## 1. Instructions générales

1. Recherche et lis le fichier `agents.md` existant à la racine du projet (ou son équivalent `AGENTS.md`).
2. Conserve toutes les instructions existantes qui ne contredisent pas les nouvelles règles.
3. Ajoute ou adapte les sections nécessaires pour intégrer l'ensemble des contraintes détaillées ci-dessous.
4. Organise les règles de manière claire, structurée et sans ambiguïté afin qu'elles puissent être correctement interprétées par un agent de programmation.
5. En cas de contradiction, les règles définies dans ce prompt sont prioritaires.
6. Ne modifie aucun fichier source du projet dans le cadre de cette mission : seule la documentation d'instructions destinée aux agents doit être adaptée.

## 2. Gestion de la mémoire et des pointeurs

- Interdire l'utilisation des pointeurs bruts (`T*`) dans le code applicatif, sauf lorsqu'ils sont strictement imposés par une API externe, notamment SDL3.
- Interdire explicitement l'utilisation de `new`, `delete`, `malloc` et `free`.
- Privilégier le stockage et la gestion automatique de la mémoire à l'aide des conteneurs de la bibliothèque standard C++ :
  - `std::vector`
  - `std::array`
  - `std::map`
- Privilégier les objets à durée de vie automatique et la gestion des ressources par RAII.
- Lorsque l'utilisation de pointeurs est indispensable, notamment pour le polymorphisme par héritage, utiliser des pointeurs intelligents :
  - `std::unique_ptr` par défaut.
  - `std::shared_ptr` uniquement lorsqu'un partage de propriété est réellement nécessaire.
- Ne jamais introduire de gestion manuelle de la mémoire lorsqu'une solution simple reposant sur la STL ou sur des objets automatiques est possible.
- Les pointeurs imposés par SDL3 peuvent être utilisés aux frontières de l'API, sans généraliser leur usage au reste du projet.

## 3. Respect du programme pédagogique C++

Le code produit doit impérativement rester dans le périmètre des notions enseignées dans le cours :

- Structures (`struct`) et classes (`class`).
- Templates simples.
- Conteneurs et algorithmes de la STL.
- Smart pointers.
- Héritage et polymorphisme.
- Foncteurs.
- Expressions lambda.

Éviter les fonctionnalités avancées, obscures ou inutilement complexes du C++.

En particulier :

- Ne pas introduire de métaprogrammation complexe.
- Éviter les concepts et techniques avancées qui ne sont pas nécessaires au projet.
- Ne pas utiliser de patterns de conception complexes lorsqu'une approche orientée objet classique suffit.
- Préférer une implémentation simple, lisible, explicite et pédagogique à une solution techniquement sophistiquée.

**Objectif : produire du C++ compréhensible par un étudiant maîtrisant uniquement le programme du cours.**

## 4. Programmation orientée objet et encapsulation

- Privilégier la programmation orientée objet pour organiser le projet.
- Regrouper les données et les comportements associés dans des classes cohérentes.
- Respecter systématiquement le principe d'encapsulation.
- Utiliser explicitement les niveaux d'accès `private` et `public`.
- Déclarer les attributs d'une classe en `private` par défaut.
- Exposer uniquement les méthodes nécessaires à son utilisation.
- Ajouter des getters et setters lorsque l'accès ou la modification contrôlée d'un attribut le justifie.
- Éviter de créer automatiquement un getter et un setter pour chaque attribut si cela n'apporte aucun intérêt.
- Utiliser l'héritage et le polymorphisme lorsqu'ils permettent de représenter naturellement les relations entre les objets, sans complexifier artificiellement l'architecture.

## 5. Organisation des fichiers

- Respecter la règle : **une seule classe ou structure principale par fichier**.
- Pour une classe, privilégier la séparation entre déclaration (`.h` ou `.hpp`) et implémentation (`.cpp`).
- Conserver une organisation cohérente des fichiers et des noms.
- Éviter de regrouper plusieurs classes indépendantes dans un même fichier.
- Les déclarations auxiliaires strictement liées à une classe peuvent rester dans son fichier si elles ne constituent pas des entités indépendantes.

## 6. Calculs géométriques en 2D

- Utiliser systématiquement la classe `V2` déjà présente dans le projet pour les calculs géométriques en deux dimensions.
- Réutiliser ses méthodes et opérateurs existants.
- Ne pas recréer de classe de vecteur 2D concurrente.
- Éviter de dupliquer les opérations géométriques déjà prises en charge par `V2`.
- Consulter l'interface de `V2` avant d'implémenter de nouveaux calculs géométriques.

## 7. Const-correctness et passage des paramètres

- Qualifier les méthodes membres avec `const` lorsqu'elles ne modifient pas l'état de l'objet.
- Privilégier les références constantes (`const T&`) pour transmettre les objets qui n'ont pas besoin d'être modifiés.
- Utiliser une référence non constante uniquement lorsqu'une modification de l'argument est intentionnelle.
- Pour les types simples et peu coûteux à copier (`int`, `float`, `bool`, etc.), privilégier le passage par valeur.
- Ne pas ajouter de qualifications `const` artificielles ou inutiles.

## 8. Conventions de nommage

Respecter la convention **camelCase** pour les identifiants du code :

- Variables : `playerPosition`, `windowWidth`.
- Attributs : `movementSpeed`, `currentHealth`.
- Fonctions et méthodes : `updatePosition()`, `renderScene()`.
- Paramètres : `deltaTime`, `targetPosition`.

Pour les classes et structures, conserver la convention existante du projet, en privilégiant `PascalCase` si aucune convention n'est définie.

Ne pas renommer les symboles imposés par des bibliothèques externes, notamment SDL3, ni les éléments existants sans nécessité.

## 9. Commentaires des fonctions

- Ajouter systématiquement un commentaire immédiatement au-dessus de chaque nouvelle fonction ou méthode.
- Ce commentaire doit expliquer brièvement le rôle et le fonctionnement de la fonction.
- Privilégier des commentaires simples, pédagogiques et utiles.
- Ne pas paraphraser inutilement le nom de la fonction.
- Pour les fonctions existantes modifiées de manière importante, actualiser leurs commentaires si nécessaire.
- Lorsqu'une méthode est déclarée dans un fichier d'en-tête et définie dans un `.cpp`, placer le commentaire au-dessus de sa déclaration, sauf convention contraire existante.

Exemple :

```cpp
// Met à jour la position du joueur selon sa vitesse et le temps écoulé.
void updatePosition(float deltaTime);
```

## 10. Gestion des erreurs et exceptions

Afin de conserver un code simple et conforme aux attentes pédagogiques du projet :

- Ne pas mettre en place de gestion des exceptions C++.
- Ne pas introduire de blocs `try`, `catch` ou d'instructions `throw`.
- Ne pas ajouter de mécanismes de propagation ou de traitement des erreurs.
- Ne pas vérifier ni traiter systématiquement les codes de retour des fonctions lorsque ceux-ci servent uniquement à signaler un échec.
- Ne pas ajouter de couches d'abstraction dédiées à la gestion des erreurs.
- Préserver les vérifications indispensables à la logique métier ou à la prévention d'un comportement indéfini ; elles ne constituent pas une gestion d'erreur à supprimer.

Ces règles s'appliquent au code écrit ou modifié par l'agent. Ne pas supprimer sans nécessité les mécanismes déjà présents dans les parties du projet qui ne sont pas concernées.

## 11. Règles spécifiques à SDL3

- Ne pas vérifier ni traiter les valeurs de retour des fonctions SDL3 lorsqu'elles indiquent uniquement le succès ou l'échec d'une opération.
- Ne pas ajouter de messages d'erreur, de logs ou de branchements conditionnels destinés à gérer ces échecs.
- Utiliser SDL3 de manière directe, avec un code aussi léger et lisible que possible.
- Respecter les contraintes d'interface de SDL3 lorsque la bibliothèque nécessite des pointeurs bruts ou des handles.
- Ne pas confondre l'absence de gestion des erreurs SDL3 avec la gestion normale des événements, des entrées utilisateur et du cycle de vie des objets.
- Conserver les appels nécessaires à la libération des ressources SDL3, par exemple les fonctions `SDL_Destroy...`, lorsque ces ressources ont été créées et doivent être libérées.

## 12. Priorités de développement

Lors de chaque intervention sur le projet, appliquer les priorités suivantes :

1. Respecter les exigences fonctionnelles demandées.
2. Respecter les contraintes pédagogiques et les règles de programmation ci-dessus.
3. Réutiliser les classes, structures et fonctionnalités déjà présentes dans le projet.
4. Privilégier la simplicité et la lisibilité du code.
5. Préserver une architecture orientée objet cohérente.
6. Éviter toute complexité supplémentaire non justifiée.

Ne pas introduire de dépendances, d'abstractions ou de fonctionnalités non demandées.

## 13. Vérification systématique avant de terminer une modification

Avant de considérer une tâche de programmation comme terminée, vérifier que :

- Aucun `new`, `delete`, `malloc` ou `free` n'a été introduit.
- Aucun pointeur brut non justifié n'a été ajouté.
- Les smart pointers sont employés lorsque cela est nécessaire.
- Les conteneurs STL sont privilégiés.
- Le code reste dans le périmètre du programme du cours.
- Les principes de programmation orientée objet et d'encapsulation sont respectés.
- Une classe ou structure principale au maximum est définie par fichier.
- La classe `V2` est réutilisée pour les calculs géométriques 2D.
- Les qualifications `const` et références constantes sont utilisées à bon escient.
- Les noms respectent les conventions du projet.
- Chaque nouvelle fonction possède un commentaire explicatif.
- Aucun mécanisme de gestion des exceptions ou des erreurs n'a été ajouté.
- Aucun traitement des codes de retour SDL3 signalant un échec n'a été introduit.

## 14. Résultat attendu pour cette mission

Après avoir adapté le fichier `agents.md` :

1. Vérifie que toutes les règles précédentes y figurent clairement.
2. Vérifie qu'aucune instruction contradictoire ne subsiste.
3. Évite les répétitions et conserve une structure facile à consulter.
4. Présente un bref résumé des modifications effectuées.
5. Signale les éventuelles contradictions préexistantes que tu as dû résoudre.

**Important : tu dois réellement modifier le fichier d'instructions du dépôt, et non simplement proposer son nouveau contenu dans ta réponse.**

Ces conventions sont des contraintes permanentes du projet. Elles doivent être appliquées lors de toutes les interventions futures de l'agent.