E-Planung -> Layout: e_planning.py, scl_skeleton --eplan, Kapitel Daten

- doc/Klassenhierarchie.md: Kapitel "Daten" - alle Daten der SCL-Referenzen
  nach Quelle (Layout, E-Planung, Namenskonvention, Parameter)
- doc/E-Planung_Bruecke.md: Bruecke ueber *_positionsdraw.json des
  Kabellaengen-Tools, Befunde an Mubea
- lib/e_planning.py + cfg/e_planning.ini + bin/e_planning.bat/.sh:
  Lagebezug E-Zeichnung -> CSV, Zuordnung BMK -> Layout-Bauteil nach Regeln
  (Abstand, Sollabstand, Nummernregel MB = BG + 1), <csv>_eplan.json + Bericht
- scl_skeleton --eplan: Separator-Sensor und Stopperventil eingesetzt,
  ohne Schalter unveraenderte Ausgabe (Golden-Files gleich)
- tests/test_e_planning.py

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

CLAUDE.md

@@ -27,13 +27,16 @@ Template" below). What exists today is:
   tool in `lib/` (see "Environment scripts" below)
 - `lib/*.py` — CLI tools and libraries that turn a CSV export into a material-flow graph,
   a derived TRO list/diagram, a TRO-JSON (`lib/model.py`), an `FB_Main` SCL skeleton, and
-  (with the BricsCAD DXF) an annotated copy of the drawing for visual checking.
+  (with the BricsCAD DXF) an annotated copy of the drawing for visual checking;
+  `lib/e_planning.py` assigns the E-planning's sensors/valves (from the cable-length
+  tool's `*_positionsdraw.json`) to the layout parts so the skeleton can carry real names.
   See **`doc/Python_Scripts.md`** for what each script does and which switches it takes.
 - `data/` — input CSV exports (gitignored, not committed)
 - `cad/tro_types.lsp` — generated type list for the BricsCAD `TROEDIT` dialog (written by
   `tro_annotate.py --emit-lisp`)
 - `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/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
 - `doc/*.md` — analysis documents that reverse-engineer the SCL patterns and propose the
   fuller JSON layout schema for the parts of the pipeline still to be built out
 
@@ -90,7 +93,7 @@ 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`,
-   plus the `lib/tro_catalog.py`, `lib/model.py`, `lib/dxf_registration.py` and
+   `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
    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
@@ -182,6 +185,13 @@ byte — rewrite them (`SKEL_UPDATE_GOLDEN=1`) only for a reviewed, intended cha
    `sps_skel-tro-extract-v1` JSON, which `scl_skeleton.py` no longer accepts. Not deleted, not
    extended; if drawing edits (`TRO_INSERT`/`TRO_EDIT`) are ever needed again, it should
    write `model.TroDocument`. See `doc/Python_Scripts.md` §5a.
+5. **`lib/e_planning.py`** (implemented, first version) — CSV + E-planning
+   `*_positionsdraw.json` → `<csv>_eplan.json` (`EplanDocument`): registers the E drawing to
+   the CSV (`dxf_registration.py`) and assigns BMKs to layout parts by rules in
+   `cfg/e_planning.ini` (distance, target distance, numbering rule `MB = BG + 1`).
+   `scl_skeleton.py --eplan` fills separator sensor and stopper valve from it; jam sensors
+   and outfeed/switch valves are assigned but not yet placed in the SCL. See
+   `doc/Python_Scripts.md` §5c and `doc/E-Planung_Bruecke.md`.
 
 What is **not** built out yet, relative to the original two-tool design: