# 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.