docs: Review-Korrekturen aus Peer-Review anwenden

- UNZ_0010 -> UNZ_0036 (meilensteine.md, technik-und-architektur.md)
- FEHLER_MASSNAHME -> FEHLER_MAßNAHME (meilensteine.md, technik-und-architektur.md)
- Exit-Code-Kommentar bereinigt (CLAUDE.md)
- V1-K-Nachrangigkeit ergaenzt (CLAUDE.md)
- Zielbild-Anmerkung in README
- Spec-Tippfehler DATUM_ERSTELLUNG dokumentiert (technik-und-architektur.md)
- R-CROSS-KKS-SPEZ-NACHRICHTENTYP-001 ergaenzt (fachliche-anforderungen.md)
- R-IFA-OVER-002 Quelle praezisiert, V1-V bestaetigt (fachliche-anforderungen.md)
- R-FHL-2.13-001 Feldart K, Regeltext angepasst (fachliche-anforderungen.md)
- R-GLOBAL-MIN-NACHRICHTEN-001 ergaenzt (fachliche-anforderungen.md)
- RSA-Schluessellaengen-Hinweis ergaenzt (technik-und-architektur.md)

docs/specs/fachliche-anforderungen.md

@@ -163,6 +163,7 @@ Diese Regeln gelten **artefaktübergreifend** und sind unabhängig davon zu prü
 | `R-GLOBAL-UNKOMPRIMIERT-001` | Grundsätze Datenübermittlung | ASV-Dateien werden unkomprimiert übertragen. | V1-V | kein eindeutiger offizieller Fehlercode |
 | `R-GLOBAL-EINE-KASSE-001` | Grundsätze Datenübermittlung | Pro Kasse (unterschiedliches Abrechnungs-IK) wird genau eine Datei erstellt; eine Bündelung mehrerer Kassen in einer Datei ist unzulässig. | V1-V | kein eindeutiger offizieller Fehlercode |
 | `R-GLOBAL-SORTIERUNG-001` | Hinweis zur Nachrichtenstruktur | Die Sortierreihenfolge der Nachrichten innerhalb einer Datei ist gemäß Spezifikation willkürlich. V1 darf keine Sortierregel erzwingen. | V1-V | kein offizieller Fehlercode, da kein Verstoß bei beliebiger Reihenfolge |
+| `R-GLOBAL-MIN-NACHRICHTEN-001` | Grundsätze Datenübermittlung, „mindestens jedoch eine ASV-Nachricht" | Eine Nutzdatendatei muss mindestens ein `UNH`/`UNT`-Paar enthalten. Eine Datei ohne jede Nachricht ist ungültig. | V1-V | `10003` (UNH fehlt) |
 
 ## 6. Fachlich relevante Eingabeartefakte und Nachrichtentypen
 
@@ -233,9 +234,9 @@ Für spätere Implementierung und Arbeitspakete gilt:
 | 2 | `IFA` | Muss | einmal pro Nachricht |
 | 3 | `DGN` | Kann, 0..n | bei Rechnung fachlich regelmäßig erforderlich; bei Storno unzulässig |
 | 4 | `LEA` | Kann, 0..n | bei Rechnung fachlich regelmäßig erforderlich; bei Storno unzulässig |
-| 5 | `SAC` | Kann, 0..n je `LEA` | nur innerhalb einer Leistung |
-| 6 | `GEN` | Kann, 0..n je `LEA` | nur innerhalb einer Leistung |
-| 7 | `OPA` | Kann, 0..n je `LEA` | nur innerhalb einer Leistung |
+| 5 | `SAC` | Kann, 0..n je `LEA` | nur innerhalb einer LEA; 0..n je LEA |
+| 6 | `GEN` | Kann, 0..n je `LEA` | nur innerhalb einer LEA; 0..n je LEA |
+| 7 | `OPA` | Kann, 0..n je `LEA` | nur innerhalb einer LEA; 0..n je LEA |
 | 8 | `REA` | Muss | einmal pro Nachricht |
 | 9 | `IVA` | Muss | einmal pro Nachricht |
 | 10 | `UNT` | Muss | Nachrichtenende |
@@ -400,7 +401,7 @@ Für spätere Implementierung und Arbeitspakete gilt:
 | `R-IFA-1.3.3-001` | IFA 1.3.3 | LANR Überweiser | K | bei Vorlage einer Überweisung | Format/Länge lokal; Bestandsabgleich nicht belastbar | V1-T | `3A033` – fachlich einschlägig, lokal in V1 ohne Referenzbestände nicht belastbar auslösbar |
 | `R-IFA-1.3.4-001` | IFA 1.3.4 | Beginn ASV-Behandlung | K | Muss belegt sein, wenn `1.3.1` gefüllt ist | formales Datum; Bedingung mit 1.3.1 | V1-V | `3A005` – Beginn ASV-Behandlung fehlt trotz externer Überweisung; `20021` / `3A011` |
 | `R-IFA-OVER-001` | Hinweis 9 | Teamebene Vertretung | Regel | Bei Vertretung (Teamebene 4 im ASV-Verzeichnis) ist die Teamebene des Vertretenen anzugeben. | ohne Referenzbestand nur eingeschränkt prüfbar | V1-N | `4A007` – Teamnummer/LANR/Teamebene entspricht nicht ASV-Verzeichnis |
