Dokumente hinzugefügt

docs/specs/technik-und-architektur.md

@@ -0,0 +1,859 @@
+# Technik und Architektur
+
+> **Dokumentversion:** v5 (final)
+> **Stand:** 08.04.2026
+> **Status:** verbindlicher Architektur-Soll-Rahmen für die Implementierung von Version 1
+> **Bezugsspezifikation:** Technische Anlage ASV 1.09, Stand 09.10.2025, anzuwenden ab Leistungserbringungsquartal 2/2026
+
+## Zweck des Dokuments
+
+Dieses Dokument beschreibt den technischen und architektonischen Soll-Rahmen für das Projekt **ASV-Format-Validator** in **Version 1**.
+
+Dieses Dokument ist **kein Ersatz** für die offizielle ASV-Spezifikation. Bei jeder fachlichen oder technischen Kollision gilt stets die **Technische Anlage ASV 1.09, Stand 09.10.2025, anzuwenden ab Leistungserbringungsquartal 2/2026** als maßgebliche Wahrheit. Dieses Dokument konkretisiert nur die technische Umsetzung für Version 1.
+
+Nicht Bestandteil dieses Dokuments sind:
+
+- konkrete Implementierungs-Prompts für eine umsetzende KI
+- Arbeitspakete
+- Java-Code
+- die Datei `/docs/specs/fachliche-anforderungen.md`
+- GUI-Umsetzung
+- Server-, Container- oder Web-Betrieb
+- Mehrversionssupport der ASV-Spezifikation
+
+Version 1 verfolgt ein bewusst schlankes Zielbild: Eine **lokale Windows-CLI-Anwendung** soll **genau eine Datei pro Lauf** so robust wie technisch vertretbar analysieren, validieren und darüber berichten.
+
+## Zielversion der Spezifikation
+
+Version 1 richtet sich fachlich und technisch auf genau **eine** ASV-Zielversion aus:
+
+- **Technische Anlage 1.09**
+- **Stand 09.10.2025**
+- **anzuwenden ab Leistungserbringungsquartal 2/2026**
+
+Mehrversionsunterstützung ist nicht Scope von Version 1.
+
+Die Hinweis- und Erläuterungssektionen der Spezifikation sind **verbindlicher Regelinput**. Dazu gehören insbesondere auch Sonderregeln und Ausnahmen, etwa:
+
+- Pseudo-GOP `88999` bzw. regionale Pseudo-GOP
+- GOÄ-Sonderfall
+- Vertretungs-Teamebene `4`
+- obsolet gewordene, aber weiterhin zu füllende Felder `4/4.2.4` und `4/4.2.5`
+- Geburtsdatum-Sonderwerte im Ersatzverfahren
+- Regeln zu negativen numerischen Werten und Dezimaltrennzeichen
+
+## Technisches Zielbild
+
+Die Anwendung ist in Version 1 ein **reines CLI-Werkzeug** mit folgenden Eigenschaften:
+
+- lokaler Betrieb unter **Windows**
+- Auslieferung als **eine direkt startbare JAR-Datei**
+- Laufzeitvoraussetzung: **Java JDK 21**
+- genau **eine lokale Eingabedatei pro Programmaufruf**
+- Pflichtübergabe des Eingabepfads als **Positionsargument**
+- kein Serverbetrieb, keine Containerisierung, keine Web-Anwendung
+- kein stdin, keine Batch-Verarbeitung, keine Verzeichnisverarbeitung
+
+Die Architektur von Version 1 muss jedoch bereits so geschnitten sein, dass in einer späteren Version eine **JavaFX-GUI** ohne grundlegenden Umbau an denselben Kern angebunden werden kann.
+
+## Architekturprinzipien
+
+### Grundsätze
+
+Für Version 1 gelten folgende Architekturprinzipien:
+
+- **hexagonale Architektur** innerhalb des bestehenden Maven-Projekts
+- **keine neue Maven-Modulzerlegung als Sollvorgabe**, aber klare Pakettrennung
+- **evolutionäre Weiterentwicklung** des bestehenden Projekts in kleinen, sicheren Schritten
+- **kein schwergewichtiges Application-Framework**
+- **kein Dependency-Injection-Framework**
+- Verdrahtung erfolgt **manuell per Constructor Injection** im Bootstrap
+- **plain Java 21** plus gezielt eingesetzte Bibliotheken
+- externe Bibliotheken sind erlaubt, wenn sie die Lösung robuster, klarer oder kleiner machen
+- Design Patterns werden bewusst und gezielt eingesetzt, aber nie als Selbstzweck
+
+### Technische Entkopplung
+
+Der innere Kern bleibt strikt frei von Infrastruktur- und Technikdetails.
+
+**Nicht** in `domain` oder `application`:
+
+- CLI
+- Logging-Framework, konkrete Logging-Bindung oder Log-Konfiguration
+- Dateisystemzugriffe
+- PKCS#7-/Krypto-Bibliotheken
+- konkrete Parser-Bibliotheken
+- Berichtserzeugung als Text
+- Konsolen- oder Dateiausgabe
+
+Diese Dinge gehören ausschließlich in Adapter bzw. Infrastruktur. Insbesondere darf die konkrete Log4j2-Bindung niemals außerhalb des Bootstrap- oder Logging-Adapters sichtbar werden.
+
+## Gewünschte Paketstruktur
+
+Die Soll-Struktur innerhalb des bestehenden Projekts orientiert sich explizit an einer hexagonalen Trennung, zum Beispiel entlang folgender Pakete:
+
+- `domain`
+- `application`
+- `adapter.in.cli`
+- `adapter.out.filesystem`
+- `adapter.out.parsing`
+- `adapter.out.crypto`
+- `adapter.out.reporting`
+- `adapter.out.logging`
+- `bootstrap`
+
+Die exakten Paketnamen dürfen projektnah angepasst werden, die fachlich-technische Trennung muss aber klar erkennbar bleiben.
+
+## Verantwortlichkeiten der Schichten
+
+### Domain
+
+Die Domain enthält die stabilen fachlich-technischen Kernmodelle und Regeln, insbesondere:
+
+- kanonisches internes Modell der ASV-Inhalte
+- Befundmodell
+- Schichtmodell für Artefakte, technische Struktur und Fachsicht
+- gemeinsame Begriffe, Wertobjekte und Regelabstraktionen
+- keine Infrastrukturabhängigkeiten
+
+### Application
+
+Die Application orchestriert den Validierungslauf, insbesondere:
+
+- Annahme eines Validierungsauftrags
+- Steuerung der Erkennung, des Einlesens, des Parsings und der Validierung
+- Trennung zwischen **Spec-konformem Prüfurteil** und **zusätzlicher diagnostischer Weiteranalyse**
+- Zusammenführen aller Teilbefunde
+- Erzeugung eines strukturierten Gesamtergebnisses
+- keine textnahe Ausgabe, kein direktes Loggingformat, keine Dateiausgabe
+
+### Adapter in
+
+Der CLI-Adapter übernimmt ausschließlich ein- und ausgangsnahe Verantwortung:
+
+- Auslesen der CLI-Parameter
+- Übergabe an die Application
+- Schreiben des Berichts in Konsole und Berichtdatei
+- technische Initialisierung
+
+### Adapter out
+
+Adapter out kapseln technische Details, zum Beispiel:
+
+- Dateisystemzugriffe
+- Einlesen von Dateien inklusive Zeichensatzbehandlung
+- PKCS#7-/Krypto-Verarbeitung
+- Auftragsdatei-/Nutzdatendatei-Erkennung
+- Parser für technische Dateischichten
+- Bericht-Rendering als Text
+- Logging-Anbindung
+
+### Bootstrap
+
+Der Bootstrap startet die Anwendung, verdrahtet die Komponenten **manuell per Constructor Injection** und bleibt dünn.
+
+## Laufzeit- und Betriebsmodell
+
+### Grundverhalten
+
+Version 1 arbeitet pro Lauf:
+
+- mit **genau einer Eingabedatei**
+- **read-only** bezüglich der Eingabedatei
+- **zustandslos** im Sinne der fachlichen Verarbeitung
+- ohne Persistenz, Cache oder Historie
+- mit **immer erzeugtem Bericht**, auch bei frühen technischen Fehlern, soweit irgendetwas belastbar feststellbar ist
+
+### Ausgabeartefakte
+
+Version 1 erzeugt pro Lauf genau zwei Ausgabedateien im **Verzeichnis der Eingabedatei**:
+
+- eine **Berichtdatei** im Format `.txt`
+- eine **Log-Datei** im Format `.log`
+
+Zusätzlich wird der Validierungsbericht in die **Konsole** geschrieben.
+
+Sind für dieselbe Eingabedatei bereits Bericht- oder Log-Dateien vorhanden, werden neue Dateinamen mit laufendem Suffix erzeugt, zum Beispiel:
+
+- `_v1`
+- `_v2`
+- `_v3`
+
+Die Zählung erfolgt **pro Eingabedatei/Basisname**. Da Version 1 nur einen Lauf pro Aufruf kennt und kein Mehrbenutzerbetrieb vorgesehen ist, werden Race Conditions bei paralleler Ausführung auf derselben Eingabedatei nicht behandelt.
+
+### Zeichensätze
+
+- **Eingabedateien** werden grundsätzlich als **ISO 8859-15** verarbeitet.
+- Die Anwendung darf keine stillschweigende UTF-8- oder Plattform-Default-Dekodierung verwenden.
+- Bei Artefakten, deren eigene Metadaten einen Zeichensatzbezug enthalten, ist zusätzlich die Konsistenz zu diesen Metadaten zu prüfen.
+- **Bericht- und Log-Dateien** werden in **UTF-8** geschrieben.
+
+Hinweis: Eine tatsächlich abweichende Kodierung ist auf Byte-Ebene nicht immer sicher beweisbar. V1 behandelt daher primär Verstöße gegen **erwartete Zeichensatzfestlegungen** und **nicht darstellbare Inhalte** als Befunde.
+
+### EDIFACT-Trennzeichen und UNA
+
+Die Anwendung muss das **UNA-Segment** als optionales Service-Segment korrekt verarbeiten.
+
+Für ASV gelten gemäß Spezifikation folgende Trennzeichen:
+
+| Funktion | Zeichen | Dezimalcode |
+|---|---|---|
+| Segmentende | IS4 | 28 |
+| Datenelementtrennung | IS3 | 29 |
+| Gruppenelementtrennung | IS1 | 31 |
+| Dezimalzeichen | `,` | – |
+
+Für Version 1 gilt:
+
+- Ist `UNA` vorhanden, werden dessen Trennzeichenvorgaben geparst und geprüft.
+- Ist `UNA` nicht vorhanden, arbeitet der Parser mit den **ASV-konformen Standardtrennzeichen**.
+- Abweichende oder fehlerhafte Trennzeichenvorgaben sind als technische Befunde zu melden.
+
+## Unterstützte Eingabeartefakte
+
+Version 1 verarbeitet lokale Datei-Artefakte auf Dateisystemebene, insbesondere:
+
+- ASV-Nutzdatendateien mit `ASVREC`
+- ASV-Fehlernachrichten mit `ASVFEH`
+- Storno-Nachrichten als spezielle Ausprägung von `ASVREC`
+- Auftragsdateien (`.AUF`, KKS-Auftragssatz)
+- verschlüsselte bzw. transportnahe PKCS#7-Artefakte
+
+Nicht im Scope von Version 1:
+
+- E-Mail-Dateien wie `.eml` oder `.msg`
+- Server-/Transportintegration
+- Verzeichnis- oder Mehrdateiverarbeitung als eigener Betriebsmodus
+- automatische Korrektur oder Rewrite von Eingabedateien
+
+## Dateierkennung und Modussteuerung
+
+### Automatische Erkennung
+
+Der Validator soll Dateityp und verarbeitbare Schichten **automatisch erkennen**, soweit das zuverlässig möglich ist.
+
+### Explizite Benutzersteuerung
+
+Der Benutzer darf den Dateityp bzw. Prüfmodus **explizit vorgeben**. Diese Vorgabe ist maßgeblich.
+
+Wenn die automatische Erkennung zu einem anderen Ergebnis kommt als die Benutzervorgabe:
+
+- wird **gemäß Benutzervorgabe verarbeitet**
+- wird zusätzlich eine **Warnung** ausgegeben
+- erfolgt **kein Abbruch allein wegen dieses Widerspruchs**
+
+Wenn ein Dateityp nicht hinreichend sicher erkennbar ist und keine explizite Vorgabe vorliegt:
+
+- erfolgt eine **generische Basisprüfung**
+- wird mindestens eine **Warnung** ausgegeben
+
+## Dateinamenskonventionen
+
+Die Dateinamenschemata gemäß Spezifikation Abschnitt 3.5 sind **harte Prüfregeln** und werden vom Validator geprüft.
+
+### Unverschlüsselte Datei
+
+Schema: `B<VKNR><Jahr><Quartal><Zähler>` (11 Stellen)
+
+| Stelle | Inhalt |
+|---|---|
+| 1 | Konstante `B` für ASV |
+| 2–6 | VKNR oder `00000` bei Direktabrechnung |
+| 7 | Jahresbuchstabe (`A` = 2014, `B` = 2015 usw.) |
+| 8 | Quartal des Erstellungsjahres |
+| 9–11 | Zähler `001`–`999` |
+
+### Verschlüsselte Datei
+
+Schema: `<IK-Sender>_<IK-Kasse>_<E|T>ASV0<Zähler>`
+
+| Stelle | Inhalt |
+|---|---|
+| 1–10 | IK Sender plus `_` |
+| 11–20 | Abrechnungs-IK Kasse plus `_` |
+| 21 | `E` oder `T` |
+| 22–24 | `ASV` |
+| 25 | `0` |
+| 26–28 | Zähler `001`–`999` |
+
+### Auftragsdatei
+
+Die Auftragsdatei hat denselben Basisnamen wie die verschlüsselte Datei und endet auf `.AUF`.
+
+### Konsistenzregeln
+
+Mindestens folgende Konsistenzregeln sind zu prüfen:
+
+- physischer Dateiname ↔ `UNB_0020`
+- `UNB_0020` ↔ `UNZ_0020`
+- Anzahl Nachrichten in `UNZ_0010` ↔ tatsächliche Anzahl der `UNH`/`UNT`-Paare in der Datei
+- Referenzgleichheit `UNH_0062` ↔ `UNT_0062` je Nachricht
+- physischer Dateiname ↔ KKS-`DATEINAME`
+- Zähler im Dateinamen ↔ KKS-`TRANSFER_NUMMER`
+- Echtdaten-/Testdaten-Kennzeichen zwischen Dateiname, KKS und `UNB 0035`, soweit die jeweilige Schicht vorhanden ist; insbesondere darf `UNB 0035 = 1` nur für Testübertragungen verwendet werden, während Echtdaten dort keinen Testindikator tragen
+
+### Übermittlungszähler
+
+Für Version 1 gilt:
+
+- der Zähler wird auf **Wertebereich `001`–`999`** und **Struktur** (3-stellig, numerisch) geprüft
+- gemäß Spezifikation gilt ein Überlauf nach `999` zurück auf `001`; pro Erstellquartal sind maximal 999 Dateien pro Datensender und Krankenkasse zulässig
+- eine echte quartalsübergreifende Folgesequenzprüfung (lückenlose Inkrementierung über mehrere Übermittlungen hinweg) ist ohne Verlauf **nicht** möglich
+- diese Grenze ist als bewusste V1-Einschränkung im Bericht zu kennzeichnen
+
+## Paarigkeit von Dateien
+
+Zur verschlüsselten Nutzdatendatei gehört **deterministisch genau eine Auftragsdatei** mit identischem Basisnamen plus Endung `.AUF` im selben Verzeichnis.
+
+Version 1 sucht diese Partnerdatei **nicht heuristisch**, sondern unter dem exakt abgeleiteten Pfad.
+
+Wenn die Partnerdatei:
+
+- fehlt oder
+- inhaltlich nicht zur Hauptdatei passt,
+
+wird die übergebene Datei trotzdem geprüft. Zusätzlich wird eine **Warnung** ausgegeben.
+
+## Verarbeitungsmodell und Schichten
+
+Version 1 verwendet bewusst ein **mehrschichtiges internes Modell**.
+
+Mindestens folgende Sichten sind getrennt zu halten:
+
+1. **äußeres Artefakt**
+   - Datei auf Dateisystemebene
+   - Dateiname
+   - Dateityp
+   - PKCS#7-/Auftragsdatei-/Nutzdatei-Schicht
+
+2. **technische Struktur**
+   - Service-Segmente (`UNA`, `UNB`, `UNH`, `UNT`, `UNZ`)
+   - technische Datensätze des KKS-Auftragssatzes
+   - Datei-/Transportebene
+   - Nachrichtenhüllen
+
+3. **kanonisches Fachmodell**
+   - fachlich-technische Repräsentation der ASV-Nachrichten
+   - `ASVREC`, `ASVFEH` und Storno-Ausprägungen
+
+Diese Schichttrennung ist für Version 1 wichtig, damit:
+
+- technische Befunde nicht mit fachlichen Befunden vermischt werden
+- Teilinformationen auch bei Fehlern erhalten bleiben
+- eine spätere GUI differenziert auf dieselben Daten zugreifen kann
+- Spec-Verdikt und zusätzliche Diagnose sauber getrennt bleiben
+
+## Kanonisches internes Modell
+
+Alle unterstützten Eingabearten sollen nach Möglichkeit auf ein **gemeinsames internes Zielmodell** hinauslaufen.
+
+Dieses Modell dient als zentrale Grundlage für:
+
+- technische und fachliche Validierung
+- Berichtserzeugung
+- spätere GUI-Darstellung
+- spätere Erweiterungen wie alternative Ausgabeformen
+
+Zusätzlich muss das Modell **Traceability-Informationen** mitführen, insbesondere:
+
+- Artefaktschicht
+- Prüfstufe
+- Segmenttyp
+- Segmentindex
+- Feld bzw. Feld-ID
+- Rohwert
+- Position
+- Nachricht bzw. Fall
+
+## Mapping auf die Prüfstufen der Spezifikation
+
+Die Spezifikation definiert in Abschnitt 6 fünf Prüfstufen. Version 1 bildet diese **nicht vollumfänglich**, sondern **teilweise und transparent** ab.
+
+| Stufe | Inhalt laut Spec | Umsetzung in V1 |
+|---|---|---|
+| **0** | physikalische Lesbarkeit, Entschlüsselbarkeit | **lokal umsetzbar**, soweit anhand der vorliegenden Datei und des bereitgestellten Materials entscheidbar |
+| **1** | Service-Segment-Struktur, Dateistruktur, Kommunikationspartner, Referenzgleichheiten | **teilweise**: Struktur- und Konsistenzprüfungen werden lokal umgesetzt; **Kommunikationspartnerprüfung** ist ohne Referenzbestände nicht vollständig möglich |
+| **2** | Syntax der Nachricht und Feldebene | **lokal weitgehend** für Typ, Länge, Vorkommen und Segmentreihenfolge gemäß Nachrichtenaufbaudiagramm; gemeint sind **referenzfreie Syntaxregeln** der Nachricht und Feldebene |
+| **3** | formale Feldinhalte und Schlüsselverzeichnisabgleiche | **teilweise**: nur formale Prüfungen ohne externe oder eingebettete Referenzbestände |
+| **4** | Fachverfahren der einzelnen Krankenkassen | **nicht Bestandteil von V1** |
+
+Wichtig:
+
+- V1 darf zusätzlich zu einer spec-konformen Ablehnungsentscheidung **diagnostisch weiter analysieren**, wenn dies technisch sinnvoll ist.
+- Das interne Ergebnis muss deshalb zwischen **Spec-Urteil** und **zusätzlicher diagnostischer Weiteranalyse** unterscheiden.
+- Eine diagnostische Weiteranalyse hebt eine Spec-konforme Ablehnung **nicht** auf.
+- Diagnosebefunde dürfen das Spec-Urteil **niemals** in ein erfolgreiches Prüfurteil umdeuten.
+
+## Parsing und Validierung
+
+### Grundsatz
+
+Parsing und Validierung sind **architektonisch getrennt**, aber nicht künstlich isoliert.
+
+Es gilt ein **Hybrid-Modell**:
+
+- parse-nahe Sofortprüfungen sind erlaubt und sinnvoll
+- eigentliche Regelvalidierung erfolgt getrennt auf dem internen Modell
+
+### Parse-nahe Prüfungen
+
+Bereits beim Einlesen bzw. Parsing dürfen und sollen unter anderem erkannt werden:
+
+- Lesbarkeit und technische Verarbeitbarkeit
+- Zeichensatz- und Trennzeichenprobleme
+- Schicht- und Strukturprobleme
+- Service-Segment-Reihenfolge
+- grobe Segment- und Feldprobleme
+- elementare Formatverletzungen
+- technische Unstimmigkeiten, die für die weitere Verarbeitung relevant sind
+
+Parse-nahe Sofortprüfungen erzeugen **ausschließlich** strukturelle und technische Befunde, etwa zu Lesbarkeit, Zeichensatz, Trennzeichen, Service-Segment-Reihenfolge und groben Segment-/Feldfehlern. **Fachliche Regeln, feldwertbezogene Plausibilitäten und Bezugskontrollen** dürfen nicht in den Parser wandern, sondern gehören in die Regelvalidierung auf dem internen Modell.
+
+### Regelvalidierung
+
+Die eigentliche Validierung auf dem internen Modell umfasst unter anderem:
+
+- Pflichtfeldbeziehungen
+- Struktur- und Konsistenzregeln
+- Summen- und Bezugskontrollen
+- stornospezifische Regeln
+- Regeln für `ASVREC` und `ASVFEH`
+- KKS-Regeln des Auftragssatzes
+- fachlich-technische Plausibilitätsprüfungen, soweit ohne externe Referenzbestände möglich
+- Regeln, die sich aus Hinweisen und Bemerkungen der Spezifikation ergeben
+
+## KKS-Auftragssatz als eigener Prüfgegenstand
+
+AUF-Dateien dürfen architektonisch **nicht nur** als Partnerartefakt betrachtet werden. Der **KKS-Auftragssatz** ist ein **eigenständiger Validierungsgegenstand**.
+
+Mindestens folgende Regeln sind verbindlich zu modellieren:
+
+- **alle Muss-Felder des KKS-Auftragssatzes** werden mindestens auf **Mussbelegung, Feldtyp, Feldlänge und formale Werte** geprüft, auch wenn nicht jedes Feld zusätzlich fachlich gecrosst werden kann
+- `IDENTIFIKATOR = 500000`
+- `VERSION = 01`
+- `LÄNGE_AUFTRAG = 00000348`
+- `SEQUENZ_NR = 000`
+- **keine Teillieferungen** zulässig
+- `VERFAHREN_KENNUNG`: Stelle 20 `E` oder `T`, Stellen 21–23 `ASV`, Stelle 24 `0`
+- `VERFAHREN_KENNUNG_SPEZIFIKATION` ist gemäß Spezifikation ein **Kann-Feld**. Wird das Feld geliefert, muss es einen der definierten Werte tragen, in der Regel `ASVA0` für Abrechnung oder `ASVF0` für Fehlermeldung. Ein nicht geliefertes oder mit Blanks (`HEX 20`) gefülltes Feld ist **kein** Befund.
+- `ABSENDER_EIGNER`, `ABSENDER_PHYSIKALISCH`, `EMPFÄNGER_NUTZER` und `EMPFÄNGER_PHYSIKALISCH` sind als Muss-Felder strukturell und formal zu prüfen; eine vollständige inhaltliche Kommunikationspartnerprüfung ist ohne Referenzbestände jedoch nicht möglich
+- `FEHLER_NUMMER = 000000`
+- `FEHLER_MASSNAHME = 000000`
+- `DATEIVERSION = 000000`
+- `KORREKTUR = 0`
+- `DATEINAME` entspricht dem unverschlüsselten Dateinamen gemäß Dateinamensregeln
+- `DATUM_ERSTELLUNG` ist formal im vorgegebenen 14-stelligen Zahlenformat zu prüfen
+- `DATEIGRÖSSE_NUTZDATEN` (Stellen 179–190, M): muss exakt der unverschlüsselten Nutzdatendateigröße in Bytes entsprechen, soweit die unverschlüsselte Schicht lokal vorliegt.
+- `DATEIGRÖSSE_ÜBERTRAGUNG` (Stellen 191–202, M): muss exakt der verschlüsselten Übertragungsdateigröße in Bytes entsprechen.
+- `ZEICHENSATZ` (Stellen 203–204, M): Festwert `I5` (ISO 8859-15). Abweichungen sind als Fehler zu melden und sind zugleich der formale Anker für die ISO-8859-15-Annahme der gesamten Anwendung.
+- `KOMPRIMIERUNG = 00` (unkomprimiert)
+- `VERSCHLÜSSELUNGSART = 03`
+- `ELEKTRONISCHE_UNTERSCHRIFT = 03`
+- Datumsfelder sind, soweit lokal prüfbar, formal zu validieren
+- Kann-Felder des KKS-Auftragssatzes werden mindestens strukturell auf Feldtyp, Feldlänge und korrekte Nichtbelegungsfüllung geprüft
+
+Zusätzlich gilt für Kann-Felder:
+
+- numerische Kann-Felder werden bei Nichtbelegung mit Nullen (`HEX 30`) gefüllt
+- alphanumerische Kann-Felder werden bei Nichtbelegung mit Blanks (`HEX 20`) gefüllt
+
+## Regeln für Nutzdatennachrichten
+
+### `ASVREC`
+
+Für `ASVREC` sind mindestens zu modellieren:
+
+- Struktur und Reihenfolge der Segmente gemäß Spezifikation
+- Muss-/Kann-Logik je Feld
+- Bezugskonsistenz zwischen `IFA`, `DGN`, `LEA`, `SAC`, `GEN`, `OPA`, `REA`, `IVA`
+- Summenprüfung `REA` gegen `LEA` und `SAC`, soweit ohne externe Bestände lokal möglich
+- Regeln zur Storno-Variante
+- Ein-Datei-eine-Kasse-Regel
+
+### Storno-Variante
+
+Storno ist **keine freie Sonderbehandlung**, sondern eine eigene, klar definierte Strukturvariante.
+
+Für Version 1 gilt:
+
+- bei Storno werden nur die in der Spezifikation vorgesehenen Muss-Segmente und Muss-Felder erwartet
+- `REA` enthält das Rechnungskennzeichen für Storno
+- der Rechnungsbetrag ist gemäß Spezifikation zu behandeln
+- die ursprüngliche Rechnungsnummer ist als Bezug zur stornierten Nachricht zu führen
+- Segmente, die bei Storno laut Spezifikation entfallen, dürfen nicht fälschlich als Muss-Segmente eingefordert werden
+
+### `ASVFEH`
+
+Die Validierung von `ASVFEH` ist von `ASVREC` getrennt zu modellieren. Dabei gilt:
+
+- `ASVFEH` kann gemäß Spezifikation in zwei strukturellen Ausprägungen auftreten:
+  - als **eigenständige Übertragungsdatei** mit ausschließlich `ASVFEH`-Nachricht(en) – typisch für Stufe-1-Rückmeldungen (Struktur: `UNB`, `UNH` mit Nachrichtentyp `ASVFEH`, `FHL`, `UNT`, `UNZ`).
+  - als **eingebettete Nachricht** innerhalb einer Übertragungsdatei, die zusätzlich die Originalnutzdatensegmente trägt – typisch für Stufen 2 bis 4 (Struktur: `UNH`, originale Nutzdatensegmente, `FHL`, `UNT`).
+  V1 muss beide Ausprägungen erkennen und korrekt verarbeiten.
+
+- Die Originalnachricht ist bei **Prüfstufe 1 nicht zu übertragen**.
+- Die Originalnachricht ist bei **Prüfstufen 2 bis 4 grundsätzlich mitzuliefern**. Ihre Abwesenheit ist **kein Fehler**, wenn die Originalnutzdaten gemäß Spezifikation nicht lesbar oder nicht der vereinbarten Syntax entsprechend übertragbar waren. V1 darf das Fehlen der Originalnachricht in `ASVFEH` daher nicht pauschal als Befund melden, sondern höchstens als Hinweis.
+- Die Validierung einer `ASVFEH` **erstreckt sich nicht auf die mitgelieferte Originalnachricht** als eigenständigen Validierungsgegenstand.
+- Hinweis: Die Spec verbietet, eine Fehlernachricht ihrerseits mit einer Fehlernachricht zu beantworten. Diese Regel betrifft das Verfahren zwischen Sender und Empfänger und ist an einer einzelnen, isoliert übergebenen Datei nicht prüfbar. V1 setzt sie deshalb **nicht** als Validierungsregel um.
+- Für `FHL`-Segmente gilt: Kann-Datenelemente werden zu Muss-Datenelementen, wenn ihr Inhalt aus der Fehlersituation bestimmbar ist. V1 darf dies nur dort als Fehler umsetzen, wo diese Ermittelbarkeit aus der vorliegenden Datei belastbar ableitbar ist.
+- Die Spezifikation sieht für `FHL` bis zu 99 Vorkommen vor; diese Obergrenze ist strukturell zu berücksichtigen.
+
+## Bekannte Spec-Fallstricke und Pflichtregeln
+
+Die folgenden Regeln sind verbindlich zu berücksichtigen. **Die hier genannten Sonderwerte und Ausnahmen dürfen im jeweils von der Spec vorgesehenen Feld- und Kontextbezug nicht als Fehler oder Warnung gemeldet werden** — eine naive Format- oder Pflichtfeldprüfung muss diese Sonderfälle aktiv aussparen:
+
+- **Geburtsdatum im Ersatzverfahren** (Feld `8/8.4.3`): Im Format `JJJJMMTT` sind beliebige numerische Werte zulässig; der Inhalt muss nicht zwingend einem logischen Kalenderdatum entsprechen. Zusätzlich sind die Platzhalter `00` (unbekannter Tag), `0000` (unbekannter Tag und Monat) und `00000000` (vollständig unbekannt) zulässig. Eine Datumsplausibilisierung in diesem Feld ist daher unzulässig.
+- **Pseudo-GOP `88999`** bzw. regionale Pseudo-GOP ist für Sachkosten ohne Sachzusammenhang zulässig.
+- **GOÄ-Übermittlung**: In Feld `3/3.2.1` ist die Pseudo-GOP zu übertragen, in Feld `3/3.2.5` die zugehörige GOÄ-Ziffer.
+- **Vertretung**: Bei Teamebene `4` ist die Teamebene des Vertretenen maßgeblich.
+- **Obsolete Muss-Felder `4/4.2.4` und `4/4.2.5`** (ab Q1/2020 fachlich obsolet) bleiben füllpflichtig mit beliebigem Inhalt, der jedoch **nicht ausschließlich aus Leerzeichen** bestehen darf. Inhaltlich werden diese Felder nicht geprüft.
+- **Negative numerische Werte** zählen das führende Minuszeichen nicht zur maximalen Feldlänge.
+- **Dezimalzeichen `,`** zählt nicht zur maximalen Feldlänge.
+- **Pro Datei darf nicht kassenübergreifend gebündelt werden**.
+- **Sortierreihenfolge der Nachrichten** innerhalb einer Datei ist gemäß Spec willkürlich. V1 darf keine Sortierregel erzwingen.
+- **Vertraglich bedingte Muss-Felder**: Einige Muss-Felder sind in der Spec mit dem Hinweis „wird erst geliefert, wenn vertraglich vereinbart" markiert. Diese werden in V1 nicht hart erzwungen.
+
+### Versichertennummer
+
+Für Version 1 gilt mindestens die Strukturprüfung:
+
+- Stelle 1: Alpha `A`–`Z` ohne Umlaute
+- Stellen 2–9: numerisch
+- Stelle 10: Prüfzifferstelle vorhanden
+
+Eine echte algorithmische Prüfziffervalidierung darf nur dann verpflichtend werden, wenn der offizielle Algorithmus außerhalb der ASV-Spezifikation eindeutig, verlässlich und rechtssicher vorliegt. Sie ist **kein Muss dieses Dokuments**, solange die ASV-Spezifikation selbst den Algorithmus nicht definiert.
+
+## Regelmodell und Design Patterns
+
+Prüfregeln sind in Version 1 **explizit als eigene, separat testbare Regel-Komponenten** zu modellieren.
+
+Erwartet wird ein regelorientierter Zuschnitt, zum Beispiel mit sinnvollen Pattern-Ansätzen wie:
+
+- Strategy / Policy für Prüfvarianten
+- Specification-artigen Regelobjekten für kombinierbare Regeln
+- Pipeline / Chain für geordnete Prüfschritte
+
+Die Regeln dürfen **nicht verteilt und unübersichtlich** in Parsern, Hilfsklassen oder Services zerfasern.
+
+## Fehlertoleranz und Robustheit
+
+Version 1 verfolgt ein robustes Leitprinzip:
+
+> Die Datei wird auf Biegen und Brechen geprüft, so weit die Technik das zulässt.
+
+Daraus folgen insbesondere:
+
+- bei Teilfehlern wird nach Möglichkeit weitergearbeitet
+- ein schwerer Fehler in einer Nachricht stoppt nicht automatisch die übrigen Nachrichten derselben Datei
+- frühe technische Probleme verhindern nicht grundsätzlich einen Bericht
+- Teilbefunde werden erhalten und sichtbar gemacht
+- zusätzliche diagnostische Analyse ist erlaubt, auch wenn die Spec auf derselben Ebene bereits eine Zurückweisung verlangen würde
+
+Wichtig: Die diagnostische Weiteranalyse ändert **nicht** das spec-konforme Prüfurteil.
+
+## Unbekannte oder fremde Inhalte
+
+Unbekannte, nicht erwartete oder versionsfremde Segmente bzw. Felder sollen, soweit technisch möglich:
+
+- **erhalten** bleiben
+- als **unbekannt** markiert werden
+- in Bericht und internem Modell sichtbar sein
+- nicht vorschnell verworfen werden
+
+Das Ziel ist maximaler Erkenntnisgewinn aus der Eingabedatei, auch wenn nicht alles vollständig interpretierbar ist. Das Erhalten unbekannter Inhalte dient ausschließlich der **Diagnose** und verändert das **Spec-Urteil** nicht.
+
+## Ergebnis- und Befundmodell
+
+### Interne Ergebnisstruktur
+
+Der Kern liefert **immer ein strukturiertes internes Resultat**. Dieses Resultat ist die einzige Grundlage für:
+
+- Konsolenbericht
+- Berichtdatei
+- spätere GUI-Darstellung
+
+Der Kern selbst erzeugt keine textnahen Endformate.
+
+### Befundarten
+
+Das Befundmodell kennt:
+
+- **Fehler**
+- **Warnungen**
+- **Hinweise**
+
+Zusätzlich muss jeder Befund mindestens folgende Meta-Informationen tragen, soweit sinnvoll ermittelbar:
+
+- Artefaktschicht
+- Prüfstufe
+- Prüfebene / Prüfbereich
+- Segmenttyp
+- Segmentindex
+- Feld / Feld-ID
+- Rohwert
+- Position
+- Nachricht bzw. Fall
+- optional offizieller Spec-Fehlercode
+
+Wo eine eindeutige Zuordnung zu einem offiziellen Fehlercode möglich ist, wird dieser am Befund hinterlegt. Wo keine eindeutige Zuordnung möglich ist, darf das interne Modell eigene technische Befundklassen verwenden.
+
+**Vorrang offizieller Fehlercodes**: Die Spezifikation definiert in Abschnitt 7 generische Sammelfehlercodes (`xx999`, `3A998`, `4A998`). Diese dürfen **nicht** verwendet werden, wenn für den konkreten Sachverhalt ein spezifischerer offizieller Fehlercode existiert. V1 hält diese Vorrangregel ein, sobald Befunde mit offiziellen Fehlercodes annotiert werden.
+
+### Gültigkeitsentscheidung und Exit-Codes
+
+Nur **Fehler** machen eine Datei insgesamt ungültig.
+
+| Exit-Code | Bedeutung |
+|---|---|
+| `0` | gültig, keine Fehler-Befunde |
+| `1` | ungültig, mindestens ein Fehler-Befund |
+| `2` | Bedienfehler, zum Beispiel fehlendes Argument oder nicht lesbare Eingabedatei |
+
+Warnungen und Hinweise beeinflussen den Exit-Code nicht.
+
+Auch bei `Exit-Code 2` soll, soweit technisch möglich, ein **Minimalbericht** erzeugt werden, der den Bedien- oder Zugriffsfehler nachvollziehbar beschreibt.
+
+## Prüfebenen und Berichtsgliederung
+
+Die Anwendung soll Befunde mindestens auf zwei Ebenen explizit unterscheiden:
+
+1. **Datei-/Transportebene**
+   - Dateiname
+   - äußere Schichten
+   - Partnerdatei-Aspekte
+   - technische Hüllen
+   - Gesamtstruktur
+
+2. **Nachrichten-/Fall-Ebene**
+   - einzelne `UNH`…`UNT`-Nachrichten
+   - fallbezogene Inhalte und Befunde
+
+Der Standardbericht ist **hierarchisch** aufgebaut, primär nach:
+
+- Datei
+- Schichten
+- Nachrichten/Fällen
+- Befunden
+
+Zusätzlich soll der Standardbericht strukturierte Bestandsinformationen enthalten, zum Beispiel:
+
+- erkannter Dateityp
+- erkannte Schichten
+- Anzahl Nachrichten/Fälle
+- relevante Kopfdaten
+- Übermittlungszähler
+- spec-konformes Prüfurteil
+- zusätzliche diagnostische Auffälligkeiten
+
+## Grenzen der Validierung in Version 1
+
+Version 1 enthält **keine eingebetteten Katalog- oder Referenzbestände**.
+
+Das bedeutet insbesondere:
+
+- keine mit der Anwendung ausgelieferten ICD-/OPS-/IK-/Stammdatenbestände
+- keine Abhängigkeit von externen Online-Diensten
+- keine lokal separat gepflegten Referenzdaten als Voraussetzung
+
+Konsequenzen:
+
+- Kommunikationspartnerprüfungen können nicht vollständig umgesetzt werden.
+- Schlüsselverzeichnisabgleiche für IK, ICD, OPS und ähnliche Bestände entfallen.
+- Die in der Spezifikation geforderte Prüfung der BSNR gegen das ASV-Verzeichnis bzw. die Arztstammdaten ist mangels Referenzbestand **nicht Bestandteil von V1**; eine BSNR wird strukturell, aber nicht inhaltlich gegen einen Stammdatenbestand geprüft.
+- Stufe 3 ist in Version 1 deshalb **nur formal**, nicht vollständig.
+- Stufe 4 ist nicht Bestandteil von Version 1.
+
+Prüfungen, die ohne solche Bestände nicht belastbar entscheidbar sind, werden in Version 1 **nicht durchgeführt**. Sie dürfen aber als **bewusst nicht geprüfter Bereich** im Bericht kenntlich gemacht werden.
+
+## Krypto- und Schichtverarbeitung
+
+Version 1 unterstützt Basis- und Tiefenprüfung verschlüsselter bzw. transportnaher Dateien im Scope der Anwendung.
+
+### Architektur
+
+- Krypto-Verarbeitung erfolgt **innerhalb der Java-Anwendung**.
+- Externe Tools oder Binaries sind ausgeschlossen.
+- Technische Krypto-Integration ist gekapselt hinter internen Ports und Abstraktionen.
+- Wenn die äußere Schicht erfolgreich verarbeitet werden kann, wird automatisch bis zur **inneren fachlichen Nutzlast** weitergegangen und diese mitvalidiert.
+- Wenn bereitgestelltes Krypto-Material technisch nicht nutzbar ist, erfolgt **Fallback auf Basisprüfung** mit Warnung.
+- Schlüssel- und Passwortmaterial wird nur **explizit per CLI** bereitgestellt.
+- Für Version 1 darf der Materialinput pragmatisch auf wenige Formate begrenzt werden, solange dies dokumentiert und technisch sauber gekapselt ist.
+
+### Mindest-Algorithmen
+
+Soweit die jeweilige Datei diese Informationen oder Anforderungen betrifft, sind mindestens folgende Verfahren zu berücksichtigen:
+
+| Aspekt | Verfahren |
+|---|---|
+| Verschlüsselungsformat | PKCS#7 |
+| Session Key | AES-256-CBC |
+| Interchange Key | RSA 4096 Bit |
+| Hash-/Signaturverfahren | SHA256withRSAandMGF1 / PSS |
+| RSA-Exponent | Fermat-4 (`2^16 + 1`) |
+
+Nicht-PSS-Altverfahren vor der Umstellung müssen in Version 1 **nicht** aktiv unterstützt werden, dürfen aber als erkannte Abweichung gemeldet werden.
+
+## CLI-Zuschnitt in Version 1
+
+Version 1 bleibt bewusst minimal.
+
+### CLI-Grundsätze
+
+- genau **ein fachlicher Hauptmodus**: validieren
+- keine frühe Aufblähung durch zusätzliche Subcommands
+- keine Pflicht für `--help` oder `--version`
+- README ist die primäre Nutzungsdokumentation
+- CLI-Optionsnamen sind **Englisch**
+- nutzerseitige Ausgaben sind **Deutsch**
+- Schlüssel- und Passwortmaterial für PKCS#7-Verarbeitung wird ausschließlich **explizit per CLI-Option** übergeben. Ohne Material erfolgt **Fallback auf Basisprüfung mit Warnung** statt hartem Abbruch. Konkrete Optionsnamen sind in der README dokumentiert.
+
+### Ausgabewege
+
+- strukturierter Validierungsbericht in **Konsole**
+- derselbe Bericht zusätzlich in **Berichtdatei**
+- technisches Logging zusätzlich in **Log-Datei**
+
+## Logging und Berichtserzeugung
+
+### Logging
+
+Version 1 verwendet für technisches Logging:
+
+- **SLF4J als Fassade**
+- **Log4j2 als Implementierungs-Bindung**
+
+Die konkrete Log4j2-Bindung darf ausschließlich in Bootstrap und Logging-Adapter sichtbar sein.
+
+Das Logging ist **immer aktiv** und wird in eine **Log-Datei** geschrieben.
+
+### Bericht
+
+Der Validierungsbericht ist **kein normales Logging**, sondern ein eigenes Ausgabeartefakt mit stabiler Struktur.
+
+Er wird:
+
+- in die **Konsole** geschrieben
+- in eine **Berichtdatei** geschrieben
+
+Bericht und Logging sind architektonisch strikt getrennt.
+
+## Sprach- und Dokumentationskonventionen
+
+Für Version 1 gelten folgende Konventionen:
+
+- Nutzertexte auf **Deutsch**
+- JavaDoc auf **Deutsch**
+- Logtexte auf **Deutsch**
+- Berichtstexte auf **Deutsch**
+- Klassennamen auf **Englisch**
+- Bezeichner und Variablennamen auf **Englisch**
+
+## Test- und Qualitätsanforderungen
+
+### Teststufen
+
+Verbindlich vorgesehen sind:
+
+- **Unit-Tests**
+- **CLI-Integrationstests**
+- **dateibasierte End-to-End-Tests**
+
+Dabei gilt:
+
+- keine Echtdaten im Projekt
+- nur synthetische, anonymisierte oder speziell erzeugte Testdaten
+- Parser-, KKS-, ASVFEH- und Storno-Fälle sind gezielt mit Testartefakten abzudecken
+
+### Qualitätsgates
+
+Verbindliche Gates für Version 1:
+
+- Build muss grün sein
+- alle Tests müssen grün sein
+- **Coverage mindestens 85 %** gesamtprojektweit
+- **PIT-Mutation-Score mindestens 70 %** gesamtprojektweit
+
+Zusätzlich gelten differenzierte Zielschwellen:
+
+| Bereich | Coverage | Mutation |
+|---|---|---|
+| `domain` | ≥ 95 % | ≥ 85 % |
+| `application` | ≥ 90 % | ≥ 80 % |
+| `adapter.out.*` | ≥ 90 % | ≥ 75 % |
+| `adapter.in.cli` | ≥ 80 % | ≥ 60 % |
+| `bootstrap` | ausgenommen | ausgenommen |
+
+Zusätzlich gilt:
+
+- echte Parser-, Erkennungs- und Validierungslogik soll sehr hoch abgesichert sein
+- triviale Getter/Setter/Record-Accessoren benötigen keine künstlichen Pflicht-Tests
+- einfache unveränderliche Datenträger sollen bevorzugt als **Records** modelliert werden, wenn das fachlich-technisch passt
+- Wertobjekte mit eigenem Validierungsbedarf werden als reguläre Klassen modelliert
+
+## Regeln für spätere Umsetzung durch eine kontextlos arbeitende KI
+
+Für spätere KI-gestützte Umsetzung gilt:
+
+- Architektur strikt evolutionär weiterentwickeln
+- keine große Komplett-Neustrukturierung in einem Wurf
+- Kern von Infrastruktur trennen
+- neue Technik nur über Adapter einführen
+- Regeln explizit und separat testbar schneiden
+- KKS-Auftragssatz und `ASVFEH` als eigene Prüfdomänen behandeln
+- Berichtserzeugung nie im Kern verankern
+- robuste Weiterverarbeitung bevorzugen
+- Spec-Verdikt und Diagnose strikt trennen
+- keine unnötigen Bibliotheken, aber pragmatischer Einsatz sinnvoller Tools ist erlaubt
+- kein Spring, kein Quarkus, kein DI-Framework
+- manuelles Constructor-Wiring im Bootstrap
+- Version 1 bewusst klein halten und zuerst nutzbar machen
+
+## Nicht-Ziele von Version 1
+
+Nicht Ziel von Version 1 sind insbesondere:
+
+- GUI
+- Mehrversionssupport der ASV-Spezifikation
+- Web-, Server- oder Containerbetrieb
+- Verzeichnis- oder Batchverarbeitung
+- JSON-Ausgabe
+- externe Konfigurationsdateien
+- eingebettete oder online aufgelöste Referenzdatenbestände als Pflichtbestandteil
+- vollständige Kommunikationspartnerprüfung ohne Referenzdaten
+- vollständige Stufe-3-Schlüsselverzeichnisabgleiche
+- Stufe-4-Prüfungen
+- automatische Korrektur oder Rewrite von Eingabedateien
+- PDF-Bericht
+- funktionale Aufblähung ohne praktischen Bedarf
+
+## Glossar
+
+| Begriff | Bedeutung |
+|---|---|
+| **ASV** | Ambulante spezialfachärztliche Versorgung gemäß § 116b Abs. 6 Satz 12 SGB V |
+| **ASVREC** | EDIFACT-Nachrichtentyp für die ASV-Abrechnung (Rechnung) |
+| **ASVFEH** | EDIFACT-Nachrichtentyp für die ASV-Fehlerrückmeldung |
+| **Storno** | Spezielle Strukturvariante einer `ASVREC`-Nachricht zur Stornierung einer zuvor übermittelten Rechnung |
+| **KKS** | Kommunikations-Kontroll-Satz; Auftragssatzformat zur Beschreibung einer Übertragungsdatei (Auftragsdatei `.AUF`) |
+| **EDIFACT** | Electronic Data Interchange For Administration, Commerce and Transport – Format der Nutzdatensegmente |
+| **Service-Segmente** | EDIFACT-Hüllsegmente: `UNA`, `UNB`, `UNH`, `UNT`, `UNZ` |
+| **FHL** | Fehlersegment innerhalb einer `ASVFEH`-Nachricht |
+| **PKCS#7** | Standard-Containerformat für signierte und verschlüsselte Nachrichten gemäß ISIS-MTT |
+| **Prüfstufen** | Spec-Prüfstufen 0–4 (physikalisch / Datei und Service-Segmente / Syntax / formale Feldinhalte / Fachverfahren der Krankenkassen) |
+| **Spec-Urteil** | Verbindliches Prüfurteil gemäß Spezifikation: gültig oder ungültig |
+| **Diagnose** | Zusätzliche, spec-unabhängige Weiteranalyse zur Erkenntnisgewinnung; verändert das Spec-Urteil nicht |
+| **Hexagonale Architektur** | Trennung von Domain/Application und technischen Adaptern (Ports & Adapters) |
+
+## Dokumenthistorie
+
+| Version | Wesentliche Änderungen |
+|---|---|
+| v1 | Erstfassung mit Architekturgrundsätzen |
+| v2 | ISO-8859-15, Prüfstufen-Mapping, Dateinamen, Crosschecks, KKS, ASVFEH, Krypto-Mindestalgorithmen, Exit-Code 2, differenzierte Quality Gates |
+| v3 | `VERFAHREN_KENNUNG_SPEZIFIKATION` als Kann-Feld, `DATEIGRÖSSE_*` als Crosschecks, `ZEICHENSATZ = I5`, ASVFEH-Originalnachricht-Ausnahme, Hybrid-Modell geschärft, `UNZ_0010`/`UNH_0062`-Crosschecks, Sortierreihenfolge willkürlich |
+| v4 | Stufe-2-Wording entschärft, Diagnose darf Spec-Urteil nicht aufheben, alle KKS-Muss-Felder strukturell zu prüfen, ABSENDER/EMPFÄNGER-Felder explizit, Sonderfall-Regel kontextbezogen, `UNB 0035`-Testindikator präzisiert, FHL bis 99 Vorkommen, Minimalbericht bei Exit-Code 2 |
+| v5 | Geburtsdatum-Sonderfall vollständig (beliebige numerische Werte plus Platzhalter), GOÄ-Felder konkret (`3/3.2.1`/`3/3.2.5`), obsolete Felder „nicht ausschließlich Leerzeichen", Übermittlungszähler-Wertebereich `001`–`999` mit Wraparound, ASVFEH-Strukturvarianten (eigenständige vs. eingebettete Datei), Vorrang offizieller Fehlercodes (`xx999`/`3A998`/`4A998`), BSNR-Stammdatencheck als nicht-Bestandteil von V1, Glossar, Dokumenthistorie |
+
+## Zusammenfassung
+
+Version 1 des ASV-Format-Validators ist eine bewusst schlanke, lokal unter Windows laufende Java-21-CLI-Anwendung mit hexagonaler Architektur, robustem Validierungskern, explizitem Regelmodell und strikt getrennten Infrastrukturadaptern. Sie prüft genau eine Datei pro Lauf gegen die Technische Anlage ASV 1.09, verarbeitet Eingaben auf Basis von ISO 8859-15, modelliert AUF/KKS, `ASVREC`, `ASVFEH` und Storno explizit, trennt spec-konformes Prüfurteil von zusätzlicher diagnostischer Weiteranalyse, bildet Prüfstufen transparent nur insoweit ab, wie dies lokal ohne Referenzbestände möglich ist, und erzeugt daraus einen stabil gegliederten deutschen Textbericht sowie ein technisches Log.