> ## Documentation Index
> Fetch the complete documentation index at: https://docs.switchbord.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Confine di persistenza

> Come funziona la proprietà del database in questo repo e come evolverla senza creare proliferazione di provider.

# Confine di persistenza

Questo repo eredita la parte utile della filosofia database di `next-forge`, non lo stack di provider predefinito.

La parte utile è:

* mantenere la proprietà del database dentro `@repo/database`
* mantenere la proprietà di auth/sessione dentro `@repo/auth`
* far sì che le app importino confini di proprietà dei package invece dei client provider grezzi

Questo repo è **Supabase-first** e **guidato da migration SQL**. **Non** è attualmente un sistema con vera abstrazione ORM.

## Verità attuale

* `packages/database` è il confine del data-plane.
* `packages/auth` possiede gli helper di autenticazione Supabase scoped alla richiesta e scoped al browser.
* `supabase/migrations` è la fonte di verità dello schema.
* molte superfici di runtime funzionano ancora tramite un adapter basato su mock.

Cosa manca oggi:

* interfacce di repository stabili
* una separazione netta tra adapter mock e Supabase
* un contratto onestamente agnostico dal provider che si possa cambiare rapidamente dietro le quinte

## Regole per il futuro

* Metti l'accesso ai dati in `packages/database`.
* Metti gli helper di auth/sessione in `packages/auth`.
* Non importare `@supabase/supabase-js` direttamente nelle app per il lavoro sul data-plane.
* Non affermare che il repo sia intercambiabile a livello di ORM finché le implementazioni mock e Supabase non si conformano alle stesse interfacce di repository.
* Quando la persistenza cambia, aggiorna insieme la documentazione delle migration e il contratto del package database.

## Direzione della migration

La sequenza prevista è:

1. definire le interfacce di repository in `packages/database`
2. separare gli adapter mock e Supabase
3. standardizzare gli script di migration root e generazione dei tipi
4. rimuovere i residui fuorvianti di Prisma dalle linee guida attive
5. mantenere le future modifiche di provider o ORM contenute dentro `@repo/database`

## Leggi anche

* [Architettura per contributori](/it/contributing/architecture)
* [Sviluppo](/it/development)
* [Piano di migration](/it/platform/migration)