Initialisation du dépôt : specs (socle plateforme, modèle de données, site vitrine) et steering
This commit is contained in:
@@ -0,0 +1,20 @@
|
||||
# Méthode de collaboration
|
||||
|
||||
## Valider l'approche avant de coder
|
||||
|
||||
Ne jamais commencer à écrire ou modifier du code applicatif tant que l'approche n'a pas été exposée et explicitement validée par l'utilisateur.
|
||||
|
||||
Pour toute évolution ou correction fonctionnelle/technique :
|
||||
|
||||
1. D'abord décrire l'orientation envisagée (structure, impacts, choix et alternatives), de façon concise.
|
||||
2. Attendre la validation explicite de l'utilisateur. Le signal convenu est le mot « code » : tant qu'il n'est pas donné, rester en discussion et ne pas éditer de fichier de code.
|
||||
3. Une fois « code » reçu, implémenter puis vérifier (build/tests).
|
||||
|
||||
## Exceptions (ne nécessitent pas le signal « code »)
|
||||
|
||||
- Les actions de configuration ou de documentation explicitement demandées par l'utilisateur (ex. ajout/mise à jour d'un fichier de steering, d'une spec, d'un README) quand la demande est sans ambiguïté.
|
||||
- Les opérations de lecture, recherche, build, test ou diagnostic qui ne modifient pas le code applicatif.
|
||||
|
||||
## Lancement de l'environnement de développement
|
||||
|
||||
C'est l'utilisateur qui lance le serveur de développement (`./run-dev.sh`). Ne pas le démarrer automatiquement ; se contenter de signaler quand un redémarrage est nécessaire (ex. changement backend).
|
||||
Reference in New Issue
Block a user