# PENGO-E002 — Nota di revisione v1 Revisione esterna del video `PENGO-E002-round1-complete-v2.mp4`, scritta il 6 ottobre 2026 guardando solo il video: nessun log, manifest o nastro. I numeri sono letti campionando il video due volte al secondo. Rispondi punto per punto con gli stessi ID. Dove un numero qui sotto differisce dai log, vale il log e la differenza va riportata. Questa nota non modifica E002 né i suoi artefatti congelati e non riguarda Pleiads (E007 chiuso, E008 congelato). Il video v2 resta com'è come prova: le correzioni vanno in un v3. ## A — Letto dal video, da confermare sui log - A1. Act 1 completato senza perdere vite. Schermata bonus: GAME TIME 23 SEC. - A2. Score 1.850 a fine round, 3.850 dopo il bonus tempo di 2.000. - A3. 1.850 = 400 × 1 (Sno-Bee schiacciato) + 500 × 2 (uova) + 100 × 3 (storditi al muro) + 30 × 5 (blocchi). - A4. Nodi: 3.099 nel pilot v1 (ultimo valore, frame ≈ 1.682). Poi il contatore riparte da 63 (frame ≈ 1.714) e arriva a 1.080 (frame ≈ 2.046). Totale 4.179. - A5. Plan latency della seconda fase: tra 8,20 e 10,02 s per decisione; negli ultimi tre valori visibili 16,36 / 6,05 / 1,94 s. - A6. Input di gioco dal frame ≈ 700 al ≈ 2.070, poi 600 frame neutri. ## Q — Domande, a cui rispondere prima di ogni nuova search - Q1. Che cos'è un «oracle node»? Motore usato nella search: prefix replay da processo nuovo, restore nativo o altro? Quanti worker? - Q2. «No loads» vale anche per la search o solo per i replay? - Q3. I due replay di verifica erano a velocità reale (throttle 100%)? - Q4. Perché il contatore riparte al frame ≈ 1.700? Il nastro è la concatenazione di due search? La seconda è stata lanciata dopo aver visto l'esito della prima? Con quali parametri diversi? - Q5. Quanti tentativi di search sono stati fatti per E002 in tutto, compresi quelli scartati, e con quale esito ciascuno? - Q6. Costo di E002: frame emulati (FE) e tempo di orologio della search che ha prodotto il nastro (pilot v1 + seconda fase). A parte, quelli dei tentativi scartati. - Q7. La plan latency cresce con l'indice di frame? Tabella latenza–frame per tutte le decisioni loggate. - Q8. Che cosa significa «Single board»? - Q9. Il labirinto cambia se START è premuto k frame dopo il frame canonico? Misura per k = 0…63: hash della tilemap a labirinto completato. Riporta quanti hash distinti. ## V — Etichette del video v3 - V1. Sotto il titolo, riga fissa: `TRAJECTORY SEARCH / 0 MODEL CALLS / NOT AN AUTONOMOUS AGENT` Se le chiamate a modelli non sono 0, scrivi il numero vero. - V2. Un solo contatore di nodi, cumulativo su tutta la search (4.179 a fine round, se A4 è confermato). Al posto di «oracle nodes», il nome del motore dato in Q1. - V3. Riga di validità con la regola del laboratorio: `FROM RESET / REAL TIME / NO SAVE-STATE LOAD / NO RAM WRITE / NO CHEAT / EXACT REPLAY` Ogni voce si scrive solo se è vera per il replay di verifica. Se i replay non erano a velocità reale, rieseguili a velocità reale prima di scrivere REAL TIME. - V4. Riga a parte per la search: motore e uso di load, come da Q1 e Q2. - V5. Costo a schermo: `Planning: for 23 s of play` - V6. Set: nome breve e descrizione esatti del set usato, come li dà `-listfull` su MAME 0.289 (dal video sembra `pengoja`). Togli «Single board», salvo che Stefano confermi che cosa dichiara. - V7. LIVES: il pannello dice 3, l'HUD mostra 2 icone. Scrivi `LIVES 3 (2 in reserve)` oppure usa lo stesso conteggio dell'HUD. ## F — Fidelity dei save-state su Pengo Motivo: se il costo per nodo cresce con il prefisso (Q7), i round successivi diventano troppo cari in prefix replay. - F0. Si esegue solo se Q1 = prefix replay. Se la search usa già il restore nativo, non eseguire F: riporta con quale evidenza di fidelity è stato ammesso. - F1. Prima di eseguirla, congela una pre-registrazione Pengo che importa per riferimento (percorso + SHA-256) le regole G2.A–G2.E, e la batteria di fidelity a cui rimandano, da `data/e007/preregistration-v1/decision-table.md` (SHA-256 e47975a19e46c75d4f4f8c347d99069214ed231be154da7349f4213bbdfd41dd), cambiando solo gioco, set e nastri. - F2. Dove una regola cita una grandezza che su Pengo non esiste, non adattarla: elenca il punto e fermati lì. - F3. L'esito dice soltanto se il restore nativo è ammissibile nella search. La verifica di ogni risultato resta da reset, processo nuovo, senza load. - F4. Il restore nativo entra nella search solo con l'approvazione esplicita di Stefano dopo l'esito. ## N — Esperimenti successivi Assegna gli ID secondo il registro esistente. Ognuno si pre-registra e si congela prima di partire. Un esito nullo chiude solo quell'esperimento. Unità di costo: C = FE della search che ha prodotto il nastro di E002 (Q6). Se gli FE non sono ricostruibili usa il tempo di orologio. Se manca anche quello, fermati e riferisci. ### N1 — Act 1 sotto i 20 secondi - Successo: schermata bonus con GAME TIME ≤ 19 SEC. (bonus 5.000), nessuna vita persa, verifica come E002. - Parziale: GAME TIME 20–22, nessuna vita persa. - Nullo: nessun nastro sotto 23 entro il budget. - Budget: 10 × C. Parametri del planner liberi, ma congelati prima dell'avvio. ### N2 — Robustezza su 20 partenze - Partenze: i primi 20 valori di k ≥ 0 (Q9) il cui labirinto ha hash diverso da tutti i precedenti. Se entro k = 63 sono meno di 20, fermati e riferisci. - Planner e parametri: quelli della seconda fase di E002, congelati. Nessuna modifica tra una partenza e l'altra. Se non sono applicabili dall'inizio del round, fermati e riferisci. - Budget per partenza: 2 × C. Una partenza che esaurisce il budget è fallita. - Successo di una partenza: Act 1 completato senza perdere vite, verificato come E002. - Esito: 18–20 successi = robusto; 14–17 = parziale; 0–13 = non robusto. - Report: una riga per partenza (k, hash, esito, GAME TIME, score, FE, tempo), fallimenti compresi. ### Non avviare ora - Allineamento dei diamanti e ottimizzazione dello score: pre-registrazione a parte. - Più round: solo dopo l'esito della sezione F. ## R — Regole - R1. Set canonico: quello usato per E002, salvo indicazione diversa di Stefano. Nastri e indirizzi RAM valgono solo per il set su cui sono nati: se il set cambia, E002 e i risultati successivi si rieseguono, non si adattano. - R2. Nel repository e nei materiali pubblici: nome del set, versione di MAME e hash. Mai ROM, BIOS, CHD o asset del gioco. - R3. In ogni materiale pubblico E002 è descritto come trajectory search su un solo round e una sola partenza.