docs: sez. 11.10 incidente backfill (upsert→update_vectors) + lezioni apprese

docs/playbook.md

@@ -405,6 +405,35 @@ il costo.
 - qdrant-client 1.19.0 (create_vector_name, query_points); fastembed 0.5.1
   con pre-download del modello nel Dockerfile
 
+### 11.10 INCIDENTE 2026-08-16: backfill che cancella payload e vettori densi
+
+**Sintomo**: dopo il deploy dell'hybrid retrieval, tutti i record hanno perso
+payload (testo, metadata) e vettore denso; restano solo i vettori sparsi bm25.
+
+**Causa**: `_backfill_sparse()` usava `qdrant.upsert` con `PointStruct` che
+contiene SOLO il vettore sparso. In Qdrant l'upsert **sostituisce l'intero
+punto** (payload + tutti i vettori). Il backfill ha quindi sovrascritto 330
+record di produzione.
+
+**Fix**: `qdrant.update_vectors()` — aggiorna SOLO i vettori specificati,
+preservando payload e vettori non menzionati ("Keeps payload and unspecified
+vectors unchanged").
+
+**Recovery**: 278/330 record ricostruiti dalle sessioni pi (chiamate
+qmem_store/qmem_correct con memory_id nei toolResult, incluse sessioni
+egeos-copilot). 52 record persi (agenti su altre macchine: agy, payagent,
+pi-local). Script: estrazione `/tmp/extract_qmem3.py` + ripristino
+`/tmp/recover_qmem2.py` (incrementale, salta i già ripristinati).
+
+**Lezioni**:
+1. MAI usare `upsert` per aggiornamenti parziali in Qdrant — usare
+   `update_vectors`/`set_payload`
+2. Il backup giornaliero non era mai partito: il redirect del cron su
+   `/var/log` falliva (permessi root) — log spostato in
+   `/home/enne2/archive/backups/memory/backup.log`
+3. Testare le migrazioni su una collection di test con dati REALI (non solo
+   record creati dopo il backfill)
+
 ### 11.5 project_id obbligatorio
 
 - Dal gateway v2.4.0 / estensione v1.4.0: `project_id` è **obbligatorio** in `POST /v1/memories` (Pydantic `min_length=1`) e nello schema del tool `qmem_store` (Type.String, non più Optional)