LeaveRolloverCommand::resolveCarry se fiait au closing_days stocké quand
une ligne existait pour l'exercice précédent. Or closing_days n'est jamais
recalculé après création (toujours = opening, ou 0 sur un bootstrap), donc
le report propageait l'ouverture sans créditer l'acquisition de l'année.
Cas Aurore : bascule 2026->2027 aurait reporté 0 au lieu de 31.
resolveCarry calcule désormais toujours la clôture réelle via
computeDynamicClosingForYear (bootstrap-aware, intègre acquisition + samedis
+ fractionnés − pris), puis fige ce résultat dans closing_days de l'exercice
qui se termine. Vérifié sur données réelles : report 2027 d'Aurore = 31,00 j
/ 5,00 samedis (au lieu de 0).
Corrections manuelles préservées : le cron reste idempotent (ne réécrit pas
une ligne existante) et le bon levier de correction devient opening_days
(propagé par le recalcul), pas closing_days.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
computeDynamicClosingForYear (qui produit le report d'ouverture de
l'exercice suivant) ignorait la table employee_leave_balances et
recalculait depuis l'embauche, sans absences historiques. Pour un
exercice consulté en avance, il cumulait donc une année pleine
d'acquisition par exercice antérieur à la mise en service.
Cas Aurore (CDI depuis 2022, bootstrap 2026 = report 32 / pris 24) :
report d'ouverture 2027 affiché à 88,39 j au lieu de 31. La vue courante
était juste car le provider, lui, lit déjà le bootstrap.
La clôture dynamique applique désormais la même règle que
EmployeeLeaveSummaryProvider::computeYearSummary : si une ligne bootstrap
existe pour l'exercice, on part de opening_days/opening_saturdays et on
ajoute l'offset taken_days/taken_saturdays, au lieu du report dynamique
accumulé. Vérifié sur données réelles : 88,39 -> 31,00 j.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tristan