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>
HW_MATERIALFLUSS ruft EXPORTCSV und lib/hw_materialfluss.py: Kreisel-Rechtecke
in Drehrichtung, Strecken AS -> Separatoren -> ES, Weichen, Be-/Entladungen.
HW_SYMBOLE vorerst Platzhalter.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Pruefskript io_zuordnung_pruefen, Konverter altZuNeu und das gemeinsame
Regelwerk cfg/io_regeln.json liegen in kabellaengen; dort werden die
dxfmakros-Mechanikbloecke erkannt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Hauptblock KF_n: flache, ungedrehte Seitenansicht mit Beschriftung und Hoehenmass; nur er wird exportiert
- Draufsicht KF_2D als getrennter Hilfsblock KF2D_n (projizierte Laenge, frei verschiebbar, per KF_EDIT regenerierbar), Verknuepfung ueber XDATA-Schluessel
- L_KF_mm = waagerechte Laenge, Sivas-Zeile ohne Laenge, Export nur KF_<Ziffern>
- ensure-block-loaded: Block ohne ILS-Datei (KF_2D) nicht mehr als fehlend melden
- Layer kettenfoerderer_beschriftung, Dispatcher-Zweig KF2D_*, Sprachdateien und Unit-Tests angepasst
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
KF_EDIT loescht beim Neuaufbau den alten Foerderer. kf-naechste-nummer zaehlte
nur die Referenzen im Modell und vergab dadurch dieselbe Nummer erneut, obwohl
die Block-Definition KF_<n> weiter in der Blocktabelle steht. _.-BLOCK traf auf
den vorhandenen Namen, die "Neu definieren?"-Abfrage verschluckte die
Folge-Eingaben, der Block entstand nicht und die Einzelteile blieben lose im
Modell liegen. GF_n und VF_n pruefen aus demselben Grund die Blocktabelle.
- kf-freie-nummer ueberspringt jede Nummer mit vorhandener Block-Definition
- kf-nummer-aus-name liest nur rein numerische Namen (KF_2D, KF_UM_26 und
KF_LAENGE tragen dasselbe Praefix, atoi("2D") waere 2)
- KF_EDIT nutzt zuerst die vorgewaehlte Auswahl (Doppelklick), entsel nur als
Rueckfall, und akzeptiert nur echte KF_<n>
- Unit-Tests fuer Namens-Parser und Nummernvergabe
- KF_2D.dwg: ueberarbeitete Draufsicht
Co-Authored-By: Claude Sonnet 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>
Drei neue Modus-2-Testfaelle aus echten Laeufen, ein Kriterium, das eine
heute eingebaute Fehlgeometrie gefunden haette, und ein aufgeraeumtes
Layout der Testketten.
1. Drei U-Form-Faelle (tests/testdata/linienzug_modus2_uform_*.json),
aufgezeichnet mit lib/vf_journal_export.py. Gefaltete Laeufe: der Pfad
wechselt ueber zwei 90-Grad-Vario-Kurven dreimal die Fahrtrichtung, die
Kletterstrecke liegt in einem ANDEREN Schenkel als der Lauf-Eingang -
genau der am 2026-10-29 korrigierte Fall. Variiert werden GF-Verteilung
(alles am Einlauf vs. 1/2+1/2) und Winkel; beides ist noetig, weil die
Verteilung entscheidet, ob ueberhaupt GF im fremden Schenkel steht, und
der Restfehler der alten Bilanz mit L_GF skalierte.
c:TEST_LINIENZUG_MODUS2 ist dafuer tabellengesteuert - ein weiterer Fall
ist jetzt eine Zeile in *tlz-m2-faelle*.
2. RUECKNAHME des Schluss-Solves (vfl-zsolve-schluss-ziel, heute frueh
eingebaut). Er loeste den letzten Fueller gegen Richtung UND Laenge und
traf den Zielpunkt dadurch in X und Y exakt - um den Preis, dass er die
letzte Gerade um 6.15 Grad verdrehte (hz-plan -90 -> -96.15), in der
Zeichnung als schiefer Schenkel sichtbar. Das widerspricht der
Entscheidung vom 2026-10-26: quer MUSS 0 sein, LAENGS DARF ABWEICHEN -
der Hauptstrang bleibt gerade, der seitliche Versatz des ES-Elements ist
dessen Bauform. Die Messwerte von heute (0.56 / 0.7 mm quer) stammen
nicht von dieser Aenderung, sondern von der Laengenbilanz des gefalteten
Laufs (35ebee1) - der Zweig blieb dort ungenutzt. Die Begruendung steht
jetzt an der Aufrufstelle, damit niemand den Solve erneut baut.
3. laengs wird geprueft - als FORM-, nicht als Genauigkeitskriterium
(erwartung_laengs_mm, Toleranz 5 mm). Der Wert ist die Ausladung des
ES-Elements und je Fall eine Konstante (104.68 bei ES_Element_30,
637.58 bei ES_Element_90). Punkt 2 war am Querwert NICHT erkennbar - die
Verdrehung macht ihn gerade null, der Test meldete OK, gefunden wurde sie
mit dem Auge. Ein verdrehter Hauptstrang zielt auf den Endpunkt und
drueckt laengs auf ~0; daran faellt er auf. Gegengeprueft: mit kuenstlich
auf 0.01 mm gesetzter Toleranz kippen alle fuenf Faelle auf ABWEICHUNG.
4. Alle sieben Ketten des Menueeintrags entstehen als Reihe auf Y=0, 20 m
Abstand, statt verstreut. Die Modus-1-Skripte brauchen dafuer nur ihren
EINEN point_abs (alles Weitere ist point_rel mit dL/hz); bei Modus 2
mussten PT-Eintraege UND die Pfadkoordinaten in SEGS (Felder 6..9)
mitwandern, sonst zeigt der Pfad woanders hin als Start und Ziel.
Reine Translation - Laengen, Winkel und die geprueften Abweichungen sind
davon unabhaengig; Z blieb stehen, weil die Starthoehe ein Eingabewert
des Solvers ist. Geprueft: erstes Segment beginnt exakt am Startpunkt,
letztes endet exakt am Zielpunkt, Messwerte unveraendert.
5. Die drei letzten Verweise auf doc/VarioFoerderer_Linienzug_Prinzipien.md
(bewusst unversioniert) tragen ihre Begruendung jetzt selbst: Entkopplung
Neigung/XY, warum es genau EINEN Kletterer je Lauf gibt, und warum ein
VF-Sub-Segment auf der 3-Grad-Basis beginnen und enden muss.
Geprueft: TEST_UNIT 897/897 (die 7 Tests der entfernten Funktion sind mit
ihr gegangen), TEST_LINIENZUG_MODUS2 5 von 5 OK, voller Menueablauf baut
sieben Ketten an den vorgesehenen Stellen.
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>
Nur Dateien, deren Abweichung gegenueber dem letzten Lauf erklaert und
unbedenklich ist (reine Attribut-/Merkmal-Erweiterung, Namenszaehler-Fix,
Kreisel-Hoehen-Neuberechnung, Zuordnungs-Logik aus fea6014) - siehe
Vergleichsprotokoll in der Session. Bewusst NICHT aktualisiert:
foerderer_results.json (unerklaerte ~1mm-Drift), mubea_* (VF_4-Etage-Solver-
Aenderung + Kreisel2-Drehrichtung brauchen fachliche Pruefung),
hundm05_attribute.json (braucht dxf_vf_abbild.py --schreibe-referenz statt
Kopie), kreisel_export.csv/kreisel_sivas.csv/kreisel_tests.dxf (kein
frischer Lauf in dieser Session).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Folgewerkzeuge (sps_skel: sepliste-Gegenprobe) erkennen daran, dass ein
Separator in TrackIds, aber zu Recht nicht im Bauprotokoll der Strecke
steht. CLAUDE.md beschreibt den neuen Export-Schritt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Eigenstaendige Separatoren, deren Zuordnung eine VF/GF nennt, die aber nicht
beim Bau der Strecke entstanden, fehlten in deren sepliste und damit in
TrackIds und Nachbarn (Mubea VF_3: 0037/0038). Sie werden jetzt beim Export
nach Lage zwischen AS und ES aufgenommen - nur im Speicher des Laufs, die
sepliste-XDATA bleibt Bauprotokoll (Lisp paart sie per Anzahl je Typ mit den
Bausteinen und fuehrt reservierte AS/ES-IDs unter der lfdnr).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Unterhalb des Kreisel-Durchmessers (*kreisel-durchmesser*, Default 800mm)
wuerden sich AN8/SP8 beruehren bzw. ueberschneiden. draw-module prueft das
als harte Sperre fuer alle Aufrufer; KreiselInsert/-Connect/-Redraw fragen
bei Unterschreitung erneut ab statt abzubrechen, KreiselEdit zeigt den
Dialog erneut (Projektmuster wie GERUEST).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
TEST_LINIENZUG (ebenso hmrec:stubs-aus und vsp-headless-aus) schaltete die
GUI am Ende pauschal wieder ein. Unter SSG_RUN_ALL_TESTS fragte der direkt
folgende EXPORTSIVAS dann nach Hoehen-Check/Bereinigen und der Lauf blieb
stehen. Alle drei stellen jetzt den Vorzustand von *ssg-gui-aus* wieder her.
SSG_RUN_ALL_TESTS schaltet zusaetzlich *csv-hoehencheck-fragen* und
*csv-bereinigen-vor-export* fuer den Lauf ab (unmittelbar vor jedem Export
erneut, export.lsp belegt nil beim Nachladen wieder mit T), erzwingt GUI aus
mit Warnung und stellt am Ende die Vorgaben wieder her.
Neues Laufprotokoll DXFM_LOG/testlauf_<name>.dbg je Test (Debug-Schalter
"testlauf", Standard ein): Zustand vor/nach dem Test, Fehler, Ergebnis-JSON,
Export-Schritte. Eigene Datei mit sofortigem Schreiben statt dbgopen, damit
die Module mit ihren eigenen .dbg-Dateien es nicht umlenken und bei einem
Haenger der letzte Schritt sichtbar ist.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
EXPORTSIVAS bereinigt die Zeichnung vorab per -PURGE (abschaltbar ueber
*csv-bereinigen-vor-export*). export_sivas.py schreibt zusaetzlich je
Dispogruppe eine Datei <stamm>_zusammengefasst_dispo<N>.csv.
Co-Authored-By: Claude Sonnet 5.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>
Drei herausgeloeste Teile aus doc/todo/spec-modus2-3.md. Der Rest (volle
Spec-Grammatik fuer Modus 2/3, Schritte 3-5 und 7) bleibt bewusst liegen:
Modus-2/3-Journale sind durch ihren SEGS-Eintrag bereits selbst-enthalten
und ohne Zeichnung abspielbar, der Mehrwert einer Spec ist dort also klein.
1. lib/vf_journal_export.py trennt nach Marker. Modus 1 laeuft wie bisher
durch die Grammatik; "linienzug2"/"linienzug3" werden als Rohtokens
ausgegeben, im Format, das tests/test_linienzug.lsp einliest. Vorher lief
die Modus-1-Grammatik auch ueber sie (der startswith-Filter laesst sie
durch) und brach mit "Token 6: STEP erwartet" ab. Gegen die echte
Zeichnung geprueft: die Ausgabe ist identisch mit der bisher von Hand
erzeugten Testdatei.
2. vsp-bau-journal waehlt die Bau-Funktion jetzt anhand des Journals
(vsp-bau-fn-fuer-journal): kein SEGS = Modus 1, SEGS + Formatmarke
"m2v2" = Modus 2, SEGS ohne = Modus 3. Bewusst abgeleitet statt als
zusaetzliches Argument - die Funktion hat zwei Aufrufer, und AutoLISP
verlangt exakte Argumentzahl. Die Ableitung kann der Datenlage auch nicht
widersprechen, weil sie genau das Journal liest, das abgespielt wird.
3. Die Segment-Klassifizierung in Modus 2 journalisiert WERTE statt
Menue-Ziffern: Geradentyp "gf"/"vf", Bogentyp "gf-bogen"/"vario-kurve",
Variante "aussen"/"innen". Konsole UND Wizard-Dialoge legen dieselben
Werte ab. Damit deutet ein Umsortieren der Optionen keine gespeicherte
Kette mehr um - dasselbe Risiko, das beim Lauf-Anfang (833a4b6) real
wurde. Bestandsketten laufen ueber Alt-Tabellen weiter, ein unbekannter
Wert bricht mit Segmentnummer ab statt zu raten.
Statt dreier fast gleicher Normalisierer gibt es einen gemeinsamen
vfl-wert-norm; vfl-m2-anfang-norm delegiert jetzt dorthin.
Nebeneffekt: Bogentyp und Variante benutzten BEIDE "1"/"2" und waren im
Journal nicht zu unterscheiden - deshalb brauchte es die Formatmarke zur
Erkennung von Alt-Journalen. Mit eigenen Wertevorraeten ist das erledigt;
ein Test prueft, dass die Mengen disjunkt bleiben.
Geprueft: TEST_UNIT 883/883 (17 neue Tests). TEST_LINIENZUG_MODUS2 beide
Varianten OK - und zwar mit den AUFGEZEICHNETEN Journalen, die bei den
Segment-Fragen noch die alten Ziffern tragen. Genau darum wurden sie nicht
auf die neuen Werte umgeschrieben: sie sind der Nachweis der
Abwaertskompatibilitaet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
doc/VarioFoerderer_Linienzug_Prinzipien.md ist bewusst nicht versioniert
(siehe ce00233). Die drei Stellen, die von dort die Begruendung geholt
haben, tragen sie jetzt selbst: warum quer und dZ null sein MUESSEN und
laengs abweichen DARF - naemlich weil beides zugleich geometrisch nicht
geht und der Hauptstrang gerade bleiben soll.
Ein Verweis auf eine Datei, die im Repo fehlt, kostet den naechsten Leser
mehr Zeit als die zwei Zeilen Text.
Nicht angefasst: die aelteren Verweise in vf_linienzug.lsp (Abschnitt 14,
14.1) und vf_standard.lsp - sie stammen nicht aus dieser Arbeit und
zeigen auf Inhalte, die hier niemand kennt.
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>
Neu: TEST_LINIENZUG_MODUS2 spielt zwei echte Laeufe DERSELBEN Strecke ab -
einmal mit der 90-Grad-Ecke als Vario-Kurve (waagerecht, mit flacher Zone),
einmal als GF-Bogen (geneigt, ohne flache Zone). Beide muessen quer zur
ES-KS_AUS-Achse ~0 und dZ ~0 erreichen; laengs darf um die Ausladung des
ES-Elements abweichen (Leitsatz, doc/VarioFoerderer_Linienzug_Prinzipien.md
Abschnitt 0). Gemessen am 2026-10-27: beide 0.2 mm quer, dZ 0.
Das Paar ist Absicht. Die beiden Varianten laufen durch VERSCHIEDENE Zweige,
und erst ihr Vergleich hat die Fehler dieser Woche sichtbar gemacht - der
ES-Fussabdruck wurde vom falschen Segment abgezogen, was sich nur in der
GF-Bogen-Variante zeigte (878 mm). Einen der beiden zu loeschen nimmt dem
Test seinen Wert.
Anders als die Modus-1-Faelle braucht Modus 2 KEINE Mocks und KEINEN
gezeichneten Pfad: sein Journal traegt einen SEGS-Eintrag mit der kompletten
Segment-Essenz, ist also von den Original-Objekten unabhaengig. Der Test
spielt daher das echte, mit lib/vf_journal_export.py aus der Zeichnung
gelesene Journal ab. Jeder Eintrag fuehrt seine Art mit (PT/STR/REAL/SEGS),
womit die Verschiebe-Anfaelligkeit des Mock-Replays entfaellt.
Dazu: vf-linienzug-modus2 legt die gemessene Abweichung in
*vfl-m2-abweichung* ab (laengs quer dz). Sonst muesste ein Test sie aus der
Konsolenausgabe zurueckparsen.
Ausserdem behoben: beide Modus-1-Testskripte brachen mit
"bad argument type <\"5\"> expected <CONS> at [cdr]" ab. Commit fb56794
(Rueckwaerts-Bau) hat eine Frage VOR die AS-Praeambel gesetzt. Fuer Journale
ist sie abwaertskompatibel, fuer die MOCK-Skripte nicht: der Mock beantwortet
jede getstring-Abfrage aus der Queue, eine fehlende Antwort verschiebt also
alles Folgende um eine Position. Beide Dateien haben den Eintrag jetzt, mit
Begruendung im Kommentar.
Menue: Tests -> Foerderer-Linienzug ruft den neuen Fall mit auf. Die
kompilierte SSG_LIB.cui ist bewusst NICHT mit committet - ihre Aenderung
besteht groesstenteils aus fremden Eintraegen und verschobenen UIDs;
BricsCAD erzeugt sie beim naechsten _MENULOAD neu aus der .mnu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die beiden Laeufe vom 2026-10-26 als dokumentierte Referenz: derselbe Pfad,
einmal mit Vario-Kurve und einmal mit GF-Bogen an der 90-Grad-Ecke. Beide
muessen quer ~0 und dZ 0 erreichen; laengs darf um die ES-Ausladung
abweichen.
Der Wert liegt im VERGLEICH der beiden Varianten: ein einzelner Lauf haette
nicht gezeigt, dass der ES-Fussabdruck vom falschen Segment abgezogen wurde
(878 mm Abweichung nur in der GF-Bogen-Variante). Darum sind beide als Paar
festgehalten, mit den erwarteten Protokollzeilen - eine FEHLENDE
Zuschlagszeile ist das Warnsignal.
Noch nicht automatisiert (Pfad muesste per entmake gezeichnet und das
Journal replayt werden); die reinen Rechenkerne sind in test_unit.lsp
bereits mit genau diesen Messwerten abgedeckt.
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>
BricsCAD reicht einen /b-Start an eine offene Instanz weiter: test_unit.scr
lief dann in der Sitzung des Benutzers und das abschliessende _.QUIT blieb
an der Speichern-Rueckfrage haengen (bzw. haette die Sitzung beendet).
Pruefung per tasklist|findstr - nicht find, das ist unter Git-Bash im PATH
das Unix-find und haette eine laufende Instanz nie erkannt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- TEST_LINIENZUG: seit 1cc163d/cccd362 fragt Modus 1 nach der AS-Seite die
optionale Zufuehrungsachse ab. Der Test mockt get* direkt (keine
Replay-Queue), die neue Punktfrage verschluckte die naechste Antwort und
der Lauf desynchronisierte (FEHLER, 21 Schritte offen). Neuer Schritt-Typ
"point_none" (getpoint -> nil) und in beiden Linienzug-Testdaten nach
der AS-Seite eingetragen.
- test_hundm05.py: Zusatzobjekt-Ergebnisse filterten nur kind "kreisel" -
Separatoren/Scanner/BTMT (kind "sensor") fehlten, test_je_objekt_ein_
ergebnis schlug faelschlich fehl.
- SSG_RUN_ALL_TESTS: #VF/#GF/#Kreisel/#Eckrad_LetzteNr vor jedem Test auf 0.
Der Lauf bleibt im Namensraum des Startdokuments, die Zaehler liefen
sonst ueber alle Tests weiter (VF_5/Kreisel12 in frischer Zeichnung) und
machten jeden Referenz-Diff von der Testreihenfolge abhaengig.
Co-Authored-By: Claude Opus 5.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>
Der Drehwinkel wird beim Bau in die Geometrie eingerechnet, die Blockreferenz
selbst hat immer Drehung 0 (ssg-block-wrap-welt). KF_EDIT las die Drehung nur
aus Gruppencode 50 und baute einen mit z.B. 90 Grad gebauten Foerderer beim
Bearbeiten daher ungedreht neu.
Der gebaute Winkel steht jetzt als XDATA (SSG_KF_EDIT) am Block. KF_EDIT
addiert eine spaeter von Hand vorgenommene Drehung der Referenz
(Gruppencode 50); Altbestand ohne XDATA verhaelt sich wie bisher.
- kf-block-erstellen: neuer Parameter drehung, beide Aufrufer angepasst
- reiner Kern kf-drehung-gesamt (auf -180..180 normalisiert) mit Unit-Tests
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
