PD-177 - Scenarios de test de reference¶

0. Cadre de validation et prerequis explicites¶

• Environnement de test isole, reproductible, avec configuration versionnee (modes custody, reseaux cibles, plafond gas, politique de confirmations par reseau, endpoints RPC primaire/secondaire).
• Jeu de donnees fixe:
• MERKLE_ROOT_OK_1 et MERKLE_ROOT_OK_2 valides.
• MERKLE_ROOT_INCOMPLETE pour simuler une preuve incompletement liee.
• Identifiant d'ancrage interne deterministic (ANCHOR_ID_REF_001, etc.) pour les assertions de liaison.
• Simulateurs deterministes disponibles pour: INSUFFICIENT_FUNDS, GAS_PRICE_CEILING_EXCEEDED, indisponibilite RPC primaire/secondaire, echec de signature, reorg.
• Politique de confirmations contractualisee active en test: chainId=137 -> 12 confirmations, timeout=900s; chainId=42161 -> 30 confirmations, timeout=900s.
• Format d'horodatage attendu pour toutes les assertions temporelles: ISO 8601 UTC avec millisecondes (exemple: 2026-02-23T14:30:00.000Z).
• Collecte centralisee et horodatee des artefacts verifiables: logs applicatifs, evenements securite, registre append-only, preuve composite, statut transactionnel, codes d'erreur.
• Regle de preuve: un test est PASS uniquement si les assertions Then sont verifiees par artefact observable (et non par interpretation implicite).

1. Matrice de couverture (INV/CA -> TC)¶

2. Scenarios de test (Given / When / Then)¶

TC-177-01 - Unicite du wallet officiel actif¶

Given une configuration de production PD-177 valide When le systeme initialise le wallet officiel et expose l'adresse active Then exactement une adresse wallet officielle active est observable pour le contexte de production And toute requete de lecture de l'adresse officielle retourne cette meme adresse tant qu'aucune rotation n'est declenchee

TC-177-02 - Gate custody S2 uniquement¶

Given trois executions identiques, avec BLOCKCHAIN_CUSTODY_MODE=S2, puis S1, puis S3 When le service wallet/custody est initialise Then l'initialisation aboutit uniquement en S2 And les modes S1 et S3 echouent avec code d'erreur explicite

TC-177-03 - Conformite stricte du contrat CustodyStrategy¶

Given l'integration PD-177 candidate When la suite de validation de contrat execute initialize, getAddress, signMessage, signTransaction, validateCapability Then les 5 methodes sont presentes et executables sans rupture de signature contractuelle And aucune methode additionnelle requise n'est introduite comme prerequis bloquant

TC-177-04 - Emission nominale d'ancrage (tx_hash non vide)¶

Given MERKLE_ROOT_OK_1 et un reseau cible disponible When une transaction d'ancrage est emise Then un tx_hash non vide est retourne And le statut initial de suivi est trace

TC-177-05 - Confirmation reseau positive dans la fenetre configuree¶

Given deux transactions d'ancrage emises depuis TC-177-04, l'une sur chainId=137 et l'autre sur chainId=42161 When le suivi de confirmation reseau s'execute jusqu'a la limite des fenetres configurees Then chainId=137 est confirme apres au moins 12 confirmations avant timeout=900s And chainId=42161 est confirme apres au moins 30 confirmations avant timeout=900s And l'horodatage de confirmation est enregistre au format ISO 8601 UTC avec millisecondes

TC-177-06 - Contenu minimal et immutabilite append-only¶

Given un ancrage confirme When l'entree append-only correspondante est lue puis une tentative de modification est effectuee Then l'entree contient au minimum: identifiant ancrage interne, Merkle root, signer_address, chainId, tx_hash, horodatage d'emission au format ISO 8601 UTC avec millisecondes, etat de confirmation And la tentative de modification destructive est refusee ou tracee comme non autorisee sans alteration de l'enregistrement initial

TC-177-07 - Preuve composite conforme blockchain¶

Given un ancrage confirme et sa preuve composite When la preuve composite est validee Then le champ blockchain est present et vaut ethereum_l2 And le lien vers tx_hash est present et coherent avec le registre append-only And si une entree blockchain=tezos est recue par un service PD-177, aucune emission d'ancrage PD-177 n'est produite (ignore/passthrough hors perimetre)

TC-177-08 - Association de toute emission au wallet actif¶

Given un wallet officiel actif A puis une rotation vers B planifiee When des transactions sont emises avant et apres la bascule Then chaque transaction est associee a l'adresse active au moment exact de son emission And aucune transaction n'est associee a une adresse non active a cet instant

TC-177-09 - Exclusivite d'usage ancrage et absence de transaction arbitraire¶

