PD-16 — Rétrospective¶

1. Contexte¶

2. Métriques¶

3. Learnings clés¶

• Migrations successives = régressions : La migration de normalisation a supprimé le cas EXPIRED de la policy DELETE introduit juste avant. Une revue des migrations liées est essentielle.

• Jobs batch sans contexte RLS : Les services utilisant createQueryBuilder sans SET LOCAL verront leurs queries filtrées à 0 résultats.

• Rôle technique manquant : Le cycle PENDING→SEALED→EXPIRED suppose un worker qui peut UPDATE le status, mais les policies l'interdisent pour un user normal.

• Validation DTO = DB : Si ovh_path a une regex en DB, elle doit aussi être dans le DTO pour un rejet précoce.

4. Patterns applicables¶

Pattern existant : RLS et TypeORM¶

Comme PD-15, les queries via QueryBuilder échappent au RlsSubscriber. Le contexte doit être injecté manuellement.

Réf : PD-15-retrospective.md

Nouveau pattern : Rôle technique pour transitions¶

Pour les cycles de vie avec transitions (PENDING→SEALED→EXPIRED), prévoir un rôle PostgreSQL dédié au worker avec : - BYPASSRLS ou policy conditionnelle - Documentation explicite dans la spec

Nouveau pattern : Revue migrations liées¶

Avant merge d'une migration, vérifier les N migrations précédentes touchant les mêmes tables/policies pour éviter les régressions.

5. Signal CLAUDE.md¶

Priorité haute : Documenter le pattern "Rôle technique pour workers".

### Rôle technique pour workers (2026-02-XX)

Tout cycle de vie avec transitions automatiques (jobs, workers) nécessite :
1. Un rôle PostgreSQL dédié (`app_worker`) avec BYPASSRLS ou policies conditionnelles
2. Documentation explicite dans la spec de qui peut effectuer chaque transition
3. Tests E2E validant les transitions avec les vrais rôles

6. Conclusion¶

PD-16 a créé le schéma documents avec un cycle de vie probatoire mais a révélé des lacunes critiques : les jobs de sealing et de purge sont bloqués par les policies RLS. La distinction entre rôle utilisateur et rôle technique doit être spécifiée dès la conception.

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