docs: adopt integration-first preprocessing standard

docs/prd/2026-08-09-workspace-preprocessing-prd.md

@@ -5,7 +5,7 @@ revisione e conferma del proprietario
 **Data:** 2026-08-09
 **Autore:** analisi dello stato attuale (branch `codex/git-workspace-registry`) + decisioni con il proprietario
 **Uso:** riferimento stabile di requisiti e decisioni; da ogni punto nascerà un piano separato in
-`docs/superpowers/plans/` (sez. 10) — questo documento non è un piano di lavoro
+`docs/superpowers/plans/` (sez. 11) — questo documento non è un piano di lavoro
 
 ---
 
@@ -66,10 +66,15 @@ documentato e verificato da smoke end-to-end.
 
 - O1. Un solo modo canonico di eseguire il preprocessing per un workspace (niente più fixture "speciali").
 - O2. Il preprocessing è **idempotente e ripristinabile**: rerun senza duplicati, publish atomico, GC.
-- O3. Nessun segreto/endpoint entra nel repo workspace né nei descriptor (invariante attuale preservato).
+- O3. Nessun segreto/endpoint entra nel repository registry né nei descriptor (invariante attuale preservato).
 - O4. Il flusso è **documentato nei manuali operator** (`local/server-workspace-registry.md`) e coperto da
   smoke automatici.
 - O5. La **migrazione PSD** è definita (cosa si riusa, cosa si rigenera, cosa si esporta dal pgvector).
+- O6. Ogni piano tecnico definisce, dove applicabile, un **goal automatico di processo completo**: da stato
+  pulito costruisce un ambiente isolato, simula il flusso end-to-end entro lo scope del piano e lo porta a
+  successo con un integration test riproducibile.
+- O7. Dopo il successo automatico, un **percorso manuale separato** permette al reviewer di ripetere il
+  processo attraverso le interfacce reali, comprenderne l'architettura e approvare gli artefatti.
 
 ## 3. Non-obiettivi (fuori scope di questo PRD)
 
@@ -89,7 +94,7 @@ documentato e verificato da smoke end-to-end.
 | Utente | Esigenza |
 | --- | --- |
 | **Operatore/amministratore** (chi installa e cura un workspace) | Configurare DWH+evidence, eseguire il preprocessing, curare le FK, verificare lo stato, fare backup/restore. |
-| **Autore ETL / curatore dominio** (es. il cliente PSD) | Mantenere la cartella evidence e le annotazioni FK nel repo workspace con un flusso semplice. |
+| **Autore ETL / curatore dominio** (es. il cliente PSD) | Mantenere evidence e annotazioni FK nel namespace del workspace nel repository registry con un flusso semplice. |
 | **Reviewer umano** (usa l'app) | Vede search pack con tabelle/evidence/solved corretti: la qualità del retrieval dipende dal preprocessing. |
 | **Sviluppatore ThothII** | Comandi/endpoint deterministici, testabili, senza sorprese di configurazione. |
 
@@ -97,8 +102,9 @@ documentato e verificato da smoke end-to-end.
 
 ## 5. Scenario target (end-to-end)
 
-1. **Setup repo**: l'operatore crea `workspaces/<id>.yaml` (schema-v3: DWH, collection, LLM policy) + la
-   sorgente evidence dichiarata; push.
+1. **Setup repo**: l'operatore usa un **unico repository Git registry** per tutti i workspace e crea
+   `workspaces/<id>.yaml` (schema-v3: DWH, collection, LLM policy) insieme al tree curato
+   `workspace-content/<id>/evidence/`; descriptor e contenuti sono pubblicati nello stesso commit.
 2. **Installazione**: `.env` + bindings `THT_WS_*` + secrets; `up` dello stack (frontend/core/qdrant/embedding).
 3. **Registry**: pull → validazione → snapshot attivo; diagnostic DWH verdi.
 4. **Preprocessing DWH**: introspezione (physical.yaml: tabelle/colonne/descrizioni/esempi/eligibility) +
@@ -130,6 +136,10 @@ documentato e verificato da smoke end-to-end.
 - RF1.4 La configurazione (descriptor + bindings + config renderizzata) deve **prevedere i tre trasporti
   DWH**: `postgres_direct`, `rest_api`, `ssh_tunnel`. PSD usa `rest_api`; altri database potranno usare
   direct o tunnel.
+- RF1.5 Il registry usa **un unico repository Git** per più workspace. Per una sorgente evidence
+  `filesystem`, l'URI è relativa alla root del repository ed è confinata lessicalmente a
+  `workspace-content/<workspace_id>/`; path assoluti, traversal (`..`) e riferimenti al namespace di un
+  altro workspace sono invalidi. Descriptor e sorgente devono essere risolti dalla **stessa revisione Git**.
 
 ### RF2 — Preprocessing DWH (tabelle/colonne)
 - RF2.1 Comando/azione per eseguire `introspect` + `lsh` per un workspace del registry, contro la sua config
@@ -145,7 +155,7 @@ documentato e verificato da smoke end-to-end.
 - RF3.1 Flusso curato per-workspace: `tht schema suggest-fks` (+ `--from-sql`, `--assume`, `--write`),
   revisione umana, `tht schema check` (zero orfani).
 - RF3.2 Le FK curate devono essere **disponibili a runtime** (sezione `【Foreign keys】` del render mschema,
-  usata da F4/F6) e **versionate nel repo workspace** (D5).
+  usata da F4/F6) e **versionate nel repository registry** (D5).
 - RF3.3 Nessuna FK derivata dal modello: il modello usa solo la lista curata (contratto SKILL invariato).
 
 ### RF4 — Indice semantico schema + bootstrap collection
@@ -161,8 +171,10 @@ documentato e verificato da smoke end-to-end.
 
 ### RF5 — Evidence
 - RF5.1 Sorgente evidence dichiarabile per-workspace nel descriptor (protocollo/tipo + URI). Per PSD è un
-  **tree di file `.md` in una directory versionata nel repo del workspace** (`evidence/`); HTTP manifest e
-  S3 restano opzioni del motore per sorgenti esterne.
+  **tree di file `.md` versionato nell'unico repository registry**, sotto
+  `workspace-content/psd/evidence/`; in generale ogni workspace usa
+  `workspace-content/<workspace_id>/evidence/`. HTTP manifest e S3 restano opzioni del motore per sorgenti
+  esterne.
 - RF5.2 `tht preprocess evidence` per-workspace: discover → acquire → normalize/chunk → embed → upsert
   (kind `evidence`, payload `document_id`/`vector_generation`) → publish ACTIVE nel corpus root del workspace,
   con resume e dry-run (già implementato nel motore).
@@ -192,6 +204,11 @@ documentato e verificato da smoke end-to-end.
   sostituisce/completa `preprocess-smoke.sh` (oggi solo fixture).
 - RF8.4 Backup/restore coprono Qdrant (già `vector-backup.sh`/`vector-restore.sh`), corpus, `.tht-dwh` e
   registry.
+- RF8.5 Ogni piano successivo traduce il proprio risultato operativo in un **process goal** verificabile da
+  un integration test completo per quello scope; eventuali interventi umani iniziali o intermedi sono
+  ammessi solo se inevitabili, espliciti, documentati e riprendibili.
+- RF8.6 Ogni process goal automatico riuscito è seguito, quando utile, da un walkthrough manuale su un
+  ambiente nuovo e separato; automazione e accettazione umana producono evidenze distinte.
 
 ---
 
@@ -210,41 +227,130 @@ documentato e verificato da smoke end-to-end.
 - **RNF6 Performance**: introspezione ~minuti (non nel path di sessione), embedding batch, LSH boundato;
   il retrieval a runtime non cambia i costi attuali.
 - **RNF7 Manutenibilità**: nessun fork dei fixture; un solo percorso canonico (O1).
+- **RNF8 Integration-first**: il successo di un piano tecnico richiede un'esecuzione completa da ambiente
+  pulito, senza retry automatici che mascherino errori; ogni fallimento viene diagnosticato, corretto alla
+  radice e seguito da una nuova esecuzione completa.
+- **RNF9 Evidenza e cleanup**: ogni ambiente simulato ha identità/ownership esplicita, risorse univoche,
+  segreti fittizi, report machine-readable e leggibile, scansione anti-secret e cleanup confinato alle sole
+  risorse possedute dal run.
 
 ---
 
-## 8. Criteri di accettazione (bozza)
+## 8. Standard di esecuzione e verifica — integration-first
 
