Aller au contenu

PD-56 — Rapport de confrontation (Étape 8 — Gate Closure)

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-56-specification.md (v3) — étape 1
  • Tests : PD-56-tests.md (v3) — étape 2
  • Plan : PD-56-plan.md — étape 4
  • Acceptability : PD-56-acceptability.md — étape 7

2. Convergences

  • Contrat de sortie MerkleProofResult : les quatre documents s'accordent sur le type discriminé available | pending, les champs obligatoires (eventHash, merkleRoot, merklePath, treeId, treeSize, leafIndex, hashAlgorithm, hashAlgorithmVersion), et l'absence de CORRUPTED comme valeur exposée de status. (Spec §5.1, Plan §1 C7, Tests TC-NOM-01/TC-NOM-08, Acceptability review code)
  • Machine à états PENDING/AVAILABLE/CORRUPTED : transitions autorisées/interdites identiques dans les quatre documents. CORRUPTED terminal strict, AVAILABLE→PENDING explicitement interdit. (Spec §5.4, Plan §1 C5 + §3 INV-56-06, Tests TC-INV-06/TC-ERR-09/TC-ERR-10, Acceptability review code CONFORME)
  • Codes contractuels ERR-56-01..05 : définition, conditions de déclenchement et comportement attendu cohérents. (Spec §6, Plan §6, Tests §4)
  • Anti-flood INV-56-09 : mécanisme UPDATE WHERE state != 'CORRUPTED' RETURNING * avec émission SECURITY_ALERT uniquement sur rowCount > 0 (première détection). Cohérent entre Spec §4/§5.7, Plan §3/§7/§9 point 4, Tests TC-NOM-11/TC-ERR-10, Acceptability INV-56-09 CONFORME.
  • Auto-vérification INV-56-05 : computeRoot(eventHash, merklePath) == merkleRoot avant tout retour available, avec tri lexicographique hashPair(sorted(a,b)). (Spec §5.5 F-01/F-03, Plan §2 F-01 étape 6, Tests TC-NOM-04/TC-NOM-05, Acceptability INV-56-05 CONFORME)
  • Cas limite treeSize=1 / merklePath=[] : reconnu comme valide dans les quatre documents. (Spec §5.1 règles explicites, Plan §9 point 7, Tests TC-NOM-12/TC-NEG-13, Acceptability — couvert par tests 120/120)
  • Migration DDL : VARCHAR + CHECK constraint (pas d'ENUM PostgreSQL natif), commitTransaction() avant toute clause WHERE. Cohérent entre Spec §5.6, Plan §9 point 3 + §9bis, Acceptability DDL CONFORME.
  • Anti-énumération : message uniforme ERR-56-01 pour eventId invalide ET inexistant. (Spec §6, Plan §7, Tests TC-ERR-01/TC-ERR-02, Acceptability Anti-enum CONFORME)
  • 9 invariants : tous référencés dans la matrice de couverture Tests §2, mappés dans le Plan §3, et vérifiés comme CONFORME dans l'Acceptability.
  • 15 critères d'acceptation : couverture par tests documentée (Tests §2), mécanismes mappés (Plan §4), et résultats 120/120 (Acceptability).

3. Divergences

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

  • DIV-01 : Sonar Quality Gate non exécuté vs procédure BLOQUANTE
  • Source A (Acceptability) : Phase 1.5 Sonar SKIPPED (auth Vault 401, credentials expirés). Mention « Pipeline CI vérifiera lors du merge sur dev ».
  • Source B (Procédures procedures.md Art. VII / Phase 1.5) : « Phase 1.5 (Sonar local) est BLOQUANTE. Si Sonar QG ERROR → STOP avant reviews LLM. »

  • Impact : L'acceptabilité a poursuivi les reviews LLM (Phase 2) sans résultat Sonar. Cela constitue un contournement de la procédure obligatoire. Le report au pipeline CI ne garantit pas la détection avant Gate 8.

  • DIV-02 : Coverage 59.5% vs seuil 80%

  • Source A (Acceptability) : Coverage global module merkle = 59.5%, qualifié RESERVE. Mention « fichiers PD-56 neufs bien couverts, dette pré-existante ».
  • Source B (Plan §12) : « Tous les niveaux de test sont couverts ». Le plan ne mentionne pas de risque de coverage insuffisante.

  • Impact : Le seuil de 80% n'est pas atteint. L'argument « dette pré-existante » n'est pas quantifié : aucun chiffre de coverage isolé sur les fichiers PD-56 neufs n'est fourni dans l'acceptabilité.

  • DIV-03 : Qualité des reviews LLM (Ollama 16K vs Codex/GPT)

  • Source A (Acceptability) : Reviews Phase 2 réalisées par Ollama llama3.3:70b (context 16K) en fallback. 8 findings sécurité, tous classés « faux positifs ». Note : « analyse superficielle LLM local, contexte limité 16K tokens ».
  • Source B (Intégrations integrations.md) : Les reviews gates doivent utiliser Codex plugin (/codex:adversarial-review) en priorité. Ollama est réservé aux tâches sensibles RGPD/PI.

  • Impact : La profondeur d'analyse est auto-admise comme limitée par le reviewer lui-même. Les 8 findings classés « faux positifs » n'ont pas été contre-expertisés par un second LLM. L'Art. II (validation croisée) est respecté formellement (LLM tiers ≠ Claude) mais la qualité effective de la revue est dégradée.

  • DIV-04 : Timing attack — affirmations contradictoires entre Plan et Acceptability

  • Source A (Plan §7 Sécurité) : « MerkleProofVerifier utilise constantTimeCompare() (existant PD-237) ».
  • Source B (Acceptability Review Sécurité S-01) : « hashPairSorted utilise crypto.createHash — pas de branche timing-dependent. Le concern est théorique. Faux positif. »

  • Impact : Le plan affirme l'existence d'une protection (constantTimeCompare). L'acceptability dismiss le concern comme théorique sans mentionner ce mécanisme. Si constantTimeCompare() existe effectivement, le finding S-01 est bien un faux positif mais pour une raison différente de celle invoquée. Si constantTimeCompare() n'existe pas, la mitigation du plan est incorrecte.

  • DIV-05 : Mapping tests acceptabilité vs identifiants TC-*

  • Source A (Acceptability) : « 120/120 tests passés (10 suites : merkle-proof.service, state-machine, eta-calculator, event-resolver, format-bounds, offchain, controller, exception, filter, audit) ».
  • Source B (Tests §2-§7) : 39 scénarios TC-* définis (TC-NOM-01..12, TC-ERR-01..11, TC-INV-06..08, TC-NEG-01..14, TC-NR-01..07).
  • Impact : Aucune correspondance explicite entre les 120 tests exécutés et les 39 scénarios contractuels TC-*. Impossible de vérifier la couverture exacte des scénarios contractuels sans cette traçabilité.

4. Zones d'ombre

  • ZO-01 — Questions ouvertes Spec §10.2 non tranchées : Les 4 questions ouvertes de la spécification (source exacte eventHash, eventId en batch FAILED, politique pending > 120 min, environnement benchmark CA-56-05) ne sont pas explicitement résolues dans le plan ni dans l'acceptabilité. Le plan mentionne le risque eventId→eventHash (§9 point 1) et l'acceptabilité ne le mentionne plus (résolu implicitement ?).

  • ZO-02 — Script vérification off-chain (CA-56-03 / C12) : Le plan définit un composant C12 (script standalone verify-merkle-proof-offchain.ts). L'acceptabilité ne mentionne pas son exécution ni son résultat. Les tests listent TC-NOM-04 comme couverture de CA-56-03. Aucune trace d'exécution du script externe dans le rapport d'acceptabilité.

  • ZO-03 — Tests de performance (CA-56-04 / CA-56-05) : L'acceptabilité ne mentionne ni la mesure de taille P95 (CA-56-04 < 10KB) ni la mesure de latence P95 (CA-56-05 ≤ 10ms). Le plan et les tests les prévoient (TC-NOM-09, TC-NOM-10). Ces critères sont-ils couverts dans les 120 tests ou absents ?

  • ZO-04 — Tests de non-régression (TC-NR-01..07) : Les 7 tests de non-régression définis dans le document Tests §6 ne sont pas mentionnés dans l'acceptabilité. Leur exécution n'est ni confirmée ni infirmée.

  • ZO-05 — Hypothèse HT-56-02 (convention de tri verifier) : Le plan (§8, §9 point 2) identifie un risque de divergence entre le tri lexicographique pur (spec §5.3) et l'implémentation existante PD-237 (potentiellement basée sur l'index de feuille). L'acceptabilité ne mentionne pas la vérification de cette hypothèse.

  • ZO-06 — Coverage isolée fichiers PD-56 : L'acceptabilité qualifie la coverage de RESERVE (59.5% global) en attribuant le déficit aux fichiers pré-existants. Aucune mesure de coverage isolée sur les fichiers créés par PD-56 n'est fournie pour étayer cette affirmation.

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 : - DIV-01 (Sonar SKIPPED) est le point le plus critique : la procédure qualifie Phase 1.5 comme BLOQUANTE. Le contournement doit être résolu (exécution Sonar ou dérogation explicite PO). - DIV-05 (traçabilité TC-* vs tests exécutés) empêche de confirmer la couverture contractuelle. - ZO-03 (performance non mesurée) concerne deux critères d'acceptation contractuels (CA-56-04, CA-56-05). - Les autres divergences (DIV-02, DIV-03, DIV-04) et zones d'ombre sont qualifiables en réserves mais ne bloquent pas seules.