Given les endpoints, files de jobs et commandes exposes par PD-177 When des requetes d'usage non-ancrage (DEX/DeFi, ERC-20, transfert metier tiers) sont tentees et qu'une tentative de diffusion arbitraire est effectuee Then elles sont rejetees explicitement hors perimetre And aucune methode de type sendRawTransaction n'est exposee hors du flux d'ancrage And aucune transaction non probatoire n'est emise par le wallet officiel

TC-177-10 - Delegation de signature a custody¶

Given le worker d'ancrage en fonctionnement nominal When une transaction est preparee puis signee Then la signature est executee via la couche wallet/custody And aucune signature directe par le worker n'est observee dans les artefacts d'execution

TC-177-11 - Liaison deterministe transaction <-> append-only¶

Given un lot de N ancrages valides emis sequentiellement When les liaisons internes sont reconstruites depuis les artefacts Then chaque tx_hash correspond a une et une seule entree append-only And la regle de liaison est deterministic et reproductible a executions equivalentes

TC-177-12 - Reconstruction tierce de la chaine de preuve¶

Given un tiers auditeur sans acces a des secrets internes When il recoit Merkle root, entree append-only, tx_hash, etat de confirmation et preuve composite Then il peut verifier la correspondance Merkle root <-> transaction <-> confirmation <-> preuve composite And aucune dependance a un secret interne n'est necessaire pour conclure

TC-177-13 - Regle de finalisation stricte¶

Given trois transactions en suivi: confirmee, abandonnee, en echec non confirme When le moteur de statut termine l'evaluation Then seule la transaction confirmee est marquee finalise And les deux autres portent un statut explicite non-finalise conforme au code d'erreur

TC-177-14 - Rotation planifiee sans perte d'auditabilite¶

Given des preuves signees avant rotation et des preuves signees apres rotation When un audit historique est execute sur la periode complete Then les preuves pre-rotation restent verifiables avec leur contexte historique d'adresse And la transition n'introduit aucune rupture de chaine de preuve And ce test valide la preservation d'auditabilite lors d'une rotation simulee uniquement (declencheurs de rotation CL-177-01 non formalises)

TC-177-15 - Procedure de reprise wallet documentee et testee¶

Given une procedure de reprise versionnee et un scenario d'incident custody simule When l'exercice de reprise est execute selon la procedure Then le resultat est consigne, horodate et auditable And le statut final de l'exercice (reussi/echoue) est explicite

TC-177-16 - Conformite generation UUID via crypto.randomUUID¶

Given un environnement de test instrumente pour observer la source de generation des UUID techniques PD-177 When les operations generant ces identifiants sont executees Then chaque identifiant observe est produit via crypto.randomUUID() And le format des UUID observes est conforme au format attendu

TC-177-17 - Prefixe des cles ephemeres de test¶

Given des cles ephemeres de test introduites dans le perimetre PD-177 When leurs identifiants sont enumeres Then chaque identifiant commence par pv-test- And toute cle ne respectant pas ce prefixe est rejetee

TC-177-18 - Validation locale des migrations schema (lecon PD-55)¶

Given toute migration de schema introduite par PD-177 When la validation locale complete est executee avant integration Then elle se termine sans erreur PostgreSQL liee aux indexes partiels non supportes And le resultat de validation est archivable comme preuve de conformite process

TC-177-19 - Conformite BullMQ sans API depreciee¶

Given les interactions BullMQ introduites/majorees par PD-177 When une verification statique + executionnelle est lancee Then aucune utilisation de getRepeatableJobs ni removeRepeatableByKey n'est detectee And les APIs non depreciees requises sont utilisees

3. Tests de securite (invariants securite)¶

TC-SEC-01 - Absence de secrets en clair¶

Given un cycle nominal complet (initialisation, signature, emission, confirmation) When les logs applicatifs, traces d'erreur (y compris stack traces), enregistrements de persistance, reponses API et variables d'environnement runtime sont analyses Then aucun materiau de cle privee ou secret sensible n'apparait en clair And toute valeur sensible est absente ou redigee selon la politique de secret

TC-SEC-02 - Detection active de fuite de secret¶

Given une tentative injectee de sortie de secret vers log/erreur When le controle de securite detecte la tentative Then l'operation courante est bloquee avec echec explicite avant emission vers le canal de sortie (fail-closed) And un incident securite est cree avec identifiant, horodatage et contexte

TC-SEC-03 - Compromission serveur applicatif seule insuffisante¶

Given un scenario ou le serveur applicatif est compromis (execution de code arbitraire Node.js) mais sans acces aux credentials custody (tokens IAM, cles API KMS) When une signature arbitraire de transaction est tentee Then la signature est refusee And aucune transaction signee exploitable n'est produite

4. Tests d'erreur (ERR-177-01 a ERR-177-08)¶

