From 5aed90dd5603f32a8d1c4808bf16909bce78f75b Mon Sep 17 00:00:00 2001 From: Michael Stangl Date: Fri, 9 Oct 2026 10:56:54 +0200 Subject: [PATCH] [CHANGE] doc/plan und doc/todo angelegt, interne Analyse-/TODO-Dokumente dorthin verschoben doc/todo/: TODO-plan-vf-interactive.md -> plan-vf-interactive.md, TODO-modus2-achsenweise-bilanz.md -> modus2-achsenweise-bilanz.md (offene Fahrplaene/TODOs). doc/plan/: KS-Frame-Architektur.md, vf-parameter-struct-analyse.md, translate.md, Entwicklungsplan.md (Architektur-Analysen und Planungsdokumente, kein Anwender-Material). Alle internen Verweise (CLAUDE.md, Lisp/README.md, README.md, doc/variofoerderer.md, Lisp/vf_spec.lsp, lib/dxf_vf_abbild.py, lib/vf_spec_export.py, tests/test_hm_recformat.lsp, tests/test_vf_geometrie.py, tests/test_vf_headless_statisch.py) auf die neuen Pfade angepasst. Reine Pfad-Updates in Kommentaren/Docstrings, keine funktionale Aenderung - Python-Syntax nach dem Umbau geprueft. Anwender-/Entwickler-Referenzdoku (faq.md, kommandos.md, tools.md, dbg2lsp.md, csv-export.md, json-input-lisp.md, lisp_methods.md, LispTests.md, variofoerderer.md, vf_linienzug_modus1_anleitung.md) bleibt direkt in doc/. Co-Authored-By: Claude Sonnet 5 --- CLAUDE.md | 8 ++++---- Lisp/README.md | 2 +- Lisp/vf_spec.lsp | 2 +- README.md | 4 ++-- doc/{ => plan}/Entwicklungsplan.md | 0 doc/{ => plan}/KS-Frame-Architektur.md | 0 doc/{ => plan}/translate.md | 0 doc/{ => plan}/vf-parameter-struct-analyse.md | 0 .../modus2-achsenweise-bilanz.md} | 0 .../plan-vf-interactive.md} | 0 doc/variofoerderer.md | 2 +- lib/dxf_vf_abbild.py | 2 +- lib/vf_spec_export.py | 2 +- tests/test_hm_recformat.lsp | 2 +- tests/test_vf_geometrie.py | 2 +- tests/test_vf_headless_statisch.py | 2 +- 16 files changed, 14 insertions(+), 14 deletions(-) rename doc/{ => plan}/Entwicklungsplan.md (100%) rename doc/{ => plan}/KS-Frame-Architektur.md (100%) rename doc/{ => plan}/translate.md (100%) rename doc/{ => plan}/vf-parameter-struct-analyse.md (100%) rename doc/{TODO-modus2-achsenweise-bilanz.md => todo/modus2-achsenweise-bilanz.md} (100%) rename doc/{TODO-plan-vf-interactive.md => todo/plan-vf-interactive.md} (100%) diff --git a/CLAUDE.md b/CLAUDE.md index 82cca61..f2ea156 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -104,8 +104,8 @@ Detaillierte Dokumentation aller Funktionen und Befehle: siehe `Lisp/README.md`. | `ssg_blocktools.lsp` | SSG_BLOCK_COUNT, SSG_BLOCK_DELETE, SSG_ATTR_ERSETZEN | Block-Werkzeuge fuer das aktuelle Layout (Ursprung ACADSST `TOOLS.LSP`/`ssg.lsp`): Einfuegungen zaehlen (Pick, wcmatch-Muster oder Statistik aller Bloecke), alle Einfuegungen loeschen (Rueckfrage, gesperrte Layer bleiben), Attributwerte zeichnungsweit/in Auswahl suchen+ersetzen (Vorschau mit Anzahl, Teilstring oder Gesamtwert). Wirksamer Blockname (dynamische Bloecke). Reine Kerne `ssg-bt-name-passt-p`, `ssg-bt-zaehle-namen`, `ssg-bt-wert-neu` in `tests/test_unit.lsp` getestet | | `ssg_texttools.lsp` | SSG_TEXT_ERSETZEN, SSG_TEXT_PARALLEL, SSG_TEXT_HOEHE, SSG_TEXT_STIL | Text-Werkzeuge (Ursprung ACADSST `CHGTEXT`/`PARTEXT`/`ALTHOEHE`/`ALTSTIL`): Suchen/Ersetzen in TEXT, MTEXT und Block-Attributen (nutzt `ssg-bt-*`, daher NACH `ssg_blocktools` laden), Text parallel zu Linie/Polylinie/Bogen (lesbar ausgerichtet, Abstand), Hoehe/Stil aendern. Arbeitet in der XY-Ebene des Welt-KS. Reine Kerne `ssg-tt-lesbarer-winkel`, `ssg-tt-versetzt` getestet | | `KreiselInsert.lsp` | KreiselInsert, KreiselConnect, KreiselRedraw, KreiselQuick, KreiselEdit, KreiselParams, KreiselLabelSetup, KreiselLabelPos, KreiselLabelHoehe, ILS_Eckrad | ILS Kreisel und Eckrad komplett in AutoLISP | -| `VarioFoerderer.lsp` (Wrapper fuer `vf_core.lsp`/`vf_standard.lsp`/`vf_etage.lsp`/`vf_linienzug.lsp`) | FOERDERANLAGE, VARIOFOERDERER_EDIT, VARIOFOERDERER_NACHRUESTEN, Vario_Kette_Merge, VF_SEKTION_RESTORE, VF_WIZARD_AN, VF_WIZARD_AUS | Vario-Foerderanlagen Generator (Typen Standard/Etage/Linienzug); Standard- UND Etage-Typ: Werteingabe per DCL-Dialog. Der Dialog-Ablauf ist zentral in vf_core (`vf-dialog-ablauf`/`vf-dialog-berechnen-einfuegen`, parametrisiert ueber Typ-Registry `*vf-typ-registry*` + Flag `horizontal-p`); `vfs-standard-dialog-ablauf`/`vfe-etage-dialog-ablauf` sind nur noch duenne Wrapper darauf. Beide nutzen dieselben Dialoge `vfs-dialog-eingabe-basis`/`vfs-dialog-winkel-verteilung` und den gemeinsamen L_GF/L_VF-Solve `vf-winkel-solve` (vf_core; berechne-alle-winkel/berechne-winkel-etage teilen ihn); Doppelklick auf VF_n-Block ruft VARIOFOERDERER_EDIT, das per SSG_VF_EDIT-XDATA-Marker ("standard"/"etage"/"linienzug") in den passenden Neuaufbau-Zweig dispatcht (`vfe-edit-ent` fuer Etage, `vfl-edit-ent` fuer Linienzug); Altbestand-Bloecke ohne Marker werden abgewiesen. Linienzug (Modus 1, `vf-linienzug-modus`) zeichnet jede interaktive Eingabe in einem Journal auf (`vfl-in-point`/`-string`/`-real`/`-int`) und schreibt es als XDATA auf den fertigen `VF_n`-Block; ein Abbruch (ESC) loescht dadurch nichts mehr, sondern wickelt die bis dahin gebaute Teil-Geometrie ebenso zu einem Block (`vfl-modus-abbruch-sichern`) - sie bleibt stehen und ist sofort per Doppelklick weiter editierbar/fortsetzbar. Der komplette Linienzug-Hauptstrang (Menue-Fragen von AS-Element bis Kettenende, inkl. GF-Bogen/Vario-Kurve/VF-Einheit-Fortsetzung) laeuft per Default ueber DCL-Dialoge statt Konsole (`*vfl-wizard-mode*`, Befehle VF_WIZARD_AN/VF_WIZARD_AUS): `vfl-in-string`/`-int`/`-real` zeigen bei aktivem Wizard-Modus generische Dialoge aus `dcl/vf_linienzug_wizard.dcl` (Zahl-Eingabe bzw. Mehrfachauswahl aus `vfl-menu`/`vfl-menu-int`) statt `getstring`/`getint`/`getreal` aufzurufen; die ORIGINALEN Konsolen-Fragen (princ + get*, de/en ueber ssg-text) bleiben unveraendert im Code (Fallback bei Fehlern via `vl-catch-all-apply`, siehe `doc/variofoerderer.md`). `vfl-edit-ent` liest das Journal, zeigt die Sektionen ueber einen DCL-Dialog (`vfl-dlg-position`, `dcl/vfl_edit.dcl`) an, kuerzt bei Bedarf auf eine gewaehlte Sektion (stummer Replay der behaltenen Eingaben, umgeht den Wizard-Zweig komplett) und baut danach interaktiv weiter. Linienzug Modus 2 (Pfad+Zielhoehe-Solver, `vf-linienzug-modus2`) nutzt dieselben Wrapper PLUS die neue Objektauswahl-Wrapper-Funktion `vfl-in-selection` (Pfad-Objekte als stabile Entity-Handles journalisiert, neue Journal-Art `"OBJS"`) und schreibt sein Journal unter dem eigenen XDATA-Marker `"linienzug2"`; Doppelklick baut hier NICHT abschnittsweise, sondern per vollem Reset 1:1 aus dem Journal neu auf (`vfl-edit-ent2`, dispatcht aus `vfl-edit-ent` per Marker) - Modus 3 (Vorwaerts-Nachbau) bleibt bewusst reine Konsole (im Code selbst als Legacy/"wird umgebaut" markiert). `Vario_Kette_Merge` (in vf_linienzug.lsp) fuehrt mehrere einzeln gebaute VF_n-Bloecke ab einem gewaehlten Start-Baustein ueber die reale KS_AUS->KS_EIN-Nachbarschaft zu einem Gesamt-Block zusammen (aggregierte Attribute, Luecken-Erkennung). Die interaktiven Editier-Pfade (`vfl-edit-ent` Sektions-Zweig, `vfl-edit-ent2`) rufen den Neuaufbau BEWUSST direkt auf, NICHT ueber `vl-catch-all-apply`: der alte Block ist beim Neuaufbau schon per `entdel` weg, und ein Catch faengt den Abbruch VOR `*error*` ab - der Abbruch-Wickler `vfl-modus-abbruch-sichern` kaeme nie zum Zug und die ganze Kette bliebe als lose Einzelteile ohne Block liegen (Fehlerbild "VF-Block aufgebrochen"). Nur der nicht-interaktive Batch-Konverter `vfl-konvertiere-ent` behaelt den Catch (die Batch-Schleife muss weiterlaufen) und meldet den betroffenen Block. Die Abbruch-Handler setzen zusaetzlich `*ssg-ils-dim*` zurueck, weil der Aufrufer, der das sonst tut, nach einem Abbruch nicht mehr erreicht wird. Recovery-Pfad fuer bereits aufgebrochene Ketten: `VF_SEKTION_RESTORE` (vf_linienzug.lsp) setzt das Ketten-Journal aus der XDATA der losen Objekte zusammen - `SSG_VF_EDIT_SEG` traegt pro Entity den Journal-Abschnitt DER ITERATION, in der es entstand (indiziert mit dem ersten Glied-Index darin; eine VF-Einheit mit eingebetteten Vario-Kurven erzeugt mehrere Glieder in einer Iteration), `SSG_VF_EDIT_PRE` auf den Entities des ersten Gliedes die Praeambel (Startpunkt/Starthoehe/AS). Die `.dbg`-Dateien sind reine AUSGABE und werden von keinem Befehl gelesen (dbgopen legt sie bei jedem Lauf neu an) - Wiederherstellungs-Daten gehoeren in die XDATA. `vf_konstanten.lsp` (von vf_core.lsp vor den drei Submodulen geladen) sammelt alle Laengen-/Winkel-/Toleranz-Magic-Numbers aus dem VarioFoerderer-Cluster als dokumentierte `*vfk-*`-Konstanten. Die Migration ist abgeschlossen: vf_core/vf_standard/vf_etage/vf_linienzug referenzieren durchgaengig die zentralen Konstanten statt roher Literale (Winkel, Stations-/Separator-Laengen, Mindestlaengen, AS/ES-Fallback-Versaetze, Text-/Label-Masse) - Ausnahmen sind in `vf_konstanten.lsp` selbst dokumentiert (Werte mit fuehrender Config-Anbindung via `ssg-cfg-or`, itoa-/Integer-Kontexte, Blocknamen-Strings, die 2000.0-mm/m-Umrechnung). `*vfk-gf-bogen-winkel*` (30/60/90, GF-Bogen + Vario-Kurve) und `*vfk-as-es-winkel*` ("30"/"90", AS/ES; bewusst STRING, da 2-wertig und im Journal als STR gefuehrt) sind Beispiele; vf_linienzug hat fuer beide einen Fallback, falls vf_konstanten nicht geladen wurde. **Nicht-interaktiver Betrieb**: `*vfl-headless*` (+ `vfl-headless-p`/`-abbruch`/`-notausgang`, Diagnose `*vfl-headless-fehler*`, optionaler Antwort-Hook `*vfl-headless-antwort-fn*`) verbietet jede Live-Eingabe - eine erschoepfte Replay-Queue ist damit ein harter Abbruch MIT Fundstelle (Art der Eingabe, Glied- und Eingabe-Nummer) statt eines stillen Rueckfalls auf `getpoint`/`getreal`; eingebaut in `vfl-in-value`/`-value-p`/`-selection`/`-abstand`. Die Bau-Pfade melden abgewiesene Sektionen ueber `vfl-meldung` (sammelt nach `*vfl-meldungen*` + `dbgmsg`, `alert` nur bei erlaubter GUI, sonst `princ`) statt per blockierendem `alert`; reine Interaktiv-Alerts (fehlendes DCL, "nicht editierbar", "kein Journal") bleiben `alert`. Genutzt von `tests/test_hm_recformat.lsp` (Replay der echten Aufzeichnungen) und von `vf_spec.lsp`; Fahrplan in `doc/TODO-plan-vf-interactive.md`. Details/Entscheidungsbaum: `doc/variofoerderer.md` | -| `vf_spec.lsp` (von vf_core.lsp NACH vf_linienzug.lsp geladen) | VF_SPEC_BAU | Linienzug-Ketten aus **Eingabedaten** bauen, ohne Dialog und ohne Konsolenfrage (Stufe 1 aus `doc/TODO-plan-vf-interactive.md`). 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` (Replay-Kern `vsp-bau-journal` - nimmt auch ein unveraendert uebernommenes, aufgezeichnetes Journal, z.B. aus `dxf_anlage_export.py`). Damit traegt der fertige Block 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. Wichtige Regeln, die der Uebersetzer kennt: der Menue-Code haengt am Frame (erste Sektion 4 Optionen ohne GF-Bogen, danach 5), `hz` steht nur beim ERSTEN Segment im Journal, und `erst-hor` unterscheidet den horizontalen Erstkoerper einer VF-Einheit (Separator-/Endpunktfragen vorab) vom gewinkelten (keine Frage). Fehlerverhalten: fail fast - `vsp-pruefen` sammelt ALLE Spec-Fehler, gebaut wird dann nichts (nichts wird geraten). Ergebnis-Record je Kette mit `status` (`executed`/`warnung`/`desync`/`abbruch`/`spec-fehler`), Block/Handle/Einfuegepunkt/Attributen, `prompts` (muss 0 sein), `glieder_soll` vs. `glieder_ist` (Desync-Detektor, der auch bei aufgehender Queue greift) und den gesammelten `meldungen`. Headless-Rahmen `vsp-headless-an`/`-aus` (Save/Restore von `*vfl-headless*`, `*vfl-wizard-mode*`, `*ssg-gui-aus*` + zaehlende Eingabe-Stubs). Spec-Datei flach als JSON (`ssg-load-json` liest zeilenweise), erzeugt von `lib/vf_spec_export.py`. Gegenstueck/Referenz in Python: derselbe Emitter, gegen die 5 echten HundM-Ketten rundlaufgeprueft | +| `VarioFoerderer.lsp` (Wrapper fuer `vf_core.lsp`/`vf_standard.lsp`/`vf_etage.lsp`/`vf_linienzug.lsp`) | FOERDERANLAGE, VARIOFOERDERER_EDIT, VARIOFOERDERER_NACHRUESTEN, Vario_Kette_Merge, VF_SEKTION_RESTORE, VF_WIZARD_AN, VF_WIZARD_AUS | Vario-Foerderanlagen Generator (Typen Standard/Etage/Linienzug); Standard- UND Etage-Typ: Werteingabe per DCL-Dialog. Der Dialog-Ablauf ist zentral in vf_core (`vf-dialog-ablauf`/`vf-dialog-berechnen-einfuegen`, parametrisiert ueber Typ-Registry `*vf-typ-registry*` + Flag `horizontal-p`); `vfs-standard-dialog-ablauf`/`vfe-etage-dialog-ablauf` sind nur noch duenne Wrapper darauf. Beide nutzen dieselben Dialoge `vfs-dialog-eingabe-basis`/`vfs-dialog-winkel-verteilung` und den gemeinsamen L_GF/L_VF-Solve `vf-winkel-solve` (vf_core; berechne-alle-winkel/berechne-winkel-etage teilen ihn); Doppelklick auf VF_n-Block ruft VARIOFOERDERER_EDIT, das per SSG_VF_EDIT-XDATA-Marker ("standard"/"etage"/"linienzug") in den passenden Neuaufbau-Zweig dispatcht (`vfe-edit-ent` fuer Etage, `vfl-edit-ent` fuer Linienzug); Altbestand-Bloecke ohne Marker werden abgewiesen. Linienzug (Modus 1, `vf-linienzug-modus`) zeichnet jede interaktive Eingabe in einem Journal auf (`vfl-in-point`/`-string`/`-real`/`-int`) und schreibt es als XDATA auf den fertigen `VF_n`-Block; ein Abbruch (ESC) loescht dadurch nichts mehr, sondern wickelt die bis dahin gebaute Teil-Geometrie ebenso zu einem Block (`vfl-modus-abbruch-sichern`) - sie bleibt stehen und ist sofort per Doppelklick weiter editierbar/fortsetzbar. Der komplette Linienzug-Hauptstrang (Menue-Fragen von AS-Element bis Kettenende, inkl. GF-Bogen/Vario-Kurve/VF-Einheit-Fortsetzung) laeuft per Default ueber DCL-Dialoge statt Konsole (`*vfl-wizard-mode*`, Befehle VF_WIZARD_AN/VF_WIZARD_AUS): `vfl-in-string`/`-int`/`-real` zeigen bei aktivem Wizard-Modus generische Dialoge aus `dcl/vf_linienzug_wizard.dcl` (Zahl-Eingabe bzw. Mehrfachauswahl aus `vfl-menu`/`vfl-menu-int`) statt `getstring`/`getint`/`getreal` aufzurufen; die ORIGINALEN Konsolen-Fragen (princ + get*, de/en ueber ssg-text) bleiben unveraendert im Code (Fallback bei Fehlern via `vl-catch-all-apply`, siehe `doc/variofoerderer.md`). `vfl-edit-ent` liest das Journal, zeigt die Sektionen ueber einen DCL-Dialog (`vfl-dlg-position`, `dcl/vfl_edit.dcl`) an, kuerzt bei Bedarf auf eine gewaehlte Sektion (stummer Replay der behaltenen Eingaben, umgeht den Wizard-Zweig komplett) und baut danach interaktiv weiter. Linienzug Modus 2 (Pfad+Zielhoehe-Solver, `vf-linienzug-modus2`) nutzt dieselben Wrapper PLUS die neue Objektauswahl-Wrapper-Funktion `vfl-in-selection` (Pfad-Objekte als stabile Entity-Handles journalisiert, neue Journal-Art `"OBJS"`) und schreibt sein Journal unter dem eigenen XDATA-Marker `"linienzug2"`; Doppelklick baut hier NICHT abschnittsweise, sondern per vollem Reset 1:1 aus dem Journal neu auf (`vfl-edit-ent2`, dispatcht aus `vfl-edit-ent` per Marker) - Modus 3 (Vorwaerts-Nachbau) bleibt bewusst reine Konsole (im Code selbst als Legacy/"wird umgebaut" markiert). `Vario_Kette_Merge` (in vf_linienzug.lsp) fuehrt mehrere einzeln gebaute VF_n-Bloecke ab einem gewaehlten Start-Baustein ueber die reale KS_AUS->KS_EIN-Nachbarschaft zu einem Gesamt-Block zusammen (aggregierte Attribute, Luecken-Erkennung). Die interaktiven Editier-Pfade (`vfl-edit-ent` Sektions-Zweig, `vfl-edit-ent2`) rufen den Neuaufbau BEWUSST direkt auf, NICHT ueber `vl-catch-all-apply`: der alte Block ist beim Neuaufbau schon per `entdel` weg, und ein Catch faengt den Abbruch VOR `*error*` ab - der Abbruch-Wickler `vfl-modus-abbruch-sichern` kaeme nie zum Zug und die ganze Kette bliebe als lose Einzelteile ohne Block liegen (Fehlerbild "VF-Block aufgebrochen"). Nur der nicht-interaktive Batch-Konverter `vfl-konvertiere-ent` behaelt den Catch (die Batch-Schleife muss weiterlaufen) und meldet den betroffenen Block. Die Abbruch-Handler setzen zusaetzlich `*ssg-ils-dim*` zurueck, weil der Aufrufer, der das sonst tut, nach einem Abbruch nicht mehr erreicht wird. Recovery-Pfad fuer bereits aufgebrochene Ketten: `VF_SEKTION_RESTORE` (vf_linienzug.lsp) setzt das Ketten-Journal aus der XDATA der losen Objekte zusammen - `SSG_VF_EDIT_SEG` traegt pro Entity den Journal-Abschnitt DER ITERATION, in der es entstand (indiziert mit dem ersten Glied-Index darin; eine VF-Einheit mit eingebetteten Vario-Kurven erzeugt mehrere Glieder in einer Iteration), `SSG_VF_EDIT_PRE` auf den Entities des ersten Gliedes die Praeambel (Startpunkt/Starthoehe/AS). Die `.dbg`-Dateien sind reine AUSGABE und werden von keinem Befehl gelesen (dbgopen legt sie bei jedem Lauf neu an) - Wiederherstellungs-Daten gehoeren in die XDATA. `vf_konstanten.lsp` (von vf_core.lsp vor den drei Submodulen geladen) sammelt alle Laengen-/Winkel-/Toleranz-Magic-Numbers aus dem VarioFoerderer-Cluster als dokumentierte `*vfk-*`-Konstanten. Die Migration ist abgeschlossen: vf_core/vf_standard/vf_etage/vf_linienzug referenzieren durchgaengig die zentralen Konstanten statt roher Literale (Winkel, Stations-/Separator-Laengen, Mindestlaengen, AS/ES-Fallback-Versaetze, Text-/Label-Masse) - Ausnahmen sind in `vf_konstanten.lsp` selbst dokumentiert (Werte mit fuehrender Config-Anbindung via `ssg-cfg-or`, itoa-/Integer-Kontexte, Blocknamen-Strings, die 2000.0-mm/m-Umrechnung). `*vfk-gf-bogen-winkel*` (30/60/90, GF-Bogen + Vario-Kurve) und `*vfk-as-es-winkel*` ("30"/"90", AS/ES; bewusst STRING, da 2-wertig und im Journal als STR gefuehrt) sind Beispiele; vf_linienzug hat fuer beide einen Fallback, falls vf_konstanten nicht geladen wurde. **Nicht-interaktiver Betrieb**: `*vfl-headless*` (+ `vfl-headless-p`/`-abbruch`/`-notausgang`, Diagnose `*vfl-headless-fehler*`, optionaler Antwort-Hook `*vfl-headless-antwort-fn*`) verbietet jede Live-Eingabe - eine erschoepfte Replay-Queue ist damit ein harter Abbruch MIT Fundstelle (Art der Eingabe, Glied- und Eingabe-Nummer) statt eines stillen Rueckfalls auf `getpoint`/`getreal`; eingebaut in `vfl-in-value`/`-value-p`/`-selection`/`-abstand`. Die Bau-Pfade melden abgewiesene Sektionen ueber `vfl-meldung` (sammelt nach `*vfl-meldungen*` + `dbgmsg`, `alert` nur bei erlaubter GUI, sonst `princ`) statt per blockierendem `alert`; reine Interaktiv-Alerts (fehlendes DCL, "nicht editierbar", "kein Journal") bleiben `alert`. Genutzt von `tests/test_hm_recformat.lsp` (Replay der echten Aufzeichnungen) und von `vf_spec.lsp`; Fahrplan in `doc/todo/plan-vf-interactive.md`. Details/Entscheidungsbaum: `doc/variofoerderer.md` | +| `vf_spec.lsp` (von vf_core.lsp NACH vf_linienzug.lsp geladen) | VF_SPEC_BAU | Linienzug-Ketten aus **Eingabedaten** bauen, ohne Dialog und ohne Konsolenfrage (Stufe 1 aus `doc/todo/plan-vf-interactive.md`). 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` (Replay-Kern `vsp-bau-journal` - nimmt auch ein unveraendert uebernommenes, aufgezeichnetes Journal, z.B. aus `dxf_anlage_export.py`). Damit traegt der fertige Block 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. Wichtige Regeln, die der Uebersetzer kennt: der Menue-Code haengt am Frame (erste Sektion 4 Optionen ohne GF-Bogen, danach 5), `hz` steht nur beim ERSTEN Segment im Journal, und `erst-hor` unterscheidet den horizontalen Erstkoerper einer VF-Einheit (Separator-/Endpunktfragen vorab) vom gewinkelten (keine Frage). Fehlerverhalten: fail fast - `vsp-pruefen` sammelt ALLE Spec-Fehler, gebaut wird dann nichts (nichts wird geraten). Ergebnis-Record je Kette mit `status` (`executed`/`warnung`/`desync`/`abbruch`/`spec-fehler`), Block/Handle/Einfuegepunkt/Attributen, `prompts` (muss 0 sein), `glieder_soll` vs. `glieder_ist` (Desync-Detektor, der auch bei aufgehender Queue greift) und den gesammelten `meldungen`. Headless-Rahmen `vsp-headless-an`/`-aus` (Save/Restore von `*vfl-headless*`, `*vfl-wizard-mode*`, `*ssg-gui-aus*` + zaehlende Eingabe-Stubs). Spec-Datei flach als JSON (`ssg-load-json` liest zeilenweise), erzeugt von `lib/vf_spec_export.py`. Gegenstueck/Referenz in Python: derselbe Emitter, gegen die 5 echten HundM-Ketten rundlaufgeprueft | | `Gefaellestrecke.lsp` | GEFAELLESTRECKE, GEFAELLESTRECKE_EDIT | Gefaelle-Foerderanlage (AUS -> Staustrecke skaliert -> Separator -> EIN); Modus 1 per DCL-Dialog (Einfuegehoehe, Element-Winkel 30/90); Doppelklick auf GF_n-Block ruft GEFAELLESTRECKE_EDIT (Dialog vorbelegt, Neuaufbau) | | `export.lsp` | EXPORTSIVAS, EXPORTCSV, OMNI_UPDATE_ATTRIBS, CSV_EXPORT_KONFIG | JSON-Sammlung und Python-Export (Omniflo-Merkmale/Sum-Zeile via lib/export_csv.py). **Gefrorene Layer**: `csv:collect-export-blocks` laesst Bloecke auf gefrorenen Layern aus (ausgeschaltete Layer zaehlen NICHT), Schalter `*csv-gefrorene-ausschliessen*` (Standard an, Toggle im Dialog CSV_EXPORT_KONFIG). Die Hilfsobjekte eines gefrorenen VF_n/GF_n (Separator-/Element-Kopien, Einheiten-/AS-ES-Marker) liegen auf eigenen Layern und werden darum ueber `*csv-ausschluss-enames*` mit ausgelassen (gesetzt in `csv:export-vorbereiten` per `csv:hilfskopien-ausschluss`); erzeugt und nummeriert werden sie trotzdem, damit IDs stabil bleiben. DrawPlanquadrate nutzt dieselbe Sammlung und folgt dem Filter | | `OmniModulInsert.lsp` | OMNI_LOAD, OMNI_APB_*, OMNI_W*_*, OMNI_AP60/AP110, OMNI_TEF_*, OMNI_TV_*, OMNI_APBW_*, OMNI_LADESCHLEIFE_AP110, OMNI_EDIT | Omniflo-Komponenten: Boegen, Weichen, Verbinder, Transferwagen, Ladeschleifen (`data/json/omniflo_ladeschleifen.json`, per `ssg-json-laden`, da die Beschreibungen Kommas enthalten; Blockdatei darf `.dwg` statt `.dxf` sein), Edit-Dialog | @@ -174,7 +174,7 @@ Werden via `bin/setenv.bat` gesetzt. Wichtigste: - Die **Farbe** wirkt nur bei der Neuanlage des Layers (`ssg-make-layer` laesst bestehende Layer unveraendert, damit Kundenzeichnungen nicht umgefaerbt werden). Layer, die eine Blockdatei aus `data/ils` selbst mitbringt (z.B. `ILS_SP`/`_3D_ILS_SP`), legt BricsCAD schon beim Einfuegen des Blocks mit der Farbe **aus der DWG** an - dort greift die cfg-Farbe nicht, wohl aber der Layername des Wrappers. Fuer Layer ohne Baugruppen-Key gibt es zusaetzlich den Abschnitt `[farben]` (Layername = Farbe), gelesen von `ssg-layer-farbe-fuer-name`. - Komponentendaten (Masse, Sivas-IDs) liegen als JSON in `data/json/` - Sprache im Code und Kommentaren: Deutsch -- **Benutzermeldungen sind ZWEISPRACHIG (de/en)**: Jede an den Anwender gerichtete Meldung (`princ`/`alert`/`getstring`/`getint`/`getreal`/`getkword`-Prompts, auch per `strcat` zusammengesetzte) laeuft ueber `(ssg-text "key")` bzw. `(ssg-textf "key" (list args))`. Die Texte stehen in `lang/de_DE.json` UND `lang/en_GB.json` unter `"texts"` und muessen key-fuer-key synchron bleiben (Paritaets-Check vor dem Commit). Konventionen: Key-Prefix je Modul (`vfc-` vf_core, `gf-` Gefaellestrecke), geteilte Prompts ohne Prefix (`prompt-wahl-1-2` usw.) - vor dem Anlegen eines neuen Keys erst die JSONs nach dem deutschen String grep'en und wiederverwenden. Sonderzeichen wie Grad `(chr 176)` / Delta `(chr 916)` als `%n`-Platzhalter uebergeben, nicht in die (ASCII-)JSON einbetten. **Untranslatiert bleiben** (bewusst): Bracket-Diagnosen (`[vf_core]` o.ae.), die VOR dem garantierten Laden von `ssg_lang.lsp` feuern (Bootstrap-Fallbacks am Dateikopf - `ssg-text` existiert dort noch nicht), Lade-Banner (`>>> ... geladen`), reine `====`/`---`-Trenner und reine Entwickler-Diagnosebefehle (nicht im Menue). Details und Entscheidungsbaum: `doc/translate.md`. +- **Benutzermeldungen sind ZWEISPRACHIG (de/en)**: Jede an den Anwender gerichtete Meldung (`princ`/`alert`/`getstring`/`getint`/`getreal`/`getkword`-Prompts, auch per `strcat` zusammengesetzte) laeuft ueber `(ssg-text "key")` bzw. `(ssg-textf "key" (list args))`. Die Texte stehen in `lang/de_DE.json` UND `lang/en_GB.json` unter `"texts"` und muessen key-fuer-key synchron bleiben (Paritaets-Check vor dem Commit). Konventionen: Key-Prefix je Modul (`vfc-` vf_core, `gf-` Gefaellestrecke), geteilte Prompts ohne Prefix (`prompt-wahl-1-2` usw.) - vor dem Anlegen eines neuen Keys erst die JSONs nach dem deutschen String grep'en und wiederverwenden. Sonderzeichen wie Grad `(chr 176)` / Delta `(chr 916)` als `%n`-Platzhalter uebergeben, nicht in die (ASCII-)JSON einbetten. **Untranslatiert bleiben** (bewusst): Bracket-Diagnosen (`[vf_core]` o.ae.), die VOR dem garantierten Laden von `ssg_lang.lsp` feuern (Bootstrap-Fallbacks am Dateikopf - `ssg-text` existiert dort noch nicht), Lade-Banner (`>>> ... geladen`), reine `====`/`---`-Trenner und reine Entwickler-Diagnosebefehle (nicht im Menue). Details und Entscheidungsbaum: `doc/plan/translate.md`. - **Subagenten** sollten von Claude nur mit Rückfrage an den Nutzer gestartet werden. Dabei sollten wenn möglich die leichteren Modelle gewählt werden, da es sich dabei in der Regel um Code recherche handelt. ## Python-Bibliotheken @@ -211,7 +211,7 @@ Abhaengigkeiten: `ezdxf`, Standard-Library. Benoetigen Umgebungsvariablen (`DXFM ## Entwicklungsstand -Siehe `doc/Entwicklungsplan.md` fuer Meilensteinplanung und Aufwandsschaetzung. +Siehe `doc/plan/Entwicklungsplan.md` fuer Meilensteinplanung und Aufwandsschaetzung. Fertig (DONE): ILS Kreisel, ILS Eckrad, ILS Variofoerderer, ILS BTMT Be-/Entladung (Einfuegen), Omniflo Boegen, Omniflo Weichen. ## Debug diff --git a/Lisp/README.md b/Lisp/README.md index 05d5e12..48c6d1f 100644 --- a/Lisp/README.md +++ b/Lisp/README.md @@ -190,7 +190,7 @@ Interne Parser-Funktionen (nicht direkt aufrufen): ### `ssg_lang.lsp` – Sprachumschaltung (Deutsch/Englisch) -Zentrale Textverwaltung fuer benutzersichtbare Meldungen. Kern-Modul, wird direkt nach `ssg_core` geladen. Wird schrittweise auf weitere Module ausgerollt (siehe `doc/translate.md`). +Zentrale Textverwaltung fuer benutzersichtbare Meldungen. Kern-Modul, wird direkt nach `ssg_core` geladen. Wird schrittweise auf weitere Module ausgerollt (siehe `doc/plan/translate.md`). | Funktion | Beschreibung | | --- | --- | diff --git a/Lisp/vf_spec.lsp b/Lisp/vf_spec.lsp index 66609ff..bd8fe61 100644 --- a/Lisp/vf_spec.lsp +++ b/Lisp/vf_spec.lsp @@ -1,7 +1,7 @@ ;; ============================================================ ;; vf_spec.lsp - VF-Linienzug aus Eingabedaten bauen (ohne GUI/Konsole) ;; ============================================================ -;; Stufe 1 des Fahrplans in doc/TODO-plan-vf-interactive.md. +;; Stufe 1 des Fahrplans in doc/todo/plan-vf-interactive.md. ;; ;; Eine SPEC beschreibt eine Kette in Domaenenwerten ("links", "winkel", ;; "aussen", ja/nein) statt in Menue-Codes: lesbar, schreibbar, versionierbar. diff --git a/README.md b/README.md index 61630db..9715b25 100644 --- a/README.md +++ b/README.md @@ -74,7 +74,7 @@ dxfmakros/ ├── cfg/ # Konfigurationsdateien ├── data/ # JSON-Daten, DXF-Quellen, Block-Libraries - nicht im Git ├── dcl/ # DCL-Dialogdefinitionen -├── doc/ # Dokumentation, Entwicklungsplan +├── doc/ # Dokumentation (doc/plan Architektur/Analysen, doc/todo offene Fahrplaene) ├── lib/ # Python-Skripte (DXF-Bearbeitung, Export) ├── log/ # Logdateien - nicht im Git ├── menu/ # BricsCAD-Menudefinition (SSG_LIB.mnu, SSG_LIB.mnl) @@ -114,7 +114,7 @@ Zeichnungs-/Szenario-Tests laufen interaktiv in BricsCAD ueber das Menue `Tests` ## Dokumentation -Ausfuehrliche Modul- und Befehlsdokumentation: `CLAUDE.md` (Projektanweisungen) und `Lisp/README.md`. Weitere Themen in `doc/` (u.a. `variofoerderer.md`, `translate.md`, `csv-export.md`, `Entwicklungsplan.md`, `faq.md`, `kommandos.md`). +Ausfuehrliche Modul- und Befehlsdokumentation: `CLAUDE.md` (Projektanweisungen) und `Lisp/README.md`. Weitere Anwender-/Entwickler-Themen direkt in `doc/` (u.a. `variofoerderer.md`, `csv-export.md`, `faq.md`, `kommandos.md`). Architektur-Analysen und Planungsdokumente in `doc/plan/` (u.a. `translate.md`, `Entwicklungsplan.md`), offene Fahrplaene/TODOs in `doc/todo/`. ## Lizenz diff --git a/doc/Entwicklungsplan.md b/doc/plan/Entwicklungsplan.md similarity index 100% rename from doc/Entwicklungsplan.md rename to doc/plan/Entwicklungsplan.md diff --git a/doc/KS-Frame-Architektur.md b/doc/plan/KS-Frame-Architektur.md similarity index 100% rename from doc/KS-Frame-Architektur.md rename to doc/plan/KS-Frame-Architektur.md diff --git a/doc/translate.md b/doc/plan/translate.md similarity index 100% rename from doc/translate.md rename to doc/plan/translate.md diff --git a/doc/vf-parameter-struct-analyse.md b/doc/plan/vf-parameter-struct-analyse.md similarity index 100% rename from doc/vf-parameter-struct-analyse.md rename to doc/plan/vf-parameter-struct-analyse.md diff --git a/doc/TODO-modus2-achsenweise-bilanz.md b/doc/todo/modus2-achsenweise-bilanz.md similarity index 100% rename from doc/TODO-modus2-achsenweise-bilanz.md rename to doc/todo/modus2-achsenweise-bilanz.md diff --git a/doc/TODO-plan-vf-interactive.md b/doc/todo/plan-vf-interactive.md similarity index 100% rename from doc/TODO-plan-vf-interactive.md rename to doc/todo/plan-vf-interactive.md diff --git a/doc/variofoerderer.md b/doc/variofoerderer.md index fd97fca..0b0c20a 100644 --- a/doc/variofoerderer.md +++ b/doc/variofoerderer.md @@ -448,7 +448,7 @@ Optionen, bei "Eigene Werte" zusaetzlich L_GF1 als Zahl) -> Bestaetigung ## 8b. Nicht-interaktiver Betrieb (Headless) Fuer Tests, Batch-Nachbau und den geplanten Spec-Bau (Fahrplan: -`doc/TODO-plan-vf-interactive.md`) muss eine Kette **ohne** Dialog und ohne +`doc/todo/plan-vf-interactive.md`) muss eine Kette **ohne** Dialog und ohne Konsolenfrage laufen. Drei Schalter greifen dabei ineinander: | Schalter | Datei | Wirkung | diff --git a/lib/dxf_vf_abbild.py b/lib/dxf_vf_abbild.py index 88a62d6..6b1584f 100644 --- a/lib/dxf_vf_abbild.py +++ b/lib/dxf_vf_abbild.py @@ -5,7 +5,7 @@ dxf_vf_abbild.py - Abbild der VF_/GF_-Wrapperbloecke einer Testzeichnung: Attribute und Bausteinliste je Kette. Zweck: Regressionsnetz fuer Umbauten am Bau-Ablauf. Nach jedem Schritt der -Funktionstrennung (doc/TODO-plan-vf-interactive.md, Stufe 2) muss die +Funktionstrennung (doc/todo/plan-vf-interactive.md, Stufe 2) muss die gebaute Geometrie unveraendert sein - "unveraendert" heisst hier: gleiche Attribute (inklusive der reihenfolgeabhaengigen Komma-Listen L_VF_m/L_GF_m/ GF_WINKEL, die in der Zeichnung unsichtbar, im Sivas-Export aber falsch diff --git a/lib/vf_spec_export.py b/lib/vf_spec_export.py index a52abc4..861b0a4 100644 --- a/lib/vf_spec_export.py +++ b/lib/vf_spec_export.py @@ -7,7 +7,7 @@ uebersetzen und zurueck. Eine Spec beschreibt eine Kette in Domaenenwerten ("links", "winkel", "aussen", ja/nein) statt in Menue-Codes und Journal-Tokens: lesbar, schreibbar und damit die Eingabeform fuer den nicht-interaktiven Bau -(Lisp/vf_spec.lsp, siehe doc/TODO-plan-vf-interactive.md Stufe 1). +(Lisp/vf_spec.lsp, siehe doc/todo/plan-vf-interactive.md Stufe 1). Zwei Richtungen, die einander pruefen: diff --git a/tests/test_hm_recformat.lsp b/tests/test_hm_recformat.lsp index bbd5972..3347780 100644 --- a/tests/test_hm_recformat.lsp +++ b/tests/test_hm_recformat.lsp @@ -10,7 +10,7 @@ ;; roh aus der XDATA einer echten Zeichnung. Damit ist dies der einzige Test, ;; der belegt, dass ein BESTEHENDER VF_n-Block weiter abspielbar bleibt - ;; also dass Doppelklick-Editieren und 2D/3D-Konvertierung an Altbestand -;; funktionieren (Invariante I1 in doc/TODO-plan-vf-interactive.md). Ein +;; funktionieren (Invariante I1 in doc/todo/plan-vf-interactive.md). Ein ;; spec-gebautes Journal kann das nicht zeigen, es kommt aus dem Uebersetzer. ;; ;; Darum in tests/alltests.json auf "disabled": true - er baut dieselbe diff --git a/tests/test_vf_geometrie.py b/tests/test_vf_geometrie.py index f62b708..ac8cd37 100644 --- a/tests/test_vf_geometrie.py +++ b/tests/test_vf_geometrie.py @@ -7,7 +7,7 @@ HundM-Ketten. Warum zusaetzlich zu tests/test_hundm05.py: der Ergebnis-Record sagt "executed, kein Prompt, Journal aufgegangen" - er sagt NICHT, ob dieselbe Geometrie herauskam wie vorher. Genau das ist bei der Funktionstrennung in -Stufe 2 (doc/TODO-plan-vf-interactive.md) das Risiko: die Reihenfolge der +Stufe 2 (doc/todo/plan-vf-interactive.md) das Risiko: die Reihenfolge der dL-Subtraktionen und der vfl-acc-*-Aufrufe IST Geometrie, und eine falsche Reihenfolge faellt in der Zeichnung nicht auf - nur im Sivas-Export. diff --git a/tests/test_vf_headless_statisch.py b/tests/test_vf_headless_statisch.py index f098990..60419fe 100644 --- a/tests/test_vf_headless_statisch.py +++ b/tests/test_vf_headless_statisch.py @@ -11,7 +11,7 @@ einem selten erreichten Zweig ein neues (alert ...) oder ein rohes (getreal ...) hinzufuegt. Genau das haelt dieser Test fest: die Fundstellen sind eingecheckt, jede neue muss hier bewusst eingetragen werden. -Hintergrund und Fahrplan: doc/TODO-plan-vf-interactive.md, +Hintergrund und Fahrplan: doc/todo/plan-vf-interactive.md, Mechanik: doc/variofoerderer.md Abschnitt 8b. """