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>

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.