84 lines
3.6 KiB
Markdown
84 lines
3.6 KiB
Markdown
# 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`
|