Fehler/Warnungen als zwei einfache Listen (neue_meldungen,
meldungen_als_dict) statt der aus kabellaengen kopierten
ErrorCollector-Klasse; lib/error_collector.py entfernt. Format der
Fehlerdatei unveraendert, an sechs Testzeichnungen gegen das Original
verglichen (identische Nummern und Fehlerdateien).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Symbole erzeugen (HW_SYMBOLE, Einzelbefehle HW_SYM_*): Bauteile nach
cfg/io_regeln.json (reduzierte Kopie aus kabellaengen), Symbole aus
cfg/hw_symbole.json katalog-identisch nachgebaut (lib/hw_symbole.py),
REALE_POSITION mit x auf dem Bauteil, Paare uebereinander, Ausweichen
in y ohne Ueberlappung
- Symbole nummerieren (HW_NUMMERIEREN): lib/create_numbers.py samt
error_collector.py und cfg/enumerate.cfg aus kabellaengen uebernommen
- Ausgabeziel per Dialog dcl/hw_ausgabe.dcl: aktuelle Zeichnung,
bestehende Datei ergaenzen oder neue Datei
- Materialfluss mit XDATA SSG_HW_MF, ergaenzt vorhandene Datei
- Doku doc/hw_planung.md
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Zwei TODO-Punkte aus doc/todo.md entfernt - beide nicht, weil die Arbeit
getan waere, sondern weil ihr Anlass entfallen ist. Abschnitt 1 der Liste
schrumpft damit von drei auf einen Punkt.
**Stufe-2-Funktionstrennung** (doc/todo/linienzug-ohne-gui.md):
zurueckgestellt. Sie sollte den Journal-Replay-Umweg ueberfluessig machen -
nur ist der keiner mehr: ein Linienzug-Journal traegt mit SEGS die komplette
Segment-Essenz und laeuft ohne Zeichnung, worauf schon die Streichung des
Spec-Uebersetzers beruhte (4a19ac0). Die Modus-2-Regressionstests fahren
genau diesen Pfad. Dem gegenueber stehen die offenen Schritte 5c/6/8/9/10,
die den Code anfassen, in dem die Reihenfolge selbst Geometrie ist (geklammerte
dL-Kette, vfl-acc-*-Reihenfolge, lazy gelesene AS/ES-Winkel) - hoher Einsatz,
kein Funktionsgewinn. Die Datei nennt jetzt drei konkrete Bedingungen fuer
eine Wiederaufnahme.
**Spec-Uebersetzer Modus 2/3** (doc/todo/spec-modus2-3.md): abgeschlossen.
Die Schritt-Tabelle war veraltet - sie fuehrte alle sieben Schritte als
offen, obwohl der Kopf der Datei das Gegenteil sagte; jetzt steht je Schritt
erledigt / gestrichen.
Offen war dort zuletzt NICHT "ein Test fuer Modus 3", sondern dessen
Segment-Klassifizierung: sie vergleicht roh gegen Menue-Ziffern "1".."4" und
schreibt sie genauso ins Journal (Marker linienzug3). Wer die Optionen
umsortiert, ergaenzt oder entfernt, deutet damit jede gespeicherte Kette
still um - real passiert beim Lauf-Anfang (833a4b6). Modus 2 ist davon
befreit (selbstbeschreibende Werte + Alt-Tabelle ueber vfl-wert-norm); Modus
3 nicht, weil ohne aufgezeichnetes Journal der Beweis fehlt, dass
Bestandsketten die Umstellung ueberstehen.
Nutzer-Entscheidung 2026-10-29: fuer Modus 3 vorerst kein Testfall, bei
Problemen im Einsatz wird getestet und korrigiert. Das Risiko bleibt damit
bestehen - und wandert dorthin, wo es gefaehrlich wird: als Warnblock direkt
ueber der Segment-Auswahl in vf_linienzug.lsp, statt in eine TODO-Datei, die
beim Umsortieren einer Option niemand aufschlaegt. Er nennt auch den Ausweg:
Journal mit lib/vf_journal_export.py aus der Zeichnung ziehen, dann ist die
Umstellung derselbe Handgriff wie bei Modus 2.
Beide Fahrplaene bleiben liegen - spec-modus2-3.md ist aus
lib/vf_journal_export.py an drei Stellen referenziert, eine davon landet im
Beschreibungstext frisch exportierter Testdaten.
Am LISP-Code ist ausschliesslich Kommentar geaendert. TEST_UNIT 897/897.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gefaltete VF-Laeufe wurden zu kurz gebaut, weil der Solver Posten dem
falschen Schenkel zurechnete. Vier Aenderungen, alle nach demselben
Leitsatz: die letzten freien Groessen folgen der GEMESSENEN Ist-Lage,
nicht einer vorab verteilten Gesamtplanung.
1. vfl-zsolve-schluss-ziel (neu): endet der Lauf auf einem flachen
Fueller, werden RICHTUNG und LAENGE gemeinsam gegen den Zielpunkt
geloest statt nur die Laenge. Geschlossene Loesung ueber
A = sqrt(|D|^2 - P^2), hz = Winkel(D) - atan2(P, A); C und P sind
von hz unabhaengig, daher ohne Iteration. Bisher uebernahm der
Solve die Richtung aus dem gezeichneten Pfad - ein Querversatz der
realen Eck-Bauteile war damit prinzipiell unerreichbar, weil eine
Laenge die Kette nur entlang ihrer Achse verschiebt.
2. Eingangs-Hardware bei gefaltetem Lauf: Umlenkstation + Separator
stehen auf dem Eingangs-Schenkel und verbrauchen die Kletterspanne
nicht; ihr Laengenanteil wird der Spanne wieder zugeschlagen.
feste-vf bleibt unveraendert - sein sin3-Hoehenanteil ist real.
3. kletter-ende-fp: endet der Lauf auf einem KLETTERER, gibt es keinen
Schluss-Fueller, der Motorstation + Separator + ES abzieht - sie
standen in keinem Budget. Nur bei flacher Zone, Pfadende und
vorhandenem ES, sonst sind sie bereits anderweitig verbucht.
4. Nachrechner wieder aktiv (8 statt 4 Runden): GF1 steht im Budget,
aber im Eingangs-Schenkel. Die Kollision mit filler-A-len, wegen
der er abgeschaltet war, ist entfallen.
3 und 4 wirken NUR gemeinsam - die Betraege heben sich teilweise auf,
eine einzeln eingebaute Korrektur verschiebt den Fehler bloss in die
andere Richtung (GF1 1636.9 - (Motor+Sep+ES) 1235.1 = 401.8 mm).
Gemessen am selben Pfad: 9 Grad 0.56 mm, 12 Grad 0.7 mm quer (vorher
1424 bzw. 934 mm), dZ 0.1 mm. Beide Modus-2-Regressionsketten weiter
OK; TEST_UNIT 904/904 mit 7 neuen file-freien Tests.
doc/todo.md: Punkt "Modus-2-Solver: achsenweise Laengen-Bilanz" ist
damit erledigt. Die Detaildatei bleibt liegen, weil vier Kommentare in
vf_linienzug.lsp auf ihren Pfad verweisen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier Eintraege geprueft, drei davon betroffen:
- Spec-Uebersetzer Modus 2/3: Entscheidung dokumentiert, dass die Spec dort
NICHT gebaut wird (SEGS macht die Journale selbst-enthalten), welche drei
Schritte stattdessen umgesetzt wurden und warum die uebrigen gestrichen
sind. Offen bleibt nur dasselbe fuer Modus 3 - dort fehlt ein
aufgezeichnetes Journal als Netz.
- Achsenweise Laengen-Bilanz: teilweise entschaerft. AS-Element,
Abschlussbogen+Motorstation und die Eck-Differenzen gehen seit ce4ad0f an
das Segment, auf dem sie stehen - vfl-eck-extra ist bereits die hier
geforderte Form (Zuschlag je Segment statt Skalar). SKALAR geblieben sind
feste-vf und gf-total, und genau die verursachen den U-Form-Fehler; das
Symptom bleibt also bestehen. Mit Hinweis, dass die neuen
Zuschlags-Meldungen der schnellste Einstieg in die Diagnose sind.
- Linienzug ohne GUI, Schritt 11: war zurueckgestellt, bis echte
Modus-2-Journale als Referenz vorliegen. Diese Vorbedingung ist erfuellt;
der Schritt selbst bleibt offen.
Unveraendert: Stufe-3-Winkelwahl "Ab"-Zweig - von dieser Arbeit nicht
beruehrt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
doc/VarioFoerderer_Linienzug_Prinzipien.md war in ce4ad0f versehentlich
mit eingecheckt worden. Auf Wunsch des Autors bleibt es eine lokale
Arbeitsdatei - die Datei selbst ist unveraendert vorhanden, nur nicht
mehr getrackt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Leitsatz, aus dem alle Einzelaenderungen folgen (neu als Abschnitt 0 in
doc/VarioFoerderer_Linienzug_Prinzipien.md): die gezeichneten GERADEN
besitzen den Pfad, ein gezeichneter Bogen ist Hilfsgeometrie und nennt nur
Ort und Drehsinn. Jedes fest gebaute Teil zieht seine Laenge von dem
Segment ab, auf dem es steht - und zwar in LAENGEN- UND HOEHENbilanz mit
demselben, GEMESSENEN Wert.
Behoben:
- AS-Element: Fussabdruck wurde bei vf-start = 0 gar nicht abgezogen
(die Trimmung lief nur im Front-Lauf, der dort leer ist). Jetzt gemessen
aus dem gebauten KS_AUS - ein aus dem Block-dx gerechneter Wert lag
184 mm daneben.
- Abschlussbogen + Motorstation: standen auf dem letzten Segment des
VF-Laufs, fehlten aber im Budget (feste-vf traegt den Motor nur im Zweig
OHNE flache Zone).
- ES-Element: die letzte Gerade reservierte nur den Laengsanteil. Jetzt die
Strecke, die auch den Querversatz aufhebt (vfl-es-achs-reserve) - Vorgabe:
quer zur KS_AUS-Achse MUSS 0 sein, laengs darf abweichen, dZ MUSS 0 sein.
- ES-Abzug griff auch, wenn ein Back-Lauf zwischen VF-Lauf und ES liegt,
und verkuerzte dann das falsche Segment um die volle ES-Laenge (878 mm).
Jetzt nur noch bei direktem Anschluss (vf-ende = n-1).
- Eck-Bauteile: Vario-Kurve/Gefaellebogen ersetzen den gezeichneten Bogen
mit eigenem Fussabdruck. Die Differenz der Tangentenabstaende geht als
Zuschlag an beide angrenzenden Geraden (vfl-eck-korrekturen/-zerlegen),
damit die Mittellinie beide beruehrt. Der gezeichnete Radius kuerzt sich
dabei heraus. GF-Boegen werden geneigt eingebaut - ihr Grundriss-
Fussabdruck wird mit vfl-projiziere-neigung projiziert.
- Kletterlaenge wurde anteilig mit der Planlaenge im Zaehler und dem
korrigierten climber-span im Nenner verteilt; die Anteile summierten sich
dadurch auf weniger als 1.
- Absturz bei fehlendem Uebergangsbogen: get-bogen-mass wurde zweimal fuer
dieselbe Suche aufgerufen und sein nil ungeprueft an
vfl-projiziere-neigung gereicht.
Messreihe ueber die Sitzung (gleicher Pfad, Abweichung quer):
695.7 -> 270 -> 139.5 -> 98.5 -> 45.7 -> 2.4 -> 0.2 mm, dZ durchgehend 0.
Beide Pfad-Varianten (Ecke als Vario-Kurve bzw. als GF-Bogen) landen auf
demselben Wert - 0.2 mm ist die Messaufloesung, kein Restfehler.
21 neue file-freie Unit-Tests mit den echten Messwerten; TEST_UNIT 866/866.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nach vla-saveas ist die Zeichnung benannt, export:dwg-praefix setzt
"<name>_tests_" selbst davor - SSG_RUN_ALL_TESTS hatte ihn schon im
Namen. Ergebnis war "<name>_tests_<name>_tests_export.csv" fuer
foerderer/linienzug/gefaellestrecke, das Warten lief ins Timeout und
die Python-Pruefungen (test_foerderer/test_gefaellestrecke) wurden
mangels Datei still uebersprungen. testrun:ohne-praefix zieht den
Praefix vor dem Umbiegen der Dateinamen ab (DXF-Tests unveraendert).
doc/todo.md: erledigten Eintrag "Statisches Inventar veraltet" entfernt
(test_vf_headless_statisch.py ist seit 0babf78 gruen).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- vfl-konvertiere-ent laeuft unter *vfl-headless* (Wizard/GUI aus): reicht
ein Journal nicht, Abbruch mit Fundstelle statt Live-Rueckfrage im Batch
- alter VF_n-Block wird erst nach erfolgreichem Neubau geloescht; bei
Fehlschlag raeumt vfl-konvert-aufraeumen die Teil-Geometrie weg
- SSG_DIM_ALL_2D/_3D listet fehlgeschlagene Bloecke am Ende auf und
konvertiert jetzt auch Modus-3-Bloecke (linienzug3 wurde uebersprungen)
- statischer Headless-Test: vfl-menu-strwert/vflw-radio-wahl-impl erlaubt
- TODO: Stufe 2 und Spec-Uebersetzer Modus 2/3 in eigene Dateien ausgelagert
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- doc/todo.md sammelt alle offenen Punkte (VF/Linienzug, Export, Geruest,
Omniflo, ILS, Tests, spaetere Meilensteine); detaillierte Fahrplaene in
doc/todo/*.md und cfg/sivas_merkmal_zuordnung.md nur kurz verlinkt
- CLAUDE.md: Konvention "Woechentliche Doku- und TODO-Pruefung (freitags)"
- CLAUDE.md/README.md verweisen auf doc/todo.md
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- dcl/stueckliste.dcl: wurde von keinem Code geladen (ssg-sl-dialog existiert nicht)
- bin/create_tests.bat: rief das nicht mehr vorhandene tests/ILS_test.scr auf;
Ersatz ist run_tests.bat bzw. SSG_RUN_ALL_TESTS
- Kommentare in lib/ und tests/ verweisen statt auf das geloeschte
tests/testdata/object_data.md auf doc/json-input-lisp.md, mit den dort
gueltigen Abschnittsnummern (alt 5 -> 2, 3.1 -> 3, 2.1 -> 4.1, 8 -> 6)
- CLAUDE.md / doc/kommandos.md / doc/json-input-lisp.md nachgezogen
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
WARUM MODUS 3 BLEIBT
Modus 2 und 3 arbeiten beide auf einem gezeichneten Pfad (LINE/ARC), aber sie
loesen verschiedene Aufgaben:
Modus 2 = Randwertproblem - Start UND Ziel (je X/Y/Z) sind bekannt, die
Zwischenhoehen werden gerechnet, die Zielhoehe wird exakt
getroffen.
Modus 3 = Anfangswertproblem - die Kette wird mit vorgegebenen Winkeln
vorwaerts durchgebaut, die Endhoehe ist das ERGEBNIS.
Modus 3 kann damit etwas, was Modus 2 grundsaetzlich nicht kann: ohne
vorgegebene Zielhoehe arbeiten ("folge dieser Linie mit 3 Grad und lass uns
sehen, wo wir landen") - und er hat keinen Solver, der scheitern kann.
Dazu kommt ein harter Bestandsgrund: Modus 3 schreibt ein eigenes Journal
(Marker "linienzug3") und ist per Doppelklick editierbar. Faellt der Code
weg, verlieren alle bereits damit gebauten Ketten ihren Editier-Pfad.
Der Stempel "Legacy / wird umgebaut" war ueberholt und ist raus.
MODUS 3 - DREI AENDERUNGEN (Nutzer-Vorgabe 2026-10-22)
1. "AS bauen?" und 2. "ES bauen?" sind jetzt abfragbar (vorher wurden beide
immer gebaut), zusammen mit Winkel und Seite in je EINEM Dialog - dasselbe
Muster, das Modus 2 schon nutzt (vflw-gruppe-as-impl), kein neuer Code.
Ohne AS beginnt die Kette direkt am Startpunkt (flacher Rahmen statt
Block); die Fussabdruck-Trimmung der ersten Geraden rechnet dann von
selbst 0, weil Rahmen und Startpunkt zusammenfallen.
3. Die ES-Frage steht jetzt VOR dem Bau. Das behebt einen echten Fehler: die
letzte Gerade wird um "Separator + ein-dx" gekuerzt, ein-dx wurde aber
gelesen, BEVOR es gesetzt war - beim ersten Lauf griff der Schaetzwert
*vfk-as-es-fallback-dx*, bei jedem weiteren stand dort der Wert der
VORHERIGEN Kette (falscher Winkel, falsche Seite). Jetzt traegt die
Trimmung den echten Fussabdruck der gewaehlten ES-Variante; ohne ES
entfaellt sie ganz.
ABWAERTSKOMPATIBILITAET
Das Verschieben der ES-Frage aendert die Journal-Reihenfolge. Bestehende
"linienzug3"-Ketten bleiben per Doppelklick nachbaubar: alt-journal erkennt
sie am WERT des ersten Antwort-Eintrags ("30"/"90" = alt, "1"/"2" = neu, die
Mengen sind disjunkt) und spielt sie in der alten Reihenfolge ab. Dafuer der
neue Helfer vfl-replay-peek-wert neben vfl-replay-peek-art.
DIALOG vflw_as
Die Seitenauswahl wurde bei 30 Grad ausgegraut und NICHT in die Pending-Queue
gelegt - eine reine Modus-1-Regel (dort ersetzte die Zufuehrungsachse die
Seitenfrage). Modus 1 hat seit 2026-10-21 seinen eigenen Dialog; uebrig
blieben ES-Element sowie Modus 2/3, wo die Seite IMMER gebraucht wird - dort
ging bei 30 Grad ein zweites Fenster nur fuer die Seite auf. Entfernt.
NAMENSSCHEMA (faellt in denselben Commit, weil dieselbe Datei)
Die Helfer-Praefixe vfl2-/vfl3- stammten aus einer Planungsphase vor der
endgueltigen Menue-Zuordnung und waren dazu VERTAUSCHT: alle vfl3-* gehoeren
zu Modus 2, die vfl2-* zu Modus 3 - und drei davon zu BEIDEN. Eine
Modus-Nummer war fuer diese drei also gar nicht richtig vergebbar. Sie heissen
jetzt nach ihrer Rolle: vfl-zsolve-* (rechnet die Hoehen durch, nur Modus 2)
und vfl-pfad-* (arbeitet am gezeichneten Pfad, Modus 2 UND 3). 18 Funktionen,
jede Aufrufstelle maschinell gegen die Definitionen geprueft. Die falsche
Block-Ueberschrift "MODUS 3: Pfad + Ziel-Hoehe" (gemeint war Modus 2) ist
korrigiert, beide Gruppen haben jetzt einen erklaerenden Kopf.
vfl-zsolve-bruecke (frueher vfl3-solve-bruecke) wird von niemandem aufgerufen
- bewusst stehen gelassen und markiert, Loeschen gehoert in ein
Tote-Code-Review.
MENUE
Die Modi heissen jetzt nach ihrem Unterschied statt nach der Bedienung:
"aus 3D Linie mit Zielhoehe" / "aus 3D Linie ohne Zielhoehe" (vorher
"3D Objekte stueckweise (in Arbeit)").
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die AS-Praeambel in Modus 1 fragt jetzt Winkel, Seite UND eine optionale
Zufuehrungsachse (2. Punkt) - im Assistenten alles in einem Fenster
(vflw_as_achse). Beide Angaben zusammen legen das AS vollstaendig fest: der
2. Punkt gibt die KS_EIN-Achse (Zufuehrung/Fahrtrichtung), links/rechts die
AS-Variante und damit die KS_AUS-Richtung der Kette. Bisher galt die Achse
nur beim 30-Grad-Element und ERSETZTE dort die Seitenfrage.
Darauf setzt die neue 5. Option der gf-laenge-modus-Frage auf, intern
"parallel" (vfl-gf-parallel-kreisel): AS -> GF-Stueck -> GF-Bogen aus EINEM
Abstandswert, gemessen senkrecht zur Zufuehrungsachse von AS-KS_EIN bis
Bogen-KS_AUS. Kein Separator dazwischen, damit der Abstand exakt getroffen
wird; die Kettenende-Frage stellt der Zweig selbst NACH dem Bau. Waehlbar
nur am Kettenanfang mit AS UND Achse.
Der Bogen ist nicht verdrahtet: gewaehlt wird der, der den gemessenen
Grundriss-Schwenk des AS-Blocks aufhebt (vf-element-plan-turn) - mit den
vorhandenen Bausteinen AS 30 -> 30-Grad-Bogen, AS 90 -> 90-Grad-Bogen,
immer zur Gegenseite. Querversatz von AS und Bogen wird gemessen statt
gerechnet; die Bogen-Probe laeuft dabei auf dem IDEALISIERTEN 3-Grad-Rahmen,
auf dem der echte Bogen spaeter sitzt (auf dem AS-Rahmen gemessen lag der
Abstand im BricsCAD-Test um 0.5 mm daneben).
Journal: [STR winkel][STR seite][PT p2 | NIL]. Welche Fragen gestellt wurden,
wird nicht journalisiert, sondern beim Replay an der Eintragsart erkannt -
alte Ketten bleiben ohne Sonderbehandlung editierbar. Die Journal-Werkzeuge
(vf_linienzug_grammatik.py, vf_spec_export.py, vf_journal_export.py,
vf_spec.lsp, test_hm_recformat.lsp) kennen das optionale Achsen-Token.
Tests: 11 neue Unit-Tests fuer die reinen Kerne vfl-par-bogen-waehlen und
vfl-par-gf-laenge (tu-tests-vfl-parallel), TEST_UNIT 701/701 gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bisher brach GEFAELLESTRECKE_EDIT bei jeder Streckengruppe (TYP "Streckengruppe", d.h. mit mindestens einem Bogen) mit "Nur einfache Gefaellestrecken..." ab - Grund war nicht fehlende Technik, sondern dass gf-linienzug-modus schlicht keine Edit-XDATA schrieb (anders als Modus 1/2 ueber SSG_GF_EDIT).
Neue XDATA-App SSG_GF_LZ (gf-lz-xdata-schreiben/-lesen in Lisp/Gefaellestrecke.lsp) sichert die Segmentliste (Typ/hz/Laenge/Winkel/Seite je Segment, bereits laengenfertig) + den Baustartpunkt - Serialisierung per gf-segmente->string/gf-string->segmente, Chunking ueber die bestehenden ssg-sepliste-chunk-string/-split-feld/-explode-chars-Helfer aus ssg_ks_insert.lsp (wiederverwendet statt dupliziert).
Neue Funktion gf-linienzug-rebuild: baut die Kette am selben Startpunkt neu, AS-/EIN-Element und Gefaellewinkel bleiben ueber dieselben zwei Dialoge wie beim Bauen editierbar (gf-dialog-linienzug-aus-ein/-winkel, jetzt mit prefill-Parameter fuer den Edit-Fall statt Defaults) - die Segmentlaengen/-form selbst nicht (dafuer bleibt GEFAELLESTRECKE_LINIENZUG als Neubau). c:GEFAELLESTRECKE_EDIT dispatcht vor der bisherigen TYP-Sperre: Streckengruppe MIT SSG_GF_LZ-XDATA -> neuer Rebuild-Pfad, Streckengruppe OHNE (Altbestand/VF-Kombi) -> bleibt wie bisher abgewiesen. Alter Block wird erst NACH erfolgreichem Neuaufbau geloescht.
doc/variofoerderer.md um den Edit-Ablauf ergaenzt.
Manuell in BricsCAD getestet (Doppelklick auf Linienzug-Streckengruppe, beide Dialoge vorbelegt, Neuaufbau, erneuter Doppelklick auf das Ergebnis) - laeuft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Zwei neue Dialoge (dcl/gefaellestrecke.dcl, Lisp/Gefaellestrecke.lsp):
- gf-dialog-linienzug-aus-ein: AUS-/EIN-Element Winkel+Seite in EINEM Dialog, ersetzt die vier fruehen Konsolenfragen. Muss vor der Segmentlaengen-/Winkelberechnung laufen (haengt von AS-/ES-Masse ab), darum eigener, fruehzeitiger Dialog.
- gf-dialog-linienzug-winkel: zeigt den automatisch aus der Segmentkette berechneten Gefaellewinkel-Vorschlag ueberschreibbar, mit kurzer Segment-Zusammenfassung und dem bereits gewaehlten AS/ES-Paar nur noch zur Kontrolle (disabled). Ersetzt zugleich die SPAETERE finale Einfuegen-Bestaetigung - nach der rein automatischen AS/ES-Korrekturschleife waere eine zweite Rueckfrage redundant.
Objektauswahl (ssget LINE/ARC) und Start-/Endpunktwahl bleiben bewusst Zeichnung/Konsole. Rueckfall auf die alten Konsolenfragen bleibt erhalten, wenn ein Dialog nicht gezeigt werden kann/darf (GUI aus); ein bewusster Dialog-Abbruch bricht dagegen den ganzen Befehl ab statt auf Konsole zurueckzufallen - neu im Vergleich zum alten Verhalten, aber konsistent mit vfc_eingabemodus/vfs_nachruesten_hz aus Teil A/C.
doc/variofoerderer.md (Abschnitt 4) aktualisiert und um einen bebilderten Beispiel-Walkthrough ergaenzt (gf-linienzug1-3.png: Ausgangslinie, Dialog mit Vorschlagswinkel, fertige Strecke neben der Original-Linie).
Manuell in BricsCAD getestet (vollstaendiger Lauf inkl. Abbruch in beiden Dialogen) - laeuft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer Dialog vfs_nachruesten_hz (dcl/variofoerderer.dcl) + vfs-dialog-nachruesten-hz (Lisp/vf_standard.lsp) ersetzt den fruehren getreal-Prompt. Zeigt pro unmarkiertem VF_n-Fund Blockname/erkannten Typ und ein hz-Feld, vorbelegt mit dem zuletzt eingegebenen Wert (identisches Default-Fortpflanzungs-Verhalten wie vorher).
"Abbrechen" im Dialog uebernimmt bewusst nur den Vorgabewert fuer DIESEN Fund (Rueckgabe 'ABBRUCH), statt die ganze Nachruesten-Schleife abzubrechen oder auf die Konsole zurueckzufallen - echter Konsolen-Rueckfall bleibt ausschliesslich fuer den Fall, dass der Dialog gar nicht gezeigt werden kann (GUI abgeschaltet). Die Objektauswahl (ssget) selbst bleibt unveraendert Zeichnung/Konsole.
doc/variofoerderer.md um den Befehl ergaenzt (war dort bisher gar nicht erwaehnt).
Manuell in BricsCAD getestet (unmarkierter VF_4-Block, Dialog erscheint, hz=0 markiert) - laeuft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer Dialog vfc_eingabemodus (dcl/variofoerderer.dcl) + vfc-dialog-eingabemodus-waehlen (Lisp/vf_core.lsp), analog zum bestehenden vfc_typ-Muster: Radio-Buttons "3D-Linie auswaehlen" / "Werte manuell eingeben" ersetzen die fruehere getstring-Konsolenabfrage in vf-dialog-ablauf. Betrifft StandardVarioFoerderer3D und EtageVarioFoerderer3D (beide rufen denselben Ablauf).
Die 3D-Linie-Objektauswahl selbst (vfc-3dlinie-erfassen) bleibt bewusst Zeichnung/Konsole - eine Linie laesst sich nicht durch ein Formularfeld ersetzen. Alle daraus abgeleiteten Werte (deltaL/deltaH/hz/Einfuegehoehe) gehen als Prefill in den bereits bestehenden Basis-Dialog (variofoerderer_basis), der sie ueberschreibbar anzeigt - identisch zum "Werte manuell"-Pfad.
Rueckfall auf die alte Konsolenabfrage bleibt erhalten (GUI abgeschaltet, DXFM_LANG=en_GB), wie bei vfc_typ. doc/variofoerderer.md (Abschnitt 2, 8, Entscheidungsbaum) und CLAUDE.md entsprechend aktualisiert.
Manuell in BricsCAD getestet (StandardVarioFoerderer3D + EtageVarioFoerderer3D, beide Dialogzweige inkl. Abbruch) - laeuft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
tests/testdata/linienzug_tests_stufe2.json hat sich seit Erstellung des Dokuments geaendert (62 statt 57 Eingabe-Eintraege, zusaetzliche Separator-Vor/Nach-Fragen, Kettenende-Frage vor statt nach der Gefaelle-Berechnung). Fragen-Tabelle in Abschnitt 3 komplett neu durchnummeriert und mit den tatsaechlichen JSON-Kommentaren abgeglichen.
Stufe-2-Ergebnis war veraltet: GF2=86mm/VF=286mm ersetzt durch die tatsaechlichen GF2=319mm/L_VF=48mm aus der Datei; Hoehenrest-Beispielrechnung in Abschnitt 5.a entsprechend angepasst.
Fehlerhafter Fakt in Abschnitt 5.c korrigiert: linienzug_tests.json hat ebenfalls erwartung_dx_mm=638 (nicht dY=637 wie behauptet) - beide Testfaelle zeigen denselben dX-Versatz.
Code-Fakten verifiziert und unveraendert korrekt: Winkeltabelle 3/6/9/12/15/18/21/27/33/39/45/51 Grad (data/json/component_defaults.json), *vfk-feste-horizontal-kettenende*=800mm, *vfl-gf-min-laenge*=400mm, vfl-winkel-stufe-entscheidung/berechne-alle-winkel/berechne-horizontale-mitte/vfl-loesche-seit/vfl-modus-abbruch-sichern existieren alle weiterhin, TEST_LINIENZUG_STUFE2 liest weiterhin linienzug_tests_stufe2.json.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Datenbasis (data/json/omniflo_*.json) hat sich seit der letzten Doku-Pflege verschoben: Boegen 27->29, Delta 1->7, Sternweiche 1->2, Dreifachweiche 6->0 (Typ aktuell nicht mehr in den Daten vorhanden), Gesamt 107->110. Schalter/Filterkriterien selbst (SWITCH_FILTERS in lib/omniflo_utils.py) sind unveraendert und weiterhin korrekt dokumentiert.
set_koords-Aufruf im Dokument auf bin\set_coords.bat vereinheitlicht (war inkonsistent zu set_einfuegepunkt.bat, das korrekt den bin\-Wrapper nennt).
bin/set_coords.bat trug noch den Kopfkommentar von set_einfuegepunkt.bat (Copy-Paste-Fehler) - korrigiert auf den tatsaechlichen Zweck (K1-K4 setzen).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Drei neue bin/*.bat nach dem bestehenden Pass-Through-Muster (setenv.bat + python ... %*, siehe set_einfuegepunkt.bat/dbg2lsp.bat), damit diese lib/-Skripte wie die uebrigen Python-Kommandozeilen bequem ueber bin/ aufrufbar sind. doc/kommandos.md Abschnitt 3 ergaenzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
dxf_anlage_export.py und dxf_scan_components.py fuehrten dieselben Feldnamen (abstand, deltaL_mm, as_seite, ...) aus doc/json-input-lisp.md unabhaengig als lose String-Literale - ein Tippfehler oder eine Schema-Aenderung in nur einer Datei waere nicht aufgefallen. Neues Modul lib/testdata_schema.py buendelt die Feldnamen/festen Werte der dokumentierten Schemas (Kreisel, Einzelblock, VF Standard/Etage, Gefaellestrecke Modus 1) als benannte Konstanten; dxf_anlage_export.py nutzt sie jetzt durchgaengig.
dxf_scan_components.py bewusst NICHT mitumgebaut: deutlich grösser/komplexer, mit zusaetzlichen Sonderfaellen (z.B. "startpunkt"/"gerade"-Form), ein vollstaendiger Umbau haette den Rahmen dieser Aenderung gesprengt und mehr Risiko als Nutzen gehabt.
Verhaltensgleich: alle 9 Tests in tests/test_dxf_anlage_export.py laufen weiterhin gruen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
kommandos.md: lib/dxf_anlage_export.py fehlte in der Python-Kommandozeilen-Liste.
faq.md: FAQ-Eintrag fuer QcLinieMitGf/QcLinieMitGfUForm ergaenzt (bisher nur stichwortartig in der Gefaellestrecke-Liste erwaehnt, nirgends erklaert).
json-input-lisp.md: tests/testdata/showroom_ils.json fehlte in der Testdaten-Uebersicht (Abschnitt 9), obwohl TEST_SHOWROOM_ILS dokumentiert ist.
Alle anderen Befehle/Dateien/Testdaten in den drei Dokumenten gegen den aktuellen Code-Stand geprueft und bestaetigt aktuell.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Die Linie wird weiterhin gepickt (vfc-3dlinie-erfassen, aus vf-eingabe-abfragen herausgezogen), liefert aber deltaL/deltaH/Richtung/Einfuegehoehe/Fahrtrichtung nur noch als Prefill fuer vfs-dialog-eingabe-basis - Seite/Motorseite/Darstellung/Geruest bleiben wie bisher ueber die GUI einstellbar. c:VarioFoerderer dispatcht Standard/Etage dadurch immer in vfs-standard-dialog-ablauf/vfe-etage-dialog-ablauf; der alte rein konsolenbasierte Fallback-Pfad (Schritte 3-11, vf-eingabe-abfragen) ist als toter Code entfernt. Dead-Code-Aufraeumung: 35 nur noch vom entfernten Pfad genutzte Sprachschluessel aus lang/de_DE.json + lang/en_GB.json entfernt (Paritaet geprueft).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
[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>
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>
Neue Module ssg_blocktools.lsp (SSG_BLOCK_COUNT, SSG_BLOCK_DELETE,
SSG_ATTR_ERSETZEN) und ssg_texttools.lsp (SSG_TEXT_ERSETZEN,
SSG_TEXT_PARALLEL, SSG_TEXT_HOEHE, SSG_TEXT_STIL) sowie der generische
Eingabe-Wrapper ssg_input.lsp, dazu Menue-/Lade-Integration,
zweisprachige Texte und Unit-Tests fuer die reinen Kerne.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- ZUORDNUNG: ssg-id-check-all laeuft jetzt ZUERST, danach sind die
Wrapper-IDs endgueltig - Separator-Kopien, AS/ES- und Einheiten-Marker
bekommen ZUORDNUNG direkt beim Erzeugen. Entfallen:
csv:sep-proxies-zuordnung-setzen, csv:asmark-ids-setzen,
csv:unitmark-ids-setzen. zuordnung_fix/*cs-sep-fix-by-handle* bleibt
(count_sep_scan rechnet eigenstaendige Sensoren bewusst neu).
- sepliste-IDs: Zuordnung ueber die KS-Kettenfolge je Typ
(csv:sepliste-kette-paare) statt ueber die teils gespiegelten
sepliste-Koordinaten (csv:sepliste-paare, csv:sepliste-ids-setzen
entfallen). Die Kette wird je Lauf einmal berechnet (csv:kette-von);
die ID liest csv:block-to-json erst beim Schreiben. Behebt vertauschte
TrackIds/Nachbarn in HundM05 VF_1 (0031/0029).
- Element-Klassifizierung: eine Tabelle csv:element-familien (cfg-Muster)
fuer Suche und Klassifizierung; csv:proxy-typ entfaellt.
- Einheiten-Marker: K1/K2 nur noch in *csv-baustein-by-handle*
(csv:geometrie-merken), K1/K2-Attribute und
csv:unitmark-k-kos-strings entfallen.
Geprueft: HundM05-Export alt/neu headless verglichen - einzige Abweichung
ist die korrigierte Reihenfolge in VF_1. LISP-Unit-Tests 303/303.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
AS/ES-Marker werden wie alle Hilfskopien geloescht (ausser csv_leave_proxies). IDs von AS/ES, Separator-Kopien und Einheiten bleiben ueber reservierte IDs (XDATA SSG_ID_RES) am VF_n/GF_n-Wrapper stabil: AS|n/ES|n, K|i, U|n.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
