# TODO: Modus-2-Solver auf achsenweise Laengen-Bilanz umstellen

Status: **Vorschlag / noch nicht umgesetzt** (2026-09-18). Mit dem Entwickler zu
besprechen, bevor der Solver angefasst wird. Reiner Plan - kein Code geaendert.

## Kurzfassung

Der Modus-2-Solver (`vf-linienzug-modus2`, Phase B, `Lisp/vf_linienzug.lsp`
ca. Zeile 9915-10145) modelliert den VarioFoerderer-Lauf als EINE gerade
Bruecke. Bei einer gefalteten Kette (U-Form: hoch, quer, runter) zieht er die
festen Fussabdruecke aus der falschen Achse ab: **die erste GF wird zu lang,
die Kletterstrecke zu kurz, Motor/ES landen falsch bzw. fehlen.** Der Fix:
Laengen pro Schenkelrichtung bilanzieren statt als eine skalare Spanne.

Das ist ein **dokumentiertes v1-Naeherungs-Limit**, kein Regressionsfehler -
die Umbauten SEGS/Alert-Box/Mini-Filter haben Phase B nicht angefasst.

## Symptom (echter Testfall: results/test_modus2.dxf, logs/vfl_modus2.dbg)

U-Form-Kette, 6 Segmente, EIN VF-Lauf (Seg 2-6; die zwei Vario-Kurven zaehlen
als VF-Mitglieder):

```
   ^  Seg2 VF (1500 mm)
   |  Seg1 GF (2500 mm)
 start                    Seg4 VF (2257 mm)
   |                +-----------------------+
   |           Seg3 Kurve              Seg5 Kurve
   |                                        |
   |                                   Seg6 VF (3800 mm)
   +                                        v
                                        Ziel (3520, 180)
```

Ergebnis: `SOLL-ENDE=(3520, 180, 2000)`, `IST-ENDE=(3333, 2825, 2080)` ->
`dY=+2645 mm`, `dZ=+80 mm`. Die erste GF wird zu lang erzeugt; die
Kletterstrecke (Seg 6) endet ~2645 mm zu frueh; Motorstation, das
VF-Kurven-Zwischenstueck und das ES-Element sitzen falsch bzw. fehlen.

## Ursache, praezise lokalisiert

Der Solver waehlt die laengste VF-Gerade (Seg 6, 3800) als Kletterer, der die
ganze Hoehe traegt, und rechnet die geneigte Laenge skalar:

```lisp
;; vf_linienzug.lsp:9990 - Solver bekommt die SKALARE Spanne
(setq wahl3 (vfl3-waehle-winkel climber-span dH-adj feste-vf))
;; feste-vf = Umlenk + Separator (+ Motor) -- ein fester Fussabdruck

;; vf_linienzug.lsp:10070 - Kletterer bekommt br-lvf proportional
(setq this-lvf (max clamp (* br-lvf (/ (caddr seg) climber-span))))
;;   br-lvf = climber-span MINUS feste-vf
;;   ABER: Umlenk/GF1/Motor sitzen physisch in ANDEREN Schenkeln
;;   (GF1+Umlenk am Eingang entlang hz=90, nicht in Seg6/hz=-90)
```

**Der Modellbruch:** `br-lvf` = `climber-span` minus die festen Fussabdruecke
(Umlenk 500 + Separator 300 + GF1 `gf-total` + Motor). Diese Teile liegen aber
in den ANDEREN U-Schenkeln - nicht in Seg 6. Der Solver zieht sie trotzdem von
Seg 6s 3800er-Spanne ab. Weil GF1 = "alles am Einlauf" gewaehlt war, ist
`gf-total` gross -> Seg 6 wird um genau diese Summe (~2645 mm) zu kurz. Bei
einer GERADEN Bruecke liegen alle Teile auf derselben Achse - dann stimmt die
skalare Rechnung. Bei der U-Form nicht.

Zusaetzlich: die flache Zone nimmt GENAU EIN Uebergangspaar an
(`hor-pairs = 1`, Zeile 9950), obwohl die U-Form zwei 90-Grad-Kurven plus
Kletterstrecke mischt -> daraus die Rest-dZ von +80 mm.

