diff --git a/Lisp/vf_linienzug.lsp b/Lisp/vf_linienzug.lsp index bca6f2a..ba50636 100644 --- a/Lisp/vf_linienzug.lsp +++ b/Lisp/vf_linienzug.lsp @@ -11007,6 +11007,35 @@ (strcat "Eck/Bogen " (itoa (nth 3 seg)) " Grad " (nth 4 seg))) (= run-typ "VF"))) ; Modus 3: Vario nur im offenen VF-Lauf (vfl-seg-highlight seg-ent nil))) + ;; !!! ACHTUNG beim Aendern der folgenden Auswahllisten !!! + ;; Modus 3 klassifiziert seine Segmente noch ueber MENUE-ZIFFERN: die + ;; Antworten werden roh als "1"/"2"/"3"/"4" verglichen UND genauso ins + ;; Journal geschrieben (Marker "linienzug3"). Die Ziffer bedeutet also + ;; nichts aus sich heraus - sie ist eine Position in der Liste, die hier + ;; gerade steht. + ;; Wer die Optionen umsortiert, ergaenzt oder entfernt, deutet damit JEDES + ;; bereits gespeicherte Modus-3-Journal still um: ein Doppelklick baut die + ;; Kette dann anders wieder auf, ohne Fehlermeldung. Genau das ist beim + ;; Lauf-Anfang real passiert (833a4b6). + ;; Modus 2 hat das nicht mehr: dort stehen selbstbeschreibende Werte + ;; ("gf"/"vf", "gf-bogen"/"vario-kurve", "aussen"/"innen") plus eine + ;; Alt-Tabelle fuer Bestandsketten, aufgeloest ueber vfl-wert-norm + ;; (4a19ac0). Dieselbe Mechanik ist fuer Modus 3 vorbereitet, aber BEWUSST + ;; nicht angewandt: es gibt kein aufgezeichnetes Modus-3-Journal und damit + ;; kein Sicherheitsnetz, das beweist, dass Bestandsketten die Umstellung + ;; unveraendert ueberstehen - bei Modus 2 haben das die beiden + ;; Referenzketten getan (sie tragen bis heute die alten Ziffern). + ;; Nutzer-Entscheidung 2026-10-29: ein Modus-3-Testfall wird VORERST nicht + ;; angelegt - bei Problemen im Einsatz wird getestet und korrigiert. Die + ;; Umstellung bleibt damit offen, das Risiko bestehen - deshalb steht die + ;; Warnung hier statt in einer TODO-Datei. + ;; Falls doch einmal eine Modus-3-Kette untersucht werden muss: mit + ;; lib/vf_journal_export.py das Journal aus der Zeichnung ziehen - damit + ;; liegt das fehlende Netz vor und die Umstellung ist derselbe Handgriff + ;; wie bei Modus 2. + ;; Hintergrund: doc/todo/spec-modus2-3.md, Konvention in CLAUDE.md + ;; ("Werte selbstbeschreibend fuehren, nicht als positionsabhaengige + ;; Indizes/Flags"). (cond ;; ===================== GERADE ===================== ((= typ "Linie") diff --git a/doc/todo.md b/doc/todo.md index 25760bd..c7813c1 100644 --- a/doc/todo.md +++ b/doc/todo.md @@ -11,23 +11,6 @@ Stand: 2026-10-26. Wird woechentlich (freitags) mit der Doku geprueft, siehe ## 1. VarioFoerderer / Linienzug -- **VF-Linienzug ohne GUI/Konsole, Stufe 2** (Funktionstrennung): eigener, - separat abzuarbeitender Auftrag mit Schritt-Tabelle. Schritte 5c, 6, 8, 9, - 10 offen (u.a. `vfl-spec-ausfuehren`). Schritt 11 war zurueckgestellt, bis - echte Modus-2-Journale vorliegen - **diese Vorbedingung ist seit - 2026-10-27 erfuellt** (`tests/testdata/linienzug_modus2_*.json`). Niedrige - Prioritaet - Architektur, keine neue Funktion. - -> `doc/todo/linienzug-ohne-gui.md` -- **Spec-Uebersetzer fuer Modus 2/3**: **weitgehend erledigt bzw. bewusst - gestrichen** (2026-10-27, 4a19ac0). Entscheidung: Eine Spec lohnt fuer - Modus 2/3 nicht - deren Journale tragen mit `SEGS` die komplette - Segment-Essenz und sind ohne Zeichnung abspielbar, der Mehrwert von - Domaenenwerten ist damit klein. Umgesetzt wurden die drei lohnenden Teile: - Python liest `linienzug2`/`3` (Rohtokens), `vsp-bau-journal` waehlt die - Bau-Funktion aus dem Journal, und die Segment-Antworten sind - selbstbeschreibende Werte statt Menue-Ziffern. OFFEN bleibt nur dasselbe - fuer **Modus 3** - dort fehlt ein aufgezeichnetes Journal als Netz. - -> `doc/todo/spec-modus2-3.md` - **Stufe 3 Winkelwahl: "Ab"-Zweig** (`vf_standard.lsp`, Kommentar bei der Fuellstueck-Berechnung): nur "Auf" implementiert, "Ab" bleibt bewusst offen, bis ein konkreter Bedarfsfall vorliegt. Ebenso `schon-flach` in Stufe 3. diff --git a/doc/todo/linienzug-ohne-gui.md b/doc/todo/linienzug-ohne-gui.md index af719a9..608cc6e 100644 --- a/doc/todo/linienzug-ohne-gui.md +++ b/doc/todo/linienzug-ohne-gui.md @@ -1,7 +1,33 @@ -# TODO: VF-Linienzug ohne GUI/Konsole - Stufe 2 (Funktionstrennung) +# VF-Linienzug ohne GUI/Konsole - Stufe 2 (Funktionstrennung) -**Stand:** 2026-10-26 · **Prioritaet:** niedrig - bringt Architektur, keine -neue Funktion. +**Stand:** 2026-10-29 · **ZURUECKGESTELLT** - aus `doc/todo.md` entfernt, die +Datei bleibt als Fahrplan liegen. + +## Warum zurueckgestellt + +Stufe 2 sollte den **Journal-Replay-Umweg** ueberfluessig machen: Bauteile +direkt mit Daten aufrufen statt Fragen aus einer Queue beantworten zu lassen. +Dieser Umweg ist aber keiner mehr. Ein Linienzug-Journal traegt mit `SEGS` die +komplette Segment-Essenz und laesst sich OHNE Zeichnung abspielen - mit +derselben Begruendung wurde am 2026-10-27 bereits der Spec-Uebersetzer fuer +Modus 2/3 gestrichen (4a19ac0, `doc/todo/spec-modus2-3.md`). Die +Modus-2-Regressionstests (`c:TEST_LINIENZUG_MODUS2`, seit 2026-10-29 fuenf +Faelle) laufen headless ueber genau diesen Replay-Pfad: er ist nicht der +Engpass, sondern die funktionierende Loesung. + +Dazu kommt das Risiko. Die offenen Schritte 5c/6/8/9/10 fassen den Code an, in +dem die REIHENFOLGE SELBST GEOMETRIE IST (siehe "Warum es heikel ist" unten) - +und ein Teil dieser Fehler ist in der Zeichnung unsichtbar und faellt erst im +Sivas-Export auf. Hoher Einsatz, kein Funktionsgewinn. + +**Wieder aufnehmen, wenn** einer dieser Faelle eintritt: +- einzelne Bauteile sollen ohne Journal aufrufbar sein (z.B. ein Generator, + der Ketten aus Fremddaten baut und die Frage-Reihenfolge nicht kennen will); +- der Replay-Pfad wird zu langsam oder zu fehleranfaellig; +- `vfl-spec-ausfuehren` wird von irgendwo erwartet (heute: nirgends). + +**Prioritaet beim Wiederaufnehmen:** niedrig - bringt Architektur, keine neue +Funktion. Herausgeloester Arbeitsauftrag aus dem Gesamtplan [plan-vf-interactive.md](plan-vf-interactive.md) (Teil 5 "Stufe 2: echte diff --git a/doc/todo/spec-modus2-3.md b/doc/todo/spec-modus2-3.md index d78ec6d..f3bec0f 100644 --- a/doc/todo/spec-modus2-3.md +++ b/doc/todo/spec-modus2-3.md @@ -45,15 +45,19 @@ AS/ES). Sie ist damit wie Modus 1 **ohne Zeichnung** pruefbar. ## Schritte +Die Stand-Spalte ist auf 2026-10-29 nachgezogen (sie fuehrte bis dahin +faelschlich noch alle sieben Schritte als offen, obwohl der Kopf dieser Datei +das Gegenteil sagt). + | Schritt | Inhalt | Stand | |---|---|---| -| 1 | Referenz-Journale erzeugen: in BricsCAD 2-3 typische Ketten je Modus (2 und 3) bauen, Zeichnung unter `tests/testdata/` ablegen. Abdecken: GF- und VF-Segmente, Bogen, AS/ES ja/nein, bei Modus 3 altes und neues AS/ES-Format | **offen** | -| 2 | Python-Lesepfad: `lib/vf_journal_export.py` (+ `vf_linienzug_grammatik.py`) lernen `linienzug2`/`linienzug3` mit `SEGS` (heute: "unbekannter Code") | **offen** | -| 3 | Spec-Form fuer Modus 2/3 festlegen (flaches JSON, lesbar von `ssg-load-json`, Segmente als Einzeiler) | **offen** | -| 4 | Python-Rundlauf `spec_aus_journal`/`journal_aus_spec` fuer Modus 2/3 in `lib/vf_spec_export.py`, Test in `tests/test_vf_spec.py`: Journal -> Spec -> Journal tokengleich | **offen** | -| 5 | LISP: `vsp-journal` je Modus (Dispatch ueber Spec-Feld `modus`), `vsp-pruefen` um Modus-2/3-Regeln erweitern | **offen** | -| 6 | `vsp-bau-journal`: Bau-Funktion nach Modus waehlen (`vf-linienzug-modus2`/`-modus3`), Ergebnis-Record wie Modus 1 (`prompts` = 0, `journal_diff` leer) | **offen** | -| 7 | CAD-Test analog `TEST_HUNDM05` + Eintrag in `tests/alltests.json`; file-freie Teile als `tu-*` in `tests/test_unit.lsp` | **offen** | +| 1 | Referenz-Journale erzeugen: in BricsCAD 2-3 typische Ketten je Modus (2 und 3) bauen, Zeichnung unter `tests/testdata/` ablegen. Abdecken: GF- und VF-Segmente, Bogen, AS/ES ja/nein, bei Modus 3 altes und neues AS/ES-Format | **fuer Modus 2 erledigt** (5 Ketten, `tests/testdata/linienzug_modus2_*.json`, abgespielt von `c:TEST_LINIENZUG_MODUS2`). Fuer Modus 3 auf Nutzer-Entscheidung 2026-10-29 **gestrichen** | +| 2 | Python-Lesepfad: `lib/vf_journal_export.py` (+ `vf_linienzug_grammatik.py`) lernen `linienzug2`/`linienzug3` mit `SEGS` (heute: "unbekannter Code") | **erledigt** (4a19ac0, Marker-Trennung + Rohtokens) | +| 3 | Spec-Form fuer Modus 2/3 festlegen (flaches JSON, lesbar von `ssg-load-json`, Segmente als Einzeiler) | **gestrichen** - siehe Entscheidung | +| 4 | Python-Rundlauf `spec_aus_journal`/`journal_aus_spec` fuer Modus 2/3 in `lib/vf_spec_export.py`, Test in `tests/test_vf_spec.py`: Journal -> Spec -> Journal tokengleich | **gestrichen** | +| 5 | LISP: `vsp-journal` je Modus (Dispatch ueber Spec-Feld `modus`), `vsp-pruefen` um Modus-2/3-Regeln erweitern | **gestrichen** | +| 6 | `vsp-bau-journal`: Bau-Funktion nach Modus waehlen (`vf-linienzug-modus2`/`-modus3`), Ergebnis-Record wie Modus 1 (`prompts` = 0, `journal_diff` leer) | **erledigt** (4a19ac0, Dispatch aus dem Journal statt per Spec-Feld) | +| 7 | CAD-Test analog `TEST_HUNDM05` + Eintrag in `tests/alltests.json`; file-freie Teile als `tu-*` in `tests/test_unit.lsp` | **als Journal-Replay erledigt** fuer Modus 2 (`c:TEST_LINIENZUG_MODUS2`), fuer Modus 3 gestrichen | ## Hinweise @@ -111,11 +115,30 @@ Segment-Antworten sind jetzt selbstbeschreibende Werte (`gf`/`vf`, gespeicherte Kette mehr um - genau das war beim Lauf-Anfang (833a4b6) real passiert. Bruchteil des Aufwands, gleicher Schutz. -### Noch offen +### Modus 3: abgeschlossen mit bewusst bleibendem Risiko (2026-10-29) -**Dasselbe fuer Modus 3.** Dessen Segment-Klassifizierung benutzt weiterhin -Menue-Ziffern. Bewusst nicht mit umgestellt: fuer Modus 3 gibt es kein -aufgezeichnetes Journal und damit kein Sicherheitsnetz - bei Modus 2 haben -die beiden Referenzketten bewiesen, dass Bestandsketten die Umstellung -unveraendert ueberstehen (sie tragen noch die alten Ziffern). Sobald eine -Modus-3-Kette aufgezeichnet ist, ist es dieselbe Mechanik. +**Dasselbe fuer Modus 3** - dessen Segment-Klassifizierung benutzt weiterhin +Menue-Ziffern ("1".."4", roh verglichen und genauso ins Journal geschrieben). +Nicht mit umgestellt wurde sie, weil fuer Modus 3 kein aufgezeichnetes Journal +und damit kein Sicherheitsnetz existiert - bei Modus 2 haben die +Referenzketten bewiesen, dass Bestandsketten die Umstellung unveraendert +ueberstehen (sie tragen bis heute die alten Ziffern). + +**Nutzer-Entscheidung 2026-10-29:** fuer Modus 3 wird VORERST kein Testfall +angelegt - *"bei Problemen im Einsatz testen wir und korrigieren dann"*. Die +Umstellung auf selbstbeschreibende Werte unterbleibt damit bis auf Weiteres, +und der Punkt ist aus `doc/todo.md` entfernt: er wartet nicht auf Arbeit, +sondern auf einen Anlass. + +Praktisch heisst das: Taucht in Modus 3 ein Fehler auf, der nach einer Kette +aus der Zeichnung heraus untersucht werden muss, ist der erste Schritt +`lib/vf_journal_export.py` auf diese Zeichnung - damit liegt genau das +Journal vor, das hier als Sicherheitsnetz fehlt, und die Umstellung waere +dann derselbe Handgriff wie bei Modus 2. + +Das Risiko bleibt aber bestehen und wandert dorthin, wo es gefaehrlich wird: +als Warnblock direkt ueber der Segment-Auswahl in `vf_linienzug.lsp` +(Suche nach "ACHTUNG beim Aendern der folgenden Auswahllisten"). Wer die +Modus-3-Optionen umsortiert, ergaenzt oder entfernt, deutet damit jedes +gespeicherte `linienzug3`-Journal still um. Eine TODO-Zeile haette diesen +Leser nicht erreicht, ein Kommentar an der Aenderungsstelle schon.