[AI] - CODEX - Come generare i comandi per creare l'enviroment per la sessione watchdog

Di seguito come generare i comandi affinche' l'AI generi tutti i files necessari che devono essere letti dalla sessione di watchdog per allinearsi. La mia AI si chiama Nico... lo ha scelto lei o lui...

Comando Freeze
Comando da dare alla sessione principale:

• Nico, freeze watchdog

Significato: preparo una fotografia operativa della sessione corrente, così una seconda sessione può controllarmi senza dover ricostruire tutto dalla chat.

Questo comando autorizza solo la creazione/aggiornamento dei file di memoria watchdog, non test, deploy o modifiche DB.

Operazioni Del Freeze
Quando ricevo Nico, freeze watchdog devo:

1. Fermarmi appena possibile in un punto coerente.
2. Scrivere cosa sto facendo adesso.
3. Scrivere cosa è già stato completato.
4. Scrivere cosa è in esecuzione o sta per partire.
5. Indicare comandi, log, job, processi e query di controllo.
6. Indicare durata attesa e criteri di hang.
7. Indicare cosa il watchdog può fare: solo lettura.
8. Indicare cosa non può fare senza autorizzazione.
9. Salvare/aggiornare i file watchdog.

10. Risponderti che il freeze è pronto.

File Da Creare/Aggiornare

File principale:

C:\ORACLE_WORK\<Nome_Progetto>\WATCHDOG_SESSIONE_CORRENTE.md

Contenuto:

• data/ora freeze;
• obiettivo attività;
• stato tecnico;
• comando in corso o prossimo comando previsto;
• durata attesa;
• log da controllare;
• query DB read-only utili;
• processi/job attesi;
• segnali di avanzamento;
• segnali di hang;
• cosa deve fare il watchdog se rileva blocco.

File storico opzionale:

C:\ORACLE_WORK\MEMORIA_LAVORO_<timestamp>.md

Contenuto:

• riepilogo più ampio della sessione;
• modifiche fatte;
• file toccati;
• backup creati;
• test eseguiti;
• punti chiusi;
• punti aperti.

File specifico test, se siamo su test schedulatore:

C:\ORACLE_WORK\WATCHDOG_TEST_SCHEDULATORE_A00.md

Contenuto:

• piano test corrente;
• prenotazioni coinvolte;
• directory test;
• script lanciati;
• log OS/DB da verificare;
• expected result;
• criteri di blocco.

Comando Seconda Sessione
Nella sessione watchdog per richiamare la lettura dei file di memoria occorre utilizzare il comandoi:

Nico watchdog test

Oppure, più generale:

Nico watchdog

Significato: leggi solo i file freeze/watchdog/memoria, lavora in sola lettura e controlla se la sessione principale sta avanzando o è bloccata.

Comando	Dove si usa	Scopo
Nico, freeze watchdog	sessione principale	congela la memoria operativa da far leggere al watchdog
Nico watchdog	seconda sessione	legge il freeze e controlla in sola lettura
Nico watchdog test	seconda sessione	variante specializzata per test schedulatore

Quindi prima della prossima attività lunga: basta dare il comando  Nico, freeze watchdog, e l'AI prepara i fileS, poi si puo' aprire la seconda sessione e darle il comando Nico watchdog.

[AI] - CODEX - Regole per la definizione di una sessione WatchDog

 Un watchdog ben progettato non è aggressivo: è disciplinato. La sua funzione non è risolvere il problema al posto dell’operatore, ma impedire che un processo critico resti appeso senza controllo. Per questo deve lavorare con privilegi minimi, regole verificabili, soglie chiare e report tracciabili.

In sintesi: un buon watchdog deve essere separato, leggibile, prudente, misurabile e tracciabile.

Linee Guida

Per implementare un watchdog corretto bisogna prima chiarire che non è un secondo processo operativo, ma un supervisore. Il suo valore nasce proprio dal perimetro ristretto: osserva, misura, segnala e interviene solo quando le regole lo consentono.

Un buon watchdog dovrebbe seguire queste linee guida:

1. Separare controllo e lavoro

   La sessione watchdog deve essere distinta dalla sessione principale. La sessione principale esegue test, deploy o elaborazioni; il watchdog osserva soltanto.

2. Definire regole scritte prima dell’esecuzione

   Il comportamento del watchdog deve essere documentato in un file operativo: cosa controllare, ogni quanto controllare, quali soglie usare, cosa può fermare e cosa non può toccare.

3. Lavorare in sola lettura per default

   Tutti i controlli devono essere non invasivi: lettura log, controllo processi, query SELECT, stato job, timestamp file. Le azioni modificanti devono essere eccezioni esplicite.

4. Limitare il perimetro di intervento

   Il watchdog non deve poter fermare “tutto il sistema”. Deve poter intervenire solo sui processi appartenenti al kit o al job sorvegliato, identificati da path, nomi comando o range di test.

5. Usare segnali oggettivi di avanzamento

   Non basta vedere un processo vivo. Bisogna confrontare più segnali:

   • timestamp e dimensione dei log;
   • processi attivi e loro durata;
   • job applicativi running;
   • stati DB intermedi;
   • output della sessione principale.

