# 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