# Riprendere il PRD di sicurezza con le skill di Pocock

**Stato:** prompt conservato per uso futuro; nessuna esecuzione programmata.
**PRD:** [Security hardening per Docker personale e server multiutente](2026-09-08-security-hardening-prd.md).

Apri una sessione nella codebase ThothII e incolla il blocco seguente. Il nome corretto della
skill è `grill-with-docs`, che combina `grilling` e `domain-modeling`. Il prompt apre la fase di
chiarimento; il passaggio a issue, worktree e implementazione resta soggetto alle conferme indicate.

```text
Riprendiamo il lavoro di sicurezza rinviato l'8 settembre 2026.

Leggi docs/plans/2026-09-08-security-hardening-prd.md. È una bozza di PRD ricavata da una
survey storica, non una spec approvata né una prova della configurazione del server remoto.
Voglio preparare interventi proporzionati per Docker su Mac/PC personale e per un server
multiutente con autenticazione built-in oppure OIDC. Il problema separato dei modelli
visibili sul server è fuori perimetro.

Usa realmente le skill di Matt Pocock: leggi le istruzioni installate, dichiarando quali
applichi. Parti da ask-matt per verificare il percorso e da grill-with-docs per il lavoro
di design; quest'ultima richiede grilling e domain-modeling. Se una skill non è disponibile,
segnalalo e concorda il fallback, senza installarla o fingere di averla eseguita.

FASE 1 — Riconferma delle evidenze, senza modificare il runtime

1. Leggi AGENTS.md, PROJECT_STATE.md, CONTEXT.md, le istruzioni docs/agents/ su dominio,
   issue tracker e label, gli ADR pertinenti e il PRD. Controlla HEAD, stato del worktree
   e differenze dalla baseline della survey. Preserva tutte le modifiche preesistenti.
2. Riconferma i rilievi SEC-01…SEC-12 nel codice corrente. Separa fatti verificati,
   ipotesi, rischi condizionati al profilo e problemi già risolti. Non trattare i vecchi
   conteggi delle dipendenze come una scansione aggiornata.
3. Usa controlli locali read-only e dati sintetici. Per un difetto da riprodurre, usa
   diagnosing-bugs con un segnale ripetibile sul comportamento effettivo; una diagnosi
   non autorizza ancora il fix. Confronta fatti di librerie e advisory con fonti primarie
   correnti quando necessario, senza inviare codice privato o segreti ai servizi di ricerca.
4. Non accedere o intervenire su server, IdP, DWH o provider reali senza aver concordato
   target e operazioni. Non mostrare API key, cookie, password o campioni di dati reali.

Esito della fase: una matrice aggiornata che conserva gli ID dei rilievi, con evidenza,
profilo interessato e stato. Un fatto ancora non verificabile resta esplicitamente aperto.

FASE 2 — grill-with-docs, con me presente

5. Costruisci l'albero delle decisioni. Parti da profili di deploy, fiducia fra utenti e
   condivisione dei dati; poi affronta isolamento di Pi, policy dei valori sensibili,
   revoca, retention e limiti seguendo le dipendenze effettive.
6. A ogni round presenta soltanto le domande attualmente sbloccate, numerate, con la tua
   raccomandazione e i trade-off. Attendi le mie risposte prima di assumere le decisioni
   successive. Cerca autonomamente i fatti ricavabili dal repository; usa agenti di
   ricerca mirati quando previsto dalla skill, senza delegare a loro le mie decisioni.
7. Aggiorna il PRD distinguendo proposte e decisioni confermate. Aggiorna CONTEXT.md solo
   per termini realmente risolti. Proponi ADR soltanto per scelte difficili da invertire,
   sorprendenti senza contesto e fondate su alternative reali: basta il formato minimo.
8. Concorda requisiti, priorità, rischi accettati e criteri misurabili, inclusi i tempi
   di revoca e i limiti di risorse. Conferma con me i confini pubblici dei test prima
   di scriverli. Mantieni espliciti i gate manuali già presenti in PROJECT_STATE.md.

Esito della fase: nessuna decisione bloccante lasciata implicitamente all'agente;
riepilogo e mia conferma della comprensione condivisa. Fino a quella conferma rimani
su analisi e documentazione: nessun cambiamento applicativo o di deployment.

FASE 3 — Spec e ticket, soltanto dopo mia conferma

9. Usa to-spec per sintetizzare le decisioni già prese, senza riaprire arbitrariamente
   l'intervista. Chiedimi conferma della pubblicazione prima di creare la spec nel
   tracker canonico Gitea indicato in docs/agents/issue-tracker.md, non nel mirror GitHub.
   Collega la spec canonica dal PRD e rendi chiaro quale documento è la fonte aggiornata.
10. Usa to-tickets per proporre fette verticali verificabili autonomamente, dimensionate
    per un contesto fresco. Collega ogni ticket ai requisiti e ai rilievi pertinenti,
    indica i veri blocker e includi criteri positivi e negativi. Fai approvare granularità
    e dipendenze prima di pubblicare. Solo i ticket approvati e completi ricevono
    ready-for-agent; non rimetterli in triage e non chiudere automaticamente la spec padre.
11. Se una decisione richiede una prova eseguibile, proponi un prototype limitato a quella
    domanda prima di fissare la spec. Usa wayfinder solo se il lavoro risulta realmente
    troppo ampio e incerto per essere chiarito con grill-with-docs.

Esito della fase: spec approvata e ticket autosufficienti con dipendenze risolte o esplicite.
Chiedimi se autorizzo il primo ticket: l'approvazione del design non avvia da sola il codice.

FASE 4 — Implementazione futura autorizzata

12. Prima di modificare codice, concorda e crea un worktree dedicato, verificando percorso,
    branch e commit base. Non riusare una directory occupata, non alterare il worktree
    originario e non copiare automaticamente segreti o dati operativi. Assicurati che
    PRD e prompt siano disponibili nel worktree attraverso un passaggio esplicito.
13. Esegui implement su un ticket sbloccato per volta, in un contesto fresco. Segui tdd
    ai confini concordati: un test rosso sul comportamento, implementazione minima,
    test verde. Esegui typecheck e test mirati durante il lavoro e le suite pertinenti
    al termine; usa fixture locali per IdP, DWH e provider.
14. Esegui code-review sui due assi Standards e Spec, usando i due agenti previsti dalla
    skill e una base Git fissata. Assicurati che il diff esaminato includa tutto il lavoro
    del ticket, anche se ancora non committato; un diff vuoto non è una review superata.
    Risolvi i rilievi e verifica di nuovo. Commit soltanto del lavoro pertinente nel
    worktree autorizzato; push, merge e deploy richiedono un'autorizzazione distinta.
15. Consegna evidenze dei test, istruzioni di adozione e rollback, gate manuali pendenti
    e rischi residui. Non dichiarare chiuso il PRD intero se è concluso soltanto un ticket
    o se resta un'accettazione dell'owner.

Inizia dalla Fase 1, poi proponimi il primo round di grill-with-docs.
```