| Non-conformité Spec | INV-278-01 / Spec §4, §5.2, CA-01 / Plan §3, §4, §5.3, §9, code-contract dip-migration | EC-01 — Le plan acte un enum DB à 5 valeurs (RESTITUTED inclus) et remplace l’exigence contractuelle “set exact de 4 états” par “DIP ∈ enum_range”. Cela affaiblit explicitement l’invariant contractuel. | Violation directe d’un invariant non négociable ; conformité OAIS/NF non démontrable selon le contrat PD-278. | BLOQUANT |
| Non-conformité Spec | INV-278-08, INV-278-09 / Spec §4, §5.2 / Plan §3 (fuzz 5x5 + conflit EXPIRED -> DESTROYED) | EC-02 — La matrice de transitions du plan n’est pas strictement bornée au modèle PD-278 (4 états) et reconnaît un conflit avec une transition hors contrat (EXPIRED -> DESTROYED). | Rupture de la propriété “toute transition non autorisée est interdite explicitement” dans le périmètre contractuel visé. | BLOQUANT |
| Test irréalisable | TC-ERR-05, TC-INV-07 / Spec §6 (E-403-RLS) / Plan §6, §13 C9 (branche E-404-NOT-FOUND quand lignes manquantes via RLS) | EC-03 — Le plan introduit une ambiguïté 403 vs 404 sur refus RLS ; les tests qui exigent 403 déterministe sur RLS deviennent non garantis. | Scénarios contractuels RLS non validables de façon déterministe ; testabilité contractuelle cassée. | BLOQUANT |
| Non-conformité Spec | Spec §6, §5.14 (“codes d’erreur suivent §6”) / Plan §6 (E-404-NOT-FOUND, E-503-REDIS) | EC-04 — Le plan ajoute des codes d’erreur non listés dans la spécification canonique. | Introduction de comportements d’API non spécifiés contractuellement ; divergence Plan↔Spec↔Tests. | MAJEUR |
| Couverture manquante | INV-278-10, CA-15 / Tests TC-INV-10, TC-NEG-05 / Plan §3, §4, §8 H-08, §15 (PD-37 = STUB) | EC-05 — Le plan maintient une dépendance “stub” pour la chaîne HSM/envelope tout en affirmant CA-15 testable sans réserve. | Invariant crypto non garanti en conditions réelles ; preuve de conformité sécurité potentiellement non opposable. | BLOQUANT |
| Risque sécu/conformité | INV-278-04 / Spec §4, §5.8 / Plan §13 C11 (snippet catch auditError puis réponse quand même) | EC-06 — Le flux de refus sécurité peut perdre l’événement d’audit si l’INSERT audit échoue (exception absorbée). | Rupture d’auditabilité (“chaque tentative refusée persiste”) ; trou de traçabilité sécurité. | MAJEUR |
| Hypothèse implicite | Spec §5.9 (règle cross-module obligatoire) / Plan §9 V-02, §11 (vérification ultérieure, pas mécanisme garanti) | EC-07 — La conformité de l’ordre de verrouillage dans les autres modules est supposée, pas contractualisée par mécanisme exécutable dans ce plan. | Risque de deadlock inter-modules et non-respect d’une règle obligatoire non contournable. | MAJEUR |
| Couverture manquante | Spec §5.13 (attestation “non modifiable après création”) / Plan C1/C2/C14/code-contracts | EC-08 — Le plan décrit l’intention WORM des attestations mais ne définit pas de mécanisme d’enforcement explicite et non contournable (DB/applicatif) pour l’append-only de la table d’attestation. | Intégrité probatoire des attestations affaiblie ; conformité NF sur la preuve de communication non robuste. | MAJEUR |
| Couverture manquante | Spec §5.5, Tests TC-NOM-05 / Plan §5.1 (TC-NOM-05), §13 C9 | EC-09 — Le comportement “hard timeout > 5000 ms ⇒ échec atomique” est testé dans la matrice mais le mécanisme technique d’application n’est pas défini explicitement dans le plan. | Exigence SLA contractuelle partiellement non implémentable/observable telle qu’écrite. | MAJEUR |