refactor: elimina step-7 e step-9, consolida script alla root

- step-9/: config.py, rag.py, retrieve.py → root;
  test_ollama.py → ollama/
- step-7/: eliminata, già coperta da ollama/
- sys.path aggiornati in rag.py, retrieve.py, ingest.py,
  check_env.py (step-7 e ollama)
- Riferimenti step-9/config.py → config.py in tutti i file

step-8/README.md

@@ -15,14 +15,14 @@ salva in ChromaDB (vector store persistente su disco).
 
 ## Configurazione modello
 
-Il modello di embedding viene letto da **`step-9/config.py`**:
+Il modello di embedding viene letto da **`config.py`**:
 
 ```python
-# step-9/config.py
+# config.py
 EMBED_MODEL = "nomic-embed-text"   # ← cambia qui
 ```
 
-> Il modello scelto qui deve corrispondere a quello usato in step-9.
+> Il modello scelto qui deve corrispondere a quello usato in rag.py.
 > Se lo cambi dopo aver già vettorizzato, devi rieseguire step-8 con `--force`.
 
 ---
@@ -54,7 +54,7 @@ distanza coseno. La directory è ignorata da git (generata automaticamente).
 
 ## Modelli supportati
 
-Stessi modelli raccomandati nel [README di step-7](../step-7/README.md).
+Stessi modelli raccomandati nel [README di ollama](../ollama/README.md).
 Il modello deve essere scaricato in Ollama prima di eseguire questo script
 (`ollama pull <modello>`).
 
@@ -81,16 +81,16 @@ Prima scelta: `qwen3-embedding:0.6b`.
 `qwen3-embedding` + `qwen3.5` condividono tokenizer e spazio semantico —
 il retrieval è più coerente rispetto a modelli di famiglie diverse.
 
-### Coerenza tra step-8 e step-9
+### Coerenza tra ingest e retrieval
 
-**`EMBED_MODEL` deve essere identico in step-8 e step-9.**
-ChromaDB memorizza i vettori generati con un certo modello. Se step-9 usa un
+**`EMBED_MODEL` deve essere identico in `ingest.py` e `rag.py`.**
+ChromaDB memorizza i vettori generati con un certo modello. Se `rag.py` usa un
 modello diverso per la query di ricerca, gli spazi vettoriali non corrispondono
 e il retrieval restituisce risultati casuali — senza alcun errore visibile.
 
 **Dopo aver cambiato `EMBED_MODEL`, riesegui sempre con `--force`.**
 Senza `--force` lo script salta la collection già esistente — i vecchi vettori
-(generati col modello precedente) restano e continuano a essere usati da step-9.
+(generati col modello precedente) restano e continuano a essere usati da `rag.py`.
 
 ```bash
 # Cambio modello → ricrea sempre la collection

step-8/ingest.py

@@ -5,9 +5,9 @@ Step 8 — Vettorizzazione
 Legge i chunk prodotti da step-6, genera gli embedding tramite Ollama
 e li indicizza in ChromaDB (persistente).
 
-Il modello di embedding viene letto da step-9/config.py (EMBED_MODEL).
+Il modello di embedding viene letto da config.py (EMBED_MODEL).
 Puoi sovrascriverlo con --model, ma deve corrispondere al modello che
-userai in step-9 — altrimenti riesegui con --force dopo aver cambiato.
+userai in rag.py — altrimenti riesegui con --force dopo aver cambiato.
 
 Input:  step-6/<stem>/chunks.json
 Output: chroma_db/<stem> (collection ChromaDB)
@@ -36,9 +36,7 @@ project_root = Path(__file__).parent.parent
 CHUNKS_DIR = project_root / "step-6"
 CHROMA_DIR = project_root / "chroma_db"
 
-# Legge EMBED_MODEL e OLLAMA_URL da step-9/config.py (fonte di verità).
-# Per spostare config.py alla root: cambia solo la riga qui sotto.
-sys.path.insert(0, str(project_root / "step-9"))
+sys.path.insert(0, str(project_root))
 from config import EMBED_MODEL, OLLAMA_URL  # noqa: E402
 
 EMBED_ENDPOINT = f"{OLLAMA_URL}/api/embeddings"
@@ -205,7 +203,7 @@ def main() -> int:
     parser.add_argument("--force", action="store_true",
                         help="Sovrascrive la collection se già esistente")
     parser.add_argument("--model", default=EMBED_MODEL,
-                        help=f"Modello embedding Ollama (default da step-9/config.py: {EMBED_MODEL})")
+                        help=f"Modello embedding Ollama (default da config.py: {EMBED_MODEL})")
     args = parser.parse_args()
 
     print("─── Step 8 — Vettorizzazione ─────────────────────────────────────────\n")