PD-254 — Rapport de confrontation (Étape 3)¶

Ce rapport est produit par l'orchestrateur Claude avant chaque gate PMO. Il confronte les documents produits pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontées¶

Specification : PD-254-specification.md (étape 1)
Tests : PD-254-tests.md (étape 2)

2. Convergences¶

Invariants : Les 11 invariants (INV-254-01 à INV-254-12, hors INV-254-11 retiré) sont repris fidèlement dans la matrice de couverture tests (§2) et chacun dispose d'au moins un test dédié (TC-INV-01 à TC-INV-12).
Machine d'états : Les 10 états formels et les 5 codes d'erreur métier sont cohérents entre spec §5.2 et tests TC-INV-10A/10B. La distinction états vs codes métier est explicitement testée (TC-CODES-METIER-01).
Global Root Hash : L'algorithme de tri (lexicographique hex lowercase) et le calcul SHA3-256 sont décrits identiquement dans spec §3/§5.1 et testés spécifiquement (TC-INV-03, TC-GRH-SORT-01 avec exemple concret 3 objets).
Lisibilité : Les 3 critères (I/O, MIME, décodage 1024 octets) sont identiques entre spec §3 et tests TC-INV-05/TC-LISIB-01. Le test TC-LISIB-01 fournit un scénario à 5 objets couvrant chaque critère isolément.
Manifest integrity : Protection hash SHA-3 + signature HSM (INV-254-12) est cohérente entre spec §5.6/§5.7 et tests TC-INV-12/TC-ERR-11. La revalidation au postcheck est couverte.
TOCTOU : La détection d'objets ajoutés/supprimés entre precheck et postcheck (ERR-12, MANIFEST_STALE) est spécifiée en §5.7 étape 3 et testée (TC-TOCTOU-01, TC-ERR-12).
Clearing conditionnel : Le mécanisme N cycles conformes (spec §5.10) est testé par TC-CLR-01 avec scénario reset compteur.
Schemas JSON : Les schémas contractuels §5.14 (manifest + attestation) sont référencés dans les tests TC-NOM-02, TC-NOM-04, TC-NOM-08.
Dry-run : Le comportement source/source (spec §5.9) est cohérent avec TC-NOM-05.
Bornes numériques : Les 12 paramètres contractuels (spec §5.3) sont référencés dans les tests via les cas d'erreur et le test TC-ERR-07 (verification_timeout).
SLA temporels : Les 3 SLA (spec §5.4) sont couverts par TC-ERR-08 (attestation SLA) et les transitions décrites.
Codes d'erreur métier : Les 6 codes (INVALID_INPUT, INVALID_MANIFEST, CONCURRENT_EXECUTION_DENIED, ATTESTATION_FAILED, PRECHECK_EXPIRED, MANIFEST_STALE) sont cohérents. Note : MANIFEST_STALE apparaît dans spec §5.7 et tests TC-ERR-12 mais n'est pas listé dans la table initiale des codes métier §3 de la spec — voir DIV-01.
Rate-limiting : Quota 3 lancements/heure/initiateur (spec §5.10) est testé par TC-NEG-06 (4e lancement rejeté).
Non-régression : 5 tests NR couvrant archivage existant, performance CI, compatibilité modules, WORM PD-44, pipeline quality gate.

3. Divergences¶

⚠️ Les conflits ne doivent JAMAIS être lissés. Chaque divergence est rendue visible.

DIV-01 : Code métier MANIFEST_STALE absent de la liste formelle §3
Source A (Specification §3) : Liste 5 codes d'erreur métier : INVALID_INPUT, INVALID_MANIFEST, CONCURRENT_EXECUTION_DENIED, ATTESTATION_FAILED, PRECHECK_EXPIRED.
Source B (Specification §5.7 + Tests TC-ERR-12) : Introduit un 6e code MANIFEST_STALE pour la détection TOCTOU (nombre d'objets source divergent).
Impact : Incohérence interne à la spec. Le code MANIFEST_STALE est utilisé fonctionnellement mais n'apparaît pas dans la définition §3, dans la table §5.2 des codes métier, ni dans les observabilité tests §9. Un implémenteur pourrait omettre ce code. Les tests le référencent (TC-ERR-12, TC-TOCTOU-01) ce qui confirme son existence fonctionnelle.
DIV-02 : Nombre d'états formels déclaré vs observé dans les tests
Source A (Tests TC-INV-10A) : Mentionne « 10 états formels + 5 codes métier ».
Source B (Specification §5.2) : Liste exactement 10 états formels ET 5 codes métier dans la table principale — mais MANIFEST_STALE (6e code) n'est pas compté.
Impact : Si MANIFEST_STALE est un code métier légitime, le test TC-INV-10A devrait référencer « 10 états + 6 codes ». La matrice de transitions testée serait incomplète d'un code.
DIV-03 : Transition PRECHECK_PASSED -> DRAFT sur expiration — code métier dans la spec vs. absence dans les tests
Source A (Specification §5.2) : PRECHECK_PASSED -> DRAFT est autorisée si precheck expiré, avec émission du code PRECHECK_EXPIRED avant retour.
Source B (Tests) : Aucun test dédié ne couvre explicitement la transition PRECHECK_PASSED -> DRAFT sur expiration TTL. Le code PRECHECK_EXPIRED est mentionné dans TC-INV-10A (matrice) mais sans scénario Given/When/Then spécifique.
Impact : Une transition avec SLA (TTL 168h) et code métier spécifique n'a pas de test explicite. La couverture dépend entièrement du test matriciel TC-INV-10A, sans vérification du comportement temporel.
DIV-04 : Transition VERIFIED -> ROLLED_BACK quand attestation impossible — parcours exact
Source A (Specification §5.2) : VERIFIED -> ROLLED_BACK est autorisée « si attestation impossible dans SLA ». Le code ATTESTATION_FAILED est emis, et la campagne est « transitionée vers ROLLED_BACK ».
Source B (Tests TC-ERR-08) : « Rollback obligatoire ou incident majeur selon politique opérationnelle ». Formulation « ou incident majeur » absente de la spec.
Impact : Le test introduit une alternative (incident majeur) non spécifiée. Soit la spec est incomplète (pas de chemin incident majeur), soit le test est trop permissif.
DIV-05 : Comportement readability_sample_count hors bornes
Source A (Specification §5.3) : Hors bornes → « Clamp au max + trace ».
Source B (Tests TC-NEG-05) : « Clamp max trace ou rejet selon règle de borne ».
Impact : Le test introduit une alternative « rejet » absente de la spec qui ne prévoit que le clamp. Ambiguïté sur le comportement quand la valeur est < 100 (clamp au min non mentionné explicitement dans la spec).
DIV-06 : Scénario SCN-10 (spec) vs TC-CLR-01 (tests) — séquence de cycles
Source A (Specification SCN-10) : « 1 cycle conforme → 1 cycle non conforme → 3 cycles conformes ». Le clearing est « autorisé après les 3 cycles conformes ».
Source B (Tests TC-CLR-01) : Même séquence, mêmes résultats. Cependant, clearing_cycles est configuré à 3 dans le test, alors que la spec §5.3 indique un défaut de 3 mais min 2 et max 10. Le test ne couvre qu'une seule valeur de clearing_cycles.
Impact : Mineur — couverture paramétrique limitée mais le comportement est cohérent.

4. Zones d'ombre¶

ZO-01 : Politique de sampling lisibilité non déterministe. La spec (Q-04) et les tests (§10 règles non testables) reconnaissent que la méthode de tirage (uniforme vs stratifié) n'est pas figée. Sans seed documenté ou méthode contractuelle, deux exécutions du même precheck pourraient produire des échantillons différents, affectant la reproductibilité (INV-254-09). Les tests contournent en figeant l'échantillon (TC-INV-05 : « seed déterministe ou liste d'objets explicitée »), mais en production le comportement reste indéterminé.
ZO-02 : Mapping codes retour CI non contractualisé. La spec (Q-06) et les tests (§10) identifient que le mapping numérique des codes retour CI n'est pas défini. TC-NOM-06 teste « job en état failed » mais pas le code de sortie exact. L'intégration CI/CD reste validable en principe mais pas contractuellement vérifiable.
ZO-03 : Endpoint/disponibilité registre blockchain non spécifié. Q-03 reste ouvert. Les tests TC-INV-04 et TC-ERR-04 assument un accès fonctionnel au registre mais ne couvrent pas les scénarios de dégradation partielle (registre lent, timeout partiel sans timeout global).
ZO-04 : Comportement en cas de readability_sample_count < min (100). La spec §5.3 définit min=100 mais le comportement « hors bornes » est « clamp au max + trace ». Aucune mention du clamp au min. Si un opérateur configure 50, la spec ne prescrit pas explicitement le comportement (clamp à 100 ? rejet ?). Le test TC-NEG-05 mentionne les deux options sans trancher.
ZO-05 : Archivage de l'attestation — destination contractuelle. Q-07 non résolu. CA-09 exige « archivée » et TC-NOM-04 vérifie « archivée en stockage probatoire » mais le bucket/prefix cible n'est pas contractualisé. Un audit pourrait contester la localisation.
ZO-06 : Double signature attestation. Q-08 non résolu. La spec et les tests assument une signature HSM unique, mais la nécessité d'une co-signature opérationnelle n'est ni confirmée ni infirmée.
ZO-07 : Transition CUTOVER_AUTHORIZED -> PRECHECK_PASSED — conservation du manifest. La spec §5.2 précise « conserve le manifest initial, aucun écrasement ». Aucun test ne vérifie explicitement que le manifest n'est pas écrasé lors de ce retour arrière. Un test de non-écrasement serait nécessaire pour garantir INV-254-12.
ZO-08 : Rate-limiting — granularité « par migration_id ET par initiateur ». La spec §5.10 définit deux granularités mais le quota « max 3 lancements/heure/initiateur » ne clarifie pas si c'est 3 par initiateur tous migration_id confondus, ou 3 par couple (initiateur, migration_id). TC-NEG-06 teste 4 lancements mais ne précise pas la granularité.
ZO-09 : Comportement quand readability_pass_threshold = 1.0000 strict et un seul objet échoue sur un grand lot. La spec définit un défaut de 1.0000 avec min 0.9900. Q-02 demande confirmation du seuil strict. Si confirmé à 1.0000, un seul objet non lisible sur 10 000 bloque la migration, ce qui peut être intentionnel mais mérite confirmation.
ZO-10 : Absence de test pour la transition CUTOVER_AUTHORIZED -> ROLLED_BACK. La spec §5.2 autorise cette transition (annulation opérationnelle). Aucun test Given/When/Then ne couvre ce scénario explicitement. TC-INV-10A devrait le couvrir en matrice, mais sans scénario détaillé le comportement spécifique (conservation des artefacts, notifications) n'est pas vérifié.

5. Recommandation¶

Procéder — convergence confirmée, aucun conflit bloquant
Rework nécessaire — divergences à résoudre avant de continuer
Escalade — décision humaine requise sur un point structurant

Justification : La couverture fonctionnelle est solide (11/11 invariants testés, 12/12 erreurs couvertes, machine d'états testée en matrice). Cependant :

DIV-01/DIV-02 (MANIFEST_STALE non listé formellement) est une incohérence interne de la spec qui doit être corrigée avant Gate 3 — ajouter MANIFEST_STALE à la liste §3 et §5.2 des codes métier.
DIV-03 (absence de test dédié pour PRECHECK_EXPIRED/TTL) représente une lacune de couverture sur un SLA critique.
DIV-04 (alternative « incident majeur » dans le test) doit être alignée avec la spec.
DIV-05 (clamp vs rejet readability_sample_count) doit être tranchée dans la spec.
ZO-07 et ZO-10 sont des lacunes de tests sur des transitions autorisées.

Les 5 points Q restants (Q-03 à Q-08) sont reconnus comme non testables par les deux documents et n'empêchent pas la validation du protocole, mais devront être résolus avant implémentation.