Je vais analyser les deux documents en profondeur selon les 6 axes obligatoires.

PD-56 — Specification Review¶

Audit technique indépendant — PD-56-specification.md (v3) + PD-56-tests.md (v3)¶

Écart #1¶

Type : Contradiction (Diagramme ↔ Machine d'états) Référence : Diagramme de séquence §5bis vs §5.4 (transitions interdites) vs INV-56-06 Description : Le diagramme de séquence ne branche pas sur l'état courant (proofAvailabilityState) avant de décider du chemin pending vs available. Si l'état persisté est AVAILABLE mais que finalized_at IS NULL est constaté à la relecture (régression de données), le diagramme conduit à retourner pending ou ERR-56-05 — ce qui constitue une transition AVAILABLE→PENDING explicitement interdite par §5.4. Le diagramme lit proofAvailabilityState uniquement pour court-circuiter sur CORRUPTED. Les cas PENDING et AVAILABLE suivent un flux identique, sans garde empêchant la transition interdite. Impact : Un implémenteur suivant le diagramme produirait un comportement violant INV-56-06. Ambiguïté sur le traitement attendu : corruption (→ CORRUPTED) ou réponse available idempotente malgré donnée incohérente ? Gravité : Majeur

Écart #2¶

Type : Hypothèse dangereuse Référence : H-56-06 (§9) + §5.4 (initialisation proofAvailabilityState) Description : H-56-06 reconnaît que proofAvailabilityState est initialisé par PD-237. Si cet état n'est pas initialisé au moment de l'appel PD-56, le comportement est indéterminé : la lecture d'un état absent/null ne correspond à aucun des trois états contractuels (PENDING, AVAILABLE, CORRUPTED). La spécification ne définit aucun comportement de repli (code d'erreur dédié, traitement par défaut, ou rejet explicite). Impact : Risque de faux ERR-56-03 (état lu comme invalide → corruption structurelle) ou de NullPointerException non contractualisée. L'impact est qualifié « Majeur » dans la spec elle-même. Gravité : Majeur

Écart #3¶

Type : Incohérence Spec↔Tests Référence : TC-NOM-06 (§3 Tests) vs §5.4 (condition PENDING→AVAILABLE) Description : TC-NOM-06 vérifie qu'un événement avec finalized_at IS NULL ne retourne pas available. Le test ne contraint pas l'état initial (proofAvailabilityState) du jeu de données. Si l'état est PENDING, le test est valide. Si l'état est AVAILABLE (régression de données), le comportement attendu est indéfini (cf. Écart #1) et le test ne couvre pas cette branche. Impact : Couverture lacunaire des cas de régression d'état. Un implémenteur pourrait ne pas détecter la violation AVAILABLE→PENDING. Gravité : Mineur

Écart #4¶

Type : Ambiguïté Référence : Diagramme de séquence §5bis — branche "leaf introuvable" vs §5.5 F-02 Description : Le diagramme de séquence utilise le terme "leaf introuvable" pour la branche menant au calcul d'ETA / ERR-56-05. Le texte de F-02 utilise "arbre non finalisé ou preuve non encore exploitable". Ce sont deux conditions distinctes : (a) la feuille n'existe pas encore dans merkle_leaves, (b) la feuille existe mais l'arbre n'est pas finalisé. La branche "leaf introuvable" englobe (a) mais pas nécessairement (b). La branche "leaf trouvé" avec finalized_at IS NULL couvre (b) dans le diagramme, mais F-02 ne fait pas cette distinction. Impact : Un implémenteur pourrait confondre les deux cas ou manquer le cas (a) dans sa logique. Gravité : Mineur

Écart #5¶

Type : Hypothèse dangereuse (concurrence) Référence : INV-56-09 + §5.7 + §5.8 Description : INV-56-09 exige l'émission d'un SECURITY_ALERT uniquement lors de la première détection de corruption. §5.8 contractualise une « transition conditionnelle atomique (row-level lock ou update optimiste) ». Cependant, l'atomicité porte sur la transition d'état, pas sur le couple {transition + émission d'alerte}. Deux requêtes concurrentes détectant une corruption simultanément pourraient : (a) l'une réussir la transition et émettre l'alerte, l'autre échouer et ne pas émettre — correct ; ou (b) les deux réussir la transition (idempotent CORRUPTED→CORRUPTED) et les deux émettre l'alerte — violation INV-56-09. Le spec reconnaît que le transport d'observabilité est hors scope, mais le contrat d'unicité de l'alerte repose sur un mécanisme non contractualisé. Impact : Risque de double SECURITY_ALERT en conditions concurrentes, violant l'anti-flood INV-56-09. Gravité : Mineur

Écart #6¶

Type : Incohérence Spec↔Tests Référence : TC-NEG-09 (§7 Tests) vs §5.1 / §5.3 (ETA) Description : TC-NEG-09 teste le cas « métadonnée ETA source non UTC (ex: +02:00) » et attend que le service produise une ETA UTC ou retourne ERR-56-05. La spécification ne contractualise pas le format d'entrée de window_end (source de l'ETA). Elle ne spécifie pas de conversion timezone ni de comportement en cas de source non-UTC. Le test couvre un scénario non contractualisé. Impact : Le test n'est pas opposable contractuellement. Risque de faux positif en acceptabilité si l'implémentation ne gère pas un cas non spécifié. Gravité : Mineur

Écart #7¶

Type : Cohérence diagramme (5bis) — absence de garde d'état Référence : Diagramme de séquence §5bis vs §5.4 Description : Le diagramme de séquence ne comporte qu'une seule garde sur proofAvailabilityState (vérification = CORRUPTED en début de flux). Il n'y a aucune garde sur AVAILABLE avant les branches menant à pending ou ERR-56-05. Toutes les transitions autorisées de §5.4 ne sont donc pas matérialisées comme gardes dans le diagramme. En particulier, les transitions AVAILABLE→AVAILABLE (idempotent) et AVAILABLE→CORRUPTED sont implicites, et la transition interdite AVAILABLE→PENDING n'est pas bloquée. Impact : Le diagramme est utilisable comme guide d'implémentation mais n'est pas fidèle à la machine d'états contractuelle. Gravité : Mineur (renforce l'Écart #1)

Écart #8¶

Type : Non testable Référence : INV-56-02 (déterminisme) + définition §3 "même snapshot" Description : La définition de "même snapshot" est « même état transactionnel des données (lectures dans la même transaction, ou absence d'écritures concurrentes entre lectures) ». Le critère « absence d'écritures concurrentes » n'est pas un observable contrôlable dans un environnement de test réaliste. TC-NOM-03 teste deux appels « successifs puis concurrents » mais ne peut garantir l'absence d'écritures concurrentes entre les deux, sauf en environnement strictement mono-writer. Impact : Le déterminisme est testable en conditions contrôlées (snapshot figé), mais la définition contractuelle inclut un cas non reproductible de manière déterministe. Gravité : Mineur

Synthèse¶

Les deux écarts Majeurs portent sur : 1. Une contradiction entre le diagramme de séquence et la machine d'états §5.4 (transition interdite AVAILABLE→PENDING non gardée). 2. L'absence de comportement de repli contractualisé pour un proofAvailabilityState non initialisé (H-56-06).