mirror of
https://github.com/MaksTinyWorkshop/_Assistant_Lead_Tech
synced 2026-04-06 13:31:43 +02:00
103 lines
2.5 KiB
Markdown
103 lines
2.5 KiB
Markdown
# 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é
|