| Non-conformite Spec | Spec INV-106-05 (section 3 + 4), Plan section 2.2/2.5, Plan section 9 ("Re-auth cote client vs serveur") | La spec fixe une evaluation serveur de la borne 5 minutes. Le plan decrit un controle TTL gere cote client (ReauthModal/useReauth) et signale ce point en vigilance, sans verrou contractuel explicite d'alignement serveur. | Risque de divergence de decision d'autorisation d'operation critique selon client/serveur. | MAJEUR |
| Couverture manquante | Spec INV-106-04 + ERR-106-MFA-STATE-UNAVAILABLE, Plan section 2.1 | La spec v3 exige de bloquer explicitement activation, desactivation, consultation/regeneration des codes quand l'etat MFA est inconnu. Le plan mentionne seulement "actions MFA bloquees" sans enumeration des actions contractuelles. | Ambiguite d'implementation et risque de blocage partiel non conforme. | MAJEUR |
| Test irrealisable | Tests TC-* (46 mappings annonces), Plan sections ¾/5 ("voir tableau complet") | Le plan fourni ne contient pas les tableaux complets de mapping invariants/criteres/tests et observables annonces. | Verification tierce de realisabilite des TC et de l'observabilite impossible sur la base documentaire fournie. | BLOQUANT |
| Hypothese implicite | Spec section 3 (Re-authentification : "preuve acceptee par la politique serveur"), Plan section 1.1 (ReauthModal "par mot de passe") | Le plan restreint le facteur de re-authentification a un mot de passe sans expliciter l'alignement avec la politique serveur de facteurs acceptes. | Risque de rejet fonctionnel si la politique serveur effective differe de cette hypothese. | MAJEUR |
| Risque secu/conformite | Spec ERR-106-LOGOUT-FAILED + H-106-06, Plan section 2.6 (fallback logout) | Le plan confirme une deconnexion locale forcee en cas d'echec d'invalidation serveur et qualifie un "risque session zombie". | Persistance potentielle d'une session serveur active apres logout demande (surface d'abus residuelle). | MAJEUR |
| Code Contract — Invariant | Code contracts module settings-api, module tests-pd106 | Des invariants de code contract (timeout 30s, couverture 80%, mocks deterministes) ne sont pas des sous-ensembles explicites des invariants de la spec PD-106. | Rupture de la regle de sous-ensemble invariants code contracts vs spec. | MAJEUR |
| Code Contract — Cohérence | Plan section 1.1 (settingsApi), section 1.2 (src/services/api.ts), Code contracts modules settings-api et logout | Le plan et les code contracts distribuent les responsabilites API PD-106 entre settingsApi.ts et api.ts sans frontiere contractuelle claire des interfaces exposees. | Ambiguite d'interface et risque de duplication/incoherence de comportement entre couches API. | MAJEUR |
| Code Contract — Completuude | Plan section 1.2 (modif ProfileScreen.tsx), Code contracts (aucun module ne liste ProfileScreen.tsx) | Le plan declare une modification de ProfileScreen.tsx mais le fichier n'apparait dans aucun module de code contract. | Portion du plan non couverte contractuellement par un code contract. | MAJEUR |
| Code Contract — Frontiere | Code contracts modules logout (src/services/api.ts) et settings-api (src/services/settingsApi.ts), Plan section 1.2 | La frontiere entre les deux services n'est pas explicitee alors que les deux portent des responsabilites API liees a PD-106. | Risque de chevauchement de perimetre et de comportement non uniforme. | MINEUR |
| Hypothese implicite | Spec INV-106-10 + H-106-04, Plan section 2.3/2.4 | Le plan repose sur l'invalidation des anciens recovery codes "garantie serveur" sans mecanisme documente de preuve mobile autre que l'observable fonctionnel. | En cas de non-atomicite serveur, risque de coexistence temporaire de codes valides. | MAJEUR |