## Beleg: dokumentiertes Limit, kein Regressionsfehler

| Kommentar-Fundstelle | Aussage |
|---|---|
| `vf_linienzug.lsp:9073-9075` | "v1-Naeherung Laenge ... feinere Laengen-Reservierung -> spaeter" |
| `vf_linienzug.lsp:9923-9926` | Modell explizit "EIN Vario mit Horizontal-Mitte" - eine gerade Bruecke ist die Design-Annahme |
| `vf_linienzug.lsp:9948-9950` | "flache Zone hat GENAU EIN Uebergangspaar ... unabhaengig von der Zahl der Fueller/Kurven" |

Verifiziert: SEGS-Umbau, Alert-Box und Mini-Filter haben Phase B (den Solver)
nachweislich nicht veraendert. Die Abweichung ist vorbestehend.

## Vorgeschlagener Umbau in sicheren Etappen

Nach jeder Etappe eine BricsCAD-Sichtpruefung (Geometrie ist nur interaktiv
pruefbar).

1. **Regressionsnetz zuerst.** Eine bekannt-gute GERADE Modus-2-Kette
   (GF...VF...GF, eine Achse) bauen und mit `lib/dxf_vf_abbild.py
   --schreibe-referenz` als Referenz einfrieren. Schuetzt den funktionierenden
   Normalfall, bevor die Bilanz umgebaut wird.
2. **Schenkel erkennen.** Den VF-Lauf (Seg `vf-start`..`vf-ende`) an den
   Vario-Kurven in Schenkel aufteilen - jeder Schenkel eine Fahrtrichtung (hz).
   Pro Schenkel: Summe der VF-Geraden-Laengen, welche festen Teile darin liegen.
   Neue Datenstruktur statt der skalaren `climber-span`. (ersetzt die
   climber/nonclimber-Schleife 9935-9947)
3. **Fussabdruecke dem richtigen Schenkel zuordnen** (Risiko-Kern). Umlenk/GF1
   nur vom Eingangs-Schenkel abziehen, Motor/GF2/ES nur vom Ausgangs-Schenkel -
   nicht pauschal von der Kletterstrecke. Reicht ein Schenkel nicht, verteilt
   sich die Restneigung auf weitere Schenkel. (feste-vf/dH-adj 9978-9989,
   this-lvf 10070, fill-len 10094-10104)
4. **Uebergangspaare pro Kurve** statt pauschal eins. `hor-pairs` aus der
   tatsaechlichen Schenkel-/Kurvenzahl ableiten - behebt die dZ-Restabweichung.
   (9950, dH-adj-Bildung 9982-9989)
5. **Verifikation.** Regressionsnetz aus Schritt 1 muss gruen bleiben (gerader
   Fall unveraendert). U-Form interaktiv: erste GF korrekt kurz,
   Kletterstrecke trifft den Zielpunkt, Motor + Kurven-Zwischenstueck + ES an
   der richtigen Stelle. SEGS-Journal bleibt formgleich.

## Risiko-Einschaetzung

- Der GERADE Fall funktioniert heute - er ist der Normalfall, fuer den der
  Solver gebaut ist. Ein Umbau der Kern-Bilanz kann ihn brechen -> Schritt 1
  (Referenznetz) ist nicht optional.
- Geometrie nur interaktiv in BricsCAD pruefbar -> mehrere Runden noetig.
- Gut eingegrenzt: der Umbau bleibt in Phase B von `vf-linienzug-modus2`
  (~9915-10145). Klassifizierung, SEGS-Journal, Doppelklick-Replay und die
  anderen Modi bleiben unberuehrt.

## Zwischenloesung (falls der Umbau nicht sofort kommt)

Gefaltete VF-Laeufe (mehr als eine Achsenrichtung im VF-Bereich, z.B. U-Form)
erkennen und mit klarer Meldung abweisen, statt still falsche Geometrie zu
bauen - analog zur bereits vorhandenen "nur EIN VF-Lauf"-Abweisung
(`vfl-m3-vf-lauf-alert`). Macht das Limit ehrlich sichtbar, kleiner Eingriff.