Aller au contenu

Confrontation Gate 5 — PD-55

Résultat de la confrontation (Phase 2)

Analyse par Claude des écarts identifiés par ChatGPT.


ECT-01 — Immutabilité lot finalisé

Verdict : CONFIRMÉ (reclassé MAJEUR) Analyse : L'écart est valide sur le fond. Cependant, le plan définit clairement dans CC-55-01 que le status FINALIZED est immuable, et CC-55-03 ne permet pas de modifier un lot finalisé (finalizeBatch ne permet que la transition PENDING_FINALITY → FINALIZED). La protection doit être renforcée au niveau entité (triggers DB ou contraintes CHECK).

Recommandation : Ajouter dans CC-55-01 une contrainte explicite : "Une fois en status FINALIZED, aucune colonne ne peut être modifiée (contrainte CHECK ou trigger DB)."

ECT-02 — Atomicité rollback/rééligibilité

Verdict : CONFIRMÉ (reclassé MAJEUR) Analyse : L'écart est valide. Le plan mentionne failBatch mais ne précise pas explicitement que les événements sont dissociés du lot échoué dans la même transaction. La propriété transactionnelle doit être documentée.

Recommandation : Ajouter dans CC-55-03 : "failBatch() utilise une transaction atomique : le batch passe en FAILED ET les événements sont dissociés (batchId = null) dans la même transaction."

ECT-03 — Détection trous temporels

Verdict : INSUFFISANT Analyse : Le plan couvre la collecte continue (CC-55-04) mais pas le mécanisme de détection de trous. Cependant, la détection de trous est une fonctionnalité de monitoring, pas du worker lui-même. Le plan prévoit une Phase 4 "Alerting" avec un service anchor-alert.service.ts.

Recommandation : Préciser dans Phase 4 que l'alerting inclut la détection de fenêtres manquantes.

ECT-04 — Frontières ProofArtifactDto

Verdict : NUANCÉ Analyse : Le plan définit CC-55-06 avec le schéma complet conforme au §8 de la spécification. Les frontières sont établies. L'écart relève d'une non-visibilité dans le prompt de review (le contract complet est dans le plan).

Point résolu : Le plan contient déjà :

interface ProofArtifactDto {
  version: '1.0';
  lot_id: string;
  merkle_root: string;
  tx_id: string;
  chain_id: number;
  block_number: number;
  events: Array<{ event_id, event_hash, merkle_index, merkle_proof }>;
}

ECT-05 — Journalisation non exhaustive

Verdict : CONFIRMÉ (MAJEUR) Analyse : Écart valide. La journalisation doit être homogène entre processor et services. Le plan doit expliciter que CC-55-03 et CC-55-04 journalisent également les transitions d'état.

Recommandation : Ajouter dans CC-55-03 et CC-55-04 : "Chaque méthode émettant une transition d'état DOIT journaliser (AuditService) avec timestamp, from_state, to_state, correlation_id."

ECT-06 — Équivalence mocks/runtime

Verdict : NUANCÉ Analyse : L'écart est valide mais inhérent à tout projet. Le plan mentionne des "tests d'intégration" avec mocks Redis. Les tests e2e réels (pipeline CI avec Redis réel) sont standard dans le projet ProbatioVault-backend.

Point mitigé : Le projet utilise déjà Redis réel en CI. Le plan pourrait le préciser.

ECT-07 — Point d'observabilité périodicité

Verdict : CONFIRMÉ (reclassé MINEUR) Analyse : L'écart est valide mais la solution est triviale : le timestamp de chaque cycle est déjà journalisé (INV-55-10). La différence entre timestamps successifs donne la mesure contractuelle.

Recommandation : Ajouter dans CC-55-05 : "Le processor émet un log au démarrage de chaque cycle avec timestamp ISO 8601. La mesure de périodicité = delta entre timestamps successifs."

ECT-08 — Mapping CA tronqué

Verdict : INVALIDE Analyse : Cet écart est un faux positif. Le plan complet contient le mapping de tous les 12 CA. Le ... dans le prompt de review était une troncature pour réduire la taille du prompt, pas une omission dans le plan.

Preuve : Le fichier PD-55-plan.md contient :

| CA-55-01 | Config BullMQ (cron 10 min ±2) | T55-01 |
| CA-55-02 | CC-55-02 (cardinalité 1) | T55-02 |
| CA-55-03 | CC-55-05 (hash only) | T55-15 |
... (tous les CA sont mappés)


Tableau récapitulatif

ECT Verdict Gravité révisée Action
ECT-01 CONFIRMÉ MAJEUR (↓) Ajouter contrainte immutabilité explicite
ECT-02 CONFIRMÉ MAJEUR Documenter atomicité transaction
ECT-03 INSUFFISANT MAJEUR Préciser alerting détection trous
ECT-04 NUANCÉ MINEUR Plan complet, non visible dans prompt
ECT-05 CONFIRMÉ MAJEUR Homogénéiser journalisation services
ECT-06 NUANCÉ MINEUR Préciser Redis réel en CI
ECT-07 CONFIRMÉ MINEUR (↓) Documenter mesure périodicité
ECT-08 INVALIDE - Faux positif (prompt tronqué)

Statistiques révisées

Gravité Nombre
BLOQUANT 0 (↓ de 3)
MAJEUR 4
MINEUR 3
INVALIDE 1
Total valide 7

Avis global

Les 3 bloquants initiaux sont reclassés : - ECT-01 : Valide mais MAJEUR (mécanisme clair, manque contrainte explicite) - ECT-02 : Valide mais MAJEUR (atomicité implicite mais standard) - ECT-08 : INVALIDE (faux positif)

Recommandation : RESERVE — Les écarts majeurs peuvent être corrigés rapidement par enrichissement du plan (contraintes, atomicité, journalisation). Aucun bloquant architectural.