ALVIN-YANG/ay-skills

AY Fix

Prouvez la cause, puis effectuez la plus petite réparation autorisée qui empêche la récidive.

Contrat d'approbation

• Lisez l'intégralité de la demande et enquêtez sur les faits découvrables avant d'interroger l'utilisateur.
• Traitez la revue, le diagnostic, l'explication et la planification comme des opérations en lecture seule, sauf si l'utilisateur demande également une modification.
• Considérez une instruction précise comme une approbation lorsque la cible, le résultat observable et la limite d'acceptation sont clairs.
• Un résultat large autorise l'investigation, pas les modifications de fichiers ou d'artefacts basées sur des choix que l'agent doit inventer.
• Pour une modification matériellement sous-spécifiée, présentez une proposition recommandée et attendez l'approbation.
• Après approbation, exécutez de manière autonome à l'intérieur de la limite approuvée ; ne posez pas de questions sur les détails d'implémentation courants.
• Rouvrez l'approbation uniquement lorsque de nouvelles preuves modifient le comportement, l'architecture, les contrats de données, les dépendances, le périmètre, les risques, les coûts, le rollback ou les actions externes.
• Effectuez des actions externes uniquement lorsque la demande ou la proposition approuvée les inclut. Confirmez la cible exacte avant une action irréversible.
• Préservez le travail non lié et créé par l'utilisateur. Vérifiez le résultat réel demandé avant de déclarer la tâche terminée.

Diagnostiquer

1. Capturez le symptôme exact, le comportement attendu, l'environnement et la couche de défaillance.
2. Reproduisez via le chemin disponible le plus proche, ou nommez la condition de reproduction manquante.
3. Remontez du mauvais résultat à l'état incorrect le plus ancien. Lisez les modifications récentes et les exemples fonctionnels lorsque c'est pertinent.
4. Formez des hypothèses concurrentes et exécutez le plus petit test discriminant. Instrumentez les limites lorsque l'observation est manquante.
5. Confirmez la cause. Une odeur plausible, une corrélation ou un symptôme disparu n'est pas une preuve.

Après une hypothèse échouée, collectez de nouvelles preuves avant d'en essayer une autre. Ne modifiez pas de manière répétée en lieu et place du diagnostic.

Décider de la limite de réparation

Si l'utilisateur a demandé uniquement un diagnostic, arrêtez-vous avec la cause confirmée ou le prochain test discriminant.

Si l'utilisateur a demandé une réparation, procédez sans autre point de contrôle uniquement lorsque la réparation de la cause racine est unique, locale, réversible et préserve le comportement prévu. Présentez d'abord une proposition de réparation lorsque des alternatives modifient le comportement du produit, l'architecture, les contrats de données, les dépendances, le périmètre, l'état externe ou le risque matériel.

Réparer et prouver

Corrigez la cause à la limite responsable la plus étroite, pas son symptôme en aval. Ajoutez une vérification de régression lorsqu'il existe une couture de comportement stable ; n'inventez pas de tests creux pour des surfaces non testables.

Relancez la reproduction originale, la vérification de régression et les voisins pertinents. Séparez les preuves liées à l'environnement, au harnais, à la source, à la compilation, au package, au déploiement et à l'exécution réelle. Si la cause reste non prouvée, dites-le.

Rapportez la cause, les preuves discriminantes, la réparation, la preuve et l'incertitude restante.