METODO DI LAVORO — hub operativo

File di riferimento costante: contiene l'essenziale del come lavoriamo e rimanda ai
documenti completi. Obiettivo di fondo: rendere l'esecuzione dei task autonoma e in loop,
così che gli agenti lavorino non-stop e consegnino a Ettore solo bivi di sviluppo e report.

0. Come si usa

• Questo file va caricato a ogni conversazione (estratto essenziale). In caso di conflitto, vince il file più specifico linkato.
• Non duplica gli altri documenti: qui l'essenziale, il dettaglio è nei link in fondo.
• Non tutti i task usano tutti gli strati: si sale di strato solo quando serve.

Riformulazione lineare — i 3 assi del metodo

Il metodo si legge su 3 assi ortogonali che si incastrano. Tenerli distinti è ciò che lo rende lineare:
il Ciclo dice QUANDO, gli Strati dicono COME, i Livelli di conoscenza dicono DOVE; l'Autonomia decide cosa non chiedere.

• Asse 1 · Ciclo (QUANDO) — come nasce e avanza un lavoro: bisogno → richiesta → ideazione → pianificazione → esecuzione (in loop) → check AI dei goal → check umano → feedback. Mappa su PDCA (A/B/C/D) e su CATPIT (Progetto → Fase → Task → Sottotask). Vedi §2.
• Asse 2 · 5 Strati (COME) — la pila tecnica che si applica dentro l'esecuzione: L1 prompt · L2 context · L3 harness · L4 multi-agent · L5 loop. Cumulativi. Vedi §1.
• Asse 3 · 3 Livelli di conoscenza (DOVE) — dove vive l'informazione che alimenta L2:

1. memoria agentica (.claude/…/memory/ + MEMORY.md, sempre-on); 2) contesto workspace (AGENTS.md, SOUL.md, questo file, sempre-on); 3) vault MD_DB_v1 (dettaglio, a richiesta).

• Collante · Autonomia — governa L5: reversibile → si procede da soli; stop solo su (1) irreversibile/esterno/costoso, (2) bivio di preferenza, (3) fine goal. Vedi §3.

Integrazione con gli altri processi: l'Asse 1 è il PDCA+cron già in uso; il cron dà i loop
schedulati (L5); gli agenti Romeo/Archimede/Creso sono l'L4; in CATPIT i campi prompt_avvio
e contesto di ogni task sono L1/L2 codificati nel dato.

Tipologie di task (preset di esecuzione)

Dico "svolgi in TX" e l'agente riformula il task sulle leve del metodo. Default = T2.

Combinabile col parallelo: "su A/B/C in T3 in parallelo" → sessions_spawn, una sessione per
progetto, report nella chat giusta. Guardrail invariati (anche in T3 le azioni irreversibili/esterne/
costose si propongono). Dettaglio: MD_DB_v1/01_STRUMENTI_di_LAVORO/Metodo_di_lavoro/TIPOLOGIE_TASK.md.

1. I 5 strati — la pila di esecuzione di un task

Cumulativi: ogni strato poggia sul precedente. Sono i principi che Romeo riusa per ogni nuovo task.
📚 Base di conoscenza (un pacchetto per strato): MD_DB_v1/01_STRUMENTI_di_LAVORO/Metodo_di_lavoro/CONOSCENZA_5_strati/ (L1…L5, struttura comune: definizione · principi · checklist · tecniche · errori · autonomia · esempi · fonti).

L1 · Prompt engineering — dare l'istruzione giusta.
Ruolo · obiettivo · vincoli · formato output · esempi. Tag/struttura, ragionamento passo-passo.
→ MD_DB_v1/01_STRUMENTI_di_LAVORO/06_prompt_engineering.md, skill prompting.

L2 · Context engineering — dare il contesto giusto al momento giusto.
Livelli: sistema / progetto / sessione / conoscenza. Grounding prima di agire (rileggere il
contesto locale, mai a memoria). Riassunti di passaggio e handoff a fine sessione.
→ skill context-engineering.

L3 · Harness engineering — dare gli strumenti e i guardrail giusti.
Quali tool/skill/permessi mettere a disposizione dell'agente; verificare sempre l'output;
regola reversibile/irreversibile; riusare skill/repo esistenti invece di rifare a mano.

L4 · Multi-agent framework — distribuire il lavoro quando supera un contesto o una competenza.
Romeo (capo di gabinetto) · Archimede (dev/office/CATPIT/security) · Creso (investimenti).
Delega con brief chiaro: obiettivo · output atteso · scope di scrittura · come si verifica.
→ CREW.md.

