davideandClaude Opus 5
93b61d422a
Le tabelle della v1.0 sono nate con policy USING (true) per anon e authenticated. M4 ha tolto il GRANT ad anon e la cosa è passata per "ora è chiuso", ma per gli autenticati non era rimasto nessun limite. Verificato sul database locale con un utente appena creato, senza ruolo e senza slot nella rosa: POST su eventi_app risponde 201, DELETE risponde 200. Qualsiasi giocatore loggato poteva svuotare il calendario o riscrivere il voto di un altro parlando direttamente con PostgREST, saltando l'interfaccia che quei pulsanti glieli nasconde. Il permesso viveva solo nei componenti, cioè nel posto che un attaccante non usa. M11 fa dire alle policy quello che l'interfaccia già fa: eventi_app agli admin, risposte_presenze e cacche_partita alla propria riga, i tre voti al proprio votante_id. L'admin resta incluso ovunque, perché DD-017 gli riconosce già il diritto di agire al posto del giocatore. turni_palloni e le tabelle scout restano aperte di proposito: nell'interfaccia non hanno nessun gate, quindi stringerle sarebbe una funzionalità nuova e non una messa in sicurezza. Un test lo fissa, così se il gate arriva qualcuno se ne accorge. L'identità è lo slot di giocatori_squadra collegato all'account, con lo stesso EXISTS delle policy dei profili: mio_giocatore_id() di M2 era già stata rimossa dalla migration di correzione e non va reintrodotta. I cinque test nuovi in permessi.test.ts hanno ognuno il proprio controllo positivo — l'admin crea l'evento, il giocatore salva la propria presenza — perché un database che rifiuta tutto passerebbe qualsiasi test di sola negazione. Provata con db reset da zero; non applicata in produzione. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Documentazione CrAPP
Indice della documentazione ufficiale del progetto. Ogni file risponde a una domanda precisa: se l'informazione che cerchi non è nel file indicato, probabilmente non esiste ancora e va prima documentata (vedi DD-002).
Dove sta cosa
| Documento | Risponde a |
|---|---|
| VISION.md | Perché esiste CrAPP, quali principi deve rispettare una funzionalità |
| ROADMAP.md | Cosa è fatto e cosa è previsto, versione per versione |
| ARCHITECTURE.md | Com'è fatta l'app: stack, struttura del codice, flusso di sviluppo |
| DATABASE.md | Quali tabelle esistono, a cosa servono, chi le usa |
| DESIGN_DECISIONS.md | Perché abbiamo scelto così, cosa abbiamo escluso e quando riaprire la scelta |
| PORTABILITA.md | Cosa lega l'app a un fornitore e cosa no, come spostarla su server proprio |
| EFFICIENZA_CLOUD.md | Come tenere basso il consumo cloud: cache, query, push |
| TODO.md | A cosa si sta lavorando adesso |
| CHANGELOG.md | Cosa è cambiato e quando |
| modules/ | Specifica funzionale di ogni modulo, una per file |
Le regole vincolanti per gli assistenti AI stanno in AGENTS.md; lo stato corrente del lavoro in PROJECT_STATE.md.
Ordine di lettura
Prima di modificare il codice, nell'ordine: questo indice → VISION.md → ROADMAP.md →
ARCHITECTURE.md → DATABASE.md → DESIGN_DECISIONS.md → TODO.md → il documento del
modulo interessato in modules/.
Regole di manutenzione
Ogni informazione ha una sola casa, per evitare che le copie divergano:
- l'elenco delle funzionalità (fatte e previste) sta solo in
ROADMAP.md; CHANGELOG.mdregistra quando qualcosa è stato rilasciato, non ripete l'elenco;TODO.mdcontiene solo il lavoro in corso o imminente, e rimanda alla roadmap;- lo schema del database sta solo in
DATABASE.md, allineato alle migration insupabase/migrations/: una tabella nuova si documenta nella stessa modifica che la crea; - le motivazioni stanno solo in
DESIGN_DECISIONS.md, in vociDD-XXX; per aggiungerne una si copia _template-dd.md.
Convenzioni di scrittura: un solo titolo # per file (le sezioni interne partono da ##),
niente --- come riempitivo tra i paragrafi, tabelle al posto degli elenchi ripetitivi.