Lennith/MyCodexSkills

Code Slim Refactor - Schlanker Code-Refactor

Auslösegrenze

Diese Fähigkeit nur verwenden, wenn der Benutzer explizit eine strukturierte Vereinfachung oder Konvergenz-Refactoring wünscht.

Nicht auslösen für:

• kleine Bereinigungen
• routinemäßige Fehlerbehebungen
• einmalige Umbenennungen
• gewöhnliche Refactorings, die keinen dedizierten Konvergenz-Workflow benötigen

Modi

Wähle einen Modus pro Durchlauf:

• quick: leichter Konvergenz-Durchlauf für einen kleinen oder gut abgegrenzten Bereich
• strict: formeller Refactor-Durchlauf mit vollständiger Rückverfolgbarkeit und Merge-Gates

Standardmäßig quick verwenden, es sei denn, der Benutzer wünscht ein formelles, prüfbares oder release-sensitives Refactoring.

Erforderliche Eingaben

• repo_path: absoluter Pfad zum Git-Repository
• refactor_goal: einzeiliges Konvergenzziel
• scope: optionaler Pfad oder Modul-Bereich
• mode: quick oder strict
• target_branch: nur für strict erforderlich, Standard master

Kernregel

Dieser Workflow bewahrt standardmäßig keine alte externe Kompatibilität, muss aber den beabsichtigten aktuellen Vertrag des abgegrenzten Systems bewahren.

Nie Backend-Verträge, Antwort-Semantiken oder Assertionsstandards ändern, nur um Tests bestehen zu lassen.

Schnellmodus

quick verwenden, wenn die Aufgabe begrenzt ist und der Benutzer hauptsächlich Konvergenz, nicht eine formelle Artefaktspur, wünscht.

Erforderliche Schritte:

1. Ziel, Umfang und die zu entfernende Hauptkomplexität benennen.
2. Eine kurze Aktionsliste im Gespräch oder eine minimale lokale Notiz führen, falls hilfreich.
3. Nur auf diese Aktionsliste bezogene Änderungen anwenden.
4. Backend-Verträge, Antwort-Semantiken und Assertionsstandards bewahren.
5. Fokussierte Validierung für den geänderten Bereich durchführen.
6. Wenn die Validierung auf eine Diskrepanz zwischen Backend und Test hindeutet, anhalten und das Vertragsdiskrepanz-Gate ausführen, bevor weitere Änderungen vorgenommen werden.
7. Berichten, welche Komplexität entfernt wurde, was beibehalten wurde und welches Restrisiko besteht.

./slim_refactor/-Artefakte sind im quick-Modus optional.

Strenger Modus

strict verwenden, wenn das Refactoring rückverfolgbar, prüfbar oder merge-gesichert sein muss.

Erforderliche Gates:

1. Einen dedizierten Arbeitsbranch erstellen und verwenden. Niemals direkt auf dem Zielbranch bearbeiten.
2. Design vor Code-Änderungen schreiben.
3. Artefakte unter ./slim_refactor/ verfolgen:
   • todolist.md
   • plan.md
   • report.md
4. Backend-Verträge, Antwort-Semantiken und Assertionsstandards bewahren.
5. In jeder Änderungsrunde eine Überprüfung durchführen.
6. Das Vertragsdiskrepanz-Gate ausführen, wenn die Validierung auf eine Diskrepanz zwischen Backend und Test hindeutet.
7. Den vollständigen Workflow-Gate vor dem Merge ausführen.

Vertragsdiskrepanz-Gate

Dieses Gate immer dann verwenden, wenn Tests auf eine Weise fehlschlagen, die auf eine Vertragsdiskrepanz statt auf eine echte Regression hindeuten könnte.

Erforderliche Aktionen:

1. Implementierungsänderungen anhalten, bis die Klassifikation abgeschlossen ist.
2. Aktuelles Verhalten, beabsichtigten aktuellen Vertrag und Testerwartungen vergleichen.
3. Eine unabhängige Unteragenten-Überprüfung starten, wenn Unteragenten verfügbar sind.
4. Wenn Unteragenten nicht verfügbar sind, einen expliziten lokalen Überprüfungs-Fallback durchführen und diesen Fallback in der Rundenausgabe festhalten.
5. Die Diskrepanz als genau eine der folgenden klassifizieren:
   • backend_regression: Backend-Verhalten ist falsch für den beabsichtigten aktuellen Vertrag.
   • stale_tests: Tests hinken dem beabsichtigten aktuellen Vertrag hinterher.

Erlaubte Aktionen nach der Klassifikation:

• backend_regression: Backend-Verhalten auf den beabsichtigten aktuellen Vertrag korrigieren. Tests nicht abschwächen, um das Problem zu verstecken.
• stale_tests: Nur die betroffenen Tests aktualisieren oder diese Tests für diese Runde überspringen. Backend-Verträge oder Assertionsstandards nicht lockern.

Wenn Tests übersprungen werden, den Stale-Gate-Zustand, den übersprungenen Umfang und die erforderliche Nachverfolgung melden, bevor die Runde beendet wird.

Ausführungsworkflow

Quick

1. Ziel, Umfang und Validierungsziel bestätigen.
2. Nicht wesentliche Komplexität mit dem kleinsten kohärenten Änderungssatz entfernen.
3. Löschung und Konvergenz gegenüber neuer Abstraktion bevorzugen.
4. Den beabsichtigten aktuellen Backend-Vertrag bei gleichzeitiger Strukturänderung bewahren.
5. Den betroffenen Bereich validieren.
6. Wenn die Validierung auf eine Diskrepanz zwischen Vertrag und Test hindeutet, das Vertragsdiskrepanz-Gate ausführen, bevor weitere Änderungen vorgenommen werden.
7. Konvergenzergebnis und Restrisiko zusammenfassen.

Strict

1. target_branch auschecken und synchronisieren.
2. BASE_SHA festhalten.
3. Branch codex/refactor/<topic>-<YYYYMMDD> erstellen.
4. ./slim_refactor/todolist.md erstellen oder aktualisieren.
5. ./slim_refactor/plan.md erstellen oder aktualisieren.
6. Nur im Plan deklarierte Aktionen implementieren.
7. Den beabsichtigten aktuellen Backend-Vertrag bei gleichzeitiger Konvergenz der Struktur bewahren.
8. Für jede Änderungsrunde eine Überprüfung durchführen und die Ergebnisse in ./slim_refactor/report.md festhalten.
9. Wenn die Validierung auf eine Diskrepanz zwischen Vertrag und Test hindeutet, das Vertragsdiskrepanz-Gate ausführen und Prüfertyp sowie Klassifikation festhalten.
10. Den vollständigen Workflow-Gate ausführen.
11. report.md mit Rückverfolgbarkeit und Merge- oder Block-Entscheidung finalisieren.

Ausgabeanforderungen

Immer berichten:

• entfernte Komplexität
• konvergierte Struktur
• Validierungsergebnis
• verbleibendes Risiko
• beibehaltene oder korrigierte Vertragsinvarianten
• Diskrepanzklassifikation, wenn zutreffend
• Prüfertyp (subagent oder local_fallback), wenn eine Diskrepanzüberprüfung stattfand
• geänderte oder übersprungene Tests, wenn veraltete Tests gefunden wurden

Für strict ebenfalls berichten:

• Branchname
• Artefaktpfade
• Überprüfungsergebnis
• Merge- oder Block-Entscheidung

Referenzen

• references/workflow-checklist.md
• references/design-spec-template.md
• references/todolist-template.md
• references/plan-template.md
• references/report-template.md