PD-52 — Confrontation Gate 5¶

Story : PD-52 — Setup connexion Ethereum L2 (Polygon/Arbitrum) Gate : 5 — AMBIGUITY (Review Plan) Date : 2026-02-12 Contre-auditeur : Claude Opus 4.5 (subprocess)

Synthèse¶

Bilan : 0 BLOQUANT (vs 4 initiaux), 10 MAJEURS, 2 MINEURS, 3 RÉVOQUÉS

Analyse détaillée¶

ECT-PLAN-01 : S1/S3 en stub¶

Verdict : RÉDUIT

Justification : La spécification §2 mentionne "Prise en charge contractuelle des 3 scénarios de compatibilité secp256k1 (S1, S2, S3)" mais l'hypothèse H-52-07 de la spec précise : "Le custody mode initial pour l'acceptation v1 est S2 (AWS KMS). Simplification de l'intégration ; S1 (HSM) réservé pour production."

Le plan est cohérent avec cette hypothèse explicite. Les stubs S1/S3 permettent de respecter l'interface contractuelle CustodyStrategy (unicité de mode vérifiable) tout en différant l'implémentation complète. Ce n'est pas une violation de la spec mais une priorisation conforme à H-52-07.

Gravité finale : MAJEUR (les stubs doivent retourner CUSTODY_MODE_INVALID, pas échouer silencieusement)

ECT-PLAN-02 : Contradiction /health/bc vs /health/blockchain¶

Verdict : RÉVOQUÉ

Justification : L'auditeur identifie une contradiction entre "/health/bc" (dans le diagramme §2.1) et "/health/blockchain" (dans DA-05).

En réalité, "/health/bc" dans le diagramme est une abréviation visuelle pour tenir dans la boîte du schéma ASCII. La décision DA-05 et le code contract CC-52-14 spécifient explicitement GET /health/blockchain. Il n'y a pas de contradiction contractuelle, seulement une abréviation de présentation.

Gravité finale : N/A (révoqué)

ECT-PLAN-03 : INV-52-11 couverture partielle¶

Verdict : MAINTENU

Justification : L'auditeur a raison. Le mapping INV-52-11 → T-03 couvre uniquement la définition de l'enum des codes d'erreur. Il manque : - Le mécanisme de propagation uniforme (tous les services doivent utiliser BlockchainError) - La politique de journalisation (quels champs sont loggés, lesquels sont exclus)

Ces éléments devraient être explicités dans les code contracts des services (CC-52-04 à CC-52-14).

Gravité finale : MAJEUR

ECT-PLAN-04 : Écart gas non mesuré¶

Verdict : MAINTENU

Justification : Le code contract CC-52-10 (GasEstimatorService) définit estimate() et le plan §6 mentionne "marge +20%", mais il n'y a pas de mécanisme explicite pour : 1. Enregistrer le gas réellement consommé après exécution 2. Calculer l'écart relatif 3. Vérifier CA-52-05 (< 25%)

Le ConfirmationTracker (CC-52-12) devrait inclure la mesure du gas consommé dans TransactionResult.

Gravité finale : MAJEUR

ECT-PLAN-05 : Audit secrets non planifié¶

Verdict : MAINTENU

Justification : Les tâches T-20 à T-23 couvrent les tests unitaires et d'intégration, mais aucune tâche ne planifie explicitement : - Scan gitleaks/trufflehog sur le code - Audit des logs applicatifs - Vérification des variables d'environnement

CA-52-09 requiert un audit multi-couche. Ce devrait être une tâche dédiée (T-24 ?) ou intégrée dans le pipeline CI.

Gravité finale : MAJEUR

ECT-PLAN-06 : Test 10/10 non formalisé¶

Verdict : RÉDUIT

Justification : Le test TC-NOM-01 (spec tests) décrit explicitement : "10 appels consécutifs eth_blockNumber reussis". Le plan mappe CA-52-01/CA-52-02 vers T-22 (tests intégration testnet).

L'écart n'est pas que le test est irréalisable, mais que le plan ne détaille pas explicitement ce scénario. C'est un problème de granularité, pas d'impossibilité.

Gravité finale : MAJEUR (manque de détail, pas bloquant)

ECT-PLAN-07 : SLA failover non mesurable¶

Verdict : RÉDUIT

Justification : Le plan §4 mappe CA-52-07 vers T-05/T-06/T-22 et le code contract CC-52-04 spécifie : - Postcondition : "Temps total de bascule < 5 secondes" - Error_codes : [RPC_PRIMARY_FAILED, RPC_UNAVAILABLE]

Le mécanisme de mesure peut être implicite (horodatage des logs de failover). C'est un manque d'explicitation du point d'observabilité, pas une impossibilité technique.

Le test TC-NOM-09 (spec tests) définit : "Le temps total de bascule est < 5 secondes" comme observable.

