- Login : case à cocher « Se souvenir de moi » sous le champ email ;
mémorisation de l'identifiant (email uniquement) dans le localStorage
du navigateur, pré-remplissage à la visite suivante sur le même
navigateur, effacement si décochée ; erreurs de stockage ignorées
- Panneau Totaux : « Total du mois » en gras et « Total annuel partiel »
non gras ; « Remboursement indicatif » renommé « Remboursement
indicatif pour ce mois » ; « Montant prévisionnel annuel » non gras
- Steering : nouvelle règle imposant les réponses en français
- Mise à jour requirements.md (Req 17 + glossaire), design-requirements.md
(Req 17 technique) et design.md (LoginComponent, PanneauTotaux)
Clarifie l'architecture documentaire réelle du projet (deux axes) :
- axe exigences : requirements.md (métier) + design-requirements.md
(technique, en miroir numéroté)
- axe conception : design.md
- journal : tasks.md
Ajoute les règles de routage des mises à jour et une note sur les
specs séparées (ex. precision-distances-km) et leurs renvois croisés.
- Export PDF: nouveau nommage AAAAMM/AAAA_Trajets_MATRICULE_PLAQUE.pdf,
logo carré embarqué en en-tête, km formatés selon Precision_Distance,
restructuration en-têtes (Domicile déplacé, période/année fusionnées
au titre)
- Correction bug: le nom de fichier suggéré au téléchargement ne
remontait pas au frontend (CORS WithExposedHeaders manquant +
composants résumé ne lisaient pas Content-Disposition)
- Résumé mensuel: colonne Commentaire, sélecteur temporel unifié
(auto-chargement), km selon précision
- Résumé annuel: bouton Export PDF repositionné, km selon précision
- Panneau totaux: renommage "Remboursement indicatif" + infobulles
d'aide (icône) au lieu du texte permanent
- Ajout de PdfServiceIntegrationTests (3 tests), 65/65 tests backend OK
- Mise à jour requirements.md et design.md en conséquence
- Nouveau parametre global Precision_Distance (sous-menu Application de la
Page_Parametrage, entre Compte et Vehicules), persiste via une entite
singleton ParametresApplication, expose par GET/PUT /api/parametres-application
- Arrondi superieur (ceiling) applique a l'affichage et aux agregats : trajet
simple, aller/retour (arrondi puis doublement), totaux jour/mois/annee,
carte, export PDF et bareme kilometrique - jamais a la distance brute stockee
- Refonte du Montant_Previsionnel : le montant mensuel (80%) porte desormais
sur le seul mois affiche (tranche determinee par le cumul annuel) ; nouvelle
ligne Montant_Previsionnel_Annuel (100%, sans minoration, sur le cumul)
- Backend : PrecisionDistanceService (ArrondirDistance), integration dans
ResumeService/TotauxService/RemboursementService/MontantRegleService,
migration EF Core ; 7 tests de propriete (FsCheck) + tests existants, 62/62 verts
- Frontend : ParametresApplicationService (signal partage), composant de
parametrage, fonction miroir arrondirDistance, adaptation de la liste des
trajets, du panneau des totaux, de la carte et des montants regles
- Specs : nouvelle spec precision-distances-km (requirements/design/tasks) ;
mise a jour de requirements.md, design.md et design-requirements.md de
schotziad-km-tracker (Requirement 22, renvois croises, Montant_Previsionnel)
- Suppression du fichier chromium .deb suivi par erreur dans le depot
- Backend : ajout de design-requirements a la liste blanche des documents
exposes (libelle Exigences techniques) ; embarque via le Dockerfile (*.md)
- Frontend : entree Exigences techniques dans le menu deroulant Specs ;
le menu lateral de la page Specs se remplit dynamiquement
- design.md : note renvoyant vers requirements.md et design-requirements.md
- requirements.md ne conserve que le besoin fonctionnel metier
(attendu, mode operatoire, regles de gestion) porte par le PO business
- design-requirements.md rassemble les exigences techniques (API BAN/ORS,
codes HTTP, delais, JWT/securite, cache LRU, rendu carto/Mermaid, rendu
visuel modale + grille) a arbitrer conjointement PO business / PO IT
- Decoupage critere par critere, references croisees entre les deux fichiers
- Adresses affichées en grille (côte à côte puis retour à la ligne)
- Cartes de taille homogène avec contour et effet d'ombre
- Zone de contenu élargie pour accueillir plusieurs colonnes
- Design : description de la disposition en grille de CarnetAdressesComponent
- Formulaire de création/modification affiché dans une fenêtre modale
(bouton « Ajouter une adresse » + action « Modifier » d'une ligne)
- Fermeture au succès, sur « Annuler » ou clic sur l'arrière-plan
- Suggestions BAN rendues dans le flux du panneau pour éviter la troncature
- Specs : Exigence 15 (nouveau critère 17) + description CarnetAdressesComponent
Réorganisation complète de la navigation suite au retour d'usage, plus
changement de mot de passe et affichage/masquage des mots de passe saisis.
Backend :
- Nouvel endpoint POST /api/auth/change-password (ChangePasswordDto,
MotDePasseActuelInvalideException, validateur, AuthService.ChangePasswordAsync).
Exige l'ancien mot de passe, distinct de la réinitialisation par e-mail.
- Endpoint placé dans SessionController (protégé par l'autorisation globale) et
NON dans AuthController : AuthController porte [AllowAnonymous] au niveau
classe, ce qui rend inopérant un [Authorize] posé sur une seule action (bug de
sécurité détecté par test manuel — l'endpoint était accessible sans jeton —
puis corrigé par ce déplacement).
Frontend :
- Page « Compte utilisateur » (ProfilComponent renommé) : section Maintenance
extraite vers MaintenanceComponent (route /maintenance) ; nouvelle section de
changement de mot de passe (ancien + nouveau + confirmation).
- ParametrageComponent (route /parametrage) : menu latéral Compte / Véhicules /
Barème + contenu en routes enfants, réutilisant les composants existants.
Compte et Véhicules en authGuard seul ; Barème garde profilConfigureGuard.
- Barre de navigation : Véhicules et Barème retirés (rejoignent Paramétrage) ;
logo passé en format horizontal (icône + texte).
- Avatar utilisateur (initiales) à droite de la barre : sous-menu au survol
(identité, Paramétrage, Maintenance, Se déconnecter). Menu « Specs » converti
en dropdown survolable (Exigences / Conception / Tâches).
- Dropdowns : panneau collé au bouton (plus d'espace mort) pour que le survol
reste continu jusqu'au panneau — un espace créait une fermeture prématurée.
- Barre masquée sur les pages publiques (login/register/forgot/reset-password)
même avec un jeton résiduel expiré/invalide (détection via Router events, pas
seulement la présence du jeton).
- PasswordInputComponent (shared) : bouton œil afficher/masquer, ControlValueAccessor,
style aligné sur les champs texte classiques. Appliqué aux 8 champs mot de
passe de l'application (login, register, reset-password, compte utilisateur).
Specs : requirements.md (exigences 20, 21 + glossaire) et design.md (endpoints,
DTO, composants) mis à jour. 54 tests backend au vert.
Retour d'usage : avec plusieurs journées ouvertes, viser le bouton principal
d'ajout en traversant la liste faisait dériver la date ciblée (le survol pilote
la journée affichée sur la carte).
- En-tête de journée réorganisé : jour de la semaine avant la date (ex. « Lundi
15/09/2026 »), nombre de trajets à la suite, puis un bouton dédié « + » à
l'extrémité droite (infobulle « Ajouter un trajet sur cette journée »).
- Le bouton « + » ouvre la création avec la date de SA journée, indépendamment
de la date affichée sur la carte (Output ajouterSurJournee -> conteneur fixe
lun. 21 sept. 2026 12:54:31 CEST avant ouverture via ouvrirCreationSur). stopPropagation pour ne pas
déclencher le repliage/dépliage au clic.
- Style : fond bleu IAD / texte blanc par défaut, survol orange (cohérent avec
les autres boutons d'action).
- Locale française enregistrée (registerLocaleData(localeFr) + LOCALE_ID
'fr-FR' dans app.config.ts) pour l'affichage du jour de la semaine.
Specs : requirements.md (exigence 12, critères 6 et 24) et design.md
(TrajetListComponent, locale) mis à jour.
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