docs: Spec-Uebersetzer und Stufe-2-Funktionstrennung abgeschlossen

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>
This commit is contained in:
2026-10-29 14:38:39 +01:00
parent b709f89404
commit 989ee398ce
4 changed files with 95 additions and 34 deletions
+29
View File
@@ -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")
-17
View File
@@ -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.
+29 -3
View File
@@ -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
+37 -14
View File
@@ -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.