scl_skeleton: Anlagen-JSON als Eingabe (Stufe 4, Namen)

--json erkennt <csv>_anlage.json am Schema. scl_context.HwSource setzt
Namen aus bindings (nur "zugeordnet") und conveyors ein: Separator-,
Lagerlinien-, Weichen- und Vario-Antriebsnamen, #fbCarousel<NNNN> am
Kreisel, Foerderernummer im DB_JamArea-Platzhalter (<k> bleibt offen).
Eingesetzte Namen werden gegen <projekt>_hw.json geprueft (--hw,
--strict bricht ab). --eplan bleibt fuer die TRO-JSON; Templates und
Golden-Files unveraendert.

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

doc/Python_Scripts.md

@@ -46,11 +46,13 @@ tro_flow.py       ──►  <name>_tro_flow.dot / .svg, _tro_doc.md, _tro_error
    │                  (assigns BG/MB of the E-planning drawing to the layout
    │                   parts by position + numbering rule; see §5c)
    │
-   │   NEW PATH (stages 2/3, scl_skeleton does not read it yet):
+   │   NEW PATH (stages 2-4):
    │   <name>_tro.json ──┐
    │                     ├─► merge_hw_layout.py ──► <name>_anlage.json + .md   (§5e)
    │   hw_import.py ─────┘   (TRO slots <- BMK, conveyors K0102 -> Kreisel3)
    │     ▲ *_TIA.xlsx + *_positionsconv.json            (§5d)
