Vérifier les Consommateurs Aval & Évaluer les Modifications Incompatibles

[!IMPORTANT] Aucun Commit Aval Autorisé Cette skill est entièrement focalisée sur l'évaluation des modifications incompatibles au sein de dart_skills_lint lors de la revue de PR et de la validation du changelog. Toute modification appliquée aux dépôts consommateurs aval (comme l'édition temporaire des hashes ref: dans pubspec.yaml ou la mise à jour de la syntaxe d'appel pour vérifier les migrations) est strictement diagnostique et transitoire. Vous ne devez jamais stagiser, committer, ou pousser du code dans des dépôts externes aval pendant ce workflow.

1. Préparation & Vérification du Dépôt

1. Vérifier l'État Local du Linter (dart_skills_lint)

   • Assurez-vous que votre répertoire de travail dans dart_skills_lint est propre (git status).
   • Vérifiez que tous les tests existants passent correctement (dart test).
   • Poussez les commits actuels vers la branche distante afin que les consommateurs aval puissent résoudre les hashes git directement via le réseau.
   • Enregistrez le dernier hash de commit SHA-1 distant (par exemple, 1e1f280...).

2. Localiser & Consulter les Consommateurs Aval

   • Consultez resources/known_consumers.md pour passer en revue les dépôts consommateurs typiques (flutter/flutter, flutter/devtools, dart-lang/site-www, etc.) et leurs sous-répertoires de consommation spécifiques.
   • Découvrir les Checkouts Locaux : Si vous ne connaissez pas déjà les chemins de répertoire exacts où vivent ces dépôts consommateurs sur le disque :
     1. Vérifier la Connaissance de l'Espace de Travail : Inspectez les définitions actives de l'espace de travail et les Knowledge Items (KIs) spécifiques à la machine locale, qui enregistrent fréquemment les structures de répertoires système configurées.
     2. Inspecter les Répertoires Parents Adjacents : Vérifiez les chemins pairs courants directement autour de la racine de votre dépôt actuel (par exemple, en listant les répertoires adjacents sous .. ou en exécutant des recherches localisées en profondeur limitée comme find .. -maxdepth 3 -name pubspec.yaml).
     3. Demander Avant d'Exécuter des Traversées Aveugles : N'exécutez jamais des parcours illimités du système de fichiers racine (find / -name ...). Si un dépôt cible ne peut pas être trouvé dans les limites de l'espace de travail adjacent, demandez immédiatement à l'utilisateur si le dépôt est consulté localement et sollicitez son chemin avant d'évaluer.
   • Pour chaque cible consultée sur le disque, vérifiez que son état git est propre et repose sur sa branche en amont primaire (main ou master). N'exécutez pas de tests sur des branches sales ou obsolètes.

2. Pointer les Consommateurs vers le Hash en Cours

Pour chaque consommateur aval en évaluation :

1. Mettre à Jour pubspec.yaml

   • Localisez la spécification de dépendance pertinente de la cible (par exemple, dev/tools/pubspec.yaml ou tool/pubspec.yaml).
   • Mettez à jour le champ ref: sous la configuration git pour dart_skills_lint afin qu'il corresponde exactement au hash de commit en cours :

     dart_skills_lint:
       git:
         url: https://github.com/flutter/agent-plugins
         path: tool/dart_skills_lint
         ref: <LATEST_COMMIT_HASH>

2. Résoudre les Dépendances & Exécuter les Tests de Vérification

   • Exécutez la résolution des dépendances selon l'environnement du consommateur (les espaces de travail Flutter nécessitent flutter pub get ; les dépôts Dart pur standard nécessitent dart pub get).
   • Exécutez les tests de vérification du consommateur (généralement ciblant des tests comme test/validate_skills_test.dart ou exécutant flutter test / dart test).

3. Évaluation des Modifications Incompatibles & Protocole de Décision

Chaque fois que les tests échouent ou que la résolution des dépendances rencontre des frictions API, vous devez évaluer la nature de la rupture et faire une pause pour une décision humaine délibérée en boucle fermée avant d'agir.

Analyser l'Échec

1. Diagnostiquer : Identifiez les causes exactes (par exemple, paramètres publics renommés, types de modèles supprimés, types de retour de getter modifiés, ou profils de sévérité altérés).
2. Options d'Atténuation : Déterminez si une couche de code rétro-compatible peut combler harmonieusement la modification sans compromettre les nouvelles fonctionnalités (par exemple, les getters @Deprecated mappant les nouveaux types aux structures héritées, le transfert de paramètres de constructeur, ou les exports de secours).
3. Intégrité du Changelog : Vérifiez si le comportement de rupture et ses étapes de migration requises sont entièrement documentés dans dart_skills_lint/CHANGELOG.md.

Le Point de Collaboration Humaine

Présentez votre résumé diagnostique à l'utilisateur et demandez un chemin délibéré à suivre. Le choix entre atténuer une rupture à l'intérieur du linter ou effectuer une modification incompatible dans les bibliothèques aval est strictement une décision humaine basée sur les compromis de l'écosystème.

Parcours A : Atténuation de la Rétro-compatibilité (Approuvé par l'Utilisateur)

Si la décision est d'adoucir ou d'éliminer la modification incompatible de dart_skills_lint :

1. Modifiez le code dart_skills_lint pour introduire le shim rétro-compatible (tel que les getters/constructeurs dépréciés ou les exports de compatibilité).
2. Ajoutez des tests de régression pour assurer que les appels de consommateurs hérités et les nouveaux motifs fonctionnent correctement sans lever d'exceptions, tout en vérifiant que les drapeaux mutuellement exclusifs échouent gracieusement s'ils sont combinés.
3. Assurez-vous que les shims temporaires sont correctement documentés et marqués avec des problèmes de suivi (// TODO(...)) pour une suppression future.
4. Formatez le code (dart format .), vérifiez l'analyse statique (dart analyze --fatal-infos), et confirmez que les tests passent localement (dart test).
5. Committez et poussez la branche mise à jour, capturez le hash de commit SHA-1 actualisé, mettez à jour le pubspec.yaml aval, et exécutez les tests à nouveau jusqu'à ce que le consommateur se compile proprement et passe.

Parcours B : Migration Aval via Changelog (Rupture Acceptée)

Si l'utilisateur vous demande de ne pas atténuer (ou si l'atténuation est structurellement impossible) et accepte la modification incompatible :

1. Tenter la Mise à Niveau Aval : Mettez à niveau le code d'appel de la bibliothèque aval en suivant strictement les instructions de migration écrites dans dart_skills_lint/CHANGELOG.md.
2. Évaluer la Qualité du Changelog : Si les instructions écrites dans le CHANGELOG.md sont incomplètes, confuses, ou insuffisantes pour migrer proprement le code aval, traitez cela comme un échec d'évaluation explicite. Proposez immédiatement des améliorations ciblées et des clarifications au dart_skills_lint/CHANGELOG.md.
3. Vérifier la Génération & les Tests : Après mise à jour du code base du consommateur et de toute amélioration du changelog, réexécutez les vérifications de dépendances (pub get) et les suites de tests jusqu'à ce que le paquet aval s'exécute proprement.

Contrainte — Ne Pas Committer : Souvenez-vous que toute édition de migration effectuée dans le code base aval existe purement pour vérifier que les instructions dart_skills_lint/CHANGELOG.md fonctionnent proprement en pratique. Ne stagisez ou commitez pas ces éditions à l'intérieur du dépôt consommateur.

4. Boucle d'Itération & Nettoyage du Dépôt

Après avoir évalué et résolu avec succès un dépôt cible :

1. Nettoyer l'État du Consommateur : Parce que les éditions aval sont entièrement transitoires, restaurez proprement le dépôt consommateur externe à son état git initial (git checkout -- . ou git restore . sur les chemins modifiés) avant de passer au candidat suivant, sauf si l'utilisateur vous demande expressément de laisser les modifications non stagisées sur le disque pour une inspection locale.
2. Enregistrer le Résumé d'Évaluation : Mettez à jour et maintenez des résumés clairs documentant quels dépôts ont passé proprement sans modifications, lesquels ont nécessité des atténuations locales à l'intérieur de dart_skills_lint, et lesquels ont validé les workflows de migration du changelog.
3. Vérifier l'Intention du Relecteur : Demandez à l'utilisateur relecteur s'il faut procéder directement à l'évaluation du dépôt suivant listé dans resources/known_consumers.md ou arrêter l'exécution.