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:

docs/support/MANUALE-SVILUPPO-OPERATIVO.md per la logica generale e l effetto pratico
docs/support/BUG-RISOLTI-E-VALIDAZIONI.md per fix, regressioni e stato test
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

3.6 KiB Raw Blame History