MadJax
73a70142e4
Aligne requirements.md et design.md sur l'état réel du code (écart accumulé depuis le 14/09 en mode dev direct). requirements.md : - Intro : compte unique authentifié (au lieu de « sans authentification ». - Glossaire : Compte, Adresse_Email, Mot_De_Passe, Session, JWT, Jeton_Reinitialisation, Aller_Retour, Distance_Effective. - Exigence 1 : case Aller/Retour. Exigence 10 : dénomination véhicule. - Exigence 12 : refonte consultation par mois (sélecteur année/mois, liste mensuelle groupée par jour repliable, nav jour bornée aux jours avec trajets). - Exigence 13 : tranches de barème multiples (dernière illimitée, coef 3 décimales) + recopie du dernier barème. - Exigence 16 : onboarding relié à l'authentification. - Nouvelles exigences 17 (Authentification) et 18 (Trajet aller/retour). design.md : - Overview + contraintes : compte authentifié, port 2202, Caddy externe HTTPS. - Déploiement : compose (port 2202, JWT_SECRET_KEY obligatoire, e-mail/MailKit, AUTH_FRONTEND_BASE_URL), reverse-proxy Caddy externe, pas de UseHttpsRedirection. - Nouvelle section « Évolutions majeures » : décisions d'architecture pour l'auth, l'onboarding 2 étapes, l'aller/retour, la consultation par mois, le barème multi-tranches, la dénomination véhicule et le recalcul ciblé des distances. Ajoute .kiro/steering/spec-sync.md : règle de mise à jour des specs dans le même commit que le code, à chaque évolution validée.
39 lines
2.5 KiB
Markdown
39 lines
2.5 KiB
Markdown
# Synchronisation des specs avec le code
|
|
|
|
## Règle
|
|
|
|
Les documents de spécification du projet — `requirements.md` (exigences fonctionnelles au format EARS) et `design.md` (conception technique) — sont la source de vérité à long terme de ce projet. Ils DOIVENT rester alignés avec le code.
|
|
|
|
À chaque évolution fonctionnelle ou technique validée par l'utilisateur (« ça fonctionne », « tu peux committer »), mettre à jour les specs concernées **dans le même commit** que le changement de code, avant de committer.
|
|
|
|
## Portée
|
|
|
|
- `requirements.md` : mettre à jour dès qu'un comportement observable change (nouvelle fonctionnalité, modification d'un critère d'acceptation, nouveau terme du glossaire, changement de portée comme l'ajout de l'authentification).
|
|
- `design.md` : mettre à jour dès qu'une décision d'architecture, un modèle de données, un endpoint d'API ou un composant important change.
|
|
- `tasks.md` : facultatif — c'est un journal d'implémentation, pas la source de vérité. Le mettre à jour seulement si l'utilisateur le demande.
|
|
|
|
## Ce qui déclenche une mise à jour de spec
|
|
|
|
- Nouvelle capacité (ex. aller/retour, authentification, consultation par mois).
|
|
- Changement de contrat d'API (nouveau champ DTO, nouvel endpoint, changement de statut HTTP).
|
|
- Nouveau modèle de données ou migration EF Core.
|
|
- Changement de règle métier (ex. tranches de barème multiples, distance effective doublée).
|
|
- Changement de portée du produit (ex. passage de mono-utilisateur sans compte à compte unique authentifié).
|
|
|
|
## Ce qui ne déclenche PAS forcément une mise à jour
|
|
|
|
- Ajustements purement cosmétiques (couleurs, espacements) sans exigence associée.
|
|
- Refactorisations internes sans effet observable et sans changement de décision d'architecture.
|
|
|
|
## Format
|
|
|
|
- `requirements.md` : conserver le format EARS (WHEN / IF / WHILE / WHERE / THE ... SHALL). Numéroter les nouvelles exigences à la suite. Ajouter au glossaire tout nouveau terme.
|
|
- `design.md` : conserver la structure existante (contraintes, décisions d'architecture, modèles, endpoints, composants). Documenter les décisions et les alternatives rejetées.
|
|
- Valider le format avec l'outil de validation de spec après édition.
|
|
|
|
## Workflow au moment du commit
|
|
|
|
1. Implémenter le changement de code et le faire valider par l'utilisateur.
|
|
2. Mettre à jour `requirements.md` et/ou `design.md` pour refléter le changement.
|
|
3. Committer code + specs ensemble, avec un message décrivant les deux.
|