Docs: reflect implemented DXF->JSON->SCL first version

lib/scl_skeleton.py and lib/tro_extract.py already run the pipeline
end-to-end (annotated DXF -> TRO-JSON -> FB_Main SCL skeleton), but
CLAUDE.md and README.md still described these as unwritten tools
(tro_export.py / scl_gen.py). Update the current-state docs:

- CLAUDE.md: project purpose, reading order, roadmap section, and
  standard-template notes now describe the built pipeline plus the
  parts still open (full layout JSON schema, other per-controller
  blocks, timing defaults, --skip-json).
- README.md: bin/ tree and usage examples for tro_extract/scl_skeleton.
- doc/Python_Scripts.md: intro counts (8 modules / 5 CLI tools),
  header date, pipeline diagram, and tro_overrides.py in the lib list.

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

CLAUDE.md

@@ -10,25 +10,30 @@ of Siemens SCL code** ("TRO" — Transfer Route Object — blocks for a conveyor
 control system) that can be imported directly into TIA Portal.
 
 The repository has moved past pure analysis: `lib/` now holds working Python tooling that
-derives a material-flow graph and a TRO list from a CSV export (ILS 2.0) and can annotate a
-copy of the BricsCAD drawing with the result. What does **not** exist yet is the actual
-SCL-skeleton generator — the step that would emit TIA-Portal-importable SCL from a JSON
-layout model — nor the tool that derives that JSON model from the annotated drawing; see
-"Roadmap" below for the planned two-tool pipeline that closes this gap. `tests/` and
-`examples/` are still empty scaffolding (see "Standard Programm Template" below). What
-exists today is:
+runs the **full DXF → JSON → SCL pipeline in a first version**. From a CSV export (ILS 2.0)
+it derives a material-flow graph and a TRO list, annotates a copy of the BricsCAD drawing
+with the result, reads the (possibly hand-edited) drawing back into a TRO-JSON, and emits an
+`FB_Main` **SCL skeleton** from that JSON. The skeleton is deliberately not a running
+program — every value that must come from the electrical planning is left as a visible
+`TODO(E-Planung)` gap rather than guessed. What is **not** done yet is the fuller layout-JSON
+schema (`doc/HundM/Json_Layout-Konzept.md`) as an intermediate format and the generation of
+the other per-controller blocks (`FB_CallSensors`, `FC_Direction`/`FC_Call_Jams` as
+standalone files); see "Roadmap" below. `tests/` and `examples/` are still empty scaffolding
+(see "Standard Programm Template" below). What exists today is:
 
 - `bin/` — environment/venv management scripts, plus one `.bat`/`.sh` wrapper pair per CLI
   tool in `lib/` (see "Environment scripts" below)
 - `lib/*.py` — CLI tools and libraries that turn a CSV export + BricsCAD DXF into a
