Mancava il modo di dire "finito, ma da controllare prima di consegnarlo".
Il nuovo stato sta fra "In corso" e "Fatto" ed e' visibile anche al cliente:
il lavoro c'e' ed e' in controllo qualita', non e' fermo.
Il costo non era la logica ma la dispersione: tre letterali ricopiati a mano in
otto file, in tre forme diverse (allow-list a runtime, union TS, colonne kanban,
opzioni della select) e nessun CHECK in DB a tenerli insieme. Invece di
modificarne quattordici occorrenze, tutto deriva da TASK_STATUSES in
src/lib/task-status.ts: la prossima aggiunta costa una riga.
Due punti perdevano dati in silenzio, ed erano il vero motivo per centralizzare:
- recomputePhaseStatus considerava "iniziato" solo in_progress|done, come lista.
Una fase con tutti i task in revisione non rientrava ne' in allDone ne' in
anyActive e retrocedeva a "upcoming": si leggeva "non iniziata" quando era
quasi finita. Ora e' la negazione di "todo", e regge anche il prossimo stato.
- ClientKanban ripartiva i task con un oggetto a tre chiavi fisse, non derivato
dalle colonne: un task fuori da quelle spariva da ogni colonna e da ogni
contatore, e il cliente ne vedeva meno di quanti ce n'erano, senza errore.
Chiuso anche il cast non verificato al confine del portale (page.tsx), che era
la causa a monte di entrambi: ora ci passa normalizeTaskStatus.
Nessuna migration: tasks.status e' text senza CHECK, le righe esistenti valgono.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
