66 lines
3 KiB
Markdown
66 lines
3 KiB
Markdown
# Agent Instructions
|
|
|
|
Cette zone contient l'application React + Vite et les assets publics.
|
|
|
|
## Références
|
|
|
|
Avant de modifier un outil toolbox, le stockage IndexedDB, l'import/export ou les formats de données, lire :
|
|
|
|
- `../docs/STORAGE_SCHEMA.md`
|
|
- `../docs/FEATURE_CHECKLIST.md`
|
|
|
|
Avant de modifier le style, les composants UI, les layouts, les boutons, cards, panels, hovers, scrollbars ou notifications, lire :
|
|
|
|
- `../DESIGN_SYSTEM.md`
|
|
|
|
Après ce type de modification, mettre à jour ces documents si le format, le workflow ou le pattern visuel change.
|
|
|
|
## Contenu éditable
|
|
|
|
Le contenu éditorial du site doit rester dans :
|
|
|
|
- `public/data/site.json`
|
|
- `public/data/<gameId>/...`
|
|
|
|
`site.json` est la source de vérité. `npm run check` doit échouer si le contenu requis est invalide.
|
|
|
|
## En-têtes de fichiers
|
|
|
|
Chaque nouveau fichier source ou test doit commencer par un commentaire court `Rôle : ...` décrivant ce qu'il gère.
|
|
|
|
- Mettre cet en-tête à jour si la responsabilité du fichier change.
|
|
- Garder l'intro concise, une à trois lignes maximum selon la complexité du fichier.
|
|
- Enrichir l'en-tête seulement quand le fichier porte une logique transverse, un hook partagé, un format de données ou un comportement réutilisable.
|
|
- Utiliser `// Rôle : ...` dans les fichiers JS, JSX, MJS et SCSS.
|
|
|
|
## Serveur de développement
|
|
|
|
Si le port `5173` est déjà occupé, considérer qu'un `npm run dev` est probablement déjà en cours. Ne pas lancer automatiquement un nouveau serveur sur `5174`.
|
|
|
|
Quand une vérification navigateur est nécessaire, utiliser l'instance déjà ouverte sur `http://localhost:5173` si elle répond.
|
|
|
|
## Validation
|
|
|
|
Avant de terminer une modification significative, lancer :
|
|
|
|
```bash
|
|
npm run check
|
|
```
|
|
|
|
Le check couvre la génération des index de listes, les tests et le build de production.
|
|
|
|
## Pré-push check
|
|
|
|
Quand l'utilisateur indique qu'il va push, par exemple "je vais push", "je push", "go push" ou "prêt à push", traiter le message comme une demande implicite de pré-push check. Ne pas attendre de précision supplémentaire et ne pas exécuter `git commit`, `git push` ou `git sync` sauf demande explicite. Faire une passe globale avant de conclure :
|
|
|
|
- code mort, imports inutilisés, fonctions inutilisées, styles obsolètes ;
|
|
- duplication de code ou de style pouvant être factorisée sans complexifier ;
|
|
- cohérence entre boutons, badges, cards, panels, hovers, focus states et scrollbars ;
|
|
- cohérence entre `public/data/site.json`, les validations et les textes utilisés ;
|
|
- cohérence entre `../docs/STORAGE_SCHEMA.md` et les normalisations IndexedDB réelles ;
|
|
- import/export des toolboxes quand la structure de données a changé ;
|
|
- champs inutiles persistés dans IndexedDB ou dans les exports ;
|
|
- fichiers générés attendus, notamment les index de listes ;
|
|
- optimisations simples de performance : recalculs au render, listeners non nettoyés, observers, effets CSS lourds appliqués en masse.
|
|
|
|
Après lecture du diff pré-push, proposer un message de commit anglais, concis et représentatif.
|