Refonte de l'interaction carte/liste suite au retour d'usage :
- Suppression de la bande de navigation « Jour préc. / date / Jour suiv. »
(boutons, code et styles associés retirés).
- La journée affichée sur la carte suit le SURVOL des trajets : survoler un
trajet bascule la carte sur sa journée (Subject debouncé ~80 ms) et met le
tracé en évidence ; en fin de survol, la carte reste sur la dernière journée
survolée. Au chargement d'un mois, la carte se cale sur la dernière journée
ayant des trajets.
- Bouton « Ouvrir toutes les journées » (avant « Ajouter un trajet » pour ne pas
décaler ce dernier ; affiché seulement s'il reste des journées repliées).
- Surbrillance du groupe de la journée affichée sur la carte (en-tête bleu
accentué), pilotée par le nouvel Input jourAffiche de la liste.
- Harmonisation : les mois « avec données » du sélecteur passent au même bleu
que la journée mise en avant (le mois sélectionné reste en bleu plein).
- Date par défaut à la création : date de la carte, sinon date du jour (inchangé).
Specs : requirements.md (exigence 12, glossaire Sélecteur_Temporel) et design.md
(ConsultationJour, TrajetList, SelecteurTemporel) mis à jour.
Améliorations de saisie issues du retour d'usage :
- Insertion : la date pré-remplie est celle de la JOURNÉE du trajet source (via
prefill.date), et non la date de la carte, pour éviter les erreurs de saisie.
- Insertion « après » / « avant le suivant » : l'adresse de départ pré-remplie
est le point de FIN du trajet source — son arrivée, ou son DÉPART si c'est un
aller/retour (le véhicule est revenu à son point d'origine).
- Après création/modification sur une autre journée : repositionnement auto sur
le mois du trajet, cadrage de la carte sur sa date, et dépliage du groupe de
cette journée (TrajetListComponent.ouvrirJour, différé après recalcul du
repliage) pour rendre le trajet ajouté visible.
- Bouton « Utiliser mon domicile » sur l'arrivée : pré-remplit le commentaire
avec « Retour domicile » si le commentaire est vide (jamais de remplacement).
Specs : requirements.md (exigences 10.19, 11.1/11.2/11.12, 12.23) et design.md
(TrajetForm, TrajetList, ConsultationJour) mis à jour.
Remplace le volume nommé Docker (trajets-data) par un bind mount ./data:/data,
afin d'accéder au fichier de base sans entrer dans le conteneur (inspection,
sauvegarde).
- docker-compose.yml : volumes backend -> ./data:/data ; déclaration du volume
nommé retirée.
- .gitignore / .dockerignore : exclusion du dossier data/ (base jamais versionnée
ni envoyée au contexte de build).
- design.md : références bind mount + nouvelle section « Accès à la base de
données » (inspection, sauvegarde à froid, migration depuis l'ancien volume).
- run-docker.sh supprimé : script obsolète (ancienne archi, contexte de build et
port périmés) et redondant avec docker compose v2 désormais disponible.
Déploiement validé : docker compose up -d --build fonctionne, base montée depuis
l'hôte.
Nouvelle fonctionnalité : consulter les documents de spécification (exigences,
conception technique, plan de tâches) en lecture seule dans le frontend.
Backend :
- SpecsController (GET /api/specs, GET /api/specs/{cle}) protégé par l'auth
globale ; SpecDocumentService avec whitelist (pas de path traversal) et
lecture depuis le dossier specs/ embarqué, repli sur .kiro/specs en dev.
- DTOs SpecDocumentDto / SpecContenuDto ; service enregistré dans Program.cs.
Docker :
- Contexte de build backend = racine du dépôt (dockerfile: backend/Dockerfile)
pour embarquer .kiro/specs/*.md dans l'image (app autonome).
- .dockerignore racine ajouté (exclut frontend/node_modules, bin/obj, etc.).
Frontend :
- SpecService + SpecsComponent (lazy-loadé) : page dédiée avec menu latéral par
document ; rendu Markdown via marked (GFM) assaini par DOMPurify.
- Diagrammes Mermaid (ex. graph TB) rendus en SVG via mermaid.js importé
dynamiquement ; déclenchement après résolution du @ViewChild (setTimeout).
- Barre de navigation : simple lien « Specs » (le choix du document se fait dans
le menu latéral de la page, pas dans la barre).
- Routes /specs et /specs/:cle protégées par authGuard.
Specs : exigence 19 (consultation des documents) ajoutée à requirements.md ;
design.md complété (DTOs, endpoints, composant, rendu Mermaid, note Docker).
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.
MadJax