# nyora-notes-tt : fin du sweep Phase 1, relance Phase 2 + embedding sur le volume complet (08/08/2026)

**Date** : 08/08/2026
**Instance** : hermes-tt
**Contexte** : suite directe de `nyora-notes-tt-sweep-livelock-fix-08-08-2026.md` et
`nyora-notes-tt-ao-reference-endpoint-pj-archive-fix-08-08-2026.md` (meme chantier, session
suivante). Action demandee par Nabil en fin de session precedente : surveiller la fin du
sweep Phase 1 puis enchainer Phase 2 (extraction) + embedding sur le volume complet de PJ,
sans attendre une nouvelle session.

## 1. Fin du sweep Phase 1 (confirmee, pas d'intervention necessaire)

Le sweep `run_batch_sweep_all_years.sh` (lance le 07/08 21h58, deja passe par le fix
livelock `scan_fail_count`) a atteint son plafond `MAX_BATCHES=15` de lui-meme, sans aucune
intervention :

```
[2026-08-08 02:22:41] Lot 15 termine, code retour=0
[2026,08-08 02:22:42] === FIN sweep toutes annees : 3 notes restantes ===
```

Les 3 notes restantes sont exactement les 3 notes a timeout OWA permanent deja identifiees
dans le runbook du livelock (`note_8daed11d2468`, `note_3bbba52d709b`, `note_8c56696597e7`) --
comportement attendu, decision deja actee de ne pas investiguer la cause OWA tant que ca
reste marginal. Aucune boucle infinie : le plafond de lots protege bien contre ce risque,
comme concu.

## 6. Nouveau script : run_phase2_embed_full.sh

Cree pour cette relance, sur le meme modele que `run_batch_sweep_all_years.sh` (boucle avec
condition d'arret + log horodate). Chaine trois etapes :

1. **Phase 2** (`extract_attachments_phase2.py`, limit=200 par passage) en boucle jusqu'a
   `remaining_pending<=0` (max 10 passages, garde-fou).
2. **Embedding** (`embed_attachments.py`, pas de limite -- traite tout ce qui est
   `extraction_status='processed'` et pas encore dans `attachments_vec`).
3. **Audit** : requete recap `content_hash` / `ao_reference` / `attachments_vec` / JOIN exact
   avec `onedrive_documents`.

**Piege rencontre et corrige** : l'etape d'audit utilise un heredoc Python (`docker exec -i
... python3 - << 'PYEOF'`). Le `-i` sur `docker exec` est indispensable pour que le heredoc
soit transmis en stdin au conteneur -- sans lui, `python3 -` ne recoit rien. A reutiliser
pour tout futur script qui pipe du Python inline dans un `docker exec`.

**Deuxieme piege (mineur, corrige en session)** : la premiere version de la requete d'audit
inline n'appelait pas `sqlite_vec.load(conn)` avant de lire `attachments_vec` ->
`OperationalError: no such module: vec0`. Meme piege que documente ailleurs pour
`embed_attachments.py` (chargement vec0 obligatoire avant toute requete sur les tables
`*_vec`). Corrige en relancant seulement l'audit avec le chargement d'extension.

Deploiement : script pousse sur le NAS par transfert base64 (evite tout probleme
d'echappement de guillemets a travers les couches mcp-nas -> ssh -> heredoc), puis lance en
arriere-plan (`nohup ... & disown`) sur le host via SSH `Best0f@172.17.0.1:22222` (alias
`nas-host`, deja configure cote mcp-nas) -- **`Best0f` est dans le groupe `docker`, aucun
besoin de `sudo`** pour les `docker exec`/`docker ps` (contrairement a `claude-ops`, absent
de ce conteneur mcp-nas).

## 3. Resultat

Phase 2 : 1 succes / 3 erreurs sur le dernier passage (le reste du volume avait deja ete
absorbe par les passages precedents en cours de session), `remaining_pending=0` -- plus rien
en attente d'extraction sur les PJ telechargees.

Embedding : 14 -> 24 (10 nouveaux embeddings, 0 erreur).

## 4. Audit final (08/08/2026, apres chaine complete)

| Metrique | Valeur |
|---|---|
| PJ totales identifiees | 49 |
| Telechargees avec succes | 27 |
| Echec telechargement (OWA, hors scope) | 22 |
| `content_hash` calcule | 27 (100% des telechargees) |
| `ao_reference` extraite | 23 (85% des telechargees) |
| Extraction reussie | 24 |
| Extraction en echec permanent | 3 |
| `attachments_vec` (embeddings) | 24 (100% des extraites) |
| JOIN exact `content_hash` avec `onedrive_documents` | 3 (1 seul au 08/08 matin -- en hausse, confirme l'hypothese de rattrapage progressif) |
| Notes non scannees restantes | 3 |

Couverture consideree bonne : tout ce qui est techniquement telechargeable et extractible
l'est. Les echecs restants (22 telechargement + 3 extraction) sont des cas OWA/format deja
identifies, acceptes comme limite connue, pas d'action prevue sauf si le phenomene s'etend.

## Decisions actees, ne pas rouvrir

- Ne pas relancer le sweep Phase 1 pour les 3 notes bloquees (cf runbook livelock).
- Ne pas investiguer les 22 echecs de telechargement OWA sauf extension du phenomene.
- `run_phase2_embed_full.sh` reutilisable tel quel pour toute relance future (idempotent :
  ne retraite que ce qui est `pending`/`error`, ne recree pas les embeddings existants).

## Fichiers modifies / crees

- `/volume1/docker/nyora-notes-tt/run_phase2_embed_full.sh` (nouveau)
- `/volume1/docker/nyora-notes-tt/phase2_embed_full_20260808_050903.log` (log d'execution)
- DB `nyora-notes-tt.db` : `content_hash`, `ao_reference`, `extraction_status`,
  `attachments_vec` mis a jour sur les PJ traitees lors de ce passage