Files

T

y.wang 989ee398ce 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>

2026-10-29 14:38:39 +01:00

8.6 KiB

Raw Blame History

TODO: Spec-Uebersetzer fuer VF-Linienzug Modus 2 und 3

Stand 2026-10-27: Auftrag weitgehend erledigt bzw. bewusst gestrichen. Siehe Abschnitt "Entscheidung 2026-10-27" am Ende. Der Text darunter ist die urspruengliche Planung und bleibt als Begruendung stehen - er beschreibt NICHT mehr den offenen Stand.

Stand: 2026-10-26 · Prioritaet: mittel - einzige fehlende FUNKTION im Daten-Pfad (Modus-2/3-Ketten sind nur interaktiv baubar).

Herausgeloester Rest von Stufe 1 aus plan-vf-interactive.md (dort Abschnitt 4.4, der hiermit ersetzt ist). Schwester-Auftrag: linienzug-ohne-gui.md (Stufe 2).

Ausgangslage

Der Daten-Pfad VF_SPEC_BAU (vf_spec.lsp) kann nur Modus 1:

vsp-journal (vf_spec.lsp:568) kennt nur den Fragenfluss/die Menue-Codes von vf-linienzug-modus (z.B. *vsp-tab-gf-laenge-modus*, :56).
vsp-bau-journal (:939) ruft fest vf-linienzug-modus auf (:978).

Modus 2 (vf-linienzug-modus2, Pfad + Zielhoehe, Marker "linienzug2") und Modus 3 (vf-linienzug-modus3, Vorwaerts-Nachbau, Marker "linienzug3") fragen grundlegend anders: erst Pfad-Auswahl (vfl-in-segmente), dann je Segment ein Klassifizierungs-Dialog (vflw_seg_linie_m2/_m3, vflw_seg_bogen). Dafuer gibt es weder Uebersetzer noch Bau-Aufruf.

Doppelklick-Edit/Neuaufbau funktioniert fuer beide Modi bereits (vfl-edit-ent-voll) - es fehlt nur der Bau aus einer Spec-Datei.

Korrektur des alten Entwurfs (Plan 4.4, Stand 2026-09-02)

alter Entwurf	heute (seit 2026-09-18)
Modus-2-Spec traegt `pfad-handles` (Entity-Handles, Journal-Art `OBJS`), vor dem Bau gegen die reale Zeichnung geprueft	Modus 2 UND 3 journalisieren die Segment-Essenz als Journal-Art `SEGS`: je Segment 9 Felder `typ hz laenge bwinkel bseite spx spy epx epy` (`vfl-segs->string`/`vfl-string->segs`, vf_linienzug.lsp). Die Kette ist selbst-enthalten, die Original-LINE/ARC werden nicht mehr gebraucht
Modus 3 ohne Journal-XDATA, kein Doppelklick-Edit, keine 2D/3D-Konvertierung; Nachruestung zurueckgestellt	Modus 3 schreibt Marker `"linienzug3"` und ist per Doppelklick editierbar
"Eine Gerade direkt nach einer Vario-Kurve wird nicht gefragt - der Uebersetzer leitet das ab"	gilt vermutlich weiter, am echten Journal pruefen

Folge fuer den Entwurf: Die Spec fuer Modus 2/3 traegt eine Segmentliste statt Objekt-Handles plus die Klassifizierung je Segment (Typ, GF-Neigung bzw. Wert, Bogen-Variante) und die Praeambel (Startpunkt, Starthoehe, 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	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

Korrektheitskriterium Modus 3 ist "gleiches rein, gleiches raus", NICHT "trifft den Zielpunkt" - der Ist/Soll-Ende-Report weicht schon im interaktiven Bau ab.
Alte "linienzug2"-Bloecke mit OBJS-Journal (vor 2026-09-18) sind nicht mehr editierbar und taugen NICHT als Referenz.
Neue vfl-in-*-Wrapper mit ssget/get* im statischen Waechter tests/test_vf_headless_statisch.py eintragen.
Werte selbstbeschreibend in der Spec (Winkel 30/60/90, nicht Index) - siehe CLAUDE.md, Konventionen.

Entscheidung 2026-10-27 (nach Commit `4a19ac0`)

Die Spec fuer Modus 2/3 wird NICHT gebaut. Der Grund ist erst durch den Modus-2-Regressionstest (cf626d7) sichtbar geworden:

Modus-2/3-Journale tragen mit SEGS die komplette Segment-Essenz und sind damit ohne Zeichnung abspielbar - vfl-journal-replay-start + vf-linienzug-modus2 genuegt, wie c:TEST_LINIENZUG_MODUS2 zeigt. Der Hauptnutzen einer Spec (Domaenenwerte statt Menue-Codes) faellt damit weitgehend weg: SEGS ist bereits Geometrie im Klartext, kein Menue-Code.

Fuer Modus 1 bleibt die Spec sinnvoll - dessen Journal besteht aus Menue-Ziffern ("5" = "Neue Linie BIS Kettenende"), die ohne Uebersetzung unlesbar sind.

Umgesetzt (die lohnenden Teile)

Schritt	Stand
1 Referenz-Journale	erledigt - `tests/testdata/linienzug_modus2_{variokurve,gfbogen}.json`, aus einem echten Lauf
2 Python liest `linienzug2`/`3`	erledigt - `vf_journal_export.py` trennt nach Marker, Modus 2/3 als Rohtokens. Vorher lief die Modus-1-Grammatik auch darueber und brach ab
6 Bau-Funktion nach Modus	erledigt - `vsp-bau-fn-fuer-journal` leitet sie aus dem Journal ab (kein SEGS = 1, SEGS + Marke `m2v2` = 2, SEGS ohne = 3)
7 CAD-Test	erledigt als Journal-Replay statt als Spec-Test: `c:TEST_LINIENZUG_MODUS2`, zwei Varianten derselben Strecke

Gestrichen

Schritte 3, 4 und 5 (Spec-Form, Python-Rundlauf, vsp-journal je Modus). Sie lohnen erst, wenn jemand Modus-2/3-Ketten aus EXTERNEN Daten erzeugen will - heute tut das niemand. Selbst dxf_anlage_export.py schreibt fuer Modus-1-Linienzuege das Journal unveraendert durch ("typ": "linienzug_journal") statt eine Spec zu bauen.

Stattdessen: das eigentliche Risiko direkt entschaerft

Die Spec haette eine echte Schwachstelle abgedeckt - positionsabhaengige Menue-Ziffern im Journal. Das ist stattdessen an der Quelle geloest: die Segment-Antworten sind jetzt selbstbeschreibende Werte (gf/vf, gf-bogen/vario-kurve, aussen/innen, gemeinsamer Normalisierer vfl-wert-norm). Ein Umsortieren der Optionen deutet damit keine gespeicherte Kette mehr um - genau das war beim Lauf-Anfang (833a4b6) real passiert. Bruchteil des Aufwands, gleicher Schutz.

Modus 3: abgeschlossen mit bewusst bleibendem Risiko (2026-10-29)

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.

8.6 KiB Raw Blame History