+   │   <name>_anlage.json ──► scl_skeleton.py --json ──► <name>_FB_Main.scl
+   │                          (names from the bindings; replaces --eplan)
    │
    └── same derivation ──► tro_annotate.py ──► <name>_annotated.dxf  (VIEWER ONLY)
           (also needs the BricsCAD DXF; uses dxf_registration.py for the CSV↔DXF
@@ -114,6 +116,7 @@ bin\tro_flow.bat --file mubea.csv --tosvg --use-cords --doc --json
 bin\scl_skeleton.bat --json mubea_tro.json
 bin\e_planning.bat --file mubea.csv --eplan Mubea_positionsdraw.json
 bin\scl_skeleton.bat --json mubea_tro.json --eplan mubea_eplan.json
+bin\scl_skeleton.bat --json mubea_anlage.json --templates
 bin\tro_annotate.bat --file mubea.csv --dxf 500573_60_1.dxf --flow --fb --legend
 ```
 
@@ -532,8 +535,10 @@ exits, how they divide them is a planning decision, so it stays a gap rather
 than a guess.
 
 Switches: `--json NAME` (default `export_tro.json`, looked up in
-`%SKEL_RESULTS%`; written by `tro_flow.py --json`), `--out NAME` (default
-`<source>_FB_Main.scl`), `--eplan NAME` (see below), `--start TRO`. The last one matters while the plant has
+`%SKEL_RESULTS%`; either the TRO-JSON from `tro_flow.py --json` or the plant
+JSON from `merge_hw_layout.py`, told apart by its `schema`), `--out NAME`
+(default `<source>_FB_Main.scl`, `_tro`/`_anlage` dropped from the source
+name), `--eplan NAME` and `--hw NAME` (see below), `--start TRO`. The last one matters while the plant has
 no loading/unloading station: the flow is then a closed loop with no entry, so
 the order has to be broken somewhere arbitrary. The chosen start and the reason
 are recorded in the file header.
@@ -551,8 +556,9 @@ shows up as a destination in the per-switch lists.
 (`build_context` → `SclFile` / `SclTro`: flow order, separator/switch/scanner
 blocks, jam entries/exits, destination lists, names), and `scl_skeleton.py` only
 turns that context into text (`render_context`). Every name or address is an
-`SclName` (value + `todo` flag); today all of them are placeholders with
-`todo=True`. This split prepares the move to parameterised templates and
+`SclName` (value + `todo` flag); without hardware planning all of them are
+placeholders with `todo=True`. Real names come from `scl_context.HwSource`
+(plant JSON or, phasing out, the eplan assignment). This split prepares the move to parameterised templates and
 per-project naming rules described in [`SCL_Templates.md`](SCL_Templates.md).
 
 **Templates (opt-in, `--templates [DIR]`).** With this switch every TRO whose FB
@@ -567,7 +573,30 @@ by a PLC engineer (`doc/SCL_Templates.md` §6). `2Sep1Swi`, `EmptyCarrBuffer`,
 `LoadingBoom` and `2Sep2Swi` have no call site yet and stay generic. `--strict` stops (exit `1`, no SCL) if any FB type has no
 template. Without `--templates` the output is unchanged.
 
-**Names from the E-planning (opt-in, `--eplan NAME`).** Reads the assignment
+**Names from the plant JSON (stage 4, `--json <csv>_anlage.json`).** The
+layout is `anlage.layout`; names come from `bindings[]` by TRO-ID + slot + role
+(`AnlageDocument.binding`), and only status `zugeordnet` counts — `offen` and
+`widerspruch` stay `TODO(E-Planung)`. Sensors are written as the TIA constant
+(`Binding.constant`, e.g. `cInBG0642`), outputs as the BMK (`MB0643`).
+
+| Slot / role | SCL |
+|---|---|
+| `separator<n>` `sensor` / `stopper` / `partSensor` | `stSenInSep`, `xOutStopper<n>`, `stSenPart` |
+| `line<n>` `sensor` / `stopper` / `jamSensor` | PinStore storage lines |
+| `switch<n>` `valve` | `xOutSw<n>ExTo3` |
+| `drive` `motor` / `motorProtection` / `sen*` | Vario motor, `xInMotorProtection`, `stSenCarrInPos` … (motor/protection fall back to the conveyor of the TRO's host) |
+| `conveyors[]` on the TRO's host | `xInCarouselRun` = `#fbCarousel<NNNN>.xOutConveyorFullSpeed` (Kreisel only); jam DB `"DB_JamArea<NNNN>".stJam<NNNN>_____` — still `TODO`, the running number `<k>` is not fixed yet |
+
+Not filled yet: jam sensors at the exits (`stInSenJam<n>`, the `Ausschleus.stau`
+bindings have no slot), scanners, separator/switch/MainTro numbers. The
+templates are unchanged — a known name simply drops its marker. Afterwards
+every inserted name is checked against the hardware planning (`hwFile` of the
+plant JSON in `%SKEL_RESULTS%`, or `--hw NAME`): names missing there are listed
+as a warning, with `--strict` the run stops (exit `1`, no SCL). `--eplan`
+together with a plant JSON is an error. Mubea: 46 names inserted, 47 fewer
+`TODO`s (482 → 435), 0 unknown names. Tests: `tests/test_scl_anlage.py`.
+
+**Names from the E-planning (phasing out, `--eplan NAME`, TRO-JSON only).** Reads the assignment
 `<csv>_eplan.json` written by `e_planning.py` (§5c; bare name looked up in
 `%SKEL_RESULTS%`). For every separator it assigns, the separator sensor
 (`stSenInSep := "DB_Inputs".Sensors["cInBG0642"]`) and the stopper valve
@@ -790,9 +819,9 @@ K0105 = Kreisel1 (2/3)**, each with motor and motor protection. The other
 conveyors (Aufgabestation #100/#101, Vario #106–#109) are outside the CSV or
 have a single vote and stay open.
 
-**Not yet:** `scl_skeleton` still reads `<csv>_eplan.json` (`--eplan`);
-switching it to `<csv>_anlage.json` is stage 4 of the concept, and only then
-`e_planning.py` becomes the thin wrapper and is removed.
+**Stage 4:** `scl_skeleton --json <csv>_anlage.json` reads the plant JSON
+directly (§5b). `--eplan` still works for a TRO-JSON and is phased out together
+with `e_planning.py`.
 
 Tests: `tests/test_merge_hw_layout.py` (sensor spatial / stopper by number,
 contradiction, open roles, part without slot, conveyor majority with
@@ -855,7 +884,7 @@ tro_flow.py (writes) · scl_skeleton.py (reads) · tro_annotate.py (draws)
 | `LayoutPart` | A layout part with position (`layoutId`, `kind`, `name`, `position`, `bbox`) — the target of the spatial assignment in `merge_hw_layout.py`, so that it never reads the CSV. `distance_to_box()`. Optional in v4; a file without `parts` still reads. |
 | `Binding` | One assignment hardware → slot role: `tro`, `slot`, `role`, `layoutId`, `bmk`, `constant`, `address`, `source`, `rule` (`raeumlich`/`nummer`/`mehrheit`/`hand`), `distance`, `runnerUp`, `status` (`zugeordnet`/`offen`/`widerspruch`/`ohne_slot`), `note`. |
 | `ConveyorBinding` | A conveyor of the E-planning (`K0102`) at a layout conveyor: `eplanName`, `layoutId`, `layoutName`, `votes`/`total`, `motor`, `protection`, `encoder`, `rule`, `status`, `note`. |
-| `AnlageDocument` | The plant JSON `<csv>_anlage.json` (`sps_skel-anlage-v1`): `layout` (the TRO-JSON unchanged), `registration`, `bindings`, `conveyors`, `unassigned`, `warnings`. `binding(tro, slot, role)`, `conveyor_for(layout_id)`. Written by `merge_hw_layout.py`; the future single input of `scl_skeleton`. |
+| `AnlageDocument` | The plant JSON `<csv>_anlage.json` (`sps_skel-anlage-v1`): `layout` (the TRO-JSON unchanged), `registration`, `bindings`, `conveyors`, `unassigned`, `warnings`. `binding(tro, slot, role)`, `conveyor_for(layout_id)`. Written by `merge_hw_layout.py`; input of `scl_skeleton` (stage 4). |
 
 `TroBase` and `TroCandidate` share the `position` handling (JSON `{x,y,z}`,
 `x`/`y`/`z`, `describe_position()`) through the private mixin `_Positioned`.