docs: TODO-Stand nach der Modus-2-Arbeit nachgezogen

Vier Eintraege geprueft, drei davon betroffen:

- Spec-Uebersetzer Modus 2/3: Entscheidung dokumentiert, dass die Spec dort
  NICHT gebaut wird (SEGS macht die Journale selbst-enthalten), welche drei
  Schritte stattdessen umgesetzt wurden und warum die uebrigen gestrichen
  sind. Offen bleibt nur dasselbe fuer Modus 3 - dort fehlt ein
  aufgezeichnetes Journal als Netz.
- Achsenweise Laengen-Bilanz: teilweise entschaerft. AS-Element,
  Abschlussbogen+Motorstation und die Eck-Differenzen gehen seit ce4ad0f an
  das Segment, auf dem sie stehen - vfl-eck-extra ist bereits die hier
  geforderte Form (Zuschlag je Segment statt Skalar). SKALAR geblieben sind
  feste-vf und gf-total, und genau die verursachen den U-Form-Fehler; das
  Symptom bleibt also bestehen. Mit Hinweis, dass die neuen
  Zuschlags-Meldungen der schnellste Einstieg in die Diagnose sind.
- Linienzug ohne GUI, Schritt 11: war zurueckgestellt, bis echte
  Modus-2-Journale als Referenz vorliegen. Diese Vorbedingung ist erfuellt;
  der Schritt selbst bleibt offen.

Unveraendert: Stufe-3-Winkelwahl "Ab"-Zweig - von dieser Arbeit nicht
beruehrt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

doc/todo/linienzug-ohne-gui.md

@@ -55,7 +55,7 @@ veraltet).
 | **8** | Einheit-Abschluss: `vfl-vf-einheit-abschluss` (:7889) | **offen** |
 | **9** | Kettenebene, ein Glied-Zweig pro Commit: GF-Bogen -> ES -> Horizontal-VF -> Linie-GF -> Linie-VF -> Linie | **offen** |
 | **10** | `vfl-spec-ausfuehren` - der direkte Daten-Pfad (existiert noch nicht) | **offen** |
-| 11 | Dasselbe fuer Modus 2 | zurueckgestellt, bis 2-3 echte Modus-2-Journale als Referenz vorliegen |
+| 11 | Dasselbe fuer Modus 2 | **Vorbedingung erfuellt 2026-10-27**: zwei echte Modus-2-Journale liegen als `tests/testdata/linienzug_modus2_{variokurve,gfbogen}.json` vor, abgespielt von `c:TEST_LINIENZUG_MODUS2`. Der Schritt selbst ist noch offen |
 
 ## Warum es heikel ist
 

doc/todo/modus2-achsenweise-bilanz.md

@@ -126,3 +126,43 @@ Gefaltete VF-Laeufe (mehr als eine Achsenrichtung im VF-Bereich, z.B. U-Form)
 erkennen und mit klarer Meldung abweisen, statt still falsche Geometrie zu
 bauen - analog zur bereits vorhandenen "nur EIN VF-Lauf"-Abweisung
 (`vfl-m3-vf-lauf-alert`). Macht das Limit ehrlich sichtbar, kleiner Eingriff.
+
+---
+
+## Stand 2026-10-27 (nach Commit ce4ad0f)
+
+**Teilweise entschaerft, Kern bleibt offen.**
+
+Die Budget-Arbeit vom 26./27.10. hat genau das Prinzip eingefuehrt, das
+dieses Dokument fordert - aber nur fuer DREI Posten. Sie werden jetzt dem
+Segment zugeschlagen, auf dem sie physisch stehen, statt skalar von der
+Gesamtspanne abgezogen zu werden:
+
+| Posten | wie | Stelle |
+|---|---|---|
+| AS-Element | gemessener Fussabdruck, nur `vf-start` | `as-along-fix` |
+| Abschlussbogen + Motorstation | nur `vf-ende` | `abschluss-fp` |
+| Eck-Differenz (gezeichneter Bogen gegen Bauteil) | Alist je Segmentindex | `vfl-eck-korrekturen` / `vfl-eck-extra` |
+
+`vfl-eck-extra` ist dabei bereits die hier geforderte Form: ein Zuschlag **je
+Segment**, nicht ein Skalar fuer den ganzen Lauf. Er fliesst in alle vier
+Budgets (Spannweite, Kletterer, Fueller, Rueckanker).
+
+**Skalar geblieben sind genau die zwei Posten, die den U-Form-Fehler
+verursachen:**
+
+- `feste-vf` (Umlenkstation 500 + Separator 300, ggf. + Motor) - wird in
+  `vfl-zsolve-winkel-waehlen` als EIN Wert uebergeben
+- `gf-total` (GF1) - bei "alles am Einlauf" gross, und genau diese Summe
+  fehlt dem Kletterer im anderen Schenkel
+
+Das oben beschriebene Symptom (dY = +2645 mm) bleibt daher bestehen. Der
+naechste Schritt waere, diese beiden ebenfalls dem Segment zuzuordnen, auf
+dem sie stehen - also dieselbe Umstellung wie bei AS und Motorstation, nur
+fuer den Lauf-EINGANG.
+
+Hinweis zur Fehlersuche: Seit ce4ad0f meldet die Konsole jeden Zuschlag
+namentlich (`AS-Fussabdruck ... von Segment N abgezogen`,
+`Abschluss-Fussabdruck ...`, `Eck-Korrektur ... auf Segment N`). Eine
+FEHLENDE Zeile ist das Warnsignal - so wurde ein 2,4-mm-Rest gefunden. Fuer
+die U-Form-Diagnose sind diese Zeilen der schnellste Einstieg.

doc/todo/spec-modus2-3.md

@@ -1,5 +1,10 @@
 # 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).
 
@@ -61,3 +66,56 @@ AS/ES). Sie ist damit wie Modus 1 **ohne Zeichnung** pruefbar.
   `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.
+
+### Noch offen
+
+**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.