docs: aggiungi il documento delle modifiche del 28/07/2026
Elenco dei 15 punti concordati con Trafilo, con lo stato verificato sul codice al
commit 2a56632, l'architettura d'installazione decisa il 28/07 e le nove domande
la cui risposta dipende dal cliente. E' il riferimento del lavoro su V3.0.0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Adriano Dal Pastro
@@ -0,0 +1,614 @@
|
||||
# TieMeasureFlow — modifiche da apportare
|
||||
|
||||
**Data:** 28 luglio 2026 (agg. serale: architettura d'installazione, punti 7-8 precisati, punti 14-15 nuovi, timer bidirezionale nel punto 3)
|
||||
**Riferimento codice:** branch `V2.0.0`, commit `2a56632`
|
||||
**Destinatari:** Parte 1 leggibile da cliente e rivenditore · Parte 2 per chi mette mano al codice
|
||||
|
||||
---
|
||||
|
||||
## Come leggere questo documento
|
||||
|
||||
La **Parte 1** dice *cosa deve fare* il sistema e *perché*: si può mandare a Ricerca e
|
||||
Misure e a Tràfilo. La **Parte 2** dice *dove si interviene*, con file e criteri di
|
||||
completamento. La **Parte 3** elenca le domande la cui risposta non dipende da noi.
|
||||
|
||||
Ogni punto porta lo **stato verificato sul codice**, non riferito: `già fatto`,
|
||||
`parziale`, `da fare`. Serve a evitare l'equivoco emerso in questi giorni — diverse
|
||||
funzioni risultano "già implementate" perché **l'interfaccia c'è**, ma dietro non
|
||||
succede nulla.
|
||||
|
||||
**Fonti:** specifica *Schema sviluppo SW TieFlow rev. 04-2026*; *MODIFICHE TIEMEASURE
|
||||
v260519*; call del 28/07/2026; rettifica di Marco Menoncin del 28/07; lettura diretta
|
||||
del codice.
|
||||
|
||||
---
|
||||
|
||||
## Il punto che regge tutti gli altri
|
||||
|
||||
**Lo stato della produzione oggi vive dentro una pagina del browser.**
|
||||
|
||||
Il timer, il conteggio dei cicli, il flag "produzione avviata" e le misure in corso
|
||||
sono variabili del componente Alpine di `task_execute.html`. La navigazione fra un
|
||||
task e l'altro è un **ricaricamento completo di pagina** (`window.location.href`).
|
||||
|
||||
Conseguenza diretta: **cambiando task si perde tutto.** Il timer smette di esistere,
|
||||
il conteggio dei cicli riparte, "produzione avviata" si dimentica.
|
||||
|
||||
Questo spiega, senza bisogno di altre ipotesi:
|
||||
|
||||
- perché il loop di misura non regge quando la ricetta ha altri task dopo la misura;
|
||||
- perché con più task di misura non si sa a quale tornare allo scadere del timer;
|
||||
- perché *fermo linea* e *fine produzione* non hanno nulla da fermare o da chiudere;
|
||||
- perché non esiste storico di cosa è successo durante una produzione.
|
||||
|
||||
**Va risolto per primo**: i punti 2, 3, 6 e 8 dipendono da questa scelta, e affrontarli
|
||||
prima significa rifarli dopo.
|
||||
|
||||
---
|
||||
|
||||
## Architettura d'installazione (decisa il 28/07)
|
||||
|
||||
Chiude la domanda D-3 lato Tielogic. L'installazione a Tràfilo è così composta:
|
||||
|
||||
```
|
||||
SERVER (uno, del cliente) STAZIONE (una per PC, installata in locale)
|
||||
┌─────────────────────────┐ ┌──────────────────────────────────────┐
|
||||
│ MySQL │◄──API──│ App di stazione: │
|
||||
│ Backend dati (API) │ │ · interfaccia operatore (frontend) │
|
||||
│ File dei disegni │ │ · agente hardware: calibro USB, │
|
||||
│ Migrazioni dello schema │ │ driver camera, colonnina/cicalino │
|
||||
│ Adattatore GAIA │ │ · elaborazione visione (futura: │
|
||||
└─────────────────────────┘ │ XF compare, pattern matching) │
|
||||
└──────────────────────────────────────┘
|
||||
```
|
||||
|
||||
- **Sul server vive tutto ciò che è stato**: il database, i file dei disegni, le
|
||||
migrazioni dello schema e l'unico punto di contatto col gestionale GAIA.
|
||||
Aggiornare la logica dati = un deploy, in un posto solo.
|
||||
- **Sulla stazione vive tutto ciò che tocca l'hardware**: calibro, telecamera,
|
||||
segnalazione luminosa/acustica, e in prospettiva l'elaborazione visione — che
|
||||
così non carica il server (rilevante per il dimensionamento, D-4).
|
||||
L'app di stazione è **senza stato**: non tocca il database direttamente, parla
|
||||
col backend dati via API e gli manda risultati e immagini.
|
||||
- **L'identità della stazione è data dall'installazione** (configurata sul PC),
|
||||
non più dal container sul server: il vincolo "una stazione = un container"
|
||||
decade.
|
||||
- La **licenza per postazione** ha l'aggancio naturale nell'app di stazione
|
||||
installata.
|
||||
|
||||
**Correzione a quanto detto in call:** i disegni **non stanno nel database** —
|
||||
stanno su filesystem (`uploads/`), serviti dal backend. Con questa architettura
|
||||
restano sul server, in un posto solo: nessuna cartella da sincronizzare fra i PC.
|
||||
|
||||
Conseguenza per lo sviluppo: lo stato della produzione (punto 1) va nel database
|
||||
**per obbligo architetturale**, non per scelta — con 20 app di stazione non esiste
|
||||
altro posto dove possa vivere.
|
||||
|
||||
---
|
||||
|
||||
# Parte 1 — Cosa deve fare il sistema
|
||||
|
||||
## Quadro: cosa già funziona
|
||||
|
||||
Da mettere a verbale, perché in parte era dato per mancante:
|
||||
|
||||
| Funzione | Stato |
|
||||
|---|---|
|
||||
| Stazioni e assegnazione ricette alle stazioni | ✅ presente |
|
||||
| Ruolo **capoturno** con autorizzazione a login | ✅ presente |
|
||||
| Timer d'intervallo misura con **conto alla rovescia a video** e cicalino | ✅ presente |
|
||||
| Logout automatico per inattività, configurabile | ✅ presente |
|
||||
| Tolleranze con soglie di attenzione (UTL/UWL/LWL/LTL) ed esito per quota | ✅ presente |
|
||||
| Versionamento delle ricette con storico delle modifiche | ✅ presente |
|
||||
| Registrazione del **tempo di inserimento** di ogni misura | ✅ presente (28/07) |
|
||||
| Pulsanti *Fermo linea*, *Fine produzione*, *Avvio produzione* | ⚠️ solo interfaccia |
|
||||
|
||||
L'ultima riga è la più importante: i tre pulsanti esistono, chiedono correttamente
|
||||
l'autorizzazione del capoturno, **e poi non fanno nulla**.
|
||||
|
||||
---
|
||||
|
||||
## 1. Memoria della produzione in corso `da fare` · prerequisito
|
||||
|
||||
**Oggi:** lo stato di una produzione esiste solo finché l'operatore resta sulla stessa
|
||||
schermata.
|
||||
|
||||
**Deve:** la produzione diventa un'entità con una vita propria — si apre quando parte,
|
||||
registra ciò che accade (avvio, cicli di misura, fermo linea, ripresa, chiusura) e si
|
||||
chiude quando il capoturno la chiude. Se l'operatore cambia task, esce e rientra, o il
|
||||
tablet si riavvia, la produzione è ancora lì con il suo timer.
|
||||
|
||||
**Perché conta:** senza questo, *fermo linea* e *fine produzione* non possono
|
||||
funzionare, il loop di misura non è realizzabile e non esiste il dato storico su cui
|
||||
poggiano sia la statistica sia l'integrazione col gestionale.
|
||||
|
||||
---
|
||||
|
||||
## 2. Tipo di task esplicito `da fare`
|
||||
|
||||
**Oggi:** il sistema distingue un task di misura da un task documentale **deducendolo**:
|
||||
se ha delle quote è una misura, altrimenti è una nota. Non esiste un tipo dichiarato.
|
||||
|
||||
**Deve:** ogni task nasce con un tipo scelto da chi crea la ricetta — **nota**,
|
||||
**misura**, **disegno** — predisposto per i tipi futuri (confronto profilo/DXF, misura
|
||||
con camera).
|
||||
|
||||
**Perché conta:** è la richiesta n. 1 di Menoncin, ed è ciò a cui si agganciano timer e
|
||||
loop. Con la deduzione attuale un task di misura a cui non sono ancora state inserite le
|
||||
quote viene trattato come una nota: il sistema si comporta in modo diverso a seconda di
|
||||
quanto è completa la ricetta.
|
||||
|
||||
---
|
||||
|
||||
## 3. Loop di misura e ripetizione `parziale`
|
||||
|
||||
**Oggi:** allo scadere del timer suona il cicalino e il ciclo si riazzera — ma solo se
|
||||
l'operatore è rimasto su quella schermata.
|
||||
|
||||
**Deve:**
|
||||
- l'operatore esegue i task in sequenza fino al primo task di misura;
|
||||
- da lì **resta in loop sulla misura** finché la produzione non viene chiusa;
|
||||
- il conto alla rovescia di **quanto manca alla prossima misura** è sempre visibile;
|
||||
- **arrivato a zero, il contatore riparte nell'altro senso**: mostra da quanto tempo
|
||||
si è **oltre** l'intervallo di misura, in evidenza — così il ritardo si vede, non
|
||||
si deduce (richiesta dell'operatore, 28/07);
|
||||
- allo scadere del timer la misura **si ripropone** ovunque si trovi l'operatore;
|
||||
- se la ricetta ha **più task di misura**, il timer riparte alla fine dell'**ultimo**;
|
||||
- dev'essere possibile **girare il pezzo e rimisurare** senza chiudere il ciclo.
|
||||
|
||||
**Perché conta:** è la seconda richiesta di Menoncin e il comportamento descritto al
|
||||
punto 4.10 della specifica del 19/05. La logica c'è già in gran parte: manca che
|
||||
sopravviva al cambio di schermata (punto 1).
|
||||
|
||||
---
|
||||
|
||||
## 4. Limite di tentativi prima del capoturno `da fare`
|
||||
|
||||
**Oggi:** l'operatore può ripetere la misura quante volte vuole.
|
||||
|
||||
**Deve:** dopo un numero di tentativi definito nella ricetta, per proseguire serve
|
||||
l'autorizzazione del capoturno.
|
||||
|
||||
**Perché conta:** è nella specifica ed è la contromisura al caso in cui si ripete finché
|
||||
non "viene bene". Il meccanismo di autorizzazione esiste già: manca il contatore e la
|
||||
soglia.
|
||||
|
||||
---
|
||||
|
||||
## 5. Avanzamento solo se in tolleranza `da verificare`
|
||||
|
||||
**Deve:** si passa alla quota successiva in autonomia **solo se la quota è in
|
||||
tolleranza**; per confermare una quota fuori tolleranza serve il capoturno.
|
||||
|
||||
**Nota:** il gate del capoturno per il fuori tolleranza è implementato. Va verificato
|
||||
sul campo che **blocchi davvero l'avanzamento** e non sia solo una richiesta di conferma.
|
||||
Se blocca, il punto si chiude senza sviluppo.
|
||||
|
||||
---
|
||||
|
||||
## 6. Fermo linea e Fine produzione: dare effetto `parziale`
|
||||
|
||||
**Oggi:** entrambi chiedono l'autorizzazione del capoturno, poi non succede niente.
|
||||
|
||||
**Deve:**
|
||||
- **Fermo linea** — sospende il timer e la produzione; il capoturno può riattivarla;
|
||||
- **Fine produzione** — chiude la produzione, ferma il timer definitivamente e **invia
|
||||
i dati di misura dell'intera produzione** al file di statistica.
|
||||
|
||||
**Perché conta:** il comportamento verso il gestionale è ancora da definire (Parte 3),
|
||||
ma **tutto ciò che sta prima del gestionale si può e si deve fare adesso**: sospendere,
|
||||
riprendere, chiudere, registrare. Consegnare i pulsanti funzionanti senza il gestionale
|
||||
è possibile; il contrario no.
|
||||
|
||||
---
|
||||
|
||||
## 7. Gestione delle stazioni `parziale`
|
||||
|
||||
**Deve:**
|
||||
- la lista stazioni mostra, oltre a codice e postazione, **le ricette collegate**;
|
||||
- esiste un **reset della stazione**, con un pulsante **per riga** nella lista:
|
||||
la stazione torna senza ricette associate e si riassegna (precisazione
|
||||
dell'operatore, 28/07);
|
||||
- la **stazione corrente si può cambiare al volo**, per poter provare più stazioni da un
|
||||
solo computer senza riconfigurare l'installazione.
|
||||
|
||||
**Perché conta:** è la terza richiesta di Menoncin. Il cambio al volo non è un vezzo da
|
||||
sviluppatori: senza, la sessione di collaudo con Menoncin richiede tanti PC quante sono
|
||||
le stazioni da provare.
|
||||
|
||||
---
|
||||
|
||||
## 8. Tracciabilità obbligatoria `parziale`
|
||||
|
||||
**Oggi:** numero di lotto e numero seriale sono facoltativi e si inseriscono nella lista
|
||||
task, cioè dopo aver iniziato.
|
||||
|
||||
**Deve:** l'obbligatorietà di lotto e seriale si **decide alla creazione della
|
||||
ricetta** (obbligatori sì/no); l'operatore li inserisce **alla selezione della
|
||||
ricetta**, e finché mancano il pulsante *Avvia* **non si attiva** (precisazione
|
||||
dell'operatore, 28/07).
|
||||
|
||||
**Perché conta:** una misura senza lotto non è tracciabile a posteriori, e la
|
||||
tracciabilità è metà del valore del sistema in un audit.
|
||||
|
||||
---
|
||||
|
||||
## 9. Blocco dell'inserimento manuale `da fare`
|
||||
|
||||
**Oggi:** il sistema registra **come** è stata inserita una misura (calibro o tastiera),
|
||||
ma accetta sempre entrambi.
|
||||
|
||||
**Deve:** un'impostazione della ricetta consente o vieta l'inserimento manuale, **con
|
||||
divieto come impostazione predefinita**: si misura col calibro.
|
||||
|
||||
**Perché conta:** è il punto sollevato in call — senza questo vincolo un valore in
|
||||
tolleranza si può digitare. Il dato su *come* è stata inserita c'è già: manca la regola
|
||||
che lo impedisce.
|
||||
|
||||
---
|
||||
|
||||
## 10. Interfaccia operatore: sequenza e conferme `da fare`
|
||||
|
||||
Richieste del 19/05, tutte di interfaccia:
|
||||
|
||||
- un pulsante che **avvia i task in sequenza**, senza sceglierli a uno a uno;
|
||||
- la lista completa dei task retrocessa a **secondo livello**, per tornare a vedere i
|
||||
task precedenti;
|
||||
- «inizia misure» rinominato **«visualizza singolo TASK»**;
|
||||
- dentro il task, «Riepilogo» sostituito da **«Completato»** per passare al successivo;
|
||||
- un task lasciato a metà **resta incompiuto** e si vede;
|
||||
- «fine ciclo misura» **cliccabile solo quando tutte le quote hanno un valore**.
|
||||
|
||||
---
|
||||
|
||||
## 11. Formattazione delle descrizioni `da fare`
|
||||
|
||||
**Deve:** le descrizioni dei task accettano andate a capo e grassetto.
|
||||
|
||||
**Perché conta:** chi crea le ricette fa **copia e incolla dal PDF della scheda
|
||||
tecnica**; oggi il testo arriva appiattito e va risistemato a mano ogni volta.
|
||||
|
||||
---
|
||||
|
||||
## 12. Funzionamento senza internet `da fare` · bloccante per l'installazione
|
||||
|
||||
**Oggi:** l'applicazione **non funziona senza collegamento a internet**. Cinque librerie
|
||||
vengono scaricate al volo da servizi esterni ogni volta che si apre una pagina.
|
||||
|
||||
**In una rete di produzione isolata — la norma in fabbrica — il risultato è una pagina
|
||||
bianca.** Non un degrado: l'interfaccia non parte proprio, e senza le altre non si vedono
|
||||
i disegni tecnici né i grafici statistici.
|
||||
|
||||
**Deve:** tutte le librerie sono incluse nell'installazione e l'applicazione funziona a
|
||||
rete staccata.
|
||||
|
||||
**Perché conta ora:** l'installazione a Tràfilo è on-premise e prevista per settembre.
|
||||
È poco lavoro, ma va fatto **prima**, non in fabbrica il giorno dell'installazione.
|
||||
|
||||
**Beneficio collaterale non ovvio:** oggi una delle librerie è agganciata a una versione
|
||||
"qualunque della serie 3" — cioè **l'applicazione cambia da sola** quando gli autori
|
||||
pubblicano un aggiornamento, senza che nessuno l'abbia validata. Per un sistema che
|
||||
produce evidenze per audit ISO 9001 / IATF 16949 questo è di per sé un problema.
|
||||
Includendo le librerie le versioni si congelano: da difetto diventa argomento di vendita.
|
||||
|
||||
---
|
||||
|
||||
## 13. Generazione dei task dalla scheda tecnica con l'AI `fuori offerta`
|
||||
|
||||
**Richiesta:** leggere il PDF della scheda tecnica e **creare un task per blocco**,
|
||||
invece del copia-incolla manuale.
|
||||
|
||||
**Storia:** posta il **19/05/2026** nel documento delle modifiche, rimasta senza
|
||||
risposta; **rilanciata da Tràfilo il 28/07** come elaborazione massiva iniziale delle
|
||||
schede, «senza installare agenti nel sistema».
|
||||
|
||||
**Stato:** non è in nessuna offerta. Prima di quotare servono tre informazioni: quante
|
||||
sono le schede, se il formato è standard, e se l'elaborazione è una-tantum in fase di
|
||||
avviamento o una funzione permanente del prodotto. Sono domande da fare, non da
|
||||
supporre — vedi Parte 3.
|
||||
|
||||
---
|
||||
|
||||
## 14. Stabilità del layout `da fare` · da circoscrivere
|
||||
|
||||
**Oggi:** le dimensioni delle viste **cambiano a seconda del menu**: passando da una
|
||||
schermata all'altra la finestra non mantiene proporzioni stabili.
|
||||
|
||||
**Deve:** il layout resta stabile nel passaggio fra le viste.
|
||||
|
||||
**Nota:** segnalazione dell'operatore del 28/07, non ancora circoscritta sul codice —
|
||||
prima di intervenire va riprodotta e va stilato l'elenco delle viste interessate.
|
||||
|
||||
---
|
||||
|
||||
## 15. Statistica: si registra sempre, si consulta a parte `già fatto` · da confermare sul campo
|
||||
|
||||
**Richiesta (28/07):** a fine misura l'operatore **non va portato nella pagina della
|
||||
statistica**. I dati **entrano comunque in statistica**: cambia solo chi la consulta —
|
||||
serve l'**utente con il ruolo adeguato**, che apre la pagina dedicata.
|
||||
|
||||
**Verificato sul codice:** è già così. Tutte le pagine di statistica richiedono il
|
||||
ruolo **Metrologo** (`role_required("Metrologist")` su ogni route), e a fine ciclo
|
||||
l'operatore viene portato al **riepilogo**, non alla statistica.
|
||||
|
||||
**Resta da fare:** niente sviluppo; il requisito entra come **criterio di collaudo**
|
||||
(l'operatore non deve poter raggiungere la statistica da nessun percorso) e va tenuto
|
||||
fermo quando il punto 10 ridisegna la navigazione a fine task.
|
||||
|
||||
---
|
||||
|
||||
# Parte 2 — Dove si interviene
|
||||
|
||||
Riferimenti al branch `V2.0.0`, commit `2a56632`.
|
||||
|
||||
## Ordine consigliato
|
||||
|
||||
```
|
||||
12 (offline) ──────────────► indipendente, si può fare subito
|
||||
bloccante per l'installazione
|
||||
|
||||
1 (stato produzione) ──┬───► 3 (loop misura)
|
||||
├───► 6 (fermo linea / fine produzione)
|
||||
└───► 4 (limite tentativi)
|
||||
|
||||
2 (tipo task) ─────────────► 3, 10
|
||||
|
||||
7 (stazioni) · 8 (tracciabilità) · 9 (inserimento manuale) · 11 (formattazione)
|
||||
indipendenti fra loro
|
||||
|
||||
5 (avanzamento in tolleranza) ──► prima verificare, forse è già a posto
|
||||
|
||||
14 (layout) ────────────────► prima riprodurre e circoscrivere le viste
|
||||
|
||||
15 (statistica riservata) ──► già a posto: solo criterio di collaudo,
|
||||
da non rompere lavorando sul punto 10
|
||||
```
|
||||
|
||||
La separazione **backend dati sul server / app di stazione in locale** (vedi
|
||||
*Architettura d'installazione*) non è un punto di questa lista: è il contesto in
|
||||
cui i punti 1, 3, 6 e 7 vanno progettati. In pratica: API senza stato, stato solo
|
||||
nel database, niente dipendenze dal container per l'identità della stazione.
|
||||
|
||||
## 1 · Stato della produzione lato server
|
||||
|
||||
**Problema tecnico:** `task_execute.html` tiene in variabili Alpine
|
||||
(`timerActive`, `timerRemaining`, `_timerInterval`, `cycleCount`, `cycleConfirmed`,
|
||||
`productionStarted`, `measurements`) uno stato che deve sopravvivere alla pagina.
|
||||
`goToNextTask()` fa `window.location.href` → il componente viene distrutto.
|
||||
Lato server la sessione conserva soltanto `lot_number` e `serial_number`.
|
||||
|
||||
**Intervento:**
|
||||
- nuove tabelle `production_runs` e `production_events` (avvio, ciclo completato, fermo
|
||||
linea, ripresa, chiusura), con `station_id`, `recipe_version_id`, `operator_id`,
|
||||
`supervisor_id` dove serve, timestamp;
|
||||
- endpoint REST per aprire, interrogare e aggiornare la produzione corrente della
|
||||
stazione;
|
||||
- il frontend legge lo stato all'apertura di ogni pagina invece di tenerlo in memoria;
|
||||
il conto alla rovescia si **ricalcola dall'orario di scadenza** salvato lato server,
|
||||
non da un contatore locale;
|
||||
- gli endpoint vanno progettati **senza stato in memoria di processo**: con l'app di
|
||||
stazione installata su ogni PC (vedi *Architettura d'installazione*) il database è
|
||||
l'unico posto condiviso.
|
||||
|
||||
**File:** `src/backend/models/orm/` (nuovo modulo), `src/backend/migrations/versions/`
|
||||
(migrazione 005), `src/backend/api/routers/`, `src/frontend/flask_app/blueprints/measure.py`,
|
||||
`src/frontend/flask_app/templates/measure/task_execute.html`.
|
||||
|
||||
**Fatto quando:** avviata una produzione, si naviga fra i task, si esce e si rientra, e
|
||||
il timer prosegue coerente; il riavvio del browser non azzera nulla.
|
||||
|
||||
---
|
||||
|
||||
## 2 · Tipo di task
|
||||
|
||||
**Problema tecnico:** `RecipeTask` non ha campo tipo; il frontend decide con
|
||||
`subtasks.length > 0` (`task_execute.html`, `task_list.html`).
|
||||
|
||||
**Intervento:** campo `type` su `recipe_tasks` con valori `note | measure | drawing`
|
||||
(predisposto per `xf_compare`, `camera_measure`), migrazione con valorizzazione dei dati
|
||||
esistenti secondo la regola attuale, selezione del tipo nell'editor ricetta,
|
||||
sostituzione dei controlli su `subtasks.length` con il tipo.
|
||||
|
||||
**File:** `src/backend/models/orm/task.py`, nuova migrazione,
|
||||
`src/backend/models/api/`, `src/frontend/flask_app/templates/maker/task_editor.html`,
|
||||
`templates/measure/task_execute.html`, `templates/measure/task_list.html`.
|
||||
|
||||
**Fatto quando:** una ricetta con un task di misura ancora privo di quote si comporta da
|
||||
task di misura.
|
||||
|
||||
---
|
||||
|
||||
## 3 · Loop di misura
|
||||
|
||||
**Base già presente:** `confirmCycle()`, `startMeasurementTimer()`, `onTimerExpired()`,
|
||||
`timerDisplay`, `playBuzzer()` in `task_execute.html` (righe ~955-1050). La logica è
|
||||
corretta; il problema è la persistenza (punto 1) e il fatto che allo scadere non si può
|
||||
riportare l'operatore sul task giusto.
|
||||
|
||||
**Intervento:** spostare la scadenza sul server; alla scadenza, **redirezione al task di
|
||||
misura** della produzione corrente; con più task di misura far ripartire il timer al
|
||||
completamento dell'**ultimo**; aggiungere «rimisura» che riapre il ciclo senza chiuderlo.
|
||||
|
||||
**Timer bidirezionale:** oggi il contatore **solo decrementa e si ferma a zero**
|
||||
(`timerRemaining--`, poi `onTimerExpired()`); `timerDisplay` formatta minuti:secondi
|
||||
dal residuo. Va esteso: sotto zero il valore continua **in negativo** e la
|
||||
visualizzazione passa a "oltre da m:s", con stile in evidenza. Calcolando dal
|
||||
timestamp di scadenza lato server (come sopra), il ritardo è coerente su qualunque
|
||||
schermata e sopravvive al ricaricamento.
|
||||
|
||||
**Fatto quando:** con una ricetta a due task di misura e task documentali in coda, allo
|
||||
scadere del timer l'operatore viene riportato alla misura da qualunque schermata.
|
||||
|
||||
---
|
||||
|
||||
## 4 · Limite di tentativi
|
||||
|
||||
**Problema tecnico:** nessun `max_retries` nel codice.
|
||||
|
||||
**Intervento:** campo sulla ricetta (accanto a `measurement_interval_minutes`, che segue
|
||||
lo stesso schema), contatore per quota nella produzione corrente, superata la soglia
|
||||
riuso del modale capoturno esistente con motivo `max_retries`.
|
||||
|
||||
**File:** `src/backend/models/orm/recipe.py`, migrazione,
|
||||
`templates/maker/recipe_editor.html` (accanto al timer), `task_execute.html`.
|
||||
|
||||
---
|
||||
|
||||
## 5 · Avanzamento in tolleranza — prima verificare
|
||||
|
||||
Il modale capoturno gestisce già `out_of_tolerance` (`task_execute.html`,
|
||||
`openSupervisorModal`, `validateSupervisor`, endpoint
|
||||
`measure.validate_supervisor`). **Prima di sviluppare, provare**: se il rifiuto blocca
|
||||
l'avanzamento, il punto è chiuso. Se è solo una conferma, va reso vincolante.
|
||||
|
||||
---
|
||||
|
||||
## 6 · Fermo linea e Fine produzione
|
||||
|
||||
**Problema tecnico:** in `task_execute.html` i due pulsanti aprono il modale e poi
|
||||
ricadono su un commento: `fermo_linea and fine_produzione are handled by GAIA
|
||||
integration (future)`. `startProduction()` è un `TODO` con la chiamata commentata.
|
||||
|
||||
**Intervento (senza gestionale):** scrivere gli eventi su `production_events`,
|
||||
sospendere e riprendere il timer, chiudere la produzione, ed **emettere il file di
|
||||
statistica** con tutte le misure della produzione. L'invio al gestionale resta un
|
||||
adattatore separato da riempire quando il protocollo sarà definito (Parte 3): va
|
||||
previsto il punto d'innesto, non l'implementazione.
|
||||
|
||||
**Fatto quando:** *fermo linea* congela il timer e solo il capoturno lo riattiva; *fine
|
||||
produzione* chiude e produce il file.
|
||||
|
||||
---
|
||||
|
||||
## 7 · Stazioni
|
||||
|
||||
**Base presente:** `Station` e `StationRecipeAssignment` (`models/orm/station.py`,
|
||||
migrazione 002).
|
||||
|
||||
**Intervento:** ricette collegate nella lista stazioni; pulsante di reset **per riga**
|
||||
che rimuove le assegnazioni; selezione della stazione corrente da parametro URL con
|
||||
ricaduta sulla variabile d'ambiente, per il collaudo da una sola macchina.
|
||||
|
||||
**Nota (28/07, chiude il dubbio che era in D-3):** in produzione l'identità della
|
||||
stazione è data dall'**installazione locale** dell'app di stazione, non dal container.
|
||||
Il cambio al volo via URL resta come strumento di **collaudo**.
|
||||
|
||||
---
|
||||
|
||||
## 8 · Tracciabilità
|
||||
|
||||
**Base presente:** `lot_number` e `serial_number` su `Measurement`, salvataggio in
|
||||
sessione (`measure.save_traceability`), inserimento in `task_list.html`.
|
||||
|
||||
**Intervento:** flag sulla ricetta (`richiede lotto`, `richiede seriale`); spostare
|
||||
l'inserimento sull'avvio produzione; *Avvia* disabilitato finché mancano.
|
||||
|
||||
---
|
||||
|
||||
## 9 · Inserimento manuale
|
||||
|
||||
**Base presente:** `Measurement.input_method` (`manual | usb_caliper`), valorizzato dal
|
||||
frontend.
|
||||
|
||||
**Intervento:** flag sulla ricetta `consente inserimento manuale`, **predefinito falso**;
|
||||
validazione **lato server** — un flag solo nel frontend non protegge da nulla; tastierino
|
||||
nascosto quando vietato.
|
||||
|
||||
---
|
||||
|
||||
## 10 · Interfaccia operatore
|
||||
|
||||
Interventi su `templates/measure/task_list.html` e `task_execute.html`: pulsante di
|
||||
avvio in sequenza, retrocessione della lista a secondo livello, rinomina dei due
|
||||
pulsanti, stato «incompiuto» sui task abbandonati, «fine ciclo misura» abilitato solo a
|
||||
quote complete.
|
||||
|
||||
---
|
||||
|
||||
## 11 · Formattazione descrizioni
|
||||
|
||||
`RecipeTask.description` è già `Text`. Serve un editor minimale (grassetto e a capo) e
|
||||
la resa corrispondente in esecuzione, con **sanificazione dell'HTML** in ingresso.
|
||||
|
||||
**File:** `templates/maker/task_editor.html`, `templates/measure/task_execute.html`.
|
||||
|
||||
---
|
||||
|
||||
## 12 · Funzionamento senza internet
|
||||
|
||||
**Verificato sul codice.** Cinque librerie esterne in sei template:
|
||||
|
||||
| Libreria | Dove | Senza rete si perde |
|
||||
|---|---|---|
|
||||
| Alpine.js `3.x.x` | `base.html` | **tutta l'interfaccia** |
|
||||
| Plotly `2.32.0` | `statistics/dashboard.html` | carte di controllo e istogrammi |
|
||||
| PDF.js `3.11.174` | `task_execute`, `recipe_preview`, `task_drawing`, `task_editor` | visualizzazione dei disegni |
|
||||
| Fabric.js `5.3.1` | `maker/task_drawing.html` | editor delle annotazioni |
|
||||
| Google Fonts | `base.html` | estetica e attese al caricamento |
|
||||
|
||||
**Intervento:** scaricare le librerie in `src/frontend/flask_app/static/vendor/` (la
|
||||
cartella **esiste già ed è vuota**), ripuntare i tag, chiudere la policy di sicurezza in
|
||||
`security_headers.py` da elenco-di-CDN a solo-origine-locale.
|
||||
|
||||
⚠️ **Trappola da non mancare:** PDF.js ha una **seconda** referenza al CDN,
|
||||
`pdfjsLib.GlobalWorkerOptions.workerSrc`, presente in **quattro file**. Ripuntando solo
|
||||
lo script principale la libreria si carica in locale **e il worker continua a cercare
|
||||
internet**: sembra funzionare finché non si apre un disegno.
|
||||
|
||||
**Fatto quando:** con la rete staccata si percorre login → scelta ricetta → esecuzione
|
||||
task → annotazione disegno → statistiche → report, senza errori in console.
|
||||
|
||||
---
|
||||
|
||||
# Parte 3 — Decisioni che non dipendono da noi
|
||||
|
||||
Da chiudere **prima** che i punti collegati entrino in sviluppo. Vanno girate a Tràfilo
|
||||
tramite Menoncin.
|
||||
|
||||
| # | Domanda | Blocca | Chi risponde |
|
||||
|---|---|---|---|
|
||||
| **D-1** | **Protocollo del gestionale GAIA**: come si scambiano i dati — servizi web, database condiviso, file? | avvio produzione, fermo linea, fine produzione verso il gestionale; lettura dei codici articolo per stazione | IT Tràfilo + fornitore GAIA |
|
||||
| **D-2** | **Rete e credenziali** per raggiungere GAIA dal server dove sarà installato | come sopra | IT Tràfilo |
|
||||
| ~~**D-3**~~ | ~~Una applicazione per stazione o una sola per tutte?~~ **Decisa il 28/07** lato Tielogic: backend dati sul server, app di stazione installata su ogni PC — vedi *Architettura d'installazione*. Resta la validazione con l'IT di Tràfilo (macchina e rete) | — | chiusa (noi); validazione in D-4 |
|
||||
| **D-4** | **Server**: quale macchina, quanto spazio disco. Sul server stanno database **e file dei disegni** (`uploads/`); l'elaborazione visione **non** è sul server (sta sull'app di stazione), quindi pesa lo spazio disco, non la potenza di calcolo | installazione | IT Tràfilo |
|
||||
| **D-5** | **Cicalino**: basta il suono del browser o serve una segnalazione luminosa? La specifica chiede luce **e** suono accesi per tutta la misura, visibili da lontano. Con l'architettura del 28/07 l'app di stazione **può pilotare una colonnina**: la domanda diventa *quale hardware* | punto 3 | Tràfilo |
|
||||
| **D-6** | **Autorizzazione capoturno**: username e password come oggi, o PIN rapido / badge? Venti volte al giorno la password è un attrito | punti 4, 5, 6 | Tràfilo |
|
||||
| **D-7** | **Numero di tentativi** consentiti prima del capoturno: quanti, e uguali per tutte le ricette? | punto 4 | Tràfilo |
|
||||
| **D-8** | **Schede tecniche**: quante sono, il formato è standard, e serve una conversione una-tantum o una funzione permanente? | punto 13 e la sua quotazione | Tràfilo |
|
||||
| **D-9** | Modificare i parametri di una ricetta (timer, tentativi) **crea una nuova versione** o no? Sono parametri di esercizio, non di prodotto | punti 4, 3 | noi, con conferma cliente |
|
||||
|
||||
**Nota su D-1 e D-2:** finché non hanno risposta, del gestionale si può solo predisporre
|
||||
il punto d'innesto. Tutto il resto del punto 6 — sospendere, riprendere, chiudere,
|
||||
registrare, produrre il file — **si fa comunque e va fatto adesso**.
|
||||
|
||||
---
|
||||
|
||||
## Appendice — Come è stato verificato
|
||||
|
||||
Ogni «già fatto» e ogni «da fare» viene dalla lettura del codice al commit `2a56632`,
|
||||
non dai documenti. In particolare:
|
||||
|
||||
- il **tipo di task** è dedotto da `subtasks.length > 0` in `task_execute.html:117` e
|
||||
`task_list.html:169`;
|
||||
- il **ruolo capoturno** esiste come `Supervisor`
|
||||
(`api/middleware/api_key.py:71`, `blueprints/measure.py:350`);
|
||||
- **fermo linea / fine produzione / avvio produzione** hanno interfaccia e gate ma
|
||||
nessun effetto (`task_execute.html:1017-1021`, `1118`);
|
||||
- il **timer** è un `setInterval` locale alla pagina (`task_execute.html:968-995`) e la
|
||||
navigazione fra task è un ricaricamento (`task_execute.html:1054`);
|
||||
- **`max_retries`** e **`production_events`** non compaiono in nessun file;
|
||||
- le **cinque librerie da CDN** sono ai riferimenti citati al punto 12, e
|
||||
`static/vendor/` contiene solo `.gitkeep`;
|
||||
- i **disegni stanno su filesystem**, non nel database: cartella `uploads/` servita
|
||||
dal backend (`api/routers/files.py:201`, `FileResponse`) — verifica del 28/07 sera,
|
||||
corregge quanto detto in call;
|
||||
- la **statistica è già riservata**: ogni route di `blueprints/statistics.py` porta
|
||||
`@role_required("Metrologist")`; a fine ciclo il frontend va al riepilogo
|
||||
(`task_execute.html:1126`), non alla statistica;
|
||||
- il **timer si ferma a zero**: decremento in `task_execute.html:974-975` con uscita
|
||||
su `onTimerExpired()` — il conteggio del ritardo (punto 3) oggi non esiste;
|
||||
- lo stack attuale è a 4 container (`docker-compose.yml`): MySQL 8, backend FastAPI,
|
||||
frontend Flask, nginx — base della sezione *Architettura d'installazione*.
|
||||
|
||||
Il punto 14 (layout) è l'unico **non verificato sul codice**: è una segnalazione
|
||||
dell'operatore del 28/07, da riprodurre.
|
||||
Reference in New Issue
Block a user