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>
Lisp/vf_standard.lsp: berechne-alle-winkel um Parameter schon-flach
erweitert (Fussabdruck-Korrektur, wenn ein Frame flach statt bei 3 Grad
ankommt) - vf_linienzug.lsp rief die Funktion bereits mit diesem 5.
Argument auf, dieser Commit fehlte im letzten Commit und liess den
Zwischenstand mit Argumentzahl-Mismatch zurueck. tests/test_foerderer.lsp
und tests/test_mubea.lsp ziehen dieselbe Signatur nach (inkl.
berechne-horizontale-mitte, das schon-flach bereits erwartete).
tests/testdata/linienzug_tests*.json aktualisiert passend zum echten
Bau-Ablauf. menu/SSG_LIB.mnu/.cui: TEST_LINIENZUG_STUFE2 im Testmenue
ergaenzt.
Lisp/vf_spec.lsp + lib/vf_spec_export.py: *vsp-menu-start* auf die aktuelle
6-Optionen-Kettenanfang-Zuordnung umgestellt (vorher noch 4 Optionen) -
vsp-journal replayt gegen den LEBENDEN vf-linienzug-modus. Python-Tabelle
bewusst NICHT umgestellt (dekodiert eine eingefrorene Alt-Aufzeichnung).
TEST_HUNDM05 schlaegt trotzdem weiterhin fehl (separates, ungeloestes
Problem - siehe naechster Absatz).
Bekannter offener Fehler: TEST_HUNDM05 baut nach wie vor nicht korrekt -
der Menu-Code-Fix allein reicht nicht. Root Cause nicht abschliessend
geklaert, Uebergabe an Kollegen fuer Logik-Review vorgesehen.
Co-Authored-By: Claude Sonnet 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>
y.wang
m.stangl