TC-ERR-01 - Mode custody invalide (ERR-177-01)¶

Given BLOCKCHAIN_CUSTODY_MODE different de S2 When l'initialisation wallet/custody est lancee dans le contexte PD-177 Then l'initialisation est refusee And le code d'erreur explicite ERR-177-01 est trace avec BlockchainErrorCode=INVALID_CUSTODY_MODE

TC-ERR-02 - Echec de signature (ERR-177-02)¶

Given une indisponibilite ou refus de signature cote custody When une transaction d'ancrage doit etre signee Then l'operation echoue explicitement avec ERR-177-02 And aucun secret n'est expose dans les traces d'erreur And le mapping vers BlockchainErrorCode=SIGNATURE_FAILED est observable

TC-ERR-03 - Fonds insuffisants (ERR-177-03)¶

Given la simulation INSUFFICIENT_FUNDS When une emission d'ancrage est tentee Then l'operation echoue explicitement avec ERR-177-03 And une alerte operationnelle est emise And aucun statut finalise n'est produit And le mapping vers BlockchainErrorCode=INSUFFICIENT_FUNDS est observable

TC-ERR-04 - Gas au-dessus plafond (ERR-177-04)¶

Given la simulation GAS_PRICE_CEILING_EXCEEDED When une emission d'ancrage est tentee Then la transaction n'est pas emise And l'erreur explicite ERR-177-04 et l'alerte associee sont tracees And le mapping vers BlockchainErrorCode=GAS_PRICE_CEILING_EXCEEDED est observable

TC-ERR-05 - Echec RPC primaire/secondaire (ERR-177-05)¶

Given une indisponibilite RPC primaire puis secondaire When une emission d'ancrage est tentee Then l'operation echoue avec ERR-177-05 And aucun succes fictif ni statut finalise n'est ecrit And le mapping vers BlockchainErrorCode=RPC_UNAVAILABLE est observable

TC-ERR-06 - Reorg / abandon transaction (ERR-177-06)¶

Given une transaction initialement incluse puis invalidee par reorg When le suivi de confirmation termine Then le statut final est abandonnee (ou equivalent non-finalise defini) And aucun marquage finalise errone n'est present And le mapping vers BlockchainErrorCode=TRANSACTION_REORGED_OR_ABANDONED est observable

TC-ERR-07 - Donnees de preuve incompletes (ERR-177-07)¶

Given un dossier de preuve ou la liaison Merkle root <-> tx_hash <-> confirmation est incomplete When la verification probatoire est executee Then la preuve est declaree invalide avec ERR-177-07 And la cause d'invalidite est explicitement tracee And le mapping vers BlockchainErrorCode=PROOF_LINK_INCOMPLETE est observable

TC-ERR-08 - Exposition de secret detectee (ERR-177-08)¶

Given une detection d'exposition de secret pendant une operation d'ancrage When le controle de securite est declenche Then un incident securite obligatoire est cree And l'operation courante est bloquee avec ERR-177-08 And le mapping vers BlockchainErrorCode=SECRET_EXPOSURE_DETECTED est observable

5. Regles explicitement NON TESTABLES (etat actuel)¶

• NON TESTABLE - CL-177-01 (periodicite et declencheurs de rotation): absence de valeur contractuelle cible dans la specification, donc impossible de verifier conformite temporelle; TC-177-14 couvre uniquement la preservation d'auditabilite lors d'une rotation simulee.
• NON TESTABLE - CL-177-02 (seuil de solde minimal et delai de refill): seuil/delai non normatifs, seuls les comportements d'erreur sont testables.
• NON TESTABLE - CL-177-03 (cloisonnement testnet/mainnet): criteres mesurables non specifies.
• NON TESTABLE - CL-177-04 (RTO/RPO reprise custody): objectifs quantifies non fournis.
• NON TESTABLE - CL-177-06 (obligation de declaration publique/juridique adresse): exigence gouvernance/compliance non formalisee en critere mesurable dans PD-177.
• NON TESTABLE - CL-177-07 (criteres de souverainete mesurables): absence de metriques contractuelles opposables.
• NON TESTABLE - CL-177-08 (perennite 10-50 ans): explicitement hors perimetre story.

6. Verdict¶

• Couverture INV: 21/21 invariants couverts par >=1 TC.
• Couverture CA: 17/17 criteres d'acceptation couverts par >=1 TC.
• Couverture ERR: 8/8 cas d'erreur couverts par un scenario dedie.
• Lacunes identifiees: uniquement les points "a clarifier" non formalises en exigences mesurables (section NON TESTABLE).
• Verdict global: couverture contractuelle PD-177 atteinte pour le perimetre testable; conformite objectivement evaluable sous reserve de lever les points NON TESTABLE.