Ergebnis des EXPORTCSV/EXPORTSIVAS-Laufs auf der Mubea-Zeichnung NACH dem
ID-/ZUORDNUNG-Fix (2168410), abgelegt nach der Konvention von
tests/reference/ (<basis>_export.csv + <basis>_sivas.csv, wie
foerderer_tests/gefaellestrecke_tests/kreisel_tests/omniflo_tests).
mubea_export.csv belegt beide reparierten Punkte:
- 119 Zeilen mit 119 unterschiedlichen TeileIds, lueckenlos 0001-0119.
Vorher teilten sich Gefaellestrecke/VF/Kreisel und die aus ihnen
erzeugten Separator-Kopien 26 IDs (0001-0026).
- Jeder der 20 Gefaellestrecken ist genau ein Separator zugeordnet
(0016-0035), den VF-Strecken 0013/0014/0015 sind es 2/5/4. Nur die 7
tatsaechlich freistehenden Separatoren haengen noch an einer
Kreiselhaelfte (0001-R, 0002-L, 0010-R). Vorher landeten 26 in VF/GF
VERPACKTE Separatoren bei einer Kreiselhaelfte, weil die Python-seitige
Boundingbox-Suche die bekannte Wrapper-Zuordnung ueberschrieb.
tests/test_export_ids.py laeuft gegen diese Datei gruen (gegen die alte,
fehlerhafte CSV meldete er alle 26 Dubletten).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Beim CSV-Export von Mubea trugen Gefaellestrecke/VF/Kreisel und die aus
ihnen erzeugten Separator-Kopien dieselbe ID (26 Dubletten 0001-0026), und
die ZUORDNUNG der Separatoren zeigte auf den falschen Carrier.
ssg-id-check-all: neue Phase 0 ermittelt das globale Maximum der bereits
vergebenen IDs, BEVOR die erste neue ID vergeben wird (ausgelagert nach
ssg-id-max-in-ss, das auch ssg-id-max nutzt). Bisher wurde max-id erst
waehrend Phase 1 mitgezogen (Start 0); da (ssget "X" ...) in BricsCAD die
zuletzt erzeugten Entities zuerst liefert, standen die noch ID-losen
Separator-Kopien ganz vorne und bekamen 0001, 0002, ... - genau die IDs der
weiter hinten liegenden Wrapper-Bloecke. Phase 2 konnte das nicht heilen,
weil frisch vergebene IDs nicht in id-map landen.
ssg-collect-nested-inserts: fuehrt Position, Z-Drehung und Skalierung jetzt
ueber alle Verschachtelungsebenen mit (Records statt nackter Entity-Namen).
Vorher gab die Rekursion Entities tieferer Ebenen mit ihrer ROH-Position aus
der Zwischen-Blockdefinition zurueck - zwei Separatoren an derselben lokalen
Stelle in zwei verschieden platzierten Zwischenbloecken landeten dadurch auf
exakt derselben Weltposition.
csv:sep-proxies-erzeugen: die Kopie steht jetzt exakt auf Position/Drehung/
Skalierung ihres verpackten Vorbilds; der kosmetische Versatz von 500 mm ist
weg (er kippte Separatoren am Kettenende in die Boundingbox des Nachbar-
Carriers). Der vla-InsertBlock-Aufruf ist gekapselt, damit ein Sonderfall
nur diese eine Kopie ausfallen laesst statt den ganzen Export abzubrechen.
csv:sep-proxies-zuordnung-setzen (neu, laeuft NACH ssg-id-check-all, da ein
frisch gebauter Wrapper vorher keine ID hat): fuer einen VERPACKTEN Separator
ist der Carrier bekannt - es ist der Wrapper, in dem er steckt. ZUORDNUNG
wird daher auf die Wrapper-ID gesetzt (Separator in VF 0010 -> ZUORDNUNG
0010) und ueber *cs-sep-fix-by-handle* festgenagelt: cs-zuordnung-lauf
uebernimmt sie unveraendert statt sie geometrisch neu zu raten, und
csv:block-to-json reicht sie als "zuordnung_fix" an export_csv.py durch.
Ohne das ueberschrieb compute_sensor_zuordnung (Prioritaet GF > Foerderer >
Kreiselhaelfte) den bekannten Wert - in der Mubea-Zeichnung landeten 26 in
VF/GF verpackte Separatoren so bei einer Kreiselhaelfte.
export_csv.py: respektiert "zuordnung_fix" und ersetzt eine vorhandene
ZUORDNUNG nicht mehr durch "nicht zugeordnet" - nur ein echter Treffer
ueberschreibt, wie im Docstring von compute_sensor_zuordnung beschrieben.
tests/test_export_ids.py (neu): prueft je tests/output/*_export.csv, dass
jede TeileId hoechstens einmal vorkommt und jede Sensor-Zuordnung auf eine
existierende TeileId zeigt. Gegen die fehlerhafte Mubea-CSV schlaegt der
Test mit allen 26 Dubletten an.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nach dem gruenen VF_SPEC_BAU-Lauf bauten zwei Tests dieselben 5 Ketten. Der
Spec-Pfad ist jetzt der routinemaessige Bau-Test, der Aufzeichnungs-Pfad der
abgeschaltete Regressionstest fuer das Journal-Format.
Umbenennungen:
- tests/testdata/vf_spec_hundm05.json -> tests/testdata/hundm05.json
Die Spec ist das Eingabeformat und die Datei, in der weitere Ketten der
Anlage nachgetragen werden. spec_ids jetzt VF_hundm05_LZ_* (wie im
Aufzeichnungs-Protokoll), damit sich die Ergebnisse beider Laeufe paaren
lassen.
- tests/testdata/hundm05.json -> tests/testdata/hm_recformat.json
tests/test_hundm05.lsp -> tests/test_hm_recformat.lsp (TEST_HM_RECFORMAT,
Praefix hmrec:, Export hm_recformat:export-results)
tests/test_hundm05.py -> tests/test_hm_recformat.py
In alltests.json auf "disabled": true.
Neu: tests/test_hundm05.lsp (TEST_HUNDM05) baut die Spec - OHNE eigene
Bau-Logik, es ruft vsp-bau-datei aus Lisp/vf_spec.lsp. Damit gibt es genau
einen Code-Pfad, der aus einer Spec Geometrie erzeugt; c:VF_SPEC_BAU nutzt
denselben. tests/test_hundm05.py prueft das Ergebnis (die 9 Tests, die
vorher in test_vf_spec.py standen); test_vf_spec.py ist jetzt reiner
Uebersetzer-Test ohne CAD.
Warum das Aufzeichnungsformat bleibt (Details in
doc/TODO-plan-vf-interactive.md Abschnitt 4.7):
- hm_recformat.json ist die EINZIGE eingecheckte Kopie der Originaldaten
(data/polylines.dxf ist mit 124 MB per .gitignore ausgeschlossen). Die Spec
ist daraus abgeleitet; ohne die Aufzeichnung faellt die rechte Seite des
Rundlauf-Beweises weg.
- Es prueft eine ANDERE Invariante: das Journal kommt roh aus der XDATA einer
Kundenzeichnung. TEST_HM_RECFORMAT ist damit der einzige Test dafuer, dass
ein BESTEHENDER VF_n-Block weiter abspielbar ist - also dass
Doppelklick-Edit und 2D/3D-Konvertierung an Altbestand funktionieren. Ein
spec-gebautes Journal kann das nicht zeigen, es kommt aus dem Uebersetzer.
- Es dokumentiert die Frage-Reihenfolge (kommentar je Eintrag); die Spec
verbirgt den Dialog, das ist ihr Zweck.
Weitere Anpassungen:
- Ergebnisdatei heisst nach der Spec-Datei (<basisname>_results.json), damit
Befehl und Testrunner in dieselbe Datei schreiben. Verzeichnis: tests/output
(Override DXFM_VF_SPEC_OUT); NICHT DXFM_RESULTS - das sind die Sivas-/
CSV-Exporte, dort landete die Datei ausserhalb des Testbaums.
- Neu *vsp-dim-override* fuer TEST_HUNDM05_2D/_3D: wird je Kette angewandt,
weil der Abbruch-Handler in vf-linienzug-modus *ssg-ils-dim* zurueck setzt.
- Das Anlagenkuerzel der test_id in lib/vf_journal_export.py kam aus dem
Namen der Ziel-JSON. Nach der Umbenennung haette eine Regenerierung die ids
stillschweigend auf VF_hm_recformat_LZ_* geaendert und die Paarung der
beiden Laeufe zerlegt - jetzt feste Konstante TEST_ID_ANLAGE.
- conftest: hundm05_* Fixtures -> hmrec_* (die Spec-Fixtures stehen in
tests/test_hundm05.py).
Verifiziert: 98 pytest-Tests gruen (die 9 Ergebnis-Tests warten auf einen
neuen TEST_HUNDM05-Lauf), alle .lsp lint-sauber, Spec-Regenerierung
idempotent, TEST_VF_SPEC in BricsCAD 28 PASS / 0 FAIL.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Stufe 1 des Fahrplans in doc/TODO-plan-vf-interactive.md, fertig fuer
Modus 1. Eine SPEC beschreibt eine Kette in Domaenenwerten ("links",
"winkel", "aussen", ja/nein) statt in Menue-Codes; vsp-journal uebersetzt sie
in ein Eingabe-Journal, vsp-bau-aus-spec spielt es per
vfl-journal-replay-start durch den UNVERAENDERTEN vf-linienzug-modus. Der
fertige Block traegt damit dasselbe SSG_VF_EDIT-Journal wie eine handgebaute
Kette und bleibt per Doppelklick editier- und 2D/3D-konvertierbar - kein
Journal-Konsument muss etwas von Specs wissen.
CAD-Lauf VF_SPEC_BAU: 5 OK, 0 Fehler. Je Kette status "executed",
prompts 0 (keine Live-Eingabe erreicht), eingaben_offen 0, keine
Spec-Fehler, keine Bau-Meldungen, glieder_ist == glieder_soll,
Einfuegepunkt gleich dem Kettenstart der Spec.
Neu:
- Lisp/vf_spec.lsp: Code-Tabellen, Emitter vsp-journal, Validierung
vsp-pruefen, flacher JSON-Loader, Headless-Rahmen vsp-headless-an/-aus,
Ergebnis-Record, vsp-bau-aus-spec/-liste, c:VF_SPEC_BAU. Von vf_core.lsp
NACH vf_linienzug.lsp geladen - damit sind beide Ladewege abgedeckt (Menue
und der .scr-Loader), das MNL bleibt unveraendert.
- lib/vf_spec_export.py: derselbe Emitter in Python PLUS die Umkehrung
(spec_aus_journal), erzeugt die Spec-Testdaten.
- tests/testdata/vf_spec_hundm05.json: die 5 echten Ketten als Spec,
erzeugt statt handgeschrieben.
- tests/test_vf_spec.lsp (C:TEST_VF_SPEC, in alltests.json): 7 Faelle je
Glied-Typ, 7 Validierungsfaelle, Gruppieren, und die 5 echten Ketten gegen
ihr aufgezeichnetes Journal.
- tests/test_vf_spec.py: 36 Tests (Rundlauf, Spec-Daten, Validierung,
Erwartungswert-Abgleich, Ergebnisse von VF_SPEC_BAU).
Drei Regeln, die der Uebersetzer besitzen muss - jede wuerde sonst die ganze
Replay-Queue verschieben:
- Der Menue-Code haengt am Frame: erste Sektion 4 Optionen (kein GF-Bogen,
es gibt noch keine Richtung), jede spaetere 5.
- hz steht genau EINMAL im Journal, beim ersten Segment (vfl-in-abstand
journalisiert die Richtung nur bei freier Richtungswahl).
- Nur ein HORIZONTALER Erstkoerper einer VF-Einheit stellt die Separator-/
Endpunktfragen vorab (winkel1=0 laeuft durch vfl-baue-horizontal-koerper);
ein gewinkelter wird ohne jede Frage gebaut.
Wie die Richtigkeit belegt ist - drei Implementierungen derselben Grammatik,
die einander pruefen:
- Rundlauf gegen echte Daten: journal_aus_spec(spec_aus_journal(tok)) == tok
fuer alle 5 HundM-Ketten, tokenweise numerisch verglichen. Damit ist
bewiesen, dass die Spec das Journal verlustfrei abbildet.
- Der Weg, den LISP nimmt (flaches JSON -> Spec -> Journal), ergibt separat
geprueft dieselben Journale wie das aufgezeichnete Protokoll.
- Der unabhaengige Dekoder aus lib/vf_journal_export.py verdaut alle 7
synthetischen Emitter-Ausgaben restlos, auch die zwei Zweige, die in den
echten Daten fehlen (Linie-VF, gewinkelter Erstkoerper).
- Die Erwartungswerte im LISP-Test kommen aus dem geprueften Python-Emitter;
TestLispErwartungen liest sie zurueck und vergleicht erneut. Ohne das
koennte ein Uebertragungsfehler einen falschen Erwartungswert
festschreiben und der CAD-Lauf waere gruen, obwohl der Emitter falsch
liegt.
Abweichungen von der Planung (Begruendungen in doc/TODO-plan-vf-interactive.md
Abschnitt 4.6): vsp-pruefen ruft den Emitter statt eine zweite Regelmenge zu
pflegen; das vollstaendige Journal steht nicht im Record (statt dessen
glieder_soll/glieder_ist als Desync-Detektor); Zusatzfeld segment_typ am
Glied "Linie", weil dort vfl-segment-entscheidung selbst zwischen GF und VF
waehlt; vf_ende-Werte "automatisch"/"zielpunkt-ohne-es" fuer die Faelle ohne
Frage; Praefix vsp- statt vfs- (das gehoert vf_standard.lsp).
Zusaetzlich:
- tests/test_vf_headless_statisch.py prueft jetzt auch, dass
Lisp/vf_spec.lsp UEBERHAUPT keine Eingabe-/Dialogfunktion aufruft - beim
Daten-Pfad ist die Null die Vorgabe.
- tests/testdata/mubea.json: die drei einzeln eingefuegten S-LP-Separatoren
entfernt (Fortsetzung von 699744e - die Separatoren stecken jetzt in den
Staustreckenbloecken).
Noch offen: die Uebersetzer fuer Modus 2 und 3. Modus 2 braucht laut
Fahrplan erst 2-3 echte "linienzug2"-Journale als Referenz -
tests/testdata/hundm05.json enthaelt ausschliesslich Modus-1-Ketten.
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>
Grundlage fuer reproduzierbare Nachbau-Testfaelle aus echten Projekt-
zeichnungen (HundM05).
- lib/vf_journal_export.py (neu): liest die Eingabe-Journale der VF_n-Bloecke
aus der XDATA (App SSG_VF_EDIT, Marker "linienzug") und schreibt sie als
Frage-Antwort-Protokoll im Schema von tests/testdata/linienzug_tests.json -
Gegenstueck zu vfl-entry->string, ohne ezdxf (reine Gruppencode-Lesung).
Optional --csv fuer Strecken-ID und Erwartungswerte je Kette.
- lib/extract_polylines.py (neu): LWPOLYLINE-Objekte als JSON, inkl.
OCS->Welt-Umrechnung fuer gekippte Ebenen (Handles, Segment-/Gesamtlaengen).
- lib/dxf_scan_components.py: erkennt jetzt zusaetzlich, ob ein Block ein
2D-Schema oder ein 3D-Modell ist (TYPEN_3D, ist_3d_block/darstellung_von) -
eine Anlagenzeichnung enthaelt beides. Dazu Sensor-Erfassung,
Zwillings-Zusammenfuehrung und Hoehenschaetzung aus der Umgebung.
- lib/dxf_abbild.py: gibt die erkannte Darstellung je Element mit aus.
- tests/test_vf_journal_grammatik.py (neu): prueft den Journal-Dekoder gegen
handgebaute Journale - ohne CAD und ohne die grosse DXF. Deckt die zwei
Zweige ab, die in den echten Ketten nicht vorkommen: Glied "Linie-VF" und
eine VF-Einheit mit gewinkeltem Erstkoerper (dort fragt vfl-vf-einheit
KEINE Separator-/Endpunkt-Fragen vorab, anders als beim horizontalen).
- data/polylines.md, tests/testdata/hundm05_linienzug_polylines.json:
ausgewertete Streckenzuege der Quellzeichnung.
- .gitignore: die Quellzeichnungen selbst (data/polylines.dxf 124 MB,
data/polylines.dwg, tests/HM5.dwg) bleiben draussen - eingecheckt ist die
Auswertung, nicht die Zeichnung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Separator_SP_2D/_3D-Sensorsymbole, die beim Zusammenbau der Compound-Bloecke
(VF_n/GF_n/KREISEL_n) als Sub-INSERT in deren Blockdefinition verpackt
wurden, waren fuer (ssget "X" ...) unsichtbar und blieben daher ohne eigene
ID und ohne Zeile im Export-JSON. csv:sep-proxies-erzeugen (export.lsp)
sucht solche verpackten Symbole jetzt vor jedem EXPORTCSV/EXPORTSIVAS ueber
den neuen rekursiven Helfer ssg-collect-nested-inserts (ssg_core.lsp) und
legt fuer jeden Fund eine echte, temporaere Kopie an seiner Weltposition an
(silent ueber vla-InsertBlock statt command-line INSERT). Diese Kopie
durchlaeuft ID-Vergabe/Export unveraendert ueber die bestehenden Funktionen
und wird danach wieder entfernt (csv:sep-proxies-loeschen).
Co-Authored-By: Claude Sonnet 5 <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>
Die Magic-Number-Migration im VF-Cluster ist inzwischen abgeschlossen
(Commit 41eea7f), CLAUDE.md sprach aber noch von 'Migration laeuft
schrittweise'. Beschreibung an den aktuellen, in vf_konstanten.lsp
selbst dokumentierten Stand angepasst (inkl. der dort gelisteten
bewussten Ausnahmen: Config-Anbindung, itoa-Kontexte, Blocknamen-
Strings, mm/m-Umrechnung).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- --runall gibt es nicht mehr -> --check (pytest-Validierung); an allen Stellen
ersetzt (Ablauf-Diagramm, Workflow-Schritt 2, Einzelmodul-Beispiel)
- --set-as-reference existiert nicht -> Referenz aktualisieren per manuellem
copy output\<datei> reference\<datei>; zusaetzlich --diff_references (meld)
dokumentiert
- run_tests.bat hat real nur: --lisp, --check, --diff_references
- Ablauf-Diagramm + Verzeichnisstruktur auf das aktuelle Modell verallgemeinert
(9 Module aus alltests.json statt fester 4er-Liste; reference/ enthaelt
*_results.json + *_tests_export/sivas.csv + export_raw.json, keine .dxf)
- omniflo_strecke_tests.json-Beschreibung korrigiert (7 Elemente: 4 Geraden +
2 Boegen + 1 Weiche, statt des alten 12-Element-Halbkreis-Modells)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
17 vorbestehende Failures behoben - alles veraltete Tests, kein Produktivcode:
test_foerderer.py (3): CSV-Spalten header-basiert statt per festem Index
ansprechen. Die Export-CSV hat inzwischen 17 statt 11 Spalten (Insertpoint,
K1-K4, Warnungen kamen dazu, siehe lib/export_csv.py) - die Tests hingen an
row[10] fuer Merkmale. Neu: self.col-Lookup + _cell(row, spaltenname), robust
gegen weitere Spalten.
test_mubea.py (2): _is_gefaelle zaehlte einen zweiten GF_*-Eintrag (block
'S-LP', ein Separator mit assigned_to GF_Mubea) faelschlich als Gefaellestrecke
mit -> erwartete 40 statt 20. Jetzt: GF_* UND nicht _is_separator.
test_omniflo_strecke.py (12): Test und seine Testdaten-Datei waren auf zwei
verschiedene Datenmodelle geschrieben (Test: 12 Elemente, gerade_start/
kurve_180/gerade_ende, Felder drehung_ende/x_mitte; Datei: 7 Elemente,
gerade_unten/gerade_oben/bogen/weiche ohne diese Felder). Test komplett auf das
tatsaechliche 7-Element-Modell umgeschrieben (Struktur/Katalog/Geraden-
Geometrie); Boegen gegen omniflo_boegen.json, Weiche gegen omniflo_weichen.json.
Nicht angefasst (bewusst): 3x hundm05 (funktioniert noch nicht) und
test_omniflo.py::test_zeilen_matches_reference (inkonsistente Export-CSV +
veraltete Referenz - Analyse: export_csv.py ist konsistent 17-spaltig, die
Output-Datei stammt aus einem gemischten Lauf; Referenz per --set-as-reference
neu abnehmen, kein Code-Fix noetig).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
insert-inclined-scaled-block/insert-rotated-block-with-ks riefen (itoa
winkel) fuer die Statusmeldung auf. Seit *vfk-gefaelle-winkel* (3.0,
Float) statt rohem Integer-Literal 3 verwendet wird, brach das mit
"bad argument type <3.0>; expected <INTEGER>" ab - sichtbar beim
Etage-VF-Bau (Mubea-Testfall), der danach folgende Elemente (u.a.
Gefaellestrecken) nicht mehr baute. Fix: (itoa (fix winkel)).
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 L_GF/L_VF-Solve-Block (aus A/B-Restbudget) war in berechne-alle-winkel
(Standard) und berechne-winkel-etage byte-identisch. Als vf-winkel-solve
(winkel richtung A B sinα cosEff sinEff sin3 cos3) -> (winkel L_GF L_VF gueltig)
nach vf_core gezogen; beide Winkelberechnungen nutzen ihn jetzt.
Bewusst NICHT vereinheitlicht: die A/B-Berechnung (Etage hat zusaetzliche
2*schraeg-/2*gef-/2*feste-Terme, Standard nutzt feste-hz) und die Ergebnis-
tabelle (unterschiedliche Message-Keys/Arg-Form) - beides birgt Geometrie-/
Ausgaberisiko fuer geringen Zeilengewinn. Der identische, geometrie-kritische
Solve ist der wertvolle Teil.
test_foerderer.py (Winkel-Set, Monotonie, L_GF/L_VF>0) validiert das direkt.
Paren-Balance geprueft.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
hundm05 funktioniert noch nicht - im Gesamtlauf (SSG_RUN_ALL_TESTS) erstmal
abschalten, ohne den Eintrag zu loeschen.
- alltests.json: hundm05 bekommt "disabled": true
- test_run_all.lsp: alltests:load liest das Flag; der foreach ueberspringt
deaktivierte Eintraege komplett (kein Bauen/Speichern/Export) und gibt nur
einen Hinweis auf der Konsole aus ("[DEAKTIVIERT ... uebersprungen]").
Reaktivieren spaeter: Flag in alltests.json entfernen.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Der Headless-Loader ssg_load.lsp (von den .scr-Testskripten genutzt) lud die
neue ssg_ks_insert.lsp nicht - dadurch waeren insert-block-by-ks & Co. beim
Laden ueber ssg_load undefiniert (nur der guarded Nachlade-Load in vf_core/
Gefaellestrecke haette gegriffen). Jetzt explizit in korrekter Reihenfolge
(nach ssg_core/-layer, vor KreiselInsert/VarioFoerderer/Gefaellestrecke).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
vf-frage-element-winkel (AS/ES-Winkel 30/90) pruefte *vfl-wizard-mode* direkt
und oeffnete den vflw-wahl-Dialog auch bei abgeschalteter GUI - dadurch kam im
automatischen TEST_LINIENZUG trotz (ssg-gui-aus) die AS-Element-Winkel-Abfrage
als Dialog hoch. Jetzt zusaetzlich (ssg-gui-p)-Guard wie in vfl-wizard-mode-p:
bei GUI-aus faellt die Abfrage auf getstring (Mock-Queue im Test).
War die letzte ungeguardete Wizard-Dialog-Eintrittsstelle.
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>
Neun Funktionen waren doppelt gepflegt in vf_core.lsp (unbedingt) UND
Gefaellestrecke.lsp (geguardet 'Fallback wenn vf_core nicht geladen'). Da
vf_core im MNL immer nach Gefaellestrecke laedt, gewann bisher stillschweigend
die vf_core-Version - die Gefaellestrecke-Kopien waren de facto tot und wichen
leicht ab. Jetzt EINE Quelle:
ssg_ks_insert.lsp: vec-length, ks-line-axis, ks-normalize-name, ks-relativize,
ks-absolutize, ensure-block-loaded, extract-ks-from-block[-raw],
insert-block-by-ks, insert-inclined-scaled-block, insert-rotated-block-with-ks
- Kanonische vf_core-Variante uebernommen (inkl. Null-Check, ssg-ils-block-auf-ebene,
hz-Guard, Statusmeldungen). Gefaellestrecke erhaelt dadurch dieselbe Behandlung
wie im MNL-Fluss ohnehin schon aktiv.
- Cache vereinheitlicht auf *ks-cache* (guarded init im Shared-File);
*gf-ks-cache* entfaellt.
- MNL laedt ssg_ks_insert als Core-Modul VOR Gefaellestrecke/VarioFoerderer.
- vf_core + Gefaellestrecke: guarded Nachlade-Load fuer isoliertes Test/Dev-Laden.
Paren-Balance geprueft; jede der 9 Funktionen jetzt genau 1x definiert.
Beruehrt Block-Platzierung -> BricsCAD-Test Standard/Etage/Linienzug/Gefaelle
(2D+3D) noetig.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Der Block 'Temp-Objekt einfuegen -> extract-ks-from-block -> KS_EIN/KS_AUS ->
(dx dy dz)-Diff -> Temp loeschen' stand in init-bibliothek 4x (AS/ES/Bogen
auf/ab) und in init-bibliothek-etage 4x (AS30/ES30/Gefaellebogen l/r).
vf-element-masse (vf_core) kapselt exakt diese Sequenz bereits - init nutzt sie
jetzt statt eigener Kopien. Bogen-Tabellen-Eintraege via (cons w m) == altes
(list w dx dy dz), get-bogen-mass (cdr item) unveraendert. Etage-Fallbacks +
Block-vs-KS-Warnungen erhalten. Gemessene Bloecke identisch (_rechts bei Etage,
_links bei Standard).
-120 Zeilen netto. Paren-Balance geprueft.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Die 4x4-Matrix Rz(hz)*Ry(vert) stand woertlich 11x: vf_core (2x), vf_etage (4x),
Gefaellestrecke (4x), TEFInsert (1x). Neuer dependency-freier Helper
ssg-rot-matrix-zy in ssg_core.lsp (immer zuerst geladen), damit alle drei
Cluster ihn ohne Cross-Modul-Kopplung teilen.
- vf-rot-matrix bleibt als duenner Alias in vf_core (VF-Aufrufstellen unveraendert)
- Reine 2D-Rz-Matrizen (insert-block-by-ks, nur horizontal) bleiben unangetastet
(andere Form, kein Vertikalanteil)
Werte identisch - reine Extraktion. Paren-Balance geprueft.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Der identische (setq deltaL (nth 0 eingabe) ...)-Block mit 10 Feldern stand 4x
(vf_standard: vfs-standard-dialog-ablauf + c:VARIOFOERDERER_EDIT, vf_etage:
vfe-etage-dialog-ablauf + vfe-edit-ent).
Neu in vf_core.lsp: *vf-basis-eingabe-felder* (zentrale Feldreihenfolge) +
vf-basis-eingabe-entpacken (set 'sym wert auf die dyn.-skopten Aufrufer-Locals).
Alle 4 Aufrufer deklarieren die 10 Namen weiterhin in ihrer /-Liste.
Reines Refactoring, identisches Verhalten. 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>
s.ayadi
m.stangl
s.hensch