Weichenknoten zwischen Kreiseln, Track-Mouseover, Parameter in cfg/parameter.ini

TRO-Typen an Kreisel-Beruehrpunkten (lib/kreisel_junctions.py, derive_tros
Schritt 3c): jeder Kreisel als Stadion-Form mit Laufrichtung; jeder
gleichlaufende Beruehrpunkt ist eine Weiche (exportierte ILS Weiche oder
abgeleitet W<a>_<b>), Beruehrpunkte derselben Umlenkung bilden einen
Knoten. Ein Separator steuert ihn, wenn er in Laufrichtung unmittelbar
davor liegt (keine andere Weiche dazwischen). Typ = Separatoren x Weichen.
export.csv: 1Sep1Swi (9/1, 9/8, 8/7), 2Sep1Swi (7/2), 2Sep2Swi (2/3/4),
3Sep2Swi (4/5/6). Neuer Katalogtyp 3Sep2Swi (nicht aus SCL belegt).
Gegenlaeufige Beruehrpunkte (Mubea, Dematic) bleiben bei der alten Regel;
Mubea/HundM05/Dematic unveraendert, Showroom 0018+0019 jetzt 2Sep1Swi.

material_flow --track: Mouseover je Knoten mit Zugehoerigkeit zu
Kreisel/VF/GF (Zuordnung, TrackIds-Kette, Lage laut Geometrie), Weiche mit
beiden Kreiseln, Be-/Entladung mit ihrem Kreisel; Widersprueche mit "!".

Zahlenwerte (Toleranzen, Schwellen, Massstaebe, Groessen) aus allen
lib-Modulen nach cfg/parameter.ini (lib/parameter.py, Abschnitt je Modul,
Ueberschreiben je Anlage ueber %SKEL_CFG%/parameter.ini). Ausgaben aller
Anlagen bytegleich.

tro_flow.py: Docstrings mit Parametern/Rueckgabe, fehlende Typangaben.

Geprueft: 90 Tests gruen; tro_flow/material_flow/scl_skeleton auf 5 CSVs.

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

CLAUDE.md

@@ -37,6 +37,8 @@ Template" below). What exists today is:
 - `cfg/dxf_registration.json` — persisted, verified CSV↔DXF coordinate transform;
   `cfg/tro_overrides.ini` — hand-maintained corrections to the derived TROs (see `tro_overrides.py`);
   `cfg/e_planning.ini` — project-specific rules for assigning E-planning symbols to layout parts;
+  `cfg/parameter.ini` — tolerances, thresholds, scales and drawing sizes of the `lib/` modules
+  (read by `lib/parameter.py`; no numeric settings in the code, see `doc/Python_Scripts.md` §7a);
   `cfg/<csv>_tro_ids.ini` — per-plant TRO-ID file (versioned, IDs renamed by the SPS
   programmers), created/extended by `tro_flow.py` via `lib/tro_ids.py`
 - `doc/*.md` — analysis documents that reverse-engineer the SCL patterns and propose the
@@ -95,8 +97,9 @@ this order for onboarding:
 
 0. **`doc/Python_Scripts.md`** — the existing CLI tooling (`lib/material_flow.py`,
    `lib/tro_flow.py`, `lib/tro_annotate.py`, `lib/tro_extract.py`, `lib/scl_skeleton.py`,
-   `lib/e_planning.py`, plus the `lib/tro_catalog.py`, `lib/model.py`, `lib/dxf_registration.py` and
-   `lib/tro_overrides.py` libraries they share): what each script does, its switches, inputs/outputs. This is
+   `lib/e_planning.py`, plus the `lib/tro_catalog.py`, `lib/model.py`, `lib/dxf_registration.py`,
+   `lib/kreisel_junctions.py` (switches between touching Kreisel, from geometry and direction
+   of travel) and `lib/tro_overrides.py` libraries they share): what each script does, its switches, inputs/outputs. This is
    working code, not a proposal — read it before touching `lib/`.
 1. **`doc/HundM/Json_Layout-Konzept.md`** — the core proposal: a JSON file as single source
    of truth (`plc`, `controlUnits`, `sensors[]`, `conveyors[]`, `tros[]`, `loadingBooms[]`,