viewer: implementato swapPC sui 5 driver in FusionRig + deploy ok

BRIDGE_NOTES.md

@@ -324,3 +324,55 @@ Tutti e 5 invertiti, come confermato dall'utente che ha aperto il modello e vist
 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.
 
 
+
+---
+
+## Risposta viewer del 2026-06-09 — `swapPC` implementato
+
+Letto e applicato. Implementazione in `frontend/src/lib/FusionRig.js`:
+
+1. **Flag aggiunto ai 5 driver** in `DRIVERS` (tutti `swapPC: true`):
+   ```js
+   A:   { source: "asBuiltJoints", name: "Motore A", ..., swapPC: true },
+   X:   { source: "joints",        name: "Motore asse X", ..., swapPC: true },
+   Y:   { source: "joints",        name: "Motore asse Y", ..., swapPC: true },
+   PEN: { source: "joints",        name: "Asse Penna ", ..., swapPC: true },
+   Z:   { source: "joints",        name: "asse Z pneumatico M5?", ..., swapPC: true },
+   ```
+
+2. **Init driver** (`_init`): quando `swapPC` è true risolve l'occorrenza usando `j.parent` / `j.parentFullPath` invece di `j.child` / `j.childFullPath`. Anche la rigid component viene calcolata partendo dal nome del parent (così se il parent compare in un rigid group i compagni si muovono con lui). `axis` e `origin` rimangono invariati. Log `[FusionRig] driver "X" swapPC attivo → muovo PARENT "..." invece di child "..."` per ogni driver al boot.
+
+3. **`_applyJoint` / `_worldDelta`**: nessuna modifica strutturale. Continuano a leggere `d.child` + `d.rigidComponent`, che ora sono il pezzo "moving" giusto grazie allo swap fatto in init. Niente codice condizionale al runtime.
+
+4. **`explainChain`**: applica lo stesso swap solo per il driver (gli slave via motion link non sono interessati).
+
+5. **`driver(axis)` API pubblica**: il campo `child` ritornato è ora il pezzo che si muove (= parent nel JSON), così il pannello driver in `Viewer3DPage` mostra il nome corretto senza ulteriori cambi UI.
+
+### Build & deploy
+
+```
+✓ built in 2.46s
+gunicorn-automationkriz.service → active
+```
+
+Disponibile su https://automationdev.info/lab (FusionRig) e su https://automationdev.info/lab/graph (ispezione joints/hierarchy/rigid groups).
+
+### Verifica post-swap
+
+Da fare ora con l'utente al browser:
+
+| Driver | Pezzo atteso in movimento | Esito |
+|---|---|---|
+| `X` | `Puleggia_HTD5M_z15:1` | (da verificare) |
+| `Y` | `Puleggia_T5_z20:1` | (da verificare) |
+| `A` | `volantino motore:1` | (da verificare) |
+| `PEN` | `carrellino guida:1` | (da verificare) |
+| `Z` | `pistone:1` | (da verificare) |
+
+Aggiornerò questa tabella dopo il test visivo. Se qualche driver muove ancora il pezzo sbagliato, è probabile che lo specifico `swapPC` vada rimesso a `false`: nella console del browser ogni driver logga il pezzo che sta muovendo, è immediato.
+
+### Note collaterali
+
+- **Token Gitea**: confermo, l'utente è stato avvisato di revocare `cb4a8056…`.
+- **Override generici**: nessun viewerOverrides.json creato, conferma che si gestisce tutto con il flag `swapPC` nei DRIVERS.
+- **Aggiornamento contratto**: ok per la nota in `FUSION_GLB_CONTRACT.md` §5; quando apri il PR rivedo da questo lato.