Gravité finale : MAJEUR (manque d'explicitation, pas bloquant)

ECT-PLAN-08 : Wallet pré-fundé implicite¶

Verdict : MAINTENU

Justification : L'auditeur a raison. Le plan §7 liste les faucets testnet mais ne formalise pas : - Précondition : wallet fundé avant tests - Procédure de funding automatique ou manuel - Seuil minimum de fonds requis

L'hypothèse H-52-02 de la spec mentionne ce point mais le plan devrait le reprendre explicitement.

Gravité finale : MAJEUR

ECT-PLAN-09 : Infrastructure readiness implicite¶

Verdict : MAINTENU

Justification : Le plan §7 liste les variables d'environnement mais ne formalise pas : - Conditions de readiness KMS (clé créée, permissions IAM) - Conditions de readiness HSM (slot configuré) - Conditions de readiness Vault (moteur Transit activé)

Ces préconditions devraient être documentées dans une section "Prérequis d'environnement".

Gravité finale : MAJEUR

ECT-PLAN-10 : Non-identifiance des métadonnées¶

Verdict : RÉDUIT

Justification : Le plan DA-04 définit une validation whitelist stricte. Le format de transaction type (§3 spec) est : data=keccak256("ProbatioVault:anchor:test:" || timestamp_unix)

Ce payload ne contient que : - Un préfixe fixe (non identifiant) - Un timestamp unix (non identifiant individuellement)

Le risque de corrélation existe théoriquement mais est minimal pour un timestamp. L'écart est valide mais mineur.

Gravité finale : MINEUR

ECT-PLAN-11 : 14 vs 15 codes d'erreur¶

Verdict : RÉVOQUÉ

Justification : L'auditeur compte 15 codes dans CC-52-02 mais la spec §6 définit bien 14 codes (ERR-52-01 à ERR-52-14).

En relisant CC-52-02, l'enum contient : 1. RPC_PRIMARY_FAILED 2. RPC_UNAVAILABLE 3. CUSTODY_MODE_MISSING 4. CUSTODY_MODE_INVALID 5. CUSTODY_MODE_AMBIGUOUS 6. CUSTODY_MODE_UNKNOWN 7. SIGNATURE_VERIFICATION_FAILED 8. INSUFFICIENT_FUNDS 9. GAS_PRICE_CEILING_EXCEEDED 10. TRANSACTION_REORG 11. TRANSACTION_ABANDONED (ajout pour ERR-52-08 timeout 60s) 12. SECRET_LEAK_DETECTED 13. RPC_INVALID_ENDPOINT 14. MAINNET_FORBIDDEN 15. PAYLOAD_VALIDATION_FAILED

TRANSACTION_ABANDONED est dérivé de ERR-52-08 : "Si la transaction ne reapparait pas [...] après 60 secondes, elle est marquée TRANSACTION_ABANDONED."

C'est un code distinct de TRANSACTION_REORG, conforme à la spec. L'auditeur a mal compté les codes de la spec.

Gravité finale : N/A (révoqué)

ECT-PLAN-12 : Composants sans code contract¶

Verdict : MAINTENU

Justification : L'auditeur a raison. Les fichiers suivants n'ont pas de code contract dédié : - providers/rpc-health.service.ts - custody/custody.guard.ts - wallet/wallet.validator.ts - validators/chain-id.guard.ts - dto/*.ts - blockchain.module.ts

Ces composants devraient avoir au minimum une interface et des postconditions définies.

Gravité finale : MAJEUR

ECT-PLAN-13 : Seuil confirmations absent de CC-52-01¶

Verdict : RÉVOQUÉ

Justification : L'auditeur affirme que CC-52-01 ne liste pas les seuils de confirmations. C'est incorrect.

L'interface NetworkConfig dans CC-52-01 inclut explicitement :

export interface NetworkConfig {
  chainId: number;
  rpcPrimary: string;
  rpcSecondary: string;
  confirmations: number;  // Polygon=5, Arbitrum=1
}

Le champ confirmations est présent et commenté avec les valeurs par défaut. INV-52-13 est couvert.

Gravité finale : N/A (révoqué)

ECT-PLAN-14 : MAINNET_FORBIDDEN chevauchement¶

Verdict : MAINTENU

Justification : L'écart est valide. MAINNET_FORBIDDEN apparaît dans : - CC-52-09 (PayloadValidator) : détection de chain ID mainnet dans le contexte de validation - CC-52-03 (chain-ids) : fonctions utilitaires isMainnetChainId()

Le chevauchement est mineur car chain-id.guard utilise les fonctions de chain-ids.ts, et le code d'erreur peut être émis depuis plusieurs points (défense en profondeur).

Gravité finale : MINEUR

ECT-PLAN-15 : Couverture >= 80% non formalisée¶

Verdict : MAINTENU

Justification : L'auditeur a raison. Le plan mentionne "couverture tests >= 80%" dans les métriques de succès (§1) et le code contract CC-52-19 (tests intégration) mentionne les coverage_targets, mais : - Aucune tâche ne formalise la génération du rapport de couverture - Aucun artefact de preuve n'est défini (rapport Jest/Istanbul)

CA-52-12 requiert : "Pipeline CI vert incluant tests unitaires + integration; couverture unitaire >= 80%."

Gravité finale : MAJEUR

Écarts actifs après confrontation¶

MAJEURS (10)¶

MINEURS (2)¶

RÉVOQUÉS (3)¶

Recommandation¶

Verdict préliminaire : RESERVE

Le plan est globalement cohérent et couvre les invariants majeurs. Les écarts identifiés sont des manques d'explicitation plutôt que des violations de la spec. Ils peuvent être corrigés en ajoutant :

1. Des code contracts pour les composants manquants
2. Une section "Préconditions d'environnement"
3. Des détails sur les points d'observabilité dans les tâches de test
4. Une tâche dédiée à l'audit de secrets

Aucun écart BLOQUANT ne subsiste après confrontation.