| HT-01 | L'entity LegalCompositeProof (schema vault_secure) expose un champ proofId UUID v4 qui servira de cle d'entree pour la verification | Si non, il faudra trouver ou creer la table/colonne de reference des preuves |
| HT-02 | L'enum PostgreSQL check_result est utilise dans integrity_check_attempts et potentiellement dans d'autres tables de verification ; ALTER TYPE ADD VALUE est supporte sans downtime | Si non, migration complexe avec recreation de type |
| HT-03 | Le champ chain_blockchain dans IntegrityCheckAttempt a deja default: 'PENDING' en DB — ce qui confirme que PostgreSQL accepte deja la string 'PENDING' meme si l'enum TypeScript ne le contient pas | Si l'enum PostgreSQL est stricte et ne contient que 3 valeurs, la migration ALTER TYPE est necessaire |
| HT-04 | La table anchor_batches (schema vault_blockchain) contient un champ status avec au moins la valeur 'PENDING_FINALITY' pour detecter les maillons blockchain en attente | Si non, le mecanisme de detection PENDING_FINALITY doit etre adapte |
| HT-05 | Le verificationRequestId sera genere par le serveur via crypto.randomUUID() et stocke en association avec le proofId (table de cache ou colonne additionnelle) | Si non, un autre mecanisme d'identification doit etre concu |
| HT-06 | Les timestamps pending_since par maillon sont disponibles ou derivables depuis les donnees existantes pour calculer l'expiration SLA | Si non, une colonne pending_since doit etre ajoutee a la migration |