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>
doc/VarioFoerderer_Linienzug_Prinzipien.md ist bewusst nicht versioniert
(siehe ce00233). Die drei Stellen, die von dort die Begruendung geholt
haben, tragen sie jetzt selbst: warum quer und dZ null sein MUESSEN und
laengs abweichen DARF - naemlich weil beides zugleich geometrisch nicht
geht und der Hauptstrang gerade bleiben soll.
Ein Verweis auf eine Datei, die im Repo fehlt, kostet den naechsten Leser
mehr Zeit als die zwei Zeilen Text.
Nicht angefasst: die aelteren Verweise in vf_linienzug.lsp (Abschnitt 14,
14.1) und vf_standard.lsp - sie stammen nicht aus dieser Arbeit und
zeigen auf Inhalte, die hier niemand kennt.
Co-Authored-By: Claude Opus 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>
y.wang