Créer un outil qui relit et corrige le code avec l’IA sans perdre le code de l’utilisateur

## Lire le build et les documents de responsabilité avant de modifier le code Avant de modifier le code, lisez le point d’entrée, la carte des paquets, la définition de compilation et les documents de responsabilité du dépôt. Considérez les copies générées et les résumés pratiques comme des pointeurs, et non comme des sources de vérité concurrentes. ### Repérage dans le dépôt - Repérez les points d’entrée exécutables, les paquets d’implémentation, l’infrastructure partagée et le système de compilation. - Utilisez la définition de compilation comme liste de commandes actuelle au lieu de copier des commandes dans des consignes susceptibles de devenir obsolètes. - Déterminez quel document ou fichier source fait autorité pour chaque comportement public, clé de configuration, variable d’environnement et invariant opérationnel. - Rendez explicites les adaptateurs propres à chaque hôte. Fixez les hypothèses relatives aux versions des outils externes en ligne de commande et utilisez des solutions de repli d’API stables lorsque l’état de l’arbre de travail rend les commandes de haut niveau peu fiables. ### Portes de vérification - Formatez le code et exécutez le linter avant la remise, y compris les contrôles de dérive des artefacts générés. - Exécutez des tests ciblés pendant les itérations, puis les suites faisant autorité de tests unitaires, d’intégration, de conditions de concurrence et de bout en bout exigées par la frontière modifiée. - Préférez les tests de bout en bout pour les comportements liés aux processus, aux E/S, à la configuration, à Git, aux démons et aux fixtures enregistrées ; testez les fonctions auxiliaires pures avec des tests unitaires pour gagner en rapidité et localiser les défaillances. - Compilez le véritable exécutable après toute modification non triviale. - Utilisez le développement piloté par les tests pour les corrections de bogues et les fonctionnalités, et conservez les travaux non résolus dans le gestionnaire de tickets au lieu de les dissimuler dans des modifications sans rapport. ## Arrêter tous les processus enfants à l’annulation et passer explicitement le répertoire Git Une automatisation de longue durée doit maîtriser son annulation, ses descendants, son état partagé et ses effets sur le système de fichiers sur chaque système d’exploitation pris en charge. ### Discipline des processus - Propagez les contextes d’annulation dans les travaux de longue durée, les sous-processus et les opérations réseau. - Définissez des délais d’expiration bornés pour le nettoyage, les sondes et les appels HTTP. - Placez les sous-processus annulables dans une frontière d’arborescence de processus afin que l’annulation mette fin aux descendants, et pas seulement à l’enfant direct. - Récupérez les groupes de processus lors d’une sortie normale, d’une erreur et d’une annulation ; les tubes hérités et les petits-enfants échappés ne doivent pas survivre à une exécution. - Appliquez le durcissement des processus enfants propre à la plateforme par l’intermédiaire d’un seul wrapper idempotent, afin que les tâches en arrière-plan n’ouvrent jamais de consoles indésirables. - Protégez l’état mutable partagé avec des primitives de synchronisation standard et rendez explicite la responsabilité des goroutines, des canaux, des arbres de travail et des répertoires temporaires. ### Discipline du système de fichiers et de Git - Utilisez les utilitaires de chemins de la plateforme, les racines d’état appartenant à l’application et les modes de fichiers documentés. - Résolvez les liens symboliques lorsque des alias de plateforme peuvent faire comparer différemment des chemins équivalents. - Faites passer les opérations Git sur des dépôts nus par un utilitaire qui fournit explicitement le répertoire Git ; ne dépendez jamais de la détection à partir du répertoire courant avec des paramètres Git durcis. - Ne supprimez ou ne remplacez un état que si les enregistrements de responsabilité et de cycle de vie prouvent que l’opération est sûre. ## Laisser seule la configuration de la branche de confiance choisir les commandes Une configuration qui sélectionne des commandes ou des agents exécutables est du code. Ne la chargez qu’à partir d’une révision fiable, tout en traitant les configurations et instructions contrôlées par les contributeurs comme des données non fiables. ### Entrées fiables - Déterminez la branche par défaut fiable par une nouvelle récupération distante et épinglez le commit exact avant de lire les paramètres qui exécutent du code. - Abandonnez si le commit fiable ou sa configuration actuelle ne peut pas être récupéré, lu ou analysé. Un arbre fiable lisible sans configuration peut être valide si le contrat l’autorise. - Lisez les sélecteurs de commandes, les sélecteurs d’agents, la politique de documentation, les dérogations aux instructions du projet et l’autorisation des commandes du dépôt uniquement dans la copie fiable. - Désactivez par défaut l’autorisation des commandes du dépôt. Une branche poussée ne doit jamais pouvoir activer ses propres privilèges d’exécution ni affaiblir la politique fiable. - Séparez les paramètres de fonctionnalités qui n’exécutent rien afin qu’un comportement propre à une branche ne franchisse pas la frontière d’exécution. ### Traitement fermé en cas d’échec - Nettoyez les textes de contrôle contradictoires et expurgez les secrets avant de placer du contenu utilisateur ou issu du dépôt dans les invites des agents. - Vérifiez qu’une éventuelle option de suppression des instructions fonctionne pour l’adaptateur sélectionné avant de le lancer. - Ne fabriquez jamais de confiance après un échec de récupération, d’analyse ou d’autorisation. - Ajoutez des tests de régression prouvant que le contenu poussé ne peut pas s’autoriser lui-même à exécuter des commandes, remplacer une politique fiable ou contourner le comportement fermé en cas d’échec. ## Lancer un seul service en arrière-plan et refuser l’arrêt pendant les jobs actifs Les services à l’échelle de la machine nécessitent des défenses indépendantes pour la responsabilité du singleton, la sécurité des sockets, la récupération et les commandes destructives du cycle de vie. ### Singleton et récupération - Obtenez un verrou exclusif du système d’exploitation avant les travaux de récupération ou la liaison du socket, et conservez-le pendant toute la durée de vie du processus. - Considérez un verrou de noyau détenu comme la preuve d’un propriétaire actif ; n’inventez pas d’heuristiques d’obsolescence pour ce verrou. - Sondez un socket existant avant de le supprimer et bornez séparément les délais de connexion et de contrôle d’intégrité. - Ne lancez l’exécution du service que par un mode explicite. Les variables d’environnement héritées ne doivent pas réinterpréter des sondes ordinaires comme des workers. - Rendez le nettoyage de démarrage sensible à l’état : ne supprimez jamais un arbre de travail ou une ressource dont l’enregistrement de tâche est en attente ou en cours d’exécution. ### Contrôles du cycle de vie - Refusez l’arrêt, le redémarrage et la mise à jour tant que des tâches sont actives, sauf si l’opérateur fournit la dérogation destructive explicite. - Ne laissez pas les options de confirmation non interactives contourner la protection des tâches actives. - Répertoriez les tâches bloquantes et auditez chaque invocation du cycle de vie avec l’attribution du processus et du processus parent. - Traitez les limites de surveillance de l’intégration continue comme des délais d’inactivité : ne les réarmez que sur un progrès amont vérifié, ne raccourcissez jamais l’échéance existante et échouez de manière sûre lorsque le progrès ne peut pas être vérifié. - Rendez idempotentes les opérations d’abandon des orphelins et gardez les horodatages d’attente des agents purement observationnels : ne les définissez que lorsqu’une porte est effectivement suspendue et ne les utilisez jamais pour modifier la résolution de la porte. ## Séparer les sessions de relecture et de correction et comparer les changements à l’objectif La revue doit comparer la modification complète à une intention vérifiable à partir de la source, sans permettre à un texte non fiable, au moment de la livraison ou au raisonnement du correcteur de fausser la décision. ### Intention et constats - Préservez la provenance de l’intention. Considérez une intention explicite comme des critères d’acceptation faisant autorité et une intention déduite uniquement comme un indice peu fiable. - Appliquez aux deux formes le même nettoyage, la même expurgation des secrets et la même protection contre l’exécution. - Transformez une modification du correcteur qui contredit des critères explicites en un constat nécessitant l’avis de l’utilisateur, lequel suspend l’exécution. - Pendant la revue préalable à la livraison, excluez uniquement les résultats relevant d’étapes ultérieures du pipeline ; continuez à appliquer les exigences externes ou préexistantes du cycle de vie. - Fermez le traitement en cas d’échec lorsqu’une action associée à un constat est absente ou inconnue : classez-le comme nécessitant l’avis de l’utilisateur, jamais comme automatiquement corrigeable. ### Discipline des sessions et des corrections - Conservez une session durable de réviseur par exécution et une session durable distincte pour le correcteur ; les rôles ne doivent jamais partager leur état. - Ne réutilisez les sessions que pour la boucle de revue, ne conservez que les métadonnées d’identité minimales et ne conservez jamais les invites ni les transcriptions. - Si la reprise n’est pas prise en charge ou échoue, abandonnez cette identité et répétez à froid le tour du même rôle. Ne réessayez pas après une annulation. - Chaque nouvelle revue reste une revue contradictoire complète de l’intégralité du diff de la branche. - Lors d’un cycle de correction, appliquez d’abord toutes les corrections, puis exécutez une seule vérification ciblée limitée à la zone modifiée. Laissez les portes faisant autorité de la suite complète de tests et du linter à leurs étapes dédiées. ## Régénérer la doc depuis sa source et n’envoyer ni prompts ni code dans les statistiques Conservez un seul responsable pour chaque fait, régénérez les consignes dérivées à partir de leur source et séparez les preuves de diagnostic locales des analyses distantes bornées. ### Documentation et contenu généré - Gardez les documents de présentation concis ; placez les faits de référence détaillés auprès de leur responsable désigné et ajoutez des liens vers eux depuis les guides. - Mettez à jour les cartes de responsabilité lorsque les attributions changent. - Modifiez la source des consignes générées pour les agents, régénérez l’artefact au moyen de la compilation approuvée et laissez le linter échouer en cas de dérive. - Modifiez ensemble les consignes sources et la sortie de commande au point d’utilisation lorsqu’elles expriment le même contrat opérationnel. - Si un passage d’agent combine les tâches de documentation et de linter, consommez chaque résultat exactement une fois et revenez à un passage indépendant dès qu’une sortie est ignorée, invalide ou non fiable. - Limitez les modifications de documentation aux éléments rendus obsolètes par la modification actuelle ; ne réintroduisez pas d’analyses exhaustives du corpus. ### Observabilité respectueuse de la vie privée - Les surfaces en lecture seule ne doivent émettre aucune vue de page ; conditionnez leur événement de commande distant à un changement d’état et à un intervalle borné. - Conservez une fidélité complète pour les événements de mutation tout en stockant les preuves de performance détaillées uniquement en local. - Ne stockez jamais les invites, sorties, diffs, secrets ou arguments de commande bruts dans les métriques d’invocation, et n’envoyez jamais d’identifiants d’exécution, de chemins, d’identités de session ou d’enregistrements par invocation aux analyses distantes. - N’envoyez que des nombres agrégés bornés lors des événements terminaux. - Confiez les définitions des métriques et les limites temporelles à une seule implémentation faisant autorité. Représentez les valeurs indisponibles par null, et non par un zéro fabriqué, et calculez si nécessaire l’utilisation par cycle à partir des écarts entre les valeurs cumulées de la session. ## Vérifier le dépôt distant avant un force push et signer chaque build de release L’invariant principal consiste à préserver le code de l’utilisateur. Refusez une synchronisation ou une livraison dangereuse plutôt que de tenter une récupération ingénieuse susceptible d’écraser un travail non observé. ### Sécurité du dépôt et des branches - Séparez le routage de la base de la pull request d’une cible de push facultative vers un fork. Lorsqu’un hôte ne peut pas prendre en charge le routage du fork de bout en bout, ignorez la création plutôt que d’ouvrir une pull request incorrecte vers le dépôt lui-même. - Limitez la synchronisation ordinaire à une avance rapide stricte et propre, ou à un déplacement de divergence dont l’équivalence est prouvée et qui est ancré sur la tête exacte du pipeline. - Un état passif ne doit ni récupérer ni modifier. Les chemins bloqués ne doivent pas réinitialiser, remiser, fusionner, rebaser, forcer, basculer, supprimer ou mettre à jour un dépôt distant externe. - Conservez le commit exact poussé, l’identité de cible dépourvue d’identifiants d’accès et la génération, puis revérifiez toutes les hypothèses mutables immédiatement avant d’appliquer une synchronisation. - Préservez le travail final non publié sous une référence de récupération. La récupération ne peut déplacer un arbre de travail propre que par avance rapide stricte ; conserver le travail local doit mettre à jour la porte par comparaison et échange sans déclencher un nouveau pipeline. - Dérivez les bases de rebasage de références distantes faisant autorité et fraîchement récupérées. Suspendez l’exécution lorsque des commits non poussés de la branche par défaut élargiraient silencieusement une modification. - Avant un push forcé, relisez la tête distante et ne poursuivez que pour une nouvelle branche, une tête identique, une tête précédemment observée et inchangée, ou des commits ajoutés à distance dont l’équivalence a déjà été prouvée par l’identité du correctif. Tout échec de consultation ou de preuve doit fermer le traitement en cas d’échec. - Utilisez comme ancre du bail la dernière tête effectivement observée par l’exécution, jamais une pointe récupérée juste avant l’opération forcée. ### Sécurité des versions et des dépendances - Pour une plateforme dotée d’un contrat de signature permanent, signez chaque artefact officiel avec l’identité d’application fixe, un environnement d’exécution durci et un horodatage sécurisé avant son archivage ou le calcul de sa somme de contrôle. - Limitez les identifiants de signature à la tâche de publication, importez-les dans un stockage éphémère et supprimez-les en cas de réussite comme d’échec. - Faites échouer la vérification de la version en cas de signature absente ou ambiguë, d’identité ou d’architecture incorrecte, d’exigence d’identité mutable, de durcissement absent ou d’horodatage manquant. - Traitez la notarisation, les formats de paquet et les binaires universels comme des périmètres distincts, sauf si le contrat de publication les inclut. - Avant d’ajouter une dépendance, consultez sa documentation actuelle faisant autorité et discutez de la modification avec l’utilisateur. - Ne déclarez pas le système prêt tant que le formatage, le linting, les tests ciblés, les tests d’intégration, la suite complète, les contrôles de compilation, les contrôles de documentation et la vérification propre à la publication n’ont pas produit de résultats réels.