# Distribuzione server e debug separato

## Obiettivo

Portare NetGescon fuori dalla sola rete locale e iniziare a lavorare con nodi separati per:

- deploy piu stabili
- collaudo fuori macchina sviluppo
- debug su ambienti isolati
- verifica reale di update, restore e sincronizzazioni

## Punto di partenza

Oggi il flusso piu stabile e:

1. sviluppo nel workspace Day0
2. commit e push su Gitea
3. sync UI da `Supporto > Modifiche`
4. verifica su staging

Questo flusso va mantenuto anche quando iniziamo a distribuire NetGescon su altri server.

## Strategia consigliata

### Fase 1. Nodo staging separato e disciplinato

Obiettivo:

- continuare a usare staging come nodo intermedio obbligatorio
- verificare che update, migrazioni e ricuciture dati passino sempre dalla procedura Git-first

Vincoli:

- niente modifiche manuali non tracciate sul nodo
- niente deploy paralleli fuori procedura

### Fase 2. Nodo debug esterno alla rete locale

Obiettivo:

- avere una macchina separata dalla rete di sviluppo
- usare dati di test controllati
- validare comportamento applicativo, login, PBX, allegati, storage, update

Uso consigliato:

- test deployment
- test restore
- test debug multi-macchina
- verifiche su watcher o bridge che non devono vivere solo sul PC principale

### Fase 3. Pacchetto installabile ripetibile

Obiettivo:

- trasformare NetGescon in un installabile coerente
- poter allestire un nuovo nodo senza ricostruire a mano script, env e procedure

Minimo indispensabile:

- checklist server
- script bootstrap
- procedura aggiornamento
- procedura backup e restore
- note di rete e storage

## Architettura iniziale consigliata

Per il primo ciclo non serve un parco complesso di macchine.

Bastano tre ruoli chiari:

1. workspace autorevole Day0
2. staging operativo aggiornato da Gitea
3. debug node separato per prove e collaudi fuori rete locale

## Cosa validare sul debug node

- installazione applicativa pulita
- migrazioni e bootstrap
- login e permessi ruoli
- documentazione in `Supporto > Modifiche`
- procedura Git sync e pacchetto aggiornamento
- Post-it, ticket e CRM telefonico
- storage tenant-aware e documenti sensibili
- eventuali watcher PBX o bridge esterni

## Regola pratica per il deploy

Ogni nodo deve poter essere ricostruito da materiale nel repository.

Quindi il repo deve contenere almeno:

- manuale operativo
- flusso update staging
- architettura ruoli/moduli
- note continuita agent
- script di update e di sync gia usati dalla UI

## Decisione attuale

Per il prossimo passo concreto:

1. completare il commit del slice corrente
2. aggiornare staging via Git-first
3. preparare una checklist tecnica per il primo nodo debug esterno
4. poi estrarre un bootstrap server riusabile, senza dipendere dalla macchina locale