Files
asv-format-validator/AGENTS.md

2.2 KiB

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.