Jamie-Cui/skills

Breaking Changes erlauben

Behandle die Kompatibilität mit projekteigenem historischem Verhalten für den Rest der aktuellen Konversation als optional. Bevorzuge die einfachste, sauberste Architektur für aktuelle Anforderungen; ändere Verhalten nicht nur aus Neuheitsdrang.

Richtlinie aktivieren und beibehalten

1. Aktiviere nur nach einem expliziten $allow-breaking-change Aufruf.
2. Bei einem reinen Aufruf: Bestätige die Aktivierung und die Datenschutzgrenze in einem knappen Satz, dann warte auf eine Aufgabe. Bei einem Aufruf mit Aufgabe: Aktiviere zuerst und bearbeite dann die Aufgabe.
3. Wende die Richtlinie projekt- und aufgabenübergreifend an, einschließlich Planung, Entwurf, Überprüfung, Diagnose und Implementierung, bis die Konversation endet oder der Benutzer sie explizit deaktiviert.
4. Behandle eine eindeutige aufgabenbezogene Anweisung wie "Behalte die Kompatibilität für diese Aufgabe bei" als temporäre Überschreibung. Behandle eine eindeutige Anweisung wie "Deaktiviere allow-breaking-change" als Widerruf für den Rest der Konversation.
5. Erwähne die aktive Richtlinie nur, wenn die Kompatibilität eine Entscheidung oder ein Ergebnis beeinflusst. Wiederhole keine Status-Erinnerung bei nicht zusammenhängenden Schritten.
6. Befolge weiterhin Anweisungen mit höherer Priorität, Repository-Anforderungen und explizite Einschränkungen der aktuellen Aufgabe.

Entscheidungen ohne historische Kompatibilität treffen

• Schließe Abwärts- und Aufwärtskompatibilität mit projekteigenen Legacy-APIs, CLIs, Konfigurationen, Protokollen und Dateiformaten aus den Entscheidungskriterien aus.
• Füge keine Adapter, Abkündigungsfristen, parallelen Implementierungen, Versionsbrücken oder Legacy-Parsing hinzu, die nur historische Nutzer erhalten sollen.
• Aktualisiere alle betroffenen Aufrufer, Tests, Dokumentationen, Beispiele und generierten Artefakte auf den neuen Vertrag.
• Klassifiziere alte Tests nach Absicht. Entferne oder schreibe Assertions um, die nur der Kompatibilität dienen; behalte Anforderungen an Korrektheit, Sicherheit, Datenintegrität, Barrierefreiheit und aktuelles Verhalten bei.
• Berücksichtige weiterhin Implementierungsaufwand, Risiko von Regressionen, Validierungsschwierigkeiten, Leistung und Betriebsrisiko. Die Erlaubnis, Kompatibilität zu brechen, ist keine Erlaubnis, den Aufgabenumfang zu erweitern oder destruktive Aktionen durchzuführen.
• Halte weiterhin externe Standards, Plattform-ABIs, aktive Verträge mit Drittanbietern und andere Interoperabilitätsanforderungen ein, die weiterhin Teil der aktuellen Aufgabe sind.

Architektur mit KISS und Unixify bewerten

Bei wesentlichen Änderungen an Verantwortungsgrenzen, Schnittstellen, Datenrepräsentationen oder Systemschichten wende zuerst das installierte $kiss Skill an, um unnötige Konzepte und Mechanismen zu entfernen, dann $unixify, um die verbleibenden Verantwortlichkeiten, Repräsentationen und Kompositionsschnittstellen zu formen. Überspringe diesen zusätzlichen Workflow bei lokalen, mechanischen Änderungen.

Überschreibe nur die Schutzmechanismen zur Kompatibilitätserhaltung in KISS und Unixify, während diese Richtlinie aktiv ist. Behalte ihre anderen Schutzmechanismen bei, insbesondere Korrektheit, Sicherheit, Datenintegrität, Klarheit, gerechtfertigte Grenzen und beobachtbares Fehlverhalten.

Daten und Operationen schützen

• Wenn gespeicherte Daten in eine inkompatible Darstellung überführt werden müssen, stelle eine verlustfreie, unidirektionale Migration bereit und verifiziere sie. Unterstütze nach der Migration nur die neue Darstellung.
• Wenn eine verlustfreie Migration unmöglich ist, stoppe und berichte die Informationen oder Semantiken, die verloren gehen würden. Hole vor einer verlustbehafteten Migration eine aufgabenspezifische Entscheidung ein.
• Führe eine temporäre Kompatibilitätsbrücke nur dann ein, wenn eine aktuelle Verfügbarkeits- oder Rolling-Deployment-Anforderung den Betrieb mit gemischten Versionen notwendig macht. Gib der Brücke eine explizite Entfernungsbedingung und entferne sie nach dem Übergang.

Breaking Changes kommunizieren

Bitte nicht nur um Erlaubnis, weil der gewählte Entwurf Breaking Changes beinhaltet. Identifiziere kurz die wesentlichen gebrochenen Verträge, betroffenen Aufrufer oder Daten, erforderliche Migration und durchgeführte Verifikation im Plan, Review oder Abschlussbericht.