=== Was habe ich in diesem Schritt angefasst? (mein Working-Tree-Diff, Namen) ===
 M packages/frontend/src/components/visual/ProductConfigurator.stories.ts
?? packages/frontend/.storybook/products/docking-rules.json

=== Wie werden Klasse/PMI aktuell getragen? tags vs. classes ===
-- Root-Handle eines Bauteils:
 keys am Handle: ['id', 'properties', 'components', 'tags']
 tags: ['class-schutzzaun_allround-steher']
 classes: None

=== Selektoren im Code: .class-/.name- (Tag-basiert) ===
500:            .map((o) => `:not(#${o.element} .name-${o.pmi})`)
515:    // class via a descendant `.class-<target>` selector; self-snap and occupied ends are excluded.
527:                    (dp) => `.class-${targetClass} .name-${dp}:not(${subject} .name-${dp})${openOnly}`,
533:            selector: `.name-${dragPoint}${openOnly}`,

=== Wie löst @ad/fire '.'-Selektoren auf? (tags oder classes) ===


Nein.

Ich habe in diesem Schritt **nur** die Regeln aus der Story in `docking-rules.json` ausgelagert und die Story auf Laden-aus-JSON umgestellt (`git status`: geändert nur `ProductConfigurator.stories.ts` + neue `docking-rules.json`). Am Klassen-/Tag-Mechanismus habe ich **nichts** angefasst.

Ist-Zustand, belegt:
- Bauteil-Root trägt `tags: ['class-schutzzaun_allround-steher']`, ein `classes`-Feld existiert **nicht** (`None`).
- Die Selektoren im Code sind `.class-…` / `.name-…` (`DefaultCommandProcessor.ts:527,533`) — sie matchen genau diese **`class-`/`name-`-präfixierten Tag-Strings**, nicht echte CSS-Klassen.

Also läuft es weiterhin über **Tags** (mit `class-`/`name-`-Präfix), nicht über echte CSS-Klassen. Der vereinbarte Umbau tag→CSS-Klasse ist nicht umgesetzt — weder von mir noch vorher; er war nicht Teil dieser Aufgabe.


das heißt man setzt den Klassenamen über tags?


Rollenförderer Visualisierung und Fehler beheben


Ja. Die „Klasse" eines Bauteils steckt als **Tag-String** `class-<gruppe>-<klasse>` im `tags`-Array des Root-Handles (z. B. `tags: ['class-schutzzaun_allround-steher']`). Ein eigenes `classes`-Feld gibt es nicht.

Der `class-`-Präfix ist reine Konvention, damit der Selektor `.class-schutzzaun_allround-steher` diesen Tag findet — die Selektor-Engine matcht `.foo` gegen den Tag `foo`. Gleiches Muster bei den PMIs: Tag `name-CS_EIN_L`, Selektor `.name-CS_EIN_L`.

`classOfGroup` liest genau diesen Tag zurück: `t.startsWith("class-")` → `t.slice("class-".length)` → `schutzzaun_allround-steher`.


commit und push


Bash

cd /Users/marcus.hinz/projects/adesso-cpq
git add packages/frontend/src/components/visual/ProductConfigurator.stories.ts packages/frontend/.storybook/products/docking-rules.json
git commit -q -F - <<'EOF'
ProductConfigurator-Story: Docking-Regeln aus JSON laden

- Regeln aus der inline-Konstante in .storybook/products/docking-rules.json
  ausgelagert (Bindestrich-Notation, passend zu den class-…-Tags der Bauteile).
- Story fetcht /products/docking-rules.json parallel zum Katalog und reicht sie
  per :docking-rules-Prop durch. v-if="dockingRules" am ProductConfigurator,
  weil der Processor die Prop einmalig beim Erstellen liest (nicht reaktiv).
EOF
echo "=== push ==="
git push 2>&1 | tail -4
git log --oneline -1

Commit und Push Story + docking-rules.json


=== push ===
remote:   https://git.heron.at/pzm/geko/adesso-cpq/-/merge_requests/new?merge_request%5Bsource_branch%5D=Produktmanagement
remote:
To https://git.heron.at/pzm/geko/adesso-cpq.git
   9fbadce..d448cdb  Produktmanagement -> Produktmanagement
d448cdb ProductConfigurator-Story: Docking-Regeln aus JSON laden


Committet und gepusht: `9fbadce..d448cdb` auf `Produktmanagement`. Enthält nur die zwei Dateien (Story + `docking-rules.json`); die gelöschten glb und die untracked rollenfoerderer-JSONs blieben unangetastet.