Allow Breaking Change

Autoriser le Changement Cassant

Considérez la compatibilité avec le comportement historique appartenant au projet comme optionnelle pour le reste de la conversation en cours. Privilégiez l'architecture la plus simple et saine pour les besoins actuels ; ne cassez pas le comportement uniquement par souci de nouveauté.

Activer et Conserver la Politique

1. Activez uniquement après une invocation explicite de $allow-breaking-change.
2. Pour une invocation simple, confirmez l'activation et sa limite de protection des données en une phrase concise, puis attendez une tâche. Pour une invocation avec une tâche, activez d'abord, puis traitez la tâche.
3. Appliquez la politique à tous les projets et tâches, y compris la planification, la conception, la révision, le diagnostic et l'implémentation, jusqu'à la fin de la conversation ou que l'utilisateur la désactive explicitement.
4. Traitez une instruction claire au niveau de la tâche, telle que keep compatibility for this task, comme une dérogation temporaire. Traitez une instruction claire telle que disable allow-breaking-change comme une révocation pour le reste de la conversation.
5. Mentionnez la politique active uniquement lorsque la compatibilité affecte une décision ou un résultat. Ne répétez pas un rappel d'état lors d'échanges non liés.
6. Continuez à obéir aux instructions de priorité supérieure, aux exigences du référentiel et aux contraintes explicites de la tâche en cours.

Prendre des Décisions Sans Compatibilité Historique

• Excluez la compatibilité ascendante et descendante avec les API, CLI, configurations, protocoles et formats de fichiers hérités appartenant au projet des critères de décision.
• N'ajoutez pas d'adaptateurs, de périodes de dépréciation, d'implémentations parallèles, de ponts de version ou d'analyse héritée uniquement pour préserver les consommateurs historiques.
• Mettez à jour tous les appelants, tests, documentation, exemples et artefacts générés concernés vers le nouveau contrat.
• Classez les anciens tests par intention. Supprimez ou réécrivez les assertions qui n'existent que pour la compatibilité ; conservez les exigences de correction, sécurité, intégrité des données, accessibilité et comportement actuel.
• Continuez à évaluer l'effort d'implémentation, le risque de régression, la difficulté de validation, la performance et le risque opérationnel. L'autorisation de casser la compatibilité n'est pas une autorisation d'élargir le périmètre de la tâche ou d'effectuer des actions destructrices.
• Continuez à respecter les normes externes, les ABI de plateforme, les contrats tiers actifs et autres exigences d'interopérabilité qui restent parties de la tâche en cours.

Juger l'Architecture avec KISS et Unixify

Pour les changements matériels concernant les limites de responsabilité, les interfaces, les représentations de données ou les couches système, appliquez d'abord la compétence installée $kiss pour supprimer les concepts et mécanismes inutiles, puis appliquez $unixify pour façonner les responsabilités, représentations et interfaces de composition restantes. Ignorez ce workflow supplémentaire pour les changements mécaniques locaux.

Remplacez uniquement les garde-fous de préservation de la compatibilité dans KISS et Unixify tant que cette politique est active. Préservez leurs autres garde-fous, en particulier la correction, la sécurité, l'intégrité des données, la clarté, les limites justifiées et le comportement observable en cas d'échec.

Protéger les Données et les Opérations

• Lorsque des données stockées doivent être déplacées vers une représentation incompatible, fournissez et vérifiez une migration unidirectionnelle sans perte. Ne supportez que la nouvelle représentation après la migration.
• Si une migration sans perte est impossible, arrêtez-vous et signalez les informations ou la sémantique qui seraient perdues. Obtenez une décision spécifique à la tâche avant d'effectuer une migration avec perte.
• Introduisez un pont de compatibilité temporaire uniquement lorsqu'une exigence de disponibilité actuelle ou de déploiement progressif rend le fonctionnement en version mixte nécessaire. Donnez au pont une condition de suppression explicite et retirez-le après la transition.

Communiquer les Changements Cassants

Ne demandez pas la permission simplement parce que la conception choisie est cassante. Identifiez brièvement les principaux contrats cassés, les appelants ou données concernés, la migration requise et la vérification effectuée dans le plan, le rapport de révision ou d'achèvement.