-| `R-IFA-OVER-002` | IFA Hinweise | Überweiserfelder | Regel | `1.3.1` und `1.3.2` dürfen nicht gleichzeitig belegt sein. | lokale Crosscheck-Regel | V1-V | `3A035` – externer und interner Überweiser gleichzeitig |
+| `R-IFA-OVER-002` | Konvention: IFA-Strukturlogik (keine explizite Spec-Fundstelle verifizierbar) | Überweiserfelder | Regel | `1.3.1` und `1.3.2` dürfen nicht gleichzeitig belegt sein. | lokale Crosscheck-Regel | V1-K | `3A035` – externer und interner Überweiser gleichzeitig |
 
 ## 11.2 Segment DGN – Diagnosedaten
 
@@ -524,7 +525,7 @@ Für spätere Implementierung und Arbeitspakete gilt:
 | `R-FHL-2.10.2-001` | FHL 2.10.2 | Uhrzeit der Erstellung | M | Uhrzeit aus Originalnachricht `HHMM` | Format | V1-V | `10038` analog; kein FHL-spezifischer Code |
 | `R-FHL-2.11-001` | FHL 2.11 | Nachrichtenreferenznummer | K | aus `UNH 0062` der Originalnachricht; wenn ermittelbar zu liefern | Bedingungsprüfung | V1-T | kein eindeutiger offizieller Fehlercode |
 | `R-FHL-2.12-001` | FHL 2.12 | Übertragungsreferenz | K | aus `UNB 0020` der Originalnachricht; wenn ermittelbar zu liefern | Bedingungsprüfung | V1-T | kein eindeutiger offizieller Fehlercode |
-| `R-FHL-2.13-001` | FHL 2.13 | Anforderungskennzeichen Korrektur/Storno | M | `1` = Korrektur, `2` = Storno (nur bei Fehlern der Stufe 4 relevant). | lokaler Schlüsselwert | V1-V | kein eindeutiger offizieller Fehlercode |
+| `R-FHL-2.13-001` | FHL 2.13 | Anforderungskennzeichen Korrektur/Storno | K | Kann-Feld; `1` = Korrektur, `2` = Storno (insbesondere bei Fehlern der Stufe 4 relevant). Wird zu Muss-Datenelement, wenn der Kontext eine Ermittelbarkeit belastbar erlaubt. | lokaler Schlüsselwert | V1-V | kein eindeutiger offizieller Fehlercode |
 | `R-FHL-2.14-001` | FHL 2.14 | Rechnungsnummer | K | anzugeben, sofern aus Originalnachricht lesbar | Bedingungsprüfung | V1-T | kein eindeutiger offizieller Fehlercode |
 
 ## 13. Segment-, nachrichten- und dateiübergreifende Beziehungsregeln
@@ -540,6 +541,7 @@ Für spätere Implementierung und Arbeitspakete gilt:
 | `R-CROSS-DATEINAME-005` | Abschnitt 3.5.4 | Echte lückenlose Folgeprüfung über mehrere Übermittlungen ist ohne Verlauf nicht belastbar. | V1-N | `10047` |
 | `R-CROSS-ECHT-TEST-001` | KKS, UNB 0035, Abschnitt Testverfahren | Test-/Echtkennzeichnung muss zwischen Dateiname, KKS und UNB-Testindikator konsistent sein. | V1-V | kein eindeutiger offizieller Fehlercode |
 | `R-CROSS-KASSE-001` | Grundsätze Durchführung der Datenübermittlung | Pro Kasse ist genau eine Datei zu erstellen; kassenübergreifende Bündelung in einer Datei ist unzulässig. Die lokale Prüfung erfolgt anhand der im Artefakt vorhandenen Kassenbezüge (insbesondere Abrechnungs-IK). | V1-V | kein eindeutiger offizieller Fehlercode |
+| `R-CROSS-KKS-SPEZ-NACHRICHTENTYP-001` | KKS `VERFAHREN_KENNUNG_SPEZIFIKATION`, UNH S009_0065 | Wenn KKS-`VERFAHREN_KENNUNG_SPEZIFIKATION` belegt ist (`ASVA0` oder `ASVF0`), muss der tatsächliche Nachrichtentyp in `UNH S009_0065` (`ASVREC` bzw. `ASVFEH`) konsistent dazu sein. `ASVA0` ↔ `ASVREC`; `ASVF0` ↔ `ASVFEH`. | V1-V | kein eindeutiger offizieller Fehlercode |
 
 ## 13.2 Nachrichtenebene
 

docs/specs/meilensteine.md

@@ -160,7 +160,7 @@ Die Anwendung kann die EDIFACT-Hüllstruktur zuverlässig parsen und die lokalen
   - **physischer Dateiname ↔ `UNB_0020`** (`UNB_0020` ist die Übertragungsreferenz bzw. der Dateiname der Übertragung, nicht die Senderkennung)
   - `UNB_0020` ↔ `UNZ_0020` (Referenzgleichheit von Übertragungskopf und -ende)
   - `UNH_0062` ↔ `UNT_0062` je Nachricht (Referenzgleichheit von Nachrichtenkopf und -ende)
-  - `UNZ_0010` (Nachrichtenzähler) ↔ tatsächliche Anzahl der `UNH`/`UNT`-Paare
+  - `UNZ_0036` (Nachrichtenzähler) ↔ tatsächliche Anzahl der `UNH`/`UNT`-Paare
   - Testindikator `UNB 0035`: Echtdaten-/Testdaten-Konsistenz mit der `E`/`T`-Kennung im physischen Dateinamen; Wert `1` nur für Testübertragungen
 - Konsistenzprüfungen, die den KKS-Auftragssatz voraussetzen (insbesondere die Abstimmung zwischen `UNB 0035`/Dateiname und KKS-`VERFAHREN_KENNUNG`), sind **nicht** Bestandteil von M3 und werden in M4 zusammen mit den KKS-Crosschecks umgesetzt
 - unbekannte oder fremde Segmente nicht vorschnell verwerfen, sondern diagnostisch sichtbar halten
@@ -203,7 +203,7 @@ Der KKS-Auftragssatz wird als eigenständiger, vollwertiger Prüfgegenstand umge
   - `DATUM_ERSTELLUNG`: 14-stellig `JJJJMMTThhmmss`, formal prüfen
   - `DATEIVERSION = 000000`
   - `KORREKTUR = 0`
-  - `FEHLER_NUMMER = 000000`, `FEHLER_MASSNAHME = 000000`
+  - `FEHLER_NUMMER = 000000`, `FEHLER_MAßNAHME = 000000`
   - `ZEICHENSATZ = I5` (formaler Anker für die ISO-8859-15-Annahme der gesamten Anwendung)
   - `KOMPRIMIERUNG = 00`
   - `VERSCHLÜSSELUNGSART = 03`

docs/specs/technik-und-architektur.md

@@ -286,7 +286,7 @@ 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
+- Anzahl Nachrichten in `UNZ_0036` ↔ 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`
@@ -436,9 +436,10 @@ Mindestens folgende Regeln sind verbindlich zu modellieren:
 - **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.
+- `VERFAHREN_KENNUNG_SPEZIFIKATION` ↔ Nachrichtentyp in `UNH S009_0065`: Wenn das Feld belegt ist, muss es zum tatsächlichen Nachrichtentyp passen (`ASVA0` → `ASVREC`; `ASVF0` → `ASVFEH`).
 - `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`
+- `FEHLER_MAßNAHME = 000000`
 - `DATEIVERSION = 000000`
 - `KORREKTUR = 0`
 - `DATEINAME` entspricht dem unverschlüsselten Dateinamen gemäß Dateinamensregeln
@@ -512,6 +513,9 @@ Die folgenden Regeln sind verbindlich zu berücksichtigen. **Die hier genannten
 - **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.
+- **Spec-Tippfehler DATUM_ERSTELLUNG**: Die Technische Anlage ASV 1.09 beschreibt das Format als `JJJJMMTTssmmss`. Das ist ein Tippfehler in der Spec (`ss` = Sekunde statt `hh` = Stunde). Korrekt ist `JJJJMMTThhmmss` (Jahr, Monat, Tag, Stunde, Minute, Sekunde). V1 implementiert das korrigierte Format.
+
+- **Spec-Tippfehler `DATUM_ERSTELLUNG`**: Die Technische Anlage ASV 1.09 beschreibt das Format als `JJJJMMTTssmmss`. Das ist ein Tippfehler in der Spec (ss = Sekunde statt hh = Stunde). Korrekt ist `JJJJMMTThhmmss` (Jahr, Monat, Tag, Stunde, Minute, Sekunde). V1 implementiert das korrigierte Format.
 
 ### Versichertennummer
 
@@ -691,6 +695,8 @@ Soweit die jeweilige Datei diese Informationen oder Anforderungen betrifft, sind
 | Hash-/Signaturverfahren | SHA256withRSAandMGF1 / PSS |
 | RSA-Exponent | Fermat-4 (`2^16 + 1`) |
 
+> **Hinweis:** Die Spec nennt 2048 bit als ursprünglichen Standard; die Umstellung auf 4096 bit erfolgte zum 01.05.2020. Da V1 ab Q2/2026 gilt, ist 4096 bit der verbindliche Wert.
+
 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
@@ -850,7 +856,7 @@ Nicht Ziel von Version 1 sind insbesondere:
 |---|---|
 | 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 |
+| v3 | `VERFAHREN_KENNUNG_SPEZIFIKATION` als Kann-Feld, `DATEIGRÖSSE_*` als Crosschecks, `ZEICHENSATZ = I5`, ASVFEH-Originalnachricht-Ausnahme, Hybrid-Modell geschärft, `UNZ_0036`/`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 |