PD-171 — Rétrospective¶
1. Contexte¶
| Champ | Valeur |
|---|---|
| Story ID | PD-171 |
| Titre | Synchronisation multi-device |
| Domaine | backend-core |
| Projet | backend |
| Date complétion | 2025-12-30 |
| Verdict | ACCEPTÉ après correction |
2. Métriques¶
| Métrique | Valeur |
|---|---|
| Tests passants | 253 |
| Écarts bloquants | 2 (E-01, E-02) |
| Fenêtre d'évaluation | 75ms |
| Types de conflits | C1/C2/C3/C4 |
| Règles de résolution | R1-R4 |
3. Learnings clés¶
-
Distinction C1/C2 critique : Ce n'est pas un détail d'implémentation mais un invariant fonctionnel. La première version a échoué sur ce point précis.
-
Batch temporel = abstraction logique : En HTTP synchrone, chaque requête arrive individuellement. La "fenêtre d'évaluation" doit être implémentée rétrospectivement via l'historique.
-
Cas frontière base_version == canonical_version - 1 : C'est LE cas où la distinction C1/C2 se joue. Il mérite un traitement explicite et des tests dédiés.
-
Immuabilité DB = triggers PostgreSQL : L'application ne peut pas garantir seule l'append-only ; les triggers sont un prérequis de conformité.
4. Patterns applicables¶
Nouveau pattern : Détection C1 rétrospective¶
Quand une requête arrive avec base_version < canonical_version : 1. Si base_version < canonical_version - 1 → C2 (Stale) 2. Si base_version == canonical_version - 1 → consulter recentVersion dans la fenêtre - Si recentVersion.baseVersion == request.baseVersion → C1 (LWW) - Sinon → C2 (Stale)
Pattern existant : Append-only avec triggers¶
Cohérent avec PD-237 (Merkle) : les tables d'historique doivent être protégées par triggers SQL.
5. Signal CLAUDE.md¶
Priorité haute : Documenter le pattern de résolution de conflits C1/C2.
### Conflits sync multi-device — C1 vs C2 (2026-02-XX)
**C1 (Concurrent)** : Requêtes dans la même fenêtre d'évaluation → LWW
**C2 (Stale)** : Requêtes hors fenêtre → Rejet
Le cas `base_version == canonical_version - 1` nécessite une vérification rétrospective de l'historique pour distinguer C1 de C2.
**Erreur commune** : Traiter toute requête avec `base_version < canonical_version` comme C2.
6. Conclusion¶
PD-171 a nécessité deux itérations pour implémenter correctement la distinction C1/C2. La complexité venait de l'abstraction "batch temporel" qui ne correspond pas au modèle HTTP synchrone. Le pattern de détection rétrospective via l'historique est la solution retenue et doit être documentée pour les futures stories de synchronisation.
Rétrospective générée 2026-02-19 (Étape 10 batch backend-core)