PD-177 — Confrontation Gate 5 v2 (Plan d'implementation)¶

Date : 2026-02-23 Reviewer P1 (Phase 1) : ChatGPT (via OpenCode) Confrontant P2 (Phase 2) : Claude

Synthese de la review P1 (v2)¶

ChatGPT a identifie 5 ecarts : - 0 BLOQUANT - 3 MAJEUR (SECRET_EXPOSURE vs SECRET_LEAK mapping, TC-ERR-08 irrealisable, portee append-only) - 2 MINEUR (cardinalite C-01, couverture fail-closed multi-canaux)

Analyse ecart par ecart¶

E-01 — Mapping SECRET_EXPOSURE_DETECTED vs SECRET_LEAK_DETECTED (MAJEUR → MINEUR)¶

Review P1 : Le code d'erreur contractuel attendu est SECRET_EXPOSURE_DETECTED, alors que le plan impose SECRET_LEAK_DETECTED. Confrontation : Le plan §5.1 est explicite sur ce choix : "Semantique identique. Le test PD-177 verifie que SECRET_LEAK_DETECTED est emis. Le mapping dans les tests fait la correspondance." La spec utilise SECRET_EXPOSURE_DETECTED comme nom de haut niveau ; le code existant PD-52 utilise SECRET_LEAK_DETECTED (deja present dans l'enum). Le plan CHOISIT de reutiliser le code existant plutot que de creer un doublon semantiquement identique. Ce n'est pas un oubli mais une decision documentee. L'ecart est documentaire (le test TC-ERR-08 dit "le mapping vers BlockchainErrorCode=SECRET_EXPOSURE_DETECTED est observable" — il devrait dire SECRET_LEAK_DETECTED). La correction est triviale : un alias ou une note de mapping dans le test. Verdict : MINEUR — Decision de design documentee (§5.1). Le mapping est explicite. L'ecart est reduit a une divergence de nommage dans le test TC-ERR-08.

E-02 — TC-ERR-08 irrealisable (MAJEUR → MINEUR)¶

Review P1 : TC-ERR-08 exige SECRET_EXPOSURE_DETECTED mais le plan mappe vers SECRET_LEAK_DETECTED. Confrontation : Cet ecart est le corollaire direct de E-01. Le test est parfaitement realisable — il suffit de verifier que SECRET_LEAK_DETECTED est emis (meme semantique). Le plan §5.1 documente explicitement cette correspondance. Le mot "irrealisable" est excessif : le test verifie un comportement (blocage + incident securite), pas un string literal. Le mapping spec→code est un detail d'implementation explicitement couvert par le tableau §5.1. En implementation (etape 6), le test verifiera SECRET_LEAK_DETECTED conformement au plan. Verdict : MINEUR — Le test est realisable avec le code existant. L'ecart est un renommage documentaire, pas une impossibilite technique.

E-03 — Portee append-only FINALIZED vs general (MAJEUR → MINEUR)¶

Review P1 : La spec impose UPDATE/DELETE interdit par le service PD-177 (portee generale), mais le plan restreint aux batches FINALIZED. Confrontation : La spec dit : "protection applicative interdisant UPDATE/DELETE par le service PD-177". Le plan CA-177-06 dit : "refus applicatif d'UPDATE/DELETE sur status=FINALIZED". Le reviewer a raison qu'il y a une difference de portee. Cependant, le flux PD-177 est le suivant : 1. submitBatch() cree une entree avec status=SUBMITTED 2. confirmBatch() met a jour le status de SUBMITTED a CONFIRMED puis FINALIZED 3. Une fois FINALIZED, plus aucune modification.

Si la protection bloque UPDATE/DELETE des le SUBMITTED, alors l'etape 2 (passage SUBMITTED→CONFIRMED→FINALIZED) serait impossible. Le pattern PD-55 existant est exactement le meme : le batch passe par plusieurs statuts (PENDING→SUBMITTED→CONFIRMED→FINALIZED) et la protection append-only s'applique une fois FINALIZED. La spec dit "immutable apres ecriture" (CA-177-06), ce qui designe le moment ou l'entree est complete (= FINALIZED avec tous les champs). Le plan est coherent avec le flux existant PD-55. Verdict : MINEUR — La restriction a FINALIZED est correcte pour le flux de traitement. L'ecart est documentaire : le plan pourrait preciser que "append-only" signifie "aucune modification apres FINALIZED, les transitions de statut internes sont des progressions".

E-04 — Cardinalite C-01 : 3 vs 4 codes (CONFIRME MINEUR)¶

Review P1 : §1.1 annonce 3 codes mais §5.3 en liste 4. Confrontation : Le tableau §1.1 C-01 dit "Ajout de 3 codes : INVALID_CUSTODY_MODE, SIGNATURE_FAILED, PROOF_LINK_INCOMPLETE (aliases ou nouveaux codes — voir §5)". Le §5.3 ajoute aussi TRANSACTION_REORGED_OR_ABANDONED. Le texte §1.1 mentionne "voir §5" ce qui renvoie au tableau complet. L'ecart est documentaire — la nature du code est correctement definie en §5, et le §1.1 est un resume. Verdict : MINEUR CONFIRME.

E-05 — Couverture fail-closed multi-canaux (CONFIRME MINEUR)¶

Review P1 : La demonstration fail-closed est detaillee pour HTTP mais pas exhaustivement pour les autres canaux (logger wrapper). Confrontation : Le plan §7.2 mentionne explicitement 3 points d'application : (1) Interceptor global NestJS pour les controllers, (2) Logger wrapper pour les services blockchain, (3) BlockchainError.context existant. Le point (2) est mentionne mais pas detaille avec le meme niveau que le point (1). Cependant, le plan §7.3 explique maintenant le mecanisme de maniere precise. L'ecart est reel : le logger wrapper n'a pas de description contractuelle aussi detaillee que l'interceptor HTTP. Verdict : MINEUR CONFIRME.

Synthese de la confrontation v2¶

Bilan confrontation v2 : 0 BLOQUANT, 0 MAJEUR, 5 MINEUR, 0 REJETES.

Score P1 (ChatGPT) : 7.0/10 (3 ecarts surclasses de MAJEUR a MINEUR — la review est plus severe que justifie) Score P2 (Claude) : 8.5/10 (plan v1.1 solide, corrections effectives, ecarts residuels tous MINEUR)

Analyse de la regression de score v1→v2 : ChatGPT propose un score v2 (7.50) inferieur au v1 (7.75). Ceci est incoherent car 8 ecarts ont ete corriges et seulement 5 nouveaux ecarts identifies (tous MINEUR apres confrontation). La regression de score semble due a une surclassification des 3 ecarts comme MAJEUR.