-1. Da un repo workspace vuoto si arriva a una sessione funzionante seguendo **solo i manuali aggiornati**,
+Questo standard si applica a P1 e, **ovunque sia tecnicamente significativo**, a tutti i piani successivi.
+Un piano che non possa applicarlo deve motivare esplicitamente l'eccezione e definire il verifier più vicino
+possibile al processo reale.
+
+### S1 — Goal automatico di processo
+
+- Ogni piano definisce il **processo completo entro il proprio scope**, con punto iniziale pulito, input,
+  componenti attraversati, risultato osservabile e criteri di successo.
+- Il goal non è "far passare alcuni test", ma **simulare con successo il processo operativo** che la feature
+  deve rendere possibile. Per P1 il confine completo è Git → registry → API → snapshot/docs → render →
+  `tht config check`; estrazione evidence e Qdrant appartengono ai piani successivi.
+- Durante l'esecuzione il goal resta aperto fino a una prova integrale verde. Se l'ambiente agentico supporta
+  goal persistenti, l'esecutore lo registra all'inizio e lo completa soltanto dopo l'evidenza finale.
+
+### S2 — Ambiente di integrazione isolato
+
+- Il test costruisce dipendenze controllate sotto `.artifacts/<plan>/<run-id>/`: repository Git simulati,
+  checkout, roots runtime, secret fixture, richieste/risposte, log e output.
+- Ogni run usa identità e nomi univoci e un manifest di ownership; non usa credenziali, repository o dati
+  reali salvo quando il piano dichiara esplicitamente un gate L2.
+- I servizi reali appartenenti allo scope vengono attraversati tramite le loro interfacce normali; quelli
+  esterni o non ancora nello scope sono sostituiti da fixture fedeli e deterministiche.
+
+### S3 — Contratto di successo
+
+- Il test parte da stato pulito, esegue il processo una volta senza retry automatici, termina con exit code
+  zero e produce `report.json` più un report leggibile.
+- Un fallimento richiede diagnosi della causa, test regressivo/correzione e una nuova esecuzione completa da
+  stato pulito; ripetere alla cieca non costituisce progresso verso il goal.
+- Il gate finale comprende determinismo/idempotenza pertinenti, scansione anti-secret, verifica degli
+  artefatti e prova del cleanup confinato. Gli artefatti possono essere conservati con `--keep` per review.
+
+### S4 — Interventi umani inevitabili
+
+- Passi umani iniziali o intermedi sono ammessi solo quando non simulabili in modo affidabile (per esempio
+  accesso approvato a un sistema reale o review di contenuto curato).
+- Ogni passo umano dichiara precondizioni, istruzioni, evidenza richiesta, criterio di decisione e checkpoint
+  di ripresa; l'automazione copre e verifica tutto ciò che precede e segue il checkpoint.
+- Un intervento umano non può essere sostituito da un'assunzione silenziosa né rendere non riproducibile il
+  resto del processo.
+
+### S5 — Walkthrough manuale successivo
+
+- Dopo il goal automatico verde, il reviewer ripete il processo in un **ambiente nuovo e separato**, usando
+  le interfacce reali e una guida passo-passo che spiega componente, stato letto, artefatto prodotto e
+  invariante verificata.
+- Il walkthrough serve a comprensione architetturale e accettazione; non sostituisce l'integration test e non
+  ne riusa lo stato già mutato.
+- Lo stato di consegna distingue almeno `automated integration: PASS` e `manual acceptance: PENDING/PASS`.
+  Un piano non è pienamente accettato finché l'eventuale gate manuale richiesto non è stato deciso dal reviewer.
+
+### S6 — Contenuto obbligatorio dei piani
+
+Ogni piano tecnico riporta, adattandoli al proprio scope:
+
+1. **Automated process goal** e comando unico di esecuzione;
+2. topologia dell'ambiente simulato e confini delle dipendenze;
+3. asserzioni del full integration test e contratto del report;
+4. checkpoint umani inevitabili, oppure dichiarazione esplicita che non ve ne sono;
+5. walkthrough/gate manuale successivo, quando utile;
+6. evidenze di completamento, retention degli artefatti e cleanup esatto.
+
+---
+
+## 9. Criteri di accettazione (bozza)
+
+1. Da un repository registry vuoto si arriva a una sessione funzionante seguendo **solo i manuali aggiornati**,
    senza toccare file fixture.
 2. La CLI di preprocessing funziona **sia sul PC/Mac dell'utente sia sul server che ospita il DWH**
    (stesso comando, config derivata dal workspace).
 3. La configurazione di un workspace dichiara e usa uno dei **tre trasporti DWH** (`postgres_direct`,
    `rest_api`, `ssh_tunnel`); PSD usa `rest_api`.
