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.