-  material-flow graph, a derived TRO list/diagram, and an annotated copy of the drawing.
+  material-flow graph, a derived TRO list/diagram, an annotated copy of the drawing, a
+  TRO-JSON read back out of that drawing, and an `FB_Main` SCL skeleton.
   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/dxf_registration.json` — persisted, verified CSV↔DXF coordinate transform;
+  `cfg/tro_overrides.ini` — hand-maintained corrections to the derived TROs (see `tro_overrides.py`)
 - `doc/*.md` — analysis documents that reverse-engineer the SCL patterns and propose the
-  JSON schema / code-generation approach for the generator that's still to be written
+  fuller JSON layout schema for the parts of the pipeline still to be built out
 
 Read `doc/` before writing any generator code — start with `doc/Python_Scripts.md` for the
 existing tooling, then the domain-model documents below; together they contain the actual
@@ -83,9 +88,10 @@ routing, modeled around **TRO** (Transfer Route Object) blocks. Key documents, r
 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`, plus the `lib/tro_catalog.py` and
-   `lib/dxf_registration.py` libraries they share): what each script does, its switches,
-   inputs/outputs. This is working code, not a proposal — read it before touching `lib/`.
+   `lib/tro_flow.py`, `lib/tro_annotate.py`, `lib/tro_extract.py`, `lib/scl_skeleton.py`,
+   plus the `lib/tro_catalog.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
    of truth (`plc`, `controlUnits`, `sensors[]`, `conveyors[]`, `tros[]`, `loadingBooms[]`,
    `emptyCarrBuffers[]`, `routing`, `jamAreas[]`, `scanners[]`, `connections[]`,
@@ -116,9 +122,10 @@ this order for onboarding:
 6. **`doc/HundM/suggestion.md`** — a follow-up proposal to collapse the 7 `FB_ILS_MTRO_*`
    variants into a single `FB_ILS_MTRO` block driven by an array/config descriptor
    instead of hand-duplicated numbered members (`...1`, `...2`, `Dir1..Dir4`). References
-   a not-yet-written `lib/create_skel.py` (`guess_fbtype()`) as the intended generator
-   entry point — this is still the planned shape of the SCL-emitting generator itself;
-   the current `lib/` tooling derives TROs from a layout but does not yet emit SCL.
+   a `lib/create_skel.py` (`guess_fbtype()`) as the intended generator entry point. That
+   specific module does not exist in this repo — it is the HundM Excel-based generator
+   sketch, a different input source (see "Roadmap" below). This repo's own SCL emitter is
+   `lib/scl_skeleton.py`, which already emits an `FB_Main` skeleton from the TRO-JSON.
 7. **`doc/500573_Mubea/TRO_Identifikation_500573.md`** — the derivation rules
    `lib/tro_flow.py` implements: how to infer a TRO's type from its separator's host
    object (Gefällestrecke/Strecke/Kreisel) when no I/O list or `FB_Main` exists yet.
@@ -139,38 +146,47 @@ local, fully-vendored SCL source (`FB_ILS_MTRO_Vario_workStation`, `FB_EmptyCarr
 `doc/TRO_Katalog/scl_templates/*.scl` as **read-only reference material** for pattern
 extraction, not code to execute or modify.
 
-## Roadmap: DXF → JSON → SCL (planned, not implemented)
+## Roadmap: DXF → JSON → SCL (first version implemented)
 
-`tro_annotate.py` is where the current pipeline stops today: the user can keep hand-editing
-the annotated DXF copy afterwards (via the BricsCAD `TRO_INSERT`/`TRO_EDIT` commands, see
-`doc/HundM/BricsCAD_TRO_Symbol.md`) — moving TROs, adding new ones, or changing a type. Two
-more `lib/` tools are planned to carry that drawing the rest of the way to importable SCL:
+The DXF → JSON → SCL pipeline now runs end-to-end in a first version. After `tro_annotate.py`
+burns the TROs into a copy of the drawing, the user can hand-edit that DXF in BricsCAD (via
+the `TRO_INSERT`/`TRO_EDIT` commands, see `doc/HundM/BricsCAD_TRO_Symbol.md`) — moving TROs,
+adding new ones, changing a type — and two further `lib/` tools carry the drawing the rest of
+the way to importable SCL:
 
-1. **`lib/tro_export.py`** (planned) — reads the (possibly hand-edited) annotated DXF plus
-   the CSV export and derives the JSON layout file described in
-   `doc/HundM/Json_Layout-Konzept.md` (`plc`, `controlUnits`, `sensors[]`, `conveyors[]`,
-   `tros[]`, `loadingBooms[]`, `emptyCarrBuffers[]`, `routing`, `jamAreas[]`, `scanners[]`,
-   `connections[]`, `destinations[]`). Per-TRO timing (`trailingTime`, `handlingTime`,
-   `senFree`, `senWait`, `jamTime`, ...) comes from the type-based default table in
-   `doc/TRO_Typen.md` unless the CAD symbol carries an `OVERRIDE_TIMING_JSON` value (see
-   `doc/HundM/BricsCAD_TRO_Symbol.md`), in which case the override wins. The resulting JSON
-   file is meant to be hand-edited afterwards — that's the intended place to tweak defaults
-   or individual timings before code generation.
-2. **`lib/scl_gen.py`** (planned) — reads the JSON layout file and emits the `.scl` files
-   (`FB_Main`, `FB_CallSensors`, `FC_Direction`, `FC_Call_Jams` per controller) ready for
-   TIA Portal import. Takes a `--skip-json` switch for the case where no manual JSON edits
-   are needed: it then reads the DXF + CSV directly (running the same derivation as
-   `tro_export.py` internally) and emits SCL immediately, without writing or reading an
-   intermediate JSON file.
+1. **`lib/tro_extract.py`** (implemented) — reads the (possibly hand-edited) annotated DXF
+   **only** (not the CSV) and derives a TRO-JSON (`<drawing>_tro.json`): the TROs tagged with
+   XDATA, their `predecessors`/`successors` computed from the flow arrows, and plant
+   coordinates resolved through the persisted registration. See `doc/Python_Scripts.md` §5a.
+2. **`lib/scl_skeleton.py`** (implemented) — reads that TRO-JSON and emits an `FB_Main` SCL
+   skeleton (`<source>_FB_Main.scl`): one `REGION` per TRO with the instance call and every
+   parameter line in the right order, plus inline `FC_Direction` calls for switch TROs.
+   Everything derivable from the layout is filled (REGION order, FB type, parameter-block
+   counts, destination list per switch exit, `nTo1Destinations` for single-switch TROs);
+   everything that must come from the electrical planning is a `TODO(E-Planung)` gap.
+   Switches `--json`, `--out`, `--start` (the last picks an entry point while the plant is a
+   closed loop with no loading/unloading station). See `doc/Python_Scripts.md` §5b.
 
-Both tools follow the existing `lib/` conventions once written: a `bin/<name>.bat`/`.sh`
-wrapper pair (see "Environment scripts" above) and a switches/outputs section in
-`doc/Python_Scripts.md`. Note this is a separate concept from the `create_skel.py` /
-`guess_fbtype()` generator sketched in `doc/HundM/suggestion.md` and
-`doc/HundM/Json_Layout-Konzept.md` §14.5 — that one is designed to derive its skeleton JSON
-from HundM's Excel I/O-list exports (`*_TIA.xlsx`, `*_positions.json`, ...), a different
-input source than this repo's CSV+DXF pipeline. The JSON *schema* it targets is the same
-(`doc/HundM/Json_Layout-Konzept.md`); only the derivation source differs.
+What is **not** built out yet, relative to the original two-tool design:
+
+- the fuller **layout-JSON schema** of `doc/HundM/Json_Layout-Konzept.md` (`plc`,
+  `controlUnits`, `sensors[]`, `conveyors[]`, `tros[]`, `loadingBooms[]`,
+  `emptyCarrBuffers[]`, `routing`, `jamAreas[]`, `scanners[]`, `connections[]`,
+  `destinations[]`) as the intermediate format — `tro_extract.py` currently emits a
+  TRO-focused JSON, not this full schema;
+- the **other per-controller blocks** (`FB_CallSensors`, `FC_Direction`/`FC_Call_Jams` as
+  standalone files) — only `FB_Main` is generated today;
+- **type-based timing defaults** from `doc/TRO_Typen.md` and the `OVERRIDE_TIMING_JSON` CAD
+  attribute (timings are emitted as `TODO(E-Planung): pruefen` placeholders for now);
+- a **`--skip-json`** convenience path that would read DXF + CSV directly and emit SCL
+  without an intermediate JSON file.
+
+Note the `create_skel.py` / `guess_fbtype()` generator sketched in `doc/HundM/suggestion.md`
+and `doc/HundM/Json_Layout-Konzept.md` §14.5 is a **separate concept** and is not implemented
+here: it is designed to derive its skeleton JSON from HundM's Excel I/O-list exports
+(`*_TIA.xlsx`, `*_positions.json`, ...), a different input source than this repo's CSV+DXF
+pipeline. The JSON *schema* it targets is the same (`doc/HundM/Json_Layout-Konzept.md`); only
+the derivation source differs.
 
 ## Standard Programm Template
 
@@ -188,14 +204,14 @@ sps_skel/
   examples/  example files — empty for now
   lib/       Python source, importable via SKEL_LIB on PYTHONPATH — CLI tools and
              libraries that derive material flow / TRO lists / CAD annotations from a
-             layout (see doc/Python_Scripts.md); the JSON-driven SCL generator itself
-             is not yet written
+             layout, read the TROs back into JSON, and emit an FB_Main SCL skeleton
+             (see doc/Python_Scripts.md)
   log/       gitignored
-  results/   gitignored — CLI tool output (.dot/.svg/.md/.dxf)
+  results/   gitignored — CLI tool output (.dot/.svg/.md/.dxf/.scl/.json)
   tests/     unit tests — empty for now
 ```
 
-When adding the SCL generator, put it under `lib/` (importable via `SKEL_LIB` on
-`PYTHONPATH`), add a `bin/<name>.bat`/`.sh` wrapper pair for it following the pattern of
-`bin/tro_flow.bat`/`.sh` (see "Environment scripts" above), document its switches in
-`doc/Python_Scripts.md`, and add tests under `tests/`.
+When extending the pipeline (the remaining pieces in "Roadmap" above), put new modules under
+`lib/` (importable via `SKEL_LIB` on `PYTHONPATH`), add a `bin/<name>.bat`/`.sh` wrapper pair
+for each following the pattern of `bin/tro_flow.bat`/`.sh` (see "Environment scripts" above),
+document its switches in `doc/Python_Scripts.md`, and add tests under `tests/`.