Modifier un monorepo auto-hébergé d’automatisation des certificats sans exposer de secrets

## Comprendre le cycle de vie des certificats et les secrets stockés par le système Traitez le système comme un produit privé et auto-hébergé qui gère la demande, le renouvellement, le déploiement, la supervision et la notification des certificats, ainsi que les intégrations par API. Son pipeline principal peut demander des certificats par ACME, effectuer une validation DNS-01, HTTP-01, par proxy CNAME ou propre à un fournisseur, exporter des formats tels que PEM, PFX, DER, JKS et P7B, puis déployer les certificats vers des serveurs, des proxies, des clusters, des CDN, des services cloud ou des panneaux de contrôle. Le système stocke des certificats, des identifiants de services cloud, des informations SSH, des clés d’API et d’autres configurations sensibles. N’exposez jamais de données locales ni de secrets dans les modifications du code source, les logs, les fixtures, les captures d’écran, les rapports ou les métadonnées générées. ## Garder séparés les workspaces du monorepo et ne pas toucher aux données d’exécution Utilisez le gestionnaire de paquets, la définition des espaces de travail et le fichier de verrouillage désignés par le dépôt ; n’introduisez pas de fichier de verrouillage provenant d’un autre gestionnaire de paquets. Si un package constitue un espace de travail indépendant dans le système de gestion de versions, examinez son état et son diff depuis cet espace de travail et séparez ses modifications de celles du dépôt racine. Ne modifiez pas et n’incluez pas dans un commit les données d’exécution, les logs, les résultats temporaires, les métadonnées générées, les distributions ou les manifestes de plugins exportés, sauf si la tâche les vise explicitement. Un répertoire de dépendances d’exécution peut être consulté en lecture seule lorsqu’il faut comprendre un SDK installé dynamiquement, mais ce répertoire n’est pas du code source et ne doit pas entrer dans l’ensemble des modifications. ## Placer chaque changement dans le paquet ou le plugin responsable Déterminez la responsabilité avant toute modification : les clients de protocole sont responsables du comportement des comptes, des commandes et des challenges ; les packages du pipeline, des modèles d’exécution et des cycles de vie des tâches ; les modules serveur, des entités, services, contrôleurs, autorisations et migrations ; les modules client, des vues, formulaires, routes et adaptateurs d’API ; les plugins des fournisseurs, du comportement de DNS, de déploiement et de notification propre à chaque fournisseur. Conservez un défaut propre à un seul fournisseur dans le plugin de ce fournisseur. Ne transférez un comportement vers le cœur du pipeline ou une bibliothèque partagée de plugins que s’il exprime une sémantique réutilisable qui doit rester cohérente entre les fournisseurs. Préférez les modules, services, composants et modèles de plugins établis aux implémentations parallèles. ## Utiliser les commandes propres à chaque paquet sans installer de dépendances en plus Lisez les commandes documentées avant d’exécuter une validation. Utilisez les commandes de tests unitaires, de lint, de formatage et de build propres au package concerné, et n’élargissez les contrôles que lorsque la modification franchit clairement les limites de plusieurs packages. Ne remplacez pas une validation par fichier prise en charge par une vérification de types connue pour être défectueuse ni par un script de test provisoire. N’installez pas de dépendances de manière préventive. Si des dépendances manquantes, des exigences liées au terminal ou l’accès au réseau empêchent un contrôle nécessaire, arrêtez cette tentative et signalez la limite de l’environnement. Lorsque le comportement d’un SDK dépend de sa version, examinez la dépendance d’exécution réellement installée et la documentation qui l’accompagne, au lieu de vous fier à votre mémoire ou à une autre version. ## Écrire du code lisible avec des étapes nommées et des commentaires qui expliquent pourquoi Privilégiez la lisibilité plutôt qu’une syntaxe compacte. Décomposez les conditions complexes, les opérateurs ternaires imbriqués, les longues chaînes, les objets inline et les appels d’utilitaires sur plusieurs couches en valeurs intermédiaires clairement nommées ou en méthodes ciblées. Ne placez pas un appel de méthode directement dans l’argument d’une autre méthode lorsqu’une variable locale explicite peut rendre la transition visible. Utilisez des paramètres sous forme d’objet lorsqu’une méthode nécessiterait autrement plus de trois arguments. Expliquez dans les commentaires pourquoi les règles métier, les contraintes de compatibilité, les détails du protocole et les risques cachés existent. Gardez la logique simple à son point d’utilisation, mais extrayez les règles métier, les conversions de champs, les contrôles d’autorisation, la sélection de dépôts, la propagation des transactions ou les calculs récurrents lorsque leurs copies doivent rester synchronisées. ## Écrire d’abord un test qui échoue, puis faire la plus petite correction Ajoutez des tests unitaires ciblés pour le comportement métier principal. Pour une nouvelle fonctionnalité ou la correction d’un défaut, commencez de préférence par un test qui reproduit le comportement attendu et échoue avant l’implémentation ; apportez ensuite la plus petite modification et relancez le test du package. Si un test ajouté ultérieurement exige de changer un comportement établi, confirmez avant de le modifier qu’il s’agit d’un défaut et non d’une exigence existante. Placez les tests unitaires purs près du code source et excluez-les des builds de production. Utilisez un outil adapté de simulation de modules pour les imports ESM statiques, au lieu de restructurer le code de production uniquement pour le test. Définissez explicitement l’environnement des tests unitaires du package et n’exécutez des builds plus larges que lorsque l’impact entre plusieurs packages les rend nécessaires. ## Accompagner chaque changement de table d’une migration SQL et bien transmettre les transactions Associez toute modification de la structure d’une table à une migration SQL explicite ; ne vous fiez jamais à la synchronisation de schéma de l’ORM. Faites passer les clés temporaires d’upload par le service de fichiers approuvé avant de les stocker de façon permanente, et préservez le propriétaire requis ainsi que la visibilité publique ou privée. Pour propager une transaction, transmettez un contexte contenant le gestionnaire de transactions facultatif avant l’objet de requête, puis utilisez les utilitaires partagés de dépôt et de transaction. N’ajoutez pas de contexte de transaction aux requêtes simples ni aux fonctions pures. Construisez les prédicats facultatifs de tenant ou de projet avec l’utilitaire de requête canonique, afin que les valeurs null ou undefined ne puissent pas devenir une condition d’égalité incorrecte. Évitez les noms et les signatures de méthodes de service qui entrent en conflit avec des méthodes de base héritées. Choisissez des noms précis qui préservent le contrat de base et rendent explicite la portée de l’opération. ## Construire les écrans d’administration avec le framework CRUD et les dialogues de formulaire existants Repérez la vue responsable de la fonctionnalité et son module d’API avant toute modification. Utilisez le framework CRUD approuvé pour l’administration courante, la recherche d’enregistrements et la gestion par tableaux. Ne créez une liste personnalisée que pour une présentation légère en lecture seule, une interface fortement interactive ou une incompatibilité documentée avec le framework standard. Les grilles de données intégrées nécessitent une hauteur stable ou une chaîne flex ininterrompue dont les éléments enfants peuvent rétrécir. Réutilisez les dictionnaires distants établis pour les champs d’identité consultables. Une confirmation simple peut utiliser une boîte de dialogue de confirmation, mais toute boîte de dialogue qui recueille des champs, valide des saisies ou envoie des valeurs supplémentaires doit utiliser l’abstraction de dialogue de formulaire approuvée. Lorsque la vérification de types étendue ou la commande unitaire du dépôt est connue pour être invalide, exécutez uniquement le formateur et le linter pris en charge sur les fichiers client modifiés. ## Corriger les problèmes de certificat dans la bonne couche et protéger les clés de compte Examinez les plugins des fournisseurs avant de modifier le code partagé du pipeline, et inspectez le SDK effectivement installé de manière dynamique lorsque le comportement d’un fournisseur dépend de sa version. Avant d’appliquer une correction, déterminez si le problème de certificat relève du client ACME, de l’exécution du pipeline, d’un service serveur, d’un plugin de fournisseur, d’un utilitaire partagé de certificats ou du formulaire client. Utilisez une opération de compte limitée à la consultation avec la clé privée du compte existant lorsque le client du protocole peut récupérer l’URL d’un compte existant sans consommer de nouveau matériel de liaison de compte externe. Si un identifiant de liaison de compte externe change, générez une nouvelle clé privée de compte liée à cet identifiant ; sinon, bloquez l’émission et exigez l’actualisation de la clé du compte. Gardez les valeurs des identifiants d’accès hors du code, des logs, des tests, des rapports et des artefacts inclus dans les commits. Préservez les limites de validation et d’autorisation lorsque vous étendez les flux d’upload, de déploiement, de notification ou d’API ouverte. ## Garder le comportement des anciens réglages et indiquer quels contrôles ont tourné Lors de l’ajout d’un paramètre de plugin, gérez son absence dans les configurations héritées stockées et préservez le comportement antérieur, sauf si une migration le modifie explicitement. Ne réinterprétez pas une valeur absente comme un nouveau mode sans branche de compatibilité définie. Avant de terminer, examinez le diff ciblé, vérifiez séparément la racine et chaque espace de travail imbriqué, exécutez les tests directement concernés et les contrôles de formatage ou de lint par fichier, puis confirmez les migrations nécessaires. Assurez-vous que les données d’exécution et les résultats générés restent hors de l’ensemble des modifications. Indiquez ce qui a changé, les contrôles réussis, les contrôles qui n’ont pas pu être exécutés et la raison pour laquelle une validation plus large était hors périmètre.