# Continuita sviluppo e agent

## Scopo

Questo file serve a dare continuita alle prossime sessioni di sviluppo senza dover rileggere ogni volta tutti gli script o ricostruire il contesto dai commit.

## Regola semplice

Quando facciamo una modifica significativa, aggiorniamo tre livelli diversi solo se servono:

1. `docs/support/MANUALE-SVILUPPO-OPERATIVO.md` per la logica generale e l effetto pratico
2. `docs/support/BUG-RISOLTI-E-VALIDAZIONI.md` per fix, regressioni e stato test
3. tab `Commit + Note` in `Supporto > Modifiche` per contesto breve ma utile al riaggancio

## Cosa deve poter leggere un agent

Un agent deve trovare rapidamente:

- qual e il workspace autorevole
- qual e il flusso Git reale
- quali aree sono state appena toccate
- quali bug sono stati corretti e cosa resta da verificare
- qual e lo stato operativo del PBX Panasonic e quali test sono ancora aperti
- qual e la decisione corrente su storage, isolamento dati e tenancy
- quali documenti sono la fonte principale invece di note sparse

## Flusso operativo consigliato

### Dopo una modifica piccola

- aggiorna il changelog funzionale se impatta l utente o il flusso operativo
- aggiungi una nota commit se il messaggio Git non basta

### Dopo una modifica strutturale

- aggiorna il manuale operativo
- aggiorna il registro bug/fix se il lavoro nasce da un problema concreto
- verifica che la pagina `Supporto > Modifiche` mostri il nuovo materiale

### Dopo il push

- usa il tab manuale di `Supporto > Modifiche` per lanciare la sync da Gitea sul nodo interessato
- annota eventuale esito tecnico se c e stato un problema o un comportamento speciale

## Convenzione minima per scrivere

- frasi corte
- una sezione = un obiettivo
- distinguere chiaramente `implementato`, `validato`, `da verificare`
- evitare duplicati: se un dettaglio e manuale generale non riscriverlo come nota commit lunga

## Collegamenti utili

- `docs/README.md`
- `docs/NETGESCON-MODIFICHE.md`
- `docs/support/MANUALE-SVILUPPO-OPERATIVO.md`
- `docs/support/PBX-PANASONIC-STATO-OPERATIVO.md`
- `docs/support/ARCHITETTURA-STORAGE-TENANCY.md`
- `docs/support/BUG-RISOLTI-E-VALIDAZIONI.md`

## Direzione architetturale attuale

- Day0 resta il workspace e repository autorevole
- Git -> Gitea -> staging resta il flusso operativo reale
- staging deve potersi riallineare da interfaccia web senza richiedere terminale all operatore
- CTI/PBX va tenuto aperto a provider diversi, senza chiudersi su Panasonic
- le pagine gestionali devono seguire il contesto condiviso topbar per stabile e anno

## Stato utile da ricordare dopo questo slice

- `Supporto > Modifiche` e il punto da cui l operatore deve poter riallineare staging e far partire anche la ricucitura rubrica sicura.
- `Strumenti > Post-it Gestione` mostra ora un livello operativo raggruppato per richiami consecutivi, non solo righe singole.
- `Strumenti > Post-it` sta diventando il punto unico dove inserire, prendere in carico e indirizzare il Post-it verso operatore, collaboratore o fornitore.
- `Impostazioni > Scheda Amministratore > PBX / TAPI` e gia il posto giusto per accumulare segnali PBX osservati e mapparli alle persone reali dello studio.
- la direzione architetturale e `coworking unico + moduli abilitabili + ruoli multipli sulla stessa base dominio`
- il prossimo fronte infrastrutturale non e una rivoluzione immediata a microservizi, ma la distribuzione controllata su nodi separati per debug e collaudo fuori rete locale

## File nuovi o da leggere per ripartire

- `docs/support/ARCHITETTURA-RUOLI-MODULI-COWORKING.md`
- `docs/support/DISTRIBUZIONE-SERVER-DEBUG.md`
- `docs/support/CRM-ANAGRAFICA-LEGAMI.md`
- `docs/support/AGGIORNAMENTI-STAGING-GIT.md`