simone
1fa8e1ab5e
tasks.sort_order esisteva e veniva letto in ORDER BY, ma non era mai scritto se non come max+1 all'inserimento: nel repo non c'era alcun riordino, per nessuna entita'. @dnd-kit/sortable era gia' installato e mai importato. Il nodo era PhasesTab: e' un Server Component con quattro closure "use server" inline, che in un modulo client non compilano. Quindi niente conversione: le righe restano renderizzate dal server e arrivano a SortableTaskList come ReactNode opachi, che ci monta attorno solo la maniglia. E' la stessa forma di PhasesViewToggle, che gia' passa un tab server-renderizzato come prop. reorderTasks riscrive sort_order come 0..n-1 per tutta la fase invece di scambiare due righe. Non e' pigrizia: in produzione una fase ha 14 task con sort_order sparsi su 0..23 (buchi lasciati dai delete), le righe legacy stanno sullo 0 di default e non esiste unique index su (phase_id, sort_order), quindi i duplicati sono ammessi. La riscrittura completa normalizza tutto a ogni drop. Gli id arrivano dal client, quindi vengono filtrati su quelli che appartengono davvero alla fase. Niente pacchetti nuovi: @dnd-kit/modifiers non c'e', e il vincolo verticale si ottiene azzerando la X della transform. Verificato a runtime contro il DB di produzione (build di produzione + tunnel SSH, in sola lettura): la pagina progetto risponde 200 e rende 27 maniglie, che sono esattamente i task delle fasi con piu' di un task. Il passaggio di nodi server con "use server" inline attraverso il confine client regge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>