6. Definire soglie di hang misurabili

   Esempio: “processo vivo oltre 5 minuti senza aggiornamento log” è una regola verificabile. “Mi sembra bloccato” non lo è.

7. Intervenire in modo progressivo

   Se il watchdog deve fermare processi, dovrebbe prima usare uno stop morbido, per esempio TERM, poi attendere, verificare di nuovo e solo dopo usare uno stop forzato sui PID ancora presenti.

8. Non fare cleanup automatico

   Dopo un blocco, il watchdog non dovrebbe cancellare file, svuotare tabelle, droppare job o ripristinare ambienti. Queste attività appartengono alla sessione principale o richiedono autorizzazione esplicita.

9. Registrare sempre le evidenze

   Ogni decisione deve poter essere spiegata: PID osservati, comando, durata, log fermo, stato DB, job running, azione eseguita o motivo per cui non è stata eseguita.

10. Preferire falsi allarmi a interventi pericolosi

Un watchdog corretto è conservativo. Se non è sicuro che un processo appartenga al perimetro autorizzato, segnala il dubbio e non lo termina.

11. Lasciare il controllo finale all’utente

Per azioni fuori perimetro, come kill di processi host, spegnimento VM, cleanup DB o drop job Oracle, il watchdog deve chiedere conferma esplicita.

12. Produrre un report finale

Alla fine deve indicare cosa ha visto, cosa ha fermato, cosa non ha fermato, stato finale dei job, stato finale dei dati osservati e presenza di eventuali anomalie funzionali.

[AI] - CODEX - Che cos'e' una sessione watchdog

Il watchdog e' una sessione, nel mio caso sto utilizzando Codex, parallela che osserva una lavorazione critica senza partecipare allo sviluppo. 

Il suo compito non e' correggere, ma garantire che un test lungo o rischioso non resti appeso senza controllo. Lavora con regole scritte, soglie misurabili e privilegi minimi.

La possiamo descrivere come una sessione di sorveglianza parallela, separata dalla sessione che lavora davvero sui test.

Nel nostro caso la sessione “Verifica presenza”, su codex utilizzando chatgpt, eseguiva i test operativi di uno  schedulatore, ORA_SCHED. 

La sessione “watchdog”, invece, non sviluppava, non correggeva codice e non lanciava test autonomamente: osservava soltanto se la sessione principale stava avanzando oppure se si era bloccata.

Funzionamento
Il watchdog lavora come un supervisore esterno:

1. Legge un file di regole operativo, nel nostro caso WATCHDOG_TEST_SCHEDULATORE_.md
2. Controlla periodicamente processi OS, log applicativi, job Oracle e stato delle prenotazioni di test.
3. Decide se c’e' avanzamento reale oppure un possibile blocco.
4. Interviene solo se le condizioni di hang sono soddisfatte.
5. Produce un report finale con processi osservati, job running, stati DB e azioni fatte.

La cosa importante e' che il watchdog non giudica il risultato funzionale dei test. Se una prenotazione finisce in errore applicativo, non e' automaticamente un problema per il watchdog. Diventa un problema solo se il sistema resta fermo: processo vivo troppo a lungo, log non aggiornati, job Oracle running oltre soglia, stati intermedi invariati.

• Regole di sicurezza

La forza della funzionalita' sta nei limiti espliciti:

• lavora quasi sempre in sola lettura;
• usa solo SELECT sul database;
• non modifica codice;
• non fa cleanup DB;
• non cancella log;
• non spegne la VM;
• non droppa job Oracle senza autorizzazione;
• puo' terminare solo processi OS appartenenti al kit di test, e solo se rileva un hang secondo regole gia' definite.

Quindi non e' “un secondo agente che improvvisa”. E' piu' simile a un supervisore con mandato ristretto: osserva, misura, segnala, e interviene solo dentro un perimetro autorizzato.

• Criterio di hang

Nel nostro file watchdog abbiamo definito alcune condizioni chiare:

• processo del kit vivo oltre 5 minuti senza variazione dei log;
• sqlplus del kit appeso oltre 5 minuti;
• job Oracle di test running oltre 5 minuti;
• prenotazioni 990100-990299 ferme in stato intermedio oltre 5 minuti;
• timeout dichiarato dalla sessione principale;
• comando utente esplicito, per esempio blocca tutto.

Questo rende l’intervento ripetibile e verificabile: il watchdog non ferma qualcosa “a sensazione”, ma perche' una soglia operativa e' stata superata.

• Esempio pratico

Durante il test A00 il watchdog ha visto varie fasi:

• polling iniziale;
• esecuzione expdp;
• test di concorrenza 990120 / NTCONC;
• test di parallelismo 990201-990205 / NTPAR1..5.

In ogni fase ha controllato processi, job e log. Quando vedeva timestamp aggiornati, processi giovani o stati DB che cambiavano, non interveniva. 

Alla fine ha confermato che non c’erano processi residui, nessun job Oracle running e nessuna prenotazione intermedia.