- vfl-journal-reset-lauf ans Funktionsanfang verschoben (Modus 1/2/3,
Lisp/vf_linienzug.lsp): stand bisher nach der Startpunkt/Hoehe/AS-
Praeambel und loeschte diese beim Reset selbst wieder - Journal begann
mit dem ersten STEP-Marker statt PT, betraf jede Kette.
- Spec-Grammatik erweitert (Lisp/vf_spec.lsp, lib/vf_linienzug_grammatik.py,
lib/vf_spec_export.py): "auf-ab" bei bereits flach ankommender Kette
(Richtungswahl statt Zielhoehe) und neue Linie-GF-Fragereihenfolge
(Kettenende direkt nach laenge_modus, inkl. vorgezogenem ES). Tests in
tests/test_vf_spec.lsp/.py angepasst.
- lib/vf_linienzug_grammatik.py: _linie("kettenende_ziel") erwartete
faelschlich ein hz-REAL nach der Distanz - der reale Bauablauf
(vfl-body-abschluss) leitet die Richtung dort aus dem Frame ab und
fragt sie nie. Fuehrte zu einem Token-Desync beim Dekodieren echter
Kettenende-Journale.
- tests/testdata/hundm05.json (VF_hundm05_LZ_01): 5 ueberfluessige
hz-Felder entfernt. vsp-linie injiziert bei JEDEM vorhandenen hz-Feld
einen Richtungs-Token, unabhaengig vom tatsaechlichen Bauablauf - die
Felder desyncten den Replay und liessen die Kette stumm mit der
falschen (verkuerzten) Geometrie fertig bauen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Lisp (vf_linienzug.lsp/vf_spec.lsp):
- vsp-eingang-hoehe unterstuetzt jetzt "auto" (NIL-Token statt REAL) -
bewusst keine Zahl vorgeben, der Bauablauf berechnet seinen eigenen
Vorschlag, wie bei leerer Konsoleneingabe
- vfl-journal-reset-lauf: internes Reset innerhalb von vf-linienzug-modus/
-modus2 loescht *vfl-replay-queue*/*vflw-pending* nicht mehr mit (Bug:
REPLAY-getriebener Bau (vsp-bau-aus-spec) brach mitten in der Kette ab,
weil eine noch unverbrauchte Queue verworfen wurde)
Python-Gegenstueck nachgezogen (lib/vf_linienzug_grammatik.py,
lib/vf_spec_export.py, lib/vf_journal_export.py):
- NIL-Token-Unterstuetzung fuer eingang_hoehe="auto" im gemeinsamen
Parser-Kern, im Schreiber (SpecSchreiber) und in der Protokoll-Annotation
- gf_verteilung ist im Schreiber jetzt an der Feldpraesenz in der Spec
festgemacht statt an einem Grammatik-Flag (selbstbeschreibend, deckt
Specs mit und ohne diese Frage ab, ohne dass der Aufrufer die Grammatik
kennen muss)
- Rundlauf-Pruefung (main(), test_verlustfrei) toleriert jetzt die bekannte,
schon dokumentierte Erweiterung um drei neue Linie-GF-Pflichtfragen
(ist_teilfolge statt exakter Gleichheit)
- test_gleiche_journale_wie_protokoll: alle 5 Ketten in hundm05.json weichen
inzwischen vom Rohprotokoll ab (Kette 1 bewusst wegen eingang_hoehe,
Ketten 2-5 schon laenger wegen Handkorrektur gegen echte DXF-Positionen)
- expliziter Skip mit Begruendung statt leerem Loop
tests/testdata/hundm05.json:
- mm-Werte (dl, Start-/Stuetzpunkte, Koordinaten der Nachtrag-Objekte) auf
eine Nachkommastelle gerundet
- nicht abgefragte Kopf-Metadaten entfernt (beschreibung, sivas_id,
sivas_bezeichnung, planquadrat, block, dxf_handle) - nur quelle bleibt
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vfl-gf-auf-ab-solve bekommt einen 3. Parameter s-winkel (S's Neigung -
F_total bleibt immer bei *vfk-gefaelle-winkel*=3 Grad). Neue reine
Massen-Helfer vfl-projiziere-neigung + vfl-gf-bogen-summe (Formel-basiertes
Pendant zu vfl-gf-bogen-erweitern aus Option 5, da Option 4's Solver ohne
Live-Probe rechnet). vfl-qc-linie-mit-gf probiert s-winkel=3,6,9,... in
einer Schleife (max. 10 Versuche), bis F_total/S beide baubar sind - der
flachste passende Winkel wird automatisch gewaehlt, damit auch kuerzere
Mittelteil-Gesamtlaengen baubar sind statt nur bei einem festen Winkel.
Bei s-winkel=3 (extra-grad=0) reduziert sich die neue Formel nachweislich
exakt auf die alte, bereits bestaetigte Formel (Term-fuer-Term verifiziert)
- kein Regressionsrisiko fuer den bisherigen Grundfall. Vom Nutzer in
BricsCAD erfolgreich getestet.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Linienzug-Modus 5: AS(90 Grad) -> Richtung+E1 in einem Klick -> 90-Grad-
GF-U-Turn (Gegenseite von AS) -> Fa(fallend, unbekannt)+Sep -> Bogen-auf-6
-> S(steigend, dynamisch 3/6/9/...Grad, flachster passender Winkel wird
automatisch gewaehlt) -> Bogen-ab-6 -> ES, mit exakter Kolinearitaets-
Rueckkehr zur AS-Eintrittsachse (2x2-Gleichungssystem Hoehe+Lage, analog
zu Option 4's E2-Loesung). E1 nutzt AS's real gemessene KS_AUS-Neigung
(neue vf-element-plan-neigung) statt der angenommenen 3 Grad - das macht
Fa/S ueberhaupt erst ueber E1 steuerbar. Bei "nicht baubar" wird eine
exakte Mindest-E1-Laenge vorgeschlagen (wie Option 4's Mindest-
Gesamtlaenge). Zusaetzlich: Bogen-Seite = Gegenseite der AS-Seite (Option 4
und 5), Fehler in vf-element-plan-neigung-Vorzeichen behoben, fehlender
Separator-Fussabdruck in der Hoehen-/Lage-Bilanz ergaenzt.
Neue GF-eigene Vertikalbogen-Bloecke (Vario_Bogen_auf/ab_3/6_rechts, 2D+3D)
fuer die Uebergaenge.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ersetzt den direkten vfl-vf-entscheidung-Aufruf (1300mm Budget, setzt
immer eine frische Umlenkstation voraus) durch Wiederverwendung von
vfl-body-abschluss + vfl-vf-ausgang-bauen - denselben Bausteinen, die
bereits "Option 3: Kettenende exakt am Zielpunkt" innerhalb einer
laufenden VF-Einheit nutzt (800mm Budget, keine Umlenkstation, volle
Stufe-1/2-Diagnose inkl. exakter Zielhoehe bleibt erhalten, da kein
GF1-Stumpf noetig ist).
Zusaetzlich: vfl-letzter-typ-familie korrigiert - letzter-typ="VF"
(gerade fertig gebaute VF-Einheit) zaehlt NICHT zur "VF"-Familie fuer
diesen Zweck, nur "Vario-Kurve" hat keine eigene Umlenkstation. Eine
neue VF-Einheit nach einer bereits fertigen braucht weiterhin eine
frische Umlenkstation (faellt jetzt korrekt auf die bisherige
Automatik zurueck).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nach jedem Endpunkt-Pick + Zielhoehe-Eingabe (Neue Linie: GF Zweig A,
Linie-VF, Neue Linie BIS Kettenende) wird jetzt der absolute Endpunkt
(X/Y, aus deltaL/hz-neu zurueckgerechnet) sowie die eingegebene
Zielhoehe und das daraus resultierende (noch UNREDUZIERTE) deltaH auf
der Konsole ausgegeben - vorher war z.B. bei "Neue Linie BIS
Kettenende" nur das bereits um den Separator+ES-Footprint reduzierte
deltaH sichtbar, was wie ein Rechenfehler wirken konnte.
Neuer Helfer: vfl-echo-endpunkt-hoehe.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bei "Neue Linie BIS Kettenende" (Option 6) wird jetzt erkannt, ob der
Startpunkt zu einer bestehenden VF- oder GF-Kette gehoert (KS_AUS-Scan
am Kettenanfang bzw. letzter-typ bei laufender Fortsetzung) und die
Bau-Logik entsprechend verzweigt, statt immer die generische
Machbarkeits-Automatik zu fragen:
- VF erkannt: baut zwingend ueber die Stufe-1/Stufe-2-Diagnose
(vfl-vf-entscheidung), auch wenn der natuerliche Winkel zufaellig
nahe 3 Grad liegt (vfl-segment-entscheidung haette dort faelschlich
eine reine GF gewaehlt)
- GF erkannt: neue Unterfrage mit denselben 2 Optionen wie "Neue Linie:
GF" (Zielhoehe fest -> Laenge berechnen, ODER Laenge fest -> Winkel
berechnen), eigener Radiobutton-Dialog (Wiederverwendung von
vflw-gruppe-gf-steigend-untermodus-impl)
- nicht eindeutig zuordenbar (z.B. frischer AS-Element-Start): bisherige
automatische Entscheidung unveraendert
Neue Helfer: vfl-letzter-typ-familie (Pendant zu vfl-kette-typ-familie
fuer den session-lokalen letzter-typ-String).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- vfl-in-abstand/-in-selection pruefen jetzt *vfl-wizard-abbruch-grund*
(bisher liefen beide an vfl-in-value/-value-p vorbei, ein Klick auf
"Abbrechen" im Wizard-Dialog fiel dadurch auf einen rohen getpoint
zurueck statt die Kette zu beenden)
- Kombiniertes ES-Element-Dialogfeld (Ja/Nein + Winkel 90/30 + Seite
links/rechts in einem Bildschirm, analog AS-Element)
- Separator VOR/NACH (horizontales Stueck) und Ist-Kettenende-Frage von
Dropdown auf Radiobuttons umgestellt, "Nein" als Vorgabe
- Neigungswinkel-Eingabe bei Gefaellestrecke: 3 Grad als Vorgabe statt
"Gegebene Hoehe"
- Zweig-C-Unterfrage (Endpunkt/Zielhoehe) bei "Steigende GF" bekommt
eigenen Radiobutton-Dialog statt generischem Dropdown-Fallback
- ES-Element-Anhaengung nach einer steigenden GF (Zweig C) baut jetzt
vorher per vfl-bogen-uebergang zurueck auf die Standard-Fallend-Basis
(ES-Element-Hardware gibt es nur fuer diese Anfahrt)
- Stufe-2-Diagnosetext klargestellt (Mindestlaenge vs. Fixwert ohne
GF-Bogen)
- Horizontal-VF: 1000mm-Mindestlaenge entfernt, GF1-Ziel-Hoehe-Feature
wiederhergestellt
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bei der abschliessenden Datei-fuer-Datei-Gap-Analyse gegen e76e24e (Funktions-
inventar + Lang-Key-Diff) zusaetzlich gefunden und behoben:
- vfl-modus-abbruch-sichern: "Zurueck"-Behandlung fehlte komplett - verwarf
bisher wie "Abbrechen" den kompletten Stand statt nur das letzte
angefangene Kettenglied zu verwerfen und automatisch neu zu fragen
(vfl-journal-truncate/-replay-start)
- vfl-vf-einheit (Punkt 7, Auf/Ab-Foerderer-Fortsetzung): Fall "Kette kommt
bereits flach an" (z.B. nach Horizontal-VF/Vario-Kurve) fehlte - fragte
bisher immer nach einer Zielhoehe, obwohl dort keine sinnvolle Zielhoehe
existiert; nutzt jetzt vfl-waehle-winkel-hoehen-tabelle
- Horizontal-VF: GF1-Stumpf wird bei vollem Eingang jetzt aus einer
abgefragten Zielhoehe berechnet statt pauschal auf *vfl-gf-min-laenge*
gesetzt
- Linie-VF/Linie (automatisch): erweiterte Stufe-2-Diagnose bei "nicht
baubar" (Mindestwert-Vorschlaege aus vfl-stufe2-diagnose) ergaenzt
- vfl-hor-koerper-bauen: klemmt weiterhin still auf Mindestlaenge (Kollegen-
Entscheidung, Bauteil muss fuer vf_spec.lsp deterministisch/kopflos
bleiben), meldet das Klemmen jetzt aber ueber vfl-meldung - die
urspruengliche interaktive "trotzdem bauen?"-Rueckfrage mit Checkpoint-
Rueckbau war nicht ohne Bruch der Kopflos-Tauglichkeit restaurierbar
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Restauriert alles aus e76e24e, das nach dem Reset auf master fehlte oder nur
teilweise wiederhergestellt war, und mit dem Kollegen-Umbau abgeglichen:
- vf_core.lsp: Radio-Button-Dialoge fuer Anlagen-Typ/Linienzug-Modus
(vfc-dialog-typ-waehlen/-linienzug-modus-waehlen) + Zurueck-Schleife im
c:VarioFoerderer-Dispatcher
- Vario-Kurve/GF-Bogen-Erkennung am Kettenanfang: vfl-eingang-modus-bestimmen
threaded durch vfl-vf-eingang-bauen/vfl-vf-einheit/vfl-vf-einheit-abschluss,
inkl. Punkt-7-Winkel/Hoehen-Tabelle fuer reduzierten Eingang
- Modus 2: Lauf-Anfang/Lauf-Abschluss (offener Anfang/Ende, GF-Verteilung
"alles Auslauf", Kletter-zu-kurz-Fallback) + Separator VOR/NACH bei
GF-Geraden
- Systemischer Bug behoben: mehrere Wizard-Dialogfunktionen nutzten noch
start_list/add_list (Dropdown) gegen laengst auf boxed_radio_column
umgestellte DCL-Dialoge (vflw-gruppe-as/-gefaelle/-variokurve/
-winkel-seite-impl, vflw-seg-linie-m2/-m3/-bogen-impl,
vfl-glied-gf-bogen/-vario/-as-es-dialog)
- Zentraler Abbruch-Trigger in vfl-in-value/-value-p wiederhergestellt (ohne
ihn wirkte der Zurueck/Abbrechen-Button in keinem Wizard-Dialog)
- vfl-frage-ist-endpunkt/-ist-kettenende als eigene Funktionen mit
Wizard-Dialog extrahiert (vorher Konsolen-Duplikate ohne Dialog-Hookup)
- 3 vfs-vf-entry-Aufrufe mit falscher Argumentzahl gefixt (akute
Absturz-Bugs in Modus 2/3)
- Tote Funktion vflw-gruppe-horizontal-impl entfernt (Tiles nicht mehr im
DCL vorhanden)
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>
Sammelt beim Bau von VF_n/GF_n-Ketten die Baureihenfolge der Separator-/
AS-/ES-Sub-Bloecke vor dem Block-Sweep und schreibt sie als XDATA auf den
fertigen Wrapper (ssg_ks_insert.lsp); export.lsp liest sie fuer das neue
"sepliste"-Feld im CSV-Export, export_neighbors.py nutzt es als Fallback
zur BBox-Kollisionspruefung. Dazu Unit-Tests fuer die reinen Serialisierungs-
funktionen (Chunking, Roundtrip) in test_unit.lsp.
Ausserdem: makunbound (existiert nicht in BricsCAD-AutoLISP) aus
test_run_all.lsp entfernt - verursachte Laufzeitfehler bei
SSG_RUN_ALL_TESTS_EXPORT/_OFFEN.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Der CAD-Lauf belegt die Schritte 0-4 jetzt auch EMPIRISCH:
results/test_hundm05.dxf entstand nach dem Umbau, das Ergebnis-JSON von
11:18 davor - fuer alle 5 Ketten sind ALLE 37 Attribute identisch,
inklusive der reihenfolgeabhaengigen Komma-Listen L_VF_m, L_GF_m, GF_WINKEL
und ANTRIEBFAHRTRICHTUNG. TEST_VF_SPEC: 28 PASS / 0 FAIL.
results/test_linienzug.dxf zeigt eine vollstaendige Kette (AS+ES, Motor,
Umlenkung, 2 Vario-Kurven, 22 Bausteine, HOEHE_VON = HOEHE_BIS = 4500 bei
DELTA_H 0).
Schritt 5a/5b - vfl-vf-eingang-bauen und vfl-vf-ausgang-bauen: beide Bloecke
(GF1 + Einlauf-Separator + Umlenkstation bzw. Motorstation + GF2) enthalten
keine Frage und sind zusammenhaengend, der Umzug ist wortwoertlich
(Zeilenvergleich: 0 Zeilen entfernt, nur zwei Koepfe, zwei Aufrufe und zwei
"frame)" neu). Die Auswahl gf2-eff (ziel-gf2 im Kettenende-Modus, sonst
L_GF2-bau) bleibt BEWUSST an der Aufrufstelle - genau dort entsteht sonst
still die falsche GF2 hinter dem Motor. Der Separator-Zaehler und die
vfl-acc-*-Aufrufe bleiben an derselben Stelle in derselben Reihenfolge.
Regressionsnetz, damit die restlichen Schritte nicht blind gemacht werden
muessen:
- lib/dxf_vf_abbild.py (neu): liest eine Testzeichnung streamend und bildet
je Kette Attribute, Bausteinzusammensetzung und Einfuegepunkt ab. Ketten
werden ueber den EINFUEGEPUNKT der Spec zugeordnet, nicht ueber den
Blocknamen - die VF-Nummer beginnt in jeder neuen Zeichnung wieder bei 1.
ID und Bezeichnung sind aus dem Vergleich heraus (pro Zeichnung neu).
--referenz vergleicht (Exit 1 bei Abweichung), --schreibe-referenz frischt
die Referenz nach einem GEPRUEFTEN Lauf auf.
- tests/reference/hundm05_attribute.json (neu): die Referenz, erzeugt aus dem
geprueften Lauf - also dem Stand, der attributgleich mit dem Zustand VOR
dem Umbau ist.
- tests/test_vf_geometrie.py (neu, 8 Tests): vergleicht automatisch, mit
einem eigenen Test nur fuer die Komma-Listen (das einzige, was eine
vertauschte vfl-acc-*-Reihenfolge sichtbar macht) und einer Gegenprobe,
dass eine verfaelschte Referenz auch erkannt wird.
Das faengt, was der Ergebnis-Record NICHT sieht: er sagt "executed, kein
Prompt, Journal aufgegangen", aber nichts darueber, ob dieselbe Geometrie
herauskam. Ablauf ab jetzt pro Schritt: umbauen -> TEST_HUNDM05 (save dxf)
-> pytest tests/test_vf_geometrie.py.
Offen bleiben 5c, 6, 8, 9, 10 (Schleifenrumpf der VF-Einheit, Daten-Executor,
Einheit-Abschluss, Kettenebene je Glied, vfl-spec-ausfuehren). Die vier
haengen zusammen: 6 und 10 brauchen den aufgeteilten Schleifenrumpf. Halb
umgebaut waere der Code schlechter dran als vor oder nach dem Umbau, darum
als ein Schritt mit CAD-Lauf davor und danach.
Verifiziert: 117 pytest-Tests gruen, vf_linienzug.lsp lint-sauber.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alle Aenderungen sind verhaltensgleich: die Frage-Schalen behalten ihre
Namen, keine Aufrufstelle in Modus 1/2/3 wurde angefasst.
Schritt 0 - vfl-ziel-report: der Soll-Ist-Vergleich am Kettenende stand
zweimal WORTGLEICH in vfl-vf-einheit-abschluss (einmal fuer "Kettenende ohne
ES", einmal "mit ES"); die Faelle unterscheiden sich nur darin, wann sie
melden, nicht was.
Schritt 1 - Winkelwahl aufgeteilt: vfl-winkel-gueltige (Kandidaten filtern)
und vfl-winkel-nach-index (Kandidat waehlen) sind rein; die Frage-Schale
vfl-waehle-winkel setzt sie zusammen. Neuer Vorgabe-Kanal
*vfl-winkel-idx-vorgabe*: ist er gesetzt, wird nicht gefragt. Kanal statt
Parameter, weil vfl-waehle-winkel aus vier Solvern gerufen wird
(vfl-vf-winkel, vfl-vf-entscheidung, vfl-body-zerlegung,
vfl-segment-entscheidung) - ein Parameter wuerde vier Signaturen und alle
deren Aufrufer aendern. Default nil, also heute ohne Wirkung.
Schritt 2 - vfl-es-masse-setzen: reines Globals-Setzen (ES-Winkel merken +
vf-set-es-masse) aus vfl-frage-es-seite gezogen. *vfl-es-winkel* wird LAZY
von den Blocknamen-Bauern gelesen und muss vor dem ersten ES-Insert stehen.
Schritt 3 - vfl-hor-koerper-bauen: die drei Fragen (Separator vor/nach,
Endpunkt) haengen an keinem berechneten Wert und stehen jetzt alle vor dem
Bau. Journal-Reihenfolge UND Entity-Reihenfolge bleiben identisch; nur
interaktiv erscheint der auf_3-Uebergangsblock erst nach den drei Fragen
statt zwischen Frage 1 und 2. Die dL-Subtraktionskette wurde Zeile fuer Zeile
uebernommen - jeder Schritt ist mit (max *vfk-restlaenge-min-clamp* ...)
geklammert, also nicht kommutativ, und der auf_3-Insert sitzt bewusst
zwischen Subtraktion 1 und 2 (sein Fussabdruck wird GEMESSEN). Nachweis:
Zeilenvergleich alt/neu, dieselben 15 geometrie-relevanten Zeilen in
derselben Reihenfolge.
Schritt 4 - vfl-body-abschluss-bauen: hier laesst sich NICHT alles vorab
fragen (vfl-neue-linie-messen braucht den Frame nach vfl-nach-3grad, die
Hoehenvorschlaege brauchen dL und die Kettenhoehe). Die Schale macht darum
3-Grad-Abschluss -> messen -> Vorschlaege -> Zielhoehe fragen, der reine Teil
beginnt bei der Zerlegung. Nachweis: Multiset-Vergleich der Zeilen, ausser
Kopf, Klammer und Aufruf ist keine Zeile veraendert.
Schritt 7 (Assertion-Teil) - vsp-journal-diff in Lisp/vf_spec.lsp: stellt das
aus der Spec erzeugte Journal Token fuer Token gegen das beim Bau neu
aufgezeichnete. Schaerfster Desync-Detektor - offene Queue-Werte und die
Glied-Folge zeigen nur grobe Abweichungen, ein einzelner Wert, der an der
falschen Stelle verbraucht wird, kann beide passieren lassen und trotzdem
andere Geometrie erzeugen. Neues Record-Feld journal_diff, neuer Test
test_journal_token_gleich.
Zwei bewusste Abweichungen von der Planung (begruendet in
doc/TODO-plan-vf-interactive.md, Abschnitt "Umsetzungsstand Stufe 2"):
vfl-hor-koerper-bauen behaelt ziel-modus als eigenen Parameter neben
ende-code (ende-code darf nil sein, die Separator-Subtraktionen haengen aber
allein am Ziel-Modus); vfl-body-abschluss-bauen braucht letzt-hz und
es-gewuenscht nicht.
Offen: Schritte 5, 6, 8, 9, 10. Das sind die, bei denen die Reihenfolge
selbst Geometrie ist - der Fahrplan verlangt nach jedem einen CAD-Lauf
(TEST_HUNDM05 + TEST_VF_SPEC + TEST_LINIENZUG), nach den Geometrie-Schritten
zusaetzlich DXF-Diff und Sivas-Export-Vergleich. Ohne Lauf zwischen den
Schritten waere ein Fehler nicht mehr einem Schritt zuzuordnen. Sie bringen
keine neue Faehigkeit: der Bau aus Daten laeuft seit Stufe 1 und ist mit
VF_SPEC_BAU belegt (5 OK, 0 Fehler).
Verifiziert: 109 pytest-Tests gruen, beide .lsp lint-sauber, kein neuer
alert/get*/ssget im Bau-Pfad (statischer Waechter).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ziel: eine VF_n-Kette soll aus einem Stapel Eingabedaten gebaut werden
koennen - ohne Dialog, ohne Konsolenfrage. Fahrplan und Begruendungen in
doc/TODO-plan-vf-interactive.md. Alle Aenderungen sind No-Ops, solange
*ssg-gui-aus* und *vfl-headless* nil sind.
Produktion (Lisp/vf_linienzug.lsp, Lisp/vf_core.lsp):
- vfl-journal-reset im Dispatcher VOR die Modus-cond gezogen. Bisher nur im
Modus-1-Zweig: ein frischer Modus-2-Lauf erbte das Journal des Vorlaufs und
schrieb es in die XDATA, ein spaeterer Doppelklick spielte fremde Eingaben
vor.
- Lokale Variable "member" in vf-linienzug-modus2 umbenannt. Sie verdeckte im
selben Scope das Builtin member, das weiter unten gebraucht wird - jedes
Kletterer-Segment waere in "bad function" gelaufen.
- Neu vfl-meldung: sammelt den Text nach *vfl-meldungen* + dbgmsg und zeigt
ihn nur bei erlaubter GUI modal, sonst per princ. Die 12 Bau-Pfad-alerts
darauf umgestellt; ein Alert blockierte sonst jeden Batch-Lauf, und sein
Text ist die einzige Auskunft, WELCHE Sektion abgewiesen wurde. Die reinen
Interaktiv-Alerts (fehlendes DCL, "nicht editierbar", "kein Journal")
bleiben alert.
- Neu *vfl-headless* (+ vfl-headless-p/-abbruch/-notausgang/-ort, Diagnose
*vfl-headless-fehler*, optionaler Antwort-Hook *vfl-headless-antwort-fn*):
eine erschoepfte Replay-Queue ist damit ein harter Abbruch MIT Fundstelle
(Art der Eingabe, Glied- und Eingabe-Nummer) statt eines stillen Rueckfalls
auf Live-Eingabe. Eingebaut in vfl-in-value, vfl-in-value-p,
vfl-in-selection und vfl-in-abstand.
- vfl-journal-reset loescht Meldungen und Diagnose mit (gehoeren zum Lauf);
vfl-view-refresh ueberspringt headless _PLAN/_ZOOM.
Testfall HundM05 (5 echte Ketten aus data/polylines.dxf):
- tests/testdata/hundm05.json neu erzeugt aus den XDATA-Journalen der
VF_n-Bloecke (lib/vf_journal_export.py) - flach, weil ssg-load-json
zeilenweise liest. Die drei kopierten Ketten bekommen ihren echten
Einfuegepunkt, nicht das veraltete HOEHE_VON-Attribut.
- tests/test_hundm05.lsp arbeitet jetzt per Journal-Replay statt mit
Eingabe-Mocks: ein echtes Journal fuehrt die geerbte Fahrtrichtung nicht mit
(vfl-in-abstand journalisiert hz nur beim ersten Segment), ein Mock kann sie
also nicht kennen. Schaltet *vfl-headless* ein und schreibt prompts,
headless_fehler und meldungen ins Ergebnis-JSON.
- Kettenschleife fangt je Kette: ein Fehler NACH dem Bau nimmt nicht mehr die
restlichen Ketten mit.
- entprev gibt es in AutoLISP nicht (nur entnext/entlast) - die Suche nach dem
fertigen Block laeuft vorwaerts ab dem Zeichnungsstand vor dem Bau. Dieselbe
Falle in tests/test_mubea.lsp mitbehoben; sie schlug dort nie zu, weil
entlast immer sofort traf.
Absicherung ohne CAD:
- tests/test_vf_headless_statisch.py: eingechecktes Inventar aller
alert/get*/ssget/new_dialog-Fundstellen je Funktion (ein neues getreal in
einer Bau-Funktion faellt auf, auch wenn sein Zweig im Test nie erreicht
wird), Praesenz des Riegels in allen vier Wrappern, Diagnose-Reset und die
Reset-Reihenfolge im Dispatcher. Dazu ein Waechter gegen erfundene
AutoLISP-Funktionen (entprev u.a.) - diese Fehlerklasse kostet sonst jedes
Mal einen CAD-Lauf.
- tests/test_hundm05.py prueft zusaetzlich prompts == 0, keine
Headless-Abbrueche und keine Bau-Meldungen.
tests/alltests.json: hundm05-Zeile laedt VarioFoerderer (nicht KreiselInsert)
und bleibt bis zu einem gruenen CAD-Lauf abgeschaltet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die interaktiven Editier-Pfade riefen den Neuaufbau ueber
vl-catch-all-apply auf. Der alte Block ist dort per entdel schon
entfernt, und der Catch faengt einen Abbruch (ESC -> (exit)) VOR
*error* ab - der Abbruch-Wickler vfl-modus-abbruch-sichern kam damit
nie zum Zug. Ergebnis: die komplette Kette blieb als lose Einzelteile
ohne VF_n-Block liegen und war nicht mehr per Doppelklick editierbar.
- vfl-edit-ent (Sektions-Zweig) und vfl-edit-ent2 rufen
vf-linienzug-modus/-modus2 jetzt DIREKT auf. Nur der
nicht-interaktive Batch-Konverter vfl-konvertiere-ent behaelt den
Catch (die Batch-Schleife muss weiterlaufen) und meldet den
betroffenen Block statt still zu scheitern.
- Beide Abbruch-Handler setzen *ssg-ils-dim* zurueck. Das tat bisher
nur der Aufrufer, der nach einem Abbruch nicht mehr erreicht wird -
der Dim-Override blieb fuer die restliche Sitzung stehen.
Wiederherstellung aus der Zeichnung (Sektions-XDATA):
- vfl-segment-xdata-sichern schrieb nur die Slice des LETZTEN Glieds
einer Schleifen-Iteration. Eine VF-Einheit mit eingebetteten
Vario-Kurven verlor dadurch ihre eigenen Eingaben. Jetzt wird der
komplette Journal-Abschnitt der Iteration geschrieben, indiziert mit
dem ersten Glied-Index darin (neu: vfl-journal-ab-glied,
vfl-steps-zaehlen). Ein Glied ohne Geometrie verbraucht seinen
Abschnitt nicht mehr - er wandert in den naechsten Record, der
Entities bekommt.
- Neue XDATA-App SSG_VF_EDIT_PRE haelt die Praeambel (Startpunkt,
Starthoehe, AS ja/nein + Winkel/Seite) auf den Entities der ersten
Iteration. Ohne sie fehlte der Kopf des Journals in jeder Sektion.
- Neuer Befehl VF_SEKTION_RESTORE: Auswahl der losen Geometrie ->
Sektionen lueckenlos ab Glied 1 zusammensetzen -> stummer Replay ->
interaktiv weiterbauen. Die alte Geometrie wird erst NACH
erfolgreichem Neuaufbau geloescht, ein Abbruch laesst sie samt XDATA
stehen (Versuch wiederholbar). Altbestand ohne Praeambel-XDATA wird
danach gefragt.
Die .dbg-Dateien bleiben reine Ausgabe und werden von keinem Befehl
gelesen - Wiederherstellungs-Daten gehoeren in die XDATA der Zeichnung.
tests/testdata/vfl_journal_hm05_abbruch.json: Journal der Session vom
2026-08-31 (9 Glieder), gegen das die Slice-/Join-Logik geprueft wurde.
Reine Daten, wird von keinem Befehl gelesen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Modus 2 (Pfad+Zielhoehe) und Modus 3 (Vorwaerts-Nachbau) fassen die je
Segment unmittelbar aufeinanderfolgenden Fragen (Typ + ggf. Neigung/
Vario-Winkel/Variante) in EINEM Wizard-DCL-Dialog zusammen - analog zu
Modus 1. Der Dialogkopf zeigt "Segment i/n ..."; das aktuelle Pfad-Segment
(LINE/ARC) wird vorher per redraw-Highlight in der Zeichnung hervorgehoben.
- Neue DCL-Dialoge: vflw_seg_linie_m2, vflw_seg_linie_m3, vflw_seg_bogen
- Neue Helfer: vflw-seg-*-impl (fuellen *vflw-pending*), vfl-seg-highlight,
vfl-seg-kopf
- Modus 3 zusaetzlich: Kettenstart- und AS-Element-Gruppen-Dialog; AS-Winkel
jetzt pending-aware ueber vfl-in-value
- Bogen-Dialog: vario-erlaubt-Flag (Modus 3 nur im offenen VF-Lauf), sonst
wuerde die unkonsumierte Variante-Antwort ins naechste Segment lecken
Alles hinter (vfl-wizard-aktiv) - bei GUI-aus (Tests) faellt alles
unveraendert auf Konsole/Replay zurueck.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bisher schaltete SSG_DIM_ALL_2D/3D die Linienzug-Foerderer nicht um
("gar nichts passiert"). Ursache: kein Dim-XDATA am VF_n-Block und
kein Konverter fuer die Marker "linienzug"/"linienzug2".
- Phase A: vfl-block-erstellen schreibt jetzt SSG_DIM-XDATA (deckt
Modus 1/2/3 + Abbruch-Sicherung in einem Zug ab).
- Phase B: neuer nicht-interaktiver Konverter vfl-konvertiere-ent
(stummer Journal-Replay mit *ssg-ils-dim*-Override, vl-catch-all
abgesichert).
- Phase C: ssg-dim-alle-umwandeln dispatcht VF_-Bloecke nach Marker
(Standard/Etage -> vf-konvertiere-ent, Linienzug -> vfl-konvertiere-ent,
Altbestand -> skip); Fehlversuche zaehlen als skip.
- Phase D: Doppelklick-Edit (vfl-edit-ent/-ent2) baut dimensionstreu
in der Bestandsblock-Dimension neu auf.
Phase 0 (VFL_KS_DIAG-Pruefung der 2D-KS) + Verifikation stehen noch aus
(nur in BricsCAD moeglich).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Der Block 'Gefaellestrecke-Modul geladen? + init-bibliothek falls noetig' war
in vf-linienzug-modus/-modus2/-modus3 wortwoertlich (bis auf den Alert-Text-
Key) dreifach vorhanden. Neue Hilfsfunktion vfl-gf-abhaengigkeit-sicherstellen
(alert-key) ersetzt alle drei Stellen; die modusspezifischen Alert-Texte
(Modus 1 ausfuehrlicher als 2/3) bleiben als Parameter erhalten, keine
Verhaltensaenderung.
Hintergrund: Analyse der beiden verbliebenen Punkt-4-Baustellen (siehe vorige
Session) ergab, dass der Journal-Serialisierer (String+JSON) KEIN Duplikat ist
(JSON ist reine Diagnose-Einbahnstrasse fuers .dbg-Log, kein Parser zurueck)
und das Modi-1/2/3-Praeludium bewusst NICHT weiter vereinheitlicht werden
sollte (die Abbruch-Handler-Aktivierung unterscheidet sich gewollt pro Modus -
Risiko > Nutzen). Dieser 3x identische GF-Check war der einzige echte Rest.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vf_core/vf_standard/vf_etage/vf_linienzug referenzieren jetzt durchgaengig
die zentralen *vfk-*-Konstanten aus vf_konstanten.lsp statt rohe Winkel-/
Laengen-/Toleranz-Literale (3.0 Grad, 500/300mm Stationen/Separatoren,
1000/800mm Mindestlaengen, AS/ES-Fallback-Versaetze, Text-/Label-Masse).
Bereits ueber ssg-cfg-or config-gefuehrte Werte bleiben unangetastet
(Config bleibt dort die aktive Quelle). vf_etage-Bogenwinkel-Inkonsistenz
(fest verdrahtete Liste ohne Bezug zu *vfk-bogen-winkel*) behoben.
vf_konstanten.lsp-Kommentare auf den neuen, aktiven Status aktualisiert.
Die gueltige AS/ES-Winkel-Menge ("30"/"90") stand als Literal doppelt im
Glied-Schema. Jetzt einmalig als *vfk-as-es-winkel* in vf_konstanten.lsp,
Schema referenziert sie (mit Fallback in vf_linienzug).
BEWUSST bei STRING geblieben (nicht INT): AS/ES ist echt 2-wertig (keine
60-Grad-Bloecke), das Journal fuehrt AS/ES-Winkel als STR - eine Umstellung auf
INT haette Journal-Format + Alt-Block-Editier-Kompatibilitaet beruehrt (2
Cluster) fuer reine Konsistenz. Zentrale Konstante beseitigt die Streuung ohne
dieses Risiko (Entscheidung mit Nutzer abgestimmt).
Die index-basierten Dialog-Mappings (if gwinkel "1" -> "30"/"90") bleiben,
da sie an feste 2-Options-DCL-Layouts gebunden sind (keine Listen-Lookups).
Paren-Balance geprueft.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Statt das '(30 60 90)-Literal an ~12 Stellen in vf_linienzug zu wiederholen
(Schema, schema-feld-pruefen, Live-Menue GF-Bogen + Vario-Kurve, Slice-Reader,
beide Edit-Dialoge), verweisen jetzt alle auf die EINMALIGE zentrale Definition
*vfk-gf-bogen-winkel* in vf_konstanten.lsp (war dort schon vorhanden, wurde aber
nirgends genutzt).
Kein Config-Eintrag (bewusst nicht in component_defaults.json): die Winkel sind
an die vorhandenen DWG-Bloecke gebunden, eine Config waere nur halb verdrahtet.
vf_konstanten ist zentrale Quelle; vf_linienzug hat einen Fallback, falls die
Datei nicht geladen wurde. Werte unveraendert (30/60/90), Journal/Blocknamen
kompatibel.
Paren-Balance geprueft.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Der VF-Linienzug-Wizard (*vfl-wizard-mode* Default T) oeffnete beim
automatischen Replay-Test DCL-Dialoge und blockierte den Lauf.
- ssg_core.lsp: globaler Schalter *ssg-gui-aus* + ssg-gui-p/-aus/-an
- vf_linienzug.lsp: neue vfl-wizard-mode-p (Wizard nur wenn *vfl-wizard-mode*
UND GUI nicht abgeschaltet); ersetzt die direkten *vfl-wizard-mode*-Checks in
vfl-in-string/-real/-int, vfl-winkel-live und vfl-wizard-aktiv (deckt damit
auch alle vflw-gruppe-*-Dialoge ab). Bei GUI-aus fallen die Eingaben auf den
getstring/getint/getreal-Pfad, den die Testrunner per Mock/Replay bedienen.
- test_linienzug.lsp: (ssg-gui-aus) vor dem Replay, (ssg-gui-an) danach (immer).
- test_run_all.lsp: GUI aus um den gesamten Batch, danach wieder an.
Alle Guards ueber atoms-family, damit aeltere Ladezustaende unveraendert
funktionieren. Paren-Balance geprueft.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Winkel im Linienzug durchgaengig als echter Wert (30/60/90) statt Auswahl-
Index (1/2/3) journalisiert - behebt den Bug, bei dem ein verrutschter
String-Wert zum falschen Bogen fuehrte (vfl-menu-winkel/-winkel-live/
-winkel-normieren, GF-Bogen und Vario-Kurve).
Zentrales Glied-Schema (*vfl-glied-schema*) als single source of truth fuer
AS/ES/GF-Bogen/Vario-Kurve: generisches bauen/lesen/validieren, benanntes
Debug-Log (GF-Bogen.winkel = 90 statt roher [INT]-Zeilen). VF-Einheit ueber
Sub-Step-Referenz (*vfl-vf-substeps*) benannt geloggt, ohne sie in ein starres
Feld-Schema zu zwingen.
Vario-Kurve als eigenes Sub-Glied editierbar (eigener STEP-Marker wie ES):
vfl-vario-slice-bauen/-werte/-splicen, vfl-glied-vario-dialog, Dispatcher-Zweig,
Label. Schwanz-erhaltender Splice (vfl-vario-slice-splicen), da die Vario-Kurve
mitten in der VF-Einheit steht und ihr Slice nachfolgende VF-Antworten enthaelt
- naiver Splice haette diese verworfen (adversarial verifiziert). Uebrige
VF-Sub-Segmente bleiben bewusst nur ueber Sektions-Ruecksprung editierbar.
Neuer Unittest tests/test_vfl_schema.lsp (TEST_VFL_SCHEMA, in alltests.json):
Roundtrip + Validierung + Vario-Schwanz-Splice ohne Geometrie.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Doppelklick auf einen Linienzug-VF_n-Block bietet jetzt zwei Modi
(neuer Dialog vfl_edit_modus.dcl / vfl-dlg-modus): auf eine Sektion
zuruecksetzen (bisheriges Verhalten) ODER die Eigenschaften EINES
einzelnen Glieds aendern (vfl-edit-glied). Fuer GF-Boegen laesst sich
Winkel (30/60/90) und Seite (links/rechts) direkt aendern; das Glied
wird per vfl-journal-splice im Ketten-Journal ersetzt und die komplette
Kette 1:1 neu aufgebaut.
Damit die nachfolgenden Glieder nach einer Bogen-Aenderung korrekt neu
verketten, speichert das Journal fuer Linien-Segmente jetzt nur noch die
relative Distanz (deltaL, neuer Journal-Kind "DL") statt eines absoluten
Punkts - nur der Kettenstartpunkt bleibt ein echter Punkt. Richtung wird
ohnehin vom Vorgaenger-Frame geerbt (nur das erste Segment journalisiert
zusaetzlich die gesnappte Richtung). vfl-in-abstand ersetzt die
punktbasierte Messung in vfl-neue-linie-messen; vfl-kettenanfang-baustein
rechnet die AS-Restlaenge rein skalar (kein pick-punkt mehr).
Wichtige Korrekturen:
- vfl-entry->string/-entry kannten den DL-Kind nicht (wurde als NIL
serialisiert -> Distanzverlust beim erneuten Lesen)
- vfl-in-abstand journalisiert jetzt in BEIDEN Zweigen (Replay UND Live),
wie die anderen vfl-in-*-Wrapper - sonst gingen die DL-Werte replizierter
Glieder beim erneuten Speichern verloren (2. Edit stuerzte ab)
Diagnose: komplettes Journal wird beim Erzeugen (XDATA-JOURNAL-JSON) und
zu Beginn eines Replays (REPLAY-QUEUE-JSON) als JSON in die Debug-Datei
geschrieben (No-Op ohne aktiven Debug-Schalter).
dcl/vfl_edit.dcl: Popup breiter (edit_width/list_width), damit lange
Sektionstexte nicht abgeschnitten werden.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Hoehe-Prompt/Wizard-Dialog schlagen jetzt zwei tatsaechlich baubare
Zielhoehen vor (Ab/Auf) statt der unveraenderten Kettenhoehe, die bei
direkter Uebernahme immer als deltaH=0 abgelehnt wurde (Linie-GF,
Linie-VF, automatische Linie, VF-Kette fortsetzen, Kettenende-Abschluss)
- Nach dem AS-Element-Einfuegen kann die real gemessene Restlaenge negativ
werden (Klickpunkt zu nah); Linie-GF und automatische Linie pruefen das
jetzt und brechen sauber ab statt eine entartete GF-Strecke zu bauen
- Debug-Log (Modus 1) protokolliert jetzt Erfolg/Misserfolg der
Geometrieerzeugung inkl. der verwendeten Werte
- Neue Lisp/vf_konstanten.lsp: zentrale, dokumentierte Sammlung aller
Laengen-/Winkel-Magic-Numbers aus dem VarioFoerderer-Cluster als
Nachschlagewerk (Module selbst noch unveraendert)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Beim Editieren einer bestehenden VF_n-Kette (VARIOFOERDERER_EDIT) feuerten
die Wizard-DCL-Gruppendialoge (vflw-gruppe-*-impl) weiterhin, obwohl der
Ablauf gerade aus dem gespeicherten Journal repliziert wurde - sie waren nur
an *vfl-wizard-mode* gebunden, nicht an den Replay-Status. Ihre Antworten
landeten in *vflw-pending*, wurden dort aber nie konsumiert (die vfl-in-*-
Wrapper pruefen die Replay-Queue zuerst) und blieben liegen. Sobald die
Replay-Queue leer war und auf Live-Eingabe umgeschaltet wurde, laseen die
Wrapper diese laengst veralteten, falsch typisierten Werte statt neu zu
fragen - z.B. landete eine Menue-Antwort ("1") in vfl-in-point und liess
vfl-neue-linie-messen mit "bad argument type <1> ; expected <CONS>" abstuerzen.
Neue Hilfsfunktion vfl-wizard-aktiv prueft zusaetzlich *vfl-replay-queue*
und ersetzt an allen 15 Aufrufstellen die reine *vfl-wizard-mode*-Abfrage.
Als Absicherung leeren vfl-journal-reset und vfl-journal-replay-start jetzt
zusaetzlich *vflw-pending*.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Debug-Logging (Schalter vfl-modus1/2/3) ist jetzt standardmaessig AN statt
AUS, damit nicht vor jeder Session manuell eingeschaltet werden muss. Modus 2
(vf-linienzug-modus2) war bisher nicht instrumentiert - Session-Open/Close
und *error*-Handling analog Modus 1/3 ergaenzt; da Modus 2 durchgehend die
vfl-in-*-Wrapper nutzt, wird das Eingabe-Logging automatisch ueber den
vorhandenen vfl-journal-record-Hook mitgezogen.
Bugfix: Der Hoehen-Vorschlag im GF-Zielhoehe-Dialog (Wizard + Konsole) war
schlicht die unveraenderte Ist-Hoehe der Kette. Direkt uebernommen ergab das
deltaH=0, was als "Auf" statt "Ab" gewertet und immer mit "kann nicht
steigen" abgelehnt wurde - der Default war also nie baubar. Neue Hilfs-
funktion vfl-gf-hoehe-vorschlag rundet auf volle mm ab und zieht bei
bereits ganzzahligen Werten zusaetzlich 1mm ab, damit der Vorschlag
garantiert unterhalb der Ist-Hoehe liegt.
Ausserdem: unnoetige Anfuehrungszeichen aus den zugehoerigen Fehlermeldungen
(de/en) entfernt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Zentrale Debug-Schalter-Sammlung (*dbg-schalter*, Default AUS) in
ssg_dbg.lsp: dbg-schalter-on/-off/-p/-open/-liste. dbg*-Aufrufe bleiben
dauerhaft im Code, ohne im Normalbetrieb .dbg-Dateien zu erzeugen.
Modus 1 (vf-linienzug-modus): Session-Logging ueber Schalter
"vfl-modus1" nach DXFM_LOG/vfl_modus1.dbg. Da alle interaktiven
Eingaben bereits ueber die gemeinsamen vfl-in-point/-string/-real/
-int/-value/-selection-Wrapper laufen, reicht eine einzige
Instrumentierung in vfl-journal-record/-mark/-steplabel, um jede
Frage/Antwort automatisch mitzuloggen.
Modus 3 (vf-linienzug-modus3): auf dieselben vfl-in-*-Wrapper
umgestellt (vorher rohe getstring/getreal/getint/ssget) - profitiert
dadurch vom selben automatischen Logging (Schalter "vfl-modus3",
DXFM_LOG/vfl_modus3.dbg). Kein Journal-Replay/XDATA wie bei Modus 1/2,
nur das Logging wurde uebernommen. Fix nebenbei: Dialog-Kopfzeile
"Hoehe (Z) des Endpunkts [%1]" zeigte den Platzhalter woertlich statt
des Vorschlagswerts (ssg-text statt ssg-textf).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Betrifft VarioFoerderer-Kern, Standard-/Etage-Aufbau und Linienzug (inkl.
altem Vorwaerts-Nachbau-Modus und Vario_Kette_Merge-Diagnose). Neue Keys in
lang/de_DE.json und lang/en_GB.json ergaenzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Abbruch (ESC) im Linienzug-Baumodus loescht die bereits eingefuegte
Geometrie nicht mehr, sondern wickelt sie wie ein fertiger Bau zu einem
VF_n-Block und schreibt das volle Eingabe-Journal als XDATA drauf
(vfl-modus-abbruch-sichern, ersetzt das bisherige Loesch-Rollback). Die
Teil-Kette bleibt damit stehen und ist sofort per Doppelklick weiter
editierbar/fortsetzbar - unabhaengig davon, ob der Abbruch beim frischen
Bauen oder mitten in einem Editier-Neuaufbau passiert. Der bisherige
Menuepunkt "Letzten Abbruch fortsetzen" (Session-Variable) entfaellt
dadurch ersatzlos.
vfl-edit-ent (Doppelklick-Editieren) fragt die Sektion, auf die
zurueckgesetzt werden soll, jetzt per neuem DCL-Dialog ab
(dcl/vfl_edit.dcl, vfl-dlg-position: Combobox 1..N + OK/Abbrechen) statt
per Text-Prompt. Vorbelegung auf die letzte Sektion, damit Doppelklick +
sofort OK einen abgebrochenen Bau nahtlos fortsetzt.
Die *error*-Handler-Installation wandert vor den allerersten Prompt
(vorher: nach Startpunkt/AS-Frage), damit ein ESC in diesem Fenster nicht
mehr auf den ungeschuetzten vorherigen Handler faellt. Das Wickeln im
Abbruch-Pfad ist per vl-catch-all-apply abgesichert, da vfl-block-erstellen
intern einen BKS-Wechsel per (command "_.UCS" ...) macht.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Lokaler Stand (Modus-3 Randwert-Solver, 30/90-AS/ES, Kreisel-Attribute)
mit dem Remote-Stand (Internationalisierung ssg-text, neue Bloecke,
Sivas-Export) vereint.
Konfliktaufloesung:
- vf_linienzug.lsp: Nicht-interaktive -block-Kerne (fuer Pfad-Modi) behalten,
interaktive Abfragen (GF-Bogen, Vario-Kurve, ES-Seite) auf ssg-text
umgestellt. Kein doppelter defun mehr.
- Gefaellestrecke.lsp: 30/90-Winkelabfrage mit den i18n-Seiten-Prompts
kombiniert; gefaellestrecke-einfuegen-Aufruf mit as-/es-winkel.
- vf_core.lsp: vf-frage-element-winkel nimmt jetzt einen i18n-Header-Key
(vf-winkel-aus-header / vf-winkel-ein-header) statt festem Text.
- lang/de_DE.json + en_GB.json: neue Keys vf-winkel-aus/ein-header,
vf-winkel-90/30; gf-seite-Header ohne irrefuehrendes "_90_".
- export_sivas.py: ANZAHL_SEPARATOR/ANZAHL_SCANNER mit N_*-Fallback plus
Remote-Umsortierung; doppelte "Kreiselart"-Zeile entfernt.
- AS_Element_30_links/rechts.dwg + Separator_SP.dwg (3D): Remote-Version
(Attribut-Stand) uebernommen. Die KS_AUS-Geometrie-Korrektur der 30-Grad-
AS-Elemente wird danach in BricsCAD nachgezogen.
Offen (Folge-Commit): die Modus-Treiber in vf_linienzug.lsp
(vf-linienzug-modus / -modus2 / -modus3) sind noch nicht i18n
(ca. 110 Strings).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Vollstaendiger i18n-Rollout ueber alle Feature- und Kernmodule: alle benutzersichtbaren princ/prompt/getXXX/alert-Texte laufen jetzt ueber die zentrale Sprachtabelle in ssg_lang.lsp (Deutsch/Englisch, umschaltbar via SSG_SPRACHE). 403 Tabelleneintraege, 497 Aufrufstellen in 17 Dateien.
Ausgeschlossen wie geplant: Debug-Ausgaben (dbg*), Lademeldungen, [DUMMY]-Platzhalter, [CFG]/[OMNI]-Diagnosemarker.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
