[CHANGE] doc/plan und doc/todo angelegt, interne Analyse-/TODO-Dokumente dorthin verschoben

doc/todo/: TODO-plan-vf-interactive.md -> plan-vf-interactive.md, TODO-modus2-achsenweise-bilanz.md -> modus2-achsenweise-bilanz.md (offene Fahrplaene/TODOs).
doc/plan/: KS-Frame-Architektur.md, vf-parameter-struct-analyse.md, translate.md, Entwicklungsplan.md (Architektur-Analysen und Planungsdokumente, kein Anwender-Material).

Alle internen Verweise (CLAUDE.md, Lisp/README.md, README.md, doc/variofoerderer.md, Lisp/vf_spec.lsp, lib/dxf_vf_abbild.py, lib/vf_spec_export.py, tests/test_hm_recformat.lsp, tests/test_vf_geometrie.py, tests/test_vf_headless_statisch.py) auf die neuen Pfade angepasst. Reine Pfad-Updates in Kommentaren/Docstrings, keine funktionale Aenderung - Python-Syntax nach dem Umbau geprueft.

Anwender-/Entwickler-Referenzdoku (faq.md, kommandos.md, tools.md, dbg2lsp.md, csv-export.md, json-input-lisp.md, lisp_methods.md, LispTests.md, variofoerderer.md, vf_linienzug_modus1_anleitung.md) bleibt direkt in doc/.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

doc/plan/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.