claude-projects/robotunits/OFFENE-PUNKTE.md

# Offene Punkte — bei jedem Start prüfen und abhaken

Reihenfolge: Paul · Marcel (fire-visual / Bundle) · cpq.

---

## Paul

### [ ] Schutzzaun „Element" kaputt
- **Wo:** `adesso-cpq/packages/frontend/src/components/building-blocks/ProductBrowser.vue`, Filterzeile (TODO (Paul)).
- **Stand:** Kataloggruppe `Element` im `schutzzaun_basic` per Filter rausgenommen.
- **Nötig:** Element richtig fixen statt ausfiltern.

---

## Marcel — cpq-Selection

### [ ] Selection-Logik
- **Wo:** `adesso-cpq/packages/frontend/src/components/visual/DefaultCommandProzessor.ts`, Events `selection` / `selection-click` (FIXME (Marcel)).
- **Nötig:** Selection-Logik sauber in den Griff bekommen.

---

## Marcel — Scale

### [ ] Scale-Hack vs. PlacementMode — wie lösen?
- **Hack:** `Fire3D.vue` skaliert per `scaleScene` jedes Root-Handle zur Laufzeit mit `0.002`.
- **Konflikt:** PlacementMode überschreibt die Subject-Matrix mit `Vector3.one` (`subject.matrix = bestMatrix · dragPointTransform⁻¹`). DragPoint-Transform trägt `S`, sein Inverses `1/S`, Subject bekommt `1/S` → Geometrie netto `S·1/S = 1` → ~500×.
- **Folge:** Jeder einheitliche Laufzeit-Scale (Root, Wrapper, „kleine" Selection) überlebt den Snap nicht. Hack und PlacementMode sind auf demselben Subject unvereinbar.
- **Einzige überlebende Lösung:** `S=1`, also reale kleine Koordinaten in den Daten selbst — Geometrie **und** PMIs konsistent, kein Laufzeit-Scale — plus Kamera-Config (`camera-controller` `defaultPosition`/`fixPoint`, Ortho-Frustum auf mm).
- **Offen/ungeprüft:** Ob fire-visual einen vorgesehenen Mechanismus hat (Unit-System `unitConverter`/`environment.units`; FBX `UnitScaleFactor` greift bisher nur beim Import, nicht auf fertige JSON-SceneGraphen).
- **Entscheidung nötig:** Daten in realer Einheit liefern vs. Lib-Eingriff (PlacementMode behält Subject-Scale).

---

## Marcel (Montag) — fire-visual

### [ ] Lib-Bug movementMode — an fire-visual melden
- **Wo:** `fire-visual` `threed/interaction/module/src/interactionMode/movementMode.ts`, `updateArrowHighlight`.
- **Bug:** Z. 295–299 greift `(this.interactionHelperHandle.find('.xy-plane') as Handle).renderer…` **ohne** null-Prüfung — die Achsen (Z. 305–318) sind dagegen abgesichert (`if (!arrowElement) return; if (arrowHandle?.renderer)`).
- **Trigger:** Plane-Kind fehlt (Gizmo-Helper existiert, Planes weg — z. B. wenn ein voller `setScene` das Gizmo bei aktivem Move abräumt) → `Cannot read properties of null (reading 'renderer')` in **jedem rAF-Frame** → kompletter Freeze.
- **Fix:** Upstream — Z. 295–299 konsistent zu Z. 305–318 absichern.
- **Stand:** Cpq-seitig vorerst umschifft, Upstream-Fix trotzdem nötig.

### [ ] Funktionierendes Bundle (`@ad/fire` mit Relations-Resolver)
- **Ist:** cpq lädt `@ad/fire@1.0.5` (gebündelt in `packages/runtime/visual` via `tsup`, gelinkt nach `packages/frontend/node_modules/@ad-cpq/visual-runtime`).
- **Lücke:** 1.0.5 hat `RelationsFeature` + `createRelation`, aber **nicht** `resolveRelations` / Command `resolve_relations` (im Bundle 0 Vorkommen) — der Resolver kam in der fire-visual-Quelle (`~/projects/fire-visual`) erst nach 1.0.5 dazu.
- **Folge:** `attachment_relations` (mit `constraint_position`) wird beim Placement zwar geschrieben und die Relation instanziiert, bleibt aber **inert** (kein Resolver, kein Trigger) → verbundene Teile ziehen beim Move nicht mit.
- **Nötig:** `@ad/fire` auf Stand mit Resolver bringen — fire-visual lokal bauen (`build:local`, yarn-workspaces-Monorepo) → neues `@ad/fire`, cpq's `@ad/fire@1.0.5` darauf umbiegen (pnpm-override / `file:`-Link), `packages/runtime/visual` neu bauen. Achtung API-Drift neuere fire-visual vs. cpq/Runtime.
- **Zusätzlich offen, sobald Resolver da:**
  1. **Auto-Trigger fehlt auch in der Quelle** — `resolveRelations` nur via Command, kein Update-Hook/Transform-Abo; sauber wäre der Trigger im Move-/Placement-Mode der Engine (mit gezogenem Teil gepinnt), sonst muss cpq es von außen treiben.
  2. **Persistenz** — aufgelöste Nachbar-Transforms leben in der Engine, nicht im cpq-eventStore → Readback (`get_transformation`) nötig, sonst Rücksprung beim nächsten `setScene`.

### [ ] Sichtbarer Gap beim Verbau-Ziehen
- **Symptom:** Beim Ziehen eines verbundenen Teils hängen die Follower sichtbar hinterher.
- **Ursache:** `resolutionScheduler` löst **deferred** auf — das gegriffene Teil bewegt der Gizmo in der Input/Update-Phase desselben Frames, die Relationen werden nur **markiert** (`_onTransformChange`) und erst in der **Process-Phase** (`_resolveNow`) aufgelöst, also einen Schritt später.
- **Effekt:** Follower trailen konstant um eine Frame-Bewegung (Gap skaliert mit Ziehgeschwindigkeit; bei Stillstand holen sie im nächsten Frame auf → „im Block"). Kein Timer/Throttle, `MAX_ITERATIONS=10`.
- **Erwartung:** fire-visual nimmt den Gap raus (Auflösung synchron zum Move) **oder** animiert das Nachziehen sauber.
- **Stand:** Cpq-seitig nicht lösbar ohne den Resolver gegen die Lib synchron zu treiben.

### [ ] Null-Matrix-Crash beim `setScene`-Teardown (Relationen + Rotation)
- **Symptom:** Nach mehreren Rotationen verbundener Teile (jede über cpq-`setScene` → Rebuild): `Uncaught Error: Matrix4_4(...zeros...) - inverse: can't be calculated` in `VolumeContext.updateWTL` ← `ColliderComponent.syncTransformation` ← `SynchronizeQueue.process` ← rAF, **jeden Frame** → Freeze. Davor flutet der Log mit `FeatureComponent - deregister` (Teardown der alten Szene).
- **Ursache:** Ein Collider synchronisiert während/nach dem `setScene`-Teardown gegen eine bereits abgeräumte/**genullte** Transform → Null-Matrix → Inverse unmöglich.
- **Repro:** Aktive `attachment_relations` (Position+Rotation) + wiederholtes `setScene`; kumulativ (nach einigen Rebuilds, gleiche Transform-Paarung).
- **Ausgeschlossen:** **Nicht** das Quaternion-Format (`values` = `[w,x,y,z]`, verifiziert), **nicht** Resolver/`localA`/`constraint_rotation` (mit vollständigem Constraint-Satz unverändert). Während des Ziehens (Engine-Live-Resolve) alles korrekt — nur der cpq-`setScene`-Rebuild beim Loslassen triggert es.
- **Einordnung:** Gleiche Klasse wie der movementMode-null-renderer-Freeze — Lib räumt beim Rebuild nicht sauber ab bzw. Collider-Sync läuft gegen tote Transform. Upstream-Fix nötig.
- **Stand:** Cpq-seitig umschifft — `handleRotateEnd` macht **kein** `setScene` mehr (Engine hat den Rotations-Endzustand live korrekt; Event wird nur recorded).
- **Offen:** Ein **nachfolgendes** `setScene` (z. B. Placement nach Rotation) replayt die Rotation und könnte denselben Crash auslösen. Eigentlicher Fix: upstream oder **inkrementelles** Transform-Update (`set_transformation`) statt Full-`setScene` für Move/Rotate.

---

## cpq

### [ ] Verbau-Code refactoren (nach den Klärungen)
- **Wo:** `DefaultCommandProzessor` / `SceneReplayProcessor` / `EventStore` / `eventDataUtil`.
- **Gewachsen über die Klärungsrunden (A-Modell):**
  - Move-Ende recorded bewegtes Teil + transitive Follower als eine `pushGroup`-Gruppe.
  - Placement schreibt EIN gemeinsames `attachment_relations` (wegen Clobber im `relationsProcessor`).
  - Position-Korrektur `pos = event.position − dragPMI-Offset`.
  - Subject-Ausschluss in DropPoints via `:not`.
- **Stand:** Funktioniert (Kette ≥4, Undo/Redo gruppiert), aber aufräumen.