[Bug] Correggere la modalità di annotazione sequenziale Peak/Valley dopo delete e limitare la delete ai soli ultimi step

[andreazedda]

Origine feedback

• Data: 2026-03-07 17:14
• Utente: nicola.spettu
• Tipo: Altro
• Urgenza: Media
• Pagina: /datasets/64/
• Dataset: 64

Sintesi del problema

La piattaforma offre una modalità di annotazione sequenziale in cui l’utente inserisce marker puntuali alternati secondo il pattern:

Peak -> Valley -> Peak -> Valley -> ...

Questa modalità è pensata per velocizzare l’inserimento guidato sul segnale.

Problema attuale:

• Se l’utente cancella una Valley appena inserita, il sistema continua comunque la sequenza e propone Peak, invece di riallinearsi sul marker appena rimosso e consentire la correzione locale.
• Non ha senso consentire la cancellazione (delete) di annotazioni molto precedenti nella sequenza in modalità sequenziale, perché questo rompe il vincolo di alternanza storica su cui si basa il workflow guidato.

Problema prodotto

• La modalità sequenziale Peak/Valley oggi si comporta come un semplice toggle automatico, ma invece è un workflow stateful.
• Il sistema dovrebbe:
  • mantenere coerenza con la sequenza realmente costruita;
  • consentire correzione solo sull’ultimo step appena inserito;
  • impedire modifiche retroattive profonde mentre la modalità sequenziale è attiva.
• Oggi, la sequenza continua anche dopo delete dell’ultimo marker, perdendo allineamento.
• Il sistema permette la delete di marker storici, invalidando il workflow.

Comportamento atteso

Regola 1 — la sequenza va ricalibrata solo sull’ultimo inserimento

• Se si cancella l’ultima annotazione, il sistema deve proporre nuovamente quel tipo.
  • Esempi: Peak -> Valley, delete Valley -> prossimo atteso: Valley
    Peak -> Valley -> Peak, delete Peak -> prossimo atteso: Peak

Regola 2 — delete retroattiva non consentita

• Non si può cancellare marker interni in modalità sequenziale: consentito solo l'ultimo step.
• Per editare il passato, si deve disattivare la modalità sequenziale e passare a modalità manuale.

Rationale

• La modalità sequenziale è uno stack: posso aggiungere, posso correggere solo l’ultimo elemento.
• La delete "profonda" genererebbe incoerenza storica.

Evidenze nel codice

• Alternanza dopo add: datasets/templates/datasets/detail.html#L1884-L1934
• Delete aggiorna annotazioni: datasets/templates/datasets/detail.html#L1799-L1847
• Stato della modalità in UI/DOM: datasets/templates/datasets/detail.html#L1952-L1966
• setupPeakValleySequentialUi() - toggle feature, non impone vincoli robusti su delete: datasets/templates/datasets/detail.html#L2411-L2420
• API delete aggiorna frontend: annotations/api.py#L641-L687

Root cause probabile

• Alternanza automatica in UI, non workflow con cronologia.
• Delete non distingue se si sta cancellando l’ultimo marker.
• Nessuna protezione verso delete di marker storici in modalità sequenziale.

Soluzione preferita

• Trattare la modalità sequenziale come flusso append-only con undo dell’ultimo step.

Comportamento richiesto

A. Inserimento: prosegue
B. Delete dell’ultimo marker: rollback e riallineamento
C. Delete marker non ultimo: blocco o richiesta uscita modalità sequenziale

Alternative considerate

• Opzione A: comportamento attuale, non va bene
• Opzione B: ricalcolo sempre su storia, troppo complessa e rischiosa
• Opzione C: modello append-only/undo (preferito: semplice, chiaro, coerente)

Decisione consigliata

• Adottare Opzione C (append/undo terminale)

Acceptance criteria

• Modalità sequenziale ON: dopo Peak -> Valley -> delete Valley, prossimo atteso: Valley
• Modalità sequenziale ON: dopo Peak -> Valley -> Peak -> delete Peak, prossimo atteso: Peak
• Modalità sequenziale ON: delete di marker non ultimo vietata, feedback UI chiaro
• Modalità sequenziale OFF: comportamento libero
• UI riflette sempre la sequenza

Piano tecnico suggerito

• Individuare dove è mantenuto il prossimo tipo di marker
• Aggiungere controllo su delete (ultimo vs. interno)
• Se delete ultimo, rollback
• Se delete interno, blocco o richiesta modalità manuale
• Aggiornare radio/stato UI/pannello/badge/testo coerente
• Test manuale e JS

Rischi

• "Ultimo marker" va definito chiaramente (asse/dataset/sequenza corrente)
• Feedback su azioni bloccate

Nota architetturale

• Solo modalità Peak/Valley sequenziale, non intervenire su altre parti
• Consentire solo avanzamento o correzione terminale.
  labels: ["bug"]