Drei neue Modus-2-Testfaelle aus echten Laeufen, ein Kriterium, das eine
heute eingebaute Fehlgeometrie gefunden haette, und ein aufgeraeumtes
Layout der Testketten.
1. Drei U-Form-Faelle (tests/testdata/linienzug_modus2_uform_*.json),
aufgezeichnet mit lib/vf_journal_export.py. Gefaltete Laeufe: der Pfad
wechselt ueber zwei 90-Grad-Vario-Kurven dreimal die Fahrtrichtung, die
Kletterstrecke liegt in einem ANDEREN Schenkel als der Lauf-Eingang -
genau der am 2026-10-29 korrigierte Fall. Variiert werden GF-Verteilung
(alles am Einlauf vs. 1/2+1/2) und Winkel; beides ist noetig, weil die
Verteilung entscheidet, ob ueberhaupt GF im fremden Schenkel steht, und
der Restfehler der alten Bilanz mit L_GF skalierte.
c:TEST_LINIENZUG_MODUS2 ist dafuer tabellengesteuert - ein weiterer Fall
ist jetzt eine Zeile in *tlz-m2-faelle*.
2. RUECKNAHME des Schluss-Solves (vfl-zsolve-schluss-ziel, heute frueh
eingebaut). Er loeste den letzten Fueller gegen Richtung UND Laenge und
traf den Zielpunkt dadurch in X und Y exakt - um den Preis, dass er die
letzte Gerade um 6.15 Grad verdrehte (hz-plan -90 -> -96.15), in der
Zeichnung als schiefer Schenkel sichtbar. Das widerspricht der
Entscheidung vom 2026-10-26: quer MUSS 0 sein, LAENGS DARF ABWEICHEN -
der Hauptstrang bleibt gerade, der seitliche Versatz des ES-Elements ist
dessen Bauform. Die Messwerte von heute (0.56 / 0.7 mm quer) stammen
nicht von dieser Aenderung, sondern von der Laengenbilanz des gefalteten
Laufs (35ebee1) - der Zweig blieb dort ungenutzt. Die Begruendung steht
jetzt an der Aufrufstelle, damit niemand den Solve erneut baut.
3. laengs wird geprueft - als FORM-, nicht als Genauigkeitskriterium
(erwartung_laengs_mm, Toleranz 5 mm). Der Wert ist die Ausladung des
ES-Elements und je Fall eine Konstante (104.68 bei ES_Element_30,
637.58 bei ES_Element_90). Punkt 2 war am Querwert NICHT erkennbar - die
Verdrehung macht ihn gerade null, der Test meldete OK, gefunden wurde sie
mit dem Auge. Ein verdrehter Hauptstrang zielt auf den Endpunkt und
drueckt laengs auf ~0; daran faellt er auf. Gegengeprueft: mit kuenstlich
auf 0.01 mm gesetzter Toleranz kippen alle fuenf Faelle auf ABWEICHUNG.
4. Alle sieben Ketten des Menueeintrags entstehen als Reihe auf Y=0, 20 m
Abstand, statt verstreut. Die Modus-1-Skripte brauchen dafuer nur ihren
EINEN point_abs (alles Weitere ist point_rel mit dL/hz); bei Modus 2
mussten PT-Eintraege UND die Pfadkoordinaten in SEGS (Felder 6..9)
mitwandern, sonst zeigt der Pfad woanders hin als Start und Ziel.
Reine Translation - Laengen, Winkel und die geprueften Abweichungen sind
davon unabhaengig; Z blieb stehen, weil die Starthoehe ein Eingabewert
des Solvers ist. Geprueft: erstes Segment beginnt exakt am Startpunkt,
letztes endet exakt am Zielpunkt, Messwerte unveraendert.
5. Die drei letzten Verweise auf doc/VarioFoerderer_Linienzug_Prinzipien.md
(bewusst unversioniert) tragen ihre Begruendung jetzt selbst: Entkopplung
Neigung/XY, warum es genau EINEN Kletterer je Lauf gibt, und warum ein
VF-Sub-Segment auf der 3-Grad-Basis beginnen und enden muss.
Geprueft: TEST_UNIT 897/897 (die 7 Tests der entfernten Funktion sind mit
ihr gegangen), TEST_LINIENZUG_MODUS2 5 von 5 OK, voller Menueablauf baut
sieben Ketten an den vorgesehenen Stellen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TEST_LINIENZUG (ebenso hmrec:stubs-aus und vsp-headless-aus) schaltete die
GUI am Ende pauschal wieder ein. Unter SSG_RUN_ALL_TESTS fragte der direkt
folgende EXPORTSIVAS dann nach Hoehen-Check/Bereinigen und der Lauf blieb
stehen. Alle drei stellen jetzt den Vorzustand von *ssg-gui-aus* wieder her.
SSG_RUN_ALL_TESTS schaltet zusaetzlich *csv-hoehencheck-fragen* und
*csv-bereinigen-vor-export* fuer den Lauf ab (unmittelbar vor jedem Export
erneut, export.lsp belegt nil beim Nachladen wieder mit T), erzwingt GUI aus
mit Warnung und stellt am Ende die Vorgaben wieder her.
Neues Laufprotokoll DXFM_LOG/testlauf_<name>.dbg je Test (Debug-Schalter
"testlauf", Standard ein): Zustand vor/nach dem Test, Fehler, Ergebnis-JSON,
Export-Schritte. Eigene Datei mit sofortigem Schreiben statt dbgopen, damit
die Module mit ihren eigenen .dbg-Dateien es nicht umlenken und bei einem
Haenger der letzte Schritt sichtbar ist.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neu: TEST_LINIENZUG_MODUS2 spielt zwei echte Laeufe DERSELBEN Strecke ab -
einmal mit der 90-Grad-Ecke als Vario-Kurve (waagerecht, mit flacher Zone),
einmal als GF-Bogen (geneigt, ohne flache Zone). Beide muessen quer zur
ES-KS_AUS-Achse ~0 und dZ ~0 erreichen; laengs darf um die Ausladung des
ES-Elements abweichen (Leitsatz, doc/VarioFoerderer_Linienzug_Prinzipien.md
Abschnitt 0). Gemessen am 2026-10-27: beide 0.2 mm quer, dZ 0.
Das Paar ist Absicht. Die beiden Varianten laufen durch VERSCHIEDENE Zweige,
und erst ihr Vergleich hat die Fehler dieser Woche sichtbar gemacht - der
ES-Fussabdruck wurde vom falschen Segment abgezogen, was sich nur in der
GF-Bogen-Variante zeigte (878 mm). Einen der beiden zu loeschen nimmt dem
Test seinen Wert.
Anders als die Modus-1-Faelle braucht Modus 2 KEINE Mocks und KEINEN
gezeichneten Pfad: sein Journal traegt einen SEGS-Eintrag mit der kompletten
Segment-Essenz, ist also von den Original-Objekten unabhaengig. Der Test
spielt daher das echte, mit lib/vf_journal_export.py aus der Zeichnung
gelesene Journal ab. Jeder Eintrag fuehrt seine Art mit (PT/STR/REAL/SEGS),
womit die Verschiebe-Anfaelligkeit des Mock-Replays entfaellt.
Dazu: vf-linienzug-modus2 legt die gemessene Abweichung in
*vfl-m2-abweichung* ab (laengs quer dz). Sonst muesste ein Test sie aus der
Konsolenausgabe zurueckparsen.
Ausserdem behoben: beide Modus-1-Testskripte brachen mit
"bad argument type <\"5\"> expected <CONS> at [cdr]" ab. Commit fb56794
(Rueckwaerts-Bau) hat eine Frage VOR die AS-Praeambel gesetzt. Fuer Journale
ist sie abwaertskompatibel, fuer die MOCK-Skripte nicht: der Mock beantwortet
jede getstring-Abfrage aus der Queue, eine fehlende Antwort verschiebt also
alles Folgende um eine Position. Beide Dateien haben den Eintrag jetzt, mit
Begruendung im Kommentar.
Menue: Tests -> Foerderer-Linienzug ruft den neuen Fall mit auf. Die
kompilierte SSG_LIB.cui ist bewusst NICHT mit committet - ihre Aenderung
besteht groesstenteils aus fremden Eintraegen und verschobenen UIDs;
BricsCAD erzeugt sie beim naechsten _MENULOAD neu aus der .mnu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- TEST_LINIENZUG: seit 1cc163d/cccd362 fragt Modus 1 nach der AS-Seite die
optionale Zufuehrungsachse ab. Der Test mockt get* direkt (keine
Replay-Queue), die neue Punktfrage verschluckte die naechste Antwort und
der Lauf desynchronisierte (FEHLER, 21 Schritte offen). Neuer Schritt-Typ
"point_none" (getpoint -> nil) und in beiden Linienzug-Testdaten nach
der AS-Seite eingetragen.
- test_hundm05.py: Zusatzobjekt-Ergebnisse filterten nur kind "kreisel" -
Separatoren/Scanner/BTMT (kind "sensor") fehlten, test_je_objekt_ein_
ergebnis schlug faelschlich fehl.
- SSG_RUN_ALL_TESTS: #VF/#GF/#Kreisel/#Eckrad_LetzteNr vor jedem Test auf 0.
Der Lauf bleibt im Namensraum des Startdokuments, die Zaehler liefen
sonst ueber alle Tests weiter (VF_5/Kreisel12 in frischer Zeichnung) und
machten jeden Referenz-Diff von der Testreihenfolge abhaengig.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Auf der neuen Kollegen-Architektur (Stufe 0-2: Spec/Journal/Replay-System
in vf_spec.lsp, Frage-Schale/Bauteil-Trennung) neu aufgebaut, nachdem der
urspruengliche Stand (Commit e76e24e) auf einer aelteren Basis beruhte und
per Rebase-Analyse als eigenstaendige, unabhaengige Erweiterung erkannt
wurde (der Kollege hat nichts entfernt - diese Features existierten vorher
nur lokal uncommitted).
Drei Erweiterungen fuer "Neue Linie: GF" in vf-linienzug-modus:
- Separator VOR/NACH direkt vor bzw. nach der Gefaellestrecke einfuegbar.
- Aeussere Vorwahl "Wie soll die Laenge bestimmt werden?": Endpunkt waehlen
(bisheriges Verhalten) oder Zielhoehe zuerst festlegen (Winkel wird
daraus berechnet).
- Dritte Option "Steigende GF" (Sonderfall, 0 bis 3 Grad): erlaubt eine GF,
die statt zu fallen steigt. Neuer Helfer vfl-bogen-uebergang erkennt
anhand der tatsaechlichen Frame-Neigung, ob 0/1/2 Uebergangsboegen
(Vario_Bogen_auf_3/ab_3) noetig sind, und baut sie automatisch - im
Normalfall (fallend->fallend) ein No-Op.
Lisp/vf_spec.lsp (Kollegen-Spec/Headless-Bau-System) um die drei neuen
Felder (laenge_modus/sep_vor/sep_nach/steigend_modus) erweitert, mit
Defaults, die alte Specs unveraendert lassen - haelt die "Spec-Pfad ==
interaktiver Pfad"-Invariante seines Systems (TEST_HUNDM05/VF_SPEC_BAU)
intakt. tests/test_vf_spec.lsp entsprechend mit neuen Testfaellen ergaenzt.
Neuer Regressionstest TEST_LINIENZUG_STUFE2 (linienzug_tests_stufe2.json)
sowie Anleitung doc/vf_linienzug_modus1_anleitung.md aus dem urspruenglichen
Commit uebernommen; die Gefaelle-Hoehe/Winkel-Optionsreihenfolge im
Testdatensatz an die jetzt geltende (Kollegen-)Konvention angepasst.
Offen (bewusst zurueckgestellt): lib/vf_spec_export.py (Python-Vorwaerts-
Emitter, Pendant zu vf_spec.lsp) noch nicht nachgezogen - siehe Folge-Commit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Der VF-Linienzug-Wizard (*vfl-wizard-mode* Default T) oeffnete beim
automatischen Replay-Test DCL-Dialoge und blockierte den Lauf.
- ssg_core.lsp: globaler Schalter *ssg-gui-aus* + ssg-gui-p/-aus/-an
- vf_linienzug.lsp: neue vfl-wizard-mode-p (Wizard nur wenn *vfl-wizard-mode*
UND GUI nicht abgeschaltet); ersetzt die direkten *vfl-wizard-mode*-Checks in
vfl-in-string/-real/-int, vfl-winkel-live und vfl-wizard-aktiv (deckt damit
auch alle vflw-gruppe-*-Dialoge ab). Bei GUI-aus fallen die Eingaben auf den
getstring/getint/getreal-Pfad, den die Testrunner per Mock/Replay bedienen.
- test_linienzug.lsp: (ssg-gui-aus) vor dem Replay, (ssg-gui-an) danach (immer).
- test_run_all.lsp: GUI aus um den gesamten Batch, danach wieder an.
Alle Guards ueber atoms-family, damit aeltere Ladezustaende unveraendert
funktionieren. Paren-Balance geprueft.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
y.wang
m.stangl