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

- [ ] **Paul / Schutzzaun "Element":** In `adesso-cpq/packages/frontend/src/components/building-blocks/ProductBrowser.vue` ist die kataloggruppe `Element` im `schutzzaun_basic` per Filter rausgenommen (TODO (Paul) an der Filterzeile). Element ist kaputt, muss richtig gefixt werden.
- [ ] **Marcel / Selection:** In `adesso-cpq/packages/frontend/src/components/visual/DefaultCommandProzessor.ts` sind für die Events `selection` und `selection-click` `FIXME (Marcel)`-Kommentare gesetzt. Selection-Logik sauber in den Griff bekommen.
- [ ] **Marcel / Scale-Hack vs. PlacementMode — wie lösen?** `Fire3D.vue` skaliert per `scaleScene` jedes Root-Handle mit `0.002` (Laufzeit). Der PlacementMode überschreibt die Subject-Matrix mit `Vector3.one` (`subject.matrix = bestMatrix · dragPointTransform⁻¹`); der DragPoint-Transform trägt den Faktor `S`, sein Inverses `1/S`, das Subject bekommt `1/S` → Geometrie netto `S·1/S = 1` → ~500×. Ergebnis: **jeder** einheitliche Laufzeit-Scale (Root, Wrapper, „kleine" Selection) überlebt den Snap nicht. Hack und PlacementMode sind auf demselben Subject unvereinbar. Einziger überlebender Wert: `S=1`, d. h. 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 dafür 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) / Lib-Bug movementMode — an fire-visual melden:** `fire-visual` `threed/interaction/module/src/interactionMode/movementMode.ts` `updateArrowHighlight` (Z. 295–299) greift `(this.interactionHelperHandle.find('.xy-plane') as Handle).renderer…` **ohne** null-Prüfung zu — während dieselbe Funktion die Achsen (Z. 305–318) sehr wohl absichert (`if (!arrowElement) return; if (arrowHandle?.renderer)`). Fehlt das Plane-Kind (Gizmo-Helper existiert, Planes weg — z. B. wenn ein voller `setScene` das Gizmo bei aktivem Move abräumt), wirft es `Cannot read properties of null (reading 'renderer')` **in jedem rAF-Frame** → kompletter Freeze. Lib ist nicht unser Code → upstream an fire-visual: Z. 295–299 konsistent zu Z. 305–318 absichern. Cpq-seitig vorerst umschifft (siehe unten), aber Upstream-Fix nötig.
- [ ] **Marcel (Montag) / funktionierendes Bundle (`@ad/fire` mit Relations-Resolver):** 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`). Diese Version hat `RelationsFeature` + `createRelation`, aber **nicht** `resolveRelations` bzw. das 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: das Constraint-Attachment (`attachment_relations` mit `constraint_position`) wird beim Placement zwar in den Szenegraph geschrieben und die Relation instanziiert, bleibt aber **inert** (kein Resolver, kein Trigger) → verbundene Teile ziehen beim Move nicht mit. Nötig: `@ad/fire` auf einen 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` wird nur via Command aufgerufen, 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`.
- [ ] **Marcel / fire-visual — sichtbarer Gap beim Verbau-Ziehen:** Beim Ziehen eines verbundenen Teils hängen die Follower sichtbar hinterher. Ursache: der `resolutionScheduler` löst **deferred** auf — das gegriffene Teil bewegt der Gizmo im Input/Update-Phase desselben Frames, die Relationen werden aber nur **markiert** (`_onTransformChange`) und erst in der **Process-Phase** (`_resolveNow`) aufgelöst, also einen Schritt später. Damit trailen die Follower konstant um die Bewegung eines Frames (Gap skaliert mit Ziehgeschwindigkeit; bei Stillstand holen sie im nächsten Frame auf → „im Block"). Kein Timer/Throttle, `MAX_ITERATIONS=10`. Erwartung: fire-visual soll den Gap rausnehmen (Auflösung synchron zum Move) **oder** das Nachziehen sauber animieren. Cpq-seitig nicht lösbar ohne den Resolver gegen die Lib synchron zu treiben.
- [ ] **Marcel / fire-visual — Null-Matrix-Crash beim `setScene`-Teardown (mit Relationen + Rotation):** Nach mehreren Rotationen verbundener Teile (jede über cpq-`setScene` → Rebuild) crasht es: `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). Ein Collider synchronisiert während/nach dem `setScene`-Teardown gegen eine bereits abgeräumte/**genullte** Transform → Null-Matrix → Inverse unmöglich. Reproduzierbar mit aktiven `attachment_relations` (Position+Rotation) und wiederholtem `setScene`; kumulativ (tritt nach einigen Rebuilds auf, gleiche Transform-Paarung). **Nicht** das Quaternion-Format (`values` ist `[w,x,y,z]`, verifiziert) und **nicht** der Resolver/`localA`/`constraint_rotation` (mit vollständigem Constraint-Satz unverändert). Während des Ziehens (Engine-Live-Resolve) ist alles korrekt — nur der cpq-`setScene`-Rebuild beim Loslassen triggert es. Gleiche Klasse wie der movementMode-null-renderer-Freeze: Lib räumt beim Rebuild nicht sauber ab bzw. der Collider-Sync läuft gegen eine tote Transform. Upstream-Fix nötig. Cpq-seitig vorerst umschifft: `handleRotateEnd` macht **kein** `setScene` mehr (die Engine hat den Rotations-Endzustand live schon korrekt; Event wird nur recorded). Offen bleibt: ein **nachfolgendes** `setScene` (z. B. Placement nach Rotation) replayt die Rotation und könnte denselben Teardown-Crash auslösen — der eigentliche Fix ist upstream oder ein **inkrementelles** Transform-Update (`set_transformation`) statt Full-`setScene` für Move/Rotate.
- [ ] **cpq / Verbau-Code refactoren (nach den Klärungen):** `DefaultCommandProzessor`/`SceneReplayProcessor`/`EventStore`/`eventDataUtil` sind über die Klärungsrunden gewachsen (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`). Funktioniert (Kette ≥4, Undo/Redo gruppiert), aber aufräumen.