6d15c6be13
lib/vf_journal_export.py (Journal.dekodiere) und lib/vf_spec_export.py (SpecLeser) implementierten denselben Tokenwalk (Praeambel, Sektions- schleife, Glied-Dispatch, VF-Einheit-Unterschleife) sowie dieselben Code-Tabellen (SEITE/VARIANTE/VERTEILUNG/IM_VF/ENDPUNKT/ENDE2/ENDE3/ GEFAELLE/GF_LAENGE_MODUS, MENU_START/MENU_START_AKTUELL/MENU_WEITER, Grammatik) unabhaengig voneinander - Aenderungen an der Grammatik (wie im vorigen Commit) mussten von Hand synchron gehalten werden und sind bereits einmal auseinandergelaufen. Neuer gemeinsamer Parser-Kern (Kern/lies_journal) plus Sink-Schnittstelle (SpecSink in vf_spec_export.py, ProtokollSink in vf_journal_export.py) ersetzt die doppelte Implementierung; Code-Tabellen/Grammatik-Objekte leben jetzt nur noch in lib/vf_linienzug_grammatik.py. Journal behaelt nur noch die reine XDATA/DXF-Zerlegung, SpecSchreiber (Spec -> Journal, Gegenstueck zu Lisp/vf_spec.lsp) bleibt unveraendert in vf_spec_export.py. Zusaetzlich: pruefe_flachen_freitext schlaegt jetzt hart fehl, wenn generierter Freitext (quelle/beschreibung) ein rohes Anfuehrungszeichen enthaelt - der Lisp-seitige Flach-JSON-Leser (ssg-cfg-parse-value) kennt keine Escapes und wuerde daran die Zeichenkette (und damit die gesamte restliche Datei) falsch zerlegen. Byte-identischer Output gegen die Baseline geprueft (beide CLIs, echte Eingaben); pytest tests/test_vf_spec.py + test_vf_journal_grammatik.py unveraendert: 2 bekannte, vorbestehende Fehlschlaege, 38 bestanden. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>