PD-3 — Rétrospective¶

1. Contexte¶

Champ	Valeur
Story ID	PD-3
Titre	Infrastructure Redis/BullMQ
Domaine	backend-core
Projet	backend
Date complétion	2026-01-12

2. Métriques¶

Métrique	Valeur
Tests contractuels	8/14 PASS (6 N/A)
Invariants couverts	4/4 (INV-01 à INV-04)
Durée estimée	N/A
Itérations	1

3. Learnings clés¶

Tests unit vs intégration Redis : Les invariants de persistance (INV-03) nécessitent des tests d'intégration avec Redis réel — les mocks ioredis ne valident pas le comportement AOF.
Caractères BullMQ : BullMQ interdit les : dans les noms de queue. Erreur découverte uniquement lors du test d'intégration.
Watchman macOS : L'erreur watchman bloque Jest en local. Résolu par "watchman": false dans la config Jest.
Tests E2E/chaos : Les scénarios restart/kill de processus (TC-NOM-02, TC-ERR-02) ne sont pas automatisables en CI standard.

4. Patterns applicables¶

Pattern existant : Redis Resilience¶

Les invariants INV-01 (persistance) et INV-03 (recovery après restart) dépendent de : - Configuration Redis AOF (appendonly yes) - Configuration BullMQ (stalledInterval, lockDuration) - Politique restart Systemd

Réf : Pattern documenté dans PD-30-retrospective.md

Nouveau pattern : Tests d'intégration Redis obligatoires¶

Pour tout module utilisant Redis, prévoir un fichier .integration.spec.ts exécuté uniquement en CI avec service Redis.

# .gitlab-ci.yml
services:
  - redis:7-alpine

5. Signal CLAUDE.md¶

Aucun signal priorité haute. Les patterns identifiés sont déjà couverts par PD-30 (Redis Resilience).

Priorité moyenne : Documenter les restrictions de nommage BullMQ dans les conventions de développement.

6. Conclusion¶

PD-3 a établi les fondations de l'infrastructure asynchrone avec BullMQ. Les principaux défis concernaient la frontière tests unitaires/intégration et les contraintes spécifiques de BullMQ. Le mapping invariants → mécanismes → tests documenté dans le plan d'implémentation est un accélérateur à maintenir.

Rétrospective générée 2026-02-19 (Étape 10 batch backend-core)