PD-172 — Rapport de confrontation (Étape 3)¶

Ce rapport est produit par l'orchestrateur Claude avant chaque gate PMO. Il confronte les documents produits pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontées¶

• "'PD-172 — Rate limiting distribué Redis multi-dimensions (contractuel V1) (document de spécification)
• PD-172 — Scénarios de tests contractuels (document QA/tests)

2. Convergences¶

• Convergence sur le socle contractuel multi-instances :
• Spécification : INV-172-01, CA-172-01, ST-172-01
• Tests : TC-NOM-01, matrice de couverture INV-172-01 -> CA-172-01
• Convergence sur l’atomicité quota -> métier :
• Spécification : INV-172-02, §5.5, ERR-172-01/02/03
• Tests : TC-NOM-02, TC-NOM-10, TC-NOM-11, TC-ERR-03
• Convergence sur les dimensions et fenêtres V1 obligatoires (ip, user_id, tenant, route + burst/sustained) :
• Spécification : §2 Inclus, §5.2 dimensions_count_v1=4, §5.2 windows_per_route_v1=2, CA-172-04/05
• Tests : TC-NOM-04, TC-NOM-05, TC-NOM-06
• Convergence sur la matrice Redis-down (read fail-open, auth/costly fail-closed) :
• Spécification : INV-172-05, §5.4, CA-172-08, ERR-172-06
• Tests : TC-NOM-09, TC-NOM-10, TC-NOM-11, TC-ERR-06
• Convergence sur la machine d’états normative et terminale :
• Spécification : INV-172-06, §5.4
• Tests : TC-NOM-15, TC-NOM-16
• Convergence sur l’observabilité des refus (logs structurés + métriques) :
• Spécification : INV-172-03, CA-172-06, CA-172-07
• Tests : TC-NOM-07, TC-NOM-08, tests d’invariants INV-172-03
• Convergence sur l’interdiction de whitelist/bypass en V1 :
• Spécification : INV-172-07, §2 Exclu
• Tests : TC-NOM-14, TC-NEG-07
• Convergence sur la config figée au boot (V1) :
• Spécification : INV-172-08, CA-172-10
• Tests : TC-NOM-13, TC-ERR-05
• Convergence explicite sur la testabilité partielle :
• Spécification : §5.2, §5.3, §10.2 (valeurs manquantes/ambiguïtés)
• Tests : §9 Règles non testables, §10 Verdict QA ("Testable partiellement")

3. Divergences¶

⚠️ Les conflits ne doivent JAMAIS être lissés. Chaque divergence est rendue visible.

• DIV-01 — Référentiel Epic non homogène dans les métadonnées de source
• Source A (spécification) : Référence Epic : PD-186 — Backend Core sécurisé et modulaire
• Source B (tests) : Référence Epic : EPIC-XX (référence produit : PD-186 — Backend Core sécurisé et modulaire)
• Impact : ambiguïté de traçabilité documentaire (liaison outillée potentiellement non déterministe selon l’identifiant d’Epic attendu).

4. Zones d'"'ombre¶

• Valeurs contractuelles exactes absentes pour "'burst.max_requests, burst.window_seconds, sustained.max_requests, sustained.window_seconds (bloque validation complète des critères liés aux quotas).
• SLA numériques absents pour burst_window_ttl, sustained_window_ttl, degraded_clearing_cycles (sortie de mode dégradé non objectivable).
• Paramètres de réconciliation distribuée non définis (cron, seuil d’orphelin, rattrapage).
• Code HTTP normatif du fail-closed non tranché (Q-172-03).
• Liste exhaustive des routes read autorisées en fail-open non fournie (Q-172-04).
• Format final d’identifier (brut vs pseudonymisé) non arbitré, avec tension RG métier explicitée (§5.1, Q-172-05).
• Politique explicite routes santé/monitoring vs interdiction de whitelist V1 non tranchée (Q-172-06).
• Granularité métriques obligatoire (labels) et cardinalité maximale non fixées (Q-172-09).
• Convention d’exposition publique stable des codes ERR-172-* non figée (Q-172-10).
• Stratégie définitive de résolution IP fiable en contexte proxy non fixée (Q-172-11).
• Statut V1/V2 du daily guardrail non clarifié (Q-172-12).
• Portée exacte de l’observabilité obligatoire pour les refus 400 (REJECTED_INVALID_CONTEXT, ERR-172-07) non explicitée de façon normative dans les deux documents.

5. Recommandation¶

• Procéder — convergence confirmée, aucun conflit bloquant
• Rework nécessaire — divergences à résoudre avant de continuer
• Escalade — décision humaine requise sur un point structurant