| Non-conformite Spec | Spec §3 (Champs proteges), Spec INV-32-03/04, Spec CA-32-04, Plan §2.1 GET /user/profile | Le flux GET planifie selectionne et retourne plan ({ name, email, plan, avatar_url, preferences }) alors que plan est un champ protege dans la specification. | Violation directe du contrat de minimisation et exposition d'un champ protege. | BLOQUANT |
| Non-conformite Spec | Spec §6 (format erreur), Spec CA-32-13, Plan §2.2 et §3 (INV-32-06) | Le plan declare whitelist: true rejecte -> 400 ERR-32-PROTECTED-FIELD. Le rejet de champs non whitelistes est porte par forbidNonWhitelisted; la projection d'un code erreur contractuel ERR-32-* n'est pas decrite comme garantie explicite de mapping. | CA-32-13 (code erreur contractuel observable) n'est pas demontre de facon contractuelle. | MAJEUR |
| Test irrealisable | Test TC-ERR-03, TC-ERR-04, Plan §2.½.2, Plan §1.3 | Les tests d'acces croise exigent une cible U2 explicite, mais les endpoints /user/profile n'exposent aucun parametre de cible et le plan ne decrit aucun mecanisme de simulation/verrouillage de ce cas en test. | Realisation objective de TC-ERR-03/04 non demontree dans le plan. | BLOQUANT |
| Couverture manquante | Spec CA-32-12, Test TC-ERR-08, Plan §1.3, Plan §2.½.2 | Le plan mentionne RateLimitGuard global mais ne documente pas les parametres de seuil/fenetre necessaires a la reproductibilite du test contractuel rate-limit. | Testabilite deterministe de TC-ERR-08 non etablie au niveau du plan. | MAJEUR |
| Hypothese implicite | Spec H-32-02, INV-32-02, Plan §2.½.2, Plan §3 (INV-32-02) | Le plan suppose que RLS est actif et correctement applique en environnement cible sans mecanisme de verification explicite dans le plan. | Risque d'acces croise si RLS est desactive/mal configure ; conformite dependante d'une hypothese operationnelle. | MAJEUR |
| Risque secu/conformite | Spec INV-32-03/04/10, Plan §3 (INV-32-03/04) | Le plan combine @Exclude() sur entite + DTO pour eviter les fuites. Cette protection repose sur une discipline de serialisation non explicitee (risque de bypass si retour non-DTO). | Surface de fuite potentielle de champs sensibles en cas d'ecart de serialisation. | MAJEUR |
| Code Contract — Completude | Plan §1.2 (AppModule modifie), Code contracts (modules listes) | AppModule est annonce comme composant modifie dans le plan mais aucun module de code contract ne couvre src/app.module.ts. | Completude des contracts non totale par rapport au perimetre modifie du plan. | MAJEUR |
| Code Contract — Invariant | Spec §4 (INV-32-*), Code contracts module user-module | Le contract user-module ajoute l'invariant "Le module DOIT exporter UserProfileService...", exigence absente de la specification canonique. | Le set d'invariants des code contracts n'est pas strict sous-ensemble des invariants spec. | MAJEUR |
| Code Contract — Cohérence | Spec §4 (INV-32-08), Plan §2.1, Code contracts module user-profile-controller | Le code contract controller exige retour name,email,avatar_url, mais le plan de flux GET retourne aussi plan et preferences. | Incoherence interne Plan ↔ Code contracts sur le contrat de sortie. | MAJEUR |
| Code Contract — Frontiere | Plan §1.3 (composants reutilises), Code contracts (aucun module dedie) | Les composants critiques reutilises (AuthenticationGuard, RateLimitGuard, RlsMiddleware, @CurrentUser) ne sont pas traces dans un module de contract alors qu'ils portent des invariants centraux. | Frontieres de responsabilite contractuelle incompletes pour l'audit tiers. | MINEUR |