## Problème
Le correctif #31 (dirty-tracking front) ne protège que les sessions qui
chargent le nouveau bundle. Un vieil onglet ouvert avant déploiement tourne
encore sur l'ancien JS et envoie toute la grille périmée → reproduit en prod :
un onglet ouvert le matin a supprimé ~10 lignes saisies dans la journée par
d'autres utilisateurs (entrée vide = suppression côté backend, sans garde).
## Correctif (suppression sur intention explicite)
`WorkHourBulkUpsertProcessor` ne supprime une ligne existante sur entrée vide
QUE si l'entrée porte `delete: true`. Sinon → no-op (ligne préservée). Aucune
grille périmée, quel que soit le client, ne peut plus détruire une saisie
concurrente. La création de ligne technique de validation reste limitée à
`null === $existing`.
Le front (à jour) pose `delete: true` sur une ligne vidée volontairement
(helper `isEntryEmpty`, après le filtre dirty-tracking) → suppression métier
conservée. Flag optionnel ajouté au DTO front (`WorkHourEntryPayload`) et back
(`WorkHourBulkUpsert`), défaut false.
## Testabilité
Le processor dépend désormais des interfaces repo (`EmployeeScopedRepositoryInterface`
/ `WorkHourReadRepositoryInterface`, repos concrets `final` non mockables) →
nouveau test unitaire `WorkHourBulkUpsertProcessorTest` (no-op sans flag /
suppression avec flag / update normal).
## Limite résiduelle (par choix : suppression explicite, pas verrou optimiste)
L'édition explicite d'une ligne sur données périmées peut encore écraser une
saisie concurrente sur cette même ligne. Seule la suppression est blindée.
## Vérification
- 267 tests PHPUnit OK (dont 3 nouveaux). Front : revue de code (pas de harnais).
## Doc
- doc/hours-save-dirty-tracking.md, CLAUDE.md, doc in-app.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Problème
Sur l'écran **Heures** / **Heures Conducteurs**, l'enregistrement envoyait au bulk-upsert une entrée pour **tous** les employés visibles non verrouillés, à partir de l'état en mémoire de la grille. Le backend (`WorkHourBulkUpsertProcessor`) traitant une **entrée vide comme une suppression**, un admin avec une grille **périmée** pouvait supprimer une ligne saisie entre-temps par un autre utilisateur.
### Scénario reproduit
1. Un admin ouvre l'écran ; la ligne d'un salarié `ROLE_SELF` est vide.
2. Ce salarié saisit ses heures dans sa propre session → ligne créée, **non validée** (donc non verrouillée).
3. L'admin, sur sa grille périmée, enregistre d'autres employés.
4. Le payload contient une entrée **vide** pour le salarié → le backend supprime sa ligne. **Perte de données.**
## Correctif (suivi des lignes modifiées)
`hydrateRows` capture un instantané `loadedRows` de l'état chargé depuis le serveur. `handleSave` ne transmet plus que les lignes **dont l'état courant diffère de l'instantané**.
- Ligne **intouchée** → jamais envoyée → jamais supprimée ✅
- Ligne **vidée volontairement** → envoyée vide → supprimée (métier conservé)
- Ligne **remplie/modifiée** → envoyée → créée/mise à jour
Symétrique dans `useHoursPage.ts` et `useDriverHoursPage.ts`.
## Limite connue
Pas de verrou optimiste backend : l'édition **explicite** d'une ligne sur données périmées peut toujours écraser une saisie concurrente sur cette même ligne (hors périmètre).
## Doc
- `doc/hours-save-dirty-tracking.md` (nouveau)
- Note `CLAUDE.md` (section *Validation Rules*)
## Vérification
- Pre-commit hook : **236 tests PHPUnit OK**.
- Pas de harnais de tests frontend (revue de code uniquement).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Reviewed-on: #31
Co-authored-by: tristan <tristan@yuno.malio.fr>
Co-committed-by: tristan <tristan@yuno.malio.fr>
tristan