Files

T

davideandClaude Opus 5 e1e8dd5415 Reorganize documentation and unify the AI assistant rules

Documentation:
- Add docs/README.md, the documentation index that AGENTS.md pointed to as the
  first file to read but which did not exist.
- One home per piece of information: the feature list stays in ROADMAP.md,
  CHANGELOG.md records only when something shipped, TODO.md only ongoing work.
  Reconcile the entries that had drifted (CSI was both done and pending;
  pagelle, badge social and serie were missing from the roadmap).
- Rewrite DATABASE.md as tables: add giocatori_squadra (already created by a
  migration) and profili_giocatore (planned in DD-016), fix the wrong heading
  levels, drop the duplicated roadmap.
- DESIGN_DECISIONS.md: move the index to the top and sort it, extract the
  template into _template-dd.md.
- ARCHITECTURE.md becomes the technical reference; CLAUDE.md no longer
  duplicates it.
- Add docs/EFFICIENZA_CLOUD.md with the rules previously kept in mem/,
  separating what the code enforces from the goals not yet implemented.
- Fix statements the code contradicted: mutations use setQueryData rather than
  invalidateQueries, and scout_sessioni and giocatori_squadra are not read by
  the code yet.
- Track the v1.0 modules with no spec in docs/modules/ from TODO.md.

AI assistants:
- AGENTS.md is the single source of the rules, now including the technical
  constraints only Claude Code knew about (generated files, Vite plugins, data
  access) and an end-of-work checklist that applies to every assistant.
- CLAUDE.md and .cursor/rules/crapp.mdc point to AGENTS.md instead of
  restating it.
- Remove the five .cursor/*.md files, which Cursor never loaded.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-30 16:26:14 +02:00

2.1 KiB

Raw Blame History

Efficienza cloud

Regola di progetto: CrAPP gira su un piano cloud minimo (Supabase + Vercel) per ~17 utenti. Query, traffico e invocazioni vanno tenuti al minimo per costruzione, non ottimizzati dopo.

Regole da rispettare

Niente polling: mai refetchInterval verso il database. Per sincronizzare più schede aperte si usano BroadcastChannel o gli eventi di storage.
Cache lunga e passiva: i default del QueryClient stanno in src/router.tsx (staleTime 5 min, gcTime 30 min, refetchOnWindowFocus/Mount/Reconnect disattivati, retry: 1). Non alzare la frequenza di refetch modulo per modulo.
Dopo una mutazione si aggiorna la cache con setQueryData, non con invalidateQueries: invalidare costa una rilettura. Unica eccezione oggi: src/lib/scout-live.ts.
Scout Live: scrive solo chi sta segnando; gli altri leggono dati già salvati.
Write once, read many: statistiche, badge e classifiche si calcolano una volta e non si ricalcolano a ogni apertura di pagina. I badge restano calcolati a runtime dai dati già in cache, senza query aggiuntive (DD-007): src/lib/rosa.ts aggrega ciò che è già stato letto.
Push solo per eventi importanti: convocazioni, promemoria allenamento/partita, turno palloni, esito finale.
Niente funzionalità pesanti: foto, video, chat.
Indici sui campi usati per filtri e relazioni in ogni nuova migration.

Obiettivi non ancora attuati

Questi punti sono stati definiti come direzione, ma non sono implementati: non descrivono il comportamento attuale.

Dati CSI: sincronizzazione periodica server-side salvata su una tabella locale, con l'app che legge solo dal database interno. Oggi la lettura è live dal portale a ogni richiesta, tramite /api/public/csi (vedi modules/collegamento-csi.md).
Aggregati persistiti: uno schema con statistiche_aggregate e classifica_csi è stato ipotizzato ma non esiste; nessuna di quelle tabelle è in supabase/migrations/. Va valutato con una decisione dedicata, perché tocca DD-007 (badge e statistiche calcolati a runtime).

2.1 KiB Raw Blame History

Efficienza cloud

Regole da rispettare

Obiettivi non ancora attuati

2.1 KiB

Raw Blame History