Ciclo di vita del task
agg. 2026-08-19CATPIT_vault/CICLO_TASK.mdCiclo di vita del task
Obiettivo di questo documento: rendere la chiusura di un task un fatto verificabile,
non una dichiarazione in chat.
1. Stati ammessi
Esattamente i cinque usciti dalla normalizzazione del Blocco 1 (confermati dalla
revisione Fable 5, REVISIONE_FABLE_blocco1.md). Nessuno stato nuovo:
| Stato | Significato |
|---|---|
Da iniziare | Non c'è ancora lavoro in corso su questo task. |
In corso | Qualcuno (agente o Ettore) ci sta lavorando adesso. |
Bloccato su Ettore | Il lavoro è fermo: serve una decisione o un'azione che solo Ettore può dare. Lo stato lo mette e lo toglie in automatico l'API quando una richiesta che lo cita si apre o si chiude (regola fissa, AGENTS.md) — non si scrive a mano. |
In pausa | Sospeso per scelta (priorità cambiata, in attesa di un altro task), non per un blocco su Ettore. |
Fatto | Chiuso, con criterio_fatto verificato ed esito/evidenza compilati. |
Non esiste uno stato Fallito in questo insieme: un task che non ce la fa restaIn corso o Bloccato su Ettore finché non viene deciso cosa farne, oppure si chiude
comunque Fatto con esito = fallito o esito = abbandonato (l'esito distingue il come,
lo stato dice solo se il task è ancora aperto).
2. Tabella dei passaggi
| Da | A | Chi può farlo | Cosa serve |
|---|---|---|---|
Da iniziare | In corso | agente assegnato o Ettore | assegnato_a valorizzato, iniziato_il compilato |
Da iniziare | Bloccato su Ettore | l'API, automaticamente | esiste una richiesta aperta in richieste.json che cita l'id nel campo blocca[] |
In corso | Fatto | chi esegue il lavoro | criterio_fatto non vuoto e verificato davvero (comando eseguito o file controllato); esito ∈ {riuscito, fallito, abbandonato}; chiuso_il; evidenza |
In corso | Bloccato su Ettore | l'API, automaticamente | una richiesta aperta che cita l'id; niente lo scrive a mano |
In corso | In pausa | chi esegue il lavoro | motivo scritto in note (non un blocco: una scelta) |
In pausa | In corso | chi riprende il lavoro | note aggiornata con la ripresa |
In pausa | Bloccato su Ettore | l'API, automaticamente | una richiesta aperta che cita l'id — la regola dell'API vale su qualunque stato attivo, non solo In corso (riga integrata in revisione, 19/08) |
Bloccato su Ettore | In corso (o allo stato precedente) | l'API, automaticamente | la richiesta che lo citava si chiude con una risposta |
Fatto | (nessuna uscita prevista) | — | riapertura solo con nota esplicita di Ettore nel record; non è un passaggio automatico |
3. Regola non negoziabile
Un task senza `criterio_fatto` non è eseguibile in autonomia. Il ciclo automatico
(Blocco 3) non lo lavora: lo segnala e passa al successivo. Un task del genere non è
"pronto", anche se ha una prossima_azione scritta — vedi §5 per i casi in cui questo
è un sintomo di task definito male, non un buco da riempire a forza.
4. Cosa rende un criterio valido
Un criterio_fatto è valido se:
- È verificabile da un comando o dall'esistenza/contenuto di un file — chi legge sa esattamente cosa eseguire o cosa controllare.
- Non richiede che qualcuno guardi il risultato e dia un giudizio. "Sembra giusto", "funziona bene", "Ettore è contento" non sono criteri: sono impressioni.
- È specifico: nomina il comando esatto, il percorso del file, o il confronto da fare — non un'area generica ("il sistema funziona").
- È raggiungibile con le informazioni note oggi. Se il criterio dipende da una decisione che nessuno ha ancora preso, non è un criterio: è un segnaposto per una richiesta.
Tre esempi buoni (da task veri)
- `a56` — "T1 · Maurus: attivare l'agente":
openclaw.jsoncontiene"maurus"inagents.list. Verificato davvero il 19/08 leggendo il file: oggi èfalse, il task è ancora aperto — il criterio distingue correttamente fatto/non fatto. - `a45` — "Hardening CATPIT: test suite + refactoring (Fase 3)": la suite di test gira ed è tutta verde — un controllo eseguibile, zero giudizio. (La revisione del 19/08 ha tolto la seconda metà "nessun file sopra la soglia di righe":
CATPIT_HARDENING.mdnon contiene alcuna soglia concordata — il refactoring 3b è una proposta in attesa di OK. Un criterio non può poggiare su una decisione non presa: è la regola §4.4 applicata a se stessi.) - `a20` — "Rete aziende vicentino + PMI nord Italia": interrogando Metabase con la query "prime 20 metalmeccaniche per fatturato" si ottengono 20 righe non vuote — un comando, un risultato atteso, nessuna ambiguità.
Tre esempi cattivi (da task veri)
- `a10` — "Pilota Ambientale News (Fase 1)": la sua
prossima_azioneè "chiedere a Ettore se si chiude". Non c'è lavoro da verificare: la chiusura dipende per intero da una decisione non ancora presa. Non è un criterio da scrivere meglio: è un task senza ambito proprio, candidato a essere chiuso come duplicato (lo dice la sua stessa nota). - `a09` — "Obsidian: setup e uso": il criterio dichiarato in
task_details.jsonè "Ettore apre il vault in Obsidian e ci si muove... senza chiedere aiuto" — un giudizio soggettivo di percezione, non misurabile da un comando. - `a12` — "Automazione piano pasti": la sua
prossima_azionedice esplicitamente "Ettore prova... e dice cosa manca: senza quel giro il task non si può dichiarare finito". La chiusura, per contratto dello stesso task, passa da un verdetto umano: nessun criterio automatico può sostituirlo, va lasciato così finché non arriva.
5. Quando un criterio non si riesce a scrivere
Se per un task non si riesce a scrivere un criterio che rispetti il §4, **non si forza
una frase vaga**. È un segnale che il task è definito male: o gli manca un ambito proprio
(a10), o la sua chiusura dipende da un giudizio umano dichiarato (a09, a12), o da
una decisione non ancora presa (a49, bivio sull'avvio della Cassaforte Chiavi). In questi
casi il campo resta non noto e il task va segnalato per una richiesta — non lavorato a forza.
(Nota di revisione 19/08: il primo esempio di questo caso era a06 "bloccato su q048" — ma
q048 risulta già risposta il 04/08 ("Non ancora"): il criterio di a06 si poteva scrivere,
ed è stato scritto; il task è semmai candidato a In pausa per scelta dichiarata di Ettore.)
6. Dove si scrivono esito ed evidenza
Alla chiusura, chi esegue scrive esito ed evidenza nel record (attivita.csv),
non nel canale. Il messaggio in chat/Discord resta come notifica, ma è una copia: la
fonte è la riga del task. Se il record e il messaggio in chat divergono, vince il record.
evidenza è un percorso di file, un commit, o un comando — non una frase riassuntiva.