y.wang
989ee398ce
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>
145 lines
8.6 KiB
Markdown
145 lines
8.6 KiB
Markdown
# 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](plan-vf-interactive.md)
|
|
(dort Abschnitt 4.4, der hiermit ersetzt ist). Schwester-Auftrag:
|
|
[linienzug-ohne-gui.md](linienzug-ohne-gui.md) (Stufe 2).
|
|
|
|
## Ausgangslage
|
|
|
|
Der Daten-Pfad `VF_SPEC_BAU` ([vf_spec.lsp](../../Lisp/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.
|