++ update HANDOFF.md

HANDOFF.md

@@ -4,7 +4,7 @@ Stato del progetto per chi ci mette mano dopo. Per installazione, deploy e uso
 quotidiano vedi [README.md](README.md); qui c'è il contesto che il README non
 può dare: perché le cose sono come sono, e cosa resta aperto.
 
-Ultimo aggiornamento: **18 luglio 2026**.
+Ultimo aggiornamento: **25 luglio 2026**.
 
 ---
 
@@ -89,6 +89,29 @@ messaggio d'errore è più chiaro).
 Deliberato: un errore immediato è meglio di un database in produzione con
 password `secret`.
 
+### Modifica/cancellazione delle assegnazioni: solo amministratore
+
+L'unico punto in cui un'assegnazione **esistente** si modifica o si cancella è
+il CRUD del Registro (`Livewire/Registro`: `openCreate`/`openEdit`/`save`/
+`askDelete`/`deleteConfirmed`), blindato su `settings.manage` a due livelli —
+`abort_if(..., 403)` nel componente e `@can('settings.manage')` in
+`registro.blade.php`, che nasconde pulsanti e modali. `settings.manage` ce l'ha
+solo l'`amministratore`.
+
+Di conseguenza gli altri ruoli **non** possono alterare le assegnazioni: la
+pagina Assegna solo ne crea (`territori.assign`), la pagina Rientra solo le
+chiude (`territori.return`). Nello specifico l'`assistente` (`registro.view` +
+`territori.assign` + `territori.return`) vede il Registro, crea nuove
+assegnazioni e le fa rientrare, ma non le modifica né le elimina.
+
+Poiché il seeder concede in modo additivo e non revoca mai (vedi la nota su
+`syncPermissions()` più sotto), un permesso `settings.manage` concesso a mano
+all'`assistente` in passato sopravviverebbe a ogni re-seed. La migration
+`2026_07_25_000001_revoke_settings_manage_from_assistente_role` chiude questo
+drift per i database esistenti: revoca `settings.manage` dal ruolo `assistente`
+se presente. È idempotente (no-op sul baseline) e volutamente irreversibile —
+il `down()` non ripristina il permesso.
+
 ### Un solo container esegue le migrazioni
 
 Solo `app` migra. `queue-worker` e `scheduler` usano `queue-entrypoint.sh`, che