# 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.