Mettre à jour et enrichir des instructions d'IA tirées d'un seul original pour plusieurs outils d'IA

## Trouver quelle partie gère un comportement avant de le modifier Considérez le dépôt comme un ensemble de couches aux responsabilités établies, et non comme une collection disparate de fichiers. Avant toute modification, identifiez la couche responsable du comportement demandé : - les instructions sources définissent des opérations réutilisables destinées aux utilisateurs ; - les références partagées définissent des contrats et des schémas transversaux ; - les scripts auxiliaires mettent en œuvre des traitements reproductibles ; - les adaptateurs convertissent les instructions de référence en paquets propres à chaque plateforme ; - les distributions générées contiennent des résultats pouvant être recréés ; - les hooks font respecter les règles du dépôt et des résultats ; - l'architecture et les manuels d'exploitation expliquent les interactions entre les couches ; - les fichiers de dépendances et d'installation définissent l'environnement d'exécution pris en charge. Utilisez la couche des sources de référence comme autorité. Les distributions générées prouvent que la compilation fonctionne, mais ne constituent pas des sources de vérité indépendantes. Régénérez-les au moyen du flux de compilation documenté au lieu de les modifier directement. Repérez le plus petit fichier faisant autorité qui contrôle le comportement demandé, puis identifiez chaque document, schéma, test et artefact généré qui en dépend et doit rester synchronisé. ## Garder un seul original et produire la version de chaque outil par un convertisseur Conservez les instructions réutilisables dans un format source unique et indépendant des plateformes. Laissez les adaptateurs effectuer la mise en paquet et la conversion de syntaxe requises par chaque environnement pris en charge. Un adaptateur peut : - copier une source compatible sans en modifier le sens ; - produire un paquet de compétence natif pour chaque opération ; - assembler un moteur partagé comportant plusieurs points d'entrée ; - créer un paquet de plateforme avec des prompts et des compétences auxiliaires ; - générer un répartiteur et une table de routage à partir des métadonnées de la source. Les adaptateurs doivent préserver le comportement et les contraintes d'origine. Lorsque l'environnement cible utilise d'autres outils, remplacez les noms d'outils propres à la plateforme par des actions neutres. Générez les métadonnées de routage à partir de la description de référence plutôt que de tenir un second catalogue manuscrit. Lorsque vous ajoutez une opération, ne modifiez sa source de référence qu'une seule fois. Utilisez une exclusion explicite de plateforme uniquement si l'opération ne peut pas fonctionner sur cette plateforme. Recompilez tous les adaptateurs concernés et examinez leurs résultats afin de détecter toute dérive sémantique. ## Marquer chaque note enregistrée avec ses sources et son degré de certitude Toute opération qui écrit des artefacts de connaissance doit respecter le contrat d'écriture de référence du dépôt. Concevez les artefacts pour permettre une récupération et un raisonnement futurs fiables, et non uniquement pour offrir une lisibilité humaine immédiate. Exigez que chaque artefact comprenne : - un court préambule expliquant sa finalité à un futur lecteur IA ; - des métadonnées structurées, telles que le type d'artefact, la date, les étiquettes et un indicateur `AI-first` explicite ; - des liens internes stables pour les personnes, projets, idées et décisions mentionnés ; - des marqueurs de fraîcheur pour les affirmations susceptibles de devenir obsolètes ; - les URL sources conservées textuellement à côté des affirmations externes ; - des niveaux de confiance distinguant les faits déclarés, les preuves solides, les preuves modérées et les spéculations. Ne retirez ni les métadonnées, ni les liens, ni la provenance, ni les signaux de confiance dans le seul but d'épurer l'apparence d'un artefact. Si une opération introduit un nouveau type d'artefact, étendez le schéma partagé avant de produire ce type. ## Utiliser des règles d'écriture que les contrôles automatiques peuvent confirmer Utilisez des conventions que les outils de formatage et les hooks peuvent vérifier de manière cohérente : - écrivez les titres Markdown en casse de phrase ; - excluez les emojis décoratifs des sources d'instructions ; - utilisez la ponctuation ASCII au lieu de substitutions typographiques, sauf si un symbole non ASCII possède un sens propre ; - écrivez les valeurs d'étiquette en minuscules et placez entre guillemets les chaînes de métadonnées ambiguës ; - respectez la version du langage, l'outil de formatage, la limite de longueur des lignes et le gestionnaire de dépendances configurés ; - rédigez les objets de commit à l'impératif et appliquez la politique d'attribution du dépôt. Considérez l'outil de formatage de référence et les hooks de validation comme l'autorité finale en matière de style mécanique. Ne les contournez pas et ne conservez pas manuellement un formatage qu'ils rejettent. Limitez suffisamment la portée des conventions pour qu'elles puissent être appliquées automatiquement. Lorsqu'une règle ne peut pas être vérifiée mécaniquement, documentez les preuves de revue nécessaires pour la confirmer. ## En ajoutant une tâche, mettre à jour en même temps les manuels et les listes Suivez cette séquence lorsque vous ajoutez une nouvelle opération : 1. Créez la source d'instructions de référence avec les métadonnées de routage et des directives d'exploitation complètes. 2. Ajoutez un auxiliaire dans la zone de scripts prévue uniquement lorsqu'une logique exécutable est nécessaire. 3. Référencez le contrat d'écriture partagé depuis chaque chemin susceptible de créer ou de modifier un artefact. 4. Étendez le schéma de métadonnées partagé avant d'introduire un nouveau type d'artefact. 5. Mettez à jour le manuel d'exploitation, l'inventaire des capacités, les notes d'architecture et le catalogue public des commandes. 6. Consignez la modification dans la section du journal réservée aux changements non publiés. 7. Exécutez la compilation des adaptateurs et examinez les résultats de chaque plateforme concernée. Ne dupliquez pas une opération dans les arborescences de plateforme générées. Une modification synchronisée met à jour conjointement la source, les références applicables, les tests et la documentation, afin qu'une compilation ultérieure ne puisse ni l'effacer ni la contredire. ## Tester séparément les instructions et la fabrication des versions Testez séparément le comportement de la source et le processus de génération. Utilisez un espace de travail de test isolé ou une copie de travail locale liée plutôt qu'un magasin de connaissances actif. Pour valider le comportement : - exécutez l'opération modifiée sur des données de test représentatives ; - examinez les artefacts obtenus ; - vérifiez les métadonnées, les liens, la provenance, les niveaux de confiance et les autres champs obligatoires du contrat d'écriture ; - confirmez que les faits inconnus restent explicitement signalés comme tels. Pour valider le processus : - exécutez la suite de tests rapides du dépôt au moyen de l'exécuteur de paquets configuré ; - vérifiez les emplacements des résultats des adaptateurs et le routage généré ; - testez les interfaces des scripts auxiliaires et les résultats lisibles par machine ; - mettez à jour l'assertion correspondante dans la même modification lorsqu'un changement de disposition des résultats est intentionnel. Exécutez d'abord le test pertinent le plus restreint, puis la suite de tests rapides concernée. Les vérifications manuelles du comportement complètent les tests automatisés ; elles ne les remplacent pas. ## Publier une nouvelle version seulement après les contrôles et avec autorisation Ne publiez que lorsque l'intégration continue est au vert et que le contrat d'écriture destiné aux machines reste respecté. Suivez une séquence de publication contrôlée : 1. Déplacez les entrées non publiées du journal des changements sous un titre de version daté. 2. Mettez à jour la version dans le fichier principal du paquet et dans chaque fichier miroir de manifeste ou de citation. 3. Exécutez des contrôles de dérive qui comparent toutes les déclarations de version. 4. Recompilez les distributions générées et exécutez les tests concernés. 5. Confirmez le rôle de publication et la politique de branches avant d'étiqueter ou d'effectuer un push. 6. Publiez les notes de version à partir de l'entrée approuvée du journal des changements. Protégez les branches par défaut partagées. Les contributeurs doivent suivre la voie de revue imposée. Un responsable de maintenance ne peut publier directement que si la politique du dépôt lui accorde explicitement cette autorité et si les mêmes seuils de vérification ont été franchis. ## Ne pas inventer les faits manquants ni modifier à la main les fichiers générés N'affaiblissez jamais le contrat de récupération du système pour des raisons esthétiques. Ne retirez pas les préambules ni les métadonnées obligatoires, ne reformulez pas les artefacts destinés aux machines uniquement pour leur donner un ton plus humain et n'ajoutez pas d'éléments décoratifs interdits par les conventions de source. N'inventez ni taux, ni dates, ni propriété, ni relations, ni aucun autre fait manquant. Marquez les valeurs inconnues avec `TBD` ou avec le marqueur explicite équivalent utilisé par le dépôt. Ne modifiez jamais un résultat généré lorsqu'il appartient à un générateur. Ne contournez pas les hooks, ne publiez pas depuis une branche non autorisée et ne prétendez pas avoir réussi sur la seule base de l'examen de la source. Avant de signaler l'achèvement : - examinez l'intégralité du diff prévu afin de détecter les modifications sans rapport ; - confirmez que les sources de référence et les résultats générés concordent ; - exécutez l'outil de formatage, les hooks, les tests et la compilation des adaptateurs concernés ; - vérifiez les schémas, manuels, catalogues et entrées du journal des changements qui doivent être synchronisés ; - consignez toute validation manuelle et tout contrôle qui n'a pas pu être exécuté ; - confirmez que l'action finale de publication correspondait au rôle autorisé. Indiquez le comportement modifié, les preuves de vérification, les limites restantes et toute décision encore nécessaire.