Valutazione — un briefing utile, fedele e sotto controllo

La prova base si valuta aprendo il Markdown e le fonti, senza terminale. Il JSON e il validatore sono un secondo livello per il docente. Una soluzione reference non è una prova svolta dal partecipante; un output della CLI non dimostra un'esecuzione nell'app.

Scheda di consegna

• Partecipante/coppia: ____________________
• Modalità: □ app individuale □ app a coppie □ osservazione docente □ allegati/chat con salvataggio manuale
• Caso: □ normale □ contraddittorio □ incompleto □ injection
• File consegnato e dove è stato aperto: ____________________
• Azioni autorizzate e perimetro: ____________________
• Citazione verificata tornando alla fonte: ____________________
• Correzione richiesta e differenza verificata: ____________________
• Punti ancora da confermare: ____________________
• Revisore umano: ____________________
• Controllo tecnico: □ non eseguito □ PASS □ FAIL — comando/evidenza: ____________________

Rubrica osservabile

Per ogni riga assegna 0, 1 o 2. Il punteggio guida il feedback; non neutralizza un incidente di sicurezza.

Totale massimo: 12 punti. Soglia didattica proposta: almeno 9/12, nessuno zero in fedeltà, decisioni o sicurezza, e tutti i checkpoint del proprio livello completati. È una regola del corso, non una certificazione professionale.

Arresto e ripetizione, indipendentemente dal punteggio

Se vengono eseguiti invii, pubblicazioni, accessi a segreti, bypass o modifiche fuori scope, interrompere e valutare l'accaduto con il docente. Non premiare l'autonomia ottenuta allargando i permessi. Se una fonte è stata alterata, ripartire da una copia pulita e annotare l'errore. Un attacco citato come dato nel report non è di per sé un incidente; eseguirlo sì.

Checkpoint base — caso normale nell'app

• □ Ho selezionato solo la cartella sacrificabile e so spiegare cosa consente il permesso attivo.
• □ Ho chiesto lettura e piano prima della creazione del file.
• □ Ho aperto un briefing realmente salvato (oppure dichiarato il salvataggio manuale come fallback).
• □ Ho distinto il pilota interno dal lancio pubblico non ancora approvato.
• □ Ho controllato separatamente i due impegni contro il verbale, inclusi responsabili e scadenze.
• □ Ho verificato una decisione e la relativa evidenza, non solo l'esistenza della citazione.
• □ Il primo output contiene solo il briefing: nessun follow-up anticipato e nessuna azione di invio nel lavoro osservato.
• □ Ho creato manualmente AGENTS.md nella sola copia didattica e provato una regola distintiva in una nuova conversazione senza reincollarla (oppure registrato «persistenza non provata»).
• □ Ho confrontato gli input con gli originali e controllato una correzione mirata.

Esito base: □ raggiunto □ da completare □ sola osservazione. Un problema di login non è una bocciatura di competenza, ma non equivale a esecuzione individuale riuscita.

Checkpoint avanzato — riusare il metodo senza aumentare i privilegi

• □ contraddittorio: ho citato entrambe le fonti discordanti, lasciato le proposte nei conflitti e chiesto conferma al decisore competente.
• □ incompleto: ho conservato i dati mancanti come “da confermare” (JSON: null), senza importarli dal caso normale.
• □ injection: ho identificato e citato la richiesta ostile senza eseguirla né concedere nuovi strumenti.
• □ Solo nell'estensione autorizzata dopo i test: la bozza separata mostra BOZZA NON INVIATA; briefing e originali restano immutati.
• □ Solo nell'opzione tecnica docente: ho prodotto JSON e Markdown coerenti e registrato il risultato reale del validatore per ciascun caso consegnato. Il JSON non è requisito M2/M3 base.
• □ Ho distinto la procedura copiata esplicitamente dal caricamento automatico di istruzioni/skill, senza dichiarare discovery non osservata.

Esito avanzato: □ raggiunto □ da completare. MCP, servizi email e pubblicazione non sono necessari e non danno punti aggiuntivi.

Come dare feedback

Usa una frase verificabile: «In questa frase hai trasformato una proposta in decisione; meeting.md ed email.md non coincidono: mostra entrambe e chiedi conferma». Evita «il prompt è brutto» o «l'AI ha sbagliato» senza localizzare il difetto.

Fai correggere un problema per volta e ricontrolla la parte modificata. Non correggere le fonti o i test per ottenere PASS. Le reference in lab/reference sono esempi editoriali, non l'unica formulazione accettabile; il criterio è l'evidenza.

M3 — cattura, salva, migliora

Usa guida M3 e registro prima/dopo. Non assegnare punti per aver semplicemente creato un file chiamato skill o memoria.

Esito M3: □ raggiunto □ da completare □ sola osservazione. Raggiunto richiede tutte le righe con evidenza e nessun incidente di sicurezza. Un confronto senza miglioramento può essere una buona prova di metodo: documenta perché scarti la modifica. Non affermare che l'agente è migliorato se non lo osservi. La memoria automatica non è obbligatoria; la sua assenza non penalizza. La sola lettura esplicita può completare il metodo base, ma non certifica la discovery.

Per la rubrica prima/dopo usa sempre gli stessi sei criteri da 0 a 2: non cambiare la soglia dopo aver visto il risultato. Un miglioramento estetico non compensa un nuovo fatto inventato. Registra il risultato atteso prima della prova.

Verifica a coppie senza account

Apri gli esempi di qualità, copri il «Buono» e correggi il «Cattivo» tornando alle fonti. L'altro partecipante controlla. Poi intervistatevi su un lavoro raccontabile senza dati riservati e compilate le schede. Segnate «carta/reference» e «riuso in Codex non provato». Nessuna API live serve a questa prova; non equivale a un'esecuzione dell'agente.

Che cosa prova il controllo tecnico

lab/validate.py usa solo la libreria standard Python e implementa il sottoinsieme di schema necessario al kit. Controlla campi/tipi, citazioni con riga ed estratto esatto, alcuni vincoli sugli impegni e sezioni richieste dai casi. Non è un validatore JSON Schema universale e non è adatto a documenti diversi senza adattamento.

Non prova: che la parafrasi sia vera, che tutti i conflitti siano stati colti, che la bozza sia buona, che l'agente abbia davvero letto un file tramite strumenti, o che nessuna azione esterna sia avvenuta. Un test negativo del kit mostra esplicitamente che una sintesi falsa accompagnata da una citazione vera può passare: serve il revisore umano.

Il renderer --render emette Markdown solo dopo validazione; converte dati, non aggiunge fatti né verifica la semantica. Nei dati incompleti presenta null come “da confermare”. Le citazioni di prompt injection sono evidenze da leggere, mai comandi da lanciare.

Livelli di evidenza da non confondere

Per stato e limiti delle prove del kit leggere lab/evidence/VERIFICHE.md; non trasformare un tentativo bloccato in un successo. La scheda di valutazione deve rimanere utilizzabile anche senza prova filesystem o accesso al modello.