---
name: feedback_ritorno_body_prima_di_cancellare
description: Verificare sempre il body reale di un promemoria @ritorno con query diretta prima di cancellarlo — fetch_pending_tasks lo scarta a monte, dando un falso "solo titolo"
metadata:
  type: feedback
---

Prima di cancellare un `@ritorno` da Attività (`delete_task`), verificare il campo `body` con una query diretta al singolo task (`graph_get` su `/me/todo/lists/{list}/tasks/{id}`), mai fidandosi di un controllo fatto sull'oggetto restituito da `fetch_pending_tasks()` — quella funzione scarta `body` a monte per costruzione (tiene solo `id`/`list_id`/`title`/`list`/`due`/`created`), quindi qualunque check successivo su quell'oggetto trova sempre `{}` anche quando il corpo reale ha contenuto.

**Perché**: il 26/08/2026 un `@ritorno` su domotica IoT è stato cancellato dopo un controllo che sembrava confermare "solo titolo, nessun corpo" — in realtà il controllo interrogava l'oggetto sbagliato (quello già svuotato da `fetch_pending_tasks`), non il task reale. Mauro ha segnalato che il promemoria aveva più contenuto, ma per allora era già tardi: `delete_task` su Microsoft To Do **non è recuperabile** (nessun cestino esposto via Graph API, GET successivo dà 404), e la cancellazione sincronizza sul telefono prima che si faccia in tempo a fare uno screenshot come ripiego. Contenuto perso per sempre — vedi `archivio/Mauro/progetto-domotica-iot.md` (nota 26/08) per il caso reale.

**Come applicare**: qualunque azione irreversibile (cancellazione, non solo su `@ritorno`) basata su "ho controllato e non c'è altro contenuto" merita una verifica sulla fonte primaria, non su un oggetto già filtrato/trasformato da una funzione di comodo — specialmente quando quella funzione è stata scritta per un altro scopo (qui: il fetch standard di `avvio-sessione`, che non ha mai avuto bisogno del body). Il gotcha tecnico specifico è documentato anche in `.claude/skills/processa-promemoria/SKILL.md`.