[FEAT] VF-Linienzug ohne GUI/Konsole baubar (Stufe 0) + hundm05-Testfall

Ziel: eine VF_n-Kette soll aus einem Stapel Eingabedaten gebaut werden
koennen - ohne Dialog, ohne Konsolenfrage. Fahrplan und Begruendungen in
doc/TODO-plan-vf-interactive.md. Alle Aenderungen sind No-Ops, solange
*ssg-gui-aus* und *vfl-headless* nil sind.

Produktion (Lisp/vf_linienzug.lsp, Lisp/vf_core.lsp):
- vfl-journal-reset im Dispatcher VOR die Modus-cond gezogen. Bisher nur im
  Modus-1-Zweig: ein frischer Modus-2-Lauf erbte das Journal des Vorlaufs und
  schrieb es in die XDATA, ein spaeterer Doppelklick spielte fremde Eingaben
  vor.
- Lokale Variable "member" in vf-linienzug-modus2 umbenannt. Sie verdeckte im
  selben Scope das Builtin member, das weiter unten gebraucht wird - jedes
  Kletterer-Segment waere in "bad function" gelaufen.
- Neu vfl-meldung: sammelt den Text nach *vfl-meldungen* + dbgmsg und zeigt
  ihn nur bei erlaubter GUI modal, sonst per princ. Die 12 Bau-Pfad-alerts
  darauf umgestellt; ein Alert blockierte sonst jeden Batch-Lauf, und sein
  Text ist die einzige Auskunft, WELCHE Sektion abgewiesen wurde. Die reinen
  Interaktiv-Alerts (fehlendes DCL, "nicht editierbar", "kein Journal")
  bleiben alert.
- Neu *vfl-headless* (+ vfl-headless-p/-abbruch/-notausgang/-ort, Diagnose
  *vfl-headless-fehler*, optionaler Antwort-Hook *vfl-headless-antwort-fn*):
  eine erschoepfte Replay-Queue ist damit ein harter Abbruch MIT Fundstelle
  (Art der Eingabe, Glied- und Eingabe-Nummer) statt eines stillen Rueckfalls
  auf Live-Eingabe. Eingebaut in vfl-in-value, vfl-in-value-p,
  vfl-in-selection und vfl-in-abstand.
- vfl-journal-reset loescht Meldungen und Diagnose mit (gehoeren zum Lauf);
  vfl-view-refresh ueberspringt headless _PLAN/_ZOOM.

Testfall HundM05 (5 echte Ketten aus data/polylines.dxf):
- tests/testdata/hundm05.json neu erzeugt aus den XDATA-Journalen der
  VF_n-Bloecke (lib/vf_journal_export.py) - flach, weil ssg-load-json
  zeilenweise liest. Die drei kopierten Ketten bekommen ihren echten
  Einfuegepunkt, nicht das veraltete HOEHE_VON-Attribut.
- tests/test_hundm05.lsp arbeitet jetzt per Journal-Replay statt mit
  Eingabe-Mocks: ein echtes Journal fuehrt die geerbte Fahrtrichtung nicht mit
  (vfl-in-abstand journalisiert hz nur beim ersten Segment), ein Mock kann sie
  also nicht kennen. Schaltet *vfl-headless* ein und schreibt prompts,
  headless_fehler und meldungen ins Ergebnis-JSON.
- Kettenschleife fangt je Kette: ein Fehler NACH dem Bau nimmt nicht mehr die
  restlichen Ketten mit.
- entprev gibt es in AutoLISP nicht (nur entnext/entlast) - die Suche nach dem
  fertigen Block laeuft vorwaerts ab dem Zeichnungsstand vor dem Bau. Dieselbe
  Falle in tests/test_mubea.lsp mitbehoben; sie schlug dort nie zu, weil
  entlast immer sofort traf.

Absicherung ohne CAD:
- tests/test_vf_headless_statisch.py: eingechecktes Inventar aller
  alert/get*/ssget/new_dialog-Fundstellen je Funktion (ein neues getreal in
  einer Bau-Funktion faellt auf, auch wenn sein Zweig im Test nie erreicht
  wird), Praesenz des Riegels in allen vier Wrappern, Diagnose-Reset und die
  Reset-Reihenfolge im Dispatcher. Dazu ein Waechter gegen erfundene
  AutoLISP-Funktionen (entprev u.a.) - diese Fehlerklasse kostet sonst jedes
  Mal einen CAD-Lauf.
- tests/test_hundm05.py prueft zusaetzlich prompts == 0, keine
  Headless-Abbrueche und keine Bau-Meldungen.

tests/alltests.json: hundm05-Zeile laedt VarioFoerderer (nicht KreiselInsert)
und bleibt bis zu einem gruenen CAD-Lauf abgeschaltet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

