Gefaltete VF-Laeufe wurden zu kurz gebaut, weil der Solver Posten dem
falschen Schenkel zurechnete. Vier Aenderungen, alle nach demselben
Leitsatz: die letzten freien Groessen folgen der GEMESSENEN Ist-Lage,
nicht einer vorab verteilten Gesamtplanung.
1. vfl-zsolve-schluss-ziel (neu): endet der Lauf auf einem flachen
Fueller, werden RICHTUNG und LAENGE gemeinsam gegen den Zielpunkt
geloest statt nur die Laenge. Geschlossene Loesung ueber
A = sqrt(|D|^2 - P^2), hz = Winkel(D) - atan2(P, A); C und P sind
von hz unabhaengig, daher ohne Iteration. Bisher uebernahm der
Solve die Richtung aus dem gezeichneten Pfad - ein Querversatz der
realen Eck-Bauteile war damit prinzipiell unerreichbar, weil eine
Laenge die Kette nur entlang ihrer Achse verschiebt.
2. Eingangs-Hardware bei gefaltetem Lauf: Umlenkstation + Separator
stehen auf dem Eingangs-Schenkel und verbrauchen die Kletterspanne
nicht; ihr Laengenanteil wird der Spanne wieder zugeschlagen.
feste-vf bleibt unveraendert - sein sin3-Hoehenanteil ist real.
3. kletter-ende-fp: endet der Lauf auf einem KLETTERER, gibt es keinen
Schluss-Fueller, der Motorstation + Separator + ES abzieht - sie
standen in keinem Budget. Nur bei flacher Zone, Pfadende und
vorhandenem ES, sonst sind sie bereits anderweitig verbucht.
4. Nachrechner wieder aktiv (8 statt 4 Runden): GF1 steht im Budget,
aber im Eingangs-Schenkel. Die Kollision mit filler-A-len, wegen
der er abgeschaltet war, ist entfallen.
3 und 4 wirken NUR gemeinsam - die Betraege heben sich teilweise auf,
eine einzeln eingebaute Korrektur verschiebt den Fehler bloss in die
andere Richtung (GF1 1636.9 - (Motor+Sep+ES) 1235.1 = 401.8 mm).
Gemessen am selben Pfad: 9 Grad 0.56 mm, 12 Grad 0.7 mm quer (vorher
1424 bzw. 934 mm), dZ 0.1 mm. Beide Modus-2-Regressionsketten weiter
OK; TEST_UNIT 904/904 mit 7 neuen file-freien Tests.
doc/todo.md: Punkt "Modus-2-Solver: achsenweise Laengen-Bilanz" ist
damit erledigt. Die Detaildatei bleibt liegen, weil vier Kommentare in
vf_linienzug.lsp auf ihren Pfad verweisen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier Eintraege geprueft, drei davon betroffen:
- Spec-Uebersetzer Modus 2/3: Entscheidung dokumentiert, dass die Spec dort
NICHT gebaut wird (SEGS macht die Journale selbst-enthalten), welche drei
Schritte stattdessen umgesetzt wurden und warum die uebrigen gestrichen
sind. Offen bleibt nur dasselbe fuer Modus 3 - dort fehlt ein
aufgezeichnetes Journal als Netz.
- Achsenweise Laengen-Bilanz: teilweise entschaerft. AS-Element,
Abschlussbogen+Motorstation und die Eck-Differenzen gehen seit ce4ad0f an
das Segment, auf dem sie stehen - vfl-eck-extra ist bereits die hier
geforderte Form (Zuschlag je Segment statt Skalar). SKALAR geblieben sind
feste-vf und gf-total, und genau die verursachen den U-Form-Fehler; das
Symptom bleibt also bestehen. Mit Hinweis, dass die neuen
Zuschlags-Meldungen der schnellste Einstieg in die Diagnose sind.
- Linienzug ohne GUI, Schritt 11: war zurueckgestellt, bis echte
Modus-2-Journale als Referenz vorliegen. Diese Vorbedingung ist erfuellt;
der Schritt selbst bleibt offen.
Unveraendert: Stufe-3-Winkelwahl "Ab"-Zweig - von dieser Arbeit nicht
beruehrt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
WARUM MODUS 3 BLEIBT
Modus 2 und 3 arbeiten beide auf einem gezeichneten Pfad (LINE/ARC), aber sie
loesen verschiedene Aufgaben:
Modus 2 = Randwertproblem - Start UND Ziel (je X/Y/Z) sind bekannt, die
Zwischenhoehen werden gerechnet, die Zielhoehe wird exakt
getroffen.
Modus 3 = Anfangswertproblem - die Kette wird mit vorgegebenen Winkeln
vorwaerts durchgebaut, die Endhoehe ist das ERGEBNIS.
Modus 3 kann damit etwas, was Modus 2 grundsaetzlich nicht kann: ohne
vorgegebene Zielhoehe arbeiten ("folge dieser Linie mit 3 Grad und lass uns
sehen, wo wir landen") - und er hat keinen Solver, der scheitern kann.
Dazu kommt ein harter Bestandsgrund: Modus 3 schreibt ein eigenes Journal
(Marker "linienzug3") und ist per Doppelklick editierbar. Faellt der Code
weg, verlieren alle bereits damit gebauten Ketten ihren Editier-Pfad.
Der Stempel "Legacy / wird umgebaut" war ueberholt und ist raus.
MODUS 3 - DREI AENDERUNGEN (Nutzer-Vorgabe 2026-10-22)
1. "AS bauen?" und 2. "ES bauen?" sind jetzt abfragbar (vorher wurden beide
immer gebaut), zusammen mit Winkel und Seite in je EINEM Dialog - dasselbe
Muster, das Modus 2 schon nutzt (vflw-gruppe-as-impl), kein neuer Code.
Ohne AS beginnt die Kette direkt am Startpunkt (flacher Rahmen statt
Block); die Fussabdruck-Trimmung der ersten Geraden rechnet dann von
selbst 0, weil Rahmen und Startpunkt zusammenfallen.
3. Die ES-Frage steht jetzt VOR dem Bau. Das behebt einen echten Fehler: die
letzte Gerade wird um "Separator + ein-dx" gekuerzt, ein-dx wurde aber
gelesen, BEVOR es gesetzt war - beim ersten Lauf griff der Schaetzwert
*vfk-as-es-fallback-dx*, bei jedem weiteren stand dort der Wert der
VORHERIGEN Kette (falscher Winkel, falsche Seite). Jetzt traegt die
Trimmung den echten Fussabdruck der gewaehlten ES-Variante; ohne ES
entfaellt sie ganz.
ABWAERTSKOMPATIBILITAET
Das Verschieben der ES-Frage aendert die Journal-Reihenfolge. Bestehende
"linienzug3"-Ketten bleiben per Doppelklick nachbaubar: alt-journal erkennt
sie am WERT des ersten Antwort-Eintrags ("30"/"90" = alt, "1"/"2" = neu, die
Mengen sind disjunkt) und spielt sie in der alten Reihenfolge ab. Dafuer der
neue Helfer vfl-replay-peek-wert neben vfl-replay-peek-art.
DIALOG vflw_as
Die Seitenauswahl wurde bei 30 Grad ausgegraut und NICHT in die Pending-Queue
gelegt - eine reine Modus-1-Regel (dort ersetzte die Zufuehrungsachse die
Seitenfrage). Modus 1 hat seit 2026-10-21 seinen eigenen Dialog; uebrig
blieben ES-Element sowie Modus 2/3, wo die Seite IMMER gebraucht wird - dort
ging bei 30 Grad ein zweites Fenster nur fuer die Seite auf. Entfernt.
NAMENSSCHEMA (faellt in denselben Commit, weil dieselbe Datei)
Die Helfer-Praefixe vfl2-/vfl3- stammten aus einer Planungsphase vor der
endgueltigen Menue-Zuordnung und waren dazu VERTAUSCHT: alle vfl3-* gehoeren
zu Modus 2, die vfl2-* zu Modus 3 - und drei davon zu BEIDEN. Eine
Modus-Nummer war fuer diese drei also gar nicht richtig vergebbar. Sie heissen
jetzt nach ihrer Rolle: vfl-zsolve-* (rechnet die Hoehen durch, nur Modus 2)
und vfl-pfad-* (arbeitet am gezeichneten Pfad, Modus 2 UND 3). 18 Funktionen,
jede Aufrufstelle maschinell gegen die Definitionen geprueft. Die falsche
Block-Ueberschrift "MODUS 3: Pfad + Ziel-Hoehe" (gemeint war Modus 2) ist
korrigiert, beide Gruppen haben jetzt einen erklaerenden Kopf.
vfl-zsolve-bruecke (frueher vfl3-solve-bruecke) wird von niemandem aufgerufen
- bewusst stehen gelassen und markiert, Loeschen gehoert in ein
Tote-Code-Review.
MENUE
Die Modi heissen jetzt nach ihrem Unterschied statt nach der Bedienung:
"aus 3D Linie mit Zielhoehe" / "aus 3D Linie ohne Zielhoehe" (vorher
"3D Objekte stueckweise (in Arbeit)").
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
y.wang
m.stangl