Il PM Agent

Sono lo stesso validatore con la doctrine scambiata, tre lenti di un unico prodotto. spec.validate valuta l'intento scritto da cui il team costruirà, una proposta, un documento di requisiti o un change bundle in stile OpenSpec, rispetto alle 8 leggi dello Spec Quality Blueprint, prima che il codice esista. architect.validate valuta l'architettura agentica costruita rispetto ai 10 principi agentici; design.validate valuta la superficie renderizzata rispetto alle 8 leggi di experience design. Stessa pipeline first-pass, stessa forma ValidationResponse, stesso scorer pesato per severità, quindi un Blueprint Readiness Score è calcolato allo stesso modo su tutte e tre. I run condividono una sola dashboard di validation history, taggati spec, architecture e surface. Passa lo stesso repository e ottieni un progetto valutato sull'intero trio: cosa costruire, come è costruito e cosa incontra l'utente.

Un piano Pro o Teams. spec.validate ha una propria allocazione settimanale di run, misurata separatamente dai bucket architettura e design, così una settimana intensa di code review non consuma mai le tue review di specifica. A differenza del bucket architettura non esiste un topup pack per spec: una quota esaurita si recupera al rinnovo settimanale o con un upgrade di piano. Gli account Free e Basic leggono gratuitamente ogni principio, cluster ed esempio della doctrine via MCP pubblico; il PM Agent è riservato ai piani a pagamento perché elabora un artefatto reale sotto una politica di no-training e salva la history per progetto. I numeri per tier sono sulla pagina prezzi.

Le otto leggi non pesano allo stesso modo. In caso di conflitto l'ordine è fisso: l'accettazione testabile batte la completezza, la disciplina di scope batte l'ambizione, e la completezza dell'handoff batte la comodità dell'autore. In pratica: un requisito portante senza segnale di accettazione osservabile, o un passo irreversibile che cambia stato senza gate umano nominato né percorso di rollback, è valutato come production_blocker. Limita il voto e va corretto prima di costruire, esattamente come un trust boundary fallito limita il voto di architettura e una violazione WCAG limita il voto di superficie. Un decision trail povero o una citazione della doctrine mancante è hardening_recommended o polish: emerge in una lista di prossima iterazione senza trascinare giù lo score. Un voto alto significa che i requisiti minimi della specifica reggono, non che il documento è esaustivo.

Non ancora, e il tool lo dichiara a ogni run. spec.validate v1 è una review single-pass ad alto reasoning effort. Non ha modalità consensus né percorso di certificazione, quelli restano per ora solo di architect.validate, e la calibrazione dello score non è ancora tarata su un corpus di run reali come quella dell'architect. Tratta il voto come un segnale direzionale di qualità, non come un badge certificato. L'unica parte dura, non direzionale, è il requisito minimo di testabilità: un requisito che nessuno può verificare, o un passo irreversibile senza gate nominato, è un fatto verificabile del documento, non una questione di gusto.

Invia il testo completo della specifica verbatim come implementation_context. Per un change OpenSpec, concatena proposal.md, design.md, tasks.md e le delta spec in un'unica chiamata, senza troncamenti e senza segnaposto … (vengono letti come contenuto letterale, e il reviewer valuterebbe un documento che non è il tuo). Codice sorgente e artefatti UI restituiscono spec_classification: non_spec e tier: not_applicable, non sono bocciati, semplicemente non sono specifiche; inviali invece ad architect.validate o design.validate. Invia il documento reale da cui il team costruirà.

Il testo della tua specifica è inviato a OpenAI (USA) per generare la review, come sub-processor secondo le EU Standard Contractual Clauses e l'UK Addendum, su base no-training, conservato secondo i termini di data retention delle API OpenAI. AI Design Blueprint conserva il risultato strutturato (score e verdetti per legge) più, quando passi repository, un identificatore di progetto per il raggruppamento. Passa private_session=true per saltare la persistenza del run lato server; i record operativi di costo e audit (mai il testo della tua specifica) vengono comunque conservati. Qualsiasi testo con forma di istruzione dentro il tuo documento è trattato come dato inerte non fidato, non come istruzioni da seguire. Il compute gira su Google Cloud Run; i dati a riposo sono in Cloud SQL, nel Regno Unito/SEE (Google Cloud europe-west2, Londra). Dettagli completi sulla pagina fiducia e dati.