L5 · Loop engineering — rendere l'esecuzione iterativa e autonoma. (il ponte verso l'autonomia)
Loop fino al goal; verifica automatica dei goal (check AI); l'agente si ferma solo ai punti
definiti (vedi §3). Lavori programmatici via cron. È lo strato su cui si gioca la tua esigenza.

2. Il ciclo di lavoro (metodo end-to-end)

`bisogno → richiesta → ideazione → pianificazione costruzione → prompt → esecuzione (in loop)
→ check AI dei goal → check umano → feedback`

Mappa sul PDCA già in uso (A ideazione · B pianificazione · C realizzazione/esecuzione · D check).
Due punti di fermata: check AI dei goal (automatico, dentro il loop) e check umano (tu, sui bivi
e sul deliverable). Il feedback rientra come nuovo bisogno/richiesta.
→ dettaglio in AGENTS.md (Metodo di sviluppo progetti — PDCA + cron).

3. Autonomia & loop — ⚠️ PROPOSTA da validare (punto aperto)

Ettore teme che i "gate per strato" siano più una gabbia che una liberazione. Concordo.
Proposta alternativa (non gate rigidi, ma definire cosa NON serve chiedere):

• L'agente procede non-stop su tutto ciò che è reversibile e a basso rischio (letture, ricerche, bozze, costruzione in cartelle di lavoro, iterazione fino al goal).
• Si ferma e chiede solo su: (1) azioni irreversibili / esterne / costose (scritture su fonte-verità, invii, spese API, pubblicazioni); (2) bivi di preferenza dove servono i gusti/obiettivi di Ettore; (3) fine di un goal, per il check umano.
• Tutto il resto è liberazione: definendo bene i 3 casi di stop, l'agente sa che su tutto il resto può andare avanti da solo.

(Da confermare/limare insieme prima di fissarlo come regola.)

3.1 Catena di cron a staffetta — come si occupa una finestra di utilizzo

(metodo fissato il 2026-08-02 su richiesta di Ettore)

Il problema: la capacità di calcolo non è un serbatoio che si svuota quando vuoi, è un
affitto a tempo. La finestra 5h e la settimanale si resettano da sole, e ciò che non è
stato speso evapora. Lanciare dieci cron insieme non aiuta: la finestra 5h è **una sola e
condivisa da tutti gli agenti**, quindi dieci lavori paralleli si contendono lo stesso spazio e
lo esauriscono in un colpo, lasciando vuote le ore successive.

La forma giusta è una staffetta: un anello alla volta, ognuno che passa il testimone al
successivo. Ogni anello fa quattro cose, in quest'ordine:

1. lavora — prende il primo task pronto dalla coda CATPIT e lo porta avanti;
2. misura — legge quanto resta della finestra (node scripts/finestra.mjs, che interroga /api/usage/anthropic);
3. programma il successivo — crea un cron one-shot all'orario che lo script gli dice: subito se c'è margine nella 5h, al reset della 5h se è quasi piena;
4. si cancella — deleteAfterRun: true, così la catena non lascia rifiuti dietro di sé.

La regola che tiene in piedi il metodo: l'orario non lo decide l'agente, lo decide lo script.
finestra.mjs risponde PROGRAMMA <iso> oppure STOP <motivo>, e l'anello esegue. Un modello che
calcola da sé quanto margine resta finisce per convincersi che ce n'è: qui il calcolo è aritmetica
su un dato letto, non un giudizio.

I tre freni, tutti nello script e non nel prompt:

• termine — nessun anello viene programmato oltre la scadenza della campagna;
• soglia — si smette quando la settimanale arriva al 92%, non al 100%: l'ultimo 8% serve a Ettore per lavorare;
• fail-closed — se l'usage non è leggibile, la risposta è STOP. Una catena che si ferma per un errore di lettura costa una finestra; una che gira alla cieca costa la settimana.

Quando usarla: quando c'è capacità che scadrebbe inutilizzata, o un lavoro lungo che si può
spezzare in tappe indipendenti. Quando non usarla: per lavoro che richiede una decisione di
Ettore a metà — lì la catena si ferma alla prima domanda e ha bruciato una finestra per nulla.
Prima di avviarla, i task in coda devono avere una prossima azione scritta: la staffetta non
inventa il lavoro, lo pesca.

