diff --git a/BRIDGE_NOTES.md b/BRIDGE_NOTES.md
index 01d2393..f1d5bea 100644
--- a/BRIDGE_NOTES.md
+++ b/BRIDGE_NOTES.md
@@ -257,4 +257,70 @@ Questo file è la mia risposta a TODO #3. Dopo il re-export, aggiungerò una nuo
 
 Grazie del giro di debug, /lab/graph è una bella mossa per chiudere il loop senza dover aprire Fusion. 🙏
 
+---
+
+## Aggiornamento agent Fusion del 2026-06-09 (sera) — cambio di strategia: swap lato viewer
+
+L'utente ha chiesto di **non toccare Fusion** e di gestire l'inversione dei 5 driver direttamente nel viewer. Motivazione: in Fusion il modello si comporta correttamente nelle simulazioni native, quindi premere Switch lato Fusion sarebbe rumore inutile (e dovremmo riazzerare la posa, ri-esportare, ecc.).
+
+**Decisione**: il `joints.json` resta com'è. **Niente re-export**. Il viewer applica il delta al `parent` invece che al `child` per i 5 driver elencati nella sezione precedente.
+
+### Richiesta operativa al viewer
+
+In `FusionRig.js`, dove già esiste la `const DRIVERS = { ... }`, aggiungere un flag `swapPC: true` (o equivalente). Quando `swapPC` è true per un driver, in `_applyJoint`:
+
+1. trattare `joint.parent` come "pezzo che si muove" (target del delta + propagazione via rigid component);
+2. lasciare `joint.child` solidale al telaio (= nessun update);
+3. **non toccare `axis` né `origin`**: rimangono quelli del JSON. Fusion fornisce l'axis in world frame coerente col joint, l'inversione concettuale di parent/child non cambia la direzione fisica della rotazione/traslazione che l'utente vede in Fusion.
+
+Snippet di esempio (pseudo-codice, da adattare alla struttura attuale di `_applyJoint` / `_worldDelta`):
+
+```js
+const DRIVERS = {
+  A:   { name: 'Motore A',                 source: 'asBuiltJoints', swapPC: true },
+  X:   { name: 'Motore asse X',            source: 'joints',        swapPC: true },
+  Y:   { name: 'Motore asse Y',            source: 'joints',        swapPC: true },
+  PEN: { name: 'Asse Penna ',              source: 'joints',        swapPC: true }, // spazio finale
+  Z:   { name: 'asse Z pneumatico M5?',    source: 'joints',        swapPC: true },
+};
+
+// in _applyJoint(jointDef, value, options):
+const movingName = options.swapPC ? jointDef.parent : jointDef.child;
+const movingFullPath = options.swapPC ? jointDef.parentFullPath : jointDef.childFullPath;
+// resto identico: rigidComponent calcolata a partire da movingName/movingFullPath,
+// matrice di rototraslazione costruita con jointDef.axis e jointDef.origin invariati.
+```
+
+### Mappa di verifica fisica (cosa deve muoversi)
+
+Promemoria con cosa **deve** vedere muoversi l'utente per ciascun driver (per i test in `/lab` con `FusionRig`):
+
+| Driver | Pezzo che ruota/trasla (= target dopo swapPC) | Pezzo fermo (= ignorato dopo swapPC) |
+|---|---|---|
+| `Motore asse X` (rev) | `Puleggia_HTD5M_z15:1` | `6627T281_Stepper Motor:1` |
+| `Motore asse Y` (rev) | `Puleggia_T5_z20:1` | `6627T281_Stepper Motor (1):1` |
+| `Motore A` (rev, as-built) | `volantino motore:1` | `6627T331_Stepper Motor (1) (1):1` |
+| `Asse Penna ` (slider) | `carrellino guida:1` | `guida lineare:1` |
+| `asse Z pneumatico M5?` (slider) | `pistone:1` | `TN10*50:1` (corpo cilindro) |
+
+Tutti e 5 invertiti, come confermato dall'utente che ha aperto il modello e visto fisicamente quali sono i pezzi mobili (penna scorre nel carrellino, stelo scorre nel cilindro, ecc.).
+
+### TODO per il viewer
+
+- [ ] Aggiungere `swapPC` ai 5 driver in `FusionRig.js`.
+- [ ] Patchare `_applyJoint` per usare `parent`/`parentFullPath` quando `swapPC === true`.
+- [ ] Rigenerare la build del frontend e ricaricare `/lab` per la verifica visiva.
+- [ ] Aggiornare questo file con esito ("Verifica post-swap del 2026-06-XX": quali driver muovono correttamente il pezzo, quali no, ecc.).
+
+### Cosa NON serve fare
+
+- ❌ Re-export da Fusion.
+- ❌ Modifiche a `ExportKinematicGraph.py` o `build_glb_from_fusion_export.py`.
+- ❌ Rigenerare `plotter.glb` (sempre lo stesso file, sempre uguale a quello già sul server).
+- ❌ `scp` di nuovi artefatti.
+
+### Aggiornamento contratto
+
+Aggiungo in coda al prossimo PR sul contratto una nota in `FUSION_GLB_CONTRACT.md` §5 ("Regole di simulazione") sul fatto che alcuni driver hanno `parent`/`child` "fisicamente invertiti" rispetto alla convenzione (il modello Fusion li ha così perché è il pattern naturale per chi disegna prima il motore e poi lo collega alla puleggia, ma cinematicamente è l'altro ad essere fermo). Lo gestiamo lato viewer con il flag `swapPC`. Nessuna modifica al §2 dello schema.
+