| Non-conformité Spec | Spec §4 INV-239-06 / Plan §8.3 | Le plan impose un format d’erreur {statusCode, timestamp, path, method, message, code} alors que la spec contractuelle exige strictement {error, message}. | Non‑conformité contractuelle vis‑à‑vis du format attendu par PD‑106 ; risque d’échec d’intégration. | BLOQUANT |
| Code Contract | Spec §4 INV-239-06 / Code contracts « password-change-filter » | Le code contract fixe un format d’erreur différent de la spec ({statusCode, timestamp, path, method, message, code} vs {error, message}), introduisant une règle incompatible. | Incohérence contractuelle ; impossible d’être conforme à la spec et au code contract simultanément. | BLOQUANT |
| Non-conformité Spec | Spec §2 (Inclus) / Plan §11.2 | Le plan introduit un rate limiting via MfaRateLimitGuard pour le changement de mot de passe, alors que la spec ne prévoit pas de rate limiting pour PD‑239. | Ajout d’une contrainte non spécifiée ; risque de rejet contractuel. | MAJEUR |
| Couverture manquante | Spec §4 INV-239-05 / Plan §6 (Observable) | Le plan mentionne un TTL 24h dans SessionRevocationStore mais ne fournit pas de mécanisme d’observabilité démontrant l’invalidation effective ≤ 30s (spec). | Test T‑239‑NOM‑01 non prouvable sans mesure d’effectivité dans la fenêtre contractuelle. | MAJEUR |
| Hypothèse implicite | Spec §4 INV-239-03 / Plan §5 étape 4 | Le plan s’appuie sur ReauthService.verifyPassword() pour valider l’ancien mot de passe, sans préciser si cette vérification utilise exactement l’ancien mot de passe fourni au endpoint (et non le reauth token). | Risque de confusion entre reauth et validation de l’ancien mot de passe ; conformité INV‑239‑03 non démontrable. | MAJEUR |
| Incohérence Plan↔Tests | Tests T‑239‑ERR‑08 / Plan §8.2 | Le plan normalise les erreurs Keycloak via mapping, mais ne précise pas comment injecter des erreurs Keycloak déterministes pour rendre T‑239‑ERR‑08 reproductible. | Test non déterministe sans point d’observabilité explicite. | MINEUR |