davideandClaude Sonnet 5.5
8f25143aa5
- Spezza il registro delle decisioni in docs/decisions/DD-XXX.md, con indice - Ripulisce DATABASE.md dalla storia delle migration e aggiunge la sezione Lettura - Riduce PROJECT_STATE.md a una pagina; la procedura di allestimento passa in OPERATIONS.md - Aggiunge OPERATIONS.md, GLOSSARIO.md, trappole note e checklist in ARCHITECTURE.md - Sintetizza la copertura test di badge.md e documenta docs/archive - Allinea AGENTS.md, README.md e la regola Cursor (tolto l'obbligo di develop, in contrasto con DD-019) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2.9 KiB
DD-034 — L'allenatore è uno slot della squadra con tipo diverso, non un giocatore
Data: 24 settembre 2026
Stato: Accettata (implementata con le migration M20 e M21)
Contesto
Serve un account per l'allenatore: deve gestire gli eventi (oggi solo admin, m11) ma non è
un giocatore. Non ha statistiche, badge né stagione, non vota e non viene votato. L'admin
vuole registrarlo come i giocatori, inserendo la sua email Gmail. Specifica completa in
modules/allenatore.md.
Decisione
L'allenatore è una riga di giocatori_squadra con una nuova colonna tipo = 'allenatore'
(default 'giocatore'). Così riusa senza cambiarli il collegamento per email (DD-018),
profili_giocatore per i dati personali, il bucket avatar e il compleanno sincronizzato
(DD-031). Il permesso di gestire gli eventi arriva da un nuovo valore allenatore di
app_role in user_roles (DD-011), scritto da una funzione SECURITY DEFINER quando si
collega uno slot di tipo allenatore: è quindi l'admin a concederlo, registrando lo slot.
"Rosa" diventa attivo e tipo = 'giocatore' ovunque.
Alternative scartate
- Una tabella
staffseparata → isola l'allenatore da voti e rosa senza toccare i filtri, ma duplica collegamento per email, profilo, avatar e form admin. Resta l'alternativa se i filtri sulla rosa si rivelano troppi o fragili. - Registrare l'allenatore come admin → gli darebbe dati personali e documenti di tutta la squadra (DD-017), molto più del necessario.
- Distinguere l'allenatore dal campo
ruolo(ruolo in campo) → mescola due concetti e il campo è testo libero.
Conseguenze
- Ogni lettura della rosa (client, server, SQL di voto e promemoria) va filtrata per
tipo: un punto dimenticato rende l'allenatore votabile o lo conta tra i convocati. L'elenco sta nella specifica e va coperto dai test dipermessi.test.ts. - Il trigger sugli slot cambia:
tipolo scrive solo l'admin; nome e cognome li scrive anche l'allenatore sul proprio slot. numerodiventa nullabile a database, ma solo per gli allenatori (vincolo di M21); nell'app resta un numero, 0 per l'allenatore, per non toccare i tipi di tutta la rosa.- Due fonti distinte, ciascuna per il suo scopo: i permessi (eventi, sollecito) da
user_roles, la visibilità (badge, cacche, stagione) dal tipo del proprio slot, che è immediato e non aspetta la query dei ruoli. - L'allenatore non vede le tab Stagione e Badge del Profilo, né Obiettivi e Badge di Squadra.
- In Squadra compare nella tab Rosa con «Allenatore» al posto del ruolo, ricavato da
tipo; riceve i promemoria degli eventi (dal 29/09/2026 non più: DD-039) e può sollecitare le presenze, non il turno palloni. - Non vede badge né classifiche o sondaggi sulle cacche, in nessuna schermata.
Riesame
Se arriva un secondo tipo di staff (dirigente, segreteria) o se i filtri sulla rosa diventano
fonte di bug, passare alla tabella staff separata.