simone
d6d3be00f4
Quali progetti vanno consegnati, a che punto sono e se il ritmo regge. La data attesa non esisteva nello schema. Si deduce da start_date + duration_months dell'offerta, e projects.due_date (migration 0018) la sovrascrive quando la durata a catalogo non descrive quel progetto li'. Entrano solo le offerte una_tantum. Un retainer e' continuativo e una consegna non ce l'ha per costruzione: in questa lista risulterebbe in ritardo per sempre. E' lo stesso discrimine che gia' regge il forecast. Teckell, che ha solo un "Mantenimento", sparisce dalla vista — e sparisce del tutto, non finisce fra i "senza scadenza" dove sembrerebbe una dimenticanza. Il semaforo confronta due percentuali, task chiusi e tempo trascorso, con dieci punti di tolleranza: sotto, la differenza e' rumore, e un semaforo che vira al rosso ogni settimana storta smette di essere guardato. Oltre la data di consegna e' rosso e basta. La barra le mostra entrambe: pieno = fatto, tacca = tempo passato. La distanza fra le due E' il ritardo, e si legge senza doversi fidare del semaforo. I progetti senza scadenza calcolabile restano elencati sotto invece di sparire: sono quelli a cui non e' assegnata un'offerta, cioe' esattamente il problema che la vista dovrebbe far notare. StatusBadge guadagna i toni. Serviva perche' i quattro stati di consegna non sono stadi di lead e cadevano tutti nel grigio di fallback: quattro pillole grigie non sono un semaforo. I lead continuano a usarlo come prima. Atteso e verificato sul DB: una sola riga, Rossi Inc in ritardo (22 giu + 1 mese = 22 lug, oggi 19 ago, 3 task su 28), piu' tre progetti senza scadenza. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>