- 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.
Remplace la copie des 3 fichiers listés avec continuation de ligne par un motif
.kiro/specs/schotziad-km-tracker/*.md. Forme plus robuste avec le classic builder
ET BuildKit (docker compose v2), qui n'embarque que les Markdown (pas .config.kiro
ni tasks.meta.json). Comportement de l'image inchangé : les 3 documents restent
copiés dans /app/specs.
Le bundle initial dépasse le seuil par défaut (500kb) à cause des dépendances
applicatives (Leaflet, etc.), sans lien avec une régression. On relève le budget
initial à 1mb (warning) / 2mb (error) et le budget de style de composant à 4kb /
8kb pour supprimer les avertissements de build non pertinents.
Aucun impact fonctionnel.
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.
Le tooltip Leaflet avec un simple max-width se réduisait à quelques caractères
de large (nombreuses lignes illisibles). On lui donne une largeur franche de
220px et on retire word-break (qui coupait au milieu des mots), en gardant
overflow-wrap pour les mots trop longs. Le texte se répartit désormais
normalement sans déborder de la carte.
Build prod OK.
Leaflet applique par défaut white-space: nowrap aux tooltips, ce qui forçait
l'infobulle de survol sur une seule ligne et la faisait déborder hors de la
carte (illisible). On borne désormais .leaflet-tooltip en largeur (240px) et on
autorise le retour à la ligne, à l'identique des popups (clic).
Build prod OK.
- Backend : TrajetCarteDto expose désormais le commentaire du trajet ; la
projection de GET /api/trajets/journee/{date} le renseigne.
- Frontend : l'interface TrajetCarte porte le commentaire. L'infobulle affiche
le commentaire en première ligne (s'il existe, séparé par un léger trait) et
ajoute « (A/R) » après la distance pour un aller/retour.
- Style .carte-infobulle__commentaire (italique, discret) dans les styles
globaux.
Builds backend, frontend dev et prod OK.
Le mois et l'année sélectionnés (ex. « Septembre 2026 ») sont affichés à droite
du libellé « 📅 Choisir un mois », séparés par un léger trait. Vide tant qu'aucun
mois n'est choisi. Permet de connaître la période courante sans déplier le
sélecteur.
Build prod OK.
Un mois sans trajet est un cas normal, pas une erreur :
- Panneau totaux : plus d'alerte « Impossible de charger les totaux ». Un
jour/mois sans trajet affiche simplement des totaux à 0,00 km. Signal erreur
supprimé.
- Consultation : plus d'alerte « Impossible de charger les trajets du mois ».
Signal erreur et variable resumeEnErreur supprimés ; un échec de résumé
affiche une liste vide (les vraies indisponibilités serveur restent signalées
par l'intercepteur global).
- Message vide unique : « Aucun trajet pour ce mois » n'est plus affiché en
double (retiré de la liste, conservé côté consultation avec garde de
chargement).
Builds dev et prod OK.
Les totaux affichés sont relatifs au jour ciblé sur la carte. La bande
« ‹ Jour préc. / date / Jour suiv. › » est déplacée juste sous le sélecteur de
mois, au-dessus du panneau des totaux, afin que la date pilote visuellement les
totaux et la carte qui suivent.
Build prod OK.
Les boutons « Jour préc. » / « Jour suiv. » de la carte ne s'arrêtent plus sur
tous les jours du mois mais uniquement sur les jours comportant des trajets.
Exception : dans le mois en cours, le jour courant reste navigable même sans
trajet (pour pouvoir y ajouter un trajet).
- joursNavigables() : jours du mois avec trajets (+ aujourd'hui si mois courant),
triés. La date affichée n'a pas besoin d'en faire partie.
- jourNavigableAdjacent() : jour navigable strictement avant/après la date
affichée ; boutons désactivés s'il n'y en a pas.
- À la sélection d'un mois passé, la carte se recale sur le dernier jour ayant
des trajets si le jour par défaut tombe sur une journée vide.
Builds dev et prod OK.
- Sélecteur temporel : libellé « 📅 Choisir une date » → « 📅 Choisir un mois ».
- Liste mensuelle : chaque journée est désormais repliable (en-tête cliquable
avec chevron, date et nombre de trajets). Par défaut toutes les journées sont
repliées ; au changement de mois, seule la dernière journée comportant des
trajets est dépliée. Les mises à jour au sein du même mois (ajout, suppression,
réordonnancement) conservent l'état d'ouverture courant.
- La date, désormais portée par l'en-tête du groupe, est retirée de chaque ligne
de trajet (suppression du doublon) ; le commentaire occupe seul sa ligne.
Builds dev et prod OK.
Refonte de la navigation temporelle suite au retour d'usage :
- Sélecteur temporel limité à année/mois (suppression du segment jour).
Nouvel Output moisSelectionne: {annee, mois} en remplacement de
dateSelectionnee (jour ISO). Surbrillance des mois avec données conservée.
- Consultation : deux états distincts. Le signal mois pilote le chargement
de la liste (tous les trajets du mois, triés par date), le signal date
pilote la carte (trajets du jour) et la date par défaut à l'ajout/insertion.
Bande « ‹ Jour préc. / date / Jour suiv. › » au-dessus de la carte, bornée
au mois sélectionné. La navigation jour ne recharge que la carte.
- Liste : trajets du mois groupés par journée (en-tête de date). Un
cdkDropList indépendant par jour (listes non connectées) : le
réordonnancement par glisser-déposer est limité à chaque journée, avec
recalcul des positions internes et rétablissement en cas d'échec.
Builds dev et prod OK. Backend inchangé (API résumé mensuel/réordonner
déjà en place).
La page d'inscription n'est atteinte que lorsqu'aucun compte n'existe (application
mono-utilisateur) : le lien vers la connexion n'a pas de sens. Import RouterLink
devenu inutile retiré du composant.
Corrige un contournement : après réinitialisation de la base (même JWT_SECRET_KEY),
un jeton restait cryptographiquement valide et donnait accès alors que le compte
n'existait plus, permettant d'atteindre l'onboarding sans s'inscrire.
- Backend : JwtBearer.OnTokenValidated vérifie désormais l'existence du compte
référencé par le claim sub (lu sous 'sub' ou NameIdentifier selon le remapping)
et rejette le jeton (401) si le compte est introuvable.
- Backend : nouvel endpoint protégé GET /api/auth/moi (SessionController) renvoyant
200 si la session est réellement valide, 401 sinon.
- Frontend : authGuard valide la session côté serveur (GET /auth/moi) au lieu de se
fier au seul jeton local ; sur échec, redirection vers /login (jeton purgé par
l'intercepteur sur 401). AuthService.validerSession() ajouté.
Tests backend : 54/54 au vert.
- Onboarding : redirection automatique vers /register lorsqu'aucun compte n'existe
(première utilisation), au lieu d'afficher la page de connexion.
- Carte Leaflet en production : import normalisé (Leaflet est CommonJS, l'API pouvait
se retrouver sous .default en build prod -> échec d'initialisation). Nettoyage du
marqueur _leaflet_id du conteneur pour que « Réessayer » fonctionne après un échec.
Logs d'erreur explicites en cas d'échec d'import/init.
- Mise en page : layout applicatif en flex pleine hauteur (nav de hauteur naturelle,
<main> occupe le reste et défile si besoin) sans étirer les vues courtes. La vue
Trajets occupe l'espace restant (height:100%) sans scrollbar de page : seule la
liste défile. Reset global (body margin 0, box-sizing border-box) supprimant la
scrollbar de page parasite.
- Centrage uniforme des pages : ajout de margin:0 auto aux vues profil, véhicules,
barème, résumé mensuel/annuel et montants réglés (comme trajets et carnet).
Builds backend (solution) et frontend (production) OK.
Évite d'embarquer les artefacts .NET (~220 Mo) et les bases SQLite locales dans le
contexte de build de l'image backend. Build de l'image API validé sans le projet de tests.
Évite un conflit avec une instance existante sur 8080. Seul le port HÔTE change
(2202:80) ; les ports internes des conteneurs (backend 8080) sont inchangés, donc
le proxy interne nginx -> backend n'est pas affecté. Auth__FrontendBaseUrl par défaut
et Caddyfile.example alignés sur 2202.
Configuration reverse_proxy vers l'IP de la machine Docker (port 8080 publié par le
compose), en-têtes X-Forwarded-*, sonde /health, et recommandations de sécurité
(restreindre le port 8080 à l'IP de Caddy / réseau privé) pour éviter un accès HTTP
direct contournant le TLS.
- Retire app.UseHttpsRedirection() : le conteneur écoute en HTTP, la terminaison
TLS est assurée par le reverse-proxy (Caddy) placé devant. Évite les redirections
parasites derrière le proxy.
- Ajoute Caddyfile.example (Caddy devant le compose existant : TLS auto + reverse_proxy
vers le frontend nginx qui sert l'app et proxifie /api).
- .env.example : précise AUTH_FRONTEND_BASE_URL = URL publique HTTPS en production
(liens de réinitialisation de mot de passe).
- Totaux : rafraîchissement immédiat du panneau (jour/mois/année + montant
prévisionnel) après création/modification/suppression/réordonnancement d'un
trajet, sans changer de jour (ViewChild + méthode publique rafraichir()).
- Trajets Aller/Retour : case à cocher au formulaire ; la distance comptée est
doublée (distance simple stockée + booléen AllerRetour, distance effective
utilisée dans tous les agrégats : totaux, résumés, barème, régularisation, PDF).
Migration TrajetAllerRetour. Badge « A/R » dans une colonne dédiée en début de
ligne pour garder date/adresses alignées.
- Mise en page de la page Trajets : vue à hauteur fixe où seule la liste défile ;
colonne gauche figée (sélecteur de date + navigation, totaux, carte) et bande
fixe (véhicule + bouton d'ajout) au-dessus de la liste. Layout applicatif global
en pleine hauteur (app.component).
- run-dev.sh : chargement de la clé JWT depuis .env (ou secret de dev aléatoire) et
Auth__FrontendBaseUrl sur le frontend dev ; rappel du lien de reset journalisé.
Build backend (solution) et frontend (production) OK.