Git Aufräumen
This commit is contained in:
57
AGENTS.md
57
AGENTS.md
@@ -1,57 +0,0 @@
|
|||||||
# ASV-Format-Validator
|
|
||||||
|
|
||||||
## Projektüberblick
|
|
||||||
- Java-/Maven-Projekt zur Validierung segmentorientierter Dateien gegen eine fachliche ASV-Spezifikation.
|
|
||||||
- Bestehenden Projektstand respektieren und darauf aufbauen.
|
|
||||||
- Keine Neuarchitektur.
|
|
||||||
|
|
||||||
## Technik
|
|
||||||
- Java 21
|
|
||||||
- Maven
|
|
||||||
- Log4j2
|
|
||||||
- kein Spring Boot
|
|
||||||
|
|
||||||
## Architektur- und Arbeitsregeln
|
|
||||||
- Nur kleine, kontrollierte Änderungen.
|
|
||||||
- Pro Arbeitsschritt genau eine kleine fachliche Regel oder eine eng abgegrenzte Stabilisierung.
|
|
||||||
- Kein Parser-Umbau ohne ausdrückliche Anweisung.
|
|
||||||
- Keine EDIFACT-Neuinterpretation auf Verdacht.
|
|
||||||
- Keine neue Validator-Hierarchie auf Verdacht.
|
|
||||||
- Keine Refactorings auf Verdacht.
|
|
||||||
- Bereits vorhandene Regeln und Tests dürfen nicht semantisch verbogen werden.
|
|
||||||
- Bestehende Funktionalität darf nicht verschlechtert werden.
|
|
||||||
|
|
||||||
## Parser-Leitplanken
|
|
||||||
- Aktuelle Parser-Annahmen respektieren.
|
|
||||||
- Keine zusätzliche Zerlegung von Feldwerten, außer ein bestehender Test und der aktuelle Projektstand erzwingen eine eng begrenzte lokale Korrektur.
|
|
||||||
- Keine allgemeine Normalisierung einführen, wenn nur ein lokaler Sonderfall benötigt wird.
|
|
||||||
|
|
||||||
## Code-Stil
|
|
||||||
- Technische Bezeichner auf Englisch.
|
|
||||||
- Kommentare, JavaDoc und benutzernahe Fehlermeldungen auf Deutsch.
|
|
||||||
- Vollständigen, kompilierbaren Code liefern.
|
|
||||||
- Änderungen minimal halten.
|
|
||||||
|
|
||||||
## Test- und Qualitätsregeln
|
|
||||||
- Nach jeder Änderung vollständig testen.
|
|
||||||
- Standardbefehl: `mvn clean test`
|
|
||||||
- Wenn Tests fehlschlagen:
|
|
||||||
- zuerst alle fehlgeschlagenen Tests gemeinsam analysieren
|
|
||||||
- gemeinsame Ursachen clustern
|
|
||||||
- dann alle zugehörigen Fehler in einem sauberen Durchgang beheben
|
|
||||||
- keine Fehler-für-Fehler-Mini-Iterationen
|
|
||||||
- Wenn neue Tests ergänzt werden:
|
|
||||||
- Testdaten fachlich isoliert halten
|
|
||||||
- keine unnötigen Zusatzfehler provozieren
|
|
||||||
|
|
||||||
## Änderungsschwerpunkte
|
|
||||||
- Bevorzugt bestehende Klassen gezielt ergänzen.
|
|
||||||
- Neue Klassen nur, wenn technisch wirklich nötig und klein.
|
|
||||||
- Für Validator-Schritte bevorzugt im bestehenden `DefaultStructureValidator` ergänzen, solange kein ausdrücklicher Architekturwechsel gefordert ist.
|
|
||||||
|
|
||||||
## Ausgabeerwartung
|
|
||||||
- Zuerst den ausgeführten Maven-Befehl nennen.
|
|
||||||
- Danach kurzes Testergebnis.
|
|
||||||
- Danach kurze Liste der geänderten Dateien.
|
|
||||||
- Danach vollständigen Code aller tatsächlich geänderten Dateien.
|
|
||||||
- Keine langen Erklärungen.
|
|
||||||
@@ -1,52 +0,0 @@
|
|||||||
---
|
|
||||||
name: asv-small-step
|
|
||||||
description: Verwende diesen Skill, wenn im ASV-Format-Validator ein neuer kleiner fachlicher Spezifikationsschritt umgesetzt werden soll. Der Skill erzwingt minimale Änderungen, Schutz des bestehenden Projektstands, keinen Parser-Umbau und vollständige Tests.
|
|
||||||
license: Proprietary
|
|
||||||
metadata:
|
|
||||||
project: asv-format-validator
|
|
||||||
language: de
|
|
||||||
---
|
|
||||||
|
|
||||||
# ASV Small Step
|
|
||||||
|
|
||||||
## Zweck
|
|
||||||
Dieser Skill ist für kleine, klar abgegrenzte Implementierungsschritte im Projekt ASV-Format-Validator gedacht.
|
|
||||||
|
|
||||||
## Verbindliche Arbeitsweise
|
|
||||||
- Implementiere genau **eine** neue fachliche Regel oder einen eng abgegrenzten Stabilisierungsschritt.
|
|
||||||
- Baue strikt auf dem bestehenden Projektstand auf.
|
|
||||||
- Kein Parser-Umbau.
|
|
||||||
- Keine EDIFACT-Neuinterpretation auf Verdacht.
|
|
||||||
- Keine neue Validator-Hierarchie auf Verdacht.
|
|
||||||
- Keine Refactorings auf Verdacht.
|
|
||||||
- Bestehende Regeln und Tests dürfen nicht semantisch verbogen werden.
|
|
||||||
|
|
||||||
## Architekturregeln
|
|
||||||
- Bevorzuge minimale Ergänzungen in bestehenden Klassen.
|
|
||||||
- Für Strukturregeln bevorzuge Ergänzungen im bestehenden `DefaultStructureValidator`, solange keine ausdrückliche Gegenanweisung vorliegt.
|
|
||||||
- Neue Klassen nur dann, wenn technisch zwingend nötig und sehr klein.
|
|
||||||
|
|
||||||
## Sprach- und Stilregeln
|
|
||||||
- Technische Bezeichner auf Englisch.
|
|
||||||
- Kommentare, JavaDoc und benutzernahe Fehlermeldungen auf Deutsch.
|
|
||||||
- Vollständigen, kompilierbaren Code liefern.
|
|
||||||
|
|
||||||
## Testregeln
|
|
||||||
- Für den neuen Schritt gezielte Tests ergänzen.
|
|
||||||
- Testdaten so gestalten, dass sie die neue Regel isoliert prüfen.
|
|
||||||
- Keine unnötigen Zusatzfehler in Testressourcen erzeugen.
|
|
||||||
- Nach der Umsetzung vollständig testen mit:
|
|
||||||
- `mvn clean test`
|
|
||||||
|
|
||||||
## Wenn Tests fehlschlagen
|
|
||||||
- Nicht nur den ersten Fehler beheben.
|
|
||||||
- Alle fehlschlagenden Tests gemeinsam analysieren.
|
|
||||||
- Nach gemeinsamer Ursache gruppieren.
|
|
||||||
- Alle zugehörigen Korrekturen in einem Durchgang umsetzen.
|
|
||||||
|
|
||||||
## Ausgabeformat
|
|
||||||
1. Ausgeführter Maven-Befehl
|
|
||||||
2. Kurzes Testergebnis
|
|
||||||
3. Sehr kurze Liste der geänderten Dateien
|
|
||||||
4. Vollständiger Code aller tatsächlich geänderten Dateien
|
|
||||||
5. Keine langen Erklärungen
|
|
||||||
@@ -1,51 +0,0 @@
|
|||||||
---
|
|
||||||
name: asv-test-failure-clustering
|
|
||||||
description: Verwende diesen Skill, wenn im ASV-Format-Validator Tests fehlschlagen. Der Skill erzwingt Root-Cause-Analyse über alle fehlschlagenden Tests, gruppierte Behebung in einem Durchgang und schützt vor Fehler-für-Fehler-Mini-Iterationen.
|
|
||||||
license: Proprietary
|
|
||||||
metadata:
|
|
||||||
project: asv-format-validator
|
|
||||||
language: de
|
|
||||||
---
|
|
||||||
|
|
||||||
# ASV Test Failure Clustering
|
|
||||||
|
|
||||||
## Zweck
|
|
||||||
Dieser Skill dient der strukturierten Behebung fehlgeschlagener Tests im Projekt ASV-Format-Validator.
|
|
||||||
|
|
||||||
## Verbindliche Vorgehensweise
|
|
||||||
1. Lies alle fehlgeschlagenen Tests und Fehlermeldungen vollständig.
|
|
||||||
2. Behebe nicht nur den ersten Fehler.
|
|
||||||
3. Bestimme gemeinsame Ursachen.
|
|
||||||
4. Gruppiere die Fehler nach Ursache.
|
|
||||||
5. Behebe jede Ursache in einem einzigen sauberen Durchgang.
|
|
||||||
6. Teste danach erneut vollständig.
|
|
||||||
|
|
||||||
## Prioritäten bei der Analyse
|
|
||||||
- Zuerst prüfen, ob Testdaten oder Assertions inkonsistent sind.
|
|
||||||
- Danach prüfen, ob neue Regeln unbeabsichtigte Folgefehler erzeugen.
|
|
||||||
- Produktivcode nur ändern, wenn ein echter Logikfehler belegt ist.
|
|
||||||
- Keine Umbauten auf Verdacht.
|
|
||||||
|
|
||||||
## Schutzregeln
|
|
||||||
- Kein Parser-Umbau.
|
|
||||||
- Keine neue fachliche Regel.
|
|
||||||
- Keine Refactorings auf Verdacht.
|
|
||||||
- Bestehende grüne Funktionalität darf nicht verschlechtert werden.
|
|
||||||
- Testressourcen müssen fachlich isoliert sein.
|
|
||||||
|
|
||||||
## Typische Fragen vor der Änderung
|
|
||||||
- Lösen mehrere Tests dieselbe gemeinsame Ursache aus?
|
|
||||||
- Ist die Testressource sauber isoliert?
|
|
||||||
- Passt die erwartete Assertion zur tatsächlichen Segmentanzahl bzw. zum tatsächlichen Parserverhalten?
|
|
||||||
- Entsteht ein Folgefehler nur wegen einer inkonsistenten Testdatei?
|
|
||||||
|
|
||||||
## Abschluss
|
|
||||||
- Nach den Korrekturen vollständig testen mit:
|
|
||||||
- `mvn clean test`
|
|
||||||
|
|
||||||
## Ausgabeformat
|
|
||||||
1. Ausgeführter Maven-Befehl
|
|
||||||
2. Kurzes Testergebnis
|
|
||||||
3. Sehr kurze Liste der geänderten Dateien
|
|
||||||
4. Vollständiger Code aller tatsächlich geänderten Dateien
|
|
||||||
5. Keine langen Erklärungen
|
|
||||||
Reference in New Issue
Block a user