Files

T

y.wang f2a5f6ca75 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>

2026-10-27 12:12:50 +01:00

6.9 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

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

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.

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.

6.9 KiB Raw Blame History