From 5e6e6f66177e935fb1ed1172b6ca39bf0609e209 Mon Sep 17 00:00:00 2001 From: DevEnv nis2-agile Date: Thu, 18 Jun 2026 18:08:23 +0200 Subject: [PATCH] =?UTF-8?q?[SUPERVISOR]=20Capacit=C3=A0=20di=20gestione=20?= =?UTF-8?q?del=20budget=20di=20tempo=20del=20ciclo=20(25=20min)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- scripts/nis2-supervisor-acting-prompt.md | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/nis2-supervisor-acting-prompt.md b/scripts/nis2-supervisor-acting-prompt.md index 07d8192..fa58780 100644 --- a/scripts/nis2-supervisor-acting-prompt.md +++ b/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.