Merge e-planung-bruecke: stabile TRO-IDs, TRO-JSON v4, E-Planung-Bruecke

Uebernimmt Michael Stangls Zweig (tro_ids, Slots/jamAreas v4, e_planning
--eplan, Konzept- und Datenquellen-Doku) in master, auf dem seitdem die
SCL-Templates fuer alle 7 Typen mit Referenz-Aufrufstelle liegen.

Konfliktloesung:
- lib/scl_context.py: beide Seiten zusammengefuehrt - Michaels _separator
  (E-Planung-Namen) und Staubereiche (_entries/_exit_area, ein JamEntr je
  eigenem Staubereich) plus die Template-Felder (_scanner, _store,
  carriers/data, part_sensor). _jam() fuehrt jetzt auch jam_id. Die beim
  automatischen Zusammenfuehren verlorene Property SclJam.title
  wiederhergestellt.
- Templates 1Sep, 1Sep2Swi, 1Sep_SSCC, Vario, Vario_workStation, PinStore_Auto
  auf v4 nachgezogen: Kommentar "Staubereich J.... von/vor ..." wie im
  Pilot; PinStore-TODO zaehlt Staubereiche statt Nachbarn (mubea: 2 Zulaeufe
  laufen in einen Eingang).
- Golden-Files *_templates neu erzeugt; geaendert sind ausschliesslich
  Staubereichs-Zeilen (Kennung im Kommentar, ein Eingang statt einem je
  Vorgaenger). Generische Golden-Files = Michaels Stand.
- Neuer Test: E-Planung-Namen kommen auch in der Template-Ausgabe an.
- Doku: README Schema v4, SCL_Templates.md Staubereiche und TODO-Zahlen.

Geprueft: 71 Tests gruen; tro_flow --json + scl_skeleton --templates auf
allen 8 CSVs ohne Fehler.

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

CLAUDE.md

@@ -27,13 +27,18 @@ 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;
+  `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
   fuller JSON layout schema for the parts of the pipeline still to be built out
 
@@ -90,7 +95,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
@@ -135,6 +140,16 @@ this order for onboarding:
    its generated images come from `doc/TRO_Katalog/tro_graphs/gen_tro_graphs.py`
    (doc-tooling, not part of the generator — see `doc/Python_Scripts.md` §8) built from
    `doc/TRO_Katalog/connect.ini`.
+9. **`doc/Datenquellen_Layout_Hardwareplanung.md`** — which TRO/SCL data comes from the
+   mechanical layout (CSV), which from the hardware planning (EA list, TIA import,
+   WSCAD, `positionsdraw`) and which is a default; two reference call sites annotated
+   line by line. The full raw field lists of both sources are in
+   `doc/Klassenhierarchie.md`, chapter "Daten".
+10. **`doc/Konzept_Layout_Hardware_SCL.md`** — the target workflow (planned, not built):
+    layout → `<csv>_tro.json` (with slots, `jamAreas`), hardware planning →
+    `hw_import.py` → `<projekt>_hw.json`, `hw_assign.py` → `<csv>_anlage.json`,
+    then `scl_skeleton.py`; what happens to `e_planning.py` (split),
+    `tro_annotate.py` (viewer reading the JSON) and `tro_extract.py` (dropped).
 
 ### Used libraries (referenced but not vendored)
 
@@ -167,8 +182,12 @@ and status: `doc/SCL_Templates.md`. Golden files in `tests/fixtures/scl/` pin th
 byte — rewrite them (`SKEL_UPDATE_GOLDEN=1`) only for a reviewed, intended change.
 
 1. **`lib/tro_flow.py --json`** (implemented) — writes `<csv>_tro.json` (schema
-   `sps_skel-tro-v3`, `model.TroDocument`): TROs, system boundaries `SYSn`, connections with
-   their kind, findings. See `doc/Python_Scripts.md` §4.
+   `sps_skel-tro-v4`, `model.TroDocument`): TROs with their hardware `slots`, system
+   boundaries `SYSn`, connections with their kind, `jamAreas` (one per TRO entry, key
+   `J<Separator>`, all predecessors that feed it), findings. TRO-IDs come from `cfg/<csv>_tro_ids.ini` (`lib/tro_ids.py`): each
+   TRO is found again by the position of its separators, so IDs survive a new layout export
+   (TeileIds do not); `--renumber` renumbers along the material flow, `--ids` points another
+   export of the same plant at the same file. See `doc/Python_Scripts.md` §4.
 2. **`lib/scl_skeleton.py`** (implemented) — reads that TRO-JSON through `TroDocument` (a
    wrong/renamed key or `items` not matching the catalog stops the run) and emits an `FB_Main` SCL
    skeleton (`<source>_FB_Main.scl`): one `REGION` per TRO with the instance call and every
@@ -184,6 +203,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: