Manuale sviluppo operativo NetGescon

Scopo della sezione

Questa documentazione serve a evitare dispersione di informazioni tra chat, script, note locali e memoria personale.

La regola pratica e semplice:

Per il dettaglio del flusso Git-first di staging fare riferimento anche a:

sviluppo nel workspace Day0
test locale mirato sulla funzione toccata
aggiornamento del file manuale o bug corrispondente
commit Git con messaggio leggibile
push su Gitea
aggiornamento del nodo dalla pagina admin-filament/supporto/modifiche con sync Git da Gitea
verifica finale su staging

[P] il progetto inizia ad avere una memoria strutturale interna, non solo conversazionale
[P] l agent puo leggere direttamente dal repository cosa e stato fatto, perche e stato fatto e quali file sono coinvolti
[U] chi opera dalla UI trova nello stesso punto manuale, aggiornamenti, bug e note commit
[P] dopo ogni Git staging puo essere riallineato da Gitea direttamente dalla UI, senza terminale
[P] il changelog Git automatico puo essere rigenerato sul nodo senza sporcare il repository locale

Separato il tab tecnico SMDR dal tab CTI / CSTA e Click-to-Call in strumenti/post-it-gestione.
Esposta in UI una vista piu orientata al provider PBX, non solo a Panasonic.
Aggiunta la creazione di richieste click-to-call direttamente dai messaggi tecnici CSTA.
Mantenuta la base attuale Panasonic, ma con direzione compatibile con future integrazioni FreePBX.

Effetto pratico:

[U] test piu precisi tra tracciato passivo SMDR e canale CTI/CSTA
[U] possibilita di verificare il flusso di chiamata originata dal gestionale verso il telefono/interno associato
[P] base piu riusabile per l adapter PBX successivo

gescon/ordinarie ora eredita l anno attivo dal contesto topbar.
La risoluzione dei codici legacy stabile e stata centralizzata in StabileContext.
condomini/servizi-utenze e l archivio letture applicano l anno attivo e il contesto stabile in modo piu coerente.

Effetto pratico:

[U] riduzione dei casi in cui l header mostra uno stabile/anno ma i dati arrivano da un altro contesto
[U] base piu affidabile per estrazioni acqua e verifiche contabili per gestione
[P] meno logica sparsa con chiavi session legacy non coerenti tra le pagine

La pagina ha gia tab per aggiornamenti, bug, commit e migliorie.
Ora diventa anche punto di lettura del manuale strutturale dal repository.
La sezione manuale espone anche la sync Git/Gitea per staging con stato del repository e avanzamento job.
La tab Aggiornamenti + Bug espone in chiaro sia il comando predisposto usato dalla UI sia gli aggiornamenti inclusi nel riallineamento Git.

Effetto pratico:

[P] una sola sezione per spiegare, tracciare, aggiornare e riprendere il lavoro
[U] piu semplice per chi usa il gestionale capire cosa e stato aggiunto o corretto

Quando completiamo una modifica, aggiorniamo almeno uno di questi livelli:

manuale operativo se cambia il modo di lavorare o una funzione importante
bug risolti se correggiamo un errore o un comportamento incoerente
note commit se il commit ha dettagli utili ma troppo specifici per stare nel manuale

usare questa sezione come fonte primaria per le prossime implementazioni CTI e contabilita
automatizzare anche la scrittura di snapshot di sviluppo basati sui commit e sulle note operative
aggiungere progressivamente how-to piu mirati, senza spargere file duplicati