loop-e-coda — il motore del lavoro autonomo

Usa questa skill ogni volta che stai girando dentro un cron / loop / anello di catena,
oppure quando devi creare un loop, fermarlo, o scrivere una richiesta a Ettore.

Regola madre: il trigger del lavoro non è l'orologio, è la coda. Il cron è stupido
("prendi il primo della coda"); obiettivo, deliverable e criterio di "fatto" viaggiano col
task, non col prompt del cron.

1. Cos'è un task "pronto"

Un task è pronto solo se tutte e tre:

1. non è Fatto;
2. non è Bloccato su Ettore;
3. ha una `prossima_azione` scritta — una frase che dice cosa fare adesso, non un tema.

Se manca la prossima azione, non è pronto: compare nella sezione "Non pronti" della vista
coda e non si nasconde. Non promuoverlo a mano: o gli scrivi la prossima azione (se sai qual è),
o apri una richiesta per farsela dire.

Coda vuota → il loop non si inventa lavoro. Manda le domande e si ferma. Inventare lavoro
è il modo più veloce per bruciare una finestra e produrre artefatti che nessuno ha chiesto.

2. Il giro di un anello, in ordine

1. GROUNDING   stato finestre + coda CATPIT + memoria di oggi/ieri
2. PESCA       primo task pronto (rispetta il perimetro: cosa non toccare)
3. LAVORA      fino a un artefatto verificabile
4. ALLINEA     CATPIT (master) -> ELENCO (sintesi) -> commit   [vedi allinea-fonte-verita]
5. PROGRAMMA   l'anello successivo, se ha senso
6. CHIUDI      report corto + il job si autocancella

Un anello che non lascia un artefatto verificabile ha sprecato una finestra. "Ho analizzato"
non è un artefatto; un file, un container che parte, un test verde, una riga in un CSV lo sono.

Leggere e scrivere la coda

# lettura (CSV = master)
CATPIT_vault\attivita.csv        # id, progetto_id, sigla, titolo, stato, priorita, prossima_azione, note, archiviato
CATPIT_vault\task_details.json   # workspace, contesto, prompt_avvio, programmazione, sottotask

# scrittura: SEMPRE via API, mai a mano nel CSV (l'API fa il .bak e tiene gli stati coerenti)
Invoke-RestMethod -Uri http://127.0.0.1:3010/api/tasks -Method Post -ContentType application/json -Body (@{
  action="update"; id="a69"; data=@{ stato="Fatto"; prossima_azione=""; note="..." }
} | ConvertTo-Json -Depth 5 -Compress)

action: create | update | detail | archive | restore. Risposta {ok:true}.
GET /api/tasks risponde 405: è una route di sola scrittura, per leggere usa i file.

Lo stato "Bloccato su Ettore" non lo scrivi mai a mano: lo mette e lo toglie l'API delle
richieste, da sola, sui task citati da una richiesta aperta.

3. Quando ti fermi — la richiesta

Ti fermi quando incontri una decisione che solo Ettore può prendere. La domanda va nella
stanza Richieste, non dentro un report che nessuno rileggerà.

POST http://127.0.0.1:3010/api/richieste
{ "action":"add", "richiesta": { ...campi... } }

Il contratto di scrittura completo è in CATPIT_vault\COME_SI_SCRIVE_UNA_RICHIESTA.md:
leggilo prima di scrivere la prima richiesta della sessione. In sintesi:

Test della card autoportante: una persona che non ha mai visto il progetto deve poter
leggere solo quella card, sul telefono, e capire di cosa si parla, cosa deve decidere, cosa
cambia fra A e B, e cosa resta fermo se non risponde. Se per capirla serve sapere cos'è a44,
la card è rotta.

Corollario: chi tace blocca. Il non-blocco è una scelta dichiarata (bloccante:false),
mai un effetto collaterale.

4. Programmare l'anello successivo (cron)

La regola che costa di più dimenticare: MAI `--tools`.
La allow-list viene iniettata dal tool cron MCP e mutila i permessi dell'agente
(CLI backend claude-cli cannot enforce runtime toolsAllow). Il percorso CLI senza --tools
salva un payload pulito e l'agente parte con permessi pieni.

openclaw cron add --name "<nome>" --agent main --at "<ISO>" \
  --session isolated --model claude-opus-5 --announce --channel discord \
  --to <channelId> --delete-after-run --timeout-seconds 5400 \
  --message "<brief completo: l'anello successivo non eredita il tuo contesto>"

Regole d'oro (verificate 2026-07-03):

1. mai `--tools`;
2. `--channel <id>` esplicito, mai last (ci sono più canali configurati);
3. crea il job da CLI, non con il tool cron di un agente (è quello che inietta la allowlist);
4. --delete-after-run su ogni anello di catena.

Il --message è l'unico contesto che l'anello successivo avrà: scrivici **dove sei arrivato,
cosa non deve toccare e da dove ripartire**, non un titolo.

5. Catena a staffetta ≠ loop infinito

Una catena ha una scadenza scritta e un solo anello vivo per volta. Due anelli vivi
insieme rompono la staffetta: si contendono la stessa finestra 5h e la esauriscono a metà.

• La finestra 5h è una sola, condivisa da tutti gli agenti. Per questo si lavora a staffetta e non con dieci cron in parallelo.
• Chi decide l'orario del prossimo anello è lo script, non tu (node scripts/finestra.mjs --prossimo → orario ISO oppure STOP).
• Su STOP: non creare nulla, scrivi il motivo nel report, chiudi la catena.
• Verifica sempre con openclaw cron list che non siano rimasti doppioni.
• Cedi il passo alle catene già schedulate (es. i loop di Video Factory): se il tuo orario cade dentro la loro finestra, spostalo dopo.

6. Perimetro — cosa un loop non fa mai da solo

• Niente azioni irreversibili, esterne o costose: pubblicazioni, spese, invii a terzi, cancellazioni. Quelle si propongono in una richiesta.
• Niente lavoro su file che un altro agente sta toccando in quel momento (conflitti di merge garantiti): controlla chi ha in carico cosa prima di aprire una cartella condivisa.
• Niente scritture importanti senza conferma: vale la regola di casa, anche dentro un loop.

7. Report di fine anello (corto, sempre lo stesso schema)

• che task hai preso e cosa esiste ora che prima non c'era;
• stato delle finestre a inizio e a fine;
• quando gira il prossimo anello, o perché la catena si è fermata;
• cosa serve da Ettore, con il link alla richiesta che hai aperto.