Vérifier les nouvelles soumissions à un catalogue de ressources techniques

## Garder un seul fichier de catalogue comme base et en générer le site et les données Considérez un document de catalogue lisible par l’humain comme l’unique source de référence. Générez les index, les jeux de données structurés et les pages statiques depuis cette source au lieu de modifier séparément les artefacts dérivés. Classez les entrées par catégories thématiques plutôt que par titres de langage d’implémentation. Enregistrez la prise en charge des langages dans des étiquettes intégrées à chaque entrée afin qu’une ressource puisse déclarer plusieurs langages sans changer de catégorie thématique. Documentez le flux des données : 1. Le document du catalogue conserve les entrées sélectionnées. 2. Un analyseur valide les entrées, enrichit les métadonnées externes approuvées et écrit un jeu de données structuré. 3. Un générateur de site lit le jeu de données lorsqu’il existe ; sinon, il analyse directement le catalogue pour les aperçus locaux. 4. L’intégration continue exécute l’analyseur et le générateur, puis publie uniquement le répertoire généré du site. Maintenez le comportement de l’analyseur, du générateur et du déploiement conforme à ce contrat. Ne faites pas d’une page ou d’un jeu de données généré une source de référence concurrente. ## Écrire chaque entrée du catalogue dans un même format avec des étiquettes de langage Définissez une seule structure d’entrée reconnue par l’analyseur et traitez la ponctuation comme une partie du contrat. Une entrée type contient un nom lié, une ou plusieurs étiquettes de langage intégrées et une description : ``- [Name](https://example.org) - `Language` - Description.`` Appliquez ces règles : - toute nouvelle entrée non commerciale doit comporter au moins une étiquette de langage suivie du séparateur requis ; - la description doit se terminer par un point avant tout lien facultatif vers le dépôt source ; - les nouveaux liens doivent utiliser `https://` ; - les ressources commerciales ou propriétaires appartiennent à une catégorie dédiée ; - les étiquettes de langage ne peuvent être omises que dans les catégories commerciales ou explicitement indépendantes des langages ; - le guide de contribution destiné aux utilisateurs reste la source de référence pour les personnes qui soumettent des entrées. Acceptez plusieurs étiquettes de langage sans modifier la structure environnante. Autorisez un lien facultatif vers le dépôt après la description complète. Conservez les liens vers des paquets propres à un écosystème lorsqu’ils respectent la même grammaire d’entrée. N’assouplissez pas le modèle de l’analyseur pour une seule soumission mal formée. ## Vérifier strictement les nouvelles entrées et signaler les anciennes seulement en avertissement Utilisez l’environnement et les enveloppes de tâches documentés dans le dépôt pour valider, analyser et publier. Respectez la version d’exécution requise et installez les dépendances au moyen de la commande canonique. Utilisez deux modes de validation : 1. La validation des changements vérifie uniquement les entrées ajoutées par rapport à la révision de base choisie. 2. La validation du catalogue complet vérifie chaque entrée. Pour les nouvelles entrées, traitez comme erreurs les doublons, les liens mal formés et les infractions à la politique relative aux URL. Pour le catalogue complet, signalez les problèmes hérités équivalents comme avertissements, sauf si des options strictes sont explicitement choisies. Ne laissez pas une dette héritée tolérée affaiblir le critère d’admission des nouvelles entrées. N’exécutez l’analyseur que lorsque les identifiants requis sont disponibles. Autorisez le générateur du site à utiliser un jeu de données structuré existant ou la solution de repli documentée d’analyse directe pour les aperçus locaux. ## Vérifier seulement les soumissions indiquées et chercher les doublons Limitez la révision aux soumissions nommées par l’utilisateur. Pour les opérations sur les demandes de fusion, utilisez le connecteur configuré du dépôt plutôt qu’un client de ligne de commande sans rapport. Avant toute action modificatrice : 1. Examinez les fichiers proposés et leurs différences. 2. Vérifiez le classement dans la catégorie et le format exact de l’entrée. 3. Recherchez les doublons dans le catalogue qui sert de source de référence. 4. Vérifiez que les URL utilisent un format sûr. 5. Évaluez l’activité actuelle du projet et sa documentation à l’aide de preuves. 6. Présentez les constats avant de modifier un état externe. Ne révisez pas d’autres soumissions simplement parce qu’elles sont ouvertes. Ne déduisez pas la popularité ni l’état de maintenance à partir de la seule description soumise. Distinguez la conformité au format du catalogue de la qualité et de l’utilité durable de la ressource. ## Demander avant de commenter ou de fusionner une pull request Demandez toujours l’accord de l’utilisateur avant de commenter, étiqueter, fermer ou fusionner une demande. N’appliquez l’étiquette de révision terminée qu’après l’approbation du commentaire de révision par l’utilisateur. Ne fusionnez qu’après avoir reçu une approbation explicite pour cette fusion. Utilisez les outils connectés du dépôt pour répertorier les demandes ouvertes, examiner les détails, fichiers, commentaires, étiquettes et différences, récupérer le catalogue de la branche par défaut afin de rechercher les doublons et effectuer les changements approuvés. Ne remplacez jamais le connecteur requis par un autre outil externe lorsqu’il n’est pas disponible. Si le connecteur manque, signalez que les opérations du dépôt sont bloquées et demandez à l’utilisateur de le configurer. Séparez la collecte de preuves en lecture seule des modifications externes. Une instruction de révision n’autorise pas à elle seule un commentaire, une étiquette, une fermeture ou une fusion. ## Garder la clé d’accès secrète et publier le site seulement par le processus automatique Traitez l’enrichissement des métadonnées externes comme une opération nécessitant des identifiants. Ne l’exécutez pas sans l’identifiant d’accès requis et ne révélez jamais cet identifiant dans les commandes, rapports, pages générées ou fichiers enregistrés. Maintenez la publication reproductible : - analysez le catalogue canonique pour produire le jeu de données structuré documenté ; - laissez les aperçus locaux utiliser uniquement la solution de repli documentée ; - générez la page statique à partir de l’entrée actuelle validée ; - publiez uniquement au moyen du flux configuré d’intégration continue ; - révisez les changements générés lorsque le comportement de l’analyseur ou du modèle change. N’affirmez pas que la publication a réussi sur la seule base d’un aperçu local. Vérifiez séparément l’artefact généré et le flux de publication. ## Indiquer ce qui a été vérifié, en séparant les nouvelles erreurs des anciens avertissements Indiquez les soumissions révisées, les constats, le mode de validation et toute opération bloquée. Précisez si les vérifications ont porté uniquement sur les nouvelles entrées ou sur le catalogue complet. Séparez les avertissements issus du contenu hérité des erreurs introduites par le changement actuel. Avant de terminer, confirmez : - le catalogue est resté la source de référence ; - la grammaire des entrées, la ponctuation, les étiquettes, les catégories et la sécurité des URL ont été vérifiées ; - les doublons ont été recherchés par rapport à la branche par défaut actuelle ; - les affirmations relatives à l’activité et à la documentation étaient fondées sur des preuves ; - aucun état externe n’a changé sans approbation ; - les artefacts générés n’ont pas été confondus avec le contenu source de référence. Gardez le rapport assez concis pour faciliter une décision, mais incluez chaque constat susceptible de modifier l’admission.