Strumenti: Agente Residente openclaw\scripts\finestra.mjs (metronomo) ·
scripts\token_gate.mjs (semaforo prima di un giro singolo).

3.2 Ritmo giorno/notte — quando si parla e quando si costruisce

(istruzione di Ettore, 2026-08-17)

La giornata è divisa in due tempi, con ruoli e modelli diversi. Non si mescolano: di giorno si
decide, di notte si esegue.

Giorno — chatting Ettore ↔ agenti. Il tempo in cui Ettore è presente serve a *organizzare e
pianificare i processi*: si parla, si sciolgono i bivi, si scrivono richieste e task con prossima
azione, si preparano i brief. Il prodotto del giorno non è codice: è lavoro pronto da eseguire
— task in coda con obiettivo, deliverable e criterio di fatto. Se un task non è chiaro di giorno,
di notte non lo diventa.

Notte — sviluppo, creazione app, refine. Gli agenti lavorano sulla coda preparata di giorno,
con una divisione dei ruoli fissa:

Regola non negoziabile: almeno un ciclo di controllo di Fable 5 su ogni lavoro notturno. Un
deliverable prodotto da Sonnet 5 non si considera chiuso finché Fable 5 non l'ha ripassato e non
ha detto cosa ha verificato. Se il controllo trova un difetto, il lavoro torna all'esecutore e il
ciclo si ripete — il controllo è uno almeno, non uno al massimo.

Eccezione — i lavori piccoli non aspettano la notte (istruzione di Ettore, 18/08).
Il ritmo sopra vale per i cantieri: un'app nuova, un rifacimento largo, tutto ciò che dura più
turni. Per un lavoro semplice e circoscritto — un refine dell'Hub Strumenti, un riordino, una
correzione con perimetro chiaro — si chiede subito ad Archimede con Opus 5 e si fa adesso.
Programmare una catena di turni notturni per mezz'ora di lavoro fa aspettare Ettore mezza giornata
e occupa finestre di calcolo che servono altrove. La domanda da farsi prima di scrivere un cron è
sempre la stessa: quanto dura davvero questo lavoro?

Guardrail invariati: anche di notte le azioni irreversibili/esterne/costose si propongono, e
quello che serve a Ettore decidere finisce nella stanza Richieste, non in un report. Se la coda è
vuota o i task non hanno prossima azione, la notte non si inventa lavoro: si scrivono le
domande e ci si ferma.

4. Mappa del sistema (dove sta cosa)

• Spazi: workspace .openclaw/workspace · lavoro Agente Residente openclaw · vault MD_DB_v1 · CATPIT (catpit/ app + CATPIT_vault/ dati). → 00_MAPPA_CARTELLE.md.
• Fonte-verità progetti: dati CATPIT (progetti.csv + attivita.csv + task_details.json); ELENCO_PROGETTI.md = sintesi narrativa; Airtable = specchio.
• Dove reperire conoscenza: vault MD_DB_v1 (02_CONOSCENZA, 01_STRUMENTI_di_LAVORO); memoria OpenClaw (memory/ + MEMORY.md); memory_search prima di rispondere sul pregresso.
• Agenti: Romeo / Archimede / Creso → CREW.md.

5. Prompt & context — artefatti e app dedicata (workstream APERTO)

Obiettivo: potenziare gli strumenti che permettono a Ettore di **creare prompt ben strutturati
e connessi al contesto**. Artefatti esistenti individuati (da consolidare, forse in una app dedicata):

• CATPIT — task_details.json: ogni task ha prompt_avvio + contesto + workspace strutturati, con feature "Avvia" (è già un mini prompt-builder connesso al contesto).
• Cowork — prompt costruiti ad hoc (es. 00_CC_GESTIONE_CHATS/2026-07-04_prompt-fable5-*, 2026-07-06_prompt-fable5-restyling-*).
• Vault/skill — 06_prompt_engineering.md, skill prompt-engineering / prompting.
• Direzione proposta: un'app dedicata "prompt builder" che pesca dal contesto (progetti, vault, memoria) e produce prompt pronti per gli agenti. Da decidere insieme.

6. Compilare un progetto in CATPIT — cinque passi, in quest'ordine

*Nato il 30/08/2026 dai cinque errori fatti in mezz'ora costruendo la sezione «Ispirazione ed
esempi»: fase appesa al livello sbagliato, due tassonomie da buttare, uno stato inesistente,
e sei schede create fidandosi della risposta invece di rileggere il file.*

