| Non-conformité Spec | INV-56-09 / CA-56-15 / Plan §9 point 4 | Le plan indique qu’en multi-instance « 2 alertes max possibles (acceptable) ». La spec impose une émission uniquement à la première transition vers CORRUPTED, puis aucune alerte ultérieure. | Affaiblissement explicite d’un invariant non négociable (anti-flood audit sécurité). | BLOQUANT |
| Test irréalisable | TC-NOM-11, TC-ERR-10, TC-NEG-14 / Plan §9 point 4 | Les tests exigent un seul SECURITY_ALERT par eventId sur première détection. Le plan accepte contractuellement des doublons en multi-instance. | Opposabilité des tests anti-flood non garantie dans une topologie cible distribuée. | BLOQUANT |
| Non-conformité Spec | Spec §5.5 F-02/F-05 + §10.2 Q2 / Plan §2 F-02 | Le plan introduit la règle status != FAILED pour le batch candidat, alors que la spec ne contractualise pas ce filtre (point explicitement ouvert en §10.2). | Introduction d’un comportement non spécifié pouvant modifier la décision pending vs erreur. | MAJEUR |
| Couverture manquante | Spec §5.6 / Plan C10, §9bis | L’exigence explicite « commitTransaction() avant toute clause WHERE utilisant la nouvelle valeur » n’est pas décrite dans le plan de migration. | Exigence DDL contractuelle non couverte. | MAJEUR |
| Hypothèse implicite | INV-56-02 / Plan §3 (mapping INV-56-02) | Le plan pose que READ COMMITTED suffit car « pas d’écriture concurrente sur leaf », sans mécanisme contractualisé garantissant ce prérequis. | Risque de non-déterminisme sous concurrence, fragilisant la reproductibilité audit. | MAJEUR |
| Non-conformité Spec | Spec §5.7 / Plan §2 F-01 étape 8 + Diagramme de séquence enrichi + Plan §9bis | Le plan est contradictoire sur PENDING->AVAILABLE : « aucune écriture en nominal » dans le flux/contraintes, mais transitionTo(AVAILABLE) dans le diagramme de séquence. | Ambiguïté contractuelle sur la machine d’état et risque d’implémentation divergente. | MAJEUR |
| Risque sécu/conformité | INV-56-09, Spec §5.7 / Plan §6 + §10 | Le plan ne documente pas de garantie opposable liant persistance CORRUPTED et preuve d’émission effective de SECURITY_ALERT (transport/retry explicitement hors scope). | Risque de rupture d’auditabilité sécurité (corruption persistée sans trace d’alerte probante). | MAJEUR |
| Code Contract — Invariant | Code contracts C3/C4/C11 | Plusieurs « invariants » du code contract ne sont pas des invariants de la spec PD-56 (ex. anti-énumération par message, contrainte prepared statements, « sign-verify roundtrip »). | Dérive du référentiel contractuel entre spec canonique et code contracts. | MAJEUR |
| Code Contract — Cohérence | Plan §1 (C12 dépendances) / Diagramme dépendances (A3→A12) / Code contract C12 (offchain-verifier) | Le diagramme de dépendances indique C12 dépendant de C3, alors que le plan textuel met C12 sans dépendance et le code contract impose un script standalone sans dépendances backend. | Frontière de composant ambiguë pour l’audit tiers. | MINEUR |
| Contrainte technique non documentée | Plan §9bis / Axe 7 (Compatibilité ESM/CJS) | Le plan mentionne CJS/Jest, mais n’identifie pas explicitement les dépendances ESM-only ni l’adaptation runner associée. | Risque d’ambiguïté d’exécution tests/CI sur compatibilité modules. | MAJEUR |