docs: rettifica - BUG 1 era falso allarme (mio errore in script python), chiarito comportamento _applyJoint sul child

BRIDGE_NOTES.md

@@ -80,25 +80,16 @@ Lato consumer (`automation_kriz`) ho aggiunto una pagina di ispezione live a `/l
 
 Ispezionando l'export attuale (`329 joints, 28 asBuiltJoints, 9 motionLinks, 20 rigidGroups`) ho trovato tre problemi che impediscono al viewer di propagare il movimento sull'asse X (e probabilmente anche Y e PEN dipendono dagli stessi pattern). Servono fix lato `ExportKinematicGraph.py`.
 
-### BUG 1 — `rigidGroups[].occurrences` è SEMPRE vuoto
+### BUG 1 — ~~`rigidGroups[].occurrences` è SEMPRE vuoto~~ FALSO ALLARME
 
-Tutti i 20 gruppi rigidi esportati hanno `occurrences: []`. Esempio dal file corrente:
+**Ritiro questo punto.** Era un errore nel mio script Python di diagnostica a terminale (avevo scritto `rg.get('occurrences', [])` invece di `rg.get('occurrenceNames', [])`), poi ho copiato la conclusione qui sopra senza ricontrollarla. Verifica fatta:
-```json
+
-[
+```
-  {"name": "Gruppo rigido 6", "occurrences": []},
+Keys di un rigid group: ['name', 'occurrenceNames', 'occurrencePaths', 'isSuppressed', 'isLightBulbOn', 'includeChildren']
-  {"name": "Gruppo rigido 17", "occurrences": []},
+Gruppo rigido 6 contenuto: ['end stop X PIastrina:1', 'binario SX:1', 'Cinghia T5:1']
-  ...
-]
 ```
 
-Nel `BRIDGE_NOTES` precedente è scritto che `Gruppo rigido 6` doveva contenere `end stop X PIastrina:1 | binario SX:1 | Cinghia T5:1`. Nell'export reale quelle occorrenze NON ci sono. Senza occurrences, il viewer non sa quali parti tenere "incollate" al carrello / motore / cinghia → il driver X non muove nulla.
+Il JSON è conforme al contratto §2.3 (`occurrenceNames` + `occurrencePaths`). Anche `FusionRig.js` e `KinGraphPage.jsx` lato viewer leggono già correttamente `g.occurrenceNames`. Quindi BUG 1 non esiste, scusa il rumore.
-
-Possibili cause da verificare nell'add-in:
-- Si itera `rigidGroup.occurrences` ma con un proxy stale (collection invalidata dopo `activate`/`returnToParent`)?
-- Si guarda `nativeObject.occurrences` invece di farla risolvere via `assemblyContext`?
-- Si filtra accidentalmente per `occ.isLightBulbOn` o `isSuppressed`?
-
-Verifica veloce: in console Fusion durante export stampare `len(list(rg.occurrences))` per ogni `rg` in `rootComp.allRigidGroups` e confrontare con quello che finisce nel JSON.
 
 ### BUG 2 — `Collegamento movimento 14` (driver X) ha `joint1: null`
 
@@ -126,18 +117,21 @@ Nel BRIDGE_NOTES precedente è scritto "ignorabili, propagazione passa dai rigid
 
 Fisicamente è il motore stepper che è fissato al telaio e fa girare la puleggia. Nel JSON è il contrario. Il viewer applica sempre la rotazione al `child` mantenendo fermo il `parent`, quindi vede il motore ruotare nel vuoto e la puleggia (che dovrebbe seguire) sta ferma.
 
-Fix in Fusion: aprire il joint, cliccare **Switch** per invertire `Component 1`/`Component 2`. Sospetto valga anche per gli altri driver — andrebbero controllati tutti e cinque con questo criterio:
+**Risposta alla domanda "il viewer applica al child?"**: sì, lo applica al `child` (più tutti i compagni del/dei rigid group che contengono il child). Codice in `FusionRig.js#_applyJoint` + `_worldDelta`:
-- `parent` = pezzo che resta solidale al telaio (o al precedente livello cinematico)
+```js
-- `child` = pezzo che si muove rispetto al parent
+// d.origin viene dal joint, d.axis dal joint, d.child dal joint
+const T1 = new THREE.Matrix4().makeTranslation(d.origin.x, d.origin.y, d.origin.z);
+const R  = new THREE.Matrix4().makeRotationAxis(d.axis, value);
+const T2 = new THREE.Matrix4().makeTranslation(-d.origin.x, -d.origin.y, -d.origin.z);
+// la matrice ottenuta viene poi applicata a `child` e a tutti gli oggetti in `rigidComponent`
+```
+Quindi sì, serve premere `Switch` in Fusion. Stessa verifica da fare per `Motore asse Y`, `Asse Penna `, `asse Z pneumatico M5?` e `Motore A` (asBuilt): controllare per ognuno che `child` = il pezzo che si muove rispetto al telaio del livello precedente, `parent` = il pezzo solidale al livello precedente.
+
+In ogni caso il fix è **lato Fusion**, non lato codice viewer.
 
 ### Patch temporanea lato viewer (in valutazione, non ancora applicata)
 
-Se i fix 1-3 lato Fusion richiedono tempo, lato viewer posso aggiungere:
+~~Override `viewerOverrides.json` / `viewerRigidGroups.json` / `viewerMotionLinks.json`.~~ Saltato. Visto che BUG 1 non esiste e BUG 2 non è bloccante per i driver puri (la propagazione passa dai rigid groups, che ora il viewer legge correttamente), aspetto solo il fix Fusion del BUG 3 e proviamo subito.
-- una mappa `viewerOverrides.json` con `{ jointName: { swapParentChild: true } }` per simulare il fix BUG 3 senza modificare l'export
-- una mappa `viewerRigidGroups.json` con i contenuti che `Gruppo rigido N` dovrebbe avere, in attesa del fix BUG 1
-- una mappa `viewerMotionLinks.json` per ricostruire i `joint1` mancanti del BUG 2
-
-Sono workaround sporchi: preferisco fixare l'export quando possibile e tenere il viewer privo di patch ad-hoc. Fammi sapere se preferisci che proceda comunque con gli override per sbloccare le demo nel frattempo.
 
 ### Per gli altri driver