1bdecf0678efa4fc9fa515c5b5e753601d9dadb9
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Samer AyadiandClaude Sonnet 5
|
1bdecf0678 |
fix: Horizontal-VF-Kettenanfang (eingang_hoehe) in vsp-journal nachgezogen, hundm05.json erneuert
vf-linienzug-modus fragt bei einem mit "Horizontal-VF" eroeffneten Kettenanfang eine Ziel-Hoehe fuer den GF1-Einlauf ab (vfl-prompt-hoehe- eingang-gf1) und laesst dort die GF-Verteilungsfrage weg (fest "alles am Einlauf") - vsp-journal/vsp-vf-einheit kannten das noch nicht. Ausserdem werden ES-Winkel/-Seite beim kettenende-sub jetzt an der richtigen Journal-Position (inkl. eigenem STEP-Marker) emittiert. tests/testdata/hundm05.json: VF_hundm05_LZ_02..05 (die vier baugleichen Schleifen, Block VF_1) aus tests/testdata/linienzug_tests.json neu abgeleitet, mit den realen Startkoordinaten aus results/test_hundM05.dxf statt der alten "sub":"auf-ab"-Behelfsloesung. VF_hundm05_LZ_01 und alle Kreisel-/Separator-/Scanner-/BTMT-Objekte unveraendert. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
 Yuelin WangandClaude Sonnet 5
|
4418840d5e |
fix: berechne-alle-winkel Signatur-Nachzug (schon-flach) + HundM05-Menu-Fix nachgezogen
Lisp/vf_standard.lsp: berechne-alle-winkel um Parameter schon-flach erweitert (Fussabdruck-Korrektur, wenn ein Frame flach statt bei 3 Grad ankommt) - vf_linienzug.lsp rief die Funktion bereits mit diesem 5. Argument auf, dieser Commit fehlte im letzten Commit und liess den Zwischenstand mit Argumentzahl-Mismatch zurueck. tests/test_foerderer.lsp und tests/test_mubea.lsp ziehen dieselbe Signatur nach (inkl. berechne-horizontale-mitte, das schon-flach bereits erwartete). tests/testdata/linienzug_tests*.json aktualisiert passend zum echten Bau-Ablauf. menu/SSG_LIB.mnu/.cui: TEST_LINIENZUG_STUFE2 im Testmenue ergaenzt. Lisp/vf_spec.lsp + lib/vf_spec_export.py: *vsp-menu-start* auf die aktuelle 6-Optionen-Kettenanfang-Zuordnung umgestellt (vorher noch 4 Optionen) - vsp-journal replayt gegen den LEBENDEN vf-linienzug-modus. Python-Tabelle bewusst NICHT umgestellt (dekodiert eine eingefrorene Alt-Aufzeichnung). TEST_HUNDM05 schlaegt trotzdem weiterhin fehl (separates, ungeloestes Problem - siehe naechster Absatz). Bekannter offener Fehler: TEST_HUNDM05 baut nach wie vor nicht korrekt - der Menu-Code-Fix allein reicht nicht. Root Cause nicht abschliessend geklaert, Uebergabe an Kollegen fuer Logik-Review vorgesehen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Yuelin WangandClaude Sonnet 5
|
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> |
||
|
Yuelin WangandClaude Sonnet 5
|
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> |
||
|
Samer AyadiandClaude Opus 5
|
2dd5382060 |
[FEAT] Weitere Objekte der Anlage in hundm05.json bauen (Kreisel)
tests/testdata/hundm05.json enthaelt jetzt neben den 5 Spec-Ketten auch andere Objekte der Anlage - erkennbar am Feld "function", im Format der jeweiligen Einzel-Testdaten (ein Kreisel also wie in kreisel_tests.json). Damit beschreibt EINE Datei die ganze Anlage. - tests/test_hundm05.lsp: hundm05:bau-zusatzobjekte sammelt alle Objekte mit "function" und baut sie; hundm05:bau-kreisel ruft kreisel-insert-script (wie tests/test_kreisel.lsp) und liefert einen Ergebnis-Record in derselben Form wie die Ketten. Eigener ssg-start-Rahmen mit ATTREQ/ATTDIA 0, weil vsp-bau-datei seinen schon geschlossen hat und (command "_.INSERT" ...) sonst nach Attributwerten fragt. Je Objekt gefangen, damit ein Fehler die restlichen nicht mitnimmt. - Lisp/vf_spec.lsp: "kind" ist jetzt ein Record-Feld (Default "linienzug") statt eines Literals in vsp-result-json - so schreibt vsp-results-schreiben beide Objektarten in EINE Ergebnisdatei. - lib/vf_spec_export.py: Objekte der Ziel-Datei, die keine Kette beschreiben, werden beim Neuschreiben unveraendert ans Dateiende uebernommen. Ohne das waere jeder von Hand ergaenzte Eintrag beim naechsten Generatorlauf weg - die Datei ist erzeugt UND handgepflegt. spec_aus_flachen_objekten ueberspringt sie jetzt statt zu werfen, genau wie vsp-gruppieren in LISP. - tests/test_hundm05.py: die Ketten-Tests filtern auf kind "linienzug" (Records ohne das Feld stammen aus aelteren Laeufen und waren nur Ketten); neue Klasse TestZusatzobjekte prueft Status, expect_block_prefix, expect_hoehe (Attribut HOEHE), expect_kreiselart (KREISELART) und den Einfuegepunkt - dieselben Erwartungsfelder wie tests/test_kreisel.py. - tests/test_vf_spec.py: neuer Test, dass die Zusatzobjekte die Ketten-Zerlegung nicht beeinflussen - auch nicht, wenn sie mitten zwischen den Sektionen stehen (der eingetragene Kreisel stand zunaechst inmitten der Sub-Knoten von Kette 5; nach dem Regenerieren steht er am Dateiende). Verifiziert: 118 pytest-Tests gruen, Spec-Regenerierung uebernimmt das Zusatzobjekt (58 Objekte), beide .lsp lint-sauber. Die Kreisel-Tests warten auf den naechsten TEST_HUNDM05-Lauf. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Samer AyadiandClaude Opus 5
|
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> |
||
|
Samer AyadiandClaude Opus 5
|
5902343352 |
[CHANGE] Nur noch EIN Test baut die HundM-Geometrie: Spec wird TEST_HUNDM05
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> |
||
|
Samer AyadiandClaude Opus 5
|
428f1ced70 |
[FEAT] VF-Linienzug aus Eingabedaten bauen (Stufe 1: Spec -> Journal -> Replay)
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
|