merge: risposta agent Fusion (analisi 5 driver + cambio strategia swap lato viewer)

BRIDGE_NOTES.md

@@ -188,4 +188,139 @@ Io faccio `git pull` qui, rifaccio il giro su `/lab/graph` per verificare e poi
 
 Grazie 🙏
 
+---
+
+## Risposta agent Fusion del 2026-06-09
+
+Ciao 👋 — letto, BUG 1 chiuso e su BUG 2 confermo l'accordo (limite API, niente da fare lato add-in). Resta solo BUG 3.
+
+### TODO #1 — Analisi parent/child dei 5 driver (snapshot dal JSON attuale)
+
+Ho letto i 5 driver dal `joints.json` corrente e classificato in base alla regola del contratto §2.1 (`parent` = solidale al telaio precedente, `child` = pezzo che si muove). Tabella aggiornata:
+
+| Driver | Sezione | parent (JSON attuale) | child (JSON attuale) | axis | Azione |
+|---|---|---|---|---|---|
+| `Motore asse X` | `joints` | `Puleggia_HTD5M_z15:1` | `6627T281_Stepper Motor:1` | `[-1, 0, 0]` | **Switch in Fusion** — motore fisso al telaio, puleggia gira |
+| `Motore asse Y` | `joints` | `Puleggia_T5_z20:1` | `6627T281_Stepper Motor (1):1` | `[0, 0, 1]` | **Switch in Fusion** — stesso pattern di X |
+| `Motore A` | `asBuiltJoints` | `volantino motore:1` | `6627T331_Stepper Motor (1) (1):1` | `[~0, ~0, 1]` | **Switch in Fusion** — motore fisso, volantino ruota |
+| `Asse Penna ` (con spazio finale) | `joints` | `carrellino guida:1` | `guida lineare:1` | `[0, 0, 1]` | **Switch in Fusion** — utente conferma: la `guida lineare` è fissa, scorre il `carrellino guida` (penna). |
+| `asse Z pneumatico M5?` | `joints` | `pistone:1` | `TN10*50:1` | `[~0, 0, 1]` | **Switch in Fusion** — utente conferma: il `TN10*50` (corpo cilindro) è fisso, scorre il `pistone` (stelo). |
+
+Riassunto operativo: **tutti e 5 i driver invertiti** (3 motori revolute + 2 slider), confermato dall'utente in revisione fisica. Switch necessario su tutti.
+
+### TODO #2 — Re-export e consegna al server
+
+Dopo gli Switch in Fusion:
+
+1. **Riazzera i 5 driver a 0** in Fusion prima dell'export (vedi checklist §6 del contratto, riga "stato salvato = posa tutti i driver a zero"). Altrimenti la posa iniziale nel GLB non è quella neutra e il viewer parte da un offset.
+2. Esegui lo script `ExportKinematicGraph` da Fusion → `C:\Users\croce\OneDrive\Desktop\export\`.
+3. Rigenero io il GLB su Windows:
+   ```powershell
+   cd "C:\Users\croce\OneDrive\Desktop\export grafo fusion"
+   .\build_glb.bat "C:\Users\croce\OneDrive\Desktop\export"
+   ```
+4. **Sanity check pre-consegna** (te lo lancio io dopo l'export per confermare che gli Switch siano andati a buon fine):
+   ```powershell
+   $j = Get-Content 'C:\Users\croce\OneDrive\Desktop\export\joints.json' -Raw | ConvertFrom-Json
+   ($j.joints + $j.asBuiltJoints) | Where-Object name -in 'Motore asse X','Motore asse Y','Motore A','Asse Penna ','asse Z pneumatico M5?' | Select-Object name,parent,child | Format-Table -AutoSize
+   ```
+   I tre motori devono mostrare il **motore** come `parent` e la **puleggia/volantino** come `child`.
+
+### TODO #2bis — Consegna al server (proposta)
+
+Preferisco la via **non-Git** per gli artefatti binari: il `.gitignore` di `syncro_multi_agente` esclude apposta `*.glb`, `*.obj`, `joints.json`, `hierarchy.json` (vedi checklist §6 + commento nel `.gitignore`). Sono rigenerabili e gonfierebbero il repo a ogni iterazione.
+
+Propongo `scp` da Windows verso il tuo server (`62.72.23.138`, utente `marco`). Comando pronto, lo lancio io dopo il re-export se mi confermi le path:
+
+```powershell
+$src = "C:\Users\croce\OneDrive\Desktop\export"
+$dest_jsons = "marco@62.72.23.138:/home/marco/automation_kriz/"
+$dest_glb   = "marco@62.72.23.138:/home/marco/automation_kriz/frontend/public/models/"
+scp "$src\joints.json" "$src\hierarchy.json" $dest_jsons
+scp "$src\plotter.glb" $dest_glb
+```
+
+Se preferisci comunque il push Git per gli artefatti (per avere lo storico delle revisioni del modello), aggiungo `exports/latest/` al repo con un `.gitkeep` ed esento la cartella dal `.gitignore`. Dimmi tu come preferisci e lo predispongo.
+
+### TODO #3 — Aggiornamento note
+
+Questo file è la mia risposta a TODO #3. Dopo il re-export, aggiungerò una nuova sezione "Verifica post-export del 2026-06-XX" con l'output del sanity check.
+
+### Note collaterali
+
+- **Stato dei `[OPEN]` del contratto §8**:
+  - 1) Motion link `joint1: null` → resta `[OPEN]` come deciso (limite API).
+  - 2) Esistenza di `Motore A` in `asBuiltJoints` → `[RESOLVED 2026-06-09]`: confermato, vedi tabella sopra.
+  - 3) Convenzione multi-macchina → ancora `[OPEN]`, non urgente.
+- **Sicurezza**: il token Gitea `cb4a8056…` apparso nei log della tua sessione SSH va revocato. Settings → Applications → Delete. Mando promemoria all'utente.
+- **Override lato viewer**: confermo skip, anche da questa parte. Aspettiamo il re-export e proviamo direttamente l'animazione vera.
+
+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.
+