## Approach

- Read existing files before writing. Don't re-read unless changed.
- Thorough in reasoning, concise in output.
- Skip files over 100KB unless required.
- No sycophantic openers or closing fluff.
- No emojis or em-dashes.
- Do not guess APIs, versions, flags, commit SHAs, or package names. Verify by reading code or docs before asserting.

# Instructions projet

## Méthode de travail

1. **Comprendre avant de modifier**
   Ne pas commencer à coder tant que le besoin n'est pas clair. Si la demande est ambiguë,
   incomplète ou laisse plusieurs interprétations possibles, poser des questions avant
   de toucher au code.

2. **Qualifier le besoin avant de coder**
   Reformuler/résumer ce qui va être fait (périmètre, fichiers concernés, impacts) avant
   d'implémenter, surtout si le changement touche plusieurs fichiers ou une logique
   existante.

3. **Respecter les conventions Laravel, ne pas réinventer**
   S'appuyer sur les mécanismes natifs de Laravel plutôt que sur du code maison.
    - **Controllers légers** : pas de logique métier dans les contrôleurs. Ils
      orchestrent (récupérer la requête, appeler une Action/le modèle, retourner
      la réponse).
    - **Actions** : la logique métier (création, mise à jour, traitements complexes)
      passe par des classes Action dédiées.
    - **Modèles** : un maximum de logique liée aux données (scopes, accessors,
      relations, règles métier propres à l'entité) vit dans les modèles.
    - **Form Requests** : toute validation passe par des Form Requests dédiées,
      pas de `$request->validate()` inline dans les contrôleurs sauf cas trivial.

    Ces règles s'appliquent au nouveau code et aux modifications significatives —
    ce n'est pas une obligation de refactorer l'existant à chaque édition.

4. **Livewire plutôt qu'Alpine.js quand c'est pertinent**
   Pour toute interactivité non triviale (formulaires dynamiques, recherche,
   mise à jour de données liées au backend...), privilégier un composant Livewire.
   Alpine.js reste réservé aux comportements purement UI côté client (toggle,
   dropdown, navigation de graphique...) qui ne nécessitent pas d'aller-retour
   serveur. Si une demande se prête mieux à Livewire qu'à la solution Alpine/JS
   envisagée, le proposer avant de coder.

5. **Conventions UI**
    - Boutons de fermeture des modals : icône KI (`ki-outline`/`ki-filled`), pas de SVG.
    - Boutons d'action (édition, suppression, etc.) : classes
      `kt-btn kt-btn-sm kt-btn-icon kt-btn-outline`.
    - Accordéons : `<details>`/`<summary>` HTML natif, pas Alpine.js ni le
      collapse de ktui.

6. **Un commit par feature, avec un message clair**
   Chaque développement a un début et une fin identifiables. À la fin d'une tâche,
   proposer un commit avec un message préfixé selon sa nature :
    - `FEAT:` nouvelle fonctionnalité
    - `FIX:` correction de bug
    - `REFACTOR:` changement de structure sans changement de comportement
    - `CHORE:` tâches techniques (config, dépendances, CI...)
    - `DOCS:` documentation

    Ne créer un commit que si l'utilisateur le demande explicitement.