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>
125 lines
6.1 KiB
Markdown
125 lines
6.1 KiB
Markdown
# VF-Linienzug ohne GUI/Konsole - Stufe 2 (Funktionstrennung)
|
|
|
|
**Stand:** 2026-10-29 · **ZURUECKGESTELLT** - aus `doc/todo.md` entfernt, die
|
|
Datei bleibt als Fahrplan liegen.
|
|
|
|
## Warum zurueckgestellt
|
|
|
|
Stufe 2 sollte den **Journal-Replay-Umweg** ueberfluessig machen: Bauteile
|
|
direkt mit Daten aufrufen statt Fragen aus einer Queue beantworten zu lassen.
|
|
Dieser Umweg ist aber keiner mehr. Ein Linienzug-Journal traegt mit `SEGS` die
|
|
komplette Segment-Essenz und laesst sich OHNE Zeichnung abspielen - mit
|
|
derselben Begruendung wurde am 2026-10-27 bereits der Spec-Uebersetzer fuer
|
|
Modus 2/3 gestrichen (4a19ac0, `doc/todo/spec-modus2-3.md`). Die
|
|
Modus-2-Regressionstests (`c:TEST_LINIENZUG_MODUS2`, seit 2026-10-29 fuenf
|
|
Faelle) laufen headless ueber genau diesen Replay-Pfad: er ist nicht der
|
|
Engpass, sondern die funktionierende Loesung.
|
|
|
|
Dazu kommt das Risiko. Die offenen Schritte 5c/6/8/9/10 fassen den Code an, in
|
|
dem die REIHENFOLGE SELBST GEOMETRIE IST (siehe "Warum es heikel ist" unten) -
|
|
und ein Teil dieser Fehler ist in der Zeichnung unsichtbar und faellt erst im
|
|
Sivas-Export auf. Hoher Einsatz, kein Funktionsgewinn.
|
|
|
|
**Wieder aufnehmen, wenn** einer dieser Faelle eintritt:
|
|
- einzelne Bauteile sollen ohne Journal aufrufbar sein (z.B. ein Generator,
|
|
der Ketten aus Fremddaten baut und die Frage-Reihenfolge nicht kennen will);
|
|
- der Replay-Pfad wird zu langsam oder zu fehleranfaellig;
|
|
- `vfl-spec-ausfuehren` wird von irgendwo erwartet (heute: nirgends).
|
|
|
|
**Prioritaet beim Wiederaufnehmen:** niedrig - bringt Architektur, keine neue
|
|
Funktion.
|
|
|
|
Herausgeloester Arbeitsauftrag aus dem Gesamtplan
|
|
[plan-vf-interactive.md](plan-vf-interactive.md) (Teil 5 "Stufe 2: echte
|
|
Funktionstrennung"). Dort stehen die ausfuehrliche Begruendung, die
|
|
Knotenform und die Risikoliste; diese Datei ist die Abarbeitungsliste.
|
|
|
|
## Ausgangslage (Stufe 1, fertig)
|
|
|
|
Linienzug-Ketten lassen sich bereits ohne Dialog bauen (`VF_SPEC_BAU`,
|
|
[vf_spec.lsp](../../Lisp/vf_spec.lsp)) - allerdings ueber einen Umweg:
|
|
|
|
1. Die **Spec** (Kette in Domaenenwerten) wird von `vsp-journal` in ein
|
|
Eingabe-Journal uebersetzt - also in die Antworten, die ein Anwender
|
|
gegeben haette.
|
|
2. `vsp-bau-journal` startet per `vfl-journal-replay-start` den ganz normalen
|
|
interaktiven Bau `vf-linienzug-modus` ([vf_linienzug.lsp](../../Lisp/vf_linienzug.lsp)).
|
|
3. Jede Frage wird aus der Replay-Queue beantwortet.
|
|
|
|
Das funktioniert und ist per `TEST_HUNDM05` im CAD verifiziert - der Bau
|
|
selbst "weiss" aber nichts von Daten, er fragt weiter, nur antwortet die Queue.
|
|
|
|
## Ziel (Stufe 2)
|
|
|
|
Die Funktionen in `vf_linienzug.lsp` mischen **Fragen** und **Geometrie
|
|
bauen**. Stufe 2 trennt das:
|
|
|
|
- **reiner Bauteil** (Suffix `-bauen` bzw. `-setzen`): nimmt Parameter,
|
|
baut Geometrie, fragt nichts;
|
|
- die **Frage-Schale** behaelt den bisherigen Namen und ruft den Bauteil auf
|
|
- dadurch aendert sich keine Aufrufstelle in Modus 1/2/3.
|
|
|
|
Am Ende ruft `vfl-spec-ausfuehren` die Bauteile direkt mit den Spec-Werten
|
|
auf, ohne Journal-Replay.
|
|
|
|
## Stand der Schritte
|
|
|
|
Zeilennummern Stand 2026-10-26 (die `:NNNN`-Angaben im Gesamtplan sind
|
|
veraltet).
|
|
|
|
| Schritt | Inhalt | Stand |
|
|
|---|---|---|
|
|
| 0 | `vfl-ziel-report` (vf_linienzug.lsp:7864) aus zwei identischen Bloecken gezogen | erledigt |
|
|
| 1 | Winkelwahl `vfl-winkel-gueltige` (:3071) / `vfl-winkel-nach-index` + Kanal `*vfl-winkel-idx-vorgabe*` | erledigt |
|
|
| 2 | `vfl-es-masse-setzen` (:7557) | erledigt |
|
|
| 3 | `vfl-hor-koerper-bauen` (:5989), Schale `vfl-baue-horizontal-koerper` (:6152) | erledigt |
|
|
| 4 | `vfl-body-abschluss-bauen` (:6502) | erledigt |
|
|
| 5a/5b | VF-Einheit Eingang/Ausgang: `vfl-vf-eingang-bauen` (:6728), `vfl-vf-ausgang-bauen` (:6742) | erledigt |
|
|
| **5c** | Schleifenrumpf von `vfl-vf-einheit` (:6772) - die Sub-Stuecke der VF-Einheit als Bauteil | **offen** |
|
|
| **6** | Daten-Executor fuer die VF-Einheit (baut sie direkt aus Daten) | **offen** |
|
|
| 7 | Spec + Serializer + Assertion: `vsp-journal-diff` (vf_spec.lsp:900) prueft Spec-Journal gegen das beim Bau aufgezeichnete Token fuer Token | Assertion erledigt |
|
|
| **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 | **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
|
|
|
|
Bei den offenen Schritten ist die **Reihenfolge selbst Geometrie**
|
|
(Gesamtplan, Abschnitt "Wo Geometrie still kippen kann"), u.a.:
|
|
|
|
- die dL-Subtraktionskette ist je Schritt mit
|
|
`(max *vfk-restlaenge-min-clamp* ...)` geklammert, also
|
|
reihenfolgeabhaengig;
|
|
- die `vfl-acc-*`-Aufrufe muessen an derselben Stelle in derselben
|
|
Reihenfolge bleiben, sonst vertauschen sich `L_VF_m`/`L_GF_m`/`GF_WINKEL`
|
|
- in der Zeichnung unsichtbar, im Sivas-Export falsch;
|
|
- `*vfl-as-winkel*`/`*vfl-es-winkel*` werden lazy von den Blocknamen-Bauern
|
|
gelesen - spaeter gesetzt heisst falscher Block;
|
|
- `ziel-gf2` vs. `L_GF2-bau` im Ausgang - geht es verloren, entsteht still
|
|
die falsche GF2 hinter dem Motor.
|
|
|
|
Ausdruecklich nicht anfassen: siehe Gesamtplan, Abschnitt "Ausdruecklich
|
|
nicht anfassen" (u.a. alle Journal-Konsumenten, `vfl-in-*`-Wrapper,
|
|
Wizard-Schicht, Abbruch-Pfad).
|
|
|
|
## Ablauf je Schritt
|
|
|
|
1. Umbauen (Frage-Schale behaelt Namen, Bauteil wortwoertlich umziehen,
|
|
keine Umsortierung).
|
|
2. CAD-Lauf: `TEST_HUNDM05` (save dxf), `TEST_VF_SPEC`, `TEST_LINIENZUG`.
|
|
3. `pytest tests/test_vf_geometrie.py` gegen
|
|
`tests/reference/hundm05_attribute.json` - nennt bei Abweichung Kette
|
|
und Feld. Referenz nur nach geprueftem Lauf auffrischen
|
|
(`lib/dxf_vf_abbild.py --schreibe-referenz`).
|
|
4. Nach Geometrie-Schritten (5c, 9) zusaetzlich DXF-Diff und
|
|
Sivas-Export-Vergleich.
|
|
5. Ein Schritt pro Commit - sonst ist ein Fehler keinem Schritt mehr
|
|
zuzuordnen.
|
|
|
|
## Wann angehen
|
|
|
|
Erst bei konkretem Bedarf: einzelne Bauteile ohne Journal aufrufen, oder der
|
|
Replay-Umweg wird zu langsam bzw. zu fehleranfaellig. Bis dahin genuegt
|
|
Stufe 1.
|