diff --git a/AGENTS.md b/AGENTS.md deleted file mode 100644 index 02cdd2d..0000000 --- a/AGENTS.md +++ /dev/null @@ -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. \ No newline at end of file diff --git a/skills/asv-small-step/SKILL.md b/skills/asv-small-step/SKILL.md deleted file mode 100644 index dfbf05e..0000000 --- a/skills/asv-small-step/SKILL.md +++ /dev/null @@ -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 \ No newline at end of file diff --git a/skills/asv-test-failure-clustering/SKILL.md b/skills/asv-test-failure-clustering/SKILL.md deleted file mode 100644 index 3e668b6..0000000 --- a/skills/asv-test-failure-clustering/SKILL.md +++ /dev/null @@ -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 \ No newline at end of file