feat(portale): gli stati dei task si distinguono, e "in revisione" dice di chi e' la palla
Nella Timeline — la vista di default — lo stato di un task era solo un cerchietto colorato: ambra col puntino da 1.5px per "in corso", violetto col puntino da 2px per "in revisione". A 20px sono lo stesso oggetto. Solo "in revisione" aveva un title; gli altri tre stati non avevano ne' testo, ne' tooltip, ne' aria-label — l'opposto della regola UX 3 del design system, che chiede colore + testo, mai colore da solo. Il punto pero' non era la somiglianza fra i due colori. "In revisione" non significa quello che dice5547e55, che lo descriveva come controllo qualita' interno: nel flusso reale vuol dire "consegnato, aspetta l'OK del cliente". E' uno stato che richiede un'azione, e per questo un cerchietto muto era il problema vero. - Le quattro icone si distinguono per forma, non solo per colore, quindi reggono anche in bianco e nero e con un daltonismo: vuoto -> punto -> spunta vuota -> spunta piena. La spunta compare a lavoro finito e si riempie a lavoro confermato. - Pill di testo solo su "in corso" e "in revisione". "Da fare" e' un cerchio vuoto e "fatto" ha il titolo barrato: etichettarli aggiungeva rumore, non informazione. - Il conteggio dei task in attesa sta nell'header della fase, quindi si legge anche a card chiusa. Serve davvero: l'admin puo' forzare una fase su "completata" dalla select, e in quel caso la card parte collassata con dentro la richiesta. - Legenda + micro-copy sopra entrambe le viste: chi revisiona, e che ogni pagina include un giro di revisione — l'informazione commerciale che il cliente non aveva da nessuna parte. Rimanda alla chat della fase, che esiste gia'. - Colonne del kanban cliente colorate con le stesse tinte dell'icona in Timeline: prima erano quattro colonne grigie identiche. - Icona aria-hidden + sr-only, cosi' lo screen reader annuncia lo stato anche sui due che non portano la pill. La barra di avanzamento non e' stata toccata: un task in revisione conta come uno in corso, cioe' zero. Cambia il tipo di lavoro, non l'avanzamento — gonfiare la percentuale le avrebbe fatto dire una cosa che il contatore "x di y task" smentiva una riga sotto. Visual e copy in un solo file, e la legenda si genera da TASK_STATUSES: un quinto stato non lascera' indietro una lista scritta a mano. Stessa disciplina di5547e55, nata proprio perche' due liste fisse avevano fatto sparire dei task senza un errore. Nessuna migration: e' solo UI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
+7
-6
@@ -3,9 +3,9 @@ gsd_state_version: 1.0
|
||||
milestone: v2.5
|
||||
milestone_name: Audit
|
||||
status: executing
|
||||
stopped_at: "v2.5 in PAUSA. Modifiche hub: A, B, C1, rifiniture, chat a canali (0021) e modifica messaggi + firma (0022) in prod; C2 (TidyCal) bloccato sulle credenziali API. Niente della chat e' stato provato a mano: .env.local non autentica piu'."
|
||||
last_updated: "2026-08-21T20:55:00.000Z"
|
||||
last_activity: 2026-08-21 -- modifica dei messaggi (0022) e firma di chi risponde in chat
|
||||
stopped_at: "v2.5 in PAUSA. Modifiche hub: A, B, C1, rifiniture, chat a canali (0021) e modifica messaggi + firma (0022) in prod; C2 (TidyCal) bloccato sulle credenziali API. Stati dei task nel portale: scritti, build verde, da vedere a schermo. Niente della chat e' stato provato a mano: .env.local non autentica piu'."
|
||||
last_updated: "2026-08-22T12:10:00.000Z"
|
||||
last_activity: 2026-08-22 -- stati dei task leggibili nel portale cliente (icone, pill, legenda)
|
||||
progress:
|
||||
total_phases: 4
|
||||
completed_phases: 0
|
||||
@@ -41,6 +41,7 @@ Phase 27 resta a metà — schema e fonti in prod, resto da scrivere.
|
||||
| Portale cliente — stepper compatto/full-width, card offerta | ✅ in prod 2026-08-21 (`0020`); override provato su Caruso Speaker |
|
||||
| Chat a canali — portale + inbox admin per canale | ✅ in prod 2026-08-21 (`0021`); build verde, **mai provata a mano** |
|
||||
| Chat — modifica messaggi + firma admin da `settings` | ✅ in prod 2026-08-21 (`0022`); menzioni rimandate, manca l'attribuzione |
|
||||
| Portale — stati task leggibili (forma + pill + legenda) | 🔨 scritto 2026-08-22, build verde, **da vedere a schermo** |
|
||||
| D — Whop → audit | ⏸️ dipende dal motore v2.5 |
|
||||
|
||||
Progress: [███░░░░░░░] 25% (v2.5)
|
||||
@@ -92,7 +93,7 @@ Log completo in `PROJECT.md`. Vive per il lavoro corrente:
|
||||
|
||||
## Session Continuity
|
||||
|
||||
Last session: 2026-08-21
|
||||
Stopped at: **modifica dei messaggi** (stile Slack: illimitata, senza storico, etichetta «modificato» — scelta deliberata, motivata in `STATUS.md`) e **firma di chi risponde**, che era la stringa `iamcavalli` cablata nel pannello. Migration `0022` applicata a prod prima del push e riletta a conferma; il nome e la foto (URL esterno, l'upload su volume non esiste) stanno in `settings`, nessuna migration. La lezione da non perdere: il difficile non era scrivere la modifica ma **propagarla** — il poll filtra su `created_at`, che una modifica non cambia, quindi servono insieme il filtro allargato a `edited_at` **e** il watermark del client sul massimo dei due; una sola delle due e o la modifica non arriva, o arriva a ogni giro per sempre. Build e lint verdi. **Niente di tutto questo è stato provato a mano.**
|
||||
Next: (1) provare la chat in prod — la verifica che conta è modificare un messaggio admin con la chat del cliente aperta e vedere il testo cambiare da solo entro ~20s senza duplicarsi; (2) sbloccare TidyCal con token o documentazione; (3) `LEAD_WEBHOOK_SECRET` su Coolify — finché manca la route risponde 403 a tutti; (4) poi v2.5 da `src/lib/audit/schema.ts` + `agents/`.
|
||||
Last session: 2026-08-22
|
||||
Stopped at: **stati dei task leggibili nel portale cliente.** Nella Timeline lo stato era solo un cerchietto colorato — ambra e violetto indistinguibili a 20px, e tre stati su quattro senza alcun testo. Ora le quattro icone si distinguono per **forma** (vuoto → punto → spunta vuota → spunta piena), la pill di testo sta solo sui due stati ambigui, l'header della fase conta i task in attesa anche a card chiusa, e una legenda dice chi revisiona e che **ogni pagina include un giro di revisione**. La correzione che conta: **«In revisione» significa «aspetta l'OK del cliente», non controllo qualità interno** come scrive `5547e55` — è uno stato che *richiede un'azione*, e per questo non poteva restare muto. Barra di avanzamento invariata di proposito: cambia il tipo di lavoro, non l'avanzamento. Build, typecheck e lint verdi, nessuna migration. **Non ancora visto a schermo.**
|
||||
Next: (1) verificare in prod con `?preview=1` su **Caruso Speaker, fase «3 - Esecuzione»** — l'unica dove «In corso» e «In revisione» convivono (4 + 2 su 11), quindi l'unica dove si vede se ora si distinguono; (2) provare la chat in prod: modificare un messaggio admin e vederlo cambiare da solo entro ~20s senza duplicarsi; (3) sbloccare TidyCal con token o documentazione; (4) `LEAD_WEBHOOK_SECRET` su Coolify, senza cui `/api/webhooks/lead` risponde 403 a tutti; (5) poi v2.5 da `src/lib/audit/schema.ts` + `agents/`.
|
||||
Resume file: None
|
||||
|
||||
Reference in New Issue
Block a user