-4. `search pack` di una domanda reale restituisce tabelle (con descrizioni), evidence della generazione
+4. Il goal automatico P1 costruisce da zero repository Git simulati e ambiente isolato, attraversa con
+   HTTP reale il processo Git → registry → validate/publish/read/export → snapshot/docs → render →
+   `tht config check`, supera casi positivi e negativi senza retry e produce report/artefatti secret-free.
+5. Solo dopo il punto 4, un ambiente manuale nuovo avvia il backend su `127.0.0.1:8791` e permette al
+   reviewer di ripetere ogni chiamata e ispezionare commit, snapshot, ZIP e config renderizzate seguendo una
+   guida; il gate resta `PENDING` finché il reviewer non lo approva.
+6. `search pack` di una domanda reale restituisce tabelle (con descrizioni), evidence della generazione
    ACTIVE e solved dello stesso workspace; F4/F6 mostrano le FK curate.
-5. `qdrantEnsure`/`ollamaEnsure` verdi all'ammissione; la collection ha esattamente 1024/cosine + gli 8
+7. `qdrantEnsure`/`ollamaEnsure` verdi all'ammissione; la collection ha esattamente 1024/cosine + gli 8
    keyword-index.
-6. Rerun del preprocessing: `unchanged` (nessun duplicato); modifica di un'evidence → nuova generazione,
+8. Rerun del preprocessing: `unchanged` (nessun duplicato); modifica di un'evidence → nuova generazione,
    ACTIVE aggiornato, vecchie generazioni in GC.
-7. Smoke end-to-end automatico verde in CI con cleanup esatto (stile `preprocess-smoke.sh`).
-8. Migrazione PSD documentata e provata almeno in dry-run (re-introspection o riuso catalogo + re-embedding).
+9. Smoke end-to-end automatico verde in CI con cleanup esatto (stile `preprocess-smoke.sh`).
+10. Migrazione PSD documentata e provata almeno in dry-run (re-introspection o riuso catalogo + re-embedding).
+11. Ogni piano tecnico successivo include un process goal automatico completo per il proprio scope e un
+    walkthrough manuale quando utile, oppure documenta l'inevitabile eccezione umana secondo S4.
 
 ---
 
-## 9. Decisioni chiuse (2026-08-09)
+## 10. Decisioni chiuse (2026-08-09)
 
 > La sezione nasceva come "punti di discussione"; le decisioni sono state prese con il proprietario del
-> prodotto il 2026-08-09. Ogni punto resta il riferimento del proprio piano (sez. 10). Le opzioni scartate
+> prodotto il 2026-08-09. Ogni punto resta il riferimento del proprio piano (sez. 11). Le opzioni scartate
 > sono omesse; la motivazione della scelta è inclusa in ogni punto.
 
 ### D1 — Config per-workspace: **c) misto, con sorgente completa nel descriptor**
 - Il descriptor v3 guadagna una sezione `evidence` che configura **tutta la lettura della sorgente**:
   protocollo/tipo, URI/sorgente, eventuali parametri non-secret.
-- Per PSD la sorgente è un **tree di file in una directory versionata nel repo del workspace**
-  (`evidence/`, come nella versione precedente).
+- Si usa **un unico repository Git registry** per tutti i workspace. Ogni workspace possiede il proprio tree
+  versionato sotto `workspace-content/<workspace_id>/evidence/`; per PSD il path canonico è
+  `workspace-content/psd/evidence/`.
+- Per `filesystem`, l'URI del descriptor è repo-relative, confinata al namespace dello stesso workspace e
+  risolta dalla stessa revisione Git del descriptor. Sono vietati path assoluti, traversal e riferimenti al
+  contenuto di un altro workspace; il controllo reale di symlink/containment durante la materializzazione
+  appartiene a P6.
 - Eventuali segreti (HTTP autenticato, S3) restano in overlay d'installazione — invariante: nessun segreto
   nel repo/descriptor.
