Ne publiez jamais une vulnérabilité contenant des données clients dans une issue publique. Transmettez le scénario, la route concernée, l'impact et une preuve minimale au propriétaire du dépôt afin qu'un correctif privé puisse être préparé et testé.

Chaque pull request exécute :

• installation déterministe avec npm ci ;
• audit des dépendances réellement déployées avec npm audit --omit=dev --audit-level=high ;
• lint complet ;
• build Vinext et validation de l'artefact Worker ;
• tests d'authentification, PWA, migrations et codes agents.

Les secrets OpenAI, Wave et Flutterwave sont configurés dans Sites et ne doivent jamais être committés. Les fichiers .env restent ignorés ; seul .env.example, sans valeur secrète, est versionné.

L'audit complet peut encore signaler des dépendances de développement que l'audit de production exclut :

• image-size, imposé par Vinext, est utilisé pendant la construction et n'est pas appelé par le code métier sur les fichiers téléversés ; aucune version corrigée n'est actuellement publiée dans la branche Vinext utilisée par Sites.
• une ancienne version d'esbuild, transitive de drizzle-kit, est limitée à la génération locale de migrations. Le serveur de développement ne doit jamais être exposé sur un réseau non fiable.

Ces exceptions ne couvrent pas le runtime de production, pour lequel l'audit doit rester à zéro vulnérabilité élevée. Elles doivent être supprimées dès qu'une version compatible de Vinext ou Drizzle corrige les dépendances transitives. Tout changement de version doit repasser l'intégralité de la CI et un déploiement de validation.

1. Révoquer immédiatement tout secret potentiellement exposé.
2. Restreindre l'accès Sites et suspendre les écritures si l'intégrité des données est incertaine.
3. Conserver les journaux Worker et identifier le SHA déployé.
4. Redéployer la dernière version saine ou restaurer l'instantané D1/R2 cohérent.
5. Publier le correctif via pull request, CI et procédure d'alignement documentée dans le README.