claude sync: 2026-06-28 19:19
This commit is contained in:
marcus.hinz
+2
-1
@@ -29,7 +29,8 @@
|
||||
|
||||
# Handeln / Plan
|
||||
|
||||
- Vor verändernden Aktionen (Install, neue Dependencies, neue Dateien, Commit, Multi-File-Edit) erst kurz den Plan zeigen (was + warum), dann Go abwarten. Lese-/Suchaktionen laufen ohne Vorankündigung.
|
||||
- Vor verändernden Aktionen (Install, neue Dependencies, neue Dateien, Commit, Multi-File-Edit) erst kurz den Plan zeigen (was + warum), dann Go abwarten.
|
||||
- NUR SUCHEN, WENN AUSDRÜCKLICH ANGEWIESEN. Keine eigenmächtigen Such-, Erkundungs- oder Datei-Befehle (Bash, grep, find, ls, which, Tool-Suchen, Agenten). Auch nach einem fehlgeschlagenen Befehl nicht selbsttätig weitersuchen. Eine Ja/Nein- oder Faktenfrage wird beantwortet, nicht durch Suchen „belegt". Suchen erst auf ausdrückliche Anweisung.
|
||||
|
||||
# Kein defensiver Code
|
||||
|
||||
|
||||
@@ -14,6 +14,9 @@
|
||||
"Bash(~/claude-projects/global/bin/git-sync:*)"
|
||||
]
|
||||
},
|
||||
"env": {
|
||||
"PATH": "/Users/marcus.hinz/.local/share/fnm/aliases/default/bin:/Users/marcus.hinz/.local/bin:${PATH}"
|
||||
},
|
||||
"enabledPlugins": {
|
||||
"frontend-design@claude-plugins-official": true,
|
||||
"swift-lsp@claude-plugins-official": true
|
||||
|
||||
@@ -1,10 +1,81 @@
|
||||
# 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.
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user