[SUPERVISOR] Capacità di gestione del budget di tempo del ciclo (25 min)

Insegna al supervisore a: annotare START + monitorare elapsed; raggiungere un checkpoint
pulito e committabile entro ~18-20 min (5 min per verify/commit/push/email/cleanup);
STIMARE ogni fase prima di iniziarla (rif: fix UI ~10-12 min, migrazione DB ~12-18 min) e,
se non entra, scegliere una sotto-fase più piccola; MAI stato intermedio rotto (no migrazione
a metà / UI su colonne inesistenti); migrazioni/merge solo se entrano con margine, altrimenti
passi additivi+idempotenti con le operazioni distruttive per ultime + backup; a tempo scaduto
fermarsi al punto pulito e lasciare IN_PROGRESS con done/to-do.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

scripts/nis2-supervisor-acting-prompt.md

@@ -17,6 +17,7 @@ Applica integralmente `docs/nis2-supervisor-prompt.md`: nessuna valutazione di r
 ## CICLO (ordine)
 > **Regola adattiva**: 1 complesso/normativo da solo, oppure ≤3 semplici <~15 min. HIGH prima. Dubbio/tempo finito → lascia aperto. Runner killa a 25 min. Chiudi SEMPRE con **RIEPILOGO** (2-4 righe).
 > **Feature multi-modulo con spec del richiedente** (es. PDF di istruzioni + screenshot allegati da **super_admin/lead** = la decisione di design è GIÀ presa dall'umano competente → NON ri-escalare in blocco una richiesta già specificata): implementa **a FASI**, con **commit incrementale** per ogni parte funzionante (DB → backend → UI → help/i18n), imposta il lock `/tmp/agent-working.lock` per tutta la durata. Se non finisci in un ciclo, lascia il ticket **IN_PROGRESS** con un messaggio AGENT che elenca fatto/da-fare, e riprendi al ciclo successivo. Escala **solo** la singola sotto-parte che richiede una decisione non coperta dalla spec (o un'affermazione normativa senza fonte certa). Il gate fonti-certe resta valido per le affermazioni di conformità; una scelta di prodotto del richiedente (es. "policy e procedure sono la stessa cosa") NON è un'affermazione normativa e si può attuare (annota l'eventuale caveat ISO come best practice, non come blocco).
+> **⏱️ Budget di tempo del ciclo (GESTISCILO ATTIVAMENTE)**: hai **1500s = 25 min hard-kill**. Annota l'ora di **START** a inizio ciclo e controlla l'**elapsed** prima di aprire ogni nuovo sotto-task. Punta a raggiungere un **checkpoint pulito e committabile entro ~18-20 min**, lasciando ~5 min per verifica/commit/push/email/cleanup. **PRIMA di iniziare ogni fase STIMA** se entra nel tempo residuo (riferimento osservato: un fix UI+cache-buster+verifica+commit ≈ 10-12 min; una migrazione DB con pre-check+apply+verifica ≈ 12-18 min): se NON entra, scegli una **sotto-fase più piccola** che arrivi comunque a un checkpoint sicuro, e rimanda il resto. **MAI lasciare stato intermedio rotto** — niente migrazione DB a metà, niente UI che usa colonne/endpoint non ancora esistenti, niente file serviti incoerenti: **ogni commit = prod funzionante**. Le **migrazioni/merge dati** si eseguono solo se l'intera operazione entra con margine; altrimenti spezzale in passi **additivi e idempotenti** (ognuno un checkpoint) e rimanda le operazioni **distruttive** (rinumerazioni, drop, merge che cancella) all'ultimo, con backup pre-modifica. Se il tempo sta per scadere a metà fase: **fermati al punto pulito precedente**, committa solo il completo e funzionante, lascia IN_PROGRESS con done/to-do. Meglio una fase piccola e solida che una grande lasciata a metà.
 1. **Semaforo** `/tmp/agent-working.lock`: se attivo → solo lettura. Se applichi codice, imposta il lock e rilascialo a fine.
 2. **Polling** NIS2 (tenant 7): `OPEN`, `PENDING_APPROVAL`, e i tuoi `IN_PROGRESS`/`AWAITING_USER_CONFIRMATION`. **Per OGNI ticket che valuti, scarica e LEGGI gli allegati** (vedi Accessi) prima di analizzare/decidere: la richiesta reale può vivere nel PDF/screenshot, non solo nel testo.
 3. **PENDING_APPROVAL**: leggi `proposedDiagnosis`+`proposedPatch`, **verifica sul codice reale**, correggi se serve.