claude-projects/robotunits/OFFENE-PUNKTE.md

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.