Ausgabeverzeichnis nur über Lisp Variable festlegen. Anscheinend speichert Bricscad Umgebungen über die Sessions hinweg. Die Ausgaben der Tests landen woanders als der generelle Export

Lisp/README.md

@@ -248,6 +248,21 @@ Der Omniflo-CSV-Export (Bogen/Weiche/Gerade, inkl. Merkmale-Aufbau und Sum-Zeile
 seit Entfernung von `c:OMNI_EXPORT` ausschließlich über `c:EXPORTCSV` → `lib/export_csv.py`
 (`build_bogen_merkmale`, `build_weiche_merkmale`, `build_gerade_merkmale`, `build_omni_sum_merkmale`).
 
+**Ausgabeordner:** `c:EXPORTSIVAS`/`c:EXPORTCSV` schreiben immer nach `DXFM_RESULTS`.
+`TEST_EXPORT_ALL` (siehe `tests/test_export_all.lsp`) leitet waehrend des Testlaufs stattdessen
+nach `DXFM_TESTOUT` um, über die reine Lisp-Sitzungsvariable `*export-test-override*` (wird von
+`csv:run-export` zusaetzlich zu `DXFM_RESULTS` abgefragt und danach garantiert wieder auf `nil`
+zurueckgesetzt, auch bei einem Fehler, ueber `vl-catch-all-apply`).
+
+**Wichtig:** Der Umweg über `*export-test-override*` ist bewusst gewaehlt und **kein**
+`(setenv "DXFM_RESULTS" ...)`. In BricsCAD/AutoCAD schreibt `(setenv ...)` nicht nur in den
+Windows-Prozess, sondern dauerhaft in die Profil-Registry der Anwendung – der Wert überlebt
+damit jeden Neustart und jedes `setenv.bat`, bis er erneut per `(setenv)` überschrieben wird.
+Ein einziger `(setenv "DXFM_RESULTS" ...)`-Aufruf (z. B. ein frueherer, unvollstaendiger
+Testlauf) würde `DXFM_RESULTS` für alle künftigen Sitzungen unwiderruflich auf den Testordner
+umbiegen. Falls das bereits passiert ist, hilft nur ein manuelles
+`(setenv "DXFM_RESULTS" "<richtiger Pfad>")` in BricsCAD, um den Profil-Wert zu korrigieren.
+
 ---
 
 ### `tests.lsp` – Testbefehle