Files

T

simone 2e9bd2ab60 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 dice 5547e55, 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 di 5547e55, 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>

2026-08-22 14:24:35 +02:00

8.6 KiB

Raw Blame History

gsd_state_version, milestone, milestone_name, status, stopped_at, last_updated, last_activity, progress

gsd_state_version

milestone

milestone_name

status

stopped_at

last_updated

last_activity

progress

1.0

v2.5

Audit

executing

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'.

2026-08-22T12:10:00.000Z

2026-08-22 -- stati dei task leggibili nel portale cliente (icone, pill, legenda)

total_phases	completed_phases	total_plans	completed_plans	percent
4	0	4	0	25

Project State

Digest breve, per orientarsi. Narrativa e lezioni → STATUS.md (root); requisiti → REQUIREMENTS.md; tutte le fasi → ROADMAP.md. Questo file resta sotto le 100 righe: lo impone il template GSD.

Project Reference

See: .planning/PROJECT.md · Core value: il cliente apre il link e vede a che punto è il suo progetto, senza scrivere email. · Current focus: modifiche hub (v2.5 in pausa).

Current Position

v2.5 è in pausa per scelta (2026-08-19): prima le modifiche all'hub, poi il motore. Phase 27 resta a metà — schema e fonti in prod, resto da scrivere.

Blocco (modifiche hub)	Stato
A — Progetti (via commenti/timer, riepilogo, timer per task)	✅ in produzione 2026-08-19
B — Dashboard (inbox, linee di prodotto, timeline consegne)	✅ in produzione 2026-08-19
C1 — `POST /api/webhooks/lead`	✅ in produzione, provato contro il DB vero
C2 — TidyCal	⛔ [BLOCCANTE] vedi sotto
C3 — Alleggerire l'hub	⏸️ senza perimetro
Rifiniture — tassonomie, "In revisione", tab pagamenti, riordino task	✅ in prod 2026-08-20 (migration `0019`)
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)

Dove sta cosa

Fuori dal repo, e senza questi niente è ricostruibile: i piani in ~/.claude/plans/ — …woolly-puddle.md (documento audit), …radiant-valley.md (motore), sei-arrivato-qua-search-recursive-kettle.md (modifiche hub).

Cosa (audit)	Dove	Stato
Schema, 7 tabelle + rubrica 264 voci	`0017_audits.sql`, `checklist_items`	in produzione
Fonti del motore (5 moduli)	`src/lib/audit/sources/`	in prod ma inerte: nessuna route lo chiama
Agent, sintetizzatore, pipeline, editor, pagina	`src/lib/audit/`, `src/app/{admin/audit,audit}`	da scrivere
L'unico audit prodotto finora	`spike-audit-giojello.com.json` (gitignorato)	spike 2026-08-16, zero rilevazioni

Come funziona il motore

Raccolta in parallelo (nessun LLM, nessun browser headless) → quattro sub-agent → sintetizzatore che incrocia le osservazioni in massimo 10 finding. Vincolo che regge tutto: un numero entra solo se misurato, rintracciabile in audit_runs.raw. Passo per passo in STATUS.md e in …radiant-valley.md.

Accumulated Context

Decisions

Log completo in PROJECT.md. Vive per il lavoro corrente:

[2026-08-20] Gli importi scritti a mano non si ricalcolano — amount_locked esclude la riga da rescalePayments, e lo scarto fra somma rate e totale si dichiara invece di aggiustarlo. Il backfill dell'ordine rate va per percent DESC, non per ctid: 3 progetti su 5 erano già scombinati e l'ordine fisico avrebbe fissato l'errore.
[2026-08-20] Rinominare una fase rinomina anche le fasi dei progetti — non c'è FK fra tassonomia e phases: importOfferIntoProject riconosce una fase solo dal titolo (offer_phase_id non viene mai popolata). Senza propagazione, il re-import di un'offerta crea una fase duplicata accanto a quella vecchia. È l'unico rename che scrive fuori dal catalogo, quindi l'unico con conferma.
[2026-08-19] Prima l'hub, poi il motore — le modifiche all'hub sono indipendenti e a basso rischio, il motore no. Il Whop → audit resta ultimo perché dipende dal motore.
[2026-08-19] L'incassato non attribuibile si mostra, non si spalma — i pagamenti stanno sul progetto, non sull'offerta. Un progetto senza offerta finisce in una riga "Senza offerta" separata: spalmarlo darebbe un totale che quadra e righe che mentono.
[2026-08-19] Il tempo lavorato sopravvive alla cancellazione del task — ON DELETE SET NULL, mai cascade: con cascade, ripulire una fase abbasserebbe in silenzio il fatturato tracciato.
[2026-08-18] Audit: design system dell'area admin; nessun renderer headless (il VPS non regge Chromium); laboratorio ≠ campo, quindi nomi distinti per Lighthouse e CrUX; la checklist alimenta il motore, non il documento. Per esteso in STATUS.md.

Blockers/Concerns

[BLOCCANTE] TidyCal non ha webhook (verificato 2026-08-19 sulla loro FAQ; la via suggerita è Zapier/Make). La REST API c'è, con Personal Access Token su tutti i piani, ma path, filtri e paginazione stanno dietro il login. Sblocca: l'utente apre tidycal.com/integrations → API Keys e passa token o documentazione. Non dedurre la forma dell'API dai docs.
[BLOCCANTE] LEAD_WEBHOOK_SECRET non è su Coolify: finché manca, /api/webhooks/lead risponde 403 a tutti (fallimento chiuso voluto). Sblocca: l'utente la imposta.
Il 100% dell'incassato è "Senza offerta" — Caruso Speaker e Protocollo Estetico: 5.300 € senza offerte assegnate. Si sistema assegnandole dai rispettivi progetti. Il payload Elementor, intanto, non è ancora verificato sul campo: gestito in modo difensivo, serve un invio vero.
Il copy del template v1 non ha fonte nel repo — il prototipo Giojello non c'è: testi e gerarchia dei blocchi da recuperare prima di Phase 30.
Audit, da vedere sul campo: il caso "zero dati CrUX" (test 5) e quanto del 52% non verificabile da HTML statico recuperi Lighthouse (test 3). Whitelist portale vuota per 3 clienti su 4 — si popola da /admin/clients/<id>.
.env.local NON è allineato a Coolify: ADMIN_PASSWORD, NEXTAUTH_SECRET e la password del DB sono stale, e l'host che scrive (178.104.27.55:5432) è chiuso — il DB vero è su 127.0.0.1:54321 dietro tunnel SSH. Estrarre la password viva dal container è bloccato dal classifier e non va aggirato. Rendere in locale contro i dati veri oggi non si può (2026-08-21); sblocca: l'utente riallinea il file alle variabili di Coolify. Le migration non ne soffrono, e resta valido il resto della procedura: ogni fase con schema applica la migration a prod prima del push del codice.
Debito design (DEBT-01) — ~40 file, ~450 occorrenze. Dettaglio in STATUS.md.

Deferred Items — vedi `REQUIREMENTS.md` § Backlog e § Rinviati da v2.5.

Session Continuity

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

8.6 KiB Raw Blame History