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>
