| Non-conformité Spec | Spec §5.4 / INV-265-11 / Plan DA-05 | La règle de calcul de tsaServiceState décrite en DA-05 indique flags.length > 0 → DEGRADED (avec “flag prioritaire pour affichage”), ce qui contredit le modèle contractuel (états DEGRADED_* quand 1 seul flag). | Rupture du modèle d’état contractuel, refus API (refusalReasonCode) potentiellement incohérents, et non-réalisabilité des tests qui attendent DEGRADED_NTS/REVOCATION/TRUSTLIST/KEY_LIFECYCLE. | BLOQUANT |
| Non-conformité Spec | Spec §5.1 (refusalReasonCode) / Spec §5.9 (reasonCode) / Plan DA-02, C3, C9, C12 | Les enums/codes normés sont étendus et/ou mélangés : ajout de valeurs non prévues (ex: KEY_RETIRED_SLA_BREACH, KEY_ARCHIVED_SLA_BREACH, NTS_DEGRADED, REVOCATION_DEGRADED, etc.), et divergences de libellés vs spec (ex: TL_* vs TRUSTLIST_*, MAX_DEGRADED_DURATION vs MAX_DEGRADED_EXCEEDED). | Événements d’audit et réponses de refus non conformes aux formats/énums contractuels ; audit tiers non satisfaisable et tests dépendant des motifs normés non fiables. | BLOQUANT |
| Non-conformité Spec | Spec §5.2/§5.4 (ntsReferenceServers, condition NTS) / Plan DA-01, C4 | Le plan fixe une stratégie d’agrégation multi-serveurs (worst-case : “ANY serveur KO/offset>seuil ⇒ flag NTS”, et métrique tsa_nts_offset_ms = max des offsets absolus). La spécification ne définit pas la réduction d’un set de mesures vers un scalaire unique. | Comportement introduit non spécifié ; deux implémentations pourraient produire des états différents pour les mêmes mesures multi-serveurs. | MAJEUR |
| Cohérence Plan ↔ Tests | Tests TC-NOM-01/TC-NOM-11 / Plan DA-01, C4 | Les tests ne décrivent pas de scénario de désaccord inter-serveurs NTS (ex: un serveur OK, un serveur > seuil). Le plan introduit un choix d’agrégation sans test contractuel dédié de ce cas. | Zone non vérifiée contractuellement sur un mécanisme critique (NTS fail-closed) ; risque d’écarts d’interprétation lors d’un audit tiers. | MAJEUR |
| Hypothèse implicite | INV-265-01 (fail-closed) / Plan DA-05, C3, C9 | Le plan repose sur un cache en mémoire comme source de lecture courante (guards/métriques) mais ne spécifie pas le comportement contractuel en cas de cache non initialisé, désynchronisé, ou d’indisponibilité DB au moment d’évaluer canEmitTst() / getState(). | Risque de fail-open (émission TST autorisée alors que les flags devraient bloquer) ou d’inobservabilité ; contournement possible des invariants fail-closed si le comportement par défaut n’est pas contractualisé. | MAJEUR |
| Hypothèse implicite | Spec §5.4 (refus explicite) / Plan C9 | Le plan fixe un code HTTP (503) pour le refus d’émission TST ; la spécification contractualise le contenu (refusalReasonCode, tsaServiceState, tsaServiceDegradationFlags) mais ne spécifie pas le statut HTTP. | Contrat d’API non fermé (interop/audit) : un tiers peut considérer le statut comme partie du comportement, sans base contractuelle. | MINEUR |
| Code Contract — Frontière | Code contracts CC-265-02 vs CC-265-07 (fichiers) | Chevauchement de périmètre : src/modules/tsa/entities/tsa-key-lifecycle-metadata.entity.ts est listé dans deux contrats (entities et lifecycle). | Frontières d’ownership non disjointes ; risque de conflits inter-agents et de traçabilité/audit de responsabilité non déterministe. | MAJEUR |
| Code Contract — Invariant | Code contracts CC-265-04 (invariants) / Spec | Le code contract nts-monitoring impose DA-01 (agrégation worst-case) comme invariant, alors que ce comportement n’est pas défini par la spécification. | Les invariants du code contract ne sont pas un sous-ensemble des invariants spec ; risque de non-conformité contractuelle si le plan est appliqué tel quel. | MAJEUR |
| Code Contract — Cohérence | Code contracts CC-265-02 / Plan DA-05, C2 | Le plan affirme que tsaServiceState “n’est jamais persisté”, mais l’entity C2 liste un champ state (et le code contract CC-265-02 exige “flags + state + timestamps”). | Incohérence plan ↔ code contracts sur la source de vérité et la persistance ; risque d’implémentation divergente et d’auditabilité affaiblie (état dérivé vs état stocké). | MAJEUR |
| Contrainte technique non documentée | Plan §13 (Contraintes techniques) | Le framework de test n’est pas explicitement choisi (Jest ou Vitest), alors que le plan prévoit des tests CI (*.spec.ts) et une exécution en pipeline. | Ambiguïté sur le runner/outillage : risque de non-reproductibilité CI et d’écarts de configuration (mocks, timers, ESM/CJS). | MAJEUR |
| Contrainte technique non documentée | Plan §13 (Contraintes techniques) | Les dépendances inter-PD sont mentionnées (ex: PD-55, PD-264, PD-7) mais ne sont pas listées comme dépendances avec statut (DONE/TODO/STUB acceptable) dans la section “Contraintes techniques”. | Traçabilité inter-story incomplète ; risque d’hypothèses de disponibilité de composants externes non auditées. | MINEUR |
| Contrainte technique non documentée | Plan §11/§13 (tests d’intégration + PostgreSQL réelle) | Les variables CI requises pour les tests d’intégration (ex: DATABASE_URL, CI=true, paramètres BullMQ/Redis si applicable) ne sont pas documentées. | Exécution CI/E2E potentiellement non reproductible ; risque de tests “verts local / rouges CI” sans justification contractuelle. | MINEUR |