Il giro dei posti — prima di iniziare, e prima di dire «fatto»

Quando si applica: ogni lavoro che riguarda un progetto di casa — a voce, in chat, da un
cron o da un brief. Anche piccolo: conta che qualcuno, dopo, debba poter sapere cos'è successo.

Il documento è la fonte, questa skill è il promemoria

C:\Users\Ettore\Claude\Agente Residente openclaw\materiale condiviso\Sviluppo_Sistema_Agentico\PROCEDURA_2026-09-04_riallineamenti_del_lavoro.md

Dentro: §1 la procedura · §2 le posizioni (dove sta cosa, col percorso esatto e la rotta
per scriverlo) · §3 gli inneschi (se hai toccato questo, aggiorna quello) · §4 l'esempio
completo · §5 le trappole già pagate.

I percorsi non si copiano qui. Cambiano, e due copie divergono in silenzio: si apre il
documento. Questa pagina dice solo quando aprirlo e cosa fare.

PRIMA di aprire la cartella

1. Parti dall'id del task, non dalla frase. Se hai solo la frase, cerca la scheda e dichiara quale hai scelto.
2. Leggi la scheda intera e il ramo in cui vive (sottoprogetto → fase → progetto): il lavoro sta dentro un obiettivo.
3. Se il task è Fatto, o il suo ramo è CONCLUSO, non riaprirlo: il lavoro nuovo è un task nuovo che cita il vecchio.
4. Guarda se una richiesta aperta lo blocca. Se sì, non si parte.
5. Verifica i riferimenti invece di crederci: le cartelle esistono? i file citati hanno quel nome esatto? la porta risponde? Quello che è falso si corregge adesso, prima di lavorare, e si dice. Una piantina sbagliata scoperta a lavoro finito costa il lavoro.
6. Manca la prossima azione o il criterio di fatto? Si scrivono prima di iniziare — e il criterio dev'essere verificabile e aritmeticamente possibile.
7. Leggi le ultime dieci righe del diario dell'app che stai per toccare. Se quello che stai per fare contraddice una riga, fermati e chiedi.

DURANTE

• Stato In corso e data di inizio quando cominci davvero.
• Spunta i sottotask mano a mano, non tutti alla fine.
• Lavoro non previsto → diventa un sottotask, non lavoro invisibile.
• Decisione che è solo di Ettore → richiesta con opzioni e raccomandazione; il blocco lo mette l'API da sola.
• Chiuso un pezzo, passa subito gli inneschi (§3): il riallineamento rimandato a fine giornata non si fa.

DOPO, prima di dire «fatto»

1. Chiudi la scheda: stato, data, esito, evidenza = un percorso dove si va a guardare (referto, screenshot, commit), non una frase.
2. Riscrivi i riferimenti per il prossimo: workspace, contesto e programmazione devono descrivere il mondo come è adesso.
3. Passa la lista degli inneschi (§3) e aggiorna tutto ciò che il tuo lavoro ha reso falso: porte e indirizzi, struttura delle cartelle, tessera nell'Hub, mappa di CATPIT, sintesi dei progetti, diario dell'app, registro dei guasti, storia su git.
4. Riga nel diario dell'app: data · cosa è cambiato · perché · chi · commit · referto. Il cosa si ricava dal codice, il perché no.
5. Rileggi il file per verificare. {"ok":true} non è una scrittura: la prova è la riga riletta nel CSV o nel JSON. Con il campo sbagliato la rotta risponde ok e non cambia niente.
6. Solo adesso la risposta in chat.

Le tre cose da non dimenticare mai

• Il task non è la cartella: è la scheda. La cartella dice com'è, la scheda dice perché e quando è finito.
• Consegnare non è committare, e committare non è aver riavviato.
• Un lavoro raccontato in chat e non scritto nella scheda, per il sistema non è successo.