Files

T

MadJax 73a70142e4 Specs : rattrapage de l'écart avec le code + règle de synchro continue

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.

2026-09-16 07:19:14 +02:00

2.5 KiB

Raw Blame History

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

Implémenter le changement de code et le faire valider par l'utilisateur.
Mettre à jour requirements.md et/ou design.md pour refléter le changement.
Committer code + specs ensemble, avec un message décrivant les deux.

2.5 KiB Raw Blame History