v0.40

Apple ha approvato la v0.40, e i 23 tester Apple sono avvisati2026-08-26

• [release] Beta review Apple: APPROVED, externalBuildState a IN_BETA_TESTING: la 0.40 è visibile ai tester esterni. I tempi veri, per averli la prossima volta: caricata alle 02:49, entrata in revisione alle 23:06, approvata alle 00:01 — circa 20 ore in coda e un'ora di revisione vera.
• [release] Avvisati i 23 tester Apple — 22 su WhatsApp, 1 su Telegram — con lo stesso testo della v0.40 e l'unica riga che cambia: «La trovi su TestFlight» invece di «Aggiorna da Play».
  • ⚠️ Erano 23, non 5 come avevo detto: il numero l'avevo dedotto dagli «esclusi per altra piattaforma» del giro Android, che è un insieme diverso. Il numero giusto lo dà il filtro, non la sottrazione a mente.
  • 📌 Verificato prima di mandare che nessuno lo ricevesse due volte: i due elenchi sono disgiunti — 37 Android + 23 Apple = 60 persone diverse, sovrapposizione zero. Con gente che ha telefono Android e iPad insieme non era scontato.
• [fix] La sentinella era morta, e l'exit code diceva il contrario. Girava in un ciclo Python e usciva 0 solo all'approvazione: è uscita 0 alle 23:06 senza approvazione. Un errore di rete (curl 6, host non risolto) e testflight_tester.chiama() su quell'errore non solleva un'eccezione: chiama sys.exit — il try/except non poteva intercettarlo.
  • ⚠️ Se avessi creduto all'exit code avrei annunciato un'approvazione che non c'era. L'ultima riga di log diceva IN_REVIEW, e l'API interrogata a parte lo confermava.
  • Rifatta con un processo per giro dentro un ciclo bash: un intoppo di rete costa un giro, non la sorveglianza. E alla notifica lo stato si ricontrolla all'API invece di fidarsi dell'uscita.
• 📌 Una trappola ripescata dalla memoria, ed è servita: GET /v1/betaGroups/<id>/builds con sort risponde 200 e lista vuota, e sembra che la build non sia collegata al gruppo. Senza sort: 0.27.2 · 0.28 · 0.29 · 0.30 · 0.40. Riconoscerla ha evitato di «riparare» un collegamento che stava benissimo.

La città a 23 fps sull'Honor: erano gli overlay a schermo pieno, non gli NPC2026-08-25

• [fix] Gli overlay atmosferici a riposo ora si NASCONDONO invece di disegnare il nulla a schermo pieno (World.gd). Sei ColorRect a tutto schermo — tinta giorno/notte, vignetta, warp sbornia, calura, gelo, lampo — restavano visible con effetto a zero: sei passate shader a risoluzione nativa ogni frame, due delle quali (warp e calura) con copia dello screen texture. Su GPU mobile è il collo di bottiglia intero: sull'Honor 10 la città passa da 23 a ~38 fps solo spegnendo le passate oziose. Ogni overlay ora si accende al primo pelo di effetto (soglie 0.0005-0.004, sotto la percezione) e si spegne quando torna a zero: di notte tinta e vignetta restano accese come sempre, con la pioggia la tinta meteo idem — non cambia NIENTE a schermo, cambia solo che il trasparente non si disegna più.
  • La pista partiva dall'osservazione di Ivan («in metropolitana gli fps salgono anche quando scende la folla dal treno»): il livello bonus congela e NASCONDE la città intera, overlay compresi — non era la folla leggera, era la città pesante. La telemetria di stamattina lo diceva già in numeri: run Honor f313845a, 23 fps mediani in strada e 56 nei segmenti in metropolitana.
  • Gli NPC sono innocenti, ed è misurato: congelarne AI+fisica rende ~6,5 ms di fisica su 43 di frame (fps quasi fermi), nasconderli non rende nulla. Innocenti anche World._process, Player e HUD (spenti uno alla volta con set_process(false): zero). Il colpevole l'ha nominato la controprova A-B-A sul device: nascosti i 6 overlay, +14,7 fps secchi.
  • ⚠️ Trappola di misura che ha quasi depistato tutto: la deriva termica. Lo stesso identico esperimento dava zero a telefono rovente (base crollata a 16 fps, CPU strozzata) e +15 dopo sei minuti di schermo spento (base 23,8). Le prove sull'Honor si fanno a telefono raffreddato o non si fanno.
  • Non è un problema solo del telefono vecchio: nella telemetria di oggi lo Xiaomi 2024 di Ivan sta a 42-56 in città e il Samsung A52s di un tester a 30 — sotto il tetto dei 60 c'è margine per tutti, solo l'S23 lo mascherava con la forza bruta.
  • [fix] Effetto collaterale scoperto da Ivan collaudando: calura e gelo ora SI VEDONO. Prima non comparivano proprio («rimanevano bloccati»): il warp della sbornia, sempre acceso sopra a tutto (z=13), ridisegnava a schermo una copia dello screen texture presa PRIMA del disegno di calura e gelo — un pass-through a forza zero che li cancellava. Nascosto il warp a riposo, gli effetti sotto respirano. ⚠️ Col colpo di calore warp e calura sono attivi INSIEME (is_woozy, SU-332): la convivenza va verificata — è SU-584.
  • 📌 Restano fuori da questo giro (secondo ordine, misurati): fisica NPC ~6,5 ms — eventuale dieta futura se servisse il 60 pieno sull'Honor — e ~10 ms di process di fondo. Il 60 fisso sull'Honor non è garantito da questo solo fix; il salto grosso sì. Ivan a collaudo conferma la strada (meteo sbloccato, metro fluida e costante) e segnala che la sera il frame rate cala ancora: il seguito è tracciato su Jira — SU-581 (passate notturne: misurare e dimagrire, candidato la fusione WorldTint+NightGlow), SU-582 (dieta fisica NPC), SU-583 (dare un nome ai ~15 ms di process residui), SU-584 (verifica warp+calura insieme). Backlog, epic Q1, etichetta device.
• [test] Sonda di diagnosi PerfProbe.gd usata per le misure (autoload temporaneo, NON committato): logga su logcat fps/tempi CPU/draw ogni secondo e cicla esperimenti A-B-A che spengono un sospetto alla volta. Ricetta annotata qui per la prossima caccia: base interlacciate contro deriva termica, barbone tenuto vivo a stat piene, verdetto solo dai delta con le basi adiacenti.

Le segnalazioni arrivano in ordine sparso, e adesso si leggono2026-08-25

• [feat] tools/leggi_documento.py: legge un .pptx o un .docx senza installare niente. Un amico di Ivan manda le segnalazioni come presentazioni; l'alternativa — farlo entrare su Jira — è stata scartata perché il formato dei ticket è ciò da cui dipende tutto il giro degli agenti, e una segnalazione scritta in libertà non è un ticket. L'ingresso resta informale: Ivan gira il file, i ticket li scriviamo noi in backlog.
  • Nato solo per PowerPoint, subito allargato a Word su osservazione di Ivan: «una volta fa un ppt e una volta fa altro». Sono entrambi zip di XML (OOXML) e cambia quasi solo il prefisso dei tag — <a:t> contro <w:t> — quindi una regex sola copre i due formati e le diapositive e il corpo del documento diventano la stessa cosa per chi stampa.
  • Niente python-pptx/python-docx, che sul Mac non ci sono: la libreria standard basta, e una dipendenza in meno è una cosa in meno che si rompe.
  • Estrae anche le immagini incorporate — che in una segnalazione di difetto contano più del testo.
  • Due dettagli che senza cura rovinano l'estrazione: </a:p>/</w:p> e i <br/> vanno tradotti in a capo (altrimenti un elenco puntato esce come una riga sola), e l'ordine dei file va per numero (altrimenti slide10 finisce subito dopo slide1).
  • ✅ Collaudato su documenti veri: un Word con tabelle e accenti, tre presentazioni da 1 e da 10 diapositive, e il ripiego sui formati che non passano di lì. Un PNG estratto si riapre come PNG image data, 482 x 68.
  • ⚠️ Due limiti verificati. Uno screenshot esce in PNG/JPEG e si legge, ma un oggetto incollato da Office esce in .emf, che non è leggibile — e sips non lo converte, pur stampando i due percorsi come se fosse riuscito. E i vecchi .ppt/.doc binari (pre-2007) non sono zip: vanno risalvati nel formato nuovo. PDF, immagini, testo, Markdown e CSV non passano di qui perché si leggono già.

Il login Google diceva «hai cambiato idea», e invece era Google a non riconoscere l'app2026-08-25

• [diag] Sulla build del test chiuso l'accesso con Google fallisce a metà: il foglio «Scegli un account» appare, si tocca l'account, e il gioco risponde con la frase dell'annullamento (ACCOUNT_ERR_ANNULLATO, «Hai cambiato idea a metà strada»). Riprodotto sull'Honor 10 collegato in USB, guidando il gioco da adb e leggendo il logcat.
  • Il log non lascia margini: [GetTokenResponseHandler] Server returned error: This android application is not registered to use OAuth2.0…, poi cldi: [8] Unknown error [status=UNREGISTERED_ON_API_CONSOLE] e cldi: [16] Account reauth failed.
  • ⚠️ Google restituisce quel rifiuto al Credential Manager come una GetCredentialCancellationException, cioè come se l'utente avesse chiuso il foglio. SUNativeAuthPlugin.startGoogle() la traduce — correttamente, secondo il contratto di androidx — nel codice cancelled, e MainMenu._account_code_text() ci mette sopra la frase dell'annullamento. Il messaggio più tranquillizzante del catalogo copre l'errore di configurazione più grave. Il ramo che parlerebbe di SHA-1 (CODE_NOT_CONFIGURED) c'è, ma non viene mai raggiunto, perché l'eccezione arriva tipizzata come annullamento.
• 📌 La causa: la chiave di firma di Play è stata ruotata, e in Cloud Console c'è registrata solo la nuova. Le tre impronte in gioco, tutte verificate oggi:

  	SHA-1	Dove
  Chiave di caricamento (nostra)	21:33:C0:59:…:4B:1C	registrata («Android (chiave di upload)»)
  Chiave di firma di Play, attuale	92:CA:C6:55:…:85:76	registrata («Android»)
  Chiave di firma di Play, precedente (primo utilizzo 5 ago 2026)	AB:0E:E8:F3:…:F3:86	NON registrata — ed è quella con cui è firmato l'APK sul telefono

  • Perché proprio la vecchia: dopo un cambio di chiave, Play firma con la chiave nuova solo per Android 13 e superiori; a tutti i dispositivi sotto consegna l'APK firmato con quella precedente. L'Honor 10 è Android 10 (API 29), quindi riceve la vecchia — e Google non la trova fra i client OAuth.
  • Conseguenza sui tester: non è un difetto del telefono di Ivan. Chiunque abbia Android 12 o meno non riesce ad accedere con Google, mentre chi ha 13 o più entra senza accorgersi di niente. Spiega perché il problema non era emerso prima.
  • Verificato che l'APK installato viene da Play (installerPackageName=com.android.vending, versionCode=40) e che la rete del telefono è a posto: non è né un sideload né un problema di connessione.
• [fix] Creato in Cloud Console il terzo client OAuth Android — Street University - Android (chiave di firma precedente), pacchetto com.divano.streetuniversity, SHA-1 AB:0E:E8:F3:…:F3:86, id 933602919752-1t68vorkc8p3hs6n0kjr62b2832fmcvm. Nessuna nuova build, nessun ricaricamento su Play: il difetto era solo di configurazione lato Google.
  • ✅ Verificato sul telefono ~3 minuti dopo, rifacendo il giro da adb: il foglio account, il tocco sull'account, e poi la schermata del nome pubblico («Questo nome era già tuo da un'altra volta») fino a «SEI DENTRO COME Divano (GOOGLE)». Nel logcat del secondo tentativo UNREGISTERED_ON_API_CONSOLE non compare più e non c'è nessun Flow failed.
  • ⚠️ Restano registrate tutte e tre, e devono restarci: caricamento, firma attuale, firma precedente. Chi in futuro «fa pulizia» fra i client Android riapre esattamente questo difetto, e lo riapre solo per i telefoni vecchi — cioè invisibile a chi prova su un telefono recente.
• 📌 La cosa da portarsi dietro oltre a questo bug: quando un errore di configurazione arriva mascherato da gesto dell'utente, il messaggio gentile diventa un occultamento. Qui la frase più rassicurante del catalogo copriva l'unica cosa che rendeva il gioco inservibile per una fetta di tester, e nessun log del gioco lo diceva — la verità stava solo nel logcat di sistema. Il messaggio bugiardo è ora SU-580, che cambia il testo e recupera il getMessage() che il plugin butta via — senza toccare la classificazione cancelled, che è corretta.

La telemetria su Drive ha una cartella per giorno, e i file vecchi ci sono stati spostati2026-08-25

• [feat] StreetU_telemetria/AAAA-MM/ diventa StreetU_telemetria/AAAA-MM/AAAA-MM-GG/. Richiesta di Ivan: con una cartella al mese, a fine mese sono centinaia di file in un elenco solo. Nome per esteso (2026-08-25, non 25) perché si legge meglio anche fuori dal padre.
  • 📌 Ed è una modifica «a caldo»: la struttura delle cartelle la decide solo l'Apps Script, il gioco fa una POST e basta. Vale da subito per tutte le build già in mano ai tester, senza una release.
  • ⚠️ Mese e giorno adesso si calcolano dalla STESSA stringa UTC. Prima il mese usava l'ora locale del progetto mentre il contatore giornaliero usa UTC: a cavallo di mezzanotte i due potevano non concordare, e un file dell'ultimo del mese finire nella cartella del mese dopo. Effetto collaterale gradito: una sessione delle 00:30 italiane è ancora «ieri» in UTC, quindi resta insieme ai file della serata.
• [feat] Migrazione una tantum dei file già arrivati, con il giorno letto da getDateCreated() di ogni file — non dato per scontato che fossero tutti di oggi, perché la telemetria riceve da metà agosto e un file del 24 nella cartella del 25 sarebbe una bugia scritta su disco. Esito: 9 file spostati, tutti in 2026-08/2026-08-25. (Erano davvero tutti di oggi, come diceva Ivan.)
• Provato sul deployment vivo, non solo nell'editor: POST vera all'endpoint di produzione → il file è comparso in 2026-08/2026-08-25/, e poi è stato messo nel cestino perché era una prova.
  • 📌 Il primo tentativo è stato respinto, e va bene così: avevo usato run_id = "provagiorno0825", e lo script pretende esadecimale (/^[0-9a-fA-F][0-9a-fA-F\-]{3,39}$/) perché quel valore finisce dentro un nome di file e un nome che arriva da fuori non si usa mai com'è. Il controllo ha fatto esattamente il suo mestiere.
• Deployment: «Gestisci deployment → matita → Nuova versione», che è l'unica strada che NON cambia l'URL. Verificato dopo: Versione 2, e l'ID implementazione è identico a prima (AKfycby2-xf1tW9T4Vb0…), cioè lo stesso che sta compilato dentro RunRecorder.ENDPOINT_URL.
• ⚠️ Il selettore delle funzioni dell'editor Apps Script non tiene la scelta, ed è costato quattro tentativi: si sceglie _migraFileNelGiorno, l'etichetta cambia, e «Esegui» lancia comunque doPost (tre volte, verificate nella lista Esecuzioni). Il giro che funziona: mettere temporaneamente in cima al file una funzione che chiama quella giusta, ricaricare la pagina — così diventa lei la selezione di default — premere Esegui, e poi toglierla. 📌 Da ricordare: la lista «Esecuzioni» dice quale funzione è partita davvero, ed è l'unico modo per accorgersi dello scambio.

«Un altro quartiere» era falso, ed era scritto in otto lingue2026-08-25

• [fix] La metropolitana in città non porta in un altro quartiere: porta alla fermata dopo, in un altro isolato. Lo ha corretto Ivan leggendo l'annuncio ai tester. Le note in-game della v0.40 lo dicevano sbagliato in tutte e otto le lingue, e le note sono cumulative: quella riga sarebbe rimasta lì per sempre.
  • 📌 E il ticket lo aveva previsto alla lettera. SU-465, in maiuscolo: *«ATTENZIONE AL NOME, PERCHÉ QUI CI SI CONFONDE. Nel gioco "metropolitana" significa già un'altra cosa: la schermata pre-run di selezione del quartiere. […] la schermata sceglie in che quartiere giocare, queste fermate spostano il barbone dentro il quartiere che sta già giocando.»* Era scritto, con l'avviso, e ci sono cascato lo stesso scrivendo le note. Un avvertimento dentro un ticket non protegge il testo scritto due settimane dopo da chi quel ticket non lo rilegge.
  • Corretti gli otto file, le note di rilascio di Play e il What to Test di TestFlight (questi due ancora modificabili lato server; il messaggio del tag no, resta com'è).
• [fix] La riga della banca prometteva la cosa sbagliata. Diceva «sono soldi che la retata non ti può più portare via»; su richiesta di Ivan adesso dice che al raggiungimento dell'obiettivo succede qualcosa di insolito, senza dire cosa. Otto lingue, più Play e TestFlight.
• [fix] play_upload.sh tagliava le note a 500 caratteri in silenzio. testo_note[:500]: un file più lungo partiva mozzato a metà frase, e lo si sarebbe scoperto solo aprendo la scheda da un telefono. Adesso si ferma e dice quanti caratteri sono di troppo — ed è servito subito, al primo tentativo (592, poi 503, infine 481).
• [change] genera_link_messaggi.py non schiaccia più gli a capo della frase. " ".join(frase.split()) andava bene per una riga da venti parole; per l'annuncio della v0.40 — sei blocchi, 1.500 caratteri — produceva un muro di testo che su WhatsApp non legge nessuno.

v0.40 su TestFlight, e stavolta la revisione è partita davvero2026-08-25

• [release] Build 0.40 caricata su App Store Connect (UPLOAD SUCCEEDED, IPA 90 MB, VERIFY SUCCEEDED with no errors), elaborata da Apple e portata fino in fondo. Id build 94168887-b862-….
• [release] I tre passi del «5-bis», quelli che si dimenticano. UPLOAD SUCCEEDED non basta: da solo lascia la build in READY_FOR_BETA_SUBMISSION a tempo indeterminato, invisibile ai tester e senza revisione avviata.
  • What to Test scritte in italiano dentro la localizzazione en-US — l'unica esistente, e quindi il ripiego che vedono tutti a prescindere dalla lingua del telefono (una it isolata le renderebbe invisibili a chi ha il telefono in inglese). HTTP 200. Testo depositato in STORE_ASSETS/apple/whats_to_test_v0.40.txt.
  • Collegamento al gruppo esterno «Divano» → HTTP 204.
  • betaAppReviewSubmission → HTTP 201.
  • ✅ La verifica che conta: externalBuildState è passato da READY_FOR_BETA_SUBMISSION a WAITING_FOR_BETA_REVIEW. Il collegamento al gruppo da solo non lo fa: via API il secondo passo non implica il terzo, ed è esattamente lì che si casca.
• 📌 Nelle note ai tester è scritto anche che le classifiche partono vuote e che il marchio STAGE nell'angolo del menu è normale: sono le due cose che, senza una riga, sembrerebbero guasti.

Il controllo dell'export iOS guardava un pacchetto di due settimane prima2026-08-25

• [fix] export_all.sh ios bocciava una build sana, dicendo che nel pacchetto non c'era il deployment di stage. Il pacchetto era giusto: era il controllo a guardare il file sbagliato.
  • La riga incriminata era find "$(dirname "$out")" -name '*.pck' -print -quit: sotto ~/Desktop/streetUniversityIOS/ non c'è un pck, ce ne sono otto — quello appena esportato più sette dentro le vecchie .xcarchive, dal 5 al 23 agosto. -print -quit prende il primo che capita.
  • ⚠️ E prima di oggi il difetto non si vedeva, perché falliva nel verso comodo: i file che il controllo cercava (credenziali e note di rilascio) stanno anche nei pck vecchi, quindi la verifica passava lo stesso — su un pacchetto di due settimane prima. È stato il controllo dell'ambiente, che distingue un pck dall'altro, a farlo emergere.
  • Ora prende il più recente fuori dagli archivi e stampa quale file ha controllato, così la prossima volta si vede a colpo d'occhio: ℹ pck controllato: …/Street University.pck.
  • Sul pacchetto vero, verificato a mano prima di fidarmi della correzione: deployment_id="69fcb3a5…" dentro il pck fresco, e degli altri tre deployment (dev, live, quello abbandonato) nessuna traccia.
• 📌 La lezione, che vale oltre iOS: un controllo che cerca «un file col nome giusto» in una cartella dove quel nome compare più volte non sta verificando la build — sta verificando *una* build, e non sa quale.

v0.40 su Play Alpha, e le note di rilascio via API non vogliono i tag di lingua2026-08-25

• [release] Bundle versionCode 40 caricato e pubblicato sul canale Alpha. Sul canale c'era il 30; adesso c'è il 40. I 27 tester Android lo ricevono quando Google finisce la revisione del canale di test (di solito minuti). ⚠️ Google non avvisa nessuno: l'annuncio è /avvisa-tester.
• [fix] Il primo invio è andato SENZA note di rilascio, e me ne sono accorto dalla riga ℹ nessun --note passato. Play non riusa mai un versionCode, quindi rilanciare l'invio sarebbe fallito sul duplicato: aggiunto --solo-note a play_upload.sh, che riscrive le note della release già sul canale senza ricaricare i 96 MB.
• [fix] E per strada è saltato fuori che il formato delle note era sbagliato per questa strada. I file esistenti (release_notes_play_v0.28/v0.30.txt) sono nel formato della Console, a blocchi <it-IT>…</it-IT><en-US>…</en-US> — e la Console quei tag li interpreta. L'API no: releaseNotes[].text è testo che va a schermo com'è, quindi i tag sarebbero finiti letteralmente nella scheda dello Store.
  • Il file nuovo release_notes_play_v0.40.txt è testo semplice, 495 caratteri (il tetto di Play è 500, e lo script tronca lì).
  • Aggiunta una guardia che rifiuta il file se contiene tag di lingua: era il genere di errore che si vede solo aprendo la scheda dello Store da un telefono, cioè quasi mai.
  • 📌 Una lingua sola, ed è giusto così: la scheda dello Store esiste solo in en-US, e i tester sono italiani — il testo italiano va nello slot en-US, come già si faceva.

Il bundle per Play passa da `export_all.sh`, e il `timeout` di Homebrew mandava Python sotto Rosetta2026-08-25

• [feat] export_all.sh --env stage aab: il target del bundle per Play era l'unico buco rimasto in SU-577. La skill pubblica-store esportava l'AAB con un comando Godot a mano, e quel comando non installa niente: dentro il pacchetto sarebbe finito il file di credenziali attivo per caso sul Mac — cioè dev.
  • ⚠️ La conseguenza sarebbe stata silenziosa e sgradevole: i tester del canale Alpha avrebbero scritto nella classifica di sviluppo, con la guardia di SU-574 che li lasciava passare perché env=dev e deployment di dev combaciano. Nessun errore da nessuna parte, solo i dati nel posto sbagliato.
  • Adesso l'AAB passa dalla stessa strada degli altri target: --env obbligatorio, credenziali installate e rimesse a posto, e verifica dentro il pacchetto. Sul bundle vero: ✅ ambiente verificato dentro il pacchetto: stage (69fcb3a5…), e nessun altro.
  • Il pre-volo Android (build template, patch EOS, version/code, keystore) ora vale anche per aab. --pacchetto non pubblica niente: l'upload è play_upload.sh.
• [fix] timeout di Homebrew fa girare Python sotto Rosetta, e questo era un sospetto scritto in memoria da settimane. play_upload.sh --controlla moriva sull'import di cryptography con *«mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')»* — un errore che sembra un'installazione rotta.
  • La prova, in due righe: python3 -c "platform.machine()" → arm64; timeout 10 python3 -c "platform.machine()" → x86_64. /usr/local/bin/timeout è un Mach-O x86_64 (Homebrew Intel), e macOS fa ereditare l'architettura ai figli: un binario x86_64 che lancia un universal lo fa partire x86_64.
  • 📌 Perché costa tempo: lo stesso identico comando lanciato a mano funziona. Cambia solo il timeout davanti, e l'errore non nomina mai Rosetta. Memoria aggiornata da «sospetto» a verificato.
• Il bundle v0.40, verificato prima di caricarlo: firmato (jar verified), versionName 0.40 letto dentro il manifest, libeosg allineata a 16 KB (align 2**14), 96 MB. Pre-volo di play_upload.sh verde, e sul canale alpha oggi c'è versionCode 30: il 40 passa.

Controprova sui moduli degli store: Play a posto, e su Apple mancava l'URL della privacy policy2026-08-25

• [fix] Su App Store Connect il campo «URL per l'informativa sulla privacy» era VUOTO, ed è stato compilato il 25/08 con https://www.streetuniversitygame.com/privacy/ (versione 1.2, verificata HTTP 200 prima di incollarla). Ok di Ivan in chat.
  • ⚠️ È il genere di cosa su cui si ferma la Beta App Review di TestFlight, cioè il passo che stavamo per fare: l'app dichiara dati collegati all'identità (Identificativi e Contenuti dell'utente) e non diceva dove sta l'informativa.
  • 📌 Perché era passata inosservata per venti giorni: la policy risulta «✅ scritta e ONLINE» nella documentazione, e per Play lo era davvero — l'URL è in Play Console dal 5 agosto. Ma «la pagina esiste» e «lo store sa dov'è» sono due fatti diversi. ⚠️ I due store non si controllano a coppie.
• [test] Google Play: allineato, e provato invece che dedotto. *Sicurezza dei dati — ultima modifica 24 ago 2026*, «Non hai niente in sospeso». L'export depositato di quel giorno dichiara sei tipi di dati (PSL_NAME, PSL_USER_ACCOUNT, PSL_USER_GENERATED_CONTENT, PSL_OTHER_APP_ACTIVITY, PSL_PERFORMANCE_DIAGNOSTICS, PSL_CRASH_LOGS), esattamente le righe di §8.2.
  • 📌 Il diff coi 17/08 dice la cosa che serviva sapere: l'unica aggiunta del 24/08 è PSL_CRASH_LOGS. Nome, ID utente e contenuti generati dagli utenti erano già dichiarati dal 17 agosto — le righe di login, classifica e nome pubblico non erano in ritardo su questa release.
  • ⚠️ Un numero che sembrava una contraddizione e non lo era: la console dice «Vengono raccolti o condivisi 3 tipi di dati» contro i sei dell'export. Sta contando le categorie (Informazioni personali, Attività nell'app, Informazioni e prestazioni). Sei tipi in tre categorie.
• [test] Apple: le cinque tipologie erano giuste, pubblicate il 24/08 — *Contenuti gameplay* e *ID utente* collegati all'identità, *Interazione con il prodotto*, *Dati sui crash* e *Altri dati di diagnosi* non collegati, tutte con lo scopo di §8.3.
• 📌 I due store puntano a due URL diversi della stessa pagina (Play al github.io, Apple al dominio del gioco). Funzionano entrambi e per ora resta così; scritto in §7.3 con la tabella di chi punta dove.

Il cancello del rilascio ha beccato tre musiche nuove mai committate2026-08-25

• [fix] main.ogg, main2.ogg e tutorial.ogg erano cambiati sul disco dal 23/08 e non erano mai entrati in git. Sono i tre brani sostituiti quel giorno (la stessa sostituzione che poi ha ribaltato la diagnosi di SU-546: il ticket descriveva i file vecchi, che non c'erano più). main.ogg da 2.008.938 a 1.537.789 byte — contenuto diverso, non rumore di LFS.
  • ⚠️ Perché sarebbe uscito storto, e in modo difficile da vedere: l'export prende i file dal disco, quindi il pacchetto per i tester avrebbe avuto le musiche giuste. Il tag no. Chiunque avesse ricostruito la build dal tag — un altro Mac, un clone fresco, noi fra sei mesi — avrebbe avuto le musiche vecchie, con un CHANGELOG che diceva che erano state sostituite.
  • 📌 Come sono saltate fuori: al cancello, classificando ogni file pendente come LFS o no invece di leggere git status e riconoscere «i soliti raw». I tredici modificati erano dodici LFS più tre .ogg con filter: unspecified — e quei tre non erano «i soliti».
  • Gli altri dodici restano fuori, ed è giusto: sono sprites_raw/ e Sounds_raw/, raw LFS che per regola di progetto non si committano.

Preparata la v0.40: note in otto lingue, e due affermazioni false trovate per strada2026-08-25

• [release] Le note in-game della v0.40, 24 voci, in tutte e otto le lingue. Scritte dal delta del CHANGELOG dalla v0.30 — 15 giorni e 415 commit, la release più grossa da quando c'è il repo. Le sezioni vecchie restano tutte sotto, come sempre.
  • ⚠️ Una voce annunciata e poi tolta prima di scriverla: il raddoppio di passanti e gatti (SU-478/479). Il CHANGELOG dice che l'esito della prova non è stato «×2» — annunciarlo ai tester sarebbe stato falso. È la ragione per cui le note si scrivono dal CHANGELOG e non dai titoli dei ticket.
  • C'è una voce che parla del marchio STAGE, e non è un dettaglio tecnico sfuggito: i tester lo vedranno nell'angolo del menu, e senza una riga che lo spieghi la classifica vuota sembrerebbe un guasto. Approvata da Ivan in chat.
  • Nomi dei quartieri presi dal CSV delle traduzioni, non tradotti a mano: SMOKESTACK, FUMEROLLE, HUMAREDA, QUALMHAUSEN, КОПТИЛКА, 烟囱镇, FUMACEIRA. Le note vecchie di es e pt li lasciavano in italiano — quelle non si toccano, sono storia.
• [change] config/version 0.30 → 0.40 e version/code 30 → 40 su ENTRAMBI i preset Android. Il salto è una scelta di Ivan (2026-08-25). ⚠️ Ha un prezzo dichiarato: il versionCode lo deriviamo dalla stringa (major×1000 + minor), quindi da adesso 0.31–0.39 sono bruciati su Android — i loro versionCode sarebbero più bassi di 40 e Play li rifiuterebbe.
• [fix] prepare_release.sh gridava «NOTE IN-GAME FERME» a note già scritte. Deduceva la versione in uscita dall'ultimo tag + 1 minor (v0.31-dev… → v0.32) e cercava una sezione v0.32 che nessuno avrebbe mai scritto. Ora, se config/version è più avanti dell'ultimo tag, è lui la fonte di verità, e lo script lo dice in una riga.
  • 📌 Perché non era un fastidio cosmetico: quell'avviso è lo stesso che deve beccare una traduzione dimenticata. Un avviso che grida sempre è un avviso che si impara a ignorare, e allora il giorno che ha ragione non lo legge nessuno.
• [test] Sonda nuova probe_note_v040.sh: 31 OK, 0 KO. ⚠️ Guardare i file non basta — il testo che il giocatore legge non è il file, è quello che esce da _load_release_notes_raw(), che fonde la lingua con l'italiano sezione per sezione e per una versione mancante ripiega in italiano senza dirlo. La sonda passa dalle otto lingue vere e controlla che v0.40 sia la prima sezione, che abbia 24 voci, e che la sezione non contenga la frase-spia italiana. Una traduzione dimenticata si vede solo di qui.
• [docs] «export_presets.cfg è gitignored» era falso, ripetuto in tre punti (export_all.sh ×3, 04_RELEASE.md). È tracciato, e non c'è nessuna regola di ignore: verificato con git ls-files e git check-ignore. La conseguenza è buona — una riscrittura dell'editor si vede nella diff — ma la nota diceva il contrario, e chi la leggeva credeva di non avere quella rete.

Le classifiche provate nei tre ambienti, e il controllo che mancava alla sonda2026-08-25

• [test] Domanda di Ivan: «con una build su stage le classifiche funzionano?» Risposta: sì, e adesso è misurata su tutti e tre i deployment.
• [fix] La sonda di SU-432 guardava troppo poco, e nel modo che non si vede. Delle definizioni tornate dal server leggeva il solo leaderboard_id. Ma una board può esistere ed essere collegata alla stat sbagliata, o avere l'aggregazione sbagliata: in tutti e due i casi si scrive da una parte e si legge dall'altra, e la classifica resta vuota senza dare nessun errore — cioè indistinguibile da una board nuova che nessuno ha ancora giocato. Su un ambiente appena creato quella distinzione è tutto.
  • Ora legge anche stat_name e aggregation, che la definizione porta già con sé, e li confronta: il nome della stat dev'essere identico all'id della board (in questo progetto ingest_stat_async() usa il nome della board come nome della stat) e l'aggregazione dev'essere Max. Una riga per board, con dentro tutti e tre i valori.
  • 📌 Ed è la cosa che permette di provare stage senza sporcarlo: la verifica della catena non ha più bisogno di scrivere un punteggio, e con aggregazione Max un punteggio di prova in stage lo vedrebbero i tester e non si abbasserebbe più.
• [feat] probe_su432.sh --env dev|stage|live: mette al suo posto il file di credenziali dell'ambiente e rimette quello di prima all'uscita, anche con Ctrl-C. ⚠️ --scrivi è rifiutato fuori da dev, e non è una cortesia: è l'unico modo di sporcare un ambiente che poi non si ripulisce.
• I numeri, tutti e tre gli ambienti, dal server vero:
  • stage (deployment 69fcb3a5…, quello dei tester) — guardia verde (SU-574: ambiente stage, deployment coerente), 8 definizioni su 8, ognuna stat = nome della board e aggregazione = Max, board leggibile e vuota, che su un ambiente appena creato è il fatto giusto.
  • live (2909e97b…) — identico: 8 su 8, tutte a posto, vuoto.
  • dev (f324e539…) — qui il giro completo, perché si può sporcare: submit_run_score ingerisce 1234 su SU_SCORE_CENTRO passando dalla strada vera del gioco, e la rilettura trova il PUID dentro i record, con la schermata che dice «I migliori del mondo, in questo momento». 5/5 passi.
  • 📌 Il tre-su-tre viene da deployment creati con le stesse mani lo stesso giorno: la scrittura provata in dev e le definizioni verificate identiche in stage e live sono la stessa catena.
• Niente lasciato in giro: dopo i tre giri il progetto è di nuovo su dev, nessun override.cfg, nessun file di credenziali fuori posto.

I comandi del rilascio non sapevano di `--env`, e da ieri sera si sarebbero fermati2026-08-25

• [fix] /esporta, /rilascio-beta e /testflight chiamavano export_all.sh senza --env, che da SU-577 è obbligatorio: ogni comando scritto lì dentro sarebbe morto su *«Manca --env»* al primo lancio. Ora dicono tutti --env stage, che è l'ambiente dei tester e quindi l'unico giusto per la beta.
  • ⚠️ Come mi era sfuggito: cercando i chiamanti avevo guardato .claude/skills/, tools/ e WORKFLOW/ — non .claude/commands/, che è dove stanno i comandi del rilascio. Il grep copriva quattro cartelle su cinque, e la quinta era quella che conta di più.
  • In /esporta l'ambiente è diventato il passo 0, prima ancora di «la build è quella giusta?»; in /rilascio-beta è la prima regola del giro, accanto ai quattro cancelli.
  • Provato: export_all.sh --env stage --controlla mac win → pre-volo verde su entrambi i preset, e le credenziali di lavoro rimesse su dev a fine giro.

SU-576 (metà) e SU-579: il campo `env` parte dal gioco, e BOARD_PROVA_CENTRO non esiste più2026-08-25

• [fix] SU-579 — tolta BOARD_PROVA_CENTRO, la costante che ha aperto SU-526. Non è più «vuota»: non c'è. Con lei se ne vanno i suoi due usi (la deviazione dentro board_for() e il ramo dedicato in quartiere_of()) e l'avviso a caratteri cubitali all'accensione, che ora non ha più niente da avvisare.
  • 📌 Quel lavoro lo fa l'ambiente, e lo fa meglio: in dev le prove finiscono in un deployment tutto loro, con gli stessi nomi di board. Il prefisso separava per disciplina — e la disciplina è quella che ha fallito, con la costante rimasta accesa per tutto lo Sprint 10 e il Centro che scriveva su SU_TEST_CENTRO. La sandbox separa per costruzione.
  • La sonda di SU-503 ora controlla una cosa più forte di prima: non «la costante è vuota» ma «la costante non esiste» — letta dalla get_script_constant_map() del vero autoload. Esito OK: round-trip su tutte e otto le board, current_board() e board_for() che tornano lo stesso id, SU_TEST_CENTRO che ricade nel ripiego generico, otto board in elenco e otto in cache.
  • Ripuliti anche i SU_TEST_* rimasti altrove: i default di probe_sud1_eos.gd erano SU_TEST_SCORE / SU_TEST_LEADERBOARD, nomi che nel portale non esistono più. Adesso sono i nomi veri, con scritto sopra che a tenere le prove lontane dai dati dei giocatori è il deployment dev, non un nome diverso.
  • Regressioni: probe_su432.sh COMPLETO 4/4 — e gira online, quindi vale anche come prova che il deployment nuovo risponde: otto definizioni tornate dal server e lettura vera della board. run_sp.sh 90: 18 dump, orphans 0 su tutti, nessuno SCRIPT ERROR.
• [feat] SU-576 (metà: il gioco) — env viaggia nei due payload. In NicknameRegistry il campo si aggiunge dentro _call(), non nei tre chiamanti, così non c'è un'azione che possa dimenticarselo; in RunRecorder sta nell'involucro dell'invio e non dentro il .jsonl compresso, così il server sceglie la tab senza scompattare niente.
  • ⚠️ Non è un dato nuovo che esce dal dispositivo — è il nome dell'ambiente di questa build, non un'informazione sul giocatore: i moduli degli store non cambiano.
  • ⛔ NON FATTA la metà lato server (le tab dev/stage/live nei due Apps Script), e non per dimenticanza: il codice dei due progetti non si è potuto leggere. L'editor di Apps Script è un Monaco e ogni tentativo di estrarne il sorgente dalla pagina è stato bloccato dal guardrail del browser. Modificare e ripubblicare a scatola chiusa un endpoint che le build già distribuite chiamano — con il rischio, se si sbaglia il tipo di deployment, di cambiargli l'URL e spegnere il registro nickname a tutti i tester — non è una cosa da fare di notte senza nessuno davanti.
  • ✅ E intanto non si rompe niente: un campo in più che il server non conosce viene ignorato, quindi tutto continua a finire dove finisce oggi. Il pezzo mancante è un miglioramento, non un requisito di correttezza.
  • Il codice da incollare e i passi («Gestisci deployment → matita → Versione: nuova versione», che è l'unica strada che NON cambia l'URL) stanno in OPUS_BRIEFS/SU-526_ambienti_online.md.

SU-577 e SU-578: l'ambiente si sceglie all'export, e il rilascio ha smesso di chiederlo alla memoria2026-08-25

• [feat] SU-577 — export_all.sh --env dev|stage|live. Copia eos_credentials.<env>.cfg su eos_credentials.cfg prima di esportare, e rimette il file di prima quando ha finito — con un trap su EXIT, quindi anche se l'export fallisce a metà. Senza quel ripristino il progetto sul Mac resterebbe puntato all'ultimo ambiente esportato, e il prossimo run_sp.sh scriverebbe lì.
  • ⚠️ Senza --env lo script si ferma e non indovina. Un default qui sarebbe esattamente il modo in cui ci si ritrova con la build dei tester che scrive in produzione.
  • La verifica è DENTRO il pacchetto, che è ciò che il ticket chiedeva: non «ho copiato il file giusto» (quello è sul disco, prima dell'export) ma «nel pck c'è il deployment giusto». E si guarda anche il verso opposto — gli altri due non devono esserci — che è il controllo che becca il caso brutto: un export che si porta dietro una copia vecchia delle credenziali accanto a quella nuova.
  • 📌 Il deployment atteso si legge dal file, non da una tabella nello script: una tabella in più è una tabella in più che si può sfasare. Lo script controlla anche che env= dentro il file corrisponda al nome del file, perché quell'incoerenza spegnerebbe l'online nella build (guardia SU-574).
  • Tre export mac di prova, uno per ambiente: dev (f324e539…), stage (69fcb3a5…), live (2909e97b…), ciascuno verificato dentro il .pck con «e nessun altro». La build v0.30 che stava sul Desktop è stata messa da parte prima e rimessa dopo.
  • Aggiornati i chiamanti che da adesso fallirebbero: testflight.sh (4 righe di aiuto), prova_su_telefono.sh (--env dev, è il telefono di Ivan) e i comandi iOS della skill pubblica-store (--env stage: TestFlight sono i tester).
• [docs] SU-578 — il blocco provvisorio del 24/08 in cima a WORKFLOW/04_RELEASE.md è stato SOSTITUITO, non affiancato. Al posto di «controlla a mano che BOARD_PROVA_CENTRO sia vuota» c'è la tabella *che build stai facendo → --env → dove finiscono i punteggi*, i due comandi da incollare, e come si verifica che sia andata bene.
  • Detto perché i presidi sono due: la procedura si può sempre saltare, quindi sotto c'è la guardia nel gioco che spegne l'online. La verifica sul pacchetto è la rete di sopra, la guardia quella di sotto — e nessuna delle due è «ricordarsi».
  • Nel pre-volo di pubblica-store il controllo dell'ambiente è diventato il PRIMO, prima ancora delle due domande su DSA e dati: è lì che si carica sugli store, cioè l'ultimo punto in cui si può ancora tornare indietro.
  • Aggiunto in entrambi il segnale a colpo d'occhio: un pacchetto per la produzione col marchio STAGE o DEV nell'angolo del menu è un pacchetto sbagliato.
• [docs] Corretta una data sbagliata di una sessione precedente: la voce «Collaudo d'insieme dei cinque ticket del 24/08» era datata 2026-08-25 pur stando fra la (4) e la (3) del 24, committata il 24 e parlando dei ticket «chiusi ieri». Diventa 2026-08-24 (3-bis), così la numerazione del 25 riparte da uno.

SU-574 e SU-575: la guardia che spegne l'online invece di scrivere nel posto sbagliato, e il marchio che dice dove sei2026-08-25

• [feat] SU-574 — se l'ambiente dichiarato e il deployment nelle credenziali non combaciano, EOS non si accende. EOSBridge.env_coerente() confronta il deployment_id del .cfg con quello che Env si aspetta per l'ambiente, e il verdetto entra in coda ad available().
  • 📌 Il punto in cui è agganciata è la parte importante. Non un if dentro setup(), ma available(): così l'incoerenza degrada per la stessa strada del «credenziali mancanti», che è collaudata in tutto il gioco — solo LAN, nessun tentativo di accensione, riga di stato nel menu, e il resto del gioco che non se ne accorge. Il verdetto si calcola una volta e resta.
  • Cosa si vede quando scatta: push_error (non warning: deve saltare all'occhio a chi prepara un rilascio) con i due deployment abbreviati, e nel menu solo LAN — ambiente online incoerente, chiave nuova nelle otto lingue.
  • Sonda probe_su574_guardia.gd: 11 OK, 0 KO, 1 NON MISURATO dichiarato. L'incoerenza si costruisce con l'override in user://, senza toccare le credenziali vere. Misurati: available() falsa, setup() che rifiuta, eos_ready che resta falso, la riga di stato, e — col guasto in piedi — la scena vera di gioco caricata e il tempo che scorre, che è il «resta giocabile come oggi» del ticket.
  • ⚠️ L'accensione vera di EOS non si può misurare DENTRO tools/autotest/, e il perché è la HOME finta dei runner. La sonda di SU-574 ci è rimasta appesa per sempre, due volte. Col sample di macOS la catena esatta: IEOS::tick → …EOSSDK… → SecItemAdd → makeLoginAuthUI → AuthorizationCopyRights → xpc_connection_send_message_with_reply_sync. EOS tiene il Device ID nel portachiavi; sotto la HOME finta quel portachiavi non esiste, EOS prova a crearne uno e SecItemAdd apre una finestra di conferma che in headless non può comparire.
    • 📌 La trappola era GIÀ SCRITTA in testa a probe_sud1_eos.gd e a tools/autotest/probe_su432.sh — *«con la HOME finta macOS apre un dialog modale»* — ed è per quello che probe_su432.sh non sposta HOME. Il sample ha aggiunto la catena, non la notizia.
    • ⚠️ Correzione a quello che avevo scritto prima di guardare: non è «il primo login su un deployment nuovo che blocca». Il deployment nuovo non c'entra, ed è dimostrato sotto.
    • Il portachiavi di login non è bloccato (show-keychain-info dice no-timeout): non è nemmeno la trappola di errSecInternalComponent.
    • Per questo l'accensione vera è finita dietro un flag (-- accendi): una sonda che non finisce non è una misura, è un blocco.
  • ✅ E l'accensione vera È misurata, da probe_su432.sh, che gira sul progetto VERO senza spostare HOME. Sul deployment dev nuovo: guardia verde (SU-574: ambiente dev, deployment coerente), identità del dispositivo RITROVATA, la stessa dell'avvio scorso (PUID 0002c09c…), login Epic, otto definizioni di board tornate dal deployment e lettura vera di SU_SCORE_CENTRO — «vuota», che su un ambiente appena creato è il fatto giusto.
    • 📌 Da lì scende anche la risposta a una domanda aperta dello spike: cambiare deployment non ha fatto perdere l'identità. Il PUID è tornato lo stesso.
• [feat] SU-575 — l'ambiente si vede: una riga nel log a ogni avvio, e il marchio nell'angolo del menu quando non si è in produzione. Env._ready() stampa [Env] ambiente online: dev (fonte: credenziali, deployment f324e539…), che è la riga che serve nei log che tornano indietro da un device: senza, davanti a una classifica vuota non si distingue «l'online è rotto» da «questa build scrive altrove».
  • Il marchio sta sopra il numero di versione, in basso a sinistra: quell'angolo è già suo da SU-43 e non ci passa nessuna voce di menu, che è centrata. Ciano per dev, ambra per stage, niente in live. Non è il grigio discreto della versione: questo deve farsi notare.
  • Tre scatti in-engine (shot_su575_marchio.gd, a finestra: in headless il viewport uscirebbe nero): TMP/su575_dev.png, su575_stage.png, su575_live.png. Il marchio c'è nei primi due, in live non c'è.
  • La parte «non spostare niente» misurata invece che guardata: il numero di versione sta a (10, 740) in tutti e tre gli ambienti, identico. Il marchio si aggiunge, non riorganizza.

SU-573: Env.gd, e in assenza di risposta si è in `stage`2026-08-24

• [feat] SU-573 — nasce l'autoload Env, l'unico posto che sa in quale dei tre ambienti online gira una build. Env.id() torna dev, stage o live, e da lì lo leggono in quattro: la guardia di EOS (SU-574), il marchio nel menu (SU-575), il campo env del payload di NicknameRegistry e RunRecorder (SU-576).
  • L'ordine di scelta: override → credenziali → default. Vince user://env_override.txt se c'è (stesso modello dell'endpoint_override.txt della telemetria: serve proprio a smentire le credenziali senza rifare il pacchetto), poi la chiave env di eos_credentials.cfg, e in fondo il default.
  • ⚠️ Il default è stage, e non è un default di comodo. Le build già in mano ai tester non spediscono nessuna chiave env: con un default live si metterebbero a scrivere in produzione, con un default dev si staccherebbero dalle classifiche che vedono oggi. stage è l'unico valore che le lascia esattamente dove sono, senza che nessuno debba aggiornare niente.
  • Una parola sconosciuta non vince mai in silenzio. env="produzione" o un override con dentro prod vengono scartati con un push_warning e si passa alla fonte successiva: qui vincere in silenzio vuol dire scrivere nel deployment sbagliato, che è l'errore che non si annulla.
  • In Env stanno anche le tre coppie env → deployment_id, che userà la guardia di SU-574. 📌 Sono in chiaro nel codice di proposito: i deployment id non sono segreti — viaggiano dentro ogni pacchetto che esce ed erano già in chiaro in un commento di OnlineLeaderboard.gd. Segreti sono client_secret e encryption_key, che restano solo nei .cfg fuori da git.
  • I tre file di credenziali sono nati (eos_credentials.dev.cfg, .stage.cfg, .live.cfg), generati dal file esistente cambiando il solo deployment_id e aggiungendo env. La copia attiva di questo Mac punta a dev. In .gitignore la riga singola è diventata il glob eos_credentials.*.cfg, con l'eccezione !eos_credentials.example.cfg perché il modello è tracciato e doveva restarlo — verificato con git check-ignore sui quattro file.
  • Un seam per le sonde, dichiarato: percorso_credenziali esiste perché la sonda possa far leggere Env da un .cfg finto in user:// invece che dalle credenziali vere, che sono le uniche che ci sono. In gioco non lo cambia nessuno.
  • Sonda nuova probe_su573_env.gd — 15 controlli, 15 OK. I tre del ticket (chiave assente → stage; env=live → live; override che vince sulle credenziali) più i due modi veri di sbagliare (parola sconosciuta nell'override e nelle credenziali), la guardia di coerenza nei tre versi (coppia giusta, coppia sbagliata, deployment vuoto), i tre deployment distinti e da 32 cifre, e il marchio: DEV in dev, vuoto in live.

SU-526 (2º giro): tre ambienti invece di due, e il cambio di puntamento diventa un passo del rilascio2026-08-24

• [docs] SU-526 rifatto sul KO di Ivan: «tre ambienti e tre classifiche e stats — DEV_SCORE per quando sviluppo io, TEST_SCORE per i tester, PROD_SCORE per quando l'app andrà sugli store». La prima stesura ne proponeva due (test + produzione): con due, le prove di Ivan sporcano la classifica dei tester — cioè il difetto di oggi spostato di un passo.
  • Due domande poste a Ivan prima di riscrivere, perché cambiavano il documento e non erano deducibili.
    1. *La separazione la fanno le sandbox o i nomi delle stat?* → le sandbox. I nomi restano identici nei tre ambienti (SU_SCORE_CENTRO), e a separare sono sandbox_id + deployment_id. DEV/TEST/PROD sono il nome dell'ambiente, non un prefisso. 📌 La strada dei prefissi è stata scartata perché è già fallita: BOARD_PROVA_CENTRO è rimasta accesa per tutto lo Sprint 10 (SU-503). Il prefisso separa per disciplina, la sandbox per costruzione — e c'è un secondo effetto, che col prefisso servirebbe una tabella nome→ambiente in ogni punto che tocca una board, mentre così il codice non cambia di una riga.
    2. *Al lancio pubblico i tester dove finiscono?* → restano su TEST. Non perdono niente, non fanno niente, nessuna comunicazione da mandare. ⚠️ Il prezzo, dichiarato: stage e live restano due mondi che non si vedono.
  • ⚠️ La conseguenza che il primo giro non poteva avere: l'ambiente di oggi diventa stage, non dev. I tester hanno in mano una build che punta al deployment attuale: perché non si accorgano di niente, quel deployment dev'essere il loro. E da lì discende una regola che va nel codice, non nella memoria: in assenza della chiave env si è in stage — le build già distribuite non mandano nulla e devono continuare a scrivere dove scrivono oggi.
  • 📌 E il buco più pesante del primo giro si sgonfia da sé: *«il PUID è per Product o per Sandbox?»* non blocca più i tester, perché nessuno di loro cambia sandbox. Resta da verificare solo per Ivan, che passa fra dev e stage — e se fosse per sandbox, non potrebbe verificare l'esperienza dei tester dal proprio ambiente.
  • [requisito nuovo] Il cambio di puntamento è un passo del RILASCIO, non solo una chiave. Dato da Ivan in chat: *«quando facciamo la release in staging vanno modificati i puntamenti alle classifiche, e anche quando sarà ora di rilasciarla in release»*. Il documento ora ha la tabella *momento → env → dove va scritto il passo* (WORKFLOW/04_RELEASE.md e pre-volo di pubblica-store), ed è nato il ticket 8 della lista.
  • ⚠️ Perché non basta scriverlo nella procedura: una build di test che scrive in live sporca la classifica pubblica, ed è l'errore che non si annulla — le stat EOS seguono il nome, cancellare e ricreare non svuota. Per questo il presidio vero non è «ricordarsi di cambiare la chiave» ma la guardia di coerenza che rifiuta di accendere EOS se env e deployment_id non combaciano, degradando a offline.
  • Il primo controllo da fare in portale è cambiato: quante sandbox ha davvero il Product, perché tutta la scelta poggia su tre utilizzabili. EOS ne dà tre di serie (Dev/Stage/Live) e mapperebbero esattamente, ma non è stato verificato: qui non si esegue nulla.
  • OPUS_BRIEFS/SU-526_ambienti_online.md riscritto: 187 righe, 7 alternative scartate col motivo, 14 risorse nome per nome, 6 buchi dichiarati, 10 titoli di ticket.

SU-570: la chiesa doppia era COLLINA, e il difetto era muto per costruzione2026-08-24

• [fix] SU-570 — segnalato da Ivan giocando: «in alcuni quartieri ci sono due chiese, in alcuni il numero sopra è bianco e in altri rosa, altri non l'hanno proprio». Tre sintomi, un difetto solo.
  • La causa, e perché nessuno l'aveva vista. _scegli_landmark_non_chiesa() costruisce il paniere su cui convertire la chiesa in più escludendo chiesa e banca. Con tre sole texture landmark resta la sola fabbrica — e COLLINA la fabbrica la VIETA. Paniere vuoto → la funzione torna null → _converti_landmark(idx, null) esce alla prima riga, senza convertire e senza loggare niente. La chiesa doppia restava, in silenzio.
  • ⚠️ Era già stato scritto nel report di SU-564, e archiviato come innocuo: «su COLLINA, se i dadi piazzano 2 chiese, il pool anti-doppione resta vuoto e il doppione non viene convertito (church×2) — innocuo, non richiesto dai criteri». Non era innocuo: il contatore sopra il tetto e il cuore sono nodi UNICI della mappa (ContatoreChiesa, CuoreChiesa), quindi con due chiese una sola ce l'ha. La seconda è la «chiesa senza numero» che Ivan ha visto, e su di lei la meccanica dell'offerta non esiste.
  • 📌 E i tre colori sono lo stesso difetto visto da tre angoli: il numero bianco è il contatore della chiesa (_piazza_contatore_chiesa non forza nessun colore, resta il default); quello oro/rosa è il contatore della banca (Color(1.0, 0.87, 0.35), scelto in SU-466), e su COLLINA la banca c'è; «niente numero» è la chiesa doppia orfana. Tre edifici, tre stati, una causa.
  • La cura: se è il veto ad aver svuotato il paniere, il veto cede. È la stessa regola già scritta al passo 1 di _pick_landmark_tex — *«se il veto svuota il paniere si ripesca da tutti: meglio un landmark fuori tono che un quartiere senza nessun edificio civico»* — applicata al caso gemello: meglio una fabbrica fuori tono su COLLINA che due chiese di cui una monca. E stavolta si logga.
  • Chiusa anche l'uscita muta: _converti_landmark() con tex == null ora emette un push_warning. Senza, il prossimo caso della stessa famiglia sarebbe di nuovo invisibile.
  • ⚠️ Perché la misura di SU-564 non l'aveva visto, ed è la lezione che vale oltre questo ticket. Quel collaudo contava le chiese leggendo la riga di log SU-185: landmark N — bank×1 church×1 …, che è un conteggio per texture: su otto quartieri diceva church×1 e sembrava una prova. Ma run_quartieri gira un seme per quartiere, e su COLLINA il difetto compare in metà dei semi. Un campione da uno su un fenomeno che accade la metà delle volte ha il 50% di probabilità di dire «tutto a posto» — ed è quello che ha detto.
  • I numeri, nei due versi, con la sonda nuova probe_su570_chiese.gd (8 quartieri × 8 semi = 64 città): prima 4 città con due chiese, tutte e quattro su COLLINA, zero negli altri sette quartieri; dopo 0 su 64. Nessuna città senza chiesa né prima né dopo, e nessuna chiesa senza contatore.
  • Regressioni: probe_su548.sh (l'offerta, il tetto delle 9 vite, il cuore che vola una volta sola) OK; run_quartieri.sh 20 20 PASS, con bank×1 church×1 in tutti e otto i quartieri.
  • ⚠️ NON FATTO lo scatto in-engine che il ticket chiedeva, e con una ragione: due chiese in una città non stanno nella stessa inquadratura, e il «dopo» è indistinguibile da una chiesa normale. Il conteggio per quartiere nei due versi misura esattamente la cosa che il ticket definisce come difetto — quante chiese ci sono — mentre lo scatto avrebbe aggiunto inquadratura, non prova. Quello che resta da guardare a occhio è su device, ed è di Ivan.

Le prove sul telefono vero: SU-557 e SU-558 tengono, SU-560 e SU-561 erano da rifare2026-08-24

Honor 10 (COL-L29, Android 10) collegato via USB, APK --export-release firmato col keystore vero e installato sopra quello del 23/08 — stessa firma, quindi nessun dato di Ivan perso. Tutto quello che segue è misurato lì, non in sandbox.

• [test] SU-557 — il log su file su Android in release C'È, ed era il punto dichiarato «da MISURARE, non dare per buono». La doc Godot descrive user://logs/godot.log «on desktop platforms». Dopo un am force-stop e un rilancio, il gioco stampa:

  ```

  [REC] la sessione precedente non si è chiusa bene (sentinella user://telemetria/SESSION_OPEN)

  [REC] coda del log accodata: run_20260824-174034_0f4c4b246c4bbe4e.jsonl (3841 byte da godot2026-08-24T17.40.31.log)

  ```

  Due cose in due righe: la sentinella sopravvive al kill, e il file di log esiste davvero — 3.841 byte letti da lì dentro.

  • 📌 Come si è potuto misurare senza run-as: la build di release non è debuggable, quindi user:// non si legge da adb. Ma RunRecorder stampa quello che fa, e le sue righe finiscono in logcat: la prova non era nel filesystem, era nel log. ⚠️ Con una piccola trappola: il logcat di questo Huawei è così pieno di roba di sistema che le righe di Godot venivano spinte fuori dal buffer — si cattura con adb logcat -s godot:V, filtrando per tag, altrimenti sembra che il gioco non stampi niente.
• [test] SU-558/SU-556 — la coda arriva su Drive per davvero. Il file run_0f4c4b246c4bbe4e.jsonl.gz è comparso nella cartella Drive con dentro un evento crash_tail da 4.127 byte, e il sanificatore ha lavorato: https://godotengine.org è diventato <url>, e una scansione per PUID/URL/email//Users/<nome> sul file arrivato non trova niente. ⚠️ Vale come prova della POST, che è ciò che «una GET non prova una POST» chiedeva.
  • SU-556, il numero che il ticket chiedeva: quanti secondi si perdono. Partita uccisa con am force-stop a ~40 s di gioco (cronometro dell'HUD a 29:20 su 30:00). Il file arrivato ha run_start, 19 pos, 4 stat, ultimo evento a t=40,1 s e nessun run_end: perdita sotto i 2 secondi, contro il caso peggiore teorico di un intervallo di flush (10 s). La coda si è fermata dov'era il gioco.
  • ⚠️ Il passaggio del file a .sent non è stato verificato (serve run-as, che su una build di release non c'è). L'arrivo su Drive è però il fatto più forte dei due.
• [fix] SU-560 — il PUID intero nel logcat NON era nostro, e il ticket sarebbe stato chiuso a torto. _mask_puid() copre tutte e 12 le stampe di EOSBridge.gd, ma una scansione del logcat completo durante un login vero ne trovava ancora uno:

  ```

  [HAuth] Logged into Epic Games Services with Product User ID: 0002f6a5…

  ```

  Lo stampa il plugin EOS (addons/epic-online-services-godot/heos/hauth.gd:272) a livello INFO. Su Android quel logcat lo raccoglie anche Google — cioè esattamente il canale che il ticket voleva chiudere.

  • Rimedio in casa nostra, non nel plugin: in release EOSBridge._ready() abbassa HLog.log_level a WARN. 📌 Patchare hauth.gd sarebbe stato più diretto e più fragile: quel file è di terzi e vive in addons/, e il primo aggiornamento del plugin si riprenderebbe la modifica in silenzio. Una riga in casa resiste agli aggiornamenti e copre anche le _log.debug(...) col product_user_id sparse in hlobbies/hlobbymember/hauth, che oggi tacciono solo perché il livello di default è INFO — cioè per fortuna, non per scelta.
  • ⚠️ Si carica per path con load() e si scrive con set(): un riferimento diretto a HLog non compilerebbe nella variante web, che il plugin non ce l'ha (SU-267).
  • I due versi, misurati sul telefono: prima 1 PUID intero nel logcat completo, dopo 0. Le nostre righe dicono 0002…, quella del plugin non esce più.
• [fix] SU-561 — i dati veri hanno smontato la classifica. Con il primo crash_tail autentico in mano, lo script raggruppava per la coda intera — ~4 KB di log d'avvio (banner di Godot, WorldGenerator, pool dei gatti, navmesh) con l'errore, se c'è, in fondo. Risultato: un gruppo per crash, e «ordinato per frequenza» diventa una lista di occorrenze singole. Gira, non serve.
  • 📌 Sul campione costruito il difetto era invisibile, perché lì le code erano righe brevi tutte uguali: il campione confermava il codice invece di metterlo alla prova. È lo stesso errore di un provino che semplifica proprio il ramo dove sta il guasto.
  • Ora si raggruppa per firma: le ultime 3 righe che sembrano un guasto (ERROR:, SCRIPT ERROR, SIGSEGV, Nonexistent…), o l'ultima riga viva se non ce ne sono. Il crash vero passa da 4 KB illeggibili a ERROR: [EOSBridge] setup_eos_async fallita | WARNING: RunRecorder: invio fallito (result=3 http=0) | ERROR: [EOSBridge] setup_eos_async fallita. Il vecchio comportamento resta sotto --intero. Il campione finto continua a dare 3/2/1: nessuna regressione.
• ⚠️ TRAPPOLA NUOVA, e costa documentazione: Godot RISCRIVE project.godot a ogni export e butta via i commenti ;. L'export Android ha cancellato le cinque righe di spiegazione di SU-557 sotto [debug], e con loro max_log_files=5 — quest'ultima perché 5 è già il default del motore, quindi la riga era ridondante (verificato a runtime: senza, vale comunque 5). Sopravvivono enable_file_logging=true e .web=false, che dai default differiscono davvero. La spiegazione è stata spostata in RunRecorder.gd, che è un .gd e non lo riscrive nessuno.
• [test] SU-569 su device: pagina 2 del giornale sul telefono vero, zero icone dell'HUD, ed è lo screenshot da cui è nato il ticket. Vista anche la pagina 1 (che le sonde saltavano) pulita, e l'HUD di gioco intatto durante la partita — le tre cose che il lotto A aveva dichiarato NON PROVATE.
• ⚠️ SU-555 resta l'unica non misurabile: vuole una build installata dal Play Store, non da USB, più 24-48 h prima che il crash compaia in Android vitals.

SU-562/554/563: quello che va detto agli store del log di crash, e il giro iOS verificato2026-08-24

• [doc] SU-562 — i moduli di Play e Apple dichiarano il log di arresto anomalo. Escono con la release che porta la spedizione (SU-557/558/559), non dopo: i moduli si aggiornano insieme a ciò che dichiarano.
  • Play → Sicurezza dei dati: STORE_ASSETS/google_play/data_safety_2026-08-24.csv, ripartendo dal CSV depositato del 17/08 e non a mano. Il diff è di 5 righe su 783, tutte della famiglia PSL_CRASH_LOGS: Raccolto sì, Condiviso no, non temporaneo, facoltativo (l'utente sceglie), scopo Analisi. Il CSV vecchio resta accanto: è la traccia di cosa era dichiarato prima.
  • Apple → App Privacy: riga *Diagnostics → Crash Data*, Not Linked, no tracking, Analytics. Registrata nelle tabelle §8.2 e §8.3 di DISTRIBUZIONE_STORE.md.
  • Le due informative (IT/EN) non stavano in questo repo: DISTRIBUZIONE_STORE.md §7.3 rimanda al sito, e le copie gemelle sono street-university-site/privacy/index.html e street-university-beta-devices/index.html. Modificate lì, stesso SHA-256 come vuole la convenzione già in uso — e lasciate NON committate e NON pubblicate: la pubblicazione è di Ivan.
  • ⚠️ TROVATO STRADA FACENDO, e non è di oggi: la pagina pubblica si contraddiceva. Il box «In breve» diceva «né analytics» e «il gioco si collega a Internet solo in tre casi» — falso da SU-413, cioè da quando esiste la telemetria opt-in, non da questo ticket. Descrivere il crash_tail al §5 lasciando quella frase avrebbe reso il documento incoerente con sé stesso, che su un'informativa è peggio del silenzio. Corretto al minimo e in modo verificabile: «né analytics o tracciatori di terze parti» (vero: non c'è nessun SDK di terzi) e quattro casi, col quarto che è la telemetria facoltativa. Se Ivan preferisce un'altra formula, si cambia prima di pubblicare.
• [doc] SU-554 — i simboli di debug nativi entrano nel pre-volo di pubblica-store, che è la parte che vale: senza un passo scritto, alla release dopo si dimentica. Il passo dice dove si riscarica, che va rifatto a ogni cambio di versione di Godot, e come verificare che funzioni (una traccia nativa che mostra nomi di funzione invece di indirizzi).
  • Zip scaricato e verificato nel nome (⚠️ ha .stable. in mezzo, non solo la versione numerica): 766 MB, in TMP/su554/, fuori da git per costruzione. Non si conserva: si riscarica.
  • ⚠️ Lo zip copre solo il motore, non la .so di EOS — verificato leggendo tools/android/eosg_16kb/RICETTA.md: il ponte ricompilato in casa non usa debug_symbols=yes separate_debug_symbols=yes, quindi uno stack trace che cade dentro il codice EOS resta illeggibile. È un cambio alla ricetta di compilazione, quindi un ticket a sé: segnalato, non fatto.
  • ⚠️ NON VERIFICATO: il caricamento vero in Play Console e la lettura di una traccia leggibile. Serve browser e credenziali di Ivan.
• [doc] SU-563 — il giro dei crash su iOS: verificato sulla documentazione Apple, e la risposta ribalta l'ipotesi del ticket. Sezione nuova in coda a OPUS_BRIEFS/SU-547_crash_android.md, accanto al gemello Android, con le fonti citate.
  • (a) I crash TestFlight arrivano in Xcode Organizer: sì. «TestFlight and the App Store collect crash reports for every submitted version of your app.»
  • (b) Il tester deve fare qualcosa? NO, ed è il punto. «TestFlight users of your app automatically share crash reports with you, regardless of the device settings for sharing diagnostic and use data.» L'interruttore di sistema «Condividi con gli sviluppatori» regola solo i download dalla produzione App Store. 📌 La differenza col mondo Android c'è, ma va nella direzione opposta a quella che il ticket temeva: su TestFlight il consenso non è un cancello separato, è implicito nell'essere tester. Quindi messaggio_reclutamento_beta.md non è stato toccato: non c'è nessun passaggio da aggiungere.
  • (c) I simboli ci sono già: tools/release/testflight.sh:259 mette uploadSymbols=true nell'ExportOptions.plist, che è la via raccomandata da Apple. Verificato anche sui file veri, non solo sulla configurazione: gli .xcarchive di build passate contengono tutti dSYMs/Street University.app.dSYM.
  • 📌 Nota per un ticket a sé, non bloccante: testflight.sh:246 fa rm -rf dell'archivio a ogni run, quindi non conserviamo l'.xcarchive di ogni versione spedita. Col uploadSymbols i simboli li ha già Apple, quindi al giro normale non serve — servirebbe solo per risimbolicare un log fuori dall'Organizer.

SU-569/565: il giornale di fine partita resta solo, e nel tunnel la mappa non si apre più2026-08-24

• [fix] SU-569 — sulla pagina della classifica non si vedono più le icone dell'HUD (segnalato da Ivan con lo screenshot del 2026-08-24: moneta, gatto, trombetta, fila dei power-up e punteggio accesi attorno al foglio).
  • 📌 La causa non era quella che sembrava. Non è un problema di ordine dei figli: GameOverPanel viene dalla .tscn (indice 5), mentre moneta, gatto, trombetta, super, fila dei poteri e punteggio sono costruiti a runtime e quindi appesi in fondo — disegnano sopra il velo nero al 72% del pannello. La prova sta nello screenshot di Ivan: la moneta (runtime) è accesa e la cifra «200» accanto (MoneyLabel, dalla .tscn) è spenta sotto il velo. Spostare il pannello le avrebbe lasciate comunque intraviste.
  • Cura: _nascondi_hud_di_corsa() spegne un elenco esplicito di 19 nodi, chiamata in testa a _do_gameover_presentation() — la porta di tutti i finali, MP compreso, e a monte anche della pagina 1. ⚠️ Un for sui figli si sarebbe portato via pannello finale, notifiche, pausa, opzioni e il giornale stesso.
  • ⚠️ Senza la guardia in _process il nascondere non teneva un fotogramma: _update_run_timer, _update_power_grid e _update_reuse_indicators riscrivono visible a ogni frame — «prima ferma chi scrive, poi scrivi». Sopra la guardia restano le due cose che a game over servono ancora: il rotolamento dei soldi, che deve poter finire, e la sorveglianza della sessione MP degradata, che ricostruisce il pannello della rivincita.
  • ⚠️ Sparisce anche la vignetta rossa di fame/sonno (_danger_overlay), ed è visibile nel confronto: era lei a tingere di rosso i bordi della pagina nello screenshot di Ivan, che è morto di fame. È a schermo intero e sta sopra il pannello, quindi è HUD di corsa a tutti gli effetti — ma è un cambio di resa che si nota, e lo shader del game over ha già la sua vignetta. Una riga per rimetterla, se Ivan la rivuole.
  • Scelta dichiarata: nella fase spettatore MP l'HUD resta acceso come oggi (lì _on_game_over non passa da _do_gameover_presentation); spegnerlo avrebbe tolto l'HUD per tutta la partita guardata.
  • Prova per immagini, stessa sonda lanciata due volte (rimedio disarmato / cura attiva), stesso punto del giro — TMP/su569/prima/ e TMP/su569/dopo/: in partita 16/16 icone accese in entrambi i giri (il controllo positivo, che dice che la sonda saprebbe vederle), pagina 2 su tablet 13 → 0, porta MP su telefono 16 → 0.
• [fix] SU-565 — nel tunnel della metro le azioni della città non rispondono più. Ivan, 2026-08-23: «in metro livello bonus non devi aprire la mappa, oltretutto, così come non puoi suonare o scorreggiare».
  • _superficie_congelata() legge GameState.bonus_level_active (che copre anche la cerimonia delle carte) e fa uscire _process in testa; seconde serrature in _toggle_map() e in MapOverlay.open(), che è l'ultima porta prima di get_tree().paused = true.
  • ⚠️ SORPRESA MISURATA, e contraddice il testo del ticket: delle quattro azioni solo map era viva. busk, fart e super le legge Player._physics_process, e il Player sta dentro il World che _congela_superficie() mette in PROCESS_MODE_DISABLED: erano già inerti. Lo dimostra la controprova — con la cura disarmata la sonda dà 2 KO (mappa aperta, albero in pausa) e le altre sei righe restano OK. Non è stato scritto codice per un difetto che non c'era.
  • Il danno vero era solo quello: MapOverlay metteva in pausa l'albero dentro un CanvasLayer che il congelamento aveva reso invisibile — il tunnel si piantava, a schermo non compariva niente e il giocatore non poteva capire perché.
  • ⚠️ Effetto oltre le quattro azioni, dichiarato: l'uscita in testa a _process spegne nel tunnel anche avvisi di fame/sonno, suggerimenti, timer della retata e decadimento del wanted. È coerente col congelamento (GameState di sopra è già fermo e quegli avvisi girerebbero a vuoto), ma è più di quanto il ticket chiedesse: si torna indietro con una riga.
• Numeri, rimisurati dall'orchestratore: probe_su569.sh ESITO OK · probe_su565.sh 12 criteri, 0 KO (preme i tasti veri T/B/F/Q prima sotto e poi in città) · regressione probe_su541.sh 8 criteri, 0 KO · compile-check su HUD.gd, MapOverlay.gd e le due sonde: 4 controllati, 0 FALLITI.
• ⚠️ Cosa NON è stato provato: MP vero a due peer (la porta MP è stata esercitata con show_last_survivor_win() su mondo singolo), il tocco su device dei due pulsanti spenti (verificati per is_visible_in_tree(), non con un dito), la pagina 1 del giornale (la sonda la salta per arrivare alla 2: che anche lì l'HUD sia spento discende da dove sta la chiamata, non da una foto), e RICOMINCIA premuto davvero (il mondo è stato ricostruito a mano).
• 📌 Da ricordare per chi tocca l'HUD: un nodo nuovo dell'HUD di corsa va aggiunto anche all'elenco di _nascondi_hud_di_corsa(), come già vale per _hud_blocker_rects(). Il commento sopra la funzione lo dice.

SU-557/559/558/513: la coda del log dopo un crash, e i tre messaggi all'uscita erano due difetti2026-08-24

• [feature] SU-557 — il file-sentinella «sessione non chiusa bene», e il log su file anche su telefono. L'assenza della riga run_end non basta come prova che la sessione sia morta male: su Android anche uno scorrimento via dai recenti può non consegnare la notifica di chiusura.
  • project.godot: debug/file_logging/enable_file_logging=true (era assente, quindi su Android il log su file non esisteva proprio), max_log_files=5, e .web=false — la demo web resta a secco per SU-268 (zero scritture su disco). ⚠️ Il tetto non può scendere a 1: la sessione precedente sarebbe già stata cancellata quando la si va a leggere.
  • Due sentinelle distinte, non una riusata: REC_ON (SU-414) continua a dire «accendi il registratore», la nuova user://telemetria/SESSION_OPEN dice solo «sessione cominciata e non finita bene». Scritta in _ready, tolta solo all'uscita pulita — ⚠️ mai su APPLICATION_PAUSED, altrimenti il tasto home diventerebbe un'uscita pulita e la morte da background, che è esattamente il caso da vedere, sparirebbe.
  • ⚠️ NON MISURATO: che su Android in release il log su file esista davvero. La doc Godot descrive user://logs/godot.log «on desktop platforms»; nessun apparecchio era collegato (adb devices vuoto). Come misurarlo è scritto nel report del lotto.
• [feature] SU-559 — scripts/systems/LogSanitizer.gd, il filtro che toglie gli identificativi dal log. È il gate della spedizione, non una raccomandazione: senza, il log non esce dal telefono. Spedirlo grezzo rimetterebbe dentro gli identificativi che SU-413 aveva tolto apposta e renderebbe falsa la risposta «Not Linked» già data ad Apple.
  • Due mani, in quest'ordine. (1) I segreti noti, cancellati per stringa esatta — il chiamante passa nome account, PUID, handle, id del dispositivo: è l'unica mano che prende con certezza un nickname come «Er Barbone 92», che nessuna espressione regolare saprebbe riconoscere. (2) Le forme, 12 regole: PUID di altri giocatori, token, URL, email, IP, MAC, path col nome utente.
  • Statico con preload, niente class_name: nessun simbolo globale nuovo. Legge Settings/EOSBridge in sola lettura — EOSBridge.gd non è stato toccato (è di SU-560, lavorato in parallelo).
  • 📌 La regola scritta in testa al file, ed è quella giusta: «il filtro può solo esagerare, mai risparmiare». Un falso positivo costa una parola di leggibilità in un log di diagnosi; un falso negativo costa un identificativo spedito.
  • ⚠️ La sonda ha bucato il filtro due volte, e sono le due trappole da ricordare. (1) \b non funziona contro _: PCRE2 lo conta carattere di parola, quindi run_…_3d5bb89ec345ee97.jsonl passava indenne. (2) Il nome di un altro giocatore (NetworkManager.gd:310) non sta in nessun Settings, quindi sopravviveva alla prima mano e serviva la seconda. Corrette entrambe.
  • ⚠️ E la sonda ha accusato il filtro di un residuo che non c'era, trovato rilanciandola in chiusura: il suo controllo della posta elettronica era [^\s]@[^\s], cioè qualsiasi @ fra due non-spazi — e su un log vero pulitissimo inciampava in is_night@08:06=true, che è una riga del TestBot. Ora vuole un dominio col punto e una coda di sole lettere. È il gemello esatto dell'errore già annotato lì sopra per res://. Dopo la correzione: 9 prove, 0 KO.
• [feature] SU-558 — la coda del log spedita come evento della telemetria. Al lancio dopo una sessione non chiusa bene, gli ultimi ~16 KB del log diventano una riga crash_tail dentro un normale run_*.jsonl. Riusa coda, consenso, endpoint e tetti che esistono già: nessun endpoint nuovo, nessun destinatario nuovo, nessun consenso nuovo. Il sanificatore gira prima della scrittura.
  • Scartata l'alternativa di una coda dedicata: avrebbe voluto dire una seconda coda da tenere allineata a quella che c'è.
  • 16 prove, 0 KO (tetto misurato 16.288/16.384 byte partendo da un log di 40 KB). ⚠️ NON PROVATO che la riga arrivi su Drive: serve rete e l'endpoint vero, e una GET non prova una POST. Provato che il file viene scritto e messo in coda; consenso negato e tetto dei 16 KB provati in casa.
  • ⚠️ Rischio da tenere d'occhio: su telefono quasi ogni sessione finisce con lo scorrimento via dai recenti, che non è un'uscita pulita — la sentinella resterà spesso e ci sarà spesso una coda da mandare. È il comportamento che il ticket chiede, ma se risultasse troppo chiacchierona il punto dove distinguere «messo in pausa e poi ucciso» da «morto in primo piano» è già segnato in cima a RunRecorder.gd.
• [fix] SU-513 — i tre messaggi all'uscita erano DUE difetti, non uno, e serviva riparare tutti e due. Il ticket li elencava insieme come se avessero una causa sola.
  • Unable to start the timer era di RunRecorder: _timer.start() su un timer che sta uscendo dall'albero. Riparato con le due guardie (is_inside_tree(), is_queued_for_deletion()) più il divieto di appendere figli a un nodo in uscita.
  • ObjectDB instances leaked e N resources still in use NON erano suoi: un giro --verbose ha stampato i nomi — OggPacketSequence, AudioStreamOggVorbis, AudioStreamPlaybackOggVorbis, OggPacketSequencePlayback, Resource still in use: res://assets/sounds/main2.ogg. È la musica. scripts/tools/probe_su513_musica.gd isola il fenomeno in dodici righe senza mondo e senza autoload: uscire mentre la traccia suona → i due messaggi; stop() prima → spariti; stop()+free() → spariti uguale, quindi basta fermare.
  • Rimedio: World._exit_tree() ferma music e _thunder_player. ⚠️ Non cambia *quando* la musica parte, che è la cosa delicata di quel nodo dopo SU-544: _exit_tree() gira quando il World esce dall'albero — chiusura, RICOMINCIA, ritorno al menu — cioè sempre dopo che la musica ha finito di servire.
  • 📌 I due versi, misurati dall'orchestratore su tre configurazioni, perché con due difetti sovrapposti un solo confronto prima/dopo non distingue chi ha riparato cosa. run_sp.sh 45 wander --rec, conteggio delle righe (timer / ObjectDB / resources):
    • RunRecorder vecchio + World nuovo → 2 / 2 / 2
    • RunRecorder nuovo + World vecchio → 0 / 2 / 2
    • entrambi nuovi → 0 / 0 / 0

      Nessuno dei due rimedi da solo basta, e ognuno spegne esattamente il suo messaggio.

  • ⚠️ Resta nel log l'ERROR: NavigationServer navigation map query failed…, che è preesistente e non c'entra: compare identico nei run dei quartieri senza registratore.
• Compile-check dei 6 file del lotto + World.gd e la sonda corretta: 0 FALLITI. Audit emoji: 0.

SU-564: la chiesa c'è in tutti e otto i quartieri, e il perché non c'era non era dove sembrava2026-08-24

• [fix] SU-564 — una chiesa garantita per quartiere (deciso da Ivan in chat il 2026-08-23). Da quando SU-548 le ha appeso sopra una meccanica vera — offerta, contatore, cuore che vola, vita riscattata — una chiesa che c'è a seconda del seme è peggio di una che non c'è: mancava in 4 quartieri su 8.
  • Il gemello di _garantisci_banca() non bastava, ed è la scoperta del ticket. Scritto per primo (_garantisci_chiesa(), conversione post-hoc di un landmark esistente), portava la chiesa dal 56% al 67% dei semi e da 3/8 a 3/8 quartieri: quasi nulla. ⚠️ Causa misurata: _riserva_isolati_landmark() garantiva UN SOLO slot-landmark per mappa, e quello slot lo prende sempre la banca (invariante di SU-370). Alla chiesa non restava niente su cui convertire — e non era un caso raro: in 5-6 quartieri su 8 il landmark totale era esattamente 1.
  • La cura vera: la rete di sicurezza sale a due slot (while _landmark_previsti < mini(2, _lay_landmark_max)), uno per la banca e uno per la chiesa, mai oltre il tetto del quartiere — verificato in Quartieri.gd che nessuno degli otto è sotto 2 (valori 2-4), quindi nessun tetto è stato alzato. Se la mappa è troppo piena per il secondo slot lo stampa nel log invece di nasconderlo.
  • 📌 Perché questa strada e non la conversione: _reserve_footprint() promuove un lotto 1×1 generico (palazzi/piazza), quindi non toglie niente a nessun altro landmark. La conversione post-hoc, quando scatta, un landmark lo consuma davvero — resta come rete di ultima istanza (serve ancora se i dadi piazzano zero chiese sui due slot: nel giro di collaudo è capitato a mercato), ma non è più la strada normale.
  • ⚠️ SECONDO DIFETTO, trovato solo perché il primo era stato riparato, e invisibile fino a ieri: con due slot, 20/60 semi restavano ancora senza chiesa. _pick_landmark_tex() (preesistente, SU-185) ha un anti-gemelli che scarta il landmark — il lotto già prenotato torna un condominio anonimo — quando la preferenza di quartiere restringe il paniere a un solo nome uguale al vicino appena piazzato. Con un solo slot non poteva capitare mai (_ultimo_landmark parte null: il primo landmark non ha gemelli da evitare). Ora la preferenza si allenta quando è lei a creare il vicolo cieco, ripescando dal paniere del solo veto; il veto resta un vincolo duro (mai una fabbrica alla Collina). Zero tiri di rng in più.
  • I numeri, misurati due volte. Sonda da 60 semi × 8 quartieri: 34/60 → 60/60. run_quartieri.sh 20 20 rilanciato dall'orchestratore, non preso dal report dell'agente: 8 quartieri su 8 con church×1, e bank×1 in tutti e otto — nessuno ha perso la banca. Prima: 3/8.
  • Il contatore e il cuore funzionano anche sulla chiesa del ripiego: _garantisci_chiesa() gira alla riga 806 e _piazza_chiesa_interattiva/_contatore/_cuore alle 821-823, su landmarks_piazzati letto in quel momento — qualunque chiesa esista lì è servita. L'agente l'ha misurato su 12 riparazioni reali (12/12); probe_su548.sh rilanciato a diff applicato è verde: contatore alla quota 0,20, cuore a 0,88, 0/100$, tetto delle 9 vite, offerta parziale che resta versata.
  • Determinismo MP verificato: 5 semi rigenerati due volte → 5/5 città identiche. La sequenza dei dadi cambia per le mappe che prima avevano 0-1 landmark (uno slot in più consuma un randi()), ma host e client tirano la stessa sequenza dallo stesso seme: le città salvate da prima non si riproducono più uguali, le partite sì.
  • ⚠️ Due effetti collaterali dichiarati, non nascosti. (1) In 7 semi su 60 il secondo slot non trova un lotto generico libero e ripiega su una piazza (comportamento preesistente di _reserve_footprint): verificato caso per caso che il conteggio non scende mai sotto plaza_keep_min del quartiere. (2) La chiesa ora è esattamente una, come la banca: se i dadi ne piazzano due, la seconda viene riconvertita in un altro landmark (mai in banca). Prima due chiese affiancate erano possibili.
  • Interruttori di collaudo landmark_min2_enabled e church_repair_enabled (stesso pattern di bank_repair_enabled), per contare prima e dopo senza disfare la modifica a mano.
• Compile-check scripts/world/WorldGenerator.gd: controllati 1, FALLITI 0. Gli ERROR: N resources still in use at exit nei log dei quartieri sono preesistenti — è SU-513, in lavorazione in parallelo.

SU-560/561: i PUID mascherati in release, e le code di crash finalmente leggibili2026-08-24

• [change] SU-560 — i PUID non escono più interi dalle stampe di una build di release. Non è un problema del *nostro* log: un PUID stampato finisce anche nel logcat che Google raccoglie, dove non lo controlliamo e dove il sanificatore di SU-559 — che lavora a valle, sul testo già stampato dentro il nostro file — non arriva mai. Si maschera alla fonte.
  • Una sola funzione, EOSBridge._mask_puid(): in release restano le prime 4 cifre + «…», in debug il PUID resta intero perché intero serve per lavorare (OS.is_debug_build()).
  • ⚠️ I punti da mascherare erano 11, non i 3 che il ticket citava (righe 354/1115/1794 di un'ispezione precedente): r.368, 371 ×2, 508, 518 ×2, 568, 649, 685, 1129, 1665 ×2, 1808, 1850. Chi si fosse fermato alle tre del ticket ne avrebbe lasciati otto in chiaro, e il criterio sarebbe risultato «soddisfatto».
  • 📌 Perché una funzione sola e non substr sparso: il criterio del ticket («in release nessun PUID intero nel logcat») si verifica a vista solo se c'è un unico posto da cui passano tutti. Con due copie della logica in giro, il controllo torna a essere una lettura riga per riga.
  • Un punto è stato lasciato fuori di proposito: il PUID dentro il messaggio di _link_result() (~r.1793, «Quell'accesso appartiene già a un altro giocatore (PUID %s)»). Non è una stampa ma un campo di un Dictionary — e verificato: non arriva mai a schermo, perché MainMenu.gd:6027 costruisce la propria frase con I18n.tf partendo dal codice link_altrui e quel testo lo ignora. È di fatto un campo morto.
  • ⚠️ NON MISURATO, e non è misurabile qui: il logcat di una build di release su un telefono vero. Oggi nessun device Android è collegato (adb non vede niente). Quello che è stato provato è che con is_debug_build() falso la forma esce mascherata, e che nessuna delle stampe scavalca la funzione.
  • «Il login funziona ancora» è stato provato per davvero, non dedotto: probe_su446_identita.sh rilanciata a diff applicato dà 6 verdetti OK, 0 KO — identità del dispositivo ritrovata fra due avvii del processo, creazione da zero quando non c'è, persistenza al riavvio, e il fallimento atteso (codice EOS 18) quando il Device ID non esiste. ⚠️ Il primo giro della sonda aveva dato 1 KO sul confronto fra processi: era il PUID salvato da una sessione precedente, non il diff — il secondo giro, con l'àncora fresca, è pulito. Vale la pena saperlo perché quella sonda sembra bocciare il codice mentre sta bocciando la propria memoria.
• [feature] SU-561 — tools/telemetria_crash_tail.py: le code di crash raggruppate per frequenza. Senza questo i dati arrivano su Drive e non li guarda nessuno. Python 3 di sola libreria standard, nessuna rete (python3 qui non ha i certificati CA).
  • Scandisce ricorsivamente la cartella (default: quella vera su Drive, lo stesso path di tools/archivia_telemetria_icloud.sh), legge sia run_*.jsonl sia run_*.jsonl.gz — i file veri sono gzippati — filtra gli eventi crash_tail, li raggruppa e li ordina per frequenza, con il dettaglio per versione sotto ogni gruppo.
  • 📌 La normalizzazione è il pezzo che fa la differenza fra uno strumento e un elenco inutile: timestamp, indirizzi 0x…, file.gd:riga, «line N» e numeri di 5+ cifre (pid, epoch) diventano segnaposto stabili. Senza, ogni crash è un gruppo da 1 e l'ordinamento per frequenza non dice niente.
  • ⚠️ Trovato leggendo i file veri, e corregge il testo del ticket: gli eventi della telemetria usano la chiave breve "e" ({"e":"run_start",…}), non "event". Lo script accetta entrambe, così non dipende da quale delle due userà SU-558.
  • Domanda che resta aperta fino a SU-558: il nome del campo che porterà il testo della coda. Per ora si provano in ordine text, tail, msg, message, log, stack; se nessuno combacia l'evento viene contato lo stesso e lo script stampa le chiavi che ha trovato, invece di scartarlo in silenzio.
  • Provato su dati veri per la parte che esiste: cartella Drive, 10 file, 1362 eventi, 0 righe non-JSON, 0 crash_tail — atteso, l'evento non è ancora prodotto da nessuno, e lo script lo dice invece di stampare una tabella vuota. La classifica vera e propria è provata su un campione costruito (TMP/su561_campione/, misto .jsonl/.jsonl.gz, chiavi e/event, una riga JSON invalida, un evento senza campo di testo): gruppi 3/2/1 nell'ordine giusto, riga invalida scartata e contata a parte.
• Compile-check scripts/autoload/EOSBridge.gd: controllati 1, FALLITI 0.

Collaudo d'insieme dei cinque ticket del 24/08: nessuna regressione2026-08-24

• [test] Collaudo dei cinque ticket chiusi ieri (SU-505/506/507/543/544), con una domanda sola: SU-544 ha tolto autoplay = true dal nodo Music di Main.tscn, quindi ora la musica del mondo parte solo da World._avvia_musica_col_primo_frame() — e prima quel flag mascherava qualunque fallimento di quella chiamata. Esiste una strada per entrare in partita e restare muti? No, in nessuno dei percorsi osservabili: SP con settings freschi (musica a 0,067 s dal primo frame), SP con settings.cfg vecchio (0,056 s), RICOMINCIA (0,013 s), tutorial, quartiere con traccia propria, livello bonus.
• Nessuna regressione. 14 prove verdi, dettaglio in TESTLOG.md: smoke run_sp.sh 90 con orphans:0 su tutti i dump, quattro sonde del tunnel (SU-491 ×2, SU-542, SU-551) tutte a 0 KO con l'economia che quadra, e il menu che si apre normalmente sia da non loggati sia da loggati senza nome di riserva.
• 📌 Il tutorial e' fuori dal perimetro di SU-544, e conviene saperlo perche' il collaudatore c'era arrivato per la strada debole («ho letto il codice»): TutorialWorld.tscn non ha mai avuto l'autoplay, e TutorialWorld._setup_music() fa play() per conto suo. Non e' un ramo non misurato: e' un ramo non toccato.
• ⚠️ Resta non osservabile qui: il percorso Epic reale con nome di riserva attivo, che vuole un login EOS vero. In sandbox si e' potuto verificare solo che i predicati nuovi non sbagliano con provider non-Epic.

SU-544: il frammento di musica prima del velo era l'autoplay del .tscn2026-08-24

• [fix] SU-544, secondo giro — KO di Ivan (2026-08-23): «continuo a sentire per un attimo ad inizio loading gia' la musica del livello, poi loading per shaker ecc e muto e poi parte livello con la musica». Il primo giro aveva sistemato la coda (FRAMI_SOTTO_IL_VELO 2→1, la musica che partiva un frame prima che il velo cadesse) e dato per buona la testa. Ivan stava segnalando la testa.
  • Causa radice: il nodo Music di Main.tscn aveva autoplay = true. I figli entrano nell'albero — e suonano — prima che World._ready() cominci, e il music.stop() che li zittiva arriva ~50 righe dopo. In mezzo usciva un frammento di brano a velo alzato. ⚠️ Ed era sempre main2.ogg, la traccia del .tscn, anche nei quartieri che hanno la loro: _musica_del_quartiere() cambia lo stream dopo.
  • I millisecondi che il ticket chiedeva. Prima: 88,0 / 88,0 / 77,3 ms di brano gia' suonato su tre giri col velo, 109,3 ms nel giro «analisi». Dopo: playing=false, 0,0000 s in tutti e quattro i giri. La musica al primo frame di gioco resta a 0,003 s prima e dopo: la coda sistemata al primo giro non si e' rotta.
  • Caricamento, che non deve allungarsi: media di tre giri 1072,8 → 1050,5 ms, dentro il riferimento storico 1049-1073. Zero frame piatti, velo intatto.
  • 📌 La «rete di sicurezza» che il commento difendeva non esisteva, ed e' la ragione per cui il primo giro non ha guardato li'. Il commento diceva che l'autoplay serviva «per chi istanzia la scena senza passare da qui»: ma World.gd e' lo script della radice di Main.tscn, quindi chiunque la metta nell'albero passa di li', e in fondo a _ready c'e' sempre _avvia_musica_col_primo_frame() senza nessun ramo che esca prima. Chi istanzia la scena senza metterla nell'albero non sentirebbe niente comunque. ⚠️ Lo stop() resta lo stesso, a costo zero: e' la difesa se un domani qualcuno riaccende l'autoplay dall'editor.
  • ⚠️ TRAPPOLA NUOVA, ed e' il motivo per cui nessuna sonda l'aveva visto: play() e stop() cadono dentro lo stesso frame, quindi una sonda che campiona a ogni frame vede sempre playing=false. Si e' misurato con una strumentazione temporanea sulla riga del music.stop(), poi rimossa. Un difetto udibile puo' essere invisibile a un campionamento per frame.
  • Il ramo RICOMINCIA, verificato dall'orchestratore a lotti chiusi (l'agente non ci era riuscito: la copia di lavoro montava il MainMenu.gd a meta' di un altro lotto). Rilanciato il modo ricomincia della sonda: 0 frame piatti, il velo copre i frame 0-3, il mondo nuovo appare al frame 4 ed e' li' che entra la musica (0,013 s), playing=true, scena World, 1 solo nodo nel gruppo world. ⚠️ Contava perche' togliere l'autoplay significa che se _avvia_musica_col_primo_frame() fallisse si resterebbe muti — prima l'autoplay lo mascherava. Ora la sonda lo controlla esplicitamente in due modi.
  • probe_su537_avvio.gd +32 righe: stampa Music.autoplay letto prima dell'ingresso nell'albero, controllo «la musica riparte» nel modo analisi, colonna musica nel modo ricomincia.
  • Nessun altro autoplay = true in tutto scenes/ (TutorialWorld.tscn non l'ha mai avuto). Scatti in TMP/L1_SU-544/.

SU-505/506/507: con Epic non si resta piu' senza nome pubblico2026-08-24

• [feature] SU-505 — il nome di riserva. Quando l'handle Epic non passa una delle due porte del nome pubblico, il gioco non lascia piu' il giocatore a mani vuote: gliene presta uno. ⚠️ Non era cosmetico: senza nome pubblico il giocatore Epic era fuori dal multiplayer (online_gate_reason() -> GATE_NO_NAME), e la schermata gli diceva «si cambia su Epic», cioe' da dentro il gioco non poteva fare niente.
  • Il motore sta in NicknameRegistry._claim_fallback(): il nome si costruisce sul dispositivo e poi si rivendica con la claim di sempre — stesso lock del server, quindi unico davvero, non un'etichetta locale. ⚠️ Le firme di claim e claim_provider_handle non sono state toccate (contratto SU-444), verificato sul diff: chi vuole sapere com'e' andata legge last_fallback_reason / last_fallback_name.
  • Le tre cifre finali sono deterministiche dal PUID (prime tre esadecimali riportate in 0-999): chi disinstalla e reinstalla rivede lo stesso nome. Provato: PUID 7f3c0505… → Grondaia_035 due volte, con release() e cache svuotata in mezzo.
  • Se il motivo era la forma o il «gia' preso», le lettere dell'handle si tengono (ripulite, tagliate a 12) — Pippo Re 99! → PippoRe99_080. Se era il filtro, non ne sopravvive nessuna: si pesca da 24 parole del mondo del gioco (Coperta_080, Zerbino_068). ⚠️ E non si dice al giocatore perche': il nome che porta in giro su un'altra piattaforma non e' affar nostro spiegarglielo.
  • ⚠️ Il registro muto resta fail-closed: se il server tace, nessun nome viene prodotto. Il nome di riserva non e' un permesso di saltare il registro.
  • 📌 Due buchi trovati leggendo, che il ticket non nominava. (1) set_account_login() riscriveva account_display_name con l'handle a ogni accesso: con account_name_claimed ancora vero dall'accesso prima, un handle gia' respinto dalle porte sarebbe passato dal gate. Ora l'handle grezzo sta da parte in account_provider_handle. (2) La rivendicazione si rifa' a ogni login, quindi chi aveva preso un nome di riserva e poi se l'era cambiato in «Ivan_99» se lo vedeva sostituire da Zerbino_068 a ogni ingresso, in silenzio (_has_own_name).
• [feature] SU-506 — la schermata del nome si sblocca. _nome_is_epic() blocca il campo solo se il nome viene davvero dal canale: una riga, e ne discendono campo scrivibile, regole di nuovo visibili, proposta modificabile e fuoco sul campo. Il flag resta vero per sempre (decisione di SU-470): l'handle Epic e' gia' stato dichiarato inutilizzabile, rimetterlo in gabbia sarebbe una seconda porta chiusa.
  • Tre frasi di corpo, non due: il design diceva «caso forma = stessa cosa del 3.2», ma quel corpo recita «era gia' occupato», che nel caso forma sarebbe una bugia. 6 chiavi nuove, 8 lingue verificate a runtime (non solo scritte nel CSV: tr() le restituisce da tutte e otto). Audit emoji 0.
  • La propagazione a EOS ora guarda il canale, non il flag: con un nome di riserva sarebbe partita una chiamata che su Epic non ha leva.
• [test] SU-507 — la prova che il vicolo cieco e' chiuso. probe_su446_nome.gd esteso ai tre casi che finivano nel nulla: 82 controlli nella sonda + 16 lato server, zero KO. preso → SU446Altrui_068, forma → PippoRe99_068, filtro → Zerbino_068: in tutti e tre account_name_claimed true e gate GATE_OK. ⚠️ Il quarto caso e' il controllo che dimostra che la sonda sa fallire: col registro muto resta tutto falso (no_public_name), e della parola respinta non resta traccia ne' in richieste.log ne' in registro.json.
• ⚠️ Cosa NON e' stato provato: nessun login Epic vero (su questo Mac l'account EOS e' anonimo). Restano da vedere su device gli handle Epic reali, refresh_display_name, e il rientro dopo un cambio handle su Epic — che e' l'unico modo per cui il flag torna false. Il registro e' sempre nick_test_server.py, mai l'endpoint di produzione. Nessuna prova in multiplayer vero.
• 📌 Da decidere, non deciso qui: quando l'handle Epic torna buono, oggi il nome pubblico ridiventa l'handle e il campo si richiude — e' la lettera del §3.6, ma sovrascrive un nome che il giocatore poteva essersi scelto. E ACCOUNT_ESITO_HANDLE_PRESO e' ora irraggiungibile (il nome di riserva interviene prima): lasciata come rete, candidata alla rimozione.

SU-543: la luce del tunnel torna incollata al barbone, e si spegne sulla banchina2026-08-24

• [fix] SU-543, secondo giro — KO di Ivan (2026-08-23): «ripristinare per ora la luce precedente senza muoverla in base alla lanterna, e spegnerla appena va a contatto con la banchina perche' si sale sulla banchina e li' non serve». Il primo giro aveva consegnato due cose insieme: l'alone a gradini (la pixel art, chiesta dal ticket) e la lanterna in mano presa dal Player della citta', con l'alone centrato su di lei invece che sul busto. Ivan ha bocciato la seconda, non la prima — i 5 anelli restano, torna indietro solo il movimento.
  • _costruisci_lanterna() non viene piu' chiamata (_costruisci_runner): _lanterna resta null, sottoterra non c'e' nessuna lanterna in mano. La funzione non e' stata cancellata, solo scollegata — «per ora», come dice il KO — e il blocco che la posiziona dentro _aggiorna_luce() resta scritto, dichiarato codice morto nei commenti. Il giorno che la lanterna torna, si riaggancia da li'.
  • L'alone torna all'offset storico fisso (0,-8), indifferente a verso e flip.
  • Lo spegnimento sulla banchina sta in _entra_in_banchina(), ed e' secco e definitivo: da Fase.BANCHINA non si torna mai in CORRIDOIO, quindi non serve riaccenderlo da nessuna parte.
  • ⚠️ Effetto collaterale del requisito, da sapere: il criterio del ticket «nella salita sul treno si comporta come oggi (dissolve con quota)» non e' piu' osservabile. La dissolvenza di _passo_imbarco() e' intatta e non e' stata toccata, ma quando ci si arriva l'alone e' gia' invisibile da un pezzo: non ha piu' niente da dissolvere. Non e' una regressione, e' la conseguenza diretta di quello che Ivan ha chiesto.
  • Costo: draw call 11,6 → 10,8, contro i 10,7 di baseline pre-SU-543 — cioe' il +0,9 del primo giro era esattamente la lanterna, e se n'e' andato con lei. 8,29 ms/frame su 240 frame misurati. ⚠️ fps su telefono NON presi: qui non c'e' un telefono, e gli fps a finestra su questo Mac mentono comunque (il compositore li cappa).
  • Prove guardate: TMP/su543_ko2/ — corridoio con l'alone a gradini e nessuna lanterna in mano, piede sulla banchina con la luce gia' spenta, salita in carrozza. Sonda nuova scripts/tools/shot_su543_ko2.gd + tools/autotest/probe_su543_ko2.sh, clonate da shot_su545_su543.gd. Rilanciata anche la sonda del primo giro: scarto alone-barbone costante (0,-8) a 25/50/75/99% del corridoio, mai legato al verso.

SU-545/543: il tunnel non e' piu' tagliato su iPhone, e la luce del barbone e' pixel art2026-08-23

• [fix] SU-545 — la camera adatta lo zoom all'altezza logica vera: zoom = min(CAM_ZOOM, h_logica / 304). Su iPhone il binario basso, il treno e la targa BONUS STAGE uscivano dallo schermo.
  • 📌 La causa non era la forma dello schermo. Con canvas_items+expand il fattore di scala e' il minimo dei due rapporti, quindi su qualunque schermo piu' largo di 4:3 comanda l'altezza e l'altezza logica resta 768 (misurato identico a 844×390 e a 2556×1178). Il colpevole e' content_scale_factor — l'opzione DIMENSIONE TESTO — che divide le unita' di tutto il canvas, camera compresa. ⚠️ E su telefono l'AUTO vale gia' 1,3 (VirtualControls._auto_text_scale, SU-317): il taglio era la condizione normale di un iPhone, non un caso limite.
  • I numeri, altezza di mondo visibile prima → dopo: a 1,0 307,2 → 307,2 (identico, niente cambia dove non c'era da aggiustare); a 1,3 236,3 tagliato → 304,0 dentro; a 1,5 204,8 tagliato → 304,0 dentro. In orizzontale su telefono si passa da 511,4 a 657,9 px di tunnel a 1,3, e da 443,2 a 657,9 a 1,5. Il 304 e' la fascia targa→ruote presa simmetrica attorno a CAM_Y piu' 8 px di respiro, ed e' calcolato invece che scritto a mano perche' «chi vince fra alto e basso» e' gia' cambiato una volta con SU-489.
  • ⚠️ Il paletto e' stato rimisurato, ed era la trappola del ticket: preavviso 2,800 s, invariato — i chevron nascono sulla x del barbone e la inseguono, quindi sono in campo dal primo fotogramma a qualunque zoom. Cambia solo quando si vede il *treno*: da 0,267 a 0,333 s, cioe' 66 ms di avviso in piu', mai in meno. Dettaglio che dice quanto era al limite: a 1,3 la fila di chevron della corsia bassa stava a 0,2 px dal bordo inferiore; ora ne ha 34.
• [change] SU-543 — l'alone del barbone e' pixel art, e la lanterna scende con lui fino alla banchina. Il gradino viene dalla texture, come impone il vincolo del livello (niente luci 2D, niente shader: gira su telefoni vecchi con soli Sprite2D in additivo).
  • Da GradientTexture2D 128×128 con 64 livelli d'alfa a una Image disegnata ad anelli quantizzati, 65×65 a ×4 NEAREST con 5 livelli (0,90/0,70/0,50/0,30/0,10). ⚠️ Lato forzato dispari: altrimenti il centro cade fra quattro texel e gli anelli escono ovali.
  • La lanterna non e' stata ridisegnata: lo sprite si prende dal nodo Lanterna del Player della citta' e le ancore per direzione si leggono da Player.LANTERNA_ANCORE — numeri gia' ritarati tre volte in SU-230, e una copia qui sarebbe stata la quarta destinata a restare indietro.
  • 📌 Onesta' su cosa era gia' vero: la luce arrivava fino in fondo anche prima (scarto costante (0;−8) su 7 tappe misurate). Il pezzo davvero consegnato di quel punto e' la lanterna in mano, e l'alone ora e' centrato su di lei.
  • Costo: draw call 10,7 → 11,6 (quel +0,9 e' la lanterna), oggetti 17,9 → 17,7, texture 16.384 → 4.225 texel. ⚠️ fps su telefono NON presi: qui non c'e' un telefono, e gli fps a finestra su questo Mac mentono comunque.
• Regressioni verdi, rilanciate anche dall'orchestratore: probe_su541 8/0, probe_su542 6/0, probe_su551 9/0, e probe_su491_metro 24/0 (quella che ricava la mezza schermata dallo zoom vero, la piu' esposta a questo cambio). Compile-check 0 falliti.
• Due trappole nuove, scritte nei commenti: scrivere content_scale_factor a mano non tiene (emette size_changed e VirtualControls lo rimette — sei scatti «a 1,30» erano girati tutti a 1,00), e lanciare il treno di prova sulla corsia del barbone lo investe, lasciando girare il resto della sonda su un livello morto senza una riga d'errore.
• ⚠️ Preesistente, non introdotto qui: al primissimo istante del corridoio il bordo sinistro arriva a −169 px mentre il tunnel e' disegnato da −160, cioe' ~9 px di fondo nero (12 su telefono a 1,0). Se da' fastidio si allargano a sinistra le strisce di _costruisci().

SU-567/568: il tunnel esce dal tutorial, e nei negozi si puo' finalmente comprare2026-08-23

• [change] Sei rifiniture al tutorial, chieste da Ivan guardandolo girare poche ore dopo SU-552.
  1. Le vite non sono piu' «testine»: da SU-550 sono cuori, e il testo lo dice — in tutte e 8 le lingue. ⚠️ Il gatto resta dov'e' giusto («hai NOVE VITE, come un gatto»): cambia solo la parola che descrive cosa si vede a schermo.
  2. Via il RICERCATO: il tutorial indicava «in alto a destra il livello di RICERCATO», ma quella barra e' stata tolta dall'HUD con SU-339 — il calcolo resta in GameState.wanted_level, a schermo non c'e' niente. Il tutorial insegnava a guardare una cosa che non esiste.
  3. Il tunnel esce dal tutorial: «deve essere una sorpresa». Via la stazione, la scheda, il treno e le due chiavi CSV — aggiunte stamattina da SU-552 e rimosse in giornata, il che va benissimo: il tutorial e' un pezzo di design, non di codice, e si guarda per deciderlo. ⚠️ Le lattine no: servono per la Baracca, e sono finite alla banca, che e' gia' il punto dove il gioco spiega che i soldi avanzati diventano lattine.
  4. Via il bidone dorato gigante (BIN_GOLD_SCALE 1.7) e via l'affermazione che il bidone d'oro «sta in fondo al tunnel»: non e' piu' vero. Il commento che lo dichiarava e' stato riscritto, non cancellato.
  5. L'ultimo bidone della fila e' dorato, di dimensione normale e apribile come gli altri: si impara a riconoscerlo senza che gli si dica dove trovarlo.
  6. Via il vecchio pulsante MAPPA a schermo. Era dell'HUD ma compariva solo nel tutorial (_map_button.visible = forced or _is_in_tutorial() → forced): un indizio rimasto indietro da quando la mappa e' passata sul tasto B dei controlli virtuali. Corretto di conseguenza anche il testo che indicava quel pulsante.
  7. Durata: 203,4 s → 194,4 s, stazioni 24 → 23. Il finale che sale sulla metro non e' stato toccato (8 controlli, 0 KO): il tunnel che esce e' la *stazione informativa*, non la fermata finale — sono due cose diverse.
• [fix] SU-568: nel tutorial si partiva sazi, e i negozi rifiutavano la vendita. Ivan: «nel tutorial ora sei gia' sazio e non puoi comprare roba nei negozi». Le barre partivano piene (voluto: nessuno deve morire mentre impara), ma il gioco rifiuta l'acquisto a barra piena — regola giusta in partita, che pero' rendeva impossibile proprio il gesto che il tutorial insegna.
  • 📌 Servivano tutte e due le strade, e il perche' e' interessante: abbassare la barra iniziale non bastava, perche' dentro un blocco i negozi sono tre in fila e il primo la rimette a 100 (l'hot dog fa eat(100)) — il secondo e il terzo tornerebbero a rifiutare. Quindi STAT_INIZIALE = 60 (la barra si riempie, ed e' la conferma visiva del gesto) piu' il rifiuto disattivato quando il tutorial e' attivo. 60 sta sopra la soglia degli avvisi (50) e sopra quella dell'elemosina, e con run_active=false non si puo' perdere.
  • ⚠️ Difetto trovato in fotografia, non dalle sonde: HUD._refresh_stats e' agganciato solo a stats_changed, che il tutorial non emetteva. A barre piene non si notava; a 60 l'HUD mostrava barre piene su statistiche non piene. Aggiunto l'emit.
• Sonde rilanciate dall'orchestratore: giro completo ARRIVATO IN FONDO (23 stazioni, 194,4 s), finale 8/8, negozi 8/8 — tutti e cinque i punti a pagamento comprano, e togliendo il gruppo «tutorial» lo stesso oggetto torna a dire «sei gia' sazio». Compile-check 4/4. Nessun residuo di tunnel, ricercato o testine in nessuna delle 8 lingue (verificato con grep, non solo sull'italiano).
• ⚠️ Non provato: il nuovo testo touch della mappa non e' mai stato visto a schermo — is_touch e' falso in headless, quindi va guardato su telefono o iPad.
• 📌 Rimessa a zero una regressione dell'audit emoji introdotta poche ore prima: il provino di SU-566 conteneva un carattere ♥ in un commento e in una print. Non era un testo di gioco, ma l'audit contava 1 — e un audit che non torna a zero smette di essere guardato. ⚠️ L'audit va rilanciato dopo OGNI lotto, anche quando il lotto non tocca testi: qui era passato inosservato perche' il commit precedente non l'aveva rifatto.

SU-566: banca e chiesa sulla cartina, e la legenda impara a stare nella carta2026-08-23

• [feat] Due icone nuove sulla mappa. Ivan: «ci vanno le icone banca (simbolo del dollaro, vedi te se abbellire) e chiesa (non simbolo religioso, farei simbolo cuore visto che ti curi)».
  • Banca: una moneta dorata col $, con anello interno e lucore per non essere un disco piatto. ⚠️ Non e' un'aggiunta ma una sostituzione: la banca un'icona ce l'aveva gia' — era *la texture del landmark*, cioe' l'edificio (scelta di SU-249). Il commento che difendeva quella scelta e' stato riscritto, non cancellato.
  • Chiesa: un cuore rosso con contorno scuro, ombra sotto e luce in alto. 📌 Niente simboli religiosi, ed e' una scelta scritta: li' ci si cura, quindi il simbolo e' un cuore. Vale anche se un domani l'icona si rifa'. La chiesa non aveva icona perche' Type.CHURCH e' nato la mattina stessa con SU-548 e nessuno l'aveva collegato alla cartina.
  • Le due icone sono disegnate a mano, 20×20 come le altre di mappa, nello stile che c'era gia': forma piena, contorno scuro, nessuna sfumatura. La moneta e' volutamente distinguibile dal rombo verde della metro, che era il rischio.
  • Aggiunto CHURCH anche a ENTRANCE_TYPES: senza il ricentraggio sul blocco l'icona sarebbe fluttuata sul sagrato invece che sopra la chiesa — lo stesso difetto che SU-249 aveva gia' risolto per la banca.
• ⚠️ [fix] La tredicesima voce faceva traboccare la legenda, e il primo giro l'ha mostrato. Nello scatto la riga «Chiesa» finiva fuori dall'area carta, col bordo decorativo della pergamena che le passava attraverso. La causa non era la chiesa: la legenda reggeva 12 voci e ora sono 13.
  • Non e' stata spostata la riga: il passo verticale (icona + font + separazione) ora si scala sullo spazio disponibile e viene ricalcolato a ogni apertura e a ogni resize. Scartate le due colonne, che avrebbero dimezzato i 210 px di larghezza — gia' stretti per le traduzioni lunghe («Fermata bus (riparo)», il tedesco, il russo) — e scartato il font fisso sotto soglia, che avrebbe solo spostato il problema alla voce dopo.
  • Numeri misurati: scala 0,772 a tablet (397,8 px disponibili) e 0,831 a telefono (423,9 px). 📌 Sorpresa verificata: il caso piu' stretto e' il TABLET, non il telefono — con lo stretch canvas_items+expand la finestra telefono tiene l'altezza logica ancorata alla base e la pergamena la sfrutta tutta, mentre a tablet la pergamena e' vincolata in larghezza dall'aspect 3:2. Il pavimento (LEGEND_SCALE_MIN 0,62) si tocca a ~16 righe: tre voci di margine prima che torni a traboccare, e sotto quella soglia si preferisce che trabocchi piuttosto che rendere il testo illeggibile.
• Provino nuovo shot_su566_mappa.gd (non esisteva un provino della cartina): apre MapOverlay davvero su una citta' generata col seme 424242, che ha sia banca sia chiesa. Scatti guardati a tablet e a telefono — TMP/su566/su566_mappa_tablet.png, su566_mappa_telefono.png. Chiave MAPPA_CHIESA in tutte e 8 le lingue.
• ⚠️ Non provato: una cartina con bidone d'oro E chiesa insieme; e il conteggio a ~16 righe dal vivo (servirebbero POI finti — il numero viene dalla formula usata a runtime, non da un provino).

SU-552: il tutorial insegna la citta' di adesso, e finisce salendo sulla metro2026-08-23

• [feat] Quattro stazioni nuove e due novita' innestate in stazioni che c'erano gia'. Il tutorial insegnava il gioco di parecchi mesi fa.
  • Stazione propria (non c'era un parente): banca, chiesa, tunnel bonus + lattine, metro. Dentro una stazione parente: i bidoni d'oro dentro BIDONI e il riparo/meteo dentro PIOGGIA, con la chiave accodata e senza toccare il testo gia' tradotto.
  • ⚠️ Il riparo va su PIOGGIA, non su PANCHINA, ed era la trappola scritta nel ticket: Ivan aveva detto «sotto la panchina», ma il riparo vero e' la pensilina (ShelterZone); la panchina serve a riposare. Le due stazioni erano gia' separate.
  • Del bonus stage si parla soltanto, come deciso: una scheda che dice che esiste e come funziona, nessun assaggio giocabile. Nel tutorial il bidone d'oro e' un cartonato che non si apre, con la battuta a dirlo.
• [change] Il tutorial non finisce piu' con un cancello FINE: finisce alla FERMATA DELLA METRO. L'ultima stazione chiede di salire, ed e' anche il modo in cui insegna a prenderla. La dissolvenza non e' stata inventata: si riusa il passaggio citta'-metro-quartiere che il gioco ha gia', e si sbuca sul velo di caricamento di SU-544, che era stato lasciato richiamabile apposta.
  • Per riusarlo davvero e' servito toccare un file condiviso: World.metro_ride() e' diventata la statica metro_ride_da(host, …) (World.gd:7540), col metodo d'istanza che delega in una riga — TutorialWorld non eredita da World, e l'alternativa era una seconda dissolvenza uguale, che il ticket vieta. I chiamanti vecchi continuano a funzionare (verificato: shot_su480_metro.gd usa ancora metro_ride).
• 📌 Una cosa che il ticket dava per vera e non lo era piu'. La descrizione diceva «a 100$ scatta il bidone d'oro e l'arcobaleno dice dov'e'»: da SU-466 il premio della banca e' l'arcobaleno verso una fermata, e il bidone d'oro sta in fondo al tunnel. Le schede sono state scritte sulla catena vera — banca → arcobaleno → fermata → tunnel → lattine — invece che su quella del ticket. ⚠️ Un ticket puo' invecchiare fra quando lo si scrive e quando lo si lavora: e' la seconda volta oggi (l'altra e' SU-546, dove le musiche erano state sostituite).
• I numeri chiesti: stazioni 20 → 24, schede 15 → 19 (pannelli 17 → 21), durata 169,5 s → 203,4 s (+20%), di cui 76,1 s di camminata e 127,3 s di schede. 11 chiavi nuove × 8 lingue, nessuna colonna vuota (verificato a parte).
• Sonde rilanciate dall'orchestratore: durata ESITO ARRIVATO IN FONDO (24 stazioni, 203,4 s), finale 8 controlli 0 KO — il cancello FINE non esiste piu', la scheda della fermata si vede una volta sola, premendo il tasto d'uso si sbuca su Main.tscn, e lo skip dal menu di pausa porta ancora al livello vero. Compile-check 3/3, audit emoji 0.
• ⚠️ Non provato, ed e' la cosa che manca davvero: la galleria del viaggio non e' stata vista girare. In headless metro_ride_da salta l'animazione per costruzione, quindi e' verificato solo che la catena arrivi a Main.tscn. Va guardata a mano: avvia il tutorial, corri in fondo, premi E. Da controllare anche tedesco e russo sul pannello del telefono: i testi nuovi sono lunghi.

Il cuore vuoto ha un bordo solo, crema2026-08-23

• [change] vita_cuore_vuota.png rifatto: un solo contorno crema, via il nero. Ivan, guardandolo in gioco: «i cuori vuoti falli solo con un bordo crema, non due, secondo me stanno meglio».
  • Prima erano due bordi — nero interno (l'anello ereditato dalla piena) piu' l'alone panna aggiunto per farlo leggere di notte. Ora il vuoto e' il contorno della sagoma della piena, tutto in crema: 30 pixel, alfa binaria.
  • ⚠️ Il prezzo, misurato e mostrato: con un bordo solo, su fondo chiaro il cuore vuoto sparisce (provino TMP/su549_bordo_singolo.png, prima riga). Su strada e di notte si legge benissimo, e in gioco la fila sta sopra palazzi e asfalto — verificato sullo scatto vero, TMP/su550/su550_fila_ingrandita.png. Resta il caso da tenere d'occhio: HUD sopra una superficie chiara.
• ⚠️ Trappola ripagata a metа': i .ctex non c'erano. Il primo giro di provino e' uscito senza le texture — nove scatti apparentemente buoni con i cuori invisibili, e nel log solo tre righe di Failed loading resource. Il compile-check non reimporta, e il provino da solo nemmeno: serve godot --headless --import prima. Vale ogni volta che si tocca un PNG gia' importato.

SU-548 rifatto: sopra la chiesa il contatore in cifre, e il cuore diventa un volo2026-08-23

• [fix] Rilavorazione di un KO di Ivan: «mi serve i soldi versati / soldi totali sopra la chiesa, una volta versati tutti vola in aria un cuore e basta».
  • 📌 Cosa era stato capito male, ed era colpa del ticket, non di chi l'ha implementato: la descrizione diceva «al posto del contatore in cifre della banca, un cuore grosso». La prima lavorazione ha fatto esattamente quello — un cuore-insegna permanente che si riempiva come una barra — e aveva pure dovuto spostarlo sulla torre campanaria perche' sul colmo usciva dallo schermo. Ivan voleva l'opposto: sopra la chiesa lo stesso oggetto della banca, cioe' le cifre, e il cuore solo come animazione al traguardo.
• Due mestieri, due file, invece di un oggetto che fa entrambe le cose:
  • ChurchCounter.gd (nuovo) — extends Label, gemello ricalcato di BankCounter.gd. Scrive 30/100$ e cambia colore a chiesa chiusa (schema SU-494). ⚠️ Si aggancia anche a stats_changed, perche' le vite non passano da church_changed e altrimenti il numero non si accorgerebbe di essere diventato inutile.
  • ChurchHeart.gd (riscritto da capo, nome e .uid invariati) — sopravvive ma cambia mestiere: non e' piu' un'insegna, e' il volo. Zero figli a riposo, e al fronte di salita di church_lives_given parte un cuore che sale, ondeggia e sfuma. Il volo e' ricalcato da Player._spawn_broken_heart_sprite (SU-306), cioe' dall'animazione che gia' esiste per quando una vita si *perde*: stesso gesto, senso opposto.
  • Scartato un segnale nuovo church_life_granted: il fronte di salita su un campo che c'e' gia' costa zero contratti nuovi, e church_changed viene gia' emesso dopo l'incremento.
• Due correzioni fatte guardando gli scatti, non a occhio — sono la ragione per cui su un KO di resa il provino non e' negoziabile:
  • il contatore non appoggia sul colmo come fa quello della banca: a zoom 2,5 lo schermo copre 154 px di mondo sopra il barbone e il colmo della guglia sta esattamente a 154, quindi sarebbe finito dietro la fila delle vite dell'HUD. Sta a quota 0,20.
  • il volo e' stato accorciato dopo il primo giro: partendo da mezza facciata con 72 px di salita il cuore finiva dietro la barra «LIV 1» mentre era ancora opaco. ⚠️ L'HUD e' un CanvasLayer: nessun z_index lo scavalca. Ora parte dal portone (0,88) e sale 62 px.
• Sonda probe_su548_chiesa.gd ESITO OK, 6 criteri 0 KO, rilanciata anche dall'orchestratore: i cinque vecchi tengono, e il sesto conta i voli — 0 a $90, 1 a $100, 0 nelle tre pressioni successive, 0 a chiesa chiusa — e verifica che il nodo del cuore abbia zero figli a riposo, cioe' che l'insegna non sia tornata di soppiatto. Nove scatti in TMP/su548/, guardati: su548_2_contatore_meta mostra 50/100$, su548_4_chiesa_chiusa il numero grigio col prompt sparito da solo, su548_5_cuore_a/b/c/d lo stesso volo a quattro istanti (portone → sopra il tetto → campanile → dissolto).
• Resta valido e non e' stato ritoccato: soglia fissa a $100, offerta a pressioni con scaglione da $10, offerta parziale versata, chiesa chiusa a nove vite, zero RPC nuovi, la vita riscossa dentro church_offer_money().
• ⚠️ Rischio noto: il numero resta *sospeso* poco sopra la croce del campanile invece di appoggiarci. Si abbassa con CONTATORE_CHIESA_QUOTA, ma sopra 0,32 comincia a coprire la croce dorata.
• ⚠️ Non provato: il volo con GRAFICA LEGGERA accesa (il ramo c'e', toglie l'ondeggio), una run MP a due peer davanti alla stessa chiesa, una citta' dove la chiesa cade «in fila» su lotto stretto, telefono e tablet veri.

SU-550: le 9 vite sono cuori, in gioco2026-08-23

• [change] HUD.LIFE_TEX_FULL/LIFE_TEX_EMPTY puntano ai cuori. I due PNG importati in assets/sprites/ui/, mipmap spente; il filtro NEAREST era gia' sul TextureRect in codice, quindi l'import non lo tocca. Le teste di gatto restano su disco: si torna indietro cambiando due stringhe.
  • La vuota e' la variante col bordo panna, scelta da Ivan («proviamo contorno panna») dopo il confronto affiancato: col solo contorno nero il cuore vuoto spariva sul cielo notturno.
  • _lives_row_width() = 320,0 prima e dopo (9×32 + 8×4): il criterio chiedeva che la fila non cambiasse larghezza, e infatti l'unica modifica sono due path.
• 📌 tools/import_icone_vite_super.py non e' stato toccato, ed e' la scelta giusta: e' lo script di SU-231, che parte da sorgenti 256 px in sprites_raw/UI/temp/ e le riduce; qui i sorgenti sono gia' nativi 16×16, quindi serviva una copia, non una pipeline.
• ⚠️ Trappola trovata e scritta: un sync_proj «nudo», senza ensure_import, fa un rsync --delete che rispecchia il .godot/imported/ reale del repo (che esiste su disco perche' Ivan ci lavora con l'editor, benche' gitignored): i due .ctex nuovi sparivano dalla copia di prova, dando un falso «icone non trovate».
• Scatti guardati: TMP/su550/su550_hud_9_vite.png e su550_hud_4_vite.png (+ i ritagli *_row.png) — 9 pieni, poi 4 pieni e 5 vuoti, bordi netti.
• ⚠️ Non provato: tablet 1024×768, device reali, e la carta «NOVE VITE» (usato GameState.lose_life() diretto, come indica il ticket).

SU-541/542/551: nel tunnel la prima ESC apre la pausa, le frecce muoiono sul treno, e i treni corrono di piu'2026-08-23

• [fix] SU-541 — la prima pressione di ESC apre il menu di pausa. La causa non era nel tunnel. Riprodotta prima di toccare il codice: la prima ESC lasciava in_pausa=false ma paused=true. Il colpevole e' HUD.gd:557, che si da' PROCESS_MODE_ALWAYS — e ALWAYS scavalca il PROCESS_MODE_DISABLED che il congelamento mette sul World. L'HUD resta sveglio, intercetta ESC, accende il proprio pannello dentro un CanvasLayer che il congelamento ha reso invisibile; l'input arriva prima dei _process e il tunnel e' INHERIT, quindi con l'albero appena messo in pausa quella pressione il livello non la vede mai. La seconda ESC toglieva la pausa dell'HUD e il tunnel ripartiva.
  • ⚠️ Il commento in testa al blocco pausa diceva l'esatto contrario («un nodo disabilitato non riceve _unhandled_input»): corretto sul posto, perche' e' la trappola che aveva gia' fatto perdere il primo giro su questo tasto (il 22/08 ESC *finiva il livello*).
  • Cura in un file solo: BonusLevel._input() (:1146) prende pause/ui_cancel nella fase _input, prima di GUI e _unhandled_input, e consuma sempre l'evento finche' il tunnel e' aperto — anche quando la risposta e' «no» (intro, outro), perche' lasciarlo passare vuol dire regalarlo all'HUD. Scartato lo spegnere l'HUD dentro _congela_superficie(): la cerimonia delle carte vive nel sottoalbero del World e si sarebbe spenta con lui.
• [fix] SU-542 — le frecce si spengono su una POSIZIONE, non piu' a tempo. Via manca <= -0.6, dentro treno.position.x <= fila.position.x + CHEVRON_PRIMO_DX (_aggiorna_avvisi(), :2392). I tre numeri della fila sono diventati costanti (:2319) perche' il criterio li legge. Misurato: 33 file morte sul chevron, scarto medio 10,04 px e peggiore 14,56 contro un fotogramma di treno di 14,2 px; vita della fila 2,905 s contro i 3,40 di prima.
• [change] SU-551 — mai piu' di due treni di fila sulla stessa corsia, e il tunnel corre di piu'. Il tetto di due c'era gia' e veniva scavalcato: _scegli_corsia() contava le ripetizioni, ma subito dopo _lancia_treno() riscriveva la corsia per l'ultimo tratto, e il contatore veniva aggiornato prima, sulla corsia *scelta* e non su quella davvero usata. Ora _scegli_corsia() (:1930) decide tutto, override compreso; la riga in _lancia_treno() (:1990) resta come rete per i chiamanti esterni.
  • 📌 Onesta' su cosa cambia davvero: in un giro normale quel punto non cambia lo spettacolo, cambia solo cosa il contatore *crede*. Si vede quando il progresso torna sotto la soglia — il barbone puo' camminare a sinistra — e la sonda lo prende li': rimessa la vecchia _scegli_corsia(), 2 criteri su 9 diventano KO; rimessa la nuova, 0.
  • Numeri nuovi: velocita' 700 → 850 px/s, intervallo 3,9→2,3 s diventa 3,4→2,15 s, jitter ±0,35 → ±0,30. Treni per giro da 14 a 15-16.
  • ⚠️ Il paletto e' stato rimisurato, non stimato: cammino libero dopo il cambio di corsia 1,556 s — invariato, perche' non dipende ne' da velocita' ne' da frequenza ma solo da PREAVVISO_TOT (2,8 s, intatto) e dalla larghezza della corsia. Transito del treno 0,593 s contro un intervallo minimo di 1,85 s: 3,1× di margine, erano 2,7×. Arrivo in banchina 5 giri su 5, il piu' lento a 51,6 s sul limite di 60 (8,4 s di margine, erano 9,7).
• Sonde nuove, rilanciate dall'orchestratore: probe_su541.sh 8/8, probe_su542.sh 6/6, probe_su551.sh 9/9, piu' le regressioni probe_su491.sh (39 criteri) e probe_su491_pausa.sh 16/16. Compile-check 0 falliti, audit emoji 0.
• ⚠️ Resta aperto, fuori perimetro: l'HUD non ruba piu' ESC, ma il suo _process continua a sondare Input.is_action_just_pressed("map") (HUD.gd:933) anche nel tunnel — il tasto mappa apre MapOverlay, che mette in pausa l'albero dentro un CanvasLayer nascosto. Stessa famiglia di difetto, stessa firma: la cura sta in HUD.gd/MapOverlay.gd e vuole un ticket suo.
• ⚠️ Non provato: come si *sente* il tunnel a 850 px/s (serve un giro di Ivan, le sonde non possono dirlo); il pulsante di pausa del tocco e' provato con debug_force_touch, non con un dito vero; nessun provino grafico dei chevron che si spengono; MP non toccato e non provabile (il bonus e' rifiutato in multiplayer).

SU-544: il velo di caricamento mostra i personaggi, e la musica non parte piu' un frame prima2026-08-23

• [change] Il velo a inizio partita ha per sfondo l'immagine dei personaggi, la stessa dell'avvio dell'app, con sopra la scritta tradotta di caricamento. Ivan l'ha chiesto ribaltando una scelta scritta: la nota «NIENTE IMMAGINE» in LoadingVeil.gd e' stata tolta e sostituita, non cancellata di nascosto.
  • Il secondo motivo di quella nota restava valido e si e' risolto senza rinunciare a niente: decodificare un PNG 1941×810 nel frame in cui si sta risparmiando tempo sarebbe stato assurdo, quindi la texture non si rilegge dal disco — Boot.gd:112-129 guadagna static func splash_texture() con una cache statica che sopravvive alla morte del nodo Boot, e sia l'avvio sia il velo passano da li'. Un solo punto che carica assets/ui/splash.png in tutta la sessione.
• 📌 Cercando la musica e' saltato fuori un difetto di sincronia vero, che nessuno aveva notato. Con FRAMI_SOTTO_IL_VELO = 2 c'era un frame intero in cui la musica del mondo era gia' partita e il velo copriva ancora lo schermo (misurato: 0,013 s contro 0,024 s, due frame separati). La causa: il ciclo che rileva il cambio scena consuma un frame che il coroutine della musica non consuma. Portato a 1: velo-giu' e musica-parte cadono ora nello stesso frame, e il riscaldamento shader di SU-484 resta comunque coperto.
• Numeri, a cache calda come nel gioco vero: caricamento nativo 923-1055 ms, col velo 1049-1073 ms, cioe' 28-58 ms di sovrapprezzo — in linea con i 57 ms storici di SU-537 e nessun allungamento imputabile all'immagine. La musica del menu continua sotto il velo per tutto il caricamento (comportamento di prima, non toccato) e a velo alzato non resta nessun suono di troppo.
• Continuita' verificata a vista su TMP/su544_continuita/3_affiancato.png (scatto vero: Boot.tscn → menu → avvio partita): stessa immagine, stesso crop, stessa scala, stessa banda scura — cambia solo il testo, LOADING fisso all'avvio contro CARICAMENTO... tradotto nel velo.
• Lasciato richiamabile da un'altra transizione, come chiede la nota di collegamento di SU-552: LoadingVeil.go_to_scene(tree, scene_path) non fa nessuna assunzione su chi lo chiama, quindi il tutorial che finira' con la metro potra' sbucare qui senza una seconda schermata.
• ⚠️ Non provato: MP a 2+ peer, device reale, e il layout a telefono/tablet (la formula e' identica a quella di Boot, gia' validata altrove, ma qui non e' stata riscattata). Il secondo chiamante non esiste ancora: nasce con SU-552.

SU-548: la chiesa si usa, e 100$ di offerta ridanno una vita2026-08-23

• [feat] La chiesa smette di essere un edificio-landmark e diventa interattiva come la banca. Ivan: «se doni 100$ ti ridà una vita, cuore grosso sopra la chiesa stile moneta». Offerta a pressioni con scaglione da $10, cuore grosso sopra la torre che fa da insegna e da registro, edificio che chiude quando non ha piu' niente da dare (schema dello sportello a cassa colma, SU-494). [NOVITA']
  • GameState.gd:1573-1699 blocco church_*, segnale a :25, reset a :432 · Interactable.gd Type.CHURCH in coda all'enum :18, _chiesa_e_chiusa() :2520, _use_church() :2528 · WorldGenerator.gd _piazza_chiesa_interattiva() :4923 e _piazza_cuore_chiesa() :5128 · ChurchHeart.gd nuovo · 6 chiavi × 8 lingue in ui_mondo.csv, nessuna stringa a codice.
  • Soglia fissa a $100, non raddoppia a ogni giro come in banca: la vita e' un consumabile, non un premio a scalare.
  • 📌 Scartato restore_lives_from_sleep(), che era la strada indicata dal ticket: darebbe 3 vite invece di una e disarmerebbe il flag «notte fuori» di SU-310. In chiesa non si e' dormito. La vita si riscuote dentro church_offer_money() e non nel chiamante, cosi' DebugPanel e sonde non possono riempire l'offerta senza consegnarla.
  • L'offerta parziale resta versata, ed e' una scelta scritta: la banca insegna gia' che versare e' irreversibile, e una chiesa che restituisce gli spiccioli insegnerebbe la regola opposta nello stesso gioco. L'avanzo sotto soglia a fine run non si converte in lattine — e' un'offerta, e convertirla avrebbe toccato il tabellone di fine partita.
• ⚠️ Il cuore non poteva stare sul colmo del tetto, ed e' la cosa da far validare a Ivan. Misurato: a zoom 2,5 lo schermo copre ~157 px di mondo sopra il barbone, e la chiesa dal sagrato ne e' alta 154 — sul colmo ne restavano visibili 14 su 80, il resto sopra il bordo alto e dietro la fila delle 9 vite dell'HUD. Sta quindi a CUORE_CHIESA_QUOTA = 0.68, sulla torre campanaria: copre la nicchia della campana, la croce resta visibile sopra.
• Il cuore e' disegnato in codice, non ritagliato da broken_heart_sheet.png. Misurato prima di provarci: li' dentro il cuore e' 7×7 px, ha una crepa di pixel scuri che lo taglia in due per tutta l'altezza ed e' un cuore *rotto* di mestiere; sul fianco destro i grigi dell'ala gli entrano dentro. Erano tre toppe su un disegno da buttare. La texture sta dietro una sola costante, ChurchHeart.CUORE_TEX_PATH (oggi ""): quando SU-549/SU-550 portano i cuori approvati si cambia in un punto solo.
• Due difetti trovati guardando gli scatti e corretti: il modulate grigio su un rosso puro moltiplica e dava bordeaux invece di grigio (ora lo spento passa da una copia desaturata per luminanza), e il riempimento contava anche le righe trasparenti in fondo alla texture, quindi i primi $19 non si vedevano.
• Sonda (probe_su548_chiesa.gd) e cinque scatti (shot_su548_chiesa.gd, in TMP/su548/), guardati: 5→6 vite con $100 e soldi 500→400; da 8 si arriva a 9 e 30 pressioni in piu' non tolgono un dollaro (900→900); a 9 vite la prima pressione rende $0; 3 pressioni = offerta $30 e cuore al 30% con vite ferme, +7 e la vita arriva; con $25 in tasca il denaro non sale mai sopra 25. Spunta dei 10 criteri: 9 FATTO, zero sospetti.
• ⚠️ La chiesa non e' garantita in mappa: sul seme 20260731 non c'e' proprio, e per quella partita la meccanica non esiste. Serve il gemello di _garantisci_banca() — ticket a parte. Manca anche l'icona sulla cartina (MapOverlay.POI_ICONS, fuori dai file del lotto).
• ⚠️ Non provato: run col TestBot, device, MP a 2+ peer (zero RPC nuovi comunque), e la chiesa piazzata «in fila» su lotto stretto.

SU-553: chi diceva di non avere 16 anni restava chiuso fuori per sempre2026-08-23

• [fix] scripts/ui/MainMenu.gd:6119 _account_start_login() — il cancello dell'eta' si riapre a ogni tentativo finche' non arriva un «si'». Ivan, in chat: «se dico che non ho 16 anni giustamente mi blocca, ma non posso piu' riaccedere. La volta dopo che faccio accedi con Apple, Google o Epic deve rifarmi la stessa domanda».
  • Il difetto: la domanda si apriva solo se account_age_asked era false, ma rispondere «no» metteva asked=true e ok=false. Da li' in poi ogni «accedi con...» cadeva sul ramo successivo — avviso «minorenne» e ritorno — senza mai riproporre la domanda. Vicolo cieco permanente: l'unica uscita era cancellare i dati.
  • La correzione e' togliere un controllo, non aggiungerne uno: i due rami diventano if not account_age_ok: apri il cancello. Simmetrico al consenso di pubblicazione tre righe piu' sotto, che si e' sempre comportato cosi' — il modello era gia' in casa, nello stesso file. Nessun campo nuovo: account_age_asked e account_age_ok restano i due di prima (criterio 4 del ticket).
  • Le note che difendevano il vecchio comportamento sono state riscritte, non cancellate (Settings.gd:360-372 e 1287-1293, MainMenu.gd:6117): dicevano «una volta sola, mai piu'» ed erano diventate false. Ora dicono che il «si'» non si rivede piu' e che il «no» riapre.
• Provino scripts/tools/shot_su553_eta.gd (nuovo), rilanciato dall'orchestratore: ESITO=OK, sette scatti. Preme davvero il secondo tentativo invece di chiamare la funzione — che e' il punto, perche' il difetto viveva solo nel secondo tentativo e una sonda che apre il cancello una volta sola non l'avrebbe visto. Copre i tre provider (Apple/Google/Epic) e il giro di regressione.
  • TMP/1_domanda_ripresentata_<provider>.png: la domanda e' di nuovo a schermo dopo il «no». TMP/2_domanda_consenso_<provider>.png: rispondendo «si'» si arriva al consenso senza riavviare. TMP/3_regressione_gia_risposto.png: chi aveva gia' detto «si'» torna dritto al menu account e non rivede niente.
• ⚠️ Un testo di gioco e' rimasto indietro, e va deciso da Ivan: la schermata si intitola «UNA DOMANDA SOLA» e dice «Te lo chiediamo una volta sola». Vero per chi risponde «si'»; da adesso falso per chi risponde «no», che e' esattamente il caso creato da questo ticket. Non toccato qui perche' e' un testo in 8 lingue e la formulazione nuova e' una scelta sua, non nostra.
• ⚠️ Non provato: il login vero con EOS sui tre provider. La sonda si ferma alla domanda del consenso e per la sola regressione usa un login simulato, per non far partire un popup di sistema.

SU-546: le tre musiche «basse» erano una sola, e non era colpa dei file2026-08-23

• [fix] scenes/ui/MainMenu.tscn — il lettore della musica del menu passa da volume_db = -10.0 a -2.0, cioe' allo stesso valore di tutti gli altri. Una riga.
• 📌 La diagnosi ha ribaltato il ticket, e vale piu' della correzione. SU-546 diceva che menu, tutorial e CENTRO suonano piu' basse perche' sono le tre che non passano dalla tabella dei quartieri. Misurate tutte e dieci con ffmpeg ebur128, oggi non e' piu' vero: stanno fra −13,2 e −14,5 LUFS, cioe' 1,3 dB di escursione — dentro il criterio di 1,5 dB del ticket, e menu (−13,5), tutorial (−13,7) e Centro (−14,0) sono in mezzo al gruppo, non sotto.
  • Il motivo e' che i tre brani sono stati sostituiti il 23/08 (voce 21 di oggi): il ticket descriveva i file vecchi, che nel frattempo non ci sono piu'. ⚠️ Un ticket scritto prima di un cambio di asset puo' descrivere un difetto che non esiste piu': si misura prima di lavorarlo, non dopo. Qui ha risparmiato un lotto intero.
  • Lo scalino vero era a valle, uno solo: World.gd:3831 mette i quartieri a volume_db = -2.0, e TutorialWorld.tscn e Main.tscn (il Centro suona main2) sono gia' a −2,0. Il menu stava a −10,0: otto decibel sotto tutto il resto, e nessun file c'entrava.
  • Il pareggio e' fatto sul volume_db del lettore, come prescrive il ticket, mai sul bus Music, che e' il volume scelto dal giocatore.
• Tabella dei livelli (I integrata / picco vero): main −13,5 / −1,5 · tutorial −13,7 / −2,5 · main2 (Centro) −14,0 / −3,2 · brina −13,7 / −2,9 · collina −13,2 / −0,6 · fumarola −14,2 / −3,2 · gattopoli −13,9 / −3,0 · mercato −13,9 / −2,8 · nottefonda −14,5 / −5,2 · solleone −13,8 / −3,4.
• ⚠️ Un criterio resta NON soddisfatto, di proposito: «nessuna traccia sopra −1 dBFS di picco». collina.ogg e' a −0,6 dBFS, 0,4 dB oltre il tetto. Non e' clipping (il clipping e' a 0), e per rientrare bisognerebbe ri-codificare un ogg gia' lossy, cioe' pagare una seconda generazione di perdita su tutto il brano per 0,4 dB che non si sentono. Lasciato com'e' e dichiarato: se Ivan lo vuole rientrare, si rifa' dal WAV sorgente, non dall'ogg.
• Quello che resta da fare e' un ascolto, e lo fa Ivan: il passaggio menu → tutorial → partita, per sentire se lo scalino e' sparito davvero. La misura dice di si', ma il criterio del ticket e' un orecchio.

SU-549: le 9 vite diventano cuori, e il cuore vuoto sparisce sul fondo scuro2026-08-23

• [feat] Due icone nuove in sprites_raw/UI/ — vita_cuore_piena.png e vita_cuore_vuota.png, 16×16 nativi, 0 pixel semitrasparenti su entrambe (alfa binaria, criterio del ticket). Ivan: «rifarli a forma di cuore, non di gatto, non si capisce tanto». ⚠️ Non ancora nel gioco: l'import e' SU-550 e parte solo quando Ivan approva le icone.
  • Rosso (230,51,41,255), lo stesso esatto di vita_gatto_piena.png; contorno nero, forma «a gemma» coerente col cuore rotto alato di broken_heart_sheet.png (SU-304/306) ma piatta come le icone di SU-231.
  • La riduzione l'ha fatta PIL, non il generatore: Codex ha prodotto una sola icona grande e pulita (1254×1254, alfa gia' binaria), poi BOX resize a 16×16, alfa binarizzata e colori agganciati alla palette. Aggiunta una forzatura di simmetria orizzontale non prevista dal brief: il primo giro dava 4px contro 3px ai lati della tacca, che a 16 px si vede.
  • Il cuore vuoto non e' stato rigenerato: e' l'anello di contorno della piena (erosione della maschera), lo stesso meccanismo con cui vita_gatto_vuota.png e' gia' derivato da vita_gatto_piena.png — verificato pixel per pixel prima di scrivere il codice.
• ⚠️ Il criterio «si distingue su fondo chiaro E su fondo scuro» non e' soddisfatto dalla prima versione. Nel provino il cuore vuoto e' nettissimo sul fondo panna e quasi invisibile sul fondo scuro: il contorno nero non ha contrasto contro il cielo notturno. Non e' un difetto introdotto qui — vita_gatto_vuota.png ha oggi lo stesso limite, con lo stesso meccanismo — ma il ticket lo chiede per iscritto.
  • 📌 Il rimedio ce l'avevamo gia' in casa: il doppio contorno nero+panna, la stessa cura usata per rendere leggibile un soggetto su cieli opposti. Prodotta la variante vita_cuore_vuota_v2.png — alone panna sui soli pixel trasparenti adiacenti al contorno, quindi dentro i 16×16, senza allargare la sagoma — e messa a confronto sui due fondi in TMP/su549_confronto_vuota.png: sul fondo scuro la v2 si legge, sul chiaro regge comunque.
  • La scelta fra le due la fa Ivan guardando, non noi: e' un giudizio estetico, ed e' anche il ticket in cui lo stato Fatto lo mette lui.
• Provini: TMP/su549_provino.png (fila di 9 a 32 px, 4 pieni e 5 vuoti, sui due fondi) e TMP/su549_confronto_vuota.png (attuale contro v2). Gli asset raw stanno in LFS e non si committano: qui si dichiara solo che sono stati scritti.

SU-547: i crash da Android si recuperano su due gambe, non una2026-08-23

• [docs] OPUS_BRIEFS/SU-547_crash_android.md — ticket (DESIGN), nessun codice: esce una decisione da confermare a Ivan. Domanda di partenza: «su iPhone i crash li mandano i tester, da Android come li recupero? La telemetria li becca?».
  • Decisione proposta: la combinazione, a due tempi. Android vitals subito (gratis, zero moduli store), poi un raccoglitore nostro che infila la coda *sanificata* del log come una riga in piu' dentro la telemetria che gia' esiste — nessun endpoint nuovo, nessun destinatario nuovo, nessun consenso nuovo.
  • 📌 Il motivo per cui una gamba sola non basta: vitals prende i crash che uccidono l'app, e non prende gli errori GDScript, che qui sono la classe di guasto piu' probabile — un String(null) sbaglia ogni frame, l'app resta viva, il compile-check resta verde e a Google non arriva niente. Le due strade coprono guasti diversi, non si sovrappongono.
  • ⚠️ La coda della telemetria sopravvive a un crash: sì nel codice, mai provata su device. RunRecorder._flush() apre-appende-chiude ogni 10 s e _ready() programma un giro di coda 6 s dopo l'avvio *a prescindere dalla registrazione*, con un commento che dice gia' «per i file rimasti indietro, cioe' quelli di una partita finita in un crash». Restano due limiti veri: si perdono fino a ~10 s di eventi nel buffer RAM, e l'assenza di run_end non e' prova di crash (uno scorrimento via dai recenti puo' non consegnare la notifica) — da qui il file-sentinella di sessione invece della riga mancante.
  • ⚠️ Il log grezzo non si puo' spedire, ed e' il vincolo che decide il progetto. EOSBridge.gd stampa i PUID in chiaro (righe 354, 1115, 1794): mandare godot.log com'e' rimetterebbe dentro gli identificativi che SU-413 aveva tolto apposta e renderebbe falsa la risposta «Not Linked» gia' data ad Apple. Filtro a valle obbligatorio, con sonda che lo dimostri, altrimenti la seconda gamba non esce. Corollario trovato strada facendo: quei PUID finiscono anche nel logcat che Google raccoglie, dove non li controlliamo — si risolve alla fonte, mascherandoli in release.
  • Costo privacy, che era la domanda vera di Ivan: vitals tocca zero moduli; la gamba nostra tocca tre righe, non un rifacimento — «Log di arresto anomalo» nel Data safety di Play (tipo distinto da «Dati diagnostici», che abbiamo gia'), «Diagnostics → Crash Data» in App Privacy di Apple, una frase nelle due informative.
  • Dieci ticket proposti nel §4, con l'ordine: prima i tre che costano niente e dicono se serve il resto (simboli nativi, crash forzato sull'Honor per vedere se l'Alpha arriva in vitals, prova della coda su device), poi il raccoglitore, poi i moduli store insieme alla release.
  • ⚠️ Sei cose non verificate sono scritte nel §5 col come si verificano. La piu' pesante: se i crash del canale Alpha compaiano davvero in vitals — la doc esclude solo cio' che non viene dal Play, e l'Alpha viene dal Play, ma esiste un filone di segnalazioni contrarie di cui non si e' potuto leggere il corpo. Non e' deducibile: si misura con un crash forzato. Trabocchetto per quella prova: run-as non funziona sulla build firmata di release.
  • La decisione la conferma Ivan: le tre domande secche sono in fondo al documento. Finche' non risponde, i dieci ticket non si creano.

Tre musiche nuove, e lo strumento che le importa imparava a buttare metà brano2026-08-23

• [change] Menu, tutorial e Centro cambiano colonna sonora. Ivan passa tre WAV nuovi: main menu.wav → assets/sounds/main.ogg, tutorial.wav → tutorial.ogg, centro.wav → main2.ogg (il Centro non ha una traccia sua: la sua musica è main2, montata in Main.tscn — vedi Quartieri.gd). I .import non sono stati toccati, quindi gli uid nelle tre scene reggono senza riaprire l'editor; asset reimportati headless e verificati caricando le tre AudioStream e le tre scene che le montano.
  • Menu 132,29 s (78 battute, giunzione 1,02 dB), tutorial 142,95 s (95 battute, 1,73 dB), Centro 144,00 s (60 battute, 1,86 dB). Tutte a −16,0 dB RMS e 111 kbps, come le sette dei quartieri.
  • ⚠️ Menu e tutorial hanno la stessa durata dei vecchi ma NON sono lo stesso audio (verificato sull'hash del PCM decodificato): sono remix, non ri-render. I WAV sorgente sostituiscono Sounds_raw/main.wav, tutorial.wav, main2.wav — i vecchi restano in LFS.
• [fix] tools/importa_musica_quartiere.py — due opzioni nuove, --salta e --battute, perché senza il taglio automatico sbagliava su due brani su tre.
  • ⚠️ Il punteggio non preferisce la durata. Lo script prende il taglio che giunta meglio, punto. Sul Centro ha scelto 23 battute = 55,2 s con punteggio 0,62, mentre a 60 battute = 144,0 s il punteggio era 0,70: la stessa giunzione per 2,6 volte la musica, e 140 secondi buttati senza che nulla lo dicesse. Ora lo script stampa la classifica dei candidati (i 5 migliori e i 5 più lunghi) e avvisa quando il taglio tiene meno del 60% della sorgente: si sceglie il più lungo fra quelli che giuntano bene, non il primo della lista.
  • ⚠️ Un'intro in dissolvenza avvelena il confronto. Il dislivello si misura fra la coda e i primi 0,3 s della testa: il tutorial attacca con otto secondi a −25 dB contro un corpo a −17, quindi nessuna coda pareggiava mai la testa e il taglio finiva su un troncone di 24 s su 153, con 13,45 dB di salto alla giunzione — un riavvio che si sarebbe sentito eccome. Con --salta 8.0 il taglio va a 143,2 s con 1,73 dB.
  • 📌 Un punteggio che ha un minimo netto non sta dicendo che quel minimo è la scelta giusta: dice solo che è il minimo di ciò che la formula guarda. Qui la formula non guardava né la durata né la forma dell'attacco, e il difetto si sarebbe visto solo giocando.
• [docs] Le due trappole sono scritte in cima allo script, dove le trova chi importerà il brano dopo, coi numeri di questi tre casi.
• ⚠️ Da valutare, non toccato: menu e tutorial stanno al 50,2% e 47,2% di energia nella banda 250 Hz-2 kHz, fuori dal ventaglio di tutte le tracce esistenti (10,1%-37,7%, il massimo era collina). È la banda di monetine, gatto e sirena — la regola dei medi liberi di MUSICA_AI_PROMPTS.md §1.3. Sul menu conta poco, nel tutorial si gioca. Il Centro invece è a 20,8%, in linea con il main2 di prima (20,6%).

Il numero vero ce l'aveva già la barra del Mac2026-08-23

• [feat] tools/token_finestra.py legge la percentuale VERA, non più una stima. Ivan: «ma scusa, io su sto pc ho Claude Usage Bar che mi dà la percentuale, non possiamo leggere da lì?». Sì. E chiude un pomeriggio di modelli sbagliati.
  • ClaudeUsageBar.app interroga https://claude.ai/api/organizations/<org>/usage ogni minuto e la risposta finisce nella sua cache URL standard (~/Library/Caches/com.claude.usagebar/Cache.db). Da lì la leggiamo: five_hour.utilization — la stessa percentuale che Ivan vede in /usage — più five_hour.resets_at, l'ora esatta dell'azzeramento, e la settimanale.
  • ⚠️ Zero rete e zero credenziali, ed è una scelta esplicita. L'app custodisce un cookie di sessione di claude.ai in chiaro nelle sue preferenze; interrogare l'API con quello sarebbe stato possibile ma significa maneggiare una credenziale viva a ogni chiamata. Leggere la risposta già scaricata dà lo stesso dato senza toccarla. Il cookie non viene mai letto, copiato, né scritto da nessuna parte.
  • 📌 Il database va copiato con il suo -wal. Il Cache.db da solo dava un dato di tre giorni prima: le scritture recenti stanno nel write-ahead log, e l'entry viene aggiornata in place senza toccare il time_stamp della riga. Copiati tutti e tre i file, il numero è quello di un minuto fa. La freschezza si misura sul mtime del -wal.
  • Quello che ci mettiamo noi è il cambio punti↔token, che l'API non dà: sapendo da resets_at quando la finestra è cominciata, si contano i token dei transcript in quell'intervallo. Misurato: 1 punto = 3,05M token grezzi, tetto implicito ~305M — e conferma il 3,0M/punto che era stato indovinato per altra via. Da lì la cosa che serve davvero: al 90% mancano N punti ≈ K builder (un builder = 29M ≈ 10 punti, un'onda da 4 ≈ 40 punti).
  • Tre percorsi, tutti provati: app viva → numero vero; app ferma con una lettura manuale in memoria → stima dichiarata come tale (nel collaudo dava 49% contro il 52% reale, quindi la rete di sicurezza tiene); niente di niente → lo script si ferma e chiede la lettura invece di inventarla.
  • ⚠️ Ora la regola ha una dipendenza fuori da git, ed è annotata dove si guarda quando qualcosa manca: RICOSTRUZIONE_DA_ZERO.md § 6-bis, col promemoria che il cookie lo rimette sempre Ivan.
• [docs] La regola aggiornata dove vive: CLAUDE.md, ORCHESTRAZIONE.md (Dieta token, regola 9), WORKFLOW/02_SPRINT.md, punto 7 di /sprint. Le tre smentite del pomeriggio restano scritte: finestra allineata all'ora (una finestra passata al 290%), finestra scorrevole (smentita perché /usage saliva mentre la somma scendeva), tetto dedotto dal delta fra due letture (~100M contro i 156M di una mattinata). 📌 Sono la parte che evita di rifare il giro — e la morale è che quando tre modelli plausibili cadono, il quarto non si indovina: si va a cercare chi il numero ce l'ha già.

Il contatore d'uso non si ricostruisce da fuori: lo strumento smette di indovinare il tetto2026-08-23

• [fix] tools/token_finestra.py riscritto ad àncora + deriva. Ivan conferma la riga letta e ne dà una seconda: «quella della sessione 5 ore, ora 46».
  • ⚠️ Tre modelli plausibili, tutti e tre smentiti dai dati nello stesso pomeriggio. (1) Finestra allineata all'ora piena, come ccusage: col 44% il tetto usciva 113M e una finestra passata sarebbe stata al 290%. (2) Finestra scorrevole: sei minuti dopo /usage era salito a 46 mentre la somma scorrevole scendeva di 4,3M — quindi il contatore vero accumula e non decade. (3) Tetto dedotto dal consumo fra due letture: 2 punti per 2,0M token grezzi implicherebbe un tetto di ~100M, mentre nella sola mattinata ne erano passati 156M.
  • 📌 La lezione, che vale ben oltre questo strumento: quando tre modelli plausibili vengono smentiti, il quarto non si indovina — si cambia domanda. Non serve sapere il tetto: serve sapere quanto manca. E quello si misura senza ipotesi.
  • Come funziona ora: Ivan legge /usage una volta, --usage 46 la registra come àncora, e da lì lo script misura solo la deriva — i token passati da allora, convertiti in punti a 3,0M grezzi/punto. Una lettura nuova azzera l'errore accumulato; sopra l'ora e mezza lo script lo segnala; oltre le 5 ore dichiara l'àncora scaduta e si rifiuta di stimare, perché nel frattempo la finestra può essersi azzerata. Prima di congelare chiede sempre una lettura fresca: la stima deriva, la lettura no.
  • Il fattore si affina da solo, ma solo quando due letture distano almeno 5 punti: fra «44» e «46» l'arrotondamento vale quanto il segnale, e su quei numeri lo script dichiara di non aver imparato nulla invece di fingere.
  • --reset HH:MM registra l'ora di azzeramento che /usage stampa: è l'unico modo di sapere quando riprendere dopo un congelamento, perché il contatore da solo non lo dice.
  • ⚠️ Deve essere la riga della SESSIONE (5 ore), non quella settimanale: in /usage si somigliano, e la prima calibrazione è stata verificata proprio chiedendo quale delle due fosse.
  • Quello che sopravvive ai tre modelli caduti sono i numeri sugli agenti, che non dipendono dal contatore: un builder costa in media 29M grezzi (37 subagenti del 21-22/08, 1.080M in tutto) ≈ 10 punti; un'onda da 4 ne vale ~40. È il numero che serve davvero, perché la regola non è «fermati al 90%» ma «dimensiona l'onda sul margine».
• [docs] Regola aggiornata dove viveva: CLAUDE.md (regole minime sempre valide), ORCHESTRAZIONE.md (Dieta token, regola 9), WORKFLOW/02_SPRINT.md § «Congelamento e ripresa», punto 7 di /sprint. Le tre smentite restano scritte: è la parte che evita di rifare il giro.

La prima lettura vera di `/usage` smentisce il metro appena scritto: la finestra scorre2026-08-23

• [fix] tools/token_finestra.py — finestra scorrevole invece che allineata all'ora. Ivan, poche ore dopo la voce (18): «tipo adesso è 44%, posso lanciarlo con 44?».
  • ⚠️ La calibrazione ha bocciato lo strumento, ed è servita esattamente a questo. Con il ritaglio allineato all'ora piena — quello che usa ccusage, e che sembrava ovvio — il 44% dava un tetto di 113M, con cui la finestra del 22/08 pomeriggio (327M) sarebbe stata al 290%. Un numero impossibile è una prova: sbagliato il ritaglio, non la lettura. Sostituito con la somma scorrevole degli ultimi 300 minuti, aggiornata a ogni messaggio.
  • 📌 Una calibrazione che rende il passato impossibile va rifiutata, non registrata. Ora lo script rilegge la storia prima di scrivere il tetto e rifiuta il numero se una finestra passata risulterebbe sopra il 105%, dicendo anche dove guardare (in /usage la riga della sessione e quella settimanale si somigliano).
  • Il tetto diventa ~360M grezzi, e non esce più da una coincidenza a due punti: i picchi giornalieri della finestra scorrevole si stringono su 358, 349, 347, 346, 346M in cinque giornate diverse. Il 22/08 — il giorno dello stop a mano «intorno al 90%» — ha picco 346M, il 99% di quel muro.
  • La metrica conta poco, il ritaglio contava tutto: provate sei pesature (grezzi, per modello, per costo di listino, senza cache-read, solo output), il rapporto fra consumo attuale e picco storico resta fra il 38% e il 54%. Restano i grezzi, che sono i più trasparenti.
  • ⚠️ Resta uno scarto di ~10 punti fra questo metro e /usage (53% contro 44%): non sappiamo se i picchi non fossero esattamente al 100% o se il contatore vero pesi diversamente. Se la lettura di /usage dà un tetto più ALTO dei picchi storici vince il più basso, e lo script lo dichiara nella riga di stato. Una lettura più bassa invece vince e basta. Sbagliare per eccesso significa congelare tardi, cioè perdere lavoro; per difetto costa solo un'attesa. La lettura del 23/08 (435M) è registrata ma non usata.
  • Sparisce l'«ora in cui tornano i token», che con una finestra scorrevole non esiste: il consumo decade via via che i messaggi escono dai 300 minuti. Lo script dice invece a che ora si scende sotto il 90% e sotto metà finestra se ci si ferma adesso — che è l'ora della ripresa.
• [change] La regola sale in CLAUDE.md, fra le «regole minime sempre valide». Ivan: «metti questo lavoro come regola generale dello sprint, così anche le prossime sessioni lo sanno». Vale ovunque, non solo dentro /sprint: le onde di agenti si dimensionano sul margine, al 90% si congela. Numeri aggiornati anche in ORCHESTRAZIONE.md (Dieta token, regola 9) e in WORKFLOW/02_SPRINT.md.

Al 90% lo sprint si congela da solo, e adesso il 90% è un numero che si può leggere2026-08-23

• [feat] tools/token_finestra.py — la finestra di 5 ore diventa misurabile. Ivan, dopo lo stop a mano del 22/08: «se raggiungiamo il 90%, per evitare di perdere dati, salviamo congelando e riavviamo quando tornano i token, controllando quanto manca».
  • ⚠️ Il pezzo che mancava non era la regola, era il metro. Claude non vede il contatore del limite d'uso: non esiste un claude usage da riga di comando (controllato: fra i sottocomandi non c'è), e il <total_tokens> che legge in sessione è un budget di sessione, non la finestra dell'account. Scritta senza uno strumento, «al 90% congela» sarebbe stata una regola che chi deve applicarla non può nemmeno valutare.
  • I consumi però stanno tutti nei transcript ~/.claude/projects/**/*.jsonl, subagenti compresi (<sessione>/subagents/*.jsonl — ed è lì che sta quasi tutta la spesa di uno sprint). Lo script li somma, li spezza in finestre da 5 ore come le conta Anthropic (aggancio al primo messaggio arrotondato all'ora, nuova finestra dopo 5 ore di silenzio) e stampa una riga: usato, percentuale, margine al 90%, quanti builder ci stanno ancora, a che ora tornano i token. Costo: zero token, 0,6 secondi.
  • La coincidenza che ha deciso quale metro usare. Le due finestre più grosse mai fatte — 21/08 mattina e 22/08 pomeriggio, quella fermata a mano — chiudono a 327,7M e 327,4M token grezzi: lo stesso numero a tre cifre. Pesando i token per modello (Opus 1, Sonnet 0,2, Haiku 1/15), come sembrava sensato, i due valori divergono in 300M contro 210M e la coincidenza sparisce. Quindi il metro conta i token grezzi, lettura di cache compresa, e il tetto di default è quel 328M.
  • ⚠️ Sono due punti soli, e non sappiamo se erano al 90% o al 100%: il tetto è la lettura prudente. Basta che Ivan legga una percentuale vera in /usage e si fissa per sempre — python3 tools/token_finestra.py --calibra 62. Finché non succede, lo script lo dichiara al posto di far finta di saperlo.
  • Il numero che rende la soglia decidibile: i 37 subagenti del 21-22/08 sono costati 1.080M grezzi, media 29M l'uno (mediana 23,6M, il più caro 74,6M). Cioè un builder è il 9% della finestra e un'onda da 4 è il 36%. Due onde più l'orchestratore la riempiono — che è esattamente quello che è successo il 21 e il 22.
• [docs] WORKFLOW/02_SPRINT.md — nuova sezione «Congelamento e ripresa», richiamata come punto 7 di /sprint e di /ko.
  • Le soglie non sono «fermati al 90%», ma «dimensiona l'onda sul margine»: se ci stanno 2 builder ne parti 2, anche coi lotti pronti a 4 — gli altri restano *interi* nel file di ripresa invece che a metà. Al 90% non si apre più niente: chi è in volo finisce (i suoi token sono già spesi, interromperlo li butta), si chiudono i suoi ticket e si congela. Al 97% stop secco, solo RIPRESA.md.
  • L'ordine del congelamento va dal più durevole al meno: prima i commenti e le transizioni Jira (l'unica cosa che Ivan vede dal telefono e che sopravvive a tutto), poi i commit dei soli lotti chiusi, poi il working tree lasciato sporco con git status --short copiato nel file, e infine RIPRESA.md. Se il congelamento si rompe a metà, deve rompersi *dopo* Jira.
  • 📌 Il file di ripresa non è il riassunto della giornata. Quel riassunto sta già gratis in tre posti durevoli (commenti Jira, CHANGELOG, commit) e riscriverlo è pagare due volte la stessa pagina. Ci va solo ciò che morirebbe col /clear: la ripartizione nuovi/bocciati già decisa, la tabella dei lotti, le trappole del giorno, le domande aperte. Tetto: una pagina. In fondo alla sezione c'è lo scheletro da riempire.
  • La ripresa costa RIPRESA.md + una query Jira, e nient'altro — niente transcript, niente REPORT_LOTTI.md, niente diff. La query Jira invece si rifà sempre: nel frattempo Ivan può aver scritto un KO dal telefono, ed è la stessa ragione per cui non teniamo una cache locale dei ticket.
  • ⚠️ La ripartenza automatica resta a richiesta, e claude-loop è escluso. Un prompt di permesso blocca *tutti* gli agenti in parallelo (misurato il 17/08: 3 builder fermi 7 ore su 9h40), quindi schedulare di notte significa consumare la finestra nuova da fermi. E la skill install/claude-loop riparte con --print --resume e il prompt fisso «Continue from where we left off» ogni 300 secondi: ricarica il contesto pieno di una sessione al 90% e ritenta alla cieca — il massimo dello spreco proprio dove serve il minimo.
• [change] La capsula di contesto non si riscrive più a mano: ora è WORKFLOW/CAPSULA.md. Era il pezzo più grosso del file di ripresa scritto a mano il 21/08 (25 righe su 80) e veniva ricostruita a ogni sprint. Ora si incolla da lì, e se una riga invecchia si corregge nel file, non nel brief — dove morirebbe con la sessione. Aggiornati i richiami in /sprint (punto 4), 02_SPRINT.md e WORKFLOW/README.md.
• [docs] ORCHESTRAZIONE.md, Dieta token: regola 9, «la finestra di 5 ore è una risorsa e si misura prima di spenderla», con i tre numeri (328M la finestra, 29M un builder, 36% un'onda da 4).

Al mercato i negozi diventano banchi, e il banco ferma davvero chi ci sbatte2026-08-23

• [feat] SU-540 — nel solo MERCATO i quattro punti vendita nascono come bancarelle. Ivan: «nel livello del mercato sostituisci tutti i negozi di vestiti, di hot dog, di gelati, e la vineria con i relativi banchi». Camioncino hot dog → banco hotdog, camioncino gelati → banco candy, vetrina vestiti → banco clothes, vineria → banco beer. I bagni pubblici restano bagni. [NOVITA']
  • La scelta sta nel QUARTIERE, non nel generatore, ed è il codice stesso a chiederlo: sopra la voce delle bancarelle in Quartieri.gd c'era già scritto che la configurazione per quartiere sta lì «e non in un if quartiere == "mercato" dentro il generatore». Nuova voce di layout negozi_a_banco, false ovunque e true solo al mercato; i tre costruttori deviano in testa.
  • ⚠️ Il rischio dichiarato non si è materializzato, e per costruzione. Temevo che quattro banchi in più non entrassero nelle piazze — misurato in giornata: a 112×72 il generatore ne piazzava 1-2 su 5. L'alternativa ovvia era alzare bancarelle_max da 5 a 9, ed è stata scartata: quei banchi devono *trovarsi* un posto e faticano già a cinque. I banchi dei negozi invece ereditano l'isolato che il negozio si era già prenotato, quindi lo spazio è garantito a monte. Zero avvisi «piazze strette» su tre semi.
  • Un difetto vero trovato per strada: _scatter_bancarelle contava bancarelle.size(), e coi banchi dei negozi già dentro il tetto risultava sfondato al primo giro — i cinque banchi di SU-408 non nascevano più. Misurato: 7 banchi in mappa e zero saponi. Ora conta i propri.
  • I numeri (seme 424242): nel MERCATO 0 camioncini hot dog, 0 camioncini gelati, 0 vetrine vineria, 0 vetrine vestiti; 12 banchi = 7 dai negozi + 5 di SU-408, ognuno col suo tipo. Controprova sul CENTRO: 0 banchi, i punti vendita normali al loro posto.
  • ⚠️ E qui è caduto un metodo che avevo usato io poche ore prima: l'invarianza degli altri quartieri non si può misurare col diff di due PNG, perché fuori dal Centro ci sono prop animati e due run dello *stesso identico codice* danno 1628 px diversi su FUMAROLA e 4555 su COLLINA — lo stesso ordine di grandezza di una regressione vera. Sostituito con una firma sha256 della città su 6 semi per quartiere: identica su tutti e sette, cambia solo mercato. Il confronto a immagine resta valido sul solo CENTRO, dove è deterministico.
• [fix] SU-539 — il muro del banco passa da 36 a 84, cioè tutta la sua larghezza. Ivan: «vanno corretti i confini della bancarella ora il barbone ci passa ai lati», e poi «proviamo solo ad allargare il muro anche per npc e vediamo che succede».
  • ⚠️ Il commento nel codice diceva di non farlo, con una misura a supporto — «non segue il disegno, segue il corridoio: un muro da 52 lascia 26 px di passaggio e attraversare la piazza diventa un giro del 240%». Era vero quando fu misurato, col banco largo 56 e piazzato altrimenti.
  • Rimisurato oggi con la geometria di adesso: MERCATO, stesso seme, 110 NPC lasciati camminare 12 secondi. Strada media percorsa 173,2 px con muro 36 contro 171,3 px con muro 84 — dentro il rumore. Gli unici fermi sono i cinque venditori, che stanno fermi apposta. I banchi si piazzano tutti anche a 60 e 72.
  • Il commento è stato riscritto col numero nuovo, non cancellato: chi rimettesse 36 in buona fede rimetterebbe anche il barbone che attraversa il banco. Resta segnalato che la fila dei bagni (59 px di disegno, 21 di solido) è il caso opposto e non la stessa regola.

La merce torna sopra il bancone, ricomposta con PIL invece che rigenerata2026-08-23

• [fix] SU-538 — banconi nuovi + merce del primo giro, montati insieme. Ivan, guardando gli sprite: «le birre non sono sopra il bancone ma dentro! E le paperelle sono schiacciate! Gli oggetti del primo giro erano perfetti, non puoi semplicemente dai banconi nuovi rimuoverle e ripristinare quelli originali sopra?».
  • Ed è la strada giusta, che io avevo scartato per un motivo sbagliato. Avevo escluso il montaggio pensando che la merce dovesse restare dentro la fascia del bancone; ma un banco vero ha la merce appoggiata sopra, e il venditore ci sta dietro. Rimessa così, la geometria torna e sparisce il compromesso che avevo appena dichiarato accettabile.
  • Fatto con PIL, non rigenerando — è la regola del progetto per le correzioni geometriche, e qui evita un quarto giro di Codex dopo i tre già spesi. Per beer, candy e igiene: si prende il bancone di gen5 (pieno da riga 36), si ripuliscono le assi riscrivendoci sopra una striscia di legno pulito presa più in basso (è lì che erano annegati i boccali), e si incolla la merce di gen4 con il fondo appoggiato sul ripiano.
  • ⚠️ Il rilevamento automatico del ripiano si è fatto ingannare, e il primo montaggio è uscito sbagliato: cercavo la fine del ripiano dalla luminosità della riga, ma su candy e igiene la merce è chiara (dolciumi rosa e panna, saponi bianchi), quindi la riga restava luminosa e il taglio scendeva troppo — la merce vecchia non veniva ripulita e ne comparivano due file. Risolto usando lo spessore misurato su beer (38 px), l'unico dove la merce è scura e il rilevamento non poteva sbagliare.
• [fix] Il terzo criterio invecchiato della giornata. shot_su539_mezzobusto.gd pretendeva che il mezzo busto stesse tutto dentro il vuoto: giusto finché la merce stava dentro la fascia del bancone, falso da quando sporge sopra. Dopo il montaggio la sonda dava tre KO — «il torace finisce dietro al bancone di 4-8 px» — che sono esattamente ciò che Ivan ha chiesto e che a schermo si legge meglio di prima.
  • Il criterio nuovo non è «il busto ci sta tutto» ma «si vede abbastanza busto da riconoscere una persona»: testa intera più almeno metà del mezzo busto. Sotto quella soglia il venditore diventa una testa che galleggia, e lì il KO ci vuole davvero. Misurato adesso: visibili 16-20 px su 24, e la copertura residua viene stampata come nota, non come errore.
  • 📌 Tre criteri invecchiati in un giorno solo (la passeggiata del venditore, l'ombra, il mezzo busto) dicono una cosa sola: quando cambia il comportamento, la sonda che lo sorvegliava va cambiata nello stesso commit, altrimenti al giro dopo il suo rosso si legge come un difetto vero.

Niente rider dietro al banco, e i cinque banconi sulla proporzione della nonnina2026-08-23

• [fix] SU-539 — arch_delivery escluso dal bacino dei venditori. Ivan: «Non va messo il rider dietro al bancone non è realistico 😅».
  • ⚠️ E non era solo verosimiglianza: quella risata ha corretto una mia diagnosi sbagliata. Sul banco igiene si vedeva qualcosa spuntare dal bancone e l'avevo attribuito a una fascia opaca mancante nel PNG — con tanto di misura che sembrava confermarlo. Era la bici: il fattorino se la porta dietro nello sprite, e dietro a un banco le ruote sbucavano dal legno sembrando gambe. Un mezzo, dietro a una bancarella, non ci sta comunque.
  • Nel commento sopra l'elenco c'è il criterio per chi domani aggiunge un archetipo: si escludono i civili la cui sagoma include qualcosa che non è il corpo.
• [change] SU-538 — beer, candy e igiene rigenerati sulla proporzione di clothes. Ivan: «quello con la nonnina è perfetto: altezza bancone giusta, altezza tenda giusta, li farei con quella proporzione». Il banco della nonnina è clothes.
  • La sua approvazione coincideva con una misura già in mano: sulle colonne centrali il bancone è pieno dalla riga 36 su clothes e hotdog, dalla 39 su candy, dalla 42 su beer e igiene. Adesso sono 36 tutti e cinque.
  • ⚠️ Il buco NON era solo la bici, e l'ho verificato prima di far rigenerare: sulle versioni precedenti, righe 36-41 al centro, erano trasparenti 10-13 colonne su 17 su beer e 17 su 17 su igiene. Qualunque venditore ci si vedeva attraverso. Il giro serviva.
  • ⚠️ Il numero giusto non basta, e questo giro lo dimostra due volte. Il primo rimedio ha portato tutti e tre a 36 — misura perfetta — ma guardando le immagini grandi la merce era affondata dentro le assi del bancone: i boccali di beer a metà nel legno. Se mi fossi fermato alla verifica numerica sarebbe andato a Ivan così.
  • Un compromesso scelto, non subìto. Il terzo giro ha risolto la composizione ma riaperto una feritoia fra pali e ripiano: le due richieste — opacità e composizione — non sono entrate nello stesso giro. Fermato lì per la regola dei tre tentativi, e tenuta la versione opaca: un venditore che si vede attraverso il legno è un difetto che salta all'occhio, la merce che sfiora le assi è una sbavatura di due pixel alla scala di gioco. La variante alternativa resta su disco in TMP/L14_SU-538/raw/gen6_* se Ivan preferisce l'altro compromesso.
  • Verificato in città: cinque banchi su cinque, cinque venditori distinti, mezzo busto inquadrato nel vuoto su tutti, nessuna gamba attraverso il bancone. Scatti in TMP/su539_finale/.

Il banco passa a 84x54 e il venditore si affaccia dal vuoto2026-08-23

• [change] SU-539 — bancarelle a 84×54, e il mezzo busto del venditore inquadrato fra tendone e bancone. Ivan: «la dimensione è sproporzionata rispetto al personaggio, il suo mezzo busto dovrebbe essere proporzionato allo spazio tra la tenda e il banco».
  • ⚠️ La misura è stata scelta MISURANDO, e la prima scelta era sbagliata. In chat era stato deciso 112×72; patchando una copia di lavoro e rigenerando il MERCATO collo stesso seme, la città piazza 1 banco su 5 a 112×72 («piazze strette»), 4 su 5 a 96×62 e 5 su 5 a 84×54. Ottantaquattro per cinquantaquattro è il massimo che entra, ed è stato verificato prima di spendere il giro di Codex: scoprirlo dopo sarebbe costato l'arte intera.
  • Il conto della posa, e il vincolo che lo bloccava. Con lo sprite ancorato a terra le tre fasce cadono a: tendone base.y-54…-42, vuoto -42…-18, bancone -18…0. Perché il mezzo busto (testa+torace, righe 0-23 del frame) ci finisca dentro, il venditore deve stare a base.y-18 — ma il navmesh scava attorno al bancone un foro alto quanto il muro più 9 px di raggio agente, e con un muro da 10 quel punto non era camminabile.
  • La premessa era cambiata poche ore prima e questo l'ha sbloccato: da oggi il venditore non cammina più (sta fermo e guarda a sud, richiesta di Ivan). Restava però il ramo che lo fa rientrare se qualcuno lo spinge fuori, e quello naviga. Scelto quindi di abbassare il muro da 10 a 6 invece di staccare la posa dal punto navigabile: così il posto dove sta è un posto dove si cammina davvero, e il rientro lo riporta esattamente lì — misurato, scarto dal navmesh più vicino 0,0 px su tutti e cinque. Staccando le due cose ogni spintone avrebbe lasciato uno scarto piccolo, silenzioso e permanente.
  • Un allargamento scartato con la sua ragione: BANCARELLA_MURO.x non segue la larghezza del disegno ma il corridoio della piazza, quindi resta 36 su 84. Prezzo dichiarato nel commento: ai lati del banco ci si passa attraverso, come già prima ma più visibile.
  • La prova sa bocciare: la stessa sonda sul banco vecchio dà FAIL cinque volte su cinque — «la testa entra nel tendone di 24-27 px». Un provino che non sa riprodurre il difetto non dimostra la cura.
  • ⚠️ Un residuo dichiarato, su due banchi su cinque: su beer e igiene il fronte del bancone diventa opaco solo da base.y-12, mentre su clothes e hotdog lo è da -18 — misurato colonna per colonna. In quei 6 px si vedono le gambe del venditore attraverso il banco. Non è la posa (identica sui cinque), è una fascia opaca che manca in quei due PNG: si chiude in arte, non in codice.
  • _disegna_banco_placeholder è rimasto tarato sul disegno vecchio 56×36: è codice morto finché i PNG ci sono, e adesso il commento sopra lo dice.

Il venditore sta fermo dietro al banco, e ogni banco ha la sua faccia2026-08-23

• [change] SU-539 — il venditore non passeggia più: sta fermo e guarda a sud. Ivan: «lo terrei fermo che guarda in basso».
  • _update_vendor() pescava un waypoint a caso nella fascia, ci camminava, si fermava e ne pescava un altro. Ora il bersaglio è ripinnato al centro della zona e la posa è forzata a idle_s.
  • ⚠️ Forzare la posa una volta sola non bastava, ed è la trappola già pagata altrove in questo progetto: _advance_waypoint in NPC.gd ripesca comunque un waypoint ogni volta che scade la sosta, e la superclasse riscrive l'animazione nel proprio _physics_process. La riga va riscritta dopo che ha girato la superclasse — prima si ferma chi scrive, poi si scrive.
  • Restano vivi i due soli comportamenti che Ivan voleva tenere: la reazione alla trombetta (esce subito se _busk_attracted, allarme o panico) e il rientro se qualcuno lo spinge fuori dalla fascia.
  • Misurato: spostamento in 8 s di gioco 0,00 px su tutti e cinque, contro i 14-18 px della passeggiata. Posa idle_s a inizio e fine osservazione.
• [change] SU-539 — cinque banchi, cinque venditori diversi. Ivan: «sceglierei un personaggio random da mettere lì dietro ad ogni bancarella, così genera varietà».
  • ⚠️ Il primo giro ha consegnato 2 aspetti su 5, ed è stato bocciato in casa. arch_vendor non ha arte propria e il suo bacino erano due corpi dell'operaio: tre banchi su cinque avevano il clone, cioè esattamente il difetto che la richiesta voleva togliere. La strada giusta non era sbloccare il gender di arch_vendor — era allargare il bacino.
  • Il pool si costruisce ora a runtime da tutti i corpi civili già nel gioco, con l'esclusione degli ostili (ENEMY_ARCHETYPES letta dal codice, non a memoria), della polizia, della retata e del giocatore: 14 archetipi, ~49 corpi. Risultato col seme 424242: office_zombie, richtourist, hipster, business, delivery — 5 varianti distinte su 5, e il «senza rimpiazzo» adesso confronta con tutti i banchi già piazzati, non solo con l'ultimo.
  • ⚠️ Il dado è quello del mondo, non uno nuovo: il seme viene da _rng_banchi, seedato dal seme della partita. Con un randi() libero la città sarebbe diversa a ogni avvio a parità di seme, e in multiplayer ogni peer vedrebbe venditori diversi — un difetto vero, non estetico. Verificato che due generazioni indipendenti collo stesso seme danno gli stessi cinque, e che un seme diverso ne dà altri.
• [fix] Una sonda che era diventata rossa per costruzione. shot_su539_mercato.gd verificava «se il venditore non si sposta è incastrato» — cioè controllava proprio la passeggiata che questo giro ha tolto: dopo il cambio falliva con 5 KO, per progetto. Criterio rovesciato (adesso KO se si muove) e datato in testa al file. Un criterio che va rosso da solo è peggio di nessun criterio: al giro dopo si legge come un difetto vero. È lo stesso incidente di SU-524, ed è la seconda volta: quando si cambia un comportamento, la sonda che lo sorvegliava va cambiata nello stesso commit.

L'ombra delle bancarelle diventa un'ombra, non una macchia2026-08-23

• [fix] SU-539 — l'ombra a terra del banco: sagoma PIENA al posto dello sprite bucato. Ivan: «tutto ok, per le bancarelle manca solo l'ombra a terra disegnata come per i palazzi».
  • ⚠️ Il punto di partenza NON era «manca la chiamata»: la chiamata c'era già, la stessa _spawn_ombra_generica dei palazzi e della cabina del bagno. Chi legge il ticket e aggiunge un'ombra nuova ne mette due sovrapposte.
  • Prima diagnosi, giusta ma insufficiente: era notte. Tutti gli scatti consegnati fin lì avevano l'orologio a 23:55, e aggiorna_ombre spegne tutte le ombre della città quando il fattore notte è alto — palazzi compresi. Rifatti gli scatti in pieno giorno l'ombra del banco è comparsa, e il primo verdetto è stato «funziona, identica ai palazzi, solo più piccola».
  • ⚠️ Quel verdetto era sbagliato, e a smentirlo è stato guardare il fotogramma ingrandito: l'ombra del banco era sfrangiata (bordo superiore a denti), bucata (una zona chiara in mezzo) e quasi tutta retino di dithering, mentre i palazzi nello stesso scatto proiettano parallelogrammi pieni e uniformi. Messe a confronto, una era un'ombra e l'altra una macchia. È lo stesso schema dell'ombra del rider di stamattina: misure giuste, conclusione sbagliata, e la differenza la fa l'immagine, non il riassunto.
  • La causa: a _spawn_ombra_generica si passava tex, cioè lo sprite vero del banco — alfa binaria, con il vuoto fra i due pali sotto il tendone. L'ombra era la proiezione fedele di quel vuoto. Ma un tendone la luce non la fa passare: quel buco a terra non ci deve stare. I palazzi non hanno il problema perché le loro sagome sono piene.
  • Il rimedio era già in casa, sullo stesso problema: la cabina del bagno pubblico non passa il proprio sprite ma una tex_ombra piena, e nel commento sopra c'è scritto il perché. _bancarella_tex_ombra() fa lo stesso per i banchi — riempie colonna per colonna dal primo all'ultimo pixel opaco — con cache per resource_path, così i cinque tipi si costruiscono una volta e non a ogni banco piazzato.
  • Tutto dal lato del chiamante: _spawn_ombra_generica e aggiorna_ombre non sono state toccate. Sono condivise da palazzi, arredi, lampioni, pensiline e camioncini: cambiarle per un banco sarebbe stato un intervento su tutta la città.
  • Confronto guardato, non descritto: TMP/su539_ombra/prima/ contro dopo/, ravvicinati e col palazzo nello stesso fotogramma, mattina e sera. Nel dopo il profilo è continuo e pieno, senza denti e senza buco. Dimensioni della texture invariate (56×36), quindi altezza, mezza-larghezza e z-order dell'ombra restano identici al prima.

La nuvoletta diventa un ovale, e soprattutto smette di crescere2026-08-23

• [change] SU-529 (terzo giro) — nuvoletta a MISURA FISSA e forma ovale. Ivan, con due immagini in chat: «rotonda che da subito possa tenere sia il cibo che il sonno, e al più si aggiungono, senza allargarla dopo».
  • ⚠️ La richiesta vera non era la forma, era la misura, ed è la parte che cambia il codice: il corpo si dimensionava sul contenuto, quindi con una sola icona era stretto e si allargava all'arrivo della seconda. Ora CLOUD_BODY_W è la misura che serve a due icone e non dipende più da icon_count; con una sola icona, quella sta centrata nello spazio grande.
  • Misurato, non affermato: bbox del contorno identico — 316×308 px a zoom 4x — nei tre casi solo cibo / solo sonno / cibo+sonno. E la controprova sul codice vecchio: prima il bordo destro passava da 664 a 736 fra «solo cibo» e «cibo+sonno», cioè la nuvola si allargava davvero.
  • Forma: scelta la proposta A di Ivan («secondo me è perfetta») — ovale pulito, contorno nero spesso e uniforme, riempimento bianco, codina a due pallini decrescenti. Via la corona di gobbe del giro precedente, via anche _cloud_circles/_crown_bumps/_point_in_circles: la sagoma adesso è un test d'ellisse diretto, cioè meno codice di prima.
  • ⚠️ Il margine dell'ovale non è un numero estetico: 8,5 unità oltre il rettangolo delle icone è il minimo che tiene gli angoli del rettangolo dentro l'ellisse. Un'ellisse si stringe proprio agli angoli, a differenza di un rettangolo — verificato analiticamente prima di spendere un giro di Godot.
  • Il bianco puro era stato bocciato al primo giro perché si confondeva col fondale della strada chiara: rimesso, ma questa volta provato su fondo chiaro E scuro, e il contorno nero spesso basta a staccare la sagoma. Nessun ripiego sul panna.
  • Il confronto ha in cima la scala di gioco reale (1x), non solo gli ingranditi: è la regola imparata al primo giro, dove una sagoma che funzionava a 6x era poltiglia a 1x.
  • Non cambia quando compare: soglie 50 e 25 e ritmo del pulsare invariati, icone sempre quelle dell'HUD.
  • Confronto in TMP/screenshots_claude/SU529_confronto_prima_dopo_giro3.png; tools/preview_status_cloud.py rifatto sulla stessa matematica, col flood-fill anti-buchi che era già stato raddrizzato al giro scorso.

Le bancarelle vendono finalmente la loro merce, e il venditore non fa più l'elemosina2026-08-23

• [fix] SU-539 (secondo KO, dopo la prova sull'Honor 10) — «tutte le bancarelle nonostante lo sprite dolci sapone birra sono sempre associate ai vestiti».
  • ⚠️ La causa sono DUE VOCABOLARI per la stessa bancarella, e nessuno dei due era sbagliato: tipo (clothes, hotdog, beer, candy, igiene) nomina lo sprite e la chiave di traduzione; negozio (clothes, hotdog, liquor, icecream, igiene) nomina il mestiere del banco. Coincidono in tre casi su cinque, ed è per questo che sembravano una cosa sola. _bancarella_type() e _bancarella_prompt() avevano i rami scritti col vocabolario di tipo ma venivano chiamate con negozio: birra e dolciumi non trovavano nessun ramo e cadevano sul return finale, in silenzio, che è il banco dei vestiti.
  • Il rimedio non è solo il match giusto: è rendere rumoroso il ripiego. Il difetto è arrivato fino al telefono di Ivan perché un match che non trova niente restituiva un banco di vestiti senza dire una parola. Ora il ripiego fa push_warning col valore non riconosciuto: la prossima merce che si aggiunge dimenticando un ramo grida invece di travestirsi.
  • Sopra l'array c'è adesso scritto perché i due vocabolari esistono e perché non vanno unificati: tipo è vincolato agli sprite e alle chiavi CSV già pubblicate, negozio ai metodi _use_* di Interactable.gd. Sono tassonomie diverse che capitano a coincidere.
  • 📌 igiene era già corretta, e vale la pena scriverlo: nel KO Ivan ha nominato «dolci sapone birra», ma il sapone descriveva il banco, non un terzo difetto — lì i due vocabolari coincidono. Verificato invece che dedotto: la sonda stampa tutti e cinque.
• [fix] SU-539 — il venditore non è più un bersaglio dell'elemosina. Ivan: «ogni volta che voglio interagire con la bancarella prima chiedo i soldi a lui e poi interagisco con la bancarella».
  • can_be_begged() faceva npc_type == "civilian" and not _is_alarmed, e il venditore è un civile: rubava l'interazione al banco. Ora esclude il venditore ancorato al suo banco. Un venditore senza banco non è «al lavoro» e resta elemosinabile come un civile qualunque, coerente con _update_vendor() che per lui dice «gira come un civile».
  • Un solo punto di modifica chiude anche il multiplayer, verificato e non supposto: sia il ramo locale (Player._get_beggable_npc) sia quello di rete (World._srv_beg) passano già da can_be_begged(). Nessun controllo duplicato in net_resolve_beg.
  • La seconda metà della richiesta era già vera: «al massimo si sposta se suoni la trombetta» — ModularNPC._update_vendor() esce subito se _busk_attracted. Controllato prima di toccare niente.
  • La prova ha una controprova, che è ciò che le dà valore: cinque venditori ancorati a false e un civile di controllo a true nello stesso mondo. Senza il secondo, «nessuno è elemosinabile» sarebbe passato per un successo.

Le quattro icone dell'HUD attaccate ai soldi, dentro il bordo del pannello2026-08-23

• [change] SU-530 (secondo KO, dopo la prova sull'Honor 10) — Ivan: «devono essere sotto ai soldi vicine, possibilmente senza andare oltre il bordo basso del canvas delle stats». La colonna era quella giusta, la distanza no.
  • La causa era una scatola più alta di quello che ci sta dentro. La riga dei soldi è un blocco alto MONEY_ROW_H = 48 px con dentro un'icona da 32 centrata: il fondo della scatola sta 8 px sotto l'ultimo pixel che si vede, e la cifra — centrata anche lei — finisce ancora più in alto. Agganciandosi a money_label.offset_bottom si sommavano 8 px di vuoto invisibile ai 6 di aria voluta: a schermo ne sembravano 14. Adesso il riferimento è _money_icon.offset_bottom, cioè il fondo vero, più REUSE_TOP_GAP = 2.
  • Il secondo vincolo è un «possibilmente», e il codice lo tratta come tale: se la fila sfora il bordo inferiore del pannello viene alzata, ma mai fin sopra i soldi — fra le due richieste vince «sotto ai soldi», che è quella scritta senza riserve. Quando i soldi sono già scesi sotto il pannello (canvas stretto) il vincolo non ha senso e si salta.
  • Misurato: con il pannello che finisce a 94 px, la fila ora occupa 50→82 invece di 62→94. Sta dentro il bordo con 12 px di margine, e l'aria visibile dai soldi passa da ~14 px a 2.

Le quattro icone dell'HUD passano nella colonna dei soldi2026-08-23

• [change] SU-530 (KO) — trombetta, gatto, super e bottiglia non stanno più sotto le barre di fame/sonno/igiene, ma sotto la cifra dei soldi. Ivan: «io le volevo a destra del canvas con fame sonno igiene, dove ci sono i soldi ora, sotto di questi».
  • Perché il primo giro aveva sbagliato pur avendo letto bene il ticket: la descrizione dice «sotto il contatore dei soldi», e il codice le agganciava a p.position.x, cioè al bordo sinistro del pannello. Era vero fino a SU-339, quando i soldi stavano ancora dentro il pannello; da allora i soldi sono usciti a destra e la fila è rimasta dov'era, cioè sotto le barre. Il ticket non era ambiguo: era il codice a essere rimasto indietro di un ticket.
  • Adesso il bordo sinistro della fila è quello del blocco soldi (_money_icon.offset_left), letto dopo che _place_money_block l'ha posato — così la safe-area del telefono se lo porta dietro senza doverla riapplicare a mano.
  • ⚠️ Un vincolo che i soldi da soli non coprono: _place_money_block verifica che il blocco soldi (largo MONEY_BLOCK_W) stia prima della colonna centrale, cioè delle nove vite e della barra del livello. Ma la fila è larga REUSE_ROW_W = 224 px, molto di più: su un canvas stretto finirebbe sotto le testine di gatto anche coi soldi al loro posto. Quando non ci sta, la fila non torna a sinistra — resterebbe il KO — ma scende sotto il pannello, dove la colonna centrale è finita.
  • La griglia dei poteri (SU-389) si sgancia dalla fila: le stava sotto, e con la fila andata via sarebbe rimasto un buco alto 36 px fra le barre e i poteri. Ora si aggancia al pannello. L'unico caso in cui resta appesa alla fila è il canvas stretto, dove anche i soldi scendono sotto il pannello.
  • ✅ E il criterio «il conteggio si legge a 720x1280 logico, che è la misura che decide» adesso è MISURATO — era rimasto NON MISURATO per due giri, perché nessuna delle due forme del provino era quella: 1280x720 senza scala testo, e 1200x540 con scala 1.3. Aggiunta la forma 720logico (1280x720 con le impostazioni del telefono addosso: il ticket scrive la misura in verticale, ma il gioco è in orizzontale, quindi quello che conta è il lato corto a 720). Risultato guardato: a quella forma i soldi non ci stanno di fianco al pannello e tutta la colonna scende sotto — comportamento già previsto — e i conteggi «47» e «1:02» si leggono senza sforzo.
  • Scatti in TMP/L7_SU-530/dopo/, tre forme; il confronto «prima» è TMP/L2_SU534/dopo/, che è lo stato che Ivan ha bocciato.

La classifica online non compariva perché in pausa l'SDK di EOS si ferma2026-08-23

• [fix] SU-474 (KO, secondo giro) — la causa non era nella classifica: era la pompa dell'SDK che smette di girare con l'albero in pausa. Misurata con account e rete veri (ITA_Blackwind, Epic, board SU_SCORE_CENTRO), non con una sonda che finge.
  • Il meccanismo, in una riga: le risposte di EOS le consegna IEOS.tick(), chiamato dal _process dell'autoload del plugin (addons/epic-online-services-godot/runtime.gd:35). Quel nodo non ha un process_mode suo, quindi eredita PAUSABLE. Il pannello di fine partita arriva con get_tree().paused = true (World.gd:7031): lì la pompa si spegne e nessuna chiamata a EOS torna più.
  • Numeri: PRIMA — albero_in_pausa=true, pompa_EOS_gira=false, board su «carica» per esattamente i 20 s di TIMEOUT_SEC, poi STATO_ERRORE e a schermo la sola riga «Nessuna risposta dal mondo». DOPO — pompa_EOS_gira=true, stato=ok righe=3 in ~3 s, submit_finished(esito=ok), e il pannello con le tre righe vere del mondo.
  • ⚠️ Il corollario è più grosso del ticket: in single player NON stava arrivando su EOS nessun punteggio. L'invio scadeva insieme alla lettura, per lo stesso motivo.
  • Perché il rimedio del primo giro non poteva funzionare, ed è la lezione che vale più del fix: accodava le richieste, ma a monte non tornava indietro nessuna risposta da accodare. E il suo provino posava le righe a mano, quindi la pompa non entrava mai in gioco — il provino che semplifica ed esclude proprio il ramo col difetto, di nuovo.
  • Dove sta la riga, e perché non in EOSBridge che sarebbe la casa naturale: EOSBridge è dichiarato prima di EOSGRuntime fra gli autoload (project.godot, righe 58 e 60), quindi nel suo _ready() il nodo del plugin non esiste ancora. Sta invece in _ensure_eos_ready(), l'unico varco che attraversano sia la lettura sia l'invio. La riga si mette da fuori, sul nodo, mai dentro runtime.gd: il plugin è di terzi e si aggiorna da monte.
  • 📌 Un limite che resta, dichiarato: la pompa si alza al primo uso della classifica. Da quel momento vale per tutto EOS, ma prima di quel momento qualunque altra chiamata EOS fatta in pausa (achievement, multiplayer) resterebbe appesa allo stesso modo. Vale un ticket a parte.
  • Due difetti veri trovati per strada nella coda del primo giro, e sarebbero rimasti invisibili: (1) la casella d'attesa era irraggiungibile — sta nel ramo _busy, ma una board in lettura è sempre su STATO_CARICA e usciva un passo prima, quindi la rilettura forzata dopo l'invio veniva buttata ogni volta che l'invio finiva prima della lettura, cioè il caso normale; (2) _libera() scatta quando arrivano i record, non a lettura finita — dopo restano nomi e canali — quindi una richiesta accodata lì restava in casella per sempre e partiva a sproposito alla prima lettura successiva di chiunque. Rimediati con _drain_when_load_ends() agganciato alle due vere fini della lettura. Misurato: la coda si svuota dopo esattamente una rilettura in più, nessun ciclo.
  • ⚠️ Un incidente rimediato, da sapere per le sonde future: questa sonda gira sul progetto vero e con la HOME vera (il token di rinnovo di Epic sta nel portachiavi dell'utente, sotto una HOME finta non ci sarebbe), quindi tocca il settings.cfg vero di Ivan. L'opzione --niente-invio gli toglieva account_publish_consent e non glielo rimetteva. Rimesso a true (verificato sul file), e adesso la sonda lo ripristina e risalva da sé prima di uscire.

Le bancarelle del mercato entrano in citta', col tendone che Ivan ha scelto2026-08-23

• [feat] SU-538 (KO) — i cinque banchi rigenerati col TENDONE PIENO e senza nessuna scritta. Ivan: «il tendone pieno a me piaceva, possiamo usare quella versione e provare a implementarli nel gioco? senza i nomi sul tendone, solo tendone».
  • ⚠️ Questo KO rovescia due vincoli scritti nel ticket, ed e' il motivo per cui vale la pena rileggerlo prima di rilavorarlo. Il primo: «il venditore sta dietro al banco, il disegno non lo deve coprire» — Ivan ha guardato le due versioni e ha scelto proprio quella che quel vincolo vietava. Il secondo: le insegne CLOTHES / HOT DOGS / BEER / CANDY / SOAP & DUCKS — via tutte, perche' a 56 px non si leggevano e la merce si riconosce da sola. Chi rilavora un ticket bocciato leggendo solo la descrizione qui avrebbe rifatto esattamente la versione gia' respinta.
  • Rigenerati con Codex dai quattro riferimenti del giro precedente, ma col tentativo v1 promosso da «errore da non ripetere» a «versione giusta da seguire»: e' l'unica riga dei prompt che cambia davvero, e ribalta il risultato. Divieto di testo ripetuto sia nell'intro sia nel prompt per tipo. Riduzione con PIL/BOX e alfa binaria, come prima.
  • Cinque su cinque al primo giro, nessuna rigenerazione. Verificato a occhio sugli originali 1536×1024 e sugli zoom ×14: nessuna lettera rimasta, tendone pieno e continuo — igiene compreso, che in v1 era l'unico venuto male (tendone spezzato in due pezzi piu' un cartello). 56×36, alfa binaria (solo 0 e 255), pixel opachi 1302 / 1353 / 1256 / 1036 / 1421 su 2016.
• [feat] SU-539 — i cinque PNG importati nel progetto, e il placeholder a quattro rettangoli si e' spento da se'. Nessuna riga di WorldGenerator.gd toccata, come il ticket prometteva: il codice cercava gia' res://assets/sprites/world/bancarella_<tipo>.png.
  • ⚠️ Il blocco «non si lavora finche' SU-538 non e' Fatto» e' stato superato di proposito, e la decisione e' tracciata sul ticket: nel KO di SU-538 Ivan chiede lui stesso di provarli in gioco. Aspettare il suo «Fatto» avrebbe fatto perdere un giro per una cosa che aveva gia' chiesto.
  • Il criterio «il venditore resta dietro al banco» va letto a meta', e vale la pena scriverlo perche' altrimenti al prossimo giro sembra un difetto: che il tendone copra gambe e bacino del venditore ora e' voluto (vedi sopra). Resta invece pienamente valida l'altra meta', «nessuno resta piantato contro il proprio banco»: misurata, non dedotta — nessun venditore dentro BANCARELLA_MURO, margine 17,1-20,5 px, 0,0 px di sconfinamento dalla zona in 8 s, e spostamento di 14,8-18,3 px, cioe' si muovono davvero invece di stare incastrati.
  • Citta' invariata col gate spento: 0 pixel diversi su 921.600, stesso seme, quartiere «centro», bancarelle_enabled true contro false. ⚠️ Il confronto NON e' stato fatto su Main.tscn: i pedoni che camminano avrebbero introdotto differenze di timing e quindi un KO falso. Si usa WorldGenerator nudo con camera ferma, come gia' fa shot_su270_regressioni.gd.
  • Import con lo stesso preset del bagno pubblico (verificato identico), non coi default: un .import sbagliato avrebbe dato uno sprite sfocato che sembra un difetto di disegno.
  • 📌 Notato per strada, fuori scopo e non toccato: arch_vendor non ha varianti sprite proprie in NPCDatabase, quindi i venditori riusano l'aspetto generico. Si vede negli scatti ed e' preesistente.
  • ⚠️ In due dei cinque scatti (igiene e hotdog) il banco cade proprio dietro la barra dell'XP dell'HUD, che ne copre il tendone: e' inquadratura del provino, non un difetto del gioco. I banchi che si leggono meglio sono quelli in basso negli stessi scatti.

Il foglio del giornale è carta, non carta velina2026-08-23

• [fix] SU-532 (secondo KO, in giornata) — il foglio che si sfoglia adesso è opaco. Ivan, guardando la striscia appena consegnata: «la pagina che si sfoglia non deve avere nessuna trasparenza, deve essere piena, se si sfoglia al contrario vuota dietro».
  • ⚠️ Il difetto NON stava dove sembrava. Il sospetto naturale era il rovescio: PageCurl.gd aveva TRASPARENZA_ROVESCIO = 0.16, cioè la stampa che traspariva dal retro, messa apposta nel giro precedente perché «rende foglio un'ombra che si muove». Tolta — ed era giusto toglierla, il KO la boccia esplicitamente — ma il foglio restava trasparente lo stesso.
  • La misura che ha chiuso la questione: colorare di magenta il solo rovescio e rifare lo scatto. Le testate «THE STREET» e «BARBONE TERMINA» si leggevano SOPRA il magenta, non sotto: quindi a essere trasparente era la faccia disegnata dopo, cioè il DRITTO. Un primo giro di colorazione (dritto, rovescio e parte distesa tutti tinti insieme) aveva dato una mappa ambigua e mi aveva mandato fuori strada: la prova buona è stata colorare una faccia sola.
  • La causa: _tex è la fotografia del viewport, e si porta dietro il canale alfa della schermata. Dove la pagina non era opaca al momento dello scatto, draw_polygon con la sola texture lascia vedere attraverso il foglio — e sotto c'era il fondo scuro del gioco.
  • Il rimedio, in _disegna_carta e quindi in un posto solo: sotto la stampa ci va sempre un poligono di carta opaca, con la stessa luce Lambert della stampa (se prendesse luce piena, il rotolo avrebbe le ombre solo sull'inchiostro e non sul foglio). Costa un draw_colored_polygon per striscia — 34 poligoni in più per fotogramma, su una transizione da 0,32 s.
  • Risultato guardato, non dedotto (TMP/L2_SU-532_pieno/): il lembo alzato è carta piena in tutta la corsa, il retro è carta vuota — che è la seconda metà di quello che Ivan chiedeva — e il fondo del gioco non passa più da nessuna parte.

L'ombra del rider copre le ruote anche in obliquo, e stavolta la misura è quella giusta2026-08-23

• [fix] SU-533 (KO) — DELIVERY_SHADOW_SCALE da (2.0, 1.0) a (2.0, 2.0), cioè 28×8 px invece di 28×4. Ivan: «deve esser meno ellittica, perché deve coprire anche le ruote durante gli spostamenti obliqui NE NO SE SO».
  • La larghezza non era mai il problema. Il primo giro aveva scalato solo in orizzontale, e 28 px coprono già tutto (il massimo misurato è 25 px nel laterale, 14-18 in obliquo). Quello che mancava era l'altezza: nelle pose diagonali la ruota anteriore tocca terra 3-6 px più in basso di quella posteriore, e la lamina alta 4 px non ci arrivava. Il KO dice «ruote scoperte», non «ombra stretta»: rileggerlo alla lettera indicava già dove guardare.
  • ⚠️ Un giro intermedio sbagliato, e vale la pena raccontarlo perché l'errore è insidioso. Il secondo tentativo aveva rimisurato la sagoma gambe+ruote — bbox alfa, righe 19-31 dello sprite — trovandola alta 13 px in ogni direzione, e aveva scalato l'ombra 3,25× in verticale. La misura era corretta, l'inferenza no: una ruota è un cerchio in piedi, la sua estensione verticale a schermo è quasi tutta altezza sopra il terreno, non impronta a terra. Il risultato era una lastra rettangolare che, col nodo Shadow a position = (0, 6) e la texture centered, sbordava ~6,5 px sotto la linea d'appoggio — la «pozza» che il primo giro aveva evitato apposta e in cui il secondo è ricascato. Bocciata in casa guardando lo scatto, prima che arrivasse a Ivan.
  • La misura giusta sono i punti di contatto, non la sagoma: profilo «riga più bassa opaca per colonna» sui frame sheet, direzione per direzione. Laterale: i due contatti alla stessa quota (spread ≈ 0). Diagonali se/ne: 3-6 px. Frontale/posteriore: entro 3 px.
  • Scelto fra due candidati fotografati, non a naso: (2.0, 2.0) e (2.0, 2.5). Sbordo del bordo inferiore dell'ombra oltre il punto più basso della ruota: 2 px contro 3 (era ~12 col 3,25). Equivalenti a vista, tenuto il 2.0. Rapporto finale ~3,5:1, lo stesso dell'ombra di un pedone: si legge come ombra e non come pozza, che è ciò che «meno ellittica» deve voler dire.
  • Il criterio «le ombre degli altri NPC non cambiano di un pixel» riprovato come tale: confronto pixel-per-pixel sull'NPC di controllo, 0 pixel diversi su 10 coppie prima/dopo. ⚠️ Serviva un seed() fisso nella sonda: senza, il colore casuale dell'NPC di controllo cambiava fra i due lanci e il confronto dava differenze che non c'entravano nulla con l'ombra.
  • Il commento sopra la costante adesso registra entrambi i tentativi sbagliati e perché: il numero giusto senza la misura giusta scritta accanto è un invito a rifare lo stesso errore.
  • Scatti in TMP/L1_SU-533/prima/, /dopo/, più i due candidati in /scale_2.0/ e /scale_2.5/.

La pagina del changelog è online, e sta su /changelog/2026-08-23

• [feat] SU-536 (KO) — pubblicata su https://www.streetuniversitygame.com/changelog/ . Ivan aveva dato l'ok a pubblicare ma non al percorso: «va in /changelog/», non in /novita/. Non c'era niente da redirigere — la pagina non era mai andata online — quindi è nata direttamente all'indirizzo giusto.
  • Rinominata la cartella di uscita build/sito_novita/ → build/sito_changelog/ e l'argomento --out di tools/genera_pagina_changelog.py, più i canonical delle pagine.
  • ⚠️ Nel generatore la parola «novita» ha due significati diversi, e solo uno andava toccato: il nome della cartella (rinominato) e il concetto di dominio «le novità grosse in evidenza» — compute_novita, NOVITA_TOKEN_RE, .novita-list, --novita-bg. Un find&replace cieco avrebbe rinominato anche il secondo, che è il nome giusto della cosa. Restano intatti, titolo della pagina compreso.
  • WORKFLOW/04_RELEASE.md punto 5b riscritto: percorso nuovo e autorizzazione permanente a pubblicare questa pagina (Ivan, 2026-08-23), che è un'eccezione dichiarata alla regola «verso l'esterno decide Ivan». Merge su main, tag e release restano fuori, sotto la loro regola separata al punto 5.
  • Numeri della generazione: 15 versioni, 339 voci, 72 novità in evidenza (il tetto di 6 per versione è scattato su 11 versioni), 8 sostituzioni «Street University» → «Street University», 15 pagine di dettaglio.
  • La verifica che chiude il ticket non è il push ma l'URL: HTTP 200 al quarto tentativo (~35 s di GitHub Pages), contenuto controllato — canonical giusto, versione più recente v0.31-dev con le sue novità, e non la home del sito servita al suo posto. Provata anche una pagina di dettaglio: /changelog/v/v0-31-dev.html risponde 200, quindi i link relativi dell'indice reggono sotto il percorso nuovo.
  • 📌 Una cosa da tenere d'occhio alla prossima release: la pagina di dettaglio della versione in corso pesa 831 KB (v0.31-dev accumula le voci di tutto lo sviluppo). Si apre, ma su una connessione mobile lenta è tanto: se cresce ancora vale la pena spezzarla per mese.
  • Commit sul repo pubblico BlackwindITA/street-university-site: 4494b68.

Il foglio del giornale si gira in un terzo di secondo2026-08-23

• [change] SU-532 (KO) — la transizione dello sfoglio da 0,55 s a 0,32 s. Ivan, dopo aver guardato il giro precedente: «Ko più veloce l'animazione». Meccanica invariata: resta il foglio fotografato dal viewport e riarrotolato sul cilindro, con la cerniera che scorre dal basso a destra verso l'alto a sinistra.
  • ⚠️ Il KO ha ribaltato una scelta che era stata presa apposta, e il commento nel codice la difendeva. RunReport.gd diceva testualmente che 0,30 s erano troppo pochi perché «la piega passa in quattro fotogrammi», e che 0,55 era il tempo per vedere il rotolo attraversare la pagina. Quel commento è stato riscritto, non lasciato lì: se resta la vecchia motivazione, alla prossima sessione qualcuno rialza il numero in buona fede. Adesso dice chi l'ha bocciato, quando, e con quale valore è stato sostituito.
  • Perché 0,32 e non 0,30: a 60 fps sono ~19 fotogrammi contro i ~33 di prima. La preoccupazione del giro precedente (la piega che sparisce) è stata verificata invece che dedotta: nella striscia nuova la piega è leggibile in 5 fotogrammi su 9 — l'angolo che si stacca, il rotolo a metà pagina col rovescio del foglio e l'ombra portata, e pagina 2 già visibile sotto.
  • Un'ipotesi caduta, e conta perché era la più probabile: si sospettava che oltre alla durata ci fosse un'accelerazione «molle» a far sembrare lento l'inizio — il ramo di ripiego (foglio che si chiude verso il dorso, usato solo quando la fotografia del viewport non si può fare) usa infatti progress*progress. Ma il ramo vero riceve un progress lineare e PageCurl.set_progress() lo mappa linearmente sulla posizione della cerniera: nessuna easing da correggere. Per questo PageCurl.gd non è stato toccato.
  • Sonda nuova scripts/tools/shot_l2_su532_velocita.gd + runner tools/autotest/shot_l2_su532.sh: campiona la transizione a passo e numero di scatti scelti da riga di comando, quindi la stessa sonda ha prodotto sia la striscia nuova (9 scatti a 0,04 s) sia quella vecchia (12 a 0,055 s) per il confronto. Scatti in TMP/L2_SU-532/nuovo/ e /vecchio/.

SU-484 chiuso sull'iPad: senza riscaldamento il tramonto costa un terzo di secondo, due volte2026-08-23

• [fix] SU-484 (KO) — misurato sull'iPad, ed è la piattaforma dove il riscaldamento degli shader conta di gran lunga di più. Ivan: «provalo su ipad collegato al mac e sbloccato, ho notato che anche quando diventa tramonto fa uno scatto al cambiare di luce».
  • A FREDDO (riscaldamento spento), iPad Air 5, Apple M1 GPU: 2 compilazioni CANVAS durante la spazzolata dell'orologio, alle 17:02 (night_factor 0,006, il ColorRect del bagliore notturno) e alle 18:24 (0,245). Quei due frame durano 356,19 ms e 353,91 ms contro una mediana di 16,68 — 21,4× e 21,2×. Un terzo di secondo di gelo, due volte. È esattamente lo scatto che Ivan ha visto.
  • A CALDO (com'è in gioco oggi): 0 canvas, 0 specializzazioni, 0 draw su 360 frame, e il frame peggiore di tutta la spazzolata è 18,91 ms = 1,1×, che per giunta non cade al tramonto. Verificato due volte su due avvii indipendenti.
  • 📌 Il riscaldamento è acceso di default (World.riscalda_shader := true, dal giro del 21/08): quindi il gioco che si spedisce oggi lo scatto non ce l'ha già più. Quello che Ivan aveva visto era su una build precedente.
  • Le tre piattaforme, adesso che ci sono tutte, dicono cose molto diverse — ed è la risposta al criterio «su quali piattaforme la precompilazione serve davvero»:

    · iOS: 21×. Senza riscaldamento è ingiocabile al tramonto.

    · macOS: 2,5× (21 ms contro 8,2 di mediana). Si nota, ma è un inciampo.

    · Android (Honor 10, Mali-G72): le compilazioni ci sono — 2, allo stesso innesco — ma non sono nemmeno i frame più lenti (mediana 61 ms, i 12 peggiori cadono altrove). Lì probabilmente non si vede.

    L'innesco è lo stesso su tutte e tre: le 17:02, il frame in cui nasce il ColorRect del bagliore notturno.

  • QUANTO COSTA IN AVVIO, l'altro criterio: su iPad i primi 10 frame passano da 4196 ms a freddo a 6045-6141 ms a caldo, cioè ~1,9 s in più. Su macOS era dentro il rumore (+57 ms). ⚠️ Ma quel tempo adesso sta sotto il velo di SU-537, che è nato lo stesso giorno per un'altra ragione: il giocatore vede «CARICAMENTO», non un blocco.
• [fix] Difetto nella sonda, trovato sbagliando due volte. probe_su484_tramonto_ipad.gd faceva _caldo = not (argv.size() > 0 and argv[0] == "freddo"), che ricalcola sempre: con argv vuoto dà true. E su una build esportata argv è sempre vuoto — gli argomenti da riga di comando non arrivano a OS.get_cmdline_user_args(), né su iOS né su Android. Quindi il giro «freddo» si esportava, si installava, si lanciava e misurava di nuovo il caldo, dicendolo pure nell'intestazione. Adesso senza argomenti vince il valore cotto nel file, e l'argomento serve solo da desktop.
• ⚠️ Due cose sul tooling iOS, per chi ci ripasserà. xcrun devicectl device process launch non fa partire davvero l'app: processo vivo, PID stabile, display acceso, e zero output e zero file scritti per oltre venti minuti, tre tentativi. Toccando l'icona a mano parte al primo colpo. E il posizionale «scena» passato a devicectl viene ignorato dai template esportati: la sonda va cotta come main_scene.
• 📌 E il blocco della firma non era quello che sembrava: errSecInternalComponent in CodeSign voleva dire portachiavi di login chiuso, non un problema di profilo o di team. ⚠️ Il tranello è che security find-identity continua a elencare le identità anche col portachiavi chiuso — legge i metadati, non le chiavi private. Sbloccato quello, la stessa ricetta che falliva è riuscita tre volte di fila al primo tentativo.

Via il ponteggio: la regola della tromba adesso vive in un posto solo2026-08-22

• [change] SU-524 (debito dichiarato, chiuso) — cancellata la regola VECCHIA dell'hint della tromba, che era rimasta accesa in Player.gd.
  • Il giro di stamattina aveva dovuto lasciare un ponteggio: la regola d'ambiente viveva ancora nel Player (due trigger — «fermo vicino a un passante per 3 s» e «folla per 4,5 s cumulativi») e scattava ben prima dei 3:00, quindi la run del criterio «tromba usata a 1:30 → zero comparse» ne vedeva una lo stesso. Player.gd apparteneva a un altro lotto, e l'HUD la zittiva dall'esterno alzando un flag interno del Player.
  • Adesso Player.gd è libero e il ponteggio è sparito insieme a ciò che doveva puntellare: via _update_busk_hint(), _fire_busk_hint(), _count_npcs_in_radius(), _has_busked_this_run e le quattro costanti BUSK_HINT_* — 63 righe di funzioni più le dichiarazioni. Via anche HUD._mute_player_busk_hint() e la sua chiamata a ogni frame.
  • La chiave di traduzione PLAYER_BUSKING_HINT resta viva: la riusa l'HUD, è lo stesso testo in otto lingue. Cancellarla avrebbe lasciato muto l'hint nuovo.
  • ⚠️ Anche la sonda controllava il ponteggio, ed è il tipo di criterio che invecchia peggio: probe_su524_hint.gd verificava «regola vecchia del Player zittita», cioè che il flag fosse a true. Tolto il ponteggio quel criterio sarebbe diventato un KO falso. È stato sostituito con quello giusto e più forte: nel Player non deve esistere nessuna funzione della vecchia regola. E si guarda la lista dei metodi, non il flag — un flag assente e uno a false si leggono uguali (get() torna null, bool(null) è false), quindi sul flag il criterio sarebbe passato anche col ponteggio rimesso.
  • Misurato dopo la rimozione: probe_su524.sh 15 criteri, 0 KO, zero SCRIPT ERROR. Fra questi, invariati: a 3:00 una comparsa e mai una seconda; con la tromba usata a 1:30 zero comparse in tutta la run (è il criterio per cui il ponteggio era nato, e adesso passa senza); il suggerimento ambientale sparisce a 4,99 s con 0 riaccensioni; il gate hints_enabled OFF spegne tutto.

La nuvoletta torna a essere una nuvola, e il RICOMINCIA non era rotto come credevo2026-08-22

• [change] SU-529 — la nuvoletta di fame e sonno, ridisegnata a codice. Ivan: «troppo brutta». Resta disegno a codice: passare a sprite generato avrebbe aperto la coppia di ticket generazione+implementazione.
  • Cosa non andava, in concreto: gli otto cerchi avevano raggi tutti diversi, quindi una gobba più alta e un lato più pieno dell'altro; e il riempimento bianco puro si confondeva col fondale della strada chiara.
  • ⚠️ Il primo tentativo ha risolto il difetto sbagliato: gobbe pari sì, ma il profilo diventava una pillola con due tacche — regolare e non più una nuvola. Bocciato in casa, prima di arrivare a Ivan.
  • Il secondo aggiunge una CORONA di gobbe più piccole che sporgono oltre il bordo del corpo (5 sopra / 4 sotto con due icone, 3 e 3 con una sola). Essendo puramente additiva — unione di cerchi — non può reintrodurre buchi né scoprire le icone. Riempimento panna, la stessa tinta del doppio contorno già usata altrove.
  • La prova che mancava al primo giro: tutti gli scatti erano ingranditi, e una sagoma che funziona a 6x può essere poltiglia a 1x — che è come la guarda chi gioca. Adesso il confronto ha in cima la scala di gioco reale.
  • Trovato per strada: il controllo anti-buchi di tools/preview_status_cloud.py era un'euristica («3+ lati pieni = buco») che avrebbe dato falso positivo su ogni incavo fra due gobbe, cioè proprio su ciò che la corona introduce apposta. Sostituito con un flood-fill vero dal bordo.
  • Non cambia quando compare: soglie 50/25, ritmo del pulsare, icone dell'HUD e posizione dei pallini di pensiero sono invariati, verificati uno per uno.
• [fix] SU-537 (seguito) — anche RICOMINCIA passa dal velo, ma la ragione non è quella che pensavo, ed è giusto dirlo.
  • Misurato: sul RICOMINCIA il grigio non c'era. reload_current_scene() dava 0 frame piatti, perché il grigio dell'avvio nasceva dai 508 ms di load() a cache fredda, e al riavvio la scena è già in cache. Quello che il velo cambia non è il grigio ma cosa si guarda: 352 ms di ultimo frame del gioco morto, congelato, diventano 4 frame di «CARICAMENTO», per +64 ms. Su desktop è un pareggio; su iPad, dove _ready è molto più lungo, è la differenza fra «si è piantato» e «sta caricando». È una scelta di resa, non la cura di un difetto misurato.
  • ⚠️ E la prima stesura era sbagliata in due punti, trovati misurando. (1) Il percorso scritto in chiaro: HUD.tscn è istanziato anche da TutorialWorld.tscn, e RICOMINCIA c'è anche lì — con Main.tscn fisso, ricominciare dentro il tutorial ne usciva, e per giunta saltando il reset che TutorialManager fa in quel passaggio, quindi coi soldi e il gatto del tutorial addosso. Ora si legge current_scene.scene_file_path, che è esattamente ciò che ricaricava reload_current_scene(). (2) Lo scambio di scene a mano non regge il caso in cui vecchia e nuova sono lo stesso mondo: montando prima la nuova, add_child la rinomina e player, NPC e polizia risolvono il gruppo world sul mondo morente; staccando prima la vecchia, quella resta viva fuori dall'albero e durante il _ready della nuova un EventBus.notify() arrivava al vecchio HUD, a raffica. Adesso lo scambio lo fa il motore con change_scene_to_packed(), che libera davvero prima di montare: scena nuova, un solo nodo nel gruppo world, zero errori.

L'ombra del rider copre anche la bici, e il pannello di debug ci sta dentro2026-08-22

• [fix] SU-533 — sotto il fattorino in bici c'era l'ombra di un pedone. Il nodo Shadow esisteva già in scena ma lo script non lo referenziava: bastava agganciarlo e dargli una scala per archetipo.
  • La misura non è a occhio: bbox alfa sui frame sheet veri (arch_delivery_*_sheet.png, vista laterale idle_e/walk_e) — rider+bici largo 26-29 px contro 17-19 px di un NPC normale, cioè 1,5-1,9x. Arrotondato a 2,0 solo in orizzontale: la bici è lunga, non alta, e allargare anche in verticale avrebbe fatto una pozza.
  • Il gate è sull'archetipo (arch_id == "arch_delivery"), mai un default nuovo. Il criterio «gli altri NPC non cambiano di un pixel» è stato provato come tale: confronto pixel-per-pixel prima/dopo dell'NPC di controllo nello stesso scatto, bbox delle differenze = None, zero pixel diversi.
• [fix] SU-523 — il pannello di debug usciva dal viewport, e la causa non era la larghezza dichiarata. Due CheckBox con didascalia lunga chiedevano 361 px di minimo contro un pannello dichiarato 330; un Control non rende mai meno della propria minimum-size, e con l'ancoraggio a destra la crescita si scarica sul bordo destro — spingendo il pannello fuori dallo schermo. Trovato con una sonda di introspezione, non a occhio.
  • Pannello da 330 a 420 px (35 di margine sul minimo vero) e offset da −340 a −430, stesso stacco di 10 px dal bordo. In più le 34 righe di bottoni sono passate da HBoxContainer a HFlowContainer: una riga da sei bottoni adesso va a capo invece di sforare, che è il rimedio giusto a prescindere dalla larghezza.
  • Lo scatto «prima» è stato ottenuto sincronizzando una copia di lavoro con git show HEAD:…, senza mai toccare la working tree vera.

Il momento grigio non c'e' piu', e la scelta del quartiere e' una mappa di carta2026-08-22

• [fix] SU-537 — il «momento grigio» a inizio partita era 510,8 ms della tinta di sgombero del motore, e adesso non c'e' piu' un frame. Il ticket chiedeva di misurare prima, e la misura ha cambiato il rimedio.
  • La misura, un frame alla volta dal bottone: frame 0-11 dissolvenza al nero del menu (483 ms) · frame 12 = 510,8 ms di tinta PIATTA (0.302, 0.302, 0.302), che e' esattamente la default_clear_color di Godot · frame 13 primo frame di gioco. Grigio a schermo 413 ms, con la musica gia' partita da 376. Scomposizione: load(Main.tscn) 508,2 ms + instantiate() 0,8 + add_child→World._ready 375,0 = 884 ms sincroni. Quindi e' un caricamento vero, non un frame vuoto: si copre, e si chiude anche il buco.
  • ⚠️ Le cause erano due, e la seconda spiega perche' una mezza soluzione non bastava: change_scene_to_file() butta la scena vecchia prima di avere la nuova, e il nodo Music di Main.tscn ha autoplay = true — la musica partiva coi figli, non col play() di World. Spostare il play() non avrebbe cambiato niente.
  • Il rimedio e' LoadingVeil.gd: carica la scena in un thread sotto un velo «CARICAMENTO...» e scambia le scene nell'ordine che non lascia buchi. Dopo: zero frame piatti, zero grigio, e il primo frame di gioco arriva con la musica a 0,003 s. Aspetta due frame disegnati sotto il velo — gli stessi in cui il riscaldamento shader dipinge i suoi pixel 1x1 — cosi' il primo frame che il giocatore vede e' gia' caldo.
  • Costo, A/B con lo stesso strumento e senza catture, 4 giri per parte: nativo 930 ms medi contro 987 col velo, cioe' +57 ms (6%), e nessun tempo minimo imposto. use_sub_threads = true scartato: 1106 / 1098 / 2769 ms.
  • In headless e col bot il velo si salta da se' e si cambia scena come sempre: i collaudi passano dalla stessa strada di prima.
  • Anche RICOMINCIA passa dal velo, non piu' da reload_current_scene(): ricominciare e' il gesto che si fa piu' spesso, e cadeva nello stesso grigio.
• [change] SU-484 (KO) — misurato il tramonto, e non c'era niente da aggiungere. Ivan: «anche quando diventa tramonto fa uno scatto al cambiare di luce».
  • Lo strumento del giro precedente guardava un solo contatore. Adesso se ne contano tre (CANVAS + SPECIALIZATION + DRAW), forzando l'orologio da 12 a 24 a due minuti per frame.
  • A FREDDO lo scatto c'e' ed e' localizzato: la compilazione cade alle 17:02 di orologio (night_factor 0,006), nel frame in cui nasce il ColorRect del materiale del bagliore notturno. Quei frame durano 21,1 / 20,1 / 19,9 / 19,8 ms contro una mediana di 8,2 — due volte e mezzo.
  • A CALDO, cioe' com'e' in gioco oggi, su tre giri: 0, 0 e 0. Censimento: 14 shader nel progetto, il riscaldamento ne scalda 14. Zero righe cambiate per questo ticket su macOS — resta da misurare su iPad, che e' dove Ivan lo scatto lo ha visto.
• [feat] SU-527 — la scelta del quartiere non e' piu' un elenco: e' una mappa della metropolitana di carta. Foglio con la nostra LINEA G gialla che attraversa la mappa, linee finte di altri colori che la incrociano e le corrono in parallelo, pannello largo il doppio (tetto da 760 a 1520), pallini grossi col nome sotto, e accanto a ogni fermata una miniatura della mappa vera di quel quartiere. Le fermate chiuse portano il cartello «lavori in corso» al posto della miniatura e del nome, con l'indizio di sblocco che il menu mostrava gia'. [NOVITA']
  • La navigazione non e' stata reinventata: ←/→, tap e conferma esistevano gia', e' cambiata solo la resa. Il foglio, i pallini e il cartello sono tre Control nuovi che disegnano; MainMenu calcola la griglia e passa il percorso della linea.
  • Il giallo e' stato PROVATO prima di adottarlo, come chiedeva il ticket: giallo nudo su carta si smorza, giallo con carreggiata scura stacca, l'arancione litiga con la linea finta rossa. Resta il giallo di Ivan, col contorno scuro sotto — nessuna alternativa da proporre.
  • Le otto miniature sono generate una volta sola da una sonda e committate come asset (384x240): costruire otto citta' all'apertura del menu sarebbe costato secondi. I semi sono 5270001…5270008, cosi' si rigenerano identiche.
  • Il tocco e' stato provato davvero, con un InputEventScreenTouch vero e la posizione portata da logico a finestra: pallino 76x76 logici a 720x1280, bersaglio del tocco = la cella intera, 467x309. Serpentina 4x2 in orizzontale, 2x4 in verticale.
  • ⚠️ Tolto il 🔒 da MENU_METRO_LAVORI: era un'emoji dentro un testo di gioco, che in questo progetto non si usano.
  • ⚠️ Gli indizi di sblocco piu' lunghi vengono ellissati nelle celle strette; il testo intero resta nella scheda in fondo.

Il CHANGELOG diventa una pagina che si legge2026-08-22

• [feat] SU-536 — le novità di ogni versione su una pagina web, generata dal CHANGELOG.md del repo. Nuovo tools/genera_pagina_changelog.py (Python 3, solo libreria standard, nessuna rete), più il passo di rigenerazione in WORKFLOW/04_RELEASE.md. La pagina non è ricopiata a mano: alla seconda release sarebbe già vecchia, ed è il primo criterio del ticket.
  • Dove va: nel sito pubblico che esiste già — BlackwindITA/street-university-site, servito da GitHub Pages su www.streetuniversitygame.com — in novita/. Il repo del gioco è privato, quindi Pages da lì non era un'opzione.
  • ⚠️ Il primo giro aveva sbagliato la cosa che il ticket chiede davvero. La regola automatica produceva 476 «novità in evidenza» su 331 voci: se quasi ogni voce è in evidenza, l'evidenza non esiste. Stretta a: solo bullet di primo livello, solo [feat], tetto di 6 per versione — e il taglio è silenzioso per il lettore ma loggato dal generatore (v0.31-dev: 92 candidate, 6 mostrate), perché un taglio non dichiarato si legge come copertura completa. Risultato: 72 su 332 voci in 15 versioni. Il marcatore manuale [NOVITA'] su un bullet di primo livello spegne l'automatico per quella versione e vale da solo, senza tetto (oggi non è usato da nessuna parte).
  • ⚠️ E aveva sbagliato anche il peso: 1,97 MB in un file solo non è «si legge da telefono». Adesso sono due livelli — un indice da 14 KB con le sole novità di ogni versione, e una pagina per versione col dettaglio (la più pesante è v0-31-dev.html, 785 KB, che da sola ha 109 voci).
  • «Street University» non compare: sostituito in generazione (mai nel CHANGELOG.md, che è storia) in 7 occorrenze. Il gioco si chiama Street University.
  • Tre difetti di conversione trovati guardando la pagina, non scrivendola: una tabella con la prima colonna vuota perdeva una cella; un URL dentro backtick si mangiava il tag che lo chiudeva; e un glob sprites_raw/** dentro un code-span appaiava i suoi asterischi con un grassetto vero più avanti, rompendo entrambi. Risolto isolando il codice con placeholder prima di grassetti e URL, e riverificando tutte e 16 le pagine con html.parser: 0 tag sbilanciati.
  • 📌 Non pubblicata: il comando di push sul repo del sito sta nel report e in 04_RELEASE.md, e lo lancia Ivan o l'orchestratore col suo ok. Pubblicare è un'azione verso l'esterno.

La pausa ritrova la sua scritta, il conteggio esce dall'icona, e il giornale si sfoglia davvero2026-08-22

• [fix] SU-534 — in pausa la scritta finiva DENTRO il primo pulsante. Misurato prima di toccare niente: la Label era ancorata al centro dello schermo con offset fissi +24/+50, mentre il menu vive intorno a +145. A 1280x720 con quattro voci il menu sta a 37..253 e la scritta a 24..50 — aria −229 px, cioè sovrapposta. Adesso _layout_pause_menu() conta lo spazio della riga quando decide se il blocco ci sta, e la scritta si posa sotto l'ultima voce: aria 14 px su desktop, 8 sul telefono (lì tocca il margine basso).
• [change] SU-530 — il conteggio esce dall'icona. Metà del lavoro c'era già da SU-388 («sotto i soldi»): mancavano l'ordine e il numero leggibile. Fila ora trombetta · gatto · super · bottiglia, e il conteggio è una Label a sé a corpo 18 invece di 10, in una colonna riservata sempre presente — se comparisse solo a cooldown attivo, le icone a destra ballerebbero a ogni uso.
  • Una sorpresa da tenere: con la colonna a 30 px la stringa «1:02» ne misurava 36 e sbordava di 2 px sull'icona successiva, perché una Label non si stringe sotto il proprio minimo. Colonna a 40, riverificato.
• [change] SU-524 — i suggerimenti spariscono, e quello della tromba si vede una volta sola. L'hint ambientale resta 5 secondi (proposta del ticket, consegnata come costante nominata «da tarare») e non ricompare più nella run appena il giocatore ha fatto quell'azione. Quello della tromba non è più «ogni tanto»: si guarda il cronometro a 3:00 e, se la tromba non è ancora stata usata, compare una volta sola; se è già stata usata prima, non compare mai. Schema copiato da _check_clothes_hint, che è già in casa.
  • ⚠️ La scritta si spegne con modulate, non con visible, e non è un vezzo: visible lo riscrive il Player a ogni passo di fisica, e due scrittori sulla stessa proprietà avrebbero prodotto un lampeggio. La sonda lo verifica contando le riaccensioni con un passante vero iniettato, non a fisica spenta.
  • ⚠️ PONTEGGIO DA TOGLIERE, dichiarato: la regola vecchia della tromba vive in Player._update_busk_hint() e i suoi trigger scattano ben prima dei 3:00. Player.gd apparteneva a un altro lotto in questo giro, quindi per ora l'HUD la zittisce dall'esterno alzando il flag del Player. Chi tocca Player.gd deve cancellare quelle due funzioni e questa riga insieme.
• [change] SU-531 — la seconda pagina del giornale è solo il punteggio, e più grande. Via «Giorni sopravvissuti», «Soldi guadagnati», «Imprese:» e «Miglior punteggio»: restano motivo, PUNTEGGIO e classifica. Le tre righe in meno sono lo spazio da cui viene il "più grande": corpo da 18/22 a 24/30, box da 600/900 a 720/1020, con la riduzione automatica lasciata dov'era. Zero stringhe nuove nei CSV: le righe di casa riusano la chiave già tradotta della classifica del mondo.
• [feat] SU-532 — un foglio che si gira, non una dissolvenza. Nuovo PageCurl.gd: fotografa la pagina dal viewport, spegne il foglio vero e ridisegna la texture arrotolata su un cilindro attorno a una cerniera che scorre dal basso a destra verso l'alto a sinistra — 34 strisce draw_polygon con UV, ordinate per altezza, con l'ombra portata su 12 fette. Niente shader (il compile-check non li valida e uno rotto sembra giusto).
  • ⚠️ clip_contents non serviva e sarebbe stato sbagliato: ritaglia con uno scissor allineato agli assi, quindi su un nodo ruotato non taglia in obliquo.
  • Pagina 2 adesso è davvero SOTTO e aspetta: RunReport emette finished all'inizio del giro, così il foglio scopre la classifica invece del buio, e la vecchia comparsa non si arma più.
• ⚠️ Due sonde ora falliscono APPOSTA e hanno un avviso in testa, non sono state riscritte: shot_su475_voltapagina.gd verificava il movimento che SU-532 toglie, e su207_probe.gd si aspetta ancora «Giorni sopravvissuti» in pagina 2.
• 📌 HUD.gd è stato toccato da due lotti nello stesso giro (SU-534/530/524 da una parte, la classifica di fine partita e la seconda metà del voltapagina dall'altra): il file è di uno solo per costruzione, ma la classifica vive lì e in nessun altro posto. Le zone non si sovrappongono; il diff è misto ed è stato riletto prima del commit.

L'arcobaleno smette di passare, la banca brilla, e la carta da tre livelli si fa vedere2026-08-22

• [fix] SU-490 (KO) — l'arcobaleno finiva sul marciapiede, e la coda accorciata da sola non bastava: erano DUE difetti. Ivan: «oltre a passare dietro deve terminare circa a metà dello sprite della metropolitana, altrimenti ora termina sotto lo sprite fuori dal disegno».
  • Primo: il capo della spezzata cadeva sull'origine del nodo, che è il punto d'uso, 8 px sotto il disegno. Misurato sul seme 20260465: disegno da y 106,5 a 181,5, capo a 189,5 — il 111% dell'altezza, cioè fuori, sul marciapiede. Adesso _capo_arco_locale() porta il capo a metà altezza del disegno (50%, y=144), che è quel che chiedeva il KO.
  • ⚠️ Secondo, e senza il primo non si vedeva: la banca cade quasi a piombo sotto la fermata (6,7 px su 574), e in quella condizione le due maniglie della Bézier andavano una a destra e una a sinistra, facendo un cappio: la gamba di salita passava sotto la pensilina e proseguiva fuori schermo. Guardando la fermata non si vedeva un arcobaleno che *arriva*, se ne vedeva uno che *passa*. Bastava -segno invece di +segno su c2 — maniglie dalla stessa parte, curva a «(» che non si incrocia. Le fette sono tornate tre, erano diventate cinque proprio per inseguire i due tratti del cappio.
  • Con apertura zero le due formule danno lo stesso punto: il caso normale non cambia di un pixel. ⚠️ Dove la forma cambia davvero è il bidone d'oro con i capi quasi in verticale (43% delle posizioni possibili): in gioco non è più raggiungibile — dopo SU-466 la banca non fa più comparire bidoni d'oro, resta solo il DebugPanel — e dove cambia è per togliere lo stesso cappio.
• [feat] SU-485 (KO) — d'oro anche la fermata vera, non solo quella sulla mappa. Ivan: «va bene la fermata sulla mappa ma anche quella in gioco deve diventare d'oro!». La pensilina prende un velo: un secondo Sprite2D con la stessa texture ridipinta verdi→oro, con le stesse costanti già approvate in MapOverlay._metro_icon_oro() — non un secondo criterio che le somiglia. Niente shader (il compile-check non li valida e uno rotto sembra giusto), nessun asset nuovo. Lo monta e lo smonta la stessa funzione che accende e spegne l'arcobaleno, quindi le due cose non possono divergere. Sulla mappa: nessuna riga toccata.
• [feat] SU-535 — la banca brilla quando è piena, e un suono annuncia l'arcobaleno. Nuovo BankGlitter.gd: venti scintille disegnate con _draw — niente particelle, niente shader — solo sui pixel opachi della facciata, in blocchi da 2 px squadrati sulla griglia del mondo. Sono figlie dello sprite della banca, quindi prendono lo z del mondo e non possono coprire il contatore, che sta a 3990 (era il terzo criterio del ticket). Nascono e muoiono insieme al bagliore dorato di SU-494.
  • Il suono è reward_chime.wav, che in questo sistema è già il suono del premio, e parte solo sul fronte di salita di bank_is_full(): misurato 1 suono su 12 pressioni. Senza il fronte, ogni deposito successivo al colmo lo avrebbe rifatto partire.
  • Tarato guardando: al primo giro le scintille erano 16 e se ne leggevano 2. Alzata la curva di luce, allo scatto ne risultano 14 accese su 20.
• [fix] SU-528 — la carta che nasce al livello 3 adesso si VEDE, e la muschetta arriva quando deve. Ivan, in chat: «ero convinto ne uscissero 3, però possiamo farne apparire tre sorteggiate (la stessa power up) e solo quando parte la terza fare partire la muschetta».
  • Prima l'esito card_lvl3 apriva una cerimonia sola con livelli = 3: il livello arrivava a 3, ma il «tre» il giocatore non lo vedeva mai. Adesso accoda tre cerimonie da un livello ciascuna, sulla stessa carta, riusando la coda che double_level usava già. Il livello finale resta 3, misurato — non 3+3+3.
  • ⚠️ La causa vera del ticket era un'altra, e stava dove nessuno la cercava: BonusRewards._suona_premio_grosso() faceva partire la muschetta subito alla consegna del premio, e la faceva partire per double_level e per card_lvl3 insieme. È sparita da lì: adesso levelup_triple.wav suona nel primo frame della terza cerimonia, e su double_level non suona più affatto — che è quello che Ivan ha chiesto per nome.
  • Misurato sulla run vera, carta pelle_cuoio: passo 1 «liv. 0→1» muto, passo 2 «liv. 1→2» col solo card_pick.wav, passo 3 «liv. 2→3» a +7,304 s con levelup_triple.wav letto allo stesso frame dell'apertura. Controprove su level_up e double_level: muschetta mai sentita.
  • La musica del tunnel non è stata toccata: zero righe in BonusLevel.gd.

Il tunnel non ti rispiega tutto ogni volta, e l'ombrello smette di essere un numero solo2026-08-22

• [fix] SU-492 (KO) — dalla seconda discesa nella stessa partita l'intro del bonus salta la spiegazione e corre. Ivan: «se lo rigiochi nella stessa partita solo il 3 2 1 senza spiegazione, più veloce».
  • Il contatore sta su GameState, non su BonusLevel, e non è pignoleria: il livello bonus è una scena che muore e rinasce a ogni giro, quindi un contatore lì dentro ripartirebbe da zero proprio nel caso che il ticket vuole distinguere. Si azzera in start_run() e in nessun altro posto: reset_run_state() precede sempre un ricaricamento di scena che poi richiama start_run() da World._ready(), quindi un solo punto di reset copre menu, RICOMINCIA e rematch.
  • «Niente spiegazione» vuol dire che non compare affatto, non che compare e sfuma subito: alla seconda discesa la label resta visible = false. Alla prima, la vecchia dissolvenza incrociata con il conto resta identica — restano leggibili tutte e due per mezzo secondo, che è quanto serve a collegarle.
  • I numeri, misurati sul _process() vero un frame alla volta (non a delta fisso, che avrebbe confermato solo la formula). Prima discesa: VIA a 5,03 s, controllo al giocatore a 5,58 s — identica alla linea di base del giro precedente, cioè non è regredita. Seconda discesa nella stessa partita: spiegazione mai visibile, VIA a 1,35 s, controllo a 1,71 s. Sono 3,86 secondi in meno, e la sequenza resta sempre 3, 2, 1, VIA! senza cifre doppie o saltate.
  • Le due durate «veloce» (cifra 0,45 s, VIA 0,35 s) sono costanti nominate accanto a quelle intere: cambiarle è una riga. Sonda nuova probe_su492_replay.gd, perché due discese nella stessa run non si misurano altrimenti.
• [change] SU-525 — OMBRELLO RITROVATO non è più un moltiplicatore unico: sono quattro effetti, uno per voce. Ivan li ha definiti a voce il 2026-08-22, e quella definizione sostituisce il vecchio weather_penalty_mult() da 0.5 su tutto.
  • GRANDINE: stesso danno per colpo, metà dei colpi — l'intervallo fra due passa da 2,0 a 4,0 s esatti. PIOGGIA: stessa entità del rallentamento, metà durata — 60,0 → 30,0 s. CALDO: colpo di sole 18,0 → 9,0 s. Le stat non calano più per causa meteo: fame, energia e igiene misurate prima e dopo un'ondata danno Δ 0,000 con la carta, contro −25,000 ciascuna senza.
  • ⚠️ Una correzione che il ticket non chiedeva ma che serviva: wet_ratio() divideva per la costante WET_DURATION. Con la durata dimezzata, la barretta del «fradicio» sopra la testa sarebbe nata già a metà. Adesso c'è _wet_duration_active, cioè la durata davvero usata per quel fradicio lì.
  • 📌 Dove sta il gate, e perché è facile spostarlo. «Il meteo non toglie mai stat» è scritto sul ticket come effetto della carta, e così è implementato: blocks_weather_stat_drain(), gate su has("ombrello"). Se Ivan intendeva «mai, per nessuno, anche senza carta», cambia solo dove sta il gate — le altre tre voci non si toccano.
  • Il vecchio weather_penalty_mult() è sparito, non lasciato accanto: grep conferma zero residui. Sonda probe_su525_ombrello.gd, deterministica, 8 criteri su 8.

Test e produzione: si separano i dati, non le persone2026-08-22

• [doc] SU-526 (DESIGN) — deciso come si separano ambiente di test e ambiente di produzione per i servizi online. Nessuna riga di codice: la consegna è la decisione scritta, in OPUS_BRIEFS/SU-526_ambienti_online.md.
  • La scelta: SSO e anagrafica utenti restano unici (un solo Product EOS, stessi Identity Provider, stesso bundle id, stesse app su Play e TestFlight). Si separano i soli dati di gioco, con due Sandbox/Deployment dello stesso Product — classifiche, stat e lobby si dividono da sole perché in EOS vivono sul deployment; registro nickname e telemetria si dividono con un campo env verso gli stessi Apps Script.
  • Il verso che rende tutto gratis: la produzione nasce nuova e vuota, e l'ambiente di oggi viene promosso a test. Così non c'è niente da migrare, e il vincolo peggiore di EOS — *i punteggi seguono il NOME della stat, cancellare e ricreare non svuota niente* — non morde affatto: la sandbox nuova nasce vuota con gli stessi nomi, e BOARD_PREFIX non cambia. Farlo dopo il lancio vorrebbe dire buttare le classifiche pubbliche o svuotarle un PUID alla volta.
  • Sei alternative scartate col motivo scritto, perché senza il motivo tornano. La più cara era «due Product EOS distinti»: un Product nuovo ha un client_id nuovo, e il redirect Epic è eos.<client_id>://epic/auth inchiodato in un CFBundleURLSchemes statico dentro export_presets.cfg — la login Epic su iOS morirebbe senza messaggio d'errore. E «solo prefissi nei nomi delle stat» non è teorica: è quello che si fa oggi, ed è già fallita con BOARD_PROVA_CENTRO dimenticata piena per un intero sprint (SU-503).
  • L'ambiente si sceglie da un solo dato: la chiave env di eos_credentials.cfg, lo stesso file che contiene già sandbox_id e deployment_id — cioè ciò che l'ambiente *è*. Scartati i preset di export (raddoppierebbero sei preset in un file da 1100 righe, e duplicherebbero l'informazione: il feature tag direbbe una cosa e la sandbox un'altra) e l'interruttore nel menu. Con due guardie: coerenza env→deployment_id con degrado a offline invece di scrivere nel posto sbagliato, e ambiente visibile quando non è live.
  • I tester non si accorgono di niente: non perdono i progressi (stanno in user://), non reinstallano, non rifanno il login, e le loro classifiche non ripartono — la build che hanno in mano continua a puntare al deployment di oggi, che diventa dev.
  • ⚠️ Sei buchi dichiarati, da chiudere nel portale EOS prima di implementare. Il più pesante: se il PUID sia per Product o per Sandbox. Se fosse per Sandbox, chi passa a produzione riparte con identità nuova e il registro PUID→nome va a chiave composta. Non cambia la decisione, cambia il piano di transizione.
  • Rilevato leggendo il codice, non ipotizzato: le notifiche push non esistono ancora (nessun FCM/Firebase in scripts/), e su EOS non c'è dato persistente oltre stat e leaderboard.

Le carte si aprivano mute, e il tier non deve salire se muori2026-08-22

• [fix] SU-491 — la cerimonia delle carte era MUTA nel tunnel, e il difetto sembrava capriccioso perché lo è. Ivan: «non si sente la musica delle carte che scorrono nel bonus stage, e immagino anche gli altri suoni associati».
  • La causa sta in QUANDO nasce la schermata. LevelUpScreen è figlia dell'HUD e l'HUD la istanzia alla prima carta della run (HUD.gd, load + add_child pigri). Se il giocatore una carta l'ha già presa in città, quando il tunnel congela la superficie il lettore della schermata è già lì e finisce zittito insieme a tutto il resto: il ventaglio si apre senza un suono. Chi invece prende la sua prima carta proprio quaggiù la sente, perché il lettore nasce dopo il congelamento. Da qui l'aria da difetto intermittente.
  • Il rimedio sta accanto a quello che c'era già: _riaccendi_carte() riaccendeva la FACCIA della cerimonia (il congelamento le aveva spento il CanvasLayer) e adesso le ridà anche la VOCE, riaprendo i lettori di tutto il suo ramo. E _tieni_muta_la_citta() — che gira a ogni fotogramma mentre il ventaglio è aperto — la salta: senza l'eccezione, la cerimonia tornerebbe muta un fotogramma dopo.
  • Verificato con un controllo in negativo, perché il criterio da solo non direbbe niente: la sonda si costruisce la condizione (un lettore «della cerimonia» e uno qualunque, tutti e due zittiti e tutti e due nella lista del congelamento) e guarda che il rimedio ne riaccenda uno solo. ⚠️ E i due lettori finti devono avere uno stream e stare suonando: su un lettore fermo Godot non memorizza lo stato di pausa — c'è pure il TODO nel motore, «If the stream is not playing, the pause state is not stored» — e il controllo in negativo falliva su un rimedio sanissimo.
  • 📌 Da dire, perché la parola «musica» qui inganna: la cerimonia non ha una musica sua. Ha dei JINGLE (_sfx, un lettore solo: level-up, pesca della carta, premio grosso) e per il resto tiene viva la musica del livello — che quaggiù è quella del tunnel. Quel che tornava muto sono i jingle.
• [change] SU-491 — il tier del bonus sale solo se raggiungi la banchina. Ivan: «se muoio nel bonus stage perché investito dal treno o per tempo scaduto, rimane ancora quel tier di bonus stage, la banca ti chiede ancora quei soldi e se raggiungi di nuovo il versamento in banca potrai rigiocare lo stesso tier (ricompense, futura difficoltà), se invece raggiungo la banchina sale i tier (prezzo da pagare alla banca, ricompensa)».
  • È bastata spostare una riga, perché il tier È la soglia. Interactable._giro_premio_banca() non conta niente: RICAVA il giro da bank_gold_threshold (100 = primo, 200 = secondo, 400 = terzo), e da quel numero dipendono sia il prezzo del biglietto sia il valore delle monete della banchina (BonusRewards.valore_moneta(), che raddoppia insieme). Quindi «il tier sale» e «la soglia raddoppia» sono la stessa frase, e il raddoppio è uscito da bank_take_gold_debt() — che scattava al momento di scendere — per entrare in bank_bonus_superato(), che si chiama solo con la banchina raggiunta.
  • Prima chi si faceva prendere dal primo treno si ritrovava il biglietto a $200 senza aver visto la banchina: pagava di più per aver fatto peggio. Adesso rigioca lo stesso tier allo stesso prezzo.
  • ⚠️ IL FRENO ANTI-FARMING DI SU-466 REGGE, ed è anzi più stretto: era «raddoppia a ogni premio riscosso», adesso è «a ogni premio VINTO». Chi muore rigioca allo stesso prezzo ma torna su a mani vuote, quindi il ciclo banca→tunnel non stampa soldi.
  • ⚠️ E UNA TRAPPOLA DI ORDINE, trovata dalla sonda end-to-end e non dal ragionamento. Al primo tentativo il raddoppio scattava alla fine del livello bonus, cioè PRIMA che la banca si accorgesse che l'arcobaleno era stato usato: conto $100, soglia già $200, il controllo «conto ≥ soglia» tornava false e il debito non veniva più scalato affatto — il giocatore si teneva i suoi $100 sul conto per sempre. Il prezzo è quello che si è accettato scendendo: adesso bank_take_gold_debt() scala il vecchio e SOLO DOPO raddoppia, se il flag dice che si è vinto.
• Verificato: probe_su491_metro.sh da 20 a 24 criteri, 0 KO. I nuovi: la cerimonia torna in voce e la città no (col controllo in negativo); vincendo, prezzo vecchio pagato, conto a $0 e soglia $100 → $200; perdendo, prezzo pagato lo stesso ma soglia ferma a $200. ⚠️ Il criterio del tier misura la sequenza vera (fine livello → bank_take_gold_debt()), non il solo raddoppio: guardare la soglia subito dopo il livello non direbbe niente — lì è ancora quella di prima, ed è giusto così — ed è misurando solo quella che al primo tentativo mi era sfuggito il conto mai scalato. probe_su491.sh, probe_su491_pausa.sh e probe_collaudo_bancametro.sh tutte verdi.

La pausa prende il menu vero dall'HUD, e alla fine si sale sulla metro2026-08-22

• [fix] SU-491 — la pausa del tunnel adesso è LA STESSA di sopra, non una che le somiglia. Ivan: «la pausa deve avere lo stesso layout della pausa nel livello standard». Il primo giro aveva rifatto pannello e pulsanti a mano, e si vedeva: altro corpo, altra spaziatura, altro giallo sulla voce scelta.
  • Adesso il menu è un'ISTANZA di HUD._MenuList, la classe interna che disegna e naviga le voci lassù: stessi pulsanti, stessa variazione di tema (CardboardButton), stessa altezza di riga (340×46), stessi due colori, stesso move()/activate(). Il pannello copia riga per riga HUD._setup_pause_panel() — velo nero al 55%, titolo a corpo 42 con contorno 6, hint a corpo 16 — e l'impaginazione verticale è la gemella di _layout_pause_menu(), con i due numeri (PAUSE_MENU_HISTORIC_CENTER_Y, PAUSE_MENU_EDGE_MARGIN) letti dalle costanti dell'HUD, non ricopiati: se lassù si sposta il centro, qui si sposta insieme.
  • ⚠️ Trappola del linguaggio, costata un giro di compilazione: preload() di uno script senza class_name il parser lo tratta come CLASSE, e get_script_constant_map() su una classe è un errore («Cannot call non-static function… Make an instance instead»). Serve un load() a runtime in una variabile, dove la stessa cosa è una risorsa Script e si interroga.
• [fix] Niente pausa prima del «VIA!». Ivan: «pausa la posso premere solo dopo il 3 2 1, prima no». Durante l'intro il giocatore non ha ancora il comando — _avanza_intro() gli tiene ferme le gambe — e mettere in pausa una spiegazione che scorre da sola vuol dire congelarla a metà parola. Vale anche per il pulsante del tocco, che nasce spento e compare col VIA: un pulsante che c'è ma non fa niente è peggio di uno che non c'è.
• [fix] Un difetto MIO di stamattina: il lettore della musica del tunnel restava appeso alla radice. Uscendo dal menu con RICOMINCIA o ESCI facevo _musica.stop(). Ma quel lettore vive sulla RADICE (vedi avvia_musica), quindi non muore né col livello né col cambio scena: fermarlo e basta lo lasciava lì col nome buono, e al giro dopo avvia_musica() lo ritrovava, non ne creava un altro e adottava un lettore spento — tunnel muto per sempre. Adesso si passa da _spegni_musica_bonus(), che lo rinomina, lo sfuma sul lettore (non sul livello, che muore prima) e lo libera, con un timer dell'albero come rete.
• ⚠️ [NON RIPRODOTTO] «Riprendendo riparte anche la musica del livello sopra». Ivan l'ha sentito, io non sono riuscito a farlo succedere, e lo scrivo perché il rischio è che qualcuno legga il punto qui sopra e lo creda risolto.
  • L'ipotesi che sembrava ovvia è FALSA, e ho la controprova. Godot, quando l'albero esce dalla pausa, manda NOTIFICATION_UNPAUSED a ogni AudioStreamPlayer e lì dentro chiama set_stream_paused(false): sembrava la spiegazione perfetta. Ma Node::_propagate_pause_notification() la manda solo a chi cambia stato di processo, e i lettori della città stanno sotto World, che quaggiù è in PROCESS_MODE_DISABLED: prima e dopo non possono processare, quindi non ricevono niente. La sonda l'ha verificato spausando l'albero a mano — la musica non torna.
  • E il rimedio che avevo scritto non serve a questo: disattivandolo, la sonda passa identica. Resta comunque (allargato da «il solo lettore Music» a «tutti i lettori che il congelamento ha in lista») perché sulla strada della cerimonia delle carte quel bisogno era reale e misurato — ma non è ciò che risolve quello che Ivan ha sentito.
  • Cosa ho escluso, misurandolo: nessuno tocca stream_paused fuori da BonusLevel; metro_ride non tocca la musica; _costruisci_musica() adotta il lettore già acceso invece di crearne un secondo; con la musica della città ACCESA prima di scendere (la sonda ora la accende apposta: il primo giro la misurava spenta ed era verde e cieca), dopo pausa e riprendi suona un lettore solo, quello del tunnel, e zero lettori si risvegliano.
• [feat] E alla fine si prende la metro. Ivan: «nel finale del livello pensavo anche che il barbone si muove verso la porta più vicina della metro, ci sale (sparisce) e la metro riparte solo lì». Fatto: allo scadere dei 30 secondi il barbone si sfila dal comando del giocatore, corre alla porta più vicina (140 px/s: sta prendendo l'ultima corsa), sale e sfuma dentro nell'arco di 0,45 s.
  • Due gambe, come per i passeggeri che scendono e per la stessa ragione: la porta sta SUL TRENO, oltre la riga gialla, e in diagonale non ci si arriva. Prima si cammina sul filo della banchina fino sotto la porta, poi si sale — ed è nella salita che la sagoma sfuma, perché entrare in una carrozza disegnata di fianco non si può mostrare altrimenti. ⚠️ La posa della salita è walk_n e non idle_s: sta andando VERSO il treno, che a schermo è verso l'alto; con la posa di fine livello (che guarda in basso) sembrerebbe che stesse scendendo dalla banchina.
  • ⚠️ E la metro adesso lo ASPETTA. Prima ripartiva insieme al conto, e andava bene finché il barbone restava sulla banchina a guardarla andare via; con lui che ci sale, un treno che parte mentre è ancora sui gradini è la cosa più sbagliata che si possa vedere. Anche l'orologio dell'outro è fermo finché non è dentro: se scorresse, il pannello del conto si aprirebbe sopra la scena che è stata chiesta.
• Verificato: probe_su491_pausa.sh da 10 a 16 criteri, 0 KO (fra i nuovi: nessuna pausa in fase INTRO; il menu è davvero un'istanza di HUD._MenuList, controllata sullo script del nodo e non a occhio; il velo è nero al 55%; nessun lettore audio si risveglia col riprendi; nessun MusicaBonus lasciato vivo sulla radice). probe_su491_metro.sh da 19 a 20 criteri, 0 KO: il criterio «barbone fermo» è stato sostituito — non è più vero, adesso si muove — da «sale sulla metro» (sparisce a 2 px dalla porta scelta, col joypad tenuto premuto a destra per tutto il tratto) e «il treno lo aspetta» (non si muove di un pixel prima). probe_su491.sh e probe_collaudo_bancametro.sh restano ESITO OK. Scatti su491m_4d_pausa e su491m_6a_imbarco, guardati.

ESC nel tunnel finiva il livello invece di metterlo in pausa2026-08-22

• [fix] SU-491 — il tasto della pausa chiudeva il livello bonus, e da lì non si usciva più. Ivan: «un bug grosso, se premo esc (la pausa) il barbone si ferma come se fosse finito il livello, vedo il numero delle monete ma nessun menu con ricomincia torna al menu appare, inoltre da lì non riesco più ad uscire, deve essere sistemato con una gestione come per la pausa del livello principale».
  • La causa in una riga: _leggi_input() faceva _termina(false) su ui_cancel. Era stato scritto come «abbandono volontario, si risale a mani vuote», e come valvola di sicurezza visto che il menu di pausa dell'HUD quaggiù è congelato. Ma ESC È il tasto della pausa — Settings.gd lo mappa su pause, e Godot ci mette sopra anche ui_cancel — quindi chi lo premeva per mettere in pausa si ritrovava il livello finito, il conto delle monete a schermo e nessun menu.
  • ⚠️ E il menu dell'HUD non poteva comparire: è un difetto di albero, non di logica. L'HUD è figlio di World, e _congela_superficie() mette World in PROCESS_MODE_DISABLED nascondendone tutti i CanvasLayer. Un nodo disabilitato non riceve _unhandled_input, quindi l'HUD non vedeva nemmeno passare il tasto — e se anche l'avesse visto, il suo pannello era invisibile. Riaccenderlo a metà avrebbe voluto dire far girare i suoi orologi e i suoi banner contro una città ferma.
  • La pausa del tunnel adesso c'è, con le stesse tre voci di sopra: RIPRENDI, RICOMINCIA, ESCI AL MENU PRINCIPALE. ⚠️ Ma le due azioni che contano NON sono riscritte: si chiamano HUD._do_restart_or_rematch() e HUD._on_exit_to_menu_pressed(), che sanno già sfumare la musica, azzerare GameState, spegnere il meteo e cambiare scena. Duplicarle avrebbe voluto dire due catene da tenere allineate per sempre, e a divergere per prime sarebbero state le righe che nessuno vede — tipo il reset del tutorial. ⚠️ E si risale PRIMA di chiamarle: quelle due funzioni fanno await su una dissolvenza della musica, e un HUD ancora congelato non porterebbe a termine l'attesa. _risali_ora() rimette in piedi la città e libera il tunnel; solo allora l'HUD è un nodo vivo come un altro. Zero chiavi di traduzione nuove: HUD_PAUSA_TITOLO, HUD_MENU_RIPRENDI, HUD_MENU_RICOMINCIA, HUD_MENU_ESCI esistono già in otto lingue.
  • Il livello si mette in PROCESS_MODE_ALWAYS mentre la pausa è aperta e l'input del menu si legge da _process, non da _unhandled_input: con l'albero fermo gli eventi non arrivano ai callback dei nodi pausabili, e questo livello è l'unica cosa che sta girando. È lo stesso trucco già usato per la cerimonia delle carte, e infatti la pausa non si apre mentre la cerimonia è aperta: comanda lei, e sovrapporsi lascerebbe uno dei due senza motore.
  • [feat] E su telefono, il pulsante di pausa. Senza, nel tunnel non si poteva mettere in pausa affatto: ESC non esiste e quello dell'HUD è congelato con la città. Compare con la stessa regola del suo gemello di sopra — solo con i comandi virtuali attivi — e sta in alto a sinistra, perché a destra c'è l'orologio.
  • Verificato: sonda nuova probe_su491_pausa.gd (+ tools/autotest/probe_su491_pausa.sh), 10 criteri, 0 KO. ⚠️ Preme il tasto DAVVERO (Input.action_press("pause")) invece di chiamare _apri_pausa(): chiamare la funzione a mano avrebbe saltato proprio il pezzo rotto, cioè _leggi_input(). Misurato: dopo ESC il livello non è finito (fase 1, non 3), il pannello è visibile, l'albero è in pausa, le voci sono le tre giuste; un secondo ESC riprende e il livello è ancora vivo; scegliendo «esci» il tunnel si smonta, la città torna visibile, bonus_level_active scende e l'albero non resta in pausa. Scatto su491m_4d_pausa, guardato. Le tre sonde di regressione restano verdi (19/0, ESITO OK, ESITO OK).
  • 📌 Cosa NON c'è, dichiarato: la voce OPZIONI (che il menu di sopra ha) e il vecchio «abbandona il tunnel». Le opzioni in-game sono un componente con la sua navigazione a due livelli — costruirlo anche qui era più superficie di quanta ne chiedesse il bug; l'abbandono non è più raggiungibile da ESC, e nessuno l'ha chiesto indietro.

I treni non andavano «spesso» in alto: ci andavano tutti dal 43% in poi2026-08-22

• [fix] SU-491 (6° giro) — la guardia che teneva i treni sul binario alto guardava DOVE NASCE il treno invece di QUANDO, e da metà corridoio in poi li spostava tutti. Ivan: «i treni ho notato che spesso passano tanti uno dietro l'altro sopra, non va bene perché diventa troppo facile il livello, se sono random massimo due treni consecutivi nella stessa corsia, non di più, e ultimo treno a prescindere sempre nella corsia sopra per non farlo passare sulla banchina».
  • ⚠️ IL TETTO DEI DUE CONSECUTIVI C'ERA GIÀ, e funzionava: _scegli_corsia() lo applica da SU-467, e la sonda lo conferma sulla sequenza vera — la serie più lunga è 2, su 14 treni, in tutti e due i giri misurati. Il difetto stava una funzione più in là. La guardia in _lancia_treno(), aggiunta stamattina per un'altra richiesta di Ivan («l'ultimo treno deve essere sempre nel binario alto»), diceva if corsia == 1 and x_muso + TRENO_LARGHEZZA > _x_traguardo. Ma il treno nasce a runner.x + 1.820 (252 px di anticipo del barbone più 1.568 di corsa nei 2,8 s di preavviso) e la banchina comincia a 4.050: quella condizione è vera già da runner.x > 1.726, cioè dal 43% del corridoio. Da lì in poi *ogni* treno basso veniva spostato in alto, scavalcando il tetto dei due consecutivi. Ivan ha visto esattamente questo.
  • La condizione giusta è sul progresso (PROGRESSO_SOLO_SOPRA = 0.86), e il numero viene da un conto, non dal gusto: un treno basso lanciato al 90% ha il muso che rientra nel corridoio 2,0 s dopo, quando il barbone — che al massimo corre a 90 px/s — è ancora a 223 px dal traguardo, e la camera ne vede 205 per parte. Il bordo della banchina non è ancora a schermo, quindi il pezzo di treno che ci passa sopra non lo vede nessuno. Con 0,86 il margine è più del doppio, e fra 0,86 e PROGRESSO_STOP_TRENI (0,91) ci sta poco più di un treno: la deroga al tetto dei due è di uno, non di una raffica. Misurato dopo: 57% e 64% di treni in alto, contro il quasi-tutto di prima.
  • Treni più veloci e più fitti: 560 → 700 px/s e intervalli 4,6→2,6 diventati 3,9→2,3. ⚠️ La finestra di reazione non si tocca ed è la terza volta che lo si scrive: il treno nasce alla distanza da cui arriva fra PREAVVISO_TOT secondi, quindi la velocità non la intacca — misurata 1,62 s e 1,57 s, sopra l'1,50 dichiarato in SU-467. Il vincolo intervallo > transito migliora invece di peggiorare: il transito scende a 0,72 s, quindi 2,3 lascia un rapporto di 3,19× dove 2,6 col treno da 560 ne lasciava 1,88×. Risultato: 14 treni per giro invece di 11, attraversamento da 46 a 49,2 s e margine sul tempo limite da 14 a 10,8 s (minimo dichiarato 6,0).
  • Le lattine cambiano posto e numero: da 36-48 sparse dal 2% al 97% a 14-20 nell'ultimo 14% del corridoio, tutte sul binario basso. Il criterio ereditato da SU-249 («chi si fa prendere dal primo treno deve aver già raccattato qualcosa») decade: adesso chi si fa prendere a metà esce a mani vuote, e le lattine sono un premio da raggiungere invece di un pavimento da spazzolare. ⚠️ Restano sparse a caso in verticale — la richiesta del 21/8 vale ancora — ma dentro una corsia sola. 📌 Conseguenza sulla meta-progressione, dichiarata e non «rimediata»: gli oracoli della sonda ne portano a casa 1 e 7 contro le 16 e 14 di prima. Chi vuole le lattine adesso deve andarsele a prendere sul binario basso nell'ultimo tratto — che è proprio il tratto dove i treni non scendono più.
  • Si parte in mezzo ai due binari (LINEA_MEDIANA invece di CENTRO_BASSA): «inizio livello, barbone in centro ai binari sulla sinistra del livello». ⚠️ La mediana è terra di nessuno — lo dice _corsia_runner() in testa, «non esiste una via di mezzo sicura» — quindi si parte dovendo scegliere un binario appena il primo treno si annuncia, invece di trovarsi già sistemati. I 4 s di tratto tranquillo più i 2,8 di preavviso bastano.
  • ⚠️ E questo ha stanato un difetto in una sonda, non nel gioco: probe_collaudo_bancametro.gd schivava ragionando per etichetta di corsia (qui = 0 se y < mediana), quindi partendo sulla mediana si credeva «in basso» e non schivava i treni di sopra — moriva al primo treno, al 15% del corridoio, su un livello che gli altri due oracoli attraversano in 49 s. La collisione del gioco guarda la sagoma, non il numero: adesso lo sa anche lui, e chi sta a cavallo cerca sempre una corsia libera in cui infilarsi.
  • Verificato: probe_su491.sh ESITO OK con sei criteri nuovi (lattine tutte nell'ultimo tratto, lattine tutte sul binario basso, mai più di due di fila sulla stessa corsia, ultimo treno in alto, corsie bilanciate, partenza sulla mediana); probe_su491_metro.sh 19/0; probe_collaudo_bancametro.sh ESITO OK. Scatti nuovi su491m_0_partenza e su491m_0b_lattine, guardati.

La profondità la fa la y, e i soldi tornano a cadere per terra2026-08-22

• [change] SU-491 (5° giro) — quattro cose viste giocando: la profondità fra le persone, le monete che cadono, la posa da fermo e la banchina che si svuota. Ivan: «gli npc ed il barbone devono avere tra di loro il giusto ordine di presentazione come nel mondo reale, se uno è dietro è dietro e così via, stessa cosa per lo spostamento degli npc, i soldi devono cadere a terra esattamente come nel livello standard, inoltre c'è un bug che il barbone quando premo A su un npc guarda verso il basso, deve farlo solo a fine livello, non durante l'elemosina. A fine livello inoltre gli npc si direzionano tutti verso fine della banchina a destra, uscendo dalla schermata (se non sforano i limiti della banchina sennò spariscono al limite)».
  • Le persone non hanno più un numero fisso: hanno int(position.y), riscritto a ogni passo. Con passeggeri a 7 e barbone a 8 il barbone stava davanti SEMPRE, anche a chi gli era davanti di mezzo metro. ⚠️ E la regola non è nuova: è quella della città. Interactable.gd la dichiara in testa — «Il mondo non usa y_sort: ordina a mano con z_index = int(pos.y)» — e quaggiù vale identica; inventarne una seconda avrebbe voluto dire due ordinamenti da tenere allineati per sempre. Ordinano per y anche le monete cadute, sul punto A TERRA e non sul disegno: durante il saltello la moneta è per aria ma sta appoggiata lì.
  • Conseguenza da dichiarare: treni e FX sono saliti in alto. Le persone adesso stanno fra 105 e 250, quindi i treni del corridoio sono passati da 6 a 300 (devono restare sopra chiunque: un treno che passa dietro al barbone che sta investendo non si guarda), le scintille dei carrelli da 1-2 a 297-298, e la roba che salta sopra la testa da 10 a 400. Metro (4) e fronte della banchina (5) restano dove erano.
  • I soldi cadono a terra, con i numeri di CoinDrop. Chiedere non accredita più niente: fa uscire le monete dalle tasche una per una, che schizzano di lato, rimbalzano, si posano e ondeggiano — e si raccolgono camminandoci sopra, raggio 17 come in strada. ⚠️ CoinDrop NON si riusa, e non è pigrizia: drop_reward() delega a world.drop_coin_reward(), cioè fa nascere le monete DENTRO LA CITTÀ, che quaggiù è in PROCESS_MODE_DISABLED e visible = false — nascerebbero congelate a metà saltello dentro una scena invisibile. E la sua raccolta passa da Pickup, cioè da un'Area2D che vuole il Player vero, mentre il barbone di sotto è un AnimatedSprite2D mosso a mano senza fisica. Si copiano i numeri (250-400 px/s di lancio, g 1000, rimbalzo 0,45, bob 5/1,3, armo 0,18), che è ciò che si vede.
  • Ed è sparito l'FX sopra la testa, che ora sarebbe un doppione: è la stessa cosa che il gioco di sopra ha già fatto con un KO dell'11/8 — «quando le monete cadono a terra deve sparire la moneta sopra il personaggio di una volta, perché non serve più, ci sono già le monete a terra».
  • Il barbone da fermo tiene l'ultima direzione. Il verso di ripiego di _anima_runner() era "s", quindi ogni volta che si lasciava lo stick si girava a guardare in basso; Ivan l'ha visto chiedendo l'elemosina, che è il momento in cui si sta fermi per forza. Aveva ragione due volte: guardare in basso è la posa di FINE LIVELLO, e usarla anche da fermi la svuotava di significato. Via anche _posa_elemosina(), che metteva la posa beg — che nelle SpriteFrames è frontale, cioè proprio «guarda verso il basso». Il segnale che la richiesta è andata a segno adesso è quello del gioco di sopra: le monete che cadono.
  • A fine livello la banchina sgombera: tutti verso il fondo della stazione a 110 px/s (più del passeggio, 84: l'outro dura 4,8 s e la banchina si deve vedere svuotare, non accennare a svuotarsi), e chi arriva al limite sparisce lì invece di camminare dentro il muro. Chi non era ancora sceso non scende più. ⚠️ La folla va mossa dentro l'outro: da _finito in poi _passo() non chiama più _premi.passo(), e senza la riga nuova la banchina restava congelata in posa mentre il treno se ne andava.
  • Verificato: probe_su491_metro.sh da 15 a 19 criteri, 0 KO. I quattro nuovi: 0 fotogrammi fuori ordine sul controllo z == int(y) e sull'ordine col barbone, misurato a ogni passo dei 30 secondi; una richiesta isolata che porta le monete a terra da 0 a 5 con la cassa ferma a $0 (prima si accreditava subito); posa idle_e → idle_e premendo da fermo dopo aver camminato a destra; e tutti i 40 in stato uscita con la media delle ascisse a +330 px in 3 s. Scatti nuovi su491m_4b_npc_davanti / su491m_4c_npc_dietro, guardati: nello stesso istante l'npc copre il barbone o ne è coperto a seconda di chi sta più avanti (z 201 contro 213, poi 226 contro 213).
  • ⚠️ Due volte ho misurato la cosa sbagliata, e le scrivo perché costano un giro ogni volta. (1) «La banchina sgombera» chiedeva che qualcuno ARRIVASSE al fondo: il fondo sta a oltre 1.200 px e l'outro dura 4,8 s a 110 px/s, quindi era un criterio impossibile su un comportamento sano — la domanda giusta è lo spostamento. (2) L'invariante delle 200 monete sommava «date» e «rimaste», e contava due volte quelle già cadute ma non ancora raccolte (sono uscite da una tasca e sono ancora da prendere): tornava 298 su 200 a livello perfettamente funzionante. Le pile vere sono tre — in tasca, per terra, in cassa — e il conto è raccolte + rimaste.

La banchina si alza e il treno va in profondità2026-08-22

• [change] SU-491 (4° giro) — quattro ritocchi di Ivan sulla scena della metro, e tre erano lo stesso problema: chi sta davanti a chi. «I pedoni non devono scappare fuori dal perimetro orizzontale della metro […] non devono avere il soldino sopra che vedo, devono essere in primo piano rispetto alla metro (un po' come quando raccoglievo i soldini che la moneta in salto finiva dietro per errore), e ultima cosa cerchiamo di alzare la banchina in modo tale che le ruote della metro vengano nascoste da questa, come se il treno fosse un po' in profondità».
  • L'ordine di disegno adesso vive in un posto solo, ed è il pezzo che risolve tre richieste su quattro. Il livello non ha y-sorting: chi sta davanti lo decide solo lo z_index, e prima era sparso fra cinque file. La metro è scesa da 6 a 4, e non è un ritocco cosmetico: a 6 stava davanti alla banchina, quindi la banchina non poteva alzarsi (qualunque cosa le si disegnasse davanti finiva comunque dietro al treno) e i passeggeri non potevano passare in primo piano senza salire sopra il barbone. Spostare la metro INDIETRO risolve tutte e tre con un numero solo. La scala completa: metro 4 · fronte della banchina 5 · treni del corridoio 6 (invariati, passano sopra tutto) · passeggeri 7 · barbone 8 · roba che salta 10.
  • La banchina si alza di 14 px, e il numero esce dalla misura del treno. Lo sprite è alto 109 e sta centrato su CENTRO_ALTA (120): occupa y 65,5-174,5, e i carrelli stanno attorno a y 163-174. Il filo del binario è a 176. Con 14 px di fronte si copre da 162 in giù: spariscono tutte le ruote e non un pixel della riga rossa. ⚠️ Il fronte è una fascia PIENA, non piastrellata, con una riga chiara di spigolo in cima: un ritaglio di subway_wall alto 14 px ripartirebbe da capo col disegno dei mattoni e lascerebbe una cucitura contro il pavimento, che parte da y 176 con la sua fase — e di taglio i mattoni non si vedrebbero comunque. ⚠️ Il piano su cui si cammina NON si è mosso: la riga gialla e il clamp del barbone restano dove erano, si è aggiunto solo il bordo che sporge.
  • La zona di passeggio è il CONVOGLIO, non la banchina: 1.008 px invece di 2.304. Prima si passavano a metro_arrivata() gli estremi della banchina e la gente sfilava anche dove treno non ce n'era — gente scesa da una porta che non c'è. Sparito anche lo stato «se ne va»: chi aveva già dato puntava il fondo della stazione, cioè usciva dal convoglio, che è esattamente quello che Ivan ha bocciato. Adesso chi ha dato si ferma un attimo a tirare fuori gli spiccioli e riprende a passeggiare come gli altri.
  • Via il mirino. Era la monetina che ondeggiava sopra il bersaglio più vicino, messa per un timore ragionevole (capire se si è abbastanza vicini in mezzo a quaranta sagome) e bocciata: «non devono avere il soldino sopra che vedo». Il raggio è 46 px su sprite alti 32, cioè si è vicini quando ci si tocca e si vede. Nel codice resta scritto che se un domani servisse un segnale, non dev'essere un'icona appesa sopra la testa.
  • Verificato: probe_su491_metro.sh passa da 11 a 15 criteri, 0 KO — i quattro nuovi sono ordine di disegno (metro 4 < fronte 5 < passeggeri 7 < barbone 8), ruote nascoste (fondo del treno a y 174,5 dentro il fronte y 162-176), zero icone appese ai passeggeri, e sconfinamento massimo 0,0 px dal perimetro del convoglio, misurato su tutti i 30 secondi. ⚠️ Lo scatto del fiume adesso aspetta il fotogramma giusto invece di un tempo a caso: la discesa dalla porta dura 0,34 s su trenta secondi di livello, quindi «due secondi dopo le porte» dava quasi sempre una banchina di gente già scesa — cioè la figura che NON risponde alla domanda «stanno davanti al treno?». Il provino avanza finché qualcuno non ha i piedi ancora sopra la riga gialla, ed è lì che la sagoma e la fiancata si sovrappongono. probe_su491.sh e probe_collaudo_bancametro.sh (giro intero banca → bonus → risalita) restano ESITO: OK.

Il finale del tunnel: due carrozze, le porte che si aprono, e i soldi si chiedono2026-08-22

• [change] SU-491 (3° giro) — la metro si vede arrivare, apre le porte, e le monete non stanno più per terra: si chiedono. Ivan, guardando il gioco: «a fine del livello bisogna vedere quando arriva la metropolitana e si ferma il treno, una volta fermo dalle porte devono uscire le persone (c'è modo di aprire le porte?) fiume di gente che scende, gente in movimento, devo chiedere l'elemosina io, non ci sono già le monete a terra […] se non basta un treno prevederne due uno dietro l'altro […] il secondo è "specchiato" per avere il muso dal lato opposto (come se fossero due vagoni attaccati dai rispettivi retro)».
  • La metro non si vedeva arrivare, e non era un'impressione: si fermava quattro schermate più in là. METRO_MUSO_OFFSET valeva 900 px dal piede della banchina, mentre la camera segue il barbone a zoom 2,5 su un viewport logico da 1024, cioè vede 205 px per parte. Ingresso, frenata e fermata succedevano tutti fuori campo. ⚠️ Il primo tentativo di rimedio è stato sbagliato e la sonda l'ha bocciato: messo a 150 «così entra dal bordo destro», ha dato 0,53 s di muso in campo. Il motivo è il verso — il convoglio corre VERSO SINISTRA, quindi il muso è il suo punto più a sinistra e tutti i vagoni gli stanno dietro, cioè a destra: fermandolo a +150 del treno restava in inquadratura una lingua da 55 px. Con +20 il convoglio riempie la metà destra dello schermo e l'ultima frenata si consuma in campo.
  • E anche così un secondo scarso era poco, perché il muso può correre al massimo 185 px in campo: da qui la panoramica (CAM_PANORAMICA 130 px), la camera che guarda verso il tunnel da cui la metro arriva e rientra sul barbone quando le porte sono aperte. Misurato: da 1,02 a 1,35 s di convoglio in inquadratura.
  • Le porte si aprono davvero, e senza un pixel di grafica nuova. Le sei porte doppie di una carrozza sono state misurate sul PNG, non stimate: cercando le colonne con un montante scuro CONTINUO alto ≥ 26 px nella fascia y 60-102 (le finestre non ce l'hanno; i soffietti fra le carrozze sì, ma vengono in gruppi larghi — 167-182 e 329-344 — e si riconoscono). Sono uscite sei terne pulite: 54/66/77, 119/130/141, 211/223/234, 277/288/300, 373/384/395, 438/450/461, tutte alte y 66..97. Le ante sono region_rect ritagliati dalla texture stessa, e all'apertura rientrano nei montanti invece di scivolare sopra la fiancata: quel che resta a schermo è il bordo anteriore dell'anta che cammina verso il montante, come una porta a scomparsa vera. Dietro, il vano: due tinte e non una — con un rettangolo solo si legge come un buco ritagliato nello sprite, la fascia più chiara in basso è il pavimento della carrozza e basta lei a farlo diventare una stanza.
  • Due carrozze, e la seconda è un CONTENITORE specchiato (scale.x = -1), non un flip_h. Non è preferenza di stile: flip_h è un flag letto al momento del disegno, e per le sole ante avrebbe richiesto quattro casi diversi di ritaglio (l'anta sinistra di una carrozza specchiata rientra verso destra e mostra le colonne opposte della texture) — quattro occasioni di sbagliare di un pixel su una porta larga 24. Con lo scale negativo lo specchio è una trasformazione dell'albero: dentro il contenitore tutto si scrive in coordinate della texture e la matematica dell'apertura resta una sola. Risultato: convoglio da 1.008 px con i musi ai due capi e i retri che si toccano, e 12 porte invece di 6.
  • Le monete non cadono più per terra: stanno in tasca alla gente ed escono solo se le chiedi. Il verbo è lo stesso del gioco di sopra — interact, che in Player.gd fa _try_beg() e su mobile è il tasto «A» dei VirtualControls (che quaggiù non sono congelati: l'autoload non è in AUTOLOAD_DA_CONGELARE, ed è la ragione per cui lo stick funzionava già). Ricopiarlo invece di inventarne uno nuovo vuol dire che chi ha imparato a chiedere in strada non deve imparare niente sotto terra. Sono sparite _lascia_cadere(), _semina_resto() e _raccogli_monete(): non c'è più niente da seminare. ⚠️ Una richiesta serve TUTTI quelli nel raggio (46 px, i 48 di Player.gd meno due) e non il più vicino: con quaranta persone in movimento e trenta secondi, servirne una per pressione voleva dire quaranta pressioni in mezzo minuto — non un livello arcade, un test di velocità di dito. Servendo il capannello, la bravura torna a essere dove ti metti. Sopra il bersaglio più vicino ondeggia una monetina, se no in mezzo a quaranta sagome la pressione è alla cieca.
  • Il fiume: da 20 persone che uscivano tutte nello stesso fotogramma da punti a caso della fiancata, a 40 che escono dalle porte una ogni 0,16 s per sei secondi e mezzo. Le porte si riempiono a giro e non a caso: con dodici porte e quaranta persone, tirare il dado per ognuno lascia due o tre porte da cui non esce nessuno, e una porta aperta da cui non scende nessuno si legge come una porta rotta. E non si fermano più su una meta — prima ognuno raggiungeva il suo posto e ci restava piantato, dopo dieci secondi la banchina era un museo delle statue. 40 × 5 monete = le 200 del ticket, invariante.
  • I treni ripartono mentre cadono i soldi (METRO_RIPARTENZA_ACC 200 px/s²): in 4,8 s di outro+conto il convoglio copre ~1.900 px, più della sua lunghezza più mezza schermata. Le porte si richiudono insieme alla partenza e non prima: una metro che parte a porte spalancate è la cosa che si nota di più, e aspettare la chiusura avrebbe mangiato mezzo secondo dei quattro e otto disponibili.
  • Il barbone a fine livello non camminava sul posto col joypad: era l'ANIMAZIONE che restava accesa. Da _termina() in poi _muovi_runner() non viene più chiamato e _leggi_input() torna già Vector2.ZERO — ma un walk_e lanciato con play() su un AnimatedSprite2D continua a girare da solo per sempre, perché nessuno gli dice più niente, e a schermo è indistinguibile da uno che cammina sul posto. Adesso posa idle_s e bandiera _posa_finale che vieta di riscriverla (stessa trappola già pagata su _colpito). Chi è stato spazzato via tiene la sua faccia stupita.
  • Dalla metro scendeva il barbone, e scendeva la celere. Non era un caso: nel manifest degli NPC c'è arch_player (player_cat_frames, player_new_frames), cioè gli sheet del giocatore, e il filtro escludeva solo arch_police. Fuori arch_player e — per la stessa ragione per cui c'era già la polizia — anche arch_raid: un celerino che scende dalla metro e ti fa l'elemosina è il contrario di quello che fa in strada. Nello scatto del 21/8 si vedono tutti e due, barbone e celerino, in mezzo alla folla.
  • L'ombra mancava solo ai passeggeri del bonus, e per come sono fatti: gli NPC di città nascono da NPC.tscn / ModularNPC.tscn / Police.tscn / RaidPolice.tscn, che hanno il nodo Shadow dentro la scena; questi sono costruiti a mano riga per riga, e nel copiare il barbone (che l'ombra ce l'ha) era rimasta fuori proprio lei. Stessi numeri delle scene di sopra: sprite shadow.png, y +6, z −1, alfa 0,85.
  • [change] Chiuso anche il KO del 21/8 sul valore della moneta: «per il 200 e 400 le monete a terra rimangono sempre 200 ma varranno 2 dollari e 4 dollari l'una». La moneta raddoppia col giro (1 → 2 → 4), perché raddoppia il biglietto (bank_gold_threshold, SU-466: 100 → 200 → 400). Con la moneta fissa a $1 il lordo restava $200 per sempre: al secondo giro pareggiava il biglietto e dal terzo lo perdeva di sicuro, cioè il premio non conveniva mai a nessuno, comunque si giocasse. Raddoppiando anche la moneta il rapporto resta 2:1 a ogni giro. ⚠️ Si legge giro e non bank_gold_threshold: la soglia raddoppia quando il premio viene riscosso, quindi mentre si è quaggiù vale già il prezzo del prossimo biglietto.
  • Verificato, non dichiarato. Sonda nuova probe_su491_metro.gd (+ tools/autotest/probe_su491_metro.sh), 11 criteri, 0 KO: convoglio in campo 1,35 s mentre corre; muso fermo dentro l'inquadratura; 12 porte con le ante da 284 a 0 px in 1,10 s; 0 monete incassate senza chiedere; 40 persone uscite fra 0,03 e 6,27 s; 0 su 40 senza ombra; 0 su 40 con lo sheet del barbone; $200 chiedendo; posa idle_s che regge 3 s di joypad; moneta 1·2·4 per giro; convoglio 903 px verso sinistra in 3 s. Provino shot_su491_metro.gd (+ shot_su491_metro.sh), sette scatti guardati in TMP/screenshots_claude/su491_metro/. ⚠️ La sonda vecchia è stata corretta, non aggirata: il suo oracolo camminava sopra le monete e con l'elemosina incassava zero su un livello sanissimo — adesso chiede, e il criterio economico è passato da «dal secondo giro deve perderci» (regola della moneta a $1) a «il lordo resta il doppio del biglietto a ogni giro», che è la regola del KO. probe_su491.sh ESITO: OK.
  • ⚠️ Da guardare al prossimo giro, e non è stato toccato: con l'elemosina l'oracolo perfetto porta a casa 200 su 200 in 30 secondi (prima il tetto di progetto era 45-90% anche per chi gioca da dio). Il livello è più permissivo: le leve sono i 30 secondi, il raggio da 46 px o l'ampiezza della zona in cui la folla passeggia. Non l'ho stretto di mia iniziativa perché il tocco della meccanica è una decisione di Ivan.
  • Non provato: nessun run su device reale (regola di progetto: simulatori e headless), e il tasto «A» dei VirtualControls è mappato su interact ma non è stato provato in un giro touch.

Il tunnel: treno alto, binari larghi, rumore, musica e una porta a blocchi2026-08-21

• [change] SU-489 — il treno del bonus stage si vede tutto, e la corsia si è allargata per contenerlo. Ivan, guardando il livello: «eccoti il treno da mettere e servono rotaie più larghe come terreno, con stessa grafica e stile ma più larghe per accomodarsi al treno nuovo». ⚠️ L'immagine che ha ripassato è byte-identica al raw già in gioco (0 pixel diversi su 1.572.864, confronto pixel a pixel): il disegno non cambia, cambia quanto se ne vede. La fiancata non è più compressa a 26 px ma è quella piena del raw, 45, quindi lo sprite passa da 504×90 a 504×109 — si vedono le ruote, i carrelli e le porte intere, che prima erano schiacciate in tre righe.
  • Il ticket era di geometria, non di import, ed è la corsia il numero che si è mosso: da 96 a 112 px (TILE in BonusLevel.gd). Un treno da 109 dentro una corsia da 96 sconfinerebbe di 13 px oltre la mediana, cioè coprirebbe il barbone che si è appena messo in salvo sull'altro binario: la corsia si allarga per non mentire su chi è al sicuro, non per bellezza.
  • Il tassello nuovo NON è stato rigenerato dal raw, e la ragione è quella che di solito si scopre tardi: il 96×96 in gioco è già cucito, e quella cucitura era costata tre giri a SU-464 (prima una riga scura sul confine, poi troppo legno e nessuna piastra di fissaggio). tools/allarga_binario_metro.py parte dal tassello di gioco e ne ricopia le righe — ghiaia, traversine, testa della rotaia e bulloni — spostando i due «blocchi rotaia» interi: così «stessa grafica e stile» è letterale e la cucitura orizzontale non è mai stata toccata. Scartamento da 32 a 44, stacco fra le corsie 68. ⚠️ Lo script sovrascrive il file che legge, quindi le rotaie le misura (le due righe più chiare, luminanza ~150 contro i ~54 della ghiaia) invece di averle scritte in una costante: al secondo giro la sorgente è già quella allargata, e righe fisse prenderebbero un pezzo di ghiaia scambiandolo per una rotaia.
  • La regola che non è cambiata: entrambe le rotaie devono cadere dentro il tetto del treno, se no il treno galleggia davanti ai binari invece di starci sopra. Con lo sprite ancorato centrato (come prima: il treno alto 109 in una corsia da 112 è centrato di suo, occupa 1..110) il tetto copre y 1..65 del tassello, e le rotaie stanno a 12 e 56 apposta. Il centro corsia resta a metà del tassello, così le due corsie restano simmetriche — 56 px dalla mediana per parte — e nessuno dei due binari diventa più difficile dell'altro.
  • I tempi ricalcolati, non «tarati a occhio»: il cambio di binario passa da 1,07 a 1,24 s, quindi PREAVVISO_TOT da 2,60 a 2,80 — il numero che SU-488 dichiara intoccabile è il margine (1,5 s di cammino libero dopo il cambio), non il preavviso: tenendo 2,60 il margine sarebbe sceso a 1,36, cioè si sarebbe limata la finestra di reazione senza che nessuno se ne accorgesse. Di conseguenza PROGRESSO_STOP_TRENI 0,92 → 0,91 (il punto d'incontro si è allontanato da 234 a 252 px), RUNNER_Y_MIN/MAX ±64 → ±71, CAM_Y 130 → 140 (il fondo del binario basso è sceso da 256 a 288: a 130 la camera avrebbe tagliato il treno alle ruote, cioè proprio ciò che il ticket serve a mostrare), e SCARTO_CORSIA delle lattine in BonusRewards.gd 47 → 56.
  • ⚠️ Un difetto vero trovato dallo scatto, e visibile solo adesso: sotto le ruote correva una riga ROSA. Non era una svista della maschera del fondo — quei pixel sono opachi, sono l'ombra del treno disegnata *sul* magenta, e nessuna soglia di trasparenza li prende. Con la fiancata compressa a 26 px finivano schiacciati in due righe e non si vedevano. Curati sul colore in importa_treno_metro.py (despill: dove min(R,B) − G > 20, R e B si riportano vicino a G), prima della riduzione, sennò la media d'area allarga il rosa invece di toglierlo. Residuo magenta misurato: da 423 px a 0, e la riga rossa della fiancata è intatta (1.332 pixel rossi vivi) perché il rosso ha B basso e non supera la soglia.
  • Verificato, non dichiarato: compile-check verde sui due script; probe_su491_bonus.gd tutta verde con i numeri nuovi — finestra di reazione 1,556 s (minimo 1,50), margine sul tempo limite 11,5-12,0 s (minimo 6,0), attraversamento 48,0-48,5 s su 60, lattine, folla e conto economico invariati. Provino nuovo shot_su489_treno.gd (+ tools/autotest/shot_su489.sh) perché shot_su491 scatta il treno quando il muso è ancora 272 px fuori campo: mostra i chevron, non il vagone sui binari. Tre scatti guardati — binari vuoti, muso addosso, transito.
• [feat] Il tunnel ha il suo rumore: il treno che passa e l'allerta che lo annuncia. Chiesti da Ivan lo stesso giorno del treno («serve poi anche il suono del treno quando passa, e quello di allerta quando viene segnalato, prima che passi»). ⚠️ La musica del bonus stage NON è qui e non è una dimenticanza: «alla musica ci penso io» — sta scritto anche accanto alle costanti, così alla prossima sessione non la si aggiunge per zelo.
  • Il rombo è POSIZIONALE (AudioStreamPlayer2D attaccato al vagone, non un lettore fisso): panning e distanza li fa Godot mentre il treno corre, e il suono arriva da destra crescendo — che è la stessa informazione che danno i chevron, ma per le orecchie. Il lettore sta in mezzo al convoglio e non sul muso, se no il rumore passerebbe un secondo prima del treno.
  • ⚠️ NON parte alla nascita del treno, e il perché è un conto: il treno nasce 1.176 px fuori campo e il file dura 5 s — accendendolo subito, il rombo tacerebbe proprio sotto le ruote. Si accende a 900 px, cioè 1,76 s prima dell'incontro (chiusura 420 + 90 = 510 px/s): copre arrivo, transito (1,20 s) e due secondi di coda mentre si allontana.
  • L'allerta invece NON è posizionale, ed è una scelta: in 2D il panning è solo orizzontale e le due corsie stanno una sopra l'altra, quindi un suono messo sulla corsia in pericolo direbbe «da destra» — sempre vero, quindi nessuna informazione. Da quale corsia arriva il treno lo dicono i chevron; questo suono dice «guarda a terra, adesso». Suona all'accensione della fila e una seconda volta al secondo stadio, stesso file più acuto (+18% di pitch, +2 dB): un asset invece di due.
  • Anche la metro che entra in stazione ha il rombo, con il pitch che cala mentre frena (0,72 a fermo): senza, ora che i treni del corridoio suonano, l'arrivo muto sarebbe stonato più di prima.
  • ⚠️ Un difetto vero trovato dalla sonda, che il compile-check dava verde: la metro non suonava affatto. Il play() stava prima di add_child(_metro), e un lettore che non è ancora nell'albero non suona e non protesta — nessun errore, nessun avviso, livello che gira. Spostato dopo. È il motivo per cui probe_su489_suoni.gd guarda playing sui lettori veri invece di controllare che il codice ci sia: 12 controlli, 0 KO (rombo fermo alla nascita, acceso a 892 px su 900 dichiarati, bus SFX su tutti i lettori, due colpi d'allerta per treno, metro accesa all'ingresso e calata alla fermata).
  • I file: generati con ElevenLabs e normalizzati a −20,0 dB RMS, che è la fascia degli effetti esistenti (coin −21,6, raid_siren −19,9) — un effetto nuovo non allineato entra sempre più forte degli altri e sembra un errore di missaggio. Coda muta tagliata, fade 30 ms in / 250 ms out contro i click. Sul bus SFX (con ripiego su Master se non esiste), quindi lo slider «Effetti» delle Opzioni li governa. ⚠️ Il verdetto a orecchio non è mio e non lo può essere: i due file sono stati mandati a Ivan per l'ascolto.
• [feat] Fra la città e il tunnel adesso c'è una dissolvenza a BLOCCHI, come nei giochi a 16 bit. Chiesta da Ivan: «ci va inoltre tra il livello standard e il bonus stage una transizione grafica, tipo un fade pixelloso o roba che potrebbe stare bene in un gioco retro». Lo schermo si riempie di quadrati neri in ordine sparso (0,40 s), sotto il nero pieno si cambia scena, e i quadrati se ne vanno a ritroso (altri 0,40 s). Vale in tutti e due i versi: si scende e si risale.
  • Perché non un fade morbido: un ColorRect con l'alfa sarebbe stato tre righe, ma sfuma i pixel del gioco in una nebbia grigia — l'opposto di quello che deve sembrare un gioco in pixel art. I blocchi invece sono la dissolvenza dei 16 bit.
  • ⚠️ Niente shader e niente mille nodi, e sono due trappole diverse. Uno shader che non compila in Godot non fa rumore: ripiega sul materiale di default e l'effetto sembrerebbe «solo un po' più brutto» invece che rotto (la trappola di SU-484). Un nodo per blocco sarebbero ~1.200 nodi creati e liberati a ogni ingresso. Quello che c'è è un'immagine 40×30 — un pixel per blocco — disegnata su tutto lo schermo in NEAREST: «pixelloso» è letterale, aggiornare la transizione è scrivere qualche centinaio di pixel e disegnarla è un rettangolo solo. Le righe si ricavano dal rapporto dello schermo, se no i blocchi sarebbero rettangoli diversi su telefono e su tablet.
  • ⚠️ Il velo vive sulla RADICE con PROCESS_MODE_ALWAYS, perché il livello bonus congela la città col process_mode: un'animazione appesa a un ramo congelato si fermerebbe proprio nell'istante in cui serve. E il tempo si misura con l'orologio vero, non sommando i delta, per la stessa ragione.
  • ⚠️ La transizione sta nel CHIAMANTE (Interactable._metro_apri_bonus), non dentro BonusLevel.entra(), ed è una scelta di compatibilità misurata: entra() è sincrona e dieci sonde la chiamano aspettandosi il livello nello stesso istante. Mettendo l'attesa lì dentro sarebbero da correggere tutte; così la transizione la vede solo chi gioca. In uscita invece è dentro _risali(), con due protezioni: un guardiano _in_risalita (la risalita veniva chiamata a ogni fotogramma dopo l'outro — prima non dava fastidio perché la scena si liberava subito, adesso resta viva 0,4 s e sarebbero partite dieci risalite) e il salto dell'effetto quando debug_manuale è acceso, cioè per le sonde.
  • ⚠️ E una regressione vera, trovata al cancello di chiusura e non dal compile-check: in HEADLESS la transizione non va saltata per comodità, va saltata perché non c'è schermo. probe_collaudo_bancametro percorre il giro vero — banca piena → arcobaleno → fermata → livello bonus → risalita — cioè passa dal chiamante, e cercava il livello nell'istante della chiamata: con la transizione di mezzo il livello nasce 0,4 s dopo, e sono usciti tre controlli rossi («bonus_level_active si alza», «bonus_level_started emesso», «il livello si è davvero aperto») nessuno dei quali era un difetto del gioco. La cura non è stata far aspettare la sonda: in headless un velo non ha niente da nascondere, quindi PixelWipe.copri() lì esegue e basta, sincrono come prima. Sonda di nuovo verde.
  • Verificato guardando E misurando: shot_su489_transizione.gd 9 controlli, 0 KO — a 25/55/90% di copertura chiesta corrispondono 300/660/1080 blocchi su 1.200 e la stessa percentuale di pixel neri sullo schermo vero (25/55/90%), il cambio di scena avviene con 1.200 blocchi su 1.200 coperti, e alla fine il velo si è liberato da solo. Tre scatti sulla città guardati: quadrati netti, nessuna sfumatura. ⚠️ Il provino esercita anche il ramo di uscita, che nessuna sonda del bonus guardava (girano tutte con debug_manuale, che lo salta): la risalita nasce un solo velo, richiamarla due volte non ne fa partire altri — è il guardiano — e a fine transizione il livello bonus è stato liberato.
• [docs] Il CENTRO entra in MUSICA_AI_PROMPTS.md: due prompt da provare, e un vincolo che non si tocca. Ivan: «proponimi un prompt e un testo instrumental per il quartiere Centro, che avevo già prima e potrei cambiarlo a sto punto». SU-385 aveva lasciato il Centro su main2.ogg di proposito; adesso ci sono due strade, non due tentativi: A — 100 BPM, F# minor, città grigia ma viva, parente stretta di main2 (il cambio si sente come un rifacimento); B — 108 BPM, F# major, Centro cartoonesco e solare (il cambio si sente come una decisione).
  • ⚠️ La tonica resta FA# in tutte e due, e non è gusto: è un rimando che esiste già nel gioco. NOTTEFONDA è in FA# minore *perché* è la tonalità di main2, cioè della città di partenza — «stessa tonica, trattamento opposto: chi arriva in fondo alla linea sente *casa, andata a male*». Cambiando tonalità al Centro quel richiamo non richiama più niente e NOTTEFONDA diventa un brano teso a caso. Il modo invece è libero, e la variante B (maggiore) rende il contrasto più netto, non meno.
  • ⚠️ È il brano che si sente più a lungo di tutti, perché è il quartiere dove si gioca quasi sempre: le due regole di §1 che di solito si citano per dovere qui valgono il doppio — medi liberi (monete, gatti e sirena vivono lì) e melodia indietro. Se una delle due va sacrificata, si sacrifica la melodia.
  • Variante di struttura per il solo Centro (due sezioni D in più nel blocco dei testi): il riavvio è secco e si sente una volta ogni durata del brano — su 6 minuti in una partita da mezz'ora sono cinque volte, portandolo a 7-8 sono tre. Il quartiere più frequentato è quello dove conviene spendere l'Extend.
  • Come si monta, verificato nel codice e non ricordato: il Centro ha "musica": "" in Quartieri.gd:249, ed è la stringa vuota a farlo ripiegare su main2.ogg; basterà res://assets/sounds/quartieri/centro.ogg, dopo taglio a battute intere e allineamento a −16,0 dB RMS come le altre sette.
• [feat] La musica del bonus stage — composta da Ivan — entra nel tunnel, e il tunnel smette di essere muto. ⚠️ Il silenzio di prima non era una dimenticanza ed è utile saperlo: la musica del quartiere vive su un AudioStreamPlayer figlio della città, e _congela_superficie() mette in pausa tutti i suoni della città quando si scende — quindi una traccia per quaggiù *deve* stare appesa al livello, non al mondo. Sul bus Music (lo slider Musica la governa come ogni altra traccia), riavvio secco sul segnale finished come fa World.gd, e volume che scende in 0,35 s durante la risalita invece di essere tagliato di netto insieme alla scena.
  • ⚠️ Il BPM misurato con l'autocorrelazione era SBAGLIATO, ed è la trappola già registrata per SU-385: dava 118,5, il tempo vero è 120,0. La differenza sembra nulla e non lo è — sposta il punto di taglio di un secondo e mezzo, cioè manda il loop fuori tempo. Il metodo che decide non è l'autocorrelazione ma una controprova: si costruisce la griglia dei movimenti per ogni tempo candidato e si guarda quanto ci cadono sopra gli attacchi veri. A 120 BPM ci cadono 2,03 volte più che a caso, contro 1,1-1,3 di tutti gli altri candidati: si stacca da solo.
  • ⚠️ Si taglia anche la TESTA, non solo la coda. Il brano ha 0,495 s di attacco prima del primo battere: conservandoli e chiudendo su un battere, l'intervallo fra l'ultimo battere e il primo del giro nuovo diventa mezzo secondo invece di una battuta — «a battute intere» sulla carta, fuori tempo nell'orecchio.
  • Il taglio scelto: 59 battute intere, 118,0 s (da 0,495 a 118,495). Non è il più lungo possibile: fra i candidati vince quello che minimizza il salto misurato alla giunzione, e questo dà 0,44 dB di dislivello e +1,5% di timbro fra coda e testa, contro i 3,76 dB del taglio a 69 battute che avrebbe conservato 20 s in più. Sono 20 s che in gioco non si sentirebbero comunque: il livello dura al massimo ~100 s (intro 5,65 + corridoio 60 + banchina 30 + outro), quindi il loop non si chiude quasi mai ed è una rete, non la norma. Volume portato a −16,0 dB RMS esatti come main2 e le sette dei quartieri; Ogg a 111 kbps, 1.466 KB. Medi al 19,7% dell'energia, sotto il 20,6% di main2: gli effetti del tunnel hanno spazio.
  • tools/importa_musica_quartiere.py, che SU-385 non aveva lasciato: misura del tempo con la controprova sugli attacchi, ricerca della griglia, scelta del taglio, aggancio a un passaggio per lo zero, allineamento RMS, export Ogg e stampa della banda dei medi. Servirà di nuovo per il CENTRO, quando la traccia ci sarà.
  • Verificato: probe_su489_suoni 16 controlli, 0 KO — la musica parte con l'intro, sta sul bus Music (⚠️ *non* su quello degli effetti: una musica finita per sbaglio su SFX suona benissimo e obbedisce allo slider sbagliato, e te ne accorgi solo abbassando gli effetti), e dura 118 s cioè più del livello. Giro completo banca → fermata → bonus → risalita verde. ⚠️ Il giudizio sulla cucitura non è mio: come per le sette dei quartieri è stato prodotto un provino di 6 s (coda + testa, riavvio al secondo 3) e mandato a Ivan.
• [fix] I binari erano larghi giusti ma alla quota sbagliata: scesi di 48 px, a livello delle ruote. Ivan, guardando il gioco: «i binari ora vanno bene come larghezza ma sono sfalsati rispetto al treno, il treno deve rimanere dove si trova e i binari vanno shiftati più in basso per stare a livello ruote e frecce». Le rotaie passano da y=12/56 a y=60/104 dentro il tassello (scartamento 44 invariato, treno non toccato).
  • I due numeri sono misurati, non scelti a occhio: la rotaia bassa (104) cade dentro la fascia dei carrelli dello sprite — che sta alle righe 101-109 del tassello, trovata sul crollo di luminanza (da ~100 a ~30) e di opacità (da 100% a 40%) — e la rotaia alta (60) cade dentro i chevron, che sono alti 48 e centrati sul centro corsia (56).
  • ⚠️ Cade la regola che questo stesso changelog dichiarava poche ore fa («entrambe le rotaie dentro i primi 64 px, cioè il tetto»). Non era sbagliata quando è stata scritta: era il modo di far leggere «il treno sta sui binari» quando la fiancata era compressa e le ruote non si vedevano. Adesso le ruote si vedono, e a dirlo è il contatto ruota-rotaia. Il commento nel codice porta la regola nuova e il motivo per cui la vecchia è decaduta, se no fra un mese sembra un errore.
• [fix] Il collaudo di Ivan sul tunnel: cinque rilievi, e il più grosso non era un difetto del bonus ma della città che non spariva. Tutti da una partita vera, tutti chiusi in questo giro.
  • ⚠️ «I fumetti e le monete che saltano restano bloccati a video appena inizio il bonus.» _congela_superficie() spegneva i CanvasLayer figli diretti del mondo, e i due colpevoli sono annidati: SpeechCanvas sta dentro *ogni* NPC (NPC.tscn, ModularNPC.tscn, Police.tscn, RaidPolice.tscn) e FxCanvas — quello del «giro della monetina», Sprite2D in screen-space con un tween che sale — sta dentro il Player. Un CanvasLayer non eredita il visible del padre Node2D: restavano accesi, e col process della città spento restavano anche fermi. Adesso si spengono tutti i discendenti. Il numero che dice quanto era grosso: 79 CanvasLayer nella città, di cui 4 figli diretti — 75 erano fuori portata.
  • Stessa forma, stesso rimedio, per l'audio: la pausa dei suoni guardava anch'essa i soli figli diretti, mentre SfxCoin, SfxBeg e SfxFart stanno dentro il Player — un suono lungo partito un attimo prima continuava sotto la musica del tunnel. ⚠️ E vanno cercati due tipi: AudioStreamPlayer2D non eredita da AudioStreamPlayer (uno è Node, l'altro Node2D), quindi una ricerca sola ne lasciava fuori metà. Sono 24 i lettori nella città, quasi tutti annidati.
  • ⚠️ «Il treno ha un rettangolo attorno trasparente orrendo.» Era la scia d'aria: un ColorRect azzurrino (alfa 0,20) grande quanto la corsia e 120 px più lungo del convoglio. Serviva quando il treno disegnato era alto 64 su una corsia da 96 e ne copriva due terzi: diceva che a fare male è la corsia intera, non la sagoma. Oggi il treno è 109 su 112 — non spiegava più niente e si vedeva soltanto. Tolta, col commento che dice a quale condizione andrebbe rimessa.
  • «La musica deve partire appena premo la metropolitana, già durante la transizione.» Prima partiva col livello, cioè 0,8 s dopo — muti proprio nell'istante in cui succede la cosa. Ora il lettore nasce sulla radice quando si preme la fermata (il tunnel in quel momento non esiste ancora), il livello lo adotta invece di crearne un secondo, e _risali() lo libera a mano: ⚠️ stando sulla radice non muore con la scena, e senza quella riga si tornerebbe in città con la musica del bonus addosso per sempre. Aggiunto puo_entrare(), condiviso con entra(): senza, premere la fermata in multiplayer accenderebbe la musica per un ingresso che verrà rifiutato.
  • «Il barbone non ha l'ombra a terra.» Messa, con lo stesso sprite e gli stessi numeri di Player.tscn (alfa 0,85, z −1, offset (0, 6) sul personaggio che sta a (0, −8)): senza, nel tunnel sembrava appiccicato sopra il pavimento invece che poggiato.
  • «I suoni delle lattine e delle monete raccolte, come nel livello standard.» Sono gli stessi di sopra e non due nuovi: coin.wav a −2 dB per la moneta e il «tonk» inarmonico che CanDrop sintetizza in codice per la lattina. ⚠️ Quaggiù non si passa dal Player — il barbone del tunnel è un AnimatedSprite2D mosso a mano, play_sfx_can() non esiste — quindi si suona lo stream diretto, con lo stesso anti-mitragliata da 55 ms di CanDrop e due contatori distinti: sulla banchina si cammina in mezzo a 200 monete.
  • Verificato: probe_su489_congelamento.gd (nuova) 5 controlli, 0 KO — ⚠️ e non si limita a dire che ora è a posto: conta i CanvasLayer annidati per dimostrare che il difetto era reale (79 contro 4), accende a mano fumetti e monetina, scende, e controlla anche che risalendo tornino accesi quelli che lo erano. probe_su489_suoni sale a 17 controlli, 0 KO (musica sulla radice, un solo lettore e non due sovrapposti, ombra presente). Scatti guardati: niente rettangolo attorno al treno.
• [fix] Le frecce a terra adesso corrono in mezzo ai binari, non 26 px più su. Ivan, dopo l'ultimo giro: «tutto ok per la metro tranne le frecce, che a questo punto vorrei allineate in mezzo ai binari, ora sono più su». I chevron erano ancorati al centro della corsia (56 nel tassello) — che era anche il centro delle rotaie *finché le rotaie erano centrate*. Da quando sono scese a 60 e 104 le due cose non coincidono più, e la differenza si vedeva: la fila passa da y 120 a 146, cioè sulla riga in mezzo alle rotaie, dove passerà davvero il treno.
  • Il legame è ora esplicito nel codice: tre costanti nuove (ROTAIA_ALTA_NEL_TILE, ROTAIA_BASSA_NEL_TILE, ROTAIE_CENTRO_NEL_TILE) dicono dove sono le rotaie dentro il PNG, e i chevron si allineano a quelle. ⚠️ Sono il riflesso di come è disegnato il tassello: se si rigenera con --centro N vanno rifatte, se no si allineano a binari che non ci sono più. È lo stesso inciampo di questo giro, scritto perché non si ripeta.
• [change] Le lattine non stanno più su due righe: sono sparse in verticale. Ivan: «le lattine le vorrei sparse a caso in verticale, non solo sui binari». Prima ogni lattina cadeva sul centro di una delle due corsie (una randi fra 0 e 1) e in gioco si leggevano come due file ordinate. Misurato adesso su un giro vero: 47 lattine su 37 righe distinte (prima erano 2), da y=113 a y=241.
  • ⚠️ Il criterio non è «sparse» ma «sparse E raggiungibili»: la fascia è quella in cui il barbone può davvero arrivare (RUNNER_Y_MIN..MAX, 105-247) meno un margine di 4 px. Una lattina fuori di lì si vedrebbe benissimo e non si potrebbe prendere — sarebbe arte, non un premio. Il provino lo verifica e non lo assume: 47 su 47 raggiungibili.
  • ⚠️ E la fascia ARRIVA DAL LIVELLO, non è una costante dei premi: prepara() prende un argomento in più, che BonusLevel riempie con RUNNER_Y_MAX − LINEA_MEDIANA. È la lezione appena pagata dai chevron, che erano ancorati a un numero che aveva smesso di coincidere. Il parametro ha un default perché due sonde (probe_su491_bonus, probe_su468_premio) chiamano ancora con quattro argomenti: senza, si sarebbero rotte in silenzio.
  • 📌 Conseguenza di gioco misurata, portata a Ivan e da lui APPROVATA: l'oracolo che cammina dritto raccoglie ora 13 lattine su 47 invece di 16-25, perché per prenderle bisogna deviare. Gliel'ho segnalata come cosa da valutare, e la risposta chiude la questione — «no no meglio, poche lattine che ci va tempo a guadagnarsele». ⚠️ Sta scritta anche nel codice accanto ai numeri: chi ci rimetterà mano non deve «rimediare» al calo stringendo la fascia o alzando LATTINE_MIN/MAX, perché il costo in tempo è il premio.
• [feat] Quello che raccogli salta sopra la testa, e il bidone d'oro in fondo non c'è più. Ivan: «anche nel bonus stage quando raccogli qualcosa, soldi o lattine, deve saltare sopra la testa del barbone la cosa raccolta, vedo ancora al fondo il bidone d'oro che deve sparire».
  • Il salto è quello di sopra, numeri compresi, presi da Player._spawn_item_fx() e non rifatti a occhio: parte 50 px sopra il personaggio e 10 a destra, sale di 48 in 0,28 s con ease OUT, ricade a 8 sopra la testa in 0,42 s sfumando. ⚠️ Non si passa dal Player — quaggiù il barbone è un AnimatedSprite2D mosso a mano e fx_canvas non esiste — quindi l'animazione gira in coordinate mondo invece che in screen-space: a parità di zoom è lo stesso effetto con metà codice. Tetto di 5 oggetti in volo insieme: in superficie non serve, sulla banchina si attraversano 200 monete e senza tetto ne partirebbero venti per fotogramma.
  • Il bidone d'oro era il traguardo di SU-467, quando il livello finiva con «arrivi in fondo e lo prendi». SU-491 gli ha messo al suo posto la banchina e lui era rimasto come fondale. Un premio che non si può più prendere, in fondo a un livello che premia in un altro modo, prometteva una cosa che non succede: tolto (restano le due luci calde, il fondo si legge lo stesso).
  • ⚠️ Lattine e folla della banchina pescavano dallo STESSO generatore casuale, e si è visto solo adesso: cambiare il modo di piazzare le lattine ha spostato anche dove la folla semina le monete. Adesso le lattine hanno la loro sequenza — è la stessa ragione per cui il loro seme aveva già uno scostamento rispetto a quello dei treni.
  • ⚠️ E UN CONTROLLO DELLA SONDA È ROSSO, con la causa provata e una decisione che spetta a Ivan. probe_su491 chiede che l'oracolo perfetto raccolga fra il 45% e il 90% delle monete della banchina («la banchina resta una corsa anche per chi gioca da dio»): adesso ne prende 184 su 200, il 92%. Provato nei due versi invece che ipotizzato: col codice di prima delle lattine sparse sono 180 (90%), con le lattine sparse 184. E non è rumore del seme — rifatta la misura con quattro semi diversi della folla, esce 184 tutte e quattro le volte. La sostanza non cambia (sono 4 monete su 200, cioè $4 su un biglietto da $100, e il conto economico resta identico), ma il numero supera un paletto che è un criterio di design: alzarlo di mia iniziativa sarebbe aggiustare il test. Portata a Ivan come scelta fra alzare il tetto della sonda e ritarare la banchina — risposta: «attendi e lascia così che tanto nei prossimi messaggi faccio cambiare una cosa». Quindi il controllo resta ROSSO di proposito, in attesa delle modifiche successive: la taratura si fa una volta sola, alla fine, invece di due volte per niente. ⚠️ Chi vede quel rosso prima di allora non lo consideri un difetto scoperto: è un paletto sospeso, e questo è l'unico posto dove sta scritto.
• [fix] Quello che salta passa davanti alla carrozza, non dietro. Ivan: «le monete che saltano devono essere in primo piano rispetto alla carrozza della metro quando ce l'ho sopra e raccolgo». L'oggetto in volo stava a z 5 e la metro ferma a 6: raccogliendo sotto il vagone in stazione, il salto spariva dietro la fiancata proprio nel momento più affollato del livello. Adesso è a 10.
  • I due numeri non sono più scollegati: la metro usa Z_METRO_FERMA invece di un 6 scritto a mano, e accanto a FX_SALTO_Z c'è scritto su cosa si misura. Il provino confronta i due valori a runtime, quindi se un domani la metro sale, la sonda lo dice invece di lasciarlo scoprire giocando.
  • ⚠️ Il provino ha dovuto imparare due cose per provare davvero questa riga. Primo: bisogna essere sotto il vagone — il primo giro raccoglieva la prima moneta incontrata, a mezza banchina dalla metro, e l'immagine non dimostrava niente; ora il barbone si piazza sotto la carrozza e poi raccoglie, e la sonda stampa gli estremi del vagone per dire se lo scatto vale (sotto il vagone: true). Secondo: nel provino il tempo reale è quasi fermo, e i tween vanno col tempo reale — gli oggetti lanciati camminando restavano appesi per sempre e il tetto di cinque bloccava ogni salto successivo, così la raccolta sotto la metro non produceva alcun effetto. È un difetto del provino, non del gioco (dove un oggetto atterra in 0,7 s): il cielo si svuota prima dello scatto, e sta scritto perché.
  • ⚠️ E lì è saltato fuori un errore vero del gioco: il callback del tween chiamava queue_free() sullo sprite anche se qualcun altro l'aveva già liberato — uno SCRIPT ERROR per fotogramma, di quelli che non si vedono finché non capita. Aggiunto is_instance_valid prima di liberare.

La musica del tunnel non si fermava: il tween moriva col livello2026-08-22

• [fix] Risalendo in città si sentiva ancora la musica del bonus, solo più bassa. Ivan: «la musica sotto del bonus stage non si è fermata ma si è solo abbassata, la sento ritornando su dal livello».
  • ⚠️ La causa è una riga sola, ed è il tipo di errore che il compile-check non può vedere: il tween della dissolvenza era creato con create_tween() sul livello. create_tween() lega l'animazione al nodo che la chiede, e il livello viene liberato un istante dopo — a schermo coperto, durante la galleria. Moriva il tween, e con lui il queue_free finale: il lettore restava sulla radice al volume raggiunto, che suonava per sempre sopra la città. Adesso il tween lo crea il lettore stesso, che vive sulla radice e nessuno libera.
  • E c'è una rete, perché l'errore è già sfuggito una volta ed è udibile: un timer dell'albero — che non muore con nessun nodo — libera il lettore comunque, se per qualunque motivo il tween non arrivasse in fondo. Passa l'id e non il nodo: un lambda che cattura un nodo liberato fa gridare Godot prima ancora di entrare nel corpo.
  • Provato nei due versi, che qui era obbligatorio: col controllo nuovo il provino dice «nessun lettore MusicaBonus sulla radice»; rimettendo il difetto diventa rosso e stampa il sintomo esatto che Ivan ha sentito — MusicaBonusMorente (-25,7 dB, playing true), cioè abbassata e ancora accesa. Senza la controprova, un controllo verde non avrebbe dimostrato di saper vedere niente.
  • 📌 Il controllo mancava perché guardavo la cosa sbagliata: il provino verificava che il *livello* si fosse liberato, e il livello si liberava davvero. Il lettore, però, sta sulla RADICE apposta (per poter suonare già durante la transizione d'ingresso) e a quella verifica sopravviveva.
  • Verificato: shot_su489_transizione 15 controlli, 0 KO; suoni 17/0; probe_su491 verde salvo il 92% sospeso.

Il treno prende chi tocca, non chi «sta sulla sua corsia»2026-08-22

• [fix] La collisione col treno adesso guarda le SAGOME, testa e piedi compresi. Ivan: «la metropolitana nella sua area colpisce qualsiasi punto del barbone (testa, piedi) — ora ad esempio quella in alto è passata e io ci sono entrato dentro con la testa senza essere colpito». Il criterio vecchio chiedeva da che parte della mediana stessero i piedi: bastava tenere i piedi di sotto per infilare la testa dentro il vagone e uscirne vivo. Adesso si confrontano l'ingombro del barbone e quello del treno.
  • L'altezza del barbone si MISURA dallo sprite, non è scritta a mano: i personaggi si sbloccano e non sono tutti alti uguale, e un numero fisso darebbe una collisione giusta per uno e sbagliata per gli altri.
  • ⚠️ E la regola nuova ha stanato un difetto vero, introdotto ieri sera da me: la riga che manda gli ultimi treni sul binario alto cambiava la corsia dopo aver calcolato la posizione, quindi quel treno restava disegnato in basso con l'etichetta «alta» — un treno fantasma, visibile dove non era. Finché la collisione leggeva l'etichetta il difetto era invisibile; con le sagome è saltato fuori subito, e la diagnostica lo diceva in chiaro: «preso a y 230 da un treno di corsia 0 posizionato a y 232». Il centro adesso si calcola dopo la correzione.
  • Il livello resta superabile, e non è un'opinione: probe_su491 verde con 14,0 s di margine sul tempo limite (46 s su 60) e finestra di reazione 1,556 s.
  • 📌 Due oracoli di sonda hanno dovuto imparare a schivare meglio, ed è la conseguenza onesta della regola nuova: quello di probe_su489_suoni sterzava solo mentre il treno era vicino e poi tornava dritto, restando a metà fra le due corsie — posizione che ora vuol dire «testa dentro il treno di sopra». Adesso punta sempre al centro di una corsia e ci resta. Senza la correzione la sonda non arrivava alla banchina e saltava in silenzio i due controlli sulla metro (15 verdi invece di 17: un calo che passa inosservato se si guarda solo «0 KO»).
  • Verificato: probe_su489_preso 6 controlli, 0 KO, e la prova ora è mirata alla regola nuova — il barbone si mette a y 182, cioè coi piedi sotto la mediana (col criterio vecchio era salvo) e la testa dentro il treno alto: viene preso. Suoni 17/0 con la metro di nuovo coperta, congelamento 5/0, giro completo verde.

Chi si fa prendere dal treno esce a mani vuote2026-08-22

• [fix] Il treno che ti prende adesso ti costa TUTTO: niente lattine, niente soldi, niente carta. Ivan: «se mi prende la metropolitana non guadagno nulla, né soldi né lattine né tantomeno vinco delle carte».
  • ⚠️ Le lattine se le portava a casa lo stesso, e il perché è un dettaglio di tempistica: l'accredito a MetaProgress partiva nel momento della raccolta, quindi erano già tue prima che il treno arrivasse. Adesso si contano soltanto, e diventano tue in _termina(true) — cioè quando sei arrivato in fondo. I soldi erano già a zero per costruzione (le monete stanno solo sulla banchina, e alla banchina non ci sei arrivato).
  • ⚠️ E la carta la vincevi lo stesso: la consegna era attaccata alla fine del LIVELLO, non alla vittoria. Ora chi non arriva in fondo risale e basta. Il conto finale si apre comunque, con gli zeri: dice «hai perso tutto» meglio di qualunque scritta.
  • accredita_lattine() è idempotente (azzera il contatore): il livello può arrivarci da due strade — il conto finale e la rete di sicurezza della risalita — e chiamarla due volte non deve raddoppiare niente.
  • ⚠️ Perché l'accredito sta in _termina e non nel conto: fra i due passa l'outro, 1,2 s, e la sonda legge la meta-progressione appena il giro finisce. Accreditando più tardi vedeva +0 — un falso KO che però indicava il posto giusto: «sei arrivato in fondo» è la condizione, non «la schermata del bottino è comparsa».
• [change] Lo spazzato via usa la posa del BARBONE COLPITO. Ivan: «lo sprite da ruotare come fa ora è quello del barbone colpito, come da un gatto bottiglia o poliziotto». È l'animazione hit delle SpriteFrames — le stesse del gioco di sopra, quindi c'è già — e serve un flag per tenerla: _anima_runner() riscrive la posa a ogni fotogramma in base alla direzione, e senza il flag la faccia stupita durerebbe un fotogramma. (È la trappola già registrata per i provini: «Player riscrive spr.animation ogni frame».)
• Verificato con una sonda nuova, probe_su489_preso.gd — 6 controlli, 0 KO. ⚠️ Serviva apposta: tutte le sonde del bonus giocavano giri VINTI, quindi il ramo «ti prende il treno» non lo esercitava nessuna. E ha un controllo di validità che al primo giro è fallito: «ne aveva raccolte davvero?». Camminando dritto il barbone non incrociava più nessuna lattina (da quando sono sparse in verticale), quindi «non ha guadagnato niente» sarebbe stato vero per modo di dire. Ora ne raccoglie 3 prima di farsi prendere, e il conto resta +0 lattine, +0 dollari, nessuna cerimonia, con la posa a hit.

Le scintille diventano un getto, e l'ultimo treno passa sempre in alto2026-08-22

• [change] Le scintille rifatte guardando due fotografie: non puntini, un GETTO. Ivan ha mandato due foto di un treno che slitta e ha detto «un effetto di questo tipo proprio sulle ruote». La versione di ieri faceva puntini isolati che cadevano — sembravano briciole luminose. Nelle foto non ci sono puntini: c'è un nucleo bianco al punto di contatto, un ventaglio di scie lunghe che schizzano all'indietro, e la rotaia che si illumina. Adesso ci sono tutte e tre, e servono tutte e tre: il nucleo dice *dove* sta succedendo, le scie danno la velocità, il bagliore le fa sembrare calde invece che gialle.
  • Le scie sono rettangoli ORIENTATI (fino a 14×1 px) che puntano dove volano, si accorciano mentre si spengono e ricadono con un filo di gravità. Il perno sta sulla testa e non al centro, se no ruoterebbero su sé stesse invece di puntare in avanti. ⚠️ L'alfa segue una sqrt e non una discesa liscia: con la quota lineare le scie passano metà vita quasi trasparenti e in uno scatto non si vedono.
  • ⚠️ Il getto sta su un carrello per volta e ci resta 0,28 s: cambiando carrello a ogni emissione (35 ms) le scie si spargevano lungo tutto il convoglio — tante scintille, nessun getto. Ma uno solo non bastava: il treno è lungo 504 px e la camera ne inquadra una fetta, così metà delle volte il getto stava fuori quadro e sembrava che l'effetto non ci fosse. Sono tre getti insieme: restano getti, e almeno uno si vede quasi sempre.
  • La texture del bagliore si crea UNA volta: _crea_alone() genera una GradientTexture2D 128×128 a ogni chiamata, e qui servirebbe venti volte al secondo.
  • 📌 Le liste parallele sono diventate un array di dizionari. Nodo, vita, velocità e lunghezza erano tre array da tenere allineati a mano, in un posto dove si rimuove di continuo: la prima svista li avrebbe disallineati in silenzio.
• [fix] Gli ultimi treni vanno sempre sul binario ALTO. Ivan: «l'ultimo treno deve essere sempre nel binario alto, perché può capitare che veda già un pezzo di banchina sotto e il treno ci passa erroneamente sopra». ⚠️ Nasconderlo non bastava, e il perché è nel dettaglio: t.visible guarda il muso, ma quando il muso rientra nel corridoio la coda è ancora 504 px più in là — cioè sopra il pavimento della stazione — e per quei fotogrammi si vede un treno che ci passa sopra. Adesso, se un treno nascerebbe con la coda oltre l'inizio della banchina, va sul binario alto: sopra, il binario corre per tutta la lunghezza del livello. Nessun rischio per la giocabilità: due treni di fila sull'alta lasciano comunque libera la bassa, che è la regola «sempre una via di scampo».
• Verificato: compile-check verde; probe_su491 verde salvo il 92% sospeso; suoni 17/0; giro completo banca→bonus→risalita verde; scatto guardato — sotto i carrelli si vedono nucleo, bagliore e scie.

La cerimonia era muta: zittita insieme alla città2026-08-22

• [fix] I suoni delle carte erano spariti, e la musica del tunnel si spegneva troppo presto. Ivan, sentendolo: «i suoni delle carte si sono persi e non si deve fermare la musica del bonus stage durante lo shuffle delle carte». Due errori miei della voce qui sotto, corretti insieme.
  • ⚠️ I suoni persi: zittivo l'INTERA lista dei lettori congelati della città, e lì dentro c'è la schermata delle carte — è figlia dell'HUD, che è figlio della città. Ogni fotogramma dell'attesa rimettevo in pausa anche lei: le carte si mescolavano in silenzio. Da zittire c'è una cosa sola, ed è il nodo Music del quartiere.
  • ⚠️ La musica del tunnel adesso CONTINUA sullo shuffle e si spegne alla risalita, mentre parte quella della città. È la lettura giusta di «nel frattempo deve fermarsi quella del bonus»: le due non si accavallano mai, ma il silenzio sulle carte non era voluto.
  • 📌 Il controllo che mancava alla sonda l'ho aggiunto adesso, ed è quello che avrebbe evitato il giro: i lettori dentro la schermata delle carte non devono risultare in pausa. Era un difetto udibile e invisibile ai numeri — nessuna sonda guardava i suoi lettori, e a sentirlo è stato Ivan.
  • ⚠️ E il provino ne ha trovato un altro, latente: rientrando nel tunnel mentre il lettore precedente sfuma, il livello nuovo adottava il lettore in agonia e partiva a metà volume (misurato: −25,4 dB invece di 0). Nel gioco vero fra due bonus passano minuti, nel provino tre secondi. Ora il lettore che muore viene rinominato, così avvia_musica() non può più riadottarlo.
  • Verificato: shot_su489_transizione 14 controlli, 0 KO — durante lo shuffle il tunnel è a 0,0 dB e playing, Music della città in pausa, nessun lettore della cerimonia zittito.

Sulla carta non suona niente: il tunnel tace e la città aspetta la galleria2026-08-22

• [fix] Durante la cerimonia delle carte il tunnel ammutolisce, e la musica della città torna solo col viaggio. Ivan: «la musica di livello deve ripartire solo durante la transizione in superficie e non durante la carta, e nel frattempo deve fermarsi quella del bonus stage». Adesso la sequenza sonora è: musica del tunnel per tutto il livello → silenzio quando si apre la carta (sfuma in 0,25 s: la cerimonia ha i suoi suoni, e sotto una musica che continua sembrerebbe che il livello non sia finito) → musica del quartiere sotto la galleria, a schermo coperto.
  • ⚠️ Non bastava lasciarla in pausa: la schermata delle carte lavora ATTIVAMENTE per farla suonare. SU-100 le ha insegnato a cercare il nodo Music del mondo e a mettergli PROCESS_MODE_ALWAYS, così il ventaglio non si apre nel silenzio quando l'albero è in pausa. Giusto in superficie, sbagliato quaggiù. Il tunnel adesso, per ogni fotogramma dell'attesa, rimette in pausa quello che trova acceso — la città torna a suonare quando torna la città.
  • ⚠️ E il primo controllo che avevo scritto dava un KO che non esisteva: guardava «tutti i lettori della città in pausa», e falliva già prima della carta, perché nella città ci sono lettori fermi che nessuno ha mai messo in pausa (stream_paused su un lettore spento non vuol dire niente). Il controllo giusto è sul nodo Music — che è poi l'unico che la schermata va a cercare.
  • Verificato nel provino con finestra (le sonde headless saltano la cerimonia, quindi questo ramo non lo esercita nessuna di loro): prima della carta il tunnel suona e Music è in pausa; all'apertura della carta il lettore del tunnel è a −39,6 dB e la cerimonia risulta aperta; durante la carta Music è ancora in pausa. shot_su489_transizione sale a 13 controlli, 0 KO.

Le carte si vincono nel tunnel, e il treno scintilla2026-08-22

• [change] Le carte premio si prendono ALLA FINE DEL BONUS, dopo la pioggia — non più risaliti in superficie. Ivan: «anche le carte premio le metterei alla fine del bonus stage, dopo la pioggia di monete, così quando finisce tutto dissolvenza del tunnel e si ritorna subito in superficie». L'ordine adesso è: conto → pioggia → carte → viaggio → città.
  • ⚠️ La schermata delle carte va RIACCESA a mano: è figlia dell'HUD, e l'HUD è uno dei CanvasLayer che il congelamento spegne quando si scende. Senza, la cerimonia si sarebbe aperta invisibile — il gioco fermo ad aspettare una scelta su una schermata che non c'è. (È il rovescio della medaglia della correzione di ieri sui CanvasLayer annidati: adesso li spegniamo *tutti*, quindi chi ne vuole uno acceso deve dirlo.)
  • ⚠️ Il livello passa a PROCESS_MODE_ALWAYS mentre aspetta: la cerimonia mette in pausa l'albero, e un livello in pausa non potrebbe nemmeno accorgersi che la schermata si è chiusa. E c'è una finestra di grazia di 0,8 s prima di credere che sia finita: la schermata si apre il fotogramma DOPO la consegna, quindi chiedere subito «è chiusa?» avrebbe risposto sì, e il tunnel sarebbe risalito portandosi via la cerimonia appena nata.
  • ⚠️ E LE SONDE NON DEVONO ASPETTARLA. Questa riga è costata un'ora di caccia. La schermata si apre anche sotto sonda (la scena Main ha l'HUD, quindi il ripiego «niente schermata» non scatta) e lì dentro nessuno prende mai la carta: il tunnel restava aperto per sempre, bonus_level_active non tornava false e il giro successivo veniva rifiutato in silenzio. La sonda lo raccontava così: «l'oracolo arriva alla banchina — osservato: fase 3 dopo 0,0 s», cioè stava misurando il livello VECCHIO, ancora appeso. Diagnosi fatta spegnendo un pezzo per volta (velocità, scintille, carte) invece che a intuito.
  • Resta una rete: se un domani si esce dal tunnel senza passare dal conto, il premio viene consegnato come prima (nodo staccato e appeso alla città). Nel giro normale non scatta.
• [change] Anche l'ANDATA passa dalla galleria: la dissolvenza a blocchi non si usa più per scendere. Ivan: «la dissolvenza iniziale del bonus stage non facciamola pixellata ma sempre con l'effetto tunnel». Andata e ritorno sono lo stesso viaggio — che poi è quello che succede davvero: si prende la metro per scendere e la si riprende per risalire. PixelWipe resta come ripiego se la città non sa viaggiare.
  • ⚠️ In headless metro_ride adesso salta l'effetto ed esegue subito, come già faceva PixelWipe: senza schermo non c'è niente da coprire, e l'unico effetto rimasto sarebbe stato quello collaterale — il livello che nasce un secondo e mezzo dopo la chiamata. Prezzo pagato subito da probe_collaudo_bancametro («impossibile proseguire»).
• [feat] Le ruote del treno scintillano sulle rotaie. Ivan: «metropolitana scintille pixellate puntinate piccole sulle ruote del treno come se scintillasse sui binari». Puntini di 3×3 px che nascono al bordo inferiore del vagone, schizzano all'indietro e si spengono in ~0,24 s. ⚠️ Restano sul binario invece di viaggiare col treno: attaccarle al vagone le avrebbe fatte correre con lui, che è l'effetto opposto di una scintilla.
  • ⚠️ Tre tarature, tutte decise guardando lo scatto e non a intuito. (1) Erano a z −5, cioè dietro un vagone opaco: invisibili. (2) Nascevano a caso lungo tutto il convoglio e sembravano briciole sul pavimento: adesso escono dai carrelli (dieci posizioni prese dallo sprite). (3) Il provino ne contava 166 vive quasi tutte fuori quadro, perché i treni nascono 1.568 px fuori campo e per il codice sono «visibili» tutto il tempo: ora ne fa solo chi è entro 900 px dalla camera.
• [change] Il treno passa più veloce: da 420 a 560 px/s. Chiesto da Ivan. Vale ancora il ragionamento di SU-488: la finestra di reazione non cambia, perché il treno nasce alla distanza da cui arriva fra PREAVVISO_TOT secondi (a 560 nasce 1.568 px fuori campo invece di 1.176). Quello che cambia è il transito: 504 px in 0,90 s invece di 1,20, quindi la corsia si libera prima e l'intervallo minimo ha più margine di prima. Misurato dopo: finestra 1,556 s (minimo 1,50), margine sul tempo limite 11,5-12,0 s.
• Verificato: compile-check verde su tre file; probe_su491 verde salvo il rosso del 92% sospeso da Ivan; probe_su489_suoni 17/0; probe_su489_congelamento 5/0; shot_su489_transizione 9/0; giro completo banca→bonus→risalita verde; scatti guardati, scintille comprese (ritaglio ingrandito per contarle a occhio).

Il tunnel ha un finale: il conto, la pioggia, e si risale in galleria2026-08-22

• [feat] Il livello bonus finisce con quello che hai portato a casa, e si torna su col viaggio della metro. Ivan: «finale livello bonus, in centro il numero di soldi guadagnati nel livello bonus e di lattine, con pioggia di entrambi i guadagni (esattamente il numero raccolto) poi per tornare al livello normale transizione come quando cambi fermata di metro con la galleria e si riprende».
  • Il conto è fatto di cifre e di oggetti veri, senza una parola: la moneta con $131, la lattina con ×7. ⚠️ Non è pigrizia — il gioco parla otto lingue, e un conto senza testo si legge uguale in tutte senza aggiungere una chiave ai CSV. Le icone sono le stesse texture che si raccolgono, non simboli disegnati apposta.
  • La pioggia è ESATTAMENTE il bottino: una goccia per moneta e una per lattina, mescolate. Non è una densità decorativa: chi porta a casa 131 monete vede un acquazzone, chi ne porta 12 ne conta dodici. Il ritmo si ricava dal totale (tutto nasce entro 1,9 s), così il numero resta quello vero anche quando è grosso.
  • Il ritorno è il viaggio della metro (World.metro_ride), lo stesso del cambio fermata: il vagone entra, la galleria sfila, e sotto la galleria — a schermo coperto — avviene la risalita vera. ⚠️ I blocchi restano all'andata, ed è una distinzione voluta: scendere nel tunnel è uno stacco secco, tornare è un viaggio.
  • ⚠️ metro_ride NON funzionava così com'era, e il motivo è sottile: vive sulla città, che quando il bonus la chiama è congelata — i suoi tween non avanzano di un pixel e l'effetto sembrerebbe «non partito». Adesso accetta un motore (il nodo che crea i tween e ospita il velo) e il livello gli passa la radice. Nessun cambiamento per il cambio fermata, che continua a passare da sé.
  • ⚠️ I numeri del conto si leggono PRIMA della risalita, non dopo: _risali_ora() stacca il nodo dei premi e lo regala alla città (serve a consegnare le carte a scena morta), quindi chiedergli il bottino più tardi darebbe zero senza un errore.
  • ⚠️ Un errore vero trovato dal provino: «Lambda capture at index 0 was freed». Il callback di fine volo dell'oggetto raccolto catturava lo sprite; se qualcuno lo libera prima che il volo finisca, Godot lo segnala prima di entrare nel corpo — quindi nessun is_instance_valid dentro può evitarlo (era il primo tentativo, e non bastava). Adesso si cattura l'id e il nodo si ritrova solo se è ancora vivo.
  • 📌 Due lezioni sui provini, scritte dove servono. Il conto si scatta mentre piove (le gocce nascono nei primi 1,9 s di 3,6: uno scatto tardivo mostrerebbe un cielo vuoto e sembrerebbe un difetto), e i totali si leggono dopo i 30 secondi della banchina — al primo giro il provino confrontava il pannello ($131, giusto) con un totale letto mezzo minuto prima ($59), cioè segnalava solo che la misura era presa nel momento sbagliato. Nello stesso giro il provino cercava ancora gli oggetti in volo a z 5 dopo che erano passati a 10: adesso lo chiede al codice invece di riscriverlo.
  • Verificato: shot_su489_treno — conto ["$131", "×7"] uguale al bottino vero, 74 gocce in aria al momento dello scatto; shot_su489_transizione 9 controlli 0 KO (la risalita nasce un solo velo «ViaggioMetro», richiamarla non ne fa un secondo, il livello si libera a fine viaggio); probe_su489_suoni 17/0, probe_su489_congelamento 5/0, giro completo banca→bonus→risalita verde. Resta il solo rosso del 92%, sospeso su richiesta di Ivan.

Un tester esce dagli invii ma resta in elenco2026-08-21

• [chore] Davide Defedele fuori da ogni messaggio, riga intatta. Richiesta di Ivan: niente più annunci né avvisi di nessun tipo, ma la persona resta nell'Excel perché per ora è attiva su Apple/TestFlight. Avvisa tester da Sì a — alla riga 12 (ID 10), che è l'interruttore per riga letto da tools/release/genera_link_messaggi.py; Link WhatsApp e Link Telegram svuotati insieme al flag, sennò in colonna resterebbe il link cliccabile che manderebbe l'annuncio lo stesso. Motivo scritto in Note, così la riga si spiega da sola alla prossima sessione. Backup in Beta_Tester_Homeless_City.BACKUP-2026-08-21-pre-defedele.xlsx.
  • 📌 Un interruttore solo basta perché gli invii sono due, e il secondo lo esclude già. Gli annunci di versione (/avvisa-tester) passano da Avvisa tester; il messaggio di reclutamento (BETATESTING/messaggi_beta.py --elenco) pesca solo chi ha Stato Inserito, e lui è Invitato da luglio. Stato e piattaforme non toccati: servono a dire che la sua build Apple è viva, e cambiarli lo farebbe sparire dai conti dei tester attivi.
  • Verificato con il filtro vero dello script e non a occhio: vuole_avviso('—') → False. Con lui gli esclusi sono 7 (Defedele, A. Lagna, Dellavalle, Izurieta, Cerutti, Rapalino, Peyrachia).
  • ⚠️ La cartella BETATESTING/ è gitignorata: il file cambiato non entra in nessun commit, e questa voce è l'unica traccia tracciata della modifica.

Sei ticket tornati indietro senza un KO: mancava una decisione, non il codice2026-08-21

• [fix] SU-503 — la board di prova che il codice denunciava da solo a ogni avvio. BOARD_PROVA_CENTRO torna a "": finché non lo era, il quartiere CENTRO — quello dove si gioca quasi sempre — leggeva e scriveva su SU_TEST_CENTRO, cioè i punteggi veri dei giocatori non finivano nella classifica vera. ⚠️ Non è stata una scoperta: il push_warning lo urlava a ogni accensione ed era stato visto due volte durante lo Sprint 10 e archiviato come rumore noto — la prima da me in un log di compile-check, la seconda dal collaudo sull'Honor, che stavolta l'ha misurato invece di ignorarlo. È il difetto che non fa fallire niente e per questo sopravvive ai collaudi.
  • Il meccanismo di deviazione resta, spento e leggibile, con la nota di cosa è successo: cancellarlo avrebbe tolto anche il modo di rideviare la board in un collaudo futuro.
  • Punteggi già finiti su SU_TEST_CENTRO: abbandonati, non travasati. Erano prove e collaudo, non partite di giocatori; e in EOS i punteggi seguono il nome della stat, quindi cancellare e ricreare la definizione non svuota niente — travasarli avrebbe richiesto uno svuotamento per PUID o una board nuova, lavoro vero per dati che non contano nulla. Verificato che l'abbandono non lascia strascichi: SU_TEST_CENTRO non compare in nessun percorso raggiungibile, e l'unico file in user:// scritto da OnlineLeaderboard è moderazione.cfg (nomi segnalati, non punteggi).
  • Provato nei due versi, che è l'unica forma che vale qui: rimessa la costante piena → banner [BOARD DI PROVA] + warning + 8 controlli KO nella sonda; rimessa vuota → zero banner, esito OK. Un output pulito da solo non avrebbe provato niente. Sonda nuova probe_su503_board.gd: segue entrambe le strade del gioco — current_board() (scrittura di fine partita) e board_for() (lettura del selettore) — e dimostra che tornano lo stesso id, invece di dedurlo dal fatto che il punto è uno solo.
• [change] SU-514 — ACCOUNT torna nel menu principale col corpo delle Opzioni, e il pannello non si è allargato di un pixel. Cambio di idea di Ivan rispetto a SU-456, con un motivo che regge: «la prossima versione di test è importante per l'online», quindi il problema non è più *dove la cerca chi la cerca* ma farla vedere a chi non la sta cercando.
  • ⚠️ Il vincolo arrivato a lavoro già partito, e ha ribaltato il piano: «non devi allargarlo quello del main, al massimo alzarlo». L'opzione che il ticket dava per preferibile — allargare il pannello come SU-496 fece per le Opzioni — è caduta: panel_x = 0.58 e panel_w = 0.36 sono intatti, il disegno del barbone non è coperto.
  • E il corpo pieno si è raggiunto lo stesso, senza ripiego. Speso solo ciò che restava dentro i bordi: il margine interno (label da 0.10/0.84 a 0.07/0.89, +19 px di riga utile) e l'altezza (tetto da 0.84 a 0.88; 0.08 + 0.88 + 0.04 = 1.00 esatto, cioè non avanza più niente). Risultato misurato: corpo del menu da 30 a 35 su telefono e 34 su desktop, contro il menu radice delle Opzioni che vale 35/34 — il 100%, non «più grande».
  • _fit_menu_label() non interviene su nessuna voce, in nessuna delle 8 lingue, in nessuno dei tre formati e in entrambi gli stati di login. Era il criterio che poteva far fallire il ticket: una riga più piccola delle vicine si nota, ed è il difetto per cui SU-431 accorciò «ENTRA COL TUO ACCOUNT». Il corpo ora è uno solo per tutte le righe (_corpo_voci_menu() lo chiede a OptionsPanel.opt_font_voci() e lo tira indietro con opt_font_che_entra() sulle stringhe tradotte): o si stringono insieme o non si stringe nessuna. Collo di bottiglia misurato: spagnolo, «SALIR DEL JUEGO» 328 px su 336 di label.
  • Due sorprese trovate strada facendo. (1) La sesta voce faceva scorrere la lista col passo di prima (contenuto 549 contro pannello 496): ora row_h si stringe se non ci sta, come già fa opt_row_factor nelle Opzioni. (2) ⚠️ La prima controprova non funzionava, e in silenzio: dimezzare lbl.size.x non fa niente, perché Control.set_size() risale a get_combined_minimum_size() e la minima di una Label è il suo testo. Sostituita gonfiando il corpo nominale — e lì la sonda fallisce come deve.
  • La voce resta ANCHE in Opzioni, ed è una scelta: la motivazione di SU-456 («chi cerca dove cambio il nome guarda in Opzioni») non è sbagliata, è diventata secondaria. Tenerla in due posti soddisfa entrambe; toglierla da una butterebbe via una decisione senza guadagnarci.
  • Il testo è il sostantivo, non il verbo: ACCOUNT / ACCOUNT / COMPTE / CUENTA / KONTO / АККАУНТ / 账号 / CONTA, coerente con le schermate dell'account che già dicevano «IL TUO ACCOUNT». Da loggati la voce diventa MENU_VOCE_ACCOUNT_DENTRO anche nel menu principale, come già faceva in Opzioni.
  • NON PROVATO: nessun device reale (solo finestra su Mac); demo e web non fatti girare. ⚠️ In demo «SCARICA IL GIOCO COMPLETO» resta l'unica voce che si rimpicciolisce da sé — comportamento di prima, non una regressione, ma ora si nota di più perché le vicine sono cresciute.
• [test] Collaudo d'onda sui cinque lotti: nessuna regressione, e un difetto vecchio di una settimana venuto a galla. Compile-check completo 406 script / 87 scene / FALLITI 0, audit emoji 0. A/B sul riscaldamento shader in finestra: 6/14 freddi contro 0/14, avvio 2017,5 contro 1989,6 ms. Retata vera a schermo con la vignetta rifatta: 7 scatti ispezionati uno per uno, zero SHADER ERROR. ui_menu.csv 450×9 integro (verificato col modulo csv, non con awk, che si confonde sulle virgolette). JSONL della telemetria 82/82 righe valide.
  • ⚠️ Aperto SU-513 — RunRecorder.gd:1346 perde oggetti a OGNI chiusura di run (Unable to start the timer…, ObjectDB instances leaked at exit, 2 resources still in use). git blame: 2026-08-14, quindi una settimana di vita e almeno tre collaudi passati sotto. Non è una regressione di oggi, ma diventa scomodo adesso: è lo stesso file dove SU-504 ha appena costruito, ed è rumore costante nel log, cioè la condizione perfetta perché il prossimo leak vero non lo noti nessuno. Stessa famiglia di SU-503, che oggi si è chiuso per lo stesso motivo.
• [test] SU-492 e SU-491 (2º giro) — nessuna riga di gioco cambiata: quello che mancava a entrambi era la prova, non la feature. Erano rientrati in «Da fare» senza KO, e i miei report di ieri finivano tutti e due con un NON PROVATO: quello era il ticket rimasto.
  • SU-492 — il ritmo del 3-2-1, «che va sentito». probe_su492_ritmo.gd fa girare il _process() vero, un frame headless alla volta (non un debug_passo a delta fisso, che avrebbe confermato solo la formula). Linea del tempo: spiegazione a t=0 → «3» a 2,93 s → «2» a 3,63 s → «1» a 4,33 s → «VIA!» a 5,03 s → controllo al giocatore a 5,58 s. Sequenza esatta, nessuna cifra doppia o saltata. Striscia di 41 PNG a 150 ms in TMP/su492_ritmo/.
  • ⚠️ Un falso allarme che vale la pena raccontare, perché la trappola si ripresenterà. Misurando i PNG della striscia la cifra risultava 9,0% dell'altezza schermo (35 px su 390) — piccola per un conto alla rovescia «stile arcade», e INTRO_POP_SCALA = 2.2 sembrava una costante che non arrivava a schermo. Rimisurato a cadenza fine (~17 ms): il pop c'è ed è pieno — picco 80×60 px = 20,5% dell'altezza, che rientra al 9,5% di riposo entro ~260 ms (la formula ne prevede 269,5). La griglia a 150 ms aveva pescato entrambe le cifre 500-650 ms dopo la nascita, cioè sempre nella fase piatta. Nessun difetto, BonusLevel.gd non toccato.
    • E dentro la rimisura, una seconda trappola: il primo riferimento per il diff era un fotogramma preso prima che il titolo «SOTTO LA CITTÀ» si spegnesse, e la bbox univa lo sparire del titolo alla cifra dando 166 px. Il riferimento va preso a titolo già spento.
  • SU-491 — la forbice della raccolta, ed è il numero che poteva smontare il conto economico di ieri. Il report del 21/08 dichiarava «il 90% è irraggiungibile a mano», quindi il +$80 del primo giro poggiava su un caso forse impossibile. Misurato il tetto fisico con un oracolo goloso (visibilità piena, zero ritardo): 180/200 (90,0%), e l'oracolo è in movimento il 97% dei 30 s — idle 0,78 s. Il collo di bottiglia è la velocità contro la larghezza della banchina, non la mano. Il verdetto di ieri regge, ora misurato invece che ipotizzato.
    • Conto sui tre giri, al tetto fisico: $100 → 180/200 → +$80 · $200 → 184/200 → −$16 · $400 → 181/200 → −$219. ⚠️ Dal secondo giro il tunnel è in perdita anche nel migliore caso possibile.
    • Il giro completo banca → metro → bonus → ritorno passa da probe_collaudo_bancametro.gd (che entra dallo sportello vero, non chiamando entra() a mano): OK su tutti i passaggi, cerimonia delle carte compresa. Aggiunto il pezzo che mancava — il giocatore resta dov'era: posizione invariata sui tre giri, e BonusLevel/BonusRewards non referenziano mai il Player.
  • 📌 Restano due decisioni di Ivan, non toccate di proposito: i 5,58 s di attesa fissa a ogni ingresso nel bonus (anche rigiocato) si accorciano? E le 200 monete restano così, sapendo che solo il primo giro è in attivo — e che fine fa la tabella d'oro chest_gold?
• [feat] SU-484 (2º giro) — gli shader si riscaldano al caricamento, e il difetto era più grosso di quanto il cronometro potesse dire. Ieri il ticket era stato chiuso con «niente implementato»: risposta onesta, ma la strada era già individuata e mancava solo percorrerla.
  • ⚠️ Il cronometro qui è cieco, ed è il motivo per cui il primo giro non aveva concluso niente: un frame che compila una pipeline dura quanto uno che non ne compila (5,2 contro 5,2 ms; 7,0 contro 7,0). Lo strumento giusto esiste da Godot 4.4 e risponde sì/no invece che in millisecondi: RenderingServer.get_rendering_info(RENDERING_INFO_PIPELINE_COMPILATIONS_CANVAS), cumulativo.
  • IL NUMERO CHE DECIDE, e non era noto: senza riscaldamento 5 shader su 14 sono ancora FREDDI al primo uso in partita — e *quali* cambia da run a run. Col riscaldamento: 0 su 14, su tre giri. Il difetto non era nemmeno stabile, il che spiega perché uno scatto «a volte» c'è e a volte no.
  • Tre misure hanno deciso il disegno, tutte col contatore e tutte controintuitive: (1) creare il materiale non compila niente; (2) una copia non riscalda l'originale — uno Shader.new() con codice identico compila una pipeline *nuova*, mentre lo stesso oggetto Shader in un materiale diverso fa +0: conta l'oggetto, non il materiale; (3) ⚠️ un ColorRect ad alpha 0 non compila niente, quindi un riscaldamento «invisibile» sarebbe stato esattamente la verifica-a-vuoto che si voleva evitare. I quadratini sono 1×1 px veri, per due frame.
  • Costo all'avvio: dentro il rumore. Sei giri alternati a cache azzerata: _ready 326-397 ms identico; primi 10 frame 774/776/817 ms a freddo contro 752/800 a caldo, quando all'avvio ci sono già picchi da 270-590 ms. Pipeline totali 19 contro 18-19: il lavoro è spostato, non aggiunto. Interruttore World.riscalda_shader per rimisurare in un attimo.
  • Due cose trovate strada facendo, che nessuno cercava: HUD._raid_warning_pulse() fabbricava uno Shader nuovo col solito testo a ogni chiamata — cioè una compilazione in più proprio al preavviso della retata, il momento peggiore; ora riusa l'oggetto. E senza guardia headless il riscaldamento lasciava 14 RID DummyShader leaked at exit (in headless frame_post_draw non arriva mai).
  • Scartata, e il perché resta scritto: spostare le 13 costanti in file .gdshader per lo Shader Baker dell'export — alto rischio, tre file grossi toccati, e verificabile solo sulla piattaforma che non abbiamo. Il Baker resta comunque inutile qui: 13 shader su 14 nascono da stringhe a runtime, e una stringa non è una risorsa.
  • NON PROVATO: iPhone e iPad, cioè le piattaforme del ticket — nessun device, simulatori bloccati. Tutti i numeri sono macOS/Metal. Su Android dovrebbe aiutare (stesso backend mobile) ma non è misurato; su macOS è indifferente; siccome all'avvio è gratis, si tiene acceso ovunque.
• [feat] SU-504 — lo strumento perduto non si riscrive: la misura entra nella scatola nera. Il ticket chiedeva di decidere PRIMA di scrivere codice se la telemetria coprisse già il caso. Verificato: non copre, ma è a un passo — RunRecorder.gd registra avg_fps (frame *contati* sulla finestra di 2 s, r.650-658), cioè esattamente la grandezza che il ticket vieta, quella cappata dal compositore che in questo progetto ha già mentito (119,6 contro 347 nello stesso giro).
  • Sei campi nuovi accanto ad avg_fps, che NON è stato tolto (c'è un commento KO di Ivan su SU-242 che lo giustifica): ft_p50, ft_p95, ft_p99, ft_max, ft_over, ft_n. Da Time.get_ticks_usec() reale, mai da delta — col bot Engine.time_scale lo altera e un campionamento «ogni 2 secondi» finirebbe a 20 Hz senza dirlo (trappola già scritta nel file, r.138-139).
  • La media nasconde proprio ciò che si cercava, e la sonda lo mostra in una riga: avg_fps=145,1 (cioè 6,9 ms) con ft_p99=10,2 e ft_max=16,8. Costo della misura: 0,096 µs/frame più 16,9 µs una tantum a fine finestra.
  • Perché dentro il gioco e non uno script adb. dumpsys SurfaceFlinger --latency è proprio il meccanismo che si è rotto (5 campioni su 128 slot in 32 s: la composizione passa a HWC diretto e bypassa la cronologia). Dentro il gioco la misura non dipende da quello, funziona su qualunque device senza cavo, si accende col file-sentinella REC_ON di SU-414 — l'unica via che su Android funziona — e i campioni hanno già timestamp e quartiere, quindi la deriva termica si legge nella serie invece di doverla appaiare a mano.
  • Il pezzo lato Mac esiste ed è committato, che era il criterio: tools/android/misura_tempo_frame.sh (+.py) scarica i JSONL e stampa la tabella A-B-A, o la serie finestra-per-finestra con --serie. Documentato in tools/autotest/README.md, col perché non si torna a SurfaceFlinger.
  • ⚠️ LIMITE VERO, e non è più dedotto: run-as: package not debuggable. Durante il lavoro un Honor 10 era collegato; lanciato solo il passo di sola lettura (nessuna scrittura, nessun install, nessuna sentinella), il pull dal device ha risposto così. Il travaso locale via adb richiede una build --export-debug: su una release firmata i dati escono solo per la via del consenso, non dal cavo.
  • 📌 Domanda chiusa senza girarla a Ivan: i sei campi nuovi NON obbligano a rifare i moduli degli store. BETATESTING/DICHIARAZIONI_STORE_TELEMETRIA.md (§ correzione a 1.2/2.1) dice che da quando SU-242 ha messo avg_fps nei pos la voce Diagnostics è già dichiarata su entrambi — e la voce di Play cita testualmente il *framerate*, quella di Apple è *Performance Data*. I percentili sono la stessa categoria: nessuna casella nuova da spuntare.
  • NON PROVATO: il numero che il ticket chiede per primo — tempo di frame sull'Honor con NPC_DENSITY_MULT a 1.5 contro 1.0. Serve il telefono e una build debug; il comando è nel README.
• [fix] SU-502 — il buttafuori non era una frase scelta, era il ripiego: sette codici che sapevamo prevedere ci finivano dentro. Ivan su iPhone: «il login con epic mi da il buttafuori bla bla bla e non va, quello apple si».
  • Diagnosi: ipotesi A, e decisa senza device. Su platform_override="iOS": available_providers() = ["apple","epic"], provider_offered("epic")=true, motivo vuoto → la tabella PROVIDER_PLATFORMS rifatta ieri non mura Epic, quindi non è una nostra regressione del 21/08. _eos_code_from_result() con result 14 (NotConfigured, misurato da SU-449 su iPhone) produce eos_login_failed, che nel match non aveva un ramo.
  • ⚠️ La prova più forte non è quella che il ticket suggeriva, ed è indipendente dal device: provider_not_offered e link_not_supported hanno già una frase loro. Se fosse stata l'ipotesi B, Ivan avrebbe letto «Da questo aggeggio non si entra con EPIC» — il messaggio che ha visto è esso stesso il discriminante. Non serviva la Console di macOS.
  • Causa strutturale, non configurazione mancante: il portale account dell'SDK su iOS vuole un presentation context di sistema (UIViewController in SystemSpecificOptions), e nel GDScript dell'addon non compare né presentation né IOSOptions. Quel ramo non è mai esistito.
  • Codici previsti che cadevano nel ripiego generico: 7 → 0. Tre rami nuovi (eos_login_failed, native_error/epic_web_refused, bad_arguments/provider_unknown) e due allargati; ogni frase dice cosa fare, non solo che è andata male. Il buttafuori resta, e sopra ha scritto che è per l'ignoto: se un codice noto ci ricasca, probe_su502_epic_ios.gd fallisce apposta (exit 5 prima, 0 dopo).
  • Epic su iOS entra da EOS Connect come credenziale esterna, scelto per piattaforma e non sostituito per tutti: EPIC_WEB_PLATFORMS = ["iOS"], su desktop _login_epic() col portale resta intatto (cred_type < 0), Android resta sul portale finché nessuno lo misura rotto. ⚠️ Client secret invece di PKCE, all'opposto di SU-449, e il motivo è scritto nel codice: il client Epic è confidenziale e il secret è già nel pacchetto perché EOS_Platform_Create lo pretende — non si aggiunge nessun segreto nuovo, si riusa quello che c'è.
  • NON PROVATO, ed è tutto ciò che manca: il login Epic vero su iPhone. Da qui non si vedono le due risposte di Epic (che accetti il redirect con schema personalizzato, e che il token endpoint restituisca id_token). Il codice le prevede entrambe e fallisce con un codice proprio — epic_web_no_id_token, epic_web_refused — mai col buttafuori.
  • ⚠️ SECONDA CORREZIONE, dal primo tentativo su iPhone vero: result=10, e la distinzione è tutta la diagnosi. Ivan ha provato: la pagina di Epic si è aperta, il login è andato, il redirect è tornato nel gioco — cioè tre pezzi su quattro funzionano e lo schema eos.<client_id> viene riconosciuto da iOS. Poi EOS ha risposto 10 = InvalidParameters, e *non* InvalidCredentials (2): EOS non aveva giudicato e respinto il token, aveva rifiutato la chiamata come malformata.
    • L'unico parametro che Apple e Google hanno e che Epic non può avere era user_login_info. Lo passavamo a *tutte* le credenziali esterne; l'SDK lo ammette solo per i tipi il cui token non porta un nome — e per Epic il nome lo sa EOS, arriva DOPO il login (è scritto da SU-443 tre funzioni più in là). Ora CRED_TYPES_CON_NOME elenca i tipi che lo vogliono (9, 10, 11, 12, 13, 17) e Epic (16) non è fra questi. ⚠️ È una lista di tipi, non di provider: chi aggiunge un canale nuovo senza guardarla farà ricomparire il result=10 in un punto che sembra non c'entrare.
    • Scartate per strada, e senza disturbare Ivan: che Epic andasse registrato negli *Identity Providers* — non si può nemmeno, non è nell'elenco (Amazon, Apple, Discord, GOG, Google, itch.io, Nintendo, Oculus, OpenID, PSN, Steam, Xbox Live), perché è nativo di EOS.
    • Perché il prossimo non debba più attaccare il cavo: result=10 da solo è costato un giro di Console a Ivan. Adesso il log stampa numero e nome (result=10 (InvalidParameters)) — con una ricerca nell'enum che su un numero ignoto risponde «sconosciuto» invece di restituire l'ultima chiave, che è quello che fa EOS.result_str() dell'addon indicizzando a −1. E InvalidParameters ha ora un codice suo, eos_bad_call, instradato sulla frase che già esisteva per gli errori nostri: «Questo ingresso l'abbiamo montato storto noi». Un errore che sappiamo prevedere non torna nel buttafuori.
    • ✅ CONFERMATO SU IPHONE VERO la sera stessa, parole di Ivan: «sono dentro! funziona!» L'ipotesi era giusta e il ticket si chiude sul suo criterio principale — *su iPhone reale, con Epic si entra*. Cade il NON PROVATO più vecchio della catena: SU-449 aveva misurato il difetto il 17/08 e da allora il ramo Epic su iOS non era mai stato costruito.
    • 📌 La lezione trasferibile, che vale oltre questo ticket (ed è finita in memoria): InvalidParameters (10) non è InvalidCredentials (2). Il 10 dice che EOS ha rifiutato la *chiamata*, non che ha giudicato il token — quindi non si cerca il difetto nel token, nel portale o nei permessi, si cerca un campo di troppo o mancante nelle opzioni. Il modo che ha funzionato: chiedersi *quale parametro hanno i canali che funzionano e non può avere quello che non funziona*.
  • ⚠️ CORRETTO LA SERA STESSA, dopo essere andati a guardare il Dev Portal davvero: i «due gesti per Ivan» non esistono, ed erano sbagliati tutti e due.
    • Il redirect non lo scegliamo noi. Avevo scritto streetuni://epic/auth — lo schema che l'app usa già per Apple e Google — dando per scontato di poterlo registrare fra le Redirect URL del client. Il portale lo rifiuta: quel campo pretende un URL vero, risponde «Should be valid URL» e tiene spento il salvataggio. Il motivo è che Epic lo schema personalizzato te lo assegna già lui, in un campo accanto — «Custom Schema URL», in *Product Settings → Clients → (client) → Edit*, sezione EPIC ACCOUNT SERVICE — nella forma eos.<client_id>://epic/auth. Non va registrato: c'era già, dall'inizio.
    • openid non è un interruttore. I permessi dell'applicazione sono quattro — Basic Profile (sempre attivo e obbligatorio), Online Presence, Friends, Country — e openid non è fra questi: è uno scope OIDC standard, non qualcosa che si possa aver dimenticato spento.
    • Quindi il lavoro era dalla nostra parte, non nel portale. epic_redirect_uri() ora costruisce il redirect dal client_id invece di tenerne una copia scritta a mano: sono la stessa cosa, e due copie della stessa cosa divergono. export_presets.cfg dichiara lo schema eos.<client_id> accanto a streetuni, che resta perché serve davvero a NativeAuth per Apple e Google.
    • ⚠️ L'unico accoppiamento che non si aggiorna da solo è l'Info.plist, che è una stringa statica: se il client_id cambia, il redirect segue e l'Info.plist no — Epic rimanda al telefono, iOS non riconosce lo schema e non apre niente, senza un errore che dica perché. Per questo probe_su502_epic_ios.gd adesso confronta lo schema del redirect con CFBundleURLSchemes. Provato nei due versi: tolto lo schema → KO, rimesso → OK.
    • 📌 Resta un solo NON PROVATO al posto di due: che il token endpoint restituisca davvero l'id_token. Che Epic accetti un redirect con schema personalizzato non è più un'incognita — lo accetta perché è lui ad assegnarlo.
• [docs] SU-470 e SU-471 — i due (DESIGN) si chiudono con gli otto ticket che ne discendono: SU-505 → SU-512. Erano rientrati in «Da fare» senza KO perché il documento c'era ma i ticket di implementazione no, e sono il deliverable che quei ticket chiedevano. Nati nel backlog, non nello sprint: la selezione è di Ivan.
  • Sulle sei domande aperte sono stati applicati i default già proposti nel documento, scritti sui ticket come decisioni tracciate e modificabili: nome di riserva col vocabolario del gioco (Scatolone_204), si dice che non si può usare l'handle ma non perché, il flag «nome di riserva» resta per sempre; il foglio Google e non la paginetta web, un «no» vale anche sui nomi già pubblicati, mail giornaliera solo a coda non vuota.
  • ⚠️ La dipendenza è scritta dentro i ticket e non è negoziabile: SU-508/510 non si cominciano prima di SU-505, perché un nome in revisione senza nome di riserva lascia il giocatore fuori dal multiplayer (GATE_NO_NAME) — che è esattamente il difetto che questa catena chiude.

L'arcobaleno attraversava la fermata DUE volte, e tre fette non bastavano2026-08-21

• [fix] SU-490 (2° giro) — erano due difetti, e il primo nascondeva il secondo. La foto di Ivan aveva smentito il fix precedente; questo giro li ha trovati entrambi, misurando in-engine invece di ragionare.
  1. Il rettangolo dell'occlusione non conteneva l'ultimo punto dell'arco. L'origine locale della fermata è il *punto d'uso*, 8 px più a sud del disegno: il rettangolo finiva a y=-8 e l'ultimo campione (y=0) ne restava fuori, quindi la ricerca del taglio non partiva nemmeno. Numeri del «prima»: fette 0-7 / 7-30 (z 3900, DAVANTI) / 30-32 — due soli campioni dietro. Ora il rettangolo si allunga fino alla porta.
  2. ⚠️ E qui la cosa che nessuna delle due indagini precedenti poteva indovinare: le fette non possono essere tre. Sul seme del provino la banca cade a piombo sotto la fermata (7 px di scarto su 574), e l'apertura delle gambe fa dell'arco un cappio che attraversa il disegno DUE volte — in discesa (campioni 25-32) e in salita (15-18). Nessuna scelta di due indici può nascondere due tratti separati. Ora si dà una quota a ogni punto e si emette una fetta per tratto: 0-7 / 7-14 / 14-20 dietro / 20-25 / 25-32 dietro.
     • Scartato (primo tentativo, e il perché è scritto nel codice così non si rifà): cercare il primo punto che entra nel rettangolo — prende il ramo di salita e nasconde metà arco.
     • Sul bidone d'oro il caso degenera nelle tre fette di sempre: verificato con probe_su249_arco.gd, identiche.
• [change] SU-485 (2° giro) — sulla mappa c'è l'arcobaleno VERO, e la fermata diventa d'oro. Il KO di Ivan chiedeva esattamente questo al posto dell'alone multicolore. _add_map_rainbow() riusa la spezzata già costruita in città e lo stesso RainbowArc.gd: stessa curva, stessi sette colori — non un secondo disegno che poi diverge. Lo spessore non si riscala (la carta rimpicciolisce ×3,7: sarebbe un capello). _metro_icon_oro() ridipinge map_metro.png in memoria, solo i pixel verdi → oro: niente shader (il compile-check non lo valida) e nessun asset nuovo. La classe _MetroBonusGlow è cancellata, non lasciata accanto.
• [feat] SU-486 — la metro nel verso opposto, come deciso da Ivan. Tocco = orario; 0,45 s tenuti = antiorario, stesso dollaro. L'effetto è l'animazione del viaggio al contrario (World.metro_ride(salto, verso), _MetroTunnel.verso): parete, costole e luci vanno dalla parte opposta. Nessuno sprite nuovo, come chiesto.
  • La finestra di hold si apre solo se il viaggio parte davvero: senza dollaro, in retata o davanti alla porta del bonus la risposta resta immediata.
  • _metro_hold_tick() distingue il rilascio vero da uno forzato (pausa, modale, _release_all_inputs()), che annulla.
  • Misurato: tocco corto → oraria, parte 20 ms dopo la pressione (5 ms dopo il rilascio: si risolve al rilascio, non alla soglia, che era la condizione su cui reggeva tutta la proposta); tenuto → 460 ms, fermata antioraria, $1 scalato; rilascio forzato → niente viaggio e niente biglietto.
• ⚠️ Trappola trovata, costata due giri della sonda, e vale per QUALSIASI provino che simuli pressioni: Input.action_press() marca il frame di processo corrente, e una coroutine risvegliata da create_timer() arriva dopo il _process dei nodi — la pressione non la vede nessuno e sembra che il gioco ignori il tasto. Ci si riallinea su process_frame e si concedono 3 frame.
• Non provato: l'hold col dito sul pulsante A, e il dito che scivola fuori dal pulsante (non rilascia: l'hold sopravvive, ed è voluto); il viaggio al contrario in movimento; la mappa aperta senza nessuna fermata accesa.
• 📌 Due domande per Ivan, in fondo al ticket: il verso opposto resta senza istruzioni a schermo — misurato, non temuto: aggiungendo «(tieni premuto: altro senso)» la scritta esce dallo schermo a metà parola a 1280×720, perché il prompt parte dal punto d'uso e va a destra, e alla fermata d'angolo la camera è già contro il limite di mappa. Lo si insegna con un big_notify una volta per run, o si scopre e basta? E: la fermata d'oro è sulla mappa (perimetro del ticket) — la vuole anche in città?

I due KO di resa: la freccia non era piccola, era il glifo2026-08-21

• [fix] SU-495 (2° giro) — le quattro cose del KO di Ivan, una per una. Il KO: «il tasto a sinistra per procedere è controproducente, tenerlo ma metterlo a destra e premere sul personaggio altra opzione per confermare. inoltre ingrandire le frecce».
  • GIOCA CON QUESTO passa a destra (x 77 → 639) e ← INDIETRO a sinistra — solo nel caso affiancato del telefono: tablet e desktop restano impilati agli stessi pixel.
  • Toccare il personaggio conferma: _skin_tap_lbl, la vetrinetta intera, 240×252, un gestore su gui_input.
  • ⚠️ E qui c'era l'errore del giro precedente, che spiega perché a Ivan le frecce sembravano identiche dopo averle già ingrandite una volta. Il corpo era legato a item_font, ma il glifo «◄» del font pixel disegna solo 0,36 × 0,61 del corpo (il commento vecchio diceva «poco più di metà»): cresceva la scatola e il triangolo restava di 21×30 unità. Ora il corpo lo detta la scatola: scatola 215×139 → 349×265, corpo 56 → 189, e il triangolo vero da 30×51 a 68×115 unità. La lezione è che si misura il glifo disegnato, non il font che gli si assegna.
• [fix] SU-493 (2° giro) — l'elastico non andava rifatto, andava SPOSTATO. Il KO: «ottimo l'effetto elastico, ma quando viene appoggiata sul mazzo di destra deve già fare una sorta di elastico e non fermarsi per poi ripartire».
  • Diagnosi prima del rimedio, e dice perché si vedeva «si ferma e riparte»: la carta arrivava sul mazzo a 0,15 px per frame — cioè già ferma — e ci restava 158 ms, 108 dei quali immobile. Non era la pausa (tolta al giro precedente): era il profilo del volo. TRANS_QUART/EASE_OUT finisce sempre a velocità zero, e con la quarta potenza gli ultimi 2 px si mangiano un quarto del volo.
  • Un'inversione di marcia ha per forza un istante fermo: non si toglie, si sposta. La carta non frena più *sul* mazzo — ci passa sopra ancora in corsa e si ferma un attimo oltre, dove il punto morto si legge come culmine di rimbalzo. Serviva una curva che finisse con velocità ≠ 0, e nessuna delle TRANS_* di Godot ce l'ha: il volo è un tween_method con una quarta potenza troncata al 62%.
  • Scartate: partire in EASE_IN (velocità continua ma la sosta aumenta: scivolerebbe via ancora più piano) e TRANS_BACK/EASE_OUT (scavalco proporzionale alla distanza, ~54 px non governabili).
  • Volo, elastico e rientro ora stanno sullo stesso tween: prima il secondo nasceva nella callback del primo, cioè un frame di buco proprio sul mazzo.

    	prima	dopo
    px nel frame in cui tocca il mazzo	0,15	2,17
    ms entro 3 px dal mazzo	158	18
    ms fermo fra mazzo e ripartenza	108	0
    dondolio oltre il mazzo	0,0 px	24,8 px
    rotazione sul mazzo	+0,00°	−4,08° (escursione −4,50 → +6,00)
    scavalco oltre il centro	46,0 px	46,0 px (intatto)
    durata totale	1051 ms	1061 ms

  • Le leve, se al playtest non basta ancora: FORCED_DRAW_WINNER_SKID_EASE (0,62 — più basso = arriva più veloce) e FORCED_DRAW_WINNER_SKID (26 px).
• Non regressione verificata: le misure delle altre otto schermate del provino SU-496 sono identiche riga per riga fra prima e dopo, su tutte e tre le forme.
• Non provato: il tap sul personaggio non è stato simulato — provato che il nodo è STOP e ha un gestore su gui_input, non che un dito lo faccia partire; e la resa dell'elastico è misurata, non vista in movimento.

SU-475 KO: non era la safe area, ed è per questo che si vedeva solo da lui2026-08-21

• [fix] SU-475 (2° giro) — il giornale di fine partita lasciava il giocatore BLOCCATO in partita, senza un solo pulsante. KO di Ivan: «dopo il titolo di giornale questo sparisce ma non compare la nuova schermata, non avendo nemmeno possibilità di uscire dalla partita». Solo sul suo iPhone 14 Pro; sull'iPad Air M1 no.
  • ⚠️ L'ipotesi con cui era partito il lotto era MIA, ed era sbagliata. Avevo indicato la safe area (Dynamic Island) come sospetto principale, perché era l'unica differenza nota fra i due apparecchi e nessun provino aveva mai messo gli inset diversi da zero. È stata smontata con una prova, non con un ragionamento: un esperimento a due variabili, una cosa cambiata per volta.

    Il giro B cade senza notch: la safe area è esclusa. La variabile vera è la classifica di casa vuota.

    giro	forma	inset	classifica di casa	esito prima del fix
    A	telefono 844×390	59/12/34/21	vuota (ospite)	KO — box a scala 0,000
    B	tablet 1024×768	zero	vuota (ospite)	KO identico
    C	telefono 844×390	59/12/34/21	piena	ok

  • La causa: _page_turn_arm() (HUD.gd:3317) lascia la GameOverBox a scale.x = 0 — invisibile — e l'unico punto che la riapre è _resize_gameover_box(). Il ramo del selettore delle iniziali non ci passa mai: _show_name_entry() non la chiama (lo dice il suo stesso commento a r.5297) e _online_show_board() esce subito quando c'è il selettore (r.4826). Risultato misurato: box a 0,000, menu RICOMINCIA/ESCI nascosto per scelta (compare dopo la conferma) e i tasti ▲▼/CONFERMA figli della box, quindi invisibili anche loro. Il giornale sparisce, non compare niente, non c'è un comando: parola per parola il KO.
  • 📌 Perché si vedeva solo da lui, ed è il corollario che conta più della spiegazione: in quel ramo ci si entra da ospite e solo se il punteggio entra nella classifica locale, che è roba di quel dispositivo. Su un'installazione fresca la classifica è vuota, quindi le prime cinque partite dopo l'installazione ci finiscono sempre — cioè esattamente quello che fa un beta tester appena installata la build. Non è un caso raro: è il caso di ingresso.
  • ⚠️ Perché il provino del 1° giro era verde: riempiva la classifica di casa apposta, «per mandare il pannello dritto al corpo definitivo, senza passare dalla schermata delle iniziali». L'unico ramo dove il difetto vive era escluso per costruzione. E chiamava _handle_press() a mano invece di premere davvero.
  • Rimedio in due tempi: il ramo delle iniziali fa partire il giro da sé (:5366), e una rete di sicurezza (_page_turn_rescue(), :3345) riapre la box e riaccende il menu se la presentazione si è fermata prima di _setup_gameover_menu(). Il KO non diceva «manca l'animazione», diceva «non ci sono i pulsanti»: il salvagente ripristina i comandi, non l'effetto.
  • Provato: ESITO=OK su quattro verdetti, PNG guardati uno per uno, e il provino originale resta verde (0,88 → 0,39, pagina 2 a 1,00) — l'animazione non è stata toccata. Le pressioni sono vere (Input.parse_input_event) con touch emulato: senza, su Mac gira il ramo desktop e i tasti CONFERMA non nascono nemmeno.
  • ⚠️ Due falsi verdi chiusi dentro il provino stesso: moriva sul giornale già liberato stampando ESITO=OK senza aver misurato niente. Ora c'è un controllo che i verdetti siano tanti quanti i giri.
• Non provato: il device vero (vietato installare su iOS reali); la conferma del nome fino al corpo definitivo; e perché l'iPad non lo faccia resta una deduzione (account collegato, oppure cinque punteggi locali più alti), non una misura.
• 📌 Follow-up: col notch la box del selettore misura 541 su 602 unità di canvas — ci sta, ma è stretta: se i tasti crescono ancora, è quello il punto che cede.

Sprint 10, ultimo lotto: la piazzetta di FUMAROLA stava peggiorando il quartiere2026-08-21

• [change] SU-478 + SU-479 — la prova del raddoppio ha un ESITO, e non è «×2». Misura A-B-A×3 nella stessa run (il giro pulito ha dispersione 2% fra i tre A, quello sporco 30%: si legge il pulito), cronometro sul viewport perché su questo Mac gli fps a finestra li cappa il compositore.

  Il costo sta tutto nel disegno, che è la voce che si paga su telefono — dove non si è potuto misurare. Decisione: passanti ×1,5 (45 → 68), gatti ×2,0 (8 → 16), col perché scritto sopra la costante. A 45 la città è vuota davvero (3,7 persone per schermata, spesso zero); a ×1,5 se ne vedono ~5 pagando metà dell'aumento di disegno, ed è il massimo difendibile senza un device. I gatti sono 16 nodi contro 580: costo nullo, e a 8 si gira mezza run senza munizioni.

  	×1 (45 pass. / 8 gatti)	×2 (90 / 16)	×6 (controprova)
  disegno, viewport cpu	0,406 ms	0,658 ms (+62%)	1,587 ms (+291%)
  simulazione, frame headless	7,505 ms	7,792 ms (+3,8%)	p99 da 10,8 a 14,5
  passanti per schermata	3,70 tablet · 4,09 telefono	5,93 · 7,95	16,83

  • Più viva o solo più affollata: più viva — negli scatti la gente in più si distribuisce sui marciapiedi, non si accumula.
  • Vite del gatto (criterio esplicito): NON toccate. cat_lives cambia solo per danno, per le 3 vite del rifugio e per il revive; raccogliere un gatto mette has_cat, cioè carica il colpo, non dà vite. Vite e gatti condividono l'icona, non l'economia. Cambiano invece i $5 per bersaglio e il passo dell'impresa «50 gatti a segno»: circa raddoppiati, non misurati in dollari a fine run.
  • MP, il rischio numero uno del brief — il chunking regge: i pacchetti non crescono con la popolazione, cresce il loro numero. Trasformate 2 pacchetti da ≤576 B a ×1 come a ×2; snapshot d'ingresso 4 → 7 pacchetti da ≤~700 B. Tetto EOS 1170 B mai avvicinato. Non provato con peer veri.
• [change] SU-477 — più poliziotti nella retata, e il tetto vecchio quasi nessuno lo vedeva. RAID_FIRST_WAVE 4 → 7, RAID_WAVE_SIZE 2 → 3, RAID_WAVE_INTERVAL 20 → 15 s, RAID_CAP 30 → 36. Dopo un minuto di retata gli agenti sono 19 invece di 10, e il tetto si raggiunge in 150 s invece di 260 — erano la prima ondata e il passo a farsi sentire, non il tetto.
  • Costo misurato con una sonda che forza la retata (col bot non ci si arriva: muore a 610 s contro i 1710 che servono): senza retata 0,399 ms → 7 agenti 0,425 → 36 agenti 0,619 ms (+55%). Nel giro precedente la retata *vecchia* piena costava +51% sul suo «senza»: sei agenti in più non si sentono.
• [feat] SU-480 — fra una fermata e l'altra c'è la CORSA IN GALLERIA, non un taglio nero. Una parete scura entra da destra (0,22 s: scorre, non sfuma), poi la galleria — costole verticali che sfilano, luci di servizio su tre profondità, cornice del finestrino e il vagone che sobbalza (2,5 px, sin a 37 Hz) — e infine la parete esce a sinistra scoprendo la fermata nuova. Totale 0,95 s contro i 0,94 della vecchia dissolvenza: nessun equilibrio si muove.
  • Caricamento più lento dell'animazione: non c'è caricamento (è un teletrasporto nella stessa scena). La fase d'uscita parte dopo che il salto è tornato più due frame interi, così la banchina nuova è già composta quando la parete scopre. Non esiste un istante di schermo vuoto.
  • MP: nessuna pausa, nessun RPC, nessun byte — è un CanvasLayer locale, e gli altri peer vedono il salto di posizione che Player.gd già replica.
  • Disegnata in _draw(), non con uno shader, di proposito: il compile-check non valida gli shader e Godot ripiega in silenzio sul default, quindi un tunnel rotto sembrerebbe un tunnel giusto.
  • ⚠️ Difetto trovato GUARDANDO gli scatti, con tutte le asserzioni verdi: draw_rect() dentro un Control non è ritagliato, e mentre la parete usciva le strisce di luce continuavano a disegnarsi sopra la città già scoperta. Cura: clip_contents = true.
  • La vecchia dissolvenza resta come ripiego, e non è pigrizia: Interactable vive anche dove un World non c'è (le sonde che istanziano la sola fermata), e lì metro_ride non esiste.
• [feat] SU-481 — FUMAROLA ha la sua piazzetta lastricata, ed è una CONFIG. ⚠️ Non è un quartiere nuovo: FUMAROLA esiste dal 2026-08 (SU-129) — QUARTIERI_DESIGN.md §9 la dà «da fare», ma quella tabella è la storia del piano, non lo stato dei lavori. [NOVITA']
  • Architettura: nuova chiave di layout park_min, e _ricava_parchi_garantiti() promuove a PARCO un super-isolato 2×2 di palazzi già allocato — «ricavato da un palazzo» alla lettera, la tecnica speculare di _converti_piazze_in_isolati(): la forma della città non cambia, cambia il kind. Scartato alzare prob_park, che avrebbe riscritto tutta la mappa spargendo verde a caso invece della piazzetta unica chiesta.
  • Il suolo del parco diventa floor_fumarola.png, cioè il marciapiede del quartiere: «un parco fatto a marciapiede», zero asset nuovi. ⚠️ Questo sostituisce una scelta di Ivan (SU-406, park_fumarola.png con fango e pozze) — ma quell'arte non è mai comparsa in partita, perché prob_park era 0. Il file resta nel repo: si torna indietro con una parola.
  • Determinismo: con park_min: 0 la funzione esce prima di toccare l'rng, quindi gli altri sette quartieri generano identici al pixel. È un argomento di costruzione: non è stato fatto un censimento prima/dopo.
  • ⚠️⚠️ IL DIFETTO CHE IL TICKET AVREBBE PORTATO, trovato misurando invece di dare per buono. FUMAROLA ha lo spazzino come nemico di casa, e SU-109 gli fa adottare il parco più vicino fasciandone panchine e fontana col nastro. Finché il quartiere non aveva parchi non poteva succedere. Col parco: 4 su 4 fra panchine e fontana col nastro, a t=0 e dopo 45 s, e panchine libere nel quartiere: ZERO — cioè peggio di prima del ticket, che una panchina spaiata ce l'aveva (la rete di SU-323 vedeva «3 ≥ 1» e non scattava più).
    • Due giri per chiuderlo: (1) la rete dei minimi ora conta solo le panchine fuori dai parchi; (2) — e questo si vedeva solo misurando — la panchina forzata finiva dentro la piazzetta, perché _zone_ripiego() ordina per area e il parco 2×2 è la zona più grande della mappa. Esito: 1 panchina libera, su 5 semi su 5.
  • Decisione consapevole: il presidio dello spazzino RESTA. È la battuta del quartiere (nemico di casa dichiarato), è reversibile in partita (steso lo spazzino il nastro cade da solo), e le cabine non le blocca mai — uno dei tre oggetti chiesti funziona sempre.
• Non provato: device reali (gli fps del raddoppio e della retata su telefono — è LA misura che manca); multiplayer con peer veri; il denaro di fine run coi gatti raddoppiati; un censimento prima/dopo sugli altri sette quartieri.

Sprint 10: SU-473 chiuso, anche la metà in Opzioni2026-08-21

• [change] SU-473 — dentro PROGRESSI compare solo la porta che vale adesso. La metà di fine partita era già in 4b1e648; questa è l'altra. Chi è connesso vede CLASSIFICA ONLINE e non HIGH SCORES; chi è ospite l'opposto. Le due classifiche restano divise in ogni punto del gioco, che era il vincolo del ticket.
  • La decisione non si prende con un if sullo stato di login: la chiedono OnlineLeaderboard.show_online_only() / show_local_only(), cioè la stessa fonte che usa il giornale di fine partita. Due letture diverse della stessa regola sono il modo in cui le due schermate divergono dopo un mese.
  • Il filtro sta dove c'era già quello di SU-432 (la classifica online non esiste su web): una lista sola, tre ragioni per saltare una voce, invece di tre punti che decidono ognuno per conto suo.
  • ⚠️ E qui c'era la trappola vera, che il compile-check non avrebbe mai visto: MainMenu._screens si costruisce una volta sola all'avvio. Filtrare la lista dentro _build_progressi_screen() e basta avrebbe congelato lo stato di login a quello del boot — entri con un account, apri PROGRESSI, e trovi ancora la classifica di casa. Serviva _rebuild_progressi_screen(), chiamata da _open_progressi(), sul modello di _rebuild_highscores_screen() che esisteva già per la stessa ragione.
  • Provato con probe_su473_opzioni.gd (nuovo): sei controlli, ESITO OK. Da ospite ["highscores", "quaderno", "baracca", "back"], da connesso ["classifica_online", "quaderno", "baracca", "back"] — e il secondo caso gira dopo aver cambiato lo stato senza riavviare, che è l'unico modo di accorgersi del difetto della lista congelata. Controllata anche la selezione, che su una lista accorciata può puntare fuori senza dare nessun errore.

Sprint 10, lotto fine partita: la classifica si leggeva nello stesso frame dell'invio2026-08-21

• [fix] SU-474 — «la classifica online non compare», e il caso del primo punteggio era davvero quello. Causa trovata, non dedotta: la board si legge nello stesso frame in cui si invia il punteggio, quindi torna la classifica di *prima* — alla prima partita, vuota — e nessuno rileggeva dopo. In più OnlineLeaderboard faceva return secco se era occupata, buttando via la richiesta. Ora c'è una coda (_pending_board + _libera()/_drain_pending()) e HUD forza la rilettura su submit_finished andato a buon fine.
• [change] SU-473 — l'ibrido locale+online a fine partita è tolto. OnlineLeaderboard.show_online_only() / show_local_only() sono la regola in un posto solo, scritte in positivo perché è così che compaiono nel punto di chiamata. Provino: prima «elenco di casa = true e elenco del mondo = true» in tutti e tre i casi di board — cioè l'ibrido —, dopo «casa=false, mondo=true» da loggato e «casa=true, mondo=false» da ospite.
  • ⚠️ Metà ticket resta aperta: la classifica dentro Opzioni (MainMenu.gd) non è ancora agganciata a quelle due funzioni. Il lotto non poteva toccare quel file. È una chiamata per schermata, niente if nuovi.
• [fix] SU-476 — il giornale su mobile non si vedeva tutto. La scala tipografica e il numero di colonne guardavano solo la larghezza: ora guardano anche l'altezza. Prima le colonne sforavano di 130/183/161 unità su 164 disponibili (telefono, corpo AUTO) e di 188/441 su 113 col corpo ENORME. Dopo: 0 su tutte, tablet invariato.
• [fix] SU-483 — la musica del livello non riparte più andando al menu. _silence_world_music() chiamato prima di paused = false nei due punti d'uscita. Misurato: prima 779 ms di musica del livello su 42 frame, dopo 0,000 s.
• [feat] SU-475 — la classifica di fine partita è un foglio di giornale, e la transizione è un voltapagina. Pagina 1 esce mentre pagina 2 entra: provino ESITO OK, prima 1.00→1.00 (cioè un dissolvi), dopo 0,88→0,38 in chiusura e 0,84→1,00 in apertura. Riusata la palette da giornale che c'era già (RunReport.gd:54), e la regola del KO di SU-393 — il giornale non esce mai da solo verso i record — resta in piedi. [NOVITA']
  • 📌 Due punti da decidere con Ivan, non difetti: su telefono la pagina 2 scorre (riquadro 288 unità contro 393 di testo — è la rete di SU-320, ora allineata in alto così la prima riga è intera); e il menu RICOMINCIA/ESCI è rimasto fuori dalla carta, perché sta sotto il foglio.
  • ⚠️ Artefatto da non inseguire: negli scatti a 844×390 la prima riga di pagina 2 sembra tagliata a metà. È la riduzione del provino (canvas 1278×591 dentro una finestra 844×390, 0,66×), non il layout: a scala 1.0 sul tablet la stessa riga è intera e la geometria misurata è identica.
  • Il provino shot_su475.sh è saltuariamente ballerino al secondo giro («il giornale non si è aperto»): si rilancia, non è una regressione.

Sprint 10, lotto menu mobile: la box larga era il premio delle due colonne2026-08-21

• [fix] SU-496 — «una regola sola per tutte», e la causa vera è saltata fuori misurando, non leggendo. Il ticket descriveva cinque schermate strette come cinque difetti; erano un difetto solo con due facce:
  • da SU-456 la box larga e le scritte grandi erano il premio delle due colonne: chi non si spezzava — AUDIO con 4 voci, GRAFICA su telefono con 4 — restava col vecchio 0.52 e col corpo base;
  • e le schermate che vivono in MainMenu.gd (Grafica, Controlli, Progressi, Partita→tutorial, scelta del barbone) non passavano nemmeno di lì: si scrivevano vp.x * 0.56 e vp.y * 0.030 per conto proprio.
  • Rimedio: una regola static in OptionsPanel.gd (opt_panel_width, opt_row_factor, opt_row_step, opt_row_height, opt_list_height, opt_font_voci/titolo/info, opt_font_che_entra, opt_layout). Larghezza, passo e corpo non dipendono più dal numero di colonne, e le cinque schermate figlie chiedono opt_layout() tramite due aiutanti in MainMenu.gd. Scartata la strada delle cinque correzioni a mano: la sesta schermata sarebbe rinata stretta.
  • ⚠️ Il caso peggiore era AUDIO, e non era «stretto»: era rotto. Box 640, corpo 33, passo 33,5 con righe alte 47 — cioè le righe si sovrapponevano. Ora 1125 / 35, passo 56,3.

    Telefono 844×390 (canvas 1278×590), metro = menu radice Opzioni 1125 / 35:

    schermata	prima	dopo
    AUDIO	640 / 33, righe sovrapposte	1125 / 35
    GRAFICA	1125 / 34, barra fuori centro di 33,8 px	1125 / 34, scarto 0,0
    CONTROLLI (mappatura)	680 / 16	1125 / 35
    PROGRESSI	660 / 23	1125 / 35
    PARTITA → tutorial	680 / 26	1125 / 35
    LINGUA (aggiunta, non era nel ticket)	660 / 23	1125 / 35

  • Alternativa scartata in corsa, e il perché conta: il primo tentativo allineava la barra dello slider restringendo la Label alla larghezza del binario. Allineava, ma toglieva il 30% di spazio alle voci lunghe, e CONTROLLI ricadeva su una colonna col testo più piccolo di prima (32 contro 46). La cura giusta è rendere simmetrico il binario, non accorciare la scritta.
  • Tablet e desktop: le stesse schermate passano da 532-680 / 15-30 a 901 / 34 e 1201 / 34, cioè esattamente il loro menu radice. Nessuna cresce oltre il proprio radice.
• [fix] SU-495 — la scelta del barbone su telefono. Anteprima 220×150 → 204×217 (+45% sul lato che limitava), frecce 190×63 → 215×139, pallini 48×40 → 113×50, CONFERMA 24 → 35, ← INDIETRO 21 → 35. Su canvas basso CONFERMA e ← INDIETRO vanno affiancati: senza, le fasce in fondo si mangiavano la vetrinetta e il barbone restava a 165 unità — cioè il ticket non era risolto.
• ⚠️ Dove «mai più piccolo» non è letterale, ed è dichiarato: su telefono GRAFICA (5 voci) e CONTROLLI (7) restano a corpo 34 e 29 contro 35, perché si spezzano in due colonne e la voce tradotta più lunga tira indietro il corpo. Identico prima e dopo, nessuna regressione, ma è l'unico punto che non rispetta la lettera.
• Non provato: il menu di pausa (CTX_GIOCO, ospite di HUD.gd), che passa dallo stesso pannello ma non è stato fotografato; tedesco e russo (opt_font_che_entra misura le stringhe vere, ma la prova è solo in italiano); GRAFICA su telefono vero con 4 voci, perché il Mac non sa fingere _is_mobile().
• 📌 Follow-up: il titolo delle schermate (corpo 30 su telefono) è più piccolo delle voci — vale anche nel menu radice, non toccato per non muovere il metro di paragone.

Sprint 10, lotto bonus stage: il tunnel rifatto in tre fasi, e un ticket che era già fatto2026-08-21

• [feat] SU-491 — il livello bonus è la versione decisa da Ivan il 21/08: lattine sui binari, piattaforma in fondo, la metro che scarica la gente. Il livello diventa tre fasi in fila dentro _passo() (enum Fase { INTRO, CORRIDOIO, BANCHINA, FINE }), non tre pezzi che scorrono per conto loro. [NOVITA']
  • Scartati Tween/await per l'intro e per l'arrivo della metro, ed è la scelta che regge il collaudo: il livello è pilotato a passi da debug_passo(), e qualunque animazione autonoma avrebbe fatto misurare alla sonda una cosa diversa da quella che gira in partita.
  • Scartato anche il riuso di CanDrop/MoneyCoin veri: sottoterra il barbone non è un Player, e CanDrop.drop_cans_reward() avrebbe trovato il nodo del gruppo "world" — la città congelata, non distrutta — facendo piovere lattine a decine di migliaia di pixel dal giocatore. Da qui CanDrop.accredita_meta(): il punto in cui una lattina diventa meta-progressione resta uno solo.
  • Numeri decisi col default e scritti nel codice col perché: 36-48 lattine, 20 passeggeri × 10 monete (200 in tutto), monete da $1, banchina 2.304 px, raccolta 30 s. Premio finale in sole carte, come deciso.
• [change] SU-488 — treni più veloci e più fitti, con la finestra di reazione rimisurata. Velocità 320 → 420 px/s (transito 1,58 → 1,20 s), intervallo 6,2→3,6 s diventa 4,6→2,6 s, col vincolo che l'intervallo resti maggiore del transito. Finestra di reazione misurata: 1,617 / 1,550 s contro il minimo di 1,50 — è il numero che rende il livello giusto o ingiusto, e regge.
  • L'attraversamento vero è 48,0 / 47,5 s, misurato con un oracolo che schiva camminando, non teletrasportandosi.
• [feat] SU-492 — spiegazione, conto alla rovescia arcade e tempo limite. Intro «SOTTO LA CITTÀ / Lassù il tempo si è fermato / Corri fino alla BANCHINA in fondo al tunnel», poi 3-2-1. Tempo limite 60 s contro i 48 dell'attraversamento vero: margine 12,0 / 12,5 s. 6 chiavi nuove in tutte e 8 le lingue.
• [docs] SU-489 — non andava fatto: il treno di Ivan era già in gioco dal 20/08. L'asset assets/sprites/world/subway_train.png è 504×90 (esattamente TRENO_LARGHEZZA = 504.0), non modificato, e risale al commit 6ea8904. Il raw in sprites_raw/WORLD/ risulta «modificato» in git status solo perché è RGB contro l'RGBA di HEAD — il falso positivo LFS di sempre: confrontati pixel a pixel danno 1.572.860 differenze su 1.572.864, ma l'import del raw nuovo produce un asset byte-identico a quello in gioco (0 differenze su 45.360).
  • ⚠️ La conseguenza da portare a Ivan: se il treno che aveva in mente era *un altro*, quel file non è mai arrivato su disco.
• 📌 IL CONTO ECONOMICO, che è un deliverable e non un contorno. Biglietto $100 / $200 / $400. Primo giro: +$80 con l'oracolo goloso (180 monete su 200), −$48 con quello a passate (52 su 200). Stress test del miglior incasso contro il secondo biglietto: −$20 → oltre il primo giro il ciclo banca→tunnel non stampa soldi.
  • ⚠️ Il +$80 del primo giro è la cosa nuova: SU-468 chiudeva a −$17, qui chi arriva in fondo e raccatta bene ci guadagna. È la conseguenza diretta di «200 monete alla fine», e non è stata aggiustata di nascosto.
  • Sul telefono col dito la forbice vera sta fra il 26% e il 90%, e il 90% è irraggiungibile a mano: è quel numero a decidere se il primo giro è davvero in attivo.
• ⚠️ Ereditato, non di questo lotto: probe_su467.sh era già rossa su HEAD (verificato ripristinando i file committati) — due controlli su RunManager non sono di qui; SU-491 ne rende obsoleto un terzo, che asseriva che il barbone finisse sul traguardo mentre ora il livello continua sulla banchina. E probe_su468_premio.gd misura un livello che non esiste più: da ritirare o riscrivere.
• ⚠️ Decisione a monte che resta aperta: la tabella d'oro a sei esiti (chest_gold = true) è di nuovo senza nessuno che la faccia comparire — tolta di proposito, perché gold_cash e gold_rain raddoppierebbero l'incasso della banchina.

Sprint 10, lotto progressione: il livello 24 costava 152 XP, il 25 ne costava 202026-08-21

• [fix] SU-482 — il gradino era nella formula, e si leggeva senza giocare una run. Ivan: «a 17 minuti ero al livello 23 e non salivo più». Non era un tetto ai livelli: era la forma della curva. Il ramo addolcito non *continuava* il primo, lo sostituiva — growth = 1.16 if lv < 25 else 1.06 cambia la base dell'esponente per tutto il calcolo, non solo per i livelli oltre il cap.

  Cioè un muro di 283 XP fra il 23 e il 25 — più di tutti i primi dodici livelli messi insieme — e subito dopo un regalo: dal 25 in poi un livello costa quanto ne costava uno all'undicesimo. SU-78 quel crollo l'aveva già visto e l'aveva solo *spostato* da 20 a 25, cioè esattamente in mezzo alla run da 30 minuti.

  livello	22	23	24	25
  costo XP	113	131	152	20

  • Rimedio: curva continua a tre tratti che moltiplicano invece di sostituire — +16% fino al livello 12 (i primi dodici intatti, il ritmo dei primi minuti non si tocca), +7% fino al 40, +3% oltre. Non esiste più nessun livello che costa meno del precedente, e lo sconto endless torna dov'era il suo posto: fuori dalla run normale.
  • Scartate: rendere continuo lasciando il ginocchio a 25 (peggiorava il muro invece di toglierlo) e abbassare XP_GROWTH (avrebbe toccato i primi minuti, che nessuno ha lamentato).

    	prima	dopo
    livelli in 30'	41 (16 negli ultimi 8 minuti)	36
    attesa peggiore fra due livelli	2,64' (poi 0,35' dal 25)	1,61'
    quando arriva il liv. 23 / il 25	17,0' / 21,9'	12,1' / 14,4'

  • Il giullare, il numero che il ticket chiedeva: 20.000 simulazioni a seme fisso sui pesi veri di draw_cards (pool iniziale 6 carte + 3 occasioni). Serve una carta al livello 9 → mediana 19 pescate, p90 24 se insegui sempre la carta più avanzata; mediana 35, p90 43 se peschi a gusto. Dichiarato: deve poter entrare in scena entro il minuto 16, così restano 14 minuti per trovarlo, abbatterlo e spendere la carta. Il caso p90 passa da 22' a 14'.
  • ⚠️ Chi pesca a caso resta comunque fuori (35 pescate contro 36 livelli): non è stato toccato il ventaglio delle carte, è una seconda decisione. Proposta per un ticket a sé: peso della carta crescente col suo livello.
• [feat] SU-469 — ogni moneta raccolta dà XP, riusando la strada che c'era già. La moneta riserva l'XP alla posa e lo consegna con add_xp_carried(), cioè la stessa porta di CoinDrop: nessuna seconda strada che si comporta quasi uguale. split_source_xp non era usabile (le MoneyCoin nascono una per volta dentro World._cl_coins_scattered, file di un altro lotto), quindi il resto frazionario resta in XPSystem._dollar_xp_carry e attraversa le monete: il totale è sempre floor(dollari × tier ÷ 5) comunque siano spezzati, che è il criterio del ticket. Verificato da sonda, non a mano.
  • Scartate: un XP per moneta arrotondato (rompeva proprio quel criterio) e un intero XP per dollaro (avrebbe reso le monete la sorgente XP principale).
  • Le monete del livello bonus sono escluse, via flag sulla moneta e gate bonus_level_active — deciso così perché il livello bonus lo sta rifacendo SU-491 e paga in carte: non deve pagare due volte.
• [change] SU-494 — la banca: una mossa sola tiene insieme le tre richieste. Il debito non si scala più quando l'arco si *accende* ma quando viene usato; da lì discendono sia il contatore fermo su 100/100 sia lo sportello chiuso. Cooldown a zero: si versa a ogni pressione. A conto pieno la facciata si scalda d'oro, e prompt e freccia spariscono. La banca se ne accorge da sola guardando _faro_metro_acceso() quattro volte al secondo, perché chi consuma l'arco è la fermata della metro — file di un altro lotto, non toccato.
  • Il numero del freno, che il ticket chiedeva di verificare: la prima soglia da $100 passa da 10 pressioni × 0,5 s = 5 s a 10 pressioni ≈ 1 s a raffica. La soglia che raddoppia (100 → 200 → 400) resta l'unico freno, com'era previsto.
  • Provato con scatti: a metà la banca è grigia col prompt, a conto pieno è dorata e il prompt non c'è più. Il bagliore è tarabile con BANCA_GLOW_ALPHA_MAX (0,45) — è una scelta di gusto.
  • Aggiornati perché asserivano il comportamento sostituito (erano diventati rossi): probe_su466_banca.gd e shot_su466_banca.gd.
• ⚠️ Non provato, e va detto: il giro completo «riempi → vai in metro a riscuotere → torna e deve dire 0/200» non è verificabile adesso, perché il livello bonus lo sta riscrivendo SU-491. E il modello dei minuti è un modello, ancorato al solo dato di Ivan (liv. 23 al 17'): il bot non serve a verificarlo — 90 s di run chiudono a livello 1 con 0 XP. Serve un playtest.
• 📌 Non di questo lotto ma da sapere: probe_su249_banca.gd è rossa da *prima* (asserisce che il deposito faccia comparire un bidone d'oro, sostituito dall'arcobaleno in SU-466 parte 3 — verificato su git show HEAD).

Sprint 10, lotto piattaforma: su iPad la configurazione era già giusta, il difetto è iPadOS 262026-08-21

• [fix] SU-499 — diagnosi prima del rimedio, e il rimedio non era dove il ticket lo cercava. Verificato: project.godot:85 ha window/handheld/orientation=4 dal 4/7/2026; il template iOS di Godot 4.6.2 inchioda UIRequiresFullScreen=true; e l'ultimo export vero (Street University-Info.plist:47-60) dichiara già solo LandscapeLeft/LandscapeRight sia in UISupportedInterfaceOrientations sia in ~ipad. Il project.pbxproj non ha nessun INFOPLIST_KEY_… che scavalchi.
  • La causa è fuori dal gioco: iPadOS 26 rende le app iPad finestre ridimensionabili, UIRequiresFullScreen è deprecato, e col blocco rotazione di sistema spento gli orientamenti dichiarati vengono ignorati. Non esiste una chiave da aggiungere.
  • Rimedio: non combattere il sistema, difendere il disegno. WindowShape.gd non muore più su mobile: resta in «guardia verticale»; se la finestra diventa più alta che larga il canvas si inchioda a 1024×768 con CONTENT_SCALE_ASPECT_KEEP — gioco orizzontale, bande nere — e tornando orizzontale si rimettono i valori di progetto. Su iPhone non scatta mai. Non provato su iPad vero: provata solo la meccanica su un Window nascosto, 6/6 OK.
• [change] SU-493 — l'ultima carta arriva a elastico, e i numeri ci sono. _slide_winner_to_center() è ora due tweener sullo stesso tween senza tween_interval: con due tween separati il secondo partirebbe insieme al primo e non scavalcherebbe niente. Elastico 0,34 s QUINT/EASE_OUT + rientro secco 0,14 s CUBIC/EASE_IN_OUT = 0,48 s, identico al totale di prima.

  	sosta	scavalco	rotazione	totale
  prima	117 ms	0,0 px	0,00°	485 ms
  dopo	10 ms (un frame di campionamento)	46,0 px al ms 334	+6,00° oraria	487 ms

• [change] SU-500 — la pipì era $StatusParticles, e il rimpiazzo non è costato arte nuova. Player.tscn:74: un CPUParticles2D senza texture, colore (0.6,0.5,0.1,0.7), gravity (0,+20), emesso dall'origine — nello scatto «prima» si vede il fiotto giallo che arriva a terra. Nessuna posa dello sprite era coinvolta, quindi non serviva rigenerare niente. Ora le stesse particelle salgono verdi (gravity (0,−34), color_ramp che le fa nascere e morire trasparenti), con tilde che salgono di 10 px sfumando e la gag della mosca che sviene e precipita di 9 px. Tono assurdo, non disgustoso, come chiedeva il ticket.
  • 📌 Da guardare a zoom di gioco (2,5, non il 4 del provino): che le onde non coprano troppo il cappello.
• [docs] SU-484 — misurato, e l'interruttore non serve: coprirebbe 1 shader su 14. Censiti 14 shader, di cui un solo file .gdshader: gli altri 13 nascono a runtime da costanti di testo (World 10, HUD 2, WorldGenerator 1), e zero ShaderMaterial nei .tscn/.tres. Lo Shader Baker dell'export precompila le risorse, e una stringa costruita a runtime non è una risorsa.
  • La misura: il periodo di frame non basta (il compositore cappa a 8,2 ms anche col vsync spento), quindi cronometro su viewport_get_measured_render_time_cpu — base 0,343 ms, prima volta 0,494-0,683 ms, seconda volta 0,499-0,631 ms. Prima ≈ seconda: si sta misurando il quad a schermo intero, non la compilazione. Su questo Mac lo scatto non è misurabile (il timer GPU torna 0,000 su questo backend), e il numero che serve è quello di iPhone/iPad. Niente implementato, ed è la risposta onesta: se lo scatto su device c'è, la strada è spostare le 13 costanti in file .gdshader oppure riscaldarli durante il caricamento.

Sprint 10, lotto mondo: il palo bloccava 1242 px², adesso 1442026-08-21

• [fix] SU-498 — il muro della fermata della metro era largo quanto tutto lo sprite, palo compreso. Ora sono due muri distinti: il chiosco (da METRO_PALO_DESTRA_FRAZ = 0.27 in poi) e solo il piede tondo del palo (local-x 8..16, local-y 59..70 sul PNG 86×75). Il cartello a rombo «M» e lo stelo tornano calpestabili, y-sortati dietro come vuole la REGOLA 1 della profondità del mondo. Area di collisione sul palo: 1242 → 144 px², −88%.
• [fix] SU-490 — l'arcobaleno passava davanti alla fermata, e la causa non era nell'arcobaleno. _add_interactable() dà all'area z_index = int(pos.y), e per la metro quel pos è il *fronte*, cioè spr_rect.end.y + METRO_FRONTE_OFFSET (8 px più a sud del bordo basso vero). Giusto per il punto d'uso, sbagliato per il y-sort — e nessuno lo correggeva, perché METRO_STOP non ha un _sprite_ref proprio (il disegno è di WorldGenerator, non di Interactable) e quindi Interactable._applica_z_arredo() è un no-op su quel tipo. La coda dell'arcobaleno di SU-466 si nasconde a z_bidone - 1: con lo z 8 px troppo a sud finiva 7 livelli davanti allo sprite invece che uno dietro. Riallineato a int(sprite_rect.end.y), che è esattamente lo spr.z_index che _build_metro_block dà al disegno.
  • ⚠️ La prova qui NON è la fotografia, ed è giusto dirlo: uno spostamento di z di 8 px si vede solo nella fascia in cui cade la coda, e lo scatto prima/dopo aveva un poliziotto che si era spostato nel frattempo — 2.171 pixel diversi che non dicono niente. La verifica che conta è la catena letta nel codice: spr.z_index = int(spr_rect.end.y) (r.2842) contro area.z_index = int(pos.y) con pos.y = spr_rect.end.y + 8 (r.5799, r.2883). Un ordinamento intero si prova con i numeri, non con una foto.
• [fix] SU-497 — il rider in bicicletta non si ferma più, tranne quando il barbone suona e lui viene ad ascoltare. Aggiunto _is_rider_no_stop() e due chiamate in _move_to_waypoint(): raggiunto il waypoint riparte subito verso il successivo invece di entrare in _is_waiting. Il percorso è esattamente quello di prima, come chiedeva il ticket. Osservato 9 s reali senza mai entrare in attesa, waypoint 1→2→3.
  • ⚠️ Trappola trovata durante il collaudo, e vale per tutto il progetto: String(null) in GDScript 4 non è un cast silenzioso, è uno SCRIPT ERROR. La prima stesura di _is_rider_no_stop() faceva String(archetype_id) e crashava ogni frame per ogni PoliceOfficer/RaidOfficer, che quel campo non ce l'hanno. Corretta con un is String prima del confronto. È emersa solo perché il mondo vero girava per il provino di un altro ticket: il compile-check non la vede.
• [feat] SU-485 — sulla mappa la fermata col bonus stage si illumina multicolore. Classe _MetroBonusGlow in MapOverlay.gd, agganciata a _rebuild_icons()/_process(). La sorgente di verità è la stessa dell'arcobaleno (arcobaleno_banca_attivo sull'area della fermata): nessun secondo stato inventato. Provato con scatto prima/dopo: nel «dopo» l'alone c'è, nel «prima» no.
  • 📌 Da guardare in gioco: nello scatto il giocatore sta sopra la fermata accesa, quindi l'alone e il marcatore «TU SEI QUI» si sovrappongono e non si distinguono bene. Con la fermata lontana dovrebbe leggersi meglio, ma è da vedere.
• Non provato: nessun run multiplayer reale. Rischio basso per costruzione — WorldGenerator è deterministico per seme, _move_to_waypoint() gira solo su host/SP, MapOverlay è locale al client.

Sprint 10, lotto design: il verso della metro e il vicolo cieco del nome Epic2026-08-21

• [docs] DESIGN_SPRINT10_DECISIONI.md (nuovo, 746 righe): SU-486, SU-470 e SU-471 decisi, con le alternative scartate e il perché, i testi italiani già scritti e i ticket di implementazione pronti. Nessuna riga di codice: sono ticket (DESIGN), e producono una decisione.
  • SU-486 — il verso opposto della metro. La proposta di Ivan (tenere premuto A) regge, e per una ragione che si vede solo leggendo il codice: il «tieni premuto» non è un verbo nuovo, è già quello del superpotere (SUPER_HOLD_SEC = 0.45) e il tutorial lo insegna. Il difetto che ci si aspetterebbe — «adesso la metro risponde in ritardo» — non esiste se il tocco corto si risolve al rilascio invece che alla soglia: il ritardo diventa il tempo di reazione del dito, non 450 ms. Censimento richiesto dal ticket: 3 sorgenti × 10 usi del tasto A, e nessuno legge interact tenuto premuto — tutti leggono la pressione — quindi la finestra di hold, confinata a Type.METRO_STOP, non tocca elemosina, altri interagibili, fantasmino né i sette ui_accept. Zero lavoro MP: il viaggio è già locale. Scartate: due tornelli fisici (la metro è il bottone del panico, chiedere precisione a chi è inseguito su un joystick virtuale è la richiesta peggiore possibile), il pannellino di scelta (il viaggio è scritto per non mettere MAI in pausa), la direzione data dalla levetta (muoversi ti fa uscire dal trigger), il doppio tap (il secondo tocco può finire a un passante).
  • SU-470 + SU-471 sono una decisione sola, e l'ordine conta: 470 prima, 471 dopo. Il perno è il nome di riserva: quando l'handle Epic non passa (preso, forma o filtro) il gioco ne costruisce uno con una regola scritta e lo rivendica davvero — quindi unico come tutti — e da lì la schermata del nome si sblocca anche per Epic, perché «si cambia su Epic» è una frase diventata falsa. Nessuna esenzione dalle due porte, così moderazione e unicità restano in piedi. Caso 2 (Apple/Google contro un nome Epic): prima arriva prima prende, senza corsie — e adesso lo si può dire senza sensi di colpa, perché chi perde la corsa non resta più a mani vuote.
  • ⚠️ Il danno che i ticket non nominavano e il codice sì: senza account_name_claimed il giocatore Epic non è solo «SENZA NOME» in classifica, è fuori dal multiplayer (NetworkManager.online_gate_reason() → GATE_NO_NAME). Gli stiamo dicendo di fare una cosa che dentro il gioco non esiste.
  • SU-471 — la terza risposta si inventa senza toccare is_blocked() (che è il punto unico e gira mentre la classifica disegna): una funzione nuova, chiamata solo alla rivendicazione, con la definizione «dubbio = passa il filtro di oggi ma non passerebbe un filtro di un grado più severo» — cioè i casi che il commento di SU-453 dichiara già di non coprire. Le voci corte restano fuori, sennò va in revisione mezzo elenco telefonico (Falcone contiene con). Un no va in lista per nome normalizzato, non per giocatore, sul server, per sempre. E su «dove Ivan li vede»: né lo script che accoda in un .txt né la paginetta web — il registro si è già creato da solo un foglio Google sul Drive di Ivan, bastano due schede e una colonna verdetto, dall'app Fogli sul telefono. Zero infrastruttura nuova, zero URL da proteggere.
  • 📌 Nove domande per Ivan, tre per ticket, ognuna col default che si prende se non risponde: sono in fondo a ciascuna sezione del documento.
  • ⚠️ I numeri di riga si sono mossi mentre il documento si scriveva (Interactable.gd +31 righe, MainMenu.gd +~300 nella zona account, da altri lotti dello stesso sprint): ogni citazione è stata riverificata alla fine, e in testa al documento c'è l'avviso che l'àncora è il nome della funzione, non il numero.
  • ⚠️ Il TestBot prenderà a volte la metro all'incontrario, perché preme e rilascia interact con un ritardo suo (TestBot.gd:582). Non è un difetto, ma va messo in conto leggendo i log delle run automatiche.

Sprint 10, lotto account: su iPhone il pulsante Google non è grigio, è assente2026-08-21

• [feat] SU-472 + SU-449 (residuo) + SU-451 (UI): una tabella sola, PROVIDER_PLATFORMS in EOSBridge.gd, al posto di tre pezzi di UI che decidevano ognuno per conto suo. I tre ticket sembravano distinti — «pulsanti tondi e grossi», «i provider non offerti non compaiono proprio», «collega un altro accesso» — ma insistono tutti sullo stesso punto del menu, e trattarli insieme ha prodotto una regola invece di tre correzioni.
  • ⚠️ Il perché è scritto accanto alla tabella, sennò sembra una limitazione arbitraria: EOS valida una sola audience per identity provider per sandbox, quindi un token Apple prodotto su Android è formalmente valido ma porta l'audience sbagliata e viene rifiutato sempre — non «a volte», non «finché non configuriamo qualcosa». Disegnare quel pulsante vuol dire offrire una porta murata.
  • La regola che ne esce vale per tutto il menu, non solo per i login: *assente* (riga omessa) = qui non funzionerà mai, è struttura; *spento* (riga grigia con la sua frase) = non funziona ancora, è lavoro nostro. Per questo Steam resta grigio su desktop (SU-438) e COLLEGA EPIC resta grigio con una frase che promette, invece di sparire: farli sparire toglieva l'informazione. Se Ivan li vuole assenti è una riga di tabella.
  • 📌 SU-451, la scelta di design che cambia il ticket: il collegamento non si offre in un sottomenu, si offre nel momento in cui l'incidente accade. Da loggati gli altri canali restano a schermo come COLLEGA X, e premerli non fa il login: apre la domanda «sei già dentro come *X*: collegare o entrare come un altro?», con la conseguenza in chiaro — i due giocatori non si potranno più unire. È l'unico momento in cui quella scelta è reversibile. Il motore (link_provider()) c'era dal 17/08: qui c'è la porta per usarlo, riusando il secondo passo del cancello come terzo invece di registrare una schermata nuova.
  • Pulsanti: pillole col raggio a mezza altezza, +55% di altezza, font da 0.030 a 0.036, blocco centrato perché le righe vive ora sono 1-3 e non 4 fisse. E via il testo giallo su bianco che era illeggibile, sostituito da un anello arancione.
  • Provato: check_files.sh FALLITI 0, audit emoji 0, e 14 scatti in TMP/su472/ guardati uno per uno — iPhone Apple+Epic, Android Google+Epic, PC Epic+Steam(grigio), e i canali esclusi non compaiono. Non provato: il giro vero su Android (entra con Epic → collega Google → rientra con Google → stesso PUID da adb logcat), che serve un telefono.
  • ⚠️ Trappola presa al volo, e vale per tutti i provini: il primo giro ha prodotto 14 PNG completamente neri con tutte le asserzioni numeriche verdi, perché in quel momento un file di un altro lotto non compilava. Le misure da sole non se ne erano accorte: si guardano le immagini, non i numeri del provino.
  • Fuori perimetro, dichiarato: il flusso web PKCE per Apple su Android non è stato costruito — con la regola del menu il pulsante lì non c'è più, quindi il sintomo non è raggiungibile. Se un giorno servisse è un ticket a sé: Apple non ha un endpoint token pubblico come Google, vuole un client_secret che è un JWT firmato ES256, cioè un pezzo lato server.

La voce di spesa più grossa non era Jira: sono i .gd letti per intero2026-08-21

• [change] ORCHESTRAZIONE.md regola 8 + CLAUDE.md: sopra le ~500 righe un file .gd non si apre intero. Ivan ha chiesto se anche i commenti nel codice Godot si potessero alleggerire. La misura ha risposto di sì sul peso e no sul rimedio, e ha tirato fuori un numero più grosso di tutto quello visto oggi.
  • Misurato su 487 transcript di subagenti: 896 letture di file .gd per intero = 24,9M caratteri ≈ 8,3M token, di cui 4,2M di soli commenti. Uno sprint intero costa 1,5-2,4M token nei subagenti: la lettura dei file da sola ne vale tre o quattro. Le altre 2.789 letture erano già mirate — la disciplina esiste, non è imposta. Più 43 riletture sprecate (stesso agente, stesso file, di nuovo per intero) su 26 agenti.
  • Il commento pesa davvero: 32% delle righe di scripts/ (27.170 su 86.133), e nei file caldi il 51-77% dei caratteri — CoinDrop.gd 77%, NicknameRegistry.gd 57%, XPSystem.gd 52%.
  • ⚠️ Ma tagliarli sarebbe un falso risparmio, e c'è la prova di giornata. Scrivendo SU-469, XPSystem.gd:85-94 ha spiegato la trappola dell'arrotondamento del tier (5 XP base al tier 1 valgono 6 in un colpo, spezzati in tre monete 7) e CoinDrop.gd ha rivelato che il macchinario dell'XP dentro le monete esisteva già: senza quei commenti il ticket sarebbe nato come «costruisci» invece che «estendi», cioè un secondo sistema quasi uguale al primo. Un giro di KO costa più di tutti i commenti del file. Leggere mirato risparmia gli stessi token senza perdere la conoscenza.
  • Quindi la regola non tocca i commenti: si localizza con grep -n e si legge la finestra (offset/limit, sed -n 'A,Bp'). MainMenu.gd intero sono ~148k token, World.gd ~105k, e in World.gd una funzione fa in media 25 righe su 6.915. Un file già letto non si rilegge intero.
  • 📌 Codice commentato via: 3 righe in tutto il progetto. Cercato apposta: su quel fronte non c'era niente da guadagnare, e vale la pena saperlo per non tornarci.
  • ⚠️ La regola va incollata nella CAPSULA del brief: agli agenti è vietato leggere ORCHESTRAZIONE.md, quindi scritta solo lì non la vedrebbero mai.

Il creatore di ticket alla prova dei fatti: SU-469 e SU-470 nati da un file solo2026-08-21

• [feat] SU-469 e SU-470 aperti nello Sprint 10 con tools/jira_scrivi.sh --sprint: la POST vera, che era l'unica cosa non provata, funziona. Due ticket da un file solo, in una corsa, con epic e sprint attaccati e a schermo solo le chiavi. Verificati dopo (eccezione dichiarata alla regola «non si rilegge dopo aver creato»: si stava collaudando lo strumento, non il contenuto): entrambi «Da fare», SU-469 sotto l'epic R2 e SU-470 sotto M1, tutti e due dentro SU Sprint 10, e la JQL dello sprint li vede.
  • ⚠️ --sprint non è un dettaglio: lo Sprint è customfield_10020 e in creazione vuole l'id numerico (298), non il nome — lo script lo ricava dalla board. Senza il flag il ticket nasce nel backlog, in silenzio.
  • Due difetti presi durante la prova, entrambi nella stessa riga di codice che serviva solo a togliere gli spazi: xargs interpreta le virgolette e muore sull'apostrofo italiano («non solo l'elemosina» → unterminated quote), sostituito con un trim in bash puro; e prima ancora csplit di BSD che non conosce {*}. Il tema è lo stesso: gli strumenti di testo Unix inciampano sull'italiano e falliscono in modi che sembrano altro.
  • I due ticket sono anche la prima prova delle regole di lunghezza di oggi: 3.102 e 2.771 caratteri, contro i 10.341 di SU-467. Niente alternative scartate, niente coda ripetuta, ma NON TOCCARE e FILE/SISTEMI SOSPETTI per intero.
  • 📌 Ricerca che ha cambiato SU-469 prima ancora di scriverlo: MoneyCoin._collect() dà i soldi ma nessun XP, mentre CoinDrop.gd porta già l'XP dentro la moneta (xp_carried + add_xp_carried, macchinario di SU-247). Quindi il ticket è estendere una strada che esiste, non costruirne una — e la trappola dell'arrotondamento è già scritta in XPSystem.gd:85-94 (il tier va applicato una volta sull'evento: 5 XP base al tier 1 valgono 6 in un colpo, spezzati in tre monete darebbero 7). Segnalata anche l'interazione con SU-468, che mette 100-200 monete per giro e paga già in livelli: se ogni moneta desse XP, il livello bonus pagherebbe due volte.
• [docs] 01_TICKET.md: i ticket di ragionamento si chiamano (DESIGN), non più BRAINSTORMING (convenzione di Ivan). Sono di tipo Task, i criteri di accettazione riguardano la decisione scritta e non un diff, e portano NON TOCCARE: qui non si scrive codice; i ticket di implementazione nascono dopo, al suo ok. Esempio: SU-470. La parola resta solo nel nome della skill esterna superpowers:brainstorming, che è un'altra cosa.

Le letture di Jira passano da uno script: l'MCP non filtrava niente, e la regola che diceva il contrario era falsa2026-08-21

• [change] Nuovo tools/jira_leggi.sh: da oggi Jira si LEGGE da lì, e si SCRIVE dall'MCP. Ivan ha chiesto se i ticket, molto discorsivi, si potessero scrivere in modo meno costoso, e se per caso non stessi tirando giù anche i «In revisione» e i «Fatto» che non servono. La seconda risposta era già a posto (la JQL dello sprint filtra su «Da fare» da sempre); la prima ha fatto emergere un difetto più grosso di quello cercato.
  • ⚠️ La regola 5 di ORCHESTRAZIONE.md — «una JQL con fields:["summary","description"]», scritta come misura di risparmio — era FALSA, ed è stata corretta. L'MCP Atlassian non sa restringere i campi: provato chiedendo SU-467 con fields:["summary"], cioè il solo titolo, e sono tornati 9.400 caratteri di descrizione integrale. Stessa risposta dai due connettori configurati (atlassian e Rovo via claude.ai): è lo stesso server. fields riesce a togliere i campi piccoli (labels, priority, date) e ad aggiungere comment, ma summary, description, issuetype, project, status e assignee arrivano comunque.
  • La conseguenza vera non è l'involucro, è che non esisteva una lettura leggera di Jira. Di quei ~2.000 caratteri per ticket (tre URL self, expand, iconUrl, avatarId, entityId, quattro avatarUrls del progetto, statusCategory, webUrl) se ne usano 77: id numerico, chiave, tipo. Il 96% è morto, più un blocco context da 472 caratteri per risposta (sessionId, invocationId, featureFlags). Ma il costo che pesa davvero è un altro: non si poteva chiedere l'elenco dei titoli dello sprint senza pagare tutte le descrizioni intere — ~50k token per venti titoli.
  • E i commenti arrivavano SEMPRE tutti, mai solo l'ultimo. Su SU-198, 16 commenti = 53.111 byte, riversati a ogni fetch dello sprint, mentre la regola che conta («l'ultimo KO di Ivan ridefinisce il requisito») ne usa uno.
  • Lo script chiude tutt'e tre i buchi facendo passare il JSON da jq prima che entri in contesto. elenco → chiavi e titoli, 329 caratteri per lo sprint attivo contro i ~34.000 dell'MCP. sprint → testo integrale con gli ultimi 2 commenti. ticket SU-x [n] → un ticket, n commenti a richiesta. Sui 3 ticket dello sprint di oggi: 53.176 → 23.775 caratteri, −55% (SU-449 da sola ha 11 commenti per 25.302 caratteri).
  • ⚠️ Due ipotesi di partenza si sono rivelate sbagliate e sono state buttate, non aggirate. /rest/api/2/search risponde 410 Gone — la v2 di ricerca non esiste più, quindi l'elenco si fa in v3. E la v3 rende la descrizione in ADF: 21.350 byte contro 10.341, cioè il doppio del testo semplice. La strada che regge è mista: v3 search/jql per l'elenco (lì fields restringe sul serio: 319 byte) e v2 issue/<KEY>, che invece è viva, per il testo di un ticket.
  • Credenziali fuori dal repo. Il token è in ~/.jira/curlrc (permessi 600, mai nella riga di comando: curl -K), il file JiraApiToken.txt che Ivan aveva lasciato nella root è stato tolto — era ?? in git status, cioè a un git add -A dall'essere committato, e gli agenti fanno git add da soli. Aggiunta la rete in .gitignore (JiraApiToken*, *ApiToken*.txt), verificata ricreando il file: git non lo vede più. Installazione e rigenerazione in WORKFLOW/05_SETUP_CLI.md §4-ter.
• [change] /triage aveva zero JQL scritta, ed era il buco più caro del ciclo. Il comando diceva solo «ticket nuovi o aggiornati»: la query me la inventavo ogni volta, e «aggiornati» senza filtro pesca decine di ticket — a ~2.500 token l'uno, descrizione integrale forzata, ~100k token per fare un elenco. Ora il triage è in due passi: prima elenco con la JQL scritta nel comando (status = "Da fare" AND sprint IS EMPTY AND updated >= -7d), poi il testo integrale solo dei ticket che si sta per commentare.
• [fix] 02_SPRINT.md: la prosa e la JQL dicevano cose diverse. Il perimetro dichiarava «più eventuali "In corso" rimasti a metà» ma la query accanto aveva solo status = "Da fare". Allineata a status IN ("Da fare", "In corso"), e scritto in chiaro che «In revisione» e «Fatto» non si leggono mai.
• [change] Cache locale dei ticket: valutata e SCARTATA; al suo posto le decisioni dette in chat finiscono sul ticket subito. Ivan ha proposto di tenere i ticket in una cache locale presa una volta con /sprint, lavorarli lì e ogni tanto riversare l'evoluzione su Jira — e ha poi aggiunto lui stesso l'obiezione che regge: dopo le ottimizzazioni di oggi cambierebbe poco, perché il testo lo si scrive comunque in locale e sono ugualmente token.
  • Ha ragione, e i numeri chiudono la questione. L'involucro Jira è già tolto da tools/jira_leggi.sh; quel che resta è il testo del ticket, che pesa identico dall'API o da un file (i 10.341 caratteri di SU-467 sono gli stessi). Il controllo di freschezza costerebbe ~1.400 token per 20 ticket (fields=updated, ~239 byte a ticket): poco risparmio su poco. ⚠️ In cambio si prenderebbe il rischio peggiore del ciclo: una copia locale invecchia mentre Ivan scrive un KO dal telefono, e lavorare su un requisito vecchio è peggio che non avere la copia.
  • Il pezzo che valeva, dentro quella proposta, non era la cache: era che Ivan «ultimamente dà le risposte da riga di comando, più comodo che scriverle sui task». Quelle decisioni oggi si perdono — restano in conversazione, non sul ticket, e la sessione dopo rilegge da Jira un requisito già superato a voce. È uno dei modi in cui nasce un giro di KO. Non è teorico: lo Sprint 10 va dal 2026-08-18 al 2026-09-03, diciassette giorni.
  • Regola nuova (CLAUDE.md + 02_SPRINT.md): appena Ivan decide qualcosa che cambia un requisito, Claude lo scrive come commento sul ticket in quel momento, una riga — Deciso in chat (data): … — e nella descrizione se il cambiamento è sostanziale, perché è la descrizione a finire nei brief degli agenti. Ivan continua a rispondere da CLI senza aprire Jira. Un commento è durevole (sopravvive alla sessione che muore e alla compattazione), lo vede sulla board, e non può divergere da niente. Costo: ~60 caratteri.
• [change] CLAUDE.md: fuori la narrazione di passaggio, restano le scelte e il risultato. Ivan ha detto che durante una lavorazione scriviamo troppo: a lui serve il risultato finale con le scelte e i commenti, non gli intermezzi. Misurato sui transcript (~/.claude/projects/<progetto>/*.jsonl, separando per turno l'ultimo messaggio dai precedenti): in una lavorazione vera il 43% del testo prodotto sono messaggi di passaggio — 91 messaggi in una sessione, media 210 caratteri; 40% in un'altra. Sono token in uscita, i più cari, per righe che nessuno legge.
  • La discriminante non è la lunghezza, è annuncio contro scelta. Fuori «ora guardo X», «adesso misuro Y», «fatto, passo al prossimo»: la chiamata al tool mostra già cosa si sta facendo, scriverlo è raddoppiarlo. Restano un cambio di strada col perché, un'ipotesi caduta, un blocco, una scoperta che cambia il piano — e il messaggio finale, che è la consegna.
  • ⚠️ Un'eccezione tecnica, non stilistica: nei job in background l'ambiente pretende una riga per blocco di lavoro, perché un classificatore legge solo il testo dei messaggi per dire nella lista job se il lavoro procede — silenzio totale = job che sembra fermo. Lì il minimo è una riga breve, non un paragrafo, e vale lo stesso il divieto di annunciare le intenzioni. Nelle sessioni interattive il vincolo non c'è.
• [change] Nuovo tools/jira_scrivi.sh: molti ticket si creano da UN file, in UNA corsa, e a schermo escono solo le chiavi. Ivan ha chiesto se anche lo scrivere i ticket — quando ne passa tanti insieme — si potesse alleggerire. Sulla scrittura il conto è diverso dalla lettura: i token in uscita costano molto più di quelli in entrata e sono quasi tutto il costo, quindi il grosso non si vince con un trasporto migliore ma scrivendo meno (le regole di lunghezza in 01_TICKET.md). Quello che il trasporto può togliere, però, si toglie tutto.
  • Sparisce l'eco. Ogni createJiraIssue dell'MCP rimanda indietro il ticket appena creato con tutto l'involucro; lo script stampa solo SU-xxx titolo. Non dipende da come risponde Jira: jq filtra prima che il JSON entri in contesto, quindi è garantito dalla costruzione. Aggiunta la regola gemella: dopo la creazione non si rilegge il ticket per «verificare» — la chiave nella risposta È la conferma.
  • ⚠️ La validazione sta tutta PRIMA della prima scrittura. Lo script chiede a Jira i tipi validi (per SU: Bug, Epic, Funzionalità, Sottotask, Story, Task), controlla intestazione, tipo e corpo di tutti i ticket, e solo dopo crea. Un tipo sbagliato al settimo di dieci lascerebbe i primi sei creati e il rilancio li duplicherebbe; se un POST fallisce comunque a metà, il messaggio dice quanti erano già passati.
  • Provato senza sporcare la board: payload reale spedito prima con un progetto inesistente (Jira si lamenta solo del progetto) e poi col progetto SU vero e un tipo inventato (si lamenta solo del tipo). Auth, endpoint, forma del JSON, accenti/virgolette/«»/newline e gestione degli errori confermati. 📌 NON MISURATO: la POST che riesce davvero — servirebbe creare un ticket vero e cancellarlo, e non lo si fa sulla Jira di Ivan senza il suo ok.
  • ⚠️ La v2 è una scelta, non un residuo: la v3 pretende la description in ADF (per SU-467 sono 21.350 byte contro 10.341 di testo semplice), la v2 accetta la stringa. La v2 *search* invece è morta (410) — le due cose convivono e vanno tenute distinte.
  • Due trappole pagate mentre lo scrivevo, entrambe silenziose: csplit di BSD non conosce {*} e falliva senza dire niente (avevo pure silenziato il suo stderr) — sostituito con awk; e in «$titolo» bash inghiotte il » dentro il nome della variabile, perché è multibyte — servono le graffe, «${titolo}».
  • Misura che ha sorpreso: su SU-467 e SU-468, ticket fratelli, ci sono zero frasi identiche. Non si copia-incolla fra ticket dello stesso lotto: si rispiega la stessa cosa con parole diverse, che in token costa più del copia-incolla. Da qui la regola nuova: il contesto comune a un lotto si scrive una volta sola, nell'epic o nel primo ticket.
• [change] La prolissità su Jira non era condivisa: è per tre quarti nostra, e il tetto «≤6 righe» non teneva. Ivan ha corretto la diagnosi — nei commenti lui scrive solo ok, ko e cosa non va. I commenti lunghi sembravano suoi perché l'MCP li posta con il suo account, quindi il campo author dice «Ivan Bianco» anche per i nostri report: non è un campo affidabile per capire chi ha scritto cosa.
  • Misurato su SU-198 (16 commenti, 17.882 caratteri di testo): i 7 suoi fanno 3.973 caratteri (media 567, e quella media è già gonfiata da un solo KO lungo), i 9 nostri ne fanno 13.909 (media 1.545). Il 77% della massa è nostra. Quindi la leva è tutta dalla nostra parte e non c'era niente da chiedere a lui: si stringe la nostra disciplina. ⚠️ Un KO suo lungo resta legittimo: quando non funziona molto, «cosa non va» è un elenco — quello da 2.243 caratteri con gli screenshot allegati porta informazione, non rumore.
  • chiusura-ticket passo 6: commento ≤900 caratteri, in ordine fisso — cosa NON è provato (prima riga, sempre), i numeri che il ticket chiedeva, cosa deve guardare Ivan, il commit. Il vecchio tetto era «≤6 righe» e si aggirava da solo: sei righe da un paragrafo l'una. Il racconto del processo — come ci si è arrivati, i difetti risolti per strada, le correzioni alle proprie ipotesi — esce da Jira e va nel CHANGELOG, che è il posto dove il dettaglio deve stare.
  • La tabella della spunta si scrive ma non si incolla più per intero. Ivan le tabelle non le guarda; e il valore di quella tabella sta nel compilarla — è il passaggio che fa emergere i NON MISURATO, nato dal KO di SU-198 — non nel fargliela leggere. In Jira ci vanno solo le righe non FATTO: su un ticket con dodici criteri, una o due invece di dodici. Tutte FATTO = nessuna tabella.
  • 01_TICKET.md: quanto lunga la scrive Claude una descrizione. Fuori le alternative scartate (in SU-467 le cinque proposte per l'avviso del treno erano 2.127 caratteri; con la sola scelta fanno 466, −78%, senza perdere un requisito), fuori le lezioni già in memoria automatica (~900 caratteri pagati due volte), fuori la coda identica in fondo a ogni ticket. ⚠️ Non si accorciano mai i criteri con dentro un numero, le clausole «misurato non stimato», NON TOCCARE e FILE/SISTEMI SOSPETTI: un solo giro di KO costa più di tutte le descrizioni di uno sprint messe insieme.
  • rilavora-ko: il riconoscimento dei bocciati non cita più il fields dell'MCP: gli ultimi 2 commenti che porta lo script sono esattamente «l'ultima parola di Ivan» e «il nostro ultimo report», e si distinguono a colpo d'occhio perché i suoi cominciano con ok/ko.

Tre asset rigenerati: il treno prende spessore, la fermata perde il marciapiede, il rider sale in bici2026-08-20

• [feat] Il treno del livello bonus non è più una pianta: ora si vede il tetto E la fiancata. Il vecchio subway_train.png era una vista dall'alto perfetta — solo il tetto, 504×64 — e sottoterra si leggeva come un adesivo appiccicato sul pavimento invece che come un vagone che sta *sopra* i binari. Arte rigenerata con Codex partendo dallo sprite approvato, in vista top-down 3/4 come il resto del gioco.
  • ⚠️ Il numero che decide se il treno sta sui binari è la rotaia VICINA, e i due giri di Codex l'hanno mancata tutti e due. Il tassello del binario è 96×96 con le rotaie a y=31 e y=63 (scartamento 32) e il centro corsia a y=47; lo sprite è ancorato centrato su quel centro. Il tetto è la parte che sta sui binari, quindi entrambe le rotaie devono caderci dentro; la fiancata è il fianco che si vede per via della telecamera e sporge sotto, verso chi guarda. Col raw del secondo giro (tetto 57 px di gioco, fiancata 45) la rotaia vicina cadeva in mezzo ai finestrini e le ruote finivano 31 px sotto il binario: treno che galleggia davanti alle rotaie. E il totale, 102 px, sforava la corsia da 96.
  • Il primo giro sbagliava la proporzione, il secondo l'ha risolta al contrario: chiesto tetto 195 / fiancata 55 sulla tela, il primo ha fatto fiancata alta quanto il tetto, il secondo ha alzato il tetto invece di abbassare la fiancata — il treno è cresciuto da 281 a 300 px invece di scendere a 265.
  • Chiuso senza un terzo giro, riscalando le due fasce SEPARATAMENTE: tetto riportato ai 64 px di sempre (+12%), fiancata compressa a 26 (−42%). Non è un trucco: una parete laterale vista a 45° è schiacciata, quindi la compressione va nella direzione della prospettiva. Risultato 504×90: centrato sulla corsia occupa y 2..92 di 96, e la rotaia vicina cade esattamente dove il tetto finisce e comincia la fiancata. Scelta A di Ivan; la variante B (tetto 64 + fiancata 20, totale 84) resta in TMP/prompt_codex_20260820/ricevute/.
  • ⚠️ La larghezza non è negoziabile: TRENO_LARGHEZZA = 504.0 è una costante scritta a mano in BonusLevel.gd e l'urto si calcola su quella, non sulla texture. Un treno disegnato più stretto verrebbe colpito nel vuoto oltre la coda. L'altezza invece non la usa nessuno tranne l'ancoraggio, perciò zero righe di codice cambiate.
  • Nuovo tools/importa_treno_metro.py: scontorno del magenta con la stessa maschera di su305_importa_colpito.py, taglio sul confine tetto/fiancata, riscalatura separata delle due fasce, riduzione BOX su RGB premoltiplicati. ⚠️ Il rilevatore automatico del confine al primo tentativo dava la riga 9 di 300, e l'asset che ne è uscito era da buttare: il bordo *superiore* del treno (dal vuoto al tetto chiaro) è uno stacco di luminosità molto più violento del confine cercato. Corretto con due paletti — solo righe piene (>70% di pixel opachi) e solo la fascia centrale (25-75% dell'altezza), cercando il gradino verso il basso — ora trova la riga 170.
  • Misurato: sonda dentro Godot dopo il reimport → subway_train 504x90, centrato occupa 2..92 di 96, dentro la corsia. probe_su467.sh → 3 controlli falliti, ma gli stessi 3 falliscono anche col treno vecchio: texture ripristinata da git, reimport, sonda rilanciata, e il confronto dei verdetti combacia riga per riga (differiscono solo i valori dell'orologio, 0,3318 contro 0,3270, rumore fra due run diverse). Zero regressioni.
  • 📌 Quei 3 controlli falliscono da prima e non sono un difetto del gioco: è la sonda a essere vecchia. «I soldi non sono cambiati: atteso 167, osservato 177» è SU-468 che ha messo le monete lungo i binari — la sonda di SU-467 è stata scritta quando i soldi sottoterra non esistevano. Vanno aggiornati anche «RunManager è tornato allo stato di prima» e «il controllo in superficie muove davvero l'orologio».
  • I due fari sul muso, spariti nel primo giro, sono tornati nel secondo: servono, perché il gioco attacca al muso un fascio di luce additivo e senza lampade non si capirebbe da dove esce.
• [feat] L'ingresso della metropolitana perde il marciapiede che si portava dietro, e smette di stare appiccicato in fondo al lotto. Lo sprite era disegnato in piedi su una PIAZZOLA di pietra, ma _build_metro_block stende già il suo backdrop di marciapiede sotto la fermata: il selciato veniva disegnato due volte, uno sopra l'altro e disallineati. Arte rigenerata con Codex iterando sullo sprite approvato — via la piazzola, e scale rifatte perché la luce era al contrario.
  • ⚠️ Le scale avevano la luce al rovescio, ed è il difetto che Ivan ha visto per primo: i gradini illuminati stavano in FONDO e l'imbocco era nero, mentre la luce del giorno entra dalla bocca. Rifatte col gradiente giusto e misurato sulla prima versione, dal fondo verso l'imbocco: 14 → 25 → 37 → 58 → 85 → 122 → 151 → 158 di luminosità media, monotono, col fondo del vano fermo a 22-29.
  • ⚠️ Il primo giro è stato scartato perché TROPPO GRANDE, ed è una lezione sul cosa chiedere: il prompt diceva «riempi la tela» e Codex ha obbedito, consegnando un disegno da 103×115 px di gioco contro un lotto di 96×96. In città sbordava e dominava l'isolato. Il secondo giro è ripartito dall'ORIGINALE piccolo chiedendo solo le due correzioni e vietando esplicitamente l'ingrandimento: 86×75, dentro il lotto, zero sbordo.
  • 📌 Il cartello a rombo si perde se non lo si difende in ENTRAMBI i versi. Sulla versione grande Codex l'ha trasformato in un disco due volte di fila nonostante il divieto esplicito; iterando invece sull'originale, con l'ordine «è già un rombo, lascialo com'è», è arrivato intatto. Il rombo non è un capriccio: col disco la sagoma a schermo diventa identica al roundel della fermata del bus e le due fermate non si distinguono più a colpo d'occhio.
  • [feat] Il piazzamento dentro il lotto, rifatto su richiesta di Ivan (2026-08-20): «la scala deve essere centrata rispetto al quartiere» e «l'area di occupazione deve essere la minima possibile». Prima lo sprite era appoggiato al bordo inferiore del lotto — quindi tutta la striscia di marciapiede vuota restava SOPRA — e il muro invisibile prendeva il lotto intero, quindi dietro alla fermata non ci passava nessuno.
    • In verticale si centra il disegno: margine 10,5 px sopra e 10,5 sotto, misurati.
    • In orizzontale si centra il VANO SCALA, non il disegno: il cartello sporge a sinistra e centrare il disegno spingerebbe l'ingresso a destra. ⚠️ Con un clamp però, perché il disegno non deve uscire dal lotto: sul lotto d'angolo il cartello arriva a filo del bordo sinistro e il vano resta 7 px a destra del centro. Senza il clamp sarebbe centrato perfetto ma con il cartello fuori dal marciapiede.
    • Il muro non prende più tutto: copre solo la fascia bassa del disegno (staccionata, montanti, arco e vano scala), mentre la fascia alta — il chiosco dietro la balaustra — resta calpestabile, così il barbone ci passa dietro e il y-sort lo nasconde.
    • ⚠️ I due numeri del piazzamento (METRO_SCALA_CENTRO_X = 0.636, METRO_CHIOSCO_FRAZ = 0.28) sono frazioni della texture, non pixel: misurate sull'arte (montanti a x 380..908 di un disegno largo 791; balaustra a y 440 di un disegno alto 693). Se il disegno cambia si rimisurano quelle e il codice non si tocca.
  • Misurato (bash tools/autotest/probe_su465.sh → ESITO OK): su 12 semi le quattro celle restano agli angoli, ogni sbarco è ancora muri=0 nav=0.0 porta=18, i quattro salti tornano al punto di partenza con scarto 0,0 px, e con $0 il barbone non si muove. Nuova sonda bash tools/autotest/probe_metro_dietro.sh, che stampa la mappa del lotto punto per punto: le prime tre righe (24 px) sono libere, il resto è muro, «proprio dietro al chiosco: urti=0 → SI PASSA», «dentro il vano scala: urti=1 → bloccato, giusto».
  • 📌 Il fondo ombreggiato sembrava un difetto da rigenerare e non lo era. Nella versione grande Codex aveva dipinto in ombra il fondo magenta fra il chiosco e le ringhiere (#C531BB, 6892 pixel), e a occhio erano due macchie viola destinate a restare nello sprite. Invece la maschera di su305_importa_colpito.py le prende tutte e 6892, zero superstiti: era già risolto dallo scontorno. Registrato perché la prossima volta non ci si perda un giro di generazione a inseguirlo.
  • Nuovo tools/importa_fermata_metro.py: stessa catena del treno (scontorno magenta, premoltiplica, riduzione BOX) più il posizionamento nella cella 128×128, con --altezza che decide la taglia in gioco — ⚠️ la dimensione la sceglie l'import, non il prompt, perché _metro_texture() passa per _landmark_ritagliato() e il gioco ritaglia al contenuto: i margini della tela non li vede nessuno. Provini guardati in TMP/su465/.
• [feat] Il rider delle consegne non va più a piedi: ora pedala su una bici elettrica. Tutte e cinque le tavole rigenerate con Codex partendo dai fogli approvati — le due maschili, le due femminili e la drunk col ghepardo — e importate con lo strumento di casa tools/import_people_sprites.py (griglia 5×5 su magenta, righe S/N/E/SW/NE con la SW specchiata in SE, uscita 160×160 più il .tres). Il ciclo delle colonne da camminata diventa pedalata, con la regola di sempre: colonna 2 ≠ colonna 4, altrimenti pattina.
  • ⚠️ La paura era che la bici rimpicciolisse il rider, ed è stata smentita dalla misura. extract_and_resize inquadra ogni figura nel suo LATO MAGGIORE (side = max(w, h)) e la porta a 32×32: un ciclista di profilo è più largo che alto, quindi le righe di fianco rischiavano di essere scalate più di quelle frontali e il personaggio sarebbe cambiato di taglia girandosi. Contato su tutte e 125 le celle: l'altezza resta il lato maggiore ovunque (209-251 px contro 104-234 di larghezza), quindi la scala non cambia mai. E il rider non si accorcia: casco 6-9 px contro i 6-10 di prima, maglia che comincia alla riga 3 invece che alla 4. Il motivo è che la bici non si impila SOTTO di lui ma gli si sovrappone alle gambe — che è come sta davvero un ciclista, la cui testa resta all'altezza di quando è in piedi.
  • ⚠️ Di fronte e di spalle la bici quasi sparisce. Vista in testa una bicicletta è una riga, e a 32 px resta una macchia scura fra le gambe: il fronte si legge meno bene del pedone di prima. Di fianco e nelle due diagonali — cioè le pose che in un gioco dall'alto si vedono di più — ruote, telaio e rider in sella si leggono benissimo. Confronto appaiato nuovo/vecchio su tutte e cinque le direzioni in TMP/prompt_codex_20260820/ricevute/rider/CONFRONTO_rider.png.
  • Misurato: le cinque tavole si separano in 5 bande orizzontali e 5 verticali pulite e niente tocca il bordo della tela, quindi la detection automatica dello strumento non ripiega sulla griglia fissa; tools/check_magenta_residuo.py → 0 px residui su tutte e cinque; nessuna ombra a terra disegnata dentro lo sprite (0 celle su 25 per foglio) — l'ombra la mette il motore come sprite a parte; compile-check sui cinque .tres → 0 falliti; npc_variants_manifest.gd rigenerato identico al byte, quindi nessun cambio di codice.
  • 📌 timeout di Homebrew è x86_64 e trascina Python in Rosetta. Lanciando timeout python3 tools/import_people_sprites.py PIL non si carica («mach-o file, but is an incompatible architecture (have arm64, need x86_64)») e sembra che lo strumento sia rotto. Non lo è, e non è nemmeno colpa di Python (che da solo parte arm64): è il wrapper. Basta non incapsularlo.
  • ⚠️ [fix] Lo scontorno si mangiava il contorno di casco, divisa e zaino — visto da Ivan a occhio, poi isolato per ablazione. Il colpevole non era una soglia sbagliata ma uno scarto fra la docstring e il codice di is_dark_magenta_fringe (files/homeless_city/tools/import_chatgpt_sprites.py): la docstring prescrive «g≈0 in senso STRETTO», il codice però usava un margine assoluto (r > g+20 and b > g+20), che su un pixel scuro è quasi sempre vero. Così il contorno nero dello sprite, tinto di viola dalla riduzione LANCZOS — per esempio (53, 19, 45), col verde a un terzo del rosso — passava per «frangia di magenta», e expand_dark_fringe_from_seeds, partito da una sacca legittima, proseguiva dentro il disegno.
  • La misura che ha deciso, per ablazione (stesso foglio costruito due volte, una con l'espansione spenta): l'espansione toglieva 57 pixel su arch_delivery_v1, e 57 su 57 erano colore d'arte, zero fondo. Una frangia VERA invece è il fondo scurito, e il fondo ha g≈0 per costruzione: qualunque suo blend tiene g/max(r,b) attorno a 0,013, mentre i pixel mangiati stavano a una mediana di 0,117. Aggiunta quindi la condizione g > 0,05 · max(r,b) → non è frangia: l'espansione scende da 57 pixel a 8, ne recupera 51 su questo foglio, e la frangia vera resta rimossa. tools/check_magenta_residuo.py continua a dare 0 px residui su tutti e cinque i fogli, quindi non si è barattato un difetto con l'altro. Prima/dopo in TMP/prompt_codex_20260820/ricevute/rider/CONFRONTO_morsi_contorno.png.
  • ⚠️ Gli altri 94 fogli NPC NON sono stati rigenerati, ed è una scelta: la correzione vale per tutti, ma rigenerarli tutti oggi cambierebbe decine di sprite in un colpo solo. E c'è di più — provandolo si è scoperto che rigenerare i fogli committati con lo strumento di oggi li cambia comunque, anche senza questa correzione: 49 fogli su 54 toccati, con differenze di pixel vere (sul businessman 122 pixel e 7 opachi in meno). I fogli in repo sono stati costruiti con una versione precedente della pipeline. È una deriva da sanare con calma, in un ticket suo, non di straforo dentro l'import del rider.
  • 📌 assets/sprites/npc/accessories/ è vuota: acc_phone, che tocca al 50% dei rider, non disegna niente. Era un rischio vero — un overlay a piena cella disegnato per la posa in piedi, con le mani ora sul manubrio, sarebbe finito per aria — ma oggi non si pone. Se un giorno l'accessorio arriverà, va ridisegnato per la posa in sella.

Un tester Apple nella beta, e `VALID` che non voleva dire installabile2026-08-19

• [chore] Mauro Piccoli arruolato e invitato: il gruppo esterno TestFlight passa a 29 iscritti. Ivan ha portato nome, numero, mail e piattaforma insieme, quindi è valsa la scorciatoia della skill (niente messaggio di reclutamento, dritti alla registrazione della risposta). Riga 77 dell'Excel, ID 76, mauro.piccoli87@gmail.com in Email e in Utente App Store, iPhone = Sì, Avvisa tester = Sì; backup in Beta_Tester_Homeless_City.BACKUP-2026-08-19-pre-piccoli.xlsx. Invito Apple via API al «Gruppo esterno di test Divano» → stato INVITED verificato rileggendo l'elenco (28 → 29). Messaggio di conferma Apple (testo approvato il 2026-08-06) mandato dopo l'ok esplicito di Ivan sull'anteprima, success: true, Stato → Invitato.
  • 📌 La mail è @gmail.com ma il passo degli utenti di prova OAuth NON si applica, ed è il caso che rende esplicita la regola: quell'elenco serve a chi entra da Android/Play, perché su iOS il login è Sign in with Apple (EOS valida una sola audience per provider). Una gmail non basta a far scattare il doppio inserimento — a farlo scattare è la piattaforma.
  • Data invito lasciata vuota, come per i 37 «Invitato» su 47 che ce l'hanno vuota: la colonna è caduta in disuso e nessuno degli script la scrive. Non è una dimenticanza, è la prassi corrente.
• [fix] testflight_tester.py --build diceva VALID anche su una build che nessun tester esterno può installare. Il controllo prescritto prima di invitare («al gruppo è assegnata una build valida?») leggeva il processingState, che significa solo «il binario è stato elaborato». Una build appena caricata è VALID e insieme WAITING_FOR_BETA_REVIEW — ed è esattamente lo stato in cui la 0.30 è rimasta il 17/08, come racconta la voce di release. ⚠️ Chi arruolasse un tester Apple in quella finestra gli manderebbe la mail di Apple e il messaggio «da lì installi Street University», e il tester non troverebbe niente: un fallimento silenzioso, perché il controllo che doveva prevenirlo risponde verde. Ora --build interroga anche GET /v1/builds/<id>/buildBetaDetail e stampa la colonna «esterna», con un avviso esplicito se non è IN_BETA_TESTING. Verificato su questo giro prima di scrivere a Mauro: le quattro build del gruppo (0.30, 0.29, 0.28, 0.27.2) sono tutte IN_BETA_TESTING, quindi l'invito porta davvero a un gioco installabile. Trappola registrata in BETATESTING/messaggio_reclutamento_beta.md e nella tabella della skill arruola-tester.

SU-468: il premio del livello bonus, monete garantite e livelli da conquistare2026-08-18

• [feat] SU-468 — quello che si porta a casa dal tunnel. Due cose distinte, e la distinzione È il ticket: le monete lungo i binari sono la parte garantita, il bidone d'oro in fondo è quella da conquistare.
  • Le monete restano anche se perdi, e non c'è codice che le protegga: ogni moneta accredita SUBITO con GameState.add_money() nel momento in cui la tocchi, quindi non esiste nessun «bottino da consegnare all'uscita» che una sconfitta possa annullare. È il principio di SU-249 ottenuto togliendo un meccanismo invece di aggiungerne uno.
  • ⚠️ Tutte le monete valgono $1, e il conto spiega perché. I tagli sono 1/5/10 e Ivan ha chiesto 100-200 monete per l'effetto scenico; ma il primo ingresso costa $100, e qualunque moneta da $5 o $10 porterebbe il ciclo banca→tunnel a stampare soldi. La leva prevista dal ticket è esattamente questa — «si abbassa il VALORE delle monete, non il numero» — e al taglio minimo il valore non scende oltre.
  • ⚠️ NON si usa MoneyCoin: quella si raccoglie per collisione col Player, e sottoterra il barbone non è un Player. Le monete del tunnel si raccolgono a distanza dentro _passo(), la stessa scelta già fatta per i treni. Conseguenza utile: una sonda le raccoglie simulando i passi.
  • Il tiro sui livelli: arrivare in fondo paga sempre almeno un livello, il dado decide solo se ne paga due o tre (70/25/5). ⚠️ Non viola SU-249, che vieta il tiro su se il premio arriva, non su cosa c'è dentro.
  • ⚠️ I livelli non hanno una strada nuova: si riusano i tre esiti che ChestLoot sa già consegnare — LEVEL_UP, DOUBLE_LEVEL, CARD_LVL3. E la tabella a sei esiti del bidone d'oro, rimasta senza padrone da SU-466, la eredita il bidone grosso: non sostituisce il tiro, gli si affianca.
  • Il suono dei tre livelli (levelup_triple.wav), generato e tarato sul misurato, non a orecchio: come usciva dal generatore stava 6,9 dB sotto levelup_fanfare.wav — lo stesso errore già pagato una volta. Coda muta tagliata (2,00 → 1,51 s) e picco portato a −1,0 dBFS come i vicini: RMS finale −15,0 contro i −14,0 della fanfara, cioè 1,0 dB, dentro la distanza che già separa la fanfara dal level-up. Sorgente in Sounds_raw/ e prompt nel commento accanto alla costante (convenzione 11).
• [test] Misurato (bash tools/autotest/probe_su468.sh → ESITO OK): 157 e 184 monete nei due giri, nessuna delle 5 fette di corridoio vuota; schivando si arriva in fondo in 45,0 s esatti; perdendo a un terzo di strada i $10 già raccolti restano; su 200 tiri 72,5% / 22,5% / 5,0% e zero tiri a vuoto.
  • ⚠️ Il conto economico è sul RACCOLTO, non sul piazzato, ed è la correzione che cambia il verdetto: metà delle monete sta sulla corsia che non percorri, quindi dei $157 a terra se ne incassano $78 e $88 → medio $83 contro un biglietto da $100, cioè −$17. Il ciclo non stampa soldi: quello che compri sono i livelli. La prima versione del conto usava il piazzato e dava +$50, sbagliato di segno.
  • ⚠️ Due difetti trovati dalla sonda mentre la scrivevo, entrambi miei e istruttivi. Primo: camminando in linea retta il barbone veniva preso a 19,6 s su 45 e non arrivava mai in fondo, quindi la misura della raccolta rispondeva a una domanda che nessuno aveva posto — risolto riusando l'oracolo che schiva di probe_su467. Secondo: la cerimonia delle carte mette in pausa l'albero, quindi misurare i livelli mentre è aperta dà zero senza errori, ed è esattamente l'inciampo che il ticket aveva scritto nero su bianco. La sonda ora distingue «cerimonia aperta con la carta scelta» da «livello salito subito», e BonusRewards propaga cerimonia e carta proprio per rendere distinguibili i due casi.
  • 📌 Chiarimento che vale un ticket a parte se Ivan la vede diversamente: nella tabella d'oro «livello» NON è il livello XP del giocatore (il LIV 1 dell'HUD) ma una CARTA che sale di livello, via PowerUpSystem. È la strada di SU-248 che il ticket dice di riusare, anche se la nomina «XPSystem».
  • ⚠️ NON MISURATO: la catena delle cerimonie. Il tiro sui livelli e il premio della tabella aprono due cerimonie, e il ticket chiede che la sequenza sia «guardata davvero». Da un provino headless non si può: serve un playtest a mano.

SU-467: il livello bonus sotto la metropolitana2026-08-18

• [feat] SU-467 — si scende dalla fermata illuminata dall'arcobaleno e sotto c'è un corridoio sui binari. Due corsie, treni che entrano da destra e vanno evitati cambiando binario, buio, e in fondo il bidone d'oro grosso (che qui è solo il traguardo: i premi sono SU-468). [NOVITA']
  • Le due decisioni di Ivan del 2026-08-18, prese oggi in chat: camminata libera con la camera che segue (scartato lo scorrimento automatico, che su telefono ti spinge addosso a un treno e si legge come ingiustizia), e 45 secondi di lunghezza. Il conto non è stimato: il barbone va a 90 px/s (Player.gd), quindi LUNGHEZZA_PX = 45 × 90 = 4050, cioè ~42 tasselli e circa tre volte la larghezza della città.
  • Scena a sé, come TutorialWorld: non riusa World.gd/WorldGenerator (45 NPC, pattuglie, ondate meteo, difficoltà crescente: tutto sbagliato per una stanza premio) ma riusa gli stessi mattoni. È la scelta già scritta in testa a TutorialWorld, e la regola «ogni quartiere è una config, MAI una scena nuova» qui non si applica: questo non è un quartiere.
  • ⚠️ Il barbone di sotto NON è Player.tscn. Il Player vero pesa migliaia di righe agganciate alla run (elemosina, busking, superpoteri, fame, polizia, rete MP) e un secondo nodo nel gruppo "player" mentre quello di superficie è congelato sarebbe un guaio cercato. Sottoterra c'è un Node2D con l'AnimatedSprite2D del personaggio scelto, mosso a mano alla stessa velocità. Conseguenza utile: tutto avanza dentro _passo(delta, direzione), quindi una sonda simula il livello passo per passo senza input e senza aspettare 45 secondi veri.
  • La superficie è CONGELATA e rimessa esattamente com'era: il nodo città in PROCESS_MODE_DISABLED, i suoi CanvasLayer nascosti a parte (un CanvasLayer non eredita il visible del padre), e gli autoload che scorrono da soli fermati e ripristinati — GameState, DifficultyManager, WeatherSystem, SuperPower, RunManager. Orologio, fame, meteo e polizia riprendono da dove erano: chi prende il premio al 25° minuto non lo paga due volte.
  • Gli avvisi sono i chevron scelti da Ivan, in tre stadi col faro: a ~2,6 s i chevron si accendono a scalare nel verso di marcia, a ~1,5 s la sequenza accelera e il bagliore cresce da destra, poi passa il treno col fascio davanti.
  • Il numero che rende il livello giusto o ingiusto, misurato: cambiare corsia costa 96 px / 90 px/s = 1,067 s, quindi sul preavviso di 2,6 s restano 1,533 s di margine utile (il minimo richiesto era 1,5). Per uscire soltanto dalla corsia bastano 47 px = 0,522 s, cioè 2,078 s di margine.
  • Multiplayer: rifiutato all'ingresso, e provato che non sporca niente. Portare un giocatore in una scena separata mentre gli altri giocano è esattamente ciò che vieta la regola «mai pause globali in MP».
  • Misurato (bash tools/autotest/probe_su467.sh → ESITO OK, 56 controlli): due giri nella stessa run con semi diversi (474919 e 482838) e sequenze di treni che divergono dal secondo treno; si arriva a progresso 1.0 con scarto 0,00 px dal traguardo; bonus_level_ended(true, giro) emesso; la scena liberata, la città di nuovo processabile e visibile, i CanvasLayer riaccesi, gli autoload e RunManager tornati allo stato di prima. Perdendo contro un treno: fame, vite del gatto, soldi e orologio identici.
  • ⚠️ La prova del congelamento porta la sua controprova, che è la parte che le dà valore: gli stessi 40 frame muovono l'orologio di 0,296 s in superficie e di 0,000000 s sottoterra. Senza quel confronto, «zero» avrebbe potuto voler dire soltanto che la sonda non stava misurando niente.
  • Nessun SHADER ERROR nei log di sonda e provini, cercato esplicitamente: uno shader rotto sembra giusto, perché Godot ripiega sul materiale di default e il buio sparirebbe senza un errore visibile.
  • Tre provini guardati in TMP/su467/: il corridoio con la targa BONUS STAGE, il treno in arrivo coi chevron accesi e il faro, e il bidone d'oro illuminato in fondo col barbone accanto.
  • ⚠️ NON MISURATO: il device. Le luci 2D sono la cosa che sul telefono costa di più e su questo progetto il fill rate è già un problema noto (Honor 10): il livello va guardato su un telefono vero prima di dire che gira.
  • 📌 Il contratto per SU-468 è scritto nel file, non a voce: ## CONTRATTO DI INGRESSO E DI USCITA in testa a BonusLevel.gd dice come si entra, cosa succede alla run, come si esce, quale segnale avvisa che è finito, e dove si attaccano i premi (il nodo vuoto Premi, più traguardo_position(), lunghezza_corridoio(), progresso(), runner()).

SU-465 e SU-466: quattro fermate della metro, e l'arcobaleno cambia bersaglio2026-08-18

• [feat] SU-465 — quattro fermate della metropolitana, una per angolo. Paghi $1, scendi, e riemergi alla fermata successiva in senso orario: NO → NE → SE → SO → NO. Nasce da un problema vero, detto da Ivan così: ci sono mappe «che hanno gli edifici molto spostati tra di loro», e mezza run se ne va a camminare. [NOVITA']
  • Nessun sistema nuovo: BlockKind.METRO_STOP si prenota sui quattro angoli della griglia 8×8 con lo stesso _reserve_footprint() che già riserva rifugio, negozi, gattile e landmark. Così le fermate partecipano da sole alle regole di ingombro, marciapiedi e cestini d'angolo.
  • ⚠️ Type.METRO_STOP è andato IN FONDO all'enum di Interactable (regola di SU-181): i valori numerici finiscono dentro le scene salvate, e infilarlo in mezzo avrebbe rinominato ogni oggetto del mondo.
  • ⚠️ Attenzione al nome: nel gioco «metropolitana» significava già la schermata pre-run di scelta del quartiere (SU-123), che non è stata toccata. Nei testi queste sono «prendi la metro».
  • Direzione unica, decisa qui: con quattro fermate il giro si chiude in quattro salti e la più lontana dista comunque due salti, quindi una seconda direzione raddoppierebbe comandi e scritte per far risparmiare al massimo un salto. Togliere una direzione è più difficile che aggiungerla.
  • Misurato (bash tools/autotest/probe_su465.sh → ESITO OK), su 12 semi invece dei 10 chiesti: le quattro celle sono sempre (0,0), (7,0), (7,7), (0,7); ogni sbarco ha muri=0 e sta a 18 px dalla porta, quindi è calpestabile in tutte e quattro; quattro salti di fila riportano al punto di partenza con scarto 0,0 px e $4 spesi; con $0 il barbone non si muove di un pixel.
  • Provini guardati in TMP/su465/: la fermata in città col totem a rombo e il prompt «[E] Prendi la metro ($1)», e la mappa con le quattro icone agli angoli e la voce «Metro» in legenda.
• [feat] SU-466 parte 3 — l'arcobaleno della banca punta a una fermata, non più a un bidone. Chiude il ticket, che era rimasto aperto da stamattina in attesa che le fermate esistessero. La geometria e il faro dell'arcobaleno restano quelli di SU-249: cambia solo il bersaglio, cioè la fermata più vicina. [NOVITA']
  • ⚠️ La banca NON fa più comparire il bidone d'oro (chest_gold = true, quello che nasceva dal nulla). I forzieri dorati d'arredo che il generatore piazza per strada (chest_gold = false) non sono stati toccati: restano identici, tabella compresa. Erano due cose diverse col nome quasi uguale, ed è il punto in cui questo ticket si poteva sbagliare.
  • Provato, non dedotto: dopo 31 depositi la sonda legge conto $210, soglia $200, arco montato verso la fermata giusta, e bidoni d'oro in giro: 0.
  • Sulla fermata illuminata il prompt cambia invece di sdoppiarsi: da «Prendi la metro ($1)» a «Scendi: laggiù luccica qualcosa». Una fermata, un tasto, due significati a seconda di cosa sta succedendo — si capisce senza spiegazioni.
  • 📌 La tabella a sei esiti del bidone d'oro non muore di nascosto: la eredita il bidone grosso in fondo al livello bonus (SU-468). Scritto qui perché non sparisca in silenzio.
• [test] check_files.sh FALLITI 0 su 8 file, audit_emoji_pittogrammi.py 0. Sette chiavi nuove in ui_mondo.csv, tutte a 8 lingue.

Ivan approva l'arte della metro: il rombo entra in gioco, i sorgenti in archivio2026-08-18

• [change] SU-463/SU-464 approvati da Ivan (logo v1, il rombo con la M; segnali chevron a terra). Gli asset entrano nel progetto e i grezzi vanno in archivio, come vuole la convenzione 11.
  • ⚠️ Il rombo era rimasto dentro il disco. Il montaggio consegnato incollava l'emblema *dentro* il pannello tondo del totem: il rombo si intravedeva come sfumatura, ma la sagoma che si legge a schermo restava un disco — cioè la stessa silhouette del roundel del bus, che era esattamente la differenza per cui v1 era stato consigliato. Rifatto in modo che il rombo copra il disco: mezza diagonale ≥ raggio × √2 (112 contro 78), sennò gli spicchi del cerchio sporgono dai quattro lati. Ingombro invariato (contenuto 96×70 in (16,46)-(112,116), alfa ancora binaria), quindi la fermata resta allineata alla banca.
  • In gioco (assets/sprites/world/): landmarks/landmark_metro.png, map_metro.png, subway_track.png, subway_wall.png, subway_wall_bonus.png, subway_train.png, subway_train_beam.png, subway_floor.png, i quattro subway_warn_chevron_* e bin_gold_big.png. Solo i chevron: triangolo ed esclamativo restano in TMP/su464/, non scelti — meglio in TMP che come asset morti nel progetto.
  • In archivio (git LFS): sprites_raw/BUILDINGS/ (fermata e logo), sprites_raw/WORLD/ (binario, muro, targa, treno, faro, fondo, chevron), sprites_raw/OBJECTS/bin_gold_big.png — i PNG come sono usciti dal generatore, prima di taglio e riduzione: sono gli unici da cui si può rilavorare senza rigenerare. I prompt che li hanno fatti stanno in TMP/su463/PROMPTS.md e TMP/su464/PROMPTS.md, e finiranno nei commenti accanto alle costanti quando SU-465 e SU-467 li useranno.
  • I .import sono stati copiati dalla copia di lavoro invece di rifare l'import nel repo: check_files.sh lavora su un rsync in /tmp, e un import completo costa minuti.
• [docs] Committato MUSICA_AI_PROMPTS.md v1.1, che era rimasto sul disco senza commit da una sessione precedente: aggiunge la §12, i prompt della traccia di game over (giornale + classifica) — stessa famiglia sonora di NOTTEFONDA ma struttura, durata e regole sue. Aggiornato anche il rimando a World.gd:725 per il riavvio secco del loop. Non è lavoro di questo sprint: è stato committato su richiesta esplicita di Ivan perché non andasse perso.

SU-464: tutta l'arte del livello bonus sotterraneo2026-08-18

• [feat] SU-464 — generate in TMP/su464/ le sei famiglie di asset del livello bonus, da approvare. Ticket di sola generazione: niente entra in gioco, il «Fatto» di Ivan vale come approvazione e sblocca SU-467.
  • I numeri prima dei pixel, perché sono il vincolo di tutto: il barbone è 32 px — player_sheet.png è 160×160 e le regioni vere stanno in player_frames.tres (Rect2(0, 0, 32, 32)), non i 40 px che verrebbero dividendo la tela a occhio. I tasselli del mondo sono 96×96, la camera è a zoom 2.5. Da lì: corsia = un tassello 96, corridoio = 2 corsie + muro 64 = 256 px dentro i 288 visibili.
  • Consegnate: binario_tile.png 96×96 · muro_galleria_tile.png 96×64 e muro_galleria_bonus.png 192×64 · treno_metro.png 504×64 col muso a sinistra (entra da destra) e treno_faro_fascio.png 161×96 come pezzo separato · le tre famiglie di segnali in due intensità (triangolo 32×30, chevron 26×48 più due fotogrammi di sequenza 96×48, esclamativo 18×42) · bidone_oro_grosso.png 20×32, cioè alto quanto il barbone · fondo_tunnel_tile.png 96×96. Monete non generate: si riusa coin.png.
  • La cucitura è costata tre giri, ed è il punto del ticket: il primo tentativo lasciava una riga scura sul confine verticale, il secondo aveva troppo legno e nessuna piastra di fissaggio. Lo scartamento è finito a 32 px con 52 di stacco fra le corsie: è quel rapporto a far leggere *due binari* invece di *quattro rotaie equidistanti*, che era il difetto del ritaglio ingenuo. Provata con 8 tasselli affiancati su 2 righe e guardata: rotaie continue, nessun motivo che torna.
  • Sul fondo del tunnel sono state ritagliate via due macchie d'olio presenti nel grezzo: ripetute su griglia sarebbero state esattamente il difetto di park.png citato dal ticket.
  • BONUS STAGE non l'ha disegnata il generatore: la targa smaltata è nata vuota apposta e il testo è composto col font del gioco alla risoluzione finale — l'unico modo di non rischiare lettere storpiate. In inglese, come vuole la regola degli asset.
  • Provino d'insieme guardato (insieme.png, 1280×720 a ×2.5 come la camera, col barbone dentro): le proporzioni tengono. Il treno riempie la corsia e la copre — non ci si passa accanto, si cambia binario, che è la meccanica — e il bidone grosso arriva alla testa del barbone.
  • Segnali consigliati: i chevron. Sono gli unici che dicono anche *da che parte arriva*, e accendendosi a scalare fanno il conto alla rovescia senza scritte; stanno a terra e non coprono il treno. Il triangolo a 30 px ha il bordo nero che si mangia il giallo; l'esclamativo si legge benissimo ma non dice la direzione — buono come rinforzo, non da solo.
  • Verificato, non dichiarato: le sette misure combaciano al pixel con quelle promesse, zero pixel di alone magenta su tutti i PNG, nessun file del progetto Godot toccato (Codex confinato con -C TMP/su464/raw).

SU-463: la fermata della metropolitana, tre loghi da scegliere2026-08-18

• [feat] SU-463 — generati in TMP/su463/ gli sprite della fermata della metro, da approvare. Ticket di sola generazione: le immagini non entrano in gioco, il «Fatto» di Ivan vale come approvazione e sblocca SU-465.
  • Misure prese dal codice, non a occhio: i landmark sono tele 128×128 mai scalate (_build_landmark_block), centrate sul lotto con la base sul bordo basso e ~16 px di sbordo sul marciapiede. La banca ha contenuto opaco 95×104 in (16,11)-(111,115); la fermata ne ha 96×70 in (16,46)-(112,116) — stessa colonna x e stessa base, così sta in fila con gli altri landmark invece di ballare.
  • Un file solo, non base+tetto: la pensilina del bus è spezzata in due *solo perché il giocatore ci cammina sotto* (z separati). La fermata è un landmark pieno come la banca, quindi non si eredita un montaggio che non serve — è la risposta alla domanda 3 del ticket, presa guardando il codice.
  • Tre loghi inventati, nessun marchio reale (niente roundel di Londra, niente M cerchiata di Milano): v1 rombo con la M squadrata, v2 freccia che scende sotto una linea, v3 spirale di scale. Consigliato v1: è l'unico che a 20×20 — la taglia vera dell'icona da mappa — resta leggibile, e il verde stacca dal blu del bus prima ancora che si distingua il simbolo.
  • ⚠️ Cosa manca se Ivan sceglie v1: sull'edificio tutti e tre i totem sono tondi, il rombo vive solo nell'icona da mappa. Metà dell'argomento a favore di v1 (la forma diversa dal disco del bus) sul palo non vale. È un ritocco con PIL da fare all'approvazione, non un giro di generazione.
  • Provino d'insieme guardato (TMP/su463/confronto.png): banca, pensilina e fermata affiancate su isolati veri da 96 px con strada e marciapiede del gioco, più le quattro icone da mappa a taglia vera sul fondo della carta. La fermata si legge come «qui si scende» — recinto verde, SUBWAY sull'architrave, pozzo nero — e non si confonde con la tettoia azzurra del bus.
  • Verificato, non dichiarato: alfa binaria (0 semi-trasparenze su tutti i PNG), riduzioni BOX su alfa premoltiplicata, zero magenta residuo, icone 20×20 come map_bus_shelter.png. Scritte dentro lo sprite in inglese.
  • Scartate due stazioni su tre: la prima aveva una piazzola a rombo isometrico fuori squadra con la griglia, la terza la palette spenta. TMP/su463/PROMPTS.md conserva i prompt esatti per la convenzione 11.
  • Nessun file del progetto Godot toccato: Codex confinato con -C TMP/su463, verificato con git status.

SU-466 (parti 1 e 2): la soglia della banca raddoppia, e il conto si legge sul tetto2026-08-18

• [feat] SU-466 parte 1 — la soglia parte da 100$ e RADDOPPIA a ogni premio: 100 → 200 → 400 → 800. Decisione di Ivan del 2026-08-18. Il raddoppio vive e muore dentro la singola partita: a partita nuova si riazzera a 100, MetaProgress non c'entra.
  • La costante fissa BANK_GOLD_THRESHOLD = 50 diventa BANK_GOLD_THRESHOLD_BASE = 100 (costante) più bank_gold_threshold (stato di run, azzerato con tutto il resto). ⚠️ Il nome è stato cambiato apposta: riusando quello vecchio il compilatore non avrebbe segnalato nessuno dei lettori, e qualcuno sarebbe rimasto a leggere la base credendo di leggere la soglia corrente.
  • Il resto oltre la soglia sopravvive: 110 depositati con soglia 100 → premio riscosso, conto 10, soglia nuova 200, contatore 10/200$.
  • ⚠️ Il raddoppio È il limitatore anti-farming e sostituisce ogni altro tetto: nessun «una volta per run», nessun raffreddamento.
• [feat] SU-466 parte 2 — sopra la banca compare quanto hai depositato (0/100$, 50/100$, 10/200$). Nel mondo, non nell'HUD: la banca è una sola per mappa ed è lei a dover dire a che punto sei mentre ti avvicini.
  • BankCounter.gd è un Label agganciato al segnale bank_changed: niente _process, niente ricalcolo. L'unico modo di far cambiare quel testo è muovere il conto per davvero — ed è per questo che gli scatti provano qualcosa.
  • ⚠️ Difetto trovato e corretto durante il lavoro: staccata sopra il tetto la scritta finiva a 3 px dal bordo alto dello schermo e spariva proprio depositando (la camera segue il barbone, che sta davanti alla scalinata). Ora è appoggiata 6 px dentro il colmo del tetto — si legge da tutta la piazza, e sembra l'insegna della banca.
  • Il denominatore è la soglia corrente: è la prova a schermo che il raddoppio funziona. Font del tema, contorno nero, niente emoji; chiave MONDO_BANCA_CONTATORE nelle 8 lingue.
• [fix] L'invariante di SU-249 stava per rompersi in silenzio, e la sonda l'ha preso. Alzando il primo deposito da 50$ a 100$, il caso peggiore del bidone d'oro (ChestLoot.GOLD_MONEY_MIN = 90) sarebbe stato sotto il deposito: cioè il giocatore poteva mettere 100 e riaverne 90 — esattamente ciò che SU-249 vieta («se il deposito può non pagare, si è costruito il gioco d'azzardo dentro un gioco sulla povertà»). Portato a 100-130, tenendo la stessa forbice di 30$ di prima. Il legame non è affidato alla memoria: probe_su363.sh confronta il minimo con BANK_GOLD_THRESHOLD_BASE e diventa rosso se qualcuno rialza la soglia senza guardare la tabella.
  • ⚠️ Il confronto vale sul PRIMO deposito. Dal secondo la soglia raddoppia mentre il premio non scala: è voluto (è il freno del sistema), ma finché il livello bonus non esiste il secondo ciclo è in perdita. Stato di passaggio, non bilanciamento definitivo.
• [test] Misurato (bash tools/autotest/probe_su466.sh → OK): premi a 100, 200, 400 con la soglia che sale a 800; 110/100$ → riscosso → 10/200$; reset_run_state() riporta a 100; morire con 90$ sul conto dà 9 lattine. Il contatore è centrato sull'edificio (342 contro 342) con 6 px di appoggio. Tre scatti guardati in TMP/su466/. probe_su249.sh OK (nessuna regressione), probe_su363.sh tornato OK, check_files.sh su 10 file FALLITI 0, audit emoji 0.
• ⚠️ PARTE 3 NON FATTA, e il ticket resta aperto: l'arcobaleno continua a puntare al bidone d'oro, che la banca continua a far comparire. Punterà a una fermata della metropolitana quando le fermate esisteranno (SU-465, ferma sull'approvazione dell'arte di SU-463). Non toccati: RainbowArc.gd, _posto_bidone_oro(), la tabella dei forzieri d'arredo.

SU-460: le registrazioni dei device si archiviano su iCloud con un comando2026-08-18

• [feat] SU-460 — la domanda aperta ha avuto risposta, e da lì è nato lo strumento. Ivan: «google drive ha pochi gigabyte mentre iCloud ha almeno 1 terabyte libero, volevo immagazzinare le registrazioni dei device lì; magari posso usarle direttamente da google drive ma a un certo punto come archivio le passerei su iCloud per liberare spazio su google». Le «registrazioni dei device» sono i file di telemetria delle partite (RunRecorder → Web App Apps Script → Drive), non video.
  • È un comando a mano, non uno schedulato: il piano con launchd scritto in DICHIARAZIONI_STORE_TELEMETRIA.md non è ciò che Ivan ha chiesto — lui vuole usarle da Drive e spostarle «a un certo punto».
  • Zero API, zero credenziali, zero dipendenze: le due cartelle sono già montate come cartelle locali sincronizzate su questo Mac, quindi archiviare è copiare. Niente pyicloud, niente rclone.
  • tools/archivia_telemetria_icloud.sh: mantiene la struttura AAAA-MM/, di suo copia e basta (la cancellazione da Drive è dietro --cancella-da-drive e avviene solo dopo la verifica), --dry-run per vedere cosa farebbe, idempotente. La verifica del demone bird di backup_su460_icloud.sh è stata estratta in tools/lib_icloud_verify.sh e ora la usano entrambi: una funzione sola, non due copie che divergono.
  • ⚠️ La garanzia, detta com'è: il digest SHA-256 per file prova che la copia locale è bit-identica; la conferma di bird è per tempistica sul lotto, perché macOS redige i percorsi nel log — prova che il demone si è mosso, non che quel file preciso sia già sui server Apple. E un file appena copiato ma non ancora sincronizzato esiste per una finestra di tempo in un posto solo.
  • ⚠️ Difetto trovato in chiusura e corretto: find -mtime +N vuol dire «più vecchio di N×24 ore», quindi --giorni 0 non vuol dire «tutto» — escludeva le ultime 24 ore, e il consuntivo non lo diceva: sull'archivio vero 40 file su 53 restavano fuori in silenzio. Ora la prova a vuoto e il consuntivo dichiarano sempre Registrazioni in cartella / LASCIATE FUORI dal criterio, e la riga del criterio spiega la semantica. Una copertura tagliata senza dirlo si legge come «ho guardato tutto».
  • Provato, non dedotto: archivio vero oggi = 53 file, ~119 KB, tutti nel mese corrente → col criterio «mesi chiusi» oggi non c'è niente da archiviare, ed è il caso giusto. Ramo reale esercitato su sorgente finta in TMP/: 3 copiati col digest, 1 escluso e dichiarato, uscita 2 quando bird non conferma (non dichiara un successo che non ha osservato), uscita 0 e 3 saltati al rilancio. Il ramo distruttivo è stato provato solo su file finti: il Drive vero non è stato toccato.
  • ⚠️ Nota di repo: le tre righe di documentazione sono andate in BETATESTING/DICHIARAZIONI_STORE_TELEMETRIA.md, che è gitignorato (dati dei tester) — quindi vivono solo su disco e non entrano in questo commit.

SU-452: il tetto agli abbattimenti sparisce, il giullare resta l'unica eccezione2026-08-18

• [fix] SU-452 (KO di Ivan) — abbattere un nemico paga SEMPRE, senza limiti al minuto. Il giro precedente aveva letto la riga della descrizione «serve un tetto o un raffreddamento, sennò si fa il pieno stando fermi» come un requisito, e aveva costruito una finestra scorrevole a 3 abbattimenti pagati ogni 60 s ($36/min), misurandola pure. Era una preoccupazione della descrizione, non una richiesta: «gli altri nemici devono SEMPRE lasciare monete a terra quando abbattuti, nessun tetto al minuto».
  • Rimozione completa, non una costante messa alta: spariscono ENEMY_TAKEDOWN_WINDOW, ENEMY_TAKEDOWN_MAX_PER_WINDOW, la lista di stato _enemy_takedown_paid_ms e la funzione enemy_takedowns_paid_in_window(). Un tetto a 999 sarebbe ancora un tetto, e al primo che legge il codice sembrerebbe un requisito. Verificato con un grep dei quattro identificatori su tutto il progetto: 0 occorrenze.
  • pay_enemy_takedown_loot() conserva la sola guardia _net_is_client, che è correttezza di rete e non un freno: l'autorità resta l'host, le monete si sorteggiano una volta sola e viaggiano a tutti con _cl_coins_scattered. ENEMY_TAKEDOWN_LOOT = 12 non cambia — il KO non tocca il quanto.
  • ⚠️ Al posto del tetto è rimasta una nota, non un buco: accanto alla costante c'è scritto che il limite c'è stato, chi l'ha tolto e perché. Chi domani lo reintroduce credendo di riparare una dimenticanza va contro un KO scritto. Corretto anche il commento in ModularNPC.gd che rimandava ancora «al tetto in World».
  • Il giullare era GIÀ conforme e non è stato toccato: ModularNPC._drop_takedown_loot() esce subito su JESTER_ARCH_ID, quindi lui lascia la CARTA DORATA e basta — un premio solo. Provato, non dedotto.
  • Misurato (bash tools/autotest/probe_su452.sh, sonda riscritta perché quella vecchia misurava il tasso al minuto, cioè la domanda del giro bocciato): 10 abbattimenti ravvicinati → 10 pagamenti, $120 su $120, zero buchi; il percorso vero lascia $12 in 8 monete e il barbone le raccatta davvero (+$9 nel tempo dello scatto); il giullare dà 1 carta e 0 monete. La sonda gira ora in pochi secondi invece di ~5 minuti: non deve più aspettare un orologio.
  • Provino guardato: TMP/su452/su452_dopo.png — il tossico al tappeto, la nuvola della zuffa e le monete dorate ai piedi. Come provarlo a mano: F1 → SPAWN NEMICI → «Abbatti nemico vicino», più volte di fila: pagano tutte.
  • ⚠️ NON MISURATO: il multiplayer. La strada host→client è stata letta, non eseguita: nessuna sessione MP vera.

SU-458: i fogli da cui nascono le icone smettono di stare solo sul Mac2026-08-18

• [fix] SU-458 (KO di Ivan) — i sorgenti del font delle icone entrano in git LFS. Il giro precedente li aveva salvati dal cestino ma lasciati fuori dal repo, e lo aveva pure scritto («non li ho committati di mia iniziativa: decidi tu»). Ivan ha deciso: «i fogli sorgente delle icone non sono tracciati da git, vanno tracciati con LFS». Erano l'unica copia esistente al mondo dei fogli da cui si rigenera StreetU-Icons.ttf: un disco che si rompe e le 71 icone del gioco non si potevano più rifare se non rigenerandole da zero.
  • Tracciati 32 file in sprites_raw/UI/icon_batches/: i 15 fogli batchA…batchN (batchF c'è due volte: l'originale e il rifacimento batchF_redo), i 2 riferimenti che li hanno guidati (_rif_righello.png, _rif_stile_esistente.png) e i 15 log di generazione.
  • ⚠️ I log ci sono andati apposta, non per distrazione: dentro c'è il prompt integrale di ogni foglio — stile, griglia, elenco ordinato delle icone. È la provenienza che la convenzione 11 chiede di non perdere, e questo è l'unico posto dove sopravvive. 676 KB di testo: costano niente, e senza di loro un foglio si può riguardare ma non rifare.
  • Nessuna eccezione al divieto di committare gli asset raw: .gitattributes ha già sprites_raw/** filter=lfs, quindi in git entrano 32 puntatori da ~130 byte e i 7,9 MB veri stanno in LFS. Verificato blob per blob prima del commit, non dedotto.

I sorgenti degli asset generati entrano in archivio, e diventa una regola2026-08-18

• [docs] Regola nuova, convenzione 11 di 00_CONTESTO_PROGETTO.md: ogni asset generato che Ivan approva va ANCHE nei sorgenti. Sue parole: «quelli generati li voglio anche come wav in Sounds_raw per completezza, SEMPRE da qui in avanti quando ti confermo qualcosa, lo stesso vale per gli sprite che generi». Scritta lì e non solo in una chat, così entra nelle capsule di contesto dei brief e vale anche per gli agenti dei prossimi sprint.
  • Al momento dell'approvazione, non della generazione: finché una cosa è in prova non sporca l'archivio; quando è approvata, si archivia.
  • ⚠️ Si archivia il file COME È USCITO dal generatore, prima di taglio, normalizzazione o riduzione. Nel gioco vive la versione lavorata (.ogg compresso, .wav tagliato, PNG ridotto); nei sorgenti quella grezza — è l'unica da cui si può rilavorare senza rigenerare. Archiviare solo il prodotto finito significa che la modifica successiva riparte da un file già compresso.
  • Il prompt che ha generato l'asset resta nel commento accanto alla costante che lo usa: senza, il sorgente si può riascoltare ma non rifare.
• [change] Archiviati i cinque sorgenti approvati oggi in Sounds_raw/ (git LFS): score_tick, reward_chime, raid_siren, levelup_fanfare e SU_GAMEOVER.wav — quest'ultima è la musica del game over, che era rimasta solo nei Download di Ivan e nel gioco come .ogg compresso.

SU-462: la Grande Retata si incassa, colpo su colpo2026-08-18

• [feat] SU-462 — la retata non uccide più al primo tocco. Richiesta di Ivan: «ogni colpo che ti dà un poliziotto fa scendere la vita di un punto, così dura lo stesso poco ma almeno dà l'impressione che puoi ribellarti anche se non c'è via di scampo». L'esito non cambia — dalla retata non si scappa — cambia la sensazione.
  • Il meccanismo c'era già e non se n'è inventato un secondo: i colpi della retata ora passano da GameState.lose_life(), la stessa porta di ronda, rivale, gattara, tossico, spazzino e giullare. Quindi arrivano gratis le teste di gatto che calano una per volta, il cuore che vola, il contraccolpo e l'avviso «ULTIMA VITA»: zero elementi nuovi a schermo, zero stringhe, zero chiavi nei CSV.
  • on_local_captured() è diventata on_local_raid_hit(): un colpo, non la fine. La run la chiude un punto solo, quello dell'ultima vita.
  • I numeri, col conto: raffreddamento 1,0 s, una vita a colpo → con 9 vite si resiste 8 secondi, con 3 vite 2 secondi, con una vita si muore al primo tocco come prima. Un secondo è il doppio dello stordimento da gatto (0,5 s), così la gattata resta comica e non diventa una via di fuga.
  • ⚠️ Il raffreddamento sta dalla parte di chi lo prende, non dei poliziotti, ed è la differenza che conta: per-agente, cinque poliziotti addosso avrebbero fatto cinque volte il danno.
  • ⚠️ La trappola del punteggio, evitata: register_raid_survival stava dentro la funzione della cattura — diventata «il colpo», sarebbe stata chiamata a ogni colpo, gonfiando il punteggio senza dare errore. Ora la chiama solo il punto che chiude la run. E la prova non conta le chiamate: i primi otto colpi girano a un tempo di sopravvivenza alto e l'ultimo a uno basso, e il punteggio finale vale il basso — se fosse registrata ogni volta varrebbe l'altro.
  • La carta «nove vite» resta esclusa contro la retata: incassare qualche colpo è una cosa, sopravvivere sarebbe un'altra. Verificato dalla sonda con la carta in mano.
  • Misurato (bash tools/autotest/probe_retata_vite.sh, 29 controlli, 0 KO): 9 vite → otto colpi non chiudono niente e solo il nono finisce con la causa giusta; una vita → un colpo → fine; zero vite → chiude lo stesso senza stati strani. Tre controprove, che sono la parte che dà valore al verde: senza raffreddamento i colpi diventano 9 in un frame (contro 3 in 2,5 s), il vecchio percorso riprodotto muore al primo tocco con le vite intatte, e con RAID_HIT_COOLDOWN = 0 la sonda va a 5 KO — cioè sa fallire. Più una prova end-to-end con un poliziotto vero in città.
  • ⚠️ NON MISURATO: il multiplayer. La strada host→client è stata letta, non eseguita: nessuna sessione vera. E l'RPC è stato rinominato, quindi peer con build diverse non si capirebbero su questo evento — da tenere presente al prossimo rilascio.
  • Aggiunto un bottone «Colpo retata» nel pannello F1, per provarlo senza aspettare i 30 minuti.

Salire di livello e vincere una carta non suonano più uguali2026-08-18

• [fix] Correzione di Ivan: la schermata delle carte serve due momenti diversi — si sale di livello, oppure il bidone d'oro consegna una carta — e nel giro precedente li avevo fatti suonare allo stesso modo, mettendo il chime del premio in entrambi. Sono due cose diverse e ora suonano diverse.
  • La distinzione esisteva già nel codice e non è servito inventarla: _full_fan è vero solo quando è il bidone a chiedere il ventaglio completo, _forced_card quando è la roulette. Quindi: ventaglio del bidone e roulette → chime del premio; livello salito → fanfara.
  • Suono nuovo, assets/sounds/levelup_fanfare.wav (1,20 s): arpeggio breve in salita, stessa famiglia FM 16-bit degli altri tre, ma che va verso l'alto — è un livello che sale, non un premio che arriva.
  • Il jingle storico levelup.wav resta nel progetto come ripiego.
  • ⚠️ NON MISURATO: come suona. Generato da una descrizione e rifinito sui numeri, non ascoltato.

La sirena annuncia la retata, non l'arresto2026-08-18

• [fix] La sirena della Grande Retata si è spostata dove serve. Richiesta di Ivan dopo l'ascolto: il suono va bene, ma suonava quando ti arrestano — cioè annunciava una cosa già successa. Una sirena serve ad avvisare, non a commentare. Ora parte quando la retata comincia.
  • Agganciata a raid_started, dove l'HUD mostra già il banner «GRANDE RETATA! LA SQUADRA SGOMBERO È IN STRADA!». Prende il posto dell'allarme generico che suonava lì: _sfx_danger_player è lo stesso avviso di fame e sonno, e sommarci la sirena avrebbe fatto due allarmi insieme. Quello generico resta al suo posto per gli altri pericoli — verificato che sia ancora in uso, non l'ho lasciato orfano. E resta come ripiego della sirena, se il file mancasse.
  • Tolta dal game over: la funzione che la faceva partire alla fine è stata rimossa, non svuotata, e con lei la sua connessione al segnale. Nessun riferimento orfano.
  • Conseguenza da sapere: al game over ora resta solo la musica, per qualunque causa — coerente con la scelta di spegnere il trombone.

Il suono del premio arriva anche prima delle carte2026-08-18

• [change] Quando compaiono le carte suona il chime del premio, non più il jingle del livello. Richiesta di Ivan: lo stesso suono del bidone d'oro deve arrivare prima che le carte compaiano, in tutti e due i modi in cui arrivano — il ventaglio da cui si sceglie e la roulette della carta forzata.
  • Prende il posto di levelup.wav invece di aggiungersi: due suoni sovrapposti sarebbero stati peggio di entrambi. E il chime è quello che chi gioca ha già imparato a leggere come «premio», avendolo appena sentito aprendo il bidone.
  • Il jingle non è stato buttato: resta come ripiego del chime, cioè se un domani quel file sparisse si torna al suono di prima invece che al silenzio. È anche il modo in cui la costante SFX_LEVELUP resta agganciata a qualcosa invece di diventare codice morto — verificato che non ne restassero chiamate orfane.
  • ⚠️ NON MISURATO: come suona nel flusso completo. Il chime ora si sente due volte a distanza ravvicinata — all'apertura del bidone e alla comparsa delle carte. Sulla carta forzata ci sta (sono due momenti distinti: il bidone si apre, poi la roulette gira); sul ventaglio potrebbero risultare vicini. Se all'ascolto è troppo, si toglie da uno dei due punti.

Il bidone d'oro e la Grande Retata cambiano voce2026-08-18

• [change] Il bidone d'oro usa lo stesso suono del punteggio, che a Ivan è piaciuto: il file è stato rinominato reward_chime.wav (era score_total.wav) perché ora vive in due posti e un nome che parla solo di punteggio avrebbe mentito a chi legge.
  • ⚠️ Il trabocchetto era una temporizzazione: Interactable tiene il bidone nell'albero, invisibile, finché il suo suono non è finito, e i commenti dichiaravano «kaching.wav dura 2,000 s misurati». Il suono nuovo ne dura 1,48. Il meccanismo non si è rotto — aspetta il segnale di fine e usa il tetto solo come rete — ma i numeri scritti erano diventati falsi, e un numero falso in un commento è peggio di nessun numero: sono stati aggiornati.
  • coin.wav non è stato toccato, per scelta di Ivan: monete raccolte, carte e superpoteri suonano come prima.
• [change] La Grande Retata non fa più «ka-ching»: adesso è una sirena da bombardamento. Richiesta di Ivan, e il senso è opposto e giusto — sul momento in cui ti prendono c'era il suono di un registratore di cassa, ereditato da SU-86 come «ka-ching di fine run».
  • Nuovo assets/sounds/raid_siren.wav (3,48 s): un unico lamento che sale e scende, meccanico, come da un vecchio altoparlante di strada. La costante è stata rinominata da SFX_KACHING a SFX_RETATA, perché il nome vecchio ora descriverebbe il suono sbagliato.
  • ⚠️ NON MISURATO: come suonano. Generati da una descrizione e rifiniti sui numeri (durata, inviluppo, picco), non ascoltati. In particolare la sirena esce con un picco basso (−13,8 dB): se all'ascolto risulta debole per un momento così, va alzata.

Suoni nuovi per il punteggio di fine partita2026-08-18

• [change] I due suoni del resoconto punteggio sono nuovi, generati su richiesta di Ivan («sono orribili»): assets/sounds/score_tick.wav e score_total.wav, in famiglia FM 16-bit come la musica del gioco.
  • ⚠️ NON sono stati sostituiti coin.wav e kaching.wav, ed è la parte importante. Quei due file sono usati in mezzo progetto: le monete raccolte (Player, NPC, ModularNPC), le carte del livello, i forzieri di Interactable e due superpoteri. Peggio: Interactable contiene una temporizzazione che dipende dalla durata misurata di kaching.wav (2,000 s). Sostituirli avrebbe cambiato suono a mezzo gioco e rotto quel meccanismo, senza un errore a segnalarlo. La richiesta riguardava il punteggio: cambia solo il punteggio.
  • score_tick è volutamente cortissimo — 0,26 s con dissolvenza in coda — perché il resoconto lo risuona una volta per riga con il tono che sale fino al doppio: un suono con coda, o tagliato di netto, a tono raddoppiato diventa uno schiocco. Il taglio con dissolvenza è quello che evita il clic.
  • score_total (1,48 s) è l'accordo che chiude quando tutte le righe sono atterrate.
  • Entrambi normalizzati alla stessa intensità percepita, così il secondo non arriva più debole del primo.
  • ⚠️ NON MISURATO: come suonano. Li ho generati da una descrizione e rifiniti sui numeri (durata, inviluppo, picco), ma non li ho ascoltati. Il giudizio è di Ivan: bash tools/autotest/gioca.sh, F1, slider Fame a 0.

SU-454: perché su Android il «cancella» non cancellava2026-08-18

• [fix] SU-454 — il tasto «cancella» torna a funzionare sul telefono, e la causa era il rimedio precedente. Ivan: su iPhone il campo si svuotava al primo tocco, sull'Honor non succedeva niente e bisognava rientrare nella casella.
  • ⚠️ Misurato invece che indovinato, ed era il terzo tentativo: un log diagnostico piazzato in due punti (sul campo e sul menu) ha registrato, mentre Ivan premeva cancella, solo VolumeUp e VolumeDown — i tasti fisici del telefono. Del «cancella», nessun evento, da nessuna parte. Su Android quel tasto non viaggia come tasto: passa dal meccanismo di composizione del testo di sistema, che tiene un proprio buffer.
  • La causa era la cura di poche ore prima: la selezione automatica al fuoco. Con tutto il testo selezionato, quel buffer non sa cosa cancellare e il tasto resta inerte; al secondo tocco la selezione non viene rifatta, il cursore si posiziona e il tasto torna a rispondere — che è esattamente il sintomo descritto da Ivan. La lettera invece funzionava sempre, perché quella passa dal campo e sostituisce la selezione.
  • Rimedio: la selezione resta dove funziona e sparisce dove nuoce — attiva su desktop e iPhone (dove il primo tasto sostituisce tutto, come voluto), spenta su touchscreen Android, dove il cancella torna a togliere una lettera per volta come in qualunque altra app. Scelta di Ivan fra tre strade proposte.
  • Rimossi i due tentativi falliti invece di lasciarli sedimentare: la rete che intercettava il tasto (inutile — quegli eventi non arrivano) e i log diagnostici, che avevano finito il loro lavoro. Verificato che non resti nessun riferimento orfano.
  • 📌 La lezione che vale oltre questo ticket: due piattaforme mobili hanno dato risposte opposte allo stesso codice, e la differenza non era visibile né dal Mac né dal compile-check. Solo il device l'ha detta — e solo dopo aver smesso di provare rimedi e aver messo un log.

Game over: brano nuovo, attacco secco, trombone zitto2026-08-18

• [change] Seconda passata sulla musica del game over, su richiesta di Ivan dopo l'ascolto. Tre modifiche, tutte reversibili con una costante:
  • Brano nuovo: GameOver.wav rigenerato, ora 2:31 invece di 2:49. Riconvertito in OGG (28 MB → 2,8 MB).
  • Dissolvenza in entrata SPENTA (MUSIC_GO_FADE_IN_SEC = 0.0): la musica parte subito al suo volume, così si sente l'attacco per intero. ⚠️ Il codice salta il tween quando la durata è zero invece di lanciarne uno da zero secondi: in pausa un tween istantaneo può lasciare il volume al valore di partenza, cioè far partire la musica muta. Rimettendo un numero maggiore di zero la dissolvenza torna, senza toccare altro.
  • Trombone di sconfitta ZITTO (TROMBONE_AL_GAME_OVER = false): al game over parte solo la musica. Non è stato rimosso niente — file, player e @export restano dove sono, e la costante li riaccende. Spento in entrambi i rami (partita normale e spettatore in multigiocatore), che è il punto dove una mezza modifica lascerebbe il trombone vivo in un caso su due.
  • La dissolvenza in uscita resta: RICOMINCIA ed ESCI continuano ad aspettare che la musica sfumi prima di cambiare scena.
  • ⚠️ NON MISURATO: come suona, che è tutto il punto. bash tools/autotest/gioca.sh, poi F1 e lo slider Fame a 0.

Sotto il giornale del game over adesso c'è la musica2026-08-18

• [feat] Montato il brano del game over (assets/sounds/gameover.ogg, 2:49), quello scritto sul prompt di MUSICA_AI_PROMPTS.md §12. Prima lì c'era silenzio: passava solo il trombone di sconfitta.
  • ⚠️ Perché non bastava la musica del mondo, ed è la ragione per cui serve un player nuovo: al game over l'albero va in pausa, e il nodo Music di Main.tscn non ha un override di process_mode — quindi si ferma. Il trombone si sentiva proprio perché sta sotto l'HUD con process_mode = ALWAYS. Il player della musica è stato messo lì accanto, con lo stesso trattamento.
  • Sul bus «Music», non su «SFX»: è musica, e deve spegnersi con l'interruttore MUSICA delle Opzioni come tutto il resto. Ripiego su «Master» se il bus non c'è, com'è già in World.
  • Parte in entrambi i rami del game over — quello normale e quello dello spettatore in multigiocatore — e si ferma su RICOMINCIA/RIVINCITA: senza quello stop continuerebbe sopra la partita nuova, perché il player è ALWAYS e non lo fermano né la pausa né il cambio di scena.
  • Niente loop: il brano dura più di quanto chiunque resti a guardare la classifica, e un riavvio secco a metà sarebbe peggio del silenzio.
  • Convertito da WAV a OGG (31 MB → 2,9 MB), come tutte le altre musiche del progetto.
  • Due dissolvenze, chieste da Ivan dopo il primo ascolto. In entrata la musica sale da −40 dB al massimo in 5,26 secondi, che è la durata misurata del trombone di sconfitta: i due suoni partono insieme, ma la musica arriva al volume pieno mentre la fanfara finisce, così si danno il cambio invece di accavallarsi. In uscita scende in 0,8 s, e RICOMINCIA/ESCI aspettano che abbia finito prima di cambiare scena — senza quell'attesa la dissolvenza verrebbe troncata di netto, cioè il difetto che si voleva togliere.
  • ⚠️ Il dettaglio che avrebbe fatto fallire tutto in silenzio: al game over l'albero è in pausa, e un tween normale non avanza di un frame — il volume sarebbe rimasto inchiodato a −40 dB e la musica sarebbe partita muta, senza un errore. Serve TWEEN_PAUSE_PROCESS, per la stessa ragione per cui il player è ALWAYS.
  • Misurato (bash tools/autotest/probe_musica_gameover.sh, ESITO=OK): il brano si carica come audio; il nodo MusicGameOver esiste davvero nella scena ed è ALWAYS (il compile-check non verifica i path $Nodo, quindi un @onready nullo non darebbe errore); e in pausa il volume sale davvero, da −40 a −31 dB in mezzo secondo. Con controprova: un tween impostato per fermarsi in pausa resta a −40, il che dimostra che la pausa era attiva e che la prova non è passata per caso.
  • Come provarlo: bash tools/autotest/gioca.sh, poi F1 e lo slider Fame a 0 — si collassa subito e parte il giornale. ⚠️ NON MISURATO: la resa all'ascolto, che è tutto il punto di un brano — la giudica Ivan.

L'identità EOS smette di suicidarsi a ogni avvio2026-08-18

• [fix] SU-446 (KO, quarto giro) — l'account non «scade» più a ogni riapertura del gioco. Ivan, su iPhone con Apple: entrato, nome inserito, prima partita a posto e riga verde; poi chiuso e riaperto il gioco, e la riga non era più verde, la partita nuova non arrivava in classifica, e la schermata account diceva «il collegamento con Apple è scaduto».
  • ⚠️ La causa radice sta in due righe del plugin, e i tre giri precedenti l'avevano mancata: heos/hauth.gd:317-324, dentro login_anonymous_async(), fa delete_device_id() e poi create_device_id() — cioè cancella l'identità del dispositivo e ne crea una nuova a ogni singolo avvio. E EOSBridge.setup() finiva sempre lì. Non scadeva il token di Apple: veniva buttata via l'identità EOS a cui l'account era collegato. La domanda giusta non era «come rientro» (che sa fare solo Epic, con il suo token silenzioso), era «perché sono uscito».
  • ⚠️ E rendere persistente il Device ID da solo NON bastava, il che è la scoperta che ha salvato il quarto giro dal diventare un quinto: HAuth._create_user_async() dimostra che il login con un account crea un secondo giocatore, distinto da quello del dispositivo. Un PUID stabile ma «sbagliato» avrebbe lasciato lo stesso sintomo.
  • Quindi la cura è in due tempi: identità del dispositivo persistente (si entra con quella che c'è, se ne crea una nuova solo al primo avvio in assoluto, e delete_device_id resta confinato al logout), più la fusione dell'identità del dispositivo dentro l'account al momento del login. Da lì in poi sono lo stesso giocatore, e ogni avvio entra dritto nell'account — per Apple, Google ed Epic allo stesso modo, senza trucchi diversi per ciascuno.
  • Il plugin non è stato toccato: tutto vive in EOSBridge, come stabilito da SU-451 per il collegamento account — una libreria di terzi patchata si ripaga a ogni aggiornamento.
  • ⚠️ Un pericolo introdotto e chiuso nello stesso giro: fondere un apparecchio che appartiene già a un altro account ne cancellerebbe il giocatore. Ora c'è un fatto persistito che lo impedisce, e per l'utente il rimedio è uscire e rientrare.
  • 📌 Una misura che smentisce una misura vecchia, e lasciata onesta: TransferDeviceIdAccount è la stessa chiamata che SU-431 aveva visto fallire con 7005, e che partendo dall'identità persistente riesce (result=0). Perché prima fallisse non è stato isolato, ed è scritto così invece di inventare una spiegazione.
  • Corretto anche il messaggio fuorviante: «il collegamento è scaduto» diceva una cosa che non succedeva. Riscritto in 8 lingue.
  • ⚠️ NON MISURATO: la fusione con Apple e Google — qui non esiste un token nativo vero, quindi quel ramo non è mai stato eseguito. È lo stesso codice di Epic, senza rami per provider, ma «stesso codice» non è «misurato». Con l'account Epic vero del Mac sono invece misurati: persistenza fra processi, fusione riuscita, primo avvio assoluto, e che il logout non distrugge l'account.
• [change] Board di prova sul quartiere centro, per collaudare senza sporcare la classifica vera. OnlineLeaderboard.BOARD_PROVA_CENTRO punta a SU_TEST_CENTRO (stat e classifica create apposta nel Dev Portal, aggregazione MAX). ⚠️ È consegnata ACCESA e va rimessa vuota prima di una release: all'avvio stampa un riquadro di avviso e un push_warning, perché una board di prova dimenticata accesa farebbe più danni del problema che risolve. Controprova fatta: con la costante vuota il comportamento è identico a oggi.
  • 📌 Perché serviva una board nuova e non una pulizia: misurato da Ivan che in EOS cancellare e ricreare una stat con lo stesso nome fa riapparire i punteggi. I dati seguono il nome, non la definizione — quindi l'unico modo di avere una classifica vuota è un nome mai usato.