docs: zentrale TODO-Liste doc/todo.md, woechentliche Doku-Pruefung in CLAUDE.md

- doc/todo.md sammelt alle offenen Punkte (VF/Linienzug, Export, Geruest,
  Omniflo, ILS, Tests, spaetere Meilensteine); detaillierte Fahrplaene in
  doc/todo/*.md und cfg/sivas_merkmal_zuordnung.md nur kurz verlinkt
- CLAUDE.md: Konvention "Woechentliche Doku- und TODO-Pruefung (freitags)"
- CLAUDE.md/README.md verweisen auf doc/todo.md

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

CLAUDE.md

@@ -180,6 +180,7 @@ Werden via `bin/setenv.bat` gesetzt. Wichtigste:
 - **Wiederverwendung vor Neuschaffung bei LISP-Routinen**: Neue Funktionen moeglichst als Erweiterung/Ergaenzung bestehender Funktionen anlegen. Bevor eine NEUE Bibliothek (`.lsp`-Datei) geschaffen wird, immer zuerst pruefen, ob es bereits thematisch passende Routinen gibt, in die die Funktionalitaet gehoert (z.B. Einfuege-Primitiven in `ssg_ks_insert.lsp`, Kern-Helfer in `ssg_core.lsp`, Konstanten in `vf_konstanten.lsp`). Erst wenn nichts passt, ein neues Modul.
 - **Neue LISP-Routinen nach Moeglichkeit in die LISP-Testsuite aufnehmen**: Jede neue LISP-Routine soll moeglichst einen Test bekommen. **Vorrang haben Routinen, die OHNE Zeichnung/Dateien testbar sind** (reine Berechnung, Parser, String-/Listen-Helfer, cfg-/JSON-Aufloesung) - die gehoeren als `tu-*`-Testblock in `tests/test_unit.lsp` (Befehl `TEST_UNIT`), der komplett file- und zeichnungsfrei laeuft. Zeichnungs-/geometrieabhaengige Routinen ueber ein Szenario-Modul (`tests/test_<name>.lsp` + Eintrag in `tests/alltests.json`, ausgefuehrt von `SSG_RUN_ALL_TESTS`) abdecken. Die reinen Berechnungspfade einer solchen Routine trotzdem, wo moeglich, zusaetzlich als file-freien Unit-Test herausziehen.
 - **Headless-Testlauf**: Die Unit-Tests laufen ohne GUI ueber `bin/run_tests.bat --lisp` - das startet BricsCAD im Batch-Modus (`/nologo /b`) mit `tests/test_unit.scr` und fuehrt `TEST_UNIT` aus. **BricsCAD steht dafuer ueber die Umgebungsvariable `BRICSCAD` zur Verfuegung** (in `bin/setenv.bat` gesetzt, auf die installierte `bricscad.exe` zeigend); `run_tests.bat` bricht mit Hinweis ab, wenn sie fehlt. Ein neuer file-freier Unit-Test ist damit auch ohne interaktive BricsCAD-Sitzung fahrbar. (Python-seitige Tests siehe `.venv` + `pytest tests/`.)
+- **Woechentliche Doku- und TODO-Pruefung (freitags)**: Einmal pro Woche, am besten freitags in einer Sitzung mit dem Benutzer, werden `README.md`, `CLAUDE.md`, `Lisp/README.md`, `tests/README.md` und alle `doc/*.md` (inkl. `doc/plan/`, `doc/todo/`) auf Aktualitaet geprueft: stimmen Befehle, Dateien, Funktionen und Menuestruktur noch mit dem Code (`menu/SSG_LIB.mnu`, `defun c:`-Liste) ueberein? Dabei die zentrale TODO-Liste `doc/todo.md` durchgehen - Erledigtes entfernen, neu Hinzugekommenes eintragen, Fahrplaene in `doc/todo/*.md` nur loeschen, wenn sie vollstaendig erledigt sind. Ergebnis kurz mit dem Benutzer abstimmen, dann committen.
 - **Regelmaessiges Tote-Code-Review**: Wiederkehrend auf tote/nicht mehr verwendete LISP-Routinen pruefen und aufraeumen - vorzugsweise zu Wochenbeginn, wenn in der betreffenden Woche ohnehin an den LISP-Routinen gearbeitet wird.
 - **Wiederherstellungs-/Editierdaten gehoeren in XDATA/Journal, nicht in `.dbg`**: Alles, was zum Neuaufbau/Editieren eines Blocks noetig ist (z.B. das VF-Linienzug-Eingabe-Journal `SSG_VF_EDIT`), wird als XDATA am Block gefuehrt. Die `.dbg`-Dateien (`ssg_dbg.lsp`) sind reine AUSGABE, werden von keinem Befehl gelesen und bei jedem Lauf neu angelegt - nie als Datenquelle nutzen.
 - **Editierbarkeit: festes Schema vs. Sektions-Ruecksprung**: Konstrukte mit FESTER Feldstruktur (feste Anzahl/Typen von Werten, z.B. AS/ES/GF-Bogen/Vario-Kurve im VF-Linienzug) ueber ein deklaratives Schema als einzeln editierbare Records fuehren (Einzel-Glied-Edit per Feld-Splice). Konstrukte mit VARIABLEM Dialog-Fluss (datenabhaengige Feldzahl, z.B. Horizontal-Koerper/Auf-Ab-Foerderer) NICHT per fragilem "n Felder abschneiden"-Splice editieren, sondern per Sektions-Ruecksprung: ab dem gewaehlten Glied zuruecksetzen und live neu aufbauen. Ein fester Splice ueber eine datenabhaengige Feldgrenze ist genau das Muster des Winkel-Index-Bugs.
@@ -230,7 +231,7 @@ Abhaengigkeiten: `ezdxf`, Standard-Library. Benoetigen Umgebungsvariablen (`DXFM
 ## Entwicklungsstand
 
 Siehe `doc/plan/Entwicklungsplan.md` fuer Meilensteinplanung und Aufwandsschaetzung.
-Fertig (DONE, Stand 2026-10-26): ILS Kreisel, ILS Eckrad, ILS Variofoerderer (Standard/Etage/Linienzug), ILS Gefaellestrecke, ILS BTMT Be-/Entladung, Geruest (Rohrabhaenger, Saeulen, Wandbefestigung, Traeger), Omniflo Boegen, Weichen, Verbinder, Fahrstrecke, Ladeschleifen, Kettenfoerderer, CSV-/Sivas-Export. Offen u.a.: Gattertraeger, Omniflo-Boegen fuer Weichen (`OMNI_APBW_*`, Dummy), eigenstaendige ILS-Weichen-/Kurvengeometrie. Offene Fahrplaene: `doc/todo/`.
+Fertig (DONE, Stand 2026-10-26): ILS Kreisel, ILS Eckrad, ILS Variofoerderer (Standard/Etage/Linienzug), ILS Gefaellestrecke, ILS BTMT Be-/Entladung, Geruest (Rohrabhaenger, Saeulen, Wandbefestigung, Traeger), Omniflo Boegen, Weichen, Verbinder, Fahrstrecke, Ladeschleifen, Kettenfoerderer, CSV-/Sivas-Export. Offen u.a.: Gattertraeger, Omniflo-Boegen fuer Weichen (`OMNI_APBW_*`, Dummy), eigenstaendige ILS-Weichen-/Kurvengeometrie. Alle offenen Punkte: `doc/todo.md` (Detail-Fahrplaene in `doc/todo/`).
 
 ## Debug
 Wenn Werte für das Debug in der Bricscad Konsole ausgegeben werden z.B. mit princ, soll der Benutzer dazu ermuntert werden, statt dessen die Lisp dbg Routinen zu verwenden, welche dann eine .dbg file im log folder erzeugen. Diese können ja über eine zentrale globale Sammlung von Schalter an und abgeschaltet werden, so dass die Files per default auch nicht geschrieben werden, nur wenn der passende Schalter auf 1 gesetzt wird. Damit können debug aufrufe auch im Code verbleiben.