docs: align P2-P6 planning artifacts with the P1.1 registry contract

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

@@ -9,6 +9,16 @@ revisione e conferma del proprietario
 
 ---
 
+> **Aggiornamento P1.1 (2026-08-11):** il layout del repository registry descritto nelle sezioni
+> attive di questo PRD segue il contratto P1.1 accettato: catalogo di root `thoth-workspaces.yaml`,
+> descriptor `<id>/workspace.yaml`, evidence embedded `<id>/evidence/`, annotazioni FK curate
+> `<id>/schema/annotations.yaml` (P5), docs generate `workspace-docs/<id>/`. I vecchi percorsi
+> piatti (`workspaces/<id>.yaml`, `workspace-content/<id>/evidence/`) sono superseded; le uniche
+> occorrenze rimaste sono storiche (changelog/revisioni). Vedi
+> `docs/superpowers/plans/2026-08-11-p2-p6-adaptation-to-p1-1-registry.md`.
+
+---
+
 ## 1. Contesto
 
 ThothII è passato da un indice semantico **pgvector sul server PSD** (descrizioni di tabelle/colonne,
@@ -103,8 +113,8 @@ documentato e verificato da smoke end-to-end.
 ## 5. Scenario target (end-to-end)
 
 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.
+   `<id>/workspace.yaml` (schema-v3: DWH, collection, LLM policy) insieme al tree curato
+   `<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) +
@@ -138,7 +148,7 @@ documentato e verificato da smoke end-to-end.
   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
+  `<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)
@@ -172,8 +182,8 @@ 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` 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
+  `psd/evidence/`; in generale ogni workspace usa
+  `<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,
@@ -339,8 +349,8 @@ Ogni piano tecnico riporta, adattandoli al proprio scope:
 - Il descriptor v3 guadagna una sezione `evidence` che configura **tutta la lettura della sorgente**:
   protocollo/tipo, URI/sorgente, eventuali parametri non-secret.
 - 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/`.
+  versionato sotto `<workspace_id>/evidence/`; per PSD il path canonico è
+  `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
@@ -380,7 +390,7 @@ Ogni piano tecnico riporta, adattandoli al proprio scope:
 
 ### 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.
+  `<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à).
@@ -416,12 +426,12 @@ 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 repo-relative sotto `workspace-content/<id>/evidence/`) + policy e isolamento namespace; goal automatico Git→registry→HTTP→render→harness, seguito da walkthrough manuale | — |
+| P1 | D1 | Descriptor v3: sezione `evidence` (protocollo/tipo, URI repo-relative sotto `<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 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 |
+| P6 | D6 | Materializzazione del tree `<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 (**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 |
@@ -512,7 +522,7 @@ traccia separatamente implementazione, automated integration e manual acceptance
 | 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.4 | 2026-08-09 | D1/D6: repository registry unico, namespace `workspace-content/<id>/evidence/` *(percorso storico P1, superseded da P1.1)*, 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 |
 
 ---