+- P1 applica lo standard integration-first: prima persegue un goal automatico Git→registry→HTTP→render→
+  harness sotto `.artifacts/p1-integration/<run-id>/`, poi offre un walkthrough manuale separato sotto
+  `.artifacts/manual-acceptance/p1/`. Non include ancora estrazione, embedding o verifica degli artefatti
+  `artifacts/evidence` (P2+P6).
 
 ### D2 — Esecuzione: **CLI sul host in release 0; GUI in release futura**
 - **Release 0**: una **CLI installata con ThothII sul host** — sia il PC/Mac dell'utente sia il server che
@@ -268,23 +374,28 @@ documentato e verificato da smoke end-to-end.
 - La **CLI deve poter cancellare e ricreare le collection** (rebuild esplicito, con guardie di sicurezza).
 
 ### D5 — Versioning artifacts curati: **c) misto**
-- `annotations.yaml` (cura FK, cura umana) **versionata nel repo workspace** e sincronizzata ai roots
+- `annotations.yaml` (cura FK, cura umana) **versionata nel repository registry** e sincronizzata ai roots
   runtime (il registry copia il file negli snapshots → sync).
 - `physical.yaml` (derivato dall'introspezione) rigenerato localmente, non versionato.
 
-### D6 — Evidence: **a) nel repo workspace**
-- Il workspace contiene la cartella evidence versionata (tree di file); le dimensioni non sono un vincolo.
+### D6 — Evidence: **a) nell'unico repository registry, con namespace per-workspace**
+- Ogni workspace contiene il proprio tree versionato sotto
+  `workspace-content/<workspace_id>/evidence/`; le dimensioni non sono un vincolo.
+- P6 materializza il tree dalla **stessa revisione Git** del descriptor, verifica il containment reale
+  (inclusi i symlink) e lo rende disponibile al preprocessing senza usare un checkout mobile.
 - HTTP/S3 restano opzioni future per sorgenti esterne (il motore le supporta già).
 
 ### D7 — Migrazione PSD: **inclusa, con accesso al server**
-- Il piano P7 copre: riuso di physical.yaml + annotations.yaml + evidence `.md` dal repo workspace; export
+- Il piano P7 copre: riuso di physical.yaml + annotations.yaml + evidence `.md` dal repository registry; export
   dal pgvector del server PSD (accesso disponibile); re-embedding con `qwen3-embedding:0.6b`; dry-run
   documentato.
 
-### D8 — Verifica end-to-end: **confermata; remote Git libero; DWH multi-trasporto**
-- Smoke automatico su workspace sintetico (CI) + gate manuale L2 su PSD.
-- Il workspace PSD sarà **prima generato come repository ed alimentato** (descriptor + evidence +
-  annotations), **poi** usato da ThothII. Accesso al server PSD disponibile.
+### D8 — Verifica end-to-end: **integration-first + walkthrough manuale; remote Git libero; DWH multi-trasporto**
+- Ogni fase adotta lo standard della sez. 8: prima un process goal automatico da ambiente pulito, poi —
+  quando utile o richiesto — un walkthrough manuale su stato separato. P1 è il primo riferimento concreto.
+- Il livello finale del PRD resta: smoke automatico su workspace sintetico (CI) + gate manuale L2 su PSD.
+- Il namespace PSD sarà **prima alimentato nel repository registry** (descriptor + evidence + annotations
+  nello stesso flusso Git), **poi** usato da ThothII. Accesso al server PSD disponibile.
 - **Remote Git**: lo creiamo noi, nessun vincolo tecnico (consigliato GitHub via HTTPS; SSH resta
   possibile se servirà).
 - **Trasporto DWH**: PSD via **REST** (come oggi); **la configurazione deve prevedere le tre modalità** —
@@ -296,47 +407,117 @@ documentato e verificato da smoke end-to-end.
 - Default invariati (`retain_published_generations: 3`, chunk 4000 char), configurabili per-workspace via
   la sezione `evidence`/policy del descriptor (D1).
 
-## 10. Mappa dei piani (uno per punto del PRD)
+## 11. Mappa dei piani (uno per punto del PRD)
 
 Questo PRD non diventa un unico piano: **ogni decisione/requisito produce un piano separato (P1–P10)** in
 `docs/superpowers/plans/`, eseguibile in sequenza o come workstream indipendenti. Il PRD resta il
 riferimento stabile (requisiti + decisioni); ogni piano cita il punto di origine e i criteri di
-accettazione applicabili (sez. 8).
+accettazione applicabili (sez. 9) e adotta lo standard integration-first (sez. 8).
 
 | Piano | Punto PRD | Contenuto sintetico | Dipende da |
 | --- | --- | --- | --- |
-| P1 | D1 | Descriptor v3: sezione `evidence` (protocollo/tipo, URI, sorgente tree nel repo) + policy; validazione contract (backend `schema.ts`, harness `config.py`) | — |
+| P1 | D1 | Descriptor v3: sezione `evidence` (protocollo/tipo, URI repo-relative sotto `workspace-content/<id>/evidence/`) + policy e isolamento namespace; goal automatico Git→registry→HTTP→render→harness, seguito da walkthrough manuale | — |
 | P2 | D2 | **CLI di preprocessing sul host (release 0)**: comando per-workspace che esegue l'intera catena (DWH, FK, index-schema, evidence) con la config derivata da descriptor+bindings; funziona su PC/Mac utente e server DWH | P1 |
 | P3 | D3 | Vincolo fingerprint `.tht-dwh` (test: preprocess con config identica alla runtime) + **documentazione di progetto su cos'è `.tht-dwh`** | P2 |
 | P4 | D4 | Bootstrap collection: **self-heal all'ammissione** (creazione 1024/cosine + keyword-index) + **comandi CLI delete/recreate** con guardie | — |
-| P5 | D5 | `annotations.yaml` versionata nel repo workspace + sync registry → roots runtime | P1 |
-| P6 | D6 | Evidence tree nel repo workspace (path checkout → preprocess) | P1 |
+| P5 | D5 | `annotations.yaml` versionata nel repository registry + sync registry → roots runtime | P1 |
+| P6 | D6 | Materializzazione del tree `workspace-content/<id>/evidence/` dalla revisione Git fissata → preprocess; containment reale e protezione da symlink escape | P1 |
 | P7 | D7 | Migrazione PSD: riuso catalogo/annotations/evidence, **export pgvector (accesso server)**, re-embedding, dry-run | P1–P6 |
-| P8 | D8 | Verifica end-to-end: smoke CI + gate L2 su PSD (**workspace repo alimentato prima dell'uso**; remote Git a scelta) | P1–P7 |
+| P8 | D8 | Verifica end-to-end: smoke CI + gate L2 su PSD (**namespace PSD nel repository registry alimentato prima dell'uso**; remote Git a scelta) | P1–P7 |
 | P9 | D9 | GC/retention per-workspace: policy configurabili, default invariati | P1 |
 | P10 | D8/RF1.4 | Trasporti DWH operativi: rendere `ssh_tunnel` utilizzabile a runtime e nella CLI di preprocessing (oggi solo diagnostico); verifica dei tre trasporti (direct, REST, tunnel) | P1, P2 |
 
+### Standard di verifica obbligatorio del futuro piano P1
+
+P1 è il primo piano che applica integralmente la sez. 8 e deve contenere due task/gate distinti e ordinati.
+
+#### 1. Automated integration goal — complete P1 configuration process
+
+Un comando unico (nome definitivo nel piano, interfaccia indicativa
+`./scripts/p1-acceptance.sh integration --keep`) costruisce da zero:
+
+```text
+.artifacts/p1-integration/<run-id>/
+├── ownership.json
+├── remote.git/                   # remote bare locale
+├── author/                       # clone curatore + tree evidence
+├── installation/                # checkout, snapshot e stato registry
+├── runtime-data/
+├── fixture-secrets/
+├── requests/                     # payload HTTP positivi/negativi
+├── responses/
+├── rendered/
+├── exports/
+├── logs/
+├── report.json
+└── report.md
+```
+
+Il test attraversa le interfacce reali appartenenti a P1: Git reale locale, backend Fastify su una porta
+loopback temporanea, route HTTP validate/publish/pull/read/export, snapshot/docs/contract, renderer di
+produzione e `tht config check`. Verifica anche stessa revisione Git per descriptor/tree, determinismo,
+path/protocolli/secret fields invalidi, assenza di leak e cleanup confinato. Non usa frontend, Docker, DWH,
+Qdrant o Ollama perché non appartengono allo scope P1.
+
+L'esecuzione non applica retry automatici. In caso di errore l'esecutore diagnostica, aggiunge la copertura
+regressiva necessaria, corregge e rilancia l'intero scenario da una nuova root pulita. Il goal è raggiunto
+solo con exit code zero e report integralmente verde; con `--keep` le evidenze restano disponibili.
+
+#### 2. Manual acceptance gate — descriptor and rendered configuration artifacts
+
+Dopo il goal automatico verde, il piano prepara uno stato nuovo e indipendente sotto:
+
+```text
+.artifacts/manual-acceptance/p1/
+├── remote.git/
+├── author/
+├── installation/
+├── runtime-data/
+├── requests/
+├── responses/
+├── output/
+├── logs/
+└── GUIDE.md
+```
+
+Un helper esegue soltanto `prepare/serve/stop/cleanup`; `serve` avvia il backend reale sull'host, senza
+Docker e senza frontend, vincolato a `127.0.0.1:8791`. Il reviewer segue `GUIDE.md` ed esegue personalmente
+le chiamate HTTP, i comandi Git, l'export ZIP, il doppio rendering, il confronto e `tht config check`, poi
+prova i casi invalidi e decide il gate.
+
+Il gate verifica manualmente: sezione `evidence`; pubblicazione/rilettura; commit e snapshot immutabile;
+workspace docs/contract; config harness; assenza di segreti; sicurezza protocollo/path e isolamento
+cross-workspace; output deterministico. Gli artefatti restano fino alla decisione e il cleanup rimuove solo
+la root posseduta dal test.
+
+P1 **non** dichiara di aver generato o validato `artifacts/evidence`: estrazione e mirroring richiedono
+P2+P6; record Qdrant, embedding, generazioni ACTIVE e retention appartengono ai piani successivi. Dopo il
+goal automatico lo stato è `automated integration: PASS / manual acceptance: PENDING`; P1 diventa pienamente
+accettato soltanto dopo la decisione del reviewer.
+
 Ordine consigliato: **P1 → P2 → P3** (catena config/esecuzione), **P4** e **P5/P6** in parallelo dopo P1,
 poi **P7 → P8**; P9 può essere assorbito in P1 o restare autonomo; **P10** dopo P1+P2 (necessario solo se un
 workspace target richiede davvero il tunnel — per PSD non serve, usa REST).
 
-Ogni piano segue la prassi del repo: TDD, commit scoping, verifica layer (pytest/vitest/tsc/build), gate
-deployment (`test-*`), poi smoke Docker. Lo stato di ogni piano (draft / in corso / fatto) verrà tracciato
-in questa sezione man mano che i piani partiranno.
+Ogni piano segue la prassi del repo: TDD, commit scoping, verifica layer (pytest/vitest/tsc/build) e lo
+standard della sez. 8; gate deployment e smoke Docker si aggiungono quando appartengono allo scope. Lo stato
+traccia separatamente implementazione, automated integration e manual acceptance.
 
 ---
 
-## 11. Storico revisioni
+## 12. Storico revisioni
 
 | Versione | Data | Contenuto |
 | --- | --- | --- |
 | v0.1 | 2026-08-09 | Bozza da analisi dello stato attuale (gap preprocessing per-workspace) |
 | v0.2 | 2026-08-09 | Decisioni D1–D9 chiuse con il proprietario; mappa piani P1–P10; requisiti RF1–RF8 aggiornati (evidence nel descriptor, CLI sul host, self-heal collection, multi-trasporto DWH) |
 | v0.3 | 2026-08-09 | Revisione di coerenza (numerazioni, riferimenti incrociati, header di stato) — pronto per revisione del proprietario |
+| v0.4 | 2026-08-09 | D1/D6: repository registry unico, namespace `workspace-content/<id>/evidence/`, pin alla stessa revisione Git e gate manuale P1 con remote locale usa-e-getta sotto `.artifacts/` |
+| v0.5 | 2026-08-09 | Standard integration-first per P1–P10: process goal automatico completo da ambiente simulato e pulito, gestione esplicita degli interventi umani inevitabili e walkthrough manuale successivo su stato separato |
 
 ---
 
-## 12. Riferimenti
+## 13. Riferimenti
 
 - Stato attuale: `PROJECT_STATE.md` (sezioni "Internal Qdrant + Ollama semantic infrastructure", snapshot
   registry) e `AGENTS.md`.