doc/vf-parameter-struct-analyse.md

@@ -0,0 +1,119 @@
+# VarioFoerderer-Cluster — Analyse Parameter-Buendelung (Struct-Potential)
+
+Bestandsaufnahme der globalen Variablen und Funktionssignaturen in
+`Lisp/vf_core.lsp`, `vf_konstanten.lsp`, `vf_standard.lsp`, `vf_etage.lsp`
+und `vf_linienzug.lsp` — als Grundlage fuer die Frage, ob sich haeufig
+gemeinsam durchgereichte Parameter zu einem Struct (in AutoLISP: eine
+benannte Alist) buendeln lassen, um Funktionssignaturen mit 5+ Parametern
+zu verkuerzen. Stand: 2026-09-01, rein analytisch, keine Codeaenderung.
+
+## Ausgangsbefund: globale Variablen
+
+Die globalen Variablen der drei Module sind **kein** Parameter-Problem:
+
+- `vf_konstanten.lsp` enthaelt ausschliesslich feste `*vfk-*`-Konstanten
+  (Winkel, Laengen, Toleranzen), die einmalig per `ssg-cfg-or`/Guard gesetzt
+  und direkt gelesen werden, nicht als Parameter durchgereicht.
+- `vf_core.lsp`/`vf_standard.lsp`/`vf_etage.lsp` haben Init-Flags/Caches
+  (`*lib-initialized*`, `*ks-cache*`, `bogen-auf`/`bogen-ab`), die Typ-Registry
+  `*vf-typ-registry*` und wenige AS/ES-Massen-Offsets (`aus-dx` usw.).
+- `vf_linienzug.lsp` haelt zusaetzlich Journal-/Replay-State
+  (`*vfl-journal*`, `*vfl-replay-queue*`), Wizard-Dialog-State
+  (`*vflw-pending*`, `*vflw-menu-*`) und neun parallele
+  `*vfl-acc-*`-Globals als "Ketten-Akkumulator" (siehe Abschnitt 4).
+
+Das eigentliche Problem liegt woanders: dieselben 4-8 thematisch
+zusammengehoerigen **Werte werden wortwoertlich durch dutzende
+Funktionssignaturen durchgereicht**, weil es dafuer noch keinen
+gebuendelten Wert gibt.
+
+## Bereits vorhandene Struct-Vorbilder im Code
+
+Diese Muster existieren schon und sind das natuerliche Vorbild fuer eine
+Erweiterung (AutoLISP-Konvention: Alist statt echtem Struct):
+
+- **KS-Frame** `(P xu yu zu)` — Punkt + 3 Achsvektoren als ein Wert
+  (`vf_core.lsp`, `frame` in `vf_linienzug.lsp`)
+- **`prefill`-Alists** (string-keyed, `(cdr (assoc "key" prefill))`) zur
+  Dialogvorbelegung in `vfs-dialog-eingabe-basis`/`vfs-dialog-winkel-verteilung`
+- **`*vf-basis-eingabe-felder*` + `vf-basis-eingabe-entpacken`** — eine
+  benannte, geordnete Feldliste, generisch per `foreach`/`nth` entpackt
+- **`ergebnis-liste`**-Eintraege `(winkel L_GF L_VF gueltig)` aus
+  `vf-winkel-solve`/`berechne-alle-winkel`
+- **`kette-rec`** in `vf_linienzug.lsp` — Positions-Accessor-Funktionen
+  (`vfl-kette-rec-ename` usw.) ueber eine flache Liste
+- **`*vfl-glied-schema*`** — Schema-Tabelle (Label -> Felddefinitionen) als
+  struct-aehnliche Serialisierung pro Ketten-Glied
+
+## Funktionen mit den meisten Parametern
+
+| Funktion | Datei | Anzahl Parameter |
+|---|---|---|
+| `vf-block-erstellen` | vf_core.lsp | 18 |
+| `vf-make-label` | vf_core.lsp | 13 |
+| `vf-dialog-berechnen-einfuegen` | vf_core.lsp | 12 |
+| `variofoerderer-einfuegen` | vf_standard.lsp | 10 |
+| `etage-foerderanlage-einfuegen` | vf_etage.lsp | 10 |
+| `vfs-standard-dialog-berechnen-einfuegen` | vf_standard.lsp | 10 |
+| `vfe-etage-dialog-berechnen-einfuegen` | vf_etage.lsp | 10 |
+| `vfl-block-erstellen` | vf_linienzug.lsp | 10 |
+| `vfl-modus-abbruch-sichern` | vf_linienzug.lsp | 9 |
+| `vf-winkel-solve` | vf_core.lsp | 8 |
+| `vfs-mitte-teil`, `vfl-vf-einheit`, `vfl-vf-einheit-abschluss` | standard/linienzug | je 7 |
+| `vfs-vf-koerper`, `vfl-insert-es-element`, `vfl3-es-fueller` | standard/linienzug | je 5-6 |
+| die vier `insert-hz-*`-Funktionen | vf_etage.lsp | je 4-6 |
+
+## Struct-Kandidaten
+
+1. **`geometrie-basis`** `(deltaL deltaH richtung startpunkt hz seite
+   [dim geruest-einzelmodul geruest-typ motorseite])` — identisch in
+   vf_core, vf_standard, vf_etage UND vf_linienzug. Erweitert direkt das
+   bestehende `*vf-basis-eingabe-felder*`-Muster. Groesster Hebel, da er in
+   fast jeder Top-Funktion mit vorkommt.
+2. **`ergebnis-geometrie`** `(best-winkel L_GF1 L_GF2 L_VF richtung)` —
+   entspricht der Form der `ergebnis-liste`-Eintraege aus `vf-winkel-solve`;
+   steckt in `vf-make-label`, `vf-block-erstellen`, `vfs-mitte-teil`,
+   `vfs-vf-koerper`, `variofoerderer-einfuegen`, `etage-foerderanlage-einfuegen`.
+3. **`hoehen`** `(hoehe-von hoehe-bis deltaH)` — klein, wiederholt sich in
+   `vf-make-label`/`vf-block-erstellen`; evtl. eher in Kandidat 2
+   integrieren als eigenstaendig fuehren.
+4. **`geruest-optionen`** `(geruest-einzelmodul geruest-typ motorseite)` —
+   reist durch Dialog-/Edit-/Erstellen-Funktionen; Alternative: direkt in
+   `geometrie-basis` aufnehmen statt separat zu fuehren.
+5. **`ketten-meta`** `(vfl-nummer anzahl-gf anzahl-vf hoehe-von hoehe-bis
+   delta-l-total as-seite es-seite)` — nur vf_linienzug, betrifft
+   `vfl-block-erstellen` (10) und `vfl-modus-abbruch-sichern` (9).
+6. **Rotation-Paar** `(hz-winkel vert-winkel)` (optional mit vorgerechneten
+   sin/cos) — die vier `insert-hz-*`-Funktionen in vf_etage.lsp teilen
+   dieses Paar plus dupliziertes Grad->Bogenmass/sin/cos; ein
+   gemeinsamer Wert wuerde auch die Code-Duplikation beseitigen, nicht nur
+   die Parameterzahl.
+7. **`*vfl-acc-*`-Akkumulator** — kein Parameter-, sondern ein
+   State-Problem: neun parallele globale Listen
+   (`*vfl-acc-lvf*`, `*vfl-acc-lgf*`, `*vfl-acc-gfwinkel*`,
+   `*vfl-acc-richtung*`, `*vfl-acc-winkel*`, `*vfl-acc-motorseite*`,
+   `*vfl-acc-gfbogen*`, `*vfl-acc-variokurve*`, `*vfl-acc-separator*`), die
+   konsequent zusammen gesetzt/gelesen werden. Ein Record statt neun losen
+   Globals waere robuster gegen Vertipper/vergessenes Zuruecksetzen.
+
+Mit Kandidat 1+2 allein liesse sich `vf-block-erstellen` von 18 auf
+~6-7 Parameter bringen, `vf-make-label` von 13 auf ~5-6, und die gesamte
+10-Parameter-Familie auf ~4-5.
+
+## Einschaetzung
+
+Es besteht spuerbares Potential, aber mit Vorsicht: `vf-dialog-berechnen-einfuegen`
+haengt an der Typ-Registry (`*vf-typ-registry*`, `berechne-fn`/`einfuege-fn`)
+und wird von Standard-, Etage- und indirekt Linienzug-Pfaden aufgerufen. Eine
+Signaturaenderung dort zieht Aenderungen an allen drei registrierten
+Funktionen sowie den Edit-/Rebuild-Pfaden (`vfe-edit-ent`, `vfl-edit-ent`,
+Journal-Replay) nach sich. Empfohlene Reihenfolge bei einer Umsetzung:
+
+1. Risikoarme Blattfunktionen zuerst (Rotation-Paar in vf_etage,
+   `vf-make-label`).
+2. `geometrie-basis`/`ergebnis-geometrie` als groessere, aber isolierbare
+   Cluster.
+3. Die Registry-Signatur (`vf-dialog-berechnen-einfuegen`) und die
+   Edit-/Replay-Pfade erst zuletzt anfassen.
+
+Stand jetzt: reine Analyse, keine Umsetzung angestossen.