# Règles complémentaires — Mise à jour des fichiers & format des réponses

Ce fichier définit **le contrat de travail** entre toi (l’utilisateur) et moi (l’assistant)
pour tout ce qui touche à :

- la doc du projet (.md),
- le code en général,
- les modifications multi-fichiers.

---

## 1) Règle n°1 — Format par défaut : REPLACE FILE (IMPORTANT)

Par défaut, **quand tu demandes du code, une modif, une amélioration ou une mise à jour** :

✅ Je fournis une **version COMPLETE** du fichier / snippet / module visé, prêt à être copié/collé.

Objectifs :

- lisibilité maximale
- aucune ambiguïté
- pas de “reconstruction mentale”
- facile à versionner (git)

---

## 2) Règle n°2 — Un fichier = une fenêtre de code

Si plusieurs fichiers sont concernés :

✅ Je fournis **UNE fenêtre de code par fichier**, séparée clairement, avec le nom du fichier.
❌ Je ne mélange jamais plusieurs fichiers dans un seul bloc.
❌ Je ne fais pas de patch multi-fichiers “cahotique”.

---

## 3) Exception — Diff/Patch (uniquement sur demande explicite)

Les diffs / patchs / refactors incrémentaux sont **interdits par défaut**.

Je ne fournis un diff que si tu écris explicitement :

- “donne-moi un diff”
- “patch minimal”
- “avant/après”
- “lignes numérotées”

Sinon : REPLACE FILE.

---

## 4) Signal standard quand une mise à jour de doc est pertinente

Quand je repère qu’il serait utile de documenter quelque chose :

🚨 FILE_UPDATE_PROPOSAL

Format obligatoire :

🚨 FILE_UPDATE_PROPOSAL  
Fichier : `<chemin/nom_du_fichier>`  
Action : `REPLACE FILE` | `ADD SECTION` (si tu le demandes) | `DIFF` (si tu le demandes)

### Pourquoi (1–2 phrases max)

### Ce que je propose

- Résumé très court

Ensuite, je fournis le fichier complet (REPLACE FILE).

---

## 5) Validation

À la fin d’une proposition de remplacement de fichier, je conclus par :

> “Tu confirmes que je remplace `<nom_du_fichier>` par cette version ?”

---

## 6) Nomenclature globale des fichiers (conventions)

### Dates

- Format : `DD-MM-YYYY`
- Champ recommandé : `Dernière mise à jour : DD-MM-YYYY`
- “Validé le” = date de validation réelle, pas estimation.

### Version n8n (si pertinent)

Quand un point concerne n8n :

- préciser la version observée : ex `n8n 1.121.2`
- préciser le contexte : self-hosted / docker

### Style

- titres courts, scannables
- listes à puces
- peu de prose
- l’objectif est l’utilité, pas la beauté