loop-lavoro — cosa fa un giro

Queste istruzioni sono per un agente che non sa nulla del cantiere: le esegue alla
lettera, un giro alla volta, senza inventare passi in più.

0. Prima di tutto

Sei una sessione nuova e isolata. Non usare la sessione persistente di Romeo.
Non caricare in contesto file di dati interi (attivita.csv, task_details.json,
richieste.json): leggi solo quello che ti serve, tramite gli script indicati sotto.

1. Selezione

Lancia, dalla cartella del repo (C:\Users\Ettore\Claude\Agente Residente openclaw):

node scripts\loop_lavoro.mjs --select

• Se non stampa nulla (coda vuota o nessun task eleggibile): il giro finisce qui, in silenzio. Non scrivere nel canale, non aprire richieste, non toccare nulla.
• Se stampa una riga JSON: quella è la scheda minima del task scelto (id, titolo, stato, prossima_azione, criterio_fatto, assegnato_a, e i file/percorsi che la scheda in task_details.json nomina — quando la scheda esiste).

La selezione segue esattamente questi 4 criteri, in quest'ordine, senza aggiunte
(la logica è in scripts\coda.mjs, riusata da loop_lavoro.mjs, non duplicata):

1. il task è pronto secondo coda.mjs (non Fatto, non archiviato, non Bloccato su Ettore, prossima_azione non vuota);
2. criterio_fatto non è vuoto e non è non noto;
3. assegnato_a è diverso da ettore;
4. si prende il primo nell'ordine della coda (ordine del CSV).

I confronti su assegnato_a e criterio_fatto sono normalizzati (minuscole, spazi
tolti): Ettore e ettore valgono lo stesso. Prima della revisione del 19/08 erano
case-sensitive, e un task assegnato a Ettore con la maiuscola passava il criterio 3.

Non applicabile in questo blocco: "dipendenze soddisfatte". Il piano originale
citava un controllo dipendenze; nel dato reale non esiste una colonna dipendenze.
Non è stata aggiunta. Il controllo è no-op, dichiarato qui.

Quanto pesca davvero questo imbuto, oggi (19/08): 82 task → 48 pronti → **13
eleggibili**. A restringere non è lo stato: è criterio_fatto, che su 67 righe vale
ancora non noto. E i 13 eleggibili sono **tutti in stato In corso: nessuno è `Da
iniziare`**. Due conseguenze da sapere prima di accendere il cron: (1) finché il Blocco 2
non estende i criteri di fatto, il ciclo lavora sempre dentro la stessa dozzina di task;
(2) se qualcuno reintroducesse il filtro stato = Da iniziare del prompt originale — che
il piano del cantiere ha sostituito con il criterio della coda — il ciclo non
sceglierebbe nulla e uscirebbe in silenzio per sempre, sembrando funzionante.

2. Lavoro

• Leggi solo i file che la scheda nomina (workspace + file correlati). Non aprire attivita.csv o task_details.json per intero: usa node scripts\coda.mjs . <id> se ti serve rivedere la riga CSV di un singolo task.
• Lavora un blocco solo — non incatenare più task nello stesso giro.
• Al termine, esegui davvero il controllo scritto in criterio_fatto (non un giudizio a occhio: se il criterio dice di eseguire uno script o contare qualcosa, va eseguito per davvero, e il risultato osservato va scritto in evidenza).

3. Scrittura del record

Non modificare `attivita.csv` a mano. Il file ha virgole e a capo dentro i campi
quotati: è così che si è corrotta la riga a41. Usa lo script, che fa il backup da solo,
tocca una riga sola e annulla tutto se i conteggi non tornano:

node scripts\record_task.mjs <id> --stato "<stato>" --esito <esito> --evidenza "<prova>" --chiuso-il AAAA-MM-GG

Campi disponibili: --stato, --esito, --evidenza, --iniziato-il, --chiuso-il,
--prossima-azione. Con --dry mostra il prima/dopo senza scrivere.

Cosa scrivere:

• iniziato_il (se non era già valorizzato) e chiuso_il (se il blocco chiude il task);
• esito (riuscito / fallito / valore coerente con CICLO_TASK.md);
• evidenza (percorso o comando che dimostra il criterio verificato);
• `stato` — obbligatorio, ed è il campo che conta. Se il criterio è verificato: Fatto. Se il lavoro non è finito: aggiorna almeno prossima_azione con il punto esatto a cui sei arrivato. Se non cambi né `stato` né `prossima_azione`, il giro successivo rifà lo stesso task (vedi §7): i campi del record — iniziato_il, chiuso_il, esito, evidenza — non entrano nei criteri di selezione, quindi da soli non spostano la coda di un millimetro.

Non toccare altre righe, non aggiungere colonne.

4. Se serve una decisione di Ettore

Se il lavoro si ferma su un bivio che solo Ettore può sciogliere: apri una richiesta
nella stanza Richieste (POST /api/richieste, formato del Blocco 5 — vedi
richieste.json per il formato esistente se il Blocco 5 non è ancora stato fatto) e
metti il task in Bloccato su Ettore. Non lasciarlo in un altro stato a metà.

5. Cosa scrivere nel canale

Canale: #romeo-report (channel:1525870796684136569).

Scrivi solo se: il task è stato chiuso, è fallito, oppure è nata una domanda per
Ettore (richiesta aperta). Altrimenti, silenzio totale — nessun messaggio "ho
controllato e non c'era niente".

Massimo 6 righe: cosa è stato fatto (id + titolo), esito, e se è nata una richiesta
dillo in una riga con il link/id della richiesta.

Tetto di output del turno: massimo 80 righe. Quello che eccede va scritto su file
sotto CATPIT_vault\loop_lavoro\ e nel canale si mette solo il percorso del file.

6. Consegna fallita non è lavoro non fatto

Se la consegna nel canale fallisce (es. OutboundDeliveryError: file not found, visto
sui vecchi cron loop-vf-11 e loop-vf-5): ritenta una volta. Se fallisce ancora,
il giro resta comunque valido: l'esito è già scritto nel record (passo 3), quindi
il lavoro non è perso anche se sembra silenzio.

7. Limite noto — task ripetuto

Oggi, se il passo 3 non viene eseguito (o se stato/prossima_azione restano uguali),
il giro successivo sceglie di nuovo lo stesso task: nessuno dei 4 criteri di
selezione cambia da solo. Non è stato aggiunto un quinto criterio per evitarlo (la
regola di selezione vieta aggiunte oltre i 4 elencati sopra).

Attenzione, e qui la prima versione di questo documento diceva una cosa falsa.
Scrivere il record non basta. Verificato in revisione il 19/08 su copie del CSV:

Cioè: un giro può chiudere il record in tutti i suoi campi e il ciclo lo ripesca
comunque all'ora successiva, perché esito, evidenza, iniziato_il e chiuso_il
non sono criteri di selezione. L'unica cosa che sposta la coda è stato (verso
Fatto, Bloccato su Ettore, o l'archiviazione) oppure lo svuotamento di
prossima_azione. Per questo il passo 3 chiede --stato obbligatorio.

Resta voluto che un task lasciato In corso con una prossima_azione aggiornata venga
ripreso al giro dopo: è così che un lavoro lungo avanza a blocchi senza perdersi. Ma va
tenuto d'occhio: se un giro non riesce a cambiare né stato né prossima_azione, il
ciclo gira a vuoto sullo stesso task. Un'esclusione esplicita per turno è un criterio in
più, da decidere con Ettore, non da aggiungere d'ufficio qui.

8. Riferimenti

• Selettore: scripts\loop_lavoro.mjs (--dry per test, --select per l'uso reale).
• Scrittura del record: scripts\record_task.mjs (backup automatico, una riga sola).
• Coda condivisa: scripts\coda.mjs.
• Stati e regole di chiusura: CATPIT_vault\CICLO_TASK.md.
• Stato del cantiere: CATPIT_vault\STATO_CANTIERE_RECORD.md.