---
name: feedback_adjustsimul
description: "Règles complètes pour adjustSimulForActuals — capital effectif, capital soldé, reprocess"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: cce8aa12-fe3a-4aa6-a101-357b5ce867e8
---

`adjustSimulForActuals` dans `backend/src/utils/schedule.js` est le point central déclenché après chaque remboursement. Trois règles à toujours respecter :

**1. Capital effectif = initial + réinvestissements**

**Why:** Après l'ajout des réinvestissements (mai 2026), la projection s'affichait correctement après un réinvestissement, mais dès qu'un remboursement était saisi, `adjustSimulForActuals` recalculait sur `montant_investi` seul, effaçant l'impact.

**How to apply:** À chaque nouvelle fonctionnalité modifiant le capital réel (réinvestissement, abondement…), vérifier et adapter :
1. `adjustSimulForActuals` dans `schedule.js`
2. `syncInvestissementStatut` dans `remboursements.js`
3. Le bouton ↺ (recalcul manuel) dans `simul.js`

**2. Capital soldé (remainingCapital <= 0)**

**Why:** Sans correction, l'échéance courante gardait `capital_prevu = 0` pour les prêts in fine, et des lignes à 0,00 € restaient dans le tableau au lieu d'être supprimées.

**How to apply:** Quand `remainingCapital <= 0` :
- L'échéance courante (date_prevue <= last_date) reçoit `capital_prevu = capitalAtLastDate`
- Les échéances futures (date_prevue > last_date) sont **supprimées** (DELETE), pas mises à zéro

**3. Route /reprocess doit appeler adjustSimulForActuals**

**Why:** Sans cet appel, recalculer les champs fiscaux en masse ne mettait pas à jour les échéanciers.

**How to apply:** La route `POST /api/remboursements/reprocess` doit sélectionner `r.investissement_id`, collecter les IDs dans un `Set` pendant la transaction, puis itérer avec `adjustSimulForActuals(db, invId)` après le `transaction()()`.