La gerarchia, per non sbagliare livello:
progetto → sezione → sottosezione → fase → task. Una fase non si appende a una sezione.

1. Prima domanda: cosa avrò in mano quando è finito? Una frase. Se non so rispondere, non
è ancora un progetto e non si apre. È questa risposta che detta la struttura — non il
contrario.

2. Tre letture da trenta secondi, prima di scrivere qualsiasi cosa.

• il modello: quali livelli esistono e chi sta dentro chi;
• il vocabolario: quali valori sono ammessi nei campi (gli stati dei livelli sono PIANIFICATO · IN CORSO · CONCLUSO, quelli dei task sono altri);
• un esempio vero già in casa: come è fatta una sezione che funziona.

3. I rami si tagliano sul prodotto, non sull'argomento. Una sottosezione per ogni cosa
diversa che avrò in mano alla fine. Due rami che finiscono nello stesso prodotto sono **un
ramo solo. Un ramo che finisce dove finisce già un altro pezzo del sistema non si crea**:
è duplicazione. *(Esempio buono: «sistemi che usiamo» finisce in un manuale, «control plane»
finisce in una decisione, «esempi minori» non finisce mai. Tre prodotti, tre rami.)*

4. Le fasi sono i passaggi di stato del prodotto, non le attività da svolgere. Se ne
creano solo quelle che servono adesso: le altre nascono quando ci si arriva, altrimenti
sono caselle vuote che dicono solo che non abbiamo ancora lavorato. Una fase senza criterio di
chiusura va dichiarata presidio nel nome e nel goal, o resterà «in corso» per sempre
falsando i conteggi.

5. Alla fine si rilegge dal file, non dalla risposta. «ok» non vuol dire «scritto»: l'API
dei task scarta in silenzio sottoprogetto_id, fase_id, criterio_fatto e
assegnato_a in creazione — vanno messi con una update successiva, e verificati sul CSV.

Il ritmo: prima la struttura vuota, poi il contenuto. Al contrario si spostano le stesse
schede tre volte.

Sulla velocità: non viene dallo scrivere in fretta, viene dal non rifare. Quando la
struttura dipende da una preferenza di Ettore — e capita spesso, perché è lui che ci lavora
dentro — una domanda secca vale più di tre proposte: mi dà il taglio in due righe e io lo
eseguo pulito, invece di indovinare e farmi correggere.

Link ai file completi

• AGENTS.md — regole operative + metodo PDCA/cron · SOUL.md — persona/tono · IDENTITY.md
• CREW.md — squadra e chi-fa-cosa
• 00_MAPPA_CARTELLE.md — struttura cartelle
• ELENCO_PROGETTI.md — sintesi progetti (fonte-verità = dati CATPIT)
• MD_DB_v1/01_STRUMENTI_di_LAVORO/06_prompt_engineering.md — guida prompting
• MD_DB_v1/01_STRUMENTI_di_LAVORO/14_OpenClaw_architettura_conoscenza_e_riordino.md — regole della casa

Changelog

• 2026-07-16 — v0.1: creato l'hub (5 strati, ciclo di lavoro, mappa sistema, artefatti prompt/context); §3 Autonomia e §5 App prompt restano punti aperti da decidere con Ettore. (Romeo)
• 2026-07-16 — v0.2: creata la base di conoscenza dei 5 strati in MD_DB_v1/01_STRUMENTI_di_LAVORO/Metodo_di_lavoro/CONOSCENZA_5_strati/ (L1…L5, struttura comune, fonti Anthropic). Cartella operativa con README di indice. (Romeo)
• 2026-07-19 — v0.3: aggiunte le Tipologie di task (T1-T4, preset di esecuzione) qui, in AGENTS.md (sempre-on) e in memoria; catalogo completo in Metodo_di_lavoro/TIPOLOGIE_TASK.md. (Romeo)
• 2026-08-17 — v0.4: aggiunta §3.2 Ritmo giorno/notte su istruzione di Ettore: di giorno chatting per organizzare/pianificare, di notte sviluppo con Fable 5 revisore/amministratore e Sonnet 5 esecutori, con almeno un ciclo di controllo di Fable 5 su ogni deliverable. (Romeo)
• 2026-08-30 — v0.5: aggiunta §6 Compilare un progetto in CATPIT (cinque passi), scritta su richiesta di Ettore a partire dagli errori commessi lo stesso giorno sulla sezione «Ispirazione ed esempi» del progetto CATPIT. (Romeo)