Commit Graph

72 Commits

Author SHA1 Message Date
y.wang 821b81135d fix: VF-Linienzug - ES-Fussabdruck laengs korrekt reservieren + Endpunkt per Ziellinie
Drei zusammenhaengende Korrekturen am GF-Zweig mit ES-Element (Modus 1).

1) ES-Fussabdruck wurde massiv unterschaetzt (333.65 mm zu lang)

   Reserviert wurde (abs ein-dx) - die Block-X-Komponente aus
   vf-element-masse. Ein Element wird aber so gedreht eingebaut, dass sein
   KS_EIN auf der Fahrtrichtung liegt; beim drehenden ES_Element_30
   (ein-ang=120 Grad) landet dadurch ein Teil der Block-Y-Komponente auf der
   Fahrtachse. Real verbraucht es laengs 576.2 mm statt der reservierten
   242.6 mm - die Kette ragte um die Differenz ueber den gepickten Endpunkt
   hinaus (Nutzer-Befund 2026-10-09).

   Warum das lange unentdeckt blieb: beim ES_Element_90 ist ein-ang=0, dort
   ist (abs ein-dx) ZUFAELLIG richtig. Der frueher bestaetigende 90-Grad-Test
   konnte den Fehler strukturell nicht finden (Nutzer-Hinweis).

   Neu in vf_core.lsp: vf-element-laengs / vf-element-quer (hz-unabhaengige
   Projektion auf bzw. quer zur Fahrtrichtung), vf-set-es-masse setzt
   zusaetzlich ein-laengs / ein-quer. In vf_linienzug.lsp liest vfl-es-laengs
   den Wert mit Rueckfallkette; ein bewusst genulltes ein-dx gewinnt dabei,
   damit die rund zwei Dutzend Null-/Restore-Stellen keinen Doppelabzug
   bekommen.

   In BricsCAD bestaetigt: Separator+ES verbrauchen 875.83 mm gegen 875.79 mm
   Soll (0.04 mm), Hoehe 151.23 gegen 151.20 mm.

2) Endpunkt per Ziellinie statt per Klick

   Steht die Fahrtrichtung durch den Vorgaenger fest, ist die Laenge nicht
   mehr frei: die (um den ES-Querversatz seitlich versetzte) Bahn des
   ES-KS_AUS trifft eine Ziellinie in genau einem Punkt. Ein Klick kann den
   nur annaehern. Neue Frage mit zwei gleichwertigen Optionen (Radio-Buttons
   im Wizard-Modus): Ziellinie durch ZWEI PUNKTE zeichnen - Schnittpunkt wird
   gerechnet - oder wie bisher einen Punkt waehlen.

   REIN PLANAR: die Hoehe kommt weiterhin aus dem Gefaellewinkel, die
   Ziellinie bestimmt nur X/Y (Nutzer-Praezisierung).

   Beide Wege schreiben denselben einzelnen "DL"-Journaleintrag - Replay,
   Doppelklick-Edit und 2D/3D-Konvertierung muessen von Ziellinien nichts
   wissen. Die Bindung an die Linie besteht nur beim Bauen: wird die Linie
   spaeter verschoben, folgt die Kette NICHT.

   Abwaertskompatibilitaet: die neue Frage erzeugt einen zusaetzlichen
   Journaleintrag, den aeltere Ketten nicht haben. vfl-replay-peek-art sieht
   beim Replay nach, was tatsaechlich ansteht; steht dort ein "DL", ist es
   ein Altbestand und die Frage entfaellt - sonst haette sie den Laengenwert
   als Antwort verschluckt (Queue-Desync).

3) Bedienung: Achsenzwang und ruhige Ansicht

   vfl-getpoint-achse zwingt den Cursor beim Picken auf die Anschlussachse
   (SNAPANG + ORTHOMODE, kein BKS-Wechsel - getpoint liefert daher
   unveraenderte Koordinaten). Nur die horizontale Richtung wird erzwungen,
   die Hoehe bleibt frei.

   vfl-view-refresh zoomte vor JEDER Laengeneingabe hart auf _Extents - die
   Ansicht sprang bei grossen Anlagen nach jedem Klick weg. Jetzt wird nur
   noch eingegriffen, wenn der Baupunkt aus dem sichtbaren Ausschnitt laeuft,
   und dann per _ZOOM _Center unter Beibehaltung der Zoomstufe.

13 neue Unit-Tests (etage-laengs/-quer,
vfl-es-laengs, vfl-kreuz2, vfl-laenge-bis-ziellinie inkl. Realfall aus dem
BricsCAD-Log), Suite 533/533 gruen. lang-Paritaet geprueft.

Offen und bewusst nicht angefasst: vfl-winkel-machbar-p nutzt aus-dx/ein-dx
ebenfalls als Laengsmass und hat damit denselben Fehler (AS_30: 276 mm,
ES_30: 334 mm). Der saubere Fix fuellt ein-dx/aus-dx an der Quelle mit dem
Laengswert - das beruehrt rund 87 Fundstellen samt ihrer Null-/Restore-
Konvention und gehoert separat getestet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-10-14 09:09:40 +02:00
m.stangl a6f6fcb575 [CHANGE] VF-Standard-Dialog: Geometrie-Reihenfolge angepasst (deltaL+Foerderrichtung, Einfuegehoehe+deltaH), Seite/Motorseite nebeneinander; nur Seite/Motorseite/Geruestoption bleiben Radio-Buttons, Rest wieder Combobox; Winkel/Verteilung-Dialog komplett auf Combobox zurueckgebaut (keine Radio-Variante mehr noetig)
[CHANGE] VF-Linienzug-Wizard: horizontale Kurve (GF-Bogen/Vario-Kurve) direkt nach explizit eingefuegtem AS-Element ausgegraut, da dort zuerst ein gerades Segment folgen muss

[ADD] doc/faq.md: Antworten zu VF/GF-Kombinationsfragen ergaenzt (Puffer-Umschleusung, Zielhoehe, Etagenfoerderer, Streckenueberbrueckung) + Screenshot gf-vf-kombination.png

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-08 14:42:17 +02:00
m.stangl 5b873838c1 Merge remote-tracking branch 'origin/master'
# Conflicts:
#	dcl/variofoerderer.dcl
2026-10-08 12:47:05 +02:00
m.stangl 823dc6728d [CHANGE] Streckengruppe-Menue in Werte-manuell/Zielhoehe/Stueckweise aufgeteilt, QC-Linien unter Gefaellestrecke verschoben, Linienzug-Wizard "Naechstes Element" neu sortiert (GF vor VF) mit eigenem Abschliessen-Knopf statt Kettenende-Radio
Lisp/vf_core.lsp: fuenf eigene Menue-Wrapper (LinienzugVarioFoerdererManuell/-Zielhoehe/-Stueckweise, QcLinieMitGf/-UForm) ersetzen den alten interaktiven Modus-Dialog; vfc-dialog-linienzug-modus-waehlen entfaellt.
dcl/vf_linienzug_wizard.dcl + Lisp/vf_linienzug.lsp: "Neue Linie BIS Kettenende" ist kein Radio mehr, sondern eigener Button "OK und Abschliessen" neben "Ok Weiter"; GF-Optionen stehen vor VF-Optionen.
Menue (SSG_LIB.mnu/.cui), lang/*.json, doc/kommandos.md, doc/lisp_methods.md, doc/faq.md nachgezogen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-08 12:44:36 +02:00
y.wang 00fd48d02e fix: VF-Linienzug Modus 1 GF+ES-Separator-Laenge/Hoehe korrigieren
Neue Linie: GF (Zweig A+B) zog bei Kettenende mit ES-Element nur den
ES-eigenen Fussabdruck von deltaL/deltaH ab, nicht den zusaetzlichen
automatischen 300mm-Separator, den vfl-insert-es-element immer selbst
vor dem ES-Block einfuegt - die Kette baute dadurch zu lang/zu tief.

Zusaetzlich: "Separator NACH" im Wizard-Dialog (vflw-gruppe-sep-gf-impl)
wird jetzt ausgegraut statt gefragt+nachtraeglich verworfen, wenn das
GF-Segment ohnehin mit einem ES-Element endet (der automatische
Separator deckt das bereits ab). Pending-Queue-Anzahl bleibt dabei
unveraendert (Dialog pusht weiterhin 2 Werte), um keinen Versatz mit
den nachfolgenden Konsolen-Abfragen zu erzeugen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-08 09:55:38 +02:00
s.hensch 4e39c64ec1 [ADD] Geruest: Teile-DWGs (data/geruest/<artnr>.dwg) als Geometrie im GR_-Block; TEILEFARBE als Liste parallel zu ARTINR (Flag farbig in geruest.json), Sivas-Merkmal 108 aus cfg [Sivas]; Menue-Befehle GERUEST_SAEULEN/_ROHRABHAENGER/_WANDBEFESTIGUNG
[FIX] Sivas-Export las nicht existierendes Attribut FARBE
2026-09-29 12:07:00 +02:00
s.ayadi e67f7cc1aa export: Separator-Typ VF/GF aus der Ketten-Einheit statt Bau-XDATA
Der Typ (Merkmal "Typ") jeder Separator-Zeile kommt jetzt an EINER Stelle
aus der Einheiten-Schneidung csv:kette-einheiten (neu: csv:kette-sep-typen,
eingetragen in csv:ketten-verarbeiten) - dieselbe Quelle wie die
Einheiten-Boundingbox. VF = Separator direkt vor der Umlenkstation bzw.
zwischen Umlenk- und Motorstation, sonst GF.

Die bauzeitige XDATA SSG_SEP_TYP (ssg-sep-typ-xdata-schreiben/-lesen,
15 Einfuegestellen) entfaellt. Sie war teils falsch: der Separator vor dem
ES hinter einer Motorstation bekam "VF", und ein sep_nach-Separator einer
GF, den die folgende VF-Einheit als Einlauf nutzt, blieb "GF"
(HundM05: Sep1/5/7/9/11 und Sep2).

Unit-Tests csv:kette-sep-typen in tests/test_unit.lsp.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 11:23:27 +02:00
m.stangl 2f56729308 export_csv: Separator-TYP (VF/GF) bauzeitig je Separator statt vom Wrapper-Blocknamen ableiten
csv:wrapper-strecke-typ (voriger Ansatz) las den Streckentyp aus dem
VF_n/GF_n-Wrapper-Blocknamen - falsch, weil ein einzelner Wrapper intern
mehrfach zwischen Foerderer- und Gefaellestrecke-Abschnitten wechseln kann
(HundM05 VF_1: 4 Separatoren, 2x VF, 2x GF). Jede Separator-Einfuegestelle in
vf_linienzug.lsp/Gefaellestrecke.lsp/vf_standard.lsp/vf_etage.lsp markiert
das frisch eingefuegte Staustrecke_Separator_SP_300_mm-Insert jetzt direkt
per XDATA (ssg-sep-typ-xdata-schreiben/-lesen, ssg_ks_insert.lsp). Der Export
liest den Marker am verpackten Original (nested-ent), nicht mehr am Wrapper.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-23 17:28:31 +02:00
m.stangl d0fe890d7c Start-Ausgabe entschlacken: per-Modul-Banner auf je eine Zeile kuerzen
Der SSG_LIB-Start gab ~50 Zeilen aus (mehrzeilige >>> ...geladen <<<-Banner mit
Befehlslisten/Block-Pfaden, ===-Trenner, Core-Modul-Auflistung, VarioFoerderer-
Typenliste). Fuer einen einfachen _QNEW-Start zu viel Rauschen.

Gekuerzt (nur die dicksten Bloecke, je Modul bleibt EINE knappe Zeile;
Fehler/Warnungen ALLE unveraendert erhalten):
- Kern-Module (ssg_core/dbg/dialog/layer/id): reine "X geladen"-Zeilen entfernt.
- Feature-Module: KreiselInsert/Gefaellestrecke/VarioFoerderer je auf eine
  ">>> X geladen"-Zeile; Befehlslisten, Modus-/Typen-Aufzaehlungen, Block-Pfade
  und ===-Trenner raus. VF-Submodule (vf_konstanten/standard/etage/linienzug/
  spec) Lade-Banner ganz entfernt (der Sammel-Header deckt sie ab).
- SSG_LIB_Commands "Dummy-Befehle registriert" entfernt.
- menu/SSG_LIB.mnl: ===-Trenner + Core-Auflistung raus; die doppelte
  "Einfuege-Modus 3D"-Zeile entfernt (S:STARTUP gibt sie ohnehin einmal aus).

Behalten (informativ / diagnostisch): [CFG] Config geladen: N Sektionen,
[LANG] N Texte geladen, alle FEHLER/WARNUNG-Zeilen, die Abschlusszeilen
"Alle Module geladen. Menue aktiv." + "Einfuege-Modus: 3D".

Reine Ausgabe-Reduktion, keine Logik geaendert. 243/243 LISP-Unit-Tests gruen;
alle Module laden fehlerfrei (Klammerbalance gegen HEAD unveraendert).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 22:13:33 +02:00
m.stangl 0babf78789 Tests + Bau-Pfad-Alert: 4 Baseline-Failures behoben
test_export_separatorliste.py (2 Failures, KeyError 'Separatorlist'): der Test
pruefte noch das alte Merkmal "Separatorlist" (nur SEP-Eintraege). write_
separatorliste_merkmale fuellt seit dem Umbau das Top-Level-Feld item["trackids"]
(CSV-Spalte "TrackIds") mit AS + Separatoren + ES in Baureihenfolge. Tests auf
die neue API/Semantik angepasst (empirisch verifiziert: "0054, 0052, 0053, 0055").

vf_linienzug.lsp - echter Fund des statischen Waechters: vfl-body-abschluss
setzte am "Kettenende nicht baubar"-Zweig ein (alert ...) im BAU-Pfad (blockiert
Batch/Headless). Auf vfl-meldung umgestellt (zeigt alert nur bei erlaubter GUI,
sonst princ) - genau die Regel, die der Waechter erzwingt.

test_vf_headless_statisch.py (2 Failures): Soll-Inventar an den aktuellen Code
angeglichen - 18 legitime neue Wizard-/Frage-Dialoge (vflw-gruppe-*-impl,
vflw-m2-*-impl, vfl-frage-ist-*) + vfl-ks-aus-hz-an-punkt (ssget, Zeichnung
durchsuchen) ergaenzt, vflw-gruppe-horizontal-impl entfernt (weg im Code),
vfl-edit-ent auf alert:2 (linienzug2-Abweisung, harter Schnitt).

Suite: 11 -> 7 failed. Verbleibend NICHT hier: test_hundm05.py (auf Wunsch
ausgenommen) + test_vf_geometrie.py (6x, gebautes HundM05-DXF weicht von der
Referenz ab - braucht fachliches Urteil ueber die neue Geometrie, nicht blind
die Referenz ueberschreiben). 243/243 LISP-Unit-Tests gruen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 21:30:14 +02:00
m.stangl 8be256fb5a VF: gemeinsamen Wrapper-Rumpf vf-wrapper-bauen (Standard/Etage + Linienzug)
vf-block-erstellen (vf_core, Standard/Etage) und vfl-block-erstellen
(vf_linienzug) hatten denselben ~25-Zeilen-Rumpf wortgleich: ATTDEFs am
Startpunkt, Entity-Sweep seit lastEnt, Sepliste sichern, ssg-block-wrap-welt,
Layer setzen, Sepliste-XDATA, Attribute setzen, ID + Dim-XDATA. Jetzt in
vf-wrapper-bauen (vf_core) zusammengefasst; beide Aufrufer bauen nur noch ihre
FERTIGE Attributliste (Standard/Etage: feste Werte; Linienzug: *vfl-acc-*-
Komma-Listen) und uebergeben sie - der Rumpf kennt die Attribut-Semantik nicht.

ATTDEF-FORMAT VEREINHEITLICHT auf den kanonischen Stil: 3 von 4 Wrapper-Bauern
(vfl-block-erstellen, Gefaellestrecke, Vario_Kette_Merge) nutzten bereits
identisch (10/11=startpunkt, 40, 70/72/74, alle am selben Punkt). vf-block-
erstellen war der Ausreisser mit Layer-0/Model-Space-Zwang, y-Dekrementierung
je Zeile und fehlenden Ausrichtungscodes - historischer Drift OHNE Effekt bei
unsichtbaren ATTDEFs (Flag 70=1, reine Attribut-Container). Standard/Etage
bauen die ATTDEFs damit jetzt im kanonischen Format.

Toter Code entfernt: *vfk-attdef-zeilenabstand* (einzige Nutzung war die
entfernte y-Dekrementierung). *vfk-attdef-texthoehe* jetzt in vf-wrapper-bauen
zentral genutzt.

Die ATTRIBUTWERTE sind unveraendert (Diff-Review: Bezeichnung wertgleich,
Etage-Bogen-Extra nur von zweitem ssg-attrib-set-on in die Hauptliste gezogen).
Verhaltensneutral fuer den Linienzug (hatte schon das kanonische Format);
fuer Standard/Etage aendert sich nur das (unsichtbare) ATTDEF-Format.

243/243 LISP-Unit-Tests gruen; Python-Suite unveraendert (11 Baseline);
Klammerbalance geprueft. Der Attribut-/Geometrie-Gleichstand von Standard/Etage
ist interaktiv in BricsCAD bzw. per SSG_RUN_ALL_TESTS gegenzupruefen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 21:08:54 +02:00
m.stangl bd33e277c5 VF-Linienzug/Edit: Praeambel, Debug-Session und Edit-Attributleser buendeln
Punkt 2 (vf_linienzug.lsp) - die drei Modi teilen jetzt zwei Praeambel-Helfer
statt sie wortgleich auszuschreiben:
- vfl-dbg-session-start (schalter datei funcname sessiontext): oeffnet die
  dbg-Datei + schreibt Kopf/Session-Start. M1 haengt seinen Replay-Queue-
  Diagnose-Zusatz danach an (M1-spezifisch).
- vfl-dbg-hook-installieren: der fruehe duenne dbg-*error*-Hook (M2/M3),
  Lambda mit dynamic-scope-Vertrag wie vfl-abbruch-handler-installieren.
- vfl-frage-punkt-hoehe (punkt-key hoehe-key abbruch-key wizard-prompt):
  Startpunkt/Hoehe-Praeambel (Wizard-Hook + vfl-in-point + vfl-in-real + Z
  uebernehmen, (exit) bei Abbruch). Genutzt fuer Startpunkt in M1/M2/M3 UND
  den Endpunkt in M2 (vier Aufrufstellen, vorher 4x strukturgleich).

Punkt 3 (vf_standard.lsp / vf_etage.lsp) - der wortgleiche Attribut-Lese- +
prefill-basis-Aufbau der beiden Edit-Bodies (c:VARIOFOERDERER_EDIT,
vfe-edit-ent) in vfs-edit-basis-lesen (ent xd default-deltah default-seite)
zusammengefasst; die zwei abweichenden Defaults sind Parameter. Gibt eine
Alist (prefill-basis + Rohwerte attribs/startpunkt/hz/z-start) zurueck.
vf-konvertiere-ent BEWUSST nicht mit zusammengelegt - andere Zielstruktur
(Einzelwerte + L_VF/L_GF fuer den Batch-Konverter), Zusammenfuehrung wuerde
beide verkomplizieren.

243/243 LISP-Unit-Tests gruen; Python-Suite unveraendert zur Baseline
(11 failed); Klammerbalance geprueft. Verhaltensneutrale Extraktionen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 20:55:17 +02:00
y.wang 733946c368 Merge remote-tracking branch 'origin/master' 2026-09-18 17:47:53 +02:00
y.wang 797afe48b4 fix: VF-Linienzug Modus 1 Option 6 und Modus 2 - mehrere Solver- und Dialog-Bugs behoben
- Modus 2 Hauptbug: Motorstation+GF2 nutzen jetzt den bereits im Winkel-Solve
  geplanten Wert (br-gf2-exp) statt einer zweiten, unabhaengigen Loesung aus
  gemessener Resthoehe - behebt Laengs-/Querversatz am Kettenende.
- Modus 2 Bug C: Separator/ES-Hoehenreservierung (vfl3-dback/z-junction) auch
  bei "Motorstation ohne ES" korrigiert (vorher nur bei komplett offenem Ende).
- Modus 2 Bug D: fehlender Separator/ES-Laengsanteil im Solve-Budget bei
  Einzel-Kletterer ohne flache Zone (hor-pairs=0) ergaenzt, ausschliesslich
  ueber das Laengenbudget (nicht ueber feste-hz, sonst Hoehen-Doppelzaehlung).
- Modus 1 Option 6 ("Neue Linie BIS Kettenende"): Vorzeichenfehler bei der
  Separator/ES-Hoehenreservierung fuer Richtung "Auf" behoben (musste addiert
  statt subtrahiert werden).
- Vario_Kette_Merge: VF_WINKEL-Attribut liest den Winkel jetzt direkt aus dem
  Blockname statt aus einer ungenauen Chord-Messung ueber den ganzen
  S-Bogen-Tripel (verwaesserte den Winkel Richtung 3-Grad-Basis).
- ES-/AS-Element-Winkel-Dialog: neuer schlanker Dialog ohne die dort nie
  gueltige "60 Grad"-Option (statt nur ausgegraut).
- Modus 2 Lauf-Abschluss-Dialog: roher i18n-Key statt uebersetztem Text
  behoben; Option 3 ("Motorstation + ES-Element") ausgeblendet, wenn die
  Upfront-ES-Frage bereits mit "Nein" beantwortet wurde.

Alle Fixes einzeln in BricsCAD nachgestellt und bestaetigt (dX/dZ exakt).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-18 17:46:30 +02:00
m.stangl 7dbf1248c9 VF-Linienzug Modus 2/3: Geister-Mini-Objekte aus Pfad-Auswahl filtern
Eine Rechteck-Auswahl kann winzige Geister-/Artefakt-Objekte miterfassen (real:
ein 14-mm-Mini-Bogen). gf-sortiere-objekte haengte sie per Nearest-Neighbor
stumm in die Kette -> ein Geister-Bauteil (im test_modus2.dxf: eine 90-Grad-
Kurve vor dem Motor, die der Nutzer nie gezeichnet hat; im SEGS-Journal als
7. Segment mit Sehne 14 mm sichtbar).

vfl-in-segmente wirft jetzt VOR der Sortierung alle Objekte unter
*vfk-pfad-min-segmentlaenge* (100 mm) aus und meldet Anzahl + Grund
(vfl-m3-mini-objekte-verworfen, de/en). Schwelle konservativ deutlich unter
jedem realen Bauteil (kleinstes: Separator 300 mm; kleinster echter Eck-Bogen
R500/30 Grad hat Sehne ~259 mm) und knapp ueber dem Restlaengen-Clamp (100 mm),
damit kein legitimes Segment faelschlich verworfen wird.

Neue Helfer: vfl-obj-2d-laenge (LINE-Laenge / ARC-Sehne), vfl-filter-mini-objekte
(-> (behalten . verworfen-anzahl)). Neue Konstante *vfk-pfad-min-segmentlaenge*.
Der Bug lag NICHT im SEGS-Umbau (gf-sortiere-objekte/-analysiere-kette
unveraendert) - der SEGS-Journal machte ihn nur erstmals sichtbar.

243/243 LISP-Unit-Tests gruen; JSON valide + de/en-Paritaet geprueft. Der
Geometrie-Effekt (Geister-Segment weg) ist interaktiv zu bestaetigen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 17:17:15 +02:00
m.stangl 255707f136 VF-Linienzug: VF-Lauf-Grenze als Alert-Box + toten Etage-Code entfernen
Zwei kleine Aenderungen am VF-Linienzug-Cluster:

1. Modus-2-Abweisung "nur EIN VF-Lauf moeglich" jetzt als sichtbare Meldung.
   Bislang ging die Grenze (vf-count != 1 -> M3b spaeter) nur ueber drei
   princ-Zeilen in die Konsole und war dort leicht zu uebersehen. Neuer
   zweisprachiger Text vfl-m3-vf-lauf-alert, gezeigt ueber vfl-meldung (alert-
   Box bei erlaubter GUI, headless nur princ - blockiert also keinen Batch).
   Die [M3a]-Konsolendiagnose bleibt zusaetzlich fuer den Log.

2. insert-hz-incl-scaled-block (vf_etage.lsp) entfernt - toter Code, kein
   Aufrufer im gesamten Repo (byte-genaue Pruefung + grep). Der zugehoerige,
   nur dort genutzte i18n-Key vfe-hz-incl-status ebenfalls aus de/en entfernt.
   Die anderen drei insert-hz-*-Funktionen BLEIBEN bewusst: sie unterscheiden
   sich in Platzierungssemantik (KS_EIN vs. Block-Ursprung) bzw. der
   Skalierung+KS+Vertikale-Kombination von den ssg_ks_insert-Primitiven, ein
   Ersatz wuerde die Geometrie verschieben (Kommentar an der Fundstelle).

243/243 LISP-Unit-Tests gruen; JSON valide + de/en-Paritaet geprueft.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 17:08:25 +02:00
m.stangl 8ccec9dea7 VF-Linienzug Modus 2 auf SEGS umstellen (behebt Doppelklick-Desync)
Modus 2 journalisiert die Segment-Essenz (SEGS) statt der Objekt-Handles
(OBJS) - identische Umstellung wie Modus 3. Damit ist der Block selbst-
enthalten und der Doppelklick-Neubau unabhaengig von den Original-LINE/ARC.
Behebt den beobachteten Modus-2-Desync (Winkel wurde beim Neuaufbau interaktiv
nachgefragt + Abweichung, weil der OBJS-Replay an den - ggf. verschobenen -
Pfad-Objekten hing).

- vfl-in-selection + obj-liste im Modus-2-Ablauf durch vfl-in-segmente ersetzt
  (Live: ssget -> gf-sortiere-objekte -> gf-analysiere-kette -> Eck-Vorpruefung
  -> SEGS; Replay: fertige Essenz aus dem Journal). Objektauswahl steht jetzt
  NACH der Startpunkt-Praeambel (vfl-in-segmente braucht den startpunkt).
- segmente9 (9-Feld-Essenz) eingefuehrt, 5-Feld-segmente daraus abgeleitet;
  seg-ent -> nil (kein Live-Highlight mehr, wie Modus 3).
- Marker bleibt "linienzug2".

HARTER SCHNITT fuer Altbestand: alte OBJS-"linienzug2"-Bloecke (ohne SEGS)
werden beim Doppelklick klar abgewiesen (neuer Text vfl-edit-m2-obsolet, de/en)
statt mit falschen Daten in den Bau zu laufen; der Batch-Konverter ueberspringt
sie. Erkennung: vfl-journal-hat-segs-p.

Tests: 3 file-freie Unit-Tests fuer vfl-journal-hat-segs-p (SEGS erkannt,
OBJS/leer nicht). 243/243 LISP-Unit-Tests gruen in BricsCAD; test-neutral gegen
HEAD (11=11 Python-Failures); lang-Paritaet geprueft. End-to-end (Neubau +
deckungsgleicher Doppelklick) wie bei Modus 3 interaktiv zu bestaetigen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 16:44:10 +02:00
m.stangl 008f497b5d VF-Linienzug: Abbruch-Wickel-Handler der 3 Modi zentralisieren
Der scharfe *error*-Abbruch-Handler (wickelt Teil-Geometrie bei ESC/(exit) zu
einem VF_n-Block mit vollem Journal) stand in Modus 1/2/3 dreimal WORTGLEICH,
nur der Marker-String unterschied sich. Jetzt eine gemeinsame Funktion
vfl-abbruch-handler-installieren (marker), die *error* als Lambda-Liste mit
eingebautem Marker-Literal setzt (list-Konstruktion, kein globaler Zwischen-
zustand). Der fragile Wickel-Rumpf existiert damit nur noch EINMAL - kuenftige
Fixes an einer Stelle statt drei.

Die je-Modus unterschiedliche old-error-Quelle bleibt an der Aufrufstelle
(M1: *error*, M2/M3: dbg-old-error via fruehem dbg-Hook) - nur der wortgleiche
Handler-Rumpf wird geteilt. Alle vom Handler zur Abbruchzeit dynamisch
aufgeloesten Locals (old-error/lastEnt/vfl-nummer/... /dbg-an) sind unveraendert
im Modus-Frame gebunden (VERTRAG in der Funktion dokumentiert).

Tests (tests/test_unit.lsp, tu-tests-vfl-abbruch): der Konstruktor erzeugt eine
gueltige (lambda (msg) ...)-Struktur und baut GENAU den uebergebenen Marker als
letztes Argument des vfl-modus-abbruch-sichern-Aufrufs ein (linienzug2 vs
linienzug3 geprueft). 240/240 LISP-Unit-Tests gruen in BricsCAD; keine neuen
Python-Failures (11 = HEAD-Baseline). Modus-1-ESC-Abbruch interaktiv bestaetigt
(Teilkette bleibt als editierbarer VF_n-Block stehen).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 16:36:11 +02:00
m.stangl 3cce1ec457 VF-Linienzug Modus 3 editierbar: Segment-Essenz statt Objekt-Handles
Modus 3 (Vorwaerts-Nachbau) hat jetzt dieselbe XDATA-Editierbarkeit +
Doppelklick-Neubau wie Modus 1/2. Statt der Pfad-Objekt-Handles wird die
abgeleitete Segment-ESSENZ journalisiert (neuer Journal-Typ SEGS): der VF_n-
Block ist damit selbst-enthalten, der Neubau unabhaengig davon, ob die
urspruenglichen LINE/ARC noch existieren - robuster als der OBJS-Weg von Modus 2.

Journal-Kern (vf_linienzug.lsp):
- Neuer Typ SEGS: Segmentliste (typ hz laenge bwinkel bseite spx spy epx epy)
  serialisiert als ";"-getrennte Segmente, Felder per "|". Eingebunden in
  vfl-entry->string / vfl-string->entry / vfl-entry->json.
- vfl-in-segmente: Live (ssget -> gf-sortiere-objekte -> gf-analysiere-kette ->
  Eck-Vorpruefung -> 9-Feld-Essenz) ODER Replay (Essenz direkt aus SEGS-Journal).
  Ersetzt vfl-in-selection im Modus-3-Ablauf.
- vfl-kette->segmente9 fuehrt Bau-Segmente + Start/Endpunkte zusammen; Soll-Ende
  kommt jetzt aus der Essenz statt aus den Original-Entities.

Modus-3-Umbau:
- Abbruch-Wickler + vfl-journal-xdata-schreiben mit Marker "linienzug3" (analog
  Modus 2). Kopf-Kommentar/Fehler-Handler-Variablen an Modus 2 angeglichen.
- Kein Live-Segment-Highlight mehr (Essenz-Bau reicht keine Entity mehr durch) -
  bewusst, im Code dokumentiert.

Doppelklick/Batch:
- vfl-edit-ent2 zu vfl-edit-ent-voll parametrisiert; vfl-edit-ent3 ruft
  vf-linienzug-modus3. vfl-edit-ent / vfl-konvertiere-ent / vfl-journal-xdata-
  lesen dispatchen "linienzug3".

Tests:
- 8 file-freie SEGS-Roundtrip-Unit-Tests (tests/test_unit.lsp, tu-tests-vfl-segs);
  234/234 LISP-Unit-Tests gruen in BricsCAD.
- vfl-in-segmente im statischen Headless-Waechter registriert.
- Verifiziert an einer echten linienzug3-Kette (results/test.dwg): SEGS-Journal
  korrekt geschrieben, Doppelklick-Neubau geometrisch deckungsgleich zum Original.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 15:55:47 +02:00
m.stangl 37fdedd996 VF-Linienzug AS/ES-Praeambel + csv:run-export entduplizieren
vf_linienzug.lsp: die 5-6x wortgleich ausgeschriebene AS-/ES-Winkel+Seite-
Praeambel (Winkel 30/90, Seite links/rechts, Masse setzen) in zwei
parametrische Helfer ausgelagert (vfl-frage-as-winkel-seite,
vfl-frage-es-winkel-seite - Seiten-Headerkey als Parameter, symmetrisch zum
bestehenden vfl-frage-es-seite). Ersetzt in modus1-AS, modus2-AS, modus2-ES.
modus3-AS und die QC-Nachfrage bleiben (kein echtes Duplikat, abweichende
Prompt-/Wizard-Semantik).

export.lsp: csv:run-export (181 Z.) in Phasen zerlegt - csv:export-vorbereiten
(Proxies/IDs/Zuordnung/Attribut-Update/Sep-Scan/REGENALL/bbox-Reset) und
csv:python-aufrufen (Python-Skript-Aufruf + Exitcode-Auswertung). Runner liest
sich jetzt als klare Sequenz.

Verhaltensneutrale Extraktionen; Klammerbalance unveraendert, Python-Testsuite
ohne neue Fehler (16 failed baseline vor/nach identisch).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@
2026-09-18 14:52:02 +02:00
y.wang d9eb41f4d1 Merge branch 'master' of https://gitea.schoenenberger.de/Schoenenberger_Systeme_GmbH/dxfmakros 2026-09-16 09:09:09 +02:00
y.wang 143a4e7999 fix: Ab/Auf VF Kettenende nutzt ersten Winkel-Solve statt fehleranfaelliger zweiter Loesung,fix: fehlende Separator-Reservierung vor ES-Element im Kettenende-Solve ergaenzt ,Stufe 3 (Winkel+Horizontal-Fuellstueck) fuer VF-Linienzug Modus 1 ergaenzt 2026-09-16 09:08:59 +02:00
s.ayadi 4a057862a8 fix: VF-Linienzug Journal-Reset, Spec-Grammatik (auf-ab/Linie-GF) und hz-Bug in HundM05
- 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>
2026-09-15 15:13:07 +02:00
s.ayadi 23d79ec354 feat: eingang_hoehe="auto" auf Python-Seite nachgezogen, hundm05.json bereinigt
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>
2026-09-14 12:54:30 +02:00
y.wang 41419763c0 feat: Option 4 - dynamische S-Winkelwahl (3/6/9...Grad) wie Option 5
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>
2026-09-14 09:07:04 +02:00
y.wang 1b49bd3c3b feat: Option 5 "QC Linie mit GF und U-Form" implementiert (Fa/S dynamisch, Kolinearitaet exakt)
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>
2026-09-14 08:36:17 +02:00
y.wang 0d9ec93623 fix: VF-Familie bei "Neue Linie BIS Kettenende" nutzt vfl-body-abschluss
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>
2026-09-12 01:33:01 +02:00
y.wang 38ee74ed3e feat: Konsolen-Echo fuer Endpunkt (X/Y) + Zielhoehe nach Eingabe
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>
2026-09-12 00:59:30 +02:00
y.wang 0f1c7d2edf feat: "Neue Linie BIS Kettenende" erkennt VF/GF-Startpunkt
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>
2026-09-12 00:38:15 +02:00
y.wang 942012e44d fix: Wizard-Dropdowns auf Radiobuttons, Abbrechen-Bug, ES-Element-Ausgleichsbogen
- 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>
2026-09-12 00:26:36 +02:00
y.wang 18ee46b361 fix: verbleibende e76e24e-Luecken aus vollstaendigem Gap-Vergleich geschlossen
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>
2026-09-11 22:02:39 +02:00
y.wang 0a1d21d8c5 fix: VF-Linienzug 100%-Wiederherstellung aus e76e24e abgeschlossen
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>
2026-09-11 18:26:48 +02:00
y.wang 23d653c4b3 feat: VF-Linienzug Linie-GF - Separator VOR/NACH, Endpunkt/Zielhoehe-Vorwahl, steigende GF (Sonderfall bis 3 Grad)
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>
2026-09-11 14:18:31 +02:00
m.stangl 3698c8982c Sepliste-XDATA fuer Separator/AS/ES-Reihenfolge + Unit-Tests, makunbound-Fix
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>
2026-09-09 20:36:42 +02:00
s.ayadi b812e99140 Merge remote-tracking branch 'origin/master' 2026-09-04 09:25:46 +02:00
s.hensch 15ec6c0504 [ADD] Layerdefinitionen und Farben durch layer.cfg für zusammengesetzte Blöcke wie Gefällestrecke oder Varioförderer werden beim Zusammenbau der Baugruppen in den Skripten verwendet; Ebenfalls als Fallback für Blöcke möglich, die kein Attribut LAYER besitzen. 2026-09-04 09:01:12 +02:00
s.ayadi e91f1d00d0 [REFACTOR] Stufe 2: VF-Eingang/-Ausgang getrennt + Regressionsnetz fuer die Geometrie
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>
2026-09-03 14:10:56 +02:00
s.ayadi 02303ad7fc [REFACTOR] Stufe 2, Schritte 0-4: Frage-Schale und reinen Bauteil trennen
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>
2026-09-03 12:14:27 +02:00
s.ayadi ba01455d52 [FEAT] VF-Linienzug ohne GUI/Konsole baubar (Stufe 0) + hundm05-Testfall
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>
2026-09-03 10:14:31 +02:00
s.ayadi 04a12e5981 [FIX] VF-Linienzug: Abbruch beim Editieren brach den VF-Block auf
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>
2026-09-01 15:15:16 +02:00
m.stangl 1d19121679 [FEAT] VF-Linienzug Modus 2+3: Segment-Gruppen-Dialoge + Highlight
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>
2026-08-31 16:45:25 +02:00
m.stangl ddb5dfa0f5 WINKEL_AS und WINKEL_ES hinzugefügt 2026-08-31 13:53:41 +02:00
m.stangl 2147f817fc [FEAT] VF-Linienzug: 2D/3D-Batch-Umschaltung implementiert
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>
2026-08-30 09:00:58 +02:00
m.stangl 64e8ebf6e1 [REFACTOR] VF-Linienzug: GF-Abhaengigkeitscheck der 3 Modi zusammengefuehrt
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>
2026-08-30 08:34:08 +02:00
m.stangl 41eea7fc01 [REFACTOR] VF-Cluster: Magic-Numbers auf *vfk-*-Konstanten umgestellt
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.
2026-08-29 17:10:05 +02:00
m.stangl bf0237666b [REFACTOR] VF-Linienzug: AS/ES-Winkel-Wertemenge zentral aus *vfk-as-es-winkel*
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>
2026-08-29 12:51:09 +02:00
m.stangl 3a0caadbb5 [REFACTOR] VF-Linienzug: GF-Bogen/Vario-Kurve-Winkel zentral aus *vfk-gf-bogen-winkel*
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>
2026-08-29 10:32:42 +02:00
m.stangl 089fbb8eed [REFACTOR] VF-Linienzug: Vario-Kurven-Winkelliste (90 60 30) -> (30 60 90)
Vereinheitlicht die Anzeige-Reihenfolge der Vario-Kurven-Winkel auf 30/60/90
(wie GF-Bogen). Betroffen: Glied-Schema, schema-feld-pruefen, Wizard-Gruppen-
dialog (vflw-gruppe-variokurve-impl), Live-Menue (vfl-insert-vario-kurve),
Edit-Dialog (vfl-glied-vario-dialog) und Slice-Reader (vfl-vario-slice-werte).

Labels, winkel-werte-Liste und Default-Index (jetzt Position 2 = 90) ueberall
konsistent geflippt. Reine Anzeige-Aenderung: das Journal speichert ohnehin den
ECHTEN Winkelwert (30/60/90), Blocknamen (Vario_Kurve_*_<itoa winkel>_TEF_*)
unveraendert -> bestehende Linienzug-Bloecke bleiben kompatibel
(vfl-winkel-normieren validiert ordnungsunabhaengig gegen die Menge).

Paren-Balance geprueft.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-29 10:21:19 +02:00
m.stangl 8f133f69b0 [TEST] Globaler GUI-Aus-Schalter fuer automatische Testlaeufe
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>
2026-08-29 09:39:30 +02:00
m.stangl 1e50a9388f [REFACTOR] VF-Linienzug: vfl-in-* Wrapper auf gemeinsames Skelett reduziert
vfl-in-point/-string/-real/-int teilten exakt dasselbe 3-Zweig-Muster
(Replay-Queue -> Pending-Queue -> Live-Eingabe -> Journal). Skelett jetzt
EINMAL in vfl-in-value; die vier Wrapper liefern nur noch livefn + kind.

- vfl-in-value: unveraendertes Default-Skelett (v non-nil = gueltig)
- vfl-in-value-p: Variante mit explizitem Gueltig-Praedikat, fuer vfl-in-string
  ("" ist ein gueltiger String -> striktes STR-Praedikat, Verhalten identisch)
- vfl-in-selection bleibt eigenstaendig (OBJS/Handle-Sonderlogik)

Signaturen + Journal-Format unveraendert, alle 63 Aufrufstellen bleiben gueltig.
Dynamic scoping: livefn-Lambdas sehen prompt/base/*vfl-wizard-mode* etc. ueber
den aktiven Wrapper-Frame. ~40 Zeilen weniger. Paren-Balance geprueft